Can I make an App that can show a person their own medical data? i.e, user-provisioned access.
I'm working on something in this space right now, would be really interesting to use Metriport for this. Though I believe that it's currently outside scope >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 thing…
Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
41–50 of 103 posts
Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#42Earlier quoted context omitted.
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.
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/mob…
I may be in a position to open some of that up before it's lost.
Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#43Earlier quoted context omitted.
I'm working on something in this space right now, would be really interesting to use Metriport for this. Though I believe that it's currently outside scope >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 thing…
What're you working on in specific? Can help provide clarification if you're able to describe the use case.
Thinking is: this was a massive tar pit in the past, new interop laws and AI tooling makes it possible now.
Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#44Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#45In 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…
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 h…
How does your service differ in practice from existing networks of networks like Health Gorilla and Particle Health?
Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#46Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#47Earlier quoted context omitted.
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.
Interesting case, inaccurate data aside, I imagine medical staff form diagnoses objectively.
Under HIPAA, patients do have the legal right to correct errors in their medical records.
https://www.hhs.gov/hipaa/for-individuals/medical-records/in...
Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#481. Some governments require ISO certifications for security
2. Some standards bodies require commercial accountability (FDA), data site redundancy, and company inspection by a standards body.
3. The ecosystem for the insurance documentation is never open source. It is not only prohibitively expensive, but comes with legal strings in the EULA.
Good luck, but please read the slicer.org story before committing too much time to the project. =)
Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#49Earlier quoted context omitted.
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 h…
Is this intended for use by providers or consumers/patients? Authorized providers can use TEFCA through a QHIN to query for treatment purpose of use, which is supported by all participants. How does your service differ in practice from existing networks of networks like Health Gorilla and Particle Health?
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!
Re: Launch HN: Metriport (YC S22) – Open-source API for healthcare data exchange
#50What percentage, or how many millions, of patients are accessible on the network today?