SIST-TP CEN/TR 15253:2006

SLOVENSKI STANDARD
SIST-TP CEN/TR 15253:2006
01-april-2006
Zdravstvena informatika – Zahteve za kakovost storitev pri izmenjavi zdravstvenih
informacij
Health informatics - Quality of service requirements for health information interchange
Medizinische Informatik - Anforderungen an die Service-Qualität für den Austausch von
medizinischen Informationen
Informatique de santé - Exigences de qualité de service pour les échanges d'information
de santé
Ta slovenski standard je istoveten z: CEN/TR 15253:2005
ICS:
03.120.99 Drugi standardi v zvezi s Other standards related to
kakovostjo quality
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
SIST-TP CEN/TR 15253:2006 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST-TP CEN/TR 15253:2006

---------------------- Page: 2 ----------------------

SIST-TP CEN/TR 15253:2006
TECHNICAL REPORT
CEN/TR 15253
RAPPORT TECHNIQUE
TECHNISCHER BERICHT
December 2005
ICS 35.240.80

English Version
Health informatics - Quality of service requirements for health
information interchange
Informatique de santé - Exigences de qualité de service Medizinische Informatik - Anforderungen an die Service-
pour les échanges d'information de santé Qualität für den Austausch von medizinischen
Informationen
This Technical Report was approved by CEN on 13 November 2005. It has been drawn up by the Technical Committee CEN/TC 251.
CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, 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: rue de Stassart, 36  B-1050 Brussels
© 2005 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 15253:2005: E
worldwide for CEN national Members.

---------------------- Page: 3 ----------------------

SIST-TP CEN/TR 15253:2006
CEN/TR 15253:2005 (E)
Contents page
Foreword .3
Introduction.4
0 Scope .5
1 Structure of this document .5
2 References.6
3 Abbreviation .7
4 Terms and definitions.8
5 Quality of service concepts.9
6 Current relevant work in healthcare informatics standardisation.13
7 Typical healthcare QoS scenarios.14
8 Healthcare QoS categories.16
9 Development of ETG 021 Method .23
10 Summary and conclusions.25

Annex A Application of QoS concepts.29

2

---------------------- Page: 4 ----------------------

SIST-TP CEN/TR 15253:2006
CEN/TR 15253:2005 (E)
Foreword
This Technical Report (CEN/TR 15253:2005) has been prepared by Technical Committee CEN /TC 251,
"Health informatics" the secretariat of which is held by NEN.
This document has been developed by the Expert Group for Healthcare within the European Workshop for
Open Systems (EWOS/EG MED). The editor of the document is Dr A J Kerr of Level-7 Ltd, a member of
EWOS/EG MED. Thanks are due to all who have contributed ideas, text and scenarios to assist in the
production of this report. Special appreciation is expressed to Jeremy Tucker, who has provided liaison with
the ISO/IEC JTC/1 QoS Group and provided much of the text for Clause 9.

3

---------------------- Page: 5 ----------------------

SIST-TP CEN/TR 15253:2006
CEN/TR 15253:2005 (E)
Introduction
Background
This report considers user requirements for Quality of Service (QoS) specifically in the healthcare Information
Technology (IT) environment.
QoS is defined in [4] as: ”A set of qualities related to the collective behaviour of one or more objects.” Thus the
definition is very broad, even when restricted to the healthcare IT environment.
CR 12161 (EWOS/ETG 021): ”A Method for Defining Profiles for Health Care” [7] deals with the general
categorisation of user requirements for healthcare information interchange. It assesses the suitability of
profiles of standards from the domains of Open Systems Interconnection / Open Systems Environment
(OSI/OSE) to satisfy those user requirements.
The method defined in CR 12161 was subsequently applied (by EWOS project team PT N024) to the specific
domain of medical image interchange, and the findings were recorded in CR 12069 (EWOS/ETG
045): ”Profiles for Medical Image Interchange” [8]. In performing this work, a number of requirements were
identified which could not adequately be mapped to the services provided by standardised OSI profiles. Some
of these requirements could be considered as QoS issues.
With this in mind, the Healthcare Expert Group of the European Workshop for Open Systems (EWOS/EG
MED) initiated a work item in May 1995 to identify QoS requirements for healthcare information interchange
which need to be supported by standardised communications services. This report is the result of that activity.
At the same time, international IT standards have been under development (by ISO/IEC JTC1/SC21 and ITU-
T SG7) to define a QoS Framework [2] of terminology and concepts, in order to assist those wishing to specify
or procure systems in which QoS is important, and to publish a Guide to QoS Methods and Mechanisms [3],
which is intended to be a source-book of references and widely-applicable mechanisms that can be used by
systems designers and implementors. The scope of the activity is all forms of interaction between elements of
distributed systems.
The QoS work in ISO has been applied to the development of time-critical communications and to enhanced
communications transport service and protocol (ECTS & P) for multicast. It is now being applied it to Open
Distributed Processing (ODP) and to the specifications produced by the Object Management Group (OMG).
This Technical Report attempts to apply the concepts in the developing international standards for QoS to the
healthcare IT domain in order to address the issues identified in the above-mentioned CEN Reports.
Purpose
The purpose of this document is specifically to identify QoS requirements for healthcare information
interchange, and to investigate possible extensions to the Method for Defining Profiles for Health Care defined
in CR 12161 to point to possible ways to satisfy user QoS requirements.
This report is intended to provide assistance to those specifying and procuring systems in the healthcare
environment. It is also potentially a contribution to the ISO/ITU-T activity described above.
4

---------------------- Page: 6 ----------------------

SIST-TP CEN/TR 15253:2006
CEN/TR 15253:2005 (E)
0 Scope
This Technical Report is concerned with QoS as it applies to interactions between components of distributed
healthcare IT systems. The scope is not limited to network infrastructures; it includes the QoS requirements
of information storage and processing IT systems. The related areas of security and financial cost
considerations are not within the primary scope of the document, although they are considered briefly.
Of course, an informatics system with a high QoS does not guarantee a high standard of healthcare in terms
of clinical outcomes or patient care. The quality of healthcare delivered to patients (the ultimate ”users”)
depends upon a number of external factors such as the experience and competence of the healthcare
professional(s) or institution(s) involved. Potential QoS characteristics for the total healthcare delivery process
such as mortality rate, clinical outcome, etc. are therefore not within the scope of this report.
The report contains no provisions to avoid the incorporation of bad or dangerous practice into healthcare IT
systems. It is possible to circumvent good clinical practice with technical solutions which may cause bad
practice. This vital issue is not covered by this report. To take an example scenario:
A patient consults a doctor, who takes a blood sample and arranges to see the patient again in two weeks.
a) A "good" practice doctor sees and reviews the blood test result as soon as it comes back from the
laboratory and then files it if no action is required.
b) A "bad" practice doctor sees and reviews the blood test results only when he reviews the patient’s case
on the patient’s next visit. This case is not defensible if the patient has a preventable adverse event and
takes legal action (source: MPS Casebook Summer 1997).
The healthcare information system put into the medical practice in electronic form could build-in either practice
(a) or practice (b). This report does not consider the clinical quality assurance mechanism for the IT system.
1 Structure of this document
Introduction - defines the scope and background of the work on QoS for Healthcare Information Interchange,
and gives a list of references and acronyms.
Clause 5 - Quality of Service Concepts - summarises QoS concepts from existing work.
Clause 6 - Current Relevant Work in Healthcare Informatics Standardisation - provides a brief survey of
known work related to QoS requirements and mechanisms in the international healthcare community.
Clause 7 - Typical Healthcare QoS Scenarios- defines a number of User Scenarios demonstrating situations
in which QoS is of importance.
Clause 8 - Healthcare QoS Categories- draws together QoS requirements in the Healthcare sector, derived
from the examples in Clause 7, and from elsewhere. It gives some guidance on what solutions may be
appropriate.
Clause 9 - Development of ETG 021 Method - considers how the ”Method for Defining Profiles for Health
Care” defined in [7], and used in [8] and [9], might be extended to cover QoS requirements.
Clause 10 - Summary and Conclusions - summarises the main points of the document and provides
recommendations on how to proceed.
Annex A - Application of QoS Concepts - contains examples of applications of the concepts in Clause 5,
including aspects such as QoS in OSI and QoS in time-critical communications, in order to provide
background information for the discussion of Attributes in Clause 9.
5

---------------------- Page: 7 ----------------------

SIST-TP CEN/TR 15253:2006
CEN/TR 15253:2005 (E)
2 References
2.1 Primary references
[1] ISO/IEC 7498-1:1994, Information technology - Open Systems Interconnection - Basic Reference Model:
the Basic Model
[2] ISO/IEC 13236:1998, Information technology – Quality of service – Framework [ITU-T Recommendation
X.641]
[3] ISO/IEC TR 13243:1999, Information technology – Quality of service - Guide to methods and
mechanisms [ITU-T Recommendation X.642]
[4] ISO/IEC 10746-2:1996, Information technology - Open Distributed Processing - Reference Model:
Foundations [ITU-T Recommendation X.902]
[5] RFC 1821 Integration of Real-time Services in an IP-ATM Network Architecture, Borden et al (August
1995)
[6] CEN/TC 251 Directory of the European Standardisation Requirements for Healthcare Informatics and
Telematics - Programme for the Development of Standards. Version 2.1 (1996-08-15)
[7] EWOS/ETG 021 (CR 12161:1995), A method for defining profiles for healthcare
[8] EWOS/ETG 045 (CR 12069:1995), Profiles for medical image interchange
[9] EWOS/ETG 068 Multimedia Medical Data Interchange
[10] IEEE Std 1073-1996, IEEE Standard for Medical Device Communications - Overview and Framework
[11] Metz CE 1986, ROC methodology in medical imaging. Investigative Radiology 21:720-733
[12] ISO/IEC 11172, Information technology - Coding of moving pictures and associated audio for digital
storage media at up to about 1,5 Mbit/s (MPEG-1)
[13] ISO/IEC DIS 13818, Information technology – Generic coding of moving pictures and associated audio
information (MPEG-2)
[14] IEEE Std 1073.3.1-1994, IEEE Standard for Medical Device Communications - Transport Profile -
Connection Mode (ANSI)
2.2 Supplementary references
The following references may also be of interest to the reader:
ISO 13485 Medical devices - Quality management systems – Requirements for regulatory purposes
ISO 13488 Quality systems – Medical devices – Particular requirements for the application of ISO 9002
Papers on QoS by Klara Nahrstedt, which can be found at the University of Illinois Department of Computer
Science WWW site:
http://cs.uiuc.edu/CS_INFO_SERVER/DEPT_INFO/CS_FACULTY/FAC_HTMLS/nahrstedt.html
6

---------------------- Page: 8 ----------------------

SIST-TP CEN/TR 15253:2006
CEN/TR 15253:2005 (E)
3 Abbreviation
BCC Bedside Communication Controller
CL Connectionless
CLNS Connectionless Network Service
CO Connection Oriented
CT Computed Tomography
DCC Device Communication Controller
DIS Draft International Standard
DTR Draft Technical Report
ECG Electrocardiogram
ECTS&P Enhanced communications transport service and protocol
EG MED EWOS Expert Group on Healthcare
EHR Electronic healthcare record
ETG EWOS Technical Guide
EWOS European Workshop for Open Systems
GOFF Goodness of Fit Factor
IEC International Electrotechnical Commission
ISO International Organization for Standardization
ITU-T International Telecommunications Union - Telecommunication Standardisation
Sector
JTC1 Joint Technical Committee (of ISO and IEC) number 1
MDIB Medical Data Information Base
MIB Medical Information Bus
MRI Magnetic Resonance Imaging
ODP Open Distributed Processing
OMA Object Management Architecture
OMG Object Management Group
OSE Open Systems Environment
OSI Open Systems Interconnection
7

---------------------- Page: 9 ----------------------

SIST-TP CEN/TR 15253:2006
CEN/TR 15253:2005 (E)
PT Project Team
QoS Quality of Service
ROC Receiver Operating Characteristic
RSVP Resource Reservation Protocol
SC21 Subcommittee 21 (of ISO/IEC JTC1)
SG7 Study Group 7 (of ITU-T)
TA EWOS Technical Assembly
TC Technical Committee
TCC Time-critical communications
4 Terms and definitions
For the purposes of this Technical Report, the terms and definitions in ISO/IEC 13236:1998 [2] and CEN/TR
12161:1996 [7] apply.
4.1
QoS category
group of user requirements that leads to the selection of a set of QoS requirements [ISO/IEC 13236:1998 [2]]
4.2
QoS characteristic
quantifiable aspect of QoS, which is defined independently of the means by which it is represented or
controlled [ISO/IEC 13236:1998 [2]]
4.3
QoS mechanism
specific mechanism that may use protocol elements, QoS parameters or QoS context, possibly in conjunction
with other QoS mechanisms, in order to support establishment, monitoring, maintenance, control, or enquiry
of QoS [ISO/IEC 13236:1998 [2]]
4.4
QoS information
information related to QoS: it is classified into QoS context (when retained in an entity) and QoS parameters
(when conveyed between entities); and it is classified into QoS requirements (if it expresses a requirement for
QoS) and QoS data (if it does not) [ISO/IEC 13236:1998 [2]]
4.5
QoS parameter
QoS information that is conveyed between entities as part of a QoS mechanism; parameters are classified
into requirement parameters and data parameters; the information conveyed may relate to one or more QoS
characteristics [ISO/IEC 13236:1998 [2]]
4.6
QoS management
any set of activities performed by a system or communications service to support QoS monitoring, control and
administration (as distinct from general techniques such as OSI management) [ISO/IEC 13236:1998 [2]]
8

---------------------- Page: 10 ----------------------

SIST-TP CEN/TR 15253:2006
CEN/TR 15253:2005 (E)
4.7
QoS agreements
the term level of agreement is sometimes used to refer to the negotiated level of support for a given set of
QoS characteristics [ISO/IEC 13236:1998 [2]]
4.8
attribute
property of a real-world object which can be characterised by a finite set of discrete values [ CR 12161:1995
[7] ]
4.9
Set of Attribute Values (SAV)
for a defined set of attributes corresponding to a particular domain of interest (e.g. information interchange),
the SAV consists of an (ordered) list of values for each attribute [ CR 12161:1995 [7] ]
4.10
Goodness of Fit Factor (GOFF)
this defines how well a particular information processing solution (such as a profile) matches a particular SAV
[ CR 12161:1995 [7] ]
4.11
user scenario
description of a real-world information processing requirement, which may be characterised by a Set of
Attribute Values [ CR 12161:1995 [7] ]
5 Quality of service concepts
5.1 Sources
The material in this clause is based on the QoS activity being undertaken by a Joint Rapporteur Group of ITU-
T SG7 and ISO/IEC JTC1/ SC21/WG7, which was established in order to provide common guidance to any
groups developing specifications relating to QoS.
The first objective of the QoS Group was to produce a QoS Framework standard, the aim of which is to
provide a consensus set of concepts and terminology that will enable all those who are developing QoS
specifications to adopt common approaches, to benefit from each others’ work and to communicate effectively.
This standard is currently an International Standard [2].
In parallel, the Group has been documenting references to QoS specifications in various standards and other
documents, as well as the details of a number of mechanisms for use with QoS that are believed to be widely-
applicable. These will be published in a Technical Report, the QoS Guide to Methods and Mechanisms [3].
The QoS Group is also specifying how QoS concepts can be incorporated into ODP (Open Distributed
Processing) and the Object Management Architecture (OMA) of the Object Management Group (OMG).
5.2 Fundamental concepts
5.2.1 General
The fundamental objective of any specification, implementation choice or mechanism relating to QoS can be
expressed using three concepts: the management of QoS characteristics to meet QoS agreements.
9

---------------------- Page: 11 ----------------------

SIST-TP CEN/TR 15253:2006
CEN/TR 15253:2005 (E)
5.2.2 QoS characteristics
QoS characteristics is the term used in the QoS Framework for the properties of systems and activities that
are of relevance to Quality of Service. They include such quantities as
• time delay between two events, such as a request and a response,
• transit delay of a data item between two points
• throughput of a data transfer
• reliability of a system element
• capacity of a system element for storage, or processing
• error-rate of a transfer
• consistency between two copies of a database
• accuracy of data.
The QoS Framework defines a number of useful characteristics, mostly in a generic way (as listed above). In
any specific case, the characteristics have to be specialised: for example, in the case of transit delay it is
necessary to specify the data item and the two points concerned.
5.2.3 QoS management
QoS characteristics have to be managed: and to distinguish this rather special form of management from
general techniques, such as OSI Management, the QoS Framework calls it QoS management. (QoS
management may, of course, call upon other management techniques to fulfil its purposes.)
Meeting a particular requirement for QoS management may need many different types of action to be
performed, for example: negotiation, admission control (e.g. controlling the rate that data is input) and
monitoring. The QoS Framework uses the term QoS mechanisms for these elements of management
function, which can be specified independently.
QoS mechanisms can be thought of as operating in different phases of activity with respect to the activity
whose QoS is to be managed, as follows.
• Prediction phase: before the activity occurs. The purpose of this phase is to predict aspects of system
behaviour so that the appropriate QoS mechanisms can be initiated.
• Establishment phase: before the activity occurs or during its initiation. In this phase elements of the
system may express requirements for QoS, enter into negotiations or re-negotiations, make agreements
on the QoS to be delivered and the actions to be performed if it degrades, and initiate mechanisms that
will be needed during the operational phase (such as allocating resources).
• Operational phase: during the course of the activity. The purpose of this phase is to honour the
agreements made during the establishment phase, or to take appropriate action if that is not possible. In
this phase system elements may monitor QoS, take recovery actions if necessary and/or notify other
system elements of changes in status.
• Release phase: during the orderly or abrupt termination of the activity, and after the activity has finished.
In this phase, the mechanisms in place for the operational phase may need to be closed in an orderly
manner. Log files may need to be closed for off-line analysis to ensure that QoS targets were in fact met.
QoS mechanisms typically require system elements to communicate with one another. Items of QoS-related
information that are communicated in this way are termed QoS parameters. Note the distinction between QoS
10

---------------------- Page: 12 ----------------------

SIST-TP CEN/TR 15253:2006
CEN/TR 15253:2005 (E)
characteristics and QoS parameters. The QoS characteristics are the real system properties to be managed,
the values of which may never be known exactly: the QoS parameters are the items of information about QoS
communicated in order to help in the management process - and they may be target values, proposed
thresholds, limits, coded requests for QoS to be monitored, etc.
5.2.4 QoS agreements
An important activity performed during the establishment phase is reaching agreement on the QoS that is to
be supported. For each QoS characteristic concerned, this may involve determining:
• the nature of the QoS value that is to be agreed (e.g. target operating value, upper limit, lower limit,
threshold for reporting, …)
• whether resources are to be allocated
• whether the QoS actually achieved is to be monitored
• the action or actions to be taken if the agreed QoS cannot be maintained, which might be
− re-negotiation of QoS
− aborting the activity
− aborting another activity of lower precedence to free resources
− changing the behaviour of the user application - for example, to switch to a lower image resolution,
or from colour to black-and-white.
The term level of agreement is sometimes used for this.
In the past, a ”best-efforts” level of agreement has been most commonly used, in which a target QoS value is
agreed for some characteristic but no effort is made to monitor the QoS actually achieved or to take any
further action relating to it. In the future, as it becomes increasingly common for data streams with very
different QoS requirements to share communications resources, systems should evolve to manage QoS more
carefully and dynamically. As can be seen from the above list, a vast range of different levels of agreement
can be defined.
The means by which an agreement is reached may be design decision, imposition by one party or negotiation.
The QoS Guide to Methods and Mechanisms [3] contains a number of definitions of generic QoS negotiation
mechanisms that can be used in a variety of circumstances, including multi-cast communications.
5.3 QoS Mechanisms
5.3.1 General
As described above, QoS mechanisms provide the means to perform the different types of action necessary
to enable a particular requirement for QoS management to be met. Some of the QoS mechanisms which
operate in the different phases of activity with respect to the activity whose QoS is to be managed, are
exemplified in the following subsections.
5.3.2 Mechanisms applicable to the prediction phase
The QoS prediction phase includes the following activities:
• enquiries and analysis of historical information on QoS measures which reflect previous levels of QoS
achieved;
11

---------------------- Page: 13 ----------------------

SIST-TP CEN/TR 15253:2006
CEN/TR 15253:2005 (E)
• prediction of QoS characteristics in the system (e.g. completion time);
• calculation of potential perturbation if specific QoS requirements are requested and granted;
• evaluation of levels of QoS parameters to be requested in the establishment phase;
• checking that requests will not conflict with admission control policies.
Typically such mechanisms are implemented by local or proprietary means; no standards or publicly available
specifications have been identified containing relevant specifications.
Where an underlying communication mechanism is needed as part of prediction phase activities, OSI
Management protocols could be used. Alternatively, a priori knowledge could be used.
5.3.3 Mechanisms applicable to the establishment phase
The QoS establishment phase includes mechanisms for resource allocation and the initialisation of
operational phase mechanisms.
An example of a mechanism for resource allocation is the Resource Reservation Protocol (RSVP) specified in
RFC 1821 [5]. The initialisation of operational phase mechanisms is typically achieved by local means that
are not subject to standardisation.
Methods and mechanisms used in the QoS establishment phase include:
• methods of reaching QoS agreements, including negotiation mechanisms;
• resource allocation mechanisms;
• initialisation mechanisms.
5.3.4 Mechanisms applicable to the operational phase
Mechanisms for the operational phase include:
• monitoring mechanisms;
• maintenance mechanisms;
• synchronisation mechanisms;
• filter mechanisms;
• enquiry mechanisms;
• alert mechanisms.
5.3.5 Mechanisms applicable to the release phase
Mechanisms applicable to the release phase include:
• resource freeing mechanisms;
• log archive mechanisms;
• statistics update mechanisms.
12

---------------------- Page: 14 ----------------------

SIST-TP CEN/TR 15253:2006
CEN/TR 15253:2005 (E)
6 Current relevant work in healthcare informatics standardisation
6.1 General
This clause considers current healthcare informatics standardisation activities which may have a relationship
with QoS. The list is illustrative and makes no attempt to be exhaustive.
There is a great deal of current work in various areas of healthcare informatics standardisation, in many
different fora. It is clearly desirable that, where such standards are concerned with aspects of QoS, they
should align with the QoS Framework and so benefit from any existing work, rather than "re-inventing the
wheel". Any standards which are concerned with qualities such as the following may well have QoS
requirements:
• certification (e.g. to certain safety standards)
• freshness (currency of information)
• calibration (e.g. of laboratory analysers)
• precision
• accuracy.
6.2 Quality management
"QoS" is not restricted to communications services. The "service" in question may include, for example, the
storage and retrieval of information within a single system. Quality procedures apply to the recording, storage,
transmission and retrieval of information, as well as to the overall framework or policy of information handling.
ISO/TC 210 deals with "Quality management and corresponding general aspects for medical devices.". Its
scope includes:
1. the application of quality systems to medical devices;
2. general aspects stemming from the application of quality principles to medical devices;
3. symbols, definitions and nomenclature for medical devices;
4. the application of risk management to medical devices.
The TC 210 work programme is concerned with:
ISO 13485 Medical devices - Quality management systems – Requirements for regulatory purposes
ISO 13488 Quality systems – Medical devices – Particular requirements for the application of ISO 9002
ISO/TR 14969 Medical devices - Quality management systems – Guidance on the application of ISO
13485:2003
ISO 14971 Medical devices - Application of risk management to medical devices
Insofar as this work deals with the quality-related parameters of medical devices, it has a bearing on the
Attributes (as defined in EWOS/ETG 021) for information interchange involvi
...