-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
fhir-server
FHIR server for Metriport - an open-source universal API for healthcare data. (by metriport)
-
fhir-data-pipes
A collection of tools for extracting FHIR resources and analytics services on top of that data.
-
fasten-onprem
Fasten is an open-source, self-hosted, personal/family electronic medical record aggregator, designed to integrate with 100,000's of insurances/hospitals/clinics
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Hey HN, Dima and Colin here from Metriport (https://www.metriport.com/), an open-source platform that makes it easy for healthcare organizations to access and exchange medical data for their patients. We support all major healthcare IT systems in the US. Try out our product and watch a demo video here: https://docs.metriport.com/medical-api/getting-started/quick...
If you’ve been to doctors in the US, you may have encountered the problem we’re solving: 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!
Thank you - glad to see there are others that are aware of the mess of healthcare data!
> Would it make sense to go one step further and bet on the future being the cloud - and start supporting existing cloud solution like Google Healthcare (FHIR) API (and others) as storage layers?
Oh for sure - to clarify, we're open-source, but we definitely have a managed cloud solution. For our backend, we currently self-host the OSS version of HAPI FHIR on AWS: https://github.com/metriport/fhir-server. It works pretty well for our purposes, and we'd prefer to not use a managed solution like the Google FHIR storage for this. Mainly for customizability, control, and to keep things OSS.
With that being said, people using Metriport can store the FHIR data and raw docs coming from our API in whatever solution they wish - including the Google FHIR storage! Everything is standardized to FHIR R4, so syncing to another backend is straightforward.
In fact, a customer of ours recently used this OSS solution to sync Metriport data to their Google cloud: https://github.com/google/fhir-data-pipes
Thank you - glad to see there are others that are aware of the mess of healthcare data!
> Would it make sense to go one step further and bet on the future being the cloud - and start supporting existing cloud solution like Google Healthcare (FHIR) API (and others) as storage layers?
Oh for sure - to clarify, we're open-source, but we definitely have a managed cloud solution. For our backend, we currently self-host the OSS version of HAPI FHIR on AWS: https://github.com/metriport/fhir-server. It works pretty well for our purposes, and we'd prefer to not use a managed solution like the Google FHIR storage for this. Mainly for customizability, control, and to keep things OSS.
With that being said, people using Metriport can store the FHIR data and raw docs coming from our API in whatever solution they wish - including the Google FHIR storage! Everything is standardized to FHIR R4, so syncing to another backend is straightforward.
In fact, a customer of ours recently used this OSS solution to sync Metriport data to their Google cloud: https://github.com/google/fhir-data-pipes
> In the US, this is part of the EHR push, each EHR is supposed to accept any outside application
To be explicit for readers here, outside applications can connect to some EHR systems using SMART on FHIR, but not all (this is what Apple Health supports in their PHR) - and this is separate from HIEs. For reasons OP mentioned, this is impractical for treatment at scale, but is currently the best way to get your health records in your pocket, or to insurance companies, for example.
Fasten is a great OSS project that facilitates this flow for individuals, and I'd suggest you check them out: https://github.com/fastenhealth/fasten-onprem
> getting a hook into the vendor operated HIEs
This is a only part of the equation - for example, one of the biggest networks we connect with is Carequality, and this is more of a framework that's not operated by any vendors. Rather, vendors connect to a shared directory and speak the same language for medical data exchange.
> The evil part of the operation is that now Metriport has proxy access to the data and eventually will get hacked
This just speaks even more volumes to our open source approach - we're not hiding behind obscurity for security.
> and bought by private equity that will sell the data to TransEquirian Insurance Score agencies.
Only if someone wants spend a long time in prison! We can not legally do anything with the data we have proxy access to, except deliver it to the healthcare organizations we work with that are involved with treating the patient - nor would we want to. There are acquisition events with healthcare organizations all the time, and the HIPAA rules protecting the data do not change.
Hopefully you can agree that, especially with us being the only vendor in the space that's open source, there is no evil at play.
Best of luck to Metriport. I've worked for years in the healthcare interoperability space and there are still a huge number of unsolved problems impacting cost and patient care.
There actually is a standard for converting C-CDA records to FHIR. It isn't 100% complete but serves as a useful starting point. If you find problems with it you can feed those back into the standards process.
http://hl7.org/fhir/us/ccda/
Microsoft has an open source library which works pretty well and I think implements at least part of that standard, although I haven't used it lately.
https://github.com/microsoft/FHIR-Converter
FHIR also includes unstructured narrative text so it isn't necessarily better than C-CDA in that regard. You'll find that data quality problems come down more to provider systems configuration and charting policies rather than data formats.
Related posts
-
Open-source API for integrating with Garmin devices
-
Metriport: Open-source and universal API for health data
-
Show HN: Metriport – Open-source universal API for health data
-
Show HN: Metriport – open-source universal API for health data
-
We just launched an OSS Health Devices API to help developers gain access to their users’ health data from various wearables, RPM devices, and mHealth apps.