NeoTool — Singular Focus, Healthcare Integrated

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

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.

While HL7 V3 is still in the “early adopter” phase, there are now over 100 registered projects in progress worldwide involving V3 – the overwhelming majority being outside the United States. Some important points to keep in mind with this HL7 standard still in an early adopter phase:

• Most deployments turn out to be rather custom based on realm-specific changes and that the current V3 standard is used as a starting point for a project – rather than the ending point.
• V3 appears to be morphing even more into a reference model and less of a messaging standard.
• Things are still in a relative state of flux as far as how V3 will be implemented by entities as evidenced with the National Health Service’s shift in the UK from using “V3 messaging” to “V3 CDA” for the Spine.

Keeping the above caveats in mind, it is still a good idea to prepare for V3 by acquainting yourself with some fundamentals.

With V3 being a model-driven standard, a logical starting point for preparation means starting with the information model upon which all V3 standards are based on – the Reference Information Model (RIM). This means that both V3 HL7 messaging standards (e.g., Inpatient Encounter, Ambulatory Encounter, etc.) and V3 Documents standards (e.g., CDA, CCD, etc.) are all based on the RIM.

As a side note, HL7 users in the United States generally think “HL7″ means HL7 2.X messaging standard. Thus, when they think V3, they think about V3 messages replacing the V2 messages. While this is technically possible, market forces are not likely to make the leap to V3 for HL7 messaging anytime soon. If you work for a healthcare provider in the United States, outside of Clinical Document Architecture (CDA), there appears to be little movement towards V3. Some of these topics on the HL7 standards - V2 and V3 - are covered in more depth in a 14-page white paper entitled, The HL7 Evolution (PDF).

With this understanding, we can now get back to V3 and the RIM. With the RIM being an object-oriented methodology implemented via XML, a good starting point to understanding it is to familiarize yourself with the six core classes of the RIM:

1. Act - represents the actions that are executed and must be documented as health care is managed and provided
2. Participation - expresses the context for an act in terms such as who performed it, for whom it was done, where it was done, etc.
3. Entity - represents the physical things and beings that are of interest to, and take part in health care
4. Role - establishes the roles that entities play as they participate in health care acts
5. ActRelationship - represents the binding of one act to another, such as the relationship between an order for an observation and the observation event as it occurs
6. RoleLink - represents relationships between individual roles

With a firm understanding of the above six core classes and their associated attributes (see the latest HL7 Version 3 Normative Edition for details on associated attributes), you should be better prepared to more quickly analyze and implement your first HL7 Standard V3 interface, regardless of whether it is a V3 message or V3 document.

When sending and receiving orders and results using the HL7 standard (HL7 v2.x), there are two identification numbers that are typically required. In HL7 terms, they are the Placer Order Number and the Filler Order Number. These numbers have distinct uses and can be represented in two different places in the Order and Result messages.

The Placer is the person or service that requests or places the order for an observation. Examples of placers include the physician, the practice, clinic, or ward service, that orders a lab test, X-ray, vital signs.

Typically, the order message (ORM) used to request the observation will contain a Placer Order Number in field 2 of the ORC segment (ORC-2) and/or in field 2 of the OBR segment (OBR-2). A requisition number is an example of a Placer Order Number. It uniquely identifies an order among all orders from a particular ordering application.

The ORC-2 Placer Order Number field contains the same information as OBR-2 Placer Order Number field. If the placer order number is not present in the ORC, it must be present in the associated OBR and vice versa. If there is a value in the ORC-2 and OBR-2, they must be the same. Note that in the ORM message, the OBR segment is optional, plus the message may contain multiple orders for which the rules still apply.

The following is an HL7 messaging example of the ORC and OBR segments from an ORM message with the Placer Order Number in ORC-2 and OBR-2:

ORC|NW|2156286|||||||20060221061809|^MOUSE^MINNIE^A^^^RN||TBU^BUTLER JR MD^THOMAS^E^^^|||||CLINIC
OBR|1|2156286||MRSHLR-C^MR Shoulder right wo/contrast|||||||||R/O RCT VS TENDONITIS|||TBU^BUTLER JR     MD^THOMAS^E^^^||…

Filler is synonymous to Producer in ASTM terminology. The Producer is the person, or service, who produces the observations (fills the order) requested by the requestor. Fillers include diagnostic services and clinical services and care providers who report observations about their patients. For example, a clinical laboratory is a producer of lab test results (filler of a lab order), and a nursing service is the producer of vital signs observations (the filler of orders to measure vital signs).
 
In reporting the observations, the Producer sends a Filler Order Number in ORC-3 and/or OBR-3. An accession number is an example of a filler order number that is returned in the observation message (ORU). This string uniquely identifies the order from other orders in a particular filling application.
 
The ORC-3 Filler Order Number field contains the same information as the OBR-3 Filler Order Number field. If the filler order number is not present in the ORC, it must be present in the associated OBR, because the ORC segment is optional in the Order Group of an ORU message.

The following is an HL7 messaging example of the ORC and OBR segments from an ORU message with the Filler Order Number in ORC-3 and OBR-3.

ORC|RE|2156286|A140875||||||20060221061809|^MOUSE^MINNIE^^^^RN||TBU^BUTLER JR     MD^THOMAS^E^^^|||||CLINIC
OBR|1|2156286|A140875|MRSHLR-C^MR Shoulder right wo/contrast|||20060220141000|||||…

Typically, and as the example message segments indicate, the Filler returns the Placer Order Number as well as its Filler Order Number in the ORU message. This allows the Placer to tie the results to the appropriate order.

In HL7 messaging, the separator characters are also known as the message delimiters or special encoding characters. The following are the HL7 recommended values:

     Segment terminator
|              Field separator, aka pipe
^            Component separator, aka hat
&           Sub-component separator
~            Field repeat separator
\             Escape character

The segment separator is not negotiable. It is always a carriage return (ASCII 13 or HEX 0D). The others are suggested values only, but usually used as indicated above. The HL7 standard lets you choose your own as long as you show them in the MSH segment.

The MSH is the first segment of all HL7 messages (except HL7 batch messages). The field separator is presented as the 4th character in the message and it also represents the first field of the MSH segment. Since the first field of the MSH is typically only a pipe,’|', counting MSH fields becomes tricky. Field 2 of the MSH (MSH-2) contains the other separator characters in this order: component, field repeat, escape, and sub-component.

Thus, the following is an example of the beginning of an HL7 message:
MSH|^~\&|…

The delimiter values used in the MSH segment are supposed to be the delimiter values used throughout the entire message. Encoding HL7 messages in this manner allows an application parser to simply use the special characters in the MSH to parse the message. However, beware that many application parsers just use hard coded values and ignore MSH-1 (Field Separator) and MSH-2 (Encoding Characters).

If you’ve been in healthcare integration for any amount of time, you’ve probably seen an HL7 ORU^R01 message. As we like to say at NeoTool, if you’ve seen one HL7 message, you’ve seen one. This is especially true in the case of an ORU^R01 message. The following example illustrates some possible variations to this message.

Scenario: An imaging center (IC) is receiving some order messages (ORM^O01) from 2 external hospitals for which they complete the orders and send back transcribed reports (ORU^R01) in an HL7 standard format. The IC is also completing their own internal orders, and the resulting reports need to be routed to their internal PACS system. Overall, there are 4 separate systems involved. In the world of HL7 messaging, this often means there will be 4 custom formats of the transcribed report.

Original Message from RIS/Dictation System:
Notice that the message is loaded with Z-segments. These Z-segments will most likely need to be stripped out of the message that will be delivered to the other 3 systems. Also, notice that in the OBX segment each line of the transcribed report becomes a separate repetition of the OBX-5 field (separated by the ‘~’ character).

MSH|^~\&|System1||||200707090801||ORU^R01|3542196||2.3
PID|1|000-0000|||”"|1922974|151-76-5760|||||||||||N
ZPI|1|N|N|N|N|N|”"|”"|”"|”"|”"| | | | | |”"|N|0|0|0|0|0|0
PV1|1|2|||||||| ||||||N|| ||
ZVI|1|”"|”"|”"|”"|”"|N|0|0|”"|”"|N|N|N|N|N|”"|”"|”"|”"|”"|0| | | |/NONE/
IN1|1|P|||||
ORC|RE||2060059||||^^^200707061707^^ ||200707051013|DIONA |||”"|||1007
OBR|||2060059|999991^Knee MRI WO| |200707061707|200707061621|200707061707||||”"|”"|||
ZOR|1|1831236|X|1|01|66696|2| |”"|”"|”"|
ZEX|1|2060059|5|G|CC11043257 |R/O MMT|1004959042 CASE # VERIFIED ONLINE DGC|APRV^APPROVED|200707090801||||||||||||0|0|0|0|N|N|N|N|N|”"|”"|”"|”"|”"||EOK
OBX|1|TX|||PROCEDURE: MRI OF THE LEFT KNEE WITHOUT CONTRAST~ ~HISTORY: Left knee pain for three months. Patient experienced a “pop” in her knee when playing tennis.~ ~TECHNIQUE: MRI of the left knee was performed on the 1.5 Tesla magnet operating at ECIC. Images were obtained in multiple planes and with varying pulse sequences. No contrast was utilized.~ ~FINDINGS: Comparison is made with radiographs of 6/22/07. These demonstrate a small joint effusion but otherwise unremarkable. ~ ~There is a very small joint effusion noted. There is also a small popliteal cyst on the posteromedial aspect of the knee.~ ~The anterior cruciate ligament is nearly completely torn with only a very thin strand of the anterior ventral fibers remaining intact. This involves the proximal third of the ligament. The posterior cruciate ligament is intact. The collateral ligaments are intact although the medial collateral ligament demonstrates mild thickening. ~ ~In the lateral compartment there is a mild impaction fracture near the sulcus terminalis of the lateral femoral condyle. There is a mild resolving contusion present on the posterior lip of the lateral tibial plateau. Along the periphery of the posterior horn of the lateral meniscus there is a subtle area of linear increased signal concerning for potential vertical meniscal tear. This would be in the excepted location of the red zone. ~ ~In the medial compartment, the meniscus is intact. No articular cartilage defects are seen. ~ ~In the patellofemoral joint the articular cartilage is intact. ~ ~IMPRESSION:~ ~1. Findings are consistent with a high grade, probably unstable, near complete tear of the anterior cruciate ligament. ~ ~2. Small peripheral vertical tear through the excepted location of the red zone of the posterior horn of the lateral meniscus.~ ~3. Contusions in the lateral femoral condyle with a mild impaction fracture at the sulcus terminalis as well as in the lateral tibial plateau consistent with a pivot shift mechanism of injury. ~ ~4. Small joint effusion and small popliteal cyst. ||||||F

Now, to illustrate how non-standard HL7 can be challenging, take a look at how the following 3 receiving systems are expecting to receive the transcribed report.
1. Internal PACS System
This system does not support the PID,PV1,IN1,ORC or any of the Z-segments. All these segments must be removed to make this message conform to the specifications of the PACS system.

MSH|^~\&|System1||||200707090801||ORU^R01|3542196||2.3
OBR|||2060059|999991^Knee MRI WO| |200707061707|200707061621|200707061707||||”"|”"|||
OBX|1|TX|||PROCEDURE: MRI OF THE LEFT KNEE WITHOUT CONTRAST~ ~HISTORY: Left knee pain for three months. Patient experienced a “pop” in her knee when playing tennis.~ ~TECHNIQUE: MRI of the left knee was performed on the 1.5 Tesla magnet operating at ECIC. Images were obtained in multiple planes and with varying pulse sequences………

2. External Hospital 1
This Hospital Information System (HIS) does not support multiple repetitions of the OBX-5 field for each line of the report. Instead each line of the report must be contained in its own OBX segment. Also, all Z-segments must be removed.

MSH|^~\&|System1||||200707090801||ORU^R01|3542196||2.3
PID|1|000-0000|||”"|1922974|111-22-3333|||||||||||N
PV1|1|2|||||||| ||||||N|| ||
IN1|1|8129||UNITED HEALTHCARE||||700049||P|||||
IN2||151-76-5760|||||||||||||||||||||||||||||||||||||”"|||^^ |||||
GT1|1|1075861|^”"^”"^”"||ALBUQUERQUE^NM^87111|||19711101|F|P|1|
ORC|RE||2060059||||^^^200707061707^^ ||200707051013|DIONA |||”"|||1007
OBR|||2060059|999991^Knee MRI WO| |200707061707|200707061621|200707061707||||”"|”"|||
OBX|1|TX|||PROCEDURE: MRI OF THE LEFT KNEE WITHOUT CONTRAST
OBX|2|TX|||
OBX|3|TX|||HISTORY: Left knee pain for three months. Patient experienced a “pop” in her knee when playing tennis.
OBN|4|TX|||
OBX|5|TX|||TECHNIQUE: MRI of the left knee was performed on the 1.5 Tesla magnet operating at ECIC. Images were obtained in multiple planes and with varying pulse sequences. No contrast was utilized.
OBX|6|TX|||
OBX|7|TX|||FINDINGS: Comparison is made with radiographs of 6/22/07. These demonstrate a small joint effusion but otherwise unremarkable.
OBX|8|TX|||
OBX|9|TX|||There is a very small joint effusion noted. There is also a small popliteal cyst on the posteromedial aspect of the knee
…
…
OBX|32|TX|||Small joint effusion and small popliteal cyst.||||||F

3. External Hospital 2
This HIS has no inbound results interface. Therefore, the reports are delivered to the inbound transcription interface. In this case, the ORU^R01 message must be converted to an MDM^T01 message. Also, they do not want the text of the report to be contained in the body of the HL7 message. Instead, they want the text written out to a formatted RTF file, complete with a report header and saved to a local share on their network. The path to this file needs to be included in TXA-16 (example C:\InterfaceShare\reports\42077460200.rtf). Notice also that the backslash characters (\) in the path need to be properly escaped using the HL7 escape sequence \E\.

MSH|^~\&|System1||||200707090801||MDM^T01|3542196|P|2.3
EVN|T01|200707090801|200707090801
PID|1|000-0000|||”"|1922974|151-76-5760|||||||||||N
PV1|1|2|||||||| ||||||N|| ||
TXA|1|DI|TX|200707191339|1578|200707200812|”"||1578||XI|42077460200||200|| C:\E\InterfaceShare\E\reports\E\42077460200.rtf

The interfacing challenge above was accomplished using an interface engine. The flexibility of the HL7 standard allows an interface engine to receive any format of HL7 and modify the data to be delivered to multiple destinations in the custom format that these systems require. Without this technology, these systems would have to create custom point-to-point interfaces in order to share information.

For more information on working with ORU messages, listen to a 15 minute presentation to learn more.

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.

HL7 terms to better understand what is HL7. In the HL7 standard, Billing Account Record (BAR) messages are used to add or change the patient’s billing account information. Outlined below are the trigger events used to transmit clinical information to the billing accounts.

• BAR^P01:  Establishes a patient’s account in billing (usually sent from a registration system)
• BAR^P02:  Deletes a patient’s billing/accounts receivable records
• BAR^P05:  Updates a patient’s account
• BAR^P06:  Notifies that an account is no longer open (i.e., no new charges can accrue to this account)
• BAR^P10:  Communicates Ambulatory Payment Classification (APC) grouping

For more on the HL7 Standard, request a copy of our HL7 Reference Guide, the most requested resource for healthcare interfacing professionals.

The EHR-Lab Interoperability and Connectivity Specification (ELINCS) specification provides a profile that refines (or constrains) “standard” HL7 messages to moving lab results from reference labs to physician offices. Like IHE, the ELINCS profile constrains the generic HL7 standard to a specific set of use cases. In addition the ELINCS standard provides business rules that must be followed between the trading partners. Such rules are outside the scope of the base HL7 standard.

ELINCS is part of the 2007 CCHIT Ambulatory Interoperability requirements.

Note that sometimes this standard is misspelled as e-links or elinks.

Resources for ELINCS:

• Accelerating EMR Interoperability with ELINCS: Streamlining Lab Connectivity to Physician EMRs
• ELINCS Standard: Laboratory Results to EMRs
• Why the Increasing Demand for Electronic Results to Physicians?
• ELINCS overview and downloadable documents
• ELINCS Specifications
• Direct link to ELINCS 1.1 PDF file

This diagram shows the most common use case for ELINCS:

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).