Skip to content

Metriport Record Retrieval Decision

Last updated: 2026-05-31

Decision

VIM will plan to use Metriport hosted as the initial external clinical record retrieval layer.

Metriport will be evaluated and integrated as a hosted service first, not as a self-hosted/open-source deployment. The intended architecture is:

Metriport hosted retrieval layer
  -> raw documents / normalized FHIR / consolidated patient data
  -> Medplum FHIR store
  -> VIM clinical workflows, summaries, care plans, and review tools

Medplum remains the preferred VIM-controlled FHIR/application substrate. Metriport is the upstream record-retrieval and normalization service.

Primary use case

VIM expects two retrieval patterns:

  1. Large upfront historical pull
  2. Retrieve available historical records for a starting cohort/roster.
  3. Ingest useful FHIR resources and document references into Medplum.

  4. Preserve source/provenance and raw-document access where possible.

  5. Ongoing appointment-based pulls

  6. Trigger refreshes for patients with upcoming appointments.
  7. Prefer webhook/status-driven workflows so care teams know whether records are ready, unavailable, unchanged, or failed.
  8. Use the results to support clinician review, health-management planning, and longitudinal patient context.

Why Metriport

Metriport is the preferred initial choice because it is well aligned with VIM's current needs:

  • API-first clinical record retrieval: designed for programmatic patient record queries rather than manual chart chasing.
  • National network orientation: supports HIE-style retrieval through major national exchange networks such as CommonWell/Carequality/eHealth-style coverage, subject to production access, patient matching, network participation, and permitted purpose of use.
  • FHIR-native output: converts/normalizes external records into FHIR R4-oriented consolidated patient data, which fits the Medplum direction.
  • Raw + structured data path: supports both raw documents and consolidated FHIR output, which lets VIM keep clinical traceability while building structured workflows.
  • Webhook/asynchronous model: appropriate for both large initial pulls and appointment-based refreshes, where retrieval may take time and completion needs to be tracked.
  • Open-source transparency: even though VIM will start hosted, the open-source repo provides visibility into data models, converter behavior, and implementation patterns.
  • Lower operational burden than self-hosting: hosted Metriport avoids near-term AWS/IHE/CommonWell operations, certificate management, and production network plumbing.

Alternatives considered

Alternative Why not first choice now Notes
Particle Health Strong direct alternative for national clinical data APIs. Keep as primary fallback/comparison vendor if Metriport pricing, coverage, or access terms are not acceptable.
Health Gorilla Strong enterprise/network option with Carequality/CommonWell/eHealth-style exchange and QHIN positioning. Worth future diligence if VIM needs heavier enterprise network posture or TEFCA/QHIN strategy.
Zus Health Potentially strong longitudinal health-data platform. May overlap with Medplum as a patient-data substrate; evaluate only if VIM wants more than a retrieval layer.
Redox Strong EHR integration platform. Better fit for direct EHR, scheduling, ADT, results, or partner integrations than primary national record retrieval.
1upHealth Strong FHIR/payer/patient-access orientation. More complementary for claims/CMS/patient-mediated data than provider treatment-based external chart retrieval.
Moxe Strong enterprise clinical data exchange, especially payer/provider workflows. May be less startup/API-first for VIM's initial treatment-based provider workflow.
Direct network participation Maximum long-term control. Too operationally heavy for initial evaluation: agreements, certificates, record locator, retrieval, parsing, normalization, and monitoring would all need to be built/operated by VIM.

Key assumptions to validate

Before using Metriport for real patient data, VIM must validate:

  • VIM's legal/clinical basis for Treatment-purpose record retrieval.
  • BAA, HIPAA, SOC 2, audit logging, retention, deletion, and security requirements.
  • Production access path and any prerequisites for CommonWell/Carequality/eHealth/pharmacy data.
  • Patient notice/consent/authorization and HIE opt-out workflow.
  • Network reciprocity/data-contribution obligations.
  • Pricing for upfront roster pulls plus recurring appointment-based refreshes.
  • Expected match rate, latency, and coverage for VIM's target patient population.
  • FHIR bundle quality, source provenance, stable IDs, document traceability, and Medplum ingestion behavior.
  • Restrictions on downstream AI summarization, clinical decision support, or derived-data use.

Initial implementation plan

  1. Obtain Metriport hosted sandbox/API access.
  2. Configure a non-PHI test workflow with synthetic/sandbox patients.
  3. Create a test facility and test patients.
  4. Trigger document queries and consolidated data queries.
  5. Capture webhook/status events and error cases.
  6. Export raw documents, document references, and consolidated FHIR bundles.
  7. Test ingestion into Medplum dev using synthetic/sandbox data only.
  8. Evaluate FHIR resource quality, provenance, duplication, clinical usefulness, and workflow fit.
  9. If sandbox passes, design a small production pilot with explicit security/compliance/clinical sign-off before any PHI use.

Non-goals for the initial phase

  • No direct self-hosted Metriport production deployment.
  • No direct CommonWell/Carequality implementation by VIM.
  • No real PHI in the Medplum dev environment until approved.
  • No vendor lock-in decision beyond the initial hosted Metriport evaluation path.

Decision status

Status: Accepted for initial planning and evaluation.

Owner: Jeremy / Robbie.

Review required before PHI or production use: engineering, security/compliance, clinical leadership, and legal/privacy.