OBJECTIVE: To report on the use of SGML and XML (a proper subset of SGML) as transfer syntaxes for HL7 Version 2.3 and Version 3.0 messages. METHODS: The methodology has focused largely on two questions: Can it be done? How best to do it? The first question is addressed by attempting to build an SGML/XML representation of HL7 messages. The second question requires a consideration of several metrics: message length, speed of message creation and parsing, interversion compatibility, local customization, conformance determination, and the availability of software tools and skill on the format. RESULTS: Detailed specifications for expressing HL7 in SGML and XML have been developed. Some HL7 requirements are not readily expressed, while some ambiguous areas of the HL7 standard are made explicit in the SGML/XML representation. With the current design, an SGML/XML parser can extract any component of any data type from a message. CONCLUSIONS: SGML and XML can both serve as implementable message specifications for HL7 Version 2.3 and Version 3.0 messages. The ability to explicitly represent an HL7 requirement in SGML/XML confers the ability to validate that requirement with an SGML parser. The optimal message representation will be a balance of functional, technical, and practical requirements.
OBJECTIVE: To report on the use of SGML and XML (a proper subset of SGML) as transfer syntaxes for HL7 Version 2.3 and Version 3.0 messages. METHODS: The methodology has focused largely on two questions: Can it be done? How best to do it? The first question is addressed by attempting to build an SGML/XML representation of HL7 messages. The second question requires a consideration of several metrics: message length, speed of message creation and parsing, interversion compatibility, local customization, conformance determination, and the availability of software tools and skill on the format. RESULTS: Detailed specifications for expressing HL7 in SGML and XML have been developed. Some HL7 requirements are not readily expressed, while some ambiguous areas of the HL7 standard are made explicit in the SGML/XML representation. With the current design, an SGML/XML parser can extract any component of any data type from a message. CONCLUSIONS: SGML and XML can both serve as implementable message specifications for HL7 Version 2.3 and Version 3.0 messages. The ability to explicitly represent an HL7 requirement in SGML/XML confers the ability to validate that requirement with an SGML parser. The optimal message representation will be a balance of functional, technical, and practical requirements.
Authors: R H Dolin; L Alschuler; C Beebe; P V Biron; S L Boyer; D Essin; E Kimber; T Lincoln; J E Mattison Journal: J Am Med Inform Assoc Date: 2001 Nov-Dec Impact factor: 4.497
Authors: K Araki; K Ohashi; S Yamazaki; Y Hirose; Y Yamashita; R Yamamoto; K Minagawa; N Sakamoto; H Yoshihara Journal: J Med Syst Date: 2000-06 Impact factor: 4.460
Authors: R H Dolin; L Alschuler; F Behlen; P V Biron; S Boyer; D Essin; L Harding; T Lincoln; J E Mattison; W Rishel; R Sokolowski; J Spinosa; J P Williams Journal: Proc AMIA Symp Date: 1999