ISO 12967-3:2020
(Main)Health informatics — Service architecture (HISA) — Part 3: Computational viewpoint
Health informatics — Service architecture (HISA) — Part 3: Computational viewpoint
This document specifies the fundamental characteristics of the computational model implemented by a specific architectural layer of the information system (i.e. the service architecture) to provide a comprehensive and integrated interface to the common enterprise information and to support the fundamental business processes of the healthcare organization, as defined in ISO 12967‑1. The computational model is specified without any explicit or implicit assumption about the physical technologies, tools or solutions to adopt for its physical implementation in the various target scenarios. The specification is nevertheless formal, complete and non-ambiguous enough to allow implementers to derive an efficient design of the system in the specific technological environment which will be selected for the physical implementation. The computational model specified in this document provides the basis for ensuring consistency between different engineering and technology specifications (including programming languages and communication mechanisms) since they are intended to be consistent with the same computational object model. This consistency allows open inter-working and portability of components in the resulting implementation. This document does not aim at representing a fixed, complete, specification of all possible interfaces that might be necessary for any requirement of any healthcare enterprise. It specifies only a set of characteristics — in terms of overall organization and individual computational objects, identified as fundamental and common to all healthcare organizations, and that are satisfied by the computational model implemented by the service architecture. Preserving consistency with the provisions of this document, physical implementations of the computational model specified in this document can allow extensions in order to support additional and local requirements. Extensions can include both the definition of additional properties of the objects of the computational model specified in this document and the implementation of entirely new objects. Also, the computational model specified in this document can be extendable over time according to the evolution of the applicable standardization initiatives, in accordance to the methodology defined in ISO 12967‑1:2020, Clause 7, which identifies a set of healthcare common information services, describing the requirements behind them and the methodology through which they will be used. The information services specified in this document are only the minimal set identifiable according to the identified requirements of the healthcare enterprise, and constituting the service architecture (i.e. the integration platform) to serve as the basis for healthcare applications, e.g. EHR or patient administration.
Informatique de santé — Architecture de service — Partie 3: Point de vue informatique
Le présent document spécifie les caractéristiques fondamentales du modèle de traitement mis en place par une couche architecturale spécifique du système d'informations (c'est-à-dire l'architecture de service) pour assurer une interface cohérente et intégrée aux données d'entreprise communes et prendre en charge les processus métier fondamentaux de l'organisme de santé, tel que défini dans l'ISO 12967-1. Le modèle de traitement est spécifié sans émettre d'hypothèse explicite ou implicite sur les technologies physiques, les outils ou les solutions à adopter pour sa mise en œuvre physique dans le cadre des différents scénarios cible. La spécification n'en est pas moins formelle, exhaustive et sans ambiguïté, afin de permettre aux implémenteurs de prévoir une conception efficace du système dans l'environnement technologique spécifique sélectionné pour sa mise en œuvre physique. Le modèle de traitement spécifié dans le présent document fournit la base permettant de garantir la cohérence des différentes spécifications d'ingénierie et de technologie (notamment des langages de programmation et des mécanismes de communication) étant donné qu'elles sont censées être conformes au même modèle d'objet de traitement. Cette cohérence permet de garantir l'interfonctionnement ouvert et la portabilité des composants dans la mise en place finale. Le présent document n'a pas pour objet d'être une représentation fixe et exhaustive de toutes les interfaces possibles susceptibles d'être nécessaires aux exigences d'une entreprise de santé. Il spécifie simplement un ensemble de caractéristiques (en termes d'objets organisationnels globaux et de traitement individuels) identifiées comme étant essentielles et communes à tous les organismes de santé et que le modèle de traitement mis en place par l'architecture de service doit satisfaire. Tout en préservant la cohérence avec les dispositions du présent document, les mises en place physiques du modèle de traitement spécifié dans le présent document peuvent permettre des extensions afin de répondre à des exigences supplémentaires et locales. Les extensions peuvent inclure aussi bien la définition de propriétés supplémentaires d'objets du modèle de traitement spécifié dans le présent document que la mise en œuvre d'objets totalement nouveaux. De même, le modèle de traitement spécifié dans le présent document peut être étendu dans le temps en fonction de l'évolution des initiatives de normalisation applicables, conformément à la méthodologie définie dans l'ISO 12967-1:2020, Article 7, qui identifie un ensemble de services d'informations communs au domaine de la santé, en décrivant les exigences sous-jacentes et la méthodologie en fonction de laquelle ils seront utilisés. Les services d'informations spécifiés dans le présent document ne correspondent qu'au plus petit ensemble de services d'informations identifiable en fonction des exigences identifiées de l'entreprise de santé et constituant l'architecture de service (c'est-à-dire la plateforme d'intégration) servant de base aux applications de santé, par exemple DIS ou administration des patients.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 12967-3
Second edition
2020-11
Health informatics — Service
architecture (HISA) —
Part 3:
Computational viewpoint
Informatique de santé — Architecture de service —
Partie 3: Point de vue informatique
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 .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviated terms . 2
5 Methodological principles . 2
5.1 General . 2
5.2 Clusters of objects . 2
5.3 Computational language . 3
5.4 The computational objects and interfaces . 4
5.5 Interactions . 5
6 General characteristics of the model . 6
6.1 The two types of computational objects for handling the information . 6
6.2 The ‘basic’ information services . 6
6.2.1 General requirements . 6
6.2.2 ‘Add’ basic information services . 7
6.2.3 "Update" basic information services . 8
6.2.4 "Delete" basic information services .10
6.2.5 "Detail" basic information services .12
6.2.6 "List" basic information services .13
6.3 General-purpose interface .15
6.3.1 General.15
6.3.2 List of information services .16
6.3.3 Behavioural specifications .16
6.4 The eHealth business-related interfaces supporting the workflow computational
objects . .17
6.4.1 General.17
6.4.2 eHealth business-related services managing healthcare workflows .17
6.4.3 Interfaces supporting the “Subject of care workflow” .17
6.4.4 Interfaces supporting the “Healthcare information workflow” .19
6.4.5 Interfaces supporting the “Activity management workflow” .21
6.4.6 Behavioural specifications, common to the eHealth business-related services .23
6.5 Common requirements of the interfaces .24
6.5.1 Interface documentation and organization .24
6.5.2 Naming criteria .24
6.5.3 Data types .25
6.5.4 Structure and organization of the interfaces .25
Annex A (informative) Example of services.27
Annex B (informative) HISA and FHIR® .29
Bibliography .33
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-3: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);
— reference to further standards, such as HL7® and FHIR®;
— 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.
iv © ISO 2020 – All rights reserved
Introduction
The ISO 12967 series specifies fundamental requirements for 'information infrastructure' and provides
guidance 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 healthcare specific service architecture), distinct from individual applications and
accessible throughout the whole information system through information services, as shown in
Figure 1.
Figure 1 — Scope of the ISO 12967 series
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 service architecture. 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 ISO 12967-1.
b) Information viewpoint: specifies the fundamental semantics of the information model to be
implemented by the service architecture to integrate the enterprise’s common data and to support
the enterprise requirements formalized in ISO 12967-1. It also provides guidance on how one
individual enterprise can extend the ISO 12967 series information 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.
c) Computational viewpoint: specifies the scope and characteristics of the information services that
should be provided by the service architecture for allowing access to the common data as well as for
the execution of the business logic supporting the enterprise processes identified in the information
viewpoint and in ISO 12967-1. It also provides guidance on how one individual enterprise can
specify additional information services needed to support local specific requirements in terms of
common business logic to be implemented.
Computational viewpoint is specified in this document.
1)
ISO 12967-1:2020, Annex C includes an explanation of ISO 23903:— and its relevance in regard to the
ISO 12967 series, for integration with other International Standards such as ISO 13940.
1) Under preparation. Stage at the time of publication: ISO/DIS 23903:2020.
vi © ISO 2020 – All rights reserved
INTERNATIONAL STANDARD ISO 12967-3:2020(E)
Health informatics — Service architecture (HISA) —
Part 3:
Computational viewpoint
1 Scope
This document specifies the fundamental characteristics of the computational model implemented
by a specific architectural layer of the information system (i.e. the service architecture) to provide
a comprehensive and integrated interface to the common enterprise information and to support
the fundamental business processes of the healthcare organization, as defined in ISO 12967-1. The
computational model is specified without any explicit or implicit assumption about the physical
technologies, tools or solutions to adopt for its physical implementation in the various target scenarios.
The specification is nevertheless formal, complete and non-ambiguous enough to allow implementers to
derive an efficient design of the system in the specific technological environment which will be selected
for the physical implementation.
The computational model specified in this document provides the basis for ensuring consistency
between different engineering and technology specifications (including programming languages and
communication mechanisms) since they are intended to be consistent with the same computational
object model. This consistency allows open inter-working and portability of components in the resulting
implementation.
This document does not aim at representing a fixed, complete, specification of all possible interfaces
that might be necessary for any requirement of any healthcare enterprise. It specifies only a set of
characteristics — in terms of overall organization and individual computational objects, identified as
fundamental and common to all healthcare organizations, and that are satisfied by the computational
model implemented by the service architecture.
Preserving consistency with the provisions of this document, physical implementations of the
computational model specified in this document can allow extensions in order to support additional and
local requirements. Extensions can include both the definition of additional properties of the objects of
the computational model specified in this document and the implementation of entirely new objects.
Also, the computational model specified in this document can be extendable over time according to
the evolution of the applicable standardization initiatives, in accordance to the methodology defined
in ISO 12967-1:2020, Clause 7, which identifies a set of healthcare common information services,
describing the requirements behind them and the methodology through which they will be used.
The information services specified in this document are only the minimal set identifiable according
to the identified requirements of the healthcare enterprise, and constituting the service architecture
(i.e. the integration platform) to serve as the basis for healthcare applications, e.g. EHR or patient
administration.
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 12967-1:2020, Health informatics — Service architecture — Part 1: Enterprise viewpoint
ISO 12967-2:2020, Health informatics — Service architecture — Part 2: Information 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
interface
abstraction of the behaviour of an object which consists of a subset of the possible interaction
mechanisms of that object, together with the set of constraints when that interaction occurs
3.2
computational object
object as seen in a computational viewpoint representing the functional decomposition of a system
showing a state and behaviour as well as interactions through interfaces with other computational objects
3.3
subject of care
patient
subject of healthcare
healthcare actor with a person role; who seeks to receive, is receiving, or has received healthcare
[SOURCE: ISO 13940:2015, 5.2.1, modified — Note and examples omitted.]
4 Abbreviated terms
EHR Electronic Health Record
HISA Health Informatics — Service Architecture
ODP Open Distributed Processing
UML Unified Modeling Language
5 Methodological principles
5.1 General
This document encompasses the computational viewpoint, which is concerned in answering HISA
design aspects through the functional decomposition of the system into a set of computational objects
that interact at interfaces, also enabling distribution. HISA will thus be further specified in terms of
computational objects, which manage information and provide services, and their interfaces, starting
from the clusters of objects identified in ISO 12967-1 and further detailed in ISO 12967-2.
5.2 Clusters of objects
ISO 12967-1 has identified the scope, need for, and use of the ISO 12967 series by both developers
and end users. It has described the scope of the business objects from the organization's viewpoint,
by summarizing the related user activities and requirements through natural language. During this
process the main healthcare common clusters of objects have been identified in ISO 12967-1:
a) Subject of care objects
These objects handle the information necessary for supporting the users’ activities that are
identified in the “Subject of care workflow”.
2 © ISO 2020 – All rights reserved
b) Activity management objects
These objects handle the information necessary for supporting the users’ activities that are
identified in the “Activity Management workflow”.
c) Healthcare information objects
These objects handle the information necessary for supporting the users’ activities that are
identified in the “Healthcare Information workflow”.
d) Users and authorization objects
These objects handle the information necessary for supporting the users’ activities related to the
management of users and authorizations.
e) Resources objects
These objects handle the information necessary for supporting the users’ activities related to the
management of resources.
f) Classification objects
These objects handle the information necessary for supporting the users’ activities related to the
management of classifications, coding criteria and dictionaries.
g) Messaging objects
These objects handle the information necessary for supporting the structuring of data and the
communications with other systems through messaging mechanisms.
ISO 12967-2 has formalized the conceptual model of the information being manipulated by the
information services, derived from the textual descriptions contained in ISO 12967-1. For each of
the clusters of objects, an information model composed of information objects has been identified in
ISO 12967-2.
This document defines the computational model, composed of computational objects, capable of meeting
the requirements described in ISO 12967-1. It is necessary in this document to identify its relationship
to the information model, and the interfaces or access mechanisms it provides to access and manipulate
the information handled by the system, which are also referred to as ‘methods’ but more appropriately
they are in the following referred to as ‘information services’.
The individual information services provided by the computational objects are described illustrating
how they allow actual access to the information handled by the system (identifying the interfaces, the
constraints, as well as which information of the underlying overall information model is accessed), and
eventual parallel actions to be taken.
5.3 Computational language
This document is directly concerned with the distribution of processing but not with the interaction
mechanisms that enable distribution to occur. The computational specification decomposes the system
into objects performing individual functions and interacting at well-defined interfaces.
The heart of the computational language is the computational object model, which constrains the
computational specification by defining:
— the form of interface that an object can have;
— the way the interfaces can be bound and the forms of interaction which can take place at them;
— actions an object can perform, in particular the creation of new objects and interfaces.
5.4 The computational objects and interfaces
The computational objects provide the interfaces through which it is possible to access and manipulate
the information managed by the information objects described in the information viewpoint. Each
cluster itself can be seen as a computational object, providing several interfaces that comprise all
interfaces of the information objects belonging to such cluster. The computational objects are defined
at the level of the HISA object.
For each cluster of objects, there will be a set of computational objects providing interfaces allowing
the management of the common information and business logic relevant to the organization. Two types
of computational object are foreseen per cluster:
— ‘basic’ computational objects deriving directly from the corresponding information object (i.e. one
computational object per information object);
— higher-level eHealth-business related computational objects providing interfaces achieving higher-
level business logic.
Thus, the majority of the computational objects will be derived directly from the corresponding
information objects. The further higher-level computational objects also envisaged provide interfaces
achieving higher-level eHealth business logic on possibly multiple information objects within the same
operation. Such eHealth business logic is described in ISO 12967-1 and has to do with the main workflow
processes (i.e. patient management, activity management, etc.).
The basic computational objects, corresponding one-to-one to the information objects, will be equipped
with standardized lower-level basic interfaces having the scope of creating, reading, updating and
deleting — in short maintaining, listing, and getting one instance of — the main classes described in
the information viewpoint.
These basic information services allow the access to and the manipulation of each element of the
underlying model. Their availability secure the openness of the system.
Figure 2 shows an example.
Figure 2 — Example of "basic services"
NOTE 1 The basic services are detailed in 6.2.
The higher-level computational objects implement eHealth business-related transactions on the objects
of the information model, simplifying and ensuring consistency of developments and allowing the
building up of common fundamental procedures of the organization.
Figure 3 shows an example of the possible information handled by an "eHealth business-related
information service"
EXAMPLES
— Patient/person area: registering a person, patient administration, merging patient identifiers, period of
care, etc.;
— Activity management and life cycle: requests, planning, booking, etc.;
— Clinical and EHR: terminologies, classifications, problem-orientation, etc.;
4 © ISO 2020 – All rights reserved
— Resource management: standard usages, etc.
Figure 3 — Example of the information handled by an "eHealth business-related information
service"
NOTE 2 The eHealth business-related information services are detailed in 6.4.
The HISA service architecture also provides a set of interfaces relating to functionalities of general utility
for the management of the overall system, with respect to the execution of particular functionalities.
These services do not pertain to any specific cluster of objects, and are related to general-purpose
issues like session management (e.g. when consumer programs and services are communicating back
and forth, logging in and out of the system, etc.), transaction management, setting system variables, etc.
These information services will be provided by at least a further computational object equipped with
appropriate services, namely the general-purpose interface.
5.5 Interactions
Three types of interaction are envisaged in ODP: signals, operations and flows. Signals are single
actions conveying data from one object to another, while operations can be seen as “client-server”
interactions between objects in which the server object elaborates the data provided by the client or
better ‘consumer’, sending back a result. Flows can be considered as a sequence of interactions (i.e.
information exchanges) between objects pertaining to a specific domain.
The interaction type is part of the interface signature. In HISA the focus is on the interaction type
operation. For this reason, it will not be explicitly referred to in this specification. Such interaction
type implies the need to identify for each computational object the role it plays in the client-server
interaction. However, HISA prescribes the general external characteristics through which each
identified computational object provides interfaces, while the interaction amongst the computational
objects is not part of this document. Thus, the role is always “server”.
NOTE Of the three types of interaction, operations are the ones that present the service-oriented call/return,
or client-server pattern required in the service architecture. The other interaction types can, when necessary, be
described as particular type of operations.
6 General characteristics of the model
6.1 The two types of computational objects for handling the information
The computational objects provide the interfaces through which it is possible to access and manipulate
the information managed by the information objects described in the information viewpoint. An
example of the two types of computational objects is displayed in Figure 4 and shall be referred to in the
following as ‘basic’ and eHealth business-related’ computational objects according to the terminology
adopted in 5.4. The information services that these will expose shall also be referred to in the following
as ‘basic’ and business-related’.
Figure 4 — types of computational object
6.2 The ‘basic’ information services
6.2.1 General requirements
For each class belonging to the seven clusters of objects defined in ISO 12967-1 and specified in the
information viewpoint, the service architecture shall be equipped with a computational object each of
which is in turn equipped with a set of information services allowing to access and to manipulate every
concept (i.e. objects and properties) of the class. The generic structure is displayed in Figure 5.
Figure 5 — Generic structure of the computational objects
6 © ISO 2020 – All rights reserved
The following information services shall be available in the basic computational objects. Each
information service has a scope and a description. Many of the information service specification tables
also include an example.
6.2.2 ‘Add’ basic information services
6.2.2.1 General
The “add” information services shall allow the client of the computational object to create instances of
HISA objects.
6.2.2.2 List of information services
6.2.2.2.1 Information service add
Information add
service
Scope Shall be used to create a new instance of a HISA object.
Description The instances that shall be added are the individual HISA classes specified in ISO 12967-
2:2020, Clause 7. The instance, its class-specific attribute set, and the common system and
version properties shall be created through this information service.
Example The addition of a new person in the system shall be accomplished by calling the add
information service of the person computational object [Person.add]. The caller will
pass as input several fields belonging to the class-specific attribute set (id, name,
birthTime, deceasedTime, gender, address, etc.). The information service shall also
allow the user to pass information to override any default value for its common system
and version-related attributes.
6.2.2.2.2 Information service Xadd
Information Xadd
service
Scope Shall be used to create a new instance of extended data and associate it to a HISA object.
Description The specification of the extended data object that will be created is found in ISO 12967-2:2020,
6.3.7. The instances to which the extended data shall be attached are the individual HISA
classes specified in ISO 12967-2:2020, Clause 7. The extended data properties and the common
system and version properties it comprises shall be created through this information service.
Example The calling of this information service [Person.Xadd] shall allow doing things such as adding,
among others: the digital photograph of the person to the instance of the person object, the
scanned image of the signed consent to receive treatment, etc. The semantics of the extended
datum shall be classified in its property type, the media type in the property mediaType, the
language in the language property, etc.
6.2.2.2.3 Information service Cadd
Information Cadd
service
Scope Shall be used to create a new instance of classification criteria data and associate it to a
HISA object.
Description The specification of the classification criteria data that will be created is found in ISO 12967-
2:2020, 6.3.10. The instances to which the classification data shall be attached are the individ-
ual HISA classes specified in ISO 12967-2:2020, Clause 7. The classification data properties and
its common system and version properties shall be created through this information service.
Example Persons might be classified in healthcare organizations according to their education. The
calling of this information service [Person.Cadd] allows classifying the person according to the
criteria in use e.g. in the national, regional, or local classification in use.
6.2.2.2.4 Information service BRadd
Information BRadd
service
Scope Shall be used to create a new instance of a business rule concerning the HISA object to which it
is associated.
Description The specification of the business rule data that will be created is found in ISO 12967-2:2020,
6.3.9. The instances to which the business rule data shall be attached are the individual HISA
classes specified in ISO 12967-2:2020, Clause 7. The business rule properties and its common
system and version properties shall be created through this information service.
Example Experimental drugs are often used in specific treatments and require the identification of spe-
cific business rules for their correct usage, for example that a specific drug can be prescribed
only by certain physicians for a certain class of illnesses. In this case, the information service
[Resource.BRadd] shall be used once the business rule is defined.
6.2.2.3 Behavioural specifications
It is up to the client of the object (i.e. the caller) to pass valid data as input for the class-specific properties
and for those system and version attributes for which the default values should be overridden.
The system shall generate appropriate values for the common system and version attributes of the HISA
class when the instance is created, for those parameters that are not passed by the caller. In particular
the following.
— Instance identifier shall be unique within the open distributed processing environment of the
system within the enterprise. A unique identifier of the HISA class may be specified by the caller of
the operation. In this case the service shall verify the uniqueness of the identifier.
— System shall take care of managing state changes by adding dynamically and automatically the
values that record the changes occurred in the specific properties of the class or when extended
data, classification data and business rules are attached to it, thus keeping track of the life cycle of
the instance during time. The state changes class is specified in ISO 12967-2:2020, 6.3.8.
— Information service shall return to the client at least the set of common attributes related to the
HISA object created. Such information shall include a value indicating successful execution of the
operation or an error indicating the reason for failure.
— Information service shall implement all integrity checks with respect to the information passed by
the client of operation, aborting it if the operation would lead to an inconsistent informational state.
6.2.3 "Update" basic information services
6.2.3.1 General
The “update” information services shall allow the client of the operation to update instances of HISA
objects.
6.2.3.2 List of information services
6.2.3.2.1 Information service update
Information update
service
Scope Shall be used to update an existing instance of a HISA object.
Description The instances that shall be updated are the individual HISA classes specified in ISO 12967-
2:2020, Clause 7. The instance, its class-specific attribute set, and the common system and
version properties shall be updated through this information service.
8 © ISO 2020 – All rights reserved
Information update
service
Example The updating of a person in the system shall be accomplished by calling the update informa-
tion service of the person computational object [Person.update]. The information service shall
also allow the user to pass information to override any default value for its common system
and version-related attributes.
6.2.3.2.2 Information service Xupdate
Information Xupdate
service
Scope Shall be used to update an existing instance of the extended data associated to a HISA object.
Description The extended data instances that shall be updated are the ones already attached to the indi-
vidual HISA classes specified in ISO 12967-2:2020, Clause 7. The extended data object and its
common system and version properties shall be updated through this information service.
Example The updating of the properties of the extended data of a person in the system shall be accom-
plished by calling the update information service of the person computational object [Person.
Xupdate]. The information service shall also allow the user to pass information to override any
default value for the extended data’s common system and version-related attributes.
6.2.3.2.3 Information service Cupdate
Information Cupdate
service
Scope Shall be used to update an existing instance of classification data associated to a HISA object.
Description The classification data instances that shall be updated are the ones already attached to the
individual HISA classes specified in ISO 12967-2:2020, Clause 7. The classification object and
its common system and version properties shall be updated through this information service.
Example The updating of the classification criteria of a person in the system shall be accomplished by
calling the update information service of the person computational object [Person.Cupdate].
The information service shall also allow the user to pass information to override any default
value for its common system and version-related attributes.
6.2.3.2.4 Information service BRupdate
Information BRupdate
service
Scope Shall be used to update an existing instance of a business rule associated to the HISA object.
Description The specification of the business rule that will be created is found in ISO 12967-2:2020, 6.3.9.
The instances to which the business rule data shall be attached are the individual HISA classes
specified in ISO 12967-2:2020, Clause 7. The business rule properties and its common system
and version properties shall be updated through this information service.
Example Experimental drugs are often used in treatments and need specific business rules to be
identified for their correct usage, e.g., that a specific drug can be prescribed only by certain
physicians for a certain class of illnesses. When these business rules need to be updated, the
information service [Resource.BRupdate] shall be used.
6.2.3.3 Behavioural specifications
It is up to the client of the object to pass valid data as input for the class specific properties and for those
system and version attributes for which the default values should be overridden.
The system shall generate and/or update the appropriate values for the common system and version
attributes of the HISA class when it is updated. In particular the following.
— Operation shall require as input the common attributes necessary for the update information.
— Instance identifier shall never be updated.
— Update shall not occur if the timestamp of the instance to be updated differs from the timestamp
received as input, since this indicates that the value in the HISA system has changed since the client
originally read the instance from the system. The change occurred while the caller was performing
the operation and the update would cause inconsistency in the common information heritage.
NOTE Such an approach in managing concurrent access to data is generally called “optimistic-locking”.
— System shall take care of managing state changes when the update operation is invoked by adding
dynamically and automatically the values that record the changes occurred in the specific properties
of the class or when extended data, classification data and business rules attached to it are updated,
thus keeping track of the life cycle of the instance during time. The state changes class is specified
in ISO 12967-2:2020, 6.3.8.
— Operations shall return to the client at least the set of common attributes related to the HISA object
updated with the update operation. Such information shall include a value indicating successful
execution of the operation or an error indicating the reason for failure.
— Operations shall implement all integrity checks with respect to the information passed by the client
of operation, aborting it if the operation would lead to an inconsistent informational state.
6.2.4 "Delete" basic information services
6.2.4.1 General
The “delete” information services shall allow the client of the operation to logically delete instances of
HISA objects.
6.2.4.2 List of information services
6.2.4.2.1 Information service delete
Information delete
service
Scope Shall be used to logically delete an existing instance of a HISA object.
Description The instances that shall be logically deleted are the individual HISA classes specified in
ISO 12967-2:2020, Clause 7. The object, its class-specific attribute set, and its common system
and version properties shall be deleted through this information service
6.2.4.2.2 Information service Xdelete
Information Xdelete
service
Scope Shall be used to logically delete an existing instance of the extended data associated to a
HISA object.
Description The extended data instances that are logically deleted shall be the ones already attached to the
individual HISA classes specified in ISO 12967-2:2020, Clause 7. The extended data object and
its common system and version properties shall be logically deleted through this information
service.
6.2.4.2.3 Information service Cdelete
Information Cdelete
service
Scope Shall be used to logically delete an existing instance of classification data associated to a
HISA object.
10 © ISO 2020 – All rights reserved
Information Cdelete
service
Description The classification data instances that shall be logically deleted are the ones already attached to
the individual HISA classes specified in ISO 12967-2:2020, Clause 7. The object and its common
system and version attributes shall be logically deleted through this information service.
6.2.4.2.4 Information service BRdelete
Information BRdelete
service
Scope Shall be used to logically delete an existing instance of a business rule associated to the
HISA object.
Description The specification of the business rule that shall be logically deleted is found in ISO 12967-
2:2020, 6.3.9. The instances to which the business rule data is attached are the individual HISA
classes specified in ISO 12967-2:2020, Clause 7. The business rule properties and its common
system and version properties shall be deleted through this information service.
6.2.4.2.5 Information service Pack
Information Pack
service
Scope Shall be used to physically delete the logically deleted instances.
Description The logical deletion allows keeping in the system instances for which clients have requested
the logical deletion. This functionality shall be available mainly for system administration
purposes, to physically remove elements that have been logically deleted and can safely be
removed from the system.
Operation shall require as input the representation of the information object to carry out
the Pack.
6.2.4.3 Behavioural specifications
The system shall generate and/or update the appropriate values for the common system and version
attributes of the HISA class when it is logically deleted. In particular the following.
— Operation shall require as input the common attributes necessary for the delete information.
— Logical deletion shall cause the “isDeleted” attribute of the object to be set to “True”, without
physically removing the instance from the common information heritage of the enterprise.
— Delete operation shall not occur if the timestamp of the instance to be logically deleted differs from
the timestamp received as input, since this indicates that
...
NORME ISO
INTERNATIONALE 12967-3
Deuxième édition
2020-11
Informatique de santé — Architecture
de service —
Partie 3:
Point de vue informatique
Health informatics — Service architecture (HISA) —
Part 3: Computational 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 .iv
Introduction .v
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 2
4 Termes abrégés . 2
5 Principes méthodologiques . 2
5.1 Généralités . 2
5.2 Groupes d'objets . 3
5.3 Langage de traitement . 4
5.4 Objets de traitement et interfaces . 4
5.5 Interactions . 6
6 Caractéristiques générales du modèle . 6
6.1 Deux types d'objets de traitement pour la gestion des informations . 6
6.2 Services d'informations «de base» . 6
6.2.1 Exigences générales . 6
6.2.2 Services d'informations de base «ajout» . 7
6.2.3 Services d'informations de base «mise_à_jour» . 9
6.2.4 Services d'informations de base «suppression».11
6.2.5 Services d'informations de base «détail» .13
6.2.6 Services d'informations de base «liste» .15
6.3 Interface à usage général .17
6.3.1 Généralités .17
6.3.2 Liste des services d'informations .17
6.3.3 Spécifications comportementales .18
6.4 Interfaces liées au secteur de l’eSanté prenant en charge les objets de traitement
des workflows .18
6.4.1 Généralités .18
6.4.2 Services liés au domaine de l'eSanté gérant les workflows de santé .18
6.4.3 Interfaces prenant en charge le workflow «Sujet des soins» .19
6.4.4 Interfaces prenant en charge le workflow «Informations de soins de santé» .21
6.4.5 Interfaces prenant en charge le workflow «Gestion d'activité» .22
6.4.6 Spécifications comportementales communes à tous les services liés
au domaine de l'eSanté . .25
6.5 Exigences communes des interfaces .26
6.5.1 Documentation et organisation de l'interface .26
6.5.2 Critères d'attribution de noms .26
6.5.3 Types de données .27
6.5.4 Structure et organisation des interfaces .27
Annexe A (informative) Exemples de services .29
Annexe B (informative) Normes HISA et FHIR® .31
Bibliographie .35
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é 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-3: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);
— référence à d'autres normes, telles que HL7® et FHIR®;
— mises à jour de la Bibliographie.
Une liste de toutes les parties de la série ISO 12967 est disponible 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.
iv © ISO 2020 – Tous droits réservés
Introduction
La série ISO 12967 spécifie les exigences fondamentales d'une «infrastructure d'informations» et établit
les principes généraux de description, de planification et de développement de nouveaux systèmes et
d'intégration des systèmes d'informations existants, tant dans le cadre d'une entreprise qu'à travers
différents organismes de santé, grâce à la mise en place d'une architecture intégrant les données
communes et la logique métier dans une couche architecturale spécifique (à savoir, l’architecture de
service propre au domaine de la santé), distincte des applications individuelles et accessible par tout le
système d'information grâce à des services d’informations (voir Figure 1).
Figure 1 — Domaine d'application de la série ISO 12967
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 d'appuyer grâce aux informations et aux fonctionnalités de
l'architecture de service. Il fournit également des recommandations quant à la manière dont une
entreprise individuelle (par exemple un système de santé régional, un grand hôpital ou toute autre
institution dans laquelle 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 l'ISO 12967-1.
b) Point de vue de l'information: il spécifie les aspects sémantiques fondamentaux du modèle
d'information à mettre en œuvre par l’architecture de service afin d'intégrer les données communes
de l'entreprise et de prendre en charge les exigences de l'entreprise formalisées dans l'ISO 12967-1.
Il donne également des recommandations quant à la manière dont une entreprise individuelle peut
étendre le modèle d'information de la série ISO 12967 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
d’informations qu'il convient de fournir via l’architecture de service pour accéder aux données
communes et exécuter la logique applicative prenant en charge les processus d'entreprise
identifiés dans le point de vue de l'information et dans l’ISO 12967-1. Il fournit également des
recommandations relatives à la manière dont une entreprise individuelle peut spécifier des services
d’informations 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 le présent document.
1)
L'ISO 12967-1:2020, 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 internationales, telles
que l'ISO 13940.
1) En cours d'élaboration. Stade à la date de publication: ISO/DIS 23903:2020.
vi © ISO 2020 – Tous droits réservés
NORME INTERNATIONALE ISO 12967-3:2020(F)
Informatique de santé — Architecture de service —
Partie 3:
Point de vue informatique
1 Domaine d'application
Le présent document spécifie les caractéristiques fondamentales du modèle de traitement mis en
place par une couche architecturale spécifique du système d'informations (c'est-à-dire l’architecture
de service) pour assurer une interface cohérente et intégrée aux données d'entreprise communes et
prendre en charge les processus métier fondamentaux de l'organisme de santé, tel que défini dans
l'ISO 12967-1. Le modèle de traitement est spécifié sans émettre d'hypothèse explicite ou implicite sur
les technologies physiques, les outils ou les solutions à adopter pour sa mise en œuvre physique dans
le cadre des différents scénarios cible. La spécification n'en est pas moins formelle, exhaustive et sans
ambiguïté, afin de permettre aux implémenteurs de prévoir une conception efficace du système dans
l'environnement technologique spécifique sélectionné pour sa mise en œuvre physique.
Le modèle de traitement spécifié dans le présent document fournit la base permettant de garantir la
cohérence des différentes spécifications d'ingénierie et de technologie (notamment des langages de
programmation et des mécanismes de communication) étant donné qu'elles sont censées être conformes
au même modèle d’objet de traitement. Cette cohérence permet de garantir l'interfonctionnement
ouvert et la portabilité des composants dans la mise en place finale.
Le présent document n'a pas pour objet d'être une représentation fixe et exhaustive de toutes les
interfaces possibles susceptibles d'être nécessaires aux exigences d'une entreprise de santé. Il spécifie
simplement un ensemble de caractéristiques (en termes d'objets organisationnels globaux et de
traitement individuels) identifiées comme étant essentielles et communes à tous les organismes de
santé et que le modèle de traitement mis en place par l’architecture de service doit satisfaire.
Tout en préservant la cohérence avec les dispositions du présent document, les mises en place physiques
du modèle de traitement spécifié dans le présent document peuvent permettre des extensions afin
de répondre à des exigences supplémentaires et locales. Les extensions peuvent inclure aussi bien la
définition de propriétés supplémentaires d’objets du modèle de traitement spécifié dans le présent
document que la mise en œuvre d'objets totalement nouveaux.
De même, le modèle de traitement spécifié dans le présent document peut être étendu dans le temps
en fonction de l'évolution des initiatives de normalisation applicables, conformément à la méthodologie
définie dans l’ISO 12967-1:2020, Article 7, qui identifie un ensemble de services d'informations communs
au domaine de la santé, en décrivant les exigences sous-jacentes et la méthodologie en fonction de
laquelle ils seront utilisés.
Les services d'informations spécifiés dans le présent document ne correspondent qu’au plus petit
ensemble de services d’informations identifiable en fonction des exigences identifiées de l'entreprise de
santé et constituant l’architecture de service (c'est-à-dire la plateforme d'intégration) servant de base
aux applications de santé, par exemple DIS ou administration des patients.
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 12967-1:2020, Informatique de santé — Architecture de service — Partie 1: Point de vue de l’entreprise
ISO 12967-2:2020, Informatique de santé — Architecture de service — Partie 2: Point de vue de l’information
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
interface
abstraction du comportement d'un objet composée d'un sous-ensemble des mécanismes d'interaction
possibles dudit objet, avec l'ensemble de contraintes lorsque cette interaction a lieu
3.2
objet de traitement
objet perçu du point de vue informatique représentant la décomposition fonctionnelle d'un système et
montrant un état, un comportement et des interactions par l'intermédiaire d'interfaces avec d'autres
objets de traitement
3.3
sujet des soins
patient
sujet des soins de santé
acteur de soins de santé avec un rôle de personne, qui cherche à recevoir, reçoit ou a reçu des soins
de santé
[SOURCE: ISO 13940:2015, 5.2.1, modifiée — La Note et les exemples n'ont pas été inclus.]
4 Termes abrégés
DIS Dossier informatisé de santé
HISA Health Informatics Service Architecture (architecture des services d'information de santé)
ODP Open Distributed Processing (traitement réparti ouvert)
UML Unified Modeling Language (langage de modélisation unifié)
5 Principes méthodologiques
5.1 Généralités
Le présent document porte sur le point de vue informatique, qui vise à répondre aux aspects liés à
la conception de l’architecture HISA par la décomposition fonctionnelle du système en un ensemble
d'objets de traitement qui interagissent au niveau des interfaces, tout en permettant la répartition. Par
conséquent, le système HISA sera approfondi en termes d'objets de traitement (permettant de gérer les
informations et de fournir des services) et de leurs interfaces. Il s'agira en premier lieu de décrire les
groupes d'objets identifiés dans l'ISO 12967-1 et détaillés dans l’ISO 12967-2.
2 © ISO 2020 – Tous droits réservés
5.2 Groupes d'objets
L’ISO 12967-1 a identifié le domaine d'application, la nécessité de la série ISO 12967 et son utilisation tant
par les développeurs et que par les utilisateurs. Elle a décrit le domaine d'application des objets métier
du point de vue de l'organisme, en résumant les activités et les exigences associées de l'utilisateur, au
moyen d'un langage naturel. Lors de ce processus, les groupes d'objets principaux communs au domaine
de la santé ont été identifiés dans l'ISO 12967-1.
a) Objets Sujet des soins
Ces objets traitent les informations nécessaires à la prise en charge des activités des utilisateurs
identifiées dans le «workflow Sujet des soins».
b) Objets Gestion d'activité
Ces objets traitent les informations nécessaires à la prise en charge des activités des utilisateurs
identifiées dans le «workflow Gestion d'activité».
c) Objets Informations de soins de santé
Ces objets traitent les informations nécessaires à la prise en charge des activités des utilisateurs
identifiées dans le «workflow Informations de soins de santé».
d) Objets Utilisateurs et autorisations
Ces objets traitent les informations nécessaires à la prise en charge des activités des utilisateurs
liées à la gestion des utilisateurs et des autorisations.
e) Objets Ressources
Ces objets traitent les informations nécessaires à la prise en charge des activités des utilisateurs
liées à la gestion des ressources.
f) Objets Classification
Ces objets traitent les informations nécessaires à la prise en charge des activités des utilisateurs
liées à la gestion des classifications, des critères de codage et des dictionnaires.
g) Objets Messagerie
Ces objets traitent les informations nécessaires à la prise en charge de la structuration des données
et des communications avec d'autres systèmes par des mécanismes de messagerie.
L'ISO 12967-2 a formalisé le modèle conceptuel des informations manipulées par les services
d’informations, lequel est dérivé des descriptions textuelles contenues dans l'ISO 12967-1. Pour chacun
des groupes d'objets, un modèle d'information composé d'objets informations a été identifié dans
l'ISO 12967-2.
Le présent document définit le modèle de traitement (composé d'objets de traitement) permettant
de répondre aux exigences décrites dans l'ISO 12967-1. Il est nécessaire, dans le présent document,
d'identifier ses relations avec le modèle d'information, ainsi que les interfaces ou les mécanismes
d’accès qu'il propose pour pouvoir manipuler et accéder aux informations traitées par le système, qui
sont également appelées «méthodes», mais qui, de manière plus appropriée, sont ci-après appelées
«services d'informations».
Les services d'informations individuels proposés par les objets de traitement doivent être décrits en
illustrant la manière dont ils accèdent réellement aux informations traitées par le système (en identifiant
les interfaces et les contraintes, ainsi que les informations accessibles du modèle d'information global
sous-jacent) et les actions parallèles éventuelles à réaliser.
5.3 Langage de traitement
Le présent document est directement concerné par la répartition du traitement, mais sans les
mécanismes d'interaction à l'origine de cette répartition. La spécification de traitement décompose
le système en objets exécutant des fonctions individuelles et interagissant au niveau d'interfaces bien
définies.
Le cœur du langage de traitement est le modèle d'objet de traitement, qui délimite la spécification de
traitement en définissant:
— la forme de l'interface dont peut disposer un objet;
— la manière dont les interfaces peuvent être liées et les formes d'interaction qui peuvent prendre
place à leur niveau;
— les actions qu'un objet peut réaliser, en particulier la création de nouveaux objets et interfaces.
5.4 Objets de traitement et interfaces
Les objets de traitement offrent les interfaces permettant d'accéder aux informations gérées par les
objets d'informations décrits dans le point de vue de l'information, et de les manipuler. Chaque groupe
peut être perçu comme un objet de traitement, offrant des interfaces composées de toutes les interfaces
des objets d’informations appartenant audit groupe. Les objets de traitement sont définis au niveau de
l'objet HISA.
À chaque groupe d'objets correspond un ensemble d'objets de traitement offrant des interfaces de
gestion des informations communes et de la logique métier pertinentes pour l'organisme. Deux types
d'objets de traitement sont prévus par groupe:
— les objets de traitement de base dérivés directement de l'objet d'information correspondant (en
d'autres termes, il existe un objet de traitement par objet d'information);
— les objets de traitement de haut niveau liés au secteur de l’eSanté, offrant des interfaces permettant
d'atteindre un degré élevé de logique métier.
Par conséquent, la majorité des objets de traitement dérivera directement des objets d'informations
correspondants. Les objets de traitement de haut niveau supplémentaires également envisagés
permettent aux interfaces d'atteindre un degré plus élevé de logique métier propre à l’eSanté, bâti
éventuellement sur plusieurs objets d'informations dans le cadre d’une même opération. Une telle
logique métier propre à l’eSanté est décrite dans l'ISO 12967-1 et concerne les principaux processus de
workflow (c'est-à-dire la gestion des patients, la gestion d'activité, etc.).
Les objets de traitement de base, qui correspondent de manière biunivoque à des objets d'informations,
seront associés à des interfaces de base normalisées de bas niveau visant à créer, lire, mettre à jour
et supprimer (en bref, conserver, répertorier et extraire) une instance des classes principales décrites
dans le point de vue de l'information.
Ces services d'informations de base permettent d'accéder à chaque élément du modèle sous-jacent et de
les manipuler. Leur disponibilité garantit l'ouverture du système.
La Figure 2 en est un exemple.
4 © ISO 2020 – Tous droits réservés
Figure 2 — Exemple de «services de base»
NOTE 1 Les services de base sont détaillés en 6.2.
Les objets de traitement de haut niveau permettent de mettre en place des transactions liées au
domaine de l'eSanté sur les objets du modèle d'information, ce qui simplifie et garantit la cohérence
des développements et permet la mise en place de procédures fondamentales communes au sein de
l'organisme.
La Figure 3 donne un exemple d'informations possibles traitées par un «service d'information lié au
domaine de l'eSanté».
EXEMPLES
— le domaine patient/personne, notamment l'enregistrement d'une personne, l'administration des patients, la
fusion des identifiants patient, la période de soins, etc.;
— la gestion d'activité et le cycle de vie, notamment les demandes, la planification, les rendez-vous, etc.;
— les données cliniques et le dossier informatisé de santé du patient, notamment les terminologies, les
classifications, l'orientation en fonction du problème, etc.;
— la gestion des ressources, notamment les usages standard, etc.
Figure 3 — Exemple d'informations traitées par un «service d'information lié au domaine
de l'eSanté»
NOTE 2 Les services d'informations liés au domaine de l'eSanté sont détaillés en 6.4.
L’architecture de service HISA fournit également un ensemble d'interfaces portant sur les fonctionnalités
d'utilité générale pour la gestion de l'ensemble du système, et tenant compte de l'exécution de
fonctionnalités particulières.
Ces services ne dépendent pas d'un groupe d'objets particulier. Ils portent sur des questions d'ordre
général comme la gestion de session (par exemple, lorsque des programmes et services destinés aux
consommateurs communiquent entre eux, la connexion au système/déconnexion du système, etc.),
la gestion des transactions, la définition des variables système, etc. Ces services d'informations sont
fournis par au moins un autre objet de traitement disposant des services appropriés, à savoir l'interface
à usage général.
5.5 Interactions
Trois types d'interaction sont envisagés dans ODP: les signaux, les opérations et les flux. Les signaux
sont des actions uniques permettant de transmettre des données entre des objets, alors que les
opérations peuvent être perçues comme des interactions «client-serveur» entre des objets dans
lesquelles l'objet serveur traite les données fournies par le client, ou mieux le «consommateur», et
renvoie un résultat. Les flux peuvent être considérés comme une séquence d'interactions (c'est-à-dire
des échanges d'informations) entre des objets portant sur un domaine particulier.
Le type d'interaction fait partie intégrante de la signature d'interface. HISA se concentre
essentiellement sur le type d'interaction «opération». C'est la raison pour laquelle il ne sera pas abordé
de manière explicite dans la présente spécification. Ce type d'interaction implique d'identifier le rôle
que joue chacun des objets de traitement dans l'interaction client-serveur. Néanmoins, HISA précise les
caractéristiques externes générales grâce auxquelles chacun des objets de traitement identifié fournit
des interfaces, même si l'interaction entre chacun d'eux n'est pas couverte par le présent document. Par
conséquent, le rôle est toujours celui du «serveur».
NOTE Sur les trois types d'interaction, les opérations sont celles qui présentent la configuration d'appel/de
retour orientée service ou la configuration client-serveur requise dans l'architecture de service. Les autres types
d'interaction peuvent, si nécessaire, être décrits comme un type particulier d'opérations.
6 Caractéristiques générales du modèle
6.1 Deux types d'objets de traitement pour la gestion des informations
Les objets de traitement offrent les interfaces permettant d'accéder aux informations gérées par les
objets d'informations décrits dans le point de vue de l'information, et de les manipuler. La Figure 4
donne un exemple des deux types d'objets de traitement, qui doivent être appelés objets de traitement
«de base» et objets de traitement «liés au domaine de l'eSanté», conformément à la terminologie adoptée
en 5.4. Les services d'informations qui vont être présentés doivent également être qualifiés de services
«de base» et de services «liés à l’activité».
Figure 4 — Types d'objet de traitement
6.2 Services d'informations «de base»
6.2.1 Exigences générales
Pour chaque classe appartenant aux sept groupes d'objets définis dans l'ISO 12967-1 et spécifiés dans le
point de vue de l'information, l’architecture de service doit contenir un objet de traitement contenant,
lui-même, un ensemble de services d'informations permettant d'accéder et de manipuler chaque
6 © ISO 2020 – Tous droits réservés
concept (c'est-à-dire des objets et des propriétés) de la classe. La structure générique est représentée à
la Figure 5.
Figure 5 — Structure générique des objets de traitement
Les services d'informations ci-dessous doivent être disponibles dans les objets de traitement de base.
Chaque service d'information fait l'objet d'un domaine d'application et d'une description. La plupart des
tableaux de spécification des services d'informations contiennent également un exemple.
6.2.2 Services d'informations de base «ajout»
6.2.2.1 Généralités
Les services d'informations «ajout» doivent permettre au client de l'objet de traitement de créer des
instances d'objets HISA.
6.2.2.2 Liste des services d'informations
6.2.2.2.1 Service d'information «ajout»
Service ajout
d'information
Domaine Doit être utilisé pour créer une nouvelle instance d'un objet HISA.
d'application
Description Les instances à ajouter sont les classes HISA individuelles spécifiées dans l'ISO 12967-
2:2020, Article 7. L'instance, son ensemble d'attributs spécifiques à la classe et les propriétés
communes du système et de la version doivent être créés par l’intermédiaire de ce service
d'information.
Exemple L'ajout d'une nouvelle personne dans le système doit être réalisé en appelant le service
d'information «ajout» de l'objet de traitement Personne [Personne.ajout]. L'appelant trans-
met en entrée plusieurs champs de l'ensemble d'attributs spécifiques à la classe (id, nom,
heureNaissance, heureDécès, genre, adresse, etc.). Le service d'information doit également
permettre à l'utilisateur de transmettre des informations pour remplacer les valeurs par
défaut des attributs communs correspondant à son système et à sa version.
6.2.2.2.2 Service d'information «Xajout»
Service Xajout
d'information
Domaine Doit être utilisé pour créer une nouvelle instance des données étendues et l'associer à un
d'application objet HISA.
Description La spécification de l'objet de données étendues qui va être créée est disponible dans
l'ISO 12967-2:2020, paragraphe 6.3.7. Les instances auxquelles doivent être associées les don-
nées étendues sont les classes HISA individuelles spécifiées dans l'ISO 12967-2:2020, Article 7.
Les propriétés des données étendues et les propriétés communes du système et de la version
qu'elles contiennent doivent être créées par l’intermédiaire de ce service d'information.
Exemple L'appel de ce service d'information [Personne.Xajout] doit permettre de procéder à des opéra-
tions telles que l'ajout, entre autres, de la photographie numérique de la personne, de l'image
scannée de l'accord signé de réception du traitement, etc. La sémantique des références
étendues doit être classée dans son type de propriété, le type de média dans la propriété
typeMédia, la langue dans la propriété Langue, etc.
6.2.2.2.3 Service d'information «Cajout»
Service Cajout
d'information
Domaine Doit être utilisé pour créer une nouvelle instance des critères de classification et l'associer à
d'application un objet HISA.
Description La spécification des données de critère de classification qui va être créée est disponible dans
l'ISO 12967-2:2020, paragraphe 6.3.10. Les instances auxquelles doivent être associées les
données de classification sont les classes HISA individuelles spécifiées dans l'ISO 12967-
2:2020, Article 7. Les propriétés des données de classification et les propriétés communes du
système et de la version doivent être créées par l’intermédiaire de ce service d'information.
Exemple Dans les organismes de santé, les personnes peuvent être classées en fonction de leurs
études. L'appel de ce service d'information [Personne.Cajout] permet de classer la personne
en fonction des critères en vigueur (par exemple, dans la classification nationale, régionale
ou locale en vigueur).
6.2.2.2.4 Service d'information «BRajout»
Service BRajout
d'information
Domaine Doit être utilisé pour créer une nouvelle instance d'une règle régissant l'exercice de l'activité
d'application concernant l'objet HISA auquel elle est associée.
Description La spécification des données de la règle régissant l'exercice de l'activité qui va être créée est
disponible dans l'ISO 12967-2:2020, paragraphe 6.3.9. Les instances auxquelles doivent être
associées les données de la règle régissant l'exercice de l'activité sont les classes HISA indi-
viduelles spécifiées dans l'ISO 12967-2:2020, Article 7. Les propriétés de la règle régissant
l'exercice de l'activité et les propriétés communes du système et de la version doivent être
créées par l’intermédiaire de ce service d'information.
Exemple Des médicaments expérimentaux sont souvent utilisés dans le cadre de traitements bien
déterminés et nécessitent l'identification de règles régissant l'exercice de l'activité spéci-
fiques pour garantir leur utilisation correcte. C'est le cas, par exemple, des médicaments
qui peuvent être prescrits uniquement par certains médecins pour traiter certains types de
maladies. Dans ce cas, le service d'information [Ressource.BRajout] doit être utilisé une fois
la règle régissant l'exercice de l'activité définie.
6.2.2.3 Spécifications comportementales
Il revient au client de l'objet (c'est-à-dire à l'appelant) de transmettre des données valides en entrée aux
propriétés spécifiques à la classe et aux attributs du système et de la version pour lesquels il convient
de remplacer les valeurs par défaut.
8 © ISO 2020 – Tous droits réservés
Lors de la création de l'instance, le système doit générer des valeurs appropriées pour les attributs
communs du système et de la version de la classe HISA correspondant aux paramètres qui ne sont pas
transmis par l'appelant, en particulier pour les paramètres suivants.
— L'identifiant de l'instance doit être unique dans l'environnement de traitement réparti ouvert du
système de l'entreprise. Un identifiant unique de la classe HISA peut être spécifié par l'appelant de
l'opération. Dans ce cas, le service doit vérifier le caractère unique de l'identifiant.
— Le système doit tenir compte de la gestion des changements d'état en ajoutant de manière
dynamique et automatique les valeurs qui enregistrent les changements intervenus dans les
propriétés spécifiques de la classe ou lorsque des données étendues, des données de classification
et des règles régissant l'exercice de l'activité lui sont associées, ce qui permet de suivre le cycle de
vie de l'instance au fil du temps. La classe Changements d'état est spécifiée dans l'ISO 12967-2:2020,
paragraphe 6.3.8.
— Le service d'information doit renvoyer au client au moins l'ensemble des attributs communs liés à
l'objet HISA créé. Ces informations doivent inclure une valeur indiquant la réussite de l'opération ou
une erreur indiquant la raison de l'échec.
— Le service d'information doit mettre en place tous les contrôles d'intégrité se rapportant aux
informations transmises par le client de l'opération, en interrompant l’opération si celle-ci risque de
provoquer un état informationnel incohérent.
6.2.3 Services d'informations de base «mise_à_jour»
6.2.3.1 Généralités
Les services d'informations «mise_à_jour» doivent permettre au client de l'opération d’actualiser les
instances des objets HISA.
6.2.3.2 Liste des services d'informations
6.2.3.2.1 Service d'information «mise_à_jour»
Service mise_à_jour
d'information
Domaine Doit être utilisé pour mettre à jour une instance existante d'un objet HISA.
d'application
Description Les instances à mettre à jour sont les classes HISA individuelles spécifiées dans l'ISO 12967-
2:2020, Article 7. L'instance, son ensemble d'attributs spécifiques à la classe et les proprié-
tés communes du système et de la version doivent être mis à jour par l’intermédiaire de ce
service d'information.
Exemple La mise à jour d'une personne dans le système doit être réalisée en appelant le service
d'information «mise_à_jour» de l'objet de traitement Personne [Personne.mise_à_jour]. Le
service d'information doit également permettre à l'utilisateur de transmettre des informa-
tions pour remplacer les valeurs par défaut des attributs communs correspondant à son
système et à sa version.
6.2.3.2.2 Service d'information «Xmise_à_jour»
Service Xmise_à_jour
d'information
Domaine Doit être utilisé pour mettre à jour une instance existante des données étendues
d'application associées à un objet HISA.
Description Les instances de données étendues à mettre à jour sont celles déjà associées aux
classes HISA individuelles spécifiées dans l'ISO 12967-2:2020, Article 7. L'objet de
données étendues et ses propriétés communes du système et de la version doivent
être mis à jour par l’intermédiaire de ce service d'information.
Exemple La mise à jour des propriétés des données étendues d'une personne dans le système
doit être réalisée en appelant le service d'information «mise_à_jour» de l'objet de
traitement Personne [Personne.Xmise_a_jour]. Le service d'information doit égale-
ment permettre à l'utilisateur de transmettre des informations pour remplacer les
valeurs par défaut des attributs communs des données étendues correspondant à son
système et à sa version.
6.2.3.2.3 Service d'information «Cmise_à_jour»
Service Cmise_à_jour
d'information
Domaine Doit être utilisé pour mettre à jour une instance existante des données de classification asso-
d'application ciée à un objet HISA.
Description Les instances de données de classification à mettre à jour sont celles déjà associées aux
classes HISA individuelles spécifiées dans l'ISO 12967-2:2020, Article 7. L'objet de classifi-
cation et ses propriétés communes du système et de la version doivent être mis à jour par
l’intermédiaire de ce service d'information.
Exemple La mise à jour des critères de classification d'une personne dans le système doit être réalisée
en appelant le service d'information «mise_à_jour» de l'objet de traitement Personne [Per-
sonne.Cmise_à_jour]. Le service d'information doit également permettre à l'utilisateur de
transmettre des informations pour remplacer les valeurs par défaut des attributs communs
correspondant à son système et à sa version.
6.2.3.2.4 Service d'information «BRmise_à_jour»
Service BRmise_à_jour
d'information
Domaine Doit être utilisé pour mettre à jour une instance existante d'une règle régissant l'exercice de
d'application l'activité associée à un objet HISA.
Description La spécification de la règle régissant l'exercice de l'activité qui va être créée est disponible
dans l'ISO 12967-2:2020, paragraphe 6.3.9. Les instances auxquelles doivent être associées
les données de la règle régissant l'exercice de l'activité sont les classes HISA individuelles
spécifiées dans l'ISO 12967-2:2020, Article 7. Les propriétés de la règle régissant l'exercice de
l'activité et les propriétés communes du système et de la version doivent être mises à jour par
l’intermédiaire de ce service d'information.
Exemple Des médicaments expérimentaux sont souvent utilisés dans le cadre de certains traitements
et doivent faire l'objet de règles régissant l'exercice de l'activité visant à identifier leur usage
correct. C'est le cas, par exemple, des médicaments qui peuvent être prescrits uniquement
par certains médecins pour traiter certains types de maladie. Si ces règles régissant l'exer-
cice de l'activité doivent être mises à jour, le service d'information [Ressource.BRmise_à_
jour] doit être utilisé.
6.2.3.3 Spécifications comportementales
Il revient au client de l'objet d'attribuer des données valides en entrée aux propriétés spécifiques à la classe
et aux attributs du système et de la version pour lesquels il convient de remplacer les valeurs par défaut.
Le système doit générer et/ou mettre à jour les valeurs appropriées des attributs communs du système
et de la version de la classe HISA lors de sa mise à jour, en particulier pour les attributs suivants.
— L'opération doit deman
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.