EN ISO 12967-2:2011

SLOVENSKI STANDARD
01-julij-2011
1DGRPHãþD
SIST EN 12967-2:2008
Zdravstvena informatika - Arhitektura storitve - 2. del: Informacijski vidik (ISO
12967-2:2009)
Health informatics - Service architecture - Part 2: Information viewpoint (ISO 12967-
2:2009)
Medizinische Informatik - Servicearchitektur - Teil 2: Informationssicht (ISO 12967-
2:2009)
Informatique de santé - Architecture de service - Partie 2: Point de vue d'information
(ISO 12967-2:2009)
Ta slovenski standard je istoveten z: EN ISO 12967-2:2011
ICS:
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN ISO 12967-2
NORME EUROPÉENNE
EUROPÄISCHE NORM
March 2011
ICS 35.240.80 Supersedes EN 12967-2:2007
English Version
Health informatics - Service architecture - Part 2: Information
viewpoint (ISO 12967-2:2009)
Informatique de santé - Architecture de service - Partie 2: Medizinische Informatik - Servicearchitektur - Teil 2:
Point de vue d'information (ISO 12967-2:2009) Informationssicht (ISO 12967-2:2009)
This European Standard was approved by CEN on 10 March 2011.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European
Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national
standards may be obtained on application to the CEN-CENELEC 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 translation
under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management Centre has the same
status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, 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 STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2011 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 12967-2:2011: E
worldwide for CEN national Members.

Contents Page
Foreword .3

Foreword
The text of ISO 12967-2:2009 has been prepared by Technical Committee ISO/TC 215 “Health informatics” of
the International Organization for Standardization (ISO) and has been taken over as EN ISO 12967-2:2011 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 September 2011, and conflicting national standards shall be
withdrawn at the latest by September 2011.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN 12967-2:2007.
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, Croatia, 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 the United Kingdom.
Endorsement notice
The text of ISO 12967-2:2009 has been approved by CEN as a EN ISO 12967-2:2011 without any
modification.
INTERNATIONAL ISO
STANDARD 12967-2
First edition
2009-08-15
Health informatics — Service
architecture —
Part 2:
Information viewpoint
Informatique de santé — Architecture de service —
Partie 2: Point de vue d'information

Reference number
ISO 12967-2:2009(E)
©
ISO 2009
ISO 12967-2:2009(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2009
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2009 – All rights reserved

ISO 12967-2:2009(E)
Contents Page
Foreword .v
Introduction.vi
1 Scope.1
2 Normative references.1
3 Terms and definitions .2
4 Symbols and abbreviations.2
5 Methodological principles .2
5.1 Language and notation adopted for the specification of the model (informative).2
5.2 UML Class Diagram notation guidelines and profile (informative) .3
5.3 Clusters of objects in the information model.4
5.4 Operational and descriptive information: classifications, knowledge and its instantiation .5
5.5 DataTypes.7
5.6 Organization of the document .8
6 General characteristics of the model .9
6.1 Common structure of each information object: the GenericHisaClass.9
6.2 UML diagram.10
6.3 Specification of Generic HISA Class.11
6.3.1 General.11
6.3.2 Class: Set of structured attributes .11
6.3.3 Class: Set of class specific attributes.11
6.3.4 Class: Set of common attributes .11
6.3.5 Class: Set of system attributes.12
6.3.6 Class: Set of version attributes .12
6.3.7 Class: Extended attributes.13
6.3.8 Class: State changes .13
6.3.9 Class: Business rules .14
6.3.10 Class: Classification criteria.14
7 The reference information models .15
7.1 Classification objects.15
7.1.1 Scope.15
7.1.2 UML information model .15
7.1.3 Specification of the individual classes .16
7.2 Subject of care objects .19
7.2.1 Scope.19
7.2.2 UML information model .19
7.2.3 Specification of the individual classes .20
7.3 Activity management objects.25
7.3.1 Scope.25
7.3.2 UML information model .25
7.3.3 Specification of the individual classes .26
7.4 Clinical and health information objects .33
7.4.1 Scope.33
7.4.2 UML information model .33
7.4.3 Specification of the individual classes .34
7.5 Resource management objects .39
7.5.1 Scope.39
7.5.2 UML information model .39
7.5.3 Specification of the individual classes .40
ISO 12967-2:2009(E)
7.6 User and authorization objects .45
7.6.1 Scope.45
7.6.2 UML information model.46
7.6.3 Specification of the individual classes.47
7.7 Messaging Objects.51
7.7.1 Scope.51
7.7.2 UML information model.52
7.7.3 Specification of the individual classes.52
Annex A (informative) Mappings between HISA and GPIC.56
Bibliography .58

iv © ISO 2009 – All rights reserved

ISO 12967-2:2009(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 12967-2 was prepared by Technical Committee ISO/TC 215, Health informatics, based on the European
Standard EN 12967-2:2007 with minor editorial amendments.
ISO 12967 consists of the following parts, under the general title Health informatics — Service architecture:
⎯ Part 1: Enterprise viewpoint
⎯ Part 2: Information viewpoint
⎯ Part 3: Computational viewpoint
ISO 12967-2:2009(E)
Introduction
This is the second part of ISO 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 organizations 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.
Applications
Scope of the
standard
Middleware of objects
integrating common data and common business logic

Figure 1 — Scope
The overall architecture is formalized according to ISO/IEC 10746 (all parts) and is therefore structured
through the following three viewpoints.
a) Enterprise viewpoint: specifies a set of fundamental common requirements at enterprise level with
respect to the organizational 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 organization where this model is applicable)
can specify and document additional specific business requirements, with a view to achieving a complete
specification, adequate for the characteristics of that enterprise.
Enterprise viewpoint is specified in ISO 12967-1.
b) Information viewpoint: 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 ISO 12967-1. It also provides guidance on how one individual enterprise can 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 this part of ISO 12967.
c) Computational viewpoint: specifies the scope and characteristics of the services that must be provided by
the middleware for allowing access to the common data as well as the execution of the business logic
supporting the enterprise processes identified in the information viewpoint and in ISO 12967-1. It also
provides guidance on how one individual enterprise can specify additional services needed to support
local specific requirements in terms of common business logic to be implemented.
Computational viewpoint is specified in ISO 12967-3.
vi © ISO 2009 – All rights reserved

INTERNATIONAL STANDARD ISO 12967-2:2009(E)

Health informatics — Service architecture —
Part 2:
Information viewpoint
1 Scope
This part of ISO 12967 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 organization, as defined in ISO 12967-1.
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 can be
necessary for any requirement of any healthcare enterprise. It specifies only a set of characteristics, in terms
of overall organization and individual information objects, identified as fundamental and common to all
healthcare organizations, and that is satisfied by the information model implemented by the middleware.
Preserving consistency with the provisions of this part of ISO 12967, physical implementations allow
extensions to the standard information model in order to support additional and local requirements. Extensions
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 is extensible over time according to the evolution of the applicable
standardization initiatives.
The specification of extensions is carried out according to the methodology defined in ISO 12967-1:2009,
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.
ISO/IEC 11404:2007, Information technology — General-Purpose Datatypes (GPD)
ISO 12967-1:2009, Health informatics — Service architecture — Part 1: Enterprise viewpoint
ISO 12967-3:2009, Health informatics — Service architecture — Part 3: Computational viewpoint

ISO 12967-2:2009(E)
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
enabling technology of enterprise application integration (EAI) describing a piece of software that connects
two or more software applications so that they can exchange data
3.4
enterprise application integration
EAI
use 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 Component
5 Methodological principles
5.1 Language and notation adopted for the specification of the model (informative)
The objective of the information viewpoint specification is to describe the information relevant for the
enterprise to be handled by the middleware. It consists 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 also used for ISO 12967-1, 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
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.
2 © ISO 2009 – All rights reserved

ISO 12967-2:2009(E)
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 enterprise viewpoint, 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. These classes, however, will be coloured in yellow.
⎯ The 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 will be
instead omitted in the tables describing the classes (e.g. “Period of care” in the diagram will become
“PeriodOfCare” in the tables, “Subject of care” in the diagram will 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 the latter case, an arrow
will be added to the association label to avoid ambiguity.
⎯ Labels are always in lower case and, if a label 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 should only contain the name of the class. Properties
should be described in the tables; however, if properties are displayed in the diagrams, the following
holds.
⎯ Notation for visibility of properties is not 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 should be displayed in the class in the diagram.
⎯ 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.
ISO 12967-2:2009(E)
⎯ Properties (attributes) of classes 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 are omitted (e.g. familyName, birthDate).
⎯ Current ISO and low-level data types will preferably be used. These will allow mapping to CEN or ISO (in
the future) 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 by 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, also
allowing the treatment of the consistency among the viewpoints.
In particular, this information specification incorporates the information handled by the system as described in
6.2 to 6.4 of ISO 12967-1:2009.
Figure 2 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.
By proceeding according to the same methodology adopted for the specification of the enterprise viewpoint,
this high-level model can be refined by identifying seven clusters of objects, each of them responsible for
organizing 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 in ISO 12967-1.
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 ISO 12967-1.
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 ISO 12967-1.
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 ISO 12967-1.
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 ISO 12967-1.
6) Users and authorization objects
These objects shall organize and store the information necessary for supporting the users’ activities related to
the management of users and authorizations, as identified in ISO 12967-1.
4 © ISO 2009 – All rights reserved

is derived from >
Is subject to >
Is requesting/performing >
< groups
Is generated by /
is relevant for >
belong to >
ISO 12967-2:2009(E)
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 ISO 12967-1.
These clusters of objects are specified in Clause 7 by means of UML models.
< is responsible for
Healthcare provider Individual User
Clinical Information
Resource
Authorization Profile
< is used by
Clinical Guidelines
Health Issue
< is related to
Activity
Protocol
executed regarding >
Plan
< has < is instantiated for
Contact Subject of Care
< has
Period of Care
< is determined by
Figure 2 — High-level model of the information objects

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, organizational, 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.
ISO 12967-2:2009(E)
⎯ “Descriptive”, usually organization-related, specifying the criteria according to which the organization
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.
Descriptive Operational
information objects information objects
Class
Class
instantiate
“Type of XXXXX” “XXXXX”
Main classification,
properties, rules,
Actual live data
default values, etc.
Type of Activity instantiate
Activity
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, the
HISA model provides the package of “Concept Information Objects”, capable of organizing multiple
classifications, terminologies and other concepts. See Figure 4.
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 the following.
⎯ “Descriptive” information objects, allowing the specification of 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 the classification of each individual instance and each individual attribute according
to multiple concepts.
6 © ISO 2009 – All rights reserved

ISO 12967-2:2009(E)
Descriptive
classifications,
information objects
properties, rules, etc.
0.* 0.*
Concept
HISA class
0.*
May be classified
through
0.*
HISA class
attribute
0.1
0.1
Actual
0.*
classification
0.*
HISA class
instance Operational
information objects
Actual live data
Figure 4 — Further classification criteria for each HISA class

5.5 DataTypes
The primitive data types given in Table 1 are used in this specification.
Table 1
Data type Semantics
String Series of characters, as defined in ISO/IEC 11404:2007
Boolean Boolean value, as defined in ISO/IEC 11404:2007
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:2007

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.
ISO 12967-2:2009(E)
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 bytes 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 Organization of the document
The specification of the overall information model is structured through the following sections:
⎯ Formalization of the general criteria and of the properties common to all classes identified in the model.
⎯ One schema for each business process identified in the enterprise view, showing the sole classes
relevant for that business process.
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
a brown colour.
⎯ Specification of the identified objects, with the definition of the related properties and of the relations
among them.
⎯ Informative Annex A summarizes essential guidelines on the UML notation adopted for the specification
of the schemas.
8 © ISO 2009 – All rights reserved

ISO 12967-2:2009(E)
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 the following:
⎯ 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 Clause 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 others, 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, organizational, 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 part of ISO 12967, which only prescribes the capability of each
object to allow the recording and management of such type of information.
⎯ indefinite number of properties (named “state changes”), which shall be added dynamically at run-time
automatically by the class itself, and that shall record the changes that occurred in the “specific attributes”
of the class, in order to keep track of the life cycle of the instance during the time; these properties shall
comprise, among others, 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;
ISO 12967-2:2009(E)
⎯ set of attributes (named “versioning attributes”), common to all objects, supporting the definition and
management of multiple
...