ISO 12967-1:2020
(Main)Health informatics — Service architecture (HISA) — Part 1: Enterprise viewpoint
Health informatics — Service architecture (HISA) — Part 1: Enterprise viewpoint
This document provides guidance and requirements for the description, planning and development of new systems, as well as for the integration of existing information systems, both within one enterprise and across different healthcare organizations, through an architecture integrating the common data and business logic into a specific architectural layer (i.e. the middleware), distinct from individual applications and accessible throughout the whole information system through services, as shown in Figure 2.
Informatique de santé — Architecture de service — Partie 1: Point de vue de l'entreprise
Le présent document fournit des recommandations et des exigences pour la description, la planification et le développement de nouveaux systèmes ainsi que pour l'intégration des systèmes d'information existants, tant dans le cadre d'une entreprise qu'entre organismes de santé, grâce à la mise en place d'une architecture intégrant les données communes et la logique applicative dans une couche architecturale spécifique (à savoir la couche interstitielle), distincte des applications individuelles et accessible par tous les systèmes d'information grâce à des services (voir Figure 2).
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 12967-1
Second edition
2020-11
Health informatics — Service
architecture (HISA) —
Part 1:
Enterprise viewpoint
Informatique de santé — Architecture de service —
Partie 1: Point de vue de l'entreprise
Reference number
©
ISO 2020
© ISO 2020
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: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2020 – All rights reserved
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
3.1 Healthcare . 2
3.2 System concepts . 3
3.3 Concepts relating to organization . 4
3.4 Community concepts . 4
3.5 Behaviour concepts . 5
3.6 Policy concepts . 7
3.7 Accountability, responsibility and time concepts . 7
3.8 Information management . 9
4 Symbols and abbreviations .10
5 Methodology for the specification of the architecture .10
5.1 General .10
5.2 Viewpoints for the specification of the architecture .10
5.3 The HISA specification procedure .11
5.3.1 The strategic paradigm.11
5.3.2 Specification of the enterprise viewpoint .12
5.3.3 Specification of the information viewpoint .12
5.3.4 Specification of the computational viewpoint.13
5.4 Iterative specification .13
5.5 Viewpoints specification languages, notations and levels of abstraction .14
6 HISA overview.15
6.1 General requirement .15
6.2 Enterprise viewpoint .16
6.3 Information viewpoint .17
6.4 Computational viewpoint .18
7 Methodology for extensions .19
8 Conformance criteria .19
8.1 General .19
8.2 Conformance of specification documents to the HISA methodology .20
8.3 Conformance of middleware products to the HISA architectural requirements .20
9 The HISA Enterprise viewpoint .21
9.1 Overview .21
9.1.1 General.21
9.1.2 The regional, inter-enterprise perspective .21
9.1.3 The medical/clinical perspective .22
9.1.4 The operational/clinical and organizational process model perspective .24
9.1.5 The information services and their complexity .28
9.2 The fundamental workflows and groups of users’ activities to be supported by the
middleware .28
9.3 General information requirements for all users’ activities .30
9.3.1 General.30
9.3.2 Common attributes .30
9.3.3 Extensibility .30
9.3.4 Versioning .31
9.3.5 Auditing .31
9.3.6 Handling of life cycle.31
9.4 Subject of care workflow .31
9.4.1 Textual description of requirements .31
9.4.2 Use-case examples .33
9.5 Healthcare information workflow .38
9.5.1 Textual specification of requirements .38
9.5.2 Use-case examples .39
9.6 Healthcare activity management workflow .40
9.6.1 Textual description of requirements .40
9.6.2 Use-case examples .43
9.6.3 Examples of functions from ISO/HL7 10781 supporting the use case .46
9.7 Resources management activities .47
9.8 Management activities for users and authorizations .47
9.9 Classifications, coding and dictionaries management activities .49
9.9.1 General description of requirements .49
9.9.2 Examples of functions from ISO/HL7 10781 providing support .51
Annex A (informative) Highlights of ODP .52
Annex B (informative) Rationale for the federative structure of the health informatics
service architecture.55
Annex C (informative) Cross-Domain Interoperability .58
Bibliography .65
iv © ISO 2020 – All rights reserved
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation 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).
This second edition cancels and replaces the first edition (ISO 12967-1:2009), which has been technically
revised. The main changes compared to the previous edition are as follows:
— use of terms, definitions and concepts from ISO 13940:2015 (Contsys), with textual alignment
throughout the document including figures, to the extent possible and beneficial;
— reference to further standards, such as HL7® and FHIR®;
— addition of abstraction layers supplementing the viewpoint descriptions;
— introduction of example functions from ISO/HL7 10781 supporting the use case examples of this
document;
— addition of Annex C, Cross-Domain Interoperability, in line with the current (2020) ongoing
ISO Interoperability and Integration Reference Architecture standardization initiative;
— updates to the Bibliography.
A list of all parts in the ISO 12967 series can be found on the ISO website.
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.
Introduction
The healthcare organizational structure consists of networks of centres (hospitals of different
types and sizes and outpatient clinics for primary and secondary care within a geographical area)
distributed over the territory, characterized by a high degree of heterogeneity and diversity, from
organizational, logistic, clinical, technological and even cultural perspectives. The structure of
individual centres evolves from a vertical, aggregated organization towards the integration of a set
of specialized functional areas (e.g. unit of laboratory analyses, unit of surgery), with specific needs
and characteristics, nevertheless needing to share common information and to operate according to
integrated workflows. Such a situation determines two main needs which conflict with each other
in a certain way. On the one hand, it is necessary to effectively support the specific requirements of
each unit or user in the most appropriate and cost-effective way whilst, on the other hand, it is vital to
ensure the consistency and integration of the overall organization, at local and territorial levels. This
integration requirement is not only related to the need for improving clinical treatments to the subject
of care but is also demanded by the urgent necessity of all countries to control and optimize the current
level of expenditure for health, whilst ensuring the necessary qualitative level of services to all subjects
of care.
The large number of databases and applications, mutually isolated and incompatible, which are already
available on the market and operational in healthcare organizations to support specific needs of users,
cannot be underestimated. Even within the same centre, healthcare information systems are frequently
fragmented across a number of applications, data and functionalities, isolated and scarcely consistent
with each other.
In the present circumstances, the main need for care delivery organizations is to integrate and to make
available the existing information assets, and to make possible the integration and interoperability
of existing applications, thereby protecting investments. During integration activities, continuity
of service needs to be achieved whilst gradual migration of existing proprietary, monolithic systems
towards the new concepts of openness and modularity occurs. The cost-effectiveness of the solutions,
especially when projected on the scale of the whole healthcare organization, represents another crucial
aspect to be evaluated carefully.
A further aspect is related to quality management (see bibliography), where information management
is an integrated part of quality management and the strategic and operative approaches for these two
managerial aspects need to be co-ordinated to be effective. Clinical processes are comprehensive.
Systematic and structured information management including medical knowledge management is
required for high-level quality in effective healthcare systems.
The aims can be achieved through a unified, open architecture based on middleware independent from
specific applications and capable of integrating common data and business logic and of making them
available to diverse, multi-vendor applications through many types of deployment. According to the
integration objectives at organizational level, all aspects (i.e. clinical, organizational and managerial)
of the healthcare structure should be supported by the architecture, which should therefore be able to
comprise all relevant information and all business workflows, structuring them according to criteria
and paradigms independent from specific sectorial aspects, temporary requirements or technological
solutions.
Standards and technological solutions already exist and will continue to be defined for supporting
specific requirements, both in terms of in situ user operations and with respect to the movement of
information. The architecture should be able to accommodate such requirements by allowing the
specific models to be integrated with the complete information assets of the healthcare organization
and e.g. communication messages to be “services” extracting or importing data from/to the common
information shown in Figure 1.
On the basis of these considerations, the purpose of the ISO 12967 series is twofold:
— identify a methodology to describe healthcare information systems through a language, notation
and paradigms suitable to facilitate the planning, design and comparison of systems;
vi © ISO 2020 – All rights reserved
— identify the fundamental architectural aspects enabling the openness, integration and
interoperability of healthcare information systems.
The architecture is therefore intended as a basis both for working with existing systems and for the
planning and construction of new systems.
Key
1 specific models and communication interfaces (e.g. CDA, FHIR, ISO 13606, DICOM)
2 common, neutral, organisation-wide HISA model
3 integrated and consistent heritage of all common enterprise data and common business logic
Figure 1 — Complementarity and positioning of the architecture with other standards and
models
It is pointed out that the ISO 12967 series does not aim to define a unique model for clinical,
organizational, managerial or administrative activities, but rather defines a set of workflows,
information and services common to all healthcare information systems, relevant for any healthcare
sector and usable by any application also for facilitating the mutual interworking.
Similarly, the ISO 12967 series does not aim to represent a final, complete set of specifications. On the
contrary, it formalizes only fundamental aspects, identified as common in all countries and considered
to be currently essential in any advanced healthcare information system. Specifications are formalized,
avoiding any dependency on specific technological products and/or solutions.
In line with the above, HISA neither explicitly addresses major trends within healthcare in 2020 such as
"Patient Engagement" or "Patient Registries/Patient Data Hubs". HISA nevertheless also supports these
trends and might very well be used in connection herewith, providing further support for information
exchange, to the benefit of the patient, or for structured and systematic information management
regarding research, clinical databases, knowledge application and quality improvement.
The ISO 12967 series, therefore, is an open framework that, according to the specification methodology
and preserving the compatibility with previous versions, can be extended during time according to
the evolution of the healthcare organization both in the individual (national and local) contexts and
through international standardization initiatives.
A European pre-standard, ENV 12967, developed according to such rationale during 1993 to 1997
and published in 1998, was the basis for implementations of middleware products and implemented
integrations in healthcare regions in several countries. In 2000, the CEN/TC 251 Short Strategic Study
on Health Information Infrastructure identified a number of other new architectures and health
infrastructure initiatives, as well as the requirements and possibilities for alignment with the large
body of information model standards developed by CEN for various communication purposes. European
standardization initiatives have delivered a number of object-oriented domain models and message
descriptions that include an architecture for the Electronic Health Record [ISO 13606 (all parts)], and a
concept model of healthcare (ISO 13940:2015). In the last ten years ISO, HL7 and CEN have increasingly
collaborated and both the ISO 13606 (all parts) and ISO 13940:2015 have undergone major systematic
reviews as ISO standards. Besides these ISO standards, HL7 Service-Aware Interoperability Framework
(SAIF) has served as a source of inspiration, the Australian E-health Interoperability Framework (eHIF,
see bibliography) and a conference paper from 2016 "Digital Health Interoperability Frameworks: Use
of RM-ODP Standards" as sources of input for this revision (see bibliography).
The formal major revision of the pre-standard to a European standard was started in 2003 and in 2007
this led to the publication of the EN 12967-1 to EN 12967-3 series on which the ISO 12967 series is
based, currently serving as the basis for this revision.
The following characteristics of the ISO 12967 series can be highlighted as follows.
— The architecture is described according to the methodology of ISO/IEC 10746 (all parts), to provide
a formal, comprehensive and non-ambiguous specification suitable to serve as a reference in the
planning, design and implementation of healthcare information systems. (Annex A provides short
informative background information regarding the ISO/IEC 10746 (all parts) and Open Distributed
Processing).
— The scope of the architecture comprises the support to the activities of the healthcare organization
as a whole, from the clinical, organizational and managerial point of view. It therefore does not detail
specificities of different subdomains, but provides an overarching comprehensive information and
services framework to accommodate requirements.
— The architecture is intrinsically compatible, complementary and synergistic with other models
and standards, such as HL7 CDA, HL7 FHIR, ISO 13940:2015 (Contsys) and ISO 13606 (all parts).
A separate mapping document between ISO 12967-2 and HL7 RIM was produced during the
process for the first version of this ISO 12967 series. Specific information objects and services are
explicitly foreseen in the architecture to facilitate the implementation of views and communication
mechanisms based on such standards.
— Many of the concepts and principles shared with ISO 13606 (all parts), ISO 13940:2015 (Contsys)
and the ISO 12967 series are aligned, originally stemming from CEN. But as the standards also
reflect different, although complementary, scopes, purposes and objectives, as investigated during
a joint "concurrent use" initiative, differences do exist.
Each part in the ISO 12967 series is self-consistent and is also independently utilizable for the intended
purposes by different types of users (this document being more oriented to the managerial level,
Parts 2 and 3 being more dedicated to the design activities). Nevertheless, it should be understood
that they represent three aspects of the same architecture. Mutual references therefore exist between
the different parts and evolutions of the individual documents should be carried out according to the
defined methodology to reserve the overall integrity and consistency of the specification.
The overall architecture is formalized according to ISO/IEC 10746 (all parts) and is therefore structured
through the following three viewpoints.
a) Enterprise viewpoint: specifies a set of fundamental common requirements at enterprise level
with respect to the organizational purposes, scopes and policies that should be supported by the
information and functionality of the middleware. It also provides guidance on how one individual
enterprise (e.g. a regional healthcare authority, a large hospital or any other organization where
this model is applicable) can specify and document additional specific business requirements, with
a view to achieving a complete specification, adequate for the characteristics of that enterprise.
Enterprise viewpoint is specified in this document.
b) Information viewpoint: specifies the fundamental semantics of the information model to be
implemented by the middleware to integrate the common enterprise data and to support the
enterprise requirements formalized in this document. It also provides guidance on how one
individual enterprise can extend the standard model with additional concepts needed to support
local requirements in terms of information to be put in common.
Information viewpoint is specified in ISO 12967-2.
viii © ISO 2020 – All rights reserved
c) Computational viewpoint: specifies the scope and characteristics of the services that should be
provided by the middleware for allowing access to the common data as well as the execution of the
business logic supporting the enterprise processes identified in the information viewpoint and in
this document. It also provides guidance on how one individual enterprise can specify additional
services needed to support local specific requirements in terms of common business logic to be
implemented.
Computational viewpoint is specified in ISO 12967-3.
1)
Annex C includes an explanation of ISO 23903:— and its relevance in regard to the ISO 12967 series,
for integration with other standards such as ISO 13940.
1) Under preparation. Stage at the time of publication ISO/DIS 23903:2020.
INTERNATIONAL STANDARD ISO 12967-1:2020(E)
Health informatics — Service architecture (HISA) —
Part 1:
Enterprise viewpoint
1 Scope
This document provides guidance and requirements for the description, planning and development of
new systems, as well as for the integration of existing information systems, both within one enterprise
and across different healthcare organizations, through an architecture integrating the common data
and business logic into a specific architectural layer (i.e. the middleware), distinct from individual
applications and accessible throughout the whole information system through services, as shown in
Figure 2.
Key
1 applications
2 middleware of objects integrating common data and common business logic
3 scope of ISO 12967-1
Figure 2 — Scope
This document is also independent from, and does not imply either explicitly or implicitly, any specific
technological solution or product for its deployment. Accordingly, the formalization of the architecture
according to two lower levels of the ODP reference model, the engineering and technology viewpoints,
is outside the scope of this document.
The language and notations used here for specifying the architecture are based on UML (Unified
Modeling Language) complemented by case studies and other paradigms widely utilized by other
standards in health informatics. The level of the specification is complete and non-ambiguous enough to
allow its implementation into the specific physical and technological scenarios adopted by the various
healthcare organizations and vendors. Accordingly, methodology formalized by the Engineering and
Technology viewpoints of the RM ODP Reference Model can be followed for the implementation.
NOTE For more introductory material on RM-ODP and many guideline documents see www .rm -odp .net.
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 12967-2:2020, Health informatics — Service architecture — Part 2: Information viewpoint
ISO 12967-3:2020, Health informatics — Service architecture — Part 3: Computational viewpoint
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/
3.1 Healthcare
3.1.1
healthcare
care activities, services, management or supplies related to the health of an individual
Note 1 to entry: This includes more than performing procedures for subjects of care. It includes, for example, the
management of information about patients, health status and relations within the healthcare delivery framework
and may also include the management of clinical knowledge.
[SOURCE: ISO 13940:2015, 3.1.1]
3.1.2
health issue
representation of an issue related to the health of a subject of care as identified by one or more
healthcare actors
[SOURCE: ISO 13940:2015, 6.3]
3.1.3
healthcare matter
representation of a matter related to the health of a subject of care and/or the provision of healthcare to
that subject of care, as identified by one or more healthcare actors
[SOURCE: ISO 13940:2015, 6.2]
3.1.4
health state
physical and mental functions, body structure, personal factors, activity, participation and
environmental aspects as the composite health of a subject of care
[SOURCE: ISO 13940:2015, 6.5]
3.1.5
health condition
observed or potential observable aspects of the health state at a given time
[SOURCE: ISO 13940:2015, 6.4]
3.1.6
observed condition
health condition observed by a healthcare actor
[SOURCE: ISO 13940:2015, 6.4.1]
2 © ISO 2020 – All rights reserved
3.2 System concepts
3.2.1
information service
ability of the system to provide a defined set of output information based on a defined set of input
information
Note 1 to entry: The term information service is consistently used in this document for the services provided by
the information system.
Note 2 to entry: The healthcare information services are the healthcare related services provided by healthcare
information systems.
3.2.2
middleware
enabling technology of enterprise application integration describing a piece of software that connects
two or more software applications so that they can exchange data
Note 1 to entry: Common programming interfaces between applications are considered as middleware. For
example, Open Database Connectivity (ODBC) enables applications to make a standard call to all the databases
that support the ODBC interface.
Note 2 to entry: HISA services belong to the parts of the architecture that are middleware, and they address basic
aspects dealing with the fundamental openness and sharing of information and business logic for the healthcare
organization. In this document, the usage of the term "middleware" is in the context of HISA, related to the
services.
3.2.3
enterprise application integration
use of software and computer systems architectural principles to integrate a set of enterprise computer
applications
3.2.4
object
model of an entity, characterized by its behaviour and its state, encapsulated and distinct from
other objects
Note 1 to entry: This definition is about "object" in the architectural sense [in line with the ISO/IEC 10746 (all parts)].
This does not preclude the use of the word in the natural language sense as an entity itself, where e.g. a "process
object" of a healthcare/clinical process is the health state of a subject of care.
[SOURCE: ISO/IEC 10746-2:2009, 8.1, modified — shortened.]
3.2.5
enterprise object
object modelling an enterprise entity
3.2.6
class
abstraction of the knowledge and behaviour of a set of similar things
Note 1 to entry: Class in UML is a description of a set of objects that share the same attributes, operations,
methods, relationships, and semantics.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.577, modified — Note 1 to entry substituted.]
3.3 Concepts relating to organization
3.3.1
organization
person or group of people that has its own functions with responsibilities, authorities and relationships
to achieve its objectives
Note 1 to entry: An organization can be public or private.
Note 2 to entry: The scope of an organizational structure can include relevant interfaces to external organizations.
[SOURCE: ISO 9000:2015, 3.2.1, modified — Note 1 to entry has been simplified and Note 2 to entry
substituted.]
3.3.2
healthcare actor
organization or person participating in healthcare
[SOURCE: ISO 13940:2015, 5.2, modified — Note 1-3 to entry omitted.]
3.3.3
healthcare provider
healthcare actor that is able to be assigned one or more care period mandates
[SOURCE: ISO 13940:2015, 5.2.3, modified — Note 1-3 to entry omitted.]
3.3.4
subject of care
healthcare actor with a person role; who seeks to receive, is receiving, or has received healthcare
Note 1 to entry: Among synonyms are patient and subject of healthcare
[SOURCE: ISO 13940:2015, 5.2.1, modified — Note 1 to entry substituted and Examples omitted.]
3.3.5
healthcare organization
healthcare provider having an organization role
[SOURCE: ISO 13940:2015, 5.2.3.1, modified — Note 1-4 to entry and Examples omitted.]
3.3.6
role
function or position
[SOURCE: ISO 13940:2015, 3.3.5]
3.4 Community concepts
3.4.1
community
configuration of objects formed to meet an objective
Note 1 to entry: The objective is expressed as a contract, which specifies how the objective can be met.
3.4.2
federation
community of domains
4 © ISO 2020 – All rights reserved
3.4.3
objective
practical advantage or intended effect, expressed as preferences about future states
Note 1 to entry: Some objectives are ongoing, some are achieved once they are met.
3.5 Behaviour concepts
3.5.1
resource
asset that is utilized or consumed during the execution of a process
Note 1 to entry: Allocation of a resource may constrain other behaviours for which that resource is essential.
Note 2 to entry: A consumable resource may become unavailable after some amount of use or after some amount
of time (in case a duration or expiry has been specified for the resource).
[SOURCE: ISO 13940:2015, 3.4.1, modified — Note 1-2 to entry substituted.]
3.5.2
process
set of interrelated or interacting activities that use inputs to deliver an intended result
Note 1 to entry: An important objective for health care today is its ability to be organized in integrated
processes to ensure continuity of care. The processes may be considered within a single organization or across
organizations.
Note 2 to entry: Inputs to a process are generally outputs of other processes.
Note 3 to entry: The health care process is provided in the health care enterprise.
Note 4 to entry: Processes in an organization are generally planned and carried out under controlled conditions
to add value.
Note 5 to entry: A process where the conformity of the resulting output cannot be readily or economically verified
is frequently referred to as a “special process”.
Note 6 to entry: When a demand for care is accepted by a health care provider, a care mandate is established
stating the mission and authorization for the health care provider to provide health care services to the subject of
care. This care mandate is the basis for decisions about which health care activities are to be performed, what the
objective is for the health care process and the receptacle for objective evidence provided by the clinical process.
Through verification, the quality of each health care activity or series of health care activities can be assessed
giving prerequisites for possible rework, repair, scrap or concession (see respective definitions in ISO 9000:2015,
3.12.8, 3.12.9, 3.12.10, and 3.12.5). The mandate finally reaches a point where the total requirement for the health
care process has been fulfilled and the care mandate can be terminated.
Note 7 to entry: In the clinical process, the health may improve, a risk for deterioration of the health may be
reduced, or knowledge about the health may be improved, something which increases the possibilities to have a
positive influence on the health.
Note 8 to entry: Processes can be influenced by events. Such an event does not occur within the process in
question, but is the conception by the process of an activity executed in another process. An event will probably
lead to a change in the decided process strategy or to a result of the process other than the intended one.
[SOURCE: ISO 9000:2015, 3.4.1, modified — Note 1 to entry substituted, Note 2 to entry simplified,
Note 3 to entry substituted, Note 6 to entry substituted, Note 7 and 8 to entry added.]
3.5.3
step
abstraction of an action, used in a process, that might leave unspecified objects that participate in
that action
3.5.4
service
result of a process
Note 1 to entry: This definition regards the services provided in the organization, with or without an electronic
information system, whereas the definition of “Information service” regards the information (input/output)
provided by the system.
Note 2 to entry: The healthcare services are the services taking place within a healthcare organization.
3.5.5
workflow
series of activities necessary to complete a task
Note 1 to entry: In healthcare, the workflow will often take place based on three fundamental processes: the
clinical process, the communication process and the management process, where information, tasks and
activities are shifted between these.
Note 2 to entry: In terms of HISA, a workflow may involve a number of HISA services, involving the organization
in the provision of more complex objectives, according to agreed procedural rules.
3.5.6
healthcare activity
activity intended directly or indirectly to improve or maintain a health state
[SOURCE: ISO 13940:2015, 7.2, modified — Note 1-3 to entry and Examples omitted.]
3.5.7
healthcare activity element
element of healthcare activity that addresses one type of purpose
Note 1 to entry: Healthcare activity is a complex concept that can be subdivided in elements that represent
different purposes with the action. The different purposes could be direct (healthcare investigation and
healthcare treatment that directly involves the subject of care) or indirect (healthcare assessment, healthcare
evaluation, healthcare documenting or healthcare activity management) that do not necessarily directly involve
the subject of care.
[SOURCE: ISO 13940:2015, 7.2.7]
3.5.8
care plan
dynamic, personalized plan including identified needed healthcare activity, health objectives and
healthcare goals, relating to one or more specified health issues in a healthcare process
[SOURCE: ISO 13940:2015, 9.2, modified — Note 1-5 to entry and Examples omitted.]
3.5.9
healthcare goal
desired achievement of one or more healthcare activities, considered as an intermediate operational
step to reach a specific health objective
[SOURCE: ISO 13940:2015, 9.2.6, modified — Note 1 to entry and Examples omitted.]
3.5.10
protocol
customized clinical guideline
Note 1 to entry: A protocol is more precise than a clinical guideline.
Note 2 to entry: Protocols are often presented in a formal manner with respect to the expected behaviours and
roles of healthcare actors.
[SOURCE: ISO 13940:2015, 9.2.4.1, modified — Examples omitted].
6 © ISO 2020 – All rights reserved
3.5.11
clinical guideline
set of systematically developed statements to assist the decisions made by healthcare actors about
healthcare activities to be performed with regard to specified health issues
Note 1 to entry: Clinical guidelines are usually rather generic and they concern no actual subject of care in
particular. While they generally reflect a broad statement of good practice, they may sometimes include multiple
operational detail
...
NORME ISO
INTERNATIONALE 12967-1
Deuxième édition
2020-11
Informatique de santé — Architecture
de service —
Partie 1:
Point de vue de l'entreprise
Health informatics — Service architecture (HISA) —
Part 1: Enterprise viewpoint
Numéro de référence
©
ISO 2020
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2020
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.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii © ISO 2020 – Tous droits réservés
Sommaire Page
Avant-propos .v
Introduction .vii
1 Domaine d'application . 1
2 Références normatives . 2
3 Termes et définitions . 2
3.1 Soins de santé. 2
3.2 Concepts liés au système . 3
3.3 Concepts liés à l'organisme . 4
3.4 Concepts liés à la communauté . 5
3.5 Concepts liés au comportement . 5
3.6 Concepts de politique . 7
3.7 Concepts liés à l'imputabilité, à la responsabilité et au temps . 8
3.8 Gestion de l'information .10
4 Symboles et abréviations .10
5 Méthodologie pour la spécification de l'architecture .11
5.1 Généralités .11
5.2 Points de vue pour la spécification de l'architecture .11
5.3 Procédure de spécification de l'HISA .12
5.3.1 Paradigme stratégique .12
5.3.2 Spécification du point de vue de l'entreprise.13
5.3.3 Spécification du point de vue de l'information .13
5.3.4 Spécification du point de vue informatique .14
5.4 Spécification itérative .14
5.5 Langages, notations et niveaux d'abstraction de la spécification des points de vue .15
6 Présentation de l'HISA .16
6.1 Exigences générales .16
6.2 Point de vue de l'entreprise .17
6.3 Point de vue de l'information .18
6.4 Point de vue informatique .19
7 Méthodologie des extensions .20
8 Critères de conformité .21
8.1 Généralités .21
8.2 Conformité des documents de spécification à la méthodologie de l'HISA .21
8.3 Conformité des produits de couche interstitielle aux exigences de l'HISA .21
9 Point de vue de l'entreprise de l'HISA .22
9.1 Vue d'ensemble .22
9.1.1 Généralités .22
9.1.2 Point de vue régional, interentreprise .22
9.1.3 Point de vue médical/clinique .23
9.1.4 Point de vue du modèle de processus opérationnel/clinique et organisationnel 25
9.1.5 Les services d'informations et leur complexité .29
9.2 Workflows fondamentaux et groupes d'activités des utilisateurs pris en charge par
la couche interstitielle .30
9.3 Exigences en matière d'informations générales pour toutes les activités des utilisateurs 32
9.3.1 Généralités .32
9.3.2 Attributs communs .32
9.3.3 Extensibilité .32
9.3.4 Gestion des versions .33
9.3.5 Audit .33
9.3.6 Traitement du cycle de vie . .33
9.4 Workflow du sujet de soins .34
9.4.1 Description textuelle des exigences .34
9.4.2 Exemples de cas d'utilisation .36
9.5 Workflow des informations de soins de santé .42
9.5.1 Spécification textuelle des exigences .42
9.5.2 Exemples de cas d'utilisation .42
9.6 Workflow de gestion des activités de soins de santé .44
9.6.1 Description textuelle des exigences .44
9.6.2 Exemples de cas d'utilisation .47
9.6.3 Exemples de fonctions extraits de l'ISO/HL7 10781 venant à l'appui du
cas d'utilisation .50
9.7 Activités de gestion des ressources .51
9.8 Activités de gestion des utilisateurs et des autorisations .52
9.9 Activités de gestion des classifications, du codage et des dictionnaires .54
9.9.1 Description générale des exigences .54
9.9.2 Exemples de fonctions extraits de l'ISO/HL7 10781 fournissant un support .56
Annexe A (informative) Présentation du traitement réparti ouvert (ODP) .57
Annexe B (informative) Logique de la structure fédérative de l'architecture des services
informatiques de santé (HISA) .60
Annexe C (informative) Interopérabilité interdomaine .63
Bibliographie .70
iv © ISO 2020 – Tous droits réservés
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 le lien suivant: www .iso .org/ iso/ fr/ avant -propos.
Le présent document a été élaboré par le comité technique ISO/TC 215, Informatique de santé, en
collaboration avec le Comité européen de normalisation (CEN), le comité technique CEN/TC 251,
Informatique de santé, conformément à l'Accord de coopération technique entre l'ISO et le CEN (Accord
de Vienne).
Cette deuxième édition annule et remplace la première édition (ISO 12967-1:2009), qui a fait l'objet
d'une révision technique.
Les principales modifications par rapport à l'édition précédente sont les suivantes:
— utilisation des termes, définitions et concepts de l'ISO 13940:2015 (Contsys), avec alignement
textuel tout au long du document, y compris pour les figures, si cela est possible et utile;
— référence à d'autres normes, telles que HL7® et FHIR®;
— ajout de couches d'abstraction complétant les descriptions des points de vue;
— introduction d'exemples de fonctions extraits de l'ISO/HL7 10781 prenant en charge les exemples de
cas d'utilisation du présent document;
— ajout de l'Annexe C, Interopérabilité interdomaine, dans la droite ligne de l'initiative actuelle (2020)
de normalisation de l'architecture de référence de l'interopérabilité et de l'intégration de l'ISO;
— mises à jour de la Bibliographie.
Une liste de toutes les parties de la série ISO 12967 se trouve sur le site web de l'ISO.
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.
vi © ISO 2020 – Tous droits réservés
Introduction
Le système de santé se compose de réseaux d'organisations de santé (hôpitaux de différents types et
tailles, cliniques pour soins ambulatoires primaires et secondaires dans une zone géographique donnée)
répartis sur tout le territoire, caractérisés par un degré élevé d'hétérogénéité et de diversité, au niveau
organisationnel, logistique, clinique, technologique, voire culturel. La structure des organismes de santé
évolue d'une organisation globale verticale à l'intégration d'un ensemble de domaines fonctionnels
spécialisés (par exemple analyses en laboratoire, chirurgie) ayant des besoins et des caractéristiques
spécifiques, mais ressentant néanmoins le besoin de partager des informations communes et d'agir
en fonction de workflows intégrés. D'une telle situation découlent deux nécessités principales qui
s'opposent l'une à l'autre d'une certaine façon. D'une part, il est nécessaire de soutenir efficacement
les besoins spécifiques de chaque unité ou de chaque utilisateur de la manière la plus appropriée et la
plus efficiente, alors que, d'autre part, il est vital d'assurer la cohérence et l'intégration de l'ensemble
de l'organisme, tant au niveau local que territorial. Les exigences en matière d'intégration ne sont pas
uniquement liées à la nécessité d'améliorer les traitements médicaux apportés aux patients. Ils sont
aussi exigés par la demande urgente de tous les pays de contrôler et d'optimiser le niveau actuel des
dépenses de santé tout en assurant le niveau nécessaire de qualité des services à tous les patients.
Le grand nombre de bases de données et d'applications isolées et mutuellement incompatibles déjà
disponibles sur le marché, installées et opérationnelles dans les organismes de santé, afin de supporter
efficacement les besoins spécifiques des utilisateurs, ne peut pas être sous-estimé. Il arrive souvent
que, dans le même organisme, le système d'information de santé soit fréquemment fragmenté en un
certain nombre d'applications, de données et de fonctionnalités, isolées et très peu cohérentes les unes
avec les autres.
Dans la situation actuelle, la nécessité principale des organismes de santé est d'intégrer et de rendre
disponibles les informations existantes, de rendre possible l'intégration et l'interopérabilité des
applications déjà existantes et de protéger ainsi les investissements. Lors des activités d'intégration,
la continuité du service doit être maintenue, tout en facilitant une migration progressive des systèmes
propriétaires et monolithiques existants vers les nouveaux concepts d'ouverture et de modularité.
La rentabilité des solutions, surtout lorsqu'elle est projetée à l'échelle de tout l'organisme de santé,
représente un autre aspect crucial qui doit être évalué soigneusement.
Un autre aspect est lié au management de la qualité (voir Bibliographie), où la gestion de l'information
fait partie intégrante du management de la qualité et où les approches stratégiques et opérationnelles
de ces deux aspects doivent être coordonnées pour être efficaces. Les processus cliniques sont globaux.
La gestion systématique et structurée de l'information, y compris la gestion des connaissances
médicales, est nécessaire pour assurer un haut niveau de qualité et d'efficacité dans des systèmes de
soins de santé.
Les objectifs peuvent être atteints grâce à une architecture unifiée ouverte reposant sur une
couche interstitielle indépendante des applications spécifiques et en mesure d'intégrer des données
communes et des logiques applicatives et de les mettre à la disposition des différentes applications
multiprestataires par un déploiement adapté à chacune des situations. Conformément aux objectifs
d'intégration au niveau organisationnel, il convient que l'architecture soit en mesure de prendre en
charge tous les aspects, qu'ils soient cliniques, organisationnels ou managériaux. Par conséquent, il
convient qu'elle puisse inclure toutes les informations pertinentes et tous les workflows métier, en les
structurant en fonction de critères et de paradigmes indépendants des aspects sectoriels particuliers,
des besoins temporaires ou des solutions technologiques.
Des normes et des solutions technologiques existent déjà. Leur définition se poursuivra de façon à
prendre en charge les exigences spécifiques, tant en termes de besoins de l'utilisateur in situ que par
rapport au mouvement des informations. Il convient que l'architecture soit en mesure de s'adapter à
ces exigences en facilitant l'intégration de modèles propres aux informations existantes de l'organisme
de santé et, par exemple, en permettant à des messages de communication de faire office de «services»
extrayant ou important des données depuis/vers les informations mises en commun (voir Figure 1).
Sur la base de ces considérations, l'objectif de la série ISO 12967 est double:
— identifier une méthodologie afin de décrire les systèmes d'information de santé au moyen d'un
langage, d'une notation et de paradigmes pertinents facilitant la planification, la conception et la
comparaison des systèmes;
— identifier les aspects fondamentaux de l'architecture assurant l'ouverture, l'intégration et
l'interopérabilité des systèmes d'information de santé.
Par conséquent, l'architecture est prévue pour servir de base à la gestion des systèmes existants. Elle
est également utile à la planification et à la construction de nouveaux systèmes.
Légende
1 modèles spécifiques et interfaces de communication (par exemple CDA, FHIR, ISO 13606, DICOM)
2 modèle HISA commun, neutre à l'échelle de l'organisme
3 héritage intégré et cohérent de toutes les données communes de l'entreprise et de la logique métier commune
Figure 1 — Complémentarité et positionnement de l'architecture avec d'autres normes et modèles
Il convient de souligner que la série ISO 12967 n'a pas pour objet de définir un modèle unique pour
les activités médicales, organisationnelles, managériales ou administratives. Son objectif est plutôt
de définir un ensemble de workflows, d'informations et de services spécifiques de santé, communs à
tous les systèmes d'information de santé, adapté à tous les secteurs de santé et utilisables par toute
application pour faciliter leur interopérabilité.
De même, la série ISO 12967 n'a pas pour objet de représenter un ensemble de spécifications définitif
et exhaustif. Au contraire, elle formalise uniquement les aspects fondamentaux, communs à tous les
pays européens et considérés actuellement comme essentiels dans un système d'information de santé
avancé. Les spécifications sont formalisées, ce qui permet d'éviter toute dépendance vis-à-vis de
produits et/ou de solutions technologiques spécifiques.
Conformément à ce qui précède, l'HISA ne traite pas explicitement des grandes tendances 2020 du
domaine des soins de santé, telles que la «participation du patient» ou les «registres de patients/
concentrateurs de données patient», même si elle va dans le même sens et pourrait fort bien être utilisée
dans ce contexte, en apportant un soutien supplémentaire à l'échange d'informations, au bénéfice du
patient, ou à la gestion structurée et systématique des informations concernant la recherche, les bases
de données cliniques, l'application des connaissances et l'amélioration de la qualité.
Par conséquent, la série ISO 12967 se situe dans un cadre ouvert qui, conformément à la méthodologie
de spécification et en préservant la compatibilité avec les versions précédentes, peut être étendu en
fonction de l'évolution de l'organisme de santé, tant du point de vue des contextes individuels (nationaux
et locaux) que des initiatives de normalisation internationales.
Un projet de Norme européenne, l'ENV 12967, a été élaboré conformément à cette logique entre 1993
et 1997 et a été publié en 1998. Il a servi de base à la mise en œuvre de produits d'infrastructure
viii © ISO 2020 – Tous droits réservés
d'intégration dans le domaine de la santé dans plusieurs pays. En 2000, la courte étude stratégique sur
l'infrastructure de l'information en matière de santé du CEN/TC 251 a identifié un certain nombre de
nouvelles architectures et d'initiatives d'infrastructure de santé ainsi que des exigences et possibilités
d'alignement sur un large éventail de normes relatives au modèle d'information développées par le
CEN pour différents besoins de communication. En outre, des initiatives de normalisation européenne
ont permis de proposer un certain nombre de modèles de domaine orientés objet et de descriptions de
message comprenant une architecture de dossiers santé informatisés [ISO 13606 (toutes les parties)]
et un modèle de concept de soins de santé (ISO 13940:2015). Au cours des dix dernières années, l'ISO, le
HL7 et le CEN ont intensifié leur collaboration, ce qui a mené à des refontes systématiques majeures des
normes ISO 13606 (toutes les parties) et ISO 13940:2015 en tant que normes ISO. Outre ces normes ISO,
le Service-Aware Interoperability Framework (SAIF) du HL7 a servi de source d'inspiration, l'Australian
E-health Interoperability Framework (eHIF, voir Bibliographie) et un document de conférence de 2016
«Digital Health Interoperability Frameworks: Use of RM-ODP Standards» ont servi de sources de
contribution pour la présente révision (voir Bibliographie).
La principale révision formelle du projet de norme en vue d'en faire une Norme européenne a commencé
en 2003 et a abouti, en 2007, à la publication de la série de normes EN 12967-1 à EN 12967-3, sur laquelle
se fonde la série ISO 12967 et qui sert actuellement de base à la présente révision.
Les caractéristiques suivantes de la série ISO 12967 peuvent être présentées comme suit.
— L'architecture est décrite conformément à la méthodologie de l'ISO/IEC 10746 (toutes les parties),
de façon à fournir une spécification formelle, exhaustive et sans ambiguïté apte à faire office de
référence dans le cadre de la planification, de la conception et de la mise en place de systèmes
d'information de santé. (L'Annexe A présente, de manière succincte, l'ISO/IEC 10746 (toutes les
parties) ainsi que le traitement réparti ouvert.)
— Le domaine d'application de l'architecture intègre la prise en charge de toutes les activités liées à
l'ensemble de l'organisme de santé, des points de vue clinique, organisationnel et managérial. Par
conséquent, il ne détaille pas les particularités des différents sous-domaines, mais offre un cadre
d'informations et de services exhaustifs pour répondre à ces exigences.
— L'architecture est intrinsèquement compatible, complémentaire et en totale synergie avec d'autres
modèles et normes, comme le format CDA de HL7, la norme FHIR de HL7, le système Contsys de
l'ISO 13940:2015 et la norme ISO 13606 (toutes les parties). Un document distinct de mise en
correspondance entre l'ISO 12967-2 et le modèle HL7 RIM a été réalisé au cours de l'élaboration
de la première version de la présente série ISO 12967. Pour faciliter la mise en place des vues et
mécanismes de communication reposant sur de telles normes, des objets et services d'informations
spécifiques sont explicitement prévus dans l'architecture.
— De nombreux concepts et principes provenant à l'origine du CEN, communs à l'ISO 13606 (toutes
les parties), à l'ISO 13940:2015 (Contsys) et à la série ISO 12967 sont alignés. Mais, comme les
normes reflètent également des domaines d'application, des buts et des objectifs différents, même
si complémentaires, il existe des différences, comme l'a révélé une étude menée dans le cadre d'une
initiative conjointe d'«utilisation en parallèle».
Chaque partie de la série ISO 12967 est autocohérente et peut être également utilisée indépendamment,
pour les objectifs visés par différents types d'utilisateurs (le présent document étant davantage orienté
vers le niveau de gestion, les Parties 2 et 3 étant davantage dédiées aux activités de conception).
Néanmoins, il convient de comprendre qu'elles représentent trois aspects de la même architecture.
Il existe, par conséquent, des références mutuelles entre les différentes parties et il convient de faire
évoluer les documents individuels conformément à la méthodologie définie, afin de préserver l'intégrité
et la cohérence globale de la spécification.
L'architecture générale est formalisée conformément à l'ISO/IEC 10746 (toutes les parties) et est, par
conséquent, structurée par l'intermédiaire des trois points de vue suivants.
a) Point de vue de l'entreprise: il spécifie un ensemble d'exigences communes fondamentales au
niveau d'une entreprise par rapport aux objectifs, aux domaines d'application et aux politiques
organisationnels qu'il convient de prendre en charge au travers de l'information et de la
fonctionnalité de la couche interstitielle. Il fournit également des recommandations relatives à la
manière dont une entreprise individuelle (par exemple un système de santé régional, un grand
hôpital ou tout autre établissement dans lequel ce modèle peut s'appliquer) peut spécifier et
justifier des exigences de fonctionnement spécifiques supplémentaires, dans le but d'obtenir une
spécification complète et adaptée aux caractéristiques de cette entreprise.
Le point de vue de l'entreprise est spécifié dans le présent document.
b) Point de vue de l'information: il spécifie les aspects sémantiques fondamentaux du modèle
d'information à mettre en œuvre par la couche interstitielle afin d'intégrer les données d'entreprise
communes et de prendre en charge les exigences de l'entreprise formalisées dans le présent
document. Il donne également des recommandations quant à la manière dont une entreprise
individuelle peut étendre le modèle standard en ajoutant les concepts supplémentaires nécessaires
à la prise en charge des exigences locales en termes d'informations devant être mises en commun.
Le point de vue de l'information est spécifié dans l'ISO 12967-2.
c) Point de vue informatique: il spécifie le domaine d'application et les caractéristiques des services
qu'il convient d'obtenir de la couche interstitielle pour permettre d'accéder aux données communes
et d'exécuter la logique applicative prenant en charge les processus d'entreprise identifiés
dans le point de vue de l'information et dans le présent document. Il fournit également des
recommandations relatives à la manière dont une entreprise individuelle peut spécifier les services
supplémentaires nécessaires à la prise en charge d'exigences spécifiques locales en termes de mise
en œuvre de la logique applicative commune.
Le point de vue informatique est spécifié dans l'ISO 12967-3.
1)
L'Annexe C comporte une présentation de l'ISO 23903:— et de sa pertinence par rapport à la série
ISO 12967, en ce qui concerne son intégration à d'autres normes, telles que l'ISO 13940.
1) En cours d'élaboration. Stade à la date de publication: ISO/DIS 23903:2020.
x © ISO 2020 – Tous droits réservés
NORME INTERNATIONALE ISO 12967-1:2020(F)
Informatique de santé — Architecture de service —
Partie 1:
Point de vue de l'entreprise
1 Domaine d'application
Le présent document fournit des recommandations et des exigences pour la description, la planification
et le développement de nouveaux systèmes ainsi que pour l'intégration des systèmes d'information
existants, tant dans le cadre d'une entreprise qu'entre organismes de santé, grâce à la mise en place
d'une architecture intégrant les données communes et la logique applicative dans une couche
architecturale spécifique (à savoir la couche interstitielle), distincte des applications individuelles et
accessible par tous les systèmes d'information grâce à des services (voir Figure 2).
Légende
1 applications
2 couche interstitielle d'objets intégrant les données communes et la logique métier commune
3 domaine d'application de l'ISO 12967-1
Figure 2 — Domaine d'application
Le présent document est également indépendant, de manière explicite ou implicite, de toute solution
ou de tout produit technologique spécifique pour son déploiement. Par conséquent, la formalisation
de l'architecture conformément aux deux niveaux inférieurs du modèle de référence d'ODP, à savoir le
point de vue d'ingénierie et le point de vue de technologie, ne fait pas partie du domaine d'application
du présent document.
Le langage et les notations utilisés ici pour spécifier l'architecture reposent sur la notation UML
(Unified Modeling Language), complétés par des études de cas et des paradigmes largement utilisés
par d'autres normes en matière d'informatique de santé. Le niveau de la spécification est suffisamment
exhaustif et sans ambiguïté pour permettre sa mise en œuvre dans le cadre des scénarios physiques
et technologiques spécifiques adoptés par les différents organismes de santé et prestataires. En
conséquence, la méthodologie formalisée par les points de vue de l'ingénierie et de la technologie du
modèle de référence RM-ODP peut être suivie pour la mise en œuvre.
NOTE Pour en savoir plus sur le modèle de référence RM-ODP et accéder à divers documents d'aide, consulter
le site www .rm -odp .net.
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
ISO 12967-2:2020, Informatique de santé — Architecture de service — Partie 2: Point de vue de l’information
ISO 12967-3:2020, Informatique de santé — Architecture de service — Partie 3: Point de vue informatique
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 Soins de santé
3.1.1
soins de santé
activités, prestations, gestion ou fournitures relatives à la santé d'un individu
Note 1 à l'article: Les soins de santé ne se limitent pas à l'exécution de procédures pour des sujets de soins. Ils
comprennent, par exemple, la gestion des informations concernant les patients, l'état de santé et les relations
dans le cadre des soins de santé, et peuvent également inclure la gestion des connaissances cliniques.
[SOURCE: ISO 13940:2015, 3.1.1]
3.1.2
problème de santé
représentation d'une situation liée à la santé d'un sujet de soins, telle qu'identifiée par un ou plusieurs
acteur(s) de soins de santé
[SOURCE: ISO 13940:2015, 6.3]
3.1.3
question de soins de santé
représentation d'une question liée à la santé d'un sujet de soins et/ou à la délivrance de soins de santé à
ce sujet de soins, telle qu'identifiée par un ou plusieurs acteur(s) de soins de santé
[SOURCE: ISO 13940:2015, 6.2]
3.1.4
état de santé
fonctions physiques et mentales, structures anatomiques, facteurs personnels, activités, participation
et aspects environnementaux constitutifs des indicateurs de santé combinés d'un sujet des soins
[SOURCE: ISO 13940:2015, 6.5]
2 © ISO 2020 – Tous droits réservés
3.1.5
condition de santé
aspects observés ou potentiellement observables de l'état de santé à un moment donné
[SOURCE: ISO 13940:2015, 6.4]
3.1.6
condition observée
condition de santé observée par un acteur de soins de santé
[SOURCE: ISO 13940:2015, 6.4.1]
3.2 Concepts liés au système
3.2.1
service d'information
possibilité du système de fournir un ensemble de données de sortie en fonction d'un ensemble défini de
données d'entrée
Note 1 à l'article: Le terme de service d'information est utilisé de manière cohérente dans le présent document
pour désigner les services fournis par le système d'information.
Note 2 à l'article: Les services d'informations de santé sont des services liés aux soins de santé fournis par les
systèmes d'information de santé.
3.2.2
couche interstitielle
technologie d'activation du système d'intégration d'applications d'entreprise décrivant une partie de
logiciel associant plusieurs applications logicielles de façon à leur permettre d'échanger des données
Note 1 à l'article: Les interfaces de programmation communes entre applications sont considérées comme des
couches interstitielles. Par exemple, ODBC (Open Database Connectivity) permet aux applications d'accéder à
toutes les bases de données qui prennent en charge l'interface ODBC.
Note 2 à l'article: Les services HISA appartiennent à des parties de l'architecture qui constituent la couche
interstitielle. Ils traitent d'aspects essentiels pour l'organisme de santé, tels que l'ouverture fondamentale et
le partage d'informations et de logique applicative. Dans le présent document, l'utilisation du terme «couche
interstitielle» se présente dans le contexte de l'HISA, associée à des services.
3.2.3
intégration d'applications d'entreprise
utilisation de principes d'architecture de logiciels et systèmes informatiques pour intégrer un ensemble
d'applications informatiques d'entreprise
3.2.4
objet
modèle d'une entité, caractérisé par son comportement et son état, encapsulé et distinct de tout
autre objet
Note 1 à l'article: Cette définition se rapporte au terme «objet» au sens architectural [c'est-à-dire conformément
à l'ISO/IEC 10746 (toutes les parties)]. Cela n'exclut pas l'utilisation du terme dans son acception courante en tant
qu'entité proprement dite où, par exemple, un «objet de processus» d'un processus de soins de santé/clinique
représente l'état de santé d'un sujet de soins.
[SOURCE: ISO/IEC 10746-2:2009, 8.1, modifiée — allégée.]
3.2.5
objet d'entreprise
objet permettant de modéliser une entité d'entreprise
3.2.6
classe
abstraction de la connaissance et du comportement d'un ensemble de choses similaires
Note 1 à l'article: Une classe UML est une description d'un ensemble d'objets partageant les mêmes attributs,
opérations, méthodes, relations et sémantique.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.577, modifiée — La Note 1 à l'article a été remplacée.]
3.3 Concepts liés à l'organisme
3.3.1
organisme
personne ou groupe de personnes ayant un rôle avec les responsabilités, l'autorité et les relations lui
permettant d'atteindre ses objectifs
Note 1 à l'article: Un organisme peut être public ou privé.
Note 2 à l'article: Le domaine d'application d'un organisme peut inclure des interfaces pertinentes avec des
organismes externes.
[SOURCE: ISO 9000:2015, 3.2.1, modifiée — La Note 1 à l'article a été simplifiée et la Note 2 à l'article a
été remplacée.]
3.3.2
acteur de soins de santé
organisation ou personne participant aux soins de santé
[SOURCE: ISO 13940:2015, 5.2, modifiée — Les Notes 1 à 3 à l'article ont été supprimées.]
3.3.3
prestataire de soins de santé
acteur de soins de santé à qui un ou plusieurs mandats de période de soins peuvent être confiés
[SOURCE: ISO 13940:2015, 5.2.3, modifiée — Les Notes 1 à 3 à l'article ont été supprimées.]
3.3.4
sujet des soins
acteur de soins de santé avec un rôle de personne, qui cherche à recevoir, reçoit ou a reçu des soins
de santé
Note 1 à l'article: Parmi les synonymes, on peut citer «patient» et «sujet des soins de santé».
[SOURCE: ISO 13940:2015, 5.2.1, modifiée — La Note 1 à l'article a été remplacée et les Exemples n'ont
pas été inclus.]
3.3.5
organisation de soins de santé
prestataire de soins de santé ayant un rôle d'organisation
[SOURCE: ISO 13940:2015, 5.2.3.1, modifiée — Les Notes 1 à 4 à l'article ont été supprimées et les
Exemples n'ont pas été inclus.]
3.3.6
rôle
fonction ou poste
[SOURCE: ISO 13940:2015, 3.3.5]
4 © ISO 2020 – Tous droits réservés
3.4 Concepts liés à la communauté
3.4.1
communauté
configuration d'objets formée pour atteindre un objectif
Note 1 à l'article: L'objectif est exprimé sous la forme d'un contrat précisant la manière dont l'objectif peut être
atteint.
3.4.2
fédération
communauté de domaines
3.4.3
objectif
avantage pratique ou effet prévu, exprimé en tant que préférences d'états à venir
Note 1 à l'article: Certains objectifs sont en cours, d'autres sont terminés lorsqu'ils ont été atteints.
3.5 Concepts liés au comportement
3.5.1
ressource
actif utilisé ou consommé lors de l'exécution d'un processus
Note 1 à l'article: Une attribution de ressource peut gêner d'autres comportements pour lesquels ladite ressource
est essentielle.
Note 2 à l'article: Une ressource consommable peut devenir indisponible après un certain nombre d'utilisations
ou un certain temps (si une durée ou un délai d'expiration a été précisé pour la ressource).
[SOURCE: ISO 13940:2015, 3.4.1, modifiée — Les Notes 1 et 2 à l'article ont été remplacées.]
3.5.2
processus
ensemble d'activités corrélées ou en interaction qui utilise des éléments d'entrée pour produire un
résultat escompté
Note 1 à l'article: De nos jours, un objectif important du système de santé est sa capacité à être organisé en
processus intégrés de façon à garantir la continuité des soins. Les processus peuvent être considérés au sein d'un
seul organisme ou à travers plusieurs organismes.
Note 2 à l'article: Les éléments d'entrée d'un processus sont généralement les éléments de sortie d'autres
processus.
Note 3 à l'article: Le processus de soins de santé est fourni dans l'organisme de soins.
Note 4 à l'article: Les processus d'un organisme sont généralement planifiés et mis en œuvre dans des conditions
maîtrisées afin d'apporter une valeur ajoutée.
Note 5 à l'article: Lorsque la conformité de l'élément de sortie résultant ne peut pas être immédiatement ou
économiquement vérifiée, le processus est souvent qualifié de «procédé spécial».
Note 6 à l'article: Lorsqu'une demande de soins est acceptée par un prestataire de soins de santé, il est établi
un mandat de soins dans lequel sont précisées la mission et l'autorisation permettant au prestataire de soins
d'apporter les prestations de soins de santé au sujet de soins. Ce mandat est la base des décisions concernant
les actes de soins de santé devant être réalisés, les objectifs et le réceptacle des preuves matérielles fournies
par le processus clinique. Ces vérifications permettent d'évaluer la qualité de chaque activité de soins de santé
ou série d'activités de soins de santé en formulant des conditions préalables à une possible reprise, réparation,
mise au rebut ou dérogation après production (voir les définitions respectives dans l'ISO 9000:2015, 3.12.8,
3.12.9, 3.12.10 et 3.12.5). Enfin, le manda
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.