SIST EN 12967-3:2008

6/29(16., R6,67SU(1

35('67$1'$5'
QRYHPEHU
=GUDYVWYHQDLQIRUPDWLND±$UKLWHNWXUDVWRULWYH±GHO9LGLNREGHODYH
LQIRUPDFLM
+HDOWKLQIRUPDWLFV6HUYLFHDUFKLWHFWXUH3DUW&RPSXWDWLRQDOYLHZSRLQW
,&6 5HIHUHQþQDãWHYLOND

R6,67SU(1HQ
�������������� ��� �������������������������������������������������������������� ����� ����������!�����"�#$����%&�������������’� �����������( �����)� �&!������� ������*��������+� ��,�����������%������ �-� �.� �������������

---------------------- Page: 1 ----------------------
EUROPEAN STANDARD
DRAFT
prEN 12967-3
NORME EUROPÉENNE
EUROPÄISCHE NORM
August 2006
ICS

English Version
Health informatics - Service architecture - Part 3: Computational
viewpoint
Informatique de santé - Architecture des services - Partie 3: Medizinische Informatik - Servicearchitektur - Teil 3:
Point de vue traitement Verarbeitungssicht
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee CEN/TC 251.
If this draft becomes a European Standard, 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.
This draft European Standard was established by CEN 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 Management Centre has the same
status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, 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.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to
provide supporting documentation.
Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and
shall not be referred to as a European Standard.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36  B-1050 Brussels
© 2006 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 12967-3:2006: E
worldwide for CEN national Members.

---------------------- Page: 2 ----------------------
prEN 12967-3:2006 (E)
Contents
Foreword.3
1 Scope .5
2 Normative references .5
3 Terms and definitions .6
4 Abbreviations.6
5 Methodological Principles (informative) .6
5.1 Clusters of Objects.6
5.2 Computational language.7
5.3 The computational objects and Interfaces.7
5.4 Interaction.9
6 General characteristics of the Model.9
6.1 The two types of computational objects .9
6.2 The basic methods .9
6.2.1 General requirement.9
6.2.2 “Add” basic methods .10
6.2.3 “Update” basic methods.11
6.2.4 “Delete” basic methods .11
6.2.5 “Detail” basic methods .12
6.2.6 “List” basic methods.13
6.3 General purpose interface .13
6.3.1 List of methods .14
6.3.2 Behavioural specifications .14
6.4 The complex interfaces of the workflow related computational objects.14
6.4.1 Complex services managing healthcare workflows .14
6.4.2 Interfaces supporting the “Subject of Care Workflow” .14
6.4.3 Interfaces supporting the “Clinical Information workflow” .15
6.4.4 Interfaces supporting the “Activity Management workflow” .15
6.4.5 Behavioural specifications, common to the complex services .16
6.5 Common requirements of the interfaces .17
6.5.1 Interface documentation and organization .17
6.5.2 Data types.17
6.5.3 Structure and organization of the interfaces .17



2

---------------------- Page: 3 ----------------------
prEN 12967-3:2006 (E)
Foreword
This document (prEN 12967-3:2006) has been prepared by Technical Committee CEN/TC 251 “Health Informatics”,
the secretariat of which is held by NEN.
This document is currently submitted to the CEN Enquiry.
This is part 3 of a multipart standard under the general title Health informatics – Service architecture with the
following parts:
Part 1: Enterprise viewpoint
Part 2: Information viewpoint
Part 3: Computational viewpoint

3

---------------------- Page: 4 ----------------------
prEN 12967-3:2006 (E)
Introduction
This document represents the third part of EN 12967, a multi-part standard that provides guidance for the
description, planning and development of new systems as well as for the integration of existing information systems,
both within one enterprise and across different healthcare organisations through an architecture integrating the
common data and business logic into a specific architectural layer (i.e. the middleware), distinct from individual
applications and accessible throughout the whole information system through services, as shown in figure 1.1.

applications
Scope of the
standard
Middleware of objects
integrating common data and common business logic

Figure 1 — Scope of this standard

The overall architecture specified by the EN 12967 standard is formalised according to the ISO/IEC 10746 criteria
and is therefore structured through the three viewpoints:
a) The Enterprise Viewpoint that specifies a set of fundamental common requirements at enterprise level with
respect to the organisational 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 where this model is applicable) may specify and document
additional specific business requirements, with a view of achieving a complete specification, adequate for the
characteristics of that enterprise.
 The Enterprise Viewpoint is specified in Part 1 of the standard; document EN 12967-1
b) The Information Viewpoint that 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 formalised in the Enterprise Viewpoint. It also provides guidance on how one individual
enterprise may extend the standard model with additional concepts, needed to support local requirements in
terms of information to be put in common.
The Information Viewpoint is specified in Part 2 of the standard; document EN 12967-2
c) The Computational Viewpoint that specifies the scope and characteristics of the services that must be
provided by the middleware for allowing the access to the common data as well as the execution of the
business logic supporting the enterprise processes identified in the Information and Enterprise Viewpoints. It
also provides guidance on how one individual enterprise may specify additional services, needed to support
local specific requirements in terms of business logic to be put in common.
The Computational Viewpoint is specified in this document, representing Part 3 of the standard; document EN
12967-3
4

---------------------- Page: 5 ----------------------
prEN 12967-3:2006 (E)

1 Scope
HISA specifies fundamental requirements for 'information infrastructure' and healthcare specific middleware
services.
This part of the standard specifies the fundamental characteristics of the computational model to be implemented
by a specific architectural layer of the information system (i.e. the middleware) to provide a comprehensive and
integrated interface to the common enterprise information and to support the fundamental business processes of
the healthcare organisation, as defined in document “Health Informatics – Service Architecture - Part 1: Enterprise
Viewpoint”. The computational model is specified without any –explicit or implicit- assumption on the physical
technologies, tools or solutions to be adopted for its physical implementation in the various target scenarios. The
specification is nevertheless formal, complete and non-ambiguous enough to allow implementers to derive an
efficient design of the system in the specific technological environment that will be selected for the physical
implementation.
The computational model provides the basis for ensuring consistency between different engineering and
technology specifications (including programming languages and communication mechanisms) since they must be
consistent with the same computational object model. This consistency allows open inter-working and portability of
components in the resulting implementation.
This specification does not aim at representing a fixed, complete, specification of all possible interfaces that may be
necessary for any requirement of any healthcare enterprise. It specifies only a set of characteristics –in terms of
overall organisation and individual computational objects- identified as fundamental and common to all healthcare
organisations, and that shall be satisfied by the computational model implemented by the middleware.
Preserving the consistency with the provisions of this standard, physical implementations shall allow extensions to
the standard computational model in order to support additional and local requirements. Extensions shall include
both the definition of additional properties in the objects of the standard model, and the implementation of entirely
new objects.
Also this standard specification shall be extensible over time according to the evolution of the applicable
standardisation initiatives. The specification of extensions shall be carried out according to the methodology
defined in § 7 “Methodology for extensions” of document EN 12967-1 “Health Informatics – Service Architecture -
Part 1: Enterprise Viewpoint”, which identifies a set of healthcare common information services, describing their
need and the methodology through which they will be used. These are only the minimal identifiable set according to
the needs of the healthcare enterprise, and constituting the 'middleware' platform (i.e. integration platform) to serve
as the basis for healthcare applications, e.g. EHCR or patient administration.
2 Normative references
This European Standard incorporates by dated or undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed hereafter. For
dated references, subsequent amendments to or revisions of any of these publications apply to this European
Standard only when incorporated in it by amendment or revision. For undated references the latest edition of the
publication referred to applies.
ENV 12967-1: 1997 Medical Informatics – Healthcare Information System Architecture Part 1 (HISA) –
Healthcare Middleware Layer
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
5

---------------------- Page: 6 ----------------------
prEN 12967-3:2006 (E)

3 Terms and definitions
For the purposes of this European Standard the following terms and definitions apply.
3.1
interface
abstraction of the behaviour of an object that consists of a subset of the possible interaction mechanisms of that
object, together with the set of constraints when that interaction occurs
3.2
computational object
object as seen in a computational viewpoint representing the functional decomposition of a system showing a state
and behaviour as well as interactions through interfaces with other computational objects
4 Abbreviations
HISA Health Informatics - Service Architecture
ODP Open Distributed Processing
5 Methodological Principles (informative)
This part three of the standard encompasses the computational viewpoint, which is concerned in answering HISA
middleware design aspects through the functional decomposition of the system into a set of computational objects
that interact at interfaces, also enabling distribution. The Health Informatics Service Architecture will thus be further
specified in terms of computational objects, which manage information and provide services, and their interfaces,
starting from the Clusters of objects identified in part 1 Enterprise Viewpoint and further detailed in part 2
Information Viewpoint.
5.1 Clusters of Objects
The Enterprise Viewpoint has identified the scope, need and use of the HISA standard by both developers and
end users. It has described the scope of the business objects from the organisation viewpoint, by summarising the
related user activities and requirements through natural language. During this process the main Healthcare
Common clusters of objects have been identified:
1. Subject of care objects
These objects handle the information necessary for supporting the users’ activities identified in the
“Subject of Care workflow” of the Enterprise Viewpoint
2. Activity management objects
These objects handle the information necessary for supporting the users’ activities identified in the “Activity
Management workflow” of the Enterprise Viewpoint.
3. Clinical information objects
These objects handle the information necessary for supporting the users’ activities identified in the “Clinical
Information workflow” of the Enterprise Viewpoint.
4. Users and authorisation objects
These objects handle the information necessary for supporting the users’ activities related to the
management of users and authorisations, as identified in the Enterprise Viewpoint
6

---------------------- Page: 7 ----------------------
prEN 12967-3:2006 (E)
5. Resources objects
These objects handle the information necessary for supporting the users’ activities related to the
management of resources, as identified in the Enterprise Viewpoint.
6. Classification objects
These objects handle the information necessary for supporting the users’ activities related to the
management of classifications, coding criteria and dictionaries, as identified in the Enterprise Viewpoint.
7. Messaging objects
These objects handle the information necessary for supporting the structuring of data and the
communications with other systems through messaging mechanisms, as identified in the Enterprise
Viewpoint.
The Information Viewpoint has formalised the conceptual model of the information being manipulated by the
services, descending from the textual descriptions contained in the Enterprise Viewpoint. For each of the clusters of
objects, an information model composed of information objects has been identified in the information viewpoint.
This Computational Viewpoint shall define the computational model, composed of computational objects, capable
of meeting the requirements described in the Enterprise Viewpoint. It is necessary here to identify its relationship to
the information model, and the mechanisms it provides to access the information handled by the system (i.e.
methods or services).
The individual methods provided by the computational objects shall be described illustrating how they allow to
actually access the information handled by the system, identifying the interfaces of each, the constraints, as well as
which information of the underlying overall information model are accessed and eventual parallel actions are taken.
The scope of the interfaces for each cluster of objects is outlined, and the system will be illustrated in more detail
through a textual and formal specification of the interfaces to use the services (also called the “access
mechanisms”).
5.2 Computational language
The computational viewpoint is directly concerned with the distribution of processing but not with the interaction
mechanisms that enable distribution to occur. The computational specification decomposes the system into objects
performing individual functions and interacting at well-defined interfaces.
The heart of the computational language is the computational object model, which constrains the computational
specification by defining:
- the form of interface that an object can have
- the way the interfaces can be bound and the forms of interaction which can take place at them
- the actions an object can perform, in particular the creation of new objects and interfaces.
5.3 The computational objects and Interfaces
The computational objects provide the interfaces through which it is possible to access and manipulate the
information managed by the information objects described in the information viewpoint. Each cluster itself can be
seen as a computational object, providing interfaces that comprise all interfaces of the objects belonging to such
cluster. The computational objects shall be defined at the level of the HISA object.
For each cluster there will be a set of computational objects providing interfaces allowing the management of the
common information and business logic relevant to the organization. Two types of computational objects are
foreseen per cluster:
- Computational objects deriving directly from the corresponding information object (i.e. one computational object
per information object),
7

---------------------- Page: 8 ----------------------
prEN 12967-3:2006 (E)
- Higher-level computational objects providing interfaces achieving higher-level complex business logic.
Thus, the majority of the computational objects shall derive directly from the corresponding information objects. The
further higher-level of computational objects also envisaged, shall be providing interfaces achieving higher-level
complex business logic on possibly multiple information objects within the same operation. Such more complex
business logic is described in the Enterprise Viewpoint and has to do with the main workflow processes (i.e.
1
patient management, activity management, etc.).
The basic computational objects, corresponding to the information objects, will be equipped with standard lower-
level basic interfaces having the scope of adding, updating and deleting –in short maintaining-, listing, and getting
one instance of the main classes described in the information viewpoint. These basic methods allow the access to
and the manipulation of each element of the underlying model and secure the openness of the system.
An exemplification is found in the following figure.
Get List of…
Get Full Data of one…
Update one…

Figure 2 — An example of a "basic services"
The higher-level computational objects implement more complex business transactions on the objects of the
information model, simplifying and ensuring consistency of developments and building common fundamental
procedures of the organisation.
Examples are:
• Patient/person area, including registering a person, Patient Administration (ADT), merging patient
identifiers, period of care, etc.
• Activity management and life cycle, including requests, planning, booking, etc.
• Clinical and EHC record, including terminologies, classifications, problem-orientation, etc.
• Resource management, including standard usages, etc.
rreelala tivtivee to to
PePerrssoonn
SuSubbjjeeccttOOffCCaarree AgAgeenntt
? c? caarree dd b byy
HHeealaltthhccaarreePPrrovoviiddeerr
CCllininicicaallIInnffoorrmmaattioionn

Figure 3 — An example of "complex service"

1
 In this specification, the term patient shall sometimes be used for Subject of Care.
8

---------------------- Page: 9 ----------------------
prEN 12967-3:2006 (E)
The HISA middleware shall also provide a set of interfaces relating to functionalities of general utility for the
management of the overall system, with respect to the execution of particular functionalities. These services do not
pertain to any specific middleware component, and are related to general-purpose issues like session management
(logging and out of the system, setting system variables, etc.), transaction management, etc.
5.4 Interaction
Three types of interaction are envisaged in ODP: signals, operations and flows. Signals are single actions
conveying data from one object to another, while operations can be seen as “client-server” interactions between
objects in which the server object elaborates the data provided by the client, sending back a result. Flows can be
considered as a sequence of interactions (i.e. information exchanges) between objects pertaining to a specific
domain.
The interaction type is part of the interface signature. In HISA we shall focus on the interaction type operation. For
this reason it will not be explicitly referred to in this specification. Such interaction type implies the need to identify
for each computational object the role it plays in the client-server interaction. However, HISA prescribes the general
external characteristics through which each identified computational object provides interfaces, while the interaction
amongst the computational objects is not part of the standard. Thus, the role shall always be “server”.
6 General characteristics of the Model
6.1 The two types of computational objects
The computational objects provide the interfaces through which it is possible to access and manipulate the
information managed by the information objects described in the information viewpoint. The two types of
computational objects are displayed in the following figure, and shall be referred to in the following as “basic” and
“complex” computational objects according to the terminology adopted in section 5.3. The methods that these will
expose shall also be referred to in the following as “basic” and “complex”.
<>
HISAObject
<> <>
HISAComplex HISABasic



Figure 4 — The two types of computational objects

6.2 The basic methods
6.2.1 General requirement
For each class belonging to the seven clusters of objects defined in the information viewpoint the middleware shall
be equipped with a computational object equipped with a set of methods allowing to access and to manipulate
every concept (i.e. objects and properties) of the class, the generic structure of which is displayed in the following
figure.
9

---------------------- Page: 10 ----------------------
prEN 12967-3:2006 (E)
next version >
0.1
0.1
0.*
Generic HISA class State changes
1
0.* 0.*
0.*
0.*
0.1 Structured
Extended attributes Business Rules
Classification criteria
classified attribute > attributes set
0.*
1
1 1
Class-specific
1
attributes set
Common
attributes set
1 1
Version System
attributes set attributes set
1
HISA Concept class
Terminology Classification
Other

Figure 5 — General requirements on computational objects
The following methods shall be available in these computational objects.
6.2.2 “Add” basic methods
The “add” methods shall allow the client of the computational object to create instances of HISA objects.
6.2.2.1 List of methods
add create a new instance of the HISA object
Xadd create a new instance of extended data and associate it to the HISA object
Cadd create a new instance of classification criteria data and associate it to the HISA object
BRadd create a new instance of a business rule related to the HISA object and associate it to the
HISA object
6.2.2.2 Behavioural specifications
It is up to the client of the object (i.e. the caller) to pass as input valid data for the class-specific properties and for
those system and version attributes for which the default values should be overridden.
The system shall generate appropriate values for the common system and version attributes of the HISA class
when it is created, for those parameters that are not passed by the caller. In particular:
- The instance identifier shall be unique within the open distributed processing environment of the system within
the enterprise. A unique identifier of the HISA class may be specified by the caller of the operation. In such
case the service shall verify the uniqueness of the identifier.
- The system shall take care of managing state changes by adding dynamically and automatically the values that
record the changes occurred in the specific attributes of the class, thus keeping track of the life cycle of the
instance during time.
- The method shall return to the client at least the set of common attributes related to the HISA object created.
Such information shall include a value indicating successful execution of the operation or an error indicating the
reason for failure.
10
< classified through

---------------------- Page: 11 ----------------------
prEN 12967-3:2006 (E)
- The method shall implement all integrity checks with respect to the information passed by the client of
operation, rejecting it if the operation leads to an inconsistent informational state.
6.2.3 “Update” basic methods
The “update” methods shall allow the client of the operation to update instances of HISA objects.
6.2.3.1 List of methods
update update an instance of the HISA object
Xupdate update an instance of extended data associated to a HISA object
Cupdate update an instance of classification data associated to a HISA object
BRupdate update an instance of a business rule associated to a HISA object
6.2.3.2 Behavioural specifications
It is up to the client of the object to pass as input valid data for the class specific properties and for those system
and version attributes for which the default values should be overridden.
The system shall generate and/or update the appropriate vales for the common system and version attributes of
the HISA class when it is updated. In particular:
- The operation shall require in input the common attributes necessary for the update information.
- The instance identifier shall never be updated.
- An update shall not occur if the timestamp of the in
...