Hacker News new | ask | show | jobs
by dpflan 2419 days ago
Regarding legacy EMRs, are specifications/standards like HL7's FHIR actually gaining any traction and making data interoperability more feasible?
3 comments

In my world they sure are. Want health records on your iPhone? Well that comes via FHIR. You can even see the FHIR resource JSON in the Health app.

But there are many systems in a hospital. And as EuphoricEmu pointed out within the hospital, admits, discharges and movements throughout the hospital are still done via HL7v2 (a delimited and structured format).

Additionally, I would absolutely NOT build a new system on HL7v2 at this point in time. I would only use it to integrate with existing systems.

Also, I do know of EHR systems that use FHIR for their internal data storage format.

Yup, there are a few EHR vendors that have some limited support. Intersystems’ whole platform is shifting towards have pure native support for FHIR. It’s still very rough and to into the weeds of things you sadly have to delve into that very old language (objectscript = MUMPS). But thankfully there bindings for more modern languages for it.
Unfortunately consumer-facing use cases are the ones big EMR vendors like Epic are focusing on with FHIR, push is often neglected or left out meaning we still have to rely on good old HL7v2 to get real time feeds out of the system.
Yes exactly! Since patient movement within a hospital is done primary with v2 and then hours or even days later a patient summary CCD might get sent across. Unless you’re dealing with encounter based CCDs. But those still aren’t live.
FHIR Subscriptions do exist.
Not OP but I can tell you that due to the object size limitations of FHIR objects, document exchange is just not feasible. Using FHIR to register a patient is pretty pointless currently as every older and larger hospital sends HL7v2.

RHIOs building gateways for 3rd party apps is very much the future of FHIR. But they’ll still be interacting with that crufty legacy system.

Just my own two cents.

Thanks! I was not aware of the object size limitations nor of RHIOs

Are RHIOs using engineers/consultants to wrapped legacy systems then devise methods to make accessing that data easier -- how are RHIOs using FHIR and legacy system to construct the future of medical data interoperability?

RHIOs exist predominantly to allow the exchange of patient information between participating hospitals or even regions. I personally only have insight into how two RHIOs operate. Both are very interested how they can turn FHIR into another avenue to distribute patient information.

The issue is that most EHR/EMR vendors have very limited limited interoperability with FHIR. As a lot of these vendors are struggling with CCD 2.1 implementations. The exciting space is allowing patients through 3rd party apps to request specific information or even send it to the HIE (RHIO in this case) and let there GPs know of certain events.

Which means a lot of work to bend over backwards to get APIs exposed for these 3rd parties.

I work as a company that builds software to optimize dosing, and we have apps in a few of the major EHR vendors app stores. FHIR has been great for getting and presenting data - although I think true interop between EHRs using FHIR would be challenging, due to the large amounts of data and the (relative) complexity of each EHR. Despite everyone using FHIR, it does suffer from the same problem other specs like HTML do, everyone has an ever so slightly different implementation, and once it's been implemented, no interest in changing or improving it.