This wiki has undergone a migration to Confluence found Here

New ITS Structures

From HL7Wiki
Jump to navigation Jump to search

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

Changes from Previous Release

Prerequisites, Assumptions and Conventions

  • Section Status - complete draft

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:

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.

Use of XML Namespaces

  • section status incomplete.

All XML elements and attributes (except for informal extensions and the contents of ED datatypes) are to be represented in the namespace defined by "urn:hl7-org:v3".

Attributes "type" and "nil" from the xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" namespace may be used. The "type" attribute will be used to indicate the datatype of elements where this could be ambiguous.

In this document all examples will be written with the assumption that hl7 has been declared as a prefix for the hl7 namespace as follows: xmlns:hl7="urn:hl7-org:v3". Note that any valid namespace prefix (or none) may be used in practice.

The use of namespaces within the ED datatype are discussed in the XML ITS Data Types.

XML content from other namespaces (except within an ED datatype) will be assumed to be informal extensions as described later in this document and be ignored by receiving systems that do not recognize them.

Reference Package

  • section status incomplete

This section will be completed by Grahame. It will describe where the datatyppes and structural vocabularies that are required for use of this specification can be found. This has been moved from the "Serialisation of HL7 Classes section because it warrents its own section.

Serialisation of HL7 Classes to XML

  • there is a question as to how the references to parts of the static model should eb described. This document currently used the HMD names for components of the Static Model, and that is not ideal.

Cardinality

  • section content: complete draft (unchanged from XML ITS R1)

For each row in the HMD representing a class, attribute, or association the cardinality in the HMD sets the upper and lower limits on the number of elements that may be included in the instance which correspond to that row. Note that it is never possible to repeat structural attributes, and these are optional in the XML instances if a default or fixed value has been set.

HL7 Class

  • section content: complete draft (unchanged from XML ITS R1)

The name for the element representing the Class is taken either from the association name, or in the case of the root element representation for a transmission wrapper, from the InteractionID.

Where the Class is flagged as Mandatory it must be included in the message for the message to be valid.

The XML representation of these elements are determined by the SRC column, whose value will be one of: "N", "R", "U", "I", or "C".

Associations with direct content

If the value of the SRC column is "N" or "R" then the XML representation will be a sequence of child elements, one for each HMD row of type "Attr" followed by one for each HMD row of type "Assoc" whose InMET column equals the Row column of the row in question.

HL7 Choice structures

The preceding is true unless the value of OfMET contains a choice of more than one message element type. In this case, the XML representation represents the choice as a choice of one or more XML elements corresponding to those identified in the ofMET row. Each element will have content derived as described in this section from the row in the HMD with that Element Name.

If the value of the SRC column is “I” or “U” then the XML representation is the same as defined for the row in the HMD being referenced. In the case of “I” the content in the row must also be identical.

HL7 model boundary

If the value of the SRC column is "C" (i.e., the HMD row is defined by a CMET) then the XML representation of the element is determined by applying the rules in “Message Elements That Are RIM Classes” to the requisite CMET found in the OfMET column.

If the value of the SRC column is “I” or “U” then the XML representation is the same as defined for the row in the HMD being referenced. In the case of “I” the content in the row must also be identical.

There will also be additional attributes (are these XML attributes or might they be elements?) at the model entry point to identify the serialization and standard validation models, and to provide version information for them. Alternatively the Standard Validation model may be treated in the same way as HL7 Templates, and referenced in the templateId attribute)

HL7 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.

Abstract Serialisation Model

Informal Extensions

HL7 structural attributes are conveyed as attributes. Where there is a default or fixed value defined in the HL7 static model then the attribute may be omitted from the XML representation, and the receiving system will behave as though the fixed or default value was sent. Note that according to the Refinements and Localization document "the default is a single value, once a default has been set, it may not be further constrained. Moreover, the assertion of default values may only be done by an HL7 Technical Committee as it prepares a ballot, or by an HL7 International Affiliate that is preparing a region-specific profile".

All attributes are represented as elements with the name taken from the “Element Name” in the HMD. The XML representation of these elements are determined by the OfMET. Specifically, for rows of type "Attr", the value of OfMET will be the name of a Version 3 Data Type, and hence, the XML representation will be as described in the XML ITS Data Types.

      • note to reader -- this is different from the XML ITS R1 where structural attributes were conveyed in XML attributes

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 in this document and need to be defined in the Glossary.

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

Questions for Publishing

How do I do links to SPL?