ISO/TS 13972:2015

TECHNICAL ISO/TS
SPECIFICATION 13972
First edition
2015-10-01
Health informatics — Detailed clinical
models, characteristics and processes
Informatique de santé — Modèles cliniques détaillés,
caractéristiques et processus
Reference number
©
ISO 2015
© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Terms and definition . 1
3 Abbreviated terms . 8
4 Definition, purpose, contexts and position of Detailed Clinical Models .8
4.1 Definition of Detailed Clinical Models . 8
4.2 Purpose for Detailed Clinical Models . .10
4.3 Reference (Information) Models and Detailed Clinical Models .11
4.4 Types of Detailed Clinical Models .11
4.5 Context of Detailed Clinical Models .12
4.6 Architectural approach to healthcare interoperability and Detailed Clinical Models .13
4.7 Architectural considerations for Detailed Clinical Models based on the GCM .14
5 Requirements and Methodology for Detailed Clinical Models .16
5.1 DCM application, structure and management .16
5.2 Clinical Requirements .19
5.2.1 General.19
5.2.2 Clinician/user requirements, involvement, and verification for Detailed
Clinical Models .20
5.3 Clinical acceptance, adoption, and use .20
5.4 DCM QMS Processes for the systematic approach for quality of DCMs .21
5.4.1 General.21
5.4.2 General requirements .21
5.4.3 General DCM documentation requirements .21
5.5 DCM Governance .22
5.5.1 General.22
5.5.2 Governance and Management responsibility for Detailed Clinical Models .22
5.5.3 Organizing Detailed Clinical Model governance .22
5.5.4 Submission criteria for Detailed Clinical Models .22
5.5.5 Search/access criteria for Detailed Clinical Models .23
5.5.6 Contributors and key competence .23
5.5.7 Clear Accountability .23
5.5.8 Quality .23
5.6 Stakeholder Participation.23
5.7 DCM Development Processes .24
5.7.1 General.24
5.7.2 Hazards in data exchange between clinical information systems .24
5.7.3 Include data exchange specifically in Detailed Clinical Model hazard analysis .25
5.7.4 Keep the Detailed Clinical Model as simple as possible .25
5.8 Detailed Clinical Model content and artefacts .25
5.8.1 General.25
5.8.2 Clinical concept specification of a particular Detailed Clinical Model .26
5.8.3 Context of clinical concept in a Detailed Clinical Model .26
5.8.4 Purpose of the Detailed Clinical Model at instance level .26
5.8.5 Evidence Base for the Detailed Clinical Model topic .27
5.8.6 Description of data elements in the Detailed Clinical Model .28
5.8.7 Instructions for documentation of DCM content .33
5.8.8 Care process / dependence .34
5.8.9 Issues .34
5.8.10 Example of the DCM .35
5.8.11 References .35
5.8.12 Copyrights of source materials, Disclaimer, Terms of use and Copyrights
for Detailed Clinical Model .36
5.8.13 Metadata .37
5.8.14 Version management .41
5.8.15 Guidelines and principles for Detailed Clinical Modelling .42
5.8.16 Inclusion of other Detailed Clinical Models .48
5.8.17 Use of terminology .48
5.9 Measurement, analysis and improvement .48
5.9.1 General.48
5.9.2 Detailed Clinical Model maintenance . .49
5.9.3 Monitoring and measurement .49
Annex A (informative) Data type profile used for the logical model parts for Detailed
Clinical Models .50
Annex B (informative) Example Detailed Clinical Model in UML and Table format .51
Bibliography .54
iv © ISO 2015 – All rights reserved

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.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives ).
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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 215, Health informatics.
Introduction
In current healthcare information technology, there is an identified need for clinical information
recorded by one professional or in one information system and transferred electronically to another
professional or information system to retain enough of its intended and precise meaning to be safe
and useful [HL7, ISO 13606, EC Recommendation COM (2008) 3282 final]. In particular, clinical safety
requires that the receiving system and user of all data elements contributing to clinical knowledge
makes the exact same interpretation of their meaning as applied in the source system. Semantic
interoperability enables actors in a clinical process to cooperate by ensuring they share a common
understanding of information and activities pertinent to the clinical process. When actors in a clinical
process use a combined system containing two (or more) information systems, semantic interoperability
occurs as an emergent (whole system) characteristic of those data exchanges that constitute meaningful
communications between actors using different information systems. As is typical for engineering
properties of systems, semantic interoperability is not absolute. It enables sufficiently unambiguous
understanding of stored, used, and communicated data so that patients, health care professionals, and
others including automated systems can interpret and act upon data in health care information systems
(health IT systems) consistently and accurately.
Semantic interoperability is defined as “ensuring that the precise meaning of exchanged information
is understandable by any other system or application not initially developed for this purpose” [EC
Recommendation, COM (2008) 3282 final]. Semantic interoperability addresses issues of how to best
facilitate seamless computer mediated processes of coding, transmission, and use of meaning across
health services, between providers, patients, citizens and authorities, research, and training (modified
from Semantic Health, 2009). A key requirement to achieve this is the standardization of clinical concept
representation within health data, including content, structure, context, and transmission processes.
This represents the core development need for future electronic health records (EHR) and other health
IT systems and for communication between these systems. In addition, standardization of clinical
concept representation is a desirable and cost effective way to aggregate data from multiple health
IT systems and operate as a cohesive whole, for example for clinical audit and research. Exchanging
information using standardized clinical concept representations thereby takes its place as one of the
specific kinds of semantic interoperability, with well-defined benefits and limitations.
The ability to exchange information between clinical information systems without loss of clinical
meaning is also essential to enable safe and effective implementation of automated decision support.
Whether a decision support system requests specific information from an EHR system or an EHR
system requests specific computations from a decision support system (and both of these patterns of
interaction are used), it is essential that the clinical information exchanged is understood accurately
and consistently by both systems.
This Technical Specification provides guidance on representation format and processes to improve
the quality of modular data specifications for clinical information, here called Detailed Clinical Models
(DCM). The modelling approach described in ISO/TR 17119 as the ISO Health Informatics Profiling
Framework (HIPF) is followed. ISO/TR 17119 defines three levels of specificity for artefacts which are
CONCEPTUAL, LOGICAL, and PHYSICAL and describes six perspectives for an artefact, the WHO, WHAT,
HOW, WHERE, WHY, and WHEN perspectives.
With respect to the processes for DCM, a Quality Management system (QMS) based on a framework
such as ISO 9001 can be used. Defined processes for development, application, and governance ensure
the quality of DCM artefacts. In terms of the HIPF, this provides WHO, HOW, and WHEN perspectives at
the LOGICAL level of specificity.
The scope of this Technical Specification is the conceptual and logical aspects of a DCM and quality
management processes for DCM artefacts. Although the DCM is modelling a clinical concept, we are
defining these concepts at the logical level. Therefore, these are logical constructs. There is ongoing
debate in the Health Informatics community about the exact nature and role of modular data
specifications for clinical information. This Technical Specification reflects a pragmatic consensus
based on experience, in particular regarding the level of detail in the breakdown and representation
vi © ISO 2015 – All rights reserved

of a DCM and how instances of a DCM are likely to be used within an actual Healthcare Information
Architecture.
The following organizers and participants contributed to the Technical Specification:
— Health Level 7 International (HL7) (USA)
— National ICT Institute in Health Care (NICTIZ, Netherlands)
— National Health Service (NHS) (England)
— Canada Infoway (Canada)
— National E-Health Transition Authority (NEHTA),(Australia)
— OpenEHR (International)
— EN 13606 association (Europe)
— Intermountain Healthcare (USA)
— Center for Interoperable EHR (CiEHR) (South Korea)
— Parelsnoer Initiative (Netherlands)
— Netherlands Normalization Institute, Detailed Clinical Model Quality Center (Netherlands)
— Portavita (Netherlands)
— Clinical Information Modelling Initiative (CIMI) (International)
— Results 4 Care BV (Netherlands)
— And the many other individuals and organizations that contributed.
Clinical concepts as core of EHR and message content
Detailed Clinical Models are highly specialized logical models of clinical concepts. Their development
and management require common and more generic definitions/descriptions of clinical concepts.
ISO 13940 is suitable as a common base for development of DCMs.
To support communication between actors in clinical processes as described above and also to enable
design review by both clinical domain experts and technical modellers, an artefact describing a
DCM must contain considerable detail concerning the values and types of attributes and how they fit
together to convey the clinical reality being communicated. In this way, Detailed Clinical Models define
representations of clinical concepts independent of implementation, enabling safe translation from one
technological implementation of a Detailed Clinical Model into another of the same DCM.
Data specifications similar to the DCM described in this Technical Specification have been found to
be useful in a wide range of health care information and communication technologies, including but
not limited to EHR systems, telehealth applications, messaging integration, medical devices, computer
algorithms, and deductive reasoning for decision support (e.g. Huff et al., 2004, Hoy et al., 2007, 2009,
Kalra et al., 2008, Rector, Qamar, Marley, 2008, Goossen et al., 2010, Shafarman and Gilliam, 2010,
among others).
Standardized Detailed Clinical Models underpin the coherence of Electronic Health Records (EHR,
ISO 18308), where data needs to be accepted from multiple sources and stored in a consistent
deterministic fashion. In addition, for a functional EHR system (EHR System Functional Model,
ISO/HL7 10781), queries must be constructed based on clinical knowledge and tied to clinical context
and workflow; services need to be automated based on known values of patient parameters linked
to agreed protocols; data display and data entry needs to reference clinical guidelines while safety
and quality issues for clinicians moving from system to system can be minimized through consistent
information representation. In this way, standardized Detailed Clinical Models become the lingua
franca of reuse and reusability in and across clinical systems. They promote safety and quality, enable
decision support; are a pre-requisite for effective and reliable analysis and aggregation for research and
they underpin safe and effective exchange of clinical information. A final important aspect of Detailed
Clinical Models is that in any given implementation context, they will need to be combined into larger
interlinked structures, sometimes with changing levels of detail as might occur for specifying a hospital
discharge summary. A consequence of such requirements is that mechanisms such as specialization
are needed to enable DCM to be safely represented at different levels of detail. A hospital discharge
summary consists of many elements, many of which might be seen as DCM, however the data specification of
a discharge summary is a separate artefact making use of a number of DCMs and is not a DCM in itself. How
these combinations of DCM can be achieved is not part of this Technical Specification. For example, the
HL7 version 2 and version 3 standards both provide means whereby composite message models can be
constructed from previously defined parts. Often such combinations are defined in a Domain Analysis
Model. In the ISO 13606 environment it is usually called templating.
There is widespread acceptance that models need to be developed and standardized by clinicians on
the one hand and also be technology ‘neutral’ yet usable in real systems on the other. To be patient-
safe, a DCM must be defined in terms of an underlying information model (RM, RIM). This Technical
Specification is about meeting this challenge by detailing clinical model quality requirements, principles,
development methodology, and governance, addressing the conceptual content for the logical levels of
modelling, but not intervening in the physical implementation. This means we are modelling clinical
concepts at the logical level, but we are not doing conceptual modelling and are not doing physical
implementations.
The electronic health record (EHR, ISO 18308) is the core requirement intended to achieve safe, efficient
semantic interoperability. EHRs are based on a logical structure whereby data can be entered in a
structured format that represents systematic meaning and where the clinical concepts captured are
represented in a manner that ensures consistent semantics of what is managed and stored. This ideally
requires semantic interoperability between all EHRs, whether organizational, personal, or national and
the clinical systems which contribute to, and make use of, that data. The achievement of that vision
will be a long journey however Detailed Clinical Models will accelerate progress by determining clearly
what we need to exchange for specific purposes such as clinical record keeping, continuity of care or for
aggregation purposes.
The need for standardized clinical models has been recognized and endorsed by firstly CEN, and
then ISO, who have adopted and incorporated ‘archetypes’ and an EHR information Reference Model
into ISO 13606 where parts 1 to 3 are adapted from early specifications developed by the openEHR
Foundation. Finer grained standards for expressing clinical information have been developed as
standardized data types (ISO 21090), terminologies (SNOMED CT), and nomenclatures (ISO 11073).
This Technical Specification acknowledges that the reference model is underpinned by standardized
data types and that Detailed Clinical Models, archetypes and other clinical models need to reference
standardized term sets and units of measure. This clinical model approach has also been adopted by
HL7 International in developing HL7 v3 templates, reusable components in HL7 v3 message models
specifying data types and standardized terminology. Further evidence of shared will and harmonization
in this area is that the CEN/ISO and HL7 data types have been harmonized into ISO 21090. DCMs
support a migration path towards standards based information systems.
viii © ISO 2015 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 13972:2015(E)
Health informatics — Detailed clinical models,
characteristics and processes
1 Scope
This Technical Specification:
— Describes requirements and recommended methods against which clinicians can gather, analyse
and, specify the clinical context, content, and structure of Detailed Clinical Models.
— Defines Detailed Clinical Models (DCMs) in terms of an underlying logical model. They are logical
models of clinical concepts and can be used to define and to structure clinical information.
— Describes requirements and principles for DCMs, meta-data, versioning, content and context
specification, data element specification and data element relationships, and provide guidance
and examples.
— Specifies DCM governance principles to ensure conceptual integrity of all DCM attributes and logical
model accuracy.
— Describes DCM development and the methodology principles for use that will support the production
of quality DCMs to minimize risk and ensure patient safety.
This Technical Specification is not applicable to:
— Details of the content of instances of Detailed Clinical Models. e.g. This Technical Specification will
not specify the concrete data elements for the Glasgow Coma Scale, body height, and such (apart from
some examples to explain the clauses). It will however give guidance on how to properly specify the
clinical knowledge of Glasgow Coma Scale or body height, how to correctly identify, name and model
the data elements for these clinical concepts, and how to give unique codes to each data element
and, where possible, value set. In other words, it will explain the how to create instances, but not
offer the instances themselves.
— Specifications of dynamic modelling, for example workflow.
— Specifications for modelling entire domains or aggregates of many Detailed Clinical Models such as
complete assessment documents or discharge summaries. It will not specify DCM compositions.
2 Terms and definition
For the purposes of this document, the following terms and definitions apply.
2.1
archetype
model of a clinical or other domain-specific concept which defines the structure and business rules
of the concept
[SOURCE: ISO/TR 20514:2005]
2.2
archetype model
information model of the metadata to represent the domain-specific characteristics of Electronic
Health Record entries by specifying values or value constraints for classes and attributes in the EHR
reference model
[SOURCE: ISO 13606-1:2008]
2.3
attribute
characteristic of an object or entity
Note 1 to entry: In the context of this Technical Specification: a specific characteristic of a data element.
[SOURCE: ISO/IEC 11179-1:2004]
2.4
care provision
type and scope of responsibility taken-on by the performer of the act for a specific subject of care
Note 1 to entry: The “Act of Care Provision” is the recording of a process that defines the responsibility for
supplying support to the target of care. It is a statement of supervision, management, and custody.
[SOURCE: HL7 International]
2.5
clinical
pertaining to healthcare, in particular to characterize activities in which a patient and care professional
interact directly or indirectly
2.6
clinical concept
unit of knowledge, expressed by means of characteristics pertinent to its use in health care
2.7
clinical context
the variable situations in healthcare that influence the interpretation of health(care) information
2.8
clinical information
data that is meaningful in a clinical context
[SOURCE: ISO 13940:—]
2.9
clinical knowledge
part of medical knowledge pertaining to promoting good health and the management and prevention
of ill health
Note 1 to entry: Used to diagnose, treat, and alleviate disease/dysfunction.
Note 2 to entry: In ISO 13940 (Contys) proposed to be understood clinical information.
[SOURCE: ISO 13119:2012]
2.10
clinical statement
expression of a discrete item of clinical, clinically related, or public health information recorded because
of its relevance to the care of a patient or other entities
[SOURCE: HL7 International]
2.11
clinical template
clinical information model that structures information round discrete clinical concepts in a way that
supports reuse of components across different clinical communication and record keeping activities
and promotes common approaches to clinical information system development and interoperability
[SOURCE: Hoy et al., 2007, 2009]
2 © ISO 2015 – All rights reserved

2.12
concept
unit of knowledge created by a unique combination of characteristics
[SOURCE: ISO 1087-1:2000]
2.13
concept analysis
formal linguistic strategy that allows the defining attributes or characteristics of a concept to be examined
[SOURCE: Walker LO Avant KC (1988). Strategies for Theory Construction in Nursing. 2nd edition.
Norwalk/ San Mateo, Appleton and Lange]
2.14
concept definition
description of the attributes of a concept to delineate the meaning
2.15
conceptual model
describes common concepts and their relationships particularly in order to facilitate exchange of
information between parties within a specific domain of healthcare
[SOURCE: ENV 1613 CR 12587]
2.16
continuity of care
component of patient care quality consisting of the degree to which the care needed by a patient is
coordinated among practitioners and across organizations and time
[SOURCE: ISO/TR 18307:2001]
2.17
context
related conditions and situations that provide a useful understanding and meaning of a subject
[SOURCE: ISO/TR 17119:2005]
2.18
data
reinterpretable representation of information in a formalized manner suitable for communication,
interpretation or processing
[SOURCE: ISO/IEC 2382-1:1993]
2.19
data element
unit of data that is considered, in context, to be indivisible
[SOURCE: ISO/IEC 14957:2010]
2.20
data item
expression of a single data element or a composite data element represented in a specific format and
identified by the preceding field tag
[SOURCE: ISO 15022-1:1999]
2.21
data type
set of distinct values, characterized by properties of those values and by operations on those values
[SOURCE: ISO/IEC 11404:2007]
2.22
Detailed Clinical Model
DCM
logical model designed to express one or more clinical concepts and their context in a standardized and
reusable manner, specifying the requirements for clinical information as a discrete set of logical clinical
data elements
2.23
Domain Information Model
DIM
information model describing concepts and relationships relevant to a specific problem area
2.24
Electronic Health Record
EHR
logical representation of information regarding or relevant to the health of a subject of care
[SOURCE: ISO 18308:2011, modified]
2.25
electronic health record architecture
logical generic components from which electronic health records are designed, defined in terms of an
information model and computational services
[SOURCE: ISO 18308:2011, modified]
2.26
entity
concrete or abstract thing of interest, including associations among things
[SOURCE: ISO/IEC 2382:—]
2.27
entry
documentation of a discrete item of health information
Note 1 to entry: An entry may for example represent the documentation of a clinical observation, an inference, an
intention, a plan or an action.
[SOURCE: ISO 18308]
2.28
governance for Detailed Clinical Models
system by which development, distribution, responsibility, accountability, delegation of authoritative
powers, including legal and ethical aspects and maintenance of Detailed Clinical Models are directed
and controlled
Note 1 to entry: The management framework which governs DCM development and maintenance decision making
[SOURCE: ISO/IEC 38500:2015, modified]
2.29
harmonization
process whereby a DCM is designed and presented in such a way as to fulfill a range of criteria originally
expressed as distinct requirements and possibly originally put forward as distinct DCMs
2.30
Health(care) information
information about a person, relevant to his or her health or health care
[SOURCE: ISO 13606-1:2008]
4 © ISO 2015 – All rights reserved

2.31
information governance
processes by which an organization obtains assurance that the risks to its information and thereby the
operational capabilities and integrity of the organization, are effectively identified and managed
[SOURCE: ISO 27799:2008]
2.32
information
knowledge concerning such things as facts, concepts, objects, events, ideas
[SOURCE: ISO 1087-2:2000]
2.33
lifecycle [of information resource]
sequence of events that mark the development and use of an information resource
EXAMPLE Conception of an invention, creation of a draft, revision of an article, publication of a book,
acquisition by a library, transcription to magnetic disk, migration to optical storage, translation into English and
derivation of a new work (e.g. a movie).
[SOURCE: ISO 15836:2003]
2.34
logical information model
information model that specifies the structures and relationships between data elements but is
independent of any particular technology or implementation environment
[SOURCE: ISO/TR 17119:2005]
2.35
medical knowledge
field pertaining to the structure, function, or dysfunction of the human body and how it can be
influenced by external or internal factors and interventions
Note 1 to entry: Medical does not imply “physician”, all health professionals have medical knowledge according
to this definition.
[SOURCE: ISO 656:1980]
2.36
metadata
data that defines and describes other data
[SOURCE: ISO/IEC 11179-1:2004]
2.37
model
representation of a domain that uses abstraction to express the relevant concepts
2.38
modeling
construction of abstract representations in the course of design, for example to represent the logical
structure of software applications before coding
[SOURCE: http://www.omg.org/gettingstarted/what_is_uml.htm]
2.39
OpenEHR template
directly, locally usable data creation/validation artifact that is semantically a constraint/choice of
archetypes and which will often correspond to a whole form or screen
[SOURCE: ISO/TR 20514:2005]
2.40
OSI reference model
model that divides and defines the functions of communication equipment, such as computers, into a
seven layer structure based on the design policy of Open Systems Interconnection (OSI) established by
ISO for network structuring, in order to facilitate heterogeneous network data transfer
2.41
parameter
synonym for data item, in particular when used to adapt a computation, or the operation or appearance
of a software application for a particular purpose
2.42
patient safety
prevention of harm caused by errors of commission and omission
[SOURCE: Aspden, Corrigan, Wolcott, et al., 2004]
2.43
persistent data
data stored on a permanent basis
[SOURCE: ISO/IEC 11179-1:2004]
2.44
physical model or design model
instantiation of a logical model that respects specific technological constraints, normally for use in
building a specific system or product.
[SOURCE: ISO/TR 20514:2005 and ISO/TR 17119:2005]
2.45
quality
degree to which all the properties and characteristics of a product, process, or service satisfy the
requirements which ensue from the purpose for which that product, process, or service is to be used
[SOURCE: ISO 9001:2008]
2.46
Quality Management System (QMS)
Framework described by the ISO 9000 family of standards and comprised of the three core elements:
quality control, quality assurance and quality improvement
2.47
Reference Model for Open Distributed Processing (RM-ODP)
standardized approach to design and governance of information systems, in particular systems
involving data communications between organizations that have different computing platforms.
[SOURCE: ITU-T Rec. X.901-X.904 | ISO/IEC 10746]
2.48
safety
freedom from unacceptable risk of harm
[SOURCE: ISO/IEC Guide 51:2014]
2.49
semantic interoperability
ability for data shared by systems to be understood at the level of fully defined domain concepts
[SOURCE: ISO/TS 18308:2011]
6 © ISO 2015 – All rights reserved

2.50
template
expression of a set of constraints on the RIM/RM or derived model used to apply additional constraints
to a portion of an instance of data which is expressed in terms of some other Static Model, to further
define and refine these existing models to specify a narrower and more focused scope
[SOURCE: HL7 V3 Templates. HL7 Version 3 Standard: Specification and Use of Reusable Constraint
Templates, Release 2 February 2008]
2.51
term
designation of a defined concept in a special language by a linguistic expression
[SOURCE: ISO 1087-1:2000]
2.52
terminological system
ordered collection of concepts, in which each concept is expressed by terms, words or expressions
[SOURCE: NEN 7522, based on ISO/IEC 11179-1:2004, definition 3.2.25]
2.53
value set
uniquely identifiable set of valid concept representations, where any concept representation can be
tested to determine whether or not it is a member
Note 1 to entry: A value set is intended to be a set in the formal sense, and so should contain only one code for
each uniquely identifiable concept that it contains.
[SOURCE: Adapted from TN903 HITSP specified metadata: element, description, HITSP Template Metadata
and the HL7 Templates DSTU Property name, MIF mapping. Adapted from HL7 Version 3 Core Principals]
2.54
variable
symbolic name associated with a data element or data item, often a data element or data item whose
content or value may change over time
2.55
view
alternate presentation of data for a different user or purpose
[SOURCE: ISO 13606-1:2008]
2.56
workflow
depiction of the actual sequence of the operations or actions taken in a process
Note 1 to entry: A workflow reflects the successive decisions and activities in the performance of a process.
[SOURCE: ISO 18308:2011]
3 Abbreviated terms
For the purposes of this document, the following abbreviations apply.
CEN Comité Européen de Normalisation
DAM Domain Analysis Model
DCM Detailed Clinical Model
DIM Domain Information Model
EHR Electronic Health Record
EHR-S FM Electronic Health Record System Functional Model
GCM Generic Component Model
HIT Healthcare Information Technologies
HL7 Health Level Seven
HL7 CIM Constrained Information Models
HL7 CMET Common Message Element Type
HL7 LIM Local Information Model
ISO International Organization for Standardization
RIM Reference Information Model
RM Reference Model
OCL Object Constraint Language
OSI reference Open Systems Interconnection
model
UML Unified Modeling Language
URI Uniform Resource Identifier
URL Uniform Resource Locator
W3C World Wide Web Consortium
4 Definition, purpose, contexts and position of Detailed Clinical Models
4.1 Definition of Detailed Clinical Models
A Detailed Clinical Model is a logical model designed to express one or more clinical concepts and their
context in a standardized and reusable manner, specifying the requirements for clinical information as
a discrete set of logical clinical data elements.
They are models constructed to bridge/link the intersection between the enterprise and information
perspectives. Traceability to an underlying clinical process- (regarding clinical context) and/or a clinical
concept reference model (regarding clinical content) is required for DCMs. A Detailed Clinical Model
must further be expressed against underlying logical reference models (RMs) or reference information
models (RIM) however this TS does not specify which RM or RIM.
8 © ISO 2015 – All rights reserved

Structurally, a DCM provides the data elements and attributes of a clinical concept, including the
possible values and types of attributes and the relationships needed to convey the clinical requirements
to domain experts, data users, modellers and implementers.
Ideally all Detailed Clinical Models make use of a pragmatic and/or where possible, a purposeful defined
maximal data set for a universal use case. For safety, we should favour simplicity which favours “for
purpose” DCMs that utilize only the required data elements from the maximal data set, needed to suit
the purpose of the DCM. DCMs which represent the clinical concepts at the logical model level are to
be implemented and therefore must refer to an appropriate selection from the list described below or
equivalent models:
— An agreed conceptual model of health care, such as ISO 13940 (Contsys).
— Agreed clinical reference models based on process and concept descriptions in a standard such as
ISO 13940 (Contsys).
— An agreed standard Electronic Health Record (EHR) reference (information) model, such as
ISO 13606 and/or openEHR. The reference (information) model guarantees that the common
attributes for information in health records (such as who, when and where) have already been
identified and do not need to be addressed again in each Detailed Clinical Model.
— An agreed standard information exchange reference information model such as the HL7 v3 RIM
or ISO 13606-1.
— Requirements for EHR architectures, such as ISO 18308 or HL7 EHR-S-FM.
DCMs can be developed at different levels of complexity, ranging from one single data element to
the more common situation where most DCMs have multiple data elements. DCMs should be of a
size appropriate for the content and scope of the model. The question about how big or how small a
DCM is depends on different factors: if a data element has a role by itself, it is logical to have a single
data element DCM. Specific clinical purposes determine the logic to keep data elements together in
the context for which they are specified. This is done in order to prevent wrong interpretations and
misleading conclusions.
This is further clarified in the following examples:
a Atomic DCM. The DCM consists of one single data element only. This data element has a specific
purpose and therefore is specified. One example is the DCM Body Mass Index. The BMI has one
data element, which is the result of a formula. To use this DCM BMI, both the DCM for length and for
weight are required. Another small DCM is for the HbA1c v
...