ISO 21090:2011
(Main)Health informatics — Harmonized data types for information interchange
Health informatics — Harmonized data types for information interchange
ISO 21090:2011 - provides a set of datatype definitions for representing and exchanging basic concepts that are commonly encountered in healthcare environments in support of information exchange in the healthcare environment; - specifies a collection of healthcare-related datatypes suitable for use in a number of health-related information environments; - declares the semantics of these datatypes using the terminology, notations and datatypes defined in ISO/IEC 11404, thus extending the set of datatypes defined in that standard; - provides UML definitions of the same datatypes using the terminology, notation and types defined in Unified Modelling Language (UML) version 2.0; - specifies an XML (Extensible Mark-up Language) based representation of the datatypes. The requirements which underpin the scope reflect a mix of requirements gathered primarily from HL7 Version 3 and ISO/IEC 11404, and also from CEN/TS 14796, ISO 13606 (all parts) and past ISO work on healthcare datatypes. ISO 21090:2011 can offer a practical and useful contribution to the internal design of health information systems, but is primarily intended to be used when defining external interfaces or messages to support communication between them.
Informatique de santé — Types de données harmonisées pour une interchangeabilité d'informations
L'ISO 21090:2011 fournit un jeu de définitions de types de données permettant de représenter et d'échanger les concepts de base couramment rencontrés dans les environnements de santé pour assurer l'interchangeabilité d'informations relevant du domaine des soins de santé; spécifie un recueil de types de données de santé pouvant être utilisées dans un certain nombre d'environnements d'informations de santé; déclare la sémantique de ces types de données sur la base de la terminologie, des notations et des types de données définis dans l'ISO/CEI 11404, augmentant ainsi le jeu de types de données défini dans la présente Norme internationale; fournit les définitions UML de ces mêmes types de données sur la base de la terminologie, de la notation et des types définis dans le Unified Modeling Language (UML: langage de modélisation unifié) version 2.0; définit une représentation basée sur le langage XML [Extensible Markup Language (langage de balisage) extensible] des types de données. Le domaine d'application constitue une combinaison des exigences compilées principalement de la Version 3 d'HL7 et de l'ISO/CEI 11404, et également de celles issues de la CEN/TS 14796, de l'ISO 13606 (toutes les parties) et des travaux antérieurs de l'ISO sur les types de données de soins de santé. L'ISO 21090:2011 peut contribuer de manière pratique et utile à la conception interne des systèmes d'information de santé mais elle est principalement destinée à être utilisée pour la définition des interfaces externes ou des messages destinés à prendre en charge leur communication interne.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 21090
First edition
2011-02-15
Health informatics — Harmonized data
types for information interchange
Informatique de santé — Types de données harmonisées pour une
interchangeabilité d'informations
Reference number
©
ISO 2011
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO 2011
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2011 – All rights reserved
Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Normative references.1
3 Terms and definitions .2
4 Abbreviated terms.4
5 Conformance .5
5.1 General .5
5.2 Direct conformance.5
5.3 Indirect conformance.7
6 Datatypes overview .9
6.1 What is a datatype?.9
6.2 Definitions of datatypes.9
6.3 Datatype names and re-use of common datatype names.10
6.4 Mapping to this datatypes International Standard.10
6.5 Conformance with ISO/IEC 11404.10
6.6 Reference to UML 2.11
6.7 Modelling of datatypes.11
7 Datatypes .15
7.1 General properties.15
7.2 Top level model .20
7.3 Basic datatypes .22
7.4 Text and binary datatypes .33
7.5 Coded datatypes (terminology) .48
7.6 Identification and location datatypes.61
7.7 Name and address datatypes.72
7.8 Quantity datatypes .93
7.9 Collections of datatypes.121
7.10 Continuous set datatypes.136
7.11 Uncertainty datatypes.155
7.12 Structured text .158
Annex A (normative) XML representation.180
Annex B (normative) UML support types.183
Annex C (informative) RM-ODP viewpoint mappings .186
Annex D (informative) HL7 V3 Abstract Data Types mapping.187
Annex E (informative) Schema for XML representation.194
Bibliography.195
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 21090 was prepared by Technical Committee ISO/TC 215, Health informatics.
iv © ISO 2011 – All rights reserved
Introduction
Assistance from the Infrastructure and Messaging Committee in HL7 and the support of Connecting for Health
have been instrumental in the preparation of this International Standard, which is a shared document between
Health Level Seven (HL7) and ISO, and has been produced according the terms of the agreement between
HL7, CEN and ISO (JIC, see http://www.global-e-health-standards.org/), which ensures that the content is
fully available through ISO, CEN and HL7 publication channels.
INTERNATIONAL STANDARD ISO 21090:2011(E)
Health informatics — Harmonized data types for information
interchange
1 Scope
This International Standard
⎯ provides a set of datatype definitions for representing and exchanging basic concepts that are commonly
encountered in healthcare environments in support of information exchange in the healthcare
environment;
⎯ specifies a collection of healthcare-related datatypes suitable for use in a number of health-related
information environments;
⎯ declares the semantics of these datatypes using the terminology, notations and datatypes defined in
ISO/IEC 11404, thus extending the set of datatypes defined in that standard;
⎯ provides UML definitions of the same datatypes using the terminology, notation and types defined in
Unified Modelling Language (UML) version 2.0;
⎯ specifies an XML (Extensible Mark-up Language) based representation of the datatypes.
The requirements which underpin the scope reflect a mix of requirements gathered primarily from HL7
Version 3 and ISO/IEC 11404, and also from CEN/TS 14796, ISO 13606 (all parts) and past ISO work on
healthcare datatypes.
This International Standard can offer a practical and useful contribution to the internal design of health
information systems, but is primarily intended to be used when defining external interfaces or messages to
support communication between them.
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 4217, Codes for the representation of currencies and funds
ISO/IEC 8601, Data elements and interchange formats — Information interchange — Representation of dates
and times
ISO/IEC 8824 (all parts), Information technology — Abstract Syntax Notation One (ASN.1)
ISO/IEC 11404:2007, Information technology — General-Purpose Datatypes (GPD)
ISO/TS 22220, Health Informatics — Identification of subjects of health care
IETF RFC 1738, Uniform Resource Locators (URL)
IETF RFC 1950, ZLIB Compressed Data Format Specification version 3.3
IETF RFC 1951, DEFLATE Compressed Data Format Specification version 1.3
IETF RFC 1952, GZIP file format specification version 4.3
IETF RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
IETF RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
IETF RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax
IETF RFC 3066, Tags for the Identification of Languages
1)
IETF RFC 3966, The tel URI for Telephone Numbers
FIPS PUB 180-1, Secure Hash Standard
2)
FIPS PUB 180-2, Secure Hash Standard
Open Group, CDE 1.1, Remote Procedure Call specification, Appendix A
HL7 V3 Standard, Data Types — Abstract Specification (R2)
3)
Regenstrief Institute, Inc. and the UCUM Organization, The Unified Code for Units of Measure
4)
W3C Recommendation, XML Signature Syntax and Processing
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
attribute
characteristic of an object that is assigned a name and a type
NOTE The value of an attribute can change during the lifetime of the object.
3.2
class
descriptor for a set of objects with similar structure, behaviour and relationships
3.3
code
concept representation published by the author of a code system as part of the code system, being an entity
of that code system
1) Revision of IETF RFC 2806.
2) Revision of FIPS PUB 180-1.
3) Regenstrief Institute, Inc. and the UCUM Organization, Indianapolis, Indiana, USA [viewed 2010-08-23]. Available
from: http://aurora.regenstrief.org/ucum.
4) World Wide Web Consortium (W3C) [viewed 2010-08-23]. Available from: http://www.w3.org/TR/xmldsig-core/.
2 © ISO 2011 – All rights reserved
3.4
code system
managed collection of concept identifiers, usually codes, but sometimes more complex sets of rules and
references
NOTE They are often described as collections of uniquely identifiable concepts with associated representations,
designations, associations and meanings.
EXAMPLES ICD-9, LOINC and SNOMED
3.5
concept
unitary mental representation of a real or abstract thing; an atomic unit of thought
NOTE 1 It should be unique in a given code system.
NOTE 2 A concept can have synonyms in terms of representation and it can be a primitive or compositional term.
3.6
conformance
fulfillment of a specified requirement; adherence of an information processing entity to the requirements of one
or more specific specifications or standards
3.7
datatype
set of distinct values, characterized by properties of those values, and by operations on those values
3.8
enumeration
datatype whose instances are a set of user-specified named enumeration literals
NOTE The literals have a relative order, but no algebra is defined on them.
3.9
generalization
taxonomic relationship between a more general class, interface or concept and a more specific class,
interface or concept
NOTE 1 Each instance of the specific element is also an instance of the general element. Thus, the specific element
has all the features of the more general element.
NOTE 2 The more specific element is fully consistent with the more general element and contains additional
information.
NOTE 3 An instance of the more specific element can be used where the more general element is allowed.
3.10
information processing entity
anything that processes information and contains the concept of datatype, including other standards,
specifications, data handling facilities and services
3.11
inheritance
mechanism by which more specific elements incorporate structure and behaviour of more general elements
3.12
interface
specifier for the externally-visible operations of class, without specification of internal structure
3.13
invariant
rule about the features of a class which must always be true
3.14
operation
service that an instance of the class may be requested to perform
NOTE An operation has a name and a list of arguments with assigned names and types, and returns a value of the
type specified.
3.15
specialization
taxonomic relationship between a more general class, interface or concept and a more specific class,
interface or concept where the more specific entity adds new features or redefines existing features by
constraining their possible behaviours
3.16
string character set
character set used in all string content throughout this International Standard
3.17
valueSet
that which represents a uniquely identifiable set of valid concept representations, where any concept
representation can be tested to determine whether or not it is a member of the value set
NOTE A concept representation can be a single concept code or a post-coordinated combination of codes.
4 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
CEN Comité Européen de Normalisation (European Committee for Standardization)
CNE Coded no exceptions
CWE Coded with exceptions
GPD General-Purpose Datatypes
HL7 Health Level Seven, Inc.
IETF Internet Engineering Task Force
OID Object Identifier
OMG Object Management Group
UML Unified Modelling Language
W3C World Wide Web Consortium
XML Extensible Mark-up Language
4 © ISO 2011 – All rights reserved
5 Conformance
5.1 General
An information processing product, system, element or other entity may conform to this International Standard
either directly, by utilizing datatypes specified in this International Standard in a conforming manner, or
indirectly, by means of mappings between internal datatypes used by the entity and the datatypes specified in
this International Standard.
NOTE The term "information processing entity" is used as defined in 3.10, which is consistent with how it is used in
ISO/IEC 11404:2007, Clause 4. Specifically, this definition includes applications and also other standards and
specifications.
5.2 Direct conformance
5.2.1 Direct conformance definition
An information processing entity which conforms directly to this International Standard shall:
a) specify which of the datatypes specified in Clause 7 are provided by the entity and which are not;
b) define the value spaces of the healthcare datatypes used by the entity to be identical to the value spaces
specified by this International Standard;
c) specify to what extent the value spaces of the datatypes are constrained for use within its own context;
d) to the extent that the entity provides operations other than movement or translation of values, define
operations on the healthcare datatypes which can be derived from, or are otherwise consistent with, the
characterizing operations specified by this International Standard;
e) represent these datatypes using the Extensible Mark-up Language (XML) representation described
herein, when the datatypes are represented in XML;
f) optionally, publish a formal conformance profile making these statements clear, or reference one
published by some other information processing entity.
The above-mentioned requirements prohibit the use of a type-specifier defined in this International Standard
to designate any other datatype (but, see 6.3 concerning the scope of the datatype names). They make no
other limitation on the definition of additional datatypes in a conforming entity. For instance, a directly
conforming information processing entity could continue to use ISO/IEC 11404 general-purpose datatypes in
addition to these healthcare datatypes.
Requirement d) does not require all characterizing operations to be supported and permits the provision of
additional operations. The intention is to permit the addition of semantic interpretation to the datatypes, as
long as it does not conflict with the interpretations given in this International Standard. A conflict arises only
when a given characterizing operation could not be implemented or would not be meaningful, given the entity
provided operations on the datatype.
Examples of entities that could conform directly are language definitions or healthcare specifications whose
datatypes, and the notation for them, are those defined herein. In addition, the verbatim support by a software
tool or application package of the datatype syntax and definition facilities herein should not be precluded.
Information processing entities claiming direct conformance with this International Standard do not always
need to use the datatypes defined in this International Standard to represent the concepts, i.e. simply because
an address datatype is defined does not mean that the address datatypes must always be used for
representing addresses. However, the type defined within this International Standard shall be used where the
context is interoperability using these datatypes.
Information processing entities claiming direct conformance with this International Standard may further
constrain the value domain of any of the datatypes within their context of use. The conformance statement
shall make clear how constraints are applied within the information processing entity and how values that do
not conform to the imposed constraints are handled.
Consistency of characterizing operations specified by conforming entities may be assessed by these criteria.
Where operations have the same name as the operation defined within this International Standard, they are
consistent if the operation can be invoked with the same parameters to return the same result. Other
parameters may be defined, but shall have default values or be defined using additional definitions of
operations with the same name but other parameter lists.
Information processing entities claiming direct conformance are not required to call any or all of the types
defined in this International Standard "types". Other terms such as "data structures" may be used.
5.2.2 Conformance statements
When an information processing entity claims direct conformance with this International Standard, it should
make a conformance statement.
It is anticipated that other standards bodies would make conformance statements with regard to this
International Standard both in a general sense and in the sense of adopting these datatypes for a particular
standard. In addition, it is anticipated that certain countries publish profiles of these datatypes on either an
advisory or a normative basis. Finally, vendors and purchasers of healthcare applications may well find use in
creating, sharing and publishing these conformance statements.
This International Standard makes no rules about either the form of the statement or how it is published, but it
should be clearly and formally presented and made available to all interested parties associated with the
scope of the information processing entity.
In addition to specifying that conformance statements shall contain formal statements pertaining to
5.2.1 a) to d), this International Standard makes additional rules about what they shall or should say or may
choose to do.
5.2.2.1 Direct conformance statements shall:
a) define which character set and encoding applies; the default is Unicode (see 6.7.5);
b) if an alternative mechanism for providing history and audit data is provided, define how it maps to the
history and audit information on datatypes (see 7.1.3);
c) make clear how attribute and collection cardinality are specified (see 7.1.5);
d) define how the attributes nullFlavor, updateMode and flavorId on ANY are managed (see 7.3.3);
e) if quantities are used, make clear exactly how and when the QTY attributes expression, originalText,
uncertainty and uncertaintyType are used;
f) make clear what methods may be used to provide alternative definitions for discrete set uniqueness
(see 7.9.3);
g) if the structured documents types are used, document the scope of the document context and clearly
define how references within this document context are resolved (see 7.12);
h) specify to what degree the XML format is adopted and define the namespace that is used (see A.1).
5.2.2.2 Direct conformance statements should:
a) define defaulting rules for language (see 7.4.2.3.7);
b) declare what languages are supported in the QTY.expression property (see 7.8.2.3.1);
6 © ISO 2011 – All rights reserved
c) describe which codes may be used in QSC.code (see 7.10.8.3);
d) if the structured documents types are used, define how version tracking works in the contexts where it is
used (see 7.12.12.2.1).
5.2.2.3 Direct conformance statements may also:
a) define additional datatype flavors or additional authorities for the definition of flavors (see 6.7.6);
b) make additional arrangements for the use of derived data and the DER NullFlavor (see 7.1.4);
c) define how the controIInformationRoot and controlInformationExtension properties on HXIT are used
(see 7.3.2.3.4);
d) clarify how telecommunication and postal addresses are selected for particular purposes (see 7.6.2.3.2);
e) define the code systems to which different name and address part types are bound (see 7.7.3.6 and
7.7.5.6).
5.3 Indirect conformance
5.3.1 Indirect conformance definition
An information processing entity which conforms indirectly to this International Standard shall:
a) provide mappings between its internal datatypes and the healthcare datatypes conforming to the
specifications of Clause 7;
b) specify for which of the datatypes in Clause 7 an inward mapping is provided, for which an outward
mapping is provided and for which no mapping is provided;
c) specify whether the XML representation described in this International Standard is used when the
datatypes are represented in XML, or whether it is used optionally to provide an alternative namespace
for the XML representation;
d) optionally, publish a formal conformance profile making these statements clear or reference one
published by some other information processing entity.
Examples of entities which could conform indirectly are healthcare specifications, applications, software
engineering tools and other interface specifications, and many other entities that have a concept of datatype
and an existing notation for it.
Standards for existing healthcare specifications yet to be proposed as International Standards are expected to
provide for indirect conformance rather than direct conformance.
Information processing entities claiming indirect conformance with this International Standard do not always
need to use the datatypes defined in this International Standard to represent the concepts, i.e. simply because
an address datatype is defined does not mean that the address datatypes must always be used for
representing addresses. However the type defined within this International Standard shall be used where the
context is interoperability using these datatypes.
Information processing entities claiming indirect conformance with this International Standard may further
constrain the value domain of any of the datatypes within their context of use. The conformance statement
must make clear how constraints are applied within the information processing entity and how values that do
not conform to the imposed constraints are handled.
Information processing entities claiming indirect conformance are not required to call any or all of the types
defined in this International Standard "types". Other terms, such as "data structures" may be used.
5.3.2 Conformance statements
When an information processing entity claims indirect conformance with this International Standard, it should
make a conformance statement.
This International Standard makes no rules about either the form of the statement or how it is published, but it
should be made available to all interested parties associated with the scope of the information processing
entity.
In addition to specifying that conformance statements shall contain formal statements pertaining to
5.3.1 a) to d), this International Standard makes additional rules about what they shall or should say or may
choose to do.
5.3.2.1 Indirect conformance statements shall:
a) define which character set and encoding applies; the default is Unicode (see 6.7.5);
b) make clear what equality definitions apply and how (see 7.1.2);
c) make clear how attribute and collection cardinality are specified, if relevant (see 7.1.5);
d) if the structured documents types are used, document the scope of the document context and clearly
define how references within this document context are resolved (see 7.12).
5.3.2.2 Indirect conformance statements should:
a) define defaulting rules for language (see 7.4.2.3.7);
b) if any exist, declare the mapping between W3C digital signature and alternate implementations
(see 7.4.5.1).
5.3.2.3 Indirect conformance statements may also:
a) define additional datatype flavors or additional authorities for the definition of flavors (see 6.7.6);
b) make additional arrangements for the use of derived data and the DER NullFlavor (see 7.1.4);
c) define how the controlInformationRoot and controlInformationExtension properties on HXIT are used
(see 7.3.2.3.4);
d) clarify how telecommunication and postal addresses are selected for particular purposes (see 7.6.2.3.2);
e) define the code systems to which different name and address part types are bound (see 7.7.3.6 and
7.7.5.6);
f) declare what languages are supported in the QTY.expression property (see 7.8.2.3.1);
g) describe which codes may be used in QSC.code (see 7.10.8.3);
h) if the structured documents types are used, define how version tracking works in the contexts where it is
used (see 7.12.12.2.1).
8 © ISO 2011 – All rights reserved
6 Datatypes overview
6.1 What is a datatype?
In ISO/IEC 11404, a "datatype" is defined as a set of distinct values, characterized by properties of those
values, and by operations on those values (ISO/IEC 11404:2007, 3.12).
A datatype consists of three main features:
⎯ a value space;
⎯ a set of properties;
⎯ a set of characterizing operations.
Generally, the definitions of the scope of datatypes revolve around one or other of the following notions.
⎯ Immutability (the properties of the datatype cannot change, instead a new instance is created: datatypes
have no lifecycle).
⎯ The relationship between equality and identity (if two datatypes are equal they are the same instance).
⎯ Coherency of a single concept (each datatype should represent a single concept space).
Since the application of these concepts to the healthcare information domain and the implications of these for
the scope of datatypes are inherently a matter of perspective, the selection criterion for the datatypes defined
in this International Standard is based on the set that has emerged from the debates held within the various
stakeholder standardization bodies that define healthcare information standards. Since healthcare information
standards and specifications are expected to provide mappings to this International 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.
6.2 Definitions of datatypes
This International Standard defines a set of named datatypes. Each datatype defined in this International
Standard is allocated both a short name and a long name. The formal name of the datatype is the short name.
Each datatype is defined in two different ways:
⎯ in terms of the datatype specification language and types defined in ISO/IEC 11404;
⎯ in UML, using primitive types taken from the UML kernel package.
The ISO/IEC 11404 definition is provided to ensure continuity between this International Standard and the
ISO/IEC 11404 GPDs, while the UML definition is provided to foster software-driven implementation of these
datatypes. The ISO/IEC 11404 definitions are semantic and abstract in nature, while the UML definitions are
concrete structural definitions. This International Standard is focused on providing structural concrete
definitions, such that the UML definitions take precedence over the ISO/IEC 11404-based definitions, which
are provided in the interests of continuity with ISO/IEC 11404.
The datatypes defined in this International Standard are an implementation of the HL7 V3 Abstract Data
Types (R2). What this means is that it is possible to implement the exchange of information based on the HL7
V3 Abstract Data Type definitions using the datatypes defined in this International Standard. Annex B
demonstrates how these datatypes are implementations of the HL7 V3 Abstract Data Types (R2).
The datatypes defined in this International Standard are not restricted to the features described by the HL7 V3
Abstract Data Types, nor is the HL7 V3 Data Types Abstract specification required in order to make use of
these datatypes. The semantic definitions in the HL7 V3 Abstract Data Types may be consulted for further
useful information to help implementors understand the use of these datatypes.
6.3 Datatype names and re-use of common datatype names
Some of the names of these datatypes bear superficial similarity to similar datatypes defined in other
specifications. For instance, this International Standard defines a type REAL and there is a type Real in
ISO/IEC 11404, and a type called Real in the UML kernel (see Note 1 in B.2.7 concerning the use of floating
value types).
This International Standard is not attempting to redefine or replace the definition of real in ISO/IEC 11404 or
UML. Instead, a new type that wraps the underlying "primitive" type is defined, which builds on the
functionality of the underlying type and fits it into the overall architectural framework.
There are many specifications, languages and implementation technologies that declare similar types to either
the underlying real types or the REAL defined in this International Standard, with a profusion of names around
the common theme of Real, Float, Decimal or Double.
This International Standard does not seek to find new previously unrecognised names for the types it declares
that represent these base concepts; instead it just assigns commonly used names to them. Again, this
International Standard is not attempting to redefine or replace any other definitions by using these common
names.
For these name clashes between the datatypes defined in this International Standard and any other
specification, implementers should use some form of namespacing to ensure that the names of the datatypes
do not cause confusion, perhaps by prefixing the names with some string constant in implementation
environments that do not support proper namespacing of types.
The types BL, ST, INT, REAL, SET, LIST and BAG defined in this International Standard use this "primitive
type wrapper" pattern.
6.4 Mapping to this datatypes International Standard
Like ISO/IEC 11404, this International Standard anticipates the use of these datatypes within other
specifications. These specifications must specify how the datatypes and features described in this
International Standard 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.
6.5 Conformance with ISO/IEC 11404
This International Standard asserts direct conformance with ISO/IEC 11404. Although this International
Standard can be considered to provide support for all the general purpose datatypes, only the following types
are actually used in this International Standard:
⎯ boolean;
⎯ enumerated;
⎯ characterstring;
⎯ integer;
⎯ Real;
⎯ class;
⎯ set;
⎯ bag;
⎯ sequence;
⎯ octet.
10 © ISO 2011 – All rights reserved
The healthcare datatypes are class constructs built using these base primitive types. The healthcare
datatypes are partially defined using the datatype definition language defined in ISO/IEC 11404. Since this
language does not provide for generalization/specialization relationships, the datatypes cannot be fully defined
in the ISO/IEC 11404 language, since the generalization/specialization relationships are an important part of
the definition of the datatypes.
6.6 Reference to UML 2
This International Standard defines the datatypes using the UML. The datatypes are all specializations of the
UML Classifier, and the types are defined in this International Standard or are built on the following UML
Kernel types as defined in the OCL 2 specification:
⎯ enumeration;
⎯ boolean;
⎯ integer;
⎯ string;
⎯ collection;
⎯ sequence;
⎯ set;
⎯ bag.
6.7 Modelling of datatypes
6.7.1 General
This International Standard presents the relationship between individual datatypes using the facilities of the
Unified Modelling Language (UML) version 2. This modelling technique provides a means whereby:
⎯ properties that are common across groups of datatypes can be expressed once;
⎯ a mechanism is provided whereby one datatype within a specification may be substituted by another.
6.7.2 Attribute definitions
Unless otherwise specified, the default value for all attributes and associations is nil.
6.7.3 Generalization/specialization
This International Standard defines a series of class representations of healthcare datatypes. Within these
classes, a number of generalization/specialization relationships are defined. This has the normal meaning
associated with it as defined in the UML standard, and any instance of a class may be replaced by an
instance of a specialization of that class. However, some of the specifications that rely upon this International
Standard may make additional constraints concerning which specializations are permissible in a given context.
6.7.4 Enumeration definitions
This International Standard defines a number of attributes that have an enumerated set of possible values.
Each value in the enumeration represents a concept in a terminology. Within the terminology, there may be
generalization/specialization relationships. In this International Standard, the enumerations are defined in
three ways:
⎯ a list of codes as an ISO/IEC 11404 enumeration;
⎯ a list of codes as a UML enumeration definitions;
⎯ a table defining the enumeration in the narrative of the standard.
The table has four rows: Level, Code, Title and Definition.
The level of the concept in the hierarchy of the terminology.
All concepts marked with the same level and not separated by a concept with a level of less
Level
numerical magnitude are siblings, and all concepts that follow after another concept with a
higher level value are children of that concept.
The code that represents the concept.
This is used in the enumerations and to identify the concept in any representation or
Code
exchange of data in this International Standard. The Code is indented to represent the
hierarchy of the terminology.
Title A short human-readable description of the concept.
Definition A short definition of the intention of the concept.
The hierarchy in the enumeration is an important part of the specification. Although the enumerations are
defined as linear lists within ISO/IEC 11404 and the UML definitions, any information processing entity that
asserts direct or indirect conformance with this International Standard shall conform to the relationships when
evaluating meaning (implication) within the enumeration. In addition, this International Standard occasionally
refers to the relationships within the narrative when defining the outcome of some operations.
Except in the case of the AddressPartType enumeration, the hierarchies represent
generalization/specialization (also known as subsumption). In these hierarchies, the children codes represent
a more specialized meaning of the parent code. The AddressPartType enumeration is compositional in nature;
here codes represented as child codes of another code represent parts of the concept represented by the
parent code.
As an example, the following is a subset of the table that defines the NullFlavor Enumeration
NullFlavor Enumeration. OID: 2.16.840.1.113883.5.1008
Level Code Description Definition
NI The value is exceptional (missing, omitted, incomplete, improper).
No information as to the reason for being an exceptional value is
1 No information
provided. This is the most general exceptional value. It is also the
default exceptional value.
2 UNK Unknown A proper value is applicable, but not known.
ASKU Asked but Information was sought but not found (e.g. patient was asked but
unknown did not know).
NAV Temporarily Information is not available at this time but it is expected that it
unavailable would be available later.
3 NASK Not asked This information has not been sought (e.g. patient was not asked).
MSK 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.
2 Masked Warning: Using this Nullflavor does provide information that may be
a breach of confidentiality, even though no detailed data are
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 No proper value is applicable in this context (e.g. last menstrual
2 Not applicable
period for a male).
12 © ISO 2011 – All rights reserved
In this table, all the concepts listed below NI are indented and marked with a higher level, therefore they are
all specializations of NI. Codes ASKU, NAV and MASK are all specializations of the concept UNK, and codes
UNK, MSK and NA are siblings, specializations of NI, but not of anything else. Consequently, the eumeration
value ASKU implies that the enumeration value UNK is also applicable.
All the enumerations in this International Standard are maintained by HL7, unless otherwise specified.
Revised tables are published on a regular basis. The values defined in this International Standard will not
have their meaning changed, though they may be deprecated. When these revised tables are published by
HL7 or ISO, new enumeration values may be pre-adopted by trading partner agreement prior to the issuance
of a new edition of this International Standard.
The OID for the HL7 codeSystem is published for reference, and to assist when passing these enumerated
codes to terminology subsystems which are likely to use the OID to unambiguously refer to the code.
6.7.5 Strings and character encoding
This International Standard makes reference to both the ISO/IEC 11404 characterstring, and the UML Kernel
String. For the purposes of this International Standard, these types define the same functionality: an
immutable sequence of known length containing zero or more logical characters. This type is hereinafter
referred to in the narrrative as simply "String".
NOTE 1 Both ISO/IEC 11404 and the UML kernel define additional characterizing operations which might be useful for
implementors, and which can be considered to apply, but are not directly of interest to this International Standard.
NOTE 2 This International Standard also declares a wrapper type for String called ST, which adds additional
functionality related to how the notion of an immutable sequence of characters fits into the overall framework of healthcare
datatypes with their associated notions to do with uncertainty, unreliability and conformance.
The String datatype contains a sequence of logical characters, which is different from carrying a sequence of
bytes that enc
...
NORME ISO
INTERNATIONALE 21090
Première édition
2011-02-15
Informatique de santé — Types de
données harmonisées pour une
interchangeabilité d'informations
Health informatics — Harmonized data types for information
interchange
Numéro de référence
©
ISO 2011
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2011
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous
quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit
de l'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Version française parue en 2012
Publié en Suisse
ii © ISO 2011 – Tous droits réservés
Sommaire Page
Avant-propos . iv
Introduction . v
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 2
4 Abréviations . 4
5 Conformité. 5
5.1 Généralités . 5
5.2 Conformité directe . 5
5.3 Conformité indirecte . 7
6 Vue d'ensemble des types de données. 9
6.1 Qu'est ce qu'un type de donnée? . 9
6.2 Définitions des types de données . 10
6.3 Noms des types de données et réutilisation de noms de types de données communs . 10
6.4 Correspondance avec la présente Norme internationale de types de données . 11
6.5 Conformité à l'ISO/CEI 11404 . 11
6.6 Référence au langage UML 2. 12
6.7 Modélisation des types de données . 12
7 Types de données . 16
7.1 Propriétés générales . 16
7.2 Modèle de niveau supérieur . 22
7.3 Types de données de base . 24
7.4 Types de données textuelles (documentaires) et binaires . 35
7.5 Types de données codées (terminologie) . 50
7.6 Types de données d'identification et de localisation . 64
7.7 Types de données de nom et d'adresse . 76
7.8 Types de données de grandeur . 99
7.9 Types de données de collection . 126
7.10 Types de données d'ensemble continu . 143
7.11 Types de données d’incertitude . 163
7.12 Texte structuré . 165
Annexe A (normative) Représentation XML . 189
Annexe B (normative) Types de support UML . 192
Annexe C (informative) Mise en correspondance des points de vue du RM-ODP . 195
Annexe D (informative) Mise en correspondance des Types de données abstraits V3 d’HL7 . 196
Annexe E (informative) Schéma pour une représentation XML . 203
Bibliographie . 204
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée
aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du
comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec
la Commission électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 2.
La tâche principale des comités techniques est d'élaborer les Normes internationales. Les projets de Normes
internationales adoptés par les comités techniques sont soumis aux comités membres pour vote. Leur
publication comme Normes internationales requiert l'approbation de 75 % au moins des comités membres
votants.
L'attention est appelée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable de ne
pas avoir identifié de tels droits de propriété et averti de leur existence.
L'ISO 21090 a été élaborée par le comité technique ISO/TC 215, Informatique de santé.
iv © ISO 2011 – Tous droits réservés
Introduction
La présente Norme internationale a été élaborée en collaboration avec le Comité Infrastructure et
Messagerie (Infrastructure And Messaging) d'HL7, et le soutien de Connecting For Health. La présente
norme a été réalisée conjointement avec le Health Level Seven (HL7) et l'ISO, et a été produite
conformément aux termes de l'accord conclu entre HL7, le CEN et l'ISO (JIC, voir http://www.global-e-health-
standards.org/), qui assure la disponibilité complète du contenu par les canaux de publication de l'ISO, du
CEN et de HL7.
NORME INTERNATIONALE ISO 21090:2011(F)
Informatique de santé — Types de données harmonisées pour
une interchangeabilité d'informations
1 Domaine d'application
La présente Norme internationale
fournit un jeu de définitions de types de données permettant de représenter et d'échanger les concepts
de base couramment rencontrés dans les environnements de santé pour assurer l'interchangeabilité
d'informations relevant du domaine des soins de santé;
spécifie un recueil de types de données de santé pouvant être utilisées dans un certain nombre
d'environnements d'informations de santé;
déclare la sémantique de ces types de données sur la base de la terminologie, des notations et des types
de données définis dans l'ISO/CEI 11404, augmentant ainsi le jeu de types de données défini dans la
présente Norme internationale;
fournit les définitions UML de ces mêmes types de données sur la base de la terminologie, de la notation
et des types définis dans le Unified Modeling Language (UML: langage de modélisation unifié)
version 2.0;
définit une représentation basée sur le langage XML [Extensible Markup Language (langage de balisage
extensible)] des types de données.
Le domaine d'application constitue une combinaison des exigences compilées principalement de la Version 3
d'HL7 et de l'ISO/CEI 11404, et également de celles issues de la TS 14796 du CEN, de l'ISO 13606 (toutes
les parties) et des travaux antérieurs de l'ISO sur les types de données de soins de santé.
La présente Norme internationale peut contribuer de manière pratique et utile à la conception interne des
systèmes d'information de santé mais elle est principalement destinée à être utilisée pour la définition des
interfaces externes ou des messages destinés à prendre en charge leur communication interne.
2 Références normatives
Les documents de référence suivants sont indispensables à l'application du présent document. Pour les
références datées, seule l'édition citée s'applique. Pour les références non datées, la dernière édition du
document de référence s'applique (y compris les éventuels amendements).
ISO 4217, Codes pour la représentation des monnaies et types de fonds
ISO 8601, Éléments de données et formats d'échange — Échange d'information — Représentation de la date
et de l'heure
ISO/CEI 8824 (toutes les parties), Technologies de l'information — Notation de syntaxe abstraite
numéro 1 (ASN.1)
ISO/CEI 11404:2007, Technologies de l'information — Types de données à but général (GPD)
ISO/TS 22220, Informatique de santé — Identification des sujets de soins sanitaires
IETF RFC 1738, Uniform Resource Locators (URL)
IETF RFC 1950, ZLIB Compressed Data Format Specification version 3.3
IETF RFC 1951, DEFLATE Compressed Data Format Specification version 1.3
IETF RFC 1952, GZIP file format specification version 4.3
IETF RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
IETF RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
IETF RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax
IETF RFC 3066, Tags for the Identification of Languages
1)
IETF RFC 3966, The tel URI for Telephone Numbers
FIPS PUB 180-1, Secure Hash Standard
2)
FIPS PUB 180-2, Secure Hash Standard
Open Group, CDE 1.1, Remote Procedure Call specification, Appendix A
HL7 V3 Standard, Data Types — Abstract Specification (R2)
3)
Regenstrief Institute, Inc. and the UCUM Organization, The Unified Code for Units of Measure
4)
W3C Recommendation, XML Signature Syntax and Processing
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent
3.1
attribut
caractéristique d'un objet auquel est affecté un nom et un type
NOTE La valeur d'un attribut peut varier au cours de la durée de vie de l'objet.
3.2
classe
descripteur d'un ensemble d'objets ayant une structure, un comportement et une relation similaires
3.3
code
représentation conceptuelle publiée par l'auteur d'un système de codage comme une entité de ce même
système de codage
1) Révision de l’ IETF RFC 2806.
2) Révision de FIPS PUB 180-1.
3) Regenstrief Institute, Inc. et UCUM Organization, Indianapolis, Indiana, USA [consulté le 23/08/2010]. Disponible sur:
http://aurora.regenstrief.org/ucum.
4) World Wide Web Consortium (W3C) [consulté le 23/08/2010]. Disponible sur: http://www.w3.org/TR/xmldsig-core/.
2 © ISO 2011 – Tous droits réservés
3.4
système de codage
ensemble géré d'identifiants de concept, généralement des codes, et parfois ensembles plus complexes de
règles et de références
NOTE Ils sont souvent décrits comme des ensembles de concepts identifiables de manière unique associés à des
représentations, désignations, associations et significations correspondantes.
EXEMPLES ICD-9, LOINC et SNOMED
3.5
concept
représentation mentale unitaire d'un élément concret ou abstrait; une unité atomique de la pensée
NOTE 1 Il convient qu'elle soit unique dans un système de codage donné.
NOTE 2 Un concept peut avoir des synonymes en termes de représentation, il peut également être un terme primitif ou
compositionnel.
3.6
conformité
satisfaction à une exigence spécifiée; adhésion d'une entité de traitement des informations aux exigences
d'une ou de plusieurs spécifications ou normes spécifiques
3.7
type de donnée
ensemble de valeurs distinctes caractérisées par leurs propriétés et par les opérations qu'elles impliquent
3.8
énumération
type de donnée dont les instances constituent un ensemble de libellés d'énumération nommés spécifiés par
l'utilisateur
NOTE Les libellés ont un ordre relatif mais pas de définition algébrique.
3.9
généralisation
relation taxinomique entre une classe, une interface ou un concept plus général et une classe, une
interface ou un concept plus spécifique
NOTE 1 Chaque instance de l'élément spécifique est également une instance de l'élément général. Ainsi, l'élément
spécifique présente toutes les propriétés de l'élément plus général.
NOTE 2 L'élément plus spécifique est totalement cohérent avec l'élément plus général et comporte des informations
additionnelles.
NOTE 3 Une instance de l'élément plus spécifique peut être utilisée lorsque l'élément plus général est autorisé.
3.10
entité de traitement des informations
tout mécanisme qui traite les informations et comporte le concept de type de donnée. Ceci comprend d'autres
dispositifs et services de traitement des normes, spécifications et données
3.11
héritage
mécanisme permettant à des éléments plus spécifiques d'incorporer la structure et le comportement
d'éléments plus généraux
3.12
interface
spécificateur destiné aux opérations visibles de l'extérieur, sans spécification de la structure interne
3.13
invariant
règle applicable aux propriétés d'une classe qui doit toujours être vraie
3.14
opération
service qu'une instance de la classe peut être appelée à réaliser
NOTE Une opération dispose d'un nom et d'une liste d'arguments avec des noms et types affectés, et elle renvoie
une valeur du type spécifié.
3.15
spécialisation
relation taxinomique entre une classe, une interface ou un concept plus général et une classe, une
interface ou un concept plus spécifique où l'élément plus spécifique ajoute de nouvelles propriétés ou
redéfinit des propriétés existantes en contraignant leurs éventuels comportements
3.16
ensemble de chaînes de caractères
ensemble de caractères utilisé dans tout le contenu de la chaîne dans toute la présente Norme internationale
3.17
ensemble de valeurs (valueSet)
ensemble identifiable de manière unique de représentations conceptuelles valides dans lequel il est possible
de vérifier toute représentation conceptuelle pour déterminer si elle constitue ou non un membre de
l'ensemble de valeurs
NOTE Une représentation conceptuelle peut être un simple code conceptuel ou une combinaison post-coordonnée
de codes.
4 Abréviations
Pour les besoins du présent document, les abréviations suivantes s'appliquent.
CEN Comité Européen de Normalisation (European Committee for Standardization)
CNE Codé sans exception (Coded no exceptions)
CWE Codé avec exception (Coded with exceptions)
GPD Types de données à but général (General-Purpose Datatypes)
HL7 Health Level Seven, Inc.
IETF Internet Engineering Task Force
OID Identifiant d'objet
OMG Groupe de gestion d'objet (Object Management Group)
UML Langage de modélisation unifié (Unified Modelling Language)
W3C World Wide Web Consortium
XML Langage de balisage extensible (Extensible Mark-up Language)
4 © ISO 2011 – Tous droits réservés
5 Conformité
5.1 Généralités
Un produit, système, élément ou autre entité de traitement des informations peut se conformer à la présente
Norme internationale soit directement, en utilisant de manière appropriée les types de données spécifiés dans
la présente Norme internationale, ou indirectement, en établissant des correspondances entre les types de
données internes utilisés par l'entité et les types de données spécifiés dans la présente Norme internationale.
NOTE Le terme «entité de traitement des informations» est utilisé comme défini en 3.10 qui est cohérent avec
l'utilisation qui en est faite dans l'Article 4 de l'ISO/CEI 11404:2007. Cette définition comprend plus particulièrement des
applications ainsi que d'autres normes et spécifications.
5.2 Conformité directe
5.2.1 Définition de conformité directe
Une entité de traitement des informations qui se conforme directement à la présente Norme internationale
doit:
a) spécifier les types de données définis dans l'Article 7 qu'elle fournit ou qu'elle ne fournit pas;
b) définir les domaines de valeur (étendues de valeur) des types de données de soins qu'elle utilise devant
être identiques aux domaines de valeur spécifiés par la présente Norme internationale;
c) indiquer l'ampleur de la contrainte d'utilisation des domaines de valeur des types de données dans son
propre contexte;
d) lorsque l'entité fournit des opérations autres que le déplacement ou le transfert de valeurs, définir les
opérations sur les types de données de soins qui peuvent en être déduites ou qui sont cohérentes avec
les opérations de caractérisation spécifiées par la présente Norme internationale;
e) représenter ces types de données en utilisant la représentation du Langage de balisage extensible (XML)
décrite dans le présent document lorsque les types de données sont représentés en format XML;
f) en option, éditer un profil de conformité formel clarifiant ces déclarations, ou faire référence à un profil
formel édité par une autre entité de traitement des informations.
Les exigences susmentionnées interdisent d'utiliser un spécificateur-type défini dans la présente Norme
internationale pour désigner tout autre type de donnée (voir cependant la note concernant le domaine
d'application des noms de type de données en 6.3). Elles n'imposent pas d'autre limite à la définition des
types de données additionnels d'une entité conforme. Par exemple, outre ces types de données de soins, une
entité de traitement des informations directement conforme peut continuer à utiliser l'ISO/CEI 11404 Types de
données à but général.
L'exigence d) n'impose pas de prendre en charge toutes les opérations de caractérisation et autorise de
fournir des opérations additionnelles. Il s'agit d'autoriser l'ajout de l'interprétation sémantique aux types de
données tant qu'il n'y a pas de conflit avec les interprétations données dans la présente Norme internationale.
Il n'y a conflit que lorsqu'une opération de caractérisation donnée ne peut être mise en œuvre ou n'a pas de
sens compte tenu des opérations fournies par l'entité sur le type de donnée.
Des exemples d'entités susceptibles d'être directement conformes sont les définitions de langage ou les
spécifications de soins dont les types de données et la notation associée correspondent à ceux définis dans le
présent document. De plus, il convient de ne pas écarter la possibilité d'une prise en charge exhaustive par
un outil logiciel ou un progiciel d'application de la syntaxe des types de données et des dispositifs de définition.
Les entités de traitement des informations revendiquant une conformité directe à la présente Norme
internationale n'ont pas toujours besoin d'utiliser les types de données définis dans la présente Norme
internationale pour représenter les concepts. Ceci est justifié par le fait que la définition d'un type de donnée
d'adresse ne signifie pas que les types de données d'adresse doivent toujours être utilisés pour représenter
les adresses. Cependant, le type défini dans le cadre de la présente Norme internationale doit être utilisé
lorsque le contexte implique d'utiliser ces types de données pour l'interopérabilité.
Les entités de traitement des informations revendiquant une conformité directe à la présente Norme
internationale peuvent ultérieurement forcer (contraindre) le domaine de valeur de tous types de données
dans leur contexte d'utilisation. La déclaration de conformité doit clairement spécifier le mode d'application
des contraintes au sein de l'entité de traitement des informations, et la manière dont sont traitées les valeurs
non conformes aux contraintes imposées.
La cohérence des opérations de caractérisation spécifiées par des entités conformes peut être évaluée au
moyen de ces critères. Lorsque les opérations ont le même nom que celui de l'opération définie dans le cadre
de la présente Norme internationale, elles sont cohérentes si l'opération peut être appelée avec les mêmes
paramètres pour renvoyer le même résultat. D'autres paramètres peuvent être définis. Cependant, ils doivent
porter des valeurs par défaut ou être spécifiés à l'aide de définitions additionnelles des opérations avec le
même nom et avec d'autres listes de paramètres.
Les entités de traitement des informations revendiquant une conformité directe ne sont pas tenues d'appeler
un quelconque ou tous les types définis dans la présente Norme internationale. D'autres termes tels que
«structures de données» peuvent être utilisés.
5.2.2 Déclarations de conformité
Lorsqu'une entité de traitement des informations revendique une conformité directe à la présente Norme
internationale, Il convient qu'elle établisse une déclaration de conformité.
Il est prévu que d'autres organismes de normalisation établissent des déclarations de conformité à la présente
Norme internationale aussi bien de manière générale que dans le but d'adopter ces types de données pour
une norme particulière. En outre, il est prévu que certains pays publient des profils de ces types de données
soit sur une base de conseil ou sur une base normative. Enfin, les fournisseurs et les acheteurs d'applications
de santé peuvent également trouver utile de créer, partager et publier ces déclarations de conformité.
La présente Norme internationale n'établit aucune règle relative à la forme de la déclaration ni à la manière
dont elle est publiée, toutefois, il convient qu'elle soit présentée clairement et de manière formelle, et mise à la
disposition de toutes les parties intéressées associées au domaine d'application de l'entité de traitement des
informations.
Outre la spécification selon laquelle les déclarations de conformité doivent comporter des déclarations
formelles relatives aux points a) à d) de 5.2.1, la présente Norme internationale établit des règles
supplémentaires relatives à ce qu'elles doivent dire, ou qu'il convient qu'elles disent, ou qu'elles peuvent
choisir de dire.
5.2.2.1 Les déclarations de conformité directe doivent
a) définir l'ensemble des caractères et le codage qui s'appliquent; par défaut, c'est l'Unicode (voir 6.7.5);
b) si un autre mécanisme est fourni pour donner l'historique et des données de vérification, définir comment
il établit la correspondance avec l'historique et les informations de vérification sur les types de données
(voir 7.1.3);
c) montrer clairement comment l'attribut et la cardinalité de la collection sont spécifiés (voir 7.1.5);
d) définir comment les attributs nullFlavor, updateMode et flavorId sur ANY sont traités (voir 7.3.3);
e) si des grandeurs sont utilisées, montrer clairement et avec précision comment et quand l'expression des
attributs QTY, originalText, et l'incertitude et uncertaintyType sont utilisés;
f) montrer clairement les méthodes qui peuvent être utilisées pour fournir des définitions subsidiaires pour
l'unicité de l'ensemble discret (voir 7.9.3);
6 © ISO 2011 – Tous droits réservés
g) si les types de documents structurés sont utilisés, documenter le domaine d'application du contexte du
document et définir clairement comment les références dans le contexte de ce document sont résolues
(voir 7.12);
h) spécifier dans quelle mesure le format XML est adopté, puis définir l'espace de nom qui est utilisé
(voir A.1).
5.2.2.2 Il convient que les déclarations de conformité directe
a) définissent des règles par défaut pour le langage (voir 7.4.2.3.7);
b) déclarent les langages qui sont pris en charge dans la propriété d'expression de QTY (QTY.expression)
(voir 7.8.2.3.1);
c) décrivent les codes susceptibles d'être utilisés dans le code QSC (QSC.code) (voir 7.10.8.3);
d) si les types de documents structurés sont utilisés, définissent comment la recherche de version
fonctionne dans les contextes où elle est utilisée (voir 7.12.12.2.1).
5.2.2.3 Les déclarations de conformité directe peuvent également:
a) définir des flavors de type de donnée supplémentaires ou des autorités supplémentaires pour la définition
des flavors (voir 6.7.6);
b) prendre des dispositions supplémentaires pour l'utilisation des données dérivées et le DER nullFlavor
(voir 7.1.4);
c) définir comment les propriétés controIInformationRoot et controlInformationExtension sur HXIT sont
utilisées (voir 7.3.2.3.4);
d) clarifier comment les adresses de télécommunication et postales sont choisies à des fins particulières
(voir 7.6.2.3.2);
e) définir les systèmes de codage auxquels sont liés les différents types de partie de nom et d'adresse (voir
7.7.3.6 et 7.7.5.6).
5.3 Conformité indirecte
5.3.1 Définition de conformité indirecte
Une entité de traitement des informations qui se conforme indirectement à la présente Norme internationale
doit
a) établir des correspondances entre ses types de données internes et les types de données de soins
conformes aux spécifications de l'Article 7;
b) spécifier les types de données de l'Article 7 auxquels sont destinées la correspondance d'entrée et la
correspondance de sortie, ainsi que les types de données ne faisant pas l'objet d'une correspondance;
c) spécifier si la représentation XML décrite dans la présente Norme internationale est utilisée lorsque les
types de données sont représentés en format XML, ou fournir en option un autre espace de nom pour
la représentation XML;
d) en option, publier un profil de conformité formel clarifiant ces déclarations, ou faire référence à un profil
formel publié par une autre entité de traitement des informations.
Des exemples d'entités susceptibles d'être indirectement conformes sont les spécifications de soins, les
applications, les outils techniques logiciels et autres spécifications d'interface ainsi que bon nombre d'autres
entités disposant d'un concept de type de donnée et d'une notation existante correspondante.
Les normes relatives aux spécifications de soins existantes et qui sont en cours de proposition comme
normes internationales sont prévues pour s'appliquer à une conformité indirecte plutôt qu'à une conformité
directe.
Les entités de traitement des informations revendiquant une conformité indirecte à la présente Norme
internationale n'ont pas toujours besoin d'utiliser les types de données définis dans la présente Norme
internationale pour représenter les concepts. Ceci est justifié par le fait que la définition d'un type de donnée
d'adresse ne signifie pas que les types de données d'adresse doivent toujours être utilisés pour représenter
les adresses. Cependant, le type défini dans le cadre de la présente Norme internationale doit être utilisé
lorsque le contexte implique d'utiliser ces types de données pour l'interopérabilité.
Les entités de traitement des informations revendiquant une conformité indirecte à la présente Norme
internationale peuvent ultérieurement contraindre le domaine de valeur de tous types de données dans leur
contexte d'utilisation. La déclaration de conformité doit clairement spécifier le mode d'application des
contraintes au sein de l'entité de traitement des informations, et la manière dont sont traitées les valeurs non
conformes aux contraintes imposées.
Les entités de traitement des informations revendiquant une conformité indirecte ne sont pas tenues d'appeler
un quelconque ou tous les types définis dans la présente Norme internationale. D'autres termes tels que
«Structures de données» peuvent être utilisés.
5.3.2 Déclarations de conformité
Lorsqu'une entité de traitement des informations revendique une conformité indirecte à la présente Norme
internationale, il convient qu'elle établisse une déclaration de conformité.
La présente Norme internationale n'établit aucune règle relative à la forme de la déclaration ni à la manière
dont elle est publiée. Toutefois, il convient qu'elle soit mise à la disposition de toutes les parties intéressées
associées au domaine d'application de l'entité de traitement des informations.
Outre la spécification selon laquelle les déclarations de conformité doivent comporter des déclarations
formelles relatives aux points a) à d) de 5.3.1, la présente Norme internationale établit des règles
supplémentaires relatives à ce qu'elles doivent dire, qu'il convient qu'elles disent, ou qu'elles peuvent choisir
de dire.
5.3.2.1 Les déclarations de conformité indirecte doivent:
a) définir l'ensemble des caractères et le codage qui s'appliquent. Par défaut, c'est l'Unicode (voir 6.7.5);
b) montrer clairement à quoi s'appliquent les définitions d'égalité et de quelle manière (voir 7.1.2);
c) montrer clairement comment l'attribut et la cardinalité de la collection sont spécifiés, le cas échéant
(voir 7.1.5);
d) si les types de documents structurés sont utilisés, documenter le domaine d'application du contexte du
document et définir clairement comment les références dans le contexte de ce document sont résolues
(voir 7.12).
5.3.2.2 Il convient que les déclarations de conformité indirecte:
a) définissent des règles par défaut pour le langage (voir 7.4.2.3.7);
b) s'il en existe, déclarent la correspondance entre la signature numérique W3C et d'autres mises en œuvre
(voir 7.4.5.1).
8 © ISO 2011 – Tous droits réservés
5.3.2.3 Les déclarations de conformité indirecte peuvent également:
a) définir des flavors de type de donnée supplémentaires ou des autorités supplémentaires pour la définition
des flavors (voir 6.7.6);
b) prendre des dispositions supplémentaires pour l'utilisation des données dérivées et le DER nullFlavor
(voir 7.1.4);
c) définir comment les propriétés controIInformationRoot et controIInformationExtension sur HXIT sont
utilisées (voir 7.3.2.3.4);
d) clarifier comment les adresses de télécommunication et postales sont choisies à des fins particulières
(voir 7.6.2.3.2);
e) définir les systèmes de codage auxquels sont liés les différents types de partie de nom et d'adresse
(voir 7.7.3.6 et 7.7.5.6);
f) déclarer les langages qui sont pris en charge dans la propriété d'expression de QTY (QTY.expression)
(voir 7.8.2.3.1);
g) décrire les codes susceptibles d'être utilisés dans le code QSC (QSC.code) (voir 7.10.8.3);
h) si les types de documents structurés sont utilisés, définir comment la recherche de version fonctionne
dans les contextes où elle est utilisée (voir 7.12.12.2.1).
6 Vue d'ensemble des types de données
6.1 Qu'est ce qu'un type de donnée?
L'ISO/CEI 11404 définit un «type de donnée» comme un ensemble de valeurs distinctes caractérisées par
leurs propriétés et par les opérations qu'elles impliquent (ISO/CEI 11404:2007, 3.12).
Un type de donnée est constitué de trois principales propriétés:
un domaine de valeur;
un ensemble de propriétés;
un ensemble d'opérations de caractérisation.
En règle générale, les définitions du domaine d'application des types de données s'articulent autour de l'une
ou de toutes les notions suivantes:
Immutabilité (les propriétés du type de donnée ne peuvent pas être modifiées, à la place une nouvelle
instance est créée: les types de données n'ont pas de cycle de vie).
Relation entre égalité et identité (si deux types de données sont égaux, ils constituent la même instance).
Cohérence d'un concept unique (il convient que chaque type de donnée représente un domaine de
concept unique).
Dans la mesure où l'application de ces concepts au domaine des informations de soins ainsi que leurs
implications pour le domaine d'application des types de données relèvent par nature de l'ordre du jugement,
les critères de sélection applicables aux types de données définis dans la présente Norme internationale sont
fondés sur les conclusions tirées des discussions qui se sont tenues entre les différentes organisations de
normalisation des parties prenantes qui définissent les normes relatives aux informations de soins. Étant
donné que les normes et les spécifications relatives aux informations de soins sont destinées à fournir des
correspondances avec la présente Norme internationale, le processus a été délibérément considéré d'un
point de vue général. Les autres normes peuvent choisir de représenter les types de données avec d'autres
structures plus complexes mais il convient qu'elles expliquent comment inter-convertir ces structures avec les
types de données définis dans le présent document.
6.2 Définitions des types de données
La présente Norme internationale définit un ensemble de types de données nommés (désignés). Chaque type
de donnée défini dans la présente Norme internationale est affecté d'un nom court et d'un nom long. Le nom
court représente le nom formel du type de donnée. Chaque type de donnée est défini de deux manières
différentes:
en termes de langage et de types de spécification des types de données définis dans l'ISO/CEI 11404;
en langage UML en utilisant des types primitifs issus du paquet noyau UML.
La définition de l'ISO/CEI 11404 est destinée à assurer la continuité entre la présente Norme internationale et
les types de données à but général de l'ISO/CEI 11404, tandis que la définition UML favorise la mise en
œuvre logicielle de ces types de données. Les définitions de l'ISO/CEI 11404 sont par nature d'ordre
sémantique et abstrait, alors que celles du langage UML sont de structure concrète. La présente Norme
internationale a pour objet de fournir des définitions structurales concrètes, donnant de ce fait la priorité aux
définitions UML par rapport à celles de l'ISO/CEI 11404, qui sont fournies pour assurer la continuité avec
l'ISO/CEI 11404.
Les types de données définis dans la présente Norme internationale représentent une mise en œuvre des
types de données abstraits V3 d'HL7 (R2). En d'autres termes, ceci signifie qu'il est possible de mettre en
œuvre l'échange des informations sur la base des définitions des types de données abstraits V3 d'HL7 en
utilisant les types de données définis dans la présente Norme internationale. L'Annexe B illustre pour ces
types de données le mode de mise en œuvre des types de données abstraits V3 d'HL7 (R2).
Les types de données définis dans la présente Norme internationale ne se limitent pas aux propriétés décrites
dans les types de données abstraits V3 d'HL7, ni ne constituent la spécification des types de données
abstraits V3 d'HL7 requise pour l'utilisation de ces types de données. Les définitions sémantiques données
dans les types de données abstraits V3 d'HL7 peuvent être consultées pour obtenir de plus amples
informations utiles pour aider les responsables de la mise en œuvre à comprendre l'utilisation de ces types de
données.
6.3 Noms des types de données et réutilisation de noms de types de données communs
Certains noms de ces types de données présentent une apparente similarité avec des types de données
similaires définis dans d'autres spécifications. Par exemple, la présente Norme internationale définit un type
REAL (REEL) qui existe également dans la spécification de l'ISO/CEI 11404 ainsi que dans le noyau UML
(voir également la note 1 en B.2.7 relative à l'utilisation des types de valeur à virgule flottante).
La présente Norme internationale n'a pas pour objet de redéfinir ou de remplacer la définition de «real» (réel)
dans l'ISO/CEI 11404 ou l'UML. Elle définit en revanche un nouveau type qui prend en compte le type «primitif»
sous-jacent fondé sur la fonctionnalité du type sous-jacent et s'intègre parfaitement au cadre architectural
global.
Il existe de nombreuses spécifications et de nombreux langages et technologies de mise en œuvre qui
spécifient des types similaires soit aux types réels sous-jacents ou au REAL défini dans la présente Norme
internationale, en utilisant une grande variété de noms proches du sens commun de Real (Réel), Float
(Flottant), Décimal ou Double.
La présente Norme internationale ne recherche pas des noms nouveaux non reconnus précédemment pour
les types qu'elle déclare et qui représentent ces concepts de base. En revanche, elle leur attribue des noms
communs. Une fois encore, la présente Norme internationale n'a pas pour objet de redéfinir ou de remplacer
les définitions en se servant de ces noms communs.
10 © ISO 2011 – Tous droits réservés
S'agissant de ces conflits de noms entre les types de données définis dans la présente Norme internationale
et ceux de toute autre spécification, il convient que les responsables de la mise en œuvre utilisent une forme
d'espacement (désignation) de nom qui évite toute confusion avec les noms des types de données, et ce par
exemple en utilisant des noms préfixés avec une constante de chaîne dans des environnements de mise en
œuvre qui ne prennent pas en charge l'espacement de nom des types.
Les types BL, ST, INT, REAL, SET, LIST et BAG définis dans la présente Norme internationale utilisent ce
modèle de «mise en forme de type primitif».
6.4 Correspondance avec la présente Norme internationale de types de données
À l'instar de l'ISO/CEI 11404, la présente Norme internationale prévoit que ces types de données seront
utilisés dans d'autres spécifications. Ces spécifications doivent expliciter le mode de mise en œuvre des types
de données et des propriétés décrits dans la spécification. Les types de données peuvent être adoptés et
utilisés directement, ou ils peuvent être mis en correspondance avec d'autres types de données ou structures
en différents lieux, ou ils peuvent ne pas être pris en charge du tout.
Il convient que chaque spécification qui utilise ces types de données publie un document ou rédige une
section décrivant la mise en correspondance afin d'aider les responsables de la mise en œuvre à
inter-convertir les données des différentes spécifications.
6.5 Conformité à l'ISO/CEI 11404
La présente Norme internationale invoque une conformité directe à l'ISO/CEI 11404. Bien qu'elle puisse être
considérée comme prenant en charge tous les types de données à but général, elle n'utilise réellement que
les types suivants:
booléen (boolean);
énuméré (enumerated);
chaîne de caractères (characterstring);
entier (integer);
réel (real);
classe (class);
ensemble (set);
paquet (bag);
séquence (sequence);
octet.
Les types de données de soins sont des constructions (modèles) de classe établies au moyen de types
primitifs de base. Les types de données de soins sont en partie définis par le langage de définition des types
de données spécifié dans l'ISO/CEI 11404. Dans la mesure où ce langage ne fournit pas une relation
généralisation/spécialisation, il n'est pas possible de totalement définir les types de données dans le langage
de l'ISO/CEI 11404 du fait que la relation généralisation/spécialisation constitue une partie importante de la
définition des types de données.
6.6 Référence au langage UML 2
La présente Norme internationale définit les types de données qui utilisent le langage UML. Les types de
données sont tous des spécialisations du classificateur UML. La présente Norme internationale définit ou
construit les types selon les types du noyau UML suivants définis dans la spécification OCL 2:
énumération (Enumeration);
booléen (Boolean);
entier (Integer);
chaîne (String);
collection;
séquence (Sequence);
ensemble (Set);
paquet (Bag).
6.7 Modélisation des types de données
6.7.1 Généralités
La présente Norme internationale présente la relation qui existe entre les types de données individuels en
utilisant les dispositifs du Langage de modélisation unifié (UML) version 2. Cette technique de modélisation
fournit un moyen:
de pouvoir exprimer en une fois les propriétés communes aux groupes des types de données;
de fournir un mécanisme permettant de remplacer un type de données d'une spécification par un autre.
6.7.2 Définitions d'attribut
Sauf indication contraire, la valeur par défaut de tous les attributs et associations est nulle.
6.7.3 Généralisation/spécialisation
La présente Norme internationale définit une série de représentations de classe des types de données de
soins. Un certain nombre de relations généralisation/spécialisation sont définies au sein de ces classes. Leur
signification correspondante est normale comme défini dans la norme UML, et toute instance d'une classe
peut être remplacée par une instance d'une spécialisation de cette classe. Cependant, certaines
spécifications fondées sur la présente Norme internationale peuvent appliquer des contraintes additionnelles
relatives aux spécialisations dans un contexte donné.
6.7.4 Définitions relatives à l'énumération
La présente Norme internationale définit un certain nombre d'attributs ayant un ensemble énuméré
(énumératif) de valeurs possibles. Chaque valeur de l'énumération représente, pour une terminologie, un
concept. Des relations généralisation/spécialisation peuvent exister au sein de la terminologie. La présente
Norme internationale définit les énumérations de trois manières:
une liste de codes semblable à une énumération de l'ISO/CEI 11404;
une liste de codes semblable aux définitions d'énumération UML;
un tableau définissant l'énumération spécifiée dans le texte de la présente norme.
12 © ISO 2011 – Tous droits réservés
Le tableau se compose de quatre colonnes: Niveau, Code, Titre et Définition.
Niveau du concept dans la hiérarchie de la terminologie.
Tous les concepts appartenant au même niveau et n'étant pas séparés pa
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...