Take, for instance the "", I'd hope that anyone who has spent any time in dealing with HL7 messages knows that the "" signifies that something should be deleted. "" is not an empty string, it's not a filler etc... But occasionally, one may meet a vendor who persists in sending "" instead of just sending nothing at all.

Since, I work for a small business and have an extremely flexible HL7 interface, I can ignore ""'s in received messages. But these things are adding up.

  • Some vendors like to send custom formatted fields with psuedo-components that they leave others to interpret themselves.
  • Some vendors send all their information in note segments and assume you're going to only show users the information they send in a monospace font.
  • Some vendors even have the audacity to send Carriage Return Line Feeds at the end of each line of a file interface.
  • Some vendors absolutely refuse to send decimal numbers and in-so-doing refuse to send any numbers.

So, with all this crippling humanity against the simple plastic software man, how does one bend without breaking*? Or better yet, how does one fight back and still make money?

*my answer is usually to create an interface for the interface and keep the HL7 processing pure, but I don't think this is the best solution

closed as off topic by mattnz, Martijn Pieters, user40980, Dynamic, World Engineer Mar 2 '13 at 18:28

Questions on Software Engineering Stack Exchange are expected to relate to software engineering within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    "...it is likely that... you are inevitably faced with the task of interacting with the spaghetti that is already there. Enter the Anti-Corruption Layer." (Anatomy of an Anti-Corruption Layer, Part 1) – gnat Sep 21 '12 at 14:47
  • 2
    I swear, HL7 is the bane of my existence lately.... I typically do what you do for clients that refuse to follow standards: implement something custom for them that is separate from the regular HL7 stuff. But that doesn't answer your question on how to get them to use the proper format. – Rachel Sep 21 '12 at 15:42
  • 1
    The way I handled this was to create interfaces and base classes. Then I wrote vendor/customer specific processing modules that would be loaded dynamically from info in a settings DB table. – jfrankcarr Sep 21 '12 at 17:02
  • I guess the answer to this question depends on the leverage you have with them. If you need them more than they need you, it's going to be hard. Fight one or two battles, then fine. But, if you have to correct 30-40 vendors, then it may be easier to come up with a process that cleans their data before processing it. – L_7337 Dec 27 '13 at 18:53

The core of your question is "how to negotiate" and ultimately, the answer there is pretty simple. You provide an interface specification and request them to follow that. You can put penalties for non-conformance in your contract specification, but I suspect that's not a feasible option.

I think your real question is what to do with all of the one-off rules that are generated because the vendors aren't strictly following the interface specification.

Gnat's link to the anti-corruption layer is a good start to solving that challenge. More specifically, I think I would generate a list of rules / filters that can be applied to incoming transmissions. Each non-conforming vendor will then have a list of transformation rules that need to be applied. As new vendors come in, you can simply re-use existing rules and add to the never-ending list of variants as necessary.

The variant with the fixed font is a little more annoying as it will require some downstream work past message reception in order to make it work, but hopefully that's the minority exception case.

  • That's probably our problem, too often, and in fact all the time, we are the "Interface Spec Takers" not the "Interface Spec Makers", is that common for EHR Software? We'd like to say, just follow the spec, but pretty much the only thing we write in to contracts is "we refuse to parse free text", which is the most abhorrent detail. – Peter Turner Sep 21 '12 at 15:03
  • @PeterTurner - Until the business sees the cost of not requiring and enforcing a spec, it can't really evaluate whether or not to take action. On the one hand, the extra parsing / development could be written off as a cost of business. On the other hand, the company may say that profit on a deal is sufficiently degraded because of development overhead to pass on that deal. Unfortunately, those are all management / business decisions not programming decisions and I can't help you there. :-) – user53019 Sep 21 '12 at 15:19

The answer depends on who you are dealing with and what your goals are.

You can negotiate with other developers of small/custom emrs. Sometimes you can even dictate what you'll accept. But other times you'll be the one forced bend. How much depends on your goal.

We've taken the position that it's easy for us to customize the HL7 communication to fit the needs of the vendor because ultimately we want our clients to receive our data. A little upfront pain goes a long way.

Additionally some vendor will bend...but that process takes a long time. Days turns into weeks which turn into months. In order for us to complete an interface on time we need the momentum to continue....once we have to wait a couple of days for a vendor to change something, that momentum has been lost and our focus is diverted to other interfaces and projects. Stop/go/stop/go is a killer for, where as if the onus is all on us we can proceed much more quickly.

We manage the process like this. First we use Mirth which is extremely flexible. Second our architecture creates a "base" HL7 message. Each EMR (or client) channel is customized to the specifics of the vendor/client - but it's built off of the base channel which is standardized in the sense that if you follow the HL7 spec, there should be no transformation and the only thing that is custom is the delivery mechanism.

This leaves the heavy lifting to a channel that is tried and true, and that channel never changes.

Our custom channels typically have 0-3 transformations. Usually stuff like moving/copying Pid 3 instead of Pid 2 for patient ID or altering the client id in the MSH. Those types of changes are very manageable.

Not the answer you're looking for? Browse other questions tagged or ask your own question.