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 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).
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.
Those other agent features could be useful, though.
No offense but the whole "biohacking" and "quantified self" community is mostly a clown show. It might be a fun hobby but there's little or no reliable evidence that any of that stuff actually leads to improved outcomes in terms of lifespan or healthspan or performance or whatever. Any business built around that community might get a few early adopters but won't cross the chasm to the mainstream market.
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.
> 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 records in your pocket, or to insurance companies, for example.
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.
>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.
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.
