metriport: stitching US health data networks into one FHIR record

The problem is that US health data is fragmented by network

Metriport is described as providing real-time access to medical data for 340+ million individuals across the US, turning scattered patient records across all major healthcare IT systems into structured information. The fragmentation is not accidental, it is structural. A patient's history lives in a hospital network here, a pharmacy network there, a lab vendor somewhere else, and an EHR in the clinician's building, and each speaks its own dialect. The project manages dozens of connections across all national HIEs and QHINs, state and regional HIEs, ADT networks, pharmacies, labs and EHRs, and then matches, extracts, standardizes, deduplicates and enriches records before converting them into a unified data model. That last list is the actual product. The value is not in fetching a record, it is in the record matching, which is the hard part when the same person appears under different names across a dozen systems.

Four integration families, and ADT is the one that changes behaviour

The Integrations section is where the coverage becomes concrete. HIE Networks: a single Network Query reaches all four national networks, TEFCA and the QHINs, Carequality, CommonWell and eHealth Exchange, plus state and regional HIEs. ADT Networks: enroll a patient once and their admissions, transfers and discharges are pushed as they happen, from the national ADT networks Bamboo Health and PointClickCare and from state and regional HIEs. Pharmacies and Labs: medication fill history and notifications from Surescripts and PBM networks, reconciled onto the record you already query, and lab history and notifications from Quest. EHRs: turnkey bi-directional connections to most major EHRs that reconcile internal chart data with everything retrieved from outside it into one interactive longitudinal record. The ADT category is the one with a different character, because it is push rather than pull, which is what makes the ambient monitoring and transition of care use case possible at all.

Two ways to consume the harmonized record

The Unified Data Platform section describes the delivery side, and there are more than two options. The Harmonization Engine takes C-CDA, HL7v2 and scanned PDF inputs and produces a single FHIR R4 bundle, so the format at the source stops mattering. The API is described as universal and FHIR-native, and the diagram shows an app calling Metriport and receiving consolidated FHIR, webhook events and ADT feed payloads. The Data Warehouse flattens C-CDA, FHIR R4, HL7v2 and documents into normalized clinical tables, one table per FHIR resource type, with a single unified flattened schema applied across all of your data so you can run analytical queries. On top of that sit the Applications, including Ambient Monitoring and TCM, where a patient.discharge event leads to a retrieved encounter bundle and a same-day follow-up outreach, and the insights layer, which the Overview lists as AI medical record summarization, condition suspecting and surfacing care gaps. The repository is primarily TypeScript, and the top-level tree shows the shape: a packages/ directory with a lambdas package and a fhir-converter package, samples for python-fast-api and typescript-express, a Postman collection, and a fern/ directory for the API documentation.

A Lambda-per-concern build with a deliberate prepare-deploy step

The package.json shows how this is put together and it is a large npm workspace with npm workspaces under packages/ and a lerna.json alongside. The build is not a single command. There are separate prep targets: prep-lambdas prepares the packages/lambdas deployment, prep-converter prepares packages/fhir-converter, and prep-deploy chains install-deps, build:cloud, test, prep-lambdas and prep-converter. A separate build:staging variant sets ENV_TYPE=staging, and a build:cloud target exists so the Lambda artefacts can be produced independently of the workspaces. Every one of those targets is prefixed with a SCRIPT variable being passed through to the lambda scripts, which is the mechanism for reusing one script set across build, clean and typecheck. There is also a preinstall that installs rimraf and is-ci globally, and husky is wired up through prepare-dev, so git hooks are installed locally on clone.

The licences are the first thing to check

The repository tree carries both a LICENSE file and a LICENSE-APACHE file, and the README badge reads AGPLv3, while the project metadata records the licence as a custom one that GitHub cannot classify. The LICENSE-APACHE file in the tree is the standard dual-licence pattern, and the badge points at the AGPL as the primary. The practical point is that this is not a permissively licensed library you can drop into a closed product without reading what you are signing up for, and the AGPL has obligations around network use that a plain MIT does not. There is also a SECURITY.md and a SUPPORT.md in the root, a CONVENTIONS.md, a commitlint configuration with a custom parser preset, a .gitleaksignore, a .husky directory and a .prettierrc.yaml, which is the standard shape of a company-run open source project. The default branch is develop rather than master, which is the one piece of repository state that tells you where work actually lands.

The compliance claims are the selling point and cannot be verified from here

The Security and Privacy section states that Metriport is HITRUST r2 certified, SOC 2 Type 2 certified and HIPAA compliant, with a trust centre linked for the details and three badge images for the three certifications. Those are claims about the hosted service and its operational controls, and they say nothing about the code in this repository. The distinction matters for an adopter. What you can read here is the code and the licences; what you cannot read here is the trust centre, the connect terms, the data processing agreements, or the uptime behaviour of the network connections. The README gives operational scale figures as well: 4.2 billion network requests a month and a first structured record returned in under 15 seconds. The company was founded in 2022, is headquartered in San Francisco, and the README names Amazon One Medical, Strive Health, Color, Sollis Health and Canvas Medical as teams building on it, and it is a Y Combinator S22 company. Those are all statements by the project about itself, and the point of listing them here is to say which claims to verify with the vendor before signing.

Editorial conclusion

Adopt metriport if you are building care delivery, value-based care or health technology on US patient data and you would rather buy the network connections, the record matching and the harmonization than build them. Do not adopt it expecting an open source FHIR library you can vendor, because the repository is the platform itself and the licences are custom, with an AGPL badge on the README and separate Apache terms in the tree. Before you commit, read LICENSE, LICENSE-APACHE and CONVENTIONS.md, confirm the connect and data access terms in the documentation rather than in the code, and check the default branch, which is develop rather than master.

Frequently asked questions

Official sources

1. Issues
2. metriport/metriport on GitHub
3. Project website
4. README
5. Releases