Skip to main content

HL7 V3 Ready

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.


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.
Labels:

Comments

Post a Comment

Popular Posts

Create Your Own Social Networking Site

Create Your Own Social Networking Site JCOW: Ethical Hacking Top 10 reasons to choose Jcow:- 1. Handle more traffic - Clean codes and Dynamic caching can lower the CPU load and  speed up your website. 2 Make your site more interactive - Well designed Jcow applications help you members to connect and communicate with others more effectively. 3 Add questions to the Registration Form - You can add new member fields, which will be displayed to the registration form, profile form, and the member browsing form. 4 Easily share stuff - Within the AJAX sharing Box, your members can publish status,  photos, videos, and blogs. 5 Customize and Extend your Jcow Network - A Jcow network consists of core apps(like "Friends" and "Messages") and optional apps(like "Blogs" and ""Videos"). You can enable/disable optional apps. You can also develop your own apps. 6 Every profile could be Unique - Members can customize their own profile theme and  add music play...
Post a Comment
Read more

The Problem of Abstraction in Definitions of Data Objects

I think there is a major problem in not being able to understand and work with different levels of abstraction.  By "abstraction" in this sense I mean one concept system that somehow describes or defines (not merely relates to) another concept system.  I think this is a big problem for definitions in data models. Let us take an example in a retail business such as mortgage banking: Customer Name.  Customer Name exists in the business.  They use it all the time.  Maybe it is sometimes called Borrower Name, but the concept is the same.  This is the Level 1 abstraction. Now let us think of data values in a column in a table that holds Customer Name.  These data values are stored as a code of 1's and 0's.  Of course these bits are rendered into something we can read.  However, this is not the same as the Customer Name in the business.  I worked for a place where they prefixed the name of anyone who had recently left with "ZZZ"....
Post a Comment
Read more

The Humpty-Dumpty Principle in Definitions

In dealing with empty concepts, we came across the issue that if somebody uses a term that potentially has an unintelligible definition, they are likely to defend themselves by quickly making up some kind of definition.   I strongly suspect that in such cases, the usage of the term will be inconsistent with the definition.  Which brings us to Humpty-Dumpty. Lewis Carroll (Rev. Charles Lutwidge Dodgson) is best known for his children's' books Alice's Adventures in Wonderland and Through the Looking Glass .  It is in the latter that Humpty Dumpty - an argumentative egg perched on a wall has the following exchange with Alice: 'And only one for birthday presents, you know. There's glory for you!' `I don't know what you mean by "glory",' Alice said. Humpty Dumpty smiled contemptuously. `Of course you don't -- till I tell you. I meant "there's a nice knock-down argument for you!"' `But "glory" doesn't mean "...
Post a Comment
Read more