When I was a military medic I was fond of saying, “For every 100 people in healthcare there are 50 ways of doing things…49 of them are right.”
Any experienced HL7 programmer will tell you that sometimes much of the HL7 specification can be open to interpretation.
Take for instance the term MRN. How many of you immediately recognize it to mean “Medical Record Number”? What does that mean in your facility? How does your HIS associate this to the account number (visit number,encounter number, etc)?
Many people will give different answers, and they will mostly be correct.
That’s lesson #1: Everyone does things differently. If you have 10 years experience working for a single healthcare organization is can be something of a shock when you step out into the wider world.
That was a hard lesson for me to get my head around when I worked for an ED Systems vendor. My only exposure to the healthcare world was in the military. So while I could discuss how to implement something like The Ottawa Rules for deciding when an x-ray was necessary for an ankle fracture with front line clinical users, I was often confused when discussing identifying patients through the registration process.
A few years ago, when the Ontario government was ramping up e-health, HL7 became a very desirable thing to have on one’s resume. Of course, its an essential skill for an HL7 Integrator. However, many gloss over the requirement to understand exactly how healthcare works.
Case in point….I recently implemented a new interface with an outside organization.
When I looked at their spec I was baffled.
They wanted me to add an OBX segment to ADT-A01 messages. In this segment, they wanted me to add the hospital contact information. At the same time, they gave me a code table so I could put the proper hospital code in the sending facility field in the MSH segment.
To those who don’t have a background in HL7 let me explain…an OBX segment usually contains the results of tests. It is found in ORU messages (Observation Results). ADT (Admission, Discharge and Transfer) don’t typically (as in ever) have OBX segments, because there are no results to report on.
So, this is like ordering a burger at a restaurant….. when it arrives, you see that in place of a hamburger (or chicken, or tofu..) patty, there is a big slice of cherry pie….yes, its still edible, but its just wrong on so many levels!
For the record, I flat out refused to do this, pointing out that the hospital information should be pulled from their database, at their presentation/application level.
I next looked at the messages they wanted… Admit, Cancel Admit, and Discharge messages. They would match on the HCN as their Primary Key.
I sent them an email and pointed out that as they were looking for ER visits, that quite often we do not have the patient’s HCN when they arrive, and that sometimes we don’t even know who the patient is. I followed up by pointing out that without accepting update messages, that they would be getting bad data.
They responded by telling me that if I didn’t send an HCN in the A01 they would match on name, gender and date of birth.
There are at least three patients in our MPI who match on those three fields….
They seemed baffled by the fact that that could happen.
I also pointed out two things that should be obvious to anyone with enough experience in this field:
1) A person could be identified in my system as Smith, Jim A, and in their system he could be Smith, James Arnold, and
2) Sometimes Registration Clerks make mistakes….
They pointed out that previous sites they implemented with would store their messages and forward them once a day. Translation “We built a bad interface, and made hospitals do extra work to make up for that.”. I refused to do that, because of the amount of work involved, and the additional failure points.
They decided to proceed anyway…telling me that they still didn’t want Update messages because they wanted to avoid a “chatty interface”, and “it would mean more work”.
The lack of experience, and inability to take responsibility and fix a bad design means that this entity will be receiving bad data. Its not a patient safety issue, or I would’ve refused to implement it.
The fact that other organizations worked around The Bad means that those that designed this system (they have HL7 in their job titles) will go on to other projects. The Bad will continue….and eventually they might end up designing a mission critical system where a failure could result in a poor patient outcome.