Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

Hacker News Discussion ↗

Interoperability Strategy

  • Metriport connects to multiple health information exchanges (HIEs) and frameworks (e.g., Carequality, CommonWell, eHealth Exchange) rather than to individual EHR instances.
  • This aims to avoid one-off integrations with each provider or EHR and to solve “record location” and patient matching at scale.
  • Vaccine registries are a separate, older HL7v2 ecosystem; current support is limited but seen as a future target.

Standards, Coverage, and Use Constraints

  • Uses FHIR R4, aligned with US Core and planning for USCDI v3 (2026 ONC requirement).
  • Early FHIR implementation guide exists; a formal capability statement is planned.
  • Currently limited to HIPAA “Treatment” purposes of use; only covered entities and their business associates can use it.
  • Reported coverage is ~93% of the US population via connected networks; reasons for the remaining gap are not explained.

Product Capabilities & Architecture

  • Provides an API to pull comprehensive records and also to push data back into EHRs through HIEs.
  • Supports sending FHIR, C-CDA, PDFs, and images; FHIR is converted to C-CDA where needed so structured data appears directly in the EHR chart.
  • Backend uses a self-hosted, open-source HAPI FHIR server on AWS; customers can replicate data into other FHIR stores (e.g., Google Cloud) if desired.

Comparison to Existing Networks/Vendors

  • Positioned as an open-source alternative to “network of networks” vendors (e.g., Health Gorilla, Particle Health) and to joining eHealth Exchange directly.
  • Claims: more transparent internals, better pricing model (per full-record retrieval, no long-term lock-ins), and close, consulting-style implementation support.
  • Skeptics note traditional provider orgs often don’t care about OSS and that data quality varies widely across health systems.

Privacy, Security & Regulation

  • Maintains audit logs for all transactions; HIEs themselves generally act as directories rather than data stores.
  • Interstate privacy nuances (e.g., abortion-related protections in California) are handled case by case.
  • Thread debate over ISO/FDA requirements: some argue heavy certification is needed in certain jurisdictions; others reply that such middleware is typically not an FDA-regulated device and that OSS is widely used.

Patient Access & Consumer Apps

  • Metriport cannot currently be used by individuals to fetch their own records from HIEs; TEFCA/IAS support is seen as a future possibility but not yet practically available.
  • For now, patient-facing apps must use EHRs’ individual-access APIs (SMART on FHIR / portal logins), which is described as high-friction and fragmented.

Global Context and System Design

  • Commenters from countries with centralized, state-run health record systems (e.g., Estonia, Finland) highlight the convenience of unified national portals, though certification costs for app developers can be high.
  • In the US, some states and regions are slowly moving toward more centralized EMR deployments (e.g., statewide Epic projects), but the landscape remains fragmented.

Community Reactions & Open-Source Model

  • Many express enthusiasm that an open-source, modern API is tackling entrenched healthcare data silos and replacing fax-based workflows.
  • Investors reportedly accepted the OSS model because the operational/compliance “moat” is large even if code is forkable.
  • Some criticize the pivot away from a previous consumer app and feel existing users were left behind; others ask for a detailed postmortem on that earlier product.
  • Concerns are raised about potential future misuse of data (e.g., sale after acquisition); responses emphasize legal constraints (HIPAA), open-source-driven transparency, and a stated refusal to exploit data beyond treatment use.