NeoTool — Singular Focus, Healthcare Integrated

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.

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.

On a previous HL7 Messaging Z-Segment post, a reader responded with two questions. Outlined below are the questions about these HL7 terms and my answers.

HL7 Question 1: Can I insert a Z-segment anywhere in the HL7 message or can I only place the Z-segment at the end?

HL7 Answer: You can place the Z-segment anywhere in the HL7 message. There is no rule in HL7 that dictates where a Z-segment should be located in a message. One popular approach is to insert the Z-segment in the message so it is grouped with similar information contained in the message. For example, if you are storing insurance specific data, you may want to create a ZIN segment and place it in the insurance group in your message directly after the IN3 segment.

Another approach is to place any Z-segments at the end of your message, so systems that are configured to parse the ’standard’ HL7 format can read the segments in the order they expect them without making modifications to their configuration. Subsequently, if they need the data in the Z-segment, they can modify their parser to extract the data.

HL7 Question 2: In our customer’s interface specification, if they have not defined a Z-segment yet they send some Z-segments, should I throw an HL7 conformance error or not?

HL7 Answer: You should be prepared to accept that Z-segment in the HL7 message. It’s unfortunately very common to build your processing based on a system’s specifications and then find differences in the format once you receive actual HL7 messages. We have written a white paper on HL7 conformance checking, if you need additional information.

When you are in the testing and development phase of your healthcare integration implementation, you should ensure you can parse the structure that you will be receiving. If you are not interested in the data in the Z-segment, you may not reference it in your processing, but you still need to take into account that the format of the message will include it. If the Z-segment is at the end of the message, then you may not have to account for it since you can parse the complete HL7 message without addressing the Z-segment. How you address this issue will depend on the application you use to parse the HL7 messages.

If there are more questions about working with HL7 Z-segments, please post a reply. We welcome the questions and feedback.

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

In HL7 messaging, there are different HL7 standards from which to choose. HL7 terms like V2 and V3 are often used. Outlined below are the benefits of each of these HL7 standards.

HL7 V2 Benefits:

• Reflects the complex “everyone is special” world of healthcare
• Much less expensive to build HL7 interfaces compared to custom interfaces
• Provides 80 percent of the interface and a framework to negotiate the remaining 20 percent on an interface-by-interface basis
• Historically built in an ad hoc way, allowing the most critical areas to be defined first
• Generally provides compatibility between 2.X versions

HL7 V3

• More of a “true standard” and less of a “framework for negotiation”
• Model-based standard provides consistency across entire standard
• Application roles well defined
• Much less message optionality
• Less expensive to build and maintain mid-to-long term interfaces
• Many decades of effort over ten year period reflecting “best and brightest” thinking

Learn more about the HL7 standards, including HL7 v3, with an in-depth white paper entitled The Evolution of HL7 (long version).

HL7 terms to better understand what is HL7. In the HL7 Standard, ACKs are acknowledgements. When the receiving application accepts and consumes the data within an HL7 message, the receiving application is expected to send an ACK back to the sending application. If the sending application does not receive the ACK, it may continue to send the same message until an ACK is received.

In HL7 messaging, most ACK messages have the same structure as outlined below.

MSH Message Header
MSA Message Acknowledgment
[ERR] Error

HL7 terms to better understand what is HL7. Z segments contain clinical or patient data that the HL7 Standard may not have defined in other areas. Essentially, it is the “catch all” for data that does not fit into the HL7 Standard message definitions. Z segments can be inserted in any message at any time, and Z segments can carry any data you want. In HL7 messaging, all Z segments within it start with the letter “Z”.

Z segments are one of the reasons why the HL7 Standard is sometimes called the flexible standard. The HL7 Standard is a framework for negotiation, and Z segments is an area ripe for negotiation between healthcare vendors and systems.

When using Z segments, it is important to have adequate documentation of what is included.