Trust and Governance¶

Metricis is designed to support governed clinical-research workflows. Technical controls are only one part of a compliant system: the sponsor or operator remains responsible for intended use, validation, infrastructure, procedures, training, oversight, and applicable law and policy.

Control families¶

Identity and authorization¶

Researcher roles, study or registry scope, site access, participant accounts, caregiver attribution, scoped API tokens, and service-layer authorization limit who can perform an operation in a context.

Electronic records and signatures¶

Versioned records, reason-for-change capture, attributable signatures, state transitions, and audit history support workflows designed for requirements such as 21 CFR Part 11. They do not by themselves certify a deployment as compliant.

Consent versions, assent, authority, re-consent, purpose choices, and withdrawal effects are represented as enforceable state. Sensitive operations check authorization at the service layer rather than relying only on what a UI previously displayed.

Data integrity and provenance¶

Metricis records actors, timestamps, research context, governing versions, and transformation provenance. Released configuration and collected records follow controlled transitions; derived results identify their algorithm or configuration version.

Quality and monitoring¶

Validation, missing-data review, queries, risk-based source data verification, signatures, locks, and audit reconstruction support ICH E6(R3)-aligned research operations. The protocol and monitoring plan determine how those controls are used.

Privacy and data minimization¶

Deployment configuration can keep integration credentials server-side, redact sensitive values from logs, restrict exports, apply de-identification policy, and separate identity from research context. Privacy obligations and hosting choices remain deployment-specific.

Claim boundaries¶

Metricis documentation uses these rules:

Say a control supports a regulated workflow; do not claim that software alone makes an organization compliant.
Distinguish platform availability from deployment configuration and study-specific validation.
Do not describe research measures as diagnostic unless a separately governed intended use and evidence base support that claim.
Identify external dependencies such as REDCap, notification providers, mobile platforms, device APIs, and model providers.
Treat live OpenAPI, released configuration, audit records, and export manifests as operational evidence; treat prose as guidance.

Deployment review¶

Before production use, an operator should define intended use, data classification, hosting region, identity and access policy, backup/recovery, key and credential management, incident response, retention, validation evidence, standard operating procedures, training, vendor responsibilities, and protocol-specific consent/monitoring requirements.

See Data quality and monitoring, eConsent, and Exports and analysis for workflow details.