EN 12967-2:2007

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

Mappings between HISA and GPIC.63 Bibliography.65

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.

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

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

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.

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.

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, as exemplified in Figure 3.

Figure 3 — Knowledge base implemented through the Descriptive Information Objects In addition to the properties and to the classification provided by the related “descriptive” class, each class and each attribute of each class may need to be classified according to different, multiple, multi-language classifications for different (clinical, epidemiological, statistic, etc.) purposes. To support this requirement, HISA model provides the package of “Concept Information Objects”, capable of organising multiple classifications, terminologies and other concepts.
Each individual information element (entire instance of one class or individual attribute of one class) can be related to the Concept class to allow specifying as many classifications as necessary. Also in this case the principle of implementing a knowledge base is implemented by the HISA model that provides:  “Descriptive” information objects, allowing to specify the concepts according to which each class and each attribute of the class may be classified;  “Operational” information objects (natively present in each HISA class, as described in the “Generic HISA class”), allowing to classify each individual instance and each individual attribute according to multiple concepts.
Figure 4 — The further classification criteria for each HISA class

Semantics String
Series of characters, as defined in ISO/IEC 11404:1996 Boolean
Boolean value, as defined in ISO/IEC 11404:1996 Integer
Integer, 32 bit two’s complement Double
Double precision floating point (64-bit IEEE 754) Octet
8-bit code, as defined in ISO/IEC 11404:1996
On the basis of the primitive data types, the following HISA data types are also used in this specification to further define the meaning of data values that can be assigned to a data element. Table 2 HISA data type Primitive data type
Semantics Byte Octet Synonym of Octet ObjectIdentifier String Unchangeable string allowing the permanent and non ambiguous identification of one instance of one information object. The syntax and the structure of the string shall be defined locally by the individual implementations, according to criteria capable of ensuring the uniqueness of the value also across different models and distributed, multiple physical environments.
Identifier String Short, human-readable string allowing the non ambiguous identification of one instance of one information object. InternalTimestamp Array of Byte Representation of date and time at least up to the level of the millisecond. DateTime String Representation of date and time at least up to the level of the second. Ordinal Integer A number which defines a position in an ordered series (CEN/TS 14796:2004). Unit String Unit of measure, expressed according to codes defined in the “Unified Code for Units of Measures” (http://aurora.rg.iupui.edu/UCUM).
URI String Telecommunication address as specified by Internet standard RFC 1738 (http://www.isi.edu/in-notes/rfc1738.txt) as relates to one of the following schema codes: “http” (RFC 2068), “ftp” (RFC 1738), “file” (RFC 1738). SET
Value that contains multiple values of the data type specified as its elements.
5.6 Organisation of the document The specification of the overall information model is structured through the following sections: Formalisation of the general criteria and of the properties common to all classes identified in the model.

NOTE Due to the integration of the whole model, in each schema there are some classes that are related to objects relevant for other business processes and therefore described in the relevant sections; these classes are highlighted with the brown colour. Specification of the identified objects, with the definition of the related properties and of the relations among them. Informative Annex A summarises essential guidelines on the UML notation adopted for the specification of the schemas. 6 General characteristics of the model 6.1 Common structure of each information object: the GenericHisaClass Each object of the information model shall conform to a common structure (i.e. the “GenericHISAClass”) comprising:  set of attributes (named “specific attributes”), describing the semantic aspects specific to the class itself
(e.g. Person’s name, gender, etc.); NOTE 1 These attributes are the ones that are illustrated in the property list of the classes in the diagrams in the following section 7.  set of attributes (named “system attributes”), common to all objects, supporting general requirements in terms of accountability, auditing, legal/clinical requirements, etc. (e.g. the date time of registration/updating of the instance);  indefinite number of multi-media properties (named “extended attributes”), which may be added dynamically at run-time and that allow to record further information on the objects. These properties shall comprise, among other, the following attributes:  actual datum (i.e. the value, for example a Person’s photo, the colour of his/her eyes, etc.);  characteristics describing the properties of the actual datum (e.g. type [=IMAGE], size, etc. –these shall be described, where possible through the CEN data types);  "system attributes”, common to all instances of the object.  indefinite number of textual properties (named “business rules”), which may be added dynamically at run-time and that allow to record specific (e.g. legal, clinical, Organisational, operational) rules and criteria that may by applicable when operating with the instance in certain contexts.
These properties shall comprise, among other, the following attributes:  actual text of the rule;  scope of applicability of the rule;  "system attributes”, common to all instances of the object; NOTE 2 The Formalization of the semantics and of the syntax of such rules is under the responsibility of the specific implementation scenario and is outside the scope of this standard, which only prescribes the capability of each object to allow the recording and management of such type of information.

These properties shall comprise, among other, of the following attributes:  value of the “system attributes” prior to the change;
 identification of the system attributes that have been changed;  new values assigned to the system attributes that have been changed;
 date, time of the change;  identification of the agent (i.e. individual or system process) that has effected the change.  set of attributes (named “versioning attributes”), common to all objects, supporting the definition and management of multiple versions of the instance of the object, each of them characterised by an identification label and the time frame (i.e. starting date and ending date) of validity; NOTE 3 At a certain moment either one or no instance shall be valid, therefore time frames of validity shall not overlap.  relationship linking one version of the object with the instance representing the previous version;  indefinite number of relationships
(named “classification criteria”), which may be added dynamically at run-time and that allow to classify the entire class and/or individual attributes according to multiple classification criteria, defined in the “Concept” class of the model. 6.2 UML Diagram
Figure 5 — The generic HISA class All classes in the above diagram are specified in the following sections except the HISA Concept class, which is specified in clause 7.1.3.2.

6.3.1 General Class identifier:
GenericHISAClass Description This meta-class represents the HISA information objects belonging to the information model. Associated classes Type of Association Multiplicity StructuredAttributes Composition 1 ExtendedAttributes Composition 0.* BusinessRules Composition 0.* StateChanges Composition 0.* ClassificationCriteria Relating the instance with multiple classifications Composition 0.* Versioning Relating the instance with its previous version, if existing Association 0.1 Attributes Type Description none
6.3.2 Class: Set of structured attributes
Class identifier:
StructuredAttributes Description Set of all structured attributes of the HISA information object consisting of
the composition of a) the specific attributes peculiar of the HISA information object and b) the set of common attributes that shall be present in all classes. Associated classes Type of Association Multiplicity CommonAttributes Composition 1 ClassSpecificAttributes Composition 1 Attributes Type Description none
6.3.3 Class: Set of class specific attributes
Class identifier:
ClassSpecificAttributes Description Set of attributes specific of the individual HISA information object Associated classes Type of Association Multiplicity none
Attributes Type Description Dependent on the specific object
detailed for each class in the relevant specifications
6.3.4 Class: Set of common attributes
Class identifier:
CommonAttributes Description Set of all attributes common to all HISA information objects Associated classes Type of Association Multiplicity SystemAttributes Composition 1 VersionAttributes Composition 1 Attributes Type Description none

6.3.5 Class: Set of system attributes Class identifier:
SystemAttributes Description attributes, common to all objects, supporting general requirements in terms of accountability, auditing, etc. of the instance Associated classes Type of Association Multiplicity none
Attributes Type Description instanceID ObjectIdentifier Permanent, unchangeable, unique identifier of the instance of the class.
displayName String Short, human-readable description of the object, that may be abbreviated for display purposes. userCode Identifier
Short, human-readable code of the object, allowing to uniquely identifying the instance of the class. timestamp InternalTimestamp Internal Timestamp of the last update of the instance,
creationTime DateTime Identifies time and date of the original creation of the instance creationAgent ObjectIdentifier Identifier (i.e. instanceID) of the individual that has initially created the instance. creationUnit ObjectIdentifier Identifier (i.e. instanceID) of the unit of the organisation that has initially created the instance updateTime DateTime Identifies time and date of the last update of the instance. updateAgent ObjectIdentifier Identifier (i.e. instanceID) of the individual that has executed the last modification in the instance. updateUnit ObjectIdentifier Identifier (i.e. instanceID) of the unit of the organisation that has executed the last modification in the instance. authorization String Specific constraints with respect to the authorization rights on reading, updating or deleting the specific instance. isDeleted Boolean If True, specifies that the instance has been logically deleted. isFrozen Boolean If True, specifies that the instance cannot be modified.
6.3.6 Class: Set of version attributes Class identifier:
VersionAttributes Description attributes, common to all objects, supporting the definition and management of multiple versions of the instance of the object Associated classes Type of Association Multiplicity none
Attributes Type Description sequence Ordinal Progressive sequence number of the version
startValidityDate DateTime Starting date of validity of the version of the instance endValidityDate DateTime Ending date of validity of the version of the instance

Class identifier:
ExtendedAttributes Description Formatted or unformatted texts, multimedia data or structured information as defined by a different standard, which may be attached/removed dynamically at run-time to the instance to record further information in addition to those already specified by the StructuredAttributes Related terms See also “Encapsulated data”, as defined in CEN/TS 14796:2004. Notes Attributes extend those defined in CEN/TS 14796:2004. Associated classes Type of Association Multiplicity CommonAttributes Composition 1 Attributes Type Description sequence Ordinal Progressive sequence number of the property
type String Specification of the semantics of the property NOTE The classification criteria to be adopted shall be defined and published locally in the individual implementations.
mediaType String Identifies –according to the MIME datatypes and notations-
the encoding of the data and a method to interpret or render the data charset String Where applicable, specifies –according to the IANA character set- the character set and character encoding used.
language String Name of language used, if data is formatted text (according to ISO 639:1988 “Codes for the representation of names of languages”) compression String Id data are compressed, indicates the compression algorithm that was used reference URI URI reference to a location external to the system if the data are not natively stored in the middleware
integrityCheck Array of Byte A short binary value representing a cryptographically strong checksum over the binary data integrityCheckAlgorithm String Specifies the algorithm used to compute the integrity check value data Array of Byte Actual value of the datum alternateString String Textual title of the multi-media property, to be displayed in lieu of multimedia display

6.3.8 Class: State changes Class identifier:
StateChanges Description properties that may be added dynamically at run-time to document the updates made to the “SpecificAttributes” of the class
Associated classes Type of Association Multiplicity none
Attributes Type Description sequence Ordinal Progressive sequence position of the property
dateOfChange DateTime Identifies the time in which the change was made authorOfChange identifier Identifier (i.e. instanceID) of the individual that has performed the change oldInstance Set Identifiers and values of all attributes of the instance, prior to the change newValues Set Identifiers of the attributes that have been changed and new values assigned to each of them
6.3.9 Class: Business rules Class identifier:
BusinessRule Description properties that may be added dynamically at run-time to the record to specify rules and criteria (e.g. legal, clinical, Organisational, operational) that may be applicable when operating with the instance in certain contexts Associated classes Typ
...