What percentage, or how many millions, of patients are accessible on the network today?
Roughly 93% of the US population, so just north of 300 million.
what is blocking the remaining 7%?
Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
71–80 of 103 posts
Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#72Best 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/ Mic…
Based on your experience , what do you think is the biggest pain point?
Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#73Earlier quoted context omitted.
In principle XSLT can be used to convert between HL7 V2 Messaging, CDA, and FHIR formats. I have actually done this to an extent. But it's a huge mess and difficult to maintain or even understand. Most implementers have now moved on to other technologies for healthcare data mapping and transformation. And format conversions are only one minor piece of the interoperability puzzle. The standards bodies in the clinical…
Interesting, up north the ISO 13485 certification etc. is required to even deploy an App, as your phone would be considered a medical device under the rules if used for diagnostics and or reporting. Don't get me wrong, I am sure people have no issue paying the $84k each release cycle to be cleared as compliant. Notably, our health authority legally can't buy software without these certifications, and for the past 6 y…
Can you elaborate, aren’t there cheaper cloud based hosting solutions e.g. aws?
Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#74Earlier quoted context omitted.
Interesting, up north the ISO 13485 certification etc. is required to even deploy an App, as your phone would be considered a medical device under the rules if used for diagnostics and or reporting. Don't get me wrong, I am sure people have no issue paying the $84k each release cycle to be cleared as compliant. Notably, our health authority legally can't buy software without these certifications, and for the past 6 y…
Can you elaborate, aren’t there cheaper cloud based hosting solutions e.g. aws?
AWS is usually not compliant, and thus likely prohibited as well. Microsoft partnered with a large local telecom company to provide the NOC.
It is 100% a monopoly, and thus why we left a competing firm a long time ago. =)
Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#75Thank 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.
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 th…
I suspect that having a hosted solution -one that is very secure, could be quite lucrative.
This, on its own, is probably not something that folks could just throw onto any server, and expect reputable heath providers to use (at least, I hope not). Auditing and validation ain't cheap.
I applaud the idea, and hope that it works out. Most health providers still require faxes, which is a huge pain in the butt.
I have also heard many complaints about Epic Systems.
Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#76Earlier quoted context omitted.
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 matchin…
> 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…
>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.
Just a minor detail here. My understanding from my attendance at some of the ONC Information Blocking seminars is that if the EHR is ONC certified, they are required to provide access to a patient using any app of the patient's choice. The rules are very different if its a provider app or an app that can provide access to data for multiple patients. Unfortunately, not all EHRs are certified (looking at you mental/behavioral health sector, and cash-only EHRs).
We continue to struggle with this in our own EMR implementation as app providers constantly complain that provider/system level access to the data requires manual human intervention, which we aren't going to change anytime soon. Things like Unified Data Access Profiles (UDAP) Dynamic Client Registration are looking to mitigate some of these problems.
What I'm intrigued about with Metriport is that app providers could connect directly to them to get the patient data as long as our EMR feeds data into the HIEs they work with.
Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#77how do you make money?
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."
Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#78Earlier quoted context omitted.
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…
CAIR2 is specific to California. Every state registry has some technical differences in HL7 V2 Messaging support but most are reasonably close to the CDC/AIRA spec. https://repository.immregistries.org/resource/hl7-version-2-... The CDC IZ Gateway can make it somewhat easier to work with multiple state registries. https://www.cdc.gov/vaccines/programs/iis/iz-gateway/overvie... In practice the C-CDAs obtained from pro…
> 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.
Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#79Best 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/ Mic…
Based on your experience , what do you think is the biggest pain point?
The biggest pain point isn't technical, it's misalignment of incentives in provider organizations. Interoperability standards have existed for years and are widely implemented in commercial and open-source products and online services. Some of these may be a bit expensive or difficult to use but they work well enough, at least for common use cases.
The problem is that most providers still work on a fee-for-service basis, billing payers (insurers) and patients for individual line items. There's no line item billing code for improving clinical data quality or sharing patient records with other authorized organizations. So they mostly do the bare minimum necessary to comply with government regulations and payer coverage rules.
For example, every doctor is supposed to have a Direct Secure Messaging address listed in NPPES by now so that they can securely email patient records to each other. Every major EHR supports this standard and it can also be used through HISP online portals. But a lot of doctors still have no clue how to do this and haven't registered their address in NPPES (or misunderstood the instructions and put in their own personal Hotmail email address or something). So, they still end up sending faxes.
The situation may eventually improve with the shift to value-based care but this will be a slow process.
Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#80Earlier quoted context omitted.
> 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 ca…
We are paying 60k for Health Gorilla and I am not sure it’s worth it. I think you can distinguish yourself by providing by excellent consulting services helping your customers to implement solutions. Without help the learning curve with health data is not enormous and everything is very complex and opaque.
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