Health informatics - Quality of service requirements for health information interchange

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.

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é

Zdravstvena informatika – Zahteve za kakovost storitev pri izmenjavi zdravstvenih informacij

General Information

Status
Published
Publication Date
31-Mar-2006
Technical Committee
Current Stage
6060 - National Implementation/Publication (Adopted Project)
Start Date
01-Apr-2006
Due Date
01-Apr-2006
Completion Date
01-Apr-2006

Buy Standard

Technical report
SIST-TP CEN/TR 15253:2006
English language
32 pages
sale 10% off
Preview
sale 10% off
Preview

e-Library read for
1 day

Standards Content (sample)

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

---------------------- 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.
---------------------- 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.

---------------------- 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.
---------------------- 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
---------------------- 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
---------------------- 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]]

---------------------- 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.

---------------------- 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

---------------------- 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;
---------------------- 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.
---------------------- 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
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.