NeoTool — Singular Focus, Healthcare Integrated

Any “feed”, whether an ADT feed, ORU feed or ORM feed, is basically a streamlined way of getting messages. In the HL7 standards world, ADT, ORU (order messages) and ORM (results messages) are the most common HL7 messages. Of those three, ADT messages are the most commonly used.

ADT stand for “admissions, discharges, and transfers”. It basically means demographics; anytime you think of ADTs, think demographics: the patient’s name, the patient’s location in the hospital, his or her address, phone number, gender, etc.

There are many different types of ADT message types, such as:

• Registering a patient
• Discharging a patient
• Merging patient files to avoid duplication

An ADT feed is one way an application or a provider can get all that information from a clinic or hospital information system (HIS). With the constant updating of a client, customer or patient’s data, ADTs comprise the most HL7 messaging traffic. Change of address, addition of a middle name, and addition of next of kin are all examples of the type of data updates that make up ADT messages. Upon updating, this clinical data will then flow out to different places such as outpatient clinics or laboratories, dependent on who needs that information in their database.

Typically, a hospital registration database will have the master of the patient data and information. Each time patient information is updated, the updates will be pushed out in the form of an ADT message to the appropriate applications in facilities such as labs or clinics.

ADT feeds are usually received through either an interface engine or direct (point-to-point) interface.

In the case of an interface engine, clinical data can be provided to a variety of places. An export can be set up so there can be a one-on-one connection where, for example, a hospital registration system can establish a connection to a lab outside of the hospital. “Data dumps” are also possible, where one end of the application has all the files and the other doesn’t and through the connection, the patient data can all be transferred.

In summary, ADT feeds are the most common and high volume feed used. The updating of patient information eclipses the volume of order and result feeds. Having up-to-date patient information, though, is a critical component in streamlining and improving the continuity of patient care.

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.

HL7 does not provide a real world standard for controlling the display of text documents on the receiving system. While there are some rarely-implemented formatting codes provided in the Formatted Text (FT) section of HL7, often senders must deliver “plain, vanilla text” in order for a receiver to accept a text document via HL7 messaging. The receiver will then display the lines of text in whatever manner is appropriate for that application.

Typically this question comes up when someone is trying to ensure that text documents they send (such as a radiology report) will be displayed a specific way on a remote application. Asked another way, the sending HL7 user want to know if the receiving (remote) application will display the report in a given size font or a fixed-width font. The question revolves around the desire to put “low tech text formatting” in place to build things like tables, indented paragraphs, or even nicely word-wrapped paragraphs.

The reality is that HL7 messaging does not imply or demand that an application display a text report in any specific manner. If there is a need to ensure that the receiving application displays data in a specific way, the interface analyst must review the display mechanisms in the receiving application to see what is possible. The analyst must then change the message (text) format to work within those provided by the receiver’s display mechanisms. Typically the sender can not force the receiver to take a “pretty text document.”

The problems most frequently encountered when moving text reports are related to the size of the text, how long the lines can be, indenting text, the desire to make headers “stand out”, and how word wrapping is accomplished. All of these items are under the control the receiving application. In the real world, HL7 has no opinion on these issues.

Often applications support moving rich text documents via either an ED or RP data type. This means that the sender can deliver a PDF, Word document, RTF document, HTML document, etc — but only if the receiver supports the format. More details on rich documents are provided in this blog posting.

For those who have been involved with the HL7 Standards over these past decade, there has been a slow evolution to expand the standards, change the approach (i.e., HL7 V2 to HL7 V3), and include clinical documentation. Healthcare integration initiatives are benefiting from the changes, but confusion rises as to the differences and the growing complexity.

One question that arises is:  what is the difference between HL7 messages and HL7 documents? Outlined below is quick review of differences.

HL7 Messages:  HL7 messaging is usually a real-time flow of patient and clinical information. They convey current information about a patient, including updates to admissions or discharges (ADT), orders for tests (ORM), and test results (ORU). The more current the data, the more relevant it is in the delivery of patient care. HL7 messaging impacts the ongoing process of delivering care by delivering the most current, updated patient information available.

HL7 Documents:  HL7 documents are static - accurate given the point-in-time in which the information was captured. HL7 documents contain important information, but it is a snapshot. The documents are useful in providing relevant information in referrals to other physicians or healthcare organizations. Accordingly, it provides a starting point for the next step in patient care.

The differences in HL7 messages and HL7 documents can be summarized as active vs. passive information. HL7 messages are continuously delivered as status changes or new information is obtained. HL7 documents contain information at one specific point in time. Both are critical, however, especially when delivering connectivity or integration to Electronic Medical Record (EMR) applications in various healthcare provider offices.

How do the healthcare standards apply? In HL7 messaging, HL7 V2.X and HL7 V3 apply. In HL7 documents, HL7 Clinical Document Architecture (CDA) and ASTM Continuity of Care Record (CCR) standards apply. Both approaches deliver value to healthcare integration initiatives.

Healthcare integration plays a critical role in streamlining billing workflow. As highlighted in an earlier post, the HL7 Standard and HL7 messaging facilitates a more effective data flow.

Healthcare billing departments are dependent on getting accurate information in a timely manner to meet their goals, such as increasing cash flow and decreasing operational costs. Getting the needed patient information and charge capture data can be accomplished using HL7 interfaces.

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

• 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
• Increase efficiency

As a result, your operations will be more competitive, profitable, and streamlined. To learn more, read another blog post on how to streamline your billing workflow.

Every healthcare environment bills for services provided. The goal of billing is to increase reimbursement in a timely fashion. How does the HL7 Standard help in this endeavor? Automating clinical data delivery through HL7 interfaces provides accurate information quickly to the billing department.

When transferring patient’s billing information through HL7 messaging, it is helpful to know some of the key segments in which to find the data.

PID: Patient Information
PV1: Visit Information (DOS)
FT1: Financial Transaction
IN1: Insurance Information
IN2: Additional Insurance Information
IN3: Additional Insurance Info, Certification
GT1: Guarantor
AUT: Authorization Information

A better understanding of the HL7 messages used in various billing environments may help demonstrate the possible automation and healthcare integration capabilities.

1) In acute care hospitals, the billing department is typically in-house. As a patient is treated, the clinical data is transferred to the appropriate departments throughout the hospital, including billing. The main HL7 messages transferred to billing are:

ADT = Patient demographics
DFT = Detailed financial transaction
ORU = Observation result unsolicited

Below is an example DFT message that shows the addition of a test, Lipid Panel, to a patient’s bill:

MSH|^~\&|FrapLab|StJohn|HIS|StJohn|20071217094822||DFT^P03|MSGIDv|P|2.3
PID||3|82828||Simpson^Margaret^^^Mrs.||19650525|F|||12 Maple St.^^Springfield^OH^21003^USA
PV1|4||^22^1||||2360^England^Mikey|||IP|||||||||4|||||||||||||||||||||||||20071217094755|20071217094813
FT1|1|6|4|20071217094821||Credit|303756^Lipid Panel^L|||2|115

2) For reference laboratories or independent commercial labs, the billing department handles two types of billing: client and patient. Client billing is where the lab bills the services back to its client, the doctor’s office, clinic, etc. Patient billing involves third party billing based on patient coverage or direct bills to the patient. If the lab receives orders electronically via an HL7 interface, then the order message (ORM) may contain the needed billing information. Below is an example order for a serum Vitamin C test for a patient with a primary insurance carrier being Medicare:

MSH|^~\&|SNDAPP|SNDFAC|RCVAPP|RCVFAC|200710021226||ORM^O01|DCGTORD.2.79
|P|2.4|
PID|1|89300043|||MOUSE^MICKEY||19600505|M||||||||||1259801|999-00-888|||
IN1|1|UNK.|MR1|MEDICARE/COMMERICAL|P.O. BOX C32086^^RICHMOND^VA^23261||-0000000000|499032980||||00001231|00001231||MC|O
DONNELL^RICHARD^W^^|1|-19221027|7982 WELLINGTON DR^^WARRENTON^VA^22186^USA||||||||||||N||||-|499032980-A|||||||M||
GT1||ODONNELL,RICHARD w||7982 WELLINGTON DR^WARRENTON^VA^22186|-7033492732|||
ORC|NW|L2435^LAB|^LAB||||1^^^^^R|||||23462^ALVAN^^^||
OBR|1|L2435^LAB|010700^VITAMIN C (ASCORBIC ACID), SERUM^L||||20071002122600||||N||SICK|||23462^ALVAN^^^||||REQ#5468|||||||1^^^^^R|

3) Finally, an independent imaging center takes on the task of billing the technical and professional components of its services. The professional reads they do for hospitals or referring physicians require the patient’s billing information and the final reports for coding. The patient information can be sent via paper (e.g., faxing), sent electronically through an HL7 interface (ADT, BAR, or DFT messages), or sent via a file batch with a proprietary format. The reports used for coding can be transmitted using HL7 ORU messages.

An example BAR message that creates a new account with needed billing information follows:

MSH|^~\&|BRACK|CHA|FIN|5|040112043835||BAR^P01|0000000001|T|2.3|
PID|||3000222452||JONES^SAM^A||19931114|M||||||||||1546740|666381774|
PV1||I|BRACKENRIDGE|||||023434|||||||||023434|||||||||||||||||||||||||||20031121||
GT1|0||JONES^ANN^M||756 E FANNIN ST^^LAGRANGE^TX^789450000|9799660489|||||M|||||CARE INN|457 NMAIN^^LAGRANGE^TX^78945|
IN1|1|T71|||MEDICAID

For additional information, watch a 15-minute web seminar on the role HL7 messages play in different healthcare billing environments.

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.

In healthcare IT, there are varying standards. One standard is LOINC® - Logical Observation Identifiers Names and Codes.

LOINC facilitates the exchange of results data by providing a universal standard for identifying laboratory observations. The LOINC database and its supporting documentation are maintained by the Regenstrief Institute, Inc.

Why was LOINC established and what are the benefits?

LOINC was initiated in 1994 by the Regenstrief Institute to identify observations in HL7 messages (OBX segment). Prior to its establishment, no universal standard for laboratory test names existed. Therefore, laboratories would send varying values in the OBX-3 (observation identifier) and OBX-5 (observation value) segments. When working with multiple laboratories that used different codes for different test observations, a lack of standardization hindered the development of clinical repositories and research databases.

LOINC provides a standard way of identifying observations using approximately 41,000 observation terms. Nearly 31,000 of these terms are used for laboratory testing. LOINC codes allow you to merge clinical results from multiple sources into a single database, allowing results to be automatically sent to the appropriate place and improving patient care and clinical research.

Who uses LOINC?

LOINC is endorsed by the American Clinical Laboratory Association and the College of American Pathologists. It has been adopted by some large commercial laboratories for use in HL7 result messages and is used by some US federal agencies with healthcare interests. While initially created specifically for HL7 messaging, its use has expanded to Digital Imaging and Communication in Medicine (DICOM) ultrasound messages and Clinical Data Interchange Standards Consortium (CDISC) pharmaceutical industry messages.

Where can I get a copy?

The LOINC database and REMLA - a program for browsing the database, and mapping local files to LOINC - are available at no cost from the Regenstrief Institute. It can be downloaded here. More information about LOINC is available from the Regenstrief Institute.

Final thoughts on LOINC.

• In general, LOINC is a work-in-progress rather than a final standard.
• There is no US government mandate to move labs to LOINC. Movement will be gradual.
• ELINCS uses LOINC for the top 100 tests, not the results. More information on ELINCS can be found in a previous post.

It is possible to send a PDF file inside of an HL7 message. However, it is not a simple “encode and send” process as there are many moving pieces that allow a document file to be moved across an HL7 interface. The key question is not what the HL7 standard says about document encoding or even what the interface engine can do with the document. Rather, the focus should be on how the PDF file will be delivered to and from the source and destination application and how the target application will display the document.

The options to move a PDF document include sharing the PDF via a file system (network shared drive), sending the file via HL7 as an ED (encapsulated data) data type, or including a URL to the PDF file via an RP (reference pointer) datatype. The complexity of each solution varies wildly based on the vendors involved.

To begin, start with the answer to this question: How will the source application provide the PDF file and how will the destination application(s) receive the data?

The second question to answer: Once the document is received by the target application, how will that receiving application file it correctly into the patient chart? For example, if you send two PDF files (one pathology report and one ED summary), how will the receiving application know onto which tab of the patient chart the document should flow? Specifically, as a user, I’d hope the path report would appear somewhere on the “lab results” tab. I’d also hope the date of the report would appear next to the paper clip (or whatever) icon to tell me a “scanned report” was available. These questions about how and where the document will appear are much more challenging than, “How do I encode a PDF file in HL7?”

The actual encoding of the document is often done via either an ED or RP datatype inside of an ORU message. Review these prior blog postings for details:

• How Do I Send a Binary File Inside of an HL7 Message?
• Sending Images or Formatted Documents via HL7 Messaging
• HL7 OBX Segment

As you read this, do you know the status of every clinical interface in your environment? Unfortunately, a common answer to this question may be, “I have not received a call from anybody, so everything must be fine.” 

What needs to be monitored in HL7 messaging? Some examples include:

• Guaranteed message delivery
  • ACK vs NACK
  • No response
• Connection status
  • Started
  • Connected
  • Messages moving
  • Messages backlogged
• Errors in message processing
  • Invalid HL7 structure
  • Invalid message data
  • Database interaction issues
• Machine issues (e.g., hard drive space)

The question remains:  Do you know the status of every clinical interface in your environment? What if you could answer this question confidently and say, “Yes, I know my interfaces are all running without an issue?” How can you get to this level of confidence in your healthcare integration environment?

To get to this level of confidence, you will need interfaces that are capable of monitoring themselves. When unexpected events occur, the interfaces need to be able to recognize these events and alert the IT staff that there is a problem, and it needs immediate attention. With this level of alerting, often times HL7 messaging and communication problems can be diagnosed and resolved before the clinical staff knows they even existed. 

In today’s fast paced world, doctors need to have access to information as soon as it’s available. If the interface between two clinical applications is down, the delivery of critical patient information cannot be completed.

You don’t have to be around interfacing long to talk to somebody who has a horror story about an interface that went down, but nobody knew it was down for hours or even days. This is a common problem that many healthcare providers are facing today. These types of problems are occurring in a very controlled environment, on a local network, within the walls of a single organization.

As healthcare evolves and the communication and sharing of information continues to expand beyond the four walls of a provider organization (e.g., to a regional or  nationwide sharing environment), the importance of self monitoring interfaces and pro-active alerting becomes increasingly important.