[lostlogin]

HL7 is such a monstrosity. Once you have used it you are forever sadder and that this became the default spec for everything in health is really disappointing.

Edit: for the uninitiated. Excuse the readable line breaks, this isn’t defined in the spec (or at least is done differently by all vendors). You won’t have to suffer long though as you’ll go blind reading the ||| and ^^ when debugging.

  MSH|^~\&|EPIC|EPICADT|SMS|SMSADT|199912271408|CHARRIS|ADT^A04|1817457|D|2.5|
  PID||0493575^^^2^ID 1|454721||DOE^JOHN^^^^|DOE^JOHN^^^^|19480203|M||B|254 MYSTREET AVE^^MYTOWN^OH^44123^USA||[phone]|||M|NON|400003403~1129086|
  NK1||ROE^MARIE^^^^|SPO||[phone]||EC|||||||||||||||||||||||||||
  PV1||O|168 ~219~C~PMA^^^^^^^^^||||277^ALLEN MYLASTNAME^BONNIE^^^^|||||||||| ||2688684|||||||||||||||||||||||||199912271408||||||002376853

[lliw]

To be clear, HL7 is a not-for-profit organization which has created several sets of standards over its history (HL7-V1, V2, V3, etc)--those standards are what you are referring to above.

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/)

[cmiles74]

While I agree that HL7 is a "not-for-profit", it's important to remember that their membership is not composed of not-for-profit organizations and you must purchase that membership. While this may not be an out-of-the-ordinary way to organize a standards body, it hopefully highlights why the standard is so fractured and interoperability is such a problem: this is the preference of that membership.

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-...

[1]: http://bluebuttonconnector.healthit.gov/

[nradov]

FHIR is relatively new and still in draft form. It would be a bit unreasonable to expect vendors to put a huge amount of effort into supporting a standard that's still in rapid flux.

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.

[libc]

It is using JSON (or XML), but the underlying data model is largely carried over from V3 (or more specifically, the RIM). The problem with HL7 isn't the data format itself, but how information is encoded and the amount of variation that exists. The parent comment was a little misleading in posting a V2 message since that isn't what Apple is using, but as someone who works with HL7 on a regular basis V2 is actually more straightforward to work with a lot of the time.

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.

[tantalor]

Very confusing. You say it uses JSON/XML (for data encoding) and also the "problem" is "how information is encoded". What is the encoding problem? And how could JSON/XML be the problem? These are fairly simple encoding formats and well understood.

Are you referring to the data model as the problem? How exactly?

[troyastorino]

The data model is a big part of the problem. There are lots of different ways to encode the same information within HL7. People refer to different "flavors" of HL7, different ones for different implementations (and implementations are not just vendor specific, but site specific — EHR software is very heavily customized for each health system). Add to that doctors and nurses entering information in their own ways within a given health system (since the software isn't very clear or usable), and the data that's getting transferred is a huge mess.

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.

[commandar]

Not the poster you were replying to, but I do healthcare data integration for my day job.

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.

[lostlogin]

Poster of the V2 message here. You describing the integration problem and that is the exact problem faced. As far as I understand it, isn't integration exactly what the format is for? It doesn’t do it well.

[commandar]

The standard will generally get you 80-90% of the way there.

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.

[nradov]

That's inherent in the problem domain. The FHIR data model is distinct from the V3 RIM but clearly influenced by it. Health care has a high degree of irreducible complexity. If we oversimplify the model then it won't support important use cases and implementers will be forced to use proprietary extensions.

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.

[entee]

I work with FHIR extensively and find the standard to be decent but not great. Perhaps my biggest complaint is around naming strategies.

"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.

[nradov]

If you see a naming discrepancy then just go ahead and submit a tracker to fix it. None of the resources are normative yet and in my experience the work groups are quite willing to fix this kind of stuff as long as you provide sufficient justification. You might need to explain why the change is needed and ensure it doesn't get delayed. Don't sit back and expect someone else to identify and fix the problems; most implementers only work with a few specific resources so they might not even notice inconsistencies.

https://gforge.hl7.org/gf/project/fhir/tracker/?action=Track...

[specialist]

Sure. But HL7 is most emphatically also not-for-patient, -for-doctor, -for-providers, etc.

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

[lostlogin]

I’m not sure I agree with that. HL7 gets messages onto one system (eg the MRI) from the hospital info system (RIS). There is nothing billable in terms of insurers and while departments bill each other it’s all one system (public healthcare, New Zealand). I know we are small fry, but other places use HL7 in ways that have billing as a secondary concern too. The system I currently use doesn’t bill with HL7 at all, it’s just to get identifying info onto the images and reports to referrers.

[specialist]

Sorry for being unclear. I'm talking about the consultancies (like my former employer) fleecing their customers (hospital, clinics, agencies).

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.

[swalsh]

I've sat in on some conference calls for a standards org in healthcare. The reason these specifications are so shitty to implement became clear as day for me. There was not a single technical person on the call. To be honest the majority barely sounded computer literate.

[prepend]

The good news is that the announcement calls out FHIR which gets rid of the pipe and carrot format for json or maybe xml if you must.

It’s not beautiful, but definitely easier to debug - https://www.hl7.org/fhir/patient-example.json.html

[specialist]

I designed, implemented, supported 5 RHIXs and was party to two NHIN interop competitions.

I strongly prefer HL7 2.x, that nasty EDI mutant spawn you show, over HL7 v3 XML XSD SOAP WSDL FHIR CDA what-what insanity every time.

The trick is abandon any thoughts of "schema", "semantics", "meaning" and just treat all these ETL-esque tasks as screen scrapping.

Meanwhile, XML is always the wrong answer. Full stop.

[thomasruns]

Wow. I haven't worked with HL7 since ~2004 and I was hoping it had changed, but apparently not. With HIPAA everything starting moving to X12 formats which had smaller file sizes and were much easier for developers to work with.

I'd be curious to know why Apple went with HL7. Was it a limitation of the EHRs they're integrating with? A demand of the hospitals?

[lostlogin]

Everything uses HL7, every last bit of equipment that has patient details on it, and people are familiar with working with it. This will be why they do it I think. I don’t think it can change now as it’s so deeply entrenched.

[commandar]

We're certainly starting to see a gradual transition over to XML/JSON via FHIR, and I've even worked with a couple of vendors that are pushing RESTful web services as their preferred integration method, but agreed: there's absolutely massive inertia behind legacy HL7.

Implementation costs for a primary EMR are in the millions and most ancillary systems still cost hundreds of thousands of dollars to put in place. There's a lot of financial incentive for healthcare organizations to keep using what "works", even if it is ugly as hell.

[criley2]

The SEG|1|Field^^^|| etc stuff isn't "HL7", it's a specific HL7 spec, V2.

HL7 FHIR here is JSON and XML based.

[CabSauce]

FHIR is a separate standard build on json/xml.

[midhunsezhi]

This! If there is one thing to fix health data communications, its coming up with better spec than HL7. Nothing makes me more sad than dealing with HL7 messages.

[nradov]

HL7 operates under a very open standards development process. If you have ideas for improvement then get involved and submit formal change proposals.

[cmiles74]

I have worked in the field and I strongly disagree with this statement. The implication is that one can submit suggestions to the HL7 organization and hope to see improvement or changes in the spec. I would contend this is only the case for the larger vendors who are already established in the field, and quite happy with the current state of the (pretty much entirely non-interoperable) specification.

[nradov]

Well you can't just toss in a suggestion and hope that someone acts on it. Ideas by themselves are worthless. But anyone willing to be persistent and do the hard work of nailing down details can absolutely get their changes incorporated into the standards. I've done it several times, including when I worked for a very small vendor.

The various work groups aren't really controlled by vendors at all. Provider and payer organizations are also heavily represented.

[corey_moncure]

Looks exactly the same as the EBF format used by the FCC. I wonder if it was designed by the same persons.

A sample:

  HD|||D8ED6E0E771AA22B|KA2036||TP||||||N|N|N|N|N|N|N|N||||Y|N|Y|N|N|N|N||||||||||||||||||||
  AD|||D8ED6E0E771AA22B|||N|N||||||Y|||N||N|||||N|||N|N||
  EN|||D8ED6E0E771AA22B||L||KTVI LICENSE, LLC|||||2028953088|||2250 BALL DRIVE|ST. LOUIS|MO|63146||||0017790890|C|||

[cridenour]

Reminds me of RETS in the real estate world. Sure it’s a standard, but nothing is actually the same so it just makes things more complicated.

[nradov]

I'm not sure what you mean by "readable line breaks". Segment terminators for HL7 V2.x messages are clearly defined in the standard and done the same way by all major vendors. The standard is also quite clear about how to represent visual line breaks inside formatted text reports.

HL7 V2.x messaging is a bit of a monstrosity since the most common ER7 encoding is based loosely on old EDI standards. There is also a standardized XML encoding for V2.x messages which is a little easier to parse, although it's poorly supported in the industry and the schema doesn't really follow XML best practices.

The HL7 standards body has developed many other standards including V3 and FHIR (which is effectively "V4", it just didn't get a new version number in the same series). Most vendors and provider organizations are now moving toward FHIR since it's based on modern open Internet standards and somewhat easier to implement.

[lostlogin]

Not the down voter but having recently battled different line break methods, I disagree about universal vendor support. My use case has been entirely limited to radiology - a very small subset.

[jtchang]

A good spec is really hard. I am thinking about writing parsers for HTML and SMTP which are super difficult.