The difficulties in mapping HL7V2.x to HL7V3.0 does not make a solution based on transformation and translation easy to implement. The difficulties encounter by initial adopters is making the total adoption of HL7V3.0 very difficult. Version 3 was created as a replacement for Version 2.x, but it is observed that the two versions are catering to distinct markets. However the impending success of major projects like UK-CFH is going to make HL7V3.0 a major standard and replace HL7V2.x in the longer run. It is a well known fact that big bang change of standards in applications deployed in clinical settings is a recipe for major disaster so proposal for a transition path to independent “V3-ready” implementations and “V3-ready” implementations of Version 2.x is required. The following approaches are proposals for an HL7V3.0 ready implementation.
New HL7 V3 domains: Most of the domains which exist in HL7V2.x have equivalence in HL7V3.0 for e.g. ADT in V2.x has equivalent domain called Patient Administration in V3.0, Scheduling exists in both HL7V2.x and HL7V3.0. However the limitations of HL7V2.X did not cater for advances in clinical areas like Clinical Genomics and Clinical trials but the specifications in these areas are well defined in HL7V3.0. It is recommended that organizations start implementing these new domains in their applications using HL7V3.0 and support the existing HL7V2.x messages in other domains before phasing them out as HL7V3.0 standards in those domains mature.
Z- Segment and Z- Fields: Most of the existing clinical settings in different countries have implemented and deployed HL7V2.x specifications in their applications. The ease of implementing HL7V3.0 in these applications depends on the architectural framework and openness to extension. For legacy application which has a V2.x interface and implementing V3.0 in these applications is a cost intensive then it is recommended to use Z-segments and Z-Fields and wrap multiple messages in a single message so that the content needed to populate a v3 message can be obtained. This approach may mitigate some of the mapping and transformation issues defined in the above section.
RIM based Data Model: It should be possible to modify the physical data model of the clinical applications to follow the HL7 model. This means maintaining a relationship between the HL7V3.0 RIM based data model and physical database model. The success of this approach depends on how closely the physical data model matches the RIM logical data model (e.g. D-MIM, R-MIM). This will enable the mapping of HL V3.0 message attributes with the required table attributes in the database.
HL7V3 Conformance for V2.x Implementation: The version 3.0 approaches of use cases, story boards, interaction models and vocabulary can be used in Version 2.x implementations so that the message profiles developed for Version 2 can be mapped onto Version 3 at some point in the future. The development of message profiles as a means to guide a new HL7V2.x implementation or modify an existing HL7V2.x implementation is consistent with HL7V3.0 development methodology. This will allow us to focus on non-data aspects of HL7V3.0 i.e. defining the interactions in an implementation and the application behavior associated with this implementation. The focus shift will enable us to concentrate on HL7V3.0 messages data structure as the need for changes to application functionality is reduced.
New HL7 V3 domains: Most of the domains which exist in HL7V2.x have equivalence in HL7V3.0 for e.g. ADT in V2.x has equivalent domain called Patient Administration in V3.0, Scheduling exists in both HL7V2.x and HL7V3.0. However the limitations of HL7V2.X did not cater for advances in clinical areas like Clinical Genomics and Clinical trials but the specifications in these areas are well defined in HL7V3.0. It is recommended that organizations start implementing these new domains in their applications using HL7V3.0 and support the existing HL7V2.x messages in other domains before phasing them out as HL7V3.0 standards in those domains mature.
Z- Segment and Z- Fields: Most of the existing clinical settings in different countries have implemented and deployed HL7V2.x specifications in their applications. The ease of implementing HL7V3.0 in these applications depends on the architectural framework and openness to extension. For legacy application which has a V2.x interface and implementing V3.0 in these applications is a cost intensive then it is recommended to use Z-segments and Z-Fields and wrap multiple messages in a single message so that the content needed to populate a v3 message can be obtained. This approach may mitigate some of the mapping and transformation issues defined in the above section.
RIM based Data Model: It should be possible to modify the physical data model of the clinical applications to follow the HL7 model. This means maintaining a relationship between the HL7V3.0 RIM based data model and physical database model. The success of this approach depends on how closely the physical data model matches the RIM logical data model (e.g. D-MIM, R-MIM). This will enable the mapping of HL V3.0 message attributes with the required table attributes in the database.
HL7V3 Conformance for V2.x Implementation: The version 3.0 approaches of use cases, story boards, interaction models and vocabulary can be used in Version 2.x implementations so that the message profiles developed for Version 2 can be mapped onto Version 3 at some point in the future. The development of message profiles as a means to guide a new HL7V2.x implementation or modify an existing HL7V2.x implementation is consistent with HL7V3.0 development methodology. This will allow us to focus on non-data aspects of HL7V3.0 i.e. defining the interactions in an implementation and the application behavior associated with this implementation. The focus shift will enable us to concentrate on HL7V3.0 messages data structure as the need for changes to application functionality is reduced.
CDA Implementation: An alternative strategy is to use CDA (Clinical Document Architecture). The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange. CDA documents are encoded in XML and derive their machine processable meaning from the HL7 Reference Information Model (RIM) and use the HL7 Version 3 Data Types. The factor that makes it easy to move to CDA is that this specification defines a multi level architecture where each level is derived from a more basic level. The levels refer to varying degrees of required markup granularity and specificity and not the depth or granularity of the content. Figure below shows the definition of different CDA Levels
Figure: CDA Levels
CDA Levels provide iteratively adding greater markup to clinical documents apart from establishing baselines for conformance. As Level one includes only header includes and semantics in level one body is easy initially to implement this and have a defined phased approach to other levels.
