Integration Overview¶
Metricis can operate as the primary research-data platform or as a governed delivery and processing layer around existing systems. Integration is explicit per study, registry, site, and deployment.
Integration families¶
| Integration | Use | Availability |
|---|---|---|
| REDCap | REDCap-managed study metadata/data, event and field mappings, DET webhooks, and retryable synchronization | Configured |
| REST API | Research operations and, when enabled, scoped analysis access | Available / feature-dependent |
| HealthKit and Health Connect | Mobile device and wearable signal ingestion | Configured |
| Email, SMS, and push providers | Magic links, reminders, and notifications | Configured |
| Public edge sites | Published study/registry information and interest/join pathways | Configured |
| Statistics-package bundles | Governed analysis snapshots and manifests | Feature-gated |
Integration principles¶
- Declare the system of record. Metricis does not silently fall back from an external authority to a different local workflow.
- Map stable identifiers. Events, instruments, fields, participants, sites, versions, and purposes need explicit mappings.
- Keep credentials server-side. Clients do not receive REDCap, notification-provider, or device-service secrets.
- Make retries idempotent. A repeated webhook or queued job must not create a second logical record.
- Expose failure. Reconciliation, retry state, and terminal errors should be visible to operators.
- Preserve provenance. Imported, transformed, and exported data record their source, mapping, and relevant version.
Continue to REDCap, REST API, or device signals.