ISO 12967-1:2009

Health informatics - Service architecture - Part 1: Enterprise viewpoint

ISO 12967-1:2009 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.

Informatique de santé — Architecture de service — Partie 1: Point de vue d'entreprise

L'ISO 12967-1:2009 donne les lignes directrices de description, de planification et de développement de nouveaux systèmes et d'intégration des systèmes d'information existants, tant dans le cadre d'une entreprise qu'entre organismes de santé, grâce à la mise en place d'une architecture intégrant les données communes et la logique applicative dans une couche architecturale spécifique (à savoir la couche interstitielle), distincte des applications individuelles et accessible par tous les systèmes d'informations grâce à des services.

General Information

• Status: Withdrawn
• Publication Date: 03-Aug-2009
• Withdrawal Date: 03-Aug-2009
• ICS: 35.240.80 - IT applications in health care technology
• Technical Committee: ISO/TC 215 - Health informatics
• Drafting Committee: ISO/TC 215/WG 1 - Architecture, Frameworks and Models
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 06-Nov-2020
• Completion Date: 13-Dec-2025

Relations

• Revised: ISO 12967-1:2020 - Health informatics - Service architecture (HISA) - Part 1: Enterprise viewpoint
• Effective Date: 26-Mar-2016

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 12967-1
First edition
2009-08-15
Health informatics — Service
architecture —
Part 1:
Enterprise viewpoint
Informatique de santé — Architecture de service —
Partie 1: Point de vue d'entreprise

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 [e-mail]
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.2
3 Terms and definitions .2
3.1 System concepts .2
3.2 Concepts relating to organization .3
3.3 Community concepts .3
3.4 Behaviour concepts .4
3.5 Policy concepts .5
3.6 Accountability concepts.5
4 Symbols and abbreviations.7
5 Methodology for the specification of the architecture .7
5.1 Viewpoints for the specification of the architecture.7
5.2 The HISA specification procedure.8
5.2.1 The Strategic Paradigm.8
5.2.2 Specification of the enterprise viewpoint .9
5.2.3 Specification of the information viewpoint.9
5.2.4 Specification of the computational viewpoint.10
5.3 Iterative specification.10
5.4 Viewpoints specification languages and notations.11
6 HISA overview.11
6.1 General requirement.11
6.2 Enterprise viewpoint.12
6.3 Information viewpoint .13
6.4 Computational viewpoint.14
7 Methodology for extensions.14
8 Conformance criteria.15
8.1 Conformance of specification documents to the HISA methodology .15
8.2 Conformance of middleware products to the HISA architectural requirements .15
9 The HISA Enterprise viewpoint .16
9.1 Introduction (informative).16
9.1.1 General.16
9.1.2 The regional, inter-enterprise perspective.17
9.1.3 The medical/clinical perspective .17
9.1.4 The operational/clinical and organizational process model perspective.19
9.1.5 The Healthcare Information Services and their complexity.25
9.2 The fundamental workflows and groups of users’ activities to be supported by the
middleware.25
9.3 General information requirements for all users’ activities .26
9.3.1 Introduction.26
9.3.2 Common attributes.26
9.3.3 Extensibility.27
9.3.4 Versioning.27
9.3.5 Auditing.27
9.3.6 Handling of life cycle.27
9.4 Subject of care workflow .28
9.4.1 Textual description of requirements.28
9.4.2 Use-case examples (informative).30
9.5 Clinical information workflow.33
9.5.1 Textual specification of requirements.33
9.5.2 Use-case examples (informative).34
9.6 Activity management workflow.35
9.6.1 Textual description of requirements.35
9.6.2 Use-case examples (informative).38
9.7 Resources management activities/Textual description of requirements .40
9.8 Management activities for users and authorizations/Textual description of requirements .41
9.9 Classifications, coding and dictionaries management activities/Textual description of
requirements .42
Annex A (informative) Highlights of Open Distributed Processing (ODP).45
Annex B (informative) Rationale for the federative structure of the Health Informatics Service
Architecture.48
Bibliography .51

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-1 was prepared by Technical Committee ISO/TC 215, Health informatics, based on the European
Standard EN 12967-1: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
The healthcare organizational structure consists of networks of centres (hospital cooperations within, for
example, counties, individual hospitals, clinics, etc.) distributed over the territory, characterized by a high
degree of heterogeneity and diversity, from organizational, logistic, clinical, technological and even cultural
perspectives. The structure of individual centres evolves from a vertical, aggregated organization towards the
integration of a set of specialized functional areas (e.g. unit of laboratory analyses, unit of surgery), with
specific needs and characteristics, nevertheless needing to share common information and to operate
according to integrated workflows. Such a situation determines two main needs which conflict with each other
in a certain way. On the one hand it is necessary to effectively support the specific requirements of each unit
or user in the most appropriate and cost-effective way whilst, on the other hand, it is vital to ensure the
consistency and integration of the overall organization, at local and territorial levels. This integration
requirement is not only related to the need for improving clinical treatments to the subject of care but is also
demanded by the urgent necessity of all countries to control and optimize the current level of expenditure for
health, whilst ensuring the necessary qualitative level of services to all subjects of care.
The large number of databases and applications, mutually isolated and incompatible, which are already
available on the market and operational in healthcare organizations to support specific needs of users, cannot
be underestimated. Even within the same centre, healthcare information systems are frequently fragmented
across a number of applications, data and functionalities, isolated and scarcely consistent with each other.
In the present circumstances, the main need for care delivery organizations is to integrate and to make
available the existing information assets, and to make possible the integration and interoperability of existing
applications, thereby protecting investments. During integration activities, continuity of service needs to be
achieved whilst gradual migration of existing proprietary, monolithic systems towards the new concepts of
openness and modularity occurs. The cost-effectiveness of the solutions, especially when projected on the
scale of the whole healthcare organization, represents another crucial aspect to be evaluated carefully.
The goal can be achieved through a unified, open architecture based on middleware independent from
specific applications and capable of integrating common data and business logic and of making them
available to diverse, multi-vendor applications through many types of deployment. According to the integration
objectives at organizational level, all aspects (i.e. clinical, organizational and managerial) of the healthcare
structure must be supported by the architecture, which must therefore be able to comprise all relevant
information and all business workflows, structuring them according to criteria and paradigms independent from
specific sectorial aspects, temporary requirements or technological solutions.
Standards and technological solutions already exist and will continue to be defined for supporting specific
requirements, both in terms of in situ user operations and with respect to the movement of information. The
architecture must be able to accommodate such requirements by allowing the specific models to be integrated
with the complete information assets of the healthcare organization and the communication messages to be
“services” extracting or importing data from/to the common information shown in Figure 1.
On the basis of these considerations, the purpose of ISO 12967 is twofold:
⎯ identify a methodology to describe healthcare information systems through a language, notation and
paradigms suitable to facilitate the planning, design and comparison of systems;
⎯ identify the fundamental architectural aspects enabling the openness, integration and interoperability of
healthcare information systems.
The architecture is therefore intended as a basis both for working with existing systems and for the planning
and construction of new systems.

vi © ISO 2009 – All rights reserved

Specific models & communication interfaces
(e.g. RIM, DICOM, GPICs, etc.)
CommoCno,mmo neutnra, nl,e ourtgraaln, isaortgaionnization - w-idew HidIe HSA mISoAde mol del
CCoommommonn,, n neeuuttrarall,, H HIISSAA momoddeell
Integrated and consistent heritage of all
common enterprise data end common business logic

Figure 1 — Complementarity and positioning of the architecture with other standards and models
It is pointed out that ISO 12967 does not aim to define a unique model for clinical, organizational, managerial
or administrative activities, but rather defines a set of workflows, information and services common to all
healthcare information systems, relevant for any healthcare sector and usable by any application also for
facilitating the mutual interworking.
Similarly, ISO 12967 does not aim to represent a final, complete set of specifications. On the contrary, it
formalizes only fundamental aspects, identified as common in all countries and considered to be currently
essential in any advanced healthcare information system. Specifications are formalized, avoiding any
dependency on specific technological products and/or solutions.
ISO 12967, therefore, is an open framework that, according to the specification methodology and preserving
the compatibility with previous versions, can be extended during time according to the evolution of the
healthcare organization both in the individual (national and local) contexts and through international
standardization initiatives.
A European pre-standard, ENV 12967-1, developed according to such rationale during 1993 to 1997 and
published in 1998, was the basis for implementations of middleware products and implemented integrations in
healthcare regions in several countries. In 2000, the CEN/TC 251 Short Strategic Study on Health Information
Infrastructure identified a number of other new architectures and health infrastructure initiatives, as well as the
requirements and possibilities for alignment with the large body of information model standards developed by
CEN for various communication purposes. European standardization initiatives have delivered a number of
object-oriented domain models and message descriptions that include an architecture for the Electronic
Health Record (ISO 13606). Cooperation between CEN and HL7 was started in the year 2000, and on the
basis of the CEN modelling principles and the HL7 Reference Information Model, this led to the definition of a
set of “General Purpose Information Components” (GPICs) usable for developing messages.
The formal major revision of the pre-standard to a European standard was started in 2003 and in 2007 this led
to the publication of the EN 12967 Parts 1 to 3 series on which ISO 12967 is based.
The following characteristics of ISO 12967 can be highlighted as follows.
⎯ The architecture is described according to the methodology of ISO/IEC 10746 (all parts), to provide a
formal, comprehensive and non-ambiguous specification suitable to serve as a reference in the planning,
design and implementation of healthcare information systems.
⎯ The scope of the architecture comprises the support to the activities of the healthcare organization as a
whole, from the clinical, organizational and managerial point of view. It therefore does not detail
specificities of different subdomains, but provides an overarching comprehensive information and
services framework to accommodate requirements.
⎯ The architecture is intrinsically compatible, complementary and synergistic with other models and
standards, such as HL7 RIM, the derived GPICs and the Electronic Health Record Architecture
ISO 13606. A separate mapping document between this HISA standard and HL7 RIM was produced
during the ISO process. Specific information objects and services are explicitly foreseen in the
architecture to facilitate the implementation of views and communication mechanisms based on such
standards.
⎯ Many of the basic concepts of ISO 12967 are aligned with EN 13940, Health informatics — System of
concepts to support continuity of care that, in June 2008, it was agreed to process also as an
International Standard.
ISO 12967 consists of three parts:
⎯ Part 1 (this part) specifies the overall characteristics of the architecture, formalizes the specification
methodology and the conformance criteria, and provides details of the enterprise viewpoint of the
architecture;
⎯ Part 2 specifies the information viewpoint of the architecture;
⎯ Part 3 specifies the computational viewpoint of the architecture.
Each part is self-consistent and is also independently utilizable for the intended purposes by different types of
users (this part being more oriented to the managerial level, Parts 2 and 3 being more dedicated to the design
activities). Nevertheless, it must be understood that they represent three aspects of the same architecture.
Mutual references therefore exist between the different parts and evolutions of the individual documents must
be carried out according to the defined methodology to preserve the overall integrity and consistency of the
specification.
The overall architecture is formalized according to ISO/IEC 10746 (all parts) and is therefore structured
through the following three viewpoints.
a) Enterprise viewpoint: specifies a set of fundamental common requirements at enterprise level with
respect to the organizational purposes, scopes and policies that 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 this part of ISO 12967.
b) Information viewpoint: specifies the fundamental semantics of the information model to be implemented
by the middleware to integrate the common enterprise data and to support the enterprise requirements
formalized in this part of ISO 12967. It also provides guidance on how one individual enterprise can
extend the standard model with additional concepts needed to support local requirements in terms of
information to be put in common.
Information viewpoint is specified in ISO 12967-2.
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 this part of ISO 12967. 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.

viii © ISO 2009 – All rights reserved

INTERNATIONAL STANDARD ISO 12967-1:2009(E)

Health informatics — Service architecture —
Part 1:
Enterprise viewpoint
1 Scope
This part of ISO 12967 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 2.
Applications
Scope of the
standard
Middleware of objects
integrating common data and common business logic

Figure 2 — Scope
This part of ISO 12967 is also independent from, and does not imply either explicitly or implicitly, any specific
technological solution or product for its deployment. Accordingly, the formalization of the architecture
according to two lower levels of the ODP reference model, the engineering and technology viewpoints, is
outside the scope of this part.
The language and notations used here for specifying the architecture are based on UML (Unified Modelling
Language) complemented by case studies and other paradigms widely utilized by other standards in health
informatics. The level of the specification is complete and non-ambiguous enough to allow its implementation
into the specific physical and technological scenarios adopted by the various healthcare organizations and
vendors. For this exercise, it is recommended to follow the methodology formalized by the Engineering and
1)
Technology viewpoints of the RM ODP Reference model .

1) For more introductory material on RM-ODP and many guideline documents see www.rm-odp.net.
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 10746-1:1998, Information technology — Open Distributed Processing — Reference model:
Overview
ISO/IEC 10746-2:1996, Information technology — Open Distributed Processing — Reference model:
foundations
ISO/IEC 10746-3:1996, Information technology — Open Distributed Processing — Reference model:
Architecture
ISO/IEC 10746-4:1998, Information technology — Open Distributed Processing — Reference model:
Architectural semantics
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1 System concepts
3.1.1
scope of a system
behaviour the system is expected to exhibit towards the enterprise it serves
3.1.2
field of application of a specification
properties that the environment of the ODP system must have for the specification of that system to be viable
3.1.3
information service
ability of the system to provide a defined set of output information based on a defined set of input information
NOTE 1 The term information service is consistently used in this part of ISO 12967 for the services provided by the
information system.
NOTE 2 The healthcare information services (HCIS) are the healthcare related services provided by healthcare
information systems.
3.1.4
viewpoint on a system
abstraction that yields a specification of the whole system related to a particular set of concerns
3.1.5
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
NOTE 1 Common programming interfaces between applications are considered as middleware. For example, Open
Database Connectivity (ODBC) enables applications to make a standard call to all the databases that support the ODBC
interface.
NOTE 2 HISA services belong to the parts of the architecture that are middleware, and they address basic aspects
dealing with the fundamental openness and sharing of information and business logic for the healthcare organization. In
this part of ISO 12967, the usage of the term “middleware” is in the context of HISA, related to the services.
2 © ISO 2009 – All rights reserved

3.1.6
enterprise application integration
EAI
use of software and computer systems architectural principles to integrate a set of enterprise computer
applications
3.2 Concepts relating to organization
3.2.1
organization
group of people and facilities with an arrangement of responsibilities, authorities and relationships
[ISO 9000:2005]
NOTE 1 The arrangement is generally orderly.
NOTE 2 An organization can be public or private.
NOTE 3 This part of ISO 12967 deals with healthcare organizations ranging from hospital cooperations within, for
example, counties, in individual hospitals, individual clinics, etc. encompassing only specific subsets of normal hospital
services.
3.2.2
organizational structure
arrangement of responsibilities, authorities and relationships between people
NOTE 1 The arrangement is generally orderly.
NOTE 2 A formal expression of the organizational structure is often provided.
NOTE 3 The scope of an organizational structure can include relevant interfaces to external organizations.
3.3 Community concepts
3.3.1
community
configuration of objects formed to meet an objective
NOTE The objective is expressed as a contract, which specifies how the objective can be met
3.3.2
federation
community of domains
3.3.3
objective
practical advantage or intended effect, expressed as preferences about future states
NOTE 1 Some objectives are ongoing, some are achieved once they are met.
NOTE 2 In the text of ITU-T Rec. X.903 (in ISO/IEC 10746-3:1996) the terms purpose and objective are synonymous.
The enterprise language systematically uses the term, objective, and emphasizes the need for expressing objective in
measurable terms.
3.3.4
community object
composite enterprise object that represents a community
NOTE The components of a community object are objects of the community represented.
3.4 Behaviour concepts
3.4.1
actor with respect to an action
enterprise object that participates in the action
NOTE It may be of interest to specify which actor initiates that action.
3.4.2
artefact with respect to an action
enterprise object that is referenced in the action
NOTE An enterprise object that is an artefact in one action can be an actor in another action.
3.4.3
resource
enterprise object which is essential to some behaviour and which requires allocation or may become
unavailable
NOTE 1 Allocation of a resource may constrain other behaviours for which that resource is essential.
NOTE 2 A consumable resource may become unavailable after some amount of use or after some amount of time (in
case a duration or expiry has been specified for the resource).
3.4.4
interface role
role of a community identifying behaviour which takes place with the participation of objects that are not
members of that community
3.4.5
process
set of interrelated or interacting activities which transforms inputs into outputs
[ISO 9000:2005]
NOTE 1 Inputs to a process are generally outputs of other processes.
NOTE 2 Processes in an organization are generally planned and carried out under controlled conditions to add value.
NOTE 3 A process where the conformity of the resulting product cannot be readily or economically verified is frequently
referred to as a “special process”.
NOTE 4 An important objective for health care today is its ability to be organized in integrated processes to ensure
continuity of care. The processes may be considered within a single organization or across organizations.
NOTE 5 The health care process is provided in the health care enterprise.
NOTE 6 When a demand for care is accepted by a health care provider, a care mandate is established stating the
mission and authorization for the health care provider to provide health care services to the subject of care. This care
mandate is the basis for decisions about which health care activities are to be performed, what the objective is for the
health care process and the receptacle for objective evidence provided by the clinical process. Through verification, the
quality of each health care activity or series of health care activities can be assessed giving prerequisites for possible
rework, repair, scrap or concession [ISO 9000:2005 definitions 3.6.7, 3.6.9, 3.6.10, and 3.6.11, respectively]. The mandate
finally reaches a point where the total requirement for the health care process has been fulfilled and the care mandate can
be terminated.
NOTE 7 In the clinical process, the health may improve, a risk for deterioration of the health may be reduced, or
knowledge about the health may be improved, something which increases the possibilities to have a positive influence on
the health.
4 © ISO 2009 – All rights reserved

NOTE 8 Processes can be influenced by events. Such an event does not occur within the process in question, but is
the conception by the process of an activity executed in another process. An event will probably lead to a change in the
decided process strategy or to a result of the process other than the intended one.
NOTE 9 ISO 10746-1 defines process as: a collection of steps taking place in a prescribed manner and leading to an
objective.
3.4.6
step
abstraction of an action, used in a process, that may leave unspecified objects that participate in that action
3.4.7
service
number of processes, involving the organization in the provision of specific objectives
NOTE 1 This definition regards the services provided in the organization, with or without an electronic information
system, whereas the definition of “Information service” regards the information (input/output) provided by the system.
NOTE 2 The healthcare services are the services taking place within a healthcare organization
3.4.8
workflow
number of services, involving the organization in the provision of more complex objectives, according to
agreed procedural rules
NOTE In healthcare, the workflow will often take place based on three fundamental processes: the clinical process,
the communication process and the management process, where information, tasks and activities are shifted between
these.
3.5 Policy concepts
3.5.1
policy
set of rules related to a particular purpose
NOTE 1 A rule can be expressed as an obligation, an authorization, permission or a prohibition
NOTE 2 Not every policy is a constraint. Some policies represent an empowerment.
NOTE 3 This definition may be refined by adding authorization.
3.5.2
authorization
prescription that a particular behaviour must not be prevented
NOTE Unlike permission, an authorization is an empowerment
3.5.3
violation
action contrary to a rule
NOTE A rule or policy may provide behaviour that is to occur upon violation of that or some other rule or policy.
3.6 Accountability concepts
3.6.1
party
enterprise object modelling a natural person or any other entity considered to have some of the rights, powers
and duties of a natural person
NOTE Examples of parties include enterprise objects representing natural persons, legal entities, governments and
their parts, and other associations or groups of natural persons.
3.6.2
commitment
action resulting in an obligation by one or more of the participants in the act to comply with a rule or perform a
contract
NOTE The enterprise object(s) participating in an action of commitment may be parties or agents acting on behalf of
a party or parties. In the case of an action of commitment by an agent, the principal becomes obligated.
3.6.3
declaration
action that establishes a state of affairs in the environment of the object making the declaration
NOTE The essence of a declaration is that, by virtue of the act of declaration itself and the authority of the object or
its principal, it causes a state of affairs to come into existence outside the object making the declaration.
3.6.4
delegation
action that assigns authority, responsibility or a function to another object
NOTE A delegation, once made, may later be withdrawn.
3.6.5
evaluation
action that assesses the value of something
NOTE 1 For example, the act by which an ODP system assigns a relative status to something, according to an
estimation by the system.
NOTE 2 Value can be considered in terms of usefulness, importance, preference, acceptability, etc; the evaluated
target may be, for example, a credit rating, a system state, a potential behaviour, etc.
3.6.6
prescription
act that establishes a rule
NOTE Specialized meaning in healthcare where a prescription of medicinal products establishes the rule that
medication can be given by a pharmacy
3.6.7
agent
enterprise object (authority, responsibility, function, etc.) that has been delegated by and acts for another
enterprise object (in exercising the authority, carrying out the responsibility, performing the function, etc.)
NOTE 1 An agent may be a party or may be the ODP system or one of its components. Another system in the
environment of the ODP system may also be an agent.
NOTE 2 The delegation may have been direct, by a party, or indirect, by an agent of the party having authorization
from the party to so delegate.
3.6.8
principal
party that has delegated (authority, a function, etc.) to another
3.6.9
contracting party with respect to a contract
party that agrees to a contract
6 © ISO 2009 – All rights reserved

4 Symbols and abbreviations
ECG Electrocardiogram
EHR Electronic Health Record
HISA Health Informatics Service Architecture
ODP Open Distributed Processing
SOA Service Oriented Architecture
UML Unified Modelling Language
5 Methodology for the specification of the architecture
This clause describes the methodology adopted by this part of ISO 12967 for the specification of the
architecture. The same methodology shall be used by healthcare enterprises and industrial vendors for
describing the characteristics of HISA-conformant systems. The scope of the methodology is the specification
of the contents of the documents that will be delivered for describing the architecture. The formalization of the
process according to which a system is identified, planned, designed and implemented is outside the scope of
this part of ISO 12967; the ODP approach described in this clause may nevertheless provide guidance for the
definition of such a process.
Subclause 5.1 provides an overview on the viewpoint-based ODP methodology. Subclause 5.2 specifies how
this is used in HISA (for the enterprise, information and computation viewpoints themselves) and how the
characteristics of HISA-conformant systems should be described.
5.1 Viewpoints for the specification of the architecture
The methodology defined by ISO/IEC 10746 (all parts) shall be used for the specification of a healthcare
service architecture that shall be structured through five viewpoints, individually specifying a particular set of
concerns of the whole system:
⎯ Enterprise viewpoint, which is concerned with the purpose, scope and policies governing the activities
of the specified system within the organization of which it is a part;
⎯ Information viewpoint, which is concerned with the kinds of information handled by the system and
constraints on the use and interpretation of that information;
⎯ Computational viewpoint, which is concerned with the functional decomposition of the system into a set
of objects that interact through formalized interfaces;
⎯ Engineering viewpoint, which is concerned with the infrastructure required to support system
implementation and distribution;
⎯ Technology viewpoint, which is concerned with the choice of technology to support system
implementation and distribution.
For each viewpoint there is an associated viewpoint language that can be used to express a specification of
the system from that viewpoint. The object modelling concepts give a common basis for the viewpoint
languages and make it possible to identify relationships between the different viewpoint specifications and to
assert correspondences between the representations of the system in different viewpoints.
This part of ISO 12967 formalizes the enterprise, information and computational viewpoints illustrated in
Figure 3. Systems conformant to HISA shall be described by means of the same three viewpoints,
complemented with the specification of the infrastructural and technological characteristics. Such aspects
should be described according to the criteria defined by the ODP engineering and technology viewpoints.
NOTE An actual implementation of the HISA services could be described as a Service Oriented Architecture (SOA),
e.g. in the form of web services.
Enterprise Viewpoint
Define major requirements
Detailed from
Identify main classes
organizational
Identify life cycles of concepts
perspective
Use Cases
Detailed from
Detailed from
information perspective
information
perspective
Information Viewpoint
Strategic
Description, in UML and textual formalism, of
Paradigm
the main classes, their properties, and their
associations
Detailed from
computational perspective
Detailed from
computational
Computational Viewpoint
perspective
Description of the functional models
of the service
Textual and formal specification of the
access mechanisms to use the services
(interface specification , including the input
and output parameters)
Description of the modalities to bind (i.e.
use) the interfaces (among others IDL).

Figure 3 — Three (of five) ODP viewpoints detailed in HISA

5.2 The HISA specification procedure
5.2.1 The Strategic Paradigm
The specification of the architecture shall start with a concise, managerial-oriented document (the “Strategic
Paradigm”) that identifies (at a high level of abstraction) the overall requirements and strategic objectives of
the envisaged system. It describes, in natural language:
⎯ the rationale and scope of the IT system with respect to the overall enterprise;
⎯ fundamental organizational processes (as defined under terms and definitions) that can be identified in
the enterprise and that are relevant for the envisaged system;
⎯ fundamental constraints and objectives to be satisfied.
NOTE Subclause 6.2 further details what the content of a strategic paradigm of an enterprise should include.
By evolving and refining the Strategic Paradigm and conforming to it, the architecture shall then be described
through the different viewpoints up to a complete and formal specification of the individual areas of concern,
detailed to represent non-ambiguous terms of reference for
⎯ planning of development and evolution processes,
⎯ design and implementation of deployed systems, and
⎯ description and comparison of different products.
The methodology for carrying out the specification includes the following three viewpoints.
8 © ISO 2009 – All rights reserved

5.2.2 Specification of the enterprise viewpoint
An objective of this specification is the formalization of the requirements to be satisfied by the system from the
point of view of the target healthcare enterprise and the field of application (of the specification), expressed in
terms of user activities to be supported and man-machine interaction according to which such activities shall
be supported by the system.
The specification shall be structured hierarchically, through
...

NORME ISO
INTERNATIONALE 12967-1
Première édition
2009-08-15
Informatique de santé — Architecture de
service —
Partie 1:
Point de vue d'entreprise
Health informatics — Service architecture —
Part 1: Enterprise 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 [e-mail]
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.2
3 Termes et définitions .2
3.1 Concepts liés au système .2
3.2 Concepts liés à l'organisme .3
3.3 Concepts liés à la communauté.3
3.4 Concepts liés au comportement.4
3.5 Concepts de politique.5
3.6 Concepts liés à la responsabilité.5
4 Symboles et abréviations .7
5 Méthodologie pour la spécification de l'architecture .7
5.1 Points de vue pour la spécification de l'architecture .7
5.2 Procédure de spécifications HISA.8
5.3 Spécification itérative .10
5.4 Langages et notations de la spécification des points de vue .11
6 Présentation de HISA.11
6.1 Exigences générales.12
6.2 Point de vue de l'entreprise.12
6.3 Point de vue d'information .14
6.4 Point de vue informatique .15
7 Méthodologie des extensions .15
8 Critères de conformité .16
8.1 Conformité des documents de spécification à la méthodologie HISA .16
8.2 Conformité des produits de couche interstitielle aux exigences architecturales de HISA .16
9 Point de vue d'entreprise de HISA.17
9.1 Introduction (informative).17
9.2 Workflows fondamentaux et groupes d'activités des utilisateurs supportés par la couche
interstitielle .26
9.3 Exigences en matière d'informations générales pour toutes les activités des utilisateurs.27
9.4 Workflow du sujet de soins.29
9.5 Workflow des informations cliniques.35
9.6 Workflow de la gestion de l'activité.37
9.7 Activités de gestion des ressources/Description textuelle des exigences.42
9.8 Activités de gestion des utilisateurs et des autorisations/description textuelle des
exigences .43
9.9 Activités de gestion des classifications, du codage et des dictionnaires/description
textuelle des exigences .44
Annexe A (informative) Présentation du traitement réparti ouvert (ODP) .47
Annexe B (informative) Logique de structure fédérative de l'architecture HISA .50
Bibliographie.53

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-1 a été élaborée par le comité technique ISO/TC 215, Informatique de santé, sur la base de la
Norme européenne EN 12967-1: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
Le système de santé se compose de réseaux d'organisations de santé (coopérations entre établissements de
santé au niveau local, hôpitaux individuels, cliniques, etc.) répartis sur tout le territoire, caractérisés par un
degré élevé d'hétérogénéité et de diversité, au niveau organisationnel, logistique, clinique, technologique,
voire culturel. La structure des organismes de santé évolue d'une organisation globale verticale à l'intégration
d'un ensemble de domaines fonctionnels spécialisés (par exemple analyses en laboratoire, chirurgie) ayant
des besoins et des caractéristiques spécifiques, mais ressentant néanmoins le besoin de partager des
informations communes et d'agir en fonction de workflows intégrés. D'une telle situation découlent deux
nécessités principales qui s'opposent l'une à l'autre d'une certaine façon. D'une part, il est nécessaire de
soutenir efficacement les besoins spécifiques de chaque unité ou de chaque utilisateur de la manière la plus
appropriée et la plus efficiente, alors que, d'autre part, il est vital d'assurer la cohérence et l'intégration de
l'ensemble de l'organisme, tant au niveau local que territorial. Les exigences en matière d'intégration ne sont
pas uniquement liées à la nécessité d'améliorer les traitements médicaux apportés aux patients. Ils sont aussi
exigés par la demande urgente de tous les pays de contrôler et d'optimiser le niveau actuel des dépenses de
santé tout en assurant le niveau nécessaire de qualité des services à tous les patients.
Le grand nombre de bases de données et d'applications isolées et mutuellement incompatibles déjà
disponibles sur le marché, installées et opérationnelles dans les organismes de santé, afin de supporter
efficacement les besoins spécifiques des utilisateurs, ne doit pas être sous-estimé. Il arrive souvent que, dans
le même organisme, le système d'information de santé soit fréquemment fragmenté en un certain nombre
d'applications, de données et de fonctionnalités, isolées et très peu cohérentes les unes avec les autres.
Dans la situation actuelle, la nécessité principale des organismes de santé est d'intégrer et de rendre
disponibles les informations existantes, de rendre possible l'intégration et l'interopérabilité des applications
déjà existantes et de protéger ainsi les investissements. Lors des activités d'intégration, la continuité du
service doit être maintenue, tout en facilitant une migration progressive des systèmes propriétaires et
monolithiques existants vers les nouveaux concepts d'ouverture et de modularité. La rentabilité des solutions,
surtout lorsqu'elle est projetée à l'échelle de tout l'organisme de santé, représente un autre aspect crucial qui
doit être évalué soigneusement.
L'objectif peut être atteint grâce à une architecture unifiée ouverte reposant sur une couche interstitielle
indépendante des applications spécifiques et en mesure d'intégrer des données communes et des logiques
applicatives et de les mettre à la disposition des différentes applications multi-prestataires par un déploiement
adapté à chacune des situations. Conformément aux objectifs d'intégration au niveau organisationnel,
l'architecture doit être en mesure de prendre en charge tous les aspects, qu'ils soient cliniques,
organisationnels ou de gestion. Par conséquent, elle doit être en mesure d'inclure toutes les informations
pertinentes et tous les workflows métiers, en les structurant en fonction de critères et de paradigmes
indépendants des aspects sectoriels particuliers, des besoins temporaires ou des solutions technologiques.
Des normes et des solutions technologiques existent déjà. Leur définition se poursuivra de façon à prendre en
charge les exigences spécifiques, tant en termes de besoins de l'utilisateur in situ que par rapport au
mouvement des informations. L'architecture doit être en mesure de s'adapter à ces exigences en facilitant
l'intégration de modèles spécifiques aux informations existantes de l'organisme de santé et la communication
par l'apport de «services» permettant l'extraction ou l'import de données depuis/vers les informations mises
en commun (voir Figure 1).
Sur la base de ces considérations, l'objectif de l'ISO 12967 est double:
⎯ identifier une méthodologie afin de décrire les systèmes d'informations de santé au moyen d'un langage,
d'une notation et de paradigmes pertinents facilitant la planification, la conception et la comparaison des
systèmes;
⎯ identifier les aspects fondamentaux de l'architecture assurant l'ouverture, l'intégration et l'interopérabilité
des systèmes d'informations de santé.
Par conséquent, l'architecture est prévue pour servir de base à la gestion des systèmes existants. Elle est
également utile à la planification et à la construction de nouveaux systèmes.
Modèles spécifiques et interfaces de communication
(par exemple RIM, DICOM, GPIC, etc.)
Modèle commun HISA neutre au sein de l'organisme
Héritage intégré et cohérent de toutes les données de
l'entreprise et de la logique métier commune

Figure 1 — Complémentarité et positionnement de l'architecture avec d'autres normes et modèles
Il convient de souligner que l'ISO 12967 n'a pas pour objet de définir un modèle unique pour les activités
médicales, organisationnelles, administratives et de gestion. Son objectif est plutôt de définir un ensemble de
workflows, d'informations et de services spécifiques de santé, communs à tous les systèmes d'information de
santé, adapté à tous les secteurs de santé et utilisables par toute application pour faciliter leur interopérabilité.
De même, l'ISO 12967 n'a pas pour objet de représenter un ensemble de spécifications définitif et exhaustif.
Au contraire, elle formalise uniquement les aspects fondamentaux, communs à tous les pays européens et
considérés actuellement comme essentiels dans un système d'information de santé avancé. Les
spécifications sont formalisées, ce qui permet d'éviter toute dépendance vis-à-vis de produits et/ou de
solutions technologiques spécifiques.
Par conséquent, l'ISO 12967 se situe dans un cadre ouvert qui, conformément à la méthodologie de
spécification et en préservant la compatibilité avec les versions précédentes, peut être étendu en fonction de
l'évolution de l'organisme de santé tant du point de vue des contextes individuels (nationaux et locaux) que
des initiatives de normalisation internationales.
Un projet de norme européenne, l'ENV 12967-1, a été élaboré conformément à ces justifications entre 1993
et 1997 et a été publié en 1998. Il a servi de base à la mise en œuvre de produits d'infrastructure d'intégration
dans le domaine de la santé dans plusieurs pays. En 2000, la courte étude stratégique sur l'infrastructure de
l'information en matière de santé du CEN/TC 251 a identifié un certain nombre de nouvelles architectures et
d'initiatives d'infrastructure de santé ainsi que des exigences et possibilités d'alignement sur un large éventail
de normes relatives au modèle d'information développées par le CEN pour différents besoins de
communication. En outre, des initiatives de normalisation européenne ont permis de proposer un certain
nombre de modèles de domaine orientés objet et de descriptions de message comprenant une architecture
de dossiers informatisés de santé (EN 13606). Une coopération entre le CEN et le HL7 a également été mise
en place en 2000. Sur la base des principes de modélisation du CEN et du modèle RIM (Référence
Information Model) du HL7, cette coopération a permis de définir un ensemble de «Composants
d'informations à usage général» (GPIC) pour développer les messages.
La révision principale formelle du projet de norme en vue d'en faire une norme européenne a commencé en
2003 et cela a conduit en 2007 à la publication de la série de normes EN 12967-1 à EN 12967-3 sur laquelle
se fonde l'ISO 12967.
vi © ISO 2009 – Tous droits réservés

Les caractéristiques suivantes de l'ISO 12967 peuvent être mises en valeur comme suit.
⎯ L'architecture est décrite conformément à la méthodologie de l'ISO/CEI 10746 (toutes les parties) de
façon à fournir une spécification formelle, exhaustive et sans ambiguïté apte à faire office de référence
dans le cadre de la planification, de la conception et de la mise en place de systèmes d'informations de
santé.
⎯ Le domaine d'application de l'architecture intègre la prise en charge de toutes les activités liées à
l'ensemble de l'organisme de santé, du point de vue clinique, organisationnel et de gestion. Par
conséquent, il ne détaille pas les particularités des différents sous-domaines, mais offre un cadre
d'informations et de services exhaustifs pour répondre à ces exigences.
⎯ L'architecture est intrinsèquement compatible, complémentaire et en totale synergie avec d'autres
modèles et normes comme HL7 RIM, les GPIC obtenus et l'ISO 13606 concernant l'architecture du
dossier de santé informatisé. Un document distinct de mise en correspondance entre la présente Norme
HISA et HL7 RIM a été produit au cours du processus de l'ISO. Pour faciliter la mise en place des vues et
mécanismes de communication reposant sur de telles normes, des objets et services d'informations
spécifiques sont explicitement prévus dans l'architecture.
⎯ De nombreux concepts fondamentaux de l'ISO 12967 sont alignés sur l'EN 13940, Informatique de
santé — Système de concepts en appui de la continuité des soins, qui, en juin 2008, a également été
reconnue par accord comme Norme internationale.
L'ISO 12967 est constituée de trois parties:
⎯ Partie 1 (la présente partie) spécifie les caractéristiques générales de l'architecture, formalise la
méthodologie de spécification et les critères de conformité et fournit des détails du point de vue d'une
entreprise concernant l'architecture;
⎯ Partie 2 spécifie le point de vue d'information concernant l'architecture;
⎯ Partie 3 spécifie le point de vue informatique concernant l'architecture.
Chaque partie est auto-cohérente et peut être également utilisée indépendamment pour les buts visés par
différents types d'utilisateurs (la présente partie étant davantage orientée vers le niveau de gestion, les
Parties 2 et 3 étant davantage dédiées aux activités de conception). Néanmoins, il doit être compris qu'elles
représentent trois aspects de la même architecture. Des références mutuelles existent par conséquent entre
les différentes parties et il est nécessaire de faire évoluer les documents individuels conformément à la
méthodologie définie afin de préserver l'intégrité et la cohérence globale de la spécification.
L'architecture générale est formalisée conformément à l'ISO/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 la présente partie de l'ISO 12967.
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 la présente partie de l'ISO 12967. 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 l'ISO 12967-2.
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 la présente partie de l'ISO 12967. 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.

viii © ISO 2009 – Tous droits réservés

NORME INTERNATIONALE ISO 12967-1:2009(F)

Informatique de santé — Architecture de service —
Partie 1:
Point de vue d'entreprise
1 Domaine d'application
La présente partie de l'ISO 12967 donne les lignes directrices de description, de planification et de
développement de nouveaux systèmes et d'intégration des systèmes d'information existants, tant dans le
cadre d'une entreprise qu'entre organismes de santé, grâce à la mise en place d'une architecture intégrant les
données communes et la logique applicative dans une couche architecturale spécifique (à savoir la couche
interstitielle), distincte des applications individuelles et accessible par tous les systèmes d'informations grâce
à des services (voir Figure 2).
Applications
Domaine
d'application
de la norme
Couche interstitielle d'objets intégrant les données communes et la
logique métier commune
Figure 2 — Domaine d'application
La présente partie de l'ISO 12967 est également indépendante, de manière explicite ou implicite, de toute
solution ou de tout produit technologique spécifique pour son déploiement. Par conséquent, la formalisation
de l'architecture conformément aux deux niveaux inférieurs du modèle de référence ODP, le point de vue
d'ingénierie et de technologie, ne fait donc pas partie du domaine d'application de la présente partie de
l'ISO 12967.
Le langage et les notations utilisés ici pour spécifier l'architecture reposent sur la notation UML (Unified
Modelling Language) complétés par des études de cas et des paradigmes largement utilisés par d'autres
normes en matière d'informatique de santé. Le niveau de la spécification est suffisamment exhaustif et sans
ambiguïté pour permettre sa mise en œuvre dans le cadre des scénarios physiques et technologiques
spécifiques adoptés par les différents organismes de santé et prestataires. Pour cet exercice, il est
recommandé de suivre la méthodologie formalisée par les points de vue d'ingénierie et de technologie du
1)
modèle de référence RM-ODP .
1) Pour consulter plus de documents introductifs relatifs à RM-ODP et de nombreux documents d'aide, voir le site
http://www.rm-odp.net.
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 10746-1:1998, Technologies de l'information — Traitement réparti ouvert — Modèle de référence:
Aperçu général — Partie 1
ISO/CEI 10746-2:1996, Technologies de l'information — Traitement réparti ouvert — Modèle de référence:
Fondements — Partie 2
ISO/CEI 10746-3:1996, Technologies de l'information — Traitement réparti ouvert — Modèle de référence:
Architecture — Partie 3
ISO/CEI 10746-4:1998, Technologies de l'information — Traitement réparti ouvert — Modèle de référence:
Sémantique architecturale — Partie 4
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent.
3.1 Concepts liés au système
3.1.1
domaine d'application d'un système
comportement attendu du système vis-à-vis des besoins d'une entreprise
3.1.2
champ d'application d'une spécification
propriétés dont doit disposer le système ODP pour que la spécification dudit système soit viable
3.1.3
service d'information
possibilité du système de fournir un ensemble de données de sortie en fonction d'un ensemble défini de
données d'entrée
NOTE 1 Le terme de service d'information est utilisé de manière cohérente dans la présente partie de l'ISO 12967 pour
désigner les services fournis par le système d'information.
NOTE 2 Les services d'informations de santé (SIS) sont des services de santé fournis par les systèmes d'information
de santé.
3.1.4
point de vue d'un système
abstraction qui donne une spécification du système dans son ensemble répondant à un ensemble particulier
de problèmes
3.1.5
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
NOTE 1 Les interfaces de programmation communes entre des applications sont considérées comme des couches
interstitielles. Par exemple, ODBC (Open Database Connectivity) permet aux applications d'accéder à toutes les bases de
données qui prennent en charge l'interface ODBC.
NOTE 2 Les services HISA appartiennent à des parties de l'architecture qui constituent la couche interstitielle et ils
traitent des aspects fondamentaux abordant l'ouverture fondamentale et le partage d'informations et de logique applicative
pour l'organisme de santé. Dans la présente partie de l'ISO 12967, l'utilisation du terme «couche interstitielle» se présente
dans le contexte de l'architecture HISA, associée à des services.
2 © ISO 2009 – Tous droits réservés

3.1.6
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
3.2 Concepts liés à l'organisme
3.2.1
organisme
ensemble d'installations et de personnes avec des responsabilités, pouvoirs et relations
[ISO 9000:2005]
NOTE 1 Cet ensemble est généralement structuré.
NOTE 2 Un organisme peut être public ou privé.
NOTE 3 La présente partie de l'ISO 12967 concerne les organismes de santé, des coopérations entre hôpitaux aux
cliniques individuelles, en passant par les établissements de santé etc. en incluant uniquement les sous-ensembles
spécifiques de services hospitaliers courants.
3.2.2
organisation
ensemble de responsabilités, de pouvoirs et relations entre les personnes
NOTE 1 Cet ensemble est généralement structuré.
NOTE 2 L'organisation est souvent formalisée.
NOTE 3 Le champ d'une organisation peut inclure des interfaces pertinentes avec des organismes externes.
3.3 Concepts liés à la communauté
3.3.1
communauté
configuration d'objets formée pour atteindre un objectif
NOTE L'objectif est exprimé sous la forme d'un contrat précisant la manière dont l'objectif peut être atteint.
3.3.2
fédération
communauté de domaines
3.3.3
objectif
avantage pratique ou effet prévu, exprimé en tant que préférences d'états à venir
NOTE 1 Certains objectifs sont en cours, d'autres sont terminés une fois qu'ils ont été atteints.
NOTE 2 Dans le texte de la Rec. X.903 UIT-T (dans l'ISO/CEI 10746-3:1996), les termes «but» et «objectif» sont
synonymes. Le jargon d'entreprise utilise systématiquement le terme objectif et souligne la nécessité d'exprimer un
objectif en termes mesurables.
3.3.4
objet de communauté
objet d'entreprise composite représentant une communauté
NOTE Les composants d'un objet de communauté sont des objets de la communauté représentée.
3.4 Concepts liés au comportement
3.4.1
acteur par rapport à une action
objet d'entreprise qui participe à l'action
NOTE Il peut être judicieux de préciser l'acteur qui entame cette action.
3.4.2
artefact par rapport à une action
objet d'entreprise référencé dans l'action
NOTE Un objet d'entreprise qui est un artefact dans une action peut être un acteur dans une autre.
3.4.3
ressource
objet d'entreprise essentiel à certains comportements, qui doit être attribué ou peut devenir indisponible
NOTE 1 Une attribution de ressource peut gêner d'autres comportements pour lesquels ladite ressource est essentielle.
NOTE 2 Une ressource consommable peut devenir indisponible après un certain nombre d'utilisations ou un certain
temps (si une durée ou un délai d'expiration a été précisé pour la ressource).
3.4.4
rôle de l'interface
rôle d'une communauté permettant d'identifier le comportement qui s'instaure avec la participation d'objets qui
ne font pas partie de ladite communauté
3.4.5
processus
ensemble d'activités corrélées ou interactives qui transforme des éléments d'entrée en éléments de sortie
[ISO 9000:2005]
NOTE 1 Les éléments d'entrée d'un processus sont généralement les éléments de sortie d'autres processus.
NOTE 2 Les processus d'un organisme sont généralement planifiés et mis en œuvre dans des conditions maîtrisées
afin d'apporter une valeur ajoutée.
NOTE 3 Lorsque la conformité du produit résultant ne peut pas être immédiatement ou économiquement vérifiée, le
processus est souvent qualifié de «processus spécial».
NOTE 4 De nos jours, un objectif important du système de santé est sa capacité à être organisé en processus intégrés
de façon à garantir la continuité des soins. Les processus peuvent être considérés au sein d'un seul organisme ou à
travers plusieurs organismes.
NOTE 5 Le processus de soins est fourni dans l'organisme de soins.
NOTE 6 Lorsqu'une demande de soins est acceptée par un prestataire de soins, un mandat de soins est établi en
précisant la mission et l'autorisation du prestataire de soins d'apporter les services de santé au patient. Ce mandat est la
base des décisions concernant les actes de soins de santé devant être réalisés, les objectifs et le réceptacle des preuves
matérielles fournies par le processus clinique. Ces vérifications permettent d'évaluer la qualité de chaque acte ou série
d'actes en énonçant des conditions préalables à une possible reprise, réparation, rebut ou dérogation après production
[ISO 9000:2005, définitions 3.6.7, 3.6.9, 3.6.10 et 3.6.11, respectivement]. Enfin, le mandat permet d'atteindre un point où
la totalité des exigences générales est respectée en matière de processus de santé et où le mandat de soins peut être
clos.
NOTE 7 Dans le processus clinique, la santé peut s'améliorer, tout risque de détérioration peut être écarté ou les
connaissances en matière de santé peuvent être améliorées, pour augmenter les possibilités d'avoir une influence positive
sur la santé.
NOTE 8 Les processus peuvent être influencés par les événements. Un tel événement n'est pas produit dans le
processus lui-même. Il est conçu par une activité d'un autre processus. Un événement va probablement conduire à la
modification de la stratégie du processus sélectionné ou être pris en charge par un processus différent de celui prévu.
NOTE 9 L'ISO 10746-1 définit un processus de la façon suivante: ensemble d'étapes mis en place de manière
convenue et permettant d'atteindre un objectif.
4 © ISO 2009 – Tous droits réservés

3.4.6
étape
abstraction d'une action, utilisée dans le cadre d'un processus, susceptible de laisser des objets non spécifiés
participant à l'action
3.4.7
service
nombre de processus, impliquant l'organisme quant à des objectifs spécifiques
NOTE 1 Cette définition concerne les services fournis dans l'organisme, avec ou sans système d'information
électronique, alors que la définition de «service d'information» concerne les informations (entrées/sorties) fournies par le
système.
NOTE 2 Les services de santé sont les services effectués au sein d'un organisme de santé.
3.4.8
workflow
flux de travaux
nombre de services, impliquant l'organisme quant à la définition d'objectifs plus complexes, conformément à
des règles procédurales convenues
NOTE En matière de santé, le workflow repose souvent sur trois processus fondamentaux, à savoir le processus
clinique, le processus informationnel et le processus de gestion, dans lesquels les informations, les tâches et les activités
sont transférées de l'un à l'autre.
3.5 Concepts de politique
3.5.1
politique
ensemble de règles liées à un objectif particulier
NOTE 1 Une règle peut être exprimée sous la forme d'une obligation, d'une autorisation, d'une permission ou d'une
interdiction.
NOTE 2 Les politiques ne sont pas toutes des contraintes. Certaines politiques représentent une habilitation.
NOTE 3 Cette définition peut être précisée par l'ajout du terme «autorisation».
3.5.2
autorisation
prescription selon laquelle un comportement particulier ne doit pas être évité
NOTE À l'inverse de la permission, une autorisation est une habilitation.
3.5.3
violation
action contraire à une règle
NOTE Une règle ou une politique peut produire un comportement en violation d'une ou de plusieurs autres règles ou
politiques.
3.6 Concepts liés à la responsabilité
3.6.1
partie
objet d'entreprise permettant de modéliser une personne physique ou toute autre entité considérée comme
ayant certains droits, pouvoirs et devoirs équivalents à ceux d'une personne physique
NOTE Les exemples de parties incluent les objets d'entreprise représentant des personnes physiques, des entités
juridiques, des gouvernements et leurs parties, et d'autres associations ou groupes de personnes physiques.
3.6.2
engagement
action résultant d'une obligation d'un ou de plusieurs participants dans l'action à réaliser conformément à une
règle ou en vertu d'un contrat
NOTE Dans une action d'engagement, les objets d'entreprise peuvent être les parties ou les agents agissant au nom
d'une ou de plusieurs parties. Dans le cas d'une action d'engagement par un agent, le mandant est la personne obligée.
3.6.3
déclaration
action qui établit la situation des affaires dans l'environnement de l'objet qui crée la déclaration
NOTE L'essence d'une déclaration tient, en vertu de l'acte de déclaration lui-même et de l'autorité de l'objet ou de
son mandant, en ce qu'elle permet l'existence d'une situation d'affaires indépendamment de l'objet qui crée la déclaration.
3.6.4
délégation
action qui confère une autorité, responsabilité ou fonction à un autre objet
NOTE Une fois réalisée, une délégation peut être ultérieurement retirée.
3.6.5
évaluation
action permettant d'évaluer la valeur d'un élément
NOTE 1 Par exemple, l'acte par lequel un système ODP attribue un état relatif à un élément, en fonction de l'estimation
réalisée par le système.
NOTE 2 La valeur peut être considérée en termes d'utilité, d'importance, de préférence, d'acceptabilité, etc. La cible
évaluée peut être, par exemple, une condition de crédit, un état du système, un comportement potentiel, etc.
3.6.6
prescription
acte qui établit une règle
NOTE Dans le domaine de la santé, une prescription de médicaments établit la règle selon laquelle un médicament
peut être délivré par une pharmacie.
3.6.7
agent
objet d'entreprise qui a été délégué (autorité, responsabilité, fonction, etc.) et qui agit pour le compte d'un
autre objet d'entreprise (en exerçant l'autorité, assumant la responsabilité, occupant la fonction, etc.)
NOTE 1 Un agent peut être une partie, le système ODP ou l'un de ses composants. Il peut également s'agir d'un autre
système de l'environnement du système ODP.
NOTE 2 La délégation peut être directe (par une partie) ou indirecte (par un agent de la partie ayant obtenu
l'autorisation de déléguer de la partie).
3.6.8
mandant
partie qui a délégué (une autorité, une fonction, etc.) à une autre
3.6.9
partie contractante par rapport à un contrat
partie qui accepte les termes dudit contrat
6 © ISO 2009 – Tous droits réservés

4 Symboles et abréviations
ECG Électrocardiogramme
EHR Electronic Health Record (Dossier informatisé de santé)
HISA Health Informatics Service Architecture (Architecture des services d'information de santé)
ODP Open Distributed Processing (Traitement réparti ouvert)
SOA Service Oriented Architecture (Architecture orientée service)
UML Unified Modelling Language (Langage de modélisation UML)
5 Méthodologie pour la spécification de l'architecture
Le présent article décrit la méthodologie adoptée par la présente partie de l'ISO 12967 pour spécifier
l'architecture. Les organismes de santé et les industriels doivent utiliser la même méthodologie pour décrire
les caractéristiques des systèmes HISA. Le domaine d'application de la méthodologie est la spécification du
contenu des documents qui seront livrés pour décrire l'architecture. La formalisation du processus en fonction
de laquelle un système est identifié, planifié, conçu et mis en place, n'est pas couverte par le domaine
d'application de la présente partie de l'ISO 12967. L'approche ODP décrite dans le présent article peut
néanmoins donner les lignes directrices pour définir un tel processus.
Le point de vue reposant sur la méthodologie ODP est présenté en 5.1. La manière dont la méthodologie est
utilisée dans HISA (pour les points de vue d'entreprise, d'information et informatique eux-mêmes) et dont il
convient de décrire les caractéristiques des systèmes HISA, est spécifiée en 5.2.
5.1 Points de vue pour la spécification de l'architecture
Selon les critères définis par l'ISO/CEI 10746 (toutes les parties), la spécification de l'architecture doit être
structurée autour de cinq points de vue, chacun d'eux spécifiant un ensemble particulier de problèmes dans
l'ensemble du système:
⎯ point de vue d'entreprise, qui porte sur l'objectif, le périmètre et les politiques qui régissent le système
spécifié au sein de l'organisme dont il fait partie;
⎯ point de vue d'information, qui porte sur les types d'informations traitées par le système et les
contraintes quant à l'utilisation et à l'interprétation de ces informations;
⎯ point de vue informatique, qui porte sur la décomposition fonctionnelle du système en un ensemble
d'objets qui interagissent par l'intermédiaire d'interfaces formalisées;
⎯ point de vue d'ingénierie, qui porte sur l'infrastructure nécessaire à la mise en œuvre et la répartition du
système;
⎯ point de vue de technologie, qui porte sur le choix de la technologie permettant l'implémentation et la
répartition du système.
Un langage spécifique est associé à chaque point de vue pour spécifier le système à partir de ce point de vue.
Les concepts de modélisation d'objet offrent une base commune à ces langages et permettent d'identifier les
relations entre les différentes spécifications de point de vue et d'établir des correspondances entre les
représentations du système selon ces différents points de vue.
La présente partie de l'ISO 12967 formalise les points de vue d'entreprise, d'information et informatique
(voir Figure 3). Les systèmes conformes à HISA doivent être décrits au moyen de ces trois mêmes points de
vue, auxquels s'ajoute la spécification des caractéristiques d'infrastructure et de technologie. Il convient de
décrire ces aspects en fonction des critères définis par les points de vue ODP d'ingénierie et de technologie.
NOTE Une mise en œuvre concrète des services HISA peut être décrite comme une architecture orientée service
(SOA) sous la forme, par exemple, de services Web.
Point de vue d’entreprise
□
Définir les principales exigences
Détails du point de
□
Identifier les principales classes
vue organisationnel □
Identifier les cycles de vie des concepts
□
Cas d’utilisation
Détails du point de
vue d’information
Détails du point de
vue d’information
Point de vue d’information
□
Paradigme Description UML et formalisme textuel
des classes principales, de leurs propriétés
stratégique
et de leurs associations
Détails du point de
vue informatique
Détails du point de
Point de vue informatique
vue informatique
□
Description des modèles fonctionnels des
services
□
Spécifications textuelles et formelles des
mécanismes d’accès permettant d’utiliser
les services (
spécification d’interfaces,
intégrant les paramètres d’entrée et
de sortie)
□
Description des modalités pour lier
(c’est-à-dire utiliser) les interfaces
(IDL entre autres)
Figure 3 — Trois points de vues ODP (sur cinq) dans HISA
5.2 Procédure de spécifications HISA
5.2.1 Paradigme stratégique
La spécification de l'architecture doit commencer par un document concis et orienté gestion (le «Paradigme
stratégique») identifiant (à un niveau élevé d'abstraction) les exigences et objectifs stratégiques généraux du
système envisagé. Il décrit, en langage naturel,
⎯ la logique et le domaine d'application du système informatique par rapport à l'ensemble de l'entreprise;
⎯ les processus organisationnels fondamentaux (tels qu'ils sont définis dans les termes et définitions) qu'il
est possible d'identifier dans l'entreprise et qui sont pertinents pour le système envisagé;
⎯ les contraintes fondamentales et les objectifs à atteindre.
NOTE Le contenu d'un paradigme stratégique d'une entreprise qu'il convient d'inclure est détaillé dans une plus large
mesure en 6.2.
En développant et en affinant le concept de Paradigme stratégique et en s'y conformant, l'architecture doit
être décrite grâce aux différents points de vue de façon à obtenir une spécification exhaustive
...