[HN Gopher] Launch HN: Metriport (YC S22) - Open-source API for ...
___________________________________________________________________
Launch HN: Metriport (YC S22) - Open-source API for healthcare data
exchange
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.... Oh
and here's our github: https://github.com/metriport/metriport. 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!
Author : dgoncharov
Score : 58 points
Date : 2024-05-23 15:38 UTC (7 hours ago)
| pelagicAustral wrote:
| Congrats on the launch, the site it's quite nice and
| informative...
|
| "Access comprehensive EHR data for your patients in seconds, with
| FHIR R4...", I got Vietnam flashbacks from building an app to
| interface with the NHS Covid Vax certificate, that was my first
| encounter with FHIR... And honestly, all I wanted by the end of
| the day was to set myself on FHIR! Such a complex abstraction.
| Anyway, Godspeed!
| dgoncharov wrote:
| Hahaha definitely feel you there - also see you're a seasoned
| healthcare vet with the FHIR puns!
|
| Integrating with vaccine registries is another unique beast,
| and we haven't had the pleasure of doing that yet. Each state
| has actually has its own registry, they don't even use FHIR,
| and instead use an even older standard than C-CDAs - CAIR2
| HL7v2:
| https://www.cdph.ca.gov/Programs/CID/DCDC/CAIR/CDPH%20Docume...
|
| We don't support this yet - but we'll get there.
| zaking17 wrote:
| Congrats Dima & Colin! We've been greatly impressed with
| Metriport. If there was ever a place that needs tons of well-
| designed & open-source software, it's medical records.
| chrisfrantz wrote:
| Congrats Dima and team, it's been cool watching you build this
| over the last couple of years.
| nmitchko wrote:
| How does this compare to ehealthexchange or other qhins that have
| many years of experience and charge lower costs?
| dgoncharov wrote:
| > How does this compare to ehealthexchange
|
| Good question! eHealth Exchange (eHEX) is one of 3 national
| HIEs that we connect to (currently through Carequality). eHEX
| is mainly focused on connecting to state-level regional HIEs,
| which cover a different portion of providers than CommonWell,
| or Carequality do.
|
| For example, Cerner is a major EHR vendor (used by the VA and
| others) whose data can only be accessed through CommonWell,
| since they don't participate in other HIEs.
|
| > that have many years of experience
|
| Relatively speaking, modern HIEs are a relatively new concept
| (Carequality was founded in 2014) - so extra years of
| experience doesn't necessarily add any value, and usually just
| results in more legacy tech to deal with!
|
| > charge lower costs?
|
| This isn't necessarily true - since you brought up eHEX, see
| their pricing page: https://ehealthexchange.org/pricing-payers-
| vendors-and-for-p...
|
| TL;DR just to get started it's going to cost you $20k + some
| months to integrate, $12.5k/yr as the base membership fee (up
| to $400k if you make a lot of money!), and they charge a per-
| query price.
|
| The caveat here is per-query in eHEX, isn't what a query is in
| Metriport. They literally mean every single query (remember the
| HTTP requests to thousands of endpoints to find patient
| records, each one of those would be a query). So, if you want
| to integrate with eHEX only to get limited, messy C-CDA data,
| then you're looking at paying ~$0.80 per full record retrieval
| for a patient with 2k documents.
| adunsulag wrote:
| In your FHIR implementation, what version of USCDI do you
| support? I'm assuming you're following US Core profile's with
| your implementation guides? Have you implemented US Core STU
| 6.1.0? I know I'd be interested in using your converter and your
| exchange product if it could help facilitate what's required for
| ONC certification in 2026. I didn't see listed anywhere your
| capability statement URL that would give insight into what your
| doing.
|
| I congratulate you on your launch and I'm interested in your
| converter. I'm surprised you didn't mention the TEFCA effort and
| wondering if you're planning on becoming your own QHIN (Qualified
| Health Information Network) or if you just plan on interfacing
| with all of the major QHIN's?
|
| How are you handling interstate data exchange privacy
| requirements. Some states have restrictions on what data can be
| shared across state (thinking about this in terms of things like
| PDMP queries). I'm also wondering how you are handling the
| patient data access audit trail as well as information blocking
| filtering requirements. Perusing your documentation, it looks
| like you pass along the AuditEvent, does your system create
| additional audit trails for those who access the patient data? Or
| is that all being handled upstream w/ your QHINs?
| dgoncharov wrote:
| Thank you for the detailed questions - lots to dig into:
|
| > In your FHIR implementation, what version of USCDI do you
| support? I'm assuming you're following US Core profile's with
| your implementation guides?
|
| We will support USCDI v3 (which is the ONC requirement for
| 2026), and are following US Core as closely as possible with
| our FHIR converter.
|
| We're working on improving our FHIR documentation across the
| board, and have the beginnings of a FHIR-specific IG here:
| https://docs.metriport.com/medical-api/fhir/overview
|
| > I didn't see listed anywhere your capability statement URL
| that would give insight into what your doing.
|
| Yes good point - raised an issue for this here:
| https://github.com/metriport/metriport/issues/2142
|
| Please feel free to raise more issues on our repo if you'd like
| to see other improvements, and it would be great to get in
| touch about your use case!
|
| > you didn't mention the TEFCA effort and wondering if you're
| planning on becoming your own QHIN (Qualified Health
| Information Network) or if you just plan on interfacing with
| all of the major QHIN's?
|
| Haha this post was already close to exceeding maximum length,
| so we had to trim it down a bit - we thought no-one would know
| what TEFCA/QHINs are, but cool to see that you do.
|
| (For anyone reading this, TEFCA is the the document driving
| changes for different permitted purposes of use, and general
| governance of the networks, by the ONC. QHINs are one of the
| outputs of TEFCA, and are a flavor of HIEs that promise to
| bring more use cases, such as patient access, to the table)
|
| Unfortunately QHINs aren't very meaningful right now, since
| patient access queries are not mandated to be responded to by
| TEFCA. One of the HIEs we connect to, CommonWell, is already a
| QHIN, so we'll look at leveraging that, or becoming one
| ourselves, as we see fit.
|
| > How are you handling interstate data exchange privacy
| requirements.
|
| We handle this on a case-by-case basis based on: (1) what state
| our customers' patients' are located, (2) what kind of data
| they can/will be sharing, and (3) state requirements as you
| mention. For example, there is a new bill in California that
| will require special care of medical info as it pertains to
| abortion, contraception, and etc:
| https://trackbill.com/bill/california-assembly-bill-352-heal...
|
| > also wondering how you are handling the patient data access
| audit trail
|
| All transactions that interface with our system have audit logs
| attached to them by default (as per HIPAA/SOC2 requirements).
|
| > Or is that all being handled upstream w/ your QHINs?
|
| Nothing is handled upstream with the HIEs we connect to (note
| that QHINs are a different subject, and just enable future use
| cases outside of Treatment) - audit logging is up to each
| member of the network, including us. For example, Carequality
| only has a directory that implementers connect to, they don't
| store any data, and their only service is a directory of
| endpoints (it's more of a framework in that sense).
| gip wrote:
| Congrats on the launch. I work in healthtech and I'm always
| shocked by how fragmented and siloed the technology is in my
| industry. Both at the application level (EHR) and data level,
| leading to general inefficiency, high costs and innovation that
| do not always benefit the patients.
|
| Glad Metriport is addressing this! I hope you will drive a new
| level of standardization on an open and modern data exchange
| protocol.
|
| One question: at the product level, 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?
| dgoncharov wrote:
| 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
| gip wrote:
| > 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.
|
| Great. What I was trying to say is that there may be some
| value for larger customers if your company were building and
| managing something like it (basically a Fivetran for FHIR).
| whoomp12342 wrote:
| more data does not always mean good data. Health systems have
| varying level of quality and accuracy and in some cases, wrong
| information affects patient outcomes. The idea of connecting
| sparse systems has pros and cons.
|
| Consider someone who is misdiagnosed and switching doctors
| because they can't get the medical staff to believe them. They
| would be served by a fresh set of data and if re-diagnosed, so
| be it.
| dariosalvi78 wrote:
| Thank you for this, so much needed. I hope that you are going to
| come to Europe soon.
|
| Honest question, how was your experience with getting funding on
| an open source product within healthcare? My experience so far is
| that the field is, as you put it, 30 years back, also in terms of
| business models.
| dgoncharov wrote:
| Europe is its own beast of healthcare data problems for sure -
| perhaps one day.
|
| We get asked the fundraising question a lot, especially since
| we're open source. Once investors understood that we still have
| a hosted product we charge for, and that we have a large moat
| since someone could fork our code but it'd be very difficult to
| run the business (compliance, getting access to the different
| networks, understanding the niche space, etc) - open source
| wasn't a hinderance to raising.
|
| One thing we learned though, is that even though every human
| interacts with the healthcare system in some capacity - very
| few people know how things actually work. So, we had to tailor
| our pitches to make investors understand why our product
| matters, since generally even people that have healthcare
| experience, have no idea what the hell an HIE is.
|
| That, and our GTM allowed us to sell quickly, without needing
| to wait for slow moving hospital contracts, as are typical in
| healthcare - so some decent traction definitely helped.
| adamstecklov wrote:
| When you say that you can use the HIE's to contribute new data to
| the providers in the network, is that data actually going into
| the EHR's as if it was a record added in the EHR directly? If
| not, where are these contributed documents being stored?
| dgoncharov wrote:
| Yes!! A lot of folk think that the only way to get data into
| EHRs is by writing one-off integrations with a specific
| hospital IT system - but you can achieve the same thing using a
| single Metriport integration.
|
| We support 2 methods: (1) uploading FHIR data:
| https://docs.metriport.com/medical-api/api-
| reference/fhir/cr..., or (2) uploading documents like C-CDAs,
| PDFs, and images: https://docs.metriport.com/medical-api/api-
| reference/documen....
|
| If you send Metriport FHIR data we'll convert it to C-CDAs
| under the hood when responding to providers in the HIEs, and
| this data is parsed and integrated as structured data directly
| in the EHR in the patient's chart. Same thing goes if you
| upload C-CDAs to Metriport yourself.
|
| You can also share binary docs like PDFs and images, those will
| also be included in the patient chart in the EHR, but not
| parsed to discrete structured fields for display.
|
| So concretely, by using Metriport you can pull data from EHRs
| connected to the HIEs we connect to (like Epic or other major
| EHRs like Cerner, Athena, etc), and send data back, so that the
| provider using the EHR can see the updated patient data
| directly in the chart in the UI.
| adamstecklov wrote:
| Thanks for your response, going to play around with your API
| in the next few days. This sounds like its exactly what we've
| been looking for.
| superchris wrote:
| This sounds like a really excellent product, and I really love
| the description in this post of how you got there. Not working on
| anything just this minute that needs it, but I will definitely
| keep an eye out for opportunities.
| dgoncharov wrote:
| Glad you enjoyed the read - we're happy that we landed at a
| domain/space that we're both passionate about, and is
| impactful. Pretty great outcome as far as pivots go!
| lazyasciiart wrote:
| If I understood correctly: it sounds like HIEs were supposed to
| solve this problem but just duplicated it, so you're hoping to
| actually solve it this time?
| dgoncharov wrote:
| Pretty much! We're essentially building a service that
| leverages multiple networks - from a modern healthcare
| engineer's perspective, and focusing on product/data usability.
| robertlagrant wrote:
| Well done with the launch. This is a tricky space, but if
| successful you will be _very_ successful.
|
| A health platform I helped build was open sourced[0] (the apps
| built on it are closed source and deployed in NHS trusts). Feel
| free to dig around for any inspiration :-)
|
| [0] https://github.com/polaris-foundation
| dgoncharov wrote:
| Thank you! Glad to see more open-source in healthcare - was the
| idea here sort of like a reusable EHR backend for building
| digital health products? I see some mention of HAPI FHIR in the
| repo as well.
| robertlagrant wrote:
| Yes it was - it was internal to our company, but the apps got
| sold off when the business downsized. The engineering team
| lobbied to have the main backend open sourced, partly because
| it made the divestment of the apps built on it easier.
|
| The architecture was that that was a backend for apps, and
| the individual apps would host a stateless BFF service to
| translate the backend into what they needed, and then the
| web/mobile apps would talk to that. HAPI FHIR was integrated
| for testing reasons; it also spoke HL7v2, for our sins.
| pk-r wrote:
| Apart from your new product, the old metriport app I found very
| intresting. If you ever considered to make it opensourced, I
| would be glad to contribute.
| justanotheratom wrote:
| Can I make an App that can show a person their own medical data?
| i.e, user-provisioned access.
| adolph wrote:
| Yes. In the US, this is part of the EHR push, each EHR is
| supposed to accept any outside application. Here are some docs
| on how it works with Epic:
| https://open.epic.com/Home/InteroperabilityGuide?whoAmI=deve...
|
| A big tricky part is understanding all the different health
| systems that have part of the patient's record. Typically
| speaking you can scrape all health system FHIR access point's
| and perform some geo matching to offer the ones they likely
| have seen. From there you do the Oauth2 dance with each health
| system where the patient authenticates (if they remember their
| login) and your app gets a token good for a certain time period
| after which the patient has to log in again.
|
| The advantage of Metriport's approach is that they are getting
| a hook into the vendor operated HIEs. The patient doesn't have
| to remember/select which health care systems that have records
| for them since the VOHIEs have all that. The big hurdle is
| managing some authentication on behalf of the patient to a
| third party that they don't have a direct relationship to, the
| VOHIE. I suppose the VOHIE can pass the patient off to one of
| the member health systems and do the same Oauth dance but
| instead of just getting one health systems data, you get the
| whole enchilada.
|
| The evil part of the operation is that now Metriport has proxy
| access to the data and eventually will get hacked and bought by
| private equity that will sell the data to TransEquirian
| Insurance Score agencies.
| checkoutmygenes wrote:
| Nice work on the pivot + launch, team! You mention that IAS "may
| open up in the future." Does that mean I am not currently allowed
| to request my own record from an HIE?
| dgoncharov wrote:
| Thank you!
|
| That's right, we can't even request our own records using
| Metriport - this currently can only be done for a Treatment
| purpose of use (and opens up a lot gray area of what that
| means, as you can imagine).
|
| The promise of TEFCA, and QHINs, is to open up more use cases
| for data access, like individual access, payment/operations,
| and etc. We're optimistic that eventually this will become a
| thing, but there are a lot of politics around this, and full
| implementation of these use cases has been getting delayed for
| some time now. It's technically possible today, but responding
| to requests outside of Treatment is not a MUST, so essentially
| nobody (namely the big EHRs) will actually respond to IAS
| requests.
|
| In the meantime though, we're sprinting to hook as many
| providers up to the networks as possible, which then can share
| records with their patients.
| erkok wrote:
| I commend you trying to tackle such a challenging domain,
| something that feels should be handled on state level.
|
| As a citizen of Estonia, we pretty much have any government
| service available over the web, and yes, we also get to enjoy
| state provided health care, which makes things simpler when it
| comes to having a single unified system for all health care
| workers, which we have, have had for quite a while, probably for
| a decade or more. And it works, including patients who can also
| log into the system to check any data that is collected on their
| behalf.
___________________________________________________________________
(page generated 2024-05-23 23:00 UTC)