NeoTool — Singular Focus, Healthcare Integrated

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.

HL7 terms to better understand what is HL7. In the HL7 standard, the message type, RDE (Pharmacy/Treatment Encoded Order Message), is used by clinical applications to send an order to the pharmacy and/or dispensing systems. It may be sent as either an order containing a single pharmacy/treatment order for a patient or as an order containing multiple pharmacy/treatment orders for a patient (e.g., 1 mg tablet of Aspirin, 0.5 mg 0.5% Albuterol). 

The transmission of orders occurs between the clinical application placing the order (the placer) and the clinical application filling the order (the filler). Typically, the clinician (e.g., physician) is entering orders on the HIS application which acts as the placer application in HL7 parlance. The system to which the order is targeted (e.g., the lab in the case of a complete blood count order) is the filler of the order.

HL7 terms to better understand what is HL7. The Producer’s ID in HL7 v2.x is a specific field of the OBX segment. This field (OBX-15) contains a unique identifier of the responsible producing service provider.

In the HL7 standard, there are messages used to communicate orders and results for procedures like lab tests, x-rays, etc. The clinical laboratory is a producer of lab test results and the radiology department is the producer of an imaging diagnostic report. 

Typically, when the Producer’s ID field is null, the receiving system assumes that the observations were produced by the sending organization. The Producer’s ID should be reported explicitly when the test results are produced at outside laboratories. This information supports CLIA (Clinical Laboratory Improvement Amendments) regulations in the US. In the US, the Medicare number of the producing service is suggested as the identifier.

In HL7 messaging, the exact field contents can be negotiated based on interface specifications between the sending and receiving systems. 

An example OBX segment follows where the Producer’s ID (45D0505003) is reported in OBX-15-1:

OBX|1|NM|1001^WBC|1|3.3|K/CUMM|5.5 - 15.5|L|||F|||200510021302|45D0505003||

HL7 terms to better understand what is HL7. In HL7 v2.x, the OBX is a segment used to transmit a single observation or observation fragment. It represents the smallest indivisible unit of a report. The principal mission of an OBX is to carry information about observations and results in HL7 standard report messages (i.e., ORU or MDM). 

Sometimes, the OBX segment is found as a part of an order message (ORM or RDE). In this case, the OBX carries clinical information needed by the receiving system. For example, an OBX is needed to report the menstrual phase information which should be included on an order for a pap smear to a cytology lab.

The OBX segment can be used to contain encapsulated data, e.g., a CDA document or a DICOM image or any of the MIME (Multimedia Internet Mail Extension) support formats such as JPEG, GIF, and FAX.

If the actual observation value is not sent in an OBX but exists somewhere else, the OBX segment can contain a reference pointer. The reference pointer can be a hyperlink which the receiving system would use to access the observation information, document or image.

Essentially, the OBX segment is used to transmit patient clinical information in a variety of formats.

HL7 typically involves moving message data between two or more software applications within a clinical setting. Without a standard way of defining the types of data that can be sent, messaging is very difficult. Therefore, HL7 outlines the data model and workflows that are broadly supported.

What is HL7? Radiology Today published a good article that provides an HL7 tutorial. In addition, on this web site, you can read a 14-page white paper that outlines HL7 standards version 2 and HL7 version 3 — including a background and tutorial on HL7.

You may have read about how the HL7standard relates to various healthcare IT initiatives like ELINCS, CCR, and HL7 CDA. You may also be aware of the sea-tide change among clinics and their EMR systems as they now are actively building integration solutions to exchange clinical information between various healthcare providers (e.g., hospitals, imaging centers, labs, etc.).

At the core, the HL7 standard plays a prominent role in legacy interfaces between HIS, RIS, and LIS systems in healthcare facilities. However, have you considered who actually ‘uses’ HL7 in their day-to-day operations to support all these interfaces?

While the medical staff in a healthcare facility benefit from the exchange of patient data between applications, medical staff do not directly use HL7. HL7 is supporting the work of the front-line patient care specialists.

HL7 users are typically:

• Clinical application analysts
• Integration specialists
• Application programmers
• Systems analysts

These HL7 users are typically involved in:

• Writing the interfaces for a vendor or healthcare facility
• Writing import/export programs that interpret the data in HL7 messages before updating application databases
• Reviewing and analyzing HL7 messages for accuracy and quality
• Drafting and/or evaluating HL7 specifications
• Analyzing and reporting on HL7 log files
• Building and monitoring HL7 interfaces between clinical applications using an interface engine product

As the drumbeat continues to grow louder for the connected healthcare community, the HL7 users are the unsung heroes working to integrate and interface all the various providers and their applications together. These users may be behind the scenes, but they are making the connections happen. 

For more insight on what is HL7 and the evolution of the HL7 standard and its user community, a recent article entitled HL7 101: A Beginner’s Guide is a beneficial summary.

For The Record, a leading magazine for Healthcare Information Management professionals, published an article entitled HL7 101:  A Beginners Guide, essentially a “What is HL7″ article. It is written by one of NeoTool’s healthcare interface experts, Dave Shaver. Dave is NeoTool’s founder and CTO and is an active member in the HL7 community.

Healthcare integration is a necessity to meet the demands of EMRs, EHRs, RHIOs, and other connected healthcare initiatives. The HL7 Standard plays a key role in these clinical data exchanges. If you are looking for an overview article on HL7 and the standard’s direction, this is a good foundation article. 

If you would like to read more details on HL7, including comparisons on HL7 Version 2 and HL7 Version 3, Dave also wrote a white paper entitled The HL7 Evolution.

The Health Language Seven (HL7) organization is an ANSI accredited Standards Developing Organization. Volunteers from around the world gather in quarterly meetings to produce and refine documentation that describes how clinical information will be shared between disparate healthcare applications in a provider setting.

What is HL7? Practically speaking, HL7 is the standard to which healthcare application vendors adhere when developing application interfaces to exchange patient data. The HL7 standard defines a method of moving clinical data between independent medical applications in near real time.

One would expect that by adopting the HL7 standard interfacing applications would be a ‘plug and play’ exercise. In reality, the commercial vendors of healthcare applications bend and customize HL7 to meet the needs of the customer and their systems. This is necessary to accurately exchange patient data.

Chapter 1 of the HL7 standard Version 2.3 states that “HL7 provides a common framework for implementing interfaces between disparate vendors”. The standard is intentionally flexible; designed to allow customization but inhibits ‘plug and play’ implementations.

In summary, HL7 Version 2 messaging is the acknowledged healthcare industry standard, and the best protocol available to date for exchanging clinical data among disparate cooperating systems in a healthcare setting.

HL7 terms to better understand what is HL7. Scheduling Information Unsolicited (SIU) messages are used to communicate information about a patient’s appointment from the hospital scheduling system to a physician or clinic’s practice management system. SIU messages are a part of the HL7 Standard.

The SIU messages are generated by the hospital scheduling system and let a physician know that outpatient services are being requested. It is important for the patient’s medical record to be updated to contain appointment information.

An SIU message can contain the following information:

• Notification of new appointment booking
• Notification of appointment rescheduling
• Notification of cancellation
• Notification of addition, modification, cancellation, discontinuation, or deletion of service or resource on appointment

1. Decide if the HL7 standard Version 3 has true value in your environment. What do you expect V3 to do that existing V2 interfaces are not already doing?
2. Discuss interfacing strategy with your vendors. If you are moving towards HL7 V3, review existing vendors’ development plans to add V3 or pick new vendors with V3 interfaces.
3. Demand HL7 V3 from vendors only when there is a solid business or clinical motivation because the costs to have V3 in your environment will be high.
4. Expect that mapping between the HL7 standards (i.e., HL7 V2 and V3) will be challenging and expensive. Interface engines must be augmented with substantial data repository functionality in order to provide any mapping.
5. Weigh costs of continuing to build “80 percent standard” HL7 V2 interfaces against entering the expensive world of V3.
6. Understand how early your site will be in the HL7 V3 learning curve - ask any vendor who proposed a V3 interface how many other sites have the same V3 interface running and how many different applications are communicating using the interface.
7. Consider if your site should become an early adopter of the HL7 V3 standard – how much local interface expertise do you have? What is the backlog of interfaces? How will V3 help solve your business requirements short and long term?
8. Gain education on what is HL7 and how HL7 Version 3 fits in; start to understand the impact it will have on your interfacing environment.
9. Become involved in the HL7 standards organization – this will keep you up-to-date on the most recent developments and allow you to be part of the process.

Learn more details about the HL7 standard with the white paper entitled The Evolution of HL7.