SIST EN 12967-2:2008
Health informatics - Service architecture - Part 2: Information viewpoint
Health informatics - Service architecture - Part 2: Information viewpoint
This document represents the second 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.
Medizinische Informatik - Servicearchitektur - Teil 2 : Informationssicht
Informatique de santé - Service architecture - Partie 2 : Point de vue de l'information
La présente norme spécifie les caractéristiques fondamentales du modèle d'information qu'une couche architecturale spécifique (c'est-à-dire la couche interstitielle) du système d'informations doit mettre en place pour assurer le stockage cohérent et intégré des données d'entreprise communes et supporter les processus métier fondamentaux de l'organisation de santé, tel que le défini dans la Partie 1 de la présente norme « Informatique de la santé — Architecture des services — Partie 1 : Point de vue Entreprise ».
Le modèle d'information est spécifié sans émettre d'hypothèse (explicite ou implicite) sur les technologies physiques, les outils ou les solutions à adopter dans les 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.
Elle n'a pas pour objet d'être une représentation fixe et exhaustive de toutes les données possibles susceptibles d'être nécessaires aux exigences d'une entreprise de santé. Elle spécifie simplement un ensemble de caractéristiques (en termes d'objets d'informations organisationnelles et individuelles) identifiées comme étant essentielles pour toutes les organisations de santé et que le modèle d'information mis en place par la couche interstitielle doit satisfaire.
Tout en préservant la cohérence avec les dispositions de la présente norme, les mises en place physiques doivent permettre une extension vers un modèle d'information standard afin de répondre à des exigences supplémentaires et locales. Les extensions doivent inclure la définition d'attributs supplémentaires dans les objets du modèle standard et la mise en place d'objets totalement nouveaux.
De même, la spécification de la présente norme doit être extensible dans le temps en fonction de l’évolution des initiatives de normalisation applicables.
Zdravstvena informatika - Arhitektura storitve - 2. del: Informacijski vidik
General Information
Relations
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Health informatics - Service architecture - Part 2: Information viewpointZdravstvena informatika - Arhitektura storitve - 2. del: Informacijski vidikInformatique de santé - Service architecture - Partie 2 : Point de vue de l'informationMedizinische Informatik - Servicearchitektur - Teil 2 : InformationssichtTa slovenski standard je istoveten z:EN 12967-2:2007SIST EN 12967-2:2008en35.240.80ICS:SIST ENV 12967-1:20031DGRPHãþDSLOVENSKI
STANDARDSIST EN 12967-2:200801-maj-2008
EUROPEAN STANDARDNORME EUROPÉENNEEUROPÄISCHE NORMEN 12967-2October 2007ICS 35.240.80Supersedes ENV 12967-1:1998
English VersionHealth informatics - Service architecture - Part 2: InformationviewpointInformatique de la santé - Architecture de service - Partie 2: Point de vue informationnelMedizinische Informatik - Servicearchitektur - Teil 2 :InformationssichtThis 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-2:2007: E
EN 12967-2:2007 (E) 2 Contents Page Foreword.4 Introduction.5 1 Scope.6 2 Normative references.6 3 Terms and definitions.7 4 Symbols and abbreviations.7 5 Methodological principles.7 5.1 Language and notation adopted for the specification of the model (informative).7 5.2 UML Class Diagram notation guidelines and profile (informative).8 5.3 Clusters of objects in the information model.9 5.4 Operational and descriptive information: classifications, knowledge and its instantiation.11 5.5 DataTypes.13 5.6 Organisation of the document.13 6 General characteristics of the model.14 6.1 Common structure of each information object: the GenericHisaClass.14 6.2 UML Diagram.15 6.3 Specification of Generic HISA Class.16 6.3.1 General.16 6.3.2 Class: Set of structured attributes.16 6.3.3 Class: Set of class specific attributes.16 6.3.4 Class: Set of common attributes.16 6.3.5 Class: Set of system attributes.17 6.3.6 Class: Set of version attributes.17 6.3.7 Class: Extended attributes.18 6.3.8 Class: State changes.19 6.3.9 Class: Business rules.19 6.3.10 Class: Classification criteria.20 7 The Reference Information models.20 7.1 Classification Objects.20 7.1.1 Scope.20 7.1.2 UML information model.21 7.1.3 Specification of the individual classes.21 7.2 Subject of Care Objects.25 7.2.1 Scope.25 7.2.2 UML information model.25 7.2.3 Specification of the individual classes.26 7.3 Activity Management Objects.31 7.3.1 Scope.31 7.3.2 UML information model.31 7.3.3 Specification of the individual classes.32 7.4 Clinical and Health Information Objects.38 7.4.1 Scope.38 7.4.2 UML information model.39 7.4.3 Specification of the individual classes.40 7.5 Resource Management Objects.44 7.5.1 Scope.44 7.5.2 UML information model.45 7.5.3 Specification of the individual classes.46 7.6 User and Authorisation Objects.51
EN 12967-2:2007 (E) 3 7.6.1 Scope.51 7.6.2 UML information model.52 7.6.3 Specification of the individual classes.53 7.7 Messaging Objects.58 7.7.1 Scope.58 7.7.2 UML information model.59 7.7.3 Specification of the individual classes.59 Annex A (informative)
Mappings between HISA and GPIC.63 Bibliography.65
EN 12967-2:2007 (E) 4 Foreword This document (EN 12967-2: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-3, 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-2:2007 (E) 5 Introduction This document represents the second 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 The overall architecture specified by this standard is formalized according to the ISO/IEC 10746 (all parts) criteria and is therefore structured through the three viewpoints: 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.
The Enterprise Viewpoint is specified in Part 1 of this multi-part standard; document EN 12967-1. 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 Formalized 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 this document EN 12967-2. 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 Part 3 of this multi-part standard; document EN 12967-3.
EN 12967-2:2007 (E) 6 1 Scope This standard specifies the fundamental characteristics of the information model to be implemented by a specific architectural layer (i.e. the middleware) of the information system to provide a comprehensive and integrated storage of the common enterprise data and to support the fundamental business processes of the healthcare Organisation, as defined in part 1 of this standard “Health Informatics – Service Architecture - Part 1: Enterprise viewpoint”. The information 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. This specification does not aim at representing a fixed, complete, specification of all possible data 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 information objects- identified as fundamental and common to all healthcare Organisations, and that shall be satisfied by the information model implemented by the middleware. Preserving the consistency with the provisions of this standard, physical implementations shall allow extensions to the standard information model in order to support additional and local requirements. Extensions shall include both the definition of additional attributes 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
part 1 of this standard EN 12967-1, clause 7, “Methodology for extensions”. 2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. Not Applicable
EN 12967-2:2007 (E) 7
3 Terms and definitions For the purposes of this document, the following terms and definitions apply. 3.1 Information object information held by the system about entities of the real world, including the ODP system itself, is represented in an information specification in terms of information objects, their relationships and behaviour 3.2
package cluster of information objects 3.3 middleware middleware is the enabling technology of enterprise application integration (EAI). It describes a piece of software that connects two or more software applications so that they can exchange data 3.4 enterprise application integration (EAI) uses of software and computer systems architectural principles to integrate a set of enterprise computer applications 4 Symbols and abbreviations ODP Open Distributed Processing HISA Health Informatics Service Architecture UML Unified Modelling Language GPIC General Purpose Information Components 5 Methodological principles
5.1 Language and notation adopted for the specification of the model (informative) Objective of information viewpoint specification is the description of the information relevant for the enterprise to be handled by the middleware. It shall consist of a formal information model detailing the semantic and syntactic aspects of all data to be managed.
The specification is based on an object model, derived from the enterprise viewpoint by properly structuring and aggregating the information that has been identified as relevant in the specification of the business processes, tasks and activities. While the general approach of the ODP standard is used also for the Information Viewpoint part of this standard, the modelling language to be used is UML, which was not available at the time of the first edition of the ODP standard. The information viewpoint is concerned with information modelling (i.e. the kinds of information handled by the system). It focuses on the semantics of information and information processing in the system. The individual components of a distributed system must share a common understanding of the information they communicate when they interact, or the system will not behave as expected. Some of these items of information are handled, in one way or another, by many of the objects in the system. To ensure that the
EN 12967-2:2007 (E) 8 interpretation of these items is consistent, the information language defines concepts for the specification of the meaning of information stored within, and manipulated by, an ODP system, independently of the way the information processing functions themselves are to be implemented.
Thus, information held by the ODP system about entities in the real world, including the ODP system itself, is represented in an information specification in terms of information objects, and their associations and behaviour. Atomic information objects represent basic information elements. More complex information is represented as composite information objects each expressing associations over a set of constituent information objects. Some elements visible from the enterprise viewpoint will be visible from the information viewpoint and vice versa. For example, an activity seen from the enterprise viewpoint may appear in the information viewpoint as the specification of some processing which causes a state transition of an information entity. Different notations for information specifications model the properties of information in different ways. Emphasis may be placed on classification and reclassification of information types, or on the states and behaviour of information objects. In some specification languages, atomic information objects are represented as values. The approach to be taken will depend on the modelling technique and notation being used. Assessment of conformance to the information specification of a system involves relating the requirements expressed in the specification to sets of observations of the behaviour of the system at conformance points identified in the engineering and technology specification, and assessing the degree of consistency between the requirements and the observations. 5.2 UML Class Diagram notation guidelines and profile (informative) For each cluster of objects identified in the EV, the information objects will be illustrated according to the following rationale: Information objects (i.e. classes) grouped in the packages will be not be coloured. Classes not expressly grouped in the package will also be represented if there are associations from classes belonging to the package to these classes. The classes, however, shall be coloured in yellow. Names of classes will be meaningful and start with a capital letter (e.g. Person). If the name is composed of more than one word the blank spaces between the words present in the diagrams shall be instead omitted in the tables describing the classes (e.g. “Period of care” in the diagram shall become “PeriodOfCare” in the tables, “Subject of care” in the diagram shall become “SubjectOfCare”). Blank spaces are left in the diagrams for readability reasons. Associations will be labelled when the label adds value to the diagram. Associations may be labelled through a property, or through a verb phrase; in this latter case an arrow will be added to the association label to avoid ambiguity. Label shall always be in lower case and if it is a verb phrase (with arrow) it will have one blank space in between words. Navigability is not relevant when using UML for an information specification and will not be represented. In general, for readability reasons, the classes shall contain only the name of the class. Properties shall be described in the tables. Should properties be displayed in the diagrams, the following holds: Notation for visibility of properties shall not be used, as it is not pertinent for the conceptual models used in the information viewpoint. Although visibility symbols could be used to indicate access control this is not done as all healthcare-related information should be accessed through careful authorization. Data types of the properties shall be displayed in the class in the diagram.
EN 12967-2:2007 (E) 9 For some classes, associations to other classes could be modelled (in the UML diagrams) as attributes to the class. This reflects that the association has value rather than reference semantics, in addition to the resulting simplification of the model. In other cases the same method might be used in the UML diagrams even though the association has reference semantics. This is done just to simplify the models. In the related class descriptions these instances of simplified modelling are described as associations rather than attributes. Properties (attributes) of classes shall start with a lower case letter (e.g. name). If the property is composed of more than one word the blank spaces in between words shall be omitted (e.g. familyName, birthDate). Current ISO and low-level data types will be preferably used. These will allow mapping to CEN or future ISO when possible. Many-to-many binary associations named “related to” may be implemented as a set of specific associations or association classes of specific multiplicities. Cardinalities of properties are used in case of associations, especially to distinguish between optional and mandatory properties. Cardinality ‘*’ is never used, as the reader might be confused as to whether a 0.* or 1.* was intended. When the composition symbol is used, the non-displayed cardinality will always be ‘1’. 5.3 Clusters of objects in the information model The information specification is built considering the elements of the enterprise viewpoint specification. ODP does not impose any methodology for the definition and use of the viewpoints. Thus, the enterprise specification has been used here for building the UML specification. This approach greatly facilitates the definition of the correspondences between the related entities that appear in the different viewpoints, allowing also the treatment the consistency among the viewpoints. In particular, this information specification incorporates the information handled by the system as described in clause 6.2 and subsequent paragraphs of the enterprise viewpoint. The following diagram shows, at a first level of abstraction the main objects of the model and their relations according to the concepts identified in the Enterprise Viewpoint, with respect to the fundamental workflows and groups of users activities to be supported by the middleware.
EN 12967-2:2007 (E) 10
Figure 2 — High level model of the information objects By proceeding according to the same methodology adopted for the specification of the Enterprise Viewpoint, this high-level model can refined by identifying seven clusters of objects, each of them responsible for organising and storing the information necessary for supporting the users’ activities identified in the related areas of the Enterprise viewpoint: 1. Classification objects These objects shall organize and store the information necessary for supporting the users’ activities related to the management of classifications, coding criteria and dictionaries, as identified by the Enterprise view. 2. Subject of care objects These objects shall organize and store the information necessary for supporting the users’ activities identified in the “Subject of Care workflow” of the Enterprise view. 3. Activity management objects These objects shall organize and store the information necessary for supporting the users’ activities identified in the “Activity Management workflow” of the Enterprise view. 4. Clinical and health objects These objects shall organize and store the information necessary for supporting the users’ activities identified in the “Clinical Information workflow” of the Enterprise view.
EN 12967-2:2007 (E) 11
5. Resources objects These objects shall organize and store the information necessary for supporting the users’ activities related to the management of resources, as identified in the Enterprise view. 6. Users and authorisation objects These objects shall organize and store the information necessary for supporting the users’ activities related to the management of users and authorisations, as identified in the Enterprise view. 7. Messaging objects These objects shall organize and store the information necessary for supporting the structuring of data and the communications with other systems through messaging mechanisms, as identified in the Enterprise view. These clusters of objects are specified in the following sections by means of UML models. 5.4 Operational and descriptive information: classifications, knowledge and its instantiation From the textual descriptions in the enterprise viewpoint the middleware shall be able to manage not only the daily operational information directly related to the various business processes, but also a knowledge base, allowing managing the descriptive concepts, vocabulary items, and rules required to instantiate particular properties of the operational information. Such "concept descriptive information" is the basic knowledge base required for the actual instantiation of the operational information in the healthcare enterprise. HISA Information Objects in each package shall thus be classified as: “Operational”, usually representing the actual (clinical, Organisational, etc.) objects that are continuously generated during (and for) the daily activities. These include the personal and healthcare treatment information on patients, the individual resources used for carrying out the actual activities, etc.
The operational information objects model the entities involved in the daily activities of the healthcare enterprise in the treatment of subjects of care and in the functioning of the enterprise itself. “Descriptive”, usually Organisation-related, specifying the criteria according to which the Organisation works and is organized. It includes general classifications of clinical concepts, rules according to which the activities are performed, and more (e.g. the types of activities which are carried out in the radiology department, the diagnostic classification in use in the clinical setting, etc.). The descriptive information objects model the entities required for the overall knowledge base that is required by the healthcare enterprises to carry out daily activities related to the treatment of subjects of care and in the functioning of the enterprise itself. For each “operational” information object, therefore, the model foresees one “descriptive” information object, containing the main classification data, the properties, the rules and the default values that are necessary for the management of the live data instantiated in the “operational” object,
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.