11–20 of 103 posts
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.
Congrats on the launch. I work in healthtech and I'm always shocked by how fragmented and siloed the technology is in my industry. Both at the application level (EHR) and data level, leading to general inefficiency, high costs and innovation that do not always benefit the patients. Glad Metriport is addressing this! I hope you will drive a new level of standardization on an open and modern data exchange protocol. One…
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 th…
Great. What I was trying to say is that there may be some value for larger customers if your company were building and managing something like it (basically a Fivetran for FHIR).
Congrats on the launch. I work in healthtech and I'm always shocked by how fragmented and siloed the technology is in my industry. Both at the application level (EHR) and data level, leading to general inefficiency, high costs and innovation that do not always benefit the patients. Glad Metriport is addressing this! I hope you will drive a new level of standardization on an open and modern data exchange protocol. One…
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.
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? 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…
> 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).
When you say that you can use the HIE's to contribute new data to the providers in the network, is that data actually going into the EHR's as if it was a record added in the EHR directly? If not, where are these contributed documents being stored?
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.
This sounds like a really excellent product, and I really love the description in this post of how you got there. Not working on anything just this minute that needs it, but I will definitely keep an eye out for opportunities.
A health platform I helped build was open sourced[0] (the apps built on it are closed source and deployed in NHS trusts). Feel free to dig around for any inspiration :-)