Lessons Learned

Title: HL7 v2.x to v3 Laboratory Message Mapping Subject Terms: Message Mapping, HL7v2, HL7v3, Data Types Keywords: Laboratory Information Systems (LIS), Jurisdictional Laboratory Information Systems (JLIS),

Point of Service Systems (POS).

Lessons Learned Statement: Most jurisdictions are opting to map their HL7v2.x messages (from LIS and POS applications) to the pCLMN v3 specification (in the JLIS). The complexities associated with this mapping should be understood and planned for early in an implementation project. Contributors/Contact Information: Standards Collaborative, External articles regarding translation issues and sample messages in both versions of HL7.

Project Background
0B

The pan-Canadian Laboratory Messaging and Nomenclature (pCLMN) Specification was built using HL7v3 messaging consistent with the Infoway EHRi. The laboratory messaging suite was designed for electronic information flow between LIS and JLIS applications and between POS and JLIS applications. Historically, electronic information flow between LIS and POS applications (and in some cases JLIS as in the OLIS case) has been managed using HL7v2.x messaging and have generally been point-to-point interfaces rather than exchanges to and from a central order or result management system. As a consequence, few LIS and POS software applications have the ability to send and receive native HL7v3 messaging. To circumvent the costs associated with re-coding software applications to enable HL7v3 messaging, most jurisdictions are opting to map their HL7v2.x messages (from LIS and POS applications) to the pCLMN v3 specification (in the JLIS).

Considerations
1B

There is no pan-Canadian standard for Laboratory HL7 v2.x messages. Almost every HL7 v2.x specification is unique because of: a) The wide-spread use of Z segments to add fields not supported by the standard; and b) The misuse or lack of common use of the fields in each of the segments; and c) The use of non-standard code sets; and d) Non-semantic interoperability that is, coded values having different interpretations (e.g. abnormal flags). HL7v3 was designed to overcome these downfalls of HL7v2.x, but the mapping challenge still exists. Mapping of the current HL7 v2.x lab messages to the pCLMN requires the consideration of multiple specifications to be mapped to 1 pan-Canadian specification thus greatly increasing the complexity of the exercise.

HL7 v3 was designed with the following goals in mind: a) Designed to be scalable; and b) Designed using a formal object-oriented methodology; and c) Based on central consistent models; and d) More than messages; and e) Rigorously defined vocabulary bindings; and f) Industry standard technology for implementation and transport XML, SOAP/WDSL.

Along with this shift in design methodology for HL7 messaging comes some translation issues that should be understood and scoped during the early planning stages of an implementation. Some of the most notable ones are as follows 1 :
PF FP

Context o Many mapping issues are context driven. For example, observations that reside in SpecimenObservations class of HL7v3 contain observations that could be mapped from general observations in OBX or from SPM segment in HL7v2.x, so in a bi-directional mapping, decisions need to be made to determine which segment is most appropriate. In HL7v2.x, data that does not have a discrete field is sometimes captured as annotations in the NTE segment or as Observations in the OBX segment. This makes it difficult to create an automated mapping to the discrete attributes in the pCLMN. For example, Specimen Volume is captured as a SpecimenObservation in the pCLMN, but if captured in the NTE segment of an HL7v2.x message as a STRING, it is difficult to determine that this actually maps to a SpecimenObservation without manual intervention. Similarly, microorganism data is often captured as an Observation in HL7v2.x, whereas it is a discrete entity in the pCLMN. Other issues are driven by message structure. For example, in HL7v3 and in HL7v2.5 +, specimen data is captured discretely, whereas in HL7v2.4.x there are no fields to capture this data discretely. Rather, they are captured as Observations. Most existing HL7v2.x interfaces in Canada are HL7v2.4.x -. The use of composite data types can also prove to be problematic for mapping. For example, in HL7v2.x, Composite Quantity with Unit (CQ) contradicted measurement observations in OBX where numerical results (NM) and the units are sent in separate OBX fields. In HL7v3, there is only data type Physical Quantity (PQ) with attributes Value and Unit. PQ.LAB in the case of the pCLMN.

1
P HTU

The core translation issues were taken from http://healthcareinformatics3000feet.blogspot.com/2008/04/hl7v2x-to-hl7v30-translation-issues.html , but the lab examples are specific to the pCLMN.
P UTH

Semantics o The attributes/data type fields in both HL7v2.x and HL7v3 are associated with a specific HL7 data type. In both the versions, data types are basic building blocks of information exchanged in the messages. However, In HL7v2.x, data types are another level of nesting and are considered formats of character strings that would appear in the HL7 data fields. In HL7v3, data types define the semantics of data values that can be assigned to a data element. Not all data types that appear in HL7v2.x exist in v3 and vice versa. This complicates the mapping exercise. Data types like Composite Number (CN composite ID number and name) in HL7v2.x contain multiple concepts which are more explicitly represented in the data model as either attributes or classes in HL7v3. Some data types like Numeric (NM) in HL7v2.x are expanded in HL7v3 into multiple data types like Integer Number (INT.POS or INT.NONNEG in the pCLMN) and Real or Decimal Number (REAL.CONF). Other types, such as ID, IS, and CE, received more rigorous definition and an automatic 1:1 mapping is not often possible.

Time o There are some known issues with the mapping of time data types between HL7v2.x and HL7v3. The HL7v2.x Timing Quantity (TQ) data type which describes when a service should be performed and how frequently have potentially 3 data types in HL7v3 Periodic Interval of Time (PIVL), Event-Related Periodic Interval of Time (EIVL) and General Timing Specification (GTS). In the pCLMN, it is a GTS.BOUNDEDPIVL data type. Both the TQ and the GTS.BOUNDEDPIVL data types are complex and have multiple representational approaches and no specific level mappings are currently available. Other issues with the time data types is that the v3 data type Interval (IVL) containing a single point in time is suggested to map to HL7v2.x data type Time Stamp (TS). This mapping carries a risk of semantic loss as an HL7v3 IVL used in this way states that the event occurred over an interval containing the specific time point, whereas TS states that the event occurred at the specific point in time. Additional Resources: http://www.ringholm.de/docs/04300_en.htm - for sample lab message examples in HL7v2.x and HL7v3. http://gforge.hl7.org/gf/project/v2v3-mapping/frs/ - for sample lab message mappings bidirectionally between HL7v2.x and HL7v3. This also includes some basic data type mappings.
HTU UTH HTU UTH

Other mapping considerations include the following 2 :

PF FP

Operational Practices It is likely that there will be wide variations in data quality throughout the feeding applications (e.g. LIS or POS). It must be determined in the data is to be cleaned prior to the mapping exercise.

2
P P

BC PLIS Project Presentation

Issue Resolution when a loss of information or interpretation is identified during the mapping process and decisions need to be made that may impact clinical interpretation of data, a clinical approval process will likely be required. The effectiveness and timeliness of this process could greatly impact the implementation timeline. Access to Lab Resources working through the interpretation of both the HL7v2.x and HL7v3 data will require timely access to laboratory and messaging subject matter experts. Therefore, access and communication channels should be clearly planned in advance. HL7v2.x to HL7v3 Fit Gap Analysis/Standards Alignment gaps will be found during the mapping process (e.g. missing attritubes or concepts in the pCLMN, pan-Canadian vocabulary extensions codes required for a jurisdiction). A clear, timely process for addressing gaps (e.g. workarounds, wait for SC Delta Releases, etc.) should be clearly documented and agreed to by participating parties (e.g. Infoway SC) during the planning stages of the implementation. Detailed Planning Activities - mapping activities for Data Types, Object Identifiers (OIDs), Code Sets, Laboratory-Specific mapping rules need to be built into the project plan. Conformance Mapping Two levels of conformance need to be considered for mapping: o o Clinical-business workflow, policies and rules. HL7v3 message conformance (e.g. to pan-Canadian Conformance Profiles).

Recommended Actions

Leverage existing mapping resources to gather information regarding activities, timing, know issues, pitfalls, etc. such as:
o o o
HTU

The BC mapping document can be used as a starting point when beginning any HL7v2.x to HL7v3 pCLMN mapping (available on the SCWG 5 forum). http://www.ringholm.de/docs/04300_en.htm - for sample lab message examples in HL7v2.x and HL7v3.
HTU UTH

http://healthcareinformatics3000feet.blogspot.com/2008/04/hl7v2x-to-hl7v30-translationissues.html . For details pertaining to some translation issues.

UTH

o o

http://gforge.hl7.org/gf/project/v2v3-mapping/frs/ - for sample lab message mappings bidirectionally between HL7v2.x and HL7v3. This also includes some basic data type mappings.
HTU UTH

Speak directly with other jurisdictional lab implementation projects (possibly via the Lab Implementers Group) to determine what activities were required for their mapping process (e.g. OID mapping/registration, incorporation of lab-specific business rules, establishing 2 levels of conformance evaluation, etc.).

Standardization of the HL7 v2.x messages can reduce the mapping work for each implementation. This is what the Ontario Lab Information System (OLIS) Project has done. Consider a phased- mapping approach - Some lab practice standardization is a longer term goal. In some cases, existing lab code sets may need to be retained as is, but with a migration plan to standardize to the pan-Canadian code sets going forward.

Establish a general strategy (or broad guidelines) for dealing with bad data or gaps during the planning phase. For example, if it is know that data will be found in HL7v2.x NTE segments that has a discrete field in the pCLMN, agree that in the first phase, this will be mapped to the A_Annotation CMET in HL7v3 and a plan will be put in place to clean the data at the source for future mapping to discrete fields. For other gaps (e.g. content does not exist in the pCLMN), perhaps a workaround or pre-adoption is most practical while working through the formal change process for pan-Canadian specifications. Establish a strategy for change management in conjunction with the Standards Collaborative for issues/gaps that impact the pan-Canadian specifications. Both the Jurisdiction and the SC need to understand and agree upon the expectations for the potential inclusion of changes to the pCLMN and the timeliness in which they could be rolled out. Establish a timely clinical approval process to deal with mapping gaps that may have an impact to clinical interpretation of the data. For example, establish a clinical subject matter expert team that holds weekly teleconferences to make decisions re: clinical appropriateness. Take into consideration the availability of lab and messaging resources when developing the mapping plan.

Prepared By: Infoway Standards Collaborative. Date: October 29, 2009

Note: Infoway disclaims and makes no guarantee or warranty, expressed or implied, as to the accuracy or completeness of any information published herein, and disclaims and makes no warranty that the information in this document will fulfill any of your particular purposes or needs.

October 29, 2009

Prepared by: SC Maintenance Services