This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "New ITS Datatypes Guide"

From HL7Wiki
Jump to navigation Jump to search
 
(26 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
This document describes the rationale for the datatypes, and includes information that will be useful to those evaluating, implementing or maintaining the datatypes.
+
=Warning: the contents of the guide are no longer maintained here. If you want to contribute, please discuss with Grahame=
−
It includes a description of the design principles followed in the development of the datatypes,and a discussion of each datatype.
 
  
−
= Design Principles =
+
= Note for Balloters =
−
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=
+
This is the first draft of the New ITS datatypes guide. The document is
 +
still under development, and is expected to grow significantly as a
 +
result of comments made against the ISO Healthcare Datatypes standard
 +
and the new ITS specification.
  
 +
= Introduction =
  
−
==Context of this specification==
+
The ITS datatypes guide provides supporting information for the joint
 +
ISO / HL7 healthcare datatypes specification. The ISO healthcare
 +
datatypes is developed jointly by HL7 and ISO to provide a platform
 +
independent datatype specification for general use in healthcare
 +
specifications, and in particular to be used as part of the ITS
 +
in the context of HL7 V3.
  
−
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 guide outlines the design principles that drove the development
−
+
of the ISO datatypes specification; specifies the mapping from the
−
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.
+
ISO datatypes to the V3 modeling framework, as required by the ISO
−
   
+
specification; provides reference and tutorial information to help
 +
implementors that are experienced with the previous HL7 V3 XML ITS,
 +
along with a considerable number of annotated examples; and provides
 +
as yet incomplete documentation for the requirements that supported
 +
the design of the datatypes.
 +
 
 +
= Design philosophy =
 +
 
 +
The ISO datatypes specification was first developed as a reference package to support
 +
the UML ITS: a platform independent object orientated datatype specification for use
 +
with HL7 V3. During development it was recognised that these platform independent
 +
datatypes offered a prospect of providing convergence between HL7, CEN, and ISO on
 +
the previously contentious subject of datatypes. This final specification is a joint
 +
development between HL7 and ISO. For this reason, the design philosophy is divided into
 +
two parts. The first part details with the design philosophy of the ISO datatypes
 +
specification and the second part deals with aspects of this specification as an ITS for
 +
the HL7 abstract specification.
 +
 
 +
== ISO Healthcare datatypes design philosophy ==
 +
 
 +
The intent of the ISO healthcare datatypes is to provide a single underpinning
 +
specification tht supports the healthcare datatypes. Each of the different
 +
healthcare specifications has slightly different requirements for the underlying
 +
datatypes, and there has been substantial contention about these differences.
 +
The ISO datatypes provides a single platform independent specification that
 +
can support interoperability between the different specifications. Interoperability
 +
can be enabled if specifications use the ISO Datatypes specification directly,
 +
or if the specifications provide a thorough mapping to the ISO datatypes specification.
 +
 
 +
In addition, the ISO specification must clarify the relationship between the
 +
healthcare datatypes and the general purpose datatypes specified in ISO 11404.
 +
The Healthcare datatypes often include datatypes that represent primitive
 +
concepts such as integer or boolean that are also defined in the general
 +
purpose datatypes, and there has been confusion about the relationship between
 +
the two definitions.
 +
 
 +
The general purpose datatypes define two forms of conformance, direct and
 +
indirect. The ISO Healthcare datatypes specification extends this pattern by
 +
also allowing for direct and indirect conformance, which match the two forms
 +
of interoperability described above.
 +
 
 +
The datatypes framework provided by the 11404 standard is not a common, easy
 +
to consume, formalism for the datatypes, so in addition to the 11404 based
 +
datatype definition, the specification also includes a definition of the
 +
datatypes in UML, using the UML kernel types in the same way that it
 +
uses the 11404 General Purpose Datatypes. The UML is suitable for code
 +
generation from XMI, and XMI source will be made available. In addition,
 +
given the ubiquity of XML as an interchange format, the specification
 +
defines a normative XML representation for the datatypes.
 +
 
 +
== New datatypes ITS Design Philosophy ==
 +
 
 +
While abstract datatypes specification provides an extremely precise
 +
and thorough definition of the semantics of the HL7 datatypes, it is
 +
not suitable as a basis for implementation for several reasons:
 +
* the specification is entirely defined in terms of true and false
 +
* the specification does not differentiate between the intrinsic and derived properties
 +
* the specification makes use of some techniques that are not commonly supported in implementation platforms (such as mixins)
 +
* it is not obvious how to implement the specification in a computing environment that contains existing primitive types.
 +
 
 +
The XML ITS provided a specification that described the set of XML
 +
instances that could be used to represent the abstract datatype
 +
semantics when exchanging information between systems in XML form.
 +
The XML ITS falls short of providing the kind of implementation
 +
support desired by the implementers of HL7 V3 for several reasons:
 +
* the focus of the XML ITS is specifying the set of possible instances
 +
* the xml implementation is specific to the XML platform; the form of the ITS does not easily map to other common platforms
 +
* the schema is a secondary construct suited for validation but not optimised for model driven development
 +
* the instance format is a compromise between forms suitable for different implementation forms
 +
* the decisions made by HL7 as part of the xml implementation are not described or obvious, and create difficulties for implementors.
 +
 
 +
The focus of the new ITS datatypes philosophy is to develop a platform
 +
independent implementation model for the datatypes to provide improved
 +
support for the implementation of HL7 V3. The UML is used to provide the
 +
platform independent model. Since XML is the most common interchange
 +
format, an XML format is also described, along with a schema format
 +
which are both automatically derived from the platform independent model.
 +
The intent is that other specific platform models would also be
 +
automatically derived from the platform independent model.
 +
 
 +
The major advantage of this point is that the format is fully and clearly
 +
described by the platform independent model, and the industry standard
 +
anlaysis and development approaches can be applied directly using either
 +
UML or schema as a basis for development, including model driven development
 +
or other forms of code generation. In the parlance of the new ITS, the UML
 +
definition of the datatypes is the implementable model.
 +
 
 +
== Relationship between the Abstract Datatypes and the ISO datatypes ==
 +
 
 +
HL7 V3 has it's own abstract data type specification. This rigorously
 +
defines the semantics of the datatypes as they are used in the HL7
 +
development process. The ISO datatypes specification is a computable
 +
platform independent specification, but it is technology specific to UML,
 +
so it can be treated as an ITS for the abstract datatypes.
 +
 
 +
As an ITS of the abstract datatypes, the ISO Datatypes must implement enough of the
 +
semantics of the abstract datatypes to be useful within it's target
 +
context. There is no clear definition of what scope an ITS has to not
 +
implement all the features of the the abstract datatypes specification.
 +
The existing XML ITS has been used heavily as a guide in this area, and
 +
most of the features that are not implemented in the XML ITS are not
 +
implemented in this ITS. As an example of this, CD.code is at ST in the
 +
abstract specification, which means it has a language property. However in
 +
both the XML ITS and the ISO datatypes, CD.code is implemented as a simple
 +
String taken from the underlying technology, where there is no language
 +
property. This specification deliverately introduces support for some
 +
features that the XML ITS did not support, including:
 +
* support for CD.displayName.language
 +
* support for the ANY properties on SET, LIST, and BAG
 +
 
 +
Since the ISO datatypes is an implementation of the abstract datatypes, and
 +
supports some features differently to how they are described in the abstract
 +
datatypes, this document explains these differences below in the HL7 V3 mapping
 +
for the ISO datatypes. In particular, The ISO datatypes includes some features
 +
that are not defined in the abstract datatypes specification. The use of these
 +
features is not supported in HL7 V3.
 +
 
 +
== Use of attributes in XML ==
 +
 
 +
As part of the standard, a normative XML serialization is defined. This XML format
 +
uses attributes for simple types that are mapped to a specialization of the UML
 +
kernel type Primitive. There has been an ongoing debate concerning the advantages
 +
of elements or attributes for simple types. After some substantial debate, the
 +
standard uses attributes for the following reasons:
 +
 
 +
# the use of attributes leads to a slightly smaller xml
 +
# attributes can be given default values in schema, which are available in a PSVI
 +
# attributes are available at the same time as the element that contains them in a SAX process. This is particularly relevant for simple structural codes such as classCode, typeCode etc
  
−
==Specification Considerations==
+
None of these arguments are powerful - with the possible exception of #3 - but are
 +
considered to outweigh the main argument for using elements instead, which is
 +
that some (very old) XML binding tools struggle with attributes.
  
−
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.
+
= ISO Datatypes mapping for HL7 V3=
  
−
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.
+
The ISO datatypes standard requires that any information processing entity which
 +
declares indirect conformance to the standard provides a set of mappings between
 +
it's own datatypes and the ISO datatypes.
  
−
\[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 [http://www.xmlmodeling.com-http://www.xmlmodeling.com/]\]
+
HL7 V3 declares indirect conformance to the ISO datatypes standard, and this
 +
section is provided to fulfill the requirements for the mapping.
  
 +
== Mapping between ISO datatypes and HL7 V3 datatypes ===
  
 +
All public datatypes are supported by HL7 V3, though not all the properties of
 +
the ISO datatypes specifications are supported. Also note the mapping sections
 +
below that relate to the use of nullFlavor.
  
−
==Mappings to OpenEHR==
+
{|
 +
|ISO Data Type || HL7 V3 Datatype || Property Notes
 +
|-
 +
|ANY||ANY||See Section ANY properties below
 +
|-
 +
|HXIT||HXIT||ISO controlActIdRef is not yet added to the abstract datatypes (expected in the future), and is therefore not supported in HL7 V3
 +
|-
 +
|BL||BL||All properties are supported
 +
|-
 +
|ED||ED||All properties are supported
 +
|-
 +
|ST||ST||All properties are supported
 +
|-
 +
|SC||SC||SC.code is a CD in ISO datatypes and a CV in the abstract specification, so the use of qualifiers and translations is not supported in HL7 V3
 +
|-
 +
|CD||CD||All properties are supported
 +
|-
 +
|CR||CR||All properties are supported
 +
|-
 +
|CE||CE||All properties are supported
 +
|-
 +
|CV||CV||All properties are supported
 +
|-
 +
|CS||CS||All properties are supported
 +
|-
 +
|URL||URL||All properties are supported
 +
|-
 +
|TEL||TEL||All properties are supported
 +
|-
 +
|II||II||use is not yet added to the abstract datatypes (expected in the future), and is therefore not supported in HL7 V3.
  
−
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.  
+
type is not supported in HL7 V3
 +
|-
 +
|ADXP||ADXP||All properties are supported
 +
|-
 +
|AD||AD||All properties are supported
 +
|-
 +
|ENXP||ENXP||All properties are supported
 +
|-
 +
|EN||EN||All properties are supported
 +
|-
 +
|TN||TN||All properties are supported
 +
|-
 +
|PN||PN||All properties are supported
 +
|-
 +
|ON||ON||All properties are supported
 +
|-
 +
|QTY||QTY||All properties are supported
 +
|-
 +
|INT||INT||All properties are supported
 +
|-
 +
|CO||CO||All properties are supported
 +
|-
 +
|REAL||REAL||All properties are supported
 +
|-
 +
|RTO||RTO||All properties are supported
 +
|-
 +
|PQ||PQ||The accuracy property is not supported in HL7 V3. Also see the section PQ.specialValue below
 +
|-
 +
|PQR||PQR||All properties are supported
 +
|-
 +
|MO||MO||All properties are supported
 +
|-
 +
|TS||TS||All properties are supported
 +
|-
 +
|COLL||--||There is no equivalent to COLL in the V3 datatypes
 +
|-
 +
|SET||SET||All properties are supported
 +
|-
 +
|LIST||LIST||All properties are supported
 +
|-
 +
|GLIST||GLIST||All properties are supported
 +
|-
 +
|SLIST||SLIST||All properties are supported
 +
|-
 +
|BAG||BAG||All properties are supported
 +
|-
 +
|IVL||IVL||All properties are supported. See section about IVL.bounds below
 +
|-
 +
|PIVL||PIVL||All properties are supported
 +
|-
 +
|EIVL||EIVL||All properties are supported
 +
|-
 +
|GTS||GTS||All properties are supported
 +
|-
 +
|UVP||UVP||All properties are supported
 +
|-
 +
|NPPD||NPPD||All properties are supported
 +
|-
 +
|PPD||PPD||All properties are supported
 +
|-
 +
|}
  
−
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
+
== ANY Properties ==
−
* 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.  
+
The ISO ANY has a number of properties that map one way or another to
 +
the V3 development process. This section describes these mappings.
  
−
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.
+
'''nullFlavor''': The nullFlavor property maps directly to the abstract ANY.nullFlavor.
 +
All the ISO nullFlavors are supported by the abstract nullFlavor, but the converse is
 +
not true. Some abstract nullFlavors are not represented as nullFlavors in the ISO
 +
datatypes, and other representations must be used:
  
−
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.
+
{|
 +
|Abstract NullFlavor || ISO Equivalent
 +
|-
 +
|NI||NI
 +
|-
 +
|OTH||No direct equivalent. For datatypes derived from Term, populate the codeSystem and leave code blank.
 +
|-
 +
|NINF||No direct equivalent. For IVL, see the IVL.bounds section below
 +
|-
 +
|PINF||No direct equivalent. For IVL, see the IVL.bounds section below
 +
|-
 +
|UNK||UNK
 +
|-
 +
|ASKU||ASKU
 +
|-
 +
|NAV||NAV
 +
|-
 +
|NASK||NASK
 +
|-
 +
|TRC||No direct equivalent. For PQ, see the PQ.specialValue section below
 +
|-
 +
|QS||No direct equivalent. For PQ, see the PQ.specialValue section below
 +
|-
 +
|MSK||MSK
 +
|-
 +
|NA||NA
 +
|-
 +
|}
  
−
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.
+
'''updateMode''': this maps to the updateMode described as part of the HDF. It is
 +
only allowed where the updateMode flag is set appropriately as described by the HDF.
 +
There is no direct equivalent in the abstract datatypes
  
−
Some specific issue discussions for the OpenEHR mappings:
+
'''history''': this maps to the audit trail described as part of the HDF. It is
 +
only allowed where the updateMode flag is set appropriately as described by the HDF.
 +
There is no direct equivalent in the abstract datatypes.
  
−
NullFlavor: xxxxxxxxxxxx
+
'''flavor''': this allows for a datatype specialisation to be conveyed. It's use
 +
is described in the Refinement and Localisation specification. There is no direct
 +
equivalent in the abstract datatypes.
  
−
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.
+
== PQ.specialValue ==
  
−
= Relationship with HL7v3 datatypes release 1 (abstract and XML ITS) =
+
The ISO PQ has a property specialValue which can carry the value or TRC or QS. These
−
(from new ITS doc, status Draft)
+
are modelled as NullFlavor values in the abstract datatypes. Using specialValue
 +
of TRC or QS is semantically equivalent to using the same code in a nullFlavor.
  
−
The following summarizes the most significant changes proposed to the data types. These are fully documented in the separate datatypes proposal document. 
+
== IVL.bounds ==
−
* 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.
+
Rather than using NINF and PINF in the IVL type to specify that the upper or
 +
lower bound is unknown, like the abstract datatypes, the ISO specification uses
 +
the boolean properties lowUnbounded and highUnbounded. The semantic meaning
 +
of the two forms of representation is identical.
  
 +
== XML namespace ==
  
−
notes - things to rationalise:
+
For the XML format, the serialization defined in the ISO standard applies,
−
* why short names not human understandable names
+
but the namespace is urn:hl7-org:v3 instead of uri:iso.org:21090.
  
 +
= Implementers guide to ITS R2 =
  
 +
* comparison between ITS 1 and ITS 2, and notes for implementors
  
 +
Keith to complete
  
 
Things to talk about
 
Things to talk about
 +
* 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.
 
* what happened to null Flavors TRC, QS, NINF, PINF, OTH
 
* what happened to null Flavors TRC, QS, NINF, PINF, OTH
 
* introduction of properties on ANY
 
* introduction of properties on ANY
Line 93: Line 354:
 
** XML attributes are used for address and name part categories rather than XML element names
 
** 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
 
** Explicit XML elements were created for sets, bags and lists
 +
* why only one templateId
 +
 +
= 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.
 +
 +
 +
 +
= Examples =
 +
 +
* examples with discussion
 +
 +
=Requirements=
 +
 +
* requirements as they are collected
 +
 +
==Requirements Basic Datatypes==
 +
 +
==Requirements Text And Content Data Types==
 +
 +
==Requirements Coded Data Types (Terminology)==
 +
 +
==Requirements Identification Data Types==
 +
 +
==Requirements Name and Address Data Type==
 +
 +
==Requirements Quantity Data Types==
 +
 +
==Requirements Collection Data Types==
 +
 +
==Requirements Timing Specification Data Types==
 +
 +
 +
= old stuff =
 +
 +
==Old Introduction==
 +
 +
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.

Latest revision as of 05:30, 6 June 2007

Warning: the contents of the guide are no longer maintained here. If you want to contribute, please discuss with Grahame

Note for Balloters

This is the first draft of the New ITS datatypes guide. The document is still under development, and is expected to grow significantly as a result of comments made against the ISO Healthcare Datatypes standard and the new ITS specification.

Introduction

The ITS datatypes guide provides supporting information for the joint ISO / HL7 healthcare datatypes specification. The ISO healthcare datatypes is developed jointly by HL7 and ISO to provide a platform independent datatype specification for general use in healthcare specifications, and in particular to be used as part of the ITS in the context of HL7 V3.

This guide outlines the design principles that drove the development of the ISO datatypes specification; specifies the mapping from the ISO datatypes to the V3 modeling framework, as required by the ISO specification; provides reference and tutorial information to help implementors that are experienced with the previous HL7 V3 XML ITS, along with a considerable number of annotated examples; and provides as yet incomplete documentation for the requirements that supported the design of the datatypes.

Design philosophy

The ISO datatypes specification was first developed as a reference package to support the UML ITS: a platform independent object orientated datatype specification for use with HL7 V3. During development it was recognised that these platform independent datatypes offered a prospect of providing convergence between HL7, CEN, and ISO on the previously contentious subject of datatypes. This final specification is a joint development between HL7 and ISO. For this reason, the design philosophy is divided into two parts. The first part details with the design philosophy of the ISO datatypes specification and the second part deals with aspects of this specification as an ITS for the HL7 abstract specification.

ISO Healthcare datatypes design philosophy

The intent of the ISO healthcare datatypes is to provide a single underpinning specification tht supports the healthcare datatypes. Each of the different healthcare specifications has slightly different requirements for the underlying datatypes, and there has been substantial contention about these differences. The ISO datatypes provides a single platform independent specification that can support interoperability between the different specifications. Interoperability can be enabled if specifications use the ISO Datatypes specification directly, or if the specifications provide a thorough mapping to the ISO datatypes specification.

In addition, the ISO specification must clarify the relationship between the healthcare datatypes and the general purpose datatypes specified in ISO 11404. The Healthcare datatypes often include datatypes that represent primitive concepts such as integer or boolean that are also defined in the general purpose datatypes, and there has been confusion about the relationship between the two definitions.

The general purpose datatypes define two forms of conformance, direct and indirect. The ISO Healthcare datatypes specification extends this pattern by also allowing for direct and indirect conformance, which match the two forms of interoperability described above.

The datatypes framework provided by the 11404 standard is not a common, easy to consume, formalism for the datatypes, so in addition to the 11404 based datatype definition, the specification also includes a definition of the datatypes in UML, using the UML kernel types in the same way that it uses the 11404 General Purpose Datatypes. The UML is suitable for code generation from XMI, and XMI source will be made available. In addition, given the ubiquity of XML as an interchange format, the specification defines a normative XML representation for the datatypes.

New datatypes ITS Design Philosophy

While abstract datatypes specification provides an extremely precise and thorough definition of the semantics of the HL7 datatypes, it is not suitable as a basis for implementation for several reasons:

  • the specification is entirely defined in terms of true and false
  • the specification does not differentiate between the intrinsic and derived properties
  • the specification makes use of some techniques that are not commonly supported in implementation platforms (such as mixins)
  • it is not obvious how to implement the specification in a computing environment that contains existing primitive types.

The XML ITS provided a specification that described the set of XML instances that could be used to represent the abstract datatype semantics when exchanging information between systems in XML form. The XML ITS falls short of providing the kind of implementation support desired by the implementers of HL7 V3 for several reasons:

  • the focus of the XML ITS is specifying the set of possible instances
  • the xml implementation is specific to the XML platform; the form of the ITS does not easily map to other common platforms
  • the schema is a secondary construct suited for validation but not optimised for model driven development
  • the instance format is a compromise between forms suitable for different implementation forms
  • the decisions made by HL7 as part of the xml implementation are not described or obvious, and create difficulties for implementors.

The focus of the new ITS datatypes philosophy is to develop a platform independent implementation model for the datatypes to provide improved support for the implementation of HL7 V3. The UML is used to provide the platform independent model. Since XML is the most common interchange format, an XML format is also described, along with a schema format which are both automatically derived from the platform independent model. The intent is that other specific platform models would also be automatically derived from the platform independent model.

The major advantage of this point is that the format is fully and clearly described by the platform independent model, and the industry standard anlaysis and development approaches can be applied directly using either UML or schema as a basis for development, including model driven development or other forms of code generation. In the parlance of the new ITS, the UML definition of the datatypes is the implementable model.

Relationship between the Abstract Datatypes and the ISO datatypes

HL7 V3 has it's own abstract data type specification. This rigorously defines the semantics of the datatypes as they are used in the HL7 development process. The ISO datatypes specification is a computable platform independent specification, but it is technology specific to UML, so it can be treated as an ITS for the abstract datatypes.

As an ITS of the abstract datatypes, the ISO Datatypes must implement enough of the semantics of the abstract datatypes to be useful within it's target context. There is no clear definition of what scope an ITS has to not implement all the features of the the abstract datatypes specification. The existing XML ITS has been used heavily as a guide in this area, and most of the features that are not implemented in the XML ITS are not implemented in this ITS. As an example of this, CD.code is at ST in the abstract specification, which means it has a language property. However in both the XML ITS and the ISO datatypes, CD.code is implemented as a simple String taken from the underlying technology, where there is no language property. This specification deliverately introduces support for some features that the XML ITS did not support, including:

  • support for CD.displayName.language
  • support for the ANY properties on SET, LIST, and BAG

Since the ISO datatypes is an implementation of the abstract datatypes, and supports some features differently to how they are described in the abstract datatypes, this document explains these differences below in the HL7 V3 mapping for the ISO datatypes. In particular, The ISO datatypes includes some features that are not defined in the abstract datatypes specification. The use of these features is not supported in HL7 V3.

Use of attributes in XML

As part of the standard, a normative XML serialization is defined. This XML format uses attributes for simple types that are mapped to a specialization of the UML kernel type Primitive. There has been an ongoing debate concerning the advantages of elements or attributes for simple types. After some substantial debate, the standard uses attributes for the following reasons:

  1. the use of attributes leads to a slightly smaller xml
  2. attributes can be given default values in schema, which are available in a PSVI
  3. attributes are available at the same time as the element that contains them in a SAX process. This is particularly relevant for simple structural codes such as classCode, typeCode etc

None of these arguments are powerful - with the possible exception of #3 - but are considered to outweigh the main argument for using elements instead, which is that some (very old) XML binding tools struggle with attributes.

ISO Datatypes mapping for HL7 V3

The ISO datatypes standard requires that any information processing entity which declares indirect conformance to the standard provides a set of mappings between it's own datatypes and the ISO datatypes.

HL7 V3 declares indirect conformance to the ISO datatypes standard, and this section is provided to fulfill the requirements for the mapping.

Mapping between ISO datatypes and HL7 V3 datatypes =

All public datatypes are supported by HL7 V3, though not all the properties of the ISO datatypes specifications are supported. Also note the mapping sections below that relate to the use of nullFlavor.

ISO Data Type HL7 V3 Datatype Property Notes
ANY ANY See Section ANY properties below
HXIT HXIT ISO controlActIdRef is not yet added to the abstract datatypes (expected in the future), and is therefore not supported in HL7 V3
BL BL All properties are supported
ED ED All properties are supported
ST ST All properties are supported
SC SC SC.code is a CD in ISO datatypes and a CV in the abstract specification, so the use of qualifiers and translations is not supported in HL7 V3
CD CD All properties are supported
CR CR All properties are supported
CE CE All properties are supported
CV CV All properties are supported
CS CS All properties are supported
URL URL All properties are supported
TEL TEL All properties are supported
II II use is not yet added to the abstract datatypes (expected in the future), and is therefore not supported in HL7 V3.

type is not supported in HL7 V3

ADXP ADXP All properties are supported
AD AD All properties are supported
ENXP ENXP All properties are supported
EN EN All properties are supported
TN TN All properties are supported
PN PN All properties are supported
ON ON All properties are supported
QTY QTY All properties are supported
INT INT All properties are supported
CO CO All properties are supported
REAL REAL All properties are supported
RTO RTO All properties are supported
PQ PQ The accuracy property is not supported in HL7 V3. Also see the section PQ.specialValue below
PQR PQR All properties are supported
MO MO All properties are supported
TS TS All properties are supported
COLL -- There is no equivalent to COLL in the V3 datatypes
SET SET All properties are supported
LIST LIST All properties are supported
GLIST GLIST All properties are supported
SLIST SLIST All properties are supported
BAG BAG All properties are supported
IVL IVL All properties are supported. See section about IVL.bounds below
PIVL PIVL All properties are supported
EIVL EIVL All properties are supported
GTS GTS All properties are supported
UVP UVP All properties are supported
NPPD NPPD All properties are supported
PPD PPD All properties are supported


ANY Properties

The ISO ANY has a number of properties that map one way or another to the V3 development process. This section describes these mappings.

nullFlavor: The nullFlavor property maps directly to the abstract ANY.nullFlavor. All the ISO nullFlavors are supported by the abstract nullFlavor, but the converse is not true. Some abstract nullFlavors are not represented as nullFlavors in the ISO datatypes, and other representations must be used:

Abstract NullFlavor ISO Equivalent
NI NI
OTH No direct equivalent. For datatypes derived from Term, populate the codeSystem and leave code blank.
NINF No direct equivalent. For IVL, see the IVL.bounds section below
PINF No direct equivalent. For IVL, see the IVL.bounds section below
UNK UNK
ASKU ASKU
NAV NAV
NASK NASK
TRC No direct equivalent. For PQ, see the PQ.specialValue section below
QS No direct equivalent. For PQ, see the PQ.specialValue section below
MSK MSK
NA NA

updateMode: this maps to the updateMode described as part of the HDF. It is only allowed where the updateMode flag is set appropriately as described by the HDF. There is no direct equivalent in the abstract datatypes

history: this maps to the audit trail described as part of the HDF. It is only allowed where the updateMode flag is set appropriately as described by the HDF. There is no direct equivalent in the abstract datatypes.

flavor: this allows for a datatype specialisation to be conveyed. It's use is described in the Refinement and Localisation specification. There is no direct equivalent in the abstract datatypes.

PQ.specialValue

The ISO PQ has a property specialValue which can carry the value or TRC or QS. These are modelled as NullFlavor values in the abstract datatypes. Using specialValue of TRC or QS is semantically equivalent to using the same code in a nullFlavor.

IVL.bounds

Rather than using NINF and PINF in the IVL type to specify that the upper or lower bound is unknown, like the abstract datatypes, the ISO specification uses the boolean properties lowUnbounded and highUnbounded. The semantic meaning of the two forms of representation is identical.

XML namespace

For the XML format, the serialization defined in the ISO standard applies, but the namespace is urn:hl7-org:v3 instead of uri:iso.org:21090.

Implementers guide to ITS R2

  • comparison between ITS 1 and ITS 2, and notes for implementors

Keith to complete

Things to talk about

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

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.


Examples

  • examples with discussion

Requirements

  • requirements as they are collected

Requirements Basic Datatypes

Requirements Text And Content Data Types

Requirements Coded Data Types (Terminology)

Requirements Identification Data Types

Requirements Name and Address Data Type

Requirements Quantity Data Types

Requirements Collection Data Types

Requirements Timing Specification Data Types

old stuff

Old Introduction

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.

Retrieved from "https://wiki.hl7.org/w/index.php?title=New_ITS_Datatypes_Guide&oldid=13180"