ISO Datatypes

Scope

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.

Normative References

11404

base types to import from 11404

• Boolean
• 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
• Integer
• Real
• Class (base for ANY)
• Set
• Bag
• Sequence
• characterstring - but it's not unicode
• Octet + OctetString
• objectidentifier
• Optional for nil?

Reference to UML 2

base types imported from UML 2:

• classifier
• Boolean
• Integer
• Real
• String
• Sequence
• Set
• Bag

Terms and Definitions

Should not include anything in 11404 terms and definitions?

• HL7
• CEN
• UML required references

Conformance

??

Datatypes

Summary

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.

Template

This section lays out the template that should be generally followed for each type.

Group Name

UML diagram

then for each datatype:

Name

Definition(Intension)

Discussion of scope, usage ([+Extension])

Formal definition in 11404 language

Further discussion about why it is defined the way it is.

Properties

For each property

 Name

 Definition (+parameters if any)

 Discussion of usage

Basic Datatypes

Basic Datatypes that provide infrastructural support for specific datatypes that are defined in subsequent sections.

ANY

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 appropriate use of all three of the attributes on ANY is intimately bound to the implementation specification with which they are used. Generally the environment will need to establish special ways to control their use.

Attributes

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.

Possible Values for nullFlavor:

NI	NoInformation	No information whatsoever can be inferred from this exceptional value. This is the most general exceptional value. It is also the default exceptional value
UNK	unknown	A proper value is applicable, but not known
ASKU	asked but unknown	Information was sought but not found (e.g., patient was asked but didn\’t know)
NASK	not asked	This information has not been sought (e.g., patient was not asked)
NAV	temporarily unavailable	Information is not available at this time but it is expected that it will be available later
MSK	masked	There is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information. Warning: Using this null flavor does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.
NA	not applicable	No proper value is applicable in this context (e.g., last menstrual period for a male)

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 Possible Values for UpdateMode:

A	Add	The item was (or is to be) added, having not been present immediately before.
D	Delete	The item was (or is to be) removed (sometimes referred to as deleted)
R	Replace	The item existed previously and has (or is to be) revised.
AR	Add or Replace	The item was (or is to be) either added or replaced. (This option is included to support one specific case, discussed below. Its general use is discouraged, the preferred methodology is to use the combination of the individual Add and Replace values.)
N	No Change	There was (or is to be) no change to the item.This is primarily used when this element has not changed, but other attributes in the instance have changed.
U	Unknown	It's not specified whether the item was (or is to be) added, revised, or not changed

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.

Invariants

• 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

HXIT

Protected - not for use outside the datatypes in this specification

Definition: Information about the history of this value: period of validity and a reference to an identified event that established this value as valid.

Todo: Formal definition in 11404 language

Attributes

validTime : IVL(TS): The time interval during which the given information was, is, or is expected to be valid.

controlActIdRef : II: The identifier of the event associated with setting the datatype to its specified value. By referencing a particular event, the property links to all of the information surrounding that event, such as who made the change, when it was made, why it was made, what system originated the change, etc, as specified in the implementation specification.

Invariants

• The HXIT must have a valid time if it is not null
• The II cannot have a history on an updateMode

OCL for invariants:

 -- this constraint is not part of the abstract model. It may be relaxed
 -- if a use case presents
 inv "must have a valid time": validTime.oclIsDefined and validTime.isNotNull
 inv "no updateMode or History": (validTime.oclIsUndefined or validTime.noUpdateOrHistory)
      and (controlActIdRef.oclIsUndefined or controlActIdRef.noUpdateOrHistory)

BL

Specializes ANY

Definition: BL stands for the values of two-valued logic. A BL value can be either true or false, or, as any other value may be NULL.

Todo: Formal definition in 11404 language

With any data value potentially being NULL, the two-valued logic is effectively extended to a three-valued logic as shown in the following truth tables:

NOT			AND	true	false	NULL		OR	true	false	NULL
true	false		true	true	false	NULL		true	true	true	True
false	true		false	false	false	false		false	true	false	NULL
NULL	NULL		NULL	NULL	false	NULL		NULL	true	NULL	NULL

Where a boolean operation is performed upon 2 data types with different nullFlavors, the nullFlavor of the result is the first common ancestor of the 2 different nullFlavors, though conformant applications may also create a result that is any common ancestor (such as NI)

Attributes

value: Boolean: The value of the BL if it is non Null.

Invariants

• The BL must have a value if it is not null

OCL for invariants:

 inv "no value if null": isNull implies value.oclIsUndefined