18

I'm testing a product for health care businesses, and we're working with HL7 messages. I saw people groaning on another question about the issues with HL7 but not mentioning specifics. Can someone give me some ideas of what issues or classes of problems we should specifically be looking for?

We are using some well-used libraries for the parsing. If specifics about these or what we're doing would be helpful please let me know in the comments and I'll add to the question if I can.

G__
  • 1,850
  • 15
  • 22
Ethel Evans
  • 5,309

3 Answers3

18

I assume you're dealing with HL7 v2.x

HL7 is voluntarily extremely flexible. That has great advantages but also introduces challenges. A basic rule to keep in mind is that every single implementation will be different. If you deploy the very same product in 2 different environments (2 hospitals for instance), data exchange rule will probably be different. Your product must be ready to meet those hidden requirements if you want to be able to scale the number of HL7 interface it will interact with.

In most healthcare system dealing with HL7, we are facing this partial list of common challenges:

  • Each system could interpret the meaning of each data piece. Also the context and workflows can influence the semantic. I saw some systems using the account number (PID.18) or visit number (PV1.19) to identify the patient to be compliant to some clinical workflows. That type of semantic gap will probably have some impacts on how the system receive this data deals with it.
  • Required vs. Optional: Because a piece of data can be exchanged to achieve several goals in several different contexts, most segments and fields are documented as optional in the official documentation (and some parsers). However, to satisfy specific workflows, healthcare products would probably add data constraints rules and relax some others. Most of the time, a case by case analysis need to occur to identify them.
  • Tables: HL7 provides some list of suggested values for some fields. For instance, the suggested value list for gender is 6 long... Obviously, most systems don’t implement all 6 but what is your mapping strategy if you receive one you don’t support upfront?
  • Segments and fields can be customized: Field length, data types and other definition attributes can be customized. You need to map it to some data structure you know without loosing important information.

jlmorin

www.caristix.com

jlmorin
  • 296
10

A few issues that I've run across:

  • Some organizations may use different versions of HL7, so you'll have compatibility issues ("cross-walking"). Certainly you'll run into this if you get involved in any inter-organizational data transfers.
  • There is no semantic standard (for v2.x, I think v3 may have started to address this), so even if you know what data should be in a particular field, you may not know the exact meaning or representation of those bytes.
  • HL7 is a non-standard standard. It supports vendor-specific Z-segments which are widely used and totally proprietary.
  • HL7 v2.x (many values of x still in use in the wild) is a non-XML proprietary format, so you'll need an HL7 parser to work with it. (This, you know as you already have an HL7 parsing library just including it for others)
G__
  • 1,850
  • 15
  • 22
2

The first issue is making sure everyone knows what HL7 is.

It is a way to replace [medical|billing|insurance] coders and save a [pharmacy|bank|insurance company] money.

That's the wrinkle on top of all the normal issues in software development.

  1. Scope Creep
  2. Incomplete specifications
  3. Invalid proprietary specifications that "Can't be changed"

So, you contact your [Pharmacy|Bank|Insurance Company] who wants to squeak out all the money they can from an HL7 interface to the facility who uses your software. Your contract is with the facility, their contract is with the pharmacy, the [Pharmacy|Bank|Insurance Company] has no clue how your software works, the facility has no clue what HL7 is and you're ticked off at the pharmacy because they constantly tell you that your software is buggy.

I believe the problem with HL7 is that it is mostly done on the cheap. HL7 3.0 may never materialize because it will never monetize.

If you're going to "pay for HL7" remember that you're paying for HL[1-6] as well. A SOAP interface is not HL7. An HL7 message parser is not HL7, neither is a message generator.

Peter Turner
  • 6,955