Project No: 045225
Harmonisation, Interoperability and Standard
Status: Final version 1
D3.2: Harmonisation, Interoperability and Standard Page 1 of 38
Project Acronym: Better Breathing
Project Title: Better Breathing; A new model for continuous care of chronic patients -
eCare, eRehabilitation, eCommunity and eLearning for patients with
Contract Number: 046225
Starting date: 01.06.2007 Ending date: 31.12.2007
Deliverable Number: 3.2
Title of the Deliverable: Harmonisation, Interoperability and Standard
WP/Task related to the Deliverable: Adaptation and Localisation: WP3 / T3.2
Type (confidential or public): Public
Author(s): Miguel Ángel Sarasa, Vicente Simorte & Mayte
Hurtado, TB Solutions
Contractual date of delivery to the CEC: 29.02.2008
Actual date of delivery to the CEC: 13.03.2008
Company name : Region Syddanmark
Name of representative : Claus Duedal Pedersen
Address : Rugaardsvej 15, 2 – 5000 Odense C
Phone number : +45 65 43 20 30
Fax number : +45 65 43 20 50
E-mail : firstname.lastname@example.org
Project web site address : www.betterbreathing.org
D3.2: Harmonisation, Interoperability and Standard Page 2 of 38
Table of Contents
Executive summary ...................................................................................................... 5
Purpose and content of the deliverable ..................................................................... 6
What is healthcare interoperability? ............................................................................ 7
Syntactic interoperability ............................................................................................. 8
Semantic interoperability............................................................................................. 8
EHR interoperability .................................................................................................... 9
Relationship to standards............................................................................................ 9
Interoperability problem in the healthcare domain ................................................. 10
The Better Breathing healthcare ecosystem............................................................ 11
Services types........................................................................................................... 11
Devices types............................................................................................................ 12
Main interfaces.......................................................................................................... 12
Better Breathing healthcare interoperability through industry standards............ 15
PAN interface standards ........................................................................................... 15
LAN interface standards............................................................................................ 17
WAN interface standards .......................................................................................... 17
EHR interface standards ........................................................................................... 17
Other interoperability issues to be addressed ........................................................ 20
Conclusions ................................................................................................................ 22
Appendix I: The OSI layered model .......................................................................... 23
Communication layers............................................................................................... 23
The seven layers of the OSI model........................................................................... 23
Appendix II: Main EHR interoperability standards .................................................. 25
The GEHR / OpenEHR initiative ............................................................................... 25
CEN/TC 251 and ENV/EN 13606 EHRcom .............................................................. 25
HL7 Clinical Document Architecture (CDA) .............................................................. 26
IHE Cross-Enterprise Document Sharing (XDS)....................................................... 26
IHE Cross-Enterprise Sharing of Medical Summaries (XDS-MS)............................. 27
IHE Retrieve Information for Display (RID) ............................................................... 27
Appendix III: Standards list ....................................................................................... 28
References .................................................................................................................. 38
D3.2: Harmonisation, Interoperability and Standard Page 3 of 38
Figure 01 – Better Breathing ecosystem of healthcare devices/services ..................... 11
Figure 02 – The Better Breathing interfaces in the reference architecture ................... 13
Figure 03 – OSI layered model..................................................................................... 23
Table 01 – The seven layers of the OSI model ............................................................ 24
Table 02 – Standards list .............................................................................................. 37
D3.2: Harmonisation, Interoperability and Standard Page 4 of 38
This deliverable provides an overview of the interoperability problem for the
modules and components used in the healthcare environment within the Bet-
ter Breathing project. It presents the challenges and needs related to wired
and wireless personal healthcare systems, and also provides an outline of the
various communication standards aiming to enable the interoperability.
The ISO-OSI model is used thorough the document so as to analyze interop-
erability on a technology level. The model is discussed in detail in Appendix I:
The OSI layered model. It has been widely addressed in research and prac-
tice. In addition, reference annexes are provided, containing the major stan-
dards used to guarantee the interoperability (see them attached at the end of
the deliverable in order to keep this document short).
D3.2: Harmonisation, Interoperability and Standard Page 5 of 38
Purpose and content of the deliverable
The core objective of the deliverable is to cover the necessary issues to en-
sure the interoperability on technologies, devices and services inside the Bet-
ter Breathing project. The deliverable will also analyse the potential problems
to be addressed, as well as the solving factors about harmonisation, interop-
erability and standards relevant for the market deployment of Better Breathing
project. As a result, a background document on interoperability of the Better
Breathing healthcare devices and services will be provided, discussing the
technical issues and standards to be addressed for achieving interoperability.
The above purposes will be addressed with the ISO-OSI model as a refer-
ence, so as to analyze interoperability on a technology level. The model is dis-
cussed in detail in Appendix I: The OSI layered model. It has been widely ad-
dressed in research and practice. For the purpose of the deliverable, upper
three layers of the OSI model will be referred to address the communication
between medical technical systems (according to the model, two systems can
communicate in a technical sense as long as they use common protocols from
levels 1 through 5). When not only bit transmission is required, it is also nee-
ded a common protocol on level 6 (also called the presentation layer, with the
function of performing transformations on data before they are sent to lower
levels). Finally, to actually use the medical information, a common understand-
ing at the application level 7 will be also needed. In addition to the OSI-based
interoperability analysis, the nature of the available standards, with respect to
the contribution they make toward interoperability within the Better Breathing
healthcare domain will also be explored.
The deliverable is structured as follows: First of all, an Executive Summary, as
well as the purpose and scope of the deliverable are set up. A scattered intro-
duction is given next, addressing the overall need of interoperability in the
healthcare domain. The concepts of interoperability and interoperability types
are defined here, extending the computer science definitions to the healthcare
specific context. Moreover, a first indication of the different types of standards
needed to achieve such domain specific interoperability is also provided.
The problem of interoperability in the personal healthcare domain is elabo-
rated in more detail in the following section. A brief overview of the Better
Breathing healthcare ecosystem (reference architecture, service and device
types and main interfaces) is then presented. After that, the most relevant
standards to be measured within the Better Breathing project are outlined.
These standards are aimed to achieve the interoperability on upper-layers, as
well as on the application layer of the OSI stack, and will be related to each of
the main interfaces defined within Better Breathing healthcare ecosystem.
The last sections provide finally other interoperability issues to be addressed,
along with the concluding remarks. Reference annexes are also provided,
containing the major standards used to guarantee the interoperability.
D3.2: Harmonisation, Interoperability and Standard Page 6 of 38
The healthcare industry must improve its delivery methods to address current
and expected needs. Various technologies could help by extending traditional
treatment into personal assistance and home settings. However, creating such
a healthcare ecosystem will require interoperability.
Personal healthcare systems, including remote patient monitoring and man-
agement, are increasingly recognised as having the potential to help to im-
prove the quality of care for an increasing number of patients. This patient-
centred concept of bringing the care from the hospital or the doctor’s office to
the patient at home results in improved quality of care. This results in longer
independent living, in particular, for older patients.
In addition to the care being provided in a remote and personalised way, an
important factor for enabling the success of future healthcare systems is to
make the last hop to the patient wireless. By introducing wireless technology,
cumbersome cables can be eliminated, enabling greater physical mobility and
making the system more unobtrusive and ubiquitous for the patient.
An example for a sophisticated system solution incorporating the aspects
mentioned above are the remote patient monitoring platforms based on
TV/TDT (Terrestrial Digital Television). These platforms comprise daily, per-
sonalized patient interactions, delivered via broadband connection to the
home television. Patients receive reminders and messages, educational vid-
eos, and feedback on their vital signs comprising blood pressure, and blood
glucose levels, based on a tailored care plan defined by their caregiver.
However, besides the benefits of wireless personal healthcare systems, there
exist also several challenges and issues still unresolved. A lot of isolated and
proprietary solutions still exist today. Indeed, there is an enormous conglom-
eration of personal health devices and services lacking interoperability, and
hence preventing that the interoperability issues are solved in a unified and
standardized way. Thus, it is exactly the approach of enabling healthcare in-
teroperability and connectivity within the context of wireless personal health-
care, which is necessary for the success of future such systems.
What is healthcare interoperability?
It is widely recognised the need of medical information technology interopera-
bility in order to improve the quality of healthcare. In order to clarify the inter-
operability concept, the IEEE has proposed a definition of the term for its use
by policymakers and in legal or contractual contexts. The IEEE definition of in-
teroperability in healthcare is as follows:
In healthcare, interoperability is the ability of different information tech-
nology systems and software applications to communicate, to exchange
data accurately, effectively, and consistently, and to use the information
that has been exchanged.
D3.2: Harmonisation, Interoperability and Standard Page 7 of 38
Interoperability can be investigated in different categories in the healthcare
domain, such as the interoperability of the messages exchanged between
healthcare applications, the interoperability of Electronic Healthcare Records
(EHRs), the interoperability of patient identifiers, coding terms, clinical guide-
lines and healthcare business processes, etc. All of these categories can be
structured in three major layers of interoperability: syntactic interoperability,
semantic interoperability and EHR interoperability. All of these layers are
described in the following sections.
A prerequisite for interoperability is the ability to communicate the bits running
on the wires. Syntactic interoperability involves the ability of two or more sys-
tems to exchange information. It entails several layers:
• Network and transport layer: In transferring healthcare messages be-
tween application systems, network and transport protocols are nee-
ded, such as Internet. In fact, today, TCP/IP is the de-facto on-line
• Application protocol layer: An application protocol standard is also
needed, such as HTTP or SMTP (email).
• Messaging protocol and message format layer: On top of this layer,
standard messaging protocols are also required, such as SOAP or
• Sequencing of the messages: The sequencing of the messages also
needs to be standardized. For example, in Health Level 7 (HL7), when
“I05 RQC Request Clinical Information” message is sent, the expected
return message is “I05 RCI Return Clinical Information”. There are also
different types of messages. Each message is either one with the in-
tent of action or an acknowledgment one, indicating successful or error
transmission. Finally, for the message content to be processed cor-
rectly by the receiving application, the message content structure and
the data items in the message must be standardized, for example as
proposed by HL7 version 3.
With all above, syntactic interoperability guarantees the message to be deliv-
ered, but does not guarantee that the content of the message will be machine-
processable and “understood” at the receiving.
A common usage of the term “semantic interoperability in healthcare can be
found in CEN/ISSS:
“Semantic interoperability implies that the structure of the 'documents' is
interpretable, and that their content is understandable. Making this con-
D3.2: Harmonisation, Interoperability and Standard Page 8 of 38
tent understandable sometimes requires that the keys for its correct and
safe interpretation, such as the terminological systems used, are identi-
fied and easily available”
Semantic interoperability guarantees message contents interoperability, by
forcing them to comply with an agreed structured machine-processable stan-
dard. Thus, semantic interoperability allows for information shared by systems
to be understood at the level of formally defined domain concepts. Another
important use of semantic interoperability in the healthcare domain is the inte-
gration of data from heterogeneous sources. Semantic mediation can be used
to convert healthcare messages defined in one standard format into another.
The Electronic Healthcare Record (EHR) of a patient can be defined as digi-
tally stored healthcare information about individual’s lifetime with the purpose
of supporting continuity of care, education and research, and ensuring confi-
dentiality at all times. A patient’s healthcare information may be spread out
over a number of different institutes which do not interoperate. In order to pro-
vide continuity of care, clinicians should be able to capture the complete clini-
cal history of a patient. An exchange of well-structured and machine proc-
essable electronic healthcare records has not been achieved yet in practice
due to the lack of EHR interoperability.
Relationship to standards
In order to achieve interoperability for the emerging healthcare ecosystem in a
unified and standardized way, various connectivity and communication stan-
dards should be followed. A standard is an agreement among parties within an
area of technology. Interoperability is the result of an agreement between or
among systems to share information.
In healthcare information technology, standards can be basically categorised
on data transmission standards (to provide syntactic interoperability) and
medical terminology interpretation standards (to achieve syntactic and
EHR interoperability). In the early stages of implementation, it is unlikely that
every system is completely interoperable with every other. However, there will
be an incremental movement toward this, as interoperability of clinical informa-
tion from a variety of sources is achieved through the usage of agreed-upon
standards. Initial efforts at achieving interoperability should be focused on the
clinical information that is already stored in a coded and structured format, and
that would yield the highest clinical value if made interoperable.
Because they will supply the framework on which interoperability will develop,
standards should be open, public and non-proprietary ones. Standards specify
much of the detail necessary to ensure interoperability. However, some critical
details are in the hands of the organizations that actually implement the stan-
dards. To achieve interoperability, organizations involved in data exchange
projects need to work together to assure that such implementation details are
addressed consistently among the participants.
D3.2: Harmonisation, Interoperability and Standard Page 9 of 38
Interoperability problem in the healthcare domain
One of the key problems in healthcare informatics is the lack of interoperability
among the different healthcare information systems. Typically, they consist of
three parts: a patient-end, with personal health devices in the patient’s home,
a back-end part for storing the data, and a care provider-end, where the per-
sonal health consultant has access to the patient’s data.
The devices at home are medical equipment (e.g. blood pressure and pulse
rate meters, electrocardiographs, pulse oximeters, etc.) for measuring the pa-
tient’s vital signs, and usually some kind of compute engine (e.g. a PC, Per-
sonal Digital Assistant or mobile phone) for gathering the data and providing a
user interface for the patient. The back-end part contains a server component,
which is connected via a network (e.g. the Internet) to the patient-end part.
Similarly, at the care provider-end, access to the patient’s data on the server
component is enabled via some network, which could also be the Internet.
Obviously, there is a need for intercommunication among the various compo-
nents within the system. Focusing on the patient-end part, there are several
alternative wireless technologies to establish a wireless link between medical
devices and compute engines. However, the standardization process with re-
gard to medical device interoperability lacks behind technical possibilities. Vir-
tually, all of these solutions are specialized applications with proprietary inter-
faces unique to the two devices being linked.
Thus, ensuring compliance on the physical layer between two devices
does not ensure interoperability, as there are many different ways to trans-
mit the same information over a physical layer interface. In order to ensure in-
teroperability between multi-vendor devices, the devices must be able to un-
derstand the format and the content of the messages they communicate to
each other. Hence, on the patient-end side, the problem of device interopera-
bility has to be solved on three principle levels:
• On lower-layers: A standardized transport technology enabling basic
connectivity has to be developed.
• On upper-layers: Application profiles have to be developed, which de-
fine what capabilities of the transport technology have to be used to
best support the application requirements.
• On application level: Standardized data models and formats have to
be developed, which represent an abstract and unique mapping of the
real world entities.
While a significant amount of problems on the lower layers has been solved
already and mature standards are available, more work at levels closer to the
application is needed.
D3.2: Harmonisation, Interoperability and Standard Page 10 of 38
The Better Breathing healthcare ecosystem
A big picture of the reference architecture for the Better Breathing personal
healthcare system is given in Figure 01 – Better Breathing ecosystem of
Figure 01 – Better Breathing ecosystem of healthcare devices/services1
The different components of the reference architecture will be described in the
The service-side is basically conformed by four health services that are envis-
aged to be market validated during the project period. These services will re-
quire both, access to data repositories as well as the transmission / exchang-
ing of clinical information. The referred services are the following:
• ePatient Community services: These services will allow chronic pa-
tients to virtually meet (from their home) with other chronic patients,
and exchange experiences and advice on how to live with the disease.
• eCare services: These services will be implemented and evaluated to
demonstrate that eCare is feasible in the care of chronic patients. The
Adapted from the Continua Healthcare Alliance .
D3.2: Harmonisation, Interoperability and Standard Page 11 of 38
services will allow registered patients to run queries and send their
own biometrical data-sets to healthcare professionals.
• eRehabilitation services: These services is intended to train the pa-
tient in his/her own home by use of Information and Communication
Technology (ICT), by treating and caring for chronic patients in their
own home through the deployment of communication equipment ePa-
tient Community / eProfessional Community.
• eLearning services: The Better Breathing project will also provide ef-
fective and pedagogical tools that the patients and/or healthcare pro-
fessionals can use, thus achieving greater understanding of the dis-
ease and their ability to manage it.
Concerning the device-side, Better Breathing reference architecture breaks
down its functionality into four main device classes:
• Personal Area Network (PAN) devices: PAN devices are mainly vital
signs sensors (such as blood pressure and pulse rate meters, electro-
cardiographs, pulse oximeters, spirometers, heart-rate monitors, etc).
• Local Area Network (LAN) devices: LAN devices aggregate and sha-
re (via a network) the bound PAN devices’ information (such as a
proxy function). A LAN device can also implement sensor functionality.
• Application Hosting (AH) devices: Such as personal computers, cell
phones, Personal Data Assistants (PDAs), set top boxes, which allow
the aggregation and computation.
• Wide Area Network (WAN) devices: These devices allow the imple-
mentation of managed-network-based services. They collect informa-
tion and host a wide range of value-adding services (for example, a
health monitoring service hosted on a network-based server).
When the interoperability problem is addressed from the scope of the systems
that have to exchange information, seven different kinds of communication
can be identified. The IEEE definition of interoperability (implicitly) applies to
the communication between the technological systems. The ISO-OSI model
(see Appendix I: The OSI layered model) was developed for these kinds of in-
terconnections. The OSI model will be used as reference to analyse the inter-
operability problem, focusing on the Better Breathing domain-specific context.
The connection between/among the different devices and the reference topol-
ogy inside the Better Breathing project (i.e., the whole range from the medical
D3.2: Harmonisation, Interoperability and Standard Page 12 of 38
device at the patient’s home to the back-end services) can be addressed
through four network interoperable interfaces, which are the centre and play a
key role within the ecosystem interoperability. These four referred interfaces
are depicted in the Figure 02 – The Better Breathing interfaces in the refer-
Figure 02 – The Better Breathing interfaces in the reference architecture2
The interfaces features are summarised in the following:
• Peripheral Area Network Interface (PANI): It connects an AH device
to a PAN device. This interface has a lower-layers component, as well
as an upper-layers component. The instantiations of the lower layers
include both, wired and wireless links. Regarding the upper layers,
they are implemented using optimised exchange protocols.
• Local Area Network Interface (LANI): It connects an AH device to a
LAN device. This means that LANI’s upper layers can support the sa-
me device data model as the PANI’s upper layers. In fact, using the
same device data model, regardless of the underlying OSI lower-layers
communications mechanism, is a key interoperability feature.
• Wide Area Network Interface (WANI): This interface connects an AH
device to one or more other devices. The WANI OSI upper-layers must
use a device data model compatible with the LANI upper layers’ device
data model. Again, the exchangeable device data model is the key
component for Better Breathing interoperable healthcare ecosystem.
Adapted from the Continua Healthcare Alliance .
D3.2: Harmonisation, Interoperability and Standard Page 13 of 38
• Electronic Health Records Interface (EHRI): This interface enables
patient-centric data communications between a WAN device and a
health-record device, typically at the boundary of the personal health-
care ecosystem. This is in contrast to the other interfaces, which sup-
port device centric data communications between an AH device and
other Better Breathing devices. The typical EHR device implements a
health record database or other system, managed and operated by a
traditional healthcare service provider (for example, an electronic-
health-records system that a hospital or healthcare system manages
and operates). The HER Interface lets multiple enterprise healthcare
entities exchange personal health information. The corresponding
health-record systems have existing industry-standard information mo-
dels that likely differ from the WAN device. This interface describes
how healthcare entities can transform the data so that all parts of the
larger healthcare systems can collaborate.
Several wired and wireless standards are available for selection to establish
connectivity at the various interfaces, as will be described in the following sec-
tions of the present document.
D3.2: Harmonisation, Interoperability and Standard Page 14 of 38
Better Breathing healthcare interoperability
through industry standards
It’s rather difficult to encompass all the communications interfaces that various
vendors bring to the market using proprietary technologies. Therefore, in order
to achieve interoperability in the healthcare domain, as much as possible ex-
isting connectivity standards and guidelines for interoperability should be fol-
lowed. A vast amount of standards is available from different communities in
the healthcare domain.
As indicated in the Figure 02 – The Better Breathing interfaces in the refer-
ence architecture, the whole range of devices and services within the Better
Breathing architectural structure is addresses by defining interoperable inter-
faces. Taking this into account, the process suggested for the Better Breathing
project to develop interoperability guidelines is centred on the use of industry
standards applicable to each of these interfaces. The most relevant specifica-
tions related to each one of the referred interfaces are described as follows.
PAN interface standards
As indicated above, the Peripheral Area Network (PAN) Interface connects an
application hosting device (such a personal computer, cell phone, PDA, set
top box, etc) to a PAN device (spirometer, heart-rate monitor, etc.). This inter-
face has both, a lower-layers component, encompassing the classic Open
Systems Interconnection (OSI) layers 1 to 4, and an upper-layers component
(encompassing the classic OSI layers 5 to 7).
The instantiations of the lower OSI layers may include both, wired and wire-
less links (such as USB and/or Bluetooth based technologies). Regarding the
upper OSI layers, they can be implemented using the ISO/IEEE 11073-20601
Optimized Exchange Protocol, which leverages work from ISO/IEEE 11073
Medical Device Communications working group. A more detailed report on
each of these links is given in the following.
Wireless Area Networks (WANs) and their supporting information infrastruc-
tures offer unprecedented opportunities to monitor state of health. These mo-
bile point-of-care systems are now realizable due to the convergence of tech-
nologies such as low-power wireless communication standards, plug-and-play
device buses, handheld computers, electronic medical records, and the Inter-
net. To increase acceptance of personal monitoring technology, advances
must be made in interoperability (at both the system and device levels).
In the Better Breathing architectural structure, several wireless short-range
communication standards are available for selection so as to establish con-
nectivity at the PAN Interface. Among them, the IEEE 802.15 (WPAN) family
of standards has the largest impact on wireless today. Although providing lo-
D3.2: Harmonisation, Interoperability and Standard Page 15 of 38
wer data rates than IEEE 802.11, it is mainly the IEEE 802.15 family that fits
best the requirements of small-scale personal health devices in terms of low
power consumption and low complexity.
For the connection of medical devices to the system, the major WPAN tech-
nologies today (after the activities in IEEE 802.15.3 for high-rate WPAN have
been abandoned) are IEEE 802.15.1 (better known as Bluetooth), IEEE
802.15.4 in combination with ZigBee and Wi-Fi, amongst others.
Bluetooth allows the wireless telemetry between the components in the point-
of-care environment. In particular, the Bluetooth SIG Medical Devices Working
Group is tasked with enabling interoperability between Bluetooth-enabled me-
dical, health and fitness devices, and systems that can aggregate and perform
operations on device data (such could be data from cellular phones, health
appliances, set-top boxes, or PCs.) This effort includes the development of a
profile that allows consumers to easily connect any two devices that support
the medical device profile. Such devices have unique needs, and this working
group aims to address those needs through focused representation of the me-
dical and fitness device industries.
The other major WPAN technology referred above is IEEE 802.15.4, in com-
bination with ZigBee on top of it (with IEEE 802.15.4 defining only the physical
and MAC layer of the OSI stack). Operating in the license-free worldwide
2.4GHz ISM (Industrial, Scientific and Medical) band, IEEE 802.15.4 operates
additionally in two less-crowded sub-GHz bands.
For connections regarding the in-home network, the list includes wireless Et-
hernet, and power line communications. Last but not least, regarding the
connectivity from the patient’s home to the back-end services, some relevant
standard candidates amongst others are: Cable, DSL, Cellular (e.g. GPRS or
CDMA), WiMax, and POTS.
The USB-IF Personal Healthcare Device Working Group is tasked to enable
personal healthcare devices to seamlessly interoperate with USB hosts. The
group’s initial goal is to define a USB Personal Healthcare Device Class speci-
fication. The specification will enable health-related devices, such as blood
pressure cuffs and exercise watches, to connect via USB to consumer elec-
tronic products such as PCs and health appliances.
Interoperability of health-related devices and consumer electronic products will
facilitate the communication between a patient and a doctor, an individual and
a fitness coach, or an elderly person and a remote caregiver. For connections
regarding the in-home network wired Ethernet, and power line communica-
tions are also included.
D3.2: Harmonisation, Interoperability and Standard Page 16 of 38
LAN interface standards
The Local Area Network (LAN) Interface connects an application hosting de-
vice (personal computer, set top box, etc) to a LAN device (TV, TDT, etc). This
means that LANI’s upper layers can support the same device data model as
the PANI’s upper layers (this is to say, the ISO/IEEE 11073-20601 data mo-
del). As before, using the same device data model, despite the underlying OSI
lower-layers communications mechanism, is a key interoperability feature.
Among the many wireless short-range communication standard activities
worldwide, the IEEE 802.11 (WLAN) family of standards have the largest im-
pact on wireless today, providing higher data rates than IEEE 802.15, and tak-
ing into account that the requirements of LAN devices are also more advanced
than the ones of small-scale personal health devices in terms of low power
consumption and low complexity.
It should also be a main aim to be achieved that the LANI lower layers on In-
ternet Protocol technology allows to enable different IP-centric communica-
tions technologies (such as Ethernet and Wi-Fi technologies).
WAN interface standards
The Wide Area Network (WAN) Interface connects an application hosting de-
vice (such a personal computer, cell phone, PDA, set top box, etc) to one or
more other devices.
The upper OSI layers of the WAN Interface must use a device data model that
is compatible with the LAN Interface upper layers’ device data model. It is also
worthwhile that the WAN Interface lower layers are based on IP technology, to
enable IP centric communications technologies, such as xDSL, DOCSIS (Da-
ta over Cable Service Interface Specifications), PPP/POTS (Point-to-Point
Protocol/Plain Old Telephone Service), GPRS (General Packet Radio Service)
or EDGE (Enhanced Data Rates for GSM Evolution).
EHR interface standards
The PAN, LAN and WAN interfaces and standards referred above basically
cover the lower OSI layers (physical layers). As pointed out in section
Interoperability problem in the healthcare domain, the interoperability on appli-
cation layer requires that devices speak a common language by means of a
common nomenclature, data types, data exchange protocols, message syn-
tax, and encoding rules. Therefore, to be able to exchange information among
heterogeneous healthcare information systems, messaging interfaces must be
used. Typically, a messaging interface gathers data from the back-end appli-
cation systems, encodes the data into a message, and transmits the data over
a network to another application. On the receiver side, the received messages
are decoded, processed and the data which have been received are fed into
the receiver’s back-end systems to be stored and processed.
D3.2: Harmonisation, Interoperability and Standard Page 17 of 38
If proprietary formats were used in messaging, the number of the interfaces to
be developed would increase drastically. To overcome this potential problem,
message standards are preferred, which allow that an application can, in
principle, talk to any other application conforming to the same message stan-
dard by using the same message interface.
With all above, to address the Electronic Healthcare Record (EHR) interop-
erability problem in view of the rising activities in the Better Breathing personal
healthcare domain, system-level interoperability efforts will have to include the
development of wearable health status monitoring systems that utilize stan-
dards that enable upper-layer medical information exchange. The most rele-
vant standards for the Better Breathing specific healthcare context include:
• Health Level 7 (HL7)
• HL7 Clinical Document Architecture (CDA)
• DICOM (Digital Image COMmunication)
• CORBA (for physician-side data access, viewing, and analysis)
• ISO 11073/IEEE 1073 family of standards, formerly also referred to as
IEEE 1073 – Medical Information Bus (MIB) or x73 standards.
• CEN EN 13606 and CEN/TC 251 EHRcom
These standards aim to structure and mark-up the clinical content for the pur-
pose of exchange. A description of EHR standards is given in Appendix II:
Main EHR interoperability standards, which introduces some of the prominent
EHR standards and then describes how each addresses technical interopera-
bility layers: messaging layer and content interoperability layer.
There is also an industry initiative called Integrating the Healthcare Enter-
prise (IHE), which specified the Cross-Enterprise Document Sharing (XDS)
integration profile for this purpose. The basic idea of IHE XDS is to store
healthcare documents in ebXML registry/repository architecture so as to facili-
tate their sharing.
DICOM (Digital Image COMmunication) and HL7 (Health Level 7, referring to
ISO-OSI 7th layer) are the most concrete and operational standards. DICOM is
a standard for transmitting medical imaging data, including handling, storing
and printing. HL7 is a comprehensive set of standards for the exchange of
healthcare information between computer applications.
Currently, the Health Level 7 (HL7) version 2 Messaging Standard is the
most widely implemented message interface standard in the healthcare do-
main. However, being HL7 v2 compliant does not imply direct interoperability
between healthcare systems. This stems from the fact that version 2 mes-
sages have no explicit information model, rather vague definitions for many
D3.2: Harmonisation, Interoperability and Standard Page 18 of 38
data fields and contain many optional fields. This possibility provides great
flexibility, but necessitates detailed bilateral agreements among the healthcare
systems to achieve interoperability. To remedy this problem, Health Level 7
version 3 has been developed, which is based on an object-oriented data
model, called Reference Information Model (RIM). It should be noted that
there is an interoperability problem between HL7 v2.x and HL7 v3 messages,
as there is no well-defined mapping between HL7 v2.x and v3 ones.
The ISO/IEEE 11073 Personal Health Data Working Group is defining trans-
port-independent personal-health data and protocol standards. The group’s
charter is to provide standards that address transport-independent application
and information profiles, comprising exchange format, data representation,
and terminology. As a result, the ISO 11073/IEEE 1073 is a family of stan-
dards intended to enable medical devices to interconnect and interoperate
with other medical devices, for plug-and-play interoperability between medical
monitoring system components. ISO/IEEE 11073 utilizes the CEN TC 251 VI-
TAL standard for physiologic information representation and access as well as
a suite of ISO standards.
Consequently, it is feasible to incorporate interoperability into a WAN infra-
structure. It should be noted that, while HL7 is the most pervasive standard for
medical information exchange in the industry, it has not been widely applied to
point-of-care systems yet, and very few HL7-compliant homecare telemedicine
systems exist, and HL7 has not yet been applied in systems that incorporate
WAN technology. It is also worth noting that ISO/IEEE 11073, Health Level 7,
CORBA, Bluetooth, and ZigBee have sensible mappings to the ISO Open
System Interconnect model for standardized component interactions.
D3.2: Harmonisation, Interoperability and Standard Page 19 of 38
Other interoperability issues to be addressed
To achieve interoperability within the healthcare domain, in particular, within
Better Breathing project, further technical issues should also be addressed:
• Mapping the patient IDs among different healthcare applications:
A key issue in accessing the EHR of a patient is his/her patient identi-
fier. Yet different healthcare enterprises or even different departments
in a healthcare institute may be using diverse identifiers for the same
patient. Some of the possible mechanisms are as follows:
o A central database containing all person identification numbers
linked to demographic data.
o Smart card containing personal identification numbers.
o Master Patient Indexes mapping patient identifiers in different
systems to each other.
• Authenticating the users across the enterprises: The users must be
authenticated not only in their own domain but also across enterprises.
• Guaranteeing all computers involved to have consistent time: For
distributed applications to work correctly, it is essential that the system
clocks and time stamps of the many computers in the network are well
• Authenticating nodes and obtaining audit trail: Limiting access con-
trol to authorized users is not enough. It is necessary to limit network
access between nodes and also to each node in a healthcare setting.
Furthermore, audit trail is essential. It is necessary to allow a security
officer in a healthcare institution to audit activities to detect improper
creation, access, modification and deletion of Protected Health Infor-
mation (PHI). The audit trail must contain information to answer the fol-
o For some user: which patients’ PHI was accessed?
o For some patient PHI: which users accessed it?
o What user authentication failures were reported?
o What node authentication failures were reported?
• Cross-Border interoperability at European level: From all above, it
is clear that in order to resolve interoperability at the EU level, the is-
sues that need to be addressed include:
D3.2: Harmonisation, Interoperability and Standard Page 20 of 38
o Providing the interoperability of the various different messaging
infrastructures being used.
o Providing the interoperability of the various EHR standards be-
o Providing the interoperability of various patient identification
o Providing security, privacy and authentication in accessing cli-
Several projects are addressing these issues to propose possible al-
ternatives. It is a roadmap project for interoperability of healthcare sys-
tems leading to recommendations for actions and to preparatory ac-
tions at the European level. This roadmap will prepare the ground for
future actions as envisioned in the action plan of the healthcare Com-
munication COM 356 by coordinating various efforts on healthcare in-
teroperability in member states and the associated states.
D3.2: Harmonisation, Interoperability and Standard Page 21 of 38
Personal healthcare systems have the potential to cope with today’s major
healthcare challenge of improving the quality of care for an increasing number
of chronically ill patients. Today, there exist a lot of technologies and technol-
ogy standards, but still being isolated solutions to the overall complex prob-
lem. However, there is significant activity in industry and standardization or-
ganizations aiming at enabling real plug-and-play multi-vendor interoperability
in the personal healthcare ecosystem.
At the beginning of this deliverable, it was addressed the problem that even
though standards are vital to achieve effective communication in the net-
worked society, from a practical point of view, it is often hard to find out what a
particular standard actually has to offer to achieve “true” interoperability. In this
deliverable, it has been looked at the role of standards to arrive at interopera-
bility in a domain specific situation, the Better Breathing healthcare ecosys-
tem. A framework has been provided to determine the kinds of issues that
need to be addressed, and what different standards actually fulfil these needs.
This deliverable has aimed to contribute in two main directions. Firstly, the im-
portance of adopting a broader definition of interoperability has been stressed,
spanning beyond the interoperability between technical systems (actual com-
munications process itself) to the interoperability between socio-technical sys-
tems (medical protocol negotiation process). Secondly, a framework has been
exposed focusing the attention on relevant available standards needed to at-
tain “true” interoperability for the particular Better Breathing project domain.
D3.2: Harmonisation, Interoperability and Standard Page 22 of 38
Appendix I: The OSI layered model
When discussing various standards and systems communications protocols, it
is useful to have an understanding of the OSI model, from which these proto-
cols are based. OSI (Open System Interconnection) is an ISO standard for
worldwide communications that defines a framework for implementing com-
munications protocols in seven layers.
While the OSI model serves as a useful teaching model for protocols, there
are few real world examples of strict implementations of OSI. Most of the func-
tionality in the OSI model exists in all communications systems, although pro-
tocols and systems often use a pragmatic mixture of the various layers.
The seven layers of the OSI model
The theoretical OSI model is built around the concept of 7 layers. Ideally,
communication control is passed from one layer to the next, starting at the ap-
plication layer in the sender's domain. Each layer is insulated from the layers
above and below, and does not know or care about the workings of other lay-
ers. The OSI model illustrated in Figure 03 – OSI layered model provides a
useful mechanism for discussing the application of messaging, even though
strict adherence to the model is rare in real world.
Figure 03 – OSI layered model
D3.2: Harmonisation, Interoperability and Standard Page 23 of 38
Each layer consists of the following:
Layer Name Description
This layer supports application and end-user processes.
Communication partners are identified, quality of service
is identified, user authentication and privacy are consid-
ered, and any constraints on data syntax are identified.
Everything at this layer is application specific. This layer
7 Application provides application services for file transfers, email,
and other network software services. Telnet and FTP
are applications that exist entirely in the application
level. Tiered application architectures are part of this
layer. HL7 is primarily focussed at this layer, however
also crosses into lower layers.
This layer provides independence from differences in
data representation (e.g., encryption) by translating from
application to network format, and vice versa. The pres-
entation layer works to transform data into the form that
the application layer can accept. This layer formats and
encrypts data to be sent across a network, providing
freedom from compatibility problems. It is sometimes
called the syntax layer.
This layer establishes, manages and terminates con-
nections between applications. The layer sets up, coor-
5 Session dinates, and terminates conversations, exchanges, and
dialogues between the applications at each end. It deals
with session and connection coordination.
This layer provides transparent transfer of data between
end systems or hosts, and is responsible for end-to-end
error recovery and flow control. It ensures complete
This layer provides switching and routing technologies,
creating logical paths, known as virtual circuits, for
transmitting data from node to node. Routing and for-
warding are functions of this layer, as well as address-
ing, inter-networking, error handling, congestion control
and packet sequencing.
At this layer, data packets are encoded and decoded
into bits. It furnishes transmission protocol knowledge
and management and handles errors in the physical
layer, flow control and frame synchronization. The data
link layer is divided into two sub-layers: The Media Ac-
2 Data Link
cess Control (MAC) layer and the Logical Link Control
(LLC) layer. The MAC sub-layer controls how a com-
puter on the network gains access to the data and per-
mission to transmit it. The LLC layer controls frame syn-
chronization, flow control and error checking.
This layer conveys the bit stream - electrical impulse,
light or radio signal -- through the network at the electri-
cal and mechanical level. It provides the hardware
1 Physical means of sending and receiving data on a carrier, in-
cluding defining cables, cards and physical aspects.
Fast Ethernet, RS232, and ATM are protocols with
physical layer components
Table 01 – The seven layers of the OSI model
D3.2: Harmonisation, Interoperability and Standard Page 24 of 38
Appendix II: Main EHR interoperability standards
This appendix introduces and provides an overview of some of the prominent
EHR (Electronic Healthcare Records) standards that address the interopera-
bility within a healthcare domain. It is also described how each EHR standard
addresses the technical interoperability layers: messaging and content layers.
The GEHR / OpenEHR initiative
The most noteworthy concept introduced by GEHR / OpenEHR is the “arche-
type" concept. This approach uses a two-level methodology to model the EHR
structure. In the first level, a generic reference model (specific to the health-
care domain but still very general) is developed. This model typically contains
only a few classes (e.g. role, act, entity, participation), and must be stable over
time. In the second level, healthcare and application specific concepts (such
as blood pressure, lab results etc.) are modelled as archetypes.
An archetype definition basically consists of three parts: descriptive data, con-
straint rules and ontological definitions. The descriptive data contains a unique
identifier for the archetype, a machine-readable code describing the clinical
concept modelled by the archetype, and various metadata such as author,
version, and purpose. The constraint rules are the core of the archetype and
define restrictions on the valid structure, cardinality and content of EHR record
component instances complying to the archetype. The ontological part defines
the controlled vocabulary (that is, the machine readable codes) that can be
used in specific places in instances of the archetype. It may contain language
translations of code meanings and bindings from the local code values used
within the archetype to external vocabularies such as SNOMED or LOINC. It
may also define additional constraints on the relationship between coded en-
tries in the archetype based on the code value.
CEN/TC 251 and ENV/EN 13606 EHRcom
The CEN standard ENV 13606:2000 “Electronic Healthcare Record Commu-
nication" is a message-based standard for the exchange of electronic health-
care records. EN 13606, called EHRcom is a five-part standard consisting of:
• The Reference Model.
• Archetype Interchange Specification.
• Reference Archetypes and Term Lists.
• Security Features.
• Exchange Models (communication protocol).
D3.2: Harmonisation, Interoperability and Standard Page 25 of 38
The standard defines a list of machine-readable domain terms that can be
used to structure EHR content, a method of specifying “distribution rules", that
is, rules under which certain EHR content may be shared with other systems
and, finally, request and response messages that allow systems to exchange
subsets of an HER.
HL7 Clinical Document Architecture (CDA)
CDA is organized into three levels. Each level iteratively adds more mark-up
to clinical documents, although the clinical content remains constant at all lev-
els. “Level One" focuses on the content of narrative documents. It consists of
two parts, the CDA Header and the CDA Body, which are based on the HL7
data types. The document header is derived from RIM and unambiguously de-
fines each entry in the document. The body contains the clinical document
content, and can be either an unstructured text or can be comprised of nested
containers such as sections, paragraphs, lists, and tables through structured
mark-up. Hence there is no semantics in Level One body; it offers interopera-
bility only for human-readable content. In fact, CDA Level One describes a
kind of HTML document with a standardized header that contains additional
information on the document.
Level Two CDA models the fine-grained observations and instructions within
each heading through a set of RIM Act classes. With Level Two, it is possible
to constrain both structure and content of a document by means of a template
and thereby increase interoperability since the receiver “knows what to ex-
pect". However, a completely structured document where the semantics of
each information entity is specified by a unique code will only be possible with
Level Three providing for machine processing.
IHE Cross-Enterprise Document Sharing (XDS)
The basic idea of IHE XDS is to store healthcare documents in an ebXML reg-
istry/repository to facilitate their sharing. IHE XDS is not concerned with do-
cument content; it only specifies metadata to facilitate discovery of documents.
In the IHE XDS integration profile, a group of healthcare enterprises that agree
to work together for clinical document sharing is called the “Clinical Affinity
Domain". Such institutes agree on a common set of policies such as how the
patients are identified, the consent is obtained, the access is controlled, and
the common set of coding terms to represent the metadata of the documents.
As already mentioned, IHE XDS handles healthcare documents in a content
neutral way, that is, a document may include any type of information in any
standard format such as simple text, formatted text (e.g., HL7 CDA Release
One), images (e.g., DICOM) or structured and vocabulary coded clinical in-
formation (e.g., CDA Release Two, CEN ENV 13606 or DICOM SR). Given
this, to ensure the interoperability between the document sources and the do-
cument consumers, the clinical affinity domains also agree on the document
format, the structure and the content.
D3.2: Harmonisation, Interoperability and Standard Page 26 of 38
IHE Cross-Enterprise Sharing of Medical Summaries
Cross-Enterprise Sharing of Medical Summaries (XDS-MS) is a mechanism to
automate sharing of medical summaries between care providers. The main
characteristics of XDS-MS are as follows:
• XDS-MS Profile uses actors and transactions of IHE XDS. Only docu-
ment types used in XDS-MS are more specific medical summaries.
• Two types of medical summary content are currently specified: one for
episodic care, the other for collaborative care.
• XDS-MS specifies content of medical summaries by building and fur-
ther constraining the HL7 Clinical Document Architecture (CDA) stan-
dard and Care Record Summary (CRS) CDA implementation guides.
• Document sources provide an XML style sheet to render the content of
the medical summary document.
• Medical summaries are shared within predefined domains (called XDS
Affinity Domains) by storing the medical summaries in Registry Reposi-
tories. Note however that IHE also plans the federated XDS Affinity
domains. Therefore, the exchange of medical documents will not be
restricted to XDS Affinity Domains in the near future.
• Registry/Repository architectures facilitate the discovery of the medical
summaries in an XDS Affinity Domain.
IHE Retrieve Information for Display (RID)
Retrieve Information for Display (RID) provides a simple and rapid read-only
access to patient-centric clinical information that is located outside the user's
current application. It supports access to existing persistent documents in well-
known presentation formats such as CDA Level One, PDF and JPEG. It also
provides access to specific key patient-centric information such as allergies,
current medications, and summary of reports for presentation to a clinician.
IHE defined RID as a Web service by providing its WSDL (Web Service De-
scription Language) description with a binding to HTTP GET.
D3.2: Harmonisation, Interoperability and Standard Page 27 of 38
Appendix III: Standards list
This compilation collects the most important standards in all technical and
non-technical areas of healthcare.
Category Organisation Name Description
Specification for transferring neuro-
Electronic Health physiologic data between independ-
Record ent computer Systems. Defines how
vital signals such as EEG should be
stored. It has not been used in fa-
vour of VITAL.
Standard guide for description of
reservation, registration, admission,
discharge, transfer systems for Elec-
tronic Health Record (EHR) Sys-
tems. This guide identifies the mini-
mum information capabilities needed
by an ambulatory care system or a
resident facility R-ADT system.
Standard guide for content and
structure of the Electronic Health
Record (EHR). This guide covers all
types of healthcare services, includ-
ing those given in acute care hospi-
tals, nursing homes, skilled nursing
facilities, home healthcare, and spe-
cialty care environments as well as
ambulatory care. They apply both to
short term contacts (for example,
emergency rooms and emergency
medical service units) and long term
contacts (primary care physicians
with long term patients).
Standard guide for view of emer-
gency medical care in the computer-
ized-based patient record. It ad-
dresses the identification of the in-
ASTM E1744-98 formation that is necessary to docu-
ment emergency medical care in a
computerized patient record that is
part of a paperless patient record
An object-oriented model for regis-
tration, admitting, discharge, and
transfer functions in computer-based
patient record Systems. Details the
objects that make up the reserva-
ASTM E1715-01 tion, registration, admitting, dis-
charge, and transfer functional do-
main of the computer-based record
of care. It is intended to amplify
guide E1239 with an object-oriented
D3.2: Harmonisation, Interoperability and Standard Page 28 of 38
Category Organisation Name Description
Standard guide for properties of a
Universal Healthcare Identifier. This
guide covers a set of requirements
outlining the properties of a national
system creating a universal health
care identifier (UHID). Use of the
UHID is expected to be limited to the
population of the United States.
This standard is the European con-
Imaging tribution to the well-known DICOM.
MEDICOM Used in imaging communication
(EN12052) (see DICOM). EN 12052 supersedes
the former ENV 12052, ENV12623
Profiles for medical image inter-
change. Provides the set of profiles
for a given user scenario. Defines
greyscale, colour, volumetric and
time sequences. CR 12069 is not a
mandatory standard, it is a report.
Proposes a classification for five
FDA 63 FR 64998 types of medical image management
Standard for electronic filing of me-
MDS A 0001 dical images with security, compati-
– 0017 bility and reproducibility. It is a Japa-
DICOM (Digital Imaging and COM-
munications in Medicine) defines the
coding of medical images, the proto-
cols of interchange between both
sides and a security policy to hide
NEMA information from third people. Used
in computer tomography, image
archives, telediagnostic, EEG, ECG.
DICOM 3.0 has added waveform
support to allow EEG and ECG in-
Medical record, image, text - infor-
mation Exchange. It is related to the
information exchange between dif-
ferent medical providers. The previ-
ous version used SGML. It is a
Healthcare Information System Ar-
Infrastructure chitecture (HISA). Describes the
Architecture Healthcare Information System Ar-
chitecture (HISA), which is a descrip-
tion of the middleware layer used in
healthcare. Used in implementations
in Denmark. It is described with dia-
D3.2: Harmonisation, Interoperability and Standard Page 29 of 38
Category Organisation Name Description
Healthcare Information Framework
(HIF). Creates a basic framework to
guide healthcare informatics devel-
opers. It is a first step in standardis-
CEN ENV12443 ing the architectures that will support
the latest approaches to the delivery
of computer systems such as are
required to provide the global infor-
Identification, administrative, and
common clinical data structure for
ICDs. This standard proposes a
standardised framework for data
structures used with respect to In-
termittently Connected Devices
(ICDs). An ICD is a device that sto-
res and transmits person related
data in such a fashion that the origi-
nator of the information may not
receive confirmation of receipt by the
Interoperability of Healthcare Sys-
tems and Networks. Addresses the
interoperability of healthcare sys-
tems and networks. Part 2 of the
standard is related to real-time e-
Provides interoperability of health-
Knowledge Man- care multimedia report systems. It is
agement not mandatory. It is a recommenda-
Electronic healthcare record com-
munication. Purposes a scheme to
define a healthcare record in order
the information is recognizable and
understandable in different applica-
tions. Used in EHR products. It is
CEN ENV13606 divided in four parts:
• Part 1: Extended architec-
• Part 2: Domain term list
• Part 3: Distribution rules
• Part 4: Messages for the ex-
change of information.
Standard guide for individual rights
regarding health information. This
guide outlines the rights of individu-
als, both patients and providers,
agement and ASTM E1987-98
regarding health information and
recommends procedures for the
exercise of those rights. This guide
is intended to amplify Guide E1869.
Medical Device ography. This standard has been
Communication CEN ENV1064 taken up worldwide, not only by Eu-
ropean countries. Used in ECG Ma-
D3.2: Harmonisation, Interoperability and Standard Page 30 of 38
Category Organisation Name Description
Medical Data Interchange: HIS/RIS-
PACS and HIS/RIS. Describes the
interchange of sanitary data.
HIS/RIS-PACS and HIS/RIS.
Interoperability of patient connected
medical devices. The standard sets
up the basis of interoperability
among patient connected devices
taking account of VITAL standard to
CEN ENV13735 achieve device and signal interop-
erability. Used in medical devices.
This standard and VITAL standard
are designed to work together. Each
one specifies a level of interoperabil-
Point-of-care medical device com-
munication. Efforts are underway to
IEEE add standards for enabling internet-
working of medical devices across a
Point-of-care medical device com-
IEEE munication – Application Profiles –
1073.2.1.2 MIB Elements. MIB Element defini-
tions from the revised DIM standard.
Medical Device Communications –
Transport Profile – IrDA Based –
Cable Connected. Describes the
IrDA-based, RS-232, cable con-
nected transport between devices
connectivity. It also set up the basis
IEEE for firmware upgrades for medical
devices. Used in medical devices.
This new transport profile offers a
key advantage in fostering imple-
mentation and adoption of the IEEE
1073 Medical Information Bus Stan-
Point-of-care medical device com-
munication – Application profile –
Optional package, remote control.
ISO11073- Describes an optional application
20301 profile optional packages for remote
control. Some functions are similar
or complement the European stan-
HL7 Version 2.5. Old HL7 standards
Messages were focused on medical information
exchange. With the addition of XML
support, multimedia capabilities are
now reliable. Used in medical infor-
mation Exchange. Better support for
imaging has been introduced com-
pared with the previous ones.
D3.2: Harmonisation, Interoperability and Standard Page 31 of 38
Category Organisation Name Description
Standard Specification for Transfer-
ring Digital Waveform Data Between
Independent Computer Systems.
ASTM E1713-95 This standard defines transferring
digital waveform data between inde-
pendent computer systems. It is also
an ANSI approved standard.
Messages for the exchange of in-
formation on medicine prescriptions.
Specifies a message, called pre-
scription dispensing report message,
CEN ENV13607 containing information about pre-
scription items that is sent from the
dispensing agent to any other party
that is legally permitted to receive
Messages for the exchange of
healthcare administrative informa-
tion. Specifies messages for the
exchange of healthcare administra-
tive information to provide safe, effi-
cient and effective healthcare deliv-
ery within hospitals and in primary
Messages for exchange of labora-
tory information. Provides a com-
plete implementable specification of
the laboratory messages by imple-
mentation guidelines to supplement
CEN ENV1613 the message definitions. It also pro-
vides comprehensive data and struc-
tured tables. These coding schemes
are commonly used to provide pre-
cise and unambiguous representa-
tion of the data.
Messages for Patient Referral and
Discharge. It refers to referral and
discharge but also covers the re-
quest for specialist services and the
reports by the specialist service pro-
vider, including clinic letters and
discharge summaries. Graphical or
image information that forms part of
a request for or report of a specialist
healthcare service is excluded.
Request and Report Messages for
Diagnostic Services Departments. It
provides the description of the scope
of the messages and its functionality
and implementation guidelines for
different scenarios. Used in X-rays,
CAT, NMR, ultrasound scans,
ECGs, lung-function tests, anatomic
pathology and nuclear medicine.
The scope is limited to character-
based messages, therefore is not
related to multimedia.
D3.2: Harmonisation, Interoperability and Standard Page 32 of 38
Category Organisation Name Description
Interoperability and compatibility in
messaging and communication stan-
dards -- Key characteristics. De-
scribes a set of key characteristics to
achieve interoperability and com-
patibility in trusted health information
interchange between communicant
ISO application systems. The key char-
acteristics describe inter-application
interoperability needs of the health-
care community, in particular the
subject of care, the healthcare pro-
fessional, the healthcare provider
organization, its business units and
the integrated data.
Clinical analyser interfaces to labo-
ratory information Systems. Speci-
fies general messages for electronic
information exchange between ana-
lytical instruments and laboratory
information systems within a clinical
Medical Device ISO ISO18812
laboratory. Covers the specification
of messages used by communicat-
ing parties and the syntax in which
they are communicated. It does not
cover the transport mechanisms
used for the message interchange.
Safety and Security Related Soft-
Security ware Quality Standards for Health-
care. They propose several quality
AENOR norms related to security and protec-
tion in e-Health software. It associ-
ates the system type with the appro-
priate security measures.
Standard Practice for Healthcare
Certificate Policy. Addresses the
policy for digital certificates that sup-
port the authentication, authoriza-
tion, confidentiality, integrity, and
non-repudiation requirements of
ASTM E2212-02 persons and organizations that elec-
tronically create or transact health
information. There are 3 types of
certificate: one for computerized
entities, one for individual person
and the last one for clinical individu-
Standard Guide for Properties of
Electronic Health Records and Re-
cord Systems. The standard defines
ASTM a document structure for use by
electronic signature mechanisms
and the characteristics of the elec-
tronic signature itself.
D3.2: Harmonisation, Interoperability and Standard Page 33 of 38
Category Organisation Name Description
Specification for management of the
confidentiality and security of dicta-
tion, transcription, and transcribed
health records. It describes certain
steps that shall be taken by those
involved in the processes of dictation
ASTM E1902-02 and transcription of healthcare do-
cumentation. It also seeks to identify
certain dictation and transcription
practices that may increase the risks
of infringing on privacy and violating
security of healthcare documenta-
Standard guide on security frame-
work for healthcare information.
Describes a framework for the pro-
tection of healthcare information. It
ASTM E2085-00a addresses both storage and trans-
mission of information. It makes use
of well-known security algorithms
such as SHA-1, triple-DES and oth-
Standard guide for information ac-
cess privileges to health information.
This guide covers the process of
granting and maintaining access
ASTM E1986-98 privileges to health information. It
directly addresses the maintenance
of confidentiality of personal, pro-
vider, and organizational data in the
Standard Specification for Authenti-
cation of Healthcare Information
Using Digital Signatures. This speci-
fication covers the use of digital sig-
natures to provide authentication of
healthcare information, as described
in Guide E 1762. It describes how
the components of a digital signature
system meet the requirements
specified in Guide E 1762. This in-
cludes specification of allowable
signature and hash algorithms,
management of public and private
keys, and specific formats for keys,
certificates, and signed healthcare
Algorithm for Digital Signature Ser-
vices in Health Care. Defines the
algorithm used for digital signatures
in medicine information exchange. It
is required to achieve legal accept-
ability of the information exchange.
UNE-ENV 12388 is the Spanish
D3.2: Harmonisation, Interoperability and Standard Page 34 of 38
Category Organisation Name Description
Security for healthcare Communica-
tions. Defines concepts for secure
CEN ENV13608 systems. Besides that, secure data
objects and secure data channels
Management and security of authen-
tication by passwords. It addresses
the management and security of
authentication by passwords. Some-
times is mandatory to fulfil legal is-
Standard Specification for Health-
Standards Meth- care Document Formats. Defines
odology requirements for the headings, ar-
rangement, and appearance of sec-
tions and subsections when used
within healthcare documents. Use of
this specification in conjunction with
XML DTDs and the EHR (Electronic
Health Records) would further en-
hance efficiency in time and cost.
Standard specification for clinical
XML DTDs in healthcare. This guide
provides a compendium of informa-
tion for the use of E2183 XML DTDs
ASTM E2185-02 within health care. This guide de-
scribes design considerations, the
architecture of the DTDs, and im-
plementing systems using the E2183
Standard guide for identification and
establishment of a quality assurance
program for medical transcription. It
establishes a quality assurance pro-
gram for dictation, medical transcrip-
tion, and related processes. Quality
ASTM E2117-00 assurance is necessary to ensure
the accuracy of healthcare docu-
mentation. This guide establishes
essential and desirable elements for
quality healthcare documentation,
but it is not purported to be an ex-
Registration of information objects
Terminology used for EDI in healthcare. Defines
the registration of information ob-
jects used for EDI in healthcare for
the purpose of information inter-
change related to healthcare. It has
CEN ENV12537 two parts.
• Part 1: The Register
• Part 2: Procedures for the
registration of information
objects used for electronic
data interchange (EDI) in
D3.2: Harmonisation, Interoperability and Standard Page 35 of 38
Category Organisation Name Description
Medical Informatics Vocabulary (MI-
Voc). Defines the Medical Informat-
ics Vocabulary, which is a founda-
CEN env 12017
tion for the development of a vo-
cabulary of terms used in Medical
Categorical structures of systems of
concepts - Model for representation
of semantics. The standard provides
the vocabulary and the guidelines to
describe the categorical structure of
a concept system: the structure con-
sists in practice of a list of involved
categories with reference to the
available authoritative sources for
detailed value. Medical Informatics
deals with a great number of large,
overlapping coding systems that are
facing each other and conflicting in
the coming Integrated Healthcare
Information Environment. This stan-
dard tries to solve these conflicts.
Time Standards for Healthcare Spe-
cific Problems. Provides a set of
basic entities, with precisely defined
CEN ENV12381 properties and interrelationships
among them, that is sufficient to
allow an unambiguous representa-
tion of time-related expressions.
Logical Observation Identifiers Na-
mes and Codes. The purpose of the
LOINC database is to facilitate the
exchange and pooling of results,
such as blood haemoglobin, serum
potassium, or vital signs, for clinical
Regenstrief care, outcomes management, and
Institute research. Used in US healthcare
Framework. The Regenstrief Insti-
tute provides mapping utility called
the Regenstrief LOINC Mapping
Assistant (RELMA) to facilitate
searches through the LOINC data-
Specification for relationship be-
User Interfaces tween a person and a supplier of an
electronic personal health record.
This specification covers the rela-
tionship between a consumer, or-
ganization or custodian and a man-
aging organization (such as a web
site or other organization). This
specification will not address per-
sonal health records (PCHR) that
are created and managed by pa-
tients on paper records.
D3.2: Harmonisation, Interoperability and Standard Page 36 of 38
Category Organisation Name Description
VITAL specifies a common repre-
sentation of vital signs information. It
VITAL is non-device dependent. Used in
(ENV13734) medical device communication. It
was specially created for real time
Clinical Context Object Workgroup
Version 1.5. CCOW V1.0 defined the
overall technology-neutral context
management architecture (CMA), a
core set of data definitions, rules for
application user interfaces, and the
translation of the CMA to Microsoft’s
COM/ActiveX technology. This ver-
sion also support technology map-
ping to SOAP.
Ergonomics requirements for office
work with visual display terminals. Its
ISO ISO9241 main purpose is to set up a user-
friendly environment for general
applications (including e-Health).
Table 02 – Standards list
D3.2: Harmonisation, Interoperability and Standard Page 37 of 38
 DVB-Scene. Tune into Digital Convergence. The Standard for the Digital
World. Edition No. 16 December 2005.
 Identification of different types of standards for domain-specific interop-
erability. Robert A. Stegwee and Boriana D. Rukanova. Department of
Business Information Systems. University of Twente.
 Health Level Seven. EHR Interoperability Work Group. February 7,
2007. Patricia Gibbons, Noam Arzt, PhD, Susie Burke-Beebe, Chris
Chute, MD DrPH, Gary Dickinson, Tim Flewelling, Thomas Jepsen, Don
Kamens, MD, Joanne Larson, John Ritter, Michael Rozen, MD, Sherry
Selover and Jean Stanford.
 Key Issues of Technical Interoperability Solutions in healthcare and the
RIDE Project. Asuman Dogac, Tuncay Namli, Alper Okcan, Gokce Lale-
ci, Yildiray Kabak and Marco Eichelberg. Software R&D Center, Dept. of
Computer Eng., Middle East Technical University 06531, Ankara, Turkey
 The EHR (Electronic Health Records) Standards: an Overview. Gerard
Freriks. EuroRecord, October-2006.
 Continua: An Interoperable Personal Healthcare Ecosystem. Randy Car-
roll, Rick Cnossen, Mark Schnell, and David Simons. Vol. 6, No. 4. Oc-
tober–December 2007. IEEE Computer Society.
 System Interoperability Study for Healthcare Information System with
Web Services. J.K. Zhang and W. Xu, D. Ewins. Centre for Biomedical
Engineering, School of Engineering, Surrey University, UK. Journal of
Computer Science 3 (7): 515-522, 2007.ISSN 1549-3636.
 Towards Plug-and-Play Interoperability for Wireless Personal Healthcare
Systems. L. Schmitt, T. Falck, F. Wartena, and D. Simons. Philips Re-
 Interoperability and Security in Wireless Body Area Network Infrastruc-
tures. Steve Warren, Jeffrey Lebak, Jianchu Yao, Jonathan Creekmore,
Aleksandar Milenkovic and Emil Jovanov. Department of Electrical &
Computer Engineering, Kansas State University, Manhattan, KS, USA.
 IST- 27074 SAPHIRE. “Intelligent Healthcare Monitoring based on a
Semantic Interoperability Platform”. Strengthening the Integration of the
ICT research effort in an Enlarged Europe Focus: healthcare. Develop-
ing Security Mechanisms for sensor networks.
D3.2: Harmonisation, Interoperability and Standard Page 38 of 38