FHIR, which is what Apple is using, is its own standard, (created/managed through the HL7 organization) and is based on more modern representations of data (JSON, etc). (https://www.hl7.org/fhir/)
I've had to work with the spec, specifically to integrate different products, and it was an ongoing battle with the vendors and their consultants at every step. It's uncharitable to say that they would deliberately mis-interpret what little specification was in place solely to make integration expensive, but that was my feeling. In fact, I believe that one purpose of the specification is to keep competition out of the field.
Looking around, I'm having trouble finding an EHR that implements both importing and exporting data in the FHIR format. Instead I'm seeing products that take the FHIR data and then (presumably) emit HL7 messages aimed at an organizations interface engine (i.e. Cloverleaf or something similar).[0] If none of the big EHR support it, then it will remain an expensive "custom" add-on that will be challenging (and expensive) to support and it will end up another dead initiative like the "Blue Button".[1] With every upgrade to systems in the organization, the FHIR translator app will need to be updated as well. Will it support every vendor? Likely not, and now you may also have to foot some portion of the bill to add support for that vendor.
My fear is that people will see FHIR and Apple and assume that some progress is being made. This is a battle we've been fighting for years and even now, people walk from one office to another with a CD or DVD of data in the hopes that it can be read.
[0]: http://www.intersystems.com/au/our-products/healthshare/hl7-...
Most of the major EHR vendors do now support a significant subset of FHIR resources through read-only APIs. And several of them have publicly committed to start offering limited write APIs by the end of 2018. We have to be a little bit patient.
As for purchasing memberships, well HL7 needs some revenue to keep the lights on. A small company can purchase an annual membership for as little as $1450, and individuals can join for even less.
FHIR is definitely a step in the right direction but it is plagued with the same issues as their other "standards" so I'm not holding my breath.
Are you referring to the data model as the problem? How exactly?
The problem is that HL7 is ostensibly a standardized interchange format, but there's enough ambiguity in the spec that literally every vendor implements things differently which leads to... my job existing.
Vendors implement the spec selectively. They may or may not support any given message trigger. They may have a different idea of what exactly constitutes something as basic as a patient account number and choose to send it in an unexpected field. Or send a piece of data you weren't expecting at all there. There may be a business case for capturing data that wasn't in the spec for a version of HL7 being used -- email addresses are common one today -- that lead to user-defined fields being added ad-hoc.
Honestly, working with HL7 v2 messages like posted above isn't really any substantially harder than working with CSVs. The real headache comes from actually integrating the underlying data.
There are a lot of factors that go into why the standard fails to be plug-and-play. The fact that v2 is essentially a glorified, somewhat standardized CSV instead of a prettier JSON has next to nothing to do with it.
troyastorino's sibling comment nails a lot of it. There's no standard model for the underlying data, which makes it incredibly difficult, if not impossible, to have a standard transmission format for the data. Literally every individual facility you'll look at is unique and will have their own registration workflows, code sets, etc.
The old V2 spec isn't what I'd call good, but it works. It's ugly to look at, but it's not difficult to work with, either.
The problems you're addressing, however, are far more fundamental to the industry itself and aren't going to be solved by an interchange format.
Each medical event should have:
- Patient it relates to
- Date it happened (possibly date it started and date it ended instead)
- Who did/prescribed/ordered it
- List of medical codes+coding system tuples that happened on that event
There's tons of other information of course, but these very basic things are universal and should always be in the same place (I refer to FHIR in this case, but format is somewhat irrelevant if the API is good). I understand they're not for historic reasons, and that some might complain because it doesn't exactly fit how they think about things, but a consistent API provides more value and I think will lead to better process down the line.
HL7 is moving along with FHIR, and I think it's a good start, I look forward to where it ends up.
Well, I mean, that's pretty much the entire basis of the HL7 segment paradigm.
>- Patient it relates to
This is a much, much, much harder problem than you'd think.
Patients are going to have multiple identifiers attached to them and resolving them cleanly is literally an industry of its own within healthcare.
And that's precisely why it's a common problem during integrations - which identifier gets used how is generally a workflow and design decision made for a specific site-level implementation.
>- Date it happened (possibly date it started and date it ended instead)
>- Who did/prescribed/ordered it
These usually aren't sticking points for integration because they're the easy ones to get people to agree on.
>- List of medical codes+coding system tuples that happened on that event
These aren't really standardized at the industry level beyond ICD-10 diagnosis codes. Things like insurance provider codes, procedure codes, order codes, etc are individual to sites; even things like ethnicity and gender codes are variable by location.
I don't want it to sound like I'm down on FHIR or that I think HL7v2 is the greatest thing since sliced bread because I don't think either is the case.
The point I'm getting at is that there are huge problems with healthcare data interchange that just plain aren't going to be solved by a better interchange format.
Beyond that, a lot of the most important information is encoded in free text fields, and so isn't directly analyzable. And even when information is mapped to codes from standard medical ontologies, there's no guarantee that when that information is transferred in HL7 formats it includes the code from the ontology.
It's not at all clear what the optimal way to structure medical information should be, so it's no surprise that there's a huge amount of variance out in the world. HL7 is quite old (v2 was made in 1989), and every new variant has to support the existing variants. EHRs were originally designed around billing and administrative workflows, so it's also not surprising that the data structures aren't great for analyzing data or treating patients.
As a practical matter we can't rely on low-level standards to achieve real interoperability. Since there is often more than one way to model the same clinical information we also need high-level implementation guides with comprehensive examples to show everyone exactly what to do, along with automated conformance testing tools.
"What date did this event occur?", can be assertedDate or effectiveDateTime or performedDateTime or any number of things based on resources.
In the old versions it was even hard to know "What's the patient ID associated with this resource?", sometimes it was "patient" sometimes it was "subject". This has gotten better in STU3, and improvements have also been made to the way practitioners are identified as well.
I think there's a ton of irreducible complexity, but there are also common themes and common parts of medicine that should form the foundation of the API. It seems that instead of thinking, "What are the real commonalities here? Lets make them flexible enough to handle 90% of cases, but with a standard interface for extension." HL7 started from a current cumbersome standard and shoehorned it in.
I really am optimistic though, it's getting better all the time and FHIR is actually remarkably extensible to handle corner cases. I really hope it becomes the standard moving forward, especially as it smooths out the rough edges.
https://gforge.hl7.org/gf/project/fhir/tracker/?action=Track...
HL7 and ICD-9/10 have two purposes. First, more billable hours for consultants and make work for admins.
Second, expanding the confusopoly, enabling insurers to deny coverage, payment.
The Utopia of Rules: On Technology, Stupidity, and the Secret Joys of Bureaucracy http://a.co/5ux1yrK
I don't know your country's system. Single payer? That'd be nice.
In the Freedom Markets™ loving USA, most everyone exchanging medical data are antagonists. So all the incentives encourage hoarding and obfuscation.