Archive for the ‘HL7 Integration’ Category

Do you remember your first interface?

If you do, chances are likely that it was a custom point-to-point interface, very expensive, took many months to finish, and it did not necessarily meet all of your needs. Right?

Ouch. Let’s not go back to that ever again.

Welcome to the next generation of integration = faster, better, and cheaper. Interfaces can now be done in hours. They are also designed to meet specific needs, and the cost can be contained, i.e. minimize the customization on the vendor sides.

Believe me, this is true, though it sounds too good to be true. I understand because I, too, was a non-believer when I worked for one of those vendors.

The typical process as I remember it back then looked something like this over a year, if I were lucky:

1. Customer calls to explain they need an interface
2. Customers are redirected to inside sales to get a quote
3. Customer approves quote
4. Request is sent to the integration team queue
5. After the queue wait time which could be weeks or months, the request is evaluated
6. Specifications for the interface are discussed, documented and confirmed
7. Interface goes to the development black hole
8. Months later, you are told the interface is in your test environment for testing
9. You test and it doesn’t work
10. Repeat steps 8 and 9 until it works and pray it does not fall out of the scope such that you end up back at step 6
11. Plan, schedule and deploy into production
12. Troubleshoot production issues until interface stabilizes

I failed to mention the organizational politics and red tape, the lack of response or interest after time, and attrition over the year for any or all of the parties involved.

Whew!

Then when you think you are done, the support burden kicks in. It was amazing to see from the vendor perspective that the interfacing module (20% of the product) caused about 80% of the support tickets that could only be supported by less than 20% of my staff.

Interfaces were downright no fun.

That was then, this is now.

Now, I can configure an interface to go into system testing in minutes to hours. Interfaces can go live in days, or a few weeks at most. All the interfaces can be centrally monitored. I get proactive alerts if something is wrong rather than a call from the floor, tech, or doctor.

May not perfect, but life is much better with the new technologies in the integration world.

In order to make the most out of your time and ultimately streamline the process of building an HL7 interface, there are some key things every interface developer and analyst should do. As a senior implementations consultant at Corepoint Health, Alex Lin offers his top three suggestions for interface developers and analysts:

Test – Early and often. Ask your vendors for a varying number of test messages and obtain up-to-date system specifications. (System specifications are particularly important for an interface developer as they can often be wrong or out-of-date.) It is important to always test interface connections prior to putting an interface into production. As you test, remember to save your work. Save early and often.

Talk to your vendor. Communicate with your vendors and test with them if possible. This not only streamlines the implementation process but helps build rapport and a healthy relationship. Moreover, be flexible and understanding. It is better to have problems identified early than to strain a relationship when things don’t work later on.

Document your changes. Sometimes you will establish an interface and not revisit it for a few years. Later on, it will be valuable (for you or whomever inherits that interface) to see what changes you made when you initially established the interface and why you did what you did.

For an interface developer or analyst, investing in the establishment of an interface by testing, saving and documenting your work, will not only help future interfacing needs, but also help preserve the long-term value of the interface connections.

Are there any additional actions you like to take when developing an HL7 interface?

Having recently returned from the annual HIMSS conference in Atlanta, I’ve had a couple of weeks to reflect upon the experience, and in particular the concerns of folks that stopped by the booth to ask questions or watch an HL7 integration engine demonstration.

One of the recurring themes was the uncertainty surrounding the future of various legacy interface engines, especially as related to product support, professional services, and new functionality for future releases. Having recently worked on several integration platform conversions, wherein we evaluate existing interfaces and convert them to interfaces consolidated in our integration engine while keeping the conversion transparent to the end-users, I thought I would share some of what I’ve learned.

While there are certainly a proverbial “thousand ways to skin a cat”, generally, there are two approaches that you can take when considering how to write the logic that will be used to convert the existing interface to the new engine, regardless of whether the original legacy code is in Monk, TCL, or any of the other numerous languages in common use.

The first approach would be to simply replicate the existing logic as closely as possible, regardless of how well you understand the intended workflow at any given point in the logic, and despite any opportunities you see to modify the logic to conform to best practices, more efficient algorithms, etc. I’ll call this the “imitation” method. This method typically has the advantages of:

• Faster turn-around on existing interfaces
• Preservation of all comments, original logic, and structure as closely as can be imitated

The second approach, which I think of as the “improvement” method, is to first evaluate and understand exactly what the existing logic is attempting to accomplish, and specifically, how it means to do so. Then, the task at hand is to replicate the filtering, mapping, and data normalization steps as closely as possible, while taking advantage of the opportunity to conform to best practices and to leverage the expanded functionality that is inherent in newer engine architectures. Doing so could result in any of the following improvements:

• Increased performance (by streamlining the logic that filters, maps, and translates the HL7 data)
• Improved readability and documentation, through the consistent application of appropriate comments in a well-defined, organized logic structure. This eases maintenance of the interface, as anomalies are researched and addressed, or as workflow requirements change.

Each approach has advantages relative to the other, and anyone who intends to convert an existing interface should consider them before they dive into a conversion. The last thing anyone wants to do is get halfway through a lengthy and complicated conversion, only to find that they have been reduced to “trial and error” methods of determining the remaining logic needed to complete the interface. Knowing which method you intend to use before you begin can help you avoid such pitfalls.

Finally, during the entire conversion process, I can’t emphasize strongly enough the need for clear communication between the person doing the conversion, and the people who will be using and maintaining the interface on a day-to-day basis, as the needs of the end-user’s organization should always be the defining criteria used when establishing which conversion method should be utilized.

For more information on understanding, developing, and testing an HL7 interface, please search and read this healthcare integration resource site. Also visit HL7 Resources and the Healthcare Interoperability Glossary to learn more.

With the discussion on healthcare interoperability escalating, it is good to take a step back and outline some basics of an HL7 interface. Understanding an HL7 interface is essential as well as approaches to take  in implementing a growing number of HL7 interfaces.

What is HL7? HL7 is the most widely used standard to facilitate the communication between two or more clinical applications. The prime benefit of HL7 is that it simplifies the implementation of interfaces and reduces the need for custom interfaces. Since its inception in the late 1980’s, HL7 has evolved as a very flexible standard with a documented framework for negotiation between applications. The inherent flexibility makes deploying HL7 interfaces a little more challenging at times.

Who uses an HL7 interface? There are several types of roles involved with HL7 interfaces, including clinical application analysts, integration specialists, application programmers, and systems analysts.

How should you approach an HL7 interface? To facilitate communication between two healthcare applications, a modest HL7 interface includes:

• An export endpoint for the sending application
• An import endpoint for the receiving application
• A method of moving data between the two endpoints
• A method for handling the queuing messages
• A method for logging the flow of messages

Logic tells us that each healthcare application must grant access to accept and send patient data and have rules of what it will accept and what it will send. Frequently, the access grant will be hard-and-fast rules rather than flexible ones that provide easy methods for exchanging data. This access to data is usually tightly controlled by each application vendor to ensure data integrity within their application.

To implement an HL7 interface between two or more applications, providers usually implement either a point-to-point interfacing approach or utilize an interface engine. A white paper which outlines these two approaches is entitled What Is Your Healthcare Interfacing Approach?

On this site, we have written many posts about working with various healthcare standards with a strong focus on HL7 interfacing and messaging. Outlined below are three posts worth a read to gain further insights on developing and testing HL7 interfaces.

• Getting Started with Your HL7 Interface:  Highlights what to ask for and what to ask about as it relates to HL7 messaging.
• HL7 Specifications Defined:  Defines what should be included in a healthcare interface specification.
• HL7 Sample Messages – Always the Best Way to Go:  Outlines the importance of getting sample HL7 messages when developing an interface.

This information should provide you with a solid start in your healthcare interfacing project. Check out HL7 Resources and the Healthcare Interoperability Glossary for further definitions.

As an integration engine support engineer, I frequently provide consulting services to interface analysts, programmers, and developers that are responsible for the planning, implementation, care and feeding of new HL7 interfaces. The range of technical prowess among the clients I assist is fairly broad. For example, on any moment of a typical day you may find me fielding questions on segment cardinality from a self-professed “HL7 neophyte”, while minutes later I may be on a call to review customized TCP/MLP message framing test results with a beleaguered multi-tasker. Thus, while some are very conversant with HL7 standards, and more importantly, the actual “as-built” specifications of their trading partner’s production environment—many are not.

One of the questions that almost always needs to be addressed during new interface planning, regardless of the experience level of the client, is which version of HL7 to use when we construct messages. A recent user-community poll indicated that a large majority of HL7 messages in production are a v2.3 or v2.3.1 variant. However, when a new interface is being built (to send order results to a client system, for example) should a sending reference lab, imaging center, or hospital use the most common, or the latest v2.x?

While it is true that the newer versions of the v2.x HL7 standard are backward-compatible, the process of identifying gaps in the specifications becomes simplified when both trading partners are operating off of the same blueprint. Similarly, one shouldn’t arbitrarily choose the most common v2.x of the standard to use as a base-line for their messages either—unless their interface engine is flexible enough to easily make and test changes to the message structure, they could end up with some extended development and potential headaches long after they thought their specifications were “complete”. So which course of action is the most prudent?

My recommendation, whether solicited or offered as free advice on best practices, is always the same— talk to your trading partners. They know best which version their application is ready to accept. If they have no preference, then your discussion should lead to an agreement on the version to be used, and will naturally lead to other discussions that will help smooth the way for a more swift and efficient implementation.

To start with, IHE is an initiative by healthcare professionals and industry to improve the way computer systems in healthcare share information. IHE utilizes existing standards like DICOM and HL7 to address clinical needs. HL7 and DICOM standards provide the basis for the framework, but they do not address everything. For example:

• Too much optionality requires site-specific interface development.
• Conflicting interpretations and gaps in the standards cause an inefficient workflow.

IHE is built on standards, including:

• HL7
• DICOM
• W3C
• XML
• TLS

Technical Frameworks provide the detailed implementation of standards to provide consistency for Integrations. The integration profiles in IHE are developed by the industry subject experts, both vendor and healthcare institutions.

So what’s required of participating organizations?

First, you need to complete the MESA test, which will simulate the other vendors system and submit the log for approval before you are accepted to the Connectathon. This ensures that all system will be at a certain level. At the Connectathon, you are assigned your testing partners who you test with throughout the week. At the end of the week, a group test is performed. IHE has Project managers that observe and analyze each systems logs and software for pass or fail of the transaction test.

How do vendors prepare for the Connectathon? What helps vendors pass?

Start on time to look over which profiles and actors that you want to test with; you only have a couple of months between latest MESA test software release and when the logs are due to submit. My hat off to the dedication and time the engineers put in to have it done just before the holidays.

How would vendors go about getting involved with IHE and participating in future Connectathons?

Contact IHE and they are happy to help you through the process. IHE needs the registration to be complete in mid-September for next years connectathon in January or February, so start planning at least a year out. Vendors are very open to share helpful tips since they all benefit from more vendors and systems participating each year.

To pass on a tip that I was given, if it is your first year, bring only one system and focus on a mature profile which has gone through a couple of Connectathons. Remember, most vendors have Alpha and Beta software for the tests, so there could be much waiting around while software is tweaked.

Bring software engineers to the Connectathon; software that is failing may need to be altered on the spot to continue. Remember, you are not only responsible for your product passing, but other testing partners may depend on it as well. Bring one person that interfaces with the other vendors, as there is much coordination needed to get through the event.

From a business standpoint, how does implementing IHE profiles help vendors?

It gives you the credibility from a practical standpoint. Customers don’t have to take your word for it, and you as a vendor can back it up with an IHE statement. Also you may find the requirement in RFPs, and you don’t want to check “no” on a question regarding IHE. In addition, IHE is about workflow and interoperability and developed based on use cases. Much of the implementation challenges in the field have been solved, so the application is more successful to the customer’s need and directly has an impact on the ability to integrate/interface with other medical applications.

Keep in mind that much of the CCHIT interoperability certification requirements are taken from IHE.

There are many issues associated with connecting physician offices running EMRs into a hospital or reference lab. In prior postings we’ve covered:

• The use of standard vocabularies or terminologies such as LOINC.
• The challenges of using HL7 Orders and HL7 Results in a standard way — typically via profiling such as ELINCS profile (also described here).
• Communications infrastructure — using a VPN with a real-time, always-on connection or using an asynchronous method such as web services.

Why do I mention this topic? Because it is “readers write” day over at HIS-Talk and there is some excellent discussion about many of these topics.

Selected quotes:

I think the labs agree [more standard integration] needs to happen, but just don’t want to invest in it. It is very painful to get a lab interface up and running. Each lab has multiple regions that act differently, have their own compendiums, etc. Because there is no standard test code, all the codes are proprietary. Testing is required for each and every one.

…

One of the barriers right now is a normal one for our industry: the existence of entrenched systems which would be very costly to change. Since there are many regions with just one or two dominant lab players who control their local markets, there isn’t a great deal of momentum to make the changes happen very fast. However, the ELINCS standard definitely has traction with major players such as the Markle Foundation, CMS, HL-7, etc. and it is also the standard for results for CCHIT certification which is obviously a major force.

…

By their very design, the use of a standard will require the implementer to jump though at least a few hoops (some of which may be on fire). Also, the device-to-EMR interface you complete today will probably not work for the same device and EMR in a year from now.

…

Nobody dislikes standards. Interoperability is usually good for business. There are two primary reasons why a company might not embrace communications standards:

1. The compromise may be too costly, either from a performance or resources point of view, so a company will just do it their own way.
2. You build a propriety system in order to explicitly lock out other players. This is a tactic used by large companies that provide end-to-end systems.

…
I’ve been to many conferences (TEPR, HIMSS, World Health Congress, etc.), and nobody seems to be able to tackle the thorny problem of semantic interoperability. Everyone can speak HL7, but that’s only half the problem. There are so many different entities that need to agree on what each of those data elements MUST ACTUALLY MEAN that I’m not sure we’ll ever see a solution.

Despite previous warnings, I recently committed a cardinal interfacing sin when working on an HL7 integration project. Upon kicking off a large project involving several applications with which we’re interfacing, I requested both specifications and sample HL7 messages from the vendor. The specifications came right away; the sample messages unfortunately did not.

Rather than making a big deal out of the messages and insisting that we get them prior to interface construction, I dove right in to perform a gap analysis based on the specifications that we were furnished in order to determine the incompatibilities between the systems involved. After carefully identifying the mappings required to transform the HL7 messaging such that it would satisfy each system’s specs, the interfaces were configured.

It was time to test, and out came the disappointingly small (in some cases just 1 or 2 messages per application) sampling of test messages that had slowly trickled in but had been shelved until the ‘real’ work of building the interfaces could be completed. Those messages were loaded, the interfaces were turned on, and voila!

Errors.

The sample data didn’t align with the specs, rendering my beautiful side-by-side comparison spreadsheets useless. The mapping tables I developed from those specs to translate representations of common fields such as gender, race, and relation? Worthless as well.

How could I have so quickly forgotten that the proof is almost always in the sample message pudding?

Specification documents are often hailed as the keys to unlocking the secrets of the import/export modules of healthcare applications and successfully brokering communication between disparate systems. Good specs do just that. The only problem is that you stand a better chance of finding a few needles in a hay mountain. They’re out there; they’re just not very plentiful.

The shortcomings of specs are attributable to a variety of factors:

• They’re rarely updated at the pace of development. While correct at a particular moment in time, changes are often times made to the interface that either never make it into the document or do so after those changes have been introduced to the marketplace.
• They’re often out of sync with upgraded software versions. Even if a vendor takes extreme care in updating both the interface and the specifications simultaneously, healthcare facilities may have upgraded their software since receiving their specification document and therefore unknowingly hand an outdated version to trading partners/interface analysts.
• Variances in installed modules/features are difficult to document. Many applications offer a wide array of software modules and features that can be alternatively installed depending on the customer’s budgets or workflow that make the production of a “one size fits all” specification difficult.

But the messages don’t lie. Having them takes the guesswork out of determining exactly what is coming out of or readily received by a healthcare application. Today’s most sophisticated interface engines will even go so far as to take those messages and build an HL7 derivative to which they’ll conform at the click of a button! There’s not much left to the imagination, and thus interfaces can be built with a much greater level of confidence.

So if you’re a vendor, be sure to stamp out a good sampling (at least 50) of anonymous messages for each message type supported through your application interfaces each time a change to the interface is introduced. Doing so will not only be appreciated by interface analysts trying to connect your systems to others in a hospital, clinic, imaging center, etc. It will also ease your own interfacing burden by reducing the number of calls and questions you field related to interfacing.

And if you’re an interface analyst, stranded on a deserted integration island and given the choice between sample messages and specifications to ensure your survival, always opt for the messages. They represent much more than a means to validate interfaces – they can be vital to successfully building them. Just make sure you don’t settle for 1 or 2 like I did.

A majority of clinical applications today have the ability to interface via HL7, or as we say, they can ‘speak’ HL7. The problem is that the HL7 standard is flexible, and it is typically customized by each vendor to fit the specific needs of their application. When you need to build an interface between two independent systems, it is helpful to know where to start and what information you should gather from each vendor to begin the project.

Ask For:

HL7 Specifications – Each vendor should be able to supply an inbound and outbound HL7 specification for their application. The quality of these documents will vary greatly from vendor to vendor. These documents will allow you to do a gap analysis (see below) between the two systems.

Sample Messages – Regardless of the quality of the specifications, sample ‘production’ messages are a real representation of the messages and data format that will be exchanged. You can use this sampling of HL7 integration messages to build and test the interface, if you are using an interface engine.

Connection Details – Most HL7 interfaces transmit data over TCP/IP. That being the case, it is important to get the IP address and port information where these applications will be transmitting or receiving messages. Other considerations are VPNs or file transfer protocols. Verifying and testing the communications layer earlier in the project will prove advantageous for all parties.

Contact Information – Make sure you get the names, phone numbers, and e-mail addresses for each vendor’s contacts. These contacts will be involved with the testing and development of the interface.

Ask About:

Communication and Workflow Details – It’s important to have an understanding of how each system will handle acknowledgement (ACK and NACK) messages. Under what circumstances would a receiver connection send back a negative acknowledgement (NACK), and in this situation how should the sender respond? Should the sender resend the same message, fail the message and continue sending the next message, fail the message and suspend sending, etc. These types of workflow questions need to be addressed so that you don’t run into issues in production that could have been avoided.

Develop:

Gap Analysis – Compare the HL7 specifications from the vendors and make note of the differences. Common problems include: 1) messages sent by one system but not supported by the receiving system, or 2) message format differences. The gap analysis will help you estimate the amount of work involved in interfacing the two systems.

Test Plan – Work with your vendors to develop a test plan. The test plan needs to be complete with a list of scenarios you want to walk through prior to considering the interface ready for production. The application’s critical path is a good place to start. Scenarios may be as simple as admitting, updating, and discharging a patient, or they may be more involved and include placing orders, canceling orders, receiving results, and updating or adding addendums to reports. Also, include communication testing scenarios. What happens if the network goes down between the applications? Do they recover automatically when the network comes back up?

Go-Live Plan – Have a plan and a schedule for the go-live of the interface. Check availability for all key players. Plus, consider the need for minor modifications during the process. Can those changes be made at the time of go-live?

For an HL7 Interface definition as well as others, HL7 Resources is a great place to find additional information.

Healthcare billing departments are dependent on getting accurate information in a timely manner to meet its goals: increasing cash flow and decreasing operational costs.

The challenge is getting the data from multiple systems and even multiple facilities. Many manual methods such as faxing, printing, scanning, etc. are used to facilitate the information gathering. Getting the needed patient demographics and charge capture data can be accomplished using HL7 interfaces* or through HL7 integration initiatives.

(*Note that interfaces are dependent on an application’s ability to speak HL7, or produce or consume data in an electronic format.)

HL7 integration presents the opportunity to streamline processes and share information quickly between systems. For example, in a hospital setting, if the laboratory adds on an additional test (e.g., reflex test), then the lab can send a charge message directly to the billing department. The billing department will get notification of the add-on procedure, and it will not require any manual intervention by a clinician to fill out a manual charge capture form.

Among the hundreds of messages in HL7, the four most common messages used to transmit information to a billing department are the following:

1. DFT = Detailed Financial Transaction
2. ADT = Admission, Discharge, Transfer
3. ORU = Observation Result Unsolicited
4. BAR = Billing Account Record

Outlined below is an example DFT^P03 message:

MSH|^~\&|RIS|RIS|AR|AR|200612050932||DFT^P03|119272|P|2.5|||||||||
EVN|P03|200611031912|||
PID|||1234567||JONES^JOHN^^^MR||19270523|M|||1 MAIN AVENUE^^PLANO^TX^75093^||214/555-5555~~|~~||M|||123-12-1234||
PV1||||||||B39446^GORDON^FLASH|||||||||Out|||~~~||||||||||||||||||||||||200411221128||||||
FT1|1|0000001||20061103||CHARGE|G0202|DIGITAL-SCREENING BILATERAL||1||395.00||||^^||O|2128^150.9~2309^173.3|B38286^BERGER^PAUL^||||||76|
GT1|1||JONES^JOHN^||1 MAIN AVENUE^^PLANO^TX^75093|214/555-5555||19270523|||Self|123-12-1234||||^^^^||||
IN1|1|5||MEDICARE-FIRST COAST|Po Box 44234^^Jacksonville^FL^32232||203/639-3124|||||20041214||AUT1234567||
JONES^JOHN^|Self|19270523|1 MAIN AVENUE^^PLANO^TX^75013^|||1|0|||||||||||||123121234A||||||||^^^^|
IN1|2|11||ANTHEM BLUE CROSS AND BLUE SHIELD|P.O. BOX 533^^NORTH HAVEN^CT^06473||1/800/922/3242|||||20041214||||JONES^JOHN^|Self|19270523|1 MAIN AVENUE^^PLANO^TX^75093^|||2|0|||||||||||||XGM0555M50555||||||||^^^^|
ACC||||CT|N||||||

Automating your environment with HL7 interfaces leads to many tangible and intangible benefits for your billing facility:

• Increased accuracy with reduced manual entry
• Increased Turn Around Time (TAT) with data flowing to billing in near real time
• Decreased paper records storage and office space with electronic data (digital archive)
• Fewer denied claims due to timely and complete information
• Increased cash flow with lower DSO (Days Sales Outstanding)
• Improved data retrieval – faster, searchable, simultaneous access by multiple users
• Increased patient satisfaction with more accurate billing
• Increased efficiency

The end result of implementing HL7 interfaces to automate the collection of accurate, timely clinical data for your billing workflow: Your operations will be more competitive, profitable, and streamlined.

Review the recorded webinar presented on this topic July 31, 2007.