EN 12967-1:2007

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Health informatics - Service architecture - Part 1: Enterprise viewpointZdravstvena informatika - Arhitektura storitve - 1. del: Vidik podjetjaInformatique de la santé - Architecture de service - Partie 1 : Point de vue EntrepriseMedizinische Informatik - Servicearchitektur - Teil 1: UnternehmenssichtTa slovenski standard je istoveten z:EN 12967-1:2007SIST EN 12967-1:2008en35.240.80ICS:SIST ENV 12967-1:20031DGRPHãþDSLOVENSKI
STANDARDSIST EN 12967-1:200801-maj-2008

EUROPEAN STANDARDNORME EUROPÉENNEEUROPÄISCHE NORMEN 12967-1October 2007ICS 35.240.80Supersedes ENV 12967-1:1998
English VersionHealth informatics - Service architecture - Part 1: EnterpriseviewpointInformatique de la santé - Architecture de service - Partie 1: Point de vue EntrepriseMedizinische Informatik - Servicearchitektur - Teil 1:UnternehmenssichtThis 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-1:2007: E

This integration requirement is not only related to the need for improving clinical treatments to the subject of care but is also demanded by the urgent necessity of all countries to control and optimise the current level of expenditure for health, whilst ensuring the necessary qualitative level of services to all subjects of care. The large number of databases and applications, mutually isolated and incompatible which are, already, available on the market and operational in healthcare organisations to support specific needs of users, cannot be underestimated. Even within the same centre, healthcare information systems are frequently fragmented across a number of applications, data and functionalities, isolated and scarcely consistent with each other. Under the present circumstances, the main need for care delivery organisations is to integrate and to make available the existing information assets, to make possible the integration and interoperability of existing applications, thereby protecting investments. During integration activities, continuity of service needs to be achieved whilst gradual migration of existing proprietary, monolithic systems towards the new concepts of openness and modularity occurs. The cost-effectiveness of the solutions, especially when projected on the scale of the whole healthcare organisation, represents another crucial aspect to be evaluated carefully.
The goal can be achieved through a unified, open architecture based on a middleware independent from specific applications and capable of integrating common data and business logic and of making them available to diverse, multi-vendor applications through many types of deployment. According to the integration objectives at organisational level, all aspects (i.e. clinical, organisational and managerial) of the healthcare structure must be supported by the architecture, which must be able therefore to comprise all relevant information and all business workflows, structuring them according to criteria and paradigms independent from specific sectorial aspects, temporary requirements or technological solutions.
Standards and technological solutions already exist and will continue to be defined for supporting specific requirements, both in terms of in situ user operations and with respect to the movement of information. The architecture must be able to accommodate such requirements by allowing the specific models to be integrated with the complete information assets of the healthcare organisation and the communication messages to be “services” extracting or importing data from/to the common information as shown in Figure 1. On the basis of these considerations, the purpose of this standard is twofold:
 identify a methodology to describe healthcare information systems through a language, notation and paradigms suitable to facilitate the planning, design and comparison of systems;  identify the fundamental architectural aspects enabling the openness, integration and interoperability of healthcare information systems. The architecture is therefore intended as a basis both for working with existing systems as well as for the planning and construction of new systems.

Figure 1 — Complementarity and positioning of the architecture with other standards and models It is pointed out that this standard does not aim at defining a unique model for clinical, organisational, managerial or administrative activities, but rather defines a set of workflows, information and services common to all healthcare information systems, relevant for any healthcare sector and usable by any application also for facilitating the mutual interworking. Similarly, the standard does not aim to represent a final, complete set of specifications. On the contrary, it formalises only fundamental aspects, identified as common in all European countries and considered to be - today - essential in any advanced healthcare information system. Specifications are formalised, avoiding any dependency on specific technological products and/or solutions.
The standard, therefore, is an open framework that - according to the specification methodology and preserving the compatibility with previous versions - can be extended during time according to the evolution of the healthcare organisation both in the individual - national and local - contexts and through international standardisation initiatives.
A European pre-standard, ENV 12967-1, was developed according to such rationale during 1993 to 1997 and has been the basis for several implementations of middleware products and implemented integrations in healthcare regions. In 2000 the CEN/TC 251 Short Strategic Study on Health Information Infrastructure also identified a number of other new architectures and health infrastructure initiatives as well as the requirements and possibilities for alignment with the large body of information model standards developed by CEN for various communication purposes. Furthermore, European standardization initiatives have delivered a number of object oriented domain models and message descriptions that include an architecture for the Electronic Health Record (EN 13606). Cooperation between CEN and HL7 has also started, that, on the basis of the CEN modelling principles and HL7 Reference Information Model, has led to the definition of a set of “General Purpose Information Components”, usable for developing messages across information systems. This standard evolves and refines the ENV 12967-1 pre-standard taking into account the outcomes from its practical utilisations during the past years, as well as the other above-mentioned initiatives occurred in CEN. With such a view, the following qualifying aspects can be highlighted:  architecture is described according to the methodology of ISO/IEC 10746 (all parts) Information technology - Open Distributed Processing – Reference model, to provide a formal, comprehensive and non ambiguous specification suitable to serve as term of reference in the planning, design and implementation of healthcare information systems.
 scope of the architecture comprises the support to the activities of the healthcare organisation as a whole, from the clinical, organisational and managerial point of view. It therefore does not detail specificities of

Figure 2 The architectural principles are formalised according to the ISO/IEC 10746 (all parts) criteria and are therefore structured through the following 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 functionalities 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.
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. 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 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 standard is also independent from, and does not imply either explicitly or implicitly, any specific technological solution or product for its deployment. Accordingly, the formalisation of the architecture according to two lower levels of the ODP reference model, the Engineering and Technology viewpoints is outside the scope of this standard. The language and notations used here for specifying the architecture are based on UML (Unified Modelling Language) complemented by case studies and other paradigms widely utilised by other standards in health informatics. The level of the specification is complete and non-ambiguous enough to allow its implementation into the specific physical and technological scenarios adopted by the various healthcare organisations and

1 For more introductory material on RM-ODP and many guideline documents see WWW.RM-OPD.NET

group of people and facilities with an arrangement of responsibilities, authorities and relationships
[EN ISO 9000] NOTE 1 The arrangement is generally orderly. NOTE 2 An organisation can be public or private. NOTE 3 This standard deals with healthcare organisations, ranging from hospital co-operations within e.g. counties, over individual hospitals, to individual clinics etc. encompassing only specific subsets of normal hospital services. 3.2.2 organisational structure
arrangement of responsibilities, authorities and relationships between people NOTE 1 The arrangement is generally orderly. NOTE 2 A formal expression of the organisational structure is often provided.
NOTE 3 The scope of an organisational structure can include relevant interfaces to external organisations. 3.3 Community concepts 3.3.1 community configuration of objects formed to meet an objective

3.3.2 federation community of domains 3.3.3 objective practical advantage or intended effect, expressed as preferences about future states NOTE 1 Some objectives are ongoing, some are achieved once met. NOTE 2 In the text of ITU-T Rec. X.903 | ISO/IEC 10746-3 [3-5] the terms, purpose and objective, are synonymous. The enterprise language systematically uses the term, objective, and emphasises the need of expressing objective in measurable terms. 3.3.4 community object composite enterprise object that represents a community. Components of a community object are objects of the community represented 3.4 Behaviour concepts 3.4.1 actor (with respect to an action) enterprise object that participates in the action NOTE It may be of interest to specify which actor initiate that action. 3.4.2 artefact (with respect to an action) enterprise object that is referenced in the action NOTE An enterprise object that is an artefact in one action can be an actor in another action. 3.4.3 resource enterprise object which is essential to some behaviour and which requires allocation or may become unavailable NOTE 1 Allocation of a resource may constrain other behaviours for which that resource is essential. NOTE 2 A consumable resource may become unavailable after some amount of use or after some amount of time (in case a duration or expiry has been specified for the resource). 3.4.4 interface role role of a community identifying behaviour which takes place with the participation of objects that are not members of that community 3.4.5 process set of interrelated or interacting activities which transforms inputs into outputs
[EN ISO 9000] NOTE 1 Inputs to a process are generally outputs of other processes. NOTE 2 Processes in an organisation are generally planned and carried out under controlled conditions to add value.

NOTE 5 The health care process is provided in the health care enterprising process. NOTE 6 When a demand for care is accepted by a health care provider, a care mandate is established stating the mission and authorisation for the health care provider to provide health care services to the subject of care. This care mandate is the basis for decisions about which health care activities are to be performed, what the objective is for the health care process and receptacle for objective evidence provided by the clinical process. Through verification the quality of each health care activity or series of health care activities can be assessed giving prerequisites for possible rework, repair, scrap or concession [EN ISO 9000:2005 concepts 3.6.7, 3.6.9, 3.6.10, and 3.6.11]. The mandate finally reaches a point where the total requirement for the health care process has been fulfilled and the care mandate can be terminated.
NOTE 7 In the clinical process the health may improve, a risk for deterioration of the health may be reduced, or knowledge about the health may be improved, something which increases the possibilities to have a positive influence on the health. NOTE 8 Processes can be influenced by events. An event does not occur in the own process but is the conception by the own process of an activity executed in another process. An event will probably lead to a change in the decided process strategy or to a result of the process other than the intended one.
NOTE 9 ISO 10746-1 defines process as: a collection of steps taking place in a prescribed manner and leading to an objective. 3.4.6 step abstraction of an action, used in a process, that may leave unspecified objects that participate in that action 3.4.7 service
number of processes, involving the organisation in the provision of specific objectives NOTE 1 This definition regards the services provided in the organisation, with or without an electronic information system, whereas the definition of ‘Information service’ regards the information (input/output) provided by the System. NOTE 2 The healthcare services are the services taking place within a healthcare organisation 3.4.8 workflow number of services, involving the organisation in the provision of more complex objectives, according to agreed procedural rules
NOTE In healthcare, workflow will often take place based on three fundamental processes, the clinical process, the informative process and the management process, where information, tasks and activities are shifted between these.
3.5 Policy concepts 3.5.1 policy
set of rules related to a particular purpose. A rule can be expressed as an obligation, an authorisation, permission or a prohibition NOTE 1 Not every policy is a constraint. Some policies represent an empowerment. NOTE 2 This definition refines by adding authorisation.

enterprise object modelling a natural person or any other entity considered to have some of the rights, powers and duties of a natural person NOTE 1 Examples of parties include enterprise objects representing natural persons, legal entities, governments and their parts, and other associations or groups of natural persons. NOTE 2 The following concepts are used to identify actions which involve the accountability of a party. 3.6.2 commitment
action resulting in an obligation by one or more of the participants in the act to comply with a rule or perform a contract NOTE The enterprise object(s) participating in an action of commitment may be parties or agents acting on behalf of a party or parties. In the case of an action of commitment by an agent, the principal becomes obligated. 3.6.3 declaration action that establishes a state of affairs in the environment of the object making the declaration NOTE The essence of a declaration is that, by virtue of the act of declaration itself and the authority of the object or its principal; it causes a state of affairs to come into existence outside the object making the declaration. 3.6.4 delegation action that assigns authority, responsibility or a function to another object NOTE A delegation, once made, may later be withdrawn. 3.6.5 evaluation action that assesses the value of something NOTE 1 For example, the act by which an ODP system assigns a relative status to some thing, according to estimation by the system. NOTE 2 Value can be considered in terms of usefulness, importance, preference, acceptability etc; the evaluated target may be, for example, a credit rating, a system state, a potential behaviour, etc. 3.6.6 prescription act that establishes a rule

party that agrees to that contract 4 Symbols and abbreviations ODP Open Distributed Processing HISA Health Information Service Architecture 5 Methodology for the specification of the architecture NOTE 1 This clause describes the methodology adopted by the standard for the specification of the architecture. The same methodology shall be used by healthcare enterprises and industrial vendors for describing the characteristics of HISA-conformant systems. The scope of the methodology is the specification of the contents of the documents that will be delivered for describing the architecture. The formalisation of the process according to which a system is identified, planned, designed and implemented is outside the scope of this standard; the ODP approach described in this clause may nevertheless provide guidance for the definition of such process. NOTE 2 Clause 5.1 provides an overview on the viewpoint based ODP methodology. Clause 5.2 specifies how this is used in HISA (for the enterprise, information and computation viewpoints themselves) and how the characteristics of HISA-conformant systems should be described.
5.1 The viewpoints for the specification of the architecture The methodology defined by ISO/IEC 10746 (all parts) Information Technology - Open Distributed Processing shall be used for the specification of a healthcare service architecture that shall be structured through five viewpoints, individually specifying a particular set of concerns of the whole system:  Enterprise viewpoint, which is concerned with the purpose, scope and policies governing the activities of the specified system within the organisation of which it is a part;  Information viewpoint, which is concerned with the kinds of information handled by the system and constraints on the use and interpretation of that information;  Computational viewpoint, which is concerned with the functional decomposition of the system into a set of objects that interact through formalised interfaces;

For each viewpoint there is an associated viewpoint language that can be used to express a specification of the system from that viewpoint. The object modelling concepts give a common basis for the viewpoint languages and make it possible to identify relationships between the different viewpoint specifications and to assert correspondences between the representations of the system in different viewpoints. NOTE 1 This HISA standard formalises the enterprise, information and computational viewpoints as iIlustrated in Figure 3. Systems conformant to HISA shall be described by means of the same three viewpoints, complemented with the specification of the infrastructural and technological characteristics. Such aspects should be described according to the criteria defined by the ODP engineering and technology viewpoints.
NOTE 2 An actual implementation of the HISA services could be described as a Service Oriented Architecture (SOA), e.g. in the form of web services.
Figure 3 — Three (of five) ODP viewpoints detailed in HISA 5.2 The HISA specification procedure 5.2.1 The strategic paradigm
The specification of the architecture shall start with a concise, managerial-oriented document (the “Strategic Paradigm”) that identifies (at a high level of abstraction) the overall requirements and strategic objectives of the envisaged system. It describes, in natural language:  rationale and the scope of the IT system with respect to the overall enterprise;  fundamental organisational processes (as defined under terms and definitions) that can be identified in the enterprise and that are relevant for the envisaged system;

1) Identification of the business processes with relevant scope and objectives in regard to the overall mission of the healthcare enterprise; 2) For each process, identification of the tasks carried out by the involved users, with the mutual dependencies and interactions. When identifying such tasks all aspects and requirements of the enterprise (i.e. including the clinical, organisational and managerial characteristics) shall be taken into account; 3) For each task, identification of the information that is used and of the elementary activities that are performed for processing it; The specification of the information relevant for the task shall include: a) non-ambiguous description of the semantics of the information, including the domain of validity of the possible values and the specification of the coding criteria and classifications (if any) to be adopted; b) identification of the modalities according to which the data are used (i.e. whether they are generated or manipulated or simply acquired by the task); c) qualitative indication of the level of relevance/criticality of the data with respect to the overall business process and
d) volume of instances envisageable in the whole information assets of the enterprise. The specification of each elementary activity shall include: e) non-ambiguous description of the scope and objectives of the activity with respect to the business process; f) qualitative indication of the frequency of execution of the activity and on the rapidity of completion required by the organisational context;

5.2.3 Specification of the Information viewpoint Objective of this specification is the description of the information relevant for the enterprise to be integrated in the middleware. It shall consist of a formal information model detailing the semantic and syntactic aspects of all data to be managed. The information model delivered shall be at a level allowing implementers to derive an efficient design of the system in the specific technological environment that will be selected for the physical implementation. The specification shall be expressed as an object model. Objects shall be derived from the Enterprise viewpoint by properly structuring and aggregating the information that have been identified as relevant in the specification of the overall business processes, tasks and activities. The completeness of the information model with respect to the information requirements set out by the Enterprise viewpoint shall be verified and documented (e.g. by means of a vocabulary with the correspondence between the concepts identified in the two views). In order to inc
...