ISO 23903:2021

Health informatics - Interoperability and integration reference architecture - Model and framework

This document enables the advancement of interoperability from the data/information exchange paradigm to knowledge sharing at decreasing level of abstraction, starting at IT concept level (semantic coordination) through business domain concept level (agreed service function level cooperation), domain level (cross-domain cooperation) up to individual context (skills-based end-user collaboration). The document defines a model and framework for a harmonized representation of existing or intended systems with a specific focus on ICT-supported business systems. The Interoperability and Integration Reference Architecture supports ontology harmonization or knowledge harmonization to enable interoperability between, and integration of, systems, standards and solutions at any level of complexity without the demand for continuously adapting/revising those specifications. The approach can be used for analysing, designing, integrating, and running any type of systems. For realizing advanced interoperability, flexible, scalable, business-controlled, adaptive, knowledge-based, intelligent health and social ecosystems need to follow a systems-oriented, architecture-centric, ontology-based and policy-driven approach. The languages for representing the different views on systems such as ontology languages like Common Logic (CL) (ISO/IEC 24707[24]) and Web Ontology Language (OWL)[25] – specifically OWL 2[26] (World Wide Web Consortium (W3C®), languages for modeling and integrating business processes like Business Process Modeling Language (BPML) (OMG®), but also OMG’s Unified Modeling Language (UML, also specified as ISO/IEC 19505[27]) based representation styles for the different ISO/IEC 10746 (all parts) views are outside the scope of this document.

Informatique de santé — Architecture de référence d'interopérabilité et d'intégration — Modèle et cadre

Le présent document permet de faire progresser l'interopérabilité depuis le paradigme d'échange de données/d'informations vers le partage des connaissances à un niveau d'abstraction de moins en moins élevé, en commençant au niveau des concepts TI (coordination sémantique) en passant par le niveau des concepts de domaine d'activité (coopération convenue au niveau des fonctions de service), le niveau du domaine (coopération inter-domaines) jusqu'au contexte individuel (collaboration entre utilisateurs finaux fondée sur les compétences). Le présent document définit un modèle et un cadre pour une représentation harmonisée de systèmes existants ou prévus, portant plus particulièrement sur les systèmes professionnels pris en charge par les technologies de l'information et de la communication. L'architecture de référence d'interopérabilité et d'intégration prend en charge l'harmonisation ontologique ou l'harmonisation des connaissances afin de permettre l'interopérabilité entre, et l'intégration des, systèmes, normes et solutions à tout niveau de complexité sans exiger d'adapter ou réviser en continu ces spécifications. Cette démarche peut être utilisée pour analyser, concevoir, intégrer et faire fonctionner tout type de systèmes. Pour arriver à une interopérabilité avancée, il est nécessaire que des écosystèmes de santé et sociaux flexibles, évolutifs, contrôlés par les activités, adaptables, basés sur les connaissances et intelligents suivent une démarche orientée systèmes, centrée sur l'architecture, basée sur l'ontologie et dictée par une politique. Les langages utilisés pour représenter les différentes vues des systèmes, comme les langages d'ontologie tels que Common Logic (CL) (ISO/IEC 24707[24]) et Web Ontology Language (OWL)[25] – spécifiquement OWL 2[26] (World Wide Web Consortium, W3C®6), les langages de modélisation et d'intégration de processus professionnels tels que Business Process Modeling Language (BPML) (OMG®7), mais également Unified Modeling Language d'OMG (UML, également spécifié comme l'ISO/IEC 19505[27]) basés sur les styles de représentation pour les différentes vues de l' ISO/IEC 10746 (toutes les parties) ne relèvent pas du domaine d'application du présent document. 6 W3C est une marque déposée du World Wide Web Consortium. Cette information est donnée par souci de commodité à l'intention des utilisateurs du présent document et ne saurait constituer un engagement de la part de l'ISO quant au produit désigné. 7 OMG est une marque déposée de l'OMG (Object Management Group®). Cette information est donnée par souci de commodité à l'intention des utilisateurs du présent document et ne saurait constituer un engagement de la part de l'ISO quant au produit désigné.

General Information

• Status: Published
• Publication Date: 31-Mar-2021
• ICS: 35.240.80 - IT applications in health care technology
• Technical Committee: ISO/TC 215 - Health informatics
• Drafting Committee: ISO/TC 215/WG 1 - Architecture, Frameworks and Models
• Current Stage: 6060 - International Standard published
• Start Date: 01-Apr-2021
• Due Date: 22-Feb-2021
• Completion Date: 01-Apr-2021

Relations

• Consolidates: ISO 14946:2021 - Small craft - Maximum load capacity
• Effective Date: 06-Jun-2022

Overview - ISO 23903:2021 (Health informatics)

ISO 23903:2021 defines an Interoperability and Integration Reference Architecture - model and framework for health informatics. The standard advances interoperability beyond data/information exchange into knowledge sharing and cross‑domain cooperation, supporting ICT‑supported business systems from IT concept level (semantic coordination) up to individual, skills‑based end‑user collaboration. It provides a harmonized, domain‑independent model to represent existing or intended systems and to enable ontology/knowledge harmonization without continuous revision of individual specifications.

Key technical topics and requirements

• Interoperability levels: foundational, structural (syntactic), semantic, coordination (service-level), knowledge‑based (cross‑domain), and skills‑based (individual context).
• Generic Reference Architecture model: an abstract, system‑oriented meta‑architecture for representing components, functions, relations, and policies across granularity levels.
• Framework components:
  • Basic requirements for system representation and integration.
  • Management of relationships between domain representations and system components.
  • Business process modelling guidance using the reference architecture.
• Ontology and knowledge harmonization: supports linking domain‑specific ontologies (e.g., SNOMED‑CT, OBO) to a top‑level, architecture‑centric representation to enable knowledge‑level interoperability.
• Systems approach: emphasizes architecture‑centric, policy‑driven, and ontology‑based methods for adaptive, scalable health and social care ecosystems.
• Scope and limits: tools and languages for ontology or process representation (e.g., Common Logic, OWL 2, UML, BPML) are referenced but their specific languages/formats are outside the standard’s scope.
• Informative annexes: examples for cross‑domain EHR communication, integrating existing communication standards, and deployment considerations (e.g., relations to ISO 12967 and ISO 13972).

Practical applications and target users

• Who will use ISO 23903:2021:
  • Health informatics architects and system designers
  • Standards developers and specification writers
  • Systems integrators, implementers and vendors of EHR and health IT
  • Policy makers and program leads designing multi‑domain digital health ecosystems
• Practical uses:
  • Designing interoperable, knowledge‑aware health IT systems and ecosystems
  • Harmonizing multiple domain ontologies and standards to enable cross‑domain services
  • Analyzing and integrating legacy systems with new ICT‑supported business processes
  • Guiding enterprise architecture and business process modelling for health and social care

Related standards and references

• ISO/IEC 24707 (Common Logic), OWL 2 (W3C), UML (ISO/IEC 19505) - referenced as representation languages (out of scope)
• ISO 13940 (continuity of care concepts), ISO 12967 (systems integration), ISO 21838 (top‑level ontologies)
• Domain standards: SNOMED CT, openEHR, HL7

ISO 23903:2021 is essential when planning robust, scalable interoperability strategies that move from message exchange to true knowledge and process‑level integration in digital health.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 23903
First edition
2021-04
Corrected version
2021-07
Health informatics — Interoperability
and integration reference architecture
— Model and framework
Informatique de santé — Architecture de référence d'interopérabilité
et d'intégration — Modèle et cadre
Reference number
©
ISO 2021
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO 2021 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviations. 5
5 Overview on standard system architecture. 5
6 Interoperability and Integration Reference Architecture for ICT Supported Systems .6
6.1 Interoperability and Integration Reference Architecture domains and granularity levels . 6
6.2 Interoperability and Integration Reference Architecture model for ICT supported
systems . 7
6.3 Interoperability and Integration Reference Architecture framework . 8
6.3.1 Basic requirements . 8
6.3.2 Management of relationships in the Interoperability and Integration
Reference Architecture . 9
6.3.3 Business process modelling using the Interoperability and Integration
Reference Architecture . 9
Annex A (informative) Cross-domain interoperability for security and privacy aware EHR
communication .11
Annex B (informative) Interoperability between different communication standards .13
Annex C (informative) Integration of standards in ISO 12967 (all parts) .15
Annex D (informative) Deployment of the Interoperability and Integration Reference
Architecture Approach in ISO 13972.18
Annex E (informative) Deployment of the Interoperability and Integration Reference
Architecture Approach for the representation and harmonization of alternative
reference architectures .19
Bibliography .21
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 of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso .org/
iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 215, Health informatics, in collaboration
with the European Committee for Standardization (CEN) Technical Committee CEN/TC 251, Health
informatics, in accordance with the Agreement on technical cooperation between ISO and CEN (Vienna
Agreement).
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
This corrected version of ISO 23903:2021 incorporates the following corrections:
— Figure E.1 has been corrected.
iv © ISO 2021 – All rights reserved

Introduction
0.1  Preface
This document supports the integration of a) specifications from different domains with their specific
methodologies, terminologies and ontologies including specific specification style as well as b) systems
based on those specifications. Enabling the use-case-specific identification and consistent, formal
representation including constraints of necessary components with their specific concepts and their
relationships, this document facilitates the deployment of existing standards and systems, the analysis
and improvement of specifications under revision as well as the design of new projects.
This document provides an overview of the Interoperability and Integration Reference Architecture
[1][2]
(first introduced in the 1990s as the Generic Component Model – GCM ), providing scope, justification
and explanation of key concepts and the resulting model and framework. It contains explanatory
material on how this Interoperability and Integration Reference Architecture is interpreted and applied
by its users, who might include standards writers and architects of interoperable systems, but also
systems integrators.
The ongoing organizational, methodological and technological paradigm changes in health and
social care result in health systems transformation toward P5 (personalized, preventive, predictive,
participative precision) systems medicine as fully distributed, highly dynamic, strongly integrated,
multi-disciplinary (or multi-domain) intelligent ecosystems, comprising both structured systems,
[3]
communities governed by rules, and combinations thereof .
0.2  Interoperability levels
Interoperability (see 3.16) has evolved during the last 30 years from structured messaging (e.g. EDI,
1) 2) [4]
HL7® messaging) over sharing concepts [e.g. openEHR® Archetypes, ISO 13940 (system of
concepts to support continuity of care)] – both representing the data/information exchange paradigm
– to cooperation at application level (e.g. Web services). All those solutions focus on information and
communication technologies (ICT) systems interoperability using ICT terminologies and ontologies
for representing data, information, or even concepts and knowledge, thereby distinguishing the three
interoperability levels: a) foundational, b) structural, and c) semantic interoperability.
On the move towards digital health, ICT systems get more closely integrated in the real world business
process. This move requires supporting advanced, knowledge-level and business process focused
interoperability between all principals acting in those ecosystems such as persons, organizations,
devices, applications, components, or objects to achieve the common business objectives. As knowledge,
methodologies and terminologies of the domains involved in the business case and represented through
those domains’ ontologies, but also individual contexts, abilities and capabilities are highly different,
they must be shared and adapted in advance or dynamically at runtime, enabling adequate cooperation
[5]
of actors and systems involved. Table 1 summarizes the different interoperability levels .
1) HL7 is a registered trademark of Health Level Seven International. This information is given for the convenience
of users of this document and does not constitute an endorsement by ISO of the product named.
2) openEHR is a registered trademark of the openEHR Foundation. This information is given for the convenience
of users of this document and does not constitute an endorsement by ISO of the product named.
Table 1 — Interoperability levels
Information Perspective Organization Perspective
Interoperability
Instances Interoperability Level
Level
Technical Technical plug&play, signal & protocol com- Light-weight interactions
patibility
Structural Simple EDI, envelopes Data sharing
Syntactic Messages and clinical documents with agreed Information sharing
vocabulary
Semantic Advanced messaging with common information Knowledge sharing at IT concept level in
models and terminologies computer-parsable form
Coordination
O rg a n iza t i o n / Common business process Knowledge sharing at business concept level
Service
Agreed service function level cooperation
Knowledge based Multi-domain processes Knowledge sharing at domain level
Cross-domain cooperation
Skills based Individual engagement in multiple domains Knowledge sharing in individual context
Moderated end-user collaboration
0.3  Motivation for the Interoperability and Integration Reference Architecture
Meeting the objectives of improving safety, quality and efficiency of care with ICT support requires
advancing interoperability between computer systems towards a business-process-specific co-
operation of actors representing the different domains participating in the business case. For that
purpose, the agreed domain knowledge, but also the individual and shared context (language, education,
skills, experiences, psychological, social, occupational, environmental aspects, etc.), need to be
represented correctly and formally for integration with the ICT system as part of the business system.
As the domain experts involved describe specific aspects of that business system in their own specific
contexts and using specific terminologies and ontologies, methodologies and frameworks, the resulting
informational representations are often quite inconsistent, requiring a peer-to-peer interoperability
adaptation process. Adapting existing standardized informational representations of domain-specific
use cases to changing contexts or contexts including multiple domains requires another common
harmonized informational representation, resulting in permanent revisions of specifications.
Modelling systems for multi-domain interoperability requires the advancement from the data model,
information model, and ICT domain knowledge perspective to the knowledge perspective of the
[6]
business domains . For achieving the latter, the relevant stakeholders are responsible to define the
provided view of the model as well as the way of structuring and naming the concepts of the problem
space. First capturing key concepts and key relations at a high level of abstraction, different abstraction
levels can be used iteratively. Thereby, the first iteration is performed in a top-down manner to
guarantee the conceptual integrity of the model. This demands meeting design principles such as
[7] [8]
orthogonality, generality, parsimony, and propriety. ISO 30401 defines the requirements for
knowledge management systems in organizations to meet business objectives.
It is impossible to represent the highly complex, highly dynamic, multi-disciplinary/multi-domain
healthcare system by one domain‘s terminology/ontology or – even worse for the reasons mentioned
right before - by exclusively using ICT ontologies and ICT specific representation styles.
The alternative is an abstract, domain-independent representation of systems using Universal Type
[9]
Theory and corresponding logics. The mathematical concept representation using a Meta Reference
[9]
Architecture according to the formal theory of the Barendregt Cube with Parameters in combination
with systems engineering methodologies allows representing any system architecturally (i.e. the
system’s components, their functions and internal as well as external relations) by generically describing
its composition/decomposition and behaviour from the perspectives of all domains of relevance in a
specific business case. A third dimension describes the system’s development process such as evolution
vi © ISO 2021 – All rights reserved

for living systems, manufacturing for technical systems, or a software development process, resulting
in a generic system model or Generic Reference Architecture presented in Figure 1. Details regarding
the dimensions of the model are explained in Clause 5 and Clause 6.
Figure 1 — Generic Reference Architecture model
To represent advanced interoperability and integration settings, different domain-specific
representations are linked to the same real world component. Therefore, an abstract and generic
reference architecture is needed which is able to represent any aspect or domain of interest. For
correctly and formally representing the concepts and relations of the domain-specific subsystems
involved in that business case, those subsystems are represented by their corresponding approved
domain ontologies, resulting in a system-theoretical, architecture-centric, top-level ontology driven
[10][11]
approach . Requirements for top level ontologies are specified in ISO 21838 (all parts). Health
3)
domain ontologies are SNOMED-CT® or specific ontologies such as the Open Biomedical Ontologies
[12] [13]
(OBO), including the Gene Ontology, maintained by the OBO Foundry .
As we can consistently model and compute only systems of reasonable complexity, the Generic Reference
Architecture model (Figure 1) can be used recursively at different granularity levels, so representing,
e.g. the continuum of real-world systems from elementary particles to the universe. The concepts of
the system’s components and their relations are represented in appropriate expressions in natural or
formal languages up to the basic level of primitives. The system analysis or design needs to address
partial systems when considering higher granularity levels of the system in question.
0.4  Technical approach
A system is a composition of interrelated components, ordered to accomplish a specific function or a
set of functions. Systems can be decomposed into subsystems or composed to form super-systems.
There are constructive or structural and behavioural or functional aspects of systems. According to
[14]
IEEE 1471, the architecture of a system is the fundamental organization of that system embodied in
its components, their relationships to each other and to the environment, and the principles guiding its
design and evolution. Rules for selecting and constraining components and functions as well as relations
according to a business case are called policies. Policies define the intended behaviour of a system. For
living systems, factors such as homeostasis, with the attributes of self-organization and self-regulation
as well as growth and development, reproduction, with the associated heredity (structure preservation)
and mutation (structural change), and higher development through selection of best-adapted variants
out of a large number make the description of living systems more complicated than that of technical
[15]
systems .
3) SNOMED CT is the registered trademark of the International Health Terminology Standards Development
Organisation (IHTSDO). This information is given for the convenience of users of this document and does not
constitute an endorsement by ISO of the product named.
In the 1970s and 1980s, a data level interoperability approach was developed by defining the
application and technology agnostic standard data exchange format EDI (electronic data interchange)
in order to transform proprietary data formats into the standard data format and vice versa.
[16]
Thus International Standards arose such as ISO 9735 (EDIFACT), or its healthcare-specific
[17]
pendant ISO/HL7 27931:2009, an application protocol for electronic data exchange in healthcare
environments. This document defines a generic system architecture for knowledge level interoperability.
It allows consistently transforming and interrelating any domain specific subsystem’s structure and
behaviour (e.g. domain specific standards and specifications) by ontologically representing its concepts
and relationships at the real world system component’s level of granularity in the abstract generic
component system. In other words, the domain specific subsystem (e.g. a domain specific standard or
specification) is re-engineered using the Interoperability and Integration Reference Architecture, by
that way providing a standardized interface to that specification. In this way, the methodology offered
in this document maps between domain specific or proprietary systems and their representation as
specification or domain specific standard by transforming them into a standard system architecture
and vice versa. Annex A demonstrates the integration of two domain specific standards by reengineering
[18]
the ISO 13606-1 Reference Model and the HL7® Composite Security and Privacy Domain Analysis
[19]
Model and combining them in an Interoperability and Integration Reference Architecture model
instance. Annex B demonstrates the integration of different communication standards by reengineering
4) 4)
HL7 v3® methodology and creating an adequate HL7 v2® methodology and transforming them into
an Interoperability and Integration Reference Architecture instance. In this way, the Interoperability
and Integration Reference Architecture supports the mutual transformation of those communications
standards for the sake of interoperability of existing solutions. For ontologically representing the
[20]
models, the Communication Standards Ontology (CSO) has been used. Figure 2 correspondingly
presents this standard’s interoperability approach. Annex C demonstrates the integration of different
[21]
standards in the light of ISO 12967(all parts) , while Annex D presents the approach in context of
[22]
ISO 13972 . Finally, Annex E demonstrates the deployment of this document’s Interoperability and
Integration Reference Architecture for the representation and harmonization of alternative reference
architectures.
4) HL7 v3 and HL7 v2 are registered trademarks of Health Level Seven International. This information is given for
the convenience of users of this document and does not constitute an endorsement by ISO of the products named.
viii © ISO 2021 – All rights reserved

Figure 2 — Overview of this document’s interoperability approach
Bound to the GCM Framework, inter-domain relationships need to happen at the same level of
[23]
granularity . To get there, intra-domain specializations/generalizations are performed.
INTERNATIONAL STANDARD ISO 23903:2021(E)
Health informatics — Interoperability and integration
reference architecture — Model and framework
1 Scope
This document enables the advancement of interoperability from the data/information exchange
paradigm to knowledge sharing at decreasing level of abstraction, starting at IT concept level (semantic
coordination) through business domain concept level (agreed service function level cooperation),
domain level (cross-domain cooperation) up to individual context (skills-based end-user collaboration).
The document defines a model and framework for a harmonized representation of existing or intended
systems with a specific focus on ICT-supported business systems. The Interoperability and Integration
Reference Architecture supports ontology harmonization or knowledge harmonization to enable
interoperability between, and integration of, systems, standards and solutions at any level of complexity
without the demand for continuously adapting/revising those specifications. The approach can be
used for analysing, designing, integrating, and running any type of systems. For realizing advanced
interoperability, flexible, scalable, business-controlled, adaptive, knowledge-based, intelligent health
and social ecosystems need to follow a systems-oriented, architecture-centric, ontology-based and
policy-driven approach.
The languages for representing the different views on systems such as ontology languages like
[24] [25] [26]
Common Logic (CL) (ISO/IEC 24707 ) and Web Ontology Language (OWL) – specifically OWL 2
5)
(World Wide Web Consortium (W3C® ), languages for modeling and integrating business processes
6)
like Business Process Modeling Language (BPML) (OMG® ), but also OMG’s Unified Modeling
[27]
Language (UML, also specified as ISO/IEC 19505 ) based representation styles for the different
ISO/IEC 10746 (all parts) views are outside the scope of this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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 10746 (all parts), Information technology — Open distributed processing — Reference model
ISO 22600 (all parts), Health informatics — Privilege management and access control
ISO/IEC 21838 (all parts), Information technology — Top-level ontologies (TLO)
OMG Ontology Definition Metamodel V1.1
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
5) W3C is a registered trademark of the World Wide Web Consortium. This information is given for the convenience
of users of this document and does not constitute an endorsement by ISO of the products named.
6) OMG is a registered trademark of The Object Management Group®. This information is given for the convenience
of users of this document and does not constitute an endorsement by ISO of the products named.
3.1
architecture
set of rules to define the structure of a system (3.25) and the interrelationships between its parts
[SOURCE: ISO/IEC 10746-2:2009, 6.6, modified — "(of a system)" removed from term.]
3.2
axiom
statement that is taken to be true, to serve as a premise for further reasoning
7)
[SOURCE: ISO/IEC/PRF 21838-1:— , 3.9, modified — Note to entry removed.]
3.3
business viewpoint
viewpoint (3.28) that is concerned with the purpose, scope and policies governing the activities of the
specified ecosystem (3.10)
3.4
class
type
general entity (3.11)
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.2, modified — “type” added as second preferred term, note to
entry removed.]
3.5
collection
group of particulars (3.19)
8)
[SOURCE: ISO/IEC/PRF 21838-2:— , 3.4, modified — Notes to entry removed.]
3.6
concept
unit of knowledge created by a unique combination of characteristics
Note 1 to entry: Concepts are not necessarily bound to particular natural languages. They are, however,
influenced by the social or cultural background which often leads to different categorizations.
Note 2 to entry: As a knowledge component, a concept can be specialized and generalized as components can.
[SOURCE: ISO 1087:2019, 3.2.7, modified — Note 2 to entry replaced.]
3.7
definition
representation of a concept by a descriptive statement which serves to differentiate it from related
concepts
[SOURCE: ISO 1087:2019, 3.3.1]
3.8
domain
collection (3.5) of entities (3.11) of interest to a certain community or discipline
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.17, modified — Example and note to entry removed.]
7) Under preparation. Stage at the time of publication: ISO/IEC/PRF 21838-1:2021.
8) Under preparation. Stage at the time of publication: ISO/IEC/PRF 21838-2.2:2021.
2 © ISO 2021 – All rights reserved

3.9
domain ontology
ontology (3.18) whose terms (3.26) represent classes or types (3.4) and, optionally, certain particulars
(3.19) (called ‘distinguished individuals’) in some domain (3.8)
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.18]
3.10
ecosystem
structured systems (3.25) and communities that are governed by general rules
3.11
entity
object
item that is perceivable or conceivable
Note 1 to entry: The terms ‘entity’ and ‘object’ are catch-all terms analogous to ‘something’. In terminology
circles ‘object’ is commonly used in this way. In ontology circles, ‘entity’ and ‘thing’ are commonly used.
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.1]
3.12
expression
word or group of words or corresponding symbols that can be used in making an assertion
Note 1 to entry: Expressions are divided into natural language expressions and expressions in a formal language.
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.5]
3.13
formal language
language that is machine readable and has well-defined semantics
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.10, modified — Note removed.]
3.14
formal theory
collection (3.5) of definitions (3.7) and axioms (3.2) expressed in a formal language (3.13)
[SOURCE: ISO/IEC/PRF 21838-1: —, 3.11, modified — Note removed.]
3.15
instance
particular (3.19) that instantiates some universal (3.27)
[SOURCE: ISO/IEC/PRF 21838-2:—, 3.6, modified — Example removed.]
3.16
interoperability
ability of a system (3.25) or a product to work with other systems (3.25) or products without special
effort on the part of the customer
Note 1 to entry: Under traditional ICT focus, interoperability is ability of two or more systems or components to
[29]
exchange information and to use the information that has been exchanged .
[SOURCE: IEEE Standards Glossary]
3.17
model
unambiguous, abstract conception of some parts or aspects of the real world corresponding to the
modelling goals
Note 1 to entry: The relevant stakeholders define the provided view of the model as well as the way of structuring
and naming the concepts of the problem space. First capturing key concepts and key relations at a high level of
abstraction, different abstraction levels should be used iteratively, where the first iteration is performed in a top-
down manner to guarantee the conceptual integrity of the model. This requires meeting design principles such
[30]
as orthogonality, generality, parsimony, and propriety .
3.18
ontology
collection (3.5) of terms (3.26), relational expressions (3.24) and associated natural-language definitions
(3.7) together with one or more formal theories (3.14) designed to capture the intended interpretations
of these definitions (3.7)
Note 1 to entry: An ontology defines a set of representational primitives with which to model a domain of
knowledge or discourse. The representational primitives are typically classes (or sets), attributes (or properties),
and relationships (or relations among class members). The definitions of the representational primitives include
[31]
information about their meaning and constraints on their logically consistent application .
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.14, modified — Note to entry replaced.]
3.19
particular
individual entity (3.11)
Note 1 to entry: In contrast to classes or types, particulars are not exemplified or instantiated by further entities.
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.3]
3.20
policy
set of legal, political, organizational, functional, and technical obligations for communication and
cooperation
Note 1 to entry: Policies define the intended behaviour of systems.
[SOURCE: ISO 22600-1:2014, 3.13 modified — Note to entry added.]
3.21
primitive
expression (3.12) for which no non-circular definition (3.7) can be provided
[SOURCE: ISO/IEC/PRF 21838-2:—, 3.1]
3.22
reference architecture
reference model for a class (3.4) of architectures (3.1)
3.23
relation
way in which entities (3.11) are related
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.4, modified — Notes to entry removed.]
3.24
relational expression
expression (3.11) used to assert that a relation (3.22) obtains
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.6, modified — Example and notes removed.]
4 © ISO 2021 – All rights reserved

3.25
system
combination of interacting elements organized to achieve one or more stated purposes
Note 1 to entry: A system groups structurally and/or functionally interrelated components (elements). Systems
can be composed (aggregated/generalized) to super-systems or decomposed (specialized) to sub-systems.
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.46, modified — Note 1 to entry replaced, notes 2 and 3 to
entry removed.]
3.26
term
expression (3.12) that refers to some class (3.4) or to some particular (3.19)
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.7, modified — Note to entry removed.]
3.27
universal
type
entity (3.11) that has indefinitely many instances (3.15)
[SOURCE: ISO/IEC/PRF 21838-2:—, 3.2, modified — Example and note to entry removed.]
3.28
viewpoint
form of abstraction achieved using a selected set of architectural concepts and structuring rules, in
order to focus on particular concerns within a system
[SOURCE: ISO/IEC 10746-2:2009, 3.2.7, modified — "(on a system)" removed from term.]
4 Abbreviations
EHR Electronic Health Record
HL7® Health Level Seven®
UML Unified Modelling Language
RM-ODP Reference Model of Open Distributed Processing
5 Overview on standard system architecture
Acknowledging the different perspectives on a business system and its individual and shared context
provided by different disciplines or domains involved in the business case, the business system is
composed of subsystems represented by those domain-specific perspectives based on the domain-
specific methodologies, terminologies and ontologies. Examples of such subsystems are clinical care,
administration, legal/regulatory affairs, security, privacy, training, etc. Like any system, domains
can be composed to super-domains or de-composed to subdomains. For correctly and consistently
interrelating components of those subsystems in a way that enables the intended system behaviour
for meeting the use-case-specific business objectives, an abstract, domain-independent system
architecture with generic system components at different levels of granularity shall be defined,
enabling the composition/decomposition of any salient system. While the generic system with its
generic components and relations is represented using a domain neutral top-level ontology [see
ISO/IEC 21838 (all parts)], the business system and use-case-specifically instantiated systems
discussed as follows are represented using domain ontologies at lower level. At the first granularity
level, the domain specific subsystems (Level of Business Concepts) are specialized into sub-subsystems
representing the perspectives of specialized disciplines or subdomains within one domain, deploying
their specialized methodologies, terminologies and ontologies (Level of Relations Networks). Examples
of such subdomains within the clinical domain are microbiology, pathology, cardiology, ophthalmology,
etc. Those subdomains are furthermore specialized into subdomain- and use-case specific services
(Level of Aggregations) and tasks (Level of Details). The architectural components and their
relationships are represented using the corresponding domain or subdomain ontologies respectively.
In this way, services and tasks can be interrelated across domains by interrelating the corresponding
components and mapping their concepts, thereby inheriting the related specializations/generalization
within the domains/subdomains. For representing the business system’s policies, ISO 22600 (all parts),
[32] [33]
which is the standardization of the policy ontology of PONDER , shall be used . For managing and
harmonizing different ontologies represented using different representation styles and languages, the
9)
OMG® Ontology Definition Metamodel (ODM™) , V1.1 shall be deployed.
Deploying systems theory, especially its white box approach, the GRA (see 0.3) adopts, but goes beyond,
[14] [34]
IEEE 1471:2000, which has been later on superseded by ISO/IEC/IEEE 42010:2011. Not being
limited to ICT systems, a multi-domain real world business system view has been added, transforming
IEEE 1471, ISO/IEC/IEEE 42010 as well as the software development standard ISO/IEC 10746 (all parts)
into a three-dimensional approach. This real world business system view formally represents the
domains’ knowledge spaces, so enabling the correct selection and constraining of components, their
functions and relations, that way supporting correct knowledge-level interoperability and systems
integration. Only at this viewpoint, correctness and consistency of concepts represented in ICT
specifications and standards can be justified.
6 Interoperability and Integration Reference Architecture for ICT Supported
Systems
6.1 Interoperability and Integration Reference Architecture domains and granularity
levels
Adopting the philosophy of ISO/IEC 10746 (all parts), this document fills a gap for real world
interoperability by extending the viewpoints defined in ISO/IEC 10746-1:1998 by an ICT-independent
Business View. This way, it corresponds to the OMG® approach for representation, management,
interoperability, and application of business semantics. The latter allows for formal multi-domain
knowledge representation, interchange and harmonization by providing relationships between symbols
in the logical “universe” and individuals in the “real world”. Figure 3 presents the Interoperability
and Integration Reference Architecture business viewpoint with its domain and its composition/
decomposition dimension.
9) ODM is a registered trademark of The Object Management Group®. This information is given for the convenience
of users of this document and does not constitute an endorsement by ISO of the product named.
6 © ISO 2021 – All rights reserved

Figure 3 — Interoperability and Integration Reference Architecture domains and granularity
levels
6.2 Interoperability and Integration Reference Architecture model for ICT supported
systems
By combining that model with ISO/IEC 10746 (all parts) and its viewpoints and representational
means, the development, implementation and maintenance process of interoperable health and social
ecosystems is added to the approach, completing the Interoperability and Integration Reference
Architecture with its three dimensions system domains, system component composition, and system
viewpoints after RM-ODP (Figure 4).
Figure 4 — The Interoperability and Integration Reference Architecture model
Due to the formal, correct and consistent representation of use-case specific context aware business
systems and their tool-supported automated transformation into finally implementable solutions,
the approach can also be deployed to perform a business system and business objective conformant
analysis of existing systems and specifications regarding their appropriateness, correctness and
consistency, but also to support an appropriate design of emerging system. As the components
presented in the different RM-ODP Viewpoints starting with the Business Viewpoint of the correctly
and consistently designed business system architecture, the transformed viewpoint components shall
be instantiated, thereby preferably selecting and adapting existing specifications/solutions. In other
words, the Interoperability and Integration Reference Architecture guides developers of component
system to select and constrain the right elements, e.g. HL7’s Fast Healthcare Interoperability Resources
10)
(FHIR® ) or FHIR® Profiles. Only this way, the correctness of compositions, relations and underlying
[35]
policies can be ascertained . In consequence, both legacy systems and emerging systems can in this
way be correctly and consistently designed or redesigned.
6.3 Interoperability and Integration Reference Architecture framework
6.3.1 Basic requirements
The system’s complexity shall be limited to the level needed for representing the intended business
case. This might imply the recursive deployment of the modelling process. For each business system
component where a specification is to be developed or an integration of existing specification at any
system development view (here any view defined in ISO/IEC 10746-1:1998) is intended, the domain
this component belongs to as well as its granularity level shall be defined. The business process
and use-case-specific representation of that component shall be provided deploying the domain’s
internationally approved ontology including related logics. In case an ontology does not exist for the
domain, an ontology shall be developed following the ISO 21838 (all parts) definitions and procedures.
10) FHIR is a registered trademark of Health Level Seven International. This information is given for the convenience
of users of this document and does not constitute an endorsement by ISO of the product named.
8 © ISO 2021 – All rights reserved

6.3.2 Management of relationships in the Interoperability and Integration Reference
Architecture
There are three types of relationships between the components of the Interoperability and Integration
Reference Architecture depending on the dimension those relationships are established: specialization/
generalization; mapping; transformation (Figure 5).
Figure 5 — Relationships in the Interoperability and Integration Reference Architecture Model
Composition/decomposition, i.e. specialization/generalization of components shall be provided for
interrelating components between different granularity levels within the one view and the same
domain only. For managing the business system’s complexity, there might be a need for running the
Interoperability and Integration Reference Architecture process recursively.
Harmonization (mapping/matching) shall be provided only between components of different domains
within one view and at the same granularity level only.
Transformation (specialized instantiation) shall be provided within one domain at the same granularity
level only.
6.3.3 Business process modelling using the Interoperability and Integration Reference
Architecture
A business process is a set of related activities and tasks to accomplish agreed objectives. The
Interoperability and Integration Reference Architecture allows formally representing business systems
structure and behaviour from the perspectives of the multiple domains involved in the business
process. This implies a) the natural/logical behaviour of the business system, i.e. the functionality of
the systems components and their relations; and b) the intended behaviour, i.e. the defined policies
for meeting the business system’s objectives. While common domain ontologies describe the natural/
logical functionality of the components as part of the related concepts (case a), a specific policy domain
represents the set of rules intentionally applied for interrelating the domains in the interest of the
[32]
business objectives (case b). The policy domain, represented using policy ontologies such as PONDER
and its standardization in ISO 22600 (all parts), can be specialized into policy sub-domains such as
legal policies, process policies, individual policies of preferences, ethical policies, etc. (Figure 6). This
way, the Interoperability and Integration Reference Architecture enables an ontology-based modelling
of business processes. Such processes shall be represented by mapping concepts, related operations and
logical interrelations of components including applicable constraints at the same level of architectural
granularity.
Figure 6 — Specialization of policy domains according to ISO 22600-2:2014 and ISO 21298:2017
This document enables the formal and explicit representation of processes beyond and within the ICT
perspective. It covers living systems’ evolution as well as manufacturing, but also software development
processes. While the first group of non-IT processes is represented by the Generic Reference
Architecture (Figure 1), the latter is formalized by the Interoperability and Integration Reference
[36]
Architecture extending ISO/IEC 10746 (all pa
...

NORME ISO
INTERNATIONALE 23903
Première édition
2021-04
Informatique de santé — Architecture
de référence d'interopérabilité et
d'intégration — Modèle et cadre
Health informatics — Interoperability and integration reference
architecture – Model and framework
Numéro de référence
©
ISO 2021
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2021
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, 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, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: [phone]
E-mail: [e-mail]
Web: www.iso.org
Publié en Suisse
ii © ISO 2021 – 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 . 5
5 Vue d'ensemble de l'architecture de système standard . 5
6 Architecture de référence d'interopérabilité et d'intégration pour les systèmes pris
en charge par les technologies de l'information et de la communication .6
6.1 Domaines et niveaux de granularité de l'Architecture de référence
d'interopérabilité et d'intégration. 6
6.2 Modèle d'Architecture de référence d'interopérabilité et d'intégration pour
les systèmes pris en charge par les technologies de l'information et de la communication 7
6.3 Cadre de l'Architecture de référence d'interopérabilité et d'intégration . 8
6.3.1 Exigences de base . 8
6.3.2 Gestion des relations dans l'Architecture de référence d'interopérabilité et
d'intégration . 9
6.3.3 Modélisation du processus métier à l'aide de l'Architecture de référence
d'interopérabilité et d'intégration .10
Annexe A (informative) Interopérabilité inter-domaines pour une communication
du Dossier informatisé de santé (DIS) respectueuse de la sécurité et de la vie privée .12
Annexe B (informative) Interopérabilité entre différentes normes de communications .15
Annexe C (informative) Intégration des normes dans l'ISO 12967 (toutes les parties) .17
Annexe D (informative) Déploiement de l'approche d'Architecture de référence
d'interopérabilité et d'intégration dans l'ISO 13972 .21
Annexe E (informative) Déploiement de l'approche d'Architecture de référence
d'interopérabilité et d'intégration pour la représentation et l'harmonisation des
architectures de référence alternatives .22
Bibliographie .25
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 (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier, de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www
.iso .org/ directives).
L'attention est attiré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. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l'élaboration du document sont indiqués dans l'Introduction et/ou dans la liste des déclarations de
brevets reçues par l'ISO (voir www .iso .org/ brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion
de l'ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir www .iso .org/ avant -propos.
Le présent document a été élaboré par le comité technique ISO/TC 215, Informatique de santé, en
collaboration avec le comité technique CEN/TC 251, Informatique de santé, du Comité européen de
normalisation (CEN) conformément à l’Accord de coopération technique entre l’ISO et le CEN (Accord
de Vienne).
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l’adresse www .iso .org/ fr/ members .html.
iv © ISO 2021 – Tous droits réservés

Introduction
0.1  Préface
Le présent document accompagne l'intégration a) de spécifications de différents domaines, avec leurs
méthodologies, terminologies et ontologies spécifiques, y compris les règles de rédaction propres aux
spécifications, ainsi que b) de systèmes basés sur ces spécifications. En permettant une identification
spécifique aux cas d'utilisation, ainsi qu'une représentation cohérente et formelle, y compris les
contraintes de composants nécessaires avec leurs concepts spécifiques et leurs relations, le présent
document facilite le déploiement de normes et de systèmes existants, l'analyse et l'amélioration des
spécifications en cours de révision, ainsi que la conception de nouveaux projets.
Le présent document offre une vue d'ensemble de l'Architecture de référence d'interopérabilité et
[1]
d'intégration (introduite dans les années 90 sous le nom de Modèle de Composant Générique – GCM
[2]
), en donnant le domaine d'application, la justification et l'explication des concepts clés ainsi que le
modèle et le cadre qui en découlent. Elle explique la façon d'interpréter cette Architecture de référence
d'interopérabilité et d'intégration et la manière dont elle peut être utilisée, en particulier, par les auteurs
de normes et les architectes de systèmes interopérables, mais aussi par les intégrateurs de systèmes.
Les changements radicaux actuellement en cours concernant l'organisation, la méthodologie et la
technologie dans le domaine des soins de santé et des soins sociaux donnent lieu à une transformation
des systèmes de santé vers une médecine de systèmes P5 (médecine personnalisée, préventive,
prédictive, participative et pertinente) sous la forme d'écosystèmes pleinement répartis, extrêmement
dynamiques, hautement intégrés, pluridisciplinaires (ou multi-domaines) intelligents, qui comprennent
[3]
des systèmes structurés, des communautés régies par des règles, et leurs combinaisons .
0.2  Niveaux d'interopérabilité
L'interopérabilité (voir 3.16) a évolué au cours des 30 dernières années, des messages structurés (par
1) 2)
exemple EDI, messagerie HL7® ) à des concepts de partage [par exemple archétypes openEHR® ,
[4]
ISO 13940 (système de concepts en appui de la continuité des soins)] – tous deux représentant le
paradigme d'échange de données/d'informations, puis à la coopération au niveau des applications
(par exemple, services Web). Toutes ces solutions sont axées sur l'interopérabilité des systèmes
de technologies de l'information et de la communication (TIC) qui utilisent les terminologies et
les ontologies TIC pour représenter des données, des informations, ou même des concepts et des
connaissances, établissant ainsi une distinction entre les trois niveaux d'interopérabilité: a) primaire,
b) structurel et c) sémantique.
Dans la transition vers les soins de santé numérique, les systèmes TIC deviennent plus étroitement
intégrés dans les processus métier réels. Cette transition nécessite de promouvoir une interopérabilité
de pointe au niveau des connaissances et axée sur les processus métier entre tous les acteurs clés de
ces écosystèmes, tels que les personnes, les organismes, les dispositifs, les applications, les composants
ou les objets afin d'atteindre les objectifs métier communs. Étant donné que les connaissances, les
méthodologies et les terminologies des domaines impliqués dans l'analyse de cas et représentées par
les ontologies de ces domaines, mais aussi les contextes, facultés et capacités individuels, sont très
différentes, elles doivent être partagées et adaptées à l'avance ou dynamiquement pendant l'exécution,
pour permettre une coopération adéquate des acteurs et des systèmes en jeu. Une synthèse des
[5]
différents niveaux d'interopérabilité est donnée dans le Tableau 1 .
1) HL7 est une marque déposée de Health Level Seven International. Cette information est donnée par souci de
commodité à l'intention des utilisateurs du présent document et ne saurait constituer un engagement de la part de
l'ISO quant au produit désigné.
2) openEHR est une marque déposée de la Fondation openEHR. Cette information est donnée par souci de
commodité à l'intention des utilisateurs du présent document et ne saurait constituer un engagement de la part de
l'ISO quant au produit désigné.
Tableau 1 — Niveaux d'interopérabilité
Perspective d'information Perspective d'organisation
Niveau
Instances Niveau d'interopérabilité
d'interopérabilité
Technique Prêt à l'emploi technique, compatibilité Interactions légères
signal et protocole
Structurel EDI simple, enveloppes Partage de données
Syntaxique Messages et documents cliniques avec Partage d'informations
vocabulaire convenu
Sémantique Messagerie de pointe avec modèles Partage des connaissances au niveau
d'informations et terminologies communs du concept TI sous forme analysable
informatiquement
Coordination
Organisation/ Processus métier commun Partage des connaissances au niveau du
Service concept métier
Coopération convenue au niveau des
fonctions de service
Basé sur les Processus multi-domaines Partage des connaissances au niveau du
connaissances domaine
Coopération inter-domaines
Basé sur les Engagement individuel dans des domaines Partage des connaissances dans un
compétences multiples contexte individuel
Collaboration dirigée entre utilisateurs
finaux
0.3  Motivation de l'Architecture de référence d'interopérabilité et d'intégration
Répondre aux objectifs d'amélioration de la sécurité, de la qualité et de l'efficacité des soins au moyen
des TIC exige une interopérabilité avancée entre les systèmes informatiques allant dans le sens
d'une coopération spécifique aux processus métier des acteurs représentant les différents domaines
participant au dossier de décision. À cette fin, il est nécessaire que la connaissance du domaine concerné,
mais également le contexte individuel et partagé (langue, éducation, compétences, expérience, aspects
psychologiques, sociaux professionnels et environnementaux, etc.), soient représentés correctement et
de manière formelle pour être intégrés dans le système de TIC dans le cadre d'un système professionnel.
Étant donné que les experts de différents domaines impliqués décrivent les aspects spécifiques de
ce système professionnel dans leurs propres contextes spécifiques, utilisant leurs terminologies,
ontologies, méthodologies et cadres conceptuels spécifiques, les représentations d'informations
qui en résultent sont souvent relativement incohérentes, ce qui exige un processus d'adaptation
de l'interopérabilité de poste à poste. L'adaptation de représentations d'informations normalisées
existantes pour des cas d'utilisation spécifiques à des domaines, à des contextes changeants ou incluant
de multiples domaines exige une autre représentation d'informations harmonisée commune, ce qui
entraîne des révisions permanentes des spécifications.
Les systèmes de modélisation pour une interopérabilité multi-domaine nécessitent de passer de
la perspective des connaissances en matière de modèle de données, de modèle d'information et du
[6]
domaine des TIC à la perspective des connaissances des domaines d'activité . À cette fin, les parties
prenantes concernées doivent définir la vue fournie du modèle, ainsi que la manière de structurer et de
nommer les concepts de l'espace de problème. En capturant au préalable les concepts clés et les relations
clés à un niveau d'abstraction élevé, il est possible d'utiliser différents niveaux d'abstraction de façon
itérative. Ainsi, la première itération est effectuée de manière descendante pour garantir l'intégrité
conceptuelle du modèle. Cela nécessite de respecter des principes de conception tels que l'orthogonalité,
[7] [8]
la généralité, la parcimonie et la propriété . L'ISO 30401 définit les exigences relatives aux systèmes
de management des connaissances dans les organismes afin de répondre aux objectifs métier.
Il est impossible de représenter le système de soins de santé hautement complexe et dynamique,
pluridisciplinaire et multi-domaine au moyen de la terminologie/ontologie d'un seul domaine ou, pire
vi © ISO 2021 – Tous droits réservés

encore, pour les raisons mentionnées ci-dessus, en utilisant exclusivement des ontologies des TIC et des
styles de représentation spécifiques.
Une variante est une représentation abstraite, indépendante du domaine, des systèmes utilisant
[9]
la théorie universelle des types et les logiques correspondantes. La représentation du concept
mathématique à l'aide d'une Architecture de méta-référence suivant la théorie formelle du Cube de
[9]
Barendregt avec Paramètres combinée à des méthodologies d'ingénierie des systèmes permet de
représenter l'architecture de tout système (c'est-à-dire les composants du système, leurs fonctions et
leurs relations internes comme externes) par le biais de la description générique de sa composition/
décomposition et de son comportement du point de vue de tous les domaines pertinents dans un
dossier de décision. Une troisième dimension décrit le processus de développement du système, comme
l'évolution pour les systèmes vivants, la fabrication pour les systèmes techniques, ou un processus de
développement de logiciel, donnant un modèle de système générique ou une Architecture de référence
générique illustrée à la Figure 1. Les détails concernant les dimensions du modèle sont expliqués à
l'Article 5 et à l'Article 6.
Figure 1 — Modèle d'architecture de référence générique
Pour représenter les paramètres avancés d'interopérabilité et d'intégration, différentes représentations
spécifiques à un domaine sont associées au même composant réel. En conséquence, une architecture de
référence abstraite et générique capable de représenter tout aspect ou domaine présentant un intérêt est
nécessaire. Afin de représenter de façon formelle et correcte les concepts et relations des sous-systèmes
propres à un domaine impliqués dans ce dossier de décision, ces sous-systèmes sont représentés par
leurs ontologies de domaine approuvées correspondantes, débouchant sur une approche du système
[10][11]
théorique, centrée sur l'architecture et contrôlée par des ontologies de niveau supérieur . Les
exigences relatives aux ontologies de niveau supérieur sont spécifiées dans l'ISO 21838 (toutes les
3)
parties). les ontologies du domaine de santé sont CT SNOMED® ou des ontologies spécifiques comme
[12] [13]
les Open Biomedical Ontologies (OBO) , y compris Gene Ontology, maintenues par OBO Foundry .
Vu que nous ne pouvons modéliser et calculer que des systèmes raisonnablement complexes, le modèle
d'architecture de référence générique (Figure 1) peut être utilisé de manière récursive à différents
niveaux de granularité, représentant ainsi, par exemple, la continuité de systèmes réels, depuis les
particules élémentaires jusqu'à l'univers. Les concepts des composants du système et leurs relations
sont représentés par des expressions appropriées dans les langues naturelles ou formelles jusqu'au
niveau de base des primitives. L'analyse ou la conception du système doit prendre en compte les
systèmes partiels lorsque sont envisagés les niveaux de granularité supérieurs du système en question.
3) CT SNOMED est une marque déposée de l'International Health Terminology Standards Development Organisation
(IHTSDO). Cette information est donnée par souci de commodité à l'intention des utilisateurs du présent document
et ne saurait constituer un engagement de la part de l'ISO quant au produit désigné.
0.4  Approche technique
Un système est une composition de composants interdépendants ordonnés de façon à accomplir une
fonction ou un ensemble de fonctions spécifiques. Les systèmes peuvent être décomposés en sous-
systèmes ou regroupés pour former des super-systèmes. Les systèmes ont des aspects constructifs ou
[14]
structurels et comportementaux ou fonctionnels. Suivant l'IEEE 1471 , l'architecture d'un système
est l'organisation fondamentale de ce système telle qu'elle est concrétisée par ses composants, leurs
relations entre eux et avec l'environnement, et par les principes qui orientent sa conception et son
évolution. Les règles de sélection et de restriction des composants et des fonctions, ainsi que des
relations conformément à un dossier de décision sont appelées des politiques. Les politiques définissent
le comportement attendu d'un système. Dans le cas des systèmes vivants, des facteurs comme
l'homéostasie, avec les attributs d'auto-organisation et d'autorégulation, ainsi que de croissance
et de développement, de reproduction, avec l'hérédité (préservation des structures) et la mutation
(changements de structure) associées, et un développement supérieur par la sélection des variantes
les plus adaptées parmi beaucoup d'autres, rendent la description de systèmes vivants plus compliquée
[15]
que celle de systèmes techniques .
Dans les années 70 et 80, une démarche d'interopérabilité au niveau des données a été développée en
définissant le format EDI (electronic data interchange, échange de données électroniques) d'échange de
données standard, indépendant des applications et des technologies, afin de transformer des formats de
données propriétaires en format de données standard et vice versa. C'est pour cela qu'ont été élaborées
[16]
des Normes internationales telles que l'ISO 9735 (EDIFACT) , ou son pendant spécifique aux soins
[17]
de santé, l'ISO/HL7 27931:2009 , un protocole d'application pour l'échange de données électroniques
dans les environnements de soins. Le présent document définit une architecture générique de système
pour l'interopérabilité des niveaux de connaissance. Cette architecture permet de transformer et
d'interrelier de façon cohérente la structure et le comportement de tout sous-système spécifique à un
domaine (par exemple, les normes et spécifications propres à un domaine) en représentant de façon
ontologique ses concepts et ses relations au niveau de granularité du composant système réel dans
le système de composants génériques abstraits. En d'autres termes, le sous-système spécifique au
domaine (par exemple, une norme ou une spécification propre au domaine) est réorganisé au moyen de
l'Architecture de référence d'interopérabilité et d'intégration, produisant ainsi une interface normalisée
avec cette spécification. Ainsi, la méthodologie proposée dans le présent document établit une
correspondance entre les systèmes spécifiques à un domaine ou propriétaires et leur représentation
sous forme de spécification ou de norme spécifique à un domaine en les transformant en architecture
de système standard et vice versa. L'Annexe A démontre l'intégration de deux normes spécifiques à un
[18]
domaine en réorganisant l'ISO 13606-1 Modèle de Référence et la norme HL7® Composite Security
[19]
and Privacy Domain Analysis Model et en les combinant dans une instance de modèle d'Architecture
de référence d'interopérabilité et d'intégration. L'Annexe B démontre l'intégration de différentes normes
4)
de communication en réorganisant la méthodologie HL7 v3® et en créant une méthodologie adéquate
4)
HL7 v2® , et en les transformant en une instance d'Architecture de référence d'interopérabilité et
d'intégration. Ainsi, l'Architecture de référence d'interopérabilité et d'intégration prend en charge la
transformation mutuelle de ces normes de communications pour assurer l'interopérabilité des solutions
[20]
existantes. La Communication Standards Ontology (CSO) a été utilisée pour la représentation
ontologique des modèles. La démarche d'interopérabilité de cette norme est présentée à la Figure 2.
[21]
L'Annexe C démontre l'intégration de différentes normes d'après l'ISO 12967 (toutes les parties) ,
5) [22]
alors que l'Annexe D présente la démarche dans le contexte de l'ISO 13972 . Enfin, l'Annexe E
démontre la mise en œuvre de l'Architecture de référence d'interopérabilité et d'intégration du présent
document pour la représentation et l'harmonisation des architecture de référence alternatives.
4) HL7 v3 et HL7 v2 sont des marques déposées de Health Level Seven International. Cette information est donnée
par souci de commodité à l'intention des utilisateurs du présent document et ne saurait constituer un engagement
de la part de l'ISO quant au produit désigné.
5) En cours d'élaboration. Stade au moment de la publication: ISO/DIS 13972:2020.
viii © ISO 2021 – Tous droits réservés

Figure 2 — Vue d'ensemble de la démarche d'interopérabilité du présent document
Il est nécessaire que les relations interdomaines, liées au cadre GCM, se produisent au même niveau de
[23]
détails . Pour cela, des spécialisations/généralisations intradomaines sont effectuées.
NORME INTERNATIONALE ISO 23903:2021(F)
Informatique de santé — Architecture de référence
d'interopérabilité et d'intégration — Modèle et cadre
1 Domaine d'application
Le présent document permet de faire progresser l'interopérabilité depuis le paradigme d'échange de
données/d'informations vers le partage des connaissances à un niveau d'abstraction de moins en moins
élevé, en commençant au niveau des concepts TI (coordination sémantique) en passant par le niveau
des concepts de domaine d'activité (coopération convenue au niveau des fonctions de service), le niveau
du domaine (coopération inter-domaines) jusqu'au contexte individuel (collaboration entre utilisateurs
finaux fondée sur les compétences). Le présent document définit un modèle et un cadre pour une
représentation harmonisée de systèmes existants ou prévus, portant plus particulièrement sur les
systèmes professionnels pris en charge par les technologies de l'information et de la communication.
L'architecture de référence d'interopérabilité et d'intégration prend en charge l'harmonisation
ontologique ou l'harmonisation des connaissances afin de permettre l'interopérabilité entre, et
l'intégration des, systèmes, normes et solutions à tout niveau de complexité sans exiger d'adapter
ou réviser en continu ces spécifications. Cette démarche peut être utilisée pour analyser, concevoir,
intégrer et faire fonctionner tout type de systèmes. Pour arriver à une interopérabilité avancée, il est
nécessaire que des écosystèmes de santé et sociaux flexibles, évolutifs, contrôlés par les activités,
adaptables, basés sur les connaissances et intelligents suivent une démarche orientée systèmes, centrée
sur l'architecture, basée sur l'ontologie et dictée par une politique.
Les langages utilisés pour représenter les différentes vues des systèmes, comme les langages d'ontologie
[24] [25]
tels que Common Logic (CL) (ISO/IEC 24707 ) et Web Ontology Language (OWL) – spécifiquement
[26] 6)
OWL 2 (World Wide Web Consortium, W3C® ), les langages de modélisation et d'intégration de
7)
processus professionnels tels que Business Process Modeling Language (BPML) (OMG® ), mais
[27]
également Unified Modeling Language d'OMG (UML, également spécifié comme l'ISO/IEC 19505 )
basés sur les styles de représentation pour les différentes vues de l' ISO/IEC 10746 (toutes les parties)
ne relèvent pas du domaine d'application du présent document.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences 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/IEC 10746 (toutes les parties), Technologies de l’information — Traitement réparti ouvert — Modèle
de référence: Architecture
ISO 22600 (toutes les parties), Informatique de santé — Gestion de privilèges et contrôle d’accès
ISO/IEC 21838 (toutes les parties), Information technology — Top-level ontologies (TLO)
OMG Ontology Definition Metamodel V1.1
6) W3C est une marque déposée du World Wide Web Consortium. Cette information est donnée par souci de
commodité à l'intention des utilisateurs du présent document et ne saurait constituer un engagement de la part de
l'ISO quant au produit désigné.
7) OMG est une marque déposée de l'OMG (Object Management Group®). Cette information est donnée par souci
de commodité à l'intention des utilisateurs du présent document et ne saurait constituer un engagement de la part
de l'ISO quant au produit désigné.
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse http:// www .electropedia .org/
3.1
architecture
ensemble de règles destinées à définir la structure des systèmes (3.25), et les relations entre leurs
différentes parties
[SOURCE: ISO/IEC 10746-2:2009, 6.6, modifiée — «(d'un système)» n'est plus associé au terme.]
3.2
axiome
énoncé considéré comme vrai, servant de prémisse à un raisonnement plus approfondi
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.9, modifiée — La Note à l'article a été remplacée.]
3.3
point de vue entreprise
point de vue (3.28) qui porte sur l'objectif, le domaine d'application et les politiques qui régissent les
activités de l'écosystème (3.10) spécifié
3.4
classe
type
entité (3.11) générale
8)
[SOURCE: ISO/IEC/PRF 21838-1:— , 3.2, modifiée — «type»ajouté comme deuxième terme préférentiel
et Note à l'article supprimée.]
3.5
collection
groupe d'éléments (3.19)
9)
[SOURCE: ISO/IEC/PRF 21838-2:— , 3.4, modifiée — Notes à l'article supprimées.]
3.6
concept
unité de connaissance créée par une combinaison unique de caractéristiques
Note 1 à l'article: Les concepts ne sont pas nécessairement liés à des langues naturelles particulières. Ils sont
cependant soumis à l'influence du contexte socioculturel qui conduit souvent à des catégorisations différentes.
Note 2 à l'article: En tant que composante de connaissance, un concept peut être spécialisé et généralisé tout
comme les composantes elles-mêmes.
[SOURCE: ISO 1087:2019, 3.2.7, modifiée— Note 2 à l'article remplacée.]
8) En cours d'élaboration. Stade au moment de la publication: ISO/IEC/PRF 21838-1:2020.
9) En cours d'élaboration. Stade au moment de la publication: ISO/IEC/PRF 21838-2.2:2020.
2 © ISO 2021 – Tous droits réservés

3.7
définition
représentation d'un concept par un énoncé descriptif permettant de le différencier des concepts
associés
[SOURCE: ISO 1087:2019, 3.3.1]
3.8
domaine
collection (3.5) d'entités (3.11) présentant un intérêt pour une certaine communauté ou discipline
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.17, modifiée — Exemple et Note à l'article supprimés.]
3.9
ontologie de domaine
ontologie (3.18) dont les termes (3.26) représentent des classes ou types (3.4) et, éventuellement,
certains éléments (3.19) (appelés «individus distingués») dans un certain domaine (3.8)
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.18]
3.10
écosystème
systèmes (3.25) et communautés structurés régis par des règles générales
3.11
entité
objet
tout ce qui peut être perçu ou conçu
Note 1 à l'article: Les termes «entité» et «objet» sont des termes fourre-tout analogues à «quelque chose». Dans
les cercles terminologiques, «objet» est couramment utilisé de cette manière. Dans les cercles ontologiques, les
termes «entité» et «chose» sont couramment utilisés.
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.1]
3.12
expression
mot ou groupe de mots ou symboles correspondants permettant de formuler une déclaration
Note 1 à l'article: Les expressions sont divisées en expressions en langage naturel et en expressions dans un
langage formel.
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.5]
3.13
langage formel
langage qui peut être lu par une machine et a une sémantique clairement définie
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.10, modifiée — Note supprimée.]
3.14
théorie formelle
collection (3.5) de définitions (3.7) et d'axiomes (3.2) exprimés dans un langage formel (3.13)
[SOURCE: ISO/IEC/PRF 21838-1: —, 3.11, modifiée — Note supprimée.]
3.15
instance
élément (3.19) qui instancie un universel (3.27)
[SOURCE: ISO/IEC/PRF 21838-2:—, 3.6, modifiée — Exemple supprimé.]
3.16
interopérabilité
capacité d'un système (3.25) ou d'un produit à travailler avec d'autres systèmes (3.25) ou produits sans
effort particulier de la part du client
Note 1 à l'article: Selon l'interprétation TIC traditionnelle, l'interopérabilité est la capacité de deux systèmes ou
[29]
composants ou plus à échanger des informations et à utiliser les informations qui ont été échangées .
[SOURCE: Glossaire des normes de l'IEEE]
3.17
modèle
conception univoque et abstraite de certaines parties ou certains aspects du monde réel correspondant
aux buts de modélisation
Note 1 à l'article: Les parties prenantes concernées définissent la vue fournie du modèle, ainsi que la manière
de structurer et de nommer les concepts de l'espace de problème. En capturant au préalable les concepts clés et
les relations clés à un niveau d'abstraction élevé, il convient que différents niveaux d'abstraction soient utilisés
de façon itérative, la première itération étant effectuée de manière descendante de façon à garantir l'intégrité
conceptuelle du modèle. Cela nécessite de respecter des principes de conception tels que l'orthogonalité, la
[30]
généralité, la parcimonie et la propriété .
3.18
ontologie
collection (3.5) de termes (3.26), expressions relationnelles (3.24) et de leurs définitions (3.7) associées
en langage naturel, ainsi que d'une ou plusieurs théories formelles (3.14) conçues pour capturer les
interprétations prévues de ces définitions (3.7)
Note 1 à l'article: Une ontologie définit un ensemble de primitives représentationnelles permettant de modéliser
un domaine de connaissances ou de discours. Les primitives représentationnelles sont généralement des classes
(ou des ensembles), des attributs (ou des propriétés) et des relations (ou des relations entre les membres de la
classe). Les définitions des primitives représentationnelles comprennent des informations concernant leur
[31]
signification et les contraintes de leur application logiquement cohérente .
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.14, modifiée — Note à l'article remplacée.]
3.19
élément
entité (3.11) individuelle
Note 1 à l'article: Contrairement aux classes ou aux types, les données ne sont pas présentées sous forme
d'exemples ou instanciées par d'autres entités.
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.3]
3.20
politique
ensemble d'obligations légales, politiques, organisationnelles, fonctionnelles et techniques applicable à
une communication et à une coopération
Note 1 à l'article: Les politiques définissent le comportement attendu des systèmes.
[SOURCE: ISO 22600-1:2014, 3.13 modifiée — Note à l'article ajoutée.]
3.21
primitive
expression (3.12) pour laquelle aucune définition (3.7) non circulaire ne peut être fournie
[SOURCE: ISO/IEC/PRF 21838-2:—, 3.1]
3.22
architecture de référence
modèle de référence pour une classe (3.4) d'architectures (3.1)
4 © ISO 2021 – Tous droits réservés

3.23
relation
manière de laquelle les entités (3.11) sont reliées
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.4, modifiée — Notes à l'article supprimées.]
3.24
expression relationnelle
expression (3.12) permettant d'affirmer qu'une relation (3.22) existe
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.6, modifiée — Exemple et notes supprimés.]
3.25
système
combinaison d'éléments agissant ensemble, organisés de façon à atteindre un ou plusieurs buts définis
Note 1 à l'article: Un système regroupe des composants (éléments) reliés entre eux structurellement et/ou
fonctionnellement. Les systèmes peuvent être composés (agrégés/généralisés) en super-systèmes ou décomposés
(spécialisés) en sous-systèmes.
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.46, modifiée — Note 1 à l'article remplacée, notes 2 et 3
supprimées.]
3.26
terme
expression (3.12) faisant référence à une classe (3.4) ou un élément (3.19) quelconque
[SOURCE: ISO/IEC/PRF 21838-1:—, 3.7, modifiée — La Note à l'article a été remplacée.]
3.27
universel
type
entité (3.11) qui a un nombre indéfini d'instances (3.15)
[SOURCE: ISO/IEC/PRF 21838-2:—, 3.2, modifiée — Exemple et Note à l'article supprimés.]
3.28
point de vue
forme d'abstraction obtenue en utilisant un ensemble choisi de concepts architecturaux et de règles de
structuration, permettant de se concentrer sur des préoccupations particulières au sein d'un système
[SOURCE: ISO/IEC 10746-2:2009, 3.2.7, modifiée— «(d'un système)» n'est plus associé au terme.]
4 Abréviations
DIS Dossier informatisé de santé
HL7® Organisme de normalisation des échanges informatiques dans le domaine de la santé
(Health Level Seven®)
UML Langage de modélisation unifié (Unified Modelling Language)
RM-ODP Modèle de référence du traitement réparti ouvert (Reference Model of Open Distributed
Processing)
5 Vue d'ensemble de l'architecture de système standard
Compte tenu des différentes perspectives sur un système professionnel et son contexte individuel
et partagé fournies par différentes disciplines ou domaines impliqués dans le dossier de décision, le
système professionnel est composé de sous-systèmes représentés par les perspectives spécifiques à
un domaine basées sur les méthodologies, les terminologies et les ontologies spécifiques à un domaine.
Comme exemple de ces sous-systèmes, on peut citer les soins médicaux, l'administration, les affaires
juridiques et réglementaires, la sécurité, la protection de la vie privée, la formation, etc. Comme tout
système, les domaines peuvent être composés (agrégés) en super-domaines ou décomposés en sous-
domaines. Pour relier correctement et de façon cohérente les composants de ces sous-systèmes entre
eux de manière à permettre au comportement attendu du système de remplir les objectifs d'activité
spécifiques aux cas d'utilisation, une architecture de système abstraite, indépendante du domaine, avec
des composants système génériques à différents niveaux de granularité, doit être définie, permettant la
composition/décomposition de tout système fondamental. Si le système générique, avec ses composants
et ses relations génériques, est représenté à l'aide d'une ontologie de niveau supérieur de domaine
neutre [voir l'ISO/IEC 21838 (toutes les parties)], le système professionnel et les systèmes instanciés
spécifiques aux cas d'utilisation abordés ci-dessous sont représentés à l'aide d'ontologies de domaine à un
niveau inférieur. Au premier niveau de granularité, les sous-systèmes spécifiques à un domaine (Niveau
de concepts métier) sont spécialisés en sous-systèmes représentant les perspectives de disciplines
ou sous-domaines spécialisés au sein d'un domaine, déployant leurs méthodologies, terminologies et
ontologies spécialisées (Niveau de réseaux de relations). Parmi les exemples de ces sous-domaines
dans le domaine clinique, on peut citer la microbiologie, la pathologie, la cardiologie, l'ophtalmologie,
etc. Ces sous-domaines sont à leur tour spécialisés en services (Niveau de regroupements) et tâches
(Niveau de détails) spécifiques à des sous-domaines et cas d'utilisation. Les composants architecturaux
et leurs relations sont représentés au moyen des ontologies correspondantes de domaine ou sous-
domaine respectivement. Ainsi, il est possible d'interrelier les services et les tâches d'un domaine à
l'autre en mettant en relation les composants correspondants et en établissant une cartographie de
leurs concepts, héritant ainsi des spécialisations/généralisation connexes au sein des domaines/sous-
domaines. Pour représenter les politiques du système professionnel, l'ISO 22600 (toutes les parties), qui
[32] [33]
est la normalisation de l'ontologie des politiques de PONDER , doit être utilisée . Pour la gestion
et l'harmonisation de différentes ontologies représentées à l'aide de différents styles et langages de
10)
représentation, l'Ontology Definition Metamodel (ODM™) , V1.1 de l'OMG doit être mise en œuvre.
En utilisant la théorie des systèmes, et particulièrement sa démarche structurelle, le GRA (voir
[14]
0.3) adopte, mais va au-delà de la norme IEEE 1471:2000 , qui a été ensuite remplacée par
[34]
l'ISO/IEC/IEEE 42010:2011 . N'étant pas limitée aux systèmes TIC, une vue de système professionnel
réel multi-domaine a été ajoutée, transformant l'IEEE 1471, ISO/IEC/IEEE 42010 ainsi que la norme de
développement de logiciel ISO/IEC 10746 (toutes les parties) en une démarche tridimensionnelle. Cette
vue de système professionnel réel représente de manière formelle les espaces de connaissances des
domaines, permettant ainsi une sélection correcte et rigoureuse des composants, de leurs fonctions
et de leurs relations, et favorisant ainsi une interopérabilité et une intégration des systèmes correctes
au niveau des connaissances. C'est seulement de ce point de vue que la justesse et la cohérence des
concepts représentés dans les spécifications et les normes TIC peuvent être justifiées.
6 Architecture de référence d'interopérabilité et d'intégration pour les systèmes
pris en charge par les technologies de l'information et de la communication
6.1 Domaines et niveaux de granularité de l'Architecture de référence
d'interopérabilité et d'intégration
En adoptant la philosophie de l'ISO/IEC 10746 (toutes les parties), le présent document comble
une lacune en matière d'interopérabilité réelle en étendant les points de vue définis dans
l'ISO/IEC 10746-1:1998 avec une vue métier indépendante des TIC. Elle correspond ainsi à la démarche
de l'OMG® pour la représentation, la gestion, l'interopérabilité et l'application de la sémantique métier.
Cette dernière permet une représentation, un échange et une harmonisation formels des connaissances
multi-domaines en fournissant des relations entre les symboles de l' «univers» logique et les individus
du «monde réel». La Figure 3 présente le point de vue entreprise de l'Architecture de référence
d'interopérabilité et d'intégration avec son domaine et sa dimension de composition/décomposition.
10) ODM est une marque déposée de l'OMG (Object Management Group®). Cette information est donnée par souci
de commodité à l'intention des utilisateurs du présent document et ne saurait constituer un engagement de la part
de l'ISO quant au produit désigné.
6 © ISO 2021 – Tous droits réservés

Figure 3 — Domaines et niveaux de granularité de l'Architecture de référence
d'interopérabilité et d'intégration
6.2 Modèle d'Architecture de référence d'interopérabilité et d'intégration pour
les systèmes pris en charge par les technologies de l'information et de la communication
En combinant ce modèle avec l'ISO/IEC 10746 (toutes les parties) et ses points de vue et moyens de
représentation, le processus de développement, de mise en œuvre et de maintenance des écosystèmes
interopérables de soins de santé et sociaux est ajouté à la démarche, complétant l'Architecture de
référence d'interopérabilité et d'intégration avec ses domaines de systèmes tridimensionnels, la
composition de composants système, et les points de vue de système d'après RM-ODP (Figure 4).
Figure 4 — Modèle d'Architecture de référence d'interopérabilité et d'intégration
Au vu de la représentation formelle, correcte et cohérente des systèmes professionnels spécifiques a
...

Style Definition: Heading 1: English (United Kingdom),
2021-03-16
Indent: Left: 0 cm, First line: 0 cm
Style Definition: Heading 2: Font: Bold, English (United
Kingdom), Line spacing: At least 12.5 pt, Keep lines together,
ISO/TC 215
Tab stops: 0.96 cm, Left + 1.25 cm, Left + Not at 0.63 cm +
0.95 cm + 1.23 cm
Date :
Style Definition: Heading 3: Font: Bold, English (United
Kingdom), Line spacing: At least 11.5 pt, Keep lines together,
Tab stops: 1.55 cm, Left + Not at 1.55 cm
Style Definition: Heading 4;h4: Font: Bold, English (United
Kingdom), Space Before: 10 pt, Line spacing: At least 11.5 pt,
ISO/TC 215
Keep lines together, Tab stops: 1.65 cm, Left + 2.01 cm, Left
+ Not at 1.66 cm + 2.01 cm + 2.4 cm
Secrétariat : ANSI Style Definition: Heading 5;h5: Font: Bold, English (United
Kingdom), Space Before: 10 pt, Line spacing: At least 11.5 pt,
Keep lines together, Tab stops: 2.01 cm, Left + 2.39 cm, Left
Informatique de santé — Architecture de référence d'interopérabilité et
Style Definition: Heading 6;h6: Font: Bold, English (United
d'intégration — Modèle et cadre
Kingdom), Space Before: 10 pt, Line spacing: At least 11.5 pt,
Keep lines together
Health informatics — Interoperability and integration reference architecture – Model and
Style Definition: Base_Text: Tab stops: Not at 0.7 cm + 1.4
cm + 2.1 cm + 2.8 cm + 3.5 cm + 4.2 cm + 4.9 cm + 5.6
framework
cm + 6.3 cm + 7 cm
Style Definition: a2: English (United Kingdom), Tab stops:
ICS : 35.240.80
Not at 1.27 cm
Style Definition: Body Text_Center
Style Definition: Dimension_100
Style Definition: Figure Graphic
Style Definition: Figure subtitle
Style Definition: List Continue 1
Style Definition: List Number 1
Style Definition: RefNorm
Style Definition
...
Style Definition
...
Style Definition: Body Text First Indent
Style Definition: Mention non résolue1
Formatted
...
Formatted
...
Formatted
...
Formatted
...
Formatted
...
Formatted: Font: 13 pt, Font color: Auto, Spanish (Spain)
Formatted
...
Formatted: Font: 13 pt, Font color: Auto
Formatted
...
Formatted: Font: 13 pt, Font color: Auto
Formatted: Font: 13 pt, Bold, Font color: Auto
Formatted: Font: 13 pt, Font color: Auto
Formatted
...
Formatted: Font: 13 pt
Formatted
...
Formatted: Font: 13 pt, French (Switzerland)
Formatted: Font: 13 pt, French (Switzerland)
Type du document:  Norme internationale
Sous-type du document:
Stade du document:  (60) Publication
Langue du document:  F
Formatted: Space After: 18 pt
Formatted: Font: 10 pt
Formatted: French (Switzerland)
Type du document:  Norme internationale
Sous-type du document:
Stade du document:  (60) Publication
Langue du document:  F
Formatted: Font: 11 pt, French (France)
DOCUMENT PROTÉGÉ PAR COPYRIGHT
Formatted: Left: 1.9 cm, Right: 1.9 cm, Bottom: 1 cm,
Gutter: 0 cm
Formatted: Don't adjust space between Latin and Asian text,
Don't adjust space between Asian text and numbers, Tab
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en
stops: 16.97 cm, Left
œuvre, aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque forme
Formatted: Font: Cambria, 11 pt, French (France)
que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage
Formatted: Font: 11 pt, French (France)
sur l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation
peuvent être adressées à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du
Formatted: Don't adjust space between Latin and Asian text,
Don't adjust space between Asian text and numbers
demandeur.
Formatted: std_publisher, Font: 11 pt, French (France)
ISO copyright office
Formatted: Font: 11 pt, French (France)
Formatted: std_docNumber, Font: 11 pt, French (France)
CP 401 •• Ch. de Blandonnet 8
Formatted: Font: 11 pt, French (France)
Formatted: Space After: 12 pt, Don't adjust space between
CH-1214 Vernier, Genève
Latin and Asian text, Don't adjust space between Asian text and
numbers
Tél. :.: + 41 22 749 01 11
Formatted: Font: 11 pt, French (France)
Formatted: Font: 11 pt, French (France)
Fax : + 41 22 749 09 47
Formatted: Font: 11 pt, French (France)
E-mail : [e-mail]
Formatted: Font: 11 pt, French (France)
Web : www.iso.org Formatted: Font: 11 pt, French (France)

Field Code Changed
Formatted: French (France)
Formatted: French (France)
Publié en Suisse
Formatted: Font: 11 pt, French (France)
Formatted: Justified, Don't adjust space between Latin and
Asian text, Don't adjust space between Asian text and numbers
Formatted: Font: Bold
Formatted: Space After: 0 pt
ii
Formatted: Font: 11 pt
Sommaire Page
Formatted: Font: 11 pt
Formatted: French (France)
Avant-propos . iv
Formatted: Don't adjust space between Latin and Asian text,
Introduction. v
Don't adjust space between Asian text and numbers
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Abréviations . 5
5 Vue d'ensemble de l'architecture de système standard . 5
6 Architecture de référence d'interopérabilité et d'intégration pour les systèmes pris
en charge par les technologies de l'information et de la communication . 6
6.1 Domaines et niveaux de granularité de l'Architecture de référence
d'interopérabilité et d'intégration . 6
6.2 Modèle d'Architecture de référence d'interopérabilité et d'intégration pour les
systèmes pris en charge par les technologies de l'information et de la
communication . 7
6.3 Cadre de l'Architecture de référence d'interopérabilité et d'intégration . 9
6.3.1 Exigences de base . 9
6.3.2 Gestion des relations dans l'Architecture de référence d'interopérabilité et
d'intégration. 9
6.3.3 Modélisation du processus métier à l'aide de l'Architecture de référence
d'interopérabilité et d'intégration . 11
Annexe A (informative) Interopérabilité inter-domaines pour une communication du
Dossier informatisé de santé (DIS) respectueuse de la sécurité et de la vie privée . 14
Annexe B (informative) Interopérabilité entre différentes normes de communications . 18
Annexe C (informative) Intégration des normes dans l'ISO 12967 (toutes les parties) . 20
Annexe D (informative) Déploiement de l'approche d'Architecture de référence
d'interopérabilité et d'intégration dans l'ISO 13972 . 25
Annexe E (Informative) Déploiement de l'approche d'Architecture de référence
d'interopérabilité et d'intégration pour la représentation et l'harmonisation des
architectures de référence alternatives . 27
Bibliographie . 30
Formatted: French (France)
Formatted: Font: Bold
Formatted: Space After: 0 pt
iii
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes Formatted: French (Switzerland)
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 (IEC) en ce qui concerne la
normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier, de prendre note des différents Formatted: French (Switzerland)
critères d'approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2
Formatted: Underline, Font color: Blue
(voir www.iso.org/directives).
Formatted: Underline, Font color: Blue
L'attention est attirée sur le fait que certains des éléments du présent document peuvent faire l'objet de
Formatted: French (Switzerland)
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. Les détails concernant les
références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de l'élaboration
du document sont indiqués dans l'Introduction et/ou dans la liste des déclarations de brevets reçues par
l'ISO (voir www.iso.org/brevets). Formatted: Underline, Font color: Blue
Formatted: Underline, Font color: Blue
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
Formatted: French (Switzerland)
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions Formatted: Adjust space between Latin and Asian text, Adjust
space between Asian text and numbers
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion
de l'ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir le lien suivant : www.iso.org/iso/fr/avant-propos. Formatted: Underline, Font color: Blue
Formatted: Underline, Font color: Blue
Le présent document a été élaboré par le comité technique ISO/TC 215, Informatique de santé, en
Formatted: Underline, Font color: Blue
collaboration avec le Comité Technique comité technique CEN/TC 251, Informatique de santé, du Comité
Formatted: French (Switzerland)
européen de normalisation (CEN),) conformément à l'Accordl’Accord de coopération technique entre
Formatted: Font: Italic
l'ISOl’ISO et le CEN (Accord de Vienne).
Formatted: Font: Italic
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
Formatted: Font: Italic
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
Formatted: French (Switzerland)
se trouve à l’adresse www.iso.org/fr/members.html.
Formatted: Underline, Font color: Blue, French (Switzerland),
Pattern: Clear
Formatted: Emphasis, Font color: Black, French (Switzerland)
Formatted: Font: Bold
Formatted: Space After: 0 pt
iv
Introduction
0.1  Préface
Le présent document accompagne l'intégration a) de spécifications de différents domaines, avec leurs
méthodologies, terminologies et ontologies spécifiques, y compris les règles de rédaction propres aux
spécifications, ainsi que b) de systèmes basés sur ces spécifications. En permettant une identification
spécifique aux cas d'utilisation, ainsi qu'une représentation cohérente et formelle, y compris les
contraintes de composants nécessaires avec leurs concepts spécifiques et leurs relations, le présent
document facilite le déploiement de normes et de systèmes existants, l'analyse et l'amélioration des
spécifications en cours de révision, ainsi que la conception de nouveaux projets.
Le présent document offre une vue d'ensemble de l'Architecture de référence d'interopérabilité et
[1][2]
d'intégration (introduite dans les années 90 sous le nom de Modèle de Composant Générique – GCM ),
en donnant le domaine d'application, la justification et l'explication des concepts clés ainsi que le modèle
et le cadre qui en découlent. Elle explique la façon d'interpréter cette Architecture de référence
d'interopérabilité et d'intégration et la manière dont elle peut être utilisée, en particulier, par les auteurs
de normes et les architectes de systèmes interopérables, mais aussi par les intégrateurs de systèmes.
Les changements radicaux actuellement en cours concernant l'organisation, la méthodologie et la
technologie dans le domaine des soins de santé et des soins sociaux donnent lieu à une transformation
des systèmes de santé vers une médecine de systèmes P5 (médecine personnalisée, préventive,
prédictive, participative et pertinente) sous la forme d'écosystèmes pleinement répartis, extrêmement
dynamiques, hautement intégrés, pluridisciplinaires (ou multi-domaines) intelligents, qui comprennent
[3]
des systèmes structurés, des communautés régies par des règles, et leurs combinaisons .
0.2  Niveaux d'interopérabilité
L'interopérabilité (voir 3.16) a évolué au cours des 30 dernières années, des messages structurés (par
1 2
exemple EDI, messagerie HL7® ) à des concepts de partage [par exemple archétypes openEHR® ,
[4]
ISO 13940 (système de concepts en appui de la continuité des soins)] – tous deux représentant le
paradigme d'échange de données/d'informations, puis à la coopération au niveau des applications
(par exemple, services Web). Toutes ces solutions sont axées sur l'interopérabilité des systèmes de
technologies de l'information et de la communication (TIC) qui utilisent les terminologies et les
ontologies TIC pour représenter des données, des informations, ou même des concepts et des
connaissances, établissant ainsi une distinction entre les trois niveaux d'interopérabilité : a) primaire, b)
structurel et c) sémantique.
Dans la transition vers les soins de santé numérique, les systèmes TIC deviennent plus étroitement Formatted: Don't keep with next, Don't keep lines together
intégrés dans les processus métier réels. Cette transition nécessite de promouvoir une interopérabilité
de pointe au niveau des connaissances et axée sur les processus métier entre tous les acteurs clés de ces
écosystèmes, tels que les personnes, les organismes, les dispositifs, les applications, les composants ou
les objets afin d'atteindre les objectifs métier communs. Étant donné que les connaissances, les
méthodologies et les terminologies des domaines impliqués dans l'analyse de cas et représentées par les
ontologies de ces domaines, mais aussi les contextes, facultés et capacités individuels, sont très

HL7 est une marque déposée de Health Level Seven International. Cette information est donnée par souci de Formatted: French (Switzerland)
commodité à l'intention des utilisateurs du présent document et ne saurait constituer un engagement de la part de
l'ISO quant au produit désigné.
Formatted: French (Switzerland)
openEHR est une marque déposée de la Fondation openEHR. Cette information est donnée par souci de commodité
Formatted: Font: Bold
à l'intention des utilisateurs du présent document et ne saurait constituer un engagement de la part de l'ISO quant
au produit désigné. Formatted: Space After: 0 pt
v
différentes, elles doivent être partagées et adaptées à l'avance ou dynamiquement pendant l'exécution,
pour permettre une coopération adéquate des acteurs et des systèmes en jeu. Une synthèse des différents
[5]
niveaux d'interopérabilité est donnée dans le Tableau 1 .
Tableau 1 — Niveaux d'interopérabilité Formatted: None, Adjust space between Latin and Asian text,
Adjust space between Asian text and numbers
Perspective d'information Perspective d'organisation
Niveau
Instances Niveau d'interopérabilité
d'interopérabilité
Technique Prêt à l'emploi technique, compatibilité Interactions légères Formatted: Left
signal et protocole
Structurel EDI simple, enveloppes Partage de données
Formatted: Left
Syntaxique Messages et documents cliniques avec Partage d'informations Formatted: Left
vocabulaire convenu
Sémantique Messagerie de pointe avec modèles Partage des connaissances au niveau du
Formatted: Left
d'informations et terminologies communs concept TI sous forme analysable
informatiquement
Coordination
Organisation/ Processus métier commun Partage des connaissances au niveau du Formatted: Left
Service concept métier
Coopération convenue au niveau des
fonctions de service
Basé sur les Processus multi-domaines Partage des connaissances au niveau du
Formatted: Left
connaissances domaine
Coopération inter-domaines
Basé sur les Engagement individuel dans des domaines Partage des connaissances dans un Formatted: Left
compétences multiples contexte individuel
Collaboration dirigée entre utilisateurs
finaux
0.3  Motivation de l'Architecture de référence d'interopérabilité et d'intégration
Répondre aux objectifs d'amélioration de la sécurité, de la qualité et de l'efficacité des soins au moyen Formatted: Don't keep with next, Don't keep lines together
des TIC exige une interopérabilité avancée entre les systèmes informatiques allant dans le sens d'une
coopération spécifique aux processus métier des acteurs représentant les différents domaines
participant au dossier de décision. À cette fin, il est nécessaire que la connaissance du domaine concerné,
mais également le contexte individuel et partagé (langue, éducation, compétences, expérience, aspects
psychologiques, sociaux professionnels et environnementaux, etc.), soient représentés correctement et
de manière formelle pour être intégrés dans le système de TIC dans le cadre d'un système professionnel.
Étant donné que les experts de différents domaines impliqués décrivent les aspects spécifiques de ce
système professionnel dans leurs propres contextes spécifiques, utilisant leurs terminologies, ontologies,
méthodologies et cadres conceptuels spécifiques, les représentations d'informations qui en résultent
sont souvent relativement incohérentes, ce qui exige un processus d'adaptation de l'interopérabilité de
poste à poste. L'adaptation de représentations d'informations normalisées existantes pour des cas
d'utilisation spécifiques à des domaines, à des contextes changeants ou incluant de multiples domaines
exige une autre représentation d'informations harmonisée commune, ce qui entraîne des révisions
permanentes des spécifications.
Formatted: Font: Bold
Formatted: Space After: 0 pt
vi
Les systèmes de modélisation pour une interopérabilité multi-domaine nécessitent de passer de la
perspective des connaissances en matière de modèle de données, de modèle d'information et du domaine
[6]
des TIC à la perspective des connaissances des domaines d'activité . À cette fin, les parties prenantes
concernées doivent définir la vue fournie du modèle, ainsi que la manière de structurer et de nommer les
concepts de l'espace de problème. En capturant au préalable les concepts clés et les relations clés à un
niveau d'abstraction élevé, il est possible d'utiliser différents niveaux d'abstraction de façon itérative.
Ainsi, la première itération est effectuée de manière descendante pour garantir l'intégrité conceptuelle
du modèle. Cela nécessite de respecter des principes de conception tels que l'orthogonalité, la généralité,
[[7]] [8]
la parcimonie et la propriété. . L'ISO 30401 définit les exigences relatives aux systèmes de
management des connaissances dans les organismes afin de répondre aux objectifs métier.
Il est impossible de représenter le système de soins de santé hautement complexe et dynamique,
pluridisciplinaire et multi-domaine au moyen de la terminologie/ontologie d'un seul domaine ou, pire
encore, pour les raisons mentionnées ci-dessus, en utilisant exclusivement des ontologies des TIC et des
styles de représentation spécifiques.
Une variante est une représentation abstraite, indépendante du domaine, des systèmes utilisant la
[9]
théorie universelle des types et les logiques correspondantes. La représentation du concept
mathématique à l'aide d'une Architecture de méta-référence suivant la théorie formelle du Cube de
[9]
Barendregt avec Paramètres combinée à des méthodologies d'ingénierie des systèmes permet de
représenter l'architecture de tout système (c'est-à-dire les composants du système, leurs fonctions et
leurs relations internes comme externes) par le biais de la description générique de sa
composition/décomposition et de son comportement du point de vue de tous les domaines pertinents
dans un dossier de décision. Une troisième dimension décrit le processus de développement du système,
comme l'évolution pour les systèmes vivants, la fabrication pour les systèmes techniques, ou un
processus de développement de logiciel, donnant un modèle de système générique ou une Architecture
de référence générique illustrée à la Figure 1. Les détails concernant les dimensions du modèle sont
expliqués à l'Article 5 et à l'Article 6.

Formatted: Font: Bold
Formatted: Space After: 0 pt
vii
Figure 1 — Modèle d'architecture de référence générique
Pour représenter les paramètres avancés d'interopérabilité et d'intégration, différentes représentations
spécifiques à un domaine sont associées au même composant réel. En conséquence, une architecture de
référence abstraite et générique capable de représenter tout aspect ou domaine présentant un intérêt est
nécessaire. Afin de représenter de façon formelle et correcte les concepts et relations des sous-systèmes
propres à un domaine impliqués dans ce dossier de décision, ces sous-systèmes sont représentés par
leurs ontologies de domaine approuvées correspondantes, débouchant sur une approche du système
[10][11]
théorique, centrée sur l'architecture et contrôlée par des ontologies de niveau supérieur . Les
exigences relatives aux ontologies de niveau supérieur sont spécifiées dans l'ISO 21838 (toutes les
parties). les ontologies du domaine de santé sont CT SNOMED® ou des ontologies spécifiques comme
[12] [13]
les Open Biomedical Ontologies (OBO) , y compris Gene Ontology, maintenues par OBO Foundry .
Vu que nous ne pouvons modéliser et calculer que des systèmes raisonnablement complexes, le modèle
d'architecture de référence générique (Figure 1) peut être utilisé de manière récursive à différents
niveaux de granularité, représentant ainsi, par exemple, la continuité de systèmes réels, depuis les
particules élémentaires jusqu'à l'univers. Les concepts des composants du système et leurs relations sont
représentés par des expressions appropriées dans les langues naturelles ou formelles jusqu'au niveau de
base des primitives. L'analyse ou la conception du système doit prendre en compte les systèmes partiels
lorsque sont envisagés les niveaux de granularité supérieurs du système en question.

Formatted: French (Switzerland)
CT SNOMED est une marque déposée de l'International Health Terminology Standards Development Organisation
Formatted: Font: Bold
(IHTSDO). Cette information est donnée par souci de commodité à l'intention des utilisateurs du présent document
et ne saurait constituer un engagement de la part de l'ISO quant au produit désigné. Formatted: Space After: 0 pt
viii
0.4  Approche technique
Un système est une composition de composants interdépendants ordonnés de façon à accomplir une Formatted: Don't keep with next, Don't keep lines together
fonction ou un ensemble de fonctions spécifiques. Les systèmes peuvent être décomposés en sous-
systèmes ou regroupés pour former des super-systèmes. Les systèmes ont des aspects constructifs ou
[14]
structurels et comportementaux ou fonctionnels. Suivant l'IEEE 1471 , l'architecture d'un système est
l'organisation fondamentale de ce système telle qu'elle est concrétisée par ses composants, leurs
relations entre eux et avec l'environnement, et par les principes qui orientent sa conception et son
évolution. Les règles de sélection et de restriction des composants et des fonctions, ainsi que des relations
conformément à un dossier de décision sont appelées des politiques. Les politiques définissent le
comportement attendu d'un système. Dans le cas des systèmes vivants, des facteurs comme
l'homéostasie, avec les attributs d'auto--organisation et d'autorégulation, ainsi que de croissance et de
développement, de reproduction, avec l'hérédité (préservation des structures) et la mutation
(changements de structure) associées, et un développement supérieur par la sélection des variantes les
plus adaptées parmi beaucoup d'autres, rendent la description de systèmes vivants plus compliquée que
[15]
celle de systèmes techniques .
Dans les années 70 et 80, une démarche d'interopérabilité au niveau des données a été développée en
définissant le format EDI (electronic data interchange, échange de données électroniques) d'échange de
données standard, indépendant des applications et des technologies, afin de transformer des formats de
données propriétaires en format de données standard et vice versa. C'est pour cela qu'ont été élaborées
[16]
des Normes internationales telles que l'ISO 9735 (EDIFACT) , ou son pendant spécifique aux soins de
[17]
santé, l'ISO/HL7 27931:2009 , un protocole d'application pour l'échange de données électroniques Formatted: Default Paragraph Font
dans les environnements de soins. Le présent document définit une architecture générique de système
Formatted: Default Paragraph Font
pour l'interopérabilité des niveaux de connaissance. Cette architecture permet de transformer et
Formatted: Default Paragraph Font
d'interrelier de façon cohérente la structure et le comportement de tout sous-système spécifique à un
domaine (par exemple, les normes et spécifications propres à un domaine) en représentant de façon
ontologique ses concepts et ses relations au niveau de granularité du composant système réel dans le
système de composants génériques abstraits. En d'autres termes, le sous-système spécifique au domaine
(par exemple, une norme ou une spécification propre au domaine) est réorganisé au moyen de
l'Architecture de référence d'interopérabilité et d'intégration, produisant ainsi une interface normalisée
avec cette spécification. Ainsi, la méthodologie proposée dans le présent document établit une
correspondance entre les systèmes spécifiques à un domaine ou propriétaires et leur représentation sous
forme de spécification ou de norme spécifique à un domaine en les transformant en architecture de
système standard et vice versa. L'Annexe A démontre l'intégration de deux normes spécifiques à un
[18]
domaine en réorganisant l'ISO 13606-1 Modèle de Référence et la norme HL7® Composite Security Formatted: Default Paragraph Font
[19]
and Privacy Domain Analysis Model et en les combinant dans une instance de modèle d'Architecture
de référence d'interopérabilité et d'intégration. L'Annexe B démontre l'intégration de différentes normes
de communication en réorganisant la méthodologie HL7 v3® et en créant une méthodologie adéquate
4)
HL7 v2® , et en les transformant en une instance d'Architecture de référence d'interopérabilité et
d'intégration. Ainsi, l'Architecture de référence d'interopérabilité et d'intégration prend en charge la
Formatted: std_docPartNumber
transformation mutuelle de ces normes de communications pour assurer l'interopérabilité des solutions
Formatted: Not Superscript/ Subscript
[20]
existantes. La Communication Standards Ontology (CSO) a été utilisée pour la représentation
Formatted: French (Switzerland)
ontologique des modèles. La démarche d'interopérabilité de cette norme est présentée à la Figure 2.
[21] Formatted: Don't adjust space between Latin and Asian text,
L'Annexe C démontre l'intégration de différentes normes d'après l'ISO 12967 (toutes les parties) , alors
Don't adjust space between Asian text and numbers
5 [22]
que l'Annexe D présente la démarche dans le contexte de l'ISO 13972 . Enfin, l'Annexe E démontre la
Formatted: French (Switzerland)
Formatted: French (Switzerland)

Formatted: French (Switzerland)
HL7 v3 et HL7 v2 sont des marques déposées de Health Level Seven International. Cette information est donnée
Formatted: French (Switzerland)
par souci de commodité à l'intention des utilisateurs du présent document et ne saurait constituer un engagement
Formatted: Font: Bold
de la part de l'ISO quant au produit désigné.
En cours d'élaboration. Stade à la dateau moment de la publication : ISO/DIS 13972:2020. Formatted: Space After: 0 pt
ix
mise en œuvre de l'Architecture de référence d'interopérabilité et d'intégration du présent document
pour la représentation et l'harmonisation des architecture de référence alternatives.

Formatted: Font: Bold
Formatted: Space After: 0 pt
x
Figure 2 — Vue d'ensemble de la démarche d'interopérabilité du présent document
Il est nécessaire que les relations interdomaines, liées au cadre GCM, se produisent au même niveau de
[23]
détails . Pour cela, des spécialisations/généralisations intradomaines sont effectuées.
Formatted: Font: Bold
Formatted: Space After: 0 pt
xi
NORME INTERNATIONALE ISO 23903:2021 (F)

Formatted: French (France)
Informatique de santé — Architecture de référence
Formatted: zzSTDTitle, Space Before: 18 pt, After: 24 pt,
Don't adjust space between Latin and Asian text, Don't adjust
d'interopérabilité et d'intégration — Modèle et cadre
space between Asian text and numbers
Formatted: French (France)
1 Domaine d'application
Formatted: Tab stops: 0.76 cm, Left
Le présent document permet de faire progresser l'interopérabilité depuis le paradigme d'échange de
données/d'informations vers le partage des connaissances à un niveau d'abstraction de moins en moins
élevé, en commençant au niveau des concepts TI (coordination sémantique) en passant par le niveau des
concepts de domaine d'activité (coopération convenue au niveau des fonctions de service), le niveau du
domaine (coopération inter-domaines) jusqu'au contexte individuel (collaboration entre utilisateurs
finaux fondée sur les compétences). Le présent document définit un modèle et un cadre pour une
représentation harmonisée de systèmes existants ou prévus, portant plus particulièrement sur les
systèmes professionnels pris en charge par les technologies de l'information et de la communication.
L'architecture de référence d'interopérabilité et d'intégration prend en charge l'harmonisation
ontologique ou l'harmonisation des connaissances afin de permettre l'interopérabilité entre, et
l'intégration des, systèmes, normes et solutions à tout niveau de complexité sans exiger d'adapter ou
réviser en continu ces spécifications. Cette démarche peut être utilisée pour analyser, concevoir, intégrer
et faire fonctionner tout type de systèmes. Pour arriver à une interopérabilité avancée, il est nécessaire
que des écosystèmes de santé et sociaux flexibles, évolutifs, contrôlés par les activités, adaptables, basés
sur les connaissances et intelligents suivent une démarche orientée systèmes, centrée sur l'architecture,
basée sur l'ontologie et dictée par une politique.
Les langages utilisés pour représenter les différentes vues des systèmes, comme les langages d'ontologie
[24] [25]
tels que Common Logic (CL) (ISO/IEC 24707 ) et Web Ontology Language (OWL) – spécifiquement
[26] 6
OWL 2 (World Wide Web Consortium, W3C® ), les langages de modélisation et d'intégration de
processus professionnels tels que Business Process Modeling Language (BPML) (OMG® ), mais
[27]
également Unified Modeling Language d'OMG (UML, également spécifié comme l'ISO/IEC 19505 )
basés sur les styles de représentation pour les différentes vues de l' ISO/IEC 10746 (toutes les parties)
ne relèvent pas du domaine d'application du présent document.

W3C est une marque déposée du World Wide Web Consortium. Cette information est donnée par souci de Formatted: French (Switzerland)
commodité à l'intention des utilisateurs du présent document et ne saurait constituer un engagement de la part de
l'ISO quant au produit désigné.
OMG est une marque déposée de l'OMG (Object Management Group®). Cette information est donnée par souci de Formatted: French (Switzerland)
commodité à l'intention des utilisateurs du présent document et ne saurait constituer un engagement de la part de
l'ISO quant au produit désigné.
NORME INTERNATIONALE ISO 23903:2021(F)

Formatted: Font: 9 pt
Formatted: Space After: 36 pt, Line spacing: single
Formatted: Section start: Odd page, Different first page
header
Formatted: French (France)
2 Références normatives
Formatted: Tab stops: 0.76 cm, Left
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
Formatted: Don't keep with next, Don't keep lines together
contenu, des exigences du présent document. Pour les références datées, seule l'éditionl’édition citée
s'appliques’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/IEC 10746 (toutes les parties), Technologies de l'information l’information — Traitement réparti
ouvert — Modèle de référence : Architecture
ISO 22600 (toutes les parties), Informatique de santé — Gestion de privilèges et contrôle d'accèsd’accès
ISO/IEC 21838 (toutes les parties), Information technology — Top-level ontologies (TLO)
OMG Ontology Definition Metamodel V1.1 Formatted: English (United States)
3 Termes et définitions Formatted: French (France)
Formatted: Tab stops: 0.76 cm, Left
Pour les besoins du présent document, les termes et définitions suivants s'appliquents’appliquent.
Formatted: Adjust space between Latin and Asian text, Adjust
space between Asian text and numbers
L'ISOL’ISO et l'IECl’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées
en normalisation, consultables aux adresses suivantes ::
— ISO Online browsing platform : disponible à l'adressel’adresse https://www.iso.org/obp Formatted: Adjust space between Latin and Asian text, Adjust
space between Asian text and numbers, Tab stops: Not at 0.7
cm + 1.4 cm + 2.1 cm + 2.8 cm + 3.5 cm + 4.2 cm + 4.9
— IEC Electropedia : disponible à l'adressel’adresse http://www.electropedia.org/.
cm + 5.6 cm + 6.3 cm + 7 cm
3.1
architecture
ensemble de règles destinées à définir la structure des systèmes (3.25), et les relations entre leurs
différentes parties
[SOURCE : ISO/IEC 10746-2:2009, 6.6, modifiée — « («(d'un système) »)» n'est plus associé au terme.]
3.2
axiome
énoncé considéré comme vrai, servant de prémisse à un raisonnement plus approfondi
[SOURCE : ISO/IEC/PRF 21838-1:—, 3.9, modifiée — La Note à l'article a été remplacée.] Formatted: std_publisher
3.3
point de vue entreprise
point de vue (3.28) qui porte sur l'objectif, le domaine d'application et les politiques qui régissent les
activités de l'écosystème (3.10) spécifié
3.4 Formatted: Don't keep with next, Don't keep lines together
classe
type
Formatted: Font: 9 pt
entité (3.11) générale (3.11)
Formatted: Right, Space After: 0 pt, Line spacing: single
Formatted: Justified, Space After: 12 pt, Line spacing: At
[SOURCE : ISO/IEC/PRF 21838-1:— , 3.2, modifiée — « type »ajouté comme deuxième terme least 12 pt
préférentiel et Note à l'article supprimée.]
Formatted: French (France)
Formatted: std_publisher
3.5
Formatted: cite_sec
collection
groupe d'éléments (3.19)
[SOURCE : ISO/IEC/PRF 21838-2:— , 3.4, modifiée — Notes à l'article supprimées.] Formatted: std_publisher
Formatted: cite_sec
3.6
concept
unité de connaissance créée par une combinaison unique de caractéristiques
Note 1 à l'article : Les concepts ne sont pas nécessairement liés à des langues naturelles particulières. Ils sont
cependant soumis à l'influence du contexte socioculturel qui conduit souvent à des catégorisations différentes.
Note 2 à l'article : En tant que composante de connaissance, un concept peut être spécialisé et généralisé tout
Formatted: std_publisher
comme les composantes elles-mêmes.
Formatted: std_publisher
[SOURCE : ISO 1087:2019, 3.2.7, modifiée— Note 2 à l'article remplacée.]
Formatted: Default Paragraph Font, French (Switzerland)
Formatted: French (Switzerland)
3.7
Formatted: Default Paragraph Font, French (Switzerland)
définition
Formatted: French (Switzerland)
représentation d'un concept par un énoncé descriptif permettant de le différencier des concepts associés
Formatted: French (Switzerland)
[SOURCE : ISO 1087:2019, 3.3.1]
Formatted: Default Paragraph Font, French (Switzerland)
Formatted: Don't adjust space between Latin and Asian text,
3.8
Don't adjust space between Asian text and numbers
domaine
Formatted: French (Switzerland)
collection (3.5) d'entités (3.11) présentant un intérêt pour une certaine communauté ou discipline
Formatted: French (Switzerland)
Formatted: Default Paragraph Font, French (Switzerland)
[SOURCE : ISO/IEC/PRF 21838-1:—, 3.17, modifiée — Exemple et Note à l'article supprimés.]
Formatted: French (Switzerland)
3.9
Formatted: French (Switzerland)
ontologie de domaine
Formatted: French (Switzerland)
ontologie (3.18) dont les termes (3.26) représentent des classes ou types (3.4) et, éventuellement, certains
Formatted: Default Paragraph Font, French (Switzerland)
éléments (3.19) (appelés « individus distingués ») dans un certain domaine (3.8)
Formatted: French (Switzerland)
[SOURCE : ISO/IEC/PRF 21838-1:—, 3.18]
Formatted: French (Switzerland)
Formatted: French (Switzerland)
3.10
Formatted: French (Switzerland)
écosystème
Formatted: French (Switzerland)
systèmes (3.25) et communautés structurés régis par des règles générales
Formatted: Default Paragraph Font, French (Switzerland)
3.11 Formatted: French (Switzerland)
entité
Formatted: Default Paragraph Font, French (Switzerland)
objet
Formatted: French (Switzerland)
tout ce qui peut être perçu ou conçu
Formatted: Default Paragraph Font, French (Switzerland)
Formatted: French (Switzerland)
Note 1 à l'article : Les termes « entité » et « objet » sont des termes fourre-tout analogues à « quelque chose ». Dans
les cercles terminologiques, « objet » est couramment utilisé de cette manière. Dans les cercles ontologiques, les
Formatted: Default Paragraph Font, French (Switzerland)
termes « entité » et « chose » sont couramment utilisés.
Formatted: French (Switzerland)
Formatted: Default Paragraph Font, French (Switzerland)

8 Formatted: French (Switzerland)
En cours d'élaboration. Stade à la dateau moment de la publication : ISO/IEC/PRF 21838-1:2020.
En cours d'élaboration. Stade à la dateau moment de la publication : ISO/IEC/PRF 21838-2.2:2020. Formatted: Space After: 0 pt
least 12 pt
[SOURCE : ISO/IEC/PRF 21838-1:—, 3.1] Formatted: Font: Not Bold
Formatted: std_publisher
3.12
expression
mot ou groupe de mots ou symboles correspondants permettant de formuler une déclaration
Note 1 à l'article : Les expressions sont divisées en expressions en langage naturel et en expressions dans un
langage formel.
[SOURCE : ISO/IEC/PRF 21838-1:—, 3.5] Formatted: std_publisher
3.13
langage formel
langage qui peut être lu par une machine et a une sémantique clairement définie
[SOURCE : ISO/IEC/PRF 21838-1:—, 3.10, modifiée — Note supprimée.] Formatted: std_publisher
Formatted: std_year
3.14
théorie formelle
collection (3.5) de définitions (3.7) et d'axiomes (3.2) exprimés dans un langage formel (3.13)
[SOURCE : ISO/IEC/PRF 21838-1: —, 3.11, modifiée — Note supprimée.] Formatted: std_publisher
3.15
instance
élément (3.19) qui instancie un universel (3.27)
[SOURCE : ISO/IEC/PRF 21838-2:—, 3.6, modifiée — Exemple supprimé.] Formatted: std_publisher
3.16
interopérabilité
capacité d'un système (3.25) ou d'un produit à travailler avec d'autres systèmes (3.25) ou produits sans
effort particulier de la part du client
Note 1 à l'article : Selon l'interprétation TIC traditionnelle, l'interopérabilité est la capacité de deux systèmes ou
[29]
composants ou plus à échanger des informations et à utiliser les informations qui ont été échangées .
[SOURCE : Glossaire des normes de l'IEEE]
3.17 Formatted: Don't keep with next, Don't keep lines together
modèle
conception univoque et abstraite de certaines parties ou certains aspects du monde réel correspondant
aux buts de modélisation
Note 1 à l'article : Les parties prenantes concernées définissent la vue fournie du modèle, ainsi que la manière de
structurer et de nommer les concepts de l'espace de problème. En capturant au préalable les concepts clés et les
relations clés à un niveau d'abstraction élevé, il convient que différents niveaux d'abstraction soient utilisés de façon
itérative, la première itération étant effectuée de manière descendante de façon à garantir l'intégrité conceptuelle
du modèle. Cela nécessite de respecter des principes de conception tels que l'orthogonalité, la généralité, la
[30]
parcimonie et la propriété .
3.18
ontologie
collection (3.5) de termes (3.26), expressions relationnelles (3.24) et de leurs définitions (3.7) associées
en langage naturel, ainsi que d'une ou plusieurs théories formelles (3.14) conçues pour capturer les
interprétations prévues de ces définitions (3.7)
Formatted: Space After: 0 pt
least 12 pt
Note 1 à l'article : Une ontologie définit un ensemble de primitives représentationnelles permettant de modéliser Formatted: Font: Not Bold
un domaine de connaissances ou de discours. Les primitives représentationnelles sont généralement des classes
(ou des ensembles), des attributs (ou des propriétés) et des relations (ou des relations entre les membres de la
classe). Les définitions des primitives représentationnelles comprennent des informati
...