EN ISO 12967-1:2011

SLOVENSKI STANDARD
01-julij-2011
1DGRPHãþD
SIST EN 12967-1:2008
Zdravstvena informatika - Arhitektura storitve - 1. del: Podjetniški vidik (ISO 12967-
1:2009)
Health informatics - Service architecture - Part 1: Enterprise viewpoint (ISO 12967-
1:2009)
Medizinische Informatik - Servicearchitektur - Teil 1: Unternehmenssicht (ISO 12967-
1:2009)
Informatique de santé - Architecture de service - Partie 1: Point de vue d'entreprise (ISO
12967-1:2009)
Ta slovenski standard je istoveten z: EN ISO 12967-1:2011
ICS:
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN ISO 12967-1
NORME EUROPÉENNE
EUROPÄISCHE NORM
March 2011
ICS 35.240.80 Supersedes EN 12967-1:2007
English Version
Health informatics - Service architecture - Part 1: Enterprise
viewpoint (ISO 12967-1:2009)
Informatique de santé - Architecture de service - Partie 1: Medizinische Informatik - Servicearchitektur - Teil 1:
Point de vue d'entreprise (ISO 12967-1:2009) Unternehmenssicht (ISO 12967-1:2009)
This European Standard was approved by CEN on 10 March 2011.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European
Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national
standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN member.

This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management Centre has the same
status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2011 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 12967-1:2011: E
worldwide for CEN national Members.

Contents Page
Foreword .3

Foreword
The text of ISO 12967-1:2009 has been prepared by Technical Committee ISO/TC 215 “Health informatics” of
the International Organization for Standardization (ISO) and has been taken over as EN ISO 12967-1:2011 by
Technical Committee CEN/TC 251 “Health informatics” the secretariat of which is held by NEN.
This European Standard shall be given the status of a national standard, either by publication of an identical
text or by endorsement, at the latest by September 2011, and conflicting national standards shall be
withdrawn at the latest by September 2011.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN 12967-1:2007.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech
Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain,
Sweden, Switzerland and the United Kingdom.
Endorsement notice
The text of ISO 12967-1:2009 has been approved by CEN as a EN ISO 12967-1:2011 without any
modification.
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 12967-1:2009(E)
©
ISO 2009
ISO 12967-1:2009(E)
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

ISO 12967-1:2009(E)
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
ISO 12967-1:2009(E)
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

ISO 12967-1:2009(E)
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
ISO 12967-1:2009(E)
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

ISO 12967-1:2009(E)
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.
ISO 12967-1:2009(E)
⎯ 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.
ISO 12967-1:2009(E)
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

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

ISO 12967-1:2009(E)
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
ISO 12967-1:2009(E)
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

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