If you’ve been to doctors in the US, you may have encountered the problem: how does a healthcare provider get access to your up-to-date medical history to treat you properly? Reliance on archaic methods is still the norm: typically you, or your provider, need to call the facilities where you’ve previously received treatment (assuming you remember them all), just to have them send your records via fax (yep, fax). This can take weeks, only then to have a provider sift through hundreds of pages of unstructured docs, just to figure out basic things like your active medication list, what conditions you may have, latest lab results, etc. This not only delays treatment, it can cause improper treatment, since the medical history is critical for treatment decisions.

For example, here’s a crazy story from a customer of ours: recently a patient came to them asking for a specific medication. When the provider pulled their medical history through Metriport, they saw that the patient had had a heart attack in the last 6 months. (The patient had omitted to mention this.) In such a case, the medication they were asking for could cause death! Needless to say, the provider did not fulfill that request—but they did begin to look for medications that could actually work for that patient.

Many providers use Electronic Health Record (EHR) software to manage their patients’ data, but many EHRs don’t talk to each other, which means a patient’s data is more often than not siloed across disparate systems with incompatible data formats. More recently, Health Information Exchanges (HIEs) emerged to make the exchange of patient medical data possible between different providers. HIEs are essentially a peer-to-peer network for clinical data exchange. These networks helped push interoperability in the right direction, but their underlying technology is still based on older tech from the 90s, requiring SOAP-based protocols for transactions, using mostly C-CDAs (XML files), PDFs, and images to exchange medical data. A patient with a chronic condition may have thousands of such files across dozens of providers, and they all contain messy, likely unstructured, and duplicate information. Even if you spend lots of dev time, and money, connecting to all of these exchanges (like we did), you’re still left with the tough problem of making this medical data actually usable for providers.

We did YC in S22, starting with a quantified self personal health app (this was our Show HN: https://news.ycombinator.com/item?id=29800932 - it didn’t get very far!). Working on clinical use cases for the app ran us straight into this insane rats’ nest of 30-year-old technologies, all incompatible with each other, just to integrate medical data into our product. Vendors attempting to solve this problem wanted to lock us into $100k+ yearly contracts without even letting us try their closed-source product! Integration time would have been months, and developer docs were a whole new order of jank. It took us a while to realize there really was no good solution to this—it was hard to believe—but then we started talking to other healthcare companies and found they had the same problem. At that point it was a no-brainer to pivot to this instead. We kept the name Metriport though :).

Metriport connects to all 3 major HIE networks (CommonWell, Carequality, and eHealth Exchange), and provides an API and dashboard. Here’s how it works: (1) You input basic patient demographics (name, DOB, gender at birth, address); (2) we search through hundreds of thousands of providers across multiple HIEs for the patient’s records; (3) Once the records are found, we fetch all of them and convert them into usable JSON data - standardized to FHIR; (4) The data, and raw files, are made available on the API and dashboard.

You can render the data in a way that’s immediately useful for providers, like deduplicated PDF medical record summaries. From there, you can also use Metriport to contribute new clinical patient information back to the providers in the network, regardless of what EHR they use—eliminating the need for many painful one-off EHR integrations. It’s a little known fact that you can do this using HIEs without needing to write individual integrations to EHRs like Epic, Athena, and Cerner, for example.

The value of this approach is that healthtech companies and providers don’t have to go build dozens of EHR integrations themselves, or have to know where patient data is located, and can instead tap into a single “internet of healthcare data”. Going from entering inputs to getting a comprehensive medical record summary is done in 3 minutes on average. Compare that to weeks using fax machines just to get messy data!

You may be wondering how the search for records is done, using only patient demographics. Essentially, these networks consist of a bunch of nodes talking to each other asking “hey, do you have records for John Doe?”. So, this boils down to sending HTTP requests containing the patient’s demographics to a bunch of endpoints, and the endpoints returning the ID representing the patient in their system if there’s a match. You’ll be surprised (or at least dismayed) to hear that there is no standardization for how patient matching is determined across systems in the networks, which is problematic with something as highly variable as a person’s demographics. This means if one system wants to consider a single typo in the patient’s first name a mismatch, they can go ahead and do so—making it difficult for others to find records in their system. This problem is so pervasive that one of the national HIEs started an initiative to get other network participants to share their patient matching algorithm to help improve response rates for all systems in the network. Sadly, only one vendor agreed to share their matching algorithm. To combat this status quo, we’ve open-sourced our patient matching algorithm, which uses a variant of the Fellegi-Sunter model, and we hope other vendors will follow suit in the future: https://github.com/metriport/metriport/blob/3e82111bc081a39a...

Another big part of this is the data mapping from one format to another. If you’re not familiar with healthcare data, FHIR is the latest and greatest standard that’s ubiquitous in modern systems. In Metriport, FHIR is represented with JSON. The older standard is HL7v3 (C-CDA), which is what all healthcare information exchanges still use today, and what EHRs typically export - C-CDAs are messy XML documents that have structure, but also contain a lot of unstructured data in HTML format, or free text. So you can imagine, the ability to convert C-CDA medical records to something actually usable like FHIR, is pretty important. Given that it’s important, you’d also think it’s a fairly solved problem, with plenty of resources/tools to wrangle the data… nope. Again, there are little to no standards here, and you have different vendors building proprietary systems in-house, attempting to solve the same problem, with mediocre black-box results that you can’t trust. We see making healthcare data usable more like a public body of knowledge that can be improved upon, and don’t think this work should be closed off to the world, so we also open-sourced our FHIR converter (https://github.com/metriport/metriport/tree/develop/packages...), and you can give it a spin here: https://docs.metriport.com/converter-api/getting-started/qui.... In the future, we will also leverage things like OCR on PDFs to do clinical data extraction, and use LLMs to make even more concise medical record summaries.

Making Metriport open-source was a decision we made from day one, based on our philosophy that transparency leads to innovation, especially in healthcare.

From a security and compliance standpoint, we’re fully SOC 2 Type 2 and HIPAA compliant (https://security.metriport.com/). Additionally, using Metriport for patient data exchange today requires a Treatment purpose of use under HIPAA - which means that only Covered Entities, or Business Associates who work with Covered Entities, can use Metriport. This means that companies doing things such as clinical trials recruitment, for example, can’t use Metriport, but a primary care provider, or a clinical decision support vendor, can. This is due to current requirements set forth by HIEs, which may open up to support alternative use cases in the future, such as Individual Access Services (IAS).

We charge per full medical record retrieval for a patient (which we call a query). This starts at $1 per query (with a monthly minimum), and scales down from there based on volume. We only charge for queries that return at least one record (and even if a query returns 1000 documents for a single patient, we still count that as a single query) - no charge is incurred for sharing data back to the networks, or making API calls to generate medical record summaries, for example.

You can see all the code for Metriport in our public GitHub repo: https://github.com/metriport/metriport. For anyone wanting to give us a whirl, you can do so by getting started with our free sandbox environment (https://docs.metriport.com/medical-api/getting-started/quick...).

We’re looking forward to hearing what you think, and happy to answer any questions you may have, as the health information exchange space is pretty niche - thanks for taking the time to read this, we hope it was interesting!