EN 12967-3:2007

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

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

Computational Viewpoint is specified in Part 3 of the standard; document EN 12967-3.

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

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.

 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:

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.

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.

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.

The system shall generate appropriate values for the common system and version attributes of the HISA class when the instance is created, for those parameters that are not passed by the caller. In particular:  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 this case the service shall verify the uniqueness of the identifier.  system shall take care of managing state changes by adding dynamically and automatically the values that record the changes occurred in the specific properties of the class or when extended data, classification data and business rules are attached to it, thus keeping track of the life cycle of the instance during time. The State changes class is specified in clause 6.3.8 of part 2 of this standard.

Example The updating of a Person in the system shall be accomplished by calling the update method of the Person computational object [Person.update]. The method shall also allow the user to pass information to override any default value for its common system and version-related attributes. 6.2.3.2.2 Method Xupdate Method Xupdate Scope Shall be used to update an existing instance of the extended data associated to a HISA object. Description The extended data instances that shall be updated are the ones already attached to the individual HISA classes specified in chapter 7 of part 2 of this standard. The extended data object and its common system and version properties shall be created through this method. Example The updating of the properties of the extended data of a Person in the system shall be accomplished by calling the update method of the Person computational object [Person.Xupdate]. The method shall also allow the user to pass information to override any default value for the extended data’s common system and version-related attributes. 6.2.3.2.3 Method Cupdate Method Cupdate Scope Shall be used to update an existing instance of classification data associated to a HISA object. Description The classification data instances that shall be updated are the ones already attached to the individual HISA classes specified in chapter 7 of part 2 of this standard. The classification object and its common system and version properties shall be created through this method. Example The updating of the classification criteria of a Person in the system shall be accomplished by calling the update method of the Person computational object [Person.Cupdate]. The method shall also allow the user to pass information to override any default value for its common system and version-related attributes.

The system shall generate and/or update the appropriate values for the common system and version attributes of the HISA class when it is updated. In particular:  operation shall require as input the common attributes necessary for the update information.  instance identifier shall never be updated.  update shall not occur if the timestamp of the instance to be updated differs from the timestamp received as input, since this indicates that the value in the HISA system has changed since the client originally read the instance from the system. The change occurred while the caller was performing the operation and the update would cause inconsistency in the common information heritage. NOTE Such an approach in managing concurrent access to data is generally called “optimistic-locking.”  system shall take care of managing state changes when the update operation is invoked by adding dynamically and automatically the values that record the changes occurred in the specific properties of the class or when extended data, classification data and business rules attached to it are updated, thus keeping track of the life cycle of the instance during time. The State changes class is specified in clause 6.3.7 of part 2 of this standard.  operations shall return to the client at least the set of common attributes related to the HISA object updated with the update operation. Such information shall include a value indicating successful execution of the operation or an error indicating the reason for failure.  operations shall implement all integrity checks with respect to the information passed by the client of operation, aborting it if the operation would lead to an inconsistent informational state. 6.2.4
“Delete” basic methods 6.2.4.1 General The “delete” methods shall allow the client of the operation to delete logically instances of HISA objects.

6.2.4.2 List of methods 6.2.4.2.1 Method delete Method delete Scope Shall be used to delete an existing instance of a HISA object. Description The instances that shall be deleted are the individual HISA classes specified in chapter 7 of part 2 of this standard. The object, its class-specific attribute set, and its common system and version properties shall be deleted through this method. 6.2.4.2.2 Method Xdelete Method Xdelete Scope Shall be used to delete logically an existing instance of the extended data associated to a HISA object. Description The extended data instances that are deleted shall be the ones already attached to the individual HISA classes specified in chapter 7 of part 2 of this standard. The extended data object and its common system and version properties shall be deleted logically through this method. 6.2.4.2.3 Method Cdelete Method Cdelete Scope Shall be used to delete logically an existing instance of classification data associated to a HISA object. Description The classification data instances that shall be deleted are the ones already attached to the individual HISA classes specified in chapter 7 of part 2 of this standard. The object and its common system and version attributes shall be logically deleted through this method. 6.2.4.2.4 Method BRdelete Method BRdelete Scope Shall be used to delete logically an existing instance of a business rule associated to the HISA object. Description The specification of the business rule that shall be deleted is found in clause 6.3.8 of part 2 of this standard. The instances to which the business rule data is 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 deleted through this method. 6.2.4.2.5 Method pack Method pack Scope Shall be used to physically delete the logically deleted instances. Description The logical deletion allows keeping in the system instances that clients have requested the deletion. This functionality shall be available mainly for system administration purposes, to physically remove elements that have been logically deleted and can safely be removed from the system. 6.2.4.3 Behavioural specifications The system shall generate and/or update the appropriate values for the common system and version attributes of the HISA class when it is deleted. In particular:  Operation shall require as input the common attributes necessary for the delete information.
 Logical deletion shall cause the “isDeleted” attribute of the object to be set to “True”, without removing physically the instance from the common information heritage of the enterprise.  Delete operation shall not occur if the timestamp of the instance to be logically deleted differs from the timestamp received as input, since this indicates that the value has changed in the HISA system since the

“Detail” basic methods 6.2.5.1 General The “detail” operations shall allow the client of the operation to fetch one fully detailed instance of a HISA object. 6.2.5.2 List of methods 6.2.5.2.1 Method detail Method detail Scope Shall be used to get the information regarding an existing instance of the HISA object. Description The instances that shall be retrieved are the individual HISA classes specified in chapter 7 of part 2 of this standard. The object, its class-specific attribute set and its common system and version attributes shall be retrieved through this method. Example The retrieval of the full detail of a Person’s properties in the system for displaying it through user functionality shall be accomplished by calling this method of the Person computational object [Person.detail], thus accessing the Person’s id, his/her birthDate, etc. 6.2.5.2.2 Method Xdetail Method Xdetail Scope Shall be used to retrieve an existing instance of the extended data associated to a HISA object. Description The extended data instances that shall be retrieved from the system are described in clause 6.3.6 of part 2 of this standard and are attached to the individual HISA classes specified in chapter 7 of part 2 of this standard. The extended data object and its common system and version attributes shall be extracted and presented to the caller through this method. Example The retrieval of the extended data properties of a Person in the system, such as the Person’s picture or the signed consensus for receiving treatment are example of extended data that may need to be visualised by user functionality by calling the Xdetail method of the Person computational object [Person.Xdetail].

6.2.5.2.3 Method Cdetail Method Cdetail Scope Shall be used to retrieve an existing instance of the classification data associated to a HISA object. Description The classification data instances that shall be retrieved form the system are described in clause 6.3.9 of part 2 of this standard and attached to the individual HISA classes specified in chapter 7 of part 2 of this standard. The classification data object’s common system and version attributes shall be extracted and presented to the caller through this method. Example The retrieval of the classification data properties of a Person, such as the level of education coded according to national, regional, or local criteria shall be accomplished by calling this method of the Person computational object [Person.Cdetail]. 6.2.5.2.4 Method BRdetail Method BRdetail Scope Shall be used to retrieve an existing instance of a business rule associated to the HISA object. Description The specification of the business rule that shall be retrieved is found in clause 6.3.8 of part 2 of this standard. The instances to which the business rule data is 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 extracted through this method and presented to the caller. 6.2.5.2.5 Method Sdetail Method Sdetail Scope Shall be used to retrieve an existing instance of the state change data associated to a HISA object. Description The state change data instances that shall be retrieved form the system are described in clause 6.3.7 of part 2 of this standard and attached to the individual HISA classes specified in chapter 7 of part 2 of this standard. The state change object’s properties and its common system and version properties shall be extracted through this method. Example During the life cycle of an activity, form the moment it is defined and requested till the moment it is completed, it can undergo quite a few changes in terms of status and properties. This method [Activity.Sdetail] allows retrieving the full deta
...