NeoTool — Singular Focus, Healthcare Integrated

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.

The technology used in imaging centers and radiology practices is rapidly evolving. These technology changes affect both the front-end and back-end radiology workflows. The front-end workflows are affected by ever changing imaging and modality technology advancements while the back-end workflows are affected by advancements in information technology (IT). Keeping up with the changes can be a challenge.

The focus of this blog is the IT back-end radiology workflow changes. The goal of healthcare IT is to make all the systems work smoothly together or interoperate for organized, seamless data flow. The first step to achieving such goals is to understand your current workflow.

In an example imaging center, the workflow might be:

• Schedulers enter orders manually on the radiology information system (RIS) or orders move into the RIS electronically from external referring physicians or hospital systems.
• Those orders flow to various internal systems such as the picture archiving and communication systems (PACS) and Voice Recognition (VR).
• The images are acquired:
  • Modalities query the modality worklist manager (PACS).
  • Once the procedure is completed, images are returned to PACS.
• A radiologist reads the images and dictates the results into VR.
• A radiologist self-corrects and approves the reports.
• The reports are distributed to RIS, PACS, Billing and the applicable referring locations.

As is possible to observe in the example radiology workflow, in an imaging center, clinical data must move to and from multiple systems. Even though the workflow is unique for each imaging center, the need to transfer clinical data is not. The moving of data is where HL7 interfaces can make the most headway towards bridging the gap for interoperability and creating that organized, seamless data flow.

Using an HL7 integration approach to move clinical data between applications helps:

• Optimize information systems
• Reduce errors in multiple, manual entries
• Maximize radiology workflow
• Facilitate growth through an efficient workflow

Whatever applications and systems are used to perform the tasks necessary in your imaging center, there is still a need to make the data flow to the right place at the right time based on the capabilities of those systems. With greater requirements for RIS-driven workflow and data exchanges with referring physicians, the HL7 Standard plays a prominent role in automating the radiology workflow.

For addition information, read an interview with the CIO at Radiology Consultants of Iowa and watch a 15-minute web seminar on what role HL7 messaging can play in radiology workflows.

Many radiology practices are focusing on various radiology workflows to understand how to improve turn around times or increase efficiencies. Austin Radiological Association (ARA) focused on their billing workflow and highlighted their approach and success in a recent article entitled ARA Floats an Automated Billing Process… And Inhales. 

In the imagingBiz.com article, ARA discussed the old process and stated “We would touch each radiology report approximately six times to manually key demographics and charge transactions into the billing system.” They went on to describe the completely manual nature of their billing workflow that involved lots of people, pens, and paper.

By focusing on the workflow and determining best practice approach on how to automate it, ARA implemented a new way to deal with the billing process that has delivered big benefits. The primary benefits center around reduction of errors, expedited posting of revenues, and a leaner approach to getting the work done.

The technology applied to the workflow included a document scanning and storage application and an HL7 integration engine. Once the information is in a database, ARA will “push it through our interface engine, convert it to an HL-7 message, and upload it into our billing system.”

ARA is one of our customers. The article highlights, nonetheless, how a radiology workflow can be automated to drive real results. For additional information, please read a customer case study (PDF).

An Imaging Economics article - The Purview of the PACS Administrator - highlights the critical components of a PACS Administrator’s role that impacts radiology workflow. It is a great article because it outlines many of the key knowledge and work activities required to be an effective PACS Administrator. More than ever, PACS Administrators contribute significantly to defining, enabling, and refining radiology workflow.

Key Knowledge of a PACS Administrator. DICOM is always the healthcare standard people think about when radiology workflow is mentioned. Today, the knowledge required has expanded to include the HL7 Standard. HL7 integration is the standard that facilitates the data flow between the various applications (e.g., RIS, HIS, EMR, PACS, etc.) and streamlines the workflow by automating various activities. It is refreshing to read an article about PACS Administrators that acknowledges the HL7 Standard as a required element to gain efficiencies in a radiology practice or department.

Key Work Activities. PACS Administrators play an essential role in defining radiology workflows, re-engineering radiology workflows, and enabling radiology workflows with the right technology. This requires the PACS Administrator to have strong interpersonal skills along with strong communication, project management, IT, and healthcare standard skills.

Other key activities include monitoring the data flow, ensuring it is continuous so that a radiologist’s workload is even throughout the day. Again, this article points out it is not just the PACS that needs monitoring but also the integrated systems and interfaces. Seamless workflow requires integrated systems, which also requires flexible and robust interfaces between the various applications. The PACS Administrator is required to know more about data flow between all the systems that eventually touch the PACS or are eventually touched by the PACS. 

Equally important is data quality. Automating data flow through the systems and applications removes the opportunity for keying (re-keying) errors; additionally, it means that the data needs to be translated into different formats correctly in order to meet the various applications’ requirements.

As we have discussed in other posts, the PACS Administrator plays many different roles and the responsibilities and knowledge required have grown. In this healthcare IT article, Imaging Economics has delivered this message very competently.

During a recent stay at a very well respected Dallas area hospital that saw my wife and I welcome our first child into the world, I was reminded that the “Device Divide” that separates the vast majority of healthcare providers’ medical device data from the rest of their clinical information network is not limited to just small to medium-size hospitals.

Given the fact that the hospital is part of a large statewide chain and would likely be labeled as cutting edge from a technological standpoint, I was somewhat surprised to see a nurse come in every 2-3 hours to dutifully record my wife and son’s vitals in a paper chart. I’m sure that information was re-entered into an EMR at some point, but I couldn’t help but wonder how often the data gets transposed or forgotten.

That experience begs the question - why has it taken so long to bring patient care device data online, even at some of the nation’s largest hospitals? The problem of crossing the “Device Divide” – that gulf between the hospital network and its medical devices that is typically traversed by the nursing staff with pen and paper – is not an easy one.

One reason is a lack of cost-effective, reliable solutions for doing so. Device connectivity has only recently (within the past couple years) been given the attention that it warrants, and early solutions have been plagued with the same kinds of ‘kinks’ that any early stage technological advancements have encountered.

Another closely related explanation for the delay in crossing the “Device Divide” is that enabling devices to bridge that gap represents quite a leap outside of most manufacturers’ technological sweet spot. That’s not to say that they’re not extremely capable. In fact, the exact opposite is true – patient care device OEM employees are some of the brightest that I’ve run across. It’s just that, as Robert Nadler, an employee at a device manufacturer, recently blogged:

“The problem… is that we don’t have the resources to build each unique interface required to satisfy all of our customers. Plus that, our business is building medical devices, not EMR solutions.”

Device companies have spent years building R&D and engineering departments focused on building better and better equipment that takes more and more accurate readings in the easiest possible manner. Their aptitude for doing just that is what has always separated them from every other device manufacturer with whom they compete.

But bridging the divide requires a very different skill set – the ability to write software that provides HL7 integration capabilities that enable devices to interface with countless EMRs and other clinical applications. And once written those healthcare integration systems become much like an NFL referee – the good ones go unnoticed, and the bad ones gain the kind of notoriety we would all like to avoid. Despite representing a critical part of the total connected device solution, from the customer’s perspective there is nothing tangible about an interfacing system that will make them value it enough to justify the cost of ramping up a development shop to construct it in-house.

That’s why I think the interfacing conundrum is one that lends itself nicely to the idea behind Joseph Nemeth’s article entitled “The Drive Toward Collaborative Innovation for Medical Devices” in the August 2006 issue of Product Design & Development magazine. In it, he concludes that:

“Collaborative partnerships provide a balance of assessing what organizations require from outside sources given their need to innovate, and what they must retain to achieve their business and revenue objectives. It is a sound enterprise strategy that can minimize time to market, reduce costs, generate differentiated offerings, and drive a business model for sustained industry growth.”

Collaborating with a strategic partner well versed in ways to cross the “Device Divide” could prevent manufacturers from stretching their resources too thin and keep them from stepping too far outside their core competency. If chosen wisely, such a partner could help get a sound connectivity strategy in place for much less than the cost of taking on the initiative in a vacuum.

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 additional resources on HL7, request a complimentary copy of NeoTool’s HL7 Reference Guide and visit our resources section for additional interfacing insights.

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.

When designing an HL7 interface to send pharmacy orders from a clinical application to a pharmacy system, it can sometimes be a challenge to determine which HL7 message type to use to send different types of information.

Since both ORMs and RDEs can be used to send pharmacy orders, the question sometimes arises as to whether one should use ORM or RDE for pharmacy orders when working on an HL7 integration project. Either approach is valid.

Ultimately the question is not “Should I use ORM or RDE for pharmacy orders?”, but rather “Do my sending and receiving applications support exporting and importing of ORMs, RDEs or both for pharmacy orders?” Some vendors may choose to only export/import pharmacy orders as ORMs with additional segments or Z-segments as needed, while other vendors may choose to support export/import of RDEs instead, and still others may accept both. 

However, the above can lead to a challenge should a sending system only support exporting pharmacy orders using the HL7 standard ORM message type, while the receiving system can only support importing pharmacy orders using the RDE message type (or vice-versa). What this means is that the sending system would be sending the order in a different message format (ORM) that is in a different message format (RDE) than the receiving pharmacy system can accept — hence the receiving pharmacy system would either ignore, reject, or error the order. In such scenarios, an interface engine can be used to transform the ORM from the sending system into an RDE that the receiving system can import successfully (or vice-versa).    

There are two primary methods of moving clinical data in a hospital or clinic:

1. Point-to-point interfacing, which provides a direct connection between exactly two applications
2. Interface engine interfacing, which provides a way to leverage a set of interfaces between many applications

The presence of an HL7 interface engine in a healthcare environment gives more control to an organization and saves money and time by:

• Reducing the required number of export and import endpoints
• Allowing for reuse of data between applications
• Providing an easier method to interface a new or replaced application
• Providing the ability to monitor the entire system at one time
• Providing the ability to proactively notify interested persons using visual display and e-mail, when problems arise

Facilities that are pursuing healthcare integration initiatives and use an interface engine model find that:

• It is much less expensive and takes less time to initially implement an interface because an engine allows for leveraging of data and an engine is flexible in its acceptance of data
• The cost and time required to add new or replace existing applications is frequently less than half that required in a point-to-point model
• It requires considerably less time and money to maintain and monitor the interfaces because of the availability of centralized monitoring

There is an excellent 22 page white paper on this website entitled, “Why Do I Need an Interface Engine? Evaluating Two Approaches: Point-to-Point and Interface Engine.” It discusses the pros and cons of these two approaches in detail. Specifically, the white paper provides details on how an HL7 integration engine provides more control and saves time and money in a clinical or healthcare environment. The paper includes a comparison of an interfaced environment using point-to-point communications and an interfaced environment using an interface engine.

In a prior post, I described the motivation for mapping HL7 messages. As described in that post, the HL7 2.X messaging standard is the most widely used method to move healthcare information yet the details of the messages vary greatly from system to system.

An HL7 engine provides several functions and one of the key features of an engine is the ability to map from one set of application assumptions to another set. Said another way, an HL7 integration engine takes a message in one format and maps or transforms it into another format.

The starting and ending message formats will be controlled by the applications involved. Prior to HL7’s market dominance, the variety of message formats was large. This meant that typically an interface’s data elements closely matched the data model in the source application. Further, this made the creation of the interface “easy” by the sender of the data but “very hard” for an engine in the middle or the receiving application.

The HL7 community’s approach to define a base data model for the messages makes the variety of message formats smaller in today’s engine market. This reduction in the number of message formats is somewhat offset by the huge number of interfaces that must be created.

In the current market, typically an interface engine is mapping in one of the following ways:

• Mapping between two or more interpretations of the HL7 standard to resolve data model or workflow issues between incompatible applications
• Mapping between XML and HL7 and/or HL7’s 2.XML format
• Parsing an HL7 message and writing message contents to a database
• Reading a database and creating an HL7 message
• Working with a mixture of proprietary message formats such as CSV or flat files (sometimes called COBOL copybooks)

An HL7 interface engine needs to be flexible enough to deal with non-standard HL7 messages in an efficient and accurate manner, without having to manually code the differences for each external healthcare vendor with which it is communicating.

An HL7 interface engine also must provide a quick way to start with a standard “base HL7 version” and modify it to mirror the differences in the message that is sent or received by a particular application.

As an example, NeoTool’s interface engine supports non-standard HL7 formats by:

• Including all the standard HL7 versions loaded and available for easy modification
• Allowing for modification of these base versions by creating a derivative of the standard message format that inherits all the characteristics of the standard format – supports Z segments, non-standard separator characters, etc.
• “Change once” segment definitions so that a single change is properly reflected in all messages that use that segment
• Providing the ability to leverage prior derivative work and create a derivative of a derivative – to support two versions of a single application, for example

The message format support of an interface engine is combined with a method of actually mapping from one format to another format. Typically this is accomplished via some graphical mapping tool and executation environment. In a future post, I will describe some of the techniques used while actually mapping messages.