dgoncharov

> one that is very secure

Another reason we're open source - better security.

> Most health providers still require faxes, which is a huge pain in the butt.

Yes indeed - mindblowing how such critical data still relies on faxes in 2024.

> I have also heard many complaints about Epic Systems.

Yeah, Epic is not perfect, but they are ubiquitous in healthcare - and Metriport provides a nice interface to pull/push data to their EHRs!

> Most traditional provider orgs don't care about open source

Depends who you're talking to - from our experience CTOs of large provider orgs love the open source aspect (generally anyone with a tech team). Smaller orgs with no tech team don't care as much, you're right, but we also support them through a no-code provider dashboard.

Feel free to get in touch with us - we've migrated others of HG, and they can vouch that they get better data density, coverage, quality, and speed with Metriport.

> distinguish yourself by providing by excellent consulting services

We actually work very closely with companies month to month during a pilot period to implement an MVP integration to show them the value of the product for both data pulls, and contribution - consultant-style.

We'd love to chat if you're up for it: https://calendly.com/colinelsinga/metriport-intro

> CAIR2 is specific to California. Every state registry has some technical differences in HL7 V2

Didn't know CAIR2 was only used in CA - I guess a correct statement would be every state has an offshoot of HL7v2, with CAIR2 being one of them, as you mentioned.

> In practice the C-CDAs obtained from providers sometimes include immunization section entries

Yes for sure - we get a lot of those from C-CDAs already, these registries would be just another way to make the data even more authoritative/accurate.

See the bottom of the post: "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."

Roughly 93% of the US population, so just north of 300 million.

> Is this intended for use by providers or consumers/patients?

This currently can only be used by providers, or healthcare IT vendors working with providers. Referring to the post: "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."

> Authorized providers can use TEFCA through a QHIN to query for treatment purpose of use, which is supported by all participants.

Yes you can query for Treatment, but you won't get meaningful coverage. QHINs do not have nearly enough adoption to be used for Treatment. Essentially the pool of providers using QHINs is insignificant, so you need to go through existing HIEs to get meaningful coverage.

The driving force behind QHINs is to open up new use-cases for accessing patient data, not necessarily to make the Treatment purpose of use better.

> How does your service differ in practice from existing networks of networks

We're the only vendor that's open source, where you can see and trust what's going on under the hood. Ask other vendors how they do record location, patient matching, or data mapping, and they'll just tell you "trust us, we're the best!".

Additionally, we're the only vendor that is confident enough in our solution to work with companies month-to-month, to show them that our product actually brings them value (and works as advertised) in production. Other vendors will lock you into $120k+ yearly contracts before even showing you production patient data. True story: a provider came to us recently after one of the vendors you mentioned locked them into a yearly contract, and only after the lengthly implementation period did they realize the product didn't work well at all - so a bunch of time/money wasted, and they need to migrate now anyways.

We have many advantages feature-wise as well, feel free to compare our dev docs!

What're you working on in specific? Can help provide clarification if you're able to describe the use case.

Thank you!!

Thank you!

We'd love to open source it - but are too strapped for time to do so. Perhaps one day in the future.

\m/

Thank you - it's a difficult problem for sure, but that makes it all the more fun and rewarding.

> should be handled on state level

Many of the aforementioned HIEs in the US are actually offshoots of state, or federal, government initiatives like TEFCA. We didn't go into details in the post, but the main HIEs are definitely not privately held startups - mostly nonprofit state sponsored organizations.

> we pretty much have any government service available over the web, and yes, we also get to enjoy state provided health care

There are pros/cons of state run centralized government systems for sure - with Metriport as a communication layer, we're hoping to bring providers in the US the best of both worlds for data exchange.

> 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.

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.

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.

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.

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.

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!

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.

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).

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

> 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.

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.