Difference between revisions of "New ITS Datatypes Guide"
Line 31: | Line 31: | ||
== New datatypes ITS Design Philosophy == | == 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. | ||
+ | |||
+ | |||
+ | For a number of reasons, the abstract sp | ||
* design philosophy - why we did what we did, and some specific notes about things we did | * design philosophy - why we did what we did, and some specific notes about things we did | ||
The datatypes have been developed according to the following principles: | The datatypes have been developed according to the following principles: |
Revision as of 14:14, 23 February 2007
Contents
- 1 Introduction
- 2 Design philosophy
- 3 ISO Datatypes mapping for HL7 V3
- 4 Implementers guide to ITS R2
- 5 Relationship with HL7v3 datatypes release 1 (abstract and XML ITS)
- 6 Examples
- 7 Requirements
- 7.1 Requirements Basic Datatypes
- 7.2 Requirements Text And Content Data Types
- 7.3 Requirements Coded Data Types (Terminology)
- 7.4 Requirements Identification Data Types
- 7.5 Requirements Name and Address Data Type
- 7.6 Requirements Quantity Data Types
- 7.7 Requirements Collection Data Types
- 7.8 Requirements Timing Specification Data Types
- 8 old stuff
Introduction
The ITS datatypes guide provides supporting information for the joint ISO / HL7 healthcare datatypes specification. The joint ISO/HL7 healthcare datatypes is both an implementation of the HL7 abstract datatypes and a platform independent datatypes specification that stands alone, independent of the abstract specification, for general use in other healthcare specifications.
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 develop between HL7 and ISO. For this reason, the design philosophy is divided into two parts. the first part deals with aspects of this specification as an ITS for the HL7 abstract specification, and the second part details with the design philosophy of the ISO datatypes specification.
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.
For a number of reasons, the abstract sp
- design philosophy - why we did what we did, and some specific notes about things we did
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
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]\]
notes - things to rationalise:
- why short names not human understandable names
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.
ISO Datatypes mapping for HL7 V3
Implementers guide to ITS R2
- comparison between ITS 1 and ITS 2, and notes for implementors
Keith to complete
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
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.