Why was HL7 created?
Although HL7 V2 is a market success, it continues to be refined. Many HL7 community members volunteer to enhance HL7 messaging and improve the methods used to define it. Most agree that the primary challenges with HL7 V2 are:
Lack of consistent application data model which is only implied in the HL7 V2 standard ─ The display/storage of data by a clinical application directly impacts what portions of HL7 it can successfully implement.
Lack of formal methodologies to model data elements and messages ─ This causes inconsistencies within the standard and difficulties understanding how message elements relate to each other.
Lack of well-defined application and user roles ─ Without defined roles, which portions of HL7 are supported is a vendor choice causes large variation on which messages are used for a given set of clinical functions when two applications attempt to use the HL7 V2 standard.
Lack of precision in the standard ─ The very vagueness and flexibility that led to “simple adoption” of HL7 V2 causes it to be exactly what it was intended to be: an 80 percent solution.
V3 Goals
In the late 1990s, a subset of the HL7 standards community decided to address these HL7 V2 challenges. The goals in creating the new HL7 V3 standard were:
Internationalization — HL7 V3 needs to be able to be used by the worldwide HL7 organization while supporting the need for local variants.
Consistent data model — HL7 V3 needs to define the data model used by HL7 applications in order to have consistent data available for implementation.
Precise standard — HL7 V3 needs to take the information learned from all the HL7 V2 versions and create a standard that contains all the necessary data and is less vague and therefore less flexible.
New standard — As the community began to define HL7 V3, it decided that V3 would not be compatible with HL7 V2 for a number of reasons. Primarily, if HL7 V3 was backwards compatible with V2, the newer standard would be hamstrung with many legacy issues. Any attempt to retrofit an explicit data or application role model into HL7 V2 would be difficult and the antithesis of the vague V2 world. Finally, the standard needed breathing room so it could radically change in order to improve the quality of clinical interfaces
The early adoption of HL7 V3 has been in the following areas:
Applications without legacy communication requirements – environments where each end of the interface can be tightly controlled and where exchange of data with legacy applications is not required. Examples include the US Centers for Disease Control with state-level reporting for the National Electronic Disease Surveillance System and the US Food and Drug Administration’s clinical trial reporting purposes of electrocardiograms.
New communications environments – those where HL7 V2 was never or rarely used historically – for example, in the Netherlands for physician-to-physician communications.
Although HL7 V2 is a market success, it continues to be refined. Many HL7 community members volunteer to enhance HL7 messaging and improve the methods used to define it. Most agree that the primary challenges with HL7 V2 are:
Lack of consistent application data model which is only implied in the HL7 V2 standard ─ The display/storage of data by a clinical application directly impacts what portions of HL7 it can successfully implement.
Lack of formal methodologies to model data elements and messages ─ This causes inconsistencies within the standard and difficulties understanding how message elements relate to each other.
Lack of well-defined application and user roles ─ Without defined roles, which portions of HL7 are supported is a vendor choice causes large variation on which messages are used for a given set of clinical functions when two applications attempt to use the HL7 V2 standard.
Lack of precision in the standard ─ The very vagueness and flexibility that led to “simple adoption” of HL7 V2 causes it to be exactly what it was intended to be: an 80 percent solution.
V3 Goals
In the late 1990s, a subset of the HL7 standards community decided to address these HL7 V2 challenges. The goals in creating the new HL7 V3 standard were:
Internationalization — HL7 V3 needs to be able to be used by the worldwide HL7 organization while supporting the need for local variants.
Consistent data model — HL7 V3 needs to define the data model used by HL7 applications in order to have consistent data available for implementation.
Precise standard — HL7 V3 needs to take the information learned from all the HL7 V2 versions and create a standard that contains all the necessary data and is less vague and therefore less flexible.
New standard — As the community began to define HL7 V3, it decided that V3 would not be compatible with HL7 V2 for a number of reasons. Primarily, if HL7 V3 was backwards compatible with V2, the newer standard would be hamstrung with many legacy issues. Any attempt to retrofit an explicit data or application role model into HL7 V2 would be difficult and the antithesis of the vague V2 world. Finally, the standard needed breathing room so it could radically change in order to improve the quality of clinical interfaces
The early adoption of HL7 V3 has been in the following areas:
Applications without legacy communication requirements – environments where each end of the interface can be tightly controlled and where exchange of data with legacy applications is not required. Examples include the US Centers for Disease Control with state-level reporting for the National Electronic Disease Surveillance System and the US Food and Drug Administration’s clinical trial reporting purposes of electrocardiograms.
New communications environments – those where HL7 V2 was never or rarely used historically – for example, in the Netherlands for physician-to-physician communications.
0 comments:
Post a Comment