Archive for the ‘HL7 Terms’ Category

CDA stands for Clinical Document Architecture, and it is under the HL7 umbrella of healthcare standards.

What is HL7 CDA? It is a healthcare standard which uses XML for encoding of documents and breaks down the document in generic, unnamed, and non-templated sections. Documents can include discharge summaries, progress notes, history and physical reports, prior lab results, etc. HL7’s CDA defines a very generic structure for delivering “any document” between systems. CDA was previously known as the Patient Record Architecture (PRA).

CDA is complex, and HL7 is now working on ways to simplify it. The simplification project is called Green CDA.

According to Keith W. Boone, “Green CDA isn’t a solution that’s just around the corner.  Gestation of a new standard isn’t sped up by setting unrealistic goals…” Read his blog post called Birthing of a New Standard to gain more insight on the research underway to simplify CDA.

Even though Green CDA sounds distant in being achieved, the initial comments are positive. In the Life as a Healthcare CIO blog, John D. Halamka MD describes Green CDA in a recent post entitled Introducing the Green CDA: “It’s a streamlined, human readable and computable lighter version of CDA that includes just the data and metadata necessary to do the job of representing a clinical summary….  When I first saw the Green CDA XML, I was so impressed that I asked the question – why not use Green CDA as CDA…”

Green CDA will be an interesting project to watch and understand, and it definitely seems to be headed in the right direction. Simplified approaches to working with CDA will facilitate greater adoption of the standard and also the realization of real connected and interoperable health care.

In a recent seminar on Meaningful Use, reference was made to HL7 QRDA or, better known as, HL7 Quality Reporting Document Architecture. HL7 QRDA was new to me, so I went on a search to learn more and thought it would be good to share some key information.

First, a definition of HL7 QRDA is required. From the HL7 Wiki on this topic, it is defined as:

“…a standard for communicating health care quality measurement information. The standard will conform to the requirements of the Health Level Seven (HL7) Clinical Document Architecture Release 2.0 (CDA) and will reuse the templates developed for the ASTM/HL7 Continuity of Care Document (CCD) and other CDA implementation guides. The project started in 2007 with a private collaboration supported by the Alliance for Pediatric Quality (Alliance) – a joint effort of the American Academy of Pediatrics, The American Board of Pediatrics, Child Health Corporation of America, and the National Association of Children’s Hospitals and Related Institutions.”

Key points are that this is still a developing standard, and it is using HL7 CDA.

Second, although there are many organizations involved in drafting this healthcare standard, three organizations involved – which are not on the HL7 wiki list mentioned above – include the  American Health Information Management Association (AHIMA), the Health Information Technology Standards Panel (HITSP), and Integrating the Healthcare Enterprise (IHE).

Two key resources to review:

1. HITSP:  HITSP Patient Level Quality Data Document Using HL7 QRDA Component
2. AHIMA:  A Standard for Quality Reporting

What does this all mean? Although the picture is incomplete, HL7 QRDA may play a role in quality reporting requirements for HITECH & Meaningful Use. From John Halamka’s blog post entitled The Interim Final Rule on Standards (i.e., Meaningful Use proposed rules), point 5 is the important one on this topic:

“The adopted content standard for quality reporting is the CMS PQRI 2008 Registry XML Specification, (note that this means it was suggested by the HIT Standards Committee and not by HITSP, it’s not an SDO product but was produced by CMS). The candidate standards are those to be suggested by the HIT Standards Committee. We debated this at the HIT Standards Committee because QRDA is an emerging standard for quality reporting but not a widely implemented one. This glide path is reasonable, but does require implementers to change course – implementing PQRI XML now and possibly QRDA or other standards later. It will be interesting to follow the comments on this one – maybe PQRI and QRDA should be allowed now to prevent this rework.”

As always, more to come later…

National Quality Forum (NQF) joined with HL7, AHIMA and consulting firm Alschuler Associates to develop a draft standard called Health Quality Measure Format (HQMF).  To read more about HQMF, the following press release was issued by the HL7 organization -
Automating Performance Measurement Using Electronic Health Records (PDF).

The HL7 ballot for HQMF offers the following definition and structure outline:

“…is a standard for representing a health quality measure as an electronic document. A quality measure is a quantitative tool that provides an indication of an individual or organization’s performance in relation to a specified process or outcome via the measurement of an action, process or outcome of clinical care. Quality measures are often derived from clinical guidelines and are designed to determine whether the appropriate care has been provided given a set of clinical criteria and an evidence base. Quality measures are also often referred to as performance measures or quality indicators.

Through standardization of a measure’s structure, metadata, definitions, and logic, the HQMF provides for quality measure consistency and unambiguous interpretation. A health quality measure encoded in the HQMF format is referred to as an “eMeasure”.

Standardization of document structure (e.g. sections), metadata (e.g. author, verifier), and definitions (e.g. “numerator”, “initial patient population”) enables a wide range of measures, currently existing in a variety of formats, to achieve at least a minimal level of consistency and readability, even if not fully machine processable.”

As is the case these days, one of the reasons for HQMF is to support “meaningful use” of electronic health records as described by the American Recovery and Reinvestment Act (ARRA). In the HL7 press release, the following explanation is offered:

“‘This work will make it easier for physicians and other clinicians to monitor and evaluate the care they are providing patients based on data routinely captured during care processes,’ said Floyd Eisenberg, NQF senior vice president of health information technology. ‘This new format standard will enhance the use of nationally-recognized performance measures at the point of care to enable greater transparency for providers and consumers.’”

HL7 is receiving comments on this new format and will make a determination if it ready to become a draft standards by December. Another article which outlines HQMF was recently in Modern Healthcare entitled Quality measure format could change EHR analysis.

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, explore this site and visit the HL7 Resource Center for additional definitions and information. Both are great resources 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