analogj
Joined 14 years ago
Karma
659
Submissions
97
Member since
Oct 3
Recent submissions
Comment · 2 years ago
I just posted a tongue-in-cheek blog post about HIPAA/Cures Act Information Blocking techniques found in the wild.
These are real barriers faced by patient-access API developers like Fasten Health, effectively blocking patients' access to their own medical records
Comment · 2 years ago
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/
Comment · 2 years ago
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/
Comment · 2 years ago
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/
Comment · 2 years ago
Hey HN,
I've been thinking alot about the properties of viral open-source licenses and how this could be applied to other legal documents - like privacy policies.
As it becomes possible to share our medical records with caregivers and practitioners using apps, we have to trust that these apps are managing our data and respecting our privacy as we intend. But it's not only the app developers we need to care about, its also the third party services that they use (and share our data with), and the third party services that they then use.. its turtles all the way down.
What if we could create standardized "viral" privacy policy clauses, similar to the viral nature of open-source notice & attribution clauses.. which would "follow" Personally Identifiable Information (PII) and Protected Health Information (PHI).. ensuring it's used as we intend, no matter the degrees of separation?
Comment · 2 years ago
So this is partially the reason why I built my own open-source Personal Health Record (PHR) Fasten Health [1][2]
In my experience patient portals vary from incredibly functional to almost worthless, which was a huge problem for me given that some of my important specialists were in the latter bucket.
Honestly, everything that I've read comes to the conclusion that EHR's aren't designed for patients, nor practitioners, they're built for the accounting dept. Patient portals have been tacked on-top to comply with govt regulation & certification programs [3], but UX/usability is almost universally lacking.
Thankfully the FHIR API's that Fasten leverages seem to be fairly consistent:
- the interoperability standard (FHIR) ensures that patient medical records are (somewhat) consistent.
- EHRs APIs are tested against an automated test suite before they are "approved" - its not comprehensive, but its better than the subjective UX rules.
[1] - Marketing - https://www.fastenhealth.com/
[2] - Source Code - https://github.com/fastenhealth/fasten-onprem
Comment · 2 years ago
There's actually a "Patient-contributed data" initiative being run by the standards body (HL7) that's gaining traction.
In an ideal world it would allow patients to "push" their electronic records to a new practitioner, meaning that intake forms could be much simpler. In practice I think the implementation is going to start with Observations/Lab Results first though.
I hope to eventually support it with my open source personal health record (PHR) Fasten Health. IMO this would be a "killer app" for PHRs.
Comment · 2 years ago
Disclaimer: I built an Open-Source PHR
The thing that most people don't realize is that the legally enforced HIPAA protections they take for granted no longer apply when they request their medical data from a healthcare institution and store it in a third party app -- like Apple Health.
The only thing protecting your medical records from being data-mined and monetized is Apple Health's privacy policy and (current) technical architecture. You've seen examples of it in the news with women's period tracking apps, but it'll become even more common as apps start leveraging APIs opened by the 21st Century Cure's Act.
I'm not a tin-foil hat wearing engineer, but I can forsee a day when Apple's reputation of being "Privacy-conscious" might not be worth as much money as the medical data they've collected from their customers.
It's one of the reasons why I decided to build my own open-source PHR, so that the incentives between the software and me as an individual are kept in alignment.
Comment · 2 years ago
This is not quite the case any longer
The 21st Century Cures Act was signed 8 years ago (but compliance was only required as of 2023). It states that Healthcare Institutions (& EHR developers) must provide a mechanism for patients to access their health records electronically in a standardized format (FHIR).
It's what allowed my open-source startup Fasten Health to even exist. I was diagnosed with a chronic condition, and wanted a way to store my health records privately on my own devices. A bit of luck and a POC later, I was able to confirm that patients can access their own records with little-to-no barriers.
It doesn't matter that I've had 6 different insurance companies over my career, or that I've visited more than 2 dozen different healthcare institutions, as a Patient we have the unique ability to collate and generate our own longitudinal health record.
Comment · 2 years ago
Interestingly your [1] citation may no longer be the case. The 21st Century Cures Act was signed 8 years ago (but compliance was only required as of 2023). It states that Healthcare Institutions (& EHR developers) must provide a mechanism for patients to access their health records electronically in a standardized format (FHIR).
It's what allowed my open-source startup Fasten Health to even exist. I was diagnosed with a chronic condition, and wanted a way to store my health records privately on my own devices. A bit of luck and a POC later, I was able to confirm that patients can access their own records with little-to-no barriers.
Comment · 3 years ago
I'm actually working on an open-source Personal Health Record (PHR) app called Fasten Health - https://github.com/fastenhealth/fasten-onprem
It allows patients to pull their complete medical history from their various healthcare institutions, and store it locally without having to worry about some corporation monetizing and data-mining their health record
Comment · 3 years ago
I've been working on my own Open-Source Personal Health Record (PHR) that leverages FHIR & Smart-on-FHIR https://github.com/fastenhealth/fasten-onprem
Hopefully with the Cures Act Final Rule, interoperability will become the norm
jason @ thesparktree.com