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,329
  • 1
  • 23
  • 42

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
  • 1
  • 4
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
  • 3
    The worst of those is the lack of semantics. When even the people writing the standard say "well you could send X, or Y, but Z is also valid" you know you've got a problem. What saves it is that no-one except the parser people has to deal with the whole range of HL7 options - everyone deals with the small subset that is actually received by their customers. It means that writing a new accepter is a process of discovery (that I'm going through right now) rather than a "implement the standard" exercise. Oh, and guessing at which option you need to send in order to have the desired effect. –  Feb 14 '11 at 22:21
  • @ +1 for the answer, and with I could give +1 for including info for people other than the OP (me). @moz - good point about just needing a small subset. That is precisely our situation. You are also confirming my suspicion that comparing against customer data will be key. – Ethel Evans Feb 14 '11 at 22:28
  • 1
    @ethel and @moz, that's exactly the kind of thinking that makes dealing with HL7 so difficult, please take the time to make your programs as flexible as possbile, HL7 is one place where YAGNI is in no way applicable. – Peter Turner Feb 15 '11 at 18:41
  • Okay, this makes sense. I don't think our application will cause any YAGNI issues, as we're planning ahead to expand the types of HL7 messages we can use to provide value. We know that we don't know what we'll need in the future. – Ethel Evans Feb 15 '11 at 19:29
  • 1
    That's why I'm a fan of using the open source libraries (HAPI/NHAPI) at least for the receiving side. Much better to have a high level "we got a valid HL7 message but haven't written code to process it" than "our parser failed because we didn't expect that message". Unfortunately everyone starts small "we just send X and receive Y" so it's much simpler to hack something together for just than then extend it every time a new requirement arrives until eventually it collapses under the weight of accumulated cruft. –  Feb 15 '11 at 22:56
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,897
  • 1
  • 33
  • 57
  • 1
    HL7 is far more than just for pharmacies. Most often HL7 is used to connect disparate systems such as an EMR to a billing system. – Bill Feb 15 '11 at 17:59
  • Our product is not targeted at pharmacies, even indirectly, and the response is very biased with little support for the answer. – Ethel Evans Feb 15 '11 at 18:12
  • 1
    @Ethel I'll add some regexes but you ought to be more specific in your question. We do more than pharmacies with our 100% home grown HL7 implementation, but the prime mover behind development is always "big pharma", if others can take advantage of a widely used specification, then so be it. – Peter Turner Feb 15 '11 at 18:30
  • @Peter: I'll try to be more specific with why I think this isn't helpful. First, your highlighted quote seems highly biased and unsupported. Second, the items on your numbered list are either vague or don't add beyond what other answers have said more clearly. Third, your example scenario is highly specific and looks nothing like the scenario I (and apparently others) are dealing with, making it uninformative. Fourth, your statement that HL7 is done on the cheap seems biased and unsupported. Fifth, I'm not doing "HL7", I'm working with HL7 messages, so the last paragraph's point is lost. – Ethel Evans Feb 15 '11 at 19:27
  • 2
    @Ethel, how on earth am I supposed to support my claims, I don't benefit at all by griping about HL7, what I do know from my last years experience working with several vendors is that when someone says they want to work with my software and to send them a "Test message" so they can get a handle of what it's supposed to look like, they'll craft some sort of a ORM around the message and it'll just work for that. This is not good. If my answer seems different than others it's certainly not because I'm not telling you the truth. HL7 is mainly about the money. – Peter Turner Feb 15 '11 at 19:34
  • @Peter, I think you are being honest, but not terribly useful. If your example in your post is personal experience, share it as such. That is useful, and support for your bias. An overly-specific fictional example is not. The example in your comment above is also very useful, and highlights clearly a specific pitfall - put it in. More anecdotes could make this post helpful, and specific actions or advice. Given that you think HL7 sucks, what would you advise people do instead or to mitigate damage? Your YAGNI comment elsewhere was great, and you should include it here. – Ethel Evans Feb 15 '11 at 19:48