ISO 12967-2:2020
(Main)Health informatics — Service architecture (HISA) — Part 2: Information viewpoint
Health informatics — Service architecture (HISA) — Part 2: Information viewpoint
This document specifies the fundamental characteristics of the information model implemented by a specific architectural layer (i.e. the service architecture) of the information system to provide a comprehensive and integrated storage of the common enterprise data and to support the fundamental business processes of the healthcare organization, as defined in ISO 12967‑1. The information model is specified in this document without any explicit or implicit assumption on 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 that will be selected for the physical implementation. This document does not aim at representing a fixed, complete, specification of all possible data that can be necessary for any requirement of any healthcare enterprise. It specifies only a set of characteristics, in terms of overall organization and individual information objects, identified as fundamental and common to all healthcare organizations, and that is satisfied by the information model implemented by the service architecture. Preserving consistency with the provisions of this document, physical implementations are allowed extensions to the standard information model in order to support additional and local requirements. Extensions include both the definition of additional attributes in the objects of the standard model, and the implementation of entirely new objects. Also, this document specification is extensible over time according to the evolution of the applicable standardization initiatives. The specification of extensions is carried out according to the methodology defined in ISO 12967-1:2020, Clause 7.
Informatique de santé — Architecture de service — Partie 2: Point de vue de l'information
Le présent document spécifie les caractéristiques fondamentales du modèle d'information mis en place par une couche architecturale spécifique (c'est-à-dire l'architecture de service) du système d'information pour assurer le stockage cohérent et intégré des 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 d'information est spécifié dans le présent document 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 place physique. Le présent document n'a pas pour objet de spécifier, de manière fixe et exhaustive, toutes les données possibles susceptibles d'être nécessaires aux exigences d'une entreprise de santé. Elle spécifie simplement un ensemble de caractéristiques (en termes d'objets d'informations organisationnelles globales et individuelles) identifiées comme étant essentielles et communes à tous les organismes de santé, et que le modèle d'information 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 sont autorisées à étendre le modèle d'information standard afin de répondre à des exigences supplémentaires et locales. Les extensions incluent la définition d'attributs supplémentaires dans les objets du modèle standard et la mise en place d'objets totalement nouveaux. De même, la spécification que constitue le présent document doit être extensible dans le temps en fonction de l'évolution des initiatives de normalisation applicables. La spécification des extensions doit être réalisée conformément à la méthodologie définie dans l'ISO 12967-1:2020, Article 7.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 12967-2
Second edition
2020-11
Health informatics — Service
architecture (HISA) —
Part 2:
Information viewpoint
Informatique de santé — Architecture de service —
Partie 2: Point de vue de l'information
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 . 1
4 Abbreviated terms . 2
5 Methodological principles . 2
5.1 Language and notation adopted for the specification of the model. 2
5.2 UML class diagram notation guidelines and profile . 3
5.3 Clusters of objects in the information model . 4
5.4 Operational and descriptive information: classifications, knowledge and its instantiation 5
5.5 Data types . 7
5.6 General characteristics of the model . 8
6 General characteristics of the model . 8
6.1 Common structure of each information object: the GenericHisaClass . 8
6.2 UML diagram . 9
6.3 Specification of Generic HISA Class .10
6.3.1 Generic meta-class .10
6.3.2 Class: Set of structure attributes .11
6.3.3 Class: Set of class specific attributes .11
6.3.4 Class: Set of common attributes .11
6.3.5 Class: Set of system attributes .11
6.3.6 Class: Set of version attributes.12
6.3.7 Class: Extended attributes .12
6.3.8 Class: State changes .13
6.3.9 Class: Business rules .13
6.3.10 Class: Classification criteria.14
7 The reference information models .14
7.1 Classification objects .14
7.1.1 Aim .14
7.1.2 UML information model .14
7.1.3 Specification of the individual classes .15
7.2 Subject of care objects .18
7.2.1 Aim .18
7.2.2 UML information model .18
7.2.3 Specification of the individual classes .19
7.3 Activity management objects .23
7.3.1 Aim .23
7.3.2 UML information model .24
7.3.3 Specification of the individual classes .24
7.4 Clinical and health information objects .31
7.4.1 Aim .31
7.4.2 UML information model .31
7.4.3 Specification on the individual classes .32
7.5 Resource management objects .37
7.5.1 Aim .37
7.5.2 UML information model .37
7.5.3 Specification of the individual classes .37
7.6 User and authorization objects .43
7.6.1 Aim .43
7.6.2 UML information model .43
7.6.3 Specification of the individual classes .44
7.7 Messaging objects .49
7.7.1 Aim .49
7.7.2 UML information model .50
7.7.3 Specification of the individual classes .50
Bibliography .54
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-2: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 HL7®;
— 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 ISO 12967 series 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 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 standard model with additional concepts needed to support
local requirements in terms of information to be put in common.
Information viewpoint is specified in this document.
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 ISO 12967-3.
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-2:2020(E)
Health informatics — Service architecture (HISA) —
Part 2:
Information viewpoint
1 Scope
This document specifies the fundamental characteristics of the information model implemented by
a specific architectural layer (i.e. the service architecture) of the information system to provide a
comprehensive and integrated storage of the common enterprise data and to support the fundamental
business processes of the healthcare organization, as defined in ISO 12967-1.
The information model is specified in this document without any explicit or implicit assumption on 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 that
will be selected for the physical implementation.
This document does not aim at representing a fixed, complete, specification of all possible data that can
be necessary for any requirement of any healthcare enterprise. It specifies only a set of characteristics,
in terms of overall organization and individual information objects, identified as fundamental and
common to all healthcare organizations, and that is satisfied by the information model implemented by
the service architecture.
Preserving consistency with the provisions of this document, physical implementations are allowed
extensions to the standard information model in order to support additional and local requirements.
Extensions include both the definition of additional attributes in the objects of the standard model, and
the implementation of entirely new objects.
Also, this document specification is extensible over time according to the evolution of the applicable
standardization initiatives.
The specification of extensions is carried out according to the methodology defined in ISO 12967-1:2020,
Clause 7.
2 Normative references
There are no normative references in this document.
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
information object
information held by the system about entities of the real world
Note 1 to entry: Entities including the ODP system itself can be represented in an information specification in
terms of information objects, their relationships and behaviour.
3.2
package
cluster of information objects (3.1)
3.3
middleware
enabling technology of enterprise application integration (3.4) describing a piece of software that
connects two or more software applications so that they can exchange data
3.4
enterprise application integration
EAI
use of software and computer systems architectural principles to integrate a set of enterprise computer
applications
3.5
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
ODP Open Distributed Processing
HISA Health Informatics Service Architecture
UML Unified Modeling Language
5 Methodological principles
5.1 Language and notation adopted for the specification of the model
The objective of the information viewpoint specification is to describe the information relevant for the
enterprise to be handled by the service architecture. It consists of a formal information model detailing
the semantic and syntactic aspects of all data to be managed.
The specification is based on an object model, derived from the enterprise viewpoint by properly
structuring and aggregating the information that has been identified as relevant in the specification of
the business processes, tasks and activities.
The general approach of the ODP standard [i.e. ISO/IEC 10746 (all parts)] is also used in ISO 12967-1,
the modeling language used in this document is UML.
The information viewpoint is concerned with information modeling (i.e. the kinds of information
handled by the system). It focuses on the semantics of information and information processing in the
system. It is fundamental that the individual components of a distributed system share a common
understanding of the information they communicate when they interact, or the system will not behave
as expected. Some of these items of information are handled, in one way or another, by many of the
objects in the system. To ensure that the interpretation of these items is consistent, the information
2 © ISO 2020 – All rights reserved
language defines concepts for the specification of the meaning of information stored within, and
manipulated by, an ODP system, independently of the way the information processing functions
themselves are to be implemented.
Thus, information held by the ODP system about entities in the real world, including the ODP system
itself, is represented in an information specification in terms of information objects, and their
associations and behaviour. Atomic information objects represent basic information elements. More
complex information is represented as composite information objects, each expressing associations
over a set of constituent information objects.
Some elements visible from the enterprise viewpoint will be visible from the information viewpoint
and vice versa. For example, an activity seen from the enterprise viewpoint will be in the information
viewpoint as the specification of some processing which causes a state transition of an information entity.
Different notations for information specifications model the properties of information in different
ways. It is possible to place emphasis on classification and reclassification of information types, or on
the states and behaviour of information objects. In some specification languages, atomic information
objects are represented as values. The approach to be taken will depend on the modeling technique and
notation being used.
Assessment of conformance to the information specification of a system involves relating the
requirements expressed in the specification to sets of observations of the behaviour of the system
at conformance points identified in the engineering and technology specification, and assessing the
degree of consistency between the requirements and the observations.
5.2 UML class diagram notation guidelines and profile
For each cluster of objects identified in the enterprise viewpoint, the information objects will be
illustrated according to the following rationale.
— Information objects (i.e. classes) grouped in the packages will be not be coloured.
— Classes not expressly grouped in the package will also be represented if there are associations from
classes belonging to the package to these classes. These classes, however, will be coloured in yellow.
— The names of classes will be meaningful and start with a capital letter (e.g. Person). If the name is
composed of more than one word the blank spaces between the words present in the diagrams will
be instead omitted in the section of the tables containing the class identifiers (e.g. “subject of care
will have as class identifier “SubjectOfCare”). Blank spaces are left in the class names and diagrams
also with the scope of supporting readability.
— Associations will be labelled when the label adds value to the diagram.
— Association labels indicate a property, or a verb phrase; in the latter case, an arrow is added to the
association label to avoid ambiguity.
— Labels are always in lower case and, if a label is a verb phrase (with arrow), it will have one blank
space in between words.
— Navigability is not relevant when using UML for an information specification and will not be
represented.
— In general, in order to support readability, the classes should only contain the name of the class.
Properties should be described in the tables; however, if properties are displayed in the diagrams,
the following two points hold.
— Notation for visibility of properties is not used, as it is not pertinent for the conceptual models
used in the information viewpoint. Although visibility symbols could be used to indicate access
control, this is not done as all healthcare-related information should be accessed through
careful authorization.
— Data types of the properties should be displayed in the class in the diagram.
— For some classes, associations to other classes could be modelled (in the UML diagrams) as attributes
to the class. This reflects that the association has value rather than reference semantics, in addition
to the resulting simplification of the model. In other cases, the same method might be used in the
UML diagrams even though the association has reference semantics. This is done just to simplify
the models. In the related class descriptions, these instances of simplified modeling are described
as associations rather than attributes.
— Properties (attributes) of classes start with a lower-case letter (e.g. name). If the property is
composed of more than one word, the blank spaces in between words are omitted (e.g. familyName,
birthDate).
— Current ISO and low-level data types will preferably be used. These will allow mapping to CEN or
ISO (in the future) when possible.
— Many-to-many binary associations named “related to” may be implemented as a set of specific
associations or association classes of specific multiplicities.
— Cardinalities of properties are used in case of associations, especially to distinguish between
optional and mandatory properties.
— Cardinality ‘*’ is never used, as the reader might be confused as to whether a 0.* or 1.* was intended.
— When the composition symbol is used, the non-displayed cardinality will always be ‘1’.
5.3 Clusters of objects in the information model
The information specification is built by considering the elements of the enterprise viewpoint
specification. ODP does not impose any methodology for the definition and use of the viewpoints. Thus,
the enterprise specification has been used here for building the UML specification. This approach
greatly facilitates the definition of the correspondences between the related entities that appear in the
different viewpoints, also allowing the treatment of the consistency among the viewpoints.
In particular, this information specification incorporates the information handled by the system as
described in ISO 12967-1:2020, 6.2 to 6.4.
According to the methodology identified in the enterprise viewpoint, seven clusters of objects have
been identified, each of which is responsible for organizing and storing the information necessary for
supporting the users’ activities identified in the related areas of ISO 12967-1, as follows.
a) Classification objects
These objects handle the information necessary for supporting the users’ activities related to the
management of classifications, coding criteria and dictionaries.
b) Subject of care objects
These objects handle the information necessary for supporting the users’ activities that are
identified in the “subject of care workflow”.
c) Activity management objects
These objects handle the information necessary for supporting the users’ activities identified in
the “activity management workflow”.
d) Healthcare information objects
These objects handle the information necessary for supporting the users’ activities identified in
the “healthcare information workflow”.
e) Resources objects
4 © ISO 2020 – All rights reserved
These objects handle the information necessary for supporting the users’ activities related to the
management of resources.
f) Users and authorization objects
These objects handle the information necessary for supporting the users’ activities related to the
management of users and authorizations.
g) Messaging objects
These objects handle the information necessary for supporting the structuring of data and the
communications with other systems through messaging mechanisms.
These clusters of objects are specified in Clause 7 by means of UML models.
The HISA information models in this document are not a one-to-one unfolding of the concepts described
in ISO 12967-1, but addressing key elements hereof such as Healthcare Information, with a viewpoint of
the information constructs needed from a system perspective.
HISA is mainly about the IT domain. HISA defines models with classes and services related hereto, in
the sense of what should be supported in the enterprise domain at an overall level, not at all detailed
concepts and relations in the business domain.
HISA focuses on the information services, through which information is created, read, updated and
deleted in connection with and as a result of many healthcare activities. The management of information
through the services are key, but not as much the information itself. The high-level information models
of HISA refer, for example, to only a fraction of the concepts and terms in ISO 13940 (Contsys).
Further general information on mapping between different domains and models with different purpose,
levels and scopes is provided in ISO 12967-1:2020, Annex C.
NOTE In the following representative UML models, several terms and descriptions of the HISA classes have
been updated to reflect current state of art regarding terminology. However, the original HISA class identifiers
have not changed. These are unique to HISA and for this reason maintain their previous class identifier, thus
supporting also backward compatibility.
5.4 Operational and descriptive information: classifications, knowledge and its
instantiation
From the textual descriptions in the enterprise viewpoint, the service architecture shall be able to
manage not only the daily operational information directly related to the various business processes,
but also a knowledge base, allowing managing the descriptive concepts, vocabulary items, and rules
required to instantiate particular properties of the operational information. Such "concept descriptive
information" is the basic knowledge base required for the actual instantiation of the operational
information in the healthcare enterprise.
NOTE The topic is also explained in in ISO 12967-1:2020, 11.9.
HISA information objects in each package shall thus be classified as:
— Operational, usually representing the actual (clinical, organizational, etc.) objects that are
continuously generated during (and for) the daily activities. These include the personal and
healthcare treatment information on patients, the individual resources used for carrying out the
actual activities, etc.
— The operational information objects model the entities involved in the daily activities of
the healthcare enterprise in the treatment of subjects of care and in the functioning of the
enterprise itself.
— Descriptive, usually enterprise or organization-related, specifying the criteria according to which
the organization works and is structured. It includes general classifications of clinical concepts, rules
according to which the activities are performed, and more (e.g. the types of activities which are carried
out in the radiology department, the diagnostic classification in use in the clinical setting, etc.).
— The descriptive information objects model the entities required for the overall knowledge
base that is required by the healthcare enterprises to carry out daily activities related to the
treatment of subjects of care and in the functioning of the enterprise itself.
For each “operational” information object, therefore, the model foresees one “descriptive” information
object, containing the main classification data, the properties, the rules and the default values that are
necessary for the management of the live data instantiated in the “operational” object, as exemplified in
Figure 2.
Figure 2 — Knowledge base implemented through the descriptive information objects
In addition to the properties and to the classification provided by the related “descriptive” class,
each class and each attribute of each class can be classified according to different, multiple, multi-
language classifications for different (clinical, epidemiological, statistic, etc.) purposes. To support
this requirement, the HISA model provides the package of “Concept Information Objects”, capable of
organizing multiple classifications, terminologies and other concepts. See Figure 3.
Each individual information element (entire instance of one class or individual attribute of one class)
can be related to the concept class to allow specifying as many classifications as necessary. In this case
also, the principle of implementing a knowledge base is implemented by the HISA model that provides
the following.
— “Descriptive” information objects, allowing the specification of the concepts according to which
each class and each attribute of the class can be classified.
— “Operational” information objects (natively present in each HISA class, as described in the “Generic
HISA class”), allowing the classification of each individual instance and each individual attribute
according to multiple concepts.
6 © ISO 2020 – All rights reserved
Figure 3 — Further classification criteria for each HISA class
5.5 Data types
The primitive data types given in Table 1 are used in this specification, as illustrated in Table 2.
Table 1 — Primitive data types
Data type Semantics
String Series of characters, as defined in ISO/IEC 11404:2007
Boolean Boolean value, as defined in ISO/IEC 11404:2007
Integer Integer, 32 bit two’s complement
Double Double precision floating point (64-bit Biblio entry)
Octet 8-bit code, as defined in ISO/IEC 11404:2007
Table 2 — Usage of primitive data types
HISA data type Primitive data type Semantics
Byte Octet Synonym of octet
ObjectIdentifier String Unchangeable string allowing the permanent and
non-ambiguous identification of one instance of one
information object.
The syntax and the structure of the string shall be
defined locally by the individual implementations,
according to criteria capable of ensuring the uniqueness
of the value also across different models and distributed,
multiple physical environments.
Identifier String Short, human-readable string allowing the non-ambiguous
identification of one instance of one information object.
InternalTimestamp Array of bytes Internal system representation of date and time at least
up to the level of the millisecond.
DateTime representations are specified in
ISO 8601-1:2019 and ISO 8601-2:2019.
Table 2 (continued)
HISA data type Primitive data type Semantics
DateTime String DateTime representation are specified in
ISO 8601-1:2019 and ISO 8601-2:2019.
Representation of date and time shall be at least up to
the level of the second.
Ordinal Integer A number which defines a position in an ordered series.
Unit String Unit of measure, expressed according to codes defined in
the “Unified Code for Units of Measures”
( ht t p s:// u n i t s of me a s u r e . or g ) .
URI String Uniform Resource Identifier
NOTE First defined in Request for Comments
(RFC) 2396 and finalized in RFC 3986.
SET Value that contains multiple values of the data type
specified as its elements.
5.6 General characteristics of the model
The specification of the overall information model is structured through the following sections:
— Formalization of the general criteria and of the properties common to all classes identified in
the model.
— One schema for each business process identified in the enterprise view, showing the sole classes
relevant for that business process.
NOTE Due to the integration of the whole model, in each schema there are some classes that are related
to objects relevant for other business processes and therefore described in other sections; for readability
reasons these classes are highlighted with a brown colour.
— Specification of the identified objects, with the definition of the related properties and of the
relations among them.
— Clause 5.2 summarizes essential guidelines on the UML notation adopted for the specification of the
schemas.
6 General characteristics of the model
6.1 Common structure of each information object: the GenericHisaClass
Each object of the information model shall conform to a common structure (i.e. the “GenericHISAClass”)
comprising the following:
— set of attributes (named “specific attributes”), describing the semantic aspects specific to the class
itself (e.g. Person’s name, gender, etc.);
NOTE 1 These attributes are the ones that are illustrated in the property list of all classes in Clause 7.
— set of attributes (named “system attributes”), common to all objects, supporting general
requirements in terms of accountability, auditing, legal/clinical requirements, etc. (e.g. the date
time of registration/updating of the instance);
— indefinite number of multi-media properties (named “extended attributes”), which may be added
dynamically at run-time and that allow to record further information on the objects; these properties
shall comprise, among others, the following attributes:
— actual datum (i.e. the value, for example a Person’s photo, the colour of his/her eyes, etc.);
8 © ISO 2020 – All rights reserved
— characteristics describing the properties of the actual datum (e.g. type [=IMAGE], size, etc.;
these shall be described, where possible, through the CEN data types);
— "system attributes”, common to all instances of the object;
— indefinite number of textual properties (named “business rules”), which may be added dynamically
at run-time and that allow to record specific (e.g. legal, clinical, organizational, operational) rules and
criteria that are applicable when operating with the instance in certain contexts; these properties
shall comprise, among other, the following attributes:
— actual text of the rule;
— scope of applicability of the rule;
— "system attributes”, common to all instances of the business rule object;
NOTE 2 The formalization of the semantics and of the syntax of such rules is under the responsibility of the
specific implementation scenario and is outside the scope of this document, which prescribes the capability of
each object to allow the recording and management of such type of information.
— indefinite number of properties (named “state changes”), which shall be added dynamically at run-
time automatically by the class itself, and that shall record the changes that occurred in the “specific
attributes” of the class, in order to keep track of the life cycle of the instance during the time; these
properties shall comprise, among others, the following attributes:
— value of the “system attributes” prior to the change;
— identification of the system attributes that have been changed;
— new values assigned to the system attributes that have been changed;
— date, time of the change;
— identification of the agent (i.e. individual or system process) that has effected the change;
— set of attributes (named “versioning attributes”), common to all objects, supporting the definition
and management of multiple versions of the instance of the object, each of them characterized by an
identification label and the time frame (i.e. starting date and ending date) of validity.
At a certain moment, either one or no instance shall be valid, therefore time frames of validity shall not
overlap.
— relationship linking one version of the object with the instance representing the previous version;
— indefinite number of relationships (named “classification criteria”), which may be added dynamically
at run-time and that allow to classify the entire class and/or individual attributes according to
multiple classification criteria, defined in the “Concept” class of the model.
6.2 UML diagram
All the classes in the following Figure 4 are specified in 6.3, except the HISA Concept class, which is
specified in 7.1.3.2.
Figure 4 — The generic HISA class
6.3 Specification of Generic HISA Class
6.3.1 Generic meta-class
Class identifier: GenericHISAClass
Description This meta-class represents the HISA information objects belonging to the information model
Associated classes Type of association Multiplicity
StructuredAttributes Composition 1
ExtendedAttributes Composition 0.*
BusinessRules Composition 0.*
StateChanges Composition 0.*
ClassificationCriteria Composition 0.*
Relating the instance with multiple classifications
Versioning Association 0.1
Relating the instance with its previous version, if it exists
Attributes Type Description
none
10 © ISO 2020 – All rights reserved
6.3.2 Class: Set of structure attributes
Class identifier: StructuredAttributes
Description Set of all structured attributes of the HISA information object consisting of the composition
of a) the specific attributes peculiar to the HISA information object and b) the set of common
attributes that shall be present in all classes
Associated classes Type of association Multiplicity
CommonAttributes Composition 1
ClassSpecificAttributes Composition 1
Attributes Type Description
none
6.3.3 Class: Set of class specific attributes
Class identifier: ClassSpecificAttributes
Description Set of attributes specific to the individual HISA information object
Associated classes Type of association Multiplicity
none
Attributes Type Description
Dependent on the specific object Detailed for each class in the relevant specifications
6.3.4 Class: Set of common attributes
Class identifier: CommonAttributes
Description Set of all attributes common to all HISA information objects
Associated classes Type of association Multiplicity
SystemAttributes Composition 1
VersionAttributes Composition 1
Attributes Type Description
none
6.3.5 Class: Set of system attributes
Class identifier: SystemAttributes
Description attributes, common to all objects, supporting general requirements in terms of accountability,
auditing, etc. of the instance
Associated classes Type of association Multiplicity
none
Attributes Type Description
instanceID ObjectIdentifier Permanent, unchangeable, unique identifier of the
instance of the class.
displayName String Short, human-readable description of the object, that
may be abbreviated for display purposes.
userCode Identifier Short, human-readable c
...
NORME ISO
INTERNATIONALE 12967-2
Deuxième édition
2020-11
Informatique de santé — Architecture
de service —
Partie 2:
Point de vue de l'information
Health informatics — Service architecture (HISA) —
Part 2: Information 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 .vi
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Termes abrégés . 2
5 Principes méthodologiques . 2
5.1 Langage et notation adoptés pour la spécification du modèle . 2
5.2 Principes de notation et profil du diagramme de classes UML . 3
5.3 Groupes d'objets du modèle d'information . 4
5.4 Informations opérationnelles et descriptives: classifications, connaissances et
instanciation. 6
5.5 Types de données . 7
5.6 Caractéristiques générales du modèle . 8
6 Caractéristiques générales du modèle . 9
6.1 Structure commune de chaque objet d'information: ClasseHISAGénérique . 9
6.2 Diagramme UML .10
6.3 Spécification de la classe HISA générique .10
6.3.1 Métaclasse générique .10
6.3.2 Classe: Ensemble d'attributs de structure .11
6.3.3 Classe: Ensemble d'attributs spécifiques de la classe .11
6.3.4 Classe: Ensemble d'attributs communs .11
6.3.5 Classe: Ensemble d'attributs système .11
6.3.6 Classe: Ensemble d'attributs de version .12
6.3.7 Classe: Attributs étendus .12
6.3.8 Classe: Changements d'état .13
6.3.9 Classe: Règles métier .14
6.3.10 Classe: Critères de classification .14
7 Modèles d'information de référence .14
7.1 Objets classification .14
7.1.1 But .14
7.1.2 Modèle d'information UML .15
7.1.3 Spécification des classes individuelles .15
7.2 Objets sujet de soins .18
7.2.1 But .18
7.2.2 Modèle d'information UML .18
7.2.3 Spécification des classes individuelles .19
7.3 Objets gestion d'activité .24
7.3.1 But .24
7.3.2 Modèle d'information UML .24
7.3.3 Spécification des classes individuelles .25
7.4 Objets informations cliniques et de santé .32
7.4.1 But .32
7.4.2 Modèle d'information UML .32
7.4.3 Spécification des classes individuelles .32
7.5 Objets gestion des ressources .38
7.5.1 But .38
7.5.2 Modèle d'information UML .38
7.5.3 Spécification des classes individuelles .38
7.6 Objets utilisateurs et autorisations .44
7.6.1 But .44
7.6.2 Modèle d'information UML .44
7.6.3 Spécification des classes individuelles .45
7.7 Objets messagerie .50
7.7.1 But .50
7.7.2 Modèle d'information UML .50
7.7.3 Spécification des classes individuelles .51
Bibliographie .55
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 www .iso .org/ avant -propos.
Le présent document a été élaboré par le comité technique ISO/TC 215, Informatique de santé, en
collaboration avec le comité technique CEN/TC 251, Informatique de santé, du Comité européen de
normalisation (CEN) conformément à l’Accord de coopération technique entre l’ISO et le CEN (Accord
de Vienne).
Cette deuxième édition annule et remplace la première édition (ISO 12967-2: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®;
— 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.
Introduction
La série ISO 12967 propose des recommandations 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 que dans 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), 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 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 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 fournit également des recommandations relatives à la manière dont une entreprise individuelle
peut étendre le modèle standard en ajoutant des concepts supplémentaires nécessaires à la prise
en charge des exigences locales en termes de mise en commun des informations.
Le point de vue de l'information est spécifié dans le présent document.
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 l'ISO 12967-3.
vi © ISO 2020 – Tous droits réservés
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.
NORME INTERNATIONALE ISO 12967-2:2020(F)
Informatique de santé — Architecture de service —
Partie 2:
Point de vue de l'information
1 Domaine d'application
Le présent document spécifie les caractéristiques fondamentales du modèle d'information mis en
place par une couche architecturale spécifique (c'est-à-dire l’architecture de service) du système
d'information pour assurer le stockage cohérent et intégré des 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 d'information est spécifié dans le présent document 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 place physique.
Le présent document n'a pas pour objet de spécifier, de manière fixe et exhaustive, toutes les données
possibles susceptibles d'être nécessaires aux exigences d'une entreprise de santé. Elle spécifie
simplement un ensemble de caractéristiques (en termes d'objets d'informations organisationnelles
globales et individuelles) identifiées comme étant essentielles et communes à tous les organismes de
santé, et que le modèle d'information 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 sont autorisées à étendre le modèle d'information standard afin de répondre à des exigences
supplémentaires et locales. Les extensions incluent la définition d'attributs supplémentaires dans les
objets du modèle standard et la mise en place d'objets totalement nouveaux.
De même, la spécification que constitue le présent document doit être extensible dans le temps en
fonction de l'évolution des initiatives de normalisation applicables.
La spécification des extensions doit être réalisée conformément à la méthodologie définie dans
l'ISO 12967-1:2020, Article 7.
2 Références normatives
Le présent document ne contient aucune référence normative.
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:
— IEC Electropedia: disponible à l'adresse http:// www .electropedia .org/
— ISO Online browsing platform: disponible à l'adresse https:// www .iso .org/ obp.
3.1
objet d'information
informations détenues par le système sur des entités du monde réel
Note 1 à l'article: Les entités, y compris le système ODP lui-même, peuvent être représentées dans une
spécification d'informations en termes d'objets d'informations, de relations et de comportements.
3.2
module
regroupement d'objets d'informations (3.1)
3.3
couche interstitielle
technologie d'activation du système d'intégration d'applications d'entreprise (3.4) décrivant une partie
de logiciel associant plusieurs applications logicielles de façon à leur permettre d'échanger des données
3.4
intégration d'applications d'entreprise
IAE
utilisation de principes d'architecture de logiciels et systèmes informatiques pour intégrer un ensemble
d'applications informatiques d'entreprise
3.5
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
HISA Health Informatics Service Architecture (architecture des services d'informations 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 Langage et notation adoptés pour la spécification du modèle
L'objectif de la spécification du point de vue de l'information consiste à décrire les informations
pertinentes pour l'entreprise que l’architecture de service doit intégrer. Il doit être composé d'un modèle
d'information formel détaillant les aspects sémantiques et syntaxiques de toutes les données à gérer.
La spécification repose sur un modèle objet dérivé du point de vue de l'entreprise. Il s'agit de structurer
et de regrouper correctement les informations identifiées comme pertinentes pour la définition des
processus métier, tâches et activités.
L'approche générale de la norme ODP [c'est-à-dire l'ISO/IEC 10746 (toutes les parties)] est également
utilisée dans l'ISO 12967-1, et le langage de modélisation utilisé dans le présent document est l'UML.
Le point de vue de l'information porte sur la modélisation des informations, c'est-à-dire les types
d'informations traités par le système. Il se concentre sur la sémantique des informations et leur
traitement dans le système. Pour éviter tout comportement aléatoire du système, il est fondamental
que les différents composants d'un système réparti partagent une interprétation commune des
informations qu'ils communiquent lorsqu'ils interagissent. Certains de ces éléments d'informations
sont traités, d'une manière ou d'une autre, par la plupart des objets présents dans le système. Pour
2 © ISO 2020 – Tous droits réservés
garantir la cohérence d'interprétation de ces éléments, le langage d'information définit les concepts
de spécification, de la signification des informations reçues et manipulées par un système ODP,
indépendamment de la manière dont les fonctions de traitement des informations elles-mêmes doivent
être mises en œuvre.
Par conséquent, les informations que détient le système ODP relatives aux entités du monde réel, y
compris le système ODP lui-même, sont représentées dans une spécification fondée sur un modèle objets
d'informations, intégrant leurs relations et leur comportement. Les objets d'informations atomiques
représentent la base des éléments d'informations. Les informations plus complexes sont représentées
sous la forme d'objets d'informations composites exprimant chacun les associations parmi un ensemble
d'objets d'informations constitutifs.
Certains éléments visibles du point de vue de l'entreprise le seront du point de vue de l'information et
inversement. Par exemple, une activité considérée du point de vue de l'entreprise sera, du point de vue
de l'information, perçue comme la spécification de certains traitements à l'origine d'un changement
d'état d'une entité informationnelle.
Différentes notations des spécifications d'information permettent de modéliser les propriétés des
informations de diverses manières. Il est possible de privilégier la classification et la reclassification
des types d'informations ou les états et le comportement des objets d'informations. Dans certains
langages de spécification, les objets d'informations atomiques sont représentés sous forme de valeurs.
L'approche dépend de la technique de modélisation et de la notation utilisées.
L'évaluation de la conformité à la spécification des informations d'un système implique de lier les
exigences exprimées dans la spécification à des ensembles d'observations du comportement du système
en certains points de conformité, identifiés dans la spécification de l'ingénierie et de la technologie. Cela
implique également d'évaluer le degré de cohérence entre les exigences et les observations.
5.2 Principes de notation et profil du diagramme de classes UML
Pour chaque groupe d'objets identifiés dans le point de vue de l'entreprise, les objets d'informations
sont illustrés conformément à la logique suivante:
— les objets d'informations (c'est-à-dire les classes) groupés dans les modules ne sont pas colorés;
— les classes qui ne sont pas formellement groupées dans le module sont également représentées s'il
existe des liens entre elles et les classes appartenant au module. Toutefois, elles doivent s'afficher
en jaune;
— les noms de classe doivent être significatifs et commencer par une lettre majuscule (par exemple,
Personne). Si le nom est composé de plusieurs mots, les espaces entre chacun d'eux dans les
diagrammes doivent être supprimés dans la section des tableaux contenant les identificateurs de
classe (par exemple, «sujet de soins» aura comme identificateur de classe «SujetDeSoins»). Les
espaces (ou blancs) sont maintenus dans les noms de classe et les diagrammes, par souci de lisibilité;
— les associations sont libellées lorsque cela permet d'ajouter une valeur au diagramme;
— les libellés d'associations désignent une propriété ou une phrase verbale. Dans ce dernier cas, une
flèche est ajoutée au libellé de l'association pour éviter toute ambiguïté;
— le libellé doit toujours être rédigé en lettres minuscules. Les mots composant une phrase verbale
(avec une flèche) seront séparés par un espace;
— la navigabilité n'est pas pertinente, en cas d’utilisation du langage UML pour une spécification
d'informations, et ne sera pas représentée;
— d'une manière générale, pour des raisons de lisibilité, il convient que les classes ne contiennent
que le nom de la classe. Il est recommandé que les propriétés soient décrites dans les tableaux.
Cependant, si les propriétés sont affichées dans les diagrammes, il y a lieu d’appliquer ce qui suit:
— la notation de la visibilité des propriétés n'est pas utilisée, cela n'étant pas adapté aux modèles
conceptuels utilisés dans le point de vue de l'information. Bien que des symboles de visibilité
puissent être utilisés pour indiquer le contrôle d'accès, cela ne doit pas être le cas étant donné
qu'il est recommandé de n'accéder aux informations relatives à la santé qu'en y étant dûment
autorisé;
— il convient que les types de données des propriétés s'affichent dans la classe du diagramme;
— pour certaines classes, les associations à d'autres classes peuvent être modélisées (dans les
diagrammes UML) sous la forme d'attributs liés à la classe. Il s'agit de souligner que l'association
repose sur une sémantique de valeur plutôt que de référence, en plus de la simplification du modèle
qui en résulte. Dans d'autres cas, la même méthode peut être utilisée dans les diagrammes UML,
même si l'association repose sur une sémantique de référence. Il s'agit ici de simplifier les modèles.
Dans les descriptions de classe associées, ces instances de modélisation simplifiée sont présentées
comme des associations plutôt que comme des attributs;
— les propriétés (attributs) des classes commencent par une lettre minuscule (par exemple, nom). Si
la propriété est composée de plusieurs mots, les espaces entre chacun d'eux sont supprimés (par
exemple nomFamille, dateNaissance);
— la norme ISO en cours et les types de données de niveau inférieur sont de préférence utilisés. Cela
permet d'établir une correspondance vers le CEN ou l'ISO (à venir), le cas échéant;
— les associations binaires de type plusieurs-à-plusieurs «liées à» peuvent être mises en place en tant
qu'ensemble d'associations spécifiques ou de classes d'associations de multiplicités particulières;
— les cardinalités de propriétés sont utilisées en cas d'associations, plus particulièrement pour
distinguer les propriétés facultatives des propriétés obligatoires;
— la cardinalité «*» n'est jamais utilisée. En effet, le lecteur risque de confondre avec 0.* ou 1.*;
— si un symbole de composition est utilisé, la cardinalité non affichée est toujours de «1».
5.3 Groupes d'objets du modèle d'information
La spécification du point de vue «d’information» est conçue en tenant compte des éléments de la
spécification du point de vue «d'entreprise». ODP n'impose aucune méthodologie de définition et
d'utilisation des points de vue. Par conséquent, la spécification du point de vue «d'entreprise» a été
utilisée ici pour la conception de la spécification en UML. Cette approche facilite énormément la
définition des correspondances entre les entités associées qui apparaissent dans les différents points
de vue, ce qui permet également de traiter la cohérence des points de vue.
En particulier, la présente spécification du point de vue «d'information» intègre les informations
traitées par le système, comme cela est expliqué dans l'ISO 12967-1:2020, 6.2 à 6.4.
Selon la méthodologie identifiée dans le point de vue de l'entreprise, sept groupes d'objets ont été
identifiés, chacun d'eux étant en charge de l'organisation et du stockage des informations nécessaires à
la prise en charge des activités des utilisateurs identifiées dans les domaines concernés de l'ISO 12967-1,
selon la ventilation suivante.
a) 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.
4 © ISO 2020 – Tous droits réservés
b) Objets sujet de 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».
c) 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é».
d) 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é».
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 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.
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.
Ces groupes d'objets sont spécifiés dans l'Article 7 au moyen de modèles UML.
Les modèles d'information HISA du présent document ne constituent pas un déploiement biunivoque
des concepts décrits dans l'ISO 12967-1, mais traitent d'éléments clés tels que les informations de soins
de santé, en partant d'un point de vue de construction d'informations nécessaires dans une perspective
systémique.
L'HISA traite essentiellement du domaine des TI. L'HISA définit des modèles avec des classes et
des services s'y rapportant, dans le sens de ce qu'il convient de prendre en charge dans le domaine
de l'entreprise à un niveau global, et non avec des concepts détaillés et des relations appartenant au
domaine d'activité.
L'HISA se concentre sur les services d'informations permettant la création, la lecture, la mise à jour et
la suppression d'informations dans le cadre et à la suite de nombreuses activités de santé. La gestion
des informations par le biais des services est essentielle, mais pas autant que l'information elle-même.
Les modèles d'information de haut niveau de l'HISA ne se réfèrent, par exemple, qu'à une fraction des
concepts et termes de l'ISO 13940 (Contsys).
On trouvera à l'Annexe C de l'ISO 12967-1:2020 d'autres informations générales sur la correspondance
entre les différents domaines et modèles ayant des objectifs, des niveaux et des champs d'application
différents.
NOTE Dans les modèles UML représentatifs suivants, plusieurs termes et descriptions des classes HISA ont
été mis à jour pour refléter l'état actuel de la technique en matière de terminologie. Toutefois, les identificateurs
de classe HISA originaux n'ont pas changé. Ceux-ci sont propres à l'HISA et conservent, pour cette raison,
leur précédent identificateur de classe, ce qui permet également d’assurer la compatibilité avec les versions
antérieures.
5.4 Informations opérationnelles et descriptives: classifications, connaissances et
instanciation
Conformément aux descriptions textuelles énoncées dans le point de vue de l'entreprise, l’architecture
de service doit être en mesure de gérer non seulement les informations opérationnelles quotidiennes
directement liées aux différents processus métier, mais également la base de connaissances, afin de
gérer les concepts descriptifs, les éléments lexicaux et les règles requis pour instancier les propriétés
particulières des informations opérationnelles. Ces «informations descriptives conceptuelles» sont la
base nécessaire à la réelle instanciation des informations opérationnelles au sein de l'entreprise de santé.
NOTE Ce point est également expliqué dans l'ISO 12967-1:2020, 11.9.
Les objets d'informations HISA de chaque module doivent donc être classés de la façon suivante:
— «opérationnels», représentant généralement les objets (cliniques, organisationnels, etc.) réels
générés en permanence lors (et pour) des activités quotidiennes. Il s'agit des informations
personnelles et relatives aux soins de santé des patients, des ressources individuelles utilisées pour
effectuer des activités réelles, etc.;
— les objets d'informations opérationnels modélisent les entités impliquées dans les activités
quotidiennes de l'entreprise de santé, en matière de traitement des sujets de soins et de
fonctionnement de l'entreprise elle-même;
— «descriptifs», en général liés à l’entreprise ou à l'organisme, spécifiant ses critères de fonctionnement
et de structuration. Cela comprend les classifications générales des concepts cliniques, des règles
de réalisation des activités et bien plus encore (par exemple, les types d'activités réalisés dans le
service de radiologie, la classification de diagnostic en vigueur dans le milieu clinique, etc.);
— les objets d'informations descriptifs modélisent les entités requises pour l'ensemble de la base de
connaissances dont ont besoin les entreprises de santé pour réaliser leurs activités quotidiennes
liées au traitement des sujets de soins et au fonctionnement de l'entreprise elle-même.
Par conséquent, à chaque objet d'information «opérationnel» correspond un objet d'information
«descriptif», contenant les principales données de classification, propriétés, règles et valeurs par défaut
nécessaires à la gestion des données individualisées instanciées dans l'objet «opérationnel» (voir
Figure 2).
Figure 2 — Base de connaissances mise en place par l'intermédiaire d'objets d'informations
descriptifs
Outre les propriétés et la classification fournies par la classe «descriptive» correspondante, chaque
classe, et chacun de ses attributs, peuvent être classés en fonction de plusieurs classifications
multilingues différentes pour répondre à différents objectifs (clinique, épidémiologique, statistique,
etc.). Pour répondre à cette exigence, le modèle HISA offre le module «Objets d'informations conceptuels»,
pouvant organiser plusieurs classifications, terminologies et autres concepts. Voir Figure 3.
6 © ISO 2020 – Tous droits réservés
Chaque élément d'information individuel (une instance entière ou un attribut individuel d'une classe)
peut être associé à la classe Concept afin de spécifier autant de classifications que nécessaire. De même,
dans ce cas, le principe d'implémentation d'une base de connaissances est mis en place par le modèle
HISA, qui propose:
— des objets d'informations «descriptifs», permettant de spécifier les concepts en fonction desquels
chaque classe et attribut de la classe peuvent être classés;
— des objets d'informations «opérationnels» (présents dans chaque classe HISA, comme expliqué
dans la «Classe HISA générique»), permettant de classer chaque instance individuelle et chaque
attribut en fonction de plusieurs concepts.
Figure 3 — Critères de classification approfondie de chaque classe HISA
5.5 Types de données
Les types de données primitifs indiqués dans le Tableau 1 sont utilisés dans cette spécification, comme
l'illustre le Tableau 2.
Tableau 1 — Types de données primitifs
Type de Sémantique
données
Chaîne Série de caractères (voir l'ISO/IEC 11404:2007)
Booléen Valeur booléenne, (voir l'ISO/IEC 11404:2007)
Entier Entier, 32 bits (codé en complément à 2)
Double Virgule flottante en double précision, 64 bits (entrée [15] de la
Bibliographie)
Octet Code 8 bits (voir l'ISO/IEC 11404:2007)
Tableau 2 — Utilisation des types de données primitifs
Type de données HISA Type de données pri- Sémantique
mitif
Byte Octet Synonyme d'octet
IdentificateurObjet Chaîne Chaîne non modifiable permettant d'identifier de
manière permanente et non ambiguë une instance d'un
objet d'information.
La syntaxe et la structure de la chaîne doivent être
définies en local par les implémentations, en fonction
de critères permettant d'assurer le caractère unique de
la valeur dans différents modèles et dans des environne-
ments physiques répartis.
Identificateur Chaîne Courte chaîne interprétable par l'utilisateur permet-
tant d'identifier sans ambiguïté une instance d'un objet
d'information.
HorodatageInterne Tableau d'octets Représentation de la date et de l'heure dans le système
interne, exprimée en millisecondes au moins.
Les représentations DateHeure sont spécifiées dans
l'ISO 8601-1:2019 et l'ISO 8601-2:2019.
DateHeure Chaîne La représentation DateHeure est spécifiée dans
l'ISO 8601-1:2019 et l'ISO 8601-2:2019.
La représentation de la date et de l'heure doit être expri-
mée au moins en secondes.
Ordinal Entier Nombre qui définit une position dans une série ordonnée.
Unité Chaîne Unité de mesure, exprimée en fonction de codes définis
dans le «code unifié des unités de mesure»
(https:// unitsofmeasure .org).
URI Chaîne Identifiant de ressource universel
NOTE Défini pour la première fois dans la RFC 2396 et
finalisé dans la RFC 3986.
SET Valeur contenant plusieurs valeurs de type de données
spécifiées comme ses éléments.
5.6 Caractéristiques générales du modèle
La spécification du modèle d'information général est structurée autour des sections suivantes:
— formalisation des critères généraux et des propriétés communes à toutes les classes identifiées dans
le modèle;
— un schéma par processus métier identifié dans le point de vue de l'entreprise, illustrant les classes
uniques correspondant audit processus métier;
NOTE En raison de l'intégration de l'ensemble du modèle, chaque schéma comporte certaines classes
associées à des objets adaptés à d'autres processus métier et, par conséquent, décrits dans d'autres sections.
Pour des raisons de lisibilité, ces classes sont surlignées en marron.
— la spécification des objets identifiés, avec la définition des propriétés associées et des relations
qu'ils entretiennent;
— le paragraphe 5.2 constitue un récapitulatif des lignes directrices essentielles quant à la notation
UML adoptée pour la spécification des schémas.
8 © ISO 2020 – Tous droits réservés
6 Caractéristiques générales du modèle
6.1 Structure commune de chaque objet d'information: ClasseHISAGénérique
Chaque objet du modèle d'information doit être conforme à une structure commune (à savoir
«ClasseHISAGénérique») composée des éléments suivants:
— un ensemble d'attributs (nommés «attributs spécifiques»), décrivant les aspects sémantiques
spécifiques à la classe elle-même (par exemple, le nom ou le genre de la personne);
NOTE 1 Ces attributs sont illustrés dans la liste des propriétés de toutes les classes de l'Article 7.
— un ensemble d'attributs (nommés «attributs système»), communs à tous les objets et prenant en
charge les exigences générales en termes de gestion, d'audit, d'exigences légales/cliniques, etc. (par
exemple, la date d'enregistrement/mise à jour de l'instance);
— un nombre illimité de propriétés multimédia (nommées «attributs étendus»), qui peuvent être
ajoutées de façon dynamique lors de la phase d'exécution et qui permettent d'enregistrer des
informations complémentaires relatives à l'objet. Ces propriétés doivent comporter, entre autres,
les attributs suivants:
— référence réelle (c'est-à-dire la valeur, par exemple la photo d'une personne, la couleur de ses
yeux, etc.);
— caractéristiques décrivant les propriétés de la référence réelle (par exemple, le type [ = IMAGE],
taille, etc., qui doivent être décrits, dans la mesure du possible, par des types de données CEN);
— «attributs système», communs à toutes les instances de l'objet;
— un nombre illimité de propriétés textuelles (nommées «règles métier»), qui peuvent être ajoutées
de manière dynamique lors de la phase d'exécution et qui permettent d'enregistrer les règles et
les critères spécifiques (par exemple, juridiques, cliniques, organisationnels et opérationnels)
applicables lors de l'utilisation avec l'instance, dans certains contextes. Ces propriétés doivent
comporter, entre autres, les attributs suivants:
— texte réel de la règle;
— domaine d'application de la règle;
— «attributs système», communs à toutes les instances de l'objet Règle métier;
NOTE 2 La formalisation de la sémantique et de la syntaxe de ces règles dépend du scénario de mise
en place spécifique et n'est pas couverte par le domaine d'application du présent document, lequel
spécifie la capacité de chaque objet à enregistrer et à gérer ce type d'informations.
— un nombre illimité de propriétés (nommées «modifications de l'état»), qui doivent être ajoutées
de manière dynamique lors de la phase d'exécution par la classe ell
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.