This wiki has undergone a migration to Confluence found Here

Difference between revisions of "ISO Datatypes"

From HL7Wiki
Jump to navigation Jump to search
 
(68 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Scope ==
+
== Introduction ==
  
This International Standard specifies the shared semantics for a
+
This is a project under the [[CEN ISO HL7 Joint Initiative]]
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
+
This is a project page for the ISO datatypes activity led by Grahame Greive for HL7, and Tom Marley for ISO.
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
+
The project is currently in reconciliation activity -- with the work being done on the XML SIG telcons [[XML SIG#Conference_Calls]].
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? ===
+
Note: this page was a full draft of the ISO datatypes document - this is now maintained in the hl7 svn repository, and published in the Ballot pack [http://www.hl7.org/v3ballot/html/infrastructure/its_r2/isodatatypes.htm].
  
In ISO 11404, a "datatype" is defined as:
+
== Project Plan as of Jan 2008 ==
  
  datatype: set of distinct values, characterized by properties of
+
{| border="1"
  those values, and by operations on those values
 
 
 
  A datatype consists of three main features: a value space, a set
 
  of properties, and a set of characterizing operations.
 
 
 
Generally the definitions of the scope of datatypes revolve around either or
 
both of the following three notions:
 
* The relationship between equality and identity
 
* Coherency of a single concept
 
 
 
Since 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.
 
 
 
=== Definitions of Datatypes ===
 
 
 
This specification defines a series of named data types.
 
Each datatype defined in this specification is allocated both a
 
short name and a long name. The formal name of the data type
 
is the short name. Each datatype is defined in two different
 
ways:
 
* in terms of the datatype specification language and types defined in ISO 11404
 
* in UML using primitive types taken from the UML kernel package
 
 
 
The 11404 definition is provided to ensure continuity between
 
this specification and the 11404 GPDs, while the UML definition
 
is provided to foster software driven implementation of these datatypes.
 
 
 
Some of the names of these datatypes bear superficial similarity
 
to similar datatypes defined in other specifications. For instance,
 
this specification defines a type REAL and there is a type Real
 
in the ISO 11404 specification.
 
 
 
This specification is not attempting to redefine or replace the
 
definition of Real in ISO 11404. Instead a new type that builds
 
on the functionality of Real is defined. Where there is name clashes
 
between the datatypes defined in this specification and any other
 
specification, implementers should use some form of namespacing
 
or name mangling to ensure that the names of the datatypes do not
 
cause confusion.
 
 
 
=== Mapping to this datatypes specification ===
 
 
 
Like 11404, this specification anticipates that these datatypes
 
will be used within other specifications. These specifications
 
must specify how the datatypes and features described with this
 
specification are implemented within the specification. Datatypes
 
may be adopted and used directly, or they may be mapped to other
 
datatypes or structures in different places, or they may not be
 
supported at all.
 
 
 
Each specification that uses these datatypes should publish a
 
document or section describing the mapping, and providing assistance for
 
implementors to interconvert data between specifications.
 
 
 
As an example, this specification includes the attribute nullFlavor
 
on the ANY type. The CEN 13606 standard provides support for the
 
concept of null on the ELEMENT structure. This makes the existence
 
of nullFlavor on ANY inappropriate in the context of the 13606
 
implementation. CEN 13606 would therefore provide an implementation
 
guide explaining how nullFlavor is implemented as an attribute of
 
the ELEMENT class rather than on the ANY type.
 
 
 
== 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 ==
 
??
 
 
 
== Conventions ==
 
 
 
== Datatypes ==
 
 
 
=== Summary ===
 
 
 
[[Image:iso_datatypes_all.gif]]
 
 
 
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.
 
 
 
=== Basic Datatypes ===
 
 
 
Basic Datatypes that provide infrastructural support for specific datatypes that are defined in subsequent sections.
 
 
 
[[Image:iso_datatypes_basic.gif]]
 
 
 
==== 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.
 
 
 
'''templateId : String''': Signals the imposition of a set of constraints on the
 
datatype. The main purpose of specifying a template that has been used to further
 
constrain the datatype is to support validation. No automated processing should
 
depend on the content of the templateId attribute.
 
 
 
'''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
 
  inv "No TemplateId on Null": isNull implies templateId.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 "value required if not null": isNotNull implies value.oclIsDefined
 
 
 
  -- nullFlavor invariants
 
  inv "no value if null": isNull implies value.oclIsUndefined
 
 
 
 
 
=== Text And Content Data Types ===
 
 
 
Basic Datatypes that provide infrastructural support for specific datatypes that are defined in subsequent sections.
 
 
 
[[Image:iso_datatypes_text.gif]]
 
 
 
==== Content ====
 
 
 
Specializes ANY. This is a protected type - it cannot be used outside of this specification
 
 
 
'''Definition''': Content is an abstract type introduced to define of language
 
 
 
'''Todo''': Formal definition in 11404 language
 
 
 
'''Attributes'''
 
 
 
'''language: Code''': The human language of the content||Valid codes are taken from the Internet standard RFC 3066 (http://www.ietf.org/rfc/rfc3066.txt). The HL7 OID for this domain is 2.16.840.1.113883.5.57.
 
 
 
'''Invariants'''
 
 
 
 
 
OCL for invariants:
 
 
 
  -- nullFlavor invariants
 
  inv "no language if null": isNull implies langauge.oclIsUndefined
 
 
 
==== Data ====
 
 
 
Specializes Content. This is a protected type - it cannot be used outside of this specification.
 
 
 
'''Definition''': Data is an abstract type introduced as a common type for the definition of properties shared between ED and ED.thumbnail.
 
 
 
'''Todo''': Formal definition in 11404 language
 
 
 
 
 
'''Attributes'''
 
 
 
'''value : Binary''': The human language of the content
 
 
 
'''charset : Code''': For character-based encoding types, this property specifies the character set and character encoding used in the value that contains the content of the ED. The charset shall be identified by an Internet Assigned Numbers Authority (IANA) Charset Registration [http://www.iana.org/assignments/character-sets] in accordance with [[RFC 2978|http://www.ietf.org/rfc/rfc2978.txt]] (http://www.ietf.org/rfc/rfc2978.txt). The charset property needs to be known where the data of the ED is character type data in any form. If the data is provided directly in the value attribute, then the charset must be known. If the data is provided as a reference, and the access method does not provide the charset for the data (such as by a mime header), then the charset must be conveyed as part of the ED.
 
 
 
'''compression : Compression''': Indicates whether the raw byte data is compressed, and what compression algorithm was used
 
 
 
Possible Values for Compression:
 
 
 
{|
 
|DF  ||deflate  ||The deflate compressed data format as specified in RFC 1951 \[http://www.ietf.org/rfc/rfc1951.txt\]
 
|-
 
|GZ  ||gzip  ||A compressed data format that is compatible with the widely used GZIP utility as specified in RFC 1952 \[http://www.ietf.org/rfc/rfc1952.txt\] (uses the deflate algorithm).
 
|-
 
|ZL  ||zlib  ||A compressed data format that also uses the deflate algorithm. Specified as RFC 1950 \[http://www.ietf.org/rfc/rfc1952.txt\]
 
|-
 
|Z  ||compress  ||Original UNIX compress algorithm and file format using the LZC algorithm (a variant of LZW). Patent encumbered and less efficient than deflate
 
|-
 
|}
 
 
 
'''mediaType : Code''': Identifies the type of the encapsulated data and identifies a method to interpret or render the data. The IANA defined domain of media types is established by the Internet standard [[RFC 2045|http://www.ietf.org/rfc/rfc2045.txt]] (http://www.ietf.org/rfc/rfc2045.txt) and [[2046|http://www.ietf.org/rfc/rfc2046.txt]] (http://www.ietf.org/rfc/rfc2046.txt).
 
 
 
'''encoding : EncodingType''': Identifies the encoding type used in the value content. The content in the value may be either base64Binary content (refer xml schema defintiion (todo)), or it may be unencoded
 
 
 
Possible Values for Encoding Type:
 
 
 
{|
 
|RAW||Raw||Data is presented in it\’s raw form||
 
|-
 
|BASE64||Base 64||Data is encoded using the base 64 algorithm||
 
|-
 
|}
 
 
 
 
 
'''Invariants'''
 
 
 
OCL for invariants:
 
 
 
  -- nullFlavor invariants:
 
  inv "no value if null": isNull implies value.oclIsUndefined
 
  inv "no charset if null": isNull implies charset.oclIsUndefined
 
  inv "no compression if null": isNull implies compression.oclIsUndefined
 
  inv "no mediaType if null": isNull implies mediaType.oclIsUndefined
 
 
 
 
 
==== ED ====
 
 
 
Specializes Data
 
 
 
'''Definition''': Data that is primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information in as defined by a different standard (e.g., XML-signatures.) Encapsulated data can be present in two forms, inline or by reference. Inline data is communicated or moved as part of the encapsulated data value, whereas by-reference data may reside at a different (remote) location. The data is the same whether it is located inline or remote.
 
 
 
'''Todo''': Formal definition in 11404 language
 
 
 
'''Attributes'''
 
 
 
'''reference : URI''' : A telecommunication address (TEL), such as a URL for HTTP or FTP, which will
 
resolve to precisely the same binary data that could as well have been provided as inline data. The
 
semantic value of an encapsulated data value is the same, regardless whether the data is present
 
inline data or just by-reference. However, an encapsulated data value without inline data behaves
 
differently, since any attempt to examine the data requires the data to be downloaded from the
 
reference. An encapsulated data value may have both inline data and a reference
 
 
 
'''integrityCheck : Binary''': The integrity check is a short binary value representing a cryptographically
 
strong checksum that is calculated over the binary data. The purpose of this property,
 
when communicated with a reference is for anyone to validate later whether the reference still
 
resolved to the same data that the reference resolved to when the encapsulated data value with
 
reference was created.
 
 
 
'''integrityCheckAlgorithm : IntegrityCheckAlgorithm''': Specifies the algorithm used to compute the
 
integrityCheck value
 
 
 
Possible Values for integrityCheckAlgorithm:
 
 
 
{|
 
|SHA1||secure hash algorithm - 1||This algorithm is defined in FIPS PUB 180-1: Secure Hash Standard. As of April 17, 1995
 
|-
 
|SHA256||secure hash algorithm - 256||secure hash algorithm - 256 This algorithm is defined in FIPS PUB 180-2: Secure Hash Standard
 
|-
 
|}
 
 
 
 
 
'''thumbnail : Data''': An abbreviated rendition of the full data. A thumbnail requires significantly
 
fewer resources than the full data, while still maintaining some distinctive similarity with the full data.
 
A thumbnail is typically used with by-reference encapsulated data. It allows a user to select
 
data more efficiently before actually downloading through the reference.
 
 
 
'''Invariants'''
 
 
 
* An integrityCheckAlgorithm must be provided if an integrityCheck is provided
 
* Either reference or data must be provided if not null
 
 
 
OCL for invariants:
 
 
 
  inv "integrityCheckAlgorithm required": integrityCheck.oclIsDefined implies integrityCheckAlgorithm.oclIsDefined
 
  inv "reference or value": isNotNull implies ((reference.oclIsDefined and reference.isNotNull) or value.oclIsDefined)
 
 
 
  -- nullFlavor invariants
 
  inv "no reference if null": isNull implies reference.oclIsUndefined
 
  inv "no integrityCheck if null": isNull implies integrityCheck.oclIsUndefined
 
  inv "no integrityCheckAlgorithm if null": isNull implies integrityCheckAlgorithm.oclIsUndefined
 
  inv "no thumbnail if null": isNull implies (thumbnail.oclIsUndefined or thumbnail.isNull)
 
  inv "thumbnail has value": thumbnail.oclIsDefined and thumbnail.isNotNull implies thumbnail.value.oclIsDefined
 
 
 
 
 
==== ST (Character String) ====
 
 
 
Specializes Content
 
 
 
'''Definition''': The character string data type stands for text data, primarily
 
intended for machine processing (e.g., sorting, querying, indexing, etc.) Used
 
for names, symbols, and formal expressions.
 
 
 
'''Attributes'''
 
 
 
'''value : String''': The actual content of the string. String values are always
 
Unicode.
 
 
 
'''Invariants'''
 
 
 
OCL for invariants:
 
 
 
  -- nullFlavor invariants
 
  inv "null or content" : isNull xor (value.oclIsDefined and value.size > 0)
 
 
 
==== SC (Coded String) ====
 
 
 
Specializes ST
 
 
 
'''Definition''': A character string that optionally may have a code attached.
 
The text must always be present if a code is present. The code is often a
 
local code.  SC is used in cases where coding is exceptional (e.g., user text
 
messages are essentially text messages, and a printable message is the
 
important content. Yet, sometimes messages come from a catalog of
 
canned messages, which SC allows to reference.
 
 
 
'''Attributes'''
 
 
 
'''code : Term''': The coded value associated with the string.
 
 
 
 
 
'''Invariants'''
 
 
 
* If there is a code, there must also be some content on the SC (and therefore the SC must not be null)
 
 
 
OCL for invariants:
 
 
 
  inv "no code if no value" : code.notNull implies isNotNull
 
  inv "no updateMode or History": (code.oclIsUndefined or code.noUpdateOrHistory)
 
 
 
=== Coded Data Types (Terminology) ===
 
 
 
These datatypes provide support for use of codes and terms from terminologies and classifications.
 
 
 
[[Image:iso_datatypes_terms.gif]]
 
 
 
====Term ====
 
 
 
Specializes ANY. Protected - not for use outside the datatypes in this specification
 
 
 
'''Definition''': Represents a term taken from some defined codesystem or terminology.
 
This is a private class. One of the specialisations should be used for actually
 
representing concepts in practice.
 
 
 
'''Attributes'''
 
 
 
'''code : String''': The plain code symbol defined by the code system.
 
if the code value is empty or null, then there is no code in the code
 
system that represents the concept.
 
 
 
'''codeSystem : Uid''': Specifies the code system that defines the code,
 
or code System in which no code was found. Code systems shall be referred
 
to by a UID, which allows unambiguous reference to standard code systems
 
and other local codesystems. Where either ISO or HL7 have assigned UID
 
to code Systems, then these UIDs shall be used. Local sites must use
 
their ISO Object Identifier (OID) to construct a globally unique local
 
coding system identifier.
 
 
 
'''codeSystemName : String''': The common name of the coding system. The code
 
system name has no computational value. The purpose of a code system name is
 
to assist an unaided human interpreter of a code value to interpret
 
codeSystem.
 
 
 
'''codeSystemVersion : String''': If applicable, a version descriptor defined
 
specifically for the given code system.
 
 
 
'''displayName : ST''': A name or title for the code, under which the sending
 
system shows the code value to its users. displayName is included both as a
 
courtesy to an unaided human interpreter of a code value and as a
 
documentation of the name used to display the concept to the user.
 
The display name has no functional meaning; it can never exist without a
 
code; and it can never modify the meaning of code.
 
 
 
'''originalText : ST''': The text or phrase used as the basis for the coding.
 
The original text exists in a scenario where an originator of the information
 
does not assign a code, but where the code is assigned later by a coder
 
(post-coding.) In the production of a concept descriptor, original text may
 
thus exist without a code.
 
 
 
'''originalTextReference : URI''': A reference to the source of the text
 
or phrase used as the basis for the coding. This provides an alternative
 
to providing the originalText directly. Only one of originalText and
 
originalTextReference may be used.
 
 
 
NOTE: The details of the link between
 
different artifacts of medical information (e.g., document and coded result)
 
is outside the scope of this specification and may be further proscribed
 
in specifications that use this specification.
 
 
 
'''qualifier : Sequence(CR)''': Specifies additional codes that increase the
 
specificity of the primary code. Qualifiers constrain the meaning of the
 
primary code, but cannot negate it or change it’s meaning to that of another
 
value in the primary coding system. Qualifiers can only be used according to
 
well-defined rules of post-coordination. A value of type CD may only have
 
qualifiers if it’s code system defines the use of such qualifiers or if there
 
is a third code system that specifies how other code systems may be combined
 
 
 
'''Invariants'''
 
 
 
* A codesystem is required if not null
 
* codeSystemName must be null if codeSystem is null
 
* codeSystemVersion must be null if codeSystem is null
 
* Qualifiers can only be specified if a code is provided
 
* Can only provide either an originalText or an originalTextReference, but not both.
 
 
 
OCL for invariants:
 
  def: let hasOriginalText : Boolean = (originalText.oclIsDefined and originalText.isNotNull) or
 
          (originalTextReference.oclIsDefined and originalTextReference.isNotNull)
 
  def: let hasCode : Boolean = code.oclIsDefined
 
  def: let hasCodeSystem : Boolean = codeSystem.oclIsDefined
 
 
 
  inv "null or code and/or originalText": notNull implies (hasCode or hasOriginalText or hasCodeSystem)
 
  inv "qualifiers only if code": qualifier->size > 0 implies code.oclIsDefined
 
  inv "code only if codeSystem": code.oclIsDefined implies codeSystem.oclIsDefined
 
  inv "codeSystemName only if codeSystem": codeSystemName.oclIsDefined implies codeSystem.oclIsDefined
 
  inv "codeSystemVersion only if codeSystem": codeSystemVersion.oclIsDefined implies codeSystem.oclIsDefined
 
  inv "displayName only if code": displayName.oclIsDefined implies code.oclIsDefined
 
  inv "no updateMode or History": (displayName.oclIsUndefined or displayName.noUpdateOrHistory) and
 
      (originalText.oclIsUndefined or originalText.noUpdateOrHistory)
 
  inv "cannot provide both originalText and originalTextReference": (originalText.oclIsUndefined or originalText.isNull) xor
 
          (originalTextReference.oclIsUndefined or originalTextReference.isNull)
 
 
 
  -- nullFlavor invariants
 
  inv "no code if null": isNull implies code.oclIsUndefined
 
  inv "no codeSystem if null": isNull implies codeSystem.oclIsUndefined
 
  inv "no codeSystemName if null": isNull implies codeSystemName.oclIsUndefined
 
  inv "no codeSystemVersion if null": isNull implies codeSystemVersion.oclIsUndefined
 
  inv "no displayName if null": isNull implies displayName.oclIsUndefined
 
  inv "no originalText if null": isNull implies originalText.oclIsUndefined
 
  inv "no originalTextReference if null": isNull implies originalTextReference.oclIsUndefined
 
  inv "no qualifier if null": isNull implies qualifier.oclIsUndefinedCR)
 
 
 
 
 
==== CD (Concept Descriptor) ====
 
 
 
Specializes Term
 
 
 
'''Definition''': A CD represents any kind of concept usually by giving a code
 
defined in a code system. A CD can contain the original text or phrase that
 
served as the basis of the coding and one or more translations into different
 
coding systems. A CD can also contain qualifiers to describe, e.g., the
 
concept of a "left foot" as a postcoordinated term built from the primary
 
code "FOOT" and the qualifier "LEFT". In cases of an exceptional value, the
 
CD need not contain a code but only the original text describing that concept.
 
 
 
'''Attributes'''
 
 
 
'''translation : Sequence(Translation)''': A set of other concept descriptors that
 
translate this concept descriptor into other code systems or into synonyms
 
in the same code system. Each element of the translation set was translated
 
from the containg CD. Each translation may, however, also contain translations.
 
Thus, when a code is translated multiple times the information about which code
 
served as the input to which translation will be preserved.
 
 
 
'''Invariants'''
 
 
 
OCL for invariants:
 
  -- so you can make constraints ffrom outside that the term or on of it's translations belongs to the specified codeSystem
 
  def: let fromCodeSystem(system : Uid) : Boolean = codeSystem = system or translation->select(t | t.fromCodeSystem(system))->size > 0
 
  inv "no updateMode or History": translation->forAll(t | t.oclIsDefined and t.noUpdateOrHistory)
 
 
 
  -- nullFlavor invariants
 
  inv "no translations if null": isNull implies translations->size() = 0
 
 
 
 
 
====CR (Concept Role) ====
 
 
 
 
 
'''Definition''': A concept qualifier code with optionally named role. Both
 
qualifier role and value codes must be defined by the coding system of the
 
CD containing the concept qualifier. For example, if SNOMED RT defines a
 
concept "leg", a role relation "has-laterality", and another concept "left",
 
the concept role relation allows to add the qualifier "has-laterality: left"
 
to a primary code "leg" to construct the meaning "left leg". The use
 
of qualifiers is strictly governed by the code system used. CD does
 
not permit using code qualifiers with code systems that do not provide
 
for qualifiers (e.g. pre-coordinated systems, such as LOINC, ICD-10 PCS.)
 
 
 
'''TODO: this definition is a problem'''
 
 
 
'''Attributes'''
 
 
 
'''name : CV''': Specifies the manner in which the concept role value
 
contributes to the meaning of a code phrase. For example, if SNOMED RT
 
defines a concept "leg", a role relation "has-laterality", and another
 
concept "left", the concept role relation allows to add the qualifier
 
"has-laterality: left" to a primary code "leg" to construct the meaning
 
"left leg". In this example, name is "has-laterality". If the parent
 
CD.codeSystem allows postcoordination but no role names (e.g. SNOMED)
 
then name can be null
 
 
 
'''value : Term''': The concept that modifies the primary code of a
 
code phrase through the role relation. For example, if SNOMED RT
 
defines a concept "leg", a role relation "has-laterality", and another
 
concept "left", the concept role relation allows adding the qualifier
 
"has-laterality: left" to a primary code "leg" to construct the
 
meaning "left leg". In this example, value is "left". value is of type
 
Term and thus can in turn have qualifiers, allowing qualifiers to nest.
 
Qualifiers can only be used as far as the underlying code system defines
 
them. It is not allowed to use any kind of qualifiers for code systems
 
that do not explicitly allow and regulate such use of qualifiers.
 
 
 
'''inverted : Boolean''': Indicates if the sense of name is inverted.
 
This can be used in cases where the underlying code system defines
 
inversion but does not provide reciprocal pairs of role names. By
 
default, inverted is false. Roles may only be inverted if the
 
underlying coding system allows such inversion, and defines the exact
 
implications of using the inverted flag. Notably, if a coding
 
system defines roles in inverse pairs or intentionally does not define
 
certain inversions, the appropriate role code (e.g. "caused-by") must
 
be used rather than inversion. It must be known whether the inverted
 
property is true or false, since if it is null, the role cannot be
 
interpreted.
 
 
 
'''Invariants'''
 
 
 
* A value must be provided if the CR is not null
 
 
 
OCL for invariants:
 
 
 
  inv "null or value": notNull implies value.oclIsDefined and value.isNotNull
 
  inv "no updateMode or History": (name.oclIsUndefined or name.noUpdateOrHistory)
 
      and (value.oclIsUndefined or value.noUpdateOrHistory)
 
 
 
==== Translation ====
 
 
 
Specializes Term. This is a protected type that should not be used outside this specification.
 
 
 
'''Definition''': A translation from from one codeSystem to another or within
 
the same codeSystem. This type extends a basic term by adding a reason for
 
providing the translation.
 
 
 
'''Attributes'''
 
 
 
'''purpose : TranslationPurpose''': The reason that this translation was
 
provided.
 
 
 
Possible Values for TranslationPurpose:
 
 
 
? TODO: what purposes can there be?
 
 
 
 
 
==== CE (Coded With Equivalents) ====
 
 
 
Specializes CD
 
 
 
'''Definition''': Coded data that consists of a coded value and, optionally,
 
coded value(s) from other coding systems that identify the same concept.
 
Used when alternative codes may exist, but post coordination is not
 
appropriate.
 
 
 
'''Invariants'''
 
 
 
* No Qualifiers on a CE
 
* The translations are not allowed to contain qualifiers. '''Note : This policy is under review'''
 
 
 
OCL for invariants:
 
 
 
  inv "no qualifiers": qualifier.size = 0
 
  -- this is a little controversial
 
  inv "no qualifiers on translations": translation->forAll(t | t.qualifier->size = 0)
 
 
 
 
 
====CV (Coded Value) ====
 
 
 
Specializes CE
 
 
 
'''Definition''': Coded data, specifying only a code, code system, and optionally
 
display name and original text. Used only as the type of properties of other
 
data types. CV is used when any reasonable use case will require only a
 
single code value to be sent. Thus, it should not be used in circumstances where
 
multiple alternative codes for a given value are desired. This type may be used
 
with both the CNE (coded, non-extensible) and the CWE (coded, with extensibility)
 
domain qualifiers
 
 
 
'''Invariants'''
 
 
 
* No translations are allowed
 
 
 
OCL for invariants:
 
  inv "no translations": translation.size = 0
 
 
 
 
 
====CS (Coded Simple Value) ====
 
 
 
Specializes ANY
 
 
 
'''Definition''': Coded data in its simplest form, where only the code is not
 
predetermined. The code system and code system version are implied and fixed
 
by the context in which the CS value occurs. Due to it's highly restricted
 
functionality, CS can only be used for simple structural attributes with
 
highly controlled and stable value sets.
 
 
 
'''Attributes'''
 
 
 
'''code : String''': The plain code symbol defined by the code system.
 
if the code value is empty or null, then there is no code in the code
 
system that represents the concept.
 
 
 
'''Invariants'''
 
 
 
OCL for invariants:
 
 
 
  -- nullFlavor invariants
 
  inv "no code if null": isNull implies code.oclIsUndefined
 
 
 
=== Identification Data Types ===
 
 
 
These datatypes provide support for various identifiers and URIs.
 
 
 
[[Image:iso_datatypes_misc.gif]]
 
 
 
 
 
 
 
 
 
====II (Instance Identifier) ====
 
 
 
Specializes ANY
 
 
 
'''Definition''': An identifier that uniquely identifies a
 
thing or object. Examples are object identifier for HL7
 
RIM objects, medical record number, order id, service catalog
 
item id, Vehicle Identification Number (VIN), etc. Instance
 
identifiers are defined based on ISO object identifiers.
 
 
 
'''Attributes'''
 
 
 
'''root : Uid''': A unique identifier that guarantees the global
 
uniqueness of the instance identifier. The root alone may be the
 
entire instance identifier. In the presence of a non-null extension,
 
the root is commonly interpreted as the "issuing authority", that
 
is, it is supposed that the root somehow refers to an organization
 
that assigns identifiers sent in the extension. However, the root
 
does not have to be an organizational UID, it can also be a UID
 
specifically registered for an identifier scheme. This field can be either
 
a UUID, an OID, or a special identifier taken from lists that may be
 
published by ISO or HL7.
 
 
 
'''Note: The root should not be supposed to carry semantic meaning – all it does is ensure global computational uniqueness.'''
 
 
 
'''extension: String''': A character string as a unique identifier
 
within the scope of the identifier root. The root and extension scheme
 
effectively means that the concatenation of root and extension must be
 
a globally unique identifier for the item that this II value identifies.
 
 
 
'''assigningAuthorityName : String''': A human readable name or mnemonic
 
for the assigning authority. The Assigning Authority Name has no
 
computational value. The purpose of a Assigning Authority Name is to
 
assist an unaided human interpreter of an II value to interpret the
 
authority. Note: no automated processing must depend on the assigning
 
authority name to be present in any form
 
 
 
'''displayable : Boolean''': Specifies if the identifier is intended for
 
human display and data entry (displayable = true) as opposed to pure
 
machine interoperation (displayable = false).
 
 
 
'''use : Set(IdentifierUse)''': Specifies the intent of the scope or use of
 
this II
 
 
 
Possible Values for use:
 
 
 
{|
 
|Issued||||
 
|-
 
|Verified||||
 
|-
 
|Used||||
 
|-
 
|NonPlayer||||
 
|-
 
|RealWorld||||
 
|-
 
|Record||||
 
|-
 
|Version||||
 
|-
 
|View||||
 
|-
 
|Reference||||
 
|-
 
|Definitional||||
 
|-
 
|}
 
 
 
 
 
 
 
'''type: IdentifierType''': Specifies the type of the identifier.  The type
 
has no computational value. The purpose of a type is to assist an unaided
 
human interpreter of an II value to interpret the authority. Note: no
 
automated processing must depend on the type to be present in any form
 
 
 
Possible Values for IdentifierType:
 
 
 
 
 
{|
 
|code||title||comment
 
|-
 
|AN||Account number||An identifier that is unique to an account.
 
|-
 
|ANON||Anonymous identifier||An identifier for a living subject whose real
 
identity is protected or suppressed
 
Justification: For public health reporting
 
purposes, anonymous identifiers are occasionally
 
used for protecting patient identity in reporting
 
certain results. For instance, a state health
 
department may choose to use a scheme for
 
generating an anonymous identifier for reporting
 
a patient that has had a positive human
 
immunodeficiency virus antibody test.
 
Anonymous identifiers can be used in PID 3 by
 
replacing the medical record number or other
 
non-anonymous identifier. The assigning
 
authority for an anonymous identifier would be
 
the state/local health department.
 
|-
 
|ANC||Account number Creditor||
 
Class: Financial
 
 
 
A more precise definition of an account number:
 
sometimes two distinct account numbers must be
 
transmitted in the same message, one as the
 
creditor, the other as the debitor.
 
Kreditorenkontonummer
 
|-
 
|AND||Account number debitor||
 
Class: Financial
 
 
 
A more precise definition of an account number:
 
sometimes two distinct account numbers must be
 
transmitted in the same message, one as the
 
creditor, the other as the debitor.
 
Debitorenkontonummer
 
|-
 
|ANT||Temporary Account Number||Class: Financial
 
 
 
Temporary version of an Account Number.
 
 
 
Use Case: An ancillary system that does not
 
normally assign account numbers is the first time
 
to register a patient. This ancillary system will
 
generate a temporary account number that will
 
only be used until an official account number is
 
assigned.
 
|-
 
|APRN||Advanced Practice Registered Nurse number||An identifier that is unique to an advanced
 
practice registered nurse within the jurisdiction of
 
a certifying board
 
|-
 
|BA||Bank Account Number||Class: Financial
 
|-
 
|BC||Bank Card Number Class: Financial
 
 
 
An identifier that is unique to a person’s bank
 
card.
 
|-
 
|BR||Birth registry number
 
|-
 
|BRN||Breed Registry Number
 
|-
 
|CC||Cost Center number||Class: Financial
 
 
 
Use Case: needed especially for transmitting
 
information about invoices.
 
|-
 
|CY||County number
 
|-
 
|DDS||Dentist license number||An identifier that is unique to a dentist within the
 
jurisdiction of the licensing board
 
|-
 
|DEA||Drug Enforcement Administration registration number||An identifier for an individual or organization
 
relative to controlled substance regulation and
 
transactions.
 
 
 
Use case: This is a registration number that
 
identifies an individual or organization relative to
 
controlled substance regulation and transactions.
 
A DEA number has a very precise and widely
 
accepted meaning within the United States.
 
Surprisingly, the US Drug Enforcement
 
Administration does not solely assign DEA
 
numbers in the United States. Hospitals have the
 
authority to issue DEA numbers to their medical
 
residents. These DEA numbers are based upon
 
the hospital’s DEA number, but the authority rests
 
with the hospital on the assignment to the
 
residents. Thus, DEA as an Identifier Type is
 
necessary in addition to DEA as an Assigning
 
Authority.
 
|-
 
|DFN||Drug Furnishing or prescriptive authority Number||An identifier issued to a health care provider
 
authorizing the person to write drug orders
 
 
 
Use Case: A nurse practitioner has authorization
 
to furnish or prescribe pharmaceutical
 
substances; this identifier is in component 1.
 
|-
 
|DL||Driver’s license number
 
|-
 
|DN||Doctor number
 
|-
 
|DPM||Podiatrist license number||An identifier that is unique to a podiatrist within
 
the jurisdiction of the licensing board.
 
|-
 
|DO||Osteopathic License number||An identifier that is unique to an osteopath within
 
the jurisdiction of a licensing board.
 
|-
 
|DR||Donor Registration Number
 
|-
 
|EI||Employee number||A number that uniquely identifies an employee to
 
an employer.
 
|-
 
|EN||Employer number
 
|-
 
|FI||Facility ID
 
|-
 
|GI||Guarantor internal identifier||Class: Financial
 
|-
 
|GL||General ledger number||Class: Financial
 
|-
 
|GN||Guarantor external identifier||Class: Financial
 
|-
 
|HC||Health Card Number
 
|-
 
|JHN||Jurisdictional health number (Canada)||Class: Insurance
 
 
 
2 uses: a) UK jurisdictional CHI number; b) Canadian provincial health card number:
 
|-
 
|IND||Indigenous/Aboriginal||A number assigned to a member of an
 
indigenous or aboriginal group outside of
 
Canada.
 
|-
 
|LI||Labor and industries number
 
|-
 
|LN||License number
 
|-
 
|LR||Local Registry ID
 
|-
 
|MA||Patient Medicaid number||Class: Insurance
 
|-
 
|MB||Member Number An identifier for the insured of an insurance policy
 
(this insured always has a subscriber), usually
 
assigned by the insurance carrier.
 
 
 
Use Case: Person is covered by an insurance
 
policy. This person may or may not be the
 
subscriber of the policy.
 
|-
 
|MC||Patient's Medicare number||Class: Insurance
 
|-
 
|MCD||Practitioner Medicaid number||Class: Insurance
 
|-
 
|MCN||Microchip Number
 
|-
 
|MCR||Practitioner Medicare number||Class: Insurance
 
|-
 
|MD||Medical License number||An identifier that is unique to a medical doctor
 
within the jurisdiction of a licensing board.
 
 
 
Use Case: These license numbers are
 
sometimes used as identifiers. In some states,
 
the same authority issues all three identifiers,
 
e.g., medical, osteopathic, and physician
 
assistant licenses all issued by one state medical
 
board. For this case, the CX data type requires
 
distinct identifier types to accurately interpret
 
component 1. Additionally, the distinction among
 
these license types is critical in most health care
 
settings (this is not to convey full licensing
 
information, which requires a segment to support
 
all related attributes).
 
|-
 
|MI||Military ID number||A number assigned to an individual who has had
 
military duty, but is not currently on active duty.
 
The number is assigned by the DOD or Veterans’
 
Affairs (VA).
 
|-
 
|MR||Medical record number||An identifier that is unique to a patient within a set
 
of medical records, not necessarily unique within
 
an application.
 
|-
 
|MRT||Temporary Medical Record||Number Temporary version of a Medical Record Number
 
 
 
Use Case: An ancillary system that does not
 
normally assign medical record numbers is the
 
first time to register a patient. This ancillary
 
system will generate a temporary medical record
 
number that will only be used until an official
 
medical record number is assigned.
 
|-
 
|NE||National employer identifier||In the US, the Assigning Authority for this value is
 
typically CMS, but it may be used by all providers
 
and insurance companies in HIPAA related
 
transactions.
 
|-
 
|NH||National Health Plan Identifier||Class: Insurance
 
 
 
Used for the UK NHS national identifier.
 
In the US, the Assigning Authority for this value is
 
typically CMS, but it may be used by all providers
 
and insurance companies in HIPAA related
 
transactions.
 
|-
 
|NI||National unique individual identifier||Class: Insurance
 
 
 
In the US, the Assigning Authority for this value is
 
typically CMS, but it may be used by all providers
 
and insurance companies in HIPAA related
 
transactions.
 
|-
 
|NII||National Insurance Organization Identifier||Class: Insurance
 
 
 
In Germany a national identifier for an insurance
 
company. It is printed on the insurance card
 
(health card). It is not to be confused with the
 
health card number itself.
 
Krankenkassen-ID der KV-Karte
 
|-
 
|NIIP||National Insurance Payor Identifier (Payor)||Class: Insurance
 
 
 
In Germany the insurance identifier addressed as
 
the payor.
 
Krankenkassen-ID des Rechnungsempfängers
 
 
 
Use case: a subdivision issues the card with their
 
identifier, but the main division is going to pay the
 
invoices.
 
|-
 
|NNxxx||National Person Identifier||where the xxx
 
is the ISO table 3166 3-character
 
(alphabetic) country code
 
|-
 
|NP||Nurse practitioner number||An identifier that is unique to a nurse practitioner
 
within the jurisdiction of a certifying board.
 
NPI National provider identifier
 
 
 
Class: Insurance
 
 
 
In the US, the Assigning Authority for this value is
 
typically CMS, but it may be used by all providers
 
and insurance companies in HIPAA related
 
transactions.
 
|-
 
|OD||Optometrist license number||A number that is unique to an individual
 
optometrist within the jurisdiction of the licensing
 
board.
 
|-
 
|PA||Physician Assistant number||An identifier that is unique to a physician
 
assistant within the jurisdiction of a licensing
 
board
 
|-
 
|PCN||Penitentiary/correctional institution
 
Number
 
||A number assigned to individual who is
 
incarcerated.
 
|-
 
|PE||Living Subject Enterprise Number||An identifier that is unique to a living subject
 
within an enterprise (as identified by the
 
Assigning Authority).
 
|-
 
|PEN||Pension Number
 
|-
 
|PI||Patient internal identifier||A number that is unique to a patient within an
 
Assigning Authority.
 
|-
 
|PN||Person number||A number that is unique to a living subject within
 
an Assigning Authority.
 
|-
 
|PNT||Temporary Living Subject Number||Temporary version of a Lining Subject Number.
 
|-
 
|PPN||Passport number||A unique number assigned to the document
 
affirming that a person is a citizen of the country.
 
In the US this number is issued only by the State
 
Department.
 
|-
 
|PRC||Permanent Resident Card Number
 
|-
 
|PRN||Provider number||A number that is unique to an individual provider,
 
a provider group or an organization within an
 
Assigning Authority.
 
Use case: This allows PRN to represent either an
 
individual (a nurse) or a group/organization
 
(orthopedic surgery team).
 
|-
 
|PT||Patient external identifier
 
|-
 
|QA||QA number
 
|-
 
|RI||Resource identifier||A generalized resource identifier.
 
 
 
Use Case: An identifier type is needed to
 
accommodate what are commonly known as
 
resources. The resources can include human
 
(e.g. a respiratory therapist), non-human (e.g., a
 
companion animal), inanimate object (e.g., an
 
exam room), organization (e.g., diabetic
 
education class) or any other physical or logical
 
entity.
 
|-
 
|RPH||Pharmacist license number||An identifier that is unique to a pharmacist within
 
the jurisdiction of the licensing board.
 
|-
 
|RN||Registered Nurse Number||An identifier that is unique to a registered nurse
 
within the jurisdiction of the licensing board.
 
|-
 
|RR||Railroad Retirement number
 
|-
 
|RRI||Regional registry ID
 
|-
 
|SL||State license
 
|-
 
|SN||Subscriber Number||Class: Insurance
 
 
 
An identifier for a subscriber of an insurance
 
policy which is unique for, and usually assigned
 
by, the insurance carrier.
 
 
 
Use Case: A person is the subscriber of an
 
insurance policy. The person’s family may be
 
plan members, but are not the subscriber.
 
|-
 
|SR||State registry ID
 
|-
 
|SS||Social Security number
 
|-
 
|TAX||Tax ID number
 
|-
 
|TN||Treaty Number (Canada)||A number assigned to a member of an
 
indigenous group in Canada.
 
 
 
Use Case: First Nation.
 
|-
 
|U||Unspecified identifier
 
|-
 
|UPIN||Medicare/CMS||(formerly HCFA)’s
 
Universal Physician Identification
 
numbers
 
 
 
Class: Insurance
 
|-
 
|VN||Visit number
 
|-
 
|WC||WIC identifier
 
|-
 
|WCN||Workers’ Comp Number
 
|-
 
|}
 
 
 
 
 
'''Invariants'''
 
 
 
* A root must be present if the II is not null
 
 
 
OCL Invariants:
 
  inv "root is required": notNull implies root.oclIsDefined
 
 
 
  -- nullFlavor invariants
 
  inv "no root if null": isNull implies root.oclIsUndefined
 
  inv "no extension if null": isNull implies extension.oclIsUndefined
 
  inv "no assigningAuthorityName if null": isNull implies assigningAuthorityName.oclIsUndefined
 
  inv "no displayable if null": isNull implies displayable.oclIsUndefined
 
  inv "no use if null": isNull implies use->size= 0
 
  inv "no type if null": isNull implies type.oclIsUndefined
 
 
 
====URI ====
 
 
 
Specializes ANY
 
 
 
'''Definition''': Defines a resource that is identified by a URI, and introduces
 
the notion that the resource may have a limited availability.
 
 
 
'''Attributes'''
 
 
 
'''details : Uri''': A telecommunications address specified according to Internet
 
standard RFC 2396 [[http://www.ietf.org/rfc/rfc2396.txt]]. The URI specifies the
 
protocol and the contact point defined by that protocol for the resource. Notable
 
uses of the telecommunication address data type are for telephone and
 
telefax numbers, e-mail addresses, Hypertext references, FTP references, etc.
 
 
 
'''useablePeriod: GTS''': Specifies the periods of time during which the
 
telecommunication address can be used. For a telephone number, this can indicate
 
the time of day in which the party can be reached on that telephone. For a
 
web address, it may specify a time range in which the web content is
 
promised to be available under the given address.
 
 
 
'''Invariants'''
 
 
 
OCL for Invariants:
 
  inv "no updateMode or History": (useablePeriod.oclIsUndefined or useablePeriod.noUpdateOrHistory)
 
 
 
  -- nullflavor invariants:
 
  inv "no details if null": isNull implies details.oclIsUndefined
 
  inv "no useablePeriod if null": isNull implies (useablePeriod.oclIsUndefined or useablePeriod.isNull)
 
 
 
 
 
====TEL (Telecommunication Address)====
 
 
 
Specializes URI
 
 
 
'''Definition''': A telephone number (voice or fax), e-mail address, or other
 
locator for a resource mediated by telecommunication equipment. The address
 
is specified as a Universal Resource Locator (URL) qualified by time
 
specification and use codes that help in deciding which address to use
 
for a given time and purpose.
 
 
 
'''Attributes'''
 
 
 
'''use : Set(TelecommunicationAddressUse)''': One or more codes advising
 
system or user which telecommunication address in a set of like addresses
 
to select for a given telecommunication need. The telecommunication use
 
code is not a complete classification for equipment types or locations.
 
Its main purpose is to suggest or discourage the use of a particular
 
telecommunication address. There are no easily defined rules that govern
 
the selection of a telecommunication address.
 
 
 
Possible Values for TelecommunicationAddressUse:
 
 
 
{|
 
|H||home address||A communication address at a home, attempted contacts for business purposes might intrude privacy and chances are one will contact family or other household members instead of the person one wishes to call. Typically used with urgent cases, or if no other contacts are available.
 
|-
 
|HP||primary home||The primary home, to reach a person after business hours
 
|-
 
|HV||vacation home||A vacation home, to reach a person while on vacation
 
|-
 
|WP||work place||An office address. First choice for business related contacts during business hours
 
|-
 
|DIR||Direct||Indicates a work place address or telecommunication address that reaches the individual or organization directly without intermediaries. For phones, often referred to as a \’private line\’
 
|-
 
|PUB||Public||Indicates a work place address or telecommunication address that is a \’standard\’ address which may reach a reception service, mail-room, or other intermediary prior to the target entity
 
|-
 
|BAD||bad address||A flag indicating that the address is bad, in fact, useless
 
|-
 
|TMP||temporary address||A temporary address, may be good for visit or mailing. Note that an address history can provide more detailed information
 
|-
 
|AS||answering service||An automated answering machine used for less urgent cases and if the main purpose of contact is to leave a message or access an automated announcement.
 
|-
 
|EC||emergency contact||A contact specifically designated to be used for emergencies. This is the first choice in emergencies, independent of any other use codes
 
|-
 
|MC||mobile contact||A telecommunication device that moves and stays with its owner. May have characteristics of all other use codes, suitable for urgent matters, not the first choice for routine business
 
|-
 
|PG||pager||A paging device suitable to solicit a callback or to leave a very short message
 
|-
 
|}
 
 
 
 
 
'''Invariants'''
 
 
 
OCL for Invariants:
 
 
 
  -- nullflavor invariants:
 
  inv "no use if null": isNull implies use->size = 0
 
 
 
 
 
=== Name and Address Data Types ===
 
 
 
These datatypes provide support for various identifiers and URIs.
 
 
 
[[Image:iso_datatypes_names.gif]]
 
 
 
 
 
 
 
====ADXP (Address Part)====
 
 
 
Specializes ST
 
 
 
'''Definition''': A character string that may have a type-tag signifying
 
its role in the address. Typical parts that exist in about every address
 
are street, house number, or post box, postal code, city, country but
 
other roles may be defined regionally, nationally, or on an enterprise
 
level (e.g. in military addresses). Addresses are usually broken up into
 
lines, which may be indicated by special line-breaking delimiter elements (e.g., DEL).
 
 
 
'''Attributes'''
 
 
 
'''type : AddressPartType''': Specifies whether an address part names the
 
street, city, country, postal code, post box, etc. If the type is NULL the
 
address part is unclassified and would simply appear on an address label
 
as is
 
 
 
Possible Values for AddressPartType:
 
 
 
{|
 
|ADL||additional locator||This can be a unit designator, such as apartment number, suite number, or floor. There may be several unit designators in an address (e.g., "3rd floor, Appt. 342"). This can also be a designator pointing away from the location, rather than specifying a smaller location within some larger one (e.g., Dutch "t.o." means "opposite to" for house boats located across the street facing houses).
 
|-
 
|UNID||unit identifier||The number or name of a specific unit contained within a building or complex, as assigned by that building or complex.
 
|-
 
|UNIT||unit designator||Indicates the type of specific unit contained within a building or complex. E.g. Appartment, Floor
 
|-
 
|DAL||delivery address line||A delivery address line is frequently used instead of breaking out delivery mode, delivery installation, etc. An address generally has only a delivery address line or a street address line, but not both.
 
|-
 
|DINST||delivery installation type||Indicates the type of delivery installation (the facility to which the mail will be delivered prior to final shipping via the delivery mode.) Example: post office, letter carrier depot, community mail center, station, etc.
 
|-
 
|DINSTA||delivery installation area||The location of the delivery installation, usually a town or city, and is only required if the area is different from the municipality. Area to which mail delivery service is provided from any postal facility or service such as an individual letter carrier, rural route, or postal route.
 
|-
 
|DINSTQ||delivery installation qualifier||A number, letter or name identifying a delivery installation. E.g., for Station A, the delivery installation qualifier would be \’A\’.
 
|-
 
|DMOD||delivery mode||Indicates the type of service offered, method of delivery. For example: post office box, rural route, general delivery, etc.
 
|-
 
|DMODID||delivery mode identifier||Represents the routing information such as a letter carrier route number. It is the identifying number of the designator (the box number or rural route number).
 
|-
 
|SAL||street address line||
 
|-
 
|BNR||building number||The number of a building, house or lot alongside the street. Also known as "primary street number". This does not number the street but rather the building.
 
 
 
|-
 
|BNN||building number numeric||The numeric portion of a building number
 
|-
 
|BNS||building number suffix||Any alphabetic character, fraction or other text that may appear after the numeric portion of a building number
 
|-
 
|STR||street name||
 
|-
 
|STB||street name base||The base name of a roadway or artery recognized by a municipality (excluding street type and direction)
 
|-
 
|STTYP||street type||The designation given to the street. (e.g. Street, Avenue, Crescent, etc.)
 
|-
 
|DIR||direction||Direction (e.g., N, S, W, E)
 
|-
 
|AR||care of ||The name of the party who will take receipt at the specified address, and will take on responsibility for ensuring delivery to the target recipient
 
|-
 
|CEN||census tract||A geographic sub-unit delineated for demographic purposes
 
|-
 
|CNT||country||Country
 
|-
 
|CPA||county or parish||A sub-unit of a state or province. (49 of the United States of America use the term "county;" Louisiana uses the term "parish".)
 
|-
 
|CTY||municipality||The name of the city, town, village, or other community or delivery center
 
|-
 
|DEL||delimiter||Delimiters are printed without framing white space. If no value component is provided, the delimiter appears as a line break.
 
|-
 
|POB||post box||A numbered box located in a post station
 
|-
 
|PRE||precinct||A subsection of a municipality
 
|-
 
|STA||state or province||A sub-unit of a country with limited sovereignty in a federally organized country.
 
|-
 
|ZIP||postal code||A postal code designating a region defined by the postal service.
 
|-
 
|}
 
 
 
 
 
 
 
'''Invariants'''
 
 
 
OCL for Invariants:
 
 
 
  -- nullflavor invariants:
 
  inv "no type if null": isNull implies type.oclIsUndefined
 
  inv "no updateMode or History": noUpdateOrHistory
 
 
 
 
 
====AD (Address)====
 
 
 
Specializes ANY
 
 
 
'''Definition''': Mailing and home or office addresses. AD is primarily
 
used to communicate data that will allow printing mail labels, or that will
 
allow a person to physically visit that address. The postal address data
 
type is not supposed to be a container for additional information that
 
might be useful for finding geographic locations (e.g., GPS coordinates)
 
or for performing epidemiological studies. Such additional information should
 
be captured by other, more appropriate data structures.
 
 
 
'''Attributes'''
 
 
 
 
 
'''part : Sequence(ADXP)''': A sequence of address parts, such as street
 
or post office Box, city, postal code, country, etc
 
 
 
'''use : Set(PostalAddressUse)''': A set of codes advising a system or
 
user which address in a set of like addresses to select for a given purpose.
 
An address without specific use code might be a default address useful
 
for any purpose, but an address with a specific use code would be
 
preferred for that respective purpose.
 
 
 
Possible Values for PostalAddressUse:
 
 
 
{|
 
|H||home address||A communication address at a home, attempted contacts for business purposes might intrude privacy and chances are one will contact family or other household members instead of the person one wishes to call. Typically used with urgent cases, or if no other contacts are available.
 
 
|-
 
|-
|HP||primary home||The primary home, to reach a person after business hours
+
!Step
 +
!Expected Date
 +
!Details
 
|-
 
|-
|HV||vacation home||A vacation home, to reach a person while on vacation
+
|Ballot Resolution & Editing||Feb 11||HL7 ballot resolution for both Abstract Datatypes and ISO datatypes, followed by editorial updates for these documents.
 
|-
 
|-
|WP||work place||An office address. First choice for business related contacts during business hours
+
|Internal Review||Mid-Feb||Review by ISO & HL7 leads, ITS & WG co-chairs
 
|-
 
|-
|DIR||Direct||Indicates a work place address or telecommunication address that reaches the individual or organization directly without intermediaries. For phones, often referred to as a \’private line\’
+
|Abstract Datatypes ballot||Mar-Apr||Normal HL7 ballot
 
|-
 
|-
|PUB||Public||Indicates a work place address or telecommunication address that is a \’standard\’ address which may reach a reception service, mail-room, or other intermediary prior to the target entity
+
|ISO Datatypes ballot Opens||Late Mar||Our provisional date is Mar 29. ISO, CEN, and HL7 will all open and close their own ballots on the document the same day.
 
|-
 
|-
|BAD||bad address||A flag indicating that the address is bad, in fact, useless
+
|CEN/ISO combined meeting||May 30||Time for consideration of datatypes at combined meeting; HL7 editor attends.
 
|-
 
|-
|TMP||temporary address||A temporary address, may be good for visit or mailing. Note that an address history can provide more detailed information.
+
|ISO Datatypes ballot closes||Late Aug||Our provisional date is Aug 29. Editor will triage comments
Identifies the different representations of a name. The representation may affect how the name is used. (E.g. use of Ideographic for formal communications.)
 
|-
 
|ABC||Alphabetic||Alphabetic transcription of name (Japanese: romaji)
 
|-
 
|IDE||Ideographic||Ideographic representation of name (e.g., Japanese kanji, Chinese characters)
 
|-
 
|SYL||Syllabic||Syllabic transcription of name (e.g., Japanese kana, Korean hangul)
 
|-
 
|PHYS||physical visit address||Used primarily to visit an address.
 
|-
 
|PST||postal address||Used to send mail.
 
|-
 
|}
 
 
 
'''useablePeriod : GTS''': A General Timing Specification (GTS) specifying
 
the periods of time during which the address can be used. This is used to
 
specify different addresses for different times of the week or year
 
 
 
'''isNotOrdered : Boolean''': A boolean value specifying whether the order
 
of the address parts is known or not. While the address parts are always a
 
Sequence, the order in which they are presented may or may not be known.
 
Where this matters, the isNotOrdered property can be used to convey this
 
information.
 
 
 
'''Invariants'''
 
 
 
* Either the AD is null or it has at least one part
 
 
 
OCL for Invariants:
 
  inv "null or parts": isNull xor part->size = 0
 
 
 
  -- nullflavor invariants:
 
  inv "no use if null": isNull implies use->size = 0 -- is this true?
 
  inv "no useablePeriod if null": isNull implies (useablePeriod.oclIsUndefined or useablePeriod.isNull)
 
  inv "no updateMode or History": (useablePeriod.oclIsUndefined or useablePeriod.noUpdateOrHistory)
 
 
 
 
 
====ENXP (Entity Name Part)====
 
 
 
Specializes ST
 
 
 
'''Definition''': A character string token representing a part of a name. May
 
have a type code signifying the role of the part in the whole entity name,
 
and qualifier codes for more detail about the name part type. Typical name
 
parts for person names are given names, and family names, titles, etc.
 
 
 
'''Attributes'''
 
 
 
'''type : EntityNamePartType''': Indicates whether the name part is a given
 
name, family name, prefix, suffix, etc. Not every name part must have a type
 
code, if the type code is unknown, not applicable, or simply undefined this
 
is expressed by a NULL value (type.isNull). For example, a name may be
 
"Rogan Sulma" and it may not be clear which one is a given name or which is
 
a last name, or whether Rogan may be a title
 
 
 
Possible Values for EntityNamePartType:
 
 
 
{|
 
|FAM||family||Family name, this is the name that links to the genealogy. In some cultures (e.g. Eritrea) the family name of a son is the first name of his father.
 
|-
 
|GIV||given||Given name (don\’t call it "first name" since this given names do not always come first)
 
|-
 
|PFX||prefix||A prefix has a strong association to the immediately following name part. A prefix has no implicit trailing white space (it has implicit leading white space though). Note that prefixes can be inverted
 
|-
 
|SFX||suffix||A suffix has a strong association to the immediately preceding name part. A prefix has no implicit leading white space (it has implicit trailing white space though). Suffices can not be inverted
 
|-
 
|DEL||delimiter||A delimiter has no meaning other than being literally printed in this name representation. A delimiter has no implicit leading and trailing white space.
 
|-
 
|}
 
 
 
 
 
'''qualifier : Set(EntityNamePartQualifier)''': The qualifier is a set of
 
codes each of which specifies a certain subcategory of the name part in
 
addition to the main name part type. For example, a given name may be
 
flagged as a nickname, a family name may be a pseudonym or a name of
 
public records.
 
 
 
Possible Values for EntityNamePartQualifier:
 
 
 
{|
 
|LS||Legal status||For organizations a suffix indicating the legal status, e.g., "Inc.", "Co.", "AG", "GmbH", "B.V." "S.A.", "Ltd." etc.
 
|-
 
|AC||academic||Indicates that a prefix like "Dr." or a suffix like "M.D." or "Ph.D." is an academic title
 
|-
 
|NB||nobility||In Europe and Asia, there are still people with nobility titles (aristocrats). German "von" is generally a nobility title, not a mere voorvoegsel. Others are "Earl of" or "His Majesty King of..." etc. Rarely used nowadays, but some systems do keep track of this
 
|-
 
|PR||professional||Primarily in the British Imperial culture people tend to have an abbreviation of their professional organization as part of their credential suffices
 
|-
 
|VV||voorvoegsel||A Dutch "voorvoegsel" is something like "van" or "de" that might have indicated nobility in the past but no longer so. Similar prefixes exist in other languages such as Spanish, French or Portugese
 
|-
 
|AD||adopted||The name the person was given at the time of adoption
 
|-
 
|BR||birth||A name that a person had shortly after being born. Usually for family names but may be used to mark given names at birth that may have changed later.
 
|-
 
|SP||spouse||The name assumed from the partner in a marital relationship (hence the "M"). Usually the spouse\’s family name. Note that no inference about gender can be made from the existence of spouse names.
 
|-
 
|CL||callme||A callme name is (usually a given name) that is preferred when a person is directly addressed
 
|-
 
|IN||initial||Indicates that a name part is just an initial. Initials do not imply a trailing period since this would not work with non-Latin scripts. Initials may consist of more than one letter, e.g., "Ph." could stand for "Philippe" or "Th." for "Thomas".
 
|-
 
|TITLE||title||Indicates that a prefix or a suffix is a title that applies to the whole name, not just the adjacent name part.
 
|-
 
|}
 
 
 
 
 
'''Invariants'''
 
 
 
OCL for Invariants:
 
 
 
  -- nullflavor invariants:
 
  inv "no qualifier if null": isNull implies qualifier->size = 0
 
  inv "no updateMode or History": noUpdateOrHistory
 
 
 
 
 
====EN (Entity Name)====
 
 
 
Specializes ANY
 
 
 
'''Definition''': A name for a person, organization, place or thing. Examples
 
for entity name values are "Jim Bob Walton, Jr.", "Health Level Seven, Inc.",
 
"Lake Tahoe", etc. An entity name may be as simple as a character string or
 
may consist of several entity name parts, such as, "Jim", "Bob", "Walton",
 
and "Jr.", "Health Level Seven" and "Inc.",
 
 
 
'''Attributes'''
 
 
 
'''part : Sequence(ENXP)''': A sequence of name parts, such as given name
 
or family name, prefix, suffix, etc.
 
 
 
'''use : Set(EntityNameUse)''': A set of codes advising a system or user
 
which name in a set of names to select for a given purpose. A name without
 
specific use code might be a default name useful for any purpose, but a
 
name with a specific use code would be preferred for that respective
 
purpose.
 
 
 
Possible Values for EntityNameUse:
 
 
 
{|
 
|C||License||As recorded on a license, record, certificate, etc. (only if different from legal name)
 
|-
 
|I||Indigenous/Tribal||e.g. Chief Red Cloud
 
|-
 
|L||Legal||Known as/conventional/the one you use
 
|-
 
|P||pseudonym||A self asserted name that the person is using or has used
 
|-
 
|A||Artist/Stage||Includes writer\’s pseudonym, stage name, etc
 
|-
 
|R||Religious||e.g. Sister Mary Francis, Brother John
 
|-
 
|SRCH||search ||A name intended for use in searching or matching.
 
|-
 
|PHON||phonetic||A name spelled phonetically
 
|-
 
|SNDX||Soundex||A name spelled according to the SoundEx algorithm
 
|-
 
|ABC||Alphabetic||Alphabetic transcription of name (Japanese: romaji)
 
|-
 
|SYL||Syllabic||Syllabic transcription of name (e.g., Japanese kana, Korean hangul)
 
|-
 
|IDE||Ideographic||Ideographic representation of name (e.g., Japanese kanji, Chinese characters)
 
|-
 
|}
 
 
 
 
 
'''validTime : IVL(TS)''': An interval of time specifying the time during
 
which the name is or was used for the entity. This accomodates the fact
 
that people change names for people, places and things.
 
 
 
'''Invariants'''
 
 
 
* Either the EN is null or it has at least one part
 
 
 
OCL for Invariants:
 
  inv "null or parts": isNull xor part->size = 0
 
 
 
  -- nullflavor invariants:
 
  inv "no use if null": isNull implies use->size = 0 -- is this true?
 
  inv "no validTime if null": isNull implies (validTime.oclIsUndefined )-- or validTime.isNull)
 
  inv "no updateMode or History": (validTime.oclIsUndefined or validTime.noUpdateOrHistory)
 
 
 
 
 
 
 
====TN (Trivial Name)====
 
 
 
Specializes EN
 
 
 
'''Definition''': A restriction of entity name that is effectively a
 
simple string used for a simple name for things and places. Trivial
 
names are typically used for places and things, such as Lake Erie or
 
Washington-Reagan National Airport.
 
 
 
'''Invariants'''
 
 
 
* If the TN is not null, there can only be one part, and it can have no name
 
 
 
OCL for Invariants:
 
  inv "only one part with no type": isNotNull implies (part->size = 1 and part->first.type.oclIsUndefined)
 
 
 
 
 
====PN (Person Name)====
 
Specializes EN
 
 
 
'''Definition''': An EN used when the named Entity is a Person. A sequence
 
of name parts, such as given name or family name, prefix, suffix, etc. A
 
name part is a restriction on entity name part that only allows those
 
entity name parts qualifiers applicable to person names. Since the structure
 
of entity name is mostly determined by the requirements of person name,
 
the restriction is very minor.
 
 
 
'''Invariants'''
 
 
 
* None of the parts of a persons name can be qualified by the status LS
 
 
 
OCL for Invariants:
 
 
 
  inv "no parts are qualified by LS": part->forAll(p | not p.qualifier->includes(EntityNamePartQualifier.LS))
 
 
 
====ON (Organization Name)====
 
 
 
Specializes EN
 
 
 
'''Definition''': An EN used when the named Entity is an Organization.
 
 
 
'''Invariants'''
 
 
 
* None of the parts of a organisation name can be FAM or GIV
 
 
 
OCL for Invariants:
 
 
 
  inv "no parts are person types": part->forAll(p | not (p.type = EntityNamePartType.FAM or p.type = EntityNamePartType.GIV))
 
 
 
 
 
=== Quantity Data Types ===
 
 
 
These datatypes provide support for Quantitative values.
 
 
 
[[Image:iso_datatypes_qty.gif]]
 
 
 
 
 
====QTY (Quantity)====
 
 
 
Specializes ANY
 
 
 
'''Definition''': The quantity data type is an abstract generalization for all
 
data types whose value set has an order relation (less-or-equal) and where
 
difference is defined in all of the data type’s totally ordered value subsets.
 
The quantity type abstraction is needed in defining certain other types, such
 
as the interval and the probability distribution.
 
 
 
Note that QTY is an abstract type, but is not declared as an abstract type here because of the way that many of the following types are declared.
 
 
 
 
 
====INT (Integer)====
 
 
 
Specializes QTY
 
 
 
'''Definition''': Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise
 
numbers that are results of counting and enumerating. Integer numbers are
 
discrete, the set of integers is infinite but countable. No arbitrary limit
 
is imposed on the range of integer numbers.
 
 
 
'''Attributes'''
 
 
 
'''value : Integer''': The value of the INT if not null. Note that this
 
specification imposes no limitations on the size of integer,
 
but most implementations will map this to a 32 bit integer.
 
 
 
'''Invariants'''
 
 
 
* a value must be provided if not null
 
 
 
OCL for Invariants:
 
 
 
  inv "null or value": isNull xor value.oclIsDefined
 
 
 
 
 
====CO (Coded Ordinal) ====
 
 
 
Specializes QTY
 
 
 
'''Definition''': Represents data where coded values are associated with a specific
 
order.CO may be used for things that model rankings and scores, e.g. pain,
 
Apgar values, etc, where there is a) implied ordering, b) no implication that the
 
distance between each value is constant, and c) the total number of values is finite.
 
CO may also be used in the context of an ordered code system. In this case, it
 
may not be appropriate or even possible to use the value attribute, but CO may still
 
be used so that models that make use of such code systems may introduce model
 
elements that involve statements about the order of the terms in a domain.
 
 
 
'''Attributes'''
 
 
 
'''value : Integer''': a numerical value associated with the coded ordinal value.
 
 
 
'''code : CD''': a code representing the definition of the ordinal item.
 
 
 
'''Invariants'''
 
 
 
* there must be a code or a value if not null
 
 
 
OCL for invariants:
 
  inv "must have a code or a value": notNull implies ((code.oclIsUndefined and code.notNull) or value.oclIsDefined)
 
 
 
  --  nullFlavor invariants
 
  inv "no value if null": isNull implies value.oclIsUndefined
 
  inv "no code if null": isNull implies code.oclIsUndefined or code.isNull
 
 
 
 
 
====REAL (Real)====
 
 
 
Specializes QTY
 
 
 
'''Definition''': Fractional numbers. Typically used whenever quantities are
 
measured, estimated, or computed from other real numbers. The typical
 
representation is decimal, where the number of significant decimal digits
 
is known as the precision.
 
 
 
'''Attributes'''
 
 
 
'''value : Real''': The value of the REAL if non Null. Real is the UML Kernel
 
Real type. Note that the abstract specification imposes no limitations on
 
the size or precision of REAL, but most implementations will map this to
 
a 8 byte Real.
 
 
 
'''precision : Integer''': The number of significant digits of the decimal
 
representation. 0 (default value) means nothing is known about the precision
 
 
 
'''Invariants'''
 
 
 
* a value must be provided if not null
 
 
 
OCL for Invariants:
 
  inv "null or value": isNull xor value.oclIsDefined
 
 
 
  -- nullFlavor invariants
 
  inv "no precision if null": isNull implies precision.oclIsUndefined
 
 
 
 
 
====RTO (Ratio)====
 
 
 
Specializes QTY
 
 
 
Note: (does it need to? Why do we care in the ITS? We would only care if there was an attribute with type QTY. I\’ve never seen one. Can we specialise any not qty? This was intended to allow QTY to have extra data types, but it\’s not clear that this is useful anymore)
 
 
 
'''Definition''': A quantity constructed as the quotient of a numerator quantity
 
divided by a denominator quantity. Common factors in the numerator and
 
denominator are not automatically cancelled out. The RTO data type supports
 
titers (e.g., "1:128") and other quantities produced by laboratories that
 
truly represent ratios. Ratios are not simply "structured numerics",
 
particularly blood pressure measurements (e.g. "120/60") are not ratios.
 
 
 
Note: Ratios are different from rational numbers, i.e., in ratios common
 
factors in the numerator and denominator never cancel out. A ratio of
 
two real or integer numbers is not automatically reduced to a real number.
 
This data type is not defined to generally represent rational numbers.
 
It is used only if common factors in numerator and denominator are not
 
supposed to cancel out. This is only rarely the case. For observation
 
values, ratios occur almost exclusively with titers. In most other cases,
 
REAL should be used instead of the RTO.
 
 
 
Note: Since many implementation technologies expect generics to be collections,
 
or only have one parameter, RTO is not implemented as a generic in this specification.
 
Constraints at the point where the RTO is used will define which form of QTY are used
 
 
 
'''Attributes'''
 
 
 
'''numerator : QTY''': The quantity that is being divided in the ratio.
 
 
 
'''denominator : QTY''': The quantity that divides the numerator in the ratio.
 
The denominator must not be zero.
 
 
 
'''Invariants'''
 
 
 
* If the RTO is not null, both a numerator and a denominator are required
 
 
 
OCL for Invariants:
 
  inv "numerator and and denominator required": isNull xor ( (numerator.oclIsDefined and numerator.isNotNull)
 
      and (denominator.oclIsDefined and denominator.isNotNull) )
 
  inv "no updateMode or History": (numerator.oclIsUndefined or numerator.noUpdateOrHistory) and
 
      (denominator.oclIsUndefined or denominator.noUpdateOrHistory)
 
 
 
 
 
====PQ (Physical Quantity)====
 
 
 
Specializes QTY
 
 
 
'''Definition''': A dimensioned quantity expressing the result of measuring.
 
 
 
'''Attributes'''
 
 
 
'''value : Real''': The value of the PQ if non Null. Note that this
 
specification imposes no limitations on the size or precision of REAL,
 
but most implementations will map this to a 8 byte Real
 
 
 
'''precision : Integer''': The number of significant digits of the decimal
 
representation. 0 (default value) means nothing is known about the precision
 
 
 
'''accuracy : Real''': Accuracy of measurement instrument or method which
 
applies to this specific instance, expressed either as a half-range percent value.
 
0 (default value) means nothing is known about the precision
 
 
 
'''unit : Code''': The unit of measure specified in the Unified Code for
 
Units of Measure (UCUM) [[http://aurora.rg.iupui.edu/UCUM]. Equality of
 
physical quantities does not require the values and units to be equal
 
independently. Value and unit is only how we represent physical quantities.
 
For example, 1 m equals 100 cm. Although the units are different and the
 
values are different, the physical quantities are equal. Therefore one
 
should never expect a particular unit for a physical quantity but instead
 
allow for automated conversion between different comparable units.
 
 
 
'''translation : Set(PQR)''': An alternative representation of the same
 
physical quantity expressed in a different unit, of a different unit
 
code system and possibly with a different value.
 
 
 
''specialValue: SpecialPhysicalQuantity''': Alternative special value for
 
physical quantities that have no literal value.
 
 
 
Possible Values for SpecialPhysicalQuantity:
 
 
 
{|
 
|TRC||Trace Detected||A trace amount was detected, but too small to quantify.
 
 
|-
 
|-
|QS||Sufficient Quantity||The specific quantity is not known, but is known to
+
|Joint Disposition Meeting||11&12 Sept||a satellite meeting of the HL7 Vancouver meeting - joint CEN/ISO/HL7 meeting. We encourage all interested parties to attend this meeting. At this meeting, we will resolve the ballot line items.
be non-zero and is not specified because it makes up the bulk of the material.
 
For example: 'Add 10mg of ingredient X, 50mg of ingredient Y, and sufficient
 
quantity of water to 100mL.' The specialValue QS would be used to express
 
the quantity of water.
 
 
|-
 
|-
 +
|ISO ballot conclusion||Sept-Oct||ISO&CEN conclude their normal ballot processesat Istanbul meeting
 
|}
 
|}
  
'''Invariants'''
+
Note: Feb 11 deadline has been missed by a few days. As of this comment, it should be Feb 16 ish. --[[User:GrahameGrieve|GrahameGrieve]] 00:26, 13 February 2008 (CST)
* If the PQ is not null, a value must be present
 
* If a value is present, units must be present
 
 
 
OCL for Invariants:
 
  def: let hasValue : Boolean = value.oclIsDefined or specialValue.oclIsDefined
 
  inv "value or specialValue": value.oclIsDefined xor specialValue.oclIsDefined
 
  inv "null or value": isNull xor hasValue
 
  inv "units required": value.oclIsDefined implies units.oclIsDefined -- do not need to have units if a special value is provided
 
 
 
  -- nullFlavor invariants
 
  inv "no precision if null": isNull implies precision.oclIsUndefined
 
  inv "no translation if null": isNull implies translation->size = 0 -- ?
 
 
 
 
 
==== PQR (Physical Quantity Representation)====
 
 
 
Specializes CV
 
 
 
Definition: An extension of the coded value data type representing a
 
physical quantity using a unit from any code system. Used to show
 
alternative representation for a physical quantity. The coded value
 
represents the unit (usually in some other coding system than UCUM)
 
 
 
'''Attributes'''
 
 
 
'''value : REAL''': The value of the PQ if non Null
 
 
 
'''precision : Integer''': The number of significant digits of the decimal
 
representation. 0 (default value) means nothing is known about the precision
 
 
 
'''Invariants'''
 
 
 
* If the PQR is not null, a value must be present and not null
 
 
 
OCL for Invariants:
 
  inv "null or value": isNull xor value.oclIsDefined
 
 
 
  -- nullFlavor invariants
 
  inv "no updateMode or History": noUpdateOrHistory
 
  inv "no precision if null": isNull implies precision.oclIsUndefined
 
 
 
 
 
====MO (Monetary Amount)====
 
 
 
Specializes QTY
 
 
 
'''Definition''': An MO is a quantity expressing the amount of money
 
in some currency. Currencies are the units in which monetary amounts
 
are denominated in different economic regions. While the monetary amount
 
is a single kind of quantity (money) the exchange rates between the
 
different units are variable. This is the principle difference between
 
PQ and MO, and the reason why currency units are not physical units
 
 
 
'''Attributes'''
 
 
 
'''value : Real''' The value of the MO if non Null. MO values are usually
 
precise to 0.01 (one cent, penny, paisa, etc.) For large amounts, it is
 
important not to store MO values in floating point registers, since this
 
may lose precision.
 
 
 
'''currency : Code''': The currency unit as defined in ISO 4217.
 
 
 
'''Invariants'''
 
 
 
* If not null, a value must be present
 
* If not null, a currency must be defined
 
 
 
OCL for Invariants:
 
  inv "null or value": isNull xor value.oclIsDefined
 
  inv "null or currency": isNull xor currency.oclIsDefined
 
 
 
 
 
====TS (Point in Time)====
 
 
 
Specializes QTY
 
 
 
Definition: A quantity specifying a point on the axis of natural time. A
 
point in time is most often represented as a calendar expression
 
 
 
'''Attributes'''
 
 
 
'''value : String''': The value of the TS if non Null. value is an ISO 8601 String,
 
to the degree of precision that is appropriate.
 
 
 
'''Invariants'''
 
 
 
* If the TS is not null, a value must be present
 
 
 
OCL for Invariants:
 
  inv "null or value": isNull xor value.oclIsDefined
 
 
 
=== Collection Data Types ===
 
 
 
These datatypes provide support for collections of data.
 
 
 
[[Image:iso_datatypes_collections.gif]]
 
 
 
 
 
====SET (Set)====
 
 
 
Specializes ANY
 
 
 
Parameter: T : ANY
 
 
 
'''Definition''': A collection that contains other distinct values in no particular order
 
 
 
'''Attributes'''
 
 
 
'''item : Set(T)''': The contents of the Set.
 
 
 
'''Invariants'''
 
 
 
* If the SET is null, no items can be contained in the Set. If the SET is not null, at least one item must be present
 
 
 
OCL for Invariants:
 
  inv "null or not empty": isNull xor item->size > 0
 
 
 
 
 
====LIST (Sequence)====
 
 
 
Specializes ANY
 
 
 
Parameter: T : ANY
 
 
 
'''Definition''': A collection that contains other discrete (but not
 
necessarily distinct) values in a defined sequence
 
 
 
 
 
'''Attributes'''
 
 
 
'''item : Sequence(T)''': The contents of the Sequence
 
 
 
'''Invariants'''
 
 
 
 
 
OCL for Invariants:
 
  inv "null or not empty": isNull implies item->size = 0
 
 
 
====GLIST (Generated Sequence)====
 
 
 
 
 
Specializes ANY
 
 
 
Parameter: T : QTY
 
 
 
'''Definition''': A periodic or monotone sequence of values generated
 
from a few parameters, rather than being enumerated. Used to specify
 
regular sampling points for biosignals
 
 
 
'''Attributes'''
 
 
 
'''head : T''': The first item in this sequence. The head is a definitional
 
property for the semantics of the sequence
 
 
 
'''increment : QTY''': The difference between one value and its previous
 
different value. For example, to generate the sequence (1; 4; 7; 10; 13; ...)
 
the increment is 3; likewise to generate the sequence (1; 1; 4; 4; 7; 7;
 
10; 10; 13; 13; ...) the increment is also 3. The actual type QTY will be
 
dictated by the type of T
 
 
 
'''denominator : Integer''': The integer by which the index for the sequence
 
is divided, effectively the number of times the sequence generates the same
 
sequence item value before incrementing to the next sequence item value.
 
For example, to generate the sequence (1; 1; 1; 2; 2; 2; 3; 3; 3; ...) the
 
denominator is 3.
 
 
 
'''period : Integer''': If non-NULL, specifies that the sequence alternates,
 
i.e., after this many increments, the sequence item values roll over to start
 
from the initial sequence item value. For example, the sequence
 
(1; 2; 3; 1; 2; 3; 1; 2; 3; ...) has period 3; also the sequence
 
(1; 1; 2; 2; 3; 3; 1; 1; 2; 2; 3; 3; ...) has period 3 too.
 
 
 
'''Invariants'''
 
 
 
* If the GLIST is not null, all attributes but the period are required
 
 
 
OCL for Invariants:
 
 
 
  inv "required attributes": isNull xor (head.oclIsDefined and head.isNotNull and
 
      increment.oclIsDefined and increment.isNotNull and denominator.oclIsDefined)
 
  inv "no updateMode or History": (head.oclIsUndefined or head.noUpdateOrHistory)
 
      and (increment.oclIsUndefined or increment.noUpdateOrHistory)
 
 
 
 
 
====SLIST (Sampled Sequence)====
 
 
 
Specializes ANY
 
 
 
Parameter: T : QTY
 
 
 
'''Definition''': A sequence of sampled values scaled and translated from a list of integer values. Used to specify sampled biosignals.
 
 
 
'''Attributes'''
 
 
 
'''Origin : T''': The origin of the list item value scale. The physical quantity
 
that a zero-digit in the sequence would represent
 
 
 
'''Scale : QTY''': A ratio-scale quantity that is factored out of the digit
 
sequence. For example, to generate the sequence (1; 4; 7; 10; 13; ...) the
 
increment is 3; likewise to generate the sequence (1; 1; 4; 4; 7; 7; 10;
 
10; 13; 13; ...) the increment is also 3. The actual type QTY will be
 
dictated by the type of T
 
 
 
'''Digits : Sequence(INT)''': A sequence of raw digits for the sample
 
values. This is typically the raw output of an A/D converter. May be null.
 
 
 
'''Invariants'''
 
 
 
* If the SLIST is not null, an origin and at least one digit is required
 
 
 
OCL for Invariants:
 
 
 
  inv "required attributes": isNull xor (origin.oclIsDefined and origin.isNotNull
 
      and digits->size > 0) -- digits > 0 or null? scale can be null
 
  inv "no updateMode or History": (origin.oclIsUndefined or origin.noUpdateOrHistory)
 
      and (scale.oclIsUndefined or scale.noUpdateOrHistory)
 
      and digits->forAll(d | d.noUpdateOrHistory)
 
 
 
 
 
====BAG (Bag)====
 
 
 
 
 
Specializes ANY
 
 
 
Parameter: T : ANY
 
 
 
'''Definition''': An unordered collection of values, where each value can be
 
contained more than once in the collection
 
 
 
 
 
'''Attributes'''
 
 
 
'''item : Bag(T)''': The contents of the Bag.
 
 
 
'''Invariants'''
 
 
 
* If the BAG is null, no items can be contained in the Set. If the BAG is not null, at  least one item must be present
 
 
 
OCL for Invariants:
 
 
 
  inv "null or not empty": isNull xor item->size > 0
 
  -- rules about updateMode or history are applied to item where BAG(T) is used
 
 
 
 
 
====IVL (Interval)====
 
 
 
Specializes ANY
 
 
 
Parameter: T : QTY
 
 
 
'''Definition''': A set of consecutive values of an ordered base data type.
 
Any ordered type can be the basis of an IVL; it does not matter whether the
 
base type is discrete or continuous. If the base data type is only partially
 
ordered, all elements of the IVL must be elements of a totally ordered
 
subset of the partially ordered data type.
 
 
 
'''Attributes'''
 
 
 
'''low : T''': This is the low limit
 
 
 
'''lowClosed : Boolean''': Specifies whether low is included in the IVL (is closed) or excluded from the IVL (is open).
 
 
 
'''lowUnbounded : Boolean''': There is no lower limit
 
 
 
'''high : T''': This is the high limit
 
 
 
'''highClosed : Boolean''': Specifies whether high is included in the IVL (is closed) or excluded from the IVL (is open).
 
 
 
'''highUnbounded : Boolean''': There is no upper limit
 
 
 
'''width : QTY''': The difference between high and low boundary. Width is used when the size of the Interval is known, but the actual start and end points are not known.
 
 
 
'''Invariants'''
 
 
 
* Either the IVL is null, has a width, or has (low and/or high). Width and (low and/or high) cannot be mixed
 
* lowClosed and highClosed can only be used if low or high are used
 
 
 
OCL for Invariants:
 
 
 
  -- you can have either width or (low and/or high)
 
  -- you can only have the closed flags if you don't have width. (not sure about this)
 
  def: let hasWidth : Boolean = width.oclIsDefined and width.isNotNull
 
  def: let hasLow : Boolean = (low.oclIsDefined and low.isNotNull) or lowUnbounded
 
  def: let hasHigh : Boolean = (high.oclIsDefined and high.isNotNull) or highUnbounded
 
 
 
  def: let hasBounds : Boolean = hasLow or hasHigh
 
 
 
  inv "required attributes": isNull xor (hasBounds xor hasWidth)
 
  inv "closed attributes only if not width": (not hasLow implies lowClosed.oclIsUndefined)
 
      and (not hasHigh implies highClosed.oclIsUndefined)
 
  inv "no updateMode or History": (low.oclIsUndefined or low.noUpdateOrHistory)
 
      and (high.oclIsUndefined or high.noUpdateOrHistory) and (width.oclIsUndefined
 
      or width.noUpdateOrHistory)
 
  inv "unbounded means no value (low)": lowUnbounded implies low.oclIsUndefined
 
  inv "unbounded means no value (high)": highUnbounded implies high.oclIsUndefined
 
 
 
 
 
=== Timing Specification Data Types ===
 
 
 
These datatypes provide support for collections of data.
 
 
 
[[Image:iso_datatypes_timing.gif]]
 
 
 
 
 
 
 
====PIVL (PeriodicInterval)====
 
 
 
Specializes ANY
 
 
 
Definition: An interval of time that recurs periodically. PIVL has two properties,
 
phase and period. phase specifies the "interval prototype" that is repeated every .
 
 
 
'''Attributes'''
 
 
 
'''phase : TS''': A prototype of the repeating interval, specifying the
 
duration of each occurrence and anchors the PIVL sequence at a certain
 
point in time. phase also marks the anchor point in time for the entire
 
series of periodically recurring intervals. The recurrence of a PIVL has
 
no beginning or ending, but is infinite in both future and past.
 
 
 
'''period : PQ''': A time duration specifying as a reciprocal measure of
 
thefrequency at which the PIVL repeats
 
 
 
'''alignment : CalendarCycle''': Specifies if and how the repetitions are
 
aligned to the cycles of the underlying calendar (e.g., to distinguish
 
every 30 days from "the 5th of every month".) A non-aligned PIVL recurs
 
independently from the calendar. An aligned PIVL is synchronized with
 
the calendar.
 
 
 
'''institutionSpecified : Boolean''': Indicates whether the exact timing
 
is up to the party executing the schedule e.g., to distinguish "every 8
 
hours" from "3 times a day".
 
 
 
'''Invariants'''
 
 
 
* If PIVL is not null, phase and period must be specified
 
 
 
OCL for invariants:
 
  inv "required attributes": isNotNull implies (phase.oclIsDefined and phase.isNotNull
 
      and period.oclIsDefined and period.isNotNull)
 
  inv "no updateMode or History": (phase.oclIsUndefined or phase.noUpdateOrHistory)
 
      and (period.oclIsUndefined or period.noUpdateOrHistory)
 
 
 
 
 
====EIVL (Event-Related Periodic Interval of Time)====
 
 
 
 
 
Specializes ANY
 
 
 
'''Definition''': Specifies a periodic interval of time where the
 
recurrence is based on activities of daily living or other important
 
events that are time-related but not fully determined by time. For
 
example, "one hour after breakfast" specifies the beginning of the
 
interval at one hour after breakfast is finished. Breakfast is assumed
 
to occur before lunch but is not determined to occur at any specific time.
 
 
 
'''Attributes'''
 
 
 
'''event : TimingEvent''': A code for a common (periodical) activity of
 
daily living based on which the event related periodic interval is
 
specified. Such events qualify for being adopted in the domain of
 
this attribute for which all of the following is true:
 
 
 
* the event commonly occurs on a regular basis
 
* the event is being used for timing activities, and
 
* the event is not entirely determined by time||N/A
 
 
 
'''offset : IVL(TS)''': An interval of elapsed time (duration, not
 
absolute point in time) that marks the offsets for the beginning,
 
width and end of the EIVL measured from the time each such event
 
actually occurred. For example: if the specification is "one hour
 
before breakfast for 10 minutes" IVL.low of offset is 1 h and the
 
IVL.width of offset is 10 min.
 
 
 
'''Invariants'''
 
 
 
* If EIVL is not null, event must be specified
 
 
 
OCL for invariants:
 
  inv "required attributes": isNotNull implies (event.oclIsDefined)
 
  inv "no updateMode or History": (offset.oclIsUndefined or offset.noUpdateOrHistory)
 
 
 
====GTS (General Timing Specification)====
 
 
 
Specializes ANY
 
 
 
'''Definition''': Specifies the timing of events and actions and the
 
cyclical validity-patterns that may exist for certain kinds of information,
 
such as phone numbers (evening, daytime), addresses (so called "snowbirds,"
 
residing closer to the equator during winter and farther from
 
the equator during summer) and office hours
 
 
 
 
 
''''Attributes'''
 
 
 
'''literal : String''': A literal representation of the GTS.
 
Can be used instead of the structural alternatives offered
 
by item, event and period. '''Literal cannot be used at the same time as item, period or event.'''
 
 
 
'''item : Sequence(IVL(TS))''': A sequence of IVL<TS>
 
 
 
'''period : Sequence(PIVL)''': A sequence of periodic intervals
 
 
 
'''event : Sequence(EIVL)''': A sequence of event related intervals
 
 
 
 
 
'''Invariants'''
 
 
 
* If GTS is not null, either a literal must be provided, or else some values must be found in item, period or event.
 
 
 
  def: let hasStructuredContent : Boolean = item->size > 0 or period->size > 0 or event->size > 0
 
 
 
  inv "required attributes": isNotNull xor (literal.oclIsDefined xor hasStructuredContent)
 
  inv "no updateMode or History": item->forAll(i | i.noUpdateOrHistory) and
 
      period->forAll(p | p.noUpdateOrHistory) and event->forAll(e | e.noUpdateOrHistory)
 
 
 
 
 
== Appendix A: UML support types ==
 
 
 
This section declares some UML types that are needed to support the UML type
 
declarations for the UML types above.
 
 
 
== Appendix B: Requirements ==
 
 
 
This section is proposed by CEN TC251, but it's not clear whether this
 
is an ISO practice, or whether we can resource this or not.
 
 
 
 
 
== Editor's TODO ==
 
 
 
is null flavor a sentinal value in 11404?
 

Latest revision as of 06:26, 13 February 2008

Introduction

This is a project under the CEN ISO HL7 Joint Initiative

This is a project page for the ISO datatypes activity led by Grahame Greive for HL7, and Tom Marley for ISO.

The project is currently in reconciliation activity -- with the work being done on the XML SIG telcons XML SIG#Conference_Calls.

Note: this page was a full draft of the ISO datatypes document - this is now maintained in the hl7 svn repository, and published in the Ballot pack [1].

Project Plan as of Jan 2008

Step Expected Date Details
Ballot Resolution & Editing Feb 11 HL7 ballot resolution for both Abstract Datatypes and ISO datatypes, followed by editorial updates for these documents.
Internal Review Mid-Feb Review by ISO & HL7 leads, ITS & WG co-chairs
Abstract Datatypes ballot Mar-Apr Normal HL7 ballot
ISO Datatypes ballot Opens Late Mar Our provisional date is Mar 29. ISO, CEN, and HL7 will all open and close their own ballots on the document the same day.
CEN/ISO combined meeting May 30 Time for consideration of datatypes at combined meeting; HL7 editor attends.
ISO Datatypes ballot closes Late Aug Our provisional date is Aug 29. Editor will triage comments
Joint Disposition Meeting 11&12 Sept a satellite meeting of the HL7 Vancouver meeting - joint CEN/ISO/HL7 meeting. We encourage all interested parties to attend this meeting. At this meeting, we will resolve the ballot line items.
ISO ballot conclusion Sept-Oct ISO&CEN conclude their normal ballot processesat Istanbul meeting

Note: Feb 11 deadline has been missed by a few days. As of this comment, it should be Feb 16 ish. --GrahameGrieve 00:26, 13 February 2008 (CST)