New ITS Datatypes Guide

This document describes the rationale for the datatypes, and includes information that will be useful to those evaluating, implementing or maintaining the datatypes. It includes a description of the design principles followed in the development of the datatypes,and a discussion of each datatype.

Design Principles

The datatypes have been developed according to the following principles:

• Clarity of expression
• Ease of implementation
• Compatibility with datatypes from other specifications, in particular:
  • ISO 11404
  • HL7 V3 XML ITS datatypes R1
  • openEHR datatypes

Old Introduction

Context of this specification

This is the reference package for the UML ITS. It consists of representations of the basic datatypes, infrastructural types, and structural vocabularies defined by the V3 methodology to support the UML ITS. The rationale and design philosophy are documented in the UML ITS

This package to support a specific ITS, an implementation of the V3 abstract data types, and some parts of the RIM and the structural vocabulary. It provides a particular way to implement the V3 specifications. Implementers should be aware that not all the features provided by this ITS reference package are able to be used in all contexts, and implementers must consult the V3 modeling layer (RIM, Vocabulary Definitions, Abstract Data Types, and other models) to fully implement the V3 standard correctly.

Specification Considerations

The desire is to have a simple model, shared in common in both XML and UML. Either the UML or the XML can be used to understand the HL7 v3 messages, validate instances, generate code, etc. This is the "implementable model" that drives the implementation of HL7 v3 instances. Both the UML and Schema models are considered normative representations of the model.

The model represents the structure in as simple terms as possible, with a focus on commonly accepted o-o formalisms. In addition, invariant constraints are provided as either OCL or schematron constraints to further specify the many co-occurence constraints that exist in the HL7 v3 model.

\[Todo: this will be true\] The UML diagrams use stereotypes that define how the XML and schema re produced from the UML diagrams. These UML Stereotypes are not visible in the diagrams shown in this document, but will be found in the XMI and other UML files attached to this document. The UML profile used is that of David Carlson \[todo: David to give me the appropriate reference, and also reference his book and [1]\]

Mappings to OpenEHR

This specification includes mappings to OpenEHR data types and structures as this is of great interest to many consumers of this specification for various reasons.

There is 4 different kind of mappings that are of interest when considering the mapping of OpenEHR constructs to UML ITS constructs.

• Converting from an HL7 Model to an OpenEHR archetype
• Converting from an OpenEHR Archetype to an HL7 Model
• Converting from an instance of an HL7 model to an instance of an OpenEHR Archetype
• Converting from an instance of an OpenEHR Archetype to an instance of an HL7 model

This specification addresses the issues involved in mapping from an HL7 model to an OpenEHR Model, and converting instances in either direction.

When converting from an HL7 model to an archetype, most HL7 data types match an OpenEHR equivalent directly, and it is a simple matter to convert. Some HL7 data types map to specially developed archetypes for demographic type information, and some HL7 data types map to OpenEHR structures. Finally, some HL7 data types express constraints on the data that is properly expressed in the archetype itself in OpenEHR. For this reason, converting from HL7 to OpenEHR is not simple matter of replacing data types, the entire model must be translated or transformed. This specification provides detailed equivalence notes for each HL7 data type to their matching OpenEHR constructs to help in this process. Users should be aware that though the result of converting an HL7 Model into an archetype may work, it is unlikely to be an optimally designed archetype.

This specification does not attempt to describe or aid the process of taking an OpenEHR archetype and representing it as an HL7 model. The primary reason is that the only archetypes that can be reasonably represented as HL7 models are likely to be those that were translated and transformed using the reverse process described above, and there seems little point in exercising or describing this path. Normal Archetypes will involve the use of constructs that do not have any equivalence of expression in Hl7 models where the Act/ActRelationship construct dominates the models. Nevertheless the information in this document will be useful for helping with this process.

Given an instance of an HL7 Model and the OpenEHR archetype derived from it, it may be possible, with some computational aid, to automatically convert from one instance to another in either direction. The mapping notes contained in this specification are intended to help with the analysis, design and implementation of this process. It is unlikely to be possible to automatically convert between instances of unrelated archetypes and models.

Some specific issue discussions for the OpenEHR mappings:

NullFlavor: xxxxxxxxxxxx

There is no discussion at the abstract level concerning the use of these attributes with null values. It is disallowed until use cases for it\’s support are accepted by HL7.

Relationship with HL7v3 datatypes release 1 (abstract and XML ITS)

(from new ITS doc, status Draft)

The following summarizes the most significant changes proposed to the data types. These are fully documented in the separate datatypes proposal document.

• Null flavor values are reduced in number
• An IdentifierUse attribute has been added to II
• Encapsulated Data (ED) has been restructured to be a sibling of String (ST), rather than a child
• An explicit "data" component has been added for ED
• XML attributes are used for address and name part categories rather than XML element names
• "Group" was added to Coded Data (CD) to support post coordinated SNOMED terms
• Explicit XML elements were created for sets, bags and lists

In addition, at this time there are a significant number of open data type shange proposals on the HL7 wiki. It is proposed that these be reviewed, and all those that will not be addressed in this release cycle be explicitly deferred to avoid implementer confusion.

notes - things to rationalise:

• why short names not human understandable names

Things to talk about

• what happened to null Flavors TRC, QS, NINF, PINF, OTH
• introduction of properties on ANY
• changing the inheritance hierarchy (CO, ED/ST, GTS/IVL)
• specific of differences between abstract specification and ISO datatypes
  • no updateMode, History or nullFlavor on inner properties
  • new properties on PQ (accuracy, magnitude, specialValue)
  • no translations on qualifiers
  • GTS.literal
  • translation purpose
  • II.type & use
  • uncustomised xml for SLIST
  • An explicit "data" component has been added for ED
  • Addition of "Term" and "Data" classes
  • XML attributes are used for address and name part categories rather than XML element names
  • Explicit XML elements were created for sets, bags and lists
• why only one templateId