6

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

Peter Turner
  • 6,955

2 Answers2

5

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.

0

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.

ChronoFish
  • 101