>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 things such as clinical trials recruitment, for example, can’t use Metriport, but a primary care provider, or a clinical decision support vendor, can. This is due to current requirements set forth by HIEs, which may open up to support alternative use cases in the future, such as Individual Access Services (IAS).
Would love clarification.
Thinking is: this was a massive tar pit in the past, new interop laws and AI tooling makes it possible now.
Those other agent features could be useful, though.
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.
And I write this as someone who has personally wasted money on stuff like genetic tests for athletic performance. Interesting, but not actionable.
For common symptoms, conditions, and medications consumers mostly just rely on WebMD or similar sites.
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 matching to offer the ones they likely have seen. From there you do the Oauth2 dance with each health system where the patient authenticates (if they remember their login) and your app gets a token good for a certain time period after which the patient has to log in again.
The advantage of Metriport's approach is that they are getting a hook into the vendor operated HIEs. The patient doesn't have to remember/select which health care systems that have records for them since the VOHIEs have all that. The big hurdle is managing some authentication on behalf of the patient to a third party that they don't have a direct relationship to, the VOHIE. I suppose the VOHIE can pass the patient off to one of the member health systems and do the same Oauth dance but instead of just getting one health systems data, you get the whole enchilada.
The evil part of the operation is that now Metriport has proxy access to the data and eventually will get hacked and bought by private equity that will sell the data to TransEquirian Insurance Score agencies.
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.
Fasten is a great OSS project that facilitates this flow for individuals, and I'd suggest you check them out: https://github.com/fastenhealth/fasten-onprem
> getting a hook into the vendor operated HIEs
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.
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.
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/