This International Standard specifies the shared semantics for a collection of healthcare related datatypes used in a number of health related information standards. This standard declares these datatypes using the terminology, notations and datatypes defined in 11404 rev 2003. In addition to defining the datatypes in these terms, this standard also provides UML definitions of the same datatypes using the terminology, notation and types defined in UML 2.0.
The purpose of this international standard is to provide an agreed common semantic basis for exchanging basic concepts that are commonly encountered in healthcare environments. This standard is based on considerable input from HL7, CEN, and past ISO work on healthcare datatypes.
It is expected that other healthcare information standards and specifications will define mappings for the datatypes specified herein, though direct reference or a mixture of direct reference and mappings may also be expected.
What is a datatype?
There is no clear definition of exactly what is a datatype and where a more complex structure would be appropriate. Generally the definitions of the scope of datatypes revolve around one or more of the following three notions:
- The relationship between equality and identity
- Coherency of a single concept
Since of both of these concepts are inherently a matter of perspective, the selection criteria for the datatypes defined in this standard is based on the set that has emerged from the debates held within the various stakeholder standards bodies that define healthcare information standards. Since healthcare information standards and specifications are expected to provide mappings to this standard, the process has been deliberately inclusive. These other standards may choose to represent these datatypes with other more complex structures, but should explain how to interconvert these structures with the datatypes defined herein.
base types to import from 11404
- State (for CS? - or should this be enumerated?)
- Character - as the basis for String?
- date-and-time? this is 8601 based, but a structured time. if 8601 based, could be used? but not for UML? the problem is that it is not well documented, and it appears that the right parts are not optional
- Class (base for ANY)
- characterstring - but it's not unicode
- Octet + OctetString
- Optional for nil?
Reference to UML 2
base types imported from UML 2:
Terms and Definitions
Should not include anything in 11404 terms and definitions?
- UML required references
Each datatype defined in this specification is defined in two different ways. They are defined in terms of the datatype specification language defined in ISO 11404. In addition, the same datatype is defined in UML using primitive types taken from the UML kernel package. The UML definition is provided to foster software driven implementation of these datatypes.
This UML diagram includes all the types in a single package for ease of reference. More detailed UML diagrams are included with the the datatype definitions below.
This section lays out the template that should be generally followed for each type.
then for each datatype:
Discussion of scope, usage ([+Extension])
Formal definition in 11404 language
Further discussion about why it is defined the way it is.
For each property
Definition (+parameters if any)
Discussion of usage
Basic Datatypes that provide infrastructural support for specific datatypes that are defined in subsequent sections.
Definition: Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every public concrete type is a specialization of this general abstract DataValue type.
Todo: Formal definition in 11404 language
The use of all 3 attributes on ANY are controlled by flags in the modelling process. They are defined on ANY, but may only be used when they have not been constrained by the use of OCL or schematron statements in the XUM\’s that make the modelling flags explicit.
nullFlavor : NullFlavor: Indicates the reason that the value is unknown.
ANY is a nullable type; any instances of descendent types may also be null. Null is a special value and implementations usually have special logic for handling this. The nullFlavor attribute carries information describing why the value is null. An instance of the type ANY with a nullFlavor of NI is semantically equivalent to a null instance. If the nullFlavor of is not null, then all other attributes must be null. If the nullFlavor is null, then some of the other properties may be constrained to be not null; the invariants for the appropriate type specify the non-null attributes in this case.
updateMode : UpdateMode: The principal purpose of UpdateMode is to allow a sending system to identify to a receiving system: • the changes that have occurred in an object controlled by the sending system; or • the changes that the sender desires to be made in an object controlled by the receiving system
history : HXIT: Allows the changes to an individual attribute or association to be associated with an identified event that changed it. The event may convey such information as event time, author, authoring organization, data-enterer, reason, and any other accountability information as described by the environment in which the type is used.
- Update Mode is not allowed for null values.
- History is not allowed for null values.
OCL for invariants:
def: let isNull : Boolean = nullFlavor.oclIsDefined def: let isNotNull : Boolean = not isNull -- these are defined in order to help control updateMode and history def: let noUpdate : Boolean = updateMode.oclIsUndefined def: let noHistory : Boolean = history.oclIsUndefined def: let noUpdateOrHistory : Boolean = noUpdate and noHistory -- these 2 assertions are uncharted waters. we disallow use of updateMode and -- history with null until convincing use cases arise inv "No UpdateMode on null": isNull implies updateMode.oclIsUndefined inv "No History on null": isNull implies history.oclIsUndefined