Thaiio.com

HL7 is a health data communication standard. HL7 version 2 covers the exchange of patient demographics (otherwise known as Patient Master Index or PMI). HL7 V2 also covers other types of data such as admission details, scheduling, orders and results.

1. HL7 Interfaces are not plug and play

Unfortunately the HL7 V2 standard is interpreted in different ways by implementers and software developers. The outcome is two similar but not exactly matching interfaces that require analysis in order to identify the differences.

2. Translation of HL7 messages

Once the differences have been identified, the messages from one application needs to modified before they can be processed by the other application. Some translations may be relatively simple, such as moving a particular field from one place in the message to another.

For example the sending system may place an insurance number in the insurance segment (IN1). However another vendor may not support that segment and instead expects the insurance number to be placed in the patient identification segment (PID) or perhaps in a proprietary segment.

It is also common that fields may be needed to be moved based on business rules. Fortunately specialist software called interface engines are quire good at this task. For example the iCan Integrator software from Sun Microsystems (formally Seebeyond) provides this kind of functionality.

3.Code table mismatching

HL7 messages are littered with coded data. For example the martial status field contains a coded value such as ‘M’ for Married, ‘D’ for divorced and so on. However the receiving system may expect ‘1′ for married and ‘2′ for divorced. National standards have gone a long way to address this issue. Still, the odds are that one or more fields in your PMI message will need to be mapped. Fortunately interface engines are also good at this task.

4.HL7 PID Identifier List

The patient identification segment has three fields dedicated to identifiers. PID-2 Patient ID (external ID), PID-3 Patient ID (internal ID) and PID-4 Alternative Patient ID. The recommended use of these fields has changed with successive revisions of HL7 (HL7 V2.1, HL7 V2.2, HL7 V2.3, HL7 V2.3.1, HL7 V2.4). Different vendors have interpreted these fields differently. Almost everyone puts the patient’s medical record number (MRN) in PID-3.

If the scope of the interface is more than one hospital, then the MRN for one facility are distinguished from MRNs for other facilities by a facility code (passed as a subcomponent of the PID-3 field). The facility code may need mapping (see Tip 2!).

In another twist, the sending system may handle multiple hospitals (e.g. a patient administration system covering several hospitals) but the receiving system may only want to know about patients from just one facility. A typical example is a independent (but HL7 interfaced) applications such as an ICU clinical application. If the ICU system only manages patients from one hospital, it will only want HL7 messages for patients at that hospital. It may even only want HL7 messages for patients admitted to the ICU. Interface engines are good at the filtering, routing and translating of messages require to make this happen.

5.Repeating fields

Fields that repeat, such as the address field (PID-11) may also cause problems. The challenges include

• Different systems support different numbers of repeats. For example the sending system may support 7 addresses and the receiving system may support only 2.
• The sending system may add, update or delete the repeating field. Deleting a field can cause headaches for the downstream system. Sometimes this is overcome by the downstream system replacing the entire set of repeating fields each time.

6.Repeating segments

Segments that repeat, such as ‘Next of Kin’ (NK1) and alerts/allergies (AL1/IAM) pose similar challenges to repeating fields.

• Different systems support different numbers of repeats. For example the sending system may support 7 patient contacts (sent as 7 NK1 segments) and the receiving system may support only 2.
• The sending system may add, update or delete the repeating field. Deleting a field can cause headaches for the downstream system. Sometimes this is overcome by the downstream system replacing the entire set of repeating fields each time.

7.Shared fields

It is not unusual that the fields interfaced from the sending system can also be modified in the receiving system. Basically if the receiving system was not interfaced, then all of the information would need to have been duplicated by manually typing into the application. Unless the capability to edit data fields covered by the HL7 interface is ‘removed’ from the receiving system, changes made to the data (e.g. adding or changing an allergy, deleting a patient contact) by users in the receiving system, may be list with the next HL7 message received, process and stored for that patient.

Fortunately persistent and diligent interface analysis can overcome these and other challenges. HL7 PMI interfacing is one of the most common and best understood health application interfacing challenges. By applying these tips you will have made a good start along the road to a successful HL7 PMI interface implementation.

For more information on the HL7 standard and HL7 services please visit the Gillogley Services web site.

Peter Gillogley is the Director of Gillogley Services.

Share This

The following is an all too often scenario when trying to implement the enterprise system:

The decision is made at the executive level to build a new computer/software system. A project manager/coordinator is assigned and holds meetings with a newly created RFP committee, stakeholders and users to best determine how this system needs to look, and documents it to tremendous detail. The committee publishes the RFP and invites prospective vendors to submit bids.

After a fairly short period of time, vendors respond, and based on these bids, a short list of potential vendors is created and they are invited to demonstrate their products/prototypes, using both vendor resources as well as the public sector resources. The RFP committee, after another short period of time, makes a final selection and then the contract is negotiated.

The project kickoff occurs; the vendor spends several months or even years developing the system, and a team at the public sector agency helps verify that the system is delivered according to the specifications contained in the RFP. Certain pieces of the system may get rolled out to test users at this point too. During this process, holes in the original RFP are found, or perhaps legislation occurs that must be accounted for. Change orders are submitted, timelines get stretched, and the system costs at least twice as much as the bid.

Finally, the go live date occurs. There is much fanfare, training is done, and users start using the system. The complaints start. Certain influential users seem to sabotage the system. Other users and stakeholders may point out that the system, though delivered as documented, just isn’t going to work. When working with the vendor, the change orders will continue to break the budget, and now that the system is in production, these changes cost even more. The downward spiral has begun and there’s no saving the project.

Ironically, this is the case in most enterprise level systems. By using best practices, all involved in the project have properly covered themselves, and many have traveled this road before. They approach the entire project assuming it will eventually fail, but make sure they are not the reason for that failure. Proper documentation is in place and no one individual can be targeted as the point of failure.

Why is this so difficult? After all, within individual departments on small projects, there has been much success even with bumps in the road. Issues seem to get addressed and the projects don’t get off track much.

There is no simple key cause as to why enterprise projects like this fail. But they can succeed. And it depends on several key factors, each of which must be addressed. One weak link can destroy the project.

1. The right executive has to oversee the project

This doesn’t mean the executive has to manage the project. Many times responsibility for a project may fall on a single department, yet other parallel departments are part of the project. This is a recipe for failure. The executive must be high enough in the hierarchy to be in charge of ALL departments involved, and must oversee and provide “air cover” for the project. As an example, let’s assume a new juvenile justice case management system is to be implemented. Within the juvenile justice agency are several departments. Let’s assume (in a very simplistic way) that there is an IT department, a department that oversees private providers, a department that oversees the public agencies, and a department that oversees administration and regulations. Often times, the IT department will naturally be given the authority and responsibility to implement the new system. WRONG! In this case, the Juvenile Justice Agency head (or even higher level) must be actively involved and ultimately oversee the project. Only this executive can resolve issues that may occur between the other departments. This executive must be absolutely committed to the project, and that means this executive must be involved in all stages of the project, from RFP to vendor selection to final rollout.

2. The right project manager and methodology have to be selected

A project manager who is a stickler for detail and follows rules including all project management best practices may sound like the right fit. However, this is not the case, especially in more complex implementations.

The project manager needs to be experienced not only technically, but also politically. This is a special person that performs multiple roles: Documentation, budgeting, cheerleading, diplomacy, as well as many other hats. This person is absolutely full time during the project and becomes the key person who can be contacted about anything regarding the project. This person works directly for the key executive and they have a relationship that is strong enough to carry through some of the project lows.

This person must be able to deal with adversity and also be able to take responsibility during bumps in the road. This person must have the right attitude. If a problem occurs, this person must be more concerned with the solution than deflecting blame or covering themselves. Because this person has the right relationship with the key executive, they will not have to worry that every decision made during the project is perfect, only that if a decision isn’t right, they have the ability to perform corrective action.

This person also needs to be able to manage a project using an iterative process. As described above, no matter how carefully thought through and documented new requirements will come up that weren’t thought of, or legislative/rules changes may occur during the project. This should carefully be brought up so that those involved in the project won’t worry that every possible detail is locked in stone until the product is delivered. If project participants believe there will be no accommodations for change, then they will try to design something so complex as to handle every possible anticipated scenario, and the system will end up cumbersome and difficult to use.

3. Change Management must start before the RFP is even published

Enterprise projects mean change. For most people, this is stressful. After all, they are used to their processes, know the glitches and work-arounds in their existing systems, and think the pain of a new system just isn’t worth it for them. Often times, the new system will replace a “perfectly good” system they are using, and in many cases, people will actually lose some of their power due to more availability of information that they used to have in their control. Naturally they are resistant to change.

Of course change management strategies must be used especially in enterprise level projects. But they need to be started right at the earliest stages of a project because small problems at the very beginning with key people can destroy enthusiasm and goodwill of key players.

A good way to keep all abreast is an active internal website where content regarding the project is continually updated. It might be good to consider a web log and accept user feedback. A very new trend in the high tech world is the CEO/executives of companies actually running a blog and accepting all types of feedback, both good and bad. Sometimes it’s the fact someone is being heard that’s more important than an action being taken.

As stated in the project management section, early on in the project it is important to allow for some (but not excessive) changes to some of the low level detail design as the project progresses.

In our next article, we will uncover even more powerful reasons to pay close attention to when implementing your system. Stay tuned…. And if you’d like more information regarding this topic and many others regarding custom software development for training, case management, sales and marketing and advanced data analysis, please visit www.globalvisiontech.com.

Copyright © 2006 Chris Freund (All Rights Reserved)

Chris Freund is the President and CTO of Global Vision Technologies, Inc (GVT)., http://www.globalvisiontech.com a premiere software developer specializing in powerful, easy-to-use Internet systems for case management, child welfare, court reimbursement, online training and development, sales and marketing intelligence and pharmaceutical analytical, market research and data capture tools,. GVT’s primary goal is to provide our customers with proven technology systems for improving their productivity, profitability and overall business efficiencies.

Tags: plc
pac
pc
port
vb
vc
c#
parallel
serial
com
usb

Share This