HL7 2.X Interoperability and Conformance Profiles

November 8th, 2006 by Dave Shaver

2 Votes | Average: 4 out of 5 (2 votes, average: 4 out of 5)

Loading ...

Posted in HL7 Standards, HL7 Standard, HL7 Integration

Ken Rubin is a frequent contributor to the HL7 standards body and works for the Veterans Health Administration (VHA or VA). Among other things, he works to improve and architect current and future generations of VistA and related applications.

VistA is the Hospital Information System (HIS) that is used by hundreds of VA hospitals. In addition, various third party versions of VistA have been built as open source or proprietary electronic medical records (EMRs) on top of the “free” VistA code base. There is a great VistA history article here.

In any event, Ken made a blog posting this week regarding EMR interoperability. In part he says (in conclusion):

Many criticize HL7 v2 messaging because of the lack of interoperability that resulted from ambiguity in “Z” segments. On the contrary, HL7 V2 was and remains wildly successful at allowing organizations to interchange information and interoperate. The problem is not in the wire protocol, it is in the conformance assertions.

We have an opportunity now to benefit from the lessons learned from the past, taking the utility and flexibility offered by “Z” segments and tempering them with strong enough conformance so as to give confidence to consumers that things will interoperate within an interoperability profile. The challenge is on us to ensure that the interoperable portion is sufficient.

I agree with Ken’s words above. When I describe the HL7 integration standard during HL7 training classes or while demonstrating our interface engine, I often describe the HL7 2.X messaging standard like so:

Generic doctors treating
Generic patients using
Generic clinical methods via
Generic procedures aiming for
Generic outcomes to
Generic diseases and all paid for with
Generic insurance (or not)

The point is that the HL7 standard is in many cases the most generic form of a clinical workflow and data model. In order for it to be usable in a real world environment, the applications involved make choices and the facility where those applications are installed further refine (and sometimes override) those choices.

I describe that HL7’s entire point is to provide a framework for discussing these differences. A conformance profile - IHE, ELINCS, a vendor specification, etc. - is where the choices are written down. If multiple sites or many vendors can share one profile, we have “out of the box interoperability.” The HL7 2.X standard itself does not provide such connectivity for “free.”