New ITS Structures

Preface

Notes to Readers

This is a work in progress draft, and far from complete HL7 methodology pre-requisites for approving this ITS include:

• Establishing and normalizing V3 Serialization Models to set the wire format rules for all

HL7 message and document designs. (Note: This is likely an appropriate joint work item between INM and MnM.)

• Candidate Serialization Models include:
  • One for all clinical domains (e.g. CDA, Patient Care, Lab)
  • Medications
  • One for Administration and Finance
  • Shared Messages
• Limiting the number of Serialization Models should also increase the ease

of harmonizing [creating consistent serialization rules for] common concepts across them (e.g. the Clinical Statement Pattern, CMETs).

It is assumed that this ITS will be used alongside the proposed ISO datatypes, though this is not an absolute requirement.

Acknowledgements

This will carry forwards in part from the XML ITS R1

Prerequisites, Assumptions and Conventions

It is a prerequisite that readers have a general knowledge of XML technology. Readers unfamiliar with XML may gain the requisite knowledge from the following W3C standards:

• [[ http://www.w3.org/TR/2004/REC-xml11-20040204/ |XML 1.1]]
• [[ http://www.w3.org/XML/Schema | XML Schema]]
• [[ http://www.w3.org/TR/REC-xml-names/ | XML namespace]]

It is assumed that the reader is familiar with HL7 version 3 terminology - especially those related to message definition (HL7 information model terminology, Message Instances, Message Types, Interactions, CMETs, wrappers, etc.). For more information on these, refer to the V3 Guide.

It is also assumed that the reader has a working understanding of UML (Unified Modelling Language).

Known Issues and Planned Changes

• Model boundaries -- It is not clear how much information about the components should be included in the instance,

and how much should be held in the specification. In particular it is not clear whether there is a need to identify the serialisation model and/or the validation model that were used for each component.

• Is the name of the XML element representing a choice taken from the name of the choice, or from the association role name?
• Are names for entry points into CMETs generated from both the association and the root class name as is is the case in the current ITS?
• What mechanism for informal extensions is to be followed – that used by Gunther in SPL, that specifed in the XML IST R1, or both
• Are the identifiers for the Standard Validation Model conveyed in the templateId, or in a different attribute.
• Are Standard validation Models referenced everywhere in the instance, just at model entry points, or are they inferred from the interactionId?
• Which of the datatypes changes proposed on the HL7 Wiki have been implemented in the R2 datatypes proposal that is associated with this document?

Overview

Introduction and Scope

This document describes how HL7 V3 compliant messages can be expressed using XML. It describes how the definition of the set of valid XML instance documents is derived from a specific HL7 Message Type. It covers ISO levels 5 and 6. Those familiar with V2 might call these the "XML encoding rules" for HL7 Version 3 messages. It also defines a standard way to use W3C XML Schema and UML to describe these instances in a way that is human and machine readable.

Serialisation of HL7 Classes to XML

HL7 Choice structures

• • Choice structures are represented in the serialization model (and hence the instance)

as an XML element (naming convention to be confirmed)

HL7 model boundary

CMET and wrapper boundaries are represented using an XML element (naming convention to be confirmed)

There will also be additional attributes at the model entry point to identify the serialization model, and to provide version information for it.

Possibly the inclusion of additional attributes to identify the Standard Validation Model (alternatively these are treated in the same way as HL7 Templates, and referenced in the templateId attribute)

Reshaping of RIM based Models

The mechanics of serialization

This section describes the mechanics of V3 serialization within this ITS, including identifying the Serialization Model and creating Serialization Models.

Identifying the Serialization Model

Static Model reference to Serialization Model

Each static model will be associated with a single Serialization Model. This will either be done with an annotation in the model (details to be provided), or can be inferred from its parent static model.

Instance references to Serialization Model

In the instance, the Serialization Model and version will need to be declared using new attributes.

The instance may also include references to the Standard Validation Models to which the sender is asserting conformance, as well as any locally defined Templates. The rules for when and how such references are to be included will be clarified in the V3 Templates specification. It may be that the references are inferred from the implementation contract agreement and need not be made explicit in every message instance.

Creation of Serialization Models

The Serialization Model is created directly from an appropriate RIM based model. A set of annotations as described in Section 3.2.2 may be added to the model to indicate which classes and attributes are not to be directly included in serialization instances. These annotations are included in the "notes" field as structured text, and so are visible in the human readable specifications and in the machine-readable HL7 MIF (Model Interchange Format) documents.

When not modified by the annotations, the serialization of the structures follows the rules specified above.

For transport and control act wrapper content, the serialization may be defined by the transport protocol. While the ITS allows for this, it leaves defining such transport specific serializations to the HL7 V3 Transport Profile documentation.

Backwards and Forwards Compatability

The XML ITS R1 stated that "when there are different versions of either the abstract HL7 artifact definitions, or of the ITS, it is anticipated that these versions will be no more than a single XSLT transform apart." In this specification we hope to improve on that, maybe by using the mechamism described in the SPL (Structured Product Labling) specification.

The use of schema processors

Schema processing is not a conformance requirement although this specification has been designed to support schema processing. Where schemas are used receivers may use alternate schemas (including DTDs) than the ones provided by HL7.

Sending applications should not provide schema location hints for the HL7 namespace and receiving applications that perform schema processing should ignore such hints if provided and instead should use whatever other means they have at their disposal to locate the relevant official HL7 schemas or their own customizations thereof. It is in the interest of the receivers own security and safety not to use sender supplied schemaLocation hints.

Glossary entries

The entries here are words or phrases that are used inthis document and need to be defined in the Glossary.

• Serialisation
• Serialisation Model
• Static Model
• RIM based Model
• UML
• Model Boundary

Questions for Publishing

How do I do links to SPL?