NeoTool — Singular Focus, Healthcare Integrated

1. Remember that HL7 V3’s use of XML is only 5 percent of the value of the HL7 standard.
2. Discuss with your clients (buyers) their needs for HL7 V3. Often users ask for V3 interfaces without an understanding of the scope of the HL7 standard or the costs incurred to implement V3.
3. Review the HL7 Reference Information Model (RIM) and study the explicit data model.
4. Compare the relationships stored in your application database with those modeled in the RIM.
5. If building a new application, use the RIM’s basic concepts and relationships. Early experience shows that you cannot use the exact RIM model as a database schema because performance is too slow.
6. Understand that almost all applications that speak HL7 V3 must also speak V2 - the installed base of V2 interfaces means that typical applications must speak both.
7. Review the application roles in HL7 V3 to see what additional application functionality will be needed to support V3.
8. Educate your users around HL7 V3 and your plans to support the V3 standard or stick only with V2 (so far a common approach.)
9. Understand HL7 standards and start to realize the impact it HL7 V3 will have on your application. Depending on the application, there could be many changes required to adopt V3.
10. Become involved in the HL7 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 what is HL7, including HL7 V3, with the white paper entitled The Evolution of HL7.

The likely answer to this question is: “When the buyers of interfaces demand it, and the dollars are available to make the transition.” In the US, barring a regulatory change, the HL7 standards, V2 and V3, will coexist. In other countries, adoption will likely continue to unfold.

HL7 V3 adoption likely will occur in a slow and methodical fashion. For healthcare professionals, it will be essential to continue to gain education on V3 and get involved in the HL7 Standards Working Groups. Sharing lessons learned, watching trends, and evaluating early implementations will assist in determining the next prudent step for your organization.

Learn more details about what is HL7, including HL7 V3, with the white paper entitled The Evolution of HL7.

Gearing up to learn about HL7 standards

Day one of HL7 training was a crash course in history, usage and basic technical information - essentially, what is HL7. The day started with a nice English style breakfast, but we wasted no time and dove right into the materials. 

My impressions were that the information seemed endless and the learning of it requires assistance.  Someone in the class asked about moving beyond the history of HL7 and into the more technical aspects, but the instructor, Dave Shaver, reiterated that the history of the standard is important for understanding why it exists, what its purpose is, what the limitations are, and what thought process governs the implementation of HL7 systems.

Dave often used less technical analogies to assist in learning and decrease the mental strain of less technical people (such as myself). This technique allowed me to quickly grasp the broad concepts so that I could concentrate on learning the more complicated elements of the technology. I learned that:

• The HL7 standards are defined by the entire healthcare community and is separate from HL7 technology applications
  The standards rely on asking big picture questions about workflow and data model, and how they can be used to interpret the data
• Interfaces can be used as export “boxes”, import “boxes”, or customizable engines in between the two
• Sometimes data flow is a two way process, sometimes only a one way process, but not all data will always be transferred
• There are a number of components of an HL7 message, including unique data types, fields, components and tables, and they are customizable based on the standards

Early on, Dave told us that the goal of the training class was to address attendees’ personal questions and curiosities, while still providing an overview and explanation of HL7 as a whole.  I found that this day of training gave me a good foundation about the basics of HL7, and that it was similarly useful to other people in the class.

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.

HL7 terms to better understand what is HL7. In the HL7 Standard, the Detailed Financial Transactions (DFT) messages describe a financial transaction transmitted between the DSS/Order Filler and the Charge Processor.

The DSS/Order Filler verifies that the procedure has been completed.

The Charge Processor receives patient demographics, account information, etc. for ADT/Patient Registration. The Charge Processor also receives the posted charges and serves as a component of the financial system.

In HL7 messaging, the trigger events for a DFT message include:

• Procedure ordered
• Procedure scheduled
• Procedure completed
• Future will define Report events for professional fees

HL7 terms to better understand what is HL7. In the HL7 Standard, an Observation Result (ORU) is usually in response to an order and provides clinical observations.

In HL7 messaging, ORU messages provide structured patient-oriented clinical data between systems (e.g., EKG results to a physician’s office). ORU messages also can be used for linking orders and results to clinical trials (e.g., new drugs or new devices).

Clinical observations can include:

• Clinical laboratory results
• Imaging studies (i.e., text)
• EKG pulmonary function studies
• Interpretation

HL7 terms to better understand what is HL7. In the HL7 Standard, an order (ORM) is any request for materials (e.g., 500 ml of 2.5% saline) or services (e.g., a range of motion study, an EKG, a lipid panel, etc.).

Orders are usually for a particular patient, but they can also be for a department (e.g., floor stock) or for a non-patient (e.g., an environment study where no specific patient is involved.)

The transmission of clinical orders occurs between the application placing the order (the placer) and the clinical application filling the order (the filler).

Typically, the caregiver (e.g., physician) is entering orders on the HIS application which acts as the placer application in HL7 messaging 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. Patient Administration (ADT) messages are used to exchange the patient state within a healthcare facility. ADT messages keep patient demographic and visit information synchronized across healthcare systems.

ADT is the most commonly used HL7 messaging type, with most clinical applications enabled to receive key ADT messages.

ADT messages within the HL7 standard are typically initiated by the Hospital Information Systems (HIS), or a registration application, to inform ancillary systems that a patient has been admitted, discharged, transferred, merged, that other demographic data about the patient has changed (name, insurance, next of kin, etc.) or that some visit information has changed (patient location, attending doctor, etc.).

HL7 terms to better understand what is HL7. There are four primary HL7 standard message types:

• Patient Administration (ADT)
• Orders (ORMs)
• Results (ORUs)
• Charges (DFTs)