Difference between revisions of "Product V2 XML"
| Line 5: | Line 5: | ||
===Product Name=== | ===Product Name=== | ||
HL7 Version 2: XML Encoding Syntax, Release 1<br/> | HL7 Version 2: XML Encoding Syntax, Release 1<br/> | ||
| − | Also | + | Also referred to as '''XML Encoding Rules for HL7 V2 Messages''' |
===Topics=== | ===Topics=== | ||
| Line 16: | Line 16: | ||
Normative, ANSI Standard | Normative, ANSI Standard | ||
===Releases=== | ===Releases=== | ||
| − | *ANSI/HL7 V2 XML, | + | *ANSI/HL7 V2 XML-2003 June 4, 2003: HL7 Version 2: XML Encoding Syntax Release 1. |
| + | *:This document is the normative successor of the informative document “HL7 Recommendation: Using XML as a Supplementary Messaging Syntax for HL7 Version 2.3.1 – HL7 XML Special Interest Group, Informative Document” as of February, 2000 [rfINFO]. | ||
===Summary=== | ===Summary=== | ||
HL7 Version 2 XML Encoding Syntax was approved by the American National Standards Institute (ANSI) as an American National Standard in June 2003. This specification, informally known as HL7 V2.xml, defines the Extensible Markup Language (XML) encoding rules for traditional HL7 Version 2 message content. It primarily addresses the expression of HL7 Version 2 messages in XML as an alternative to the traditional “vertical bar” encoding, and describes the underlying rules and principles. XML schema definitions are provided for all Version 2 message types, including the corresponding data type descriptions necessary for this specification. Due to their greater expressiveness, schemas are the preferred way to describe a set of constraints on message instances. Document Type Definitions (DTDs) are also provided as an informative appendix. | HL7 Version 2 XML Encoding Syntax was approved by the American National Standards Institute (ANSI) as an American National Standard in June 2003. This specification, informally known as HL7 V2.xml, defines the Extensible Markup Language (XML) encoding rules for traditional HL7 Version 2 message content. It primarily addresses the expression of HL7 Version 2 messages in XML as an alternative to the traditional “vertical bar” encoding, and describes the underlying rules and principles. XML schema definitions are provided for all Version 2 message types, including the corresponding data type descriptions necessary for this specification. Due to their greater expressiveness, schemas are the preferred way to describe a set of constraints on message instances. Document Type Definitions (DTDs) are also provided as an informative appendix. | ||
===Description=== | ===Description=== | ||
| − | The traditional HL7 Version 2 Standard, the workhorse of clinical information exchange, is the most implemented standard for healthcare information in the world. It has been used for the exchange and management of clinical and administrative data since March of 1987. It should be noted that though HL7 Version 3 has been released, HL7 Version 2 will still be necessary to continue support for the large base of existing systems that employ it-hence the need for HL7 V2.xml. | + | The traditional HL7 Version 2 Standard, the workhorse of clinical information exchange, is the most implemented standard for healthcare information in the world. It has been used for the exchange and management of clinical and administrative data since March of 1987. It should be noted that though HL7 Version 3 has been released, HL7 Version 2 will still be necessary to continue support for the large base of existing systems that employ it-hence the need for HL7 V2.xml. It is not the intent of this document to replace the standard sequence oriented encoding rules, that use “vertical bars” and other delimiters (so called “vertical bar encoding”), but rather to provide an alternative way of encoding. Furthermore, message definitions given in the Version 2.3.1 and 2.4 standard are also untouched. However, if you are going to use XML for version 2.x messages, this HL7 ANSI/HL7 V2 XML-2003 HL7 Version 2: XML Encoding Syntax Release 1 normative document describes how to do that. This document does not modify the message definitions, only the way they are encoded. |
===Business Case (Intended Use, Customers)=== | ===Business Case (Intended Use, Customers)=== | ||
* | * | ||
===Benefits=== | ===Benefits=== | ||
| + | There are several benefits using XML as an interchange format. | ||
| + | |||
| + | The ability to explicitly represent an HL7 requirement in XML confers the ability to parse and validate messages with any XML parser. Many “off-the-shelf” XML tools are available (freeware and commercial) such as parsers, transformation applications and instance viewers, which can perform much of the validation of message/document instances, so that applications don't have to. For the encoding part, trained personnel are much easier to find if using XML than experts familiar with vertical bar encoding rules. Of course explicit knowledge about the underlying semantic assumptions is still essential. | ||
| + | |||
| + | Frequently, a typical healthcare messaging application includes an in-house developed parser (message reader) and generator (message writer) to process traditional (“vertical bar” encoded) HL7 messages with an almost certain negative impact on development and maintenance costs. The only alternative to in house tool development is to choose from among the limited but often expensive commercial tool sets. Increasing, the traditional encoding often contributes to the isolation of healthcare from the generic data interchange approaches used by other business areas. Adoption of across the board generic messaging encoding will become critical for cost and error reduction as healthcare and other areas of business increase their daily interactions. Using XML message parsers and generators will undoubtedly help to prepare healthcare for this growing challenge to increase data interchange commonality with other business areas. | ||
| + | |||
| + | Finally, an XML syntax for v2.x messages will also help vendors and providers transition from HL7 Version 2 family of standards to Version 3 by encouraging the early retooling of applications to support XML interfaces. | ||
| + | |||
THE BENEFITS OF XML | THE BENEFITS OF XML | ||
<nowiki>"</nowiki>The XML capability of HL7 V2.xml makes messages web-enabled, provides more widespread acceptance, and allows up-front validation that reduces the chance of error,<nowiki>"</nowiki> said Kai U. Heitmann, M.D. of the Institute for Medical Statistics, Informatics and Epidemiology at the University of Cologne, Germany. Heitmann is a past International Representative on the HL7 Board of Directors; Past Co-Chair of the HL7 XML Work Group; and editor of the Version 2 XML Encoding Syntax standard. | <nowiki>"</nowiki>The XML capability of HL7 V2.xml makes messages web-enabled, provides more widespread acceptance, and allows up-front validation that reduces the chance of error,<nowiki>"</nowiki> said Kai U. Heitmann, M.D. of the Institute for Medical Statistics, Informatics and Epidemiology at the University of Cologne, Germany. Heitmann is a past International Representative on the HL7 Board of Directors; Past Co-Chair of the HL7 XML Work Group; and editor of the Version 2 XML Encoding Syntax standard. | ||
Cross-industry efficiencies are another important benefit of XML-based standards. <nowiki>"</nowiki> Implementing HL7 V2.xml is also less expensive because its tag-oriented format makes available to users a rich suite of free, off-the-shelf XML tools,<nowiki>"</nowiki> Heitmann said. | Cross-industry efficiencies are another important benefit of XML-based standards. <nowiki>"</nowiki> Implementing HL7 V2.xml is also less expensive because its tag-oriented format makes available to users a rich suite of free, off-the-shelf XML tools,<nowiki>"</nowiki> Heitmann said. | ||
| + | |||
| + | <!-- | ||
===Implementations/ Case Studies (Actual Users)=== | ===Implementations/ Case Studies (Actual Users)=== | ||
* | * | ||
* | * | ||
===Resources=== | ===Resources=== | ||
| − | * | + | * --> |
====Work Groups==== | ====Work Groups==== | ||
| − | * | + | *[http://www.hl7.org/Special/committees/xml/index.cfm Implementable Technology Specifications] |
====Education==== | ====Education==== | ||
* See more at http://www.hl7.org/implement/training.cfm | * See more at http://www.hl7.org/implement/training.cfm | ||
| + | <!-- | ||
=====Certification Available===== | =====Certification Available===== | ||
*none | *none | ||
| Line 44: | Line 56: | ||
====Presentations==== | ====Presentations==== | ||
| − | + | --> | |
====Relationship to/ Dependencies on, other standards==== | ====Relationship to/ Dependencies on, other standards==== | ||
| − | * | + | *V2 |
====Links to current projects in development==== | ====Links to current projects in development==== | ||
| − | * | + | *none |
Revision as of 15:33, 10 November 2009
Contents
Product Brief - HL7 Version 2: XML Encoding Syntax, Release 1
- Back to Main_Page
- Back to Product_List
Product Name
HL7 Version 2: XML Encoding Syntax, Release 1
Also referred to as XML Encoding Rules for HL7 V2 Messages
Topics
Standard Category
Health Information Exchange Standards
Integration Paradigm
Messaging
Type
Normative, ANSI Standard
Releases
- ANSI/HL7 V2 XML-2003 June 4, 2003: HL7 Version 2: XML Encoding Syntax Release 1.
- This document is the normative successor of the informative document “HL7 Recommendation: Using XML as a Supplementary Messaging Syntax for HL7 Version 2.3.1 – HL7 XML Special Interest Group, Informative Document” as of February, 2000 [rfINFO].
Summary
HL7 Version 2 XML Encoding Syntax was approved by the American National Standards Institute (ANSI) as an American National Standard in June 2003. This specification, informally known as HL7 V2.xml, defines the Extensible Markup Language (XML) encoding rules for traditional HL7 Version 2 message content. It primarily addresses the expression of HL7 Version 2 messages in XML as an alternative to the traditional “vertical bar” encoding, and describes the underlying rules and principles. XML schema definitions are provided for all Version 2 message types, including the corresponding data type descriptions necessary for this specification. Due to their greater expressiveness, schemas are the preferred way to describe a set of constraints on message instances. Document Type Definitions (DTDs) are also provided as an informative appendix.
Description
The traditional HL7 Version 2 Standard, the workhorse of clinical information exchange, is the most implemented standard for healthcare information in the world. It has been used for the exchange and management of clinical and administrative data since March of 1987. It should be noted that though HL7 Version 3 has been released, HL7 Version 2 will still be necessary to continue support for the large base of existing systems that employ it-hence the need for HL7 V2.xml. It is not the intent of this document to replace the standard sequence oriented encoding rules, that use “vertical bars” and other delimiters (so called “vertical bar encoding”), but rather to provide an alternative way of encoding. Furthermore, message definitions given in the Version 2.3.1 and 2.4 standard are also untouched. However, if you are going to use XML for version 2.x messages, this HL7 ANSI/HL7 V2 XML-2003 HL7 Version 2: XML Encoding Syntax Release 1 normative document describes how to do that. This document does not modify the message definitions, only the way they are encoded.
Business Case (Intended Use, Customers)
Benefits
There are several benefits using XML as an interchange format.
The ability to explicitly represent an HL7 requirement in XML confers the ability to parse and validate messages with any XML parser. Many “off-the-shelf” XML tools are available (freeware and commercial) such as parsers, transformation applications and instance viewers, which can perform much of the validation of message/document instances, so that applications don't have to. For the encoding part, trained personnel are much easier to find if using XML than experts familiar with vertical bar encoding rules. Of course explicit knowledge about the underlying semantic assumptions is still essential.
Frequently, a typical healthcare messaging application includes an in-house developed parser (message reader) and generator (message writer) to process traditional (“vertical bar” encoded) HL7 messages with an almost certain negative impact on development and maintenance costs. The only alternative to in house tool development is to choose from among the limited but often expensive commercial tool sets. Increasing, the traditional encoding often contributes to the isolation of healthcare from the generic data interchange approaches used by other business areas. Adoption of across the board generic messaging encoding will become critical for cost and error reduction as healthcare and other areas of business increase their daily interactions. Using XML message parsers and generators will undoubtedly help to prepare healthcare for this growing challenge to increase data interchange commonality with other business areas.
Finally, an XML syntax for v2.x messages will also help vendors and providers transition from HL7 Version 2 family of standards to Version 3 by encouraging the early retooling of applications to support XML interfaces.
THE BENEFITS OF XML "The XML capability of HL7 V2.xml makes messages web-enabled, provides more widespread acceptance, and allows up-front validation that reduces the chance of error," said Kai U. Heitmann, M.D. of the Institute for Medical Statistics, Informatics and Epidemiology at the University of Cologne, Germany. Heitmann is a past International Representative on the HL7 Board of Directors; Past Co-Chair of the HL7 XML Work Group; and editor of the Version 2 XML Encoding Syntax standard.
Cross-industry efficiencies are another important benefit of XML-based standards. " Implementing HL7 V2.xml is also less expensive because its tag-oriented format makes available to users a rich suite of free, off-the-shelf XML tools," Heitmann said.
Work Groups
Education
- See more at http://www.hl7.org/implement/training.cfm
Relationship to/ Dependencies on, other standards
- V2
Links to current projects in development
- none
