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