CEN/TS 14796:2004

SLOVENSKI STANDARD
01-september-2004
Zdravstvena informatika – Vrste podatkov
Health Informatics - Data Types
Medizinische Informatik - Datentypen
Informatique de santé - Types de données
Ta slovenski standard je istoveten z: CEN/TS 14796:2004
ICS:
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 14796
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
June 2004
ICS 35.240.80
English version
Health Informatics - Data Types
Élément introductif - Élément central Medizinische Informatik - Datentypen
This Technical Specification (CEN/TS) was approved by CEN on 9 February 2004 for provisional application.
The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.
CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available
promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)
until the final decision about the possible conversion of the CEN/TS into an EN is reached.
CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia,
Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36  B-1050 Brussels
© 2004 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 14796:2004: E
worldwide for CEN national Members.

Contents Page
1 Scope 7
2 Normative references 7
3 Terms and definitions 7
4 Abbreviations 8
5 Introduction to abstract data type definitions 9
5.1 Data values and data types 9
5.2 Representation of Data Values 10
5.3 Properties of Data Values 10
5.4 Characteristics of the data types 11
6 Primitive data types 11
6.1 Introduction 11
6.2 Primitive type set 11
6.3 Numeric Types 12
6.4 Set 13
6.5 Sequence 14
6.6 Bag 14
6.7 Array 14
7 Constructed Data Types 15
7.1 DATA_VALUE 15
7.2 Basic data types 15
7.3 Introduction 15
7.4 Encapsulated Data 16
7.5 Instance Identifier 18
7.6 ISO Object Identifier 19
7.7 Universal Resource Identifier 20
7.8 Interval 21
8 Textual and Coded data types 23
8.1 Introduction 23
8.2 TEXT 23
8.3 SIMPLE_TEXT 25
8.4 CODED_TEXT 25
8.5 Coded Value 25
8.6 Coded with Equivalents 26
8.7 Concept Descriptor 27
8.8 Concept Role 28
8.9 Coded Simple Value  Abstract Class 29
9 Quantity Types 29
9.1 UML representation 29
9.2 QUANTITY 30
9.3 Ordinal 31
9.4 Physical Quantity 32
9.5 DURATION 33
9.6 Quantity Ratio 34
9.7 QuantityRange 35
10 Time-RelatedTypes 36
10.1 UML representation 36
10.2 Date 36
10.3 Time point 37
10.4 Interval of Time 39
10.5 Periodic Interval of Time 40
10.6 Event Related Periodic Interval of Time 41
Annex A (normative)  Null Flavors 43
A.1 Introduction 43
A.2 Null flavor structure 44
Annex B (normative) Other CS-defined code lists 45
List of Figures
Figure 1: Packages . 9
Figure 2: UML Representation of Primitive data types . 12
Figure 3: UML Representation of Basic data types . 16
Figure 4: UML Representation of Text data types . 24
Figure 5: UML Representation of Quantity data types. 30
Figure 6: UML Representation of Time-related data types . 36
List of Tables
Table 1: Names and formats of numeric data types . 12
Table 2: Content of 32-bit floating point bit positions. 13
Table 3: Content of 64-bit floating point bit positions. 13
Table 4: Attributes of encapsulated data (ED). 17
Table 5: Attributes of Instance Identifier (II). 19
Table 6: Attributes of the OID data type. 19
Table 7: URI schemes. 20
Table 8: Attributes of the URI data type. 21
Table 9: Attributes of Interval . 22
Table 10: Attributes of the TEXT data type.23
Table 11: Attributes of the CODED_TEXT data type. 25
Table 12: Attributes of the Coded Value (CV) data type. 26
Table 13: Attributes of the Coded with Equivalents (CE) data type. 26
Table 14: Attributes of Concept Descriptor (CD) data type . 27
Table 15: Attributes of Concept Role (CR) data type . 28
Table 16: Attributes of Ordinal data type . 31
Table 17: Attributes of Physical Quantity data type . 32
Table 18: Attributes of Physical Quantity data type . 33
Table 19: Attributes of Quantity Ratio . 34
Table 20: Attributes of Quantity Range. 35
Table 21: Attributes of Date . 36
Table 22: Attributes of TS . 37
Table 23: Attributes of Interval of Time. 40
Table 24: Attributes of Periodic Interval of Time. 41
Table 25: Attributes of Event Related Periodic Interval of Time . 42
Table 26: Null Flavor values. 44
Table 27: MIME media types . 45
Table 28: Character set codes as defined by IANA. 46
Table 29: Compression Algorithms. 47
Foreword
This document CEN/TS 14796:2004 has been prepared by Technical Committee CEN/TC 251 “Health
Informatics”, the secretariat of which is held by SIS.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to announce this Technical Specification: Austria, Belgium, Cyprus,
Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia,
Slovenia, Spain, Sweden, Switzerland and United Kingdom.
Introduction
ISO standards have existed for data types for some time, and especially significant is ISO 11404
(1994) Language Independent Data types. Since 1994 most data typing has been based upon or
harmonised with this standard. However, in healthcare information communication a different source
of ‘data type standardisation’ has arisen, sourced by Health Level Seven (HL7), whose data types
often resemble but are not wholly compatible with ISO 11404.
In developing this Technical Specification there has been the wish to harmonise with the HL7 data
types so that the health informatics industry in Europe and the USA can more easily be aligned. To
this end a collaboration agreement was entered into in March 2000 between CEN/TC 251 and HL7.
The goal was set for a maximum degree of alignment while maintaining their independence and need
to serve the business requirements of the respective markets but also to make the results available to
ISO for possible international standardisation.
This Technical Specification differs from the HL7 abstract data types in two major ways:
• Primitive data types are not re-defined here – they are assumed to be available in any
engineering environment that implements this specification. All other data types are defined
here
• This TS says nothing about operations that are associated with any particular data type.
Where a data type has been inherited from previously issued international standards the
associated operations may be assumed but are not specifically referred to in this document.
In most other respects, this specification may be regarded as a sub set of the HL7 Version 3 abstract
data types although partly described differently due to the fact that CEN is following the ISO rules for
drafting and presentation of standards which HL7 is not.
This version attempts to include insights gained as a result of recent CEN/HL7 harmonisation, and to
correct errors, where they were known to exist, particularly with respect to improving the technical
quality of the underlying abstract models. There are still some incomplete specifications, which are
indicated where appropriate.
The distinction between Primitive and Constructed data types has been tightened up.
Constructed types are divided into 4 packages for convenience (Basic, Text, Quantity, Time
Specification)
It is intended that, following further harmonisation work with HL7, and after there has been an
opportunity to gain implementation experience of using this specification, the TS will be developed into
a full European Standard (EN). By that stage the UML model will be extended to include all necessary
operations and formal invariants, together with attribute optionalities. For information on this process,
see www.centc251.org.
1 Scope
This Technical Specification defines abstract data types for use in communicating healthcare information and
for other health informatics purposes.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 11404 Information technology -- Programming languages, their
environments and system software interfaces -- Language-
independent datatypes
ISO 8601:2000(E) Data elements and interchange formats – Information
interchange – Representation of dates and times
Second edition 2000-12-15
ISO/IEC 8824-1 Information technology -- Abstract Syntax Notation One (ASN.1):
Specification of basic notation
ISO/IEC 10646-1
Information technology -- Universal Multiple-Octet Coded
Character Set (UCS) -- Part 1: Architecture and Basic Multilingual
Plane.
IEEE 754-1985 Standard for Binary Floating-Point Arithmetic
ISO 639:1988 (E/F) Code for the representation of names of languages
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply
3.1
data type
a set of distinct values, characterised by properties of those values and by operations on those values
3.2
date
identification of a particular calendar day, expressed by some combination of the data elements calendar year,
calendar month, calendar week, calendar day or day of the year
3.3
implementable technology specification
description of how to implement data types in a particular context (organisation, country, programming
language etc)
3.4
literal form
concise character string representation of information of a certain data type
EXAMPLE: the decimal digit string “1234” as a valid literal form for some number data types
3.5
null flavor
reason for the absence of a valid data value
3.6
period of time ( = time-interval)
portion of time between two time points
NOTE: A period of time is often also referred to as period
3.7
recurring time-interval
series of consecutive time-intervals of the same duration
3.8
time-point
instant in the laps of time regarded as dimensionless
3.9
value domain
set of valid data values for a data type
3.10
vocabulary domain
value domain for coded values
4 Abbreviations
BIN Binary Data
BL Boolean Data Value
CD Concept Descriptor
CE Coded with Equivalents
CR Concept Role
CS Coded Simple Value
CV Coded Value
DV Data Value
ED Encapsulated Data
EIVL Event Related Periodic Interval of Time
HL7 Health Level Seven
II Instance Identifier
ITS Implementable Technology Specification
IVL Interval
OID ISO object identifier
ORD Ordinal
PIVL Periodic Interval of Time
PQ Physical Quantity
RTO Ratio
ST Simple Text
TS Time Point
URI Universal Resource Identifier
UTC Coodinated Universal Time
XML Extensible Markup Language
5 Introduction to abstract data type definitions
The classes that form the abstract model of the data types are grouped for convenience into Packages as
shown in Fig 1 below
CENDataTypes
(from Logical View)
Primitives
Package
DV Package
Basic Package
Text Package
(from DV Package) (from DV Package)
Quantity Package
TimePackage
(from DV Package)
(from DV Package)
Figure 1: Packages
NOTE The names of Primitive classes (those that adopt industry standard definitions) are shown in lower case
Capitalised, whereas constructed classes defined in this specification are have their names shown in CAPITALS.
5.1 Data values and data types
Data types define the meaning (semantics) of data values that can be assigned to a data element. Meaningful
exchange of data requires that we have a shared understanding and agreed definitions for the types of data
used in the exchange.
According to ISO 11404, a data type is "a set of distinct values, characterised by properties of those values
and by operations on those values”. This TS restricts itself inasmuch as it does not yet define
operations on data values for any of its data types.
A data type defines the properties exposed by every data value of that type. Data types have a set of data
values that are of that type (i.e. the type's "value set").
A semantic property of a data type is referred to by a name and has a value for each data value. The value of
a data value's property must itself be a value defined by a data type - no data value exists that would not be
defined by a data type.
Data types are thus the basic building blocks used to construct any higher order meaning: messages,
computerised patient record documents, or business objects and their transactions.
5.2 Representation of Data Values
Data values can be represented through various symbols but the data value's meaning is not bound to any
particular representation.
The number five can be represented by the word "five" by the Arabic number "5" or the Roman number "V".
The representation does not matter so long as it conforms to the semantic definition of the data type.
Another example, the Boolean data type is defined by its extension, the two distinct values true and false and
the rules of negation and combining these values in conjunction and disjunction. The representation of
Boolean values can be the words "true" and "false," "yes" and "no," the numbers 0 and 1, any two signs that
are distinct from each other. The representation of data types does not matter as long as it conforms to the
semantic definition of the data type.
This specification defines the semantics, the meaning of the data types, independent of representational and
operational concerns or specific implementation technologies.
Additional standards for representing the data values defined here are being specified for various
technological approaches, e.g. for XML. These standards are called "Implementable Technology
Specification" (ITS) and extend the basic specification provided in this document. A variety of ITS could
therefore be defined for the set of data types specified here. These standards would define how values are
represented so that they conform to the semantic definitions of this specification and may include syntaxes for
character or binary representations, and computer procedures to act on the representation of data values.
5.3 Properties of Data Values
Data values have properties defined by their data type. The "fields" of "composite data types" are the most
common example of such properties. The properties of a data type should be considered as logical predicates
or as mathematical functions.
A property is referred to by its name. For example, the data type integer may have a property named "sign." A
property has a domain, which is the set of possible "answer" values. The set of possible "answer" values is
defined by the property's data type, but the domain of a property may be a subset of the data type's value set.
Any concrete implementation of these information model standards must ultimately use the built-in data types
of their implementation technology. Therefore, we need a very flexible mapping between abstract data types
and those data types built into any specific implementation technology.
This specification only requires that the properties defined for data values can somehow be inferred from
whatever representation is chosen, it does not matter how these values are represented. For example, a
decimal representation, a floating-point register and a scaled integer are all possible native representations of
real numbers for different implementation technologies. Some of these representations have properties that
others do not have. Scaled integers, for instance, have a fixed precision and a relatively small range.
Floating-point values have variable precision and a large range, but floating-point values lose any information
about precision. Decimal representations are of variable precision and maintain the precision information (yet
are slow to process.) The data type semantics must be independent from all these accidental properties of the
various representations, and must define the essential properties that any technology should be able to
represent.
5.4 Characteristics of the data types
These data types may be characterised by:
 type name and possibly a short name
 informal description
 use
 specialisation of
 attributes and their semantic properties
 syntax of character string value literals (if any)
6 Primitive data types
6.1 Introduction
The following types are ‘atomic’ inasmuch as they are not defined as composites of other data types.
Each of these primitive types is already the subject of existing international standards and has very similar
definitions in different implementation technologies.
This document does not attempt to redefine these primitive types but provides references to the standards
where they are defined.
6.2 Primitive type set
6.2.1
The following list is set of primitive data types that are referenced and utilised within this specification. In
addition to the primitive data types, three ‘primitive’ abstract types are described. These are Numeric, Integer
and Real. They have no attributes of their own but are used as generalisations of certain of the concrete
types which are their specialisations.
 Boolean
 String
 Integer
 Byte
 Real
 Double
 Character
 List
 Set
 Bag
 Array
6.2.2
A Unified Modeling Language (UML) representation of these primitive types is shown below.
Primitives Package
(from CENDataTypes)
Note: these classes do not inherit
from DATA_VALUE
Boolean String Character Set
List Array Bag
Byte Integer Real
Double
Figure 2: UML Representation of Primitive data types
6.3 Numeric Types
6.3.1 Names and formats
Table 1:  Names and formats of numeric data types
Type name Type description Size/format
Byte byte-length integer 8-bit two's complement
Integer standard integer 32-bit two's complement
Real single-precision floating point 32-bit IEEE 754
Double double-precision floating point 64-bit IEEE 754
6.3.2 Literal Form
A real number is represented in decimal form with optional + or - sign, and optional decimal point, and
optional exponential notation using a case insensitive “e” between the mantissa and the exponent. The
number of significant digits must conform to the precision property.
Alternative representations two thousand are 2000, 2000.0, 2e3, 2.0e+3, +2.0e+3.
Note that the literal form does not carry type information. For example, “2000” is a valid representation of both
a real number and an integer number. No trailing decimal point is used to disambiguate from integer
numbers. An ITS that uses this literal form must recover the type information from other sources.
6.3.3 Infinite values: In certain situations it is necessary to refer to the exceptional real values of positive
and negative infinity. This specification recognises that these values are generally only met as a part of a
range of values such as 0.0 to +¥ or +¥ to -¥ (see QuantityRange), and specific representations of positive
and negative infinity are not defined here.
Table 2: Content of 32-bit floating point bit positions.
Bit Positions Content
(most significant bit to
least significant bit)
1sign
2 – 9 exponent
10 – 32 mantissa
Table 3: Content of 64-bit floating point bit positions.
Bit Positions Content
(most significant bit to
least significant bit)
1sign
2 – 12 exponent
13 – 64 mantissa
6.4 Set
6.4.1 Short name: none
6.4.2 Description:  A set is a value that contains other values of a certain data type as its elements. The
elements are contained in no particular ordering.
All elements in the set are distinct, i.e. the same element value cannot be contained more than once in the set
The primitive semantic property of a set is the contains-relation of elements in the set. On this semantic
primitive, all other properties are defined. A set may only contain distinct non-NULL elements. Exceptional
values (NULL-values) cannot be elements of a set.
The empty set is a set without any elements. The empty set is a proper set value, not an exceptional (NULL)
value. The cardinality of a set is the number of distinct elements in the set.
The cardinality definition is not sufficient since it doesn’t converge for uncountable infinite sets (Real, PQ, etc.)
and it doesn’t terminate for infinite sets. In addition, the definition of integer number type in this specification is
incomplete for these cases, as it doesn’t account for infinities. Finally the cardinality value is an example
where it would be necessary to distinguish the cardinality aleph0 of countable infinite sets (e.g., INT) from
aleph1, the cardinality of uncountable sets (e.g., Real, PQ).
NOTE Cardinality can be finite (a non-negative integer) or infinite. It can be used to demonstrate that some infinite
sets are larger than others. The cardinality of the set of real numbers is greater than the cardinality of the set of integers,
although both sets are infinite! The cardinality of the set of integers is known as aleph-null or aleph0 and the cardinality of
the set of real numbers is known as aleph1. E.g. aleph0 is the first infinite cardinal, Aleph1 is the next cardinal number
indicating the next size of infinity etc.
6.5 Sequence
6.5.1 Short name: LIST
Description:  A sequence is an ordered collection of discrete values.
Elements in the sequence are not necessarily distinct, i.e. the same element value can be contained more
than once in the sequence
A sequence has a head and a tail. All non-NULL sequences must have at least a head or a tail that is non-
NULL. A sequence without at least either a head or a tail is indistinguishable from the NULL value.
A NULL sequence has length zero.
The length of a sequence is the count of elements in the sequence. NULL elements are counted as regular
sequence elements with the exception of the last element. As stated above, a sequence without at least a
non-NULL head or a tail is a NULL-sequence of zero length. Therefore, if the last element of a sequence is
NULL it is not counted towards the length of the list.
Two lists are equal if and only if both their head and their tail are equal.
6.6 Bag
6.6.1 Short name: none
Description:  A bag is an unordered collection of elements where each element can be contained more than
once in the bag.
The semantic primitive for bags is the contains-function that maps element values to non-negative integer
numbers, where zero means that the element value is not contained in the bag. An empty bag is
distinguished from an exceptional bag value (the NULL bag.).
6.7 Array
6.7.1 Short name: none
Description:  A physical container of items indexed by number
7 Constructed Data Types
Note: where short names for classes are given, they are broadly equivalent to the corresponding HL7 data
type of that short name.
7.1 DATA_VALUE
7.1.1 Short name: DV
7.1.2 Description
Defines the basic properties of every data value type. This is an abstract type, instantiated as one of the
Constructed types defined below.
7.1.3 Use
Every constructed type is a specialisation of this general abstract data type. The subtypes of DV provide a
complete set of data value types for use as the type of the value attribute of the leaf node class of a hierarchy
defined in reference models for e.g. EHR, EHR_Extract, Message.
7.1.4 Attributes
Attributes Type Properties
nullFlavor CS_NULL_FLAV If a value is an exceptional value (NULL-value), this attribute may
be used to specify in what way and why proper information is
missing. See Table 26: Annex A for values NULL_FLAVOR.
7.2 Basic data types
7.3 Introduction
This section describes those data types which utilise the primitive data types described in Section 7, but, for
documentary/diagram purposes, exclude all the Text, Time, and Quantity types (these are shown in separate
packages).
The basic data types described here are all specialisations of DATA_VALUE and Figure 3:below provides a
UML representation of them.
Basic Package
(from DV Package)
DATA_VALUE
nullFlavor : CS_NULL_FLAV
BL
IVL
ED
value : Boolean
low : T
mediaType : CS_MEDIA
high : T
charset : CS_CHARSET
lowClosed : Boolean
language : CS_LANG
highClosed : Boolean
size : Integer
URI
width : T_DIFF
compression : CS_COMPRESSION
value : String
reference : URI
scheme : String
integrityCheck : Array
path : String
integrityCheckAlgorithm : String
fragment_id : String
thumbnail : ED
query : String
data : Array
literal : String
alternateString : SIMPLE_TEXT
II
extension : String
assigningAuthorityName : String
validTime : IVL
root
OID
oid : String
Figure 3: UML Representation of Basic data types
7.4 Encapsulated Data
7.4.1 Short name: ED
7.4.2 Description: Data that are primarily intended for human interpretation or for further machine
processing outside the scope of this specification. This includes unformatted or formatted written language,
multimedia data, or structured information as defined by a different standard (e.g. XML-signatures).
NOTE: Encapsulated data can be present in two forms, inline or by reference. Inline data are communicated or moved as
part of the encapsulated data value, whereas by-reference data may reside at a different (remote) location. The data are
the same whether they are located inline or remote.
7.4.3 Specialisation of: DATA_VALUE
7.4.4 Attributes
Table 4: Attributes of encapsulated data (ED)
Attributes Type Properties
mediaType CS_MEDIA Identifies the encoding of the encapsulated data and
identifies a method to interpret or render the data.
See Table 27: of MIME data types in the Annex B.
charset CS_CHARSET Where applicable, specifies the character set and
character encoding used. Otherwise Void
Use IANA character set name if data is formatted text.
See Table 28: in the Annex B.
NOTE: The character set may be implied or fixed by the
ITS.
Name of language used if data is formatted text, from
language CS_LANG
ISO 639:1988 (E/F) "Code for the representation of
names of languages".
Otherwise Void.
size in bytes of data.
size Integer
compression CS_COMPRESSION Indicates whether the raw byte data is compressed, and
what compression algorithm was used.
Void means no compression
reference URI
URI reference to electronic information stored outside
the record as a file, database entry etc, if supplied as a
reference.
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. The reference must point to the same data as
provided inline.
integrityCheck Array A short binary value representing a cryptographically
strong checksum over the binary data.
integrityCheckAl String Specifies the algorithm used to compute the
gorithm integrityCheck value.
thumbnail ED An abbreviated rendition of the full data.
data Array the actual data if supplied inline
Text to display in lieu of multimedia display/replay
alternateString SIMPLE_TEXT
7.4.5 Properties of Encapsulated Data
7.4.5.1 Introduction
Certain of the attributes require additional specification to that provided in the above table. These are
provided in this sub-section.
7.4.5.2 mediaType : CS_MEDIA
Identifies the encoding of the encapsulated data and identifies a method to interpret or render the data. This
is specified using the MIME media types codes, defined by the Internet Assigned Numbers Authority (IANA).
To promote interoperability, this specification prefers certain media types to others. This is to define a
greatest common denominator on which interoperability is not only possible, but that is powerful enough to
support even advanced multimedia communication needs.
The set of required media types, however, is very small so that no undue requirements are forced on
applications, especially legacy systems. In general, no application is forced to support any given kind of
media other than written text.
7.4.5.3 charset : CS_CHARSET
For character-based encoding types, this property specifies the character set and character encoding used.
The charset is defined according to Internet RFC 2278, IANA Charset Registration Procedures,
[http://www.isi.edu/in-notes/rfc2278.txt].
The charset domain is maintained by the Internet Assigned Numbers Authority (IANA) [http://www.isi.edu/in-
notes/iana/assignments/character-sets].
7.4.5.4 compression : CS_COMPRESSION
Indicates whether the raw byte data is compressed, and what compression algorithm was used. Suitable
compression algorithms are given in Table 29: of the Annex.
7.4.5.5 integrityCheck : Array
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.
The integrity check is calculated according to the integrity check algorithm. By default, the Secure Hash
Algorithm-1 (SHA-1) shall be used. The integrity check is binary encoded according to the rules of the
integrity check algorithm.
The integrity check is calculated over the raw binary data that is contained in the data component, or that is
accessible through the reference. No transformations are made before the integrity check is calculated. If the
data is compressed, the Integrity Check is calculated over the compressed data.
7.5 Instance Identifier
7.5.1 Short name: II
7.5.2 Description:  Used to uniquely identify an instance, thing or object.
EXAMPLES: Identifiers for: medical record number, order id, service catalogue item id, Vehicle Identification
Number (VIN), etc.
NOTE: Instance identifiers are defined based on ISO object identifiers
7.5.3 Specialisation of: DATA_VALUE
7.5.4 Attributes
Table 5: Attributes of Instance Identifier (II)
Name Type Status Definition
extension String Optional The value of the identifier, unique within its
assigning authority’s namespace.
root OID Mandatory A unique identifier that guarantees the global
uniqueness of the instance identifier. The root
alone may be the entire instance identifier, an
extension value is not needed.
assigningAuthorityN String Optional A human readable name or mnemonic for the
ame assigning authority. This name is provided solely
for the convenience of unaided humans
interpreting an II value.
Note: no automated processing must depend on
the assigning authority name to be present in any
form.
validTime IVL Optional If applicable, specifies during what time the
identifier is valid. By default, the identifier is valid
indefinitely. Any specific interval may be undefined
on either side indicating unknown effective or
expiry time.
Note: identifiers for information objects in computer
systems should not have restricted valid times, but
should be globally unique at all times. The
identifier valid time is provided mainly for real-
world identifiers, whose maintenance policy may
include expiry (e.g., credit card numbers.)
7.6 ISO Object Identifier
7.6.1 Short name: OID
7.6.2 Description: An ISO Object Identifier (OID) is a globally unique string consisting of numbers and dots
(e.g., 2.16.840.1.113883.3.1). This string expresses a tree data structure, with the left-most number
representing the root and the right-most number representing a leaf.
NOTE: Each branch under the root corresponds to an assigning authority. Each of these assigning authorities may, in
turn, designate its own set of assigning authorities that work under its auspices, and so on down the line. Eventually, one
of these authorities assigns a unique (to it as an assigning authority) number that corresponds to a leaf node on the tree.
The leaf may represent an assigning authority (in which case the OID identifies the authority), or an instance of an object.
An assigning authority owns a namespace, consisting of its sub-tree.
7.6.3 Attributes:
Table 6: Attributes of the OID data type
Attributes Type Properties
oid String A globally unique string identifier consisting of numbers and dots.
7.7 Universal Resource Identifier
7.7.1 Short name: URI
7.7.2 Description: A type of telecommunications address specified as Internet standard RFC 1738
[http://www.isi.edu/in-notes/rfc1738.txt].
NOTE 1: The URI specifies the protocol and the contact point defined by that protocol for the resource.
NOTE 2: Notable uses of the telecommunication address data type is for telephone and telefax numbers, e-mail
addresses, Hypertext references, FTP references, etc
NOTE 3: URLs are normally represented in a character string, formatted as “: