In my last post i mentioned that i will publish the detailed information of the translation issues in a white paper. I wanted to use the white paper as a medium to let the wider auidence know of the issues which i thought were deterrent for undertaking the strategy of HL7V2-V3 translation. However the profile of visitors to the blog did convince me that publishing the information here will receive wider publicity. In the first of posts i will discuss the issues with data types.
Semantics: The attributes/data fields in both HL7 v2.x and HL73.0 are associated with a specific HL7 data types. In both the versions data types are basic building blocks of information exchanged in the messages. In V2.x data types are just another level of nesting and the different data types are just considered “formats” of character strings that would appear in HL7 data fields. In V3 the data types define clearly the semantics of data values that can be assigned to a data element. All the data types that exist in Version 2.X do not exist in Version 3 and this complicates the mapping. A few data types like composite types, such as CN (CN - composite ID number and name), contain multiple concepts, and are now represented more explicitly in the information model as either attributes or classes. Some data types like NM (Numeric) in V2.x are expanded in V3 into multiple data types like Integer Number (INT) and Real or Decimal Number (REAL). Other types, such as ID, IS, and CE, received more rigorous definition and an automatic 1:1 mapping is often not possible.
Context: Most of the mapping issues are context driven, for example observations that reside in ‘allergies and adverse reactions’ class of HL7V3.0 contain observations and no clear guidance is available if these need to mapped to general observations in OBX or to AL1 segment in HL7 v2.x. Some other issues are with the message content, for example there is a mismatch between V2.x and V3.0 in terms of Laboratory orders as all V3 Lab Messages are specimen centric i.e. one specimen , several tests and results . V2.5 is specimen centric and match V3 structure but V2.2 to V2.4 which most lab systems in Europe use does not contain any specimen information. The confusion in V2.x on data types like Composite Quantity with Unit" (CQ) which existed in all versions of HL7 v2.x had contradicted with measurement observations (OBX) where numerical result (value type NM) and the units are sent in separate OBX field. In HL7V3 there is only data type Physical Quantity (PQ) with attributes ‘value’ and ‘unit’.
Time: There are some clearly documented and known issues with time data types between V2 and V3.The TQ (Timing Quantity) data type which describes when a service should be performed and how frequently have potentially three V3 data types that can be mapped onto PIVL – Periodic Interval of Time, EIVL – Event-Related Periodic Interval of Time and GTS – General Timing Specification. Both the data types are complex and have multiple representational approaches and no specific level mappings are currently available. The TQ data type has been deprecated from HL7V2.5.
Another issues with the time data types is that the v3 data type Interval IVL
Information Loss:There are some imperfect mappings where information loss can be caused when external vocabularies are used in HL7. For example in HL7V2.X the Observation identifier (CE) carries the name of the coding system as a string and in v3.x the coding system is indicated by an OID (Object Identifier) which are globally unique. However in general the OID in HL7V3.0 in general is mapped to HD (Hierarchical descriptor) and EI (Entity identifier) HL7V2.x data types and generally used for facilities, applications, organizations, providers, patients, etc.
No comments:
Post a Comment