Live data from Hacker News

Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

news.ycombinator.com

81–90 of 103 posts

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#81
post #53

Earlier 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…

Sounds good. Most traditional provider orgs don't care about open source and lack the IT resources to look under the hood. But some newer digital health companies do care and will see that as an advantage.

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

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#82

why not integrate with the EHR vs the HIEs

It's certainly possible to integrate directly with EHRs. Most now have pretty good implementations of the interoperability standards, at least for reading data. The problem is that to get access to that data you typically have to establish agreements with individual provider organizations, which is difficult to scale. Many provider organizations also run their own EHR instances rather than using SaaS so for those you also have to deal with all of the endpoint discovery and directory issues.

Working through aggregators such as HIEs eliminates some of those issues.

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#83

Earlier quoted context omitted.

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 al…

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

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#84
post #65

Earlier 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…

I'm not sure what you mean by "mystery commits". Health plans are legally required to accept transactions that conform to CMS adopted standards. They don't know or care what software is used to generate those transactions.

https://www.cms.gov/priorities/key-initiatives/burden-reduct...

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#85
post #61

Earlier quoted context omitted.

Agent-based healthcare concierge basically (agents constantly trawling literature for ways to optimize your health, doing scheduling/appointments for you, moving data to new doctors when needed, etc.) Thinking is: this was a massive tar pit in the past, new interop laws and AI tooling makes it possible now.

Health optimization based on literature searches is a fool's errand. A certain niche segment of the "worried well" is constantly reading studies (often of questionable quality) and chasing marginal gains with the latest drugs, supplements, recovery modalities, or whatever. Meanwhile they still have poor sleep hygiene, insufficient exercise, and unresolved emotional problems. Major in the major, minor in the minor. Th…

Interesting yes, we've seen demand for the optimization stuff but admittedly I am in a bubble here (close with the biohacking community).

It may turn out to be the case that more banal cases (I have a cold, what's the fastest way for me to get symptomatic treatment?

I have X symptom, what's the fastest way to be routed to the right specialist, etc.

The doctor told me XYZ, how do I remember that and what's the best way to do all the steps required to fulfill? )

is the better play. Still doing a lot of exploration here for sure. Appreciate the insight.

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#86

Can I make an App that can show a person their own medical data? i.e, user-provisioned access.

You can build directly with patient facing API’s (USCDI) directly with a patient’s EMR if you’re working with patient data/ building a patient app.

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#87

Earlier quoted context omitted.

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

Agent-based healthcare concierge basically (agents constantly trawling literature for ways to optimize your health, doing scheduling/appointments for you, moving data to new doctors when needed, etc.) Thinking is: this was a massive tar pit in the past, new interop laws and AI tooling makes it possible now.

Guessing you’re building off of US Core patient facing API’s for this use case? That’s what I ended up doing for www.meremedical.co

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#88

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?

As the Metriport team mentions HIEs/TEFCA don't realistically allow patients to request their own medical records at the moment. However it is possible to request your individual medical records using the Cures Act Final Rule mandates -- it's what powers Fasten Health's Open Source PHR[0] and our B2B Fasten Connect service. The trade off is that patients need to remember & search for each of their health systems & then login to each of their individual patient portals. It's a pretty high friction experience.

- [0] https://www.fastenhealth.com/ - [1] https://www.fastenhealth.com/connect/

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#89

Can I make an App that can show a person their own medical data? i.e, user-provisioned access.

As the Metriport team mentions HIEs/TEFCA don't realistically allow patients to request their own medical records at the moment. But there are definitely examples of PHRs that leverages the Cures Act Final Rule mandates around individual patient access.

Fasten Health's PHR[0] and MereMedical[1] are both great examples of this. The trade off is that patients need to remember & search for each of their health systems & then login to each of their individual patient portals. It can be a pretty high friction experience.

- [0] https://www.fastenhealth.com/ - [1] https://meremedical.co/

Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange

#90

why not integrate with the EHR vs the HIEs

That's exactly what we're doing with our Fasten Health PHR[0] & with our Fasten Connect[1] product. The biggest issue is that there are 250,000 registered health systems in the US. That's a massive long-tail to support and integrate with (we only support 30,000 at the moment). It requires a ton of time and effort, and at the end the Patient experience is still... mediocre. Patients need to search for each health system, then login to their individual patient portals -- it's pretty high friction. And thats even before you discuss all the barriers that EHRs put up to make it difficult for app developers to register and get production access to EHR systems.

- [0] https://www.fastenhealth.com/ - [1] https://www.fastenhealth.com/connect/

Post reply on HN