Health informatics - Service architecture - Part 3: Computational viewpoint

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.

Medizinische Informatik - Servicearchitektur - Teil 3: Verarbeitungssicht

Informatique de santé - Architecture des services - Partie 3: Point de vue traitement

HISA spécifie les exigences fondamentales d'une "infrastructure d'informations" et des services d'interstitiels spécifiques au domaine de la santé.
La présente partie de la norme spécifie les caractéristiques fondamentales du modèle de traitement qu'une couche architecturale spécifique (c'est-à-dire la couche interstitielle) du système d'informations doit mettre en place pour assurer une interface cohérente et intégrée aux données d'entreprise communes et prendre en charge les processus métier fondamentaux de l'organisation de santé, tel que le définit le document “Informatique de la santé – Architecture des services – Partie 1 : Point de vue Entreprise". Le modèle de traitement est spécifié sans émettre d'hypothèse (explicite ou implicite) sur les technologies physiques, les outils ou les solutions à adopter pour sa mise en place physique dans le cadre des différents scénarii cible. La spécification n'en est pas moins formelle, exhaustive et sans ambiguïté, afin de permettre aux implémenteurs de prévoir une conception efficace du système dans l’environnement technologique spécifique sélectionné pour sa mise en place physique.
Le modèle de traitement fournit la base permettant de garantir la cohérence des différentes spécifications de l'ingénierie et de la technologie (notamment des langages de programmation et des mécanismes de communication) étant donné qu'elles doivent être conformes au même objet du modèle de traitement. Cette cohérence permet de garantir l'interfonctionnement ouvert et la portabilité des composants dans la mise en place finale.
Elle n'a pas pour objet d'être une représentation fixe et exhaustive de toutes les interfaces possibles susceptibles d'être nécessaires aux exigences d'une entreprise de santé.

Zdravstvena informatika - Arhitektura storitve - 3. del: Vidik obdelave informacij

General Information

Status
Withdrawn
Publication Date
20-Dec-2007
Withdrawal Date
29-May-2011
Technical Committee
Current Stage
9900 - Withdrawal (Adopted Project)
Start Date
26-May-2011
Due Date
18-Jun-2011
Completion Date
30-May-2011

Relations

Buy Standard

Standard
EN 12967-3:2008
English language
33 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day
Draft
prEN 12967-3:2006
English language
18 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Health informatics - Service architecture - Part 3: Computational viewpointZdravstvena informatika - Arhitektura storitve - 3. del: Vidik obdelave informacijInformatique de santé - Architecture des services - Partie 3: Point de vue traitementMedizinische Informatik - Servicearchitektur - Teil 3: VerarbeitungssichtTa slovenski standard je istoveten z:EN 12967-3:2007SIST EN 12967-3:2008en35.240.80Uporabniške rešitve IT v zdravstveni tehnikiIT applications in health care technologyICS:SIST ENV 12967-1:20031DGRPHãþDSLOVENSKI
STANDARDSIST EN 12967-3:200801-februar-2008







EUROPEAN STANDARDNORME EUROPÉENNEEUROPÄISCHE NORMEN 12967-3October 2007ICS 35.240.80Supersedes ENV 12967-1:1998
English VersionHealth informatics - Service architecture - Part 3: ComputationalviewpointInformatique de la santé - Architecture des services - Partie3: Point de vue TraitementMedizinische Informatik - Servicearchitektur - Teil 3:VerarbeitungssichtThis European Standard was approved by CEN on 16 September 2007.CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this EuropeanStandard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such nationalstandards may be obtained on application to the CEN 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 translationunder the responsibility of a CEN member into its own language and notified to the CEN Management Centre has the same status as theofficial versions.CEN members are the national standards bodies of Austria, Belgium, Bulgaria, 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 STANDARDIZATIONCOMITÉ EUROPÉEN DE NORMALISATIONEUROPÄISCHES KOMITEE FÜR NORMUNGManagement Centre: rue de Stassart, 36
B-1050 Brussels© 2007 CENAll rights of exploitation in any form and by any means reservedworldwide for CEN national Members.Ref. No. EN 12967-3:2007: E



EN 12967-3:2007 (E) 2 Contents Page Foreword.3 Introduction.4 1 Scope.6 2 Normative references.6 3 Terms and definitions.6 4 Symbols and abbreviations.7 5 Methodological Principles (informative).7 5.1 General.7 5.2 Clusters of Objects.7 5.3 Computational language.8 5.4 The computational objects and Interfaces.8 5.5 Interaction.11 6 General characteristics of the Model.11 6.1 The two types of computational objects.11 6.2 The basic methods.11 6.2.1 General requirement.11 6.2.2 “Add” basic methods.12 6.2.3 “Update” basic methods.14 6.2.4 “Delete” basic methods.15 6.2.5 “Detail” basic methods.17 6.2.6 “List” basic methods.19 6.3 General purpose interface.20 6.3.1 General.20 6.3.2 List of methods.21 6.3.3 Behavioural specifications.21 6.4 The complex interfaces of the workflow related computational objects.22 6.4.1 General.22 6.4.2 Complex services managing healthcare workflows.22 6.4.3 Interfaces supporting the “Subject of Care Workflow”.22 6.4.4 Interfaces supporting the “Clinical Information workflow”.24 6.4.5 Interfaces supporting the “Activity Management workflow”.25 6.4.6 Behavioural specifications, common to the complex services.28 6.5 Common requirements of the interfaces.29 6.5.1 Interface documentation and organization.29 6.5.2 Naming criteria.29 6.5.3 Data types.30 6.5.4 Structure and organization of the interfaces.30 Annex A (informative) Examples of services.31 Bibliography.33



EN 12967-3:2007 (E) 3 Foreword This document (EN 12967-3:2007) has been prepared 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 April 2008, and conflicting national standards shall be withdrawn at the latest by April 2008. This document, together with EN 12967-1 and EN 12967-2, supersedes ENV 12967-1:1998. This document represents part two of a three-part European standard, which is a major revision of ENV 12967-1, produced under a mandate given to CEN by the European Commission and the European Free Trade Association. This multi-part standard under the general heading: Health informatics – Service architecture consists of the following parts: Part 1: Enterprise viewpoint Part 2: Information viewpoint Part 3: Computational viewpoint 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, 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.



EN 12967-3:2007 (E) 4 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.
Figure 1 — Scope of this standard
The overall architecture specified by the EN 12967 standard is formalised according to ISO/IEC 10746 and is therefore structured through the three viewpoints: a)
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 organisation 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.
Enterprise Viewpoint is specified in Part 1 of the standard; document EN 12967-1. b)
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.
Information Viewpoint is specified in Part 2 of the standard; document EN 12967-2. c)
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



EN 12967-3:2007 (E) 5 Viewpoints. It also provides guidance on how one individual enterprise may specify additional services, needed to support local specific requirements in terms of common business logic to be implemented.
Computational Viewpoint is specified in Part 3 of the standard; document EN 12967-3.



EN 12967-3:2007 (E) 6 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 the document “Health Informatics – Service Architecture - Part 1: Enterprise Viewpoint”. The computational model is specified without any –explicit or implicit- assumption about 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 are satisfied by the computational model implemented by the middleware. Preserving 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 extendable 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 paragraph 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 of services 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. EHR or patient administration. 2 Normative references Not applicable. 3 Terms and definitions For the purposes of this document, 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



EN 12967-3:2007 (E) 7 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 Symbols and abbreviations HISA Health Informatics - Service Architecture ODP Open Distributed Processing UML Unified Modelling Language EHR Electronic Health Record 5 Methodological Principles (informative) 5.1 General 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.2
Clusters of Objects The Enterprise Viewpoint has identified the scope, need for, 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 summarizing the related user activities and requirements through natural language. During this process the main Healthcare Common clusters of objects have been identified:  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.  Activity management objects These objects handle the information necessary for supporting the users’ activities identified in the “Activity Management workflow” of the Enterprise Viewpoint.  Clinical information objects These objects handle the information necessary for supporting the users’ activities identified in the “Clinical Information workflow” of the Enterprise Viewpoint.  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.



EN 12967-3:2007 (E) 8
 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.  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.  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, arising 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 interfaces or access mechanisms it provides to access the information handled by the system, which in the following shall also be referred to as methods or services. The individual methods provided by the computational objects shall be described illustrating how they allow actual access to the information handled by the system (identifying the interfaces, the constraints, as well as which information of the underlying overall information model is accessed), and eventual parallel actions to be taken.
5.3 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:  form of interface that an object can have;
 way the interfaces can be bound and the forms of interaction which can take place at them;  actions an object can perform, in particular the creation of new objects and interfaces. 5.4 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 of objects 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:



EN 12967-3:2007 (E) 9  basic computational objects deriving directly from the corresponding information object (i.e. one computational object per information object);  complex, 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 provide 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. patient management, activity management, etc.). NOTE 1 The term patient is used in this specification as a synonym of Subject of Care as has been done in the other parts of this standard The basic computational objects, corresponding one to one 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.



EN 12967-3:2007 (E) 10 The following figure shows an example:
Figure 2 — Example of "basic services" NOTE 2 The actual basic services that shall be available for HISA objects are detailed in section 6.2 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.
EXAMPLE: Patient/person area, including registering a person, patient administration, merging patient identifiers, period of care, etc. Activity management and life cycle, including requests, planning, booking, etc. Clinical and EHR, including terminologies, classifications, problem-orientation, etc. Resource management, including standard usages, etc.
Figure 3 — Example of "complex service" NOTE 3 The actual complex services that shall be available for HISA objects are detailed in the clauses of section 6.4 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 in and out of the system, setting system variables, etc.), transaction management, etc. These services will be provided by at least a further computational object equipped with appropriate methods, namely the general purpose interface.



EN 12967-3:2007 (E) 11 5.5 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 the focus is 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. An example of the two types of computational objects is displayed in the following Figure 4, and shall be referred to in the following as “basic” and “complex” computational objects according to the terminology adopted in clause 5.4. The methods that these will expose shall also be referred to in the following as “basic” and “complex”.
Figure 4 — 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 enterprise viewpoint and specified 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.



EN 12967-3:2007 (E) 12 Generic HISA classStructured attributes set0.*State changesExtended attributesBusiness Rules<
classified throughClass-specific attributes setCommon attributes setVersion attributes setSystem attributes set10.*0.*0.*1HISA Concept classClassification criteria1111110.*0.10.*0.10.1next version >classified attribute > Figure 5 — Generic structure of the computational objects The following methods shall be available in the basic computational objects. Each method has a scope and a description. Many of the method specification tables also include an example. 6.2.2 “Add” basic methods 6.2.2.1 General The “add” methods shall allow the client of the computational object to create instances of HISA objects. 6.2.2.2 List of methods 6.2.2.2.1 Method add Method add Scope Shall be used to create a new instance of a HISA object. Description The instances that shall be added are the individual HISA classes specified in chapter 7 of part 2 of this standard. The instance, its class-specific attribute set, and the common system and version properties shall be created through this method. Example The addition of a new Person in the system shall be accomplished by calling the add method of the Person computational object [Person.add]. The caller will pass as input several fields belonging to the class-specific attribute set (id, name, birthTime, deceasedTime, gender, address, etc.). The method shall also allow the user to pass information to override any default value for its common system and version-related attributes.



EN 12967-3:2007 (E) 13 6.2.2.2.2 Method Xadd Method Xadd Scope Shall be used to create a new instance of extended data and associate it to a HISA object. Description The specification of the extended data object that will be created is found in clause 6.3.6 of part 2 of this standard. The instances to which the extended data shall be attached are the individual HISA classes specified in chapter 7 of part 2 of this standard. The extended data properties and the common system and version properties it comprises shall be created through this method. Example The calling of this method [Person.Xadd] shall allow doing things such as adding, among others: the digital photograph of the Person to the instance of the Person object, the scanned image of the signed consent to receive treatment, etc. The semantics of the extended datum shall be classified in its property type, the media type in the property mediaType, the language in the language property, etc. 6.2.2.2.3 Method Cadd Method Cadd Scope Shall be used to create a new instance of classification criteria data and associate it to a HISA object. Description The specification of the classification criteria data that will be created is found in clause 6.3.9 of part 2 of this standard. The instances to which the classification data shall be attached are the individual HISA classes specified in chapter 7 of part 2 of this standard. The classification data properties and its common system and version properties shall be created through this method. Example Persons might be classified in healthcare organisations according to their education. The calling of this method [Person.Cadd] allows classifying the person according to the criteria in use e.g. in the national, regional, or local classification in use. 6.2.2.2.4 Method BRadd Method BRadd Scope Shall be used to create a new instance of a business rule concerning the HISA object to which it is associated. Description The specification of the business rule data that will be created is found in clause 6.3.8 of part 2 of this standard. The instances to which the business rule data shall be attached are the individual HISA classes specified in chapter 7 of part 2 of this standard. The business rule properties and its common system and version properties shall be created through this method. Example As happens in Denmark, experimental drugs are used in some treatments and need spe
...

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

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

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

---------------------- 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
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.