ISO 12967-2:2009
(Main)Health informatics - Service architecture - Part 2: Information viewpoint
Health informatics - Service architecture - Part 2: Information viewpoint
ISO 12967-2:2009 specifies the fundamental characteristics of the information model to be implemented by a specific architectural layer (i.e. the middleware) 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 without any explicit or implicit assumption on the physical technologies, tools or solutions to be adopted 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 specification 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 middleware.
Informatique de santé — Architecture de service — Partie 2: Point de vue d'information
L'ISO 12967-2:2009 spécifie les caractéristiques fondamentales du modèle d'information qu'une couche architecturale spécifique (c'est-à-dire la couche interstitielle) du système d'informations doit mettre en place pour assurer le stockage cohérent et intégré des données d'entreprise communes et supporter les processus métiers fondamentaux de l'organisme de santé, tel que défini dans l'ISO 12967-1. Le modèle d'information est spécifié sans émettre d'hypothèse (explicite ou implicite) sur les technologies physiques, les outils ou les solutions à adopter dans les différents scénarios cibles. 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. La spécification n'a pas pour objet d'être une représentation fixe et exhaustive de 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 et individuelles) identifiées comme étant essentielles pour tous les organismes de santé et que le modèle d'information mis en place par la couche interstitielle doit satisfaire.
General Information
Relations
Frequently Asked Questions
ISO 12967-2:2009 is a standard published by the International Organization for Standardization (ISO). Its full title is "Health informatics - Service architecture - Part 2: Information viewpoint". This standard covers: ISO 12967-2:2009 specifies the fundamental characteristics of the information model to be implemented by a specific architectural layer (i.e. the middleware) 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 without any explicit or implicit assumption on the physical technologies, tools or solutions to be adopted 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 specification 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 middleware.
ISO 12967-2:2009 specifies the fundamental characteristics of the information model to be implemented by a specific architectural layer (i.e. the middleware) 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 without any explicit or implicit assumption on the physical technologies, tools or solutions to be adopted 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 specification 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 middleware.
ISO 12967-2:2009 is classified under the following ICS (International Classification for Standards) categories: 35.240.80 - IT applications in health care technology. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 12967-2:2009 has the following relationships with other standards: It is inter standard links to ISO 12967-2:2020. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 12967-2:2009 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 12967-2
First edition
2009-08-15
Health informatics — Service
architecture —
Part 2:
Information viewpoint
Informatique de santé — Architecture de service —
Partie 2: Point de vue d'information
Reference number
©
ISO 2009
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO 2009
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2009 – All rights reserved
Contents Page
Foreword .v
Introduction.vi
1 Scope.1
2 Normative references.1
3 Terms and definitions .2
4 Symbols and abbreviations.2
5 Methodological principles .2
5.1 Language and notation adopted for the specification of the model (informative).2
5.2 UML Class Diagram notation guidelines and profile (informative) .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 DataTypes.7
5.6 Organization of the document .8
6 General characteristics of the model .9
6.1 Common structure of each information object: the GenericHisaClass.9
6.2 UML diagram.10
6.3 Specification of Generic HISA Class.11
6.3.1 General.11
6.3.2 Class: Set of structured 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.12
6.3.6 Class: Set of version attributes .12
6.3.7 Class: Extended attributes.13
6.3.8 Class: State changes .13
6.3.9 Class: Business rules .14
6.3.10 Class: Classification criteria.14
7 The reference information models .15
7.1 Classification objects.15
7.1.1 Scope.15
7.1.2 UML information model .15
7.1.3 Specification of the individual classes .16
7.2 Subject of care objects .19
7.2.1 Scope.19
7.2.2 UML information model .19
7.2.3 Specification of the individual classes .20
7.3 Activity management objects.25
7.3.1 Scope.25
7.3.2 UML information model .25
7.3.3 Specification of the individual classes .26
7.4 Clinical and health information objects .33
7.4.1 Scope.33
7.4.2 UML information model .33
7.4.3 Specification of the individual classes .34
7.5 Resource management objects .39
7.5.1 Scope.39
7.5.2 UML information model .39
7.5.3 Specification of the individual classes .40
7.6 User and authorization objects .45
7.6.1 Scope.45
7.6.2 UML information model.46
7.6.3 Specification of the individual classes.47
7.7 Messaging Objects.51
7.7.1 Scope.51
7.7.2 UML information model.52
7.7.3 Specification of the individual classes.52
Annex A (informative) Mappings between HISA and GPIC.56
Bibliography .58
iv © ISO 2009 – 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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
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.
ISO 12967-2 was prepared by Technical Committee ISO/TC 215, Health informatics, based on the European
Standard EN 12967-2:2007 with minor editorial amendments.
ISO 12967 consists of the following parts, under the general title Health informatics — Service architecture:
⎯ Part 1: Enterprise viewpoint
⎯ Part 2: Information viewpoint
⎯ Part 3: Computational viewpoint
Introduction
This is the second part of ISO 12967, a multi-part standard that 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 middleware), distinct from
individual applications and accessible throughout the whole information system through services, as shown in
Figure 1.
Applications
Scope of the
standard
Middleware of objects
integrating common data and common business logic
Figure 1 — Scope
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 must be supported by the information
and functionality of the middleware. It also provides guidance on how one individual enterprise (e.g. a
regional healthcare authority, a large hospital or any other organization where this model is applicable)
can specify and document additional specific business requirements, with a view to achieving a complete
specification, adequate for the characteristics of that enterprise.
Enterprise viewpoint is specified in ISO 12967-1.
b) Information viewpoint: specifies the fundamental semantics of the information model to be implemented
by the middleware to integrate the common enterprise data and to support the enterprise requirements
formalized in 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 part of ISO 12967.
c) Computational viewpoint: specifies the scope and characteristics of the services that must be provided by
the middleware for allowing access to the common data as well as the execution of the business logic
supporting the enterprise processes identified in the information viewpoint and in ISO 12967-1. It also
provides guidance on how one individual enterprise can specify additional services needed to support
local specific requirements in terms of common business logic to be implemented.
Computational viewpoint is specified in ISO 12967-3.
vi © ISO 2009 – All rights reserved
INTERNATIONAL STANDARD ISO 12967-2:2009(E)
Health informatics — Service architecture —
Part 2:
Information viewpoint
1 Scope
This part of ISO 12967 specifies the fundamental characteristics of the information model to be implemented
by a specific architectural layer (i.e. the middleware) 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 without any explicit or implicit assumption on the physical technologies,
tools or solutions to be adopted 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 specification 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 middleware.
Preserving consistency with the provisions of this part of ISO 12967, physical implementations allow
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 standard 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:2009,
Clause 7, “Methodology for extensions”.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 11404:2007, Information technology — General-Purpose Datatypes (GPD)
ISO 12967-1:2009, Health informatics — Service architecture — Part 1: Enterprise viewpoint
ISO 12967-3:2009, Health informatics — Service architecture — Part 3: Computational viewpoint
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
information object
information held by the system about entities of the real world, including the ODP system itself, is represented
in an information specification in terms of information objects, their relationships and behaviour
3.2
package
cluster of information objects
3.3
middleware
enabling technology of enterprise application integration (EAI) 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
4 Symbols and abbreviations
ODP Open Distributed Processing
HISA Health Informatics Service Architecture
UML Unified Modelling Language
GPIC General Purpose Information Component
5 Methodological principles
5.1 Language and notation adopted for the specification of the model (informative)
The objective of the information viewpoint specification is to describe the information relevant for the
enterprise to be handled by the middleware. 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.
While the general approach of the ODP standard is also used for ISO 12967-1, the modelling language to be
used is UML, which was not available at the time of the first edition of the ODP standard.
The information viewpoint is concerned with information modelling (i.e. the kinds of information handled by the
system). It focuses on the semantics of information and information processing in the system. The individual
components of a distributed system must 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 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.
2 © ISO 2009 – All rights reserved
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 may appear 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.
Emphasis may be placed 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 modelling 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 (informative)
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 tables describing the classes (e.g. “Period of care” in the diagram will become
“PeriodOfCare” in the tables, “Subject of care” in the diagram will become “SubjectOfCare”). Blank
spaces are left in the diagrams for readability reasons.
⎯ Associations will be labelled when the label adds value to the diagram.
⎯ Associations may be labelled through a property, or through a verb phrase; in the latter case, an arrow
will be 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, for readability reasons, 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
holds.
⎯ 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 modelling 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
6.2 to 6.4 of ISO 12967-1:2009.
Figure 2 shows, at a first level of abstraction, the main objects of the model and their relations according to the
concepts identified in the enterprise viewpoint, with respect to the fundamental workflows and groups of users’
activities to be supported by the middleware.
By proceeding according to the same methodology adopted for the specification of the enterprise viewpoint,
this high-level model can be refined by identifying seven clusters of objects, each of them responsible for
organizing and storing the information necessary for supporting the users’ activities identified in the related
areas of the enterprise viewpoint.
1) Classification objects
These objects shall organize and store the information necessary for supporting the users’ activities related to
the management of classifications, coding criteria and dictionaries, as identified in ISO 12967-1.
2) Subject of care objects
These objects shall organize and store the information necessary for supporting the users’ activities identified
in the “Subject of Care workflow” of ISO 12967-1.
3) Activity management objects
These objects shall organize and store the information necessary for supporting the users’ activities identified
in the “Activity Management workflow” of ISO 12967-1.
4) Clinical and health objects
These objects shall organize and store the information necessary for supporting the users’ activities identified
in the “Clinical Information workflow” of ISO 12967-1.
5) Resources objects
These objects shall organize and store the information necessary for supporting the users’ activities related to
the management of resources, as identified in ISO 12967-1.
6) Users and authorization objects
These objects shall organize and store the information necessary for supporting the users’ activities related to
the management of users and authorizations, as identified in ISO 12967-1.
4 © ISO 2009 – All rights reserved
is derived from >
Is subject to >
Is requesting/performing >
< groups
Is generated by /
is relevant for >
belong to >
7) Messaging objects
These objects shall organize and store the information necessary for supporting the structuring of data and
the communications with other systems through messaging mechanisms, as identified in ISO 12967-1.
These clusters of objects are specified in Clause 7 by means of UML models.
< is responsible for
Healthcare provider Individual User
Clinical Information
Resource
Authorization Profile
< is used by
Clinical Guidelines
Health Issue
< is related to
Activity
Protocol
executed regarding >
Plan
< has < is instantiated for
Contact Subject of Care
< has
Period of Care
< is determined by
Figure 2 — High-level model of the information objects
5.4 Operational and descriptive information: classifications, knowledge and its
instantiation
From the textual descriptions in the enterprise viewpoint, the middleware 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.
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 organization-related, specifying the criteria according to which the organization
works and is organized. 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 3.
Descriptive Operational
information objects information objects
Class
Class
instantiate
“Type of XXXXX” “XXXXX”
Main classification,
properties, rules,
Actual live data
default values, etc.
Type of Activity instantiate
Activity
Figure 3 — 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 may need to 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 4.
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. Also in this case, 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 may 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 2009 – All rights reserved
Descriptive
classifications,
information objects
properties, rules, etc.
0.* 0.*
Concept
HISA class
0.*
May be classified
through
0.*
HISA class
attribute
0.1
0.1
Actual
0.*
classification
0.*
HISA class
instance Operational
information objects
Actual live data
Figure 4 — Further classification criteria for each HISA class
5.5 DataTypes
The primitive data types given in Table 1 are used in this specification.
Table 1
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 IEEE 754)
Octet 8-bit code, as defined in ISO/IEC 11404:2007
On the basis of the primitive data types, the following HISA data types are also used in this specification to
further define the meaning of data values that can be assigned to a data element.
Table 2
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 Representation of date and time at least up to the level of the
millisecond.
DateTime String Representation of date and time at least up to the level of the
second.
Ordinal Integer A number which defines a position in an ordered series (CEN/TS
14796:2004).
Unit String Unit of measure, expressed according to codes defined in the
“Unified Code for Units of Measures”
(http://aurora.rg.iupui.edu/UCUM).
URI String Telecommunication address as specified by Internet standard
RFC 1738 (http://www.isi.edu/in-notes/rfc1738.txt) as relates to
one of the following schema codes: “http” (RFC 2068), “ftp” (RFC
1738), “file” (RFC 1738).
SET Value that contains multiple values of the data type specified as
its elements.
5.6 Organization of the document
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 the relevant sections; 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.
⎯ Informative Annex A summarizes essential guidelines on the UML notation adopted for the specification
of the schemas.
8 © ISO 2009 – All rights reserved
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 the classes in the diagrams 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.);
⎯ 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
may by 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 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 part of ISO 12967, which only 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 Figure 5 are specified in 6.3, except the HISA Concept class, which is specified in 7.1.3.2.
next version >
0.1
0.1
0.*
Generic HISA
State changes
class
0.*
0.*
0.*
0.* 0.1 Structured
Extended attributes
Classification criteria Business rules
classified attribute >
attributes set
0.*
1 1
Class-specific
Common
attributes set
attributes set
1 1
Version System
attributes set attributes set
HISA Concept class
Figure 5 — The generic HISA class
10 © ISO 2009 – All rights reserved
< classified through
6.3 Specification of Generic HISA Class
6.3.1 General
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
6.3.2 Class: Set of structured 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 code of the object, allowing to
uniquely identify the instance of the class.
timestamp InternalTimestamp Internal Timestamp of the last update of the instance,
creationTime DateTime Identifies time and date of the original creation of the
instance
creationAgent ObjectIdentifier Identifier (i.e. instanceID) of the individual that has
initially created the instance.
creationUnit ObjectIdentifier Identifier (i.e. instanceID) of the unit of the organization
that has initially created the instance
updateTime DateTime Identifies time and date of the last update of the
instance.
updateAgent ObjectIdentifier Identifier (i.e. instanceID) of the individual that has
executed the last modification in the instance.
updateUnit ObjectIdentifier Identifier (i.e. instanceID) of the unit of the organization
that has executed the last modification in the instance.
authorization String Specific constraints with respect to the authorization
rights on reading, updating or deleting the specific
instance.
isDeleted Boolean If True, specifies that the instance has been logically
deleted.
isFrozen Boolean If True, specifies that the instance cannot be modified.
6.3.6 Class: Set of version attributes
Class identifier: VersionAttributes
Description attributes, common to all objects, supporting the definition and management of multiple versions of the
instance of the object
Associated classes Type of association Multiplicity
none
Attribute
...
NORME ISO
INTERNATIONALE 12967-2
Première édition
2009-08-15
Informatique de santé — Architecture de
service —
Partie 2:
Point de vue d'information
Health informatics — Service architecture —
Part 2: Information viewpoint
Numéro de référence
©
ISO 2009
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier
peut être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence
autorisant l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées
acceptent de fait la responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute
responsabilité en la matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info
du fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir
l'exploitation de ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation,
veuillez en informer le Secrétariat central à l'adresse donnée ci-dessous.
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2009
Droits de reproduction réservés. Sauf prescription différente, 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 et les microfilms, sans l'accord écrit
de l'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Version française parue en 2011
Publié en Suisse
ii © ISO 2009 – 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 Symboles et abréviations .2
5 Principes méthodologiques .2
5.1 Langage et notation adoptés pour la spécification du modèle (informatif).2
5.2 Principes de notation et profil du diagramme de classes UML (informatif).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 Organisation du document.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.11
7 Modèles d'information de référence.15
7.1 Objets classification.15
7.2 Objets sujet de soins .19
7.3 Objets gestion d'activité .25
7.4 Objets informations cliniques et de santé.33
7.5 Objets gestion des ressources .39
7.6 Objets utilisateurs et autorisations .45
7.7 Objets messagerie.51
Annexe A (informative) Mises en correspondance de HISA et de GPIC .56
Bibliographie.58
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 (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 2.
La tâche principale des comités techniques est d'élaborer les Normes internationales. Les projets de Normes
internationales adoptés par les comités techniques sont soumis aux comités membres pour vote. Leur
publication comme Normes internationales requiert l'approbation de 75 % au moins des comités membres
votants.
L'attention est appelé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.
L'ISO 12967-2 a été élaborée par le comité technique ISO/TC 215, Informatique de santé, sur la base de la
Norme européenne EN 12967-2:2007 en y apportant des modifications éditoriales mineures.
L'ISO 12967 comprend les parties suivantes, présentées sous le titre général Informatique de santé —
Architecture de service:
⎯ Partie 1: Point de vue d'entreprise
⎯ Partie 2: Point de vue d'information
⎯ Partie 3: Point de vue informatique
iv © ISO 2009 – Tous droits réservés
Introduction
L'ISO 12967 est une norme en plusieurs parties établissant 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 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 la couche interstitielle), distincte des applications individuelles et accessible par tout le
système d'information grâce à des services (voir Figure 1).
Applications
Domaine
d'application
de la norme
Couche interstitielle d'objets intégrant les données communes et la
logique métier commune
Figure 1 — Domaine d'application
L'architecture générale est formalisée conformément à l'ISO/CEI 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 d'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 qui
doivent être pris en charge par l'information et la fonctionnalité de la couche interstitielle. Il fournit
également des lignes directrices 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 d'entreprise est spécifié dans l'ISO 12967-1.
b) Point de vue d'information: il spécifie les aspects sémantiques fondamentaux du modèle d'information à
mettre en œuvre par la couche interstitielle afin d'intégrer les données d'entreprise communes et de
prendre en charge les exigences de l'entreprise formalisées dans l'ISO 12967-1. Il donne également les
lignes directrices quant à la manière dont une entreprise individuelle peut étendre le modèle standard en
ajoutant les concepts supplémentaires nécessaires à la prise en charge des exigences locales en termes
d'informations devant être mises en commun.
Le point de vue d'information est spécifié dans la présente partie de l'ISO 12967.
c) Point de vue informatique: il spécifie le domaine d'application et les caractéristiques des services qui
doivent être fournis par la couche interstitielle permettant d'accéder aux données communes et
d'exécuter la logique applicative prenant en charge les processus d'entreprise identifiés dans le point de
vue d'information et dans l'ISO 12967-1. Il donne également les lignes directrices quant à la manière dont
une entreprise individuelle peut spécifier les services supplémentaires nécessaires à la prise en charge
d'exigences spécifiques locales en termes de logique applicative commune devant être mise en œuvre.
Le point de vue informatique est spécifié dans l'ISO 12967-3.
NORME INTERNATIONALE ISO 12967-2:2009(F)
Informatique de santé — Architecture de service —
Partie 2:
Point de vue d'information
1 Domaine d'application
La présente partie de l'ISO 12967 spécifie les caractéristiques fondamentales du modèle d'information qu'une
couche architecturale spécifique (c'est-à-dire la couche interstitielle) du système d'informations doit mettre en
place pour assurer le stockage cohérent et intégré des données d'entreprise communes et supporter les
processus métiers fondamentaux de l'organisme de santé, tel que défini dans l'ISO 12967-1.
Le modèle d'information est spécifié sans émettre d'hypothèse (explicite ou implicite) sur les technologies
physiques, les outils ou les solutions à adopter dans les différents scénarios cibles. 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.
La spécification n'a pas pour objet d'être une représentation fixe et exhaustive de 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 et individuelles)
identifiées comme étant essentielles pour tous les organismes de santé et que le modèle d'information mis en
place par la couche interstitielle doit satisfaire.
Tout en préservant la cohérence avec les dispositions de la présente partie de l'ISO 12967, les mises en
place physiques doivent permettre une extension vers un 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 de la présente partie de l'ISO 12967 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:2009, Article 7.
2 Références normatives
Les documents de référence suivants sont indispensables à l'application 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/CEI 11404:2007, Technologies de l'information — Types de données à but général (GPD)
ISO 12967-1:2009, Informatique de santé — Architecture de service — Partie 1: Point de vue d'entreprise
ISO 12967-3:2009, Informatique de santé — Architecture de service — Partie 3: Point de vue informatique
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent.
3.1
objet d'information
informations que détient le système, relatives aux entités du monde réel, y compris le système ODP lui-même,
et qui sont 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.3
couche interstitielle
technologie d'activation du système d'intégration d'applications d'entreprise (IAE) 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 des logiciels et systèmes informatiques pour intégrer un ensemble
d'applications informatiques d'entreprise
4 Symboles et abréviations
ODP Open Distributed Processing (Traitement réparti ouvert)
HISA Health Informatics Service Architecture (Architecture des services d'informations de santé)
UML Unified Modelling Language (Langage de modélisation unifié)
GPIC General Purpose Information Components (Composants d'informations à usage général)
5 Principes méthodologiques
5.1 Langage et notation adoptés pour la spécification du modèle (informatif)
L'objectif du point de vue d'information consiste à décrire les informations pertinentes pour l'entreprise que la
couche interstitielle 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 d'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.
Si l'approche générale de la norme ODP est également utilisée pour l'ISO 12967-1, le langage de
modélisation à utiliser est l'UML, qui n'était pas disponible lors de la première édition de la norme ODP.
Le point de vue d'information porte sur la modélisation des informations, c'est-à-dire les types d'informations
traitées 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, les composants individuels d'un système réparti doivent
partager 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 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,
2 © ISO 2009 – Tous droits réservés
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, de leurs relations et de leurs comportements. 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 d'entreprise le seront du point de vue d'information et inversement.
Par exemple, une activité appréhendée du point de vue d'entreprise peut apparaître dans le point de vue
d'information sous la forme d'une 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. Une emphase peut être placée sur la classification et la reclassification des types
d'informations ou sur 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 (informatif)
Pour chaque groupe d'objets identifiés dans le point de vue d'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 seront pas colorés;
⎯ les classes qui ne sont pas formellement groupées dans le module seront également représentées s'il
existe des liens entre elles et les classes appartenant au module. Toutefois, elles doivent apparaître 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 les tableaux décrivant les classes (par exemple «Période de
soins» et «Sujet de soins» dans le diagramme doivent devenir respectivement «PériodeDeSoins» et
«SujetDeSoins» dans les tableaux). Les espaces sont maintenus dans les diagrammes pour des raisons
de lisibilité;
⎯ les associations sont libellées lorsque cela permet d'ajouter une valeur au diagramme;
⎯ les associations peuvent être libellées à l'aide d'une propriété ou d'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 lorsque le langage UML est utilisé 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, ce qui suit s'applique:
⎯ 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 d'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é;
⎯ les types de données des propriétés doivent s'afficher 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 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 0.* ou 1.*;
⎯ si un symbole de composition est utilisé, la cardinalité non affichée est toujours «1».
5.3 Groupes d'objets du modèle d'information
La spécification de la vue «information» est conçue en tenant compte des éléments de la spécification de la
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, cette spécification du point de vue «d'information» intègre les informations traitées par le
système, comme l'explique l'ISO 12967-1:2009, 6.2 à 6.4.
La Figure 2 illustre, à un premier niveau d'abstraction, les principaux objets du modèle et les relations qu'ils
entretiennent selon les concepts identifiés dans le point de vue d'entreprise, en fonction des flux de travaux
ou workflows fondamentaux et des groupes d'activités des utilisateurs que la couche interstitielle doit prendre
en charge.
En se conformant à la méthodologie adoptée pour la spécification du point de vue d'entreprise, ce modèle de
niveau élevé peut être affiné en identifiant sept groupes d'objets, chacun d'eux étant responsable de
l'organisation et du stockage des informations nécessaires à la prise en charge des activités des utilisateurs
identifiées dans les domaines correspondants du point de vue d'entreprise.
1) Objets classification
Ces objets doivent organiser et stocker 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, telles
qu'identifiées dans l'ISO 12967-1.
4 © ISO 2009 – Tous droits réservés
Est dérivé de >
Fait l’objet d’un >
Demande / exécute >
Est généré par /
< Groupes
pertinent pour >
Appartient à >
2) Objets sujet de soins
Ces objets doivent organiser et stocker les informations nécessaires à la prise en charge des activités des
utilisateurs identifiées dans le workflow sujet de soins de l'ISO 12967-1.
3) Objets gestion d'activité
Ces objets doivent organiser et stocker les informations nécessaires à la prise en charge des activités des
utilisateurs identifiées dans le workflow gestion d'activité de l'ISO 12967-1.
4) Objets clinique et santé
Ces objets doivent organiser et stocker les informations nécessaires à la prise en charge des activités des
utilisateurs identifiées dans le workflow informations cliniques de l'ISO 12967-1.
5) Objets ressources
Ces objets doivent organiser et stocker les informations nécessaires à la prise en charge des activités des
utilisateurs liées à la gestion des ressources, telles qu'identifiées dans l'ISO 12967-1.
6) Objets utilisateurs et autorisations
Ces objets doivent organiser et stocker les informations nécessaires à la prise en charge des activités des
utilisateurs liées à la gestion des utilisateurs et des autorisations, telles qu'identifiées dans l'ISO 12967-1.
7) Objets messagerie
Ces objets doivent organiser et stocker 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, telles
qu'identifiées dans l'ISO 12967-1.
Ces groupes d'objets sont spécifiés dans l'Article 7 au moyen de modèles UML.
< Responsable de
Utilisateur
Prestataire de soins
individuel
Informations cliniques
Ressource
Profil d’autorisation
< Est utilisé par
Guide de bonnes
Problème
pratiques cliniques
< Est lié à
Activité
de santé
Protocole
Exécution selon >
Plan
< Dispose de
< Est instancié pour
Contact Sujet de soins
< Dispose de
Période de soins
< est déterminé par
Figure 2 — Modèle d'objets d'informations de niveau élevé
5.4 Informations opérationnelles et descriptives: classifications, connaissances et
instanciation
Conformément aux descriptions textuelles énoncées dans le point de vue d'entreprise, la couche interstitielle
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é.
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 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'organisation, spécifiant ses critères de fonctionnement et d'organisation.
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).
⎯ 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 3).
Objets d’information Objets d’information
descriptifs opérationnels
Classe
Classe
Instancie
“Type de XXXXX” “XXXXX”
Principales classifications,
Données réelles
propriétés, règles, valeurs
par défaut, etc. .
Type d’activité Instancie
Activité
Figure 3 — Base de connaissances mise en place par l'intermédiaire des 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, peut être classée 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 4.
6 © ISO 2009 – 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.
Classification, propriétés,
Objets d’infomation
règles, etc.
descriptifs
0.* 0.*
Concept
Classe HISA
0.*
Peut être classé
par
0.*
Attribut de classe
HISA
0.1
0.1
Classification réelle
0.*
0.*
Instance de classe
Objets d’informations
HISA
opérationnels
Données réelles
Figure 4 — Critères de classification approfondie de chaque classe HISA
5.5 Types de données
Les types de données primitives indiqués dans le Tableau 1 sont utilisés dans cette spécification.
Tableau 1
Type de données Sémantique
Chaîne Série de caractères (voir l'ISO/CEI 11404:2007)
Booléen Valeur booléenne (voir l'ISO/CEI 11404:2007)
Entier Entier, 32 bits
Double Virgule flottante en double précision (64 bits IEEE 754)
Octet Code 8 bits (voir l'ISO/CEI 11404:2007)
Sur la base des types de données primitives, les types de données HISA suivants sont également utilisés
dans cette spécification de façon à préciser la signification des valeurs qui peuvent être attribuées à un
élément de données.
Tableau 2
Type de données
Type de données HISA Sémantique
primitives
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 environnements physiques répartis.
Identificateur Chaîne Courte chaîne interprétable par l'utilisateur permettant 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, exprimée en
millisecondes au moins.
DateHeure Chaîne Représentation de la date et de l'heure, exprimée en secondes au
moins.
Ordinal Entier Nombre qui définit une position dans une série ordonnée
(CEN/TS 14796:2004).
Unité Chaîne Unité de mesure, exprimée en fonction de codes définis dans le
«code unifié des unités de mesure»
).
(http://aurora.rg.iupui.edu/UCUM
URI Chaîne Adresse de télécommunication telle que spécifiée par la norme
Internet RFC 1738 (http://www.isi.edu/in-notes/rfc1738.txt) et
associée à l'un des codes de schéma suivants: “http” (RFC 2068),
“ftp” (RFC 1738), “fichier” (RFC 1738).
SET Valeur contenant plusieurs valeurs de type de données spécifiées
comme ses éléments.
5.6 Organisation du document
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 d'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 les sections correspondantes. 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;
⎯ L'Annexe A (informative) constitue un récapitulatif des lignes directrices essentielles quant à la notation
UML adoptée pour la spécification des schémas.
8 © ISO 2009 – 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
de la classe elle-même (par exemple le nom ou le sexe de la personne);
NOTE 1 Ces attributs sont illustrés dans la liste des propriétés des classes dans les diagrammes de l'Article 7 ci-après.
⎯ 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;
⎯ 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) susceptibles d'être
appliqués 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;
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 de la présente partie de l'ISO 12967, laquelle a pour unique
objet de préciser l'aptitude de chaque objet à enregistrer et gérer ce type d'informations.
⎯ 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 elle-même et doivent enregistrer les modifications
apportées aux «attributs spécifiques» de la classe afin d'assurer le suivi du cycle de vie de l'instance
dans le temps. Ces propriétés doivent comporter, entre autres, les attributs suivants:
⎯ valeur des «attributs système» avant la modification;
⎯ identification des attributs système qui ont été modifiés;
⎯ nouvelles valeurs affectées aux attributs système qui ont été modifiés;
⎯ la date et l'heure de modification;
⎯ identification de l'agent (c'est-à-dire de la personne ou du processus métier) qui a procédé à la
modification;
⎯ ensemble d'attributs (nommés «attributs de gestion des versions»), communs à tous les objets, prenant
en charge la définition et la gestion de plusieurs versions de l'instance de l'objet, chacune d'elles étant
caractérisée par un libellé d'identification et un délai (c'est-à-dire une date de début et de fin) de validité;
À un certain moment, une ou aucune instance doit être valide, les délais ne devant donc pas se chevaucher.
⎯ relation entre une version de l'objet et l'instance représentant la version précédente;
⎯ nombre illimité de relations (nommées «critères de classification»), qui peuvent être ajoutées de manière
dynamique lors de la phase d'exécution et qui permettent de classer l'ensemble de la classe et/ou les
attributs individuels en fonction de plusieurs critères de classification, définis dans la classe «Concept»
du modèle.
6.2 Diagramme UML
Toutes les classes à la Figure 5 sont spécifiées en 6.3, à l'exception de la classe Concept HISA, qui est
spécifiée en 7.1.3.2.
Version suivante >
0.1
0.1
Classe HISA
0.*
Changement d’état
générique
0.* 0.*
0.*
0.*
0.1
Critères de Ensemble d’attributs
Attributs étendus Règles métier
structurés
classification
Attribut classé >
0.*
1 1
Ensemble d’attributs
spécifiques à la classe
Ensemble d’attributs
communs
Ensemble d’attributs Ensemble d’attributs
de la version du système
Classe de concept
HISA
Figure 5 — Classe HISA générique
10 © ISO 2009 – Tous droits réservés
< Classé par
6.3 Spécification de la classe HISA générique
6.3.1 Généralités
Identificateur de classe: ClasseHISAGénérique
Description Cette méta-classe représente les objets d'informations HISA appartenant au modèle d'information.
Classes associées Type d'association Multiplicité
AttributsStructurés Composition 1
AttributsÉtendus Composition 0.*
RèglesMétier Composition 0.*
Changementsd'État Composition 0.*
CritèresClassification Composition 0.*
Associant l'instance à plusieurs classifications
Gestion des versions Association 0.1
Associant l'instance à sa version précédente, le cas
échéant
Attributs Type Description
aucun
6.3.2 Classe: Ensemble d'attributs structurés
Identificateur de classe: AttributsStructurés
Description Ensemble de tous les attributs structurés de l'objet d'information HISA composé a) des attributs
spécifiques propres à l'objet d'information HISA et b) de l'ensemble d'attributs communs qui doivent
être présents dans toutes les classes.
Classes associées Type d'association Multiplicité
AttributsCommuns Composition 1
AttributsSpécifiquesClasse Composition 1
Attributs Type Description
aucun
6.3.3 Classe: Ensemble d'attributs spécifiques de la classe
Identificateur de classe: AttributsSpécifiquesClasse
Description Ensemble d'attributs spécifiques de l'objet d'information HISA individuel
Classes associées Type d'association Multiplicité
aucune
Attributs Type Description
Dépend de l'objet spécifique Détaillée pour chaque classe dans les spécifications
correspondantes
6.3.4 Classe: Ensemble d'attributs communs
Identificateur de classe: AttributsCommuns
Description Ensemble d'attributs communs à tous les objets d'informations HISA
Classes associées Type d'association Multiplicité
AttributsSystème Composition 1
AttributsVersion Composition 1
Attributs Type Description
aucun
6.3.5 Classe: Ensemble d'attributs système
Identificateur de classe: AttributsSystème
Description Attributs, communs à tous les objets, prenant en charge les exigences générales en termes, par
exemple, de gestion ou d'audit de l'instance
Classes associées Type d'association Multiplicité
aucune
Attributs Type Description
instanceID IdentificateurObjet Identificateur unique permanent et non modifiable de
l'instance de la classe.
afficherNom Chaîne Brève description de l'objet interprétable par l'utilisateur
pouvant être abrégée pour faciliter l'affichage.
codeUtilisateur Identificateur Court code interprétable par l'utilisateur permettant
d'identifier de manière unique l'instance de la classe.
horodatage HorodatageInterne Horodatage interne de la dernière mise à jour de
l'instance.
heureCréation DateHeure Permet d'identifier la date et l'heure de création de
l'instance.
agentCréation IdentificateurObjet Identificateur (c'est-à-dire instanceID) de la personne
qui a initialement créé l'instance.
unitéCréation IdentificateurObjet Identificateur (c'est-à-dire instanceID) de l'unité de
l'organisme qui a initialement créé l'instance.
heureMiseàJour DateHeure Permet d'identifier la date et l'heure de la dernière mise
à jour de l'instance.
agentMiseàJour IdentificateurObjet Identificateur (c'est-à-dire instanceID) de la personne
qui a apporté la dernière modification à l'instance.
unitéMiseàJour IdentificateurObjet Identificateur (c'est-à-dire instanceID) de l'unité de
l'organisme qui a apporté la dernière modification à
l'instance.
autorisation Chaîne Contraintes particulières concernant les droits d'accès
en lecture, mise à jour ou suppression de l'instance
spécifique.
estSupprimé Booléen La valeur True affectée à cet attribut indique que
l'instance a été logiquement supprimée.
estGelé Booléen La valeur True affectée à cet attribut indique que
l'instance ne peut pas être modifiée.
6.3.6 Classe: Ensemble d'attributs de version
Identificateur de classe: AttributsVersion
Description Attributs, communs à tous les objets, prenant en charge la définition et la gestion de plusieurs versions
de l'instance de l'objet
Classes associées Type d'association Multiplicité
aucune
Attributs Type Description
séquence Ordinal Numéro de séquence progressif de la version
débutDateValidité DateHeure Date de début de validité de la version de l'instance
finDateValidité DateHeure Date de fin de validité de la version de l'instance
12 © ISO 2009 – Tous droits réservés
6.3.7 Classe: Attributs étendus
Identificateur de classe: AttributsÉtendus
Description Textes formatés ou non formatés, données multimédia ou informations structurées telles que définies
par une norme différente, qui peuvent être associées/supprimées de manière dy
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...