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

Hacker News Discussion ↗

An open-source startup is building an API layer on top of U.S. health information exchanges (HIEs) to simplify how providers and health IT vendors pull and push electronic health record data using standards like FHIR. Commenters probe how it compares to incumbents on coverage, cost, standards compliance, and regulatory constraints such as HIPAA, TEFCA, and state-level privacy rules, and note that current usage is largely limited to treatment rather than direct patient access. The conversation also highlights broader issues in healthcare interoperability: legacy standards, uneven data quality, misaligned incentives, and the trade-offs between centralized government-run systems and market-based, vendor-mediated networks.

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.