ICT PSP Accessibility, Ageing and Social Integration …v1.0+RH... · The information in this...
-
Upload
vuongtuong -
Category
Documents
-
view
215 -
download
0
Transcript of ICT PSP Accessibility, Ageing and Social Integration …v1.0+RH... · The information in this...
The information in this document is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability.
ICT PSP – Accessibility, Ageing and Social Integration Programme
REgioNs of Europe WorkINg toGether
for HEALTH (Grant Agreement No 250487)
Document D5.5
Technical recommendations for further
deployment
Version 1.0 Work Package: WP5
Version & Date: v1.0 / 18th December 2013
Deliverable type: Report
Distribution Status: Public
Author: Bridget Moorman
Reviewed by: Michael Strübin, John Oates
Approved by: Marco d'Angelantonio
Filename: D5.5 v1.0 Renewing Health Technical recommendations for project implementation
Abstract
This document provides the final status of the Renewing Health Pilot projects from a
technical and standards perspective and an analysis of their technical architectures. In
addition, it provides the industry status regarding available products which are Continua
certified to conform to IHE-PCD DEC and IHE-PCD IDCO. Information from each of the pilot
site demonstrations at three separate industry events is also included.
Key Word List
Standards
D5.5 Technical recommendations for further
deployment
Public Page 2 of 77 v1.0 / 18th December 2013
Executive Summary
This report provides the final status of the Renewing Health project from a technical
and industrial viewpoint. It describes the Renewing Health pilot technical
architectures, equipment and standards currently in use, as well as the industry
status as of August 2013.
The final technical analysis of those Renewing Health pilot projects yielded a
number of findings of relevance to the project related to the standards situation, the
industry offers, and the state of the field overall:
Few data transmissions followed standardised electronic protocols.
Proprietary systems seem the systems of choice. Some data is transmitted
by voice calls and manual data entry.
There were few standards-compliant products on the market when the project
began. Many pilots used mobile and smart phones to act as data hubs;
however, the implementation of standards on mobile platforms had barely
begun. By the end of the project, Continua was poised to offer mobile platform
specific guidelines, and the GSMA had greatly expanded their mHealth
offerings and guidance to mobile network operators.
The market for telemedicine products (in Europe and beyond) is still
fragmented, often with different companies operating in different countries and
different market leaders depending on the country (see Appendix B for a
“state of the market”). Solutions are still offered as end-to-end systems. There
are several possible reasons for this. It is clear that customer demand for
standards and interoperability is still weak, and has not featured as a
standard, mandatory requirement in procurements. Nevertheless, several of
the pilot sites realised over the length of the project that specifying or requiring
standards at the interface between the remote monitoring service functionality
and the healthcare enterprise medical record eases the ability for the data to
flow between those two entities.
Many of the healthcare organisations came to the conclusion that outsourcing the
remote monitoring function either at the entry or exit to/from a regional telehealth
centre providing aggregation, analysis and data filtering abilities allowed them to
concentrate on providing healthcare rather than system integration over the data
transmission path. This was due to several issues they encountered with system
integration at the medical device and gateway interface.
Achieving better interoperability and scalability of services were beyond the power,
scope and time frame of the Renewing Health project. However, the project helped
push in the right direction. The Industry Advisory Board (IAB) recommended a
concerted effort among all players in the project to help. Additionally, several of the
pilot sites shared their findings and recommendations with the follow-on project
United4Health:
For healthcare providers: to support the advance of standards by
expressing their preference for standards-compliant products by purchasing
them. Where appropriate, this may include procurement documents stating a
preference for the use of specific standards and guidelines. Where possible,
the requirement for interoperability with other existing systems should also be
required. Where appropriate standards or guidelines are not available, remote
D5.5 Technical recommendations for further
deployment
Public Page 3 of 77 v1.0 / 18th December 2013
monitoring pilots should contract with such suppliers who commit to
convergence towards standards compliance.
For industry: to bring products to market that meet guidelines and protocols
where they exist, and to accelerate the development of guidelines and
protocols where they do not (especially for those use cases that lend
themselves to remote monitoring). Moreover, to understand that either at the
interface between the gateway and aggregation point for analysis, or at the
interface between the aggregation point for analysis and the healthcare
enterprise, messaging standards and eventually data standards will be
demanded. Telehealth or remote monitoring system suppliers will need to
decide if they will invest in implementing standards at the data source or
converting their information to standard formats at the interface to the
customer. Lastly, they may be asked to integrate not just technology but
clinical services on their side of the interface point. That interface point will be
at the output of either a home gateway or a telehealth service centre.
For the remote monitoring project and funders: to be realistic about the
state of the market(s), the status of applicable standards, and the industry’s
capacity to deliver products that allow for subsequent scaling up within a
project’s time frame.
The IAB has already begun to address and follow up these recommendations. To
assist the pilots during procurement, a sample technical specification was
developed for inclusion with procurement documents (see D5.1). It specifies the
use of Continua and IHE-PCD promulgated standards.
D5.5 Technical recommendations for further
deployment
Public Page 4 of 77 v1.0 / 18th December 2013
Change History
Version History:
0.1 15th July 2013
0.2 30th July 2013
0.3 12th August 2013
0.4 25th August 2013
0.5 11th September 2013
0.6 15th November 2013
0.7 17th December 2013
1.0 18th December 2013
Version Changes
0.1 Initial draft
0.2 Finnish, Italian and German updates added
0.3 Initial review for formatting and consistency
0.4 Edits based on initial review comments
0.5 Edits for format and content, sent to IAB for review
0.6 IAB feedback, final edits.
0.7 Edits from last review
1.0 Version for release
Outstanding Issues
None
D5.5 Technical recommendations for further
deployment
Public Page 5 of 77 v1.0 / 18th December 2013
Table of Contents
EXECUTIVE SUMMARY 2
CHANGE HISTORY 4
TABLE OF CONTENTS 5
1. INTRODUCTION 9
1.1 Purpose of this document 9
1.2 Disclaimer 9
1.3 Glossary 9
2. BACKGROUND 11
2.1 Renewing Health 11
2.2 The Industry Advisory Board 11
3. THE RENEWING HEALTH PROJECT 14
3.1 Overview and generic technical architecture 14
3.2 Austria 17
3.3 Denmark 19 3.3.1 Patient Briefcase 19 3.3.2 Hospital workstation 20 3.3.3 Data transmission and storage 20 3.3.4 Integration with other applications and the IT infrastructure 20 3.3.5 Diabetes pilot 21 3.3.6 COPD pilot 21
3.4 Finland 23 3.4.1 Blood pressure meter 23 3.4.2 Blood glucose meter 24 3.4.3 Weight scale 24 3.4.4 Pedometer 24 3.4.5 Mobile phone 24 3.4.6 Web PHR application 24
3.5 Germany 25
3.6 Greece 27
3.7 Italy 28 3.7.1 Hardware at patient’s home 29 3.7.2 Region eHealth Centre 33 3.7.3 General System Description for Remote Monitoring Support 33 3.7.4 Remote Monitoring of CVD: Implantable Devices 37
3.8 Norway 38
3.9 Spain 38
3.10 Sweden 39
D5.5 Technical recommendations for further
deployment
Public Page 6 of 77 v1.0 / 18th December 2013
4. SUMMARY AND ANALYSIS 42
4.1 Parameters and data types collected (updated from D5.1) 42
4.2 Devices and interfaces (updated from D5.1) 43
4.3 Standards 47
4.4 Local issues 51 4.4.1 Germany 51 4.4.2 Norway 51 4.4.3 Greece 51 4.4.4 Spain 52 4.4.5 Denmark 52 4.4.6 Finland 52 4.4.7 Italy 53
4.5 Industry 53
5. IAB INDUSTRY OUTREACH: THE SHOP TALKS 55
6. CONCLUSIONS AND RECOMMENDATIONS 56
APPENDIX A - REFERENCES 59
APPENDIX B - STATE OF THE INDUSTRY 60
B.1 Continua Certified Products 62
B.2 IHE-PCD 01 or IDCO Compliant Companies 62
APPENDIX C - TECHNICAL SPECIFICATION FOR PROCUREMENT 64
APPENDIX D – PILOT TECHNICAL DEMONSTRATIONS 67
D.1 Finland Pilot Demo 67
D.2 Norway Pilot Demo 69
D.3 Italy Pilot Demo 70
D.4 Spain Pilot Demo 71
D.5 Sweden Pilot Demo 73
D.6 Denmark Pilot Demo 74
D.7 Austria Pilot Demo 75
D.8 Germany Pilot Demo 76
D.9 Greece Pilot Demo 77
TABLE OF TABLES
Table 1: Clusters and Pathologies by Region/Country ..................................................... 14
Table 2: Parameters and Data Types by Pathology and Country .................................... 42
Table 3: Device and Interfaces (updated) .......................................................................... 43
Table 4: Standards Comparison .......................................................................................... 48
Table 5: Leading Telehealth Vendors listed by Country - 2008 ....................................... 61
D5.5 Technical recommendations for further
deployment
Public Page 7 of 77 v1.0 / 18th December 2013
Table 6: Telehealth Vendors listed by Country - 2013 ..................................................... 61
TABLE OF FIGURES
Figure 1: Generic Remote Monitoring System Diagram (Continua) ............................... 15
Figure 2: IHE-PCD 01 Device Enterprise Communication (DEC) .................................... 16
Figure 3: Austrian Telehealth Technical Architecture Diagram ...................................... 17
Figure 4: Austrian Medical Devices for Remote Monitoring ............................................ 18
Figure 5: Austrian Mobile Data Flow Architecture – Part 1 .............................................. 18
Figure 6: Austrian Mobile Data Flow Architecture – Part 2 .............................................. 19
Figure 7: Danish Telehealth Technical Architecture Diagram – Diabetes ..................... 21
Figure 8: Danish Telehealth Technical Architecture Diagram – COPD .......................... 22
Figure 9: Danish Telecommunications Architecture Diagram – COPD and
Diabetes ........................................................................................................... 22
Figure 10: Finnish Teleheath Technical Architecture Diagram....................................... 23
Figure 11: German Telehealth Technical Architecture Diagram (COPD and
Diabetes) .......................................................................................................... 25
Figure 12: German Telehealth Technical Architecture Diagram with mobile
phone used as Communication Hub ........................................................... 26
Figure 13: Greek Telehealth Technical Architecture Diagram ........................................ 27
Figure 14: Depiction of CardGuard Gluco Module used with mobile phone
(Greece) ........................................................................................................... 28
Figure 15: Italian Telehealth Technical Architecture Diagram for telemonitoring
service for diabetes, COPD, CVD and multi-pathology clusters .............. 34
Figure 16: Italian Telehealth Technical Architecture Diagram for nurse-assisted
remote monitoring service of COPD ............................................................ 35
Figure 17: Italian Telehealth Architecture for CVD Telehealth and Telecare ................ 36
Figure 18: Italian Telehealth Architecture for remote monitoring of multi-
pathology – includes all chronic disease monitoring pathways .............. 36
Figure 19: Italian Telehealth Technical Architecture Diagram for remote ICD
monitoring ....................................................................................................... 37
Figure 20: Norwegian Telehealth Technical Architecture Diagram ................................ 38
Figure 21: Spanish Technical Architecture Diagram I ...................................................... 39
Figure 22: Spanish Technical Architecture Diagram II – LinkCare specifics ................. 39
Figure 23: Sweden Telehealth internal Technical Architecture Diagram ...................... 40
Figure 24: Sweden device specific Technical Architecture............................................. 41
Figure 25: Sample remote monitoring system .................................................................. 64
Figure 26: Finland’s Equipment for Technical Demo: mobile phone and blood
pressure measurement device ..................................................................... 68
Figure 27: Finland’s Personal Health Record application showing physiological
measurements ................................................................................................ 68
Figure 28: Niklas Andersson, Norway, showing mobile phone interface ...................... 69
Figure 29: Niklas Andersson, Norway, demonstrating glucometer measurement ....... 70
Figure 30: Ricardo Maderna, Italy, demonstrating touchscreen interface with
blood pressure device ................................................................................... 71
D5.5 Technical recommendations for further
deployment
Public Page 8 of 77 v1.0 / 18th December 2013
Figure 31: Italian pilot technical equipment: touchscreen interface, blood
pressure measurement device and pulse oximeter ................................... 71
Figure 32: Spanish medical devices used in their pilot demonstration: blood
pressure measurement device, pulse oximeter, mobile phone and
laptop computer ............................................................................................. 72
Figure 33: View of Spanish mobile phone interface showing menu of action
items available for patient ............................................................................. 72
Figure 34: Mr Isaksson during Swedish presentation showing medical devices
used.................................................................................................................. 73
Figure 35: Swedish remote monitoring architecture for EKG ......................................... 73
Figure 36: Zenicor EKG Device used for Swedish remote monitoring
demonstration ................................................................................................. 74
Figure 37: Danish demonstration of spirometric measurement using video
teleconferencing coaching ........................................................................... 74
Figure 38: Claus Duedal Pederson demonstrating Danish MediSat ‘suitcase’ ............. 75
Figure 39: Austrian presentation regarding use of mobile phone gateway with
medical device ................................................................................................ 75
Figure 40: Austrian demonstration of remote blood pressure measurement ................ 76
Figure 41: Health Insight Solutions glucometer, mobile phone and pulse
oximeter used for remote monitoring demo – RH Germany ..................... 76
D5.5 Technical recommendations for further
deployment
Public Page 9 of 77 v1.0 / 18th December 2013
1. Introduction
1.1 Purpose of this document
The Industrial Advisory Board (IAB) was asked to analyse the technological
platforms used in the current project, to provide advice on the evolution of current
services and their integration and convergence towards standard platforms, and to
monitor progress. Twice in the course of the project the IAB was to deliver a report
with technical recommendations. This present document is the second: D5.5
“Technical Recommendation for Further Implementation”.
The report describes the final architecture baseline of each of the pilot sites
regarding their technical architecture, and devices, infrastructure and standards
used. It documents the current state of the industry. It also contains comparisons
and changes to the pilot site architectures, any issues and challenges they
encountered with their systems, and system demonstration highlights that the pilot
sites provided during their presentations at three different industry events and IAB
meetings.
1.2 Disclaimer
Before publication, this document was reviewed by the Continua Technical Working
Group Chair, the IHE Europe representative to the Industry Advisory Board, as well
as the Renewing Health IAB members. It was also reviewed by COCIR, Eucomed,
and the GSM Association, the three industry associations of the IAB.
Possible inaccuracies of information are the responsibility of the project/study team.
This report reflects solely the views of its authors. The European Commission is not
liable for any use that may be made of the information contained therein.
1.3 Glossary
ADSL Asymmetric Digital Subscriber Line
AHD Application Hosting Device
BT Bluetooth
CDA2 Clinical Document Architecture version 2
CHA Continua Health Alliance
COPD Chronic Obstructive Pulmonary Disease
CTI Computer telephony integration
CVD Cardiovascular Diseases
DHDN Danish Health Data Network
EAI Enterprise Application Integration
EDI Electronic Data Interchange
EHR Electronic Health Record
D5.5 Technical recommendations for further
deployment
Public Page 10 of 77 v1.0 / 18th December 2013
EMR Electronic Medical Record
EKG Electrocardiography
ESB Enterprise Service Bus
Glucometer A medical device for determining the concentration of glucose in
the blood
GPRS General Packet Radio Service
HDP Health Devices Profile
HIS Health Information System
HRN Health Reporting Network
IAB Industry Advisory Board
IHE Integrating the Healthcare Enterprise
ITI Information Technology Infrastructure (in IHE model) domain
LAN Local Area Network
PAN Personal Area Network
PCC Patient Care Coordination (In IHE model) domain
PCD Patient Care Device (in IHE model) domain
Pedometer A device that counts each step a person takes and can calculate
the distance travelled
PHR Personal Health Record
PTSN Public Telephone Switched Network
Pulse
oximeter
A medical device that indirectly monitors the pulse rate and oxygen
saturation of a patient's blood
SOA Service Oriented Architecture
Spirometer A device for measuring the volume of air exhaled by the lungs
UMTS Universal Mobile Telephone Service
VPN Virtual Private Network
WAN Wide Area Network
XDS.b Cross-Enterprise Document Sharing-b IHE profile
XDW Cross Enterprise Workflow IHE profile
XTHM-WD Cross Enterprise TeleHome Monitoring Workflow IHE profile
D5.5 Technical recommendations for further
deployment
Public Page 11 of 77 v1.0 / 18th December 2013
2. Background
2.1 Renewing Health
Renewing Health is a European project, co-funded by the European Commission,
that has implemented large-scale real-life test beds for the validation and
subsequent evaluation of innovative telemedicine services, using a patient-centred
approach and a common rigorous assessment methodology. It involves nine
regions in the implementation and upgrade of existing health-related ICT services
for the telemonitoring and treatment of chronic patients suffering from diabetes,
COPD or cardiovascular diseases. The nine participating regions are:
Austria: Carinthia (Land Kärnten)
Denmark: Region of Southern Denmark (Syddanmark)
Finland: South Karelia (Etelä-Karjala)
Germany: Land Berlin
Greece: Central Greece (Στερεά Ελλάδα)
Italy: Veneto Region (Vèneto)
Norway: Northern Norway (Nord-Norge)
Spain: Catalonia (Catalunya)
Sweden: Norrbotten County (Norrbottens län)
In the followings chapters, each pilot project will be referred to by their country
name. (More information about the consortium partners in each region can be found
on the project website at www.renewinghealth.eu). Additional partners of the
Consortium that serve in an advisory function include: The European Patients
Forum (EPF), the European Health Telematics Association (EHTEL) and the
Continua Health Alliance (CHA). The latter is in charge of managing the Industry
Advisory Board.
2.2 The Industry Advisory Board
Although integration of the service solutions at regional level is the highest priority
for the Project partners, the use of international standards and the progressive
convergence towards common interoperable architectures was equally sought to
prepare and facilitate their subsequent scaling up at national and European levels.
To facilitate the input and advice from industry, Continua Health Alliance (CHA) was
asked to join the Consortium.
Continua Health Alliance is a non-profit, open industry coalition of healthcare and
technology companies joining together in collaboration to improve the quality of
personal healthcare. CHA is dedicated to establishing a system of interoperable
personal health solutions with the knowledge that extending those solutions into the
home fosters independence, empowers individuals and provides the opportunity for
truly personalised health and wellness management. CHA was founded in 2006 and
has more than 200 members including multinational companies and SMEs. CHA
was legally incorporated in Belgium in 2008. (More information can be found at
www.continuaalliance.org.)
CHA was asked to operate an Industry Advisory Board of experts with competence
in the management of clinical data, standards, open sources, business trends in the
D5.5 Technical recommendations for further
deployment
Public Page 12 of 77 v1.0 / 18th December 2013
Personal Health System sector, etc., and to manage the communication and the
knowledge transfer between the IAB and the project team and pilots. Specifically
the IAB is tasked with:
“[…] advising the Renewing Health project management team on all the
technical issues which are relevant to the implementation of the large scale
pilots and for the further deployment of the services. These issues include but
are not limited to the technical architecture of the services and the standards
towards which the various regional implementations have to converge to
ensure openness and scalability of the solutions and protection of the
investment (obsolescence-proof solutions).”
CHA solicited the cooperation of Integrating the Healthcare Enterprise (IHE).
Founded in the United States in 1997, IHE enables users and developers of
healthcare information technology to achieve interoperability of systems through the
precise definition of healthcare tasks, the specification of standards-based
communication between systems required to support those tasks, and the testing of
systems to determine that they conform to the specifications. The work is managed
by IHE committees and sponsored by various national and international bodies. In
Europe, IHE is a not-for-profit organisation initiated jointly by the European
Association of Radiology (EAR) and the European Coordination Committee of the
Radiological, Electromedical and Medical IT Industries (COCIR). It has been legally
incorporated in Belgium since 2008. (See www.ihe-europe.net.)
IHE integration profiles have been adopted by national and regional projects in
countries such as Austria, France, Italy and The Netherlands. These specifications
provide the necessary guidance to implement the specific standards and profiles in
commercial and self-developed systems that will help realise efforts towards large
scale interoperability of health information in Europe and worldwide.
CHA and IHE together represent hundreds of companies, from multinationals to
SMEs, that work together to promote the seamless flow of patient information. With
CHA’s focus on personal health systems and IHE’s attention on the clinical domain,
the two organisations pool and complement their expertise to cover the telemedicine
applications in the Renewing Health pilot projects.
To widen their reach, in November 2010 the IAB asked two additional European
industry associations to join: COCIR and Eucomed.
COCIR, founded in 1959 and headquartered in Brussels, counts today more than
25 member companies and 13 national member associations in the radiological,
electromedical and healthcare IT industry in Europe. It supports its members on
issues which affect the medical technology sector, and works with various
organisations promoting harmonised international standards and fair regulatory
control that respects the quality and effectiveness of medical devices and
healthcare IT systems. (See www.cocir.org.)
Eucomed, also based in Brussels, represents designers, manufacturers and
suppliers of medical technology used in the diagnosis, prevention, treatment and
amelioration of disease and disability. Eucomed members include 25 national trade
and pan-European product associations and almost 60 internationally active
manufacturers of all types of medical technology. The mission of Eucomed is to
improve patient and clinician access to modern, innovative and reliable medical
technology. (See www.eucomed.org.)
D5.5 Technical recommendations for further
deployment
Public Page 13 of 77 v1.0 / 18th December 2013
In February 2011 the GSM Association (GSMA) joined the IAB. GSMA represents
the interests of the mobile telephone industry, with a membership of nearly 800 of
the world’s mobile operators from more than 200 countries, as well as 200 other
companies in the broader mobile ecosystem, including handset makers, software
companies, equipment providers, and others. GSMA’s end goal is to drive the
growth of the mobile communications industry. GSMA has offices in the Americas,
Europe and Asia, with its headquarter in London, UK.
CHA’s European Policy Working Group has been supervising the management and
deliverables of the IAB. Principal writer and researcher of the reports has been
Bridget Moorman, CHA’s Technical Manager. The IAB has been serviced by
Michael Strübin, Continua Programme Manager Europe.
D5.5 Technical recommendations for further
deployment
Public Page 14 of 77 v1.0 / 18th December 2013
3. The Renewing Health Project
3.1 Overview and generic technical architecture
The 21 Renewing Health telemedicine trials across nine countries involve the
remote monitoring and treatment of chronic patients suffering from diabetes, COPD
or cardiovascular conditions. The services are designed to give patients a central
role in the management of their own diseases, fine-tuning the choice and dosage of
medications, promoting compliance to treatment, and helping healthcare
professionals to detect early signs of worsening in the monitored pathologies.
All pilot projects in the RH programme treat at least one, sometimes two of three
pathologies: Diabetes, Chronic Obstructive Pulmonary Disease (COPD), and
Cardiovascular Diseases (CVD). These are further broken down into ten clusters.
Table 1 shows the breakdown.
Table 1: Clusters and Pathologies by Region/Country
Pilot site
Type of service PA
TH
OLO
GY
VE
NE
TO
SY
DD
AN
MA
RK
NO
RR
BO
TT
EN
NO
RT
HE
RN
NO
RW
AY
CA
TA
LO
NIA
SO
UT
H
KA
RE
LIA
TH
ES
SA
LY
CA
RIN
TH
IA
BE
RLIN
Cluster 1 Medium-term health coaching and life-long
monitoring
DIA
BE
TE
S X X X X
Cluster 2 Life-long monitoring
X X X
Cluster 3 Ulcer monitoring
X
Cluster 4 Short term follow-up after hospital
discharge
CO
PD
X X X
Cluster 5 Life-long monitoring
X X X
Cluster 6 Medium-term health coaching and life-long
monitoring
CV
D d
iseases
X X
Cluster 7 Remote monitoring of Congestive Heart
Failure X X
Cluster 8 Remote monitoring of implantable cardiac
devices (ICD & PM) X
Cluster 11 Medium-term health coaching and life-long
monitoring, with high blood pressure X
Cluster 10 Life-long monitoring of frail patients with
chronic diseases X
While there is considerable diversity of approaches and methods, the pilots’
technical architectures share certain key characteristics. In all projects, the patient
D5.5 Technical recommendations for further
deployment
Public Page 15 of 77 v1.0 / 18th December 2013
and/or home healthcare clinician use a medical device to measure a physiological
parameter or lifestyle information. The device transmits this data by wire or
wirelessly (in some cases data input is done manually) to either a mobile phone,
computer tablet, or a computer application. This pertinent physiological information
is forwarded to a healthcare professional either through an outside vendors’ web
application and/or through that pilot country’s electronic health record (EHR) system
or electronic medical record (EMR) application. In some cases, a personal health
record (PHR) application is used. Some pilots have a feedback mechanism that
reminds patients to take their measurements and/or take follow-up action. One
pilot’s system includes an educational component that promotes better condition
and lifestyle management. The specifics of what is being collected for each
pathology are discussed in the following country descriptions and presented in
section 4.1.
From a technical perspective, the pilots in general share the functional set-up as
shown below:
Figure 1: Generic Remote Monitoring System Diagram (Continua)
The above illustration is a generic rendering of a remote monitoring system. It
consists of the patient’s medical device with Personal Area Network (PAN) or Local
Area Network (LAN) capability. The medical device connects with an Application
Hosting Device (AHD), for example a mobile device, personal computer or
communications hub, which, in turn, connects to a Wide Area Network (WAN)
device. The WAN device interfaces to the Health Reporting Network (HRN) device.
For many systems in the field, each of these connections can facilitate two-way
communication.
Figure 2 below depicts the IHE Device Enterprise Communication Profile. There are
similarities between the Continua model and IHE model at the interfaces as well as
what is communicated at those interfaces. In the case of remote monitoring
Application
Hosting Device
PAN
Device
PAN-IF LAN-IF
HRN-IF
WAN
Device
HRN
Device
*
0..1
*
*
*
*
*
*
to service provider
to hospital (clinical domain)
LAN
Device
WAN
Device WAN
Device
D5.5 Technical recommendations for further
deployment
Public Page 16 of 77 v1.0 / 18th December 2013
systems, Continua and IHE-PCD have agreed upon the same set of standards for
the WAN interface and have worked together on the HRN interface.
Figure 2: IHE-PCD 01 Device Enterprise Communication (DEC)
Specific interfaces and components of a pilot system include: the transducer to the
medical device from the patient, docking of medical device with computer (wired,
wireless), mobile phone / gateway box / telephone / computer, application on mobile
device, application on computer, integration with calendaring application on mobile
device and/or computer, intermediate server with database application, clinician
access to intermediate server, data sent over public infrastructure (internet, mobile
phone, landline) to PHR or EHR/EMR applications, and clinician communication with
the patient via public infrastructure (i.e. telephone).
To summarise, the data transmitted in Renewing Health pilots consists of
physiological measurements from a device and self-reported information from
patient (could be a physiological measurement). This data is then sent to an
intermediate server with clinician access, sent to a PHR application (outsourced or
internal to clinician provider), and/or sent to EHR/EMR (outsourced or internal to
clinician provider). Additionally, in some pilots, information is sent to the patient from
a clinical source for educational purposes and/or reminders.
The evolution of the system architectures that the pilot sites experienced tended to
occur in the following areas: medical device and gateway changes due to market
availability and human factors, awareness of brittle interfaces leading to standards
awareness and specification, awareness of application limitations for scaling, and
further desire to outsource more of the remote monitoring functionality along the
data transmission path (i.e. outsourcing the integration of the different functions
outside of the healthcare enterprise). Moreover, in many of the pilot sites, data
security and privacy led to more complex architectures.
D5.5 Technical recommendations for further
deployment
Public Page 17 of 77 v1.0 / 18th December 2013
The following sections contain descriptions of the various country pilots in the
Renewing Health project along with their actual technical architectures.
3.2 Austria
Austria participated in the clusters associated with the pathologies of Diabetes, and
COPD. The Technical Architecture Diagram for the Austrian pilot is shown below:
Figure 3: Austrian Telehealth Technical Architecture Diagram
Austria specified the use of IEEE 11073-104ZZ standards for the medical devices:
glucometers, blood pressure and weight scales (for compliance information, see
table in section 4.3). For the HIS interface (EMR interface), Austria specified CDA
L1 documents for the first phase and plans to migrate to CDA L2-3 documents the
future.
D5.5 Technical recommendations for further
deployment
Public Page 18 of 77 v1.0 / 18th December 2013
Figure 4: Austrian Medical Devices for Remote Monitoring
Figure 4 depicts the different devices Austria used for measuring the physiological
parameters in Renewing Health. Austria chose a USB stick modem to facilitate
wireless mobile transmission of physiological parameters to their web portal
application.
Figure 5: Austrian Mobile Data Flow Architecture – Part 1
Figure 5 depicts the mobile telecommunications pathway Austria used for Renewing
Health. Mocca is the application used by the home health nurse to interact with the
chronic disease management application.
D5.5 Technical recommendations for further
deployment
Public Page 19 of 77 v1.0 / 18th December 2013
Figure 6: Austrian Mobile Data Flow Architecture – Part 2
Austria used a combination of patient self-service remote monitoring and nurse
assisted remote monitoring for their Renewing Health pilot. The home health nurses
use an application called Mocca to document the care and record the physiological
parameters which are collected. For the patient directed remote monitoring, the
patients can either manually enter the information into a web portal or use devices
integrated with a mobile phone gateway as depicted in Figure 5 and Figure 6. For
integration into the HIS, DaMe+ is used for signing and encrypting a CDA document
for use by the different applications.
3.3 Denmark
Denmark participated in clusters associated with the pathologies of Diabetes and
COPD.
3.3.1 Patient Briefcase
This is a specially designed transportable telemedicine unit which makes live video-
consultations possible, as well as real-time data transmission from the medical
devices included (plugged in or Bluetooth). The Patient Briefcase is user-friendly,
with only three controls (on/off, volume, alarm).
For COPD patients, the Briefcase contains equipment for the measurement of
pulse, blood oxygen saturation and spirometry. The medical devices are off-the-
shelf products. For other diseases, these devices can be replaced by others; e.g. for
heart patients, the relevant devices are not spirometry and pulse-oximeter, but a
weight scale and blood pressure measurement device. This enables a more flexible
use of the units in the hospital.
The Patient Briefcase unit connects to the hospital workstation through either a
wired (ADSL, etc.) or wireless connection (Clearwire, 3G, NMT, satellite, etc.). These
D5.5 Technical recommendations for further
deployment
Public Page 20 of 77 v1.0 / 18th December 2013
options mean that no patients are excluded from receiving the service because they
do not have a wired connection, or live in an area with poor mobile network
coverage. As a last resort, satellite connection is possible. However this is more
expensive, and has a slight delay in image viewing.
3.3.2 Hospital workstation
Usually the workstation has three screens – one for the hospital EHR, one for live
video, and one for viewing the data transmitted from the Patient Briefcase. It also
has a built in web camera and microphone, and a computer linked to the electronic
medical records. It has all the necessary applications for connection to
videoconferencing and data reception from the patient.
3.3.3 Data transmission and storage
The vital signs data from the medical devices in the Patient Briefcase are sent to the
hospital at the same time as the measurements are taking place. The healthcare
professional at the hospital can then view the information, and analyse the data on
their PC using an application (software program) that complements the Patient
Briefcase. The data are stored in the workstation. There is currently no integration
with the patient’s electronic patient record (EPR) at the hospital. Neither is there
integration to the patient records in the homecare system or to the GP’s electronic
patient record. The EPR at hospital, homecare, and GP level are all different
systems, just as there are multiple vendors for each in the Danish healthcare
system. All information sent between the involved parties is in the format of standard
electronic messages (MedCom standards), mainly using the MedCom Clinical Email
standard.
Links between the solutions and other systems and services are based on the
national MedCom standards for communication.
3.3.4 Integration with other applications and the IT infrastructure
The integration has not been fully developed, but there has been some
consideration regarding the services in RENEWING HEALTH.
The services in RENEWING HEALTH use existing infrastructure. Nationally, the
electronic health infrastructure is based on the Danish Health Data Network
(DHDN). Today, all hospitals (60), all pharmacies (250), all local authorities (98),
99% of all GP clinics, 80% of specialised doctors and most vendors, laboratories
etc., are connected to the DHDN (www.medcom.dk).
The electronic communication among the various parties is based on common
standards that are developed, tested and certified by MedCom, which is a co-
operative venture between authorities, organisations and private firms linked to the
Danish healthcare sector. MedCom’s main task and purpose is to contribute to the
development, testing, dissemination and quality assurance of electronic
communication and information in the healthcare sector.
The integration architecture solutions for the service in RSD follow national
strategies and MedCom communication standards.
D5.5 Technical recommendations for further
deployment
Public Page 21 of 77 v1.0 / 18th December 2013
3.3.5 Diabetes pilot
This pilot used a web-based shared care database for ulcers (www.pleje.net) which
is provided by Dansk Telemedicin, and mobile phones with camera and video
functionality provided by Nokia and Sony Ericsson. Images from the mobile phone
are transmitted to the ulcer database through GSM. Data transmission to and from
the ulcer database and the Electronic Health Record at the hospital and Electronic
Homecare Record in the municipality is sent through DIS-91 EDI documents
(MedCom standard). Below is the technical architecture for the diabetes pilot.
Figure 7: Danish Telehealth Technical Architecture Diagram – Diabetes
3.3.6 COPD pilot
A spirometer and pulse oximeter by MIR (Medical International Research) are
attached via USB to the Patient Briefcase. The measurements are transmitted to a
COPD database (software system) at the hospital. Communication from the home
to hospital uses a dedicated IP line, which can either be broadband (approx. 50%)
or wireless (approx. 50%), or satellite (<1%) if neither broadband nor wireless are
available.
D5.5 Technical recommendations for further
deployment
Public Page 22 of 77 v1.0 / 18th December 2013
Figure 8: Danish Telehealth Technical Architecture Diagram – COPD
Figure 8 depicts final architecture for Danish support of COPD in Renewing Health.
In this architecture, the Patient Briefcase essentially provides a virtual clinical
presence in the patient's home. Clinically, it is difficult to obtain good quality
spirometric readings without patient coaching. Use of the briefcase for real-life
interaction with the patient ensures the clinicians get valid data for their analysis
purposes.
Figure 9: Danish Telecommunications Architecture Diagram – COPD and
Diabetes
D5.5 Technical recommendations for further
deployment
Public Page 23 of 77 v1.0 / 18th December 2013
Figure 9 depicts the telecommunications architecture for the Danish COPD remote
monitoring system. The briefcase uses various telecommunications paths to
provide the virtual clinical presence in the patient's home.
3.4 Finland
Finland participated in clusters associated with the pathologies of Diabetes and
CVD. The Technical Architecture Diagram for the Finland pilot is shown below:
Effica
Blood glucose
Blood pressure
Weight
Measuring
devices
Bluetooth or
manual entry
care
documentation,
EHR view
meas. data,
observations,
notifications
Patient
Web PHR
application
(patient) PHR view,
data entry,
messaging
Mobile PHR
application
Upload
measurements,
receive feedback
and reminders
Health professional
(1) (2)
(3)
(4)(5)
interface to
EHR and other systems(6)
Web PHR
application
(health
professional)
Steps
Self-
management
server
PHR process
support
PHR view,
data entry,
coaching
support,
notifications,
messaging
health coach
doctor/
nurse
Electronic
Health
Record
(EHR)
system
USB,
bluetooth or
manual entry
(1)
Figure 10: Finnish Teleheath Technical Architecture Diagram
In Finland’s procurement documents, a preference was specified for the use of the
Continua 1.0 guidelines at Interface 1 in the diagram above. Due to the limited
availability of Continua-compliant measurement devices, proprietary interfaces were
still used in the pilot. However, the use of open database schemas for the PHR
database has been specified in order to allow connectivity with other systems
(Interface 6). Future integration by enterprise application integration / enterprise
service bus (EAI/ESB) will be taken into account in the design of the self-
management server. This ensures it will be compatible with the service oriented
architecture (SOA) and web based platform which provides a wide range of generic
services, such as authentication, for various information systems in the EKSOTE
area. (EKSOTE is the acronym for the South Karelia Social and Health Care
District.) In the pilot phase, the telemedicine equipment was not integrated with
other IT systems; but integration interfaces are required for further development.
3.4.1 Blood pressure meter
Blood pressure meters are CE-approved. They are of upper-arm type, and enable
automatic ("one button click") measurement of systolic and diastolic blood pressure
and heart rate.
The blood pressure meters are connectable by Bluetooth. The meter enables
automatic uploading of data by connecting via a mobile phone to the self-
management server.
D5.5 Technical recommendations for further
deployment
Public Page 24 of 77 v1.0 / 18th December 2013
3.4.2 Blood glucose meter
Blood glucose meters or glucometers are CE-approved. In the pilot, patients used
two types of glucometers:
1) Basic glucometers. The glucometers are not required to be wirelessly
interoperable with the mobile phone. The glucometer measurement data was
entered manually into the mobile or web PHR application.
2) Interoperable glucometers. It is possible to connect these glucometers to a
mobile phone via Bluetooth. When connected, the glucometer should
automatically send the measurement result to the self-management server via
the inter-connected phone. A data store-and-forward mechanism is also
available. In that case, measurement results are stored in the internal memory
of the device and the results may then be uploaded later.
Many of the patients had existing glucometers. In those cases, the existing meter
was used, which was usually not interoperable with the mobile phone.
3.4.3 Weight scale
Weight scales were digital, and supported measurements up to 150kg with a
resolution of 0.1kg. There are no connectivity requirements, since the information is
manually entered into the mobile or web PHR application.
3.4.4 Pedometer
Pedometers were digital. There are no connectivity requirements, since the
information is manually entered into the mobile or web PHR application.
3.4.5 Mobile phone
The mobile phones used were standard GSM phones or feature phones (not smart
phones). The phones supported wireless connectivity with blood pressure meters
and glucometers as defined above.
3.4.6 Web PHR application
The web PHR application is a web-based application providing functionality to view
and manage personal health data stored in the PHR database, and to support the
self-management process. The application provides user interfaces for patients,
care personnel and administrators. All interfaces are browser-based. The core
functionalities are:
Storage and management of personal health data entered by the patient,
providing the possibility to view data entered by patients and care personnel.
Support for safe messaging (off-line) between patient and care personnel
based on a secure https connection between the browser and the self-
management server.
Creating and maintaining personal self-management plans.
Rule-based provision of alerts, reminders and feedback for patients and
caregivers.
D5.5 Technical recommendations for further
deployment
Public Page 25 of 77 v1.0 / 18th December 2013
Protection of information against unauthorised use.
Applications receive data via web services or other standard integration
protocols.
3.5 Germany
Germany participated in clusters associated with the pathologies of Diabetes and
COPD. The German pilot in Berlin has a mature remote telemonitoring architecture
developed in partnership with Pflegewerk, an assisted living complex in which
residents are remotely monitored both physiologically and functionally. The
functional monitoring is done through 'smart-home' technology. The technical
architecture diagrams below depict the different monitoring devices and
communication hubs used for remote telehealth monitoring. The monitoring devices
are connected to a mobile device, namely a smart phone, which collects the data
and sends them to a centralised database. These data are compared with multi-
valued threshold levels; statistics are collected and stored in electronic Patient
Health Records. There a doctor, a family member, the patient or any other person
explicitly authorised for this by the patient himself can look at the situation, and
notice any values that may give rise to doubt in a timely fashion and act accordingly.
Measurements are taken directly by the patient himself, where possible. Where
appropriate, however, the assistance / coaching of a nurse is provided. If
necessary, alarms are sent to family members, caregivers and/or doctors.
Otherwise, the assisting nurse can immediately provide the necessary care. A
telephone contact with the patient is made more frequently than before.
Figure 11: German Telehealth Technical Architecture Diagram (COPD and
Diabetes)
D5.5 Technical recommendations for further
deployment
Public Page 26 of 77 v1.0 / 18th December 2013
The German system architectures for COPD and Diabetes shared the same
attributes with merely the specific measured physiological parameters changing due
to the specific disease.
Figure 12: German Telehealth Technical Architecture Diagram with mobile
phone used as Communication Hub
The technology of the telemedicine application in German mainly uses three sorts of
devices:
Measuring devices equipped with Bluetooth interface to send the data to a
suitable receiving device. Such equipment has been on the market for a time,
but is not yet widely used. The Bluetooth interface increases the cost of the
equipment and makes it mainly suitable for telemedicine applications. As
these applications increase in number in the near future, the devices will
become more affordable.
Smart phones as a receiver of the measurement data. These are becoming
more and more available and therefore also affordable, and the quality is
improving very rapidly. This is important to ensure that the measurements are
correct and get to the right place at the right time.
A web-based database to store the data, and an application to manipulate
them, and to make some calculations and presentation (e.g. in the form of
charts). This is also a technology that is not new, but it is being improved
dramatically; one of the challenges of the application is keeping up with these
technological improvements.
D5.5 Technical recommendations for further
deployment
Public Page 27 of 77 v1.0 / 18th December 2013
At the moment, the application used in Germany is a fairly stand-alone and
proprietary application, but steps are being made to ensure this does not remain so.
Integration with the electronic patient records of Pflegewerk is under discussion with
the providers of the two software solutions. Other software solutions are being
investigated, that will allow integration of the application both with the patient
management software of Pflegewerk, and with future German centralised patient
health records.
3.6 Greece
Greece built upon a previous pilot and infrastructure and updated the infrastructure
and system for the Renewing Health pilot. They participated in clusters involved
with all of the pathologies: Diabetes, COPD, and CVD. The Technical Architecture
Diagram of the Greek pilot is shown below:
Figure 13: Greek Telehealth Technical Architecture Diagram
Greece used the Card-Guard system which provides a web-based PHR called
PMP4 for both patient and clinician access. The medical devices used are
designed to interface to the PMP4 system. Therefore from an interoperability
standpoint, this is a closed system provided by one vendor.
Pictures of the glucometer interfacing to the mobile phone are shown below:
D5.5 Technical recommendations for further
deployment
Public Page 28 of 77 v1.0 / 18th December 2013
Figure 14: Depiction of CardGuard Gluco Module used with mobile phone
(Greece)
3.7 Italy
Italy participated in clusters associated with the pathologies of Diabetes, COPD,
CVD and Implantable Cardiac Devices (ICD – PM) telemonitoring. They participated
also in the cluster that considers multi-pathology patients with Diabetes, COPD and
CVD.
For Diabetes patients, Italy used the One Touch Gita glucometer (OneTouch Vita) to
measure blood glucose. For those COPD patients that were self-monitored, the
Wrist Clinic Device (Medic4All) was used to measure pulse oximetry and pulse rate.
For CVD patients, Italy used the Wrist Clinic Device (Medic4All) to measure pulse
oximetry, pulse rate, blood pressure and EKG. Lastly, the weight scale Medic4All
WS210 was used to measure body weight. For the multi-pathology cluster, Italy
used all of the devices listed for the specific clusters.
The sections 3.7.1 and 3.7.2 contain the specifications of the hardware used in the
Italian pilot, both at the patient's home and regional health centre.
D5.5 Technical recommendations for further
deployment
Public Page 29 of 77 v1.0 / 18th December 2013
3.7.1 Hardware at patient’s home
Wrist Clinic
Functional characteristics:
ECG measurement (1-Lead) and heart rate
Heart rate 40-200 bpm
Range of frequency 0.05-40 Hz
Detection accuracy of heart rate Regular/Irregular/ND
Total measurement time About 45 sec
Time ECG measurement 30 sec
Input dynamic range ±5 mV
DC offset correction ±300 mV
A to D sampling rate 360 sample/sec
Heart rate measuring accuracy ±3.5 bpm
CMRR >95 dB
Blood pressure measurement
Method of measurement Oscillometric measurement fully automatic for
detecting the pressure on the wrist
Measuring range Blood pressure: 0-299 mmHg
Heart rate: 40-180 bpm
Accuracy Blood pressure: ±3 mmHg or 2%, for any superior
heart rate: ±5%
Inflation Automatic inflation by pumping
Deflation Rapid and automatic deflation
Pressure sensing Piezoelectric transducer of blood pressure
Wrist circumference 13.5-21.5 cm
Oxygen saturation measurement (%SpO2)
Oxygen saturation (%SpO2) 40-99%
Accuracy: for oxygen saturation
values including between 70% and
90% (without motion artefacts)
±3%
Heart rate 40-200 bpm
Accuracy (±1 SD) Heart rate: ±3%
D5.5 Technical recommendations for further
deployment
Public Page 30 of 77 v1.0 / 18th December 2013
Measurement time Internal sensor for 30 seconds, read cycles
approximately every 6 seconds
Respiratory rate measurement
Breathing 5-35 breath/min
Measurement time About 50 seconds
A to D sampling rate 360 sample/sec
Breathing measuring accuracy ±2 cycle/min
Technical characteristics:
RF communication
Frequency Factory pre-regulation 433.92 MHz or 868.3 MHz or 915
MHz
Maximum transmission power +10 dbm (EIRP)
Ranges of frequency 60 kHz
Transmission interval About 250 m (in open space)
Supply
Batteries 2 x LR03 (AAA)
Maximum current use 300mA
Maximum internal voltage 4V
Environmental specifications
Operating conditions From +10°C to +40°C; from 30% to 85% of relative
humidity
Storage conditions From -10°C to +55°C; from 10% to 95% of relative
humidity
Certifications
Certifications Conforms to European 93/42/EEC Medical Device
Conforms to European 99/05/EEC Radio and
Telecommunication
Medic Gate gateway
Technical characteristics:
RF communication
Frequency 433.92 MHz (EU) or 868.3 MHz (EU) or 915 MHz
(USA)
Maximum transmission power 10 dbm (EIRP) to 433.92 MHz and 868.3 MHz; -1 dbm
(EIRP) to 915 MHz
Bandwidth 60 kHz max
Transmission interval 250 m (in open space)
D5.5 Technical recommendations for further
deployment
Public Page 31 of 77 v1.0 / 18th December 2013
FCC ID SEBVMG02
Product ID US:M4AAL02BVMG02
REN 02B
Supply
Batteries 4 x 1.2V 1800mAH NiMH rechargeable batteries
Supply Continuous feed 9V/400mA
Environmental specifications
Operating conditions From +10°C to +40°C; from 30% to 85% of relative
humidity
Storage conditions From -10°C to +55°C; from 10% to 85% of relative
humidity
Dimensions About: 145[W] x 55[H] x 175[D] mm
Weight About: 375g without batteries
Certifications
Certifications Conforms to European 93/42/EEC Medical Device
Conforms to European 99/05/EEC Radio and
Telecommunication
Digital scale WS100 (Medic4All)
Technical characteristics:
Measurement scale
Maximum weight detectable 150 Kg
Minimum weight detectable 0.05 Kg
Storage Last 10 measurement
RF communication
Frequency 433.92 MHz or 868.3 MHz or 915 MHz
Maximum transmission power 10 dbm (EIRP) to 433.92 MHz or 868.3 MHz; -1 dbm
(EIRP) to 915 MHz; Maximum bandwidth 60 kHz.
Transmission interval 250 m (in open space)
FCC ID SEBRFADAPTER
Supply
Batteries 4x1,5v AA alkaline
D5.5 Technical recommendations for further
deployment
Public Page 32 of 77 v1.0 / 18th December 2013
Environmental specifications
Operating conditions From +10°C to +40°C; from 30% to 85% of relative
humidity
Storage conditions From +10°C to +60°C; from 30% to 85% of relative
humidity
Dimensions About: 320 x 313.36 mm
Weight About: 2.2 Kg excluding batteries
Certifications
Certifications
Conforms to European 93/42/EEC Medical Device
Conforms to European 99/05/EEC Radio and
Telecommunication
Glucometer (Onetouch® Vita™)
Technical characteristics:
Characteristic Description
Reading interval 20-600 mg/dL
Calibration Plasma-equivalent
Sample Capillary whole blood
Sample size Minimum one microlitre
Test time 5 seconds
Method of analysis Glucose oxidase biosensor
Instrument supply 1 lithium battery 0.3V CR 2032 replaceable
Lighting supply 1 lithium battery 0.3V CR 2032 replaceable
Units of measurement Mg/dL
Storage 500 results
Automatic switching off 2 minutes after the last operation
Dimensions 7.92 cm*5.72 cm*2.29cm
Weight 42.5 gr including batteries
Operating ranges Temperature: 6-44°C; Relative humidity: 10-90%; altitude:
until 3.048 m; hematocrit: 30-55%
Certifications
Certification 97/98 In Vitro Medical Device
Conforms to European 99/05/EEC Radio and
Telecommunication
D5.5 Technical recommendations for further
deployment
Public Page 33 of 77 v1.0 / 18th December 2013
3.7.2 Region eHealth Centre
Italy outsourced their regional health centres to TeSan, a subsidiary of the TBS
Group, which designs and directly manages ICT services dedicated to elderly,
disabled, chronically ill and partially self-sufficient persons.
The Regional eHealth Centre is based on:
A Multimedia Contact Centre which offers bi-directional activities
management, in association with day services, and stand-alone multimedia
services for activities; and
A Web Portal for integrated management of all services.
The Regional eHealth Center system uses a computer telephony integrated (CTI)
server (Necsy UniContact Telecare) which has been designed specifically for
telehealth, telecare and telemonitoring applications. This server provides the
following services:
Connection to a public switched telephone network (PSTN).
Local and/or remote operator stations in virtual private network (VPN) or
internet connections and,
Integrated Alarms management across multi-vendor telecare devices.
3.7.3 General System Description for Remote Monitoring Support
Diabetes, COPD (self-monitoring), CVD and multi-pathology cluster applications use
one or more medical devices to perform all the measurements needed, as defined
by the telemonitoring plan developed by the patient’s clinician. These devices
transmit all physiological data using both wireless (wrist clinic device and weight
scale) and wired (glucose meter) communication protocols to a home gateway. The
gateway then sends all data via PSTN protocol through regular phone services to
the Regional eHealth Centre in charge of data management. Patient data
measurements are available to clinicians through a dedicated web service of the
Centre. If the patient measurement is out of normal range as defined by the
protocol, the Centre first contacts the patient on the phone, with subsequent
notification to the patient’s reference clinician who can trigger messages to inform
the specialist.
Figure 15 below shows the general technical architecture diagram for the
telemonitoring services described above:
D5.5 Technical recommendations for further
deployment
Public Page 34 of 77 v1.0 / 18th December 2013
Figure 15: Italian Telehealth Technical Architecture Diagram for
telemonitoring service for diabetes, COPD, CVD and multi-pathology clusters
Since this telemonitoring service integrates a pre-existing telecare service for
detection of emergency situations at the patient’s home, patients of diabetes, COPD
(self-monitoring), CVD and multi-pathology clusters also received a personal alarm
device for 24/7 emergency detection. These alarms are wirelessly transmitted to a
home gateway that sends them automatically to the Regional eHealth Centre
through their regular phone services (PTSN). In addition to alarm response
communication, the centre operators make scheduled calls to the patient to check
the patients’ condition as well as verify the telecommunications system.
Italy bases their telemonitoring solutions on IHE integration profiles which they
believe allows improvement of information exchange and minimisation of integration
costs. For the telemonitoring of diabetes, COPD, CVD and multi-pathology clusters,
Italy is working on the technical definition of an integration platform to allow data
integration from the Regional eHealth Centre and the clinician’s EHR, using HL7
Clinical Document Architecture version 2 (CDA2) documents. This also facilitates
sharing between each actor involved in the telemonitoring process: the patient, the
workflow related to the process, and all related events (data sending, alarm
situations, change of the telemonitoring protocol, request for a visit, etc.) which are
then tracked in a specific workflow document. The IHE profiles used in this
integration platform are: Cross Enterprise TeleHome Monitoring Workflow (XTHM-
WD) profile of the Patient Care Coordination (PCC) domain, Cross Enterprise
Workflow (XDW) profile of Information Technology Infrastructure (ITI) domain for the
document workflow management, and the Cross-Enterprise Document Sharing-b
(XDS.b) profile of the ITI domain for the document infrastructure.
For COPD, home nurse monitoring was provided to patients that were not able to
perform all of the physiological measurements themselves. Physiological
measurements were collected from the patient by the nurse on his/her service
laptop, using the MIRIII Spirometer and Pulse Oximeter as well as the Abbott iSTAT
for arterial blood analysis. All data collected from each individual was taken
D5.5 Technical recommendations for further
deployment
Public Page 35 of 77 v1.0 / 18th December 2013
according to a schedule which was customised to the patient’s specific needs. Data
was then transmitted through Internet VPN to the service centre or to the healthcare
organisation for further processing.
Below are the technical architecture diagrams for remote monitoring and assisted-
monitoring service in COPD cluster, and remote monitoring in CVD, diabetes and
multi-pathology:
:
Figure 16: Italian Telehealth Technical Architecture Diagram for nurse-
assisted remote monitoring service of COPD
D5.5 Technical recommendations for further
deployment
Public Page 36 of 77 v1.0 / 18th December 2013
Figure 17: Italian Telehealth Architecture for CVD Telehealth and Telecare
Pa ent’shome RegionaleHealthCentre
5
3 2
4
GENERALPRACTITIONER
SERVER
DATATRANSMISSION DATAACCESSTHROUGHHOMECAREPORTAL
ALARMMANAGEMENTALARMMANAGEMENT
PATIENT
1
GATEWAY
ALARMDEVICE
INTERVENTIONSERVICE
SOCIALWORKER
FAMILY
6
7 TELEMONITORING
DEVICES
REGIONALCENTRE’SOPERATOR
13
Cluster 10: Multi-pathology
Veneto Region (IT) ©
Figure 18: Italian Telehealth Architecture for remote monitoring of multi-
pathology – includes all chronic disease monitoring pathways
D5.5 Technical recommendations for further
deployment
Public Page 37 of 77 v1.0 / 18th December 2013
3.7.4 Remote Monitoring of CVD: Implantable Devices
Italy also participated in the CVD cluster with monitoring of implanted cardiac
devices (ICD). The patient was equipped at his home with a gateway device able to
receive data collected by the implanted sensor and to forward it to the external
provider unit via an IP data connection (ADSL, GPRS, GSM, PSTN, UMTS). The
health professional controls the patient data transmitted, using the provider-specific
software application. These solutions preserve legacy systems and applications. For
the RENEWING HEALTH project, Italy is working with the IHE on the technical
definition of an integration platform allowing standard communication between ICD
provider systems and hospital information system with the use of the Implantable
device, Cardiac Observation (IDCO) profile of Patient Care Device (PCD) IHE
Domain.
The IDCO profile uses HL7 v2.5/6 and ISO/IEEE11073 standards including the
Rosetta Terminology mapping to facilitate interoperability at device level. Adoption of
IDCO would alleviate the problem of attending cardiologists having to use a different
system to follow up the devices of each implant manufacturer; it would also enables
storage of clinical information in the Hospital Information System (HIS) or EHR.
At the moment, none of the cardiology departments involved in the pilot adopts
integration with its clinical EHR, if the clinical EHR exists. Figure 19 below depicts
the architecture used by Italy to monitor their ICD patients.
Figure 19: Italian Telehealth Technical Architecture Diagram for remote ICD
monitoring
D5.5 Technical recommendations for further
deployment
Public Page 38 of 77 v1.0 / 18th December 2013
3.8 Norway
Norway participated in the cluster associated with the pathology of Diabetes.
Norway built upon a previous pilot and infrastructure, which was be updated for the
Renewing Health pilot. The pre-existing application was designed for a previous
pilot called the Few Touch Application (FTA). The application monitors the status of
the patient with regards to blood glucose, food intake and activity on a daily basis,
functioning essentially like a digital health diary.
The technical architecture diagram for the Norway pilot is shown below:
Figure 20: Norwegian Telehealth Technical Architecture Diagram
Patient data was stored on a server which was accessible by researchers in the
project. Norway has very strict data privacy laws which restrict the integration of
patient data outside the healthcare enterprise into the EHR/EMR, therefore the
patient data was not integrated into the healthcare enterprise EHR/EMR systems.
3.9 Spain
Spain participated in the cluster associated with COPD. The medical devices used
were the Nonin 4100 pulse oximeter, Sibelmed Datospir Micro C Spirometer, AVITA
Blood Pressure Monitor BPM65BT and AVITA wireless weight scale SC101. The
information from the devices was transmitted wirelessly using Bluetooth protocol to
a mobile phone, and then sent via GPRS or 3G to the LinkCare system. Catalonia
is developing an Electronic Health Record interface using SAP.
The technical architecture diagrams for Spain’s pilot project are shown in the
following figure:
D5.5 Technical recommendations for further
deployment
Public Page 39 of 77 v1.0 / 18th December 2013
Figure 21: Spanish Technical Architecture Diagram I
Spain used an application called LinkCare to integrate the telehealth data with their
EMR applications. The diagram below gives some details.
Figure 22: Spanish Technical Architecture Diagram II – LinkCare specifics
3.10 Sweden
Sweden participated in the clusters associated with the pathologies of Diabetes and
CVD.
D5.5 Technical recommendations for further
deployment
Public Page 40 of 77 v1.0 / 18th December 2013
The specific devices they used for diabetes were glucometers (several brands as
patients already have glucometers), polar FT2 pulse watch, OMRON M6 Comfort
blood pressure device, and the OMRON Walking Style X pedometer.
For CVD the Zenicor EKG was used.
The devices were not connected directly to a gateway communication hub. Instead,
patients manually entered the information into a mobile phone or computer.
(Swedish law does not allow a patient-acquired measurement to be transferred
directly / automatically into an EHR that is government or healthcare organisation
owned.) The Zenicor EKG communicated directly via GSM/GPRS with the web
server.
Figure 23: Sweden Telehealth internal Technical Architecture Diagram
D5.5 Technical recommendations for further
deployment
Public Page 41 of 77 v1.0 / 18th December 2013
Figure 24: Sweden device specific Technical Architecture
D5.5 Technical recommendations for further
deployment
Public Page 42 of 77 v1.0 / 18th December 2013
4. Summary and analysis
4.1 Parameters and data types collected (updated from D5.1)
Based on the breakdown of pilots along the pathologies of Diabetes, COPD and
CVD diseases, the following table gives a summary of the parameters and data
types that were collected in the Renewing Health project’s pilots. Changes from the
initial D5.1 document are show in blue colour and italics:
Table 2: Parameters and Data Types by Pathology and Country
Pathology
Parameter
Diabetes Chronic
Obstructive
Pulmonary
Disease (COPD)
Cardiovascular
Diseases (CVD)
Blood Pressure Austria, Finland,
Germany
Germany Austria, Finland,
Greece, Italy,
Sweden
Pulse Oximetry
(SPO2), Pulse Rate
Germany Denmark,
Germany, Italy
Sweden, Italy
Electrocardiography
(1-2 lead EKGs)
Greece, Italy,
Sweden
Weight Finland, Germany,
Norway
Austria, Finland,
Germany, Greece,
Italy
Spirometry Austria, Denmark,
Germany, Greece,
Italy, Spain
Prothrombin Time
and International
Normalised Ratio
(PT/INR)
N/A – cluster
cancelled due to
clinical protocol
changes
Blood Glucose Austria, Finland,
Germany, Greece,
Italy, Norway,
Sweden
Activity (pedometer) Finland Finland, Sweden
Implant status Italy
Skin status
(photographs of
ulcers via mobile
phones)
Denmark
Consumption
(electronic diary)
Austria
(alcohol/tobacco),
Norway (food)
Austria
(alcohol/tobacco)
The following section provides a detailed analysis of devices and transfer protocols
before we consider the question of standards compliance.
D5.5 Technical recommendations for further deployment
Public Page 43 of 77 v1.0 / 18th December 2013
4.2 Devices and interfaces (updated from D5.1)
Below is a summary table of the devices and interfaces used by each pilot, listed separately for each condition where they differ. The
monitoring device may be a glucometer, blood pressure cuff, weight scale, spirometer, pedometer, pulse oximeter, arterial blood analysis, or an
EKG. In Denmark, pictures of ulcers are being transmitted to a database by mobile phones. Updates from D5.1 are shown in blue colour and
italics for each country.
Table 3: Device and Interfaces (updated)
Device-
Interface
Country
Condition Monitoring device Means of
Transmission
Aggregation
Gateway in Home
(Application
Hosting Device)
Means of
Transmission
Personal
Health
Record
Electronic Health
Record
Austria COPD
smartLAB fit-BT weight
scale auto sent; manually
enter into internet health
portal; home nursing
enter into PDA
BlueTooth/USB;
ANT wireless;
manual entry
smartLAB fit-BT
hFon USB device
(ANT wireless) to
Aon Modem to
internet; Internet
health portal
access; Garmin
Asus Nuviphone
M10 Mobile phone
Internet; GSM;
UMTS (IP-VPN)
Aon Care
platform
(internet
health portal
of Telekom-
https)
HIS Orbis/HIS
Patidock using CDA1
and HL7/ELGA;
LOINC 34133-9,
11506-3, 34106-5
and 34745-0 are
used for clinical data
encoding; all done via
DaMe system
Austria Diabetes
ProfiLine Cignus
glucometer BT; Boso
medicus Prestige
BlueTooth blood pressure
machine; smartLAB profi
blood pressure machine;
smartLAB genie+
glucometer; smartLAB fit-
BT weight scale
BlueTooth; ANT
wireless
Garmin Asus
Nuviphone M10
Mobile phone;
smartLAB fit-BT
hFon USB device
(ANT wireless) to
Aon Modem to
internet; Internet
health portal
access
GSM, Internet,
UMTS (IP-VPN)
Aon Care
platform
(internet
health portal
of Telekom-
https)
HIS Orbis/HIS
Patidock using CDA1
and HL7/ELGA;
LOINC 34133-9,
11506-3, 34106-5
and 34745-0 are
used for clinical data
encoding; all done via
DaMe system
D5.5 Technical recommendations for further deployment
Public Page 44 of 77 v1.0 / 18th December 2013
Device-
Interface
Country
Condition Monitoring device Means of
Transmission
Aggregation
Gateway in Home
(Application
Hosting Device)
Means of
Transmission
Personal
Health
Record
Electronic Health
Record
Denmark COPD
Medical International
Research (MIR)
MIROxi
MIRSpiro
USB Medisat’s Patient
Briefcase
Internet either
wireless, ADSL
or satellite
COPD
database at
the hospital
No interface
Denmark Diabetes
Mobile Phone with
Camera (.jpg file)
(Nokia or Sony Ericsson)
Mobile phone
(Nokia or Sony
Ericsson)
GSM
Ulcer
database –
www.pleje.net
Cosmic (Danish
national EHR) at the
hospitals and
homecare records in
the municipalities
(Ramboll, Acure and
CSC)
Finland CVD,
Diabetes
Glucose meters: are
patient owned so patients
use different brands.
Blood pressure meter:
Stabilo graph mobil
Pedometer: asaklitt step
counter
Weight scales: are patient
own so patients use
different brands
Wireless (CVD),
Bluetooth
(Diabetes)
Nokia 5230 Navi
and home
computer through
web application
GSM, Internet
(Web)
Medixine
Clinic
Effica (Regional
EHR)
Germany COPD
SPO2-Nonin 9560 Onyx II
Jaeger -Viasys AM1+BT
Asthma Monitor
(Spirometer)
USB
Arbor Technology
Medical Tablet PC
M1255/N270 or
Mobile phone (HTC
Cha-Cha)
Internet
D5.5 Technical recommendations for further deployment
Public Page 45 of 77 v1.0 / 18th December 2013
Device-
Interface
Country
Condition Monitoring device Means of
Transmission
Aggregation
Gateway in Home
(Application
Hosting Device)
Means of
Transmission
Personal
Health
Record
Electronic Health
Record
Germany CVD
EKG – Vitaphone Remote
200-BT; Blood Pressure -
Stabilograph Mobile
Wireless
Arbor Technology
Medical Tablet PC
M1255/N270 or
Mobile phone (HTC
Cha-Cha)
Internet
Germany Diabetes
Glucometer – Cignus
Diagnostics ProfiLine,
IEM Libro-O-Graph mobil
USB, Bluetooth
Arbor Technology
Medical Tablet PC
M1255/N270 or
Mobile phone
(HTC Cha-Cha)
Internet LifeSensor
Greece COPD Card Guard Spirophone
CG-303A
Wireless or
audible
(spirometry)
report over
phone to Tele-
care Centre
PDA QTEC 2020i
and Vodafone
ETEN
GPRS or
audible
(spirometry)
report over
phone to Tele-
care Centre
PMP4
Greece CVD
EKG-Card Guard CG-
2206 1 Lead; Blood
Pressure – Card Guard
PMP4-BP-Pro, Scale
Wireless or
audible (EKG)
report over
phone to Tele-
care Centre
PDA QTEC 2020i
and Vodafone
ETEN
GPRS or
audible (EKG)
report over
phone to Tele-
care Centre
PMP4
Greece Diabetes
Glucometer – Card-Guard
PMP Self-Check Gluco
module
Bluetooth
PDA QTEC 2020i
and Vodafone
ETEN
GSM (GPRS) PMP4
Italy COPD
MIR III Spirometer (also
has pulse oximetry
function)
Abbott iSTAT (arterial
blood analysis
USB
Manual Entry
Internet Key –
ONDS MT505UP
Modem
UMTS, Internet
(web- VPN)
TPR web, electronic
patient profile
updated with the
telemonitoring data
D5.5 Technical recommendations for further deployment
Public Page 46 of 77 v1.0 / 18th December 2013
Device-
Interface
Country
Condition Monitoring device Means of
Transmission
Aggregation
Gateway in Home
(Application
Hosting Device)
Means of
Transmission
Personal
Health
Record
Electronic Health
Record
Italy COPD Wrist Clinic Medic4All
(oxymetry, pulse rate)
Wireless
(Radio
Frequency)
Medic Gate
Medic4All
Fixed (Public
Telephone
Switched
Network (PSTN)
Web Electronic
health record of the
telemonitoring centre
Italy
CVD –
Heart
Failure
Wrist Clinic Medic4All
(oxymetry, pulse rate,
blood pressure, one-
lead ECG)
Weight ScaleWS210
Medic4All
Wireless
(Radio
Frequency)
Medic Gate
Medic4All
Fixed (Public
Telephone
Switched
Network
(PSTN),
Web Electronic
health record of the
telemonitoring centre
Italy
CVD –
Implant-
able
Devices
Implantable Cardio Verter
Defibrillator or Pacemaker
(Biotronik, Medtronic, St
Jude, Boston Scientific;
Sorin)
Wireless Home gateway
ADLS, PSTN,
UMTS, GSM,
GPRS
Web Electronic
health record of the
devices’
manufacturers
Italy Diabetes Glucometer OneTouch
Vita Wired
Medic Gate
Medic4All
Fixed (Public
Telephone
Switched
Network (PTSN)
Web Electronic
health record of the
telemonitoring centre
Norway Diabetes
Glucose Meter
(Lifescan OneTouch Ultra
2); Glucose Meter
Accessory
(Polymap Wireless
Polytel GMA)
Bluetooth
Mobile Phone with
Few Touch
application (HTC
HD Mini, Windows
Mobile)
GSM
Few Touch
Application
(Web Server
(Apache,
Zope 3))
Using a research
database server due
to Norwegian privacy
regulations regarding
electronic access to
patient data
D5.5 Technical recommendations for further deployment
Public Page 47 of 77 v1.0 / 18th December 2013
Device-
Interface
Country
Condition Monitoring device Means of
Transmission
Aggregation
Gateway in Home
(Application
Hosting Device)
Means of
Transmission
Personal
Health
Record
Electronic Health
Record
Spain COPD
Nonin 4100 pulse
oximeter, Siebelmed
Datospir Micro C
spirometer, AVITA Arm-
Type Blood Pressure
Monitor BP65 Series,
AVITA wireless weight
scale
Wireless
Nokia 5800 Xpress
Music Mobile
phone
GPRS/3G LinkCare LinkCare
Sweden CVD
EKG - Zenicor;
Pedometer - Omron
Walking Style X; Polar
FT2 pulse watch; Blood
pressure - Omron M6
Comfort
Wireless for
EKG; all others
manual entry
EKG machine (has
radio in device);
Home Computer
with MS Outlook;
Mobile Phone with
MS Outlook
GSM/GPRS,
Internet Manual entry
Sweden Diabetes Many brands – is
determined by patient Manual entry
Home Computer
with MS Outlook
and Medical Data
Application; Mobile
Phone with MS
Outlook
GSM, Internet
(Web) Manual entry
The following section looks at how these devices and interfaces compare to the applicable standards.
4.3 Standards
The IAB has analysed the technical architecture of each pilot and compared it with the Continua and IHE recommendations. The
following table considers each data transmission interface (PAN, LAN, WAN and the Health Reporting Network; for reference, see
Figure 1), lists the relevant standards for Open Systems Interconnection layers for data, protocol and transport from Continua and IHE,
and juxtaposes them with the standards used in each pilot.
D5.5 Technical recommendations for further deployment
Public Page 48 of 77 v1.0 / 18th December 2013
Table 4: Standards Comparison
OSI
Layers Continua V.1 IHE Austria Denmark Finland Greece Germany Italy Norway Spain Sweden
Personal Area Network (PAN) Interface
Data IEEE 11073
PHD (11073-
104ZZ)
Device
Observation
Reporter
(IEEE
11073-
10101)
Recommended
use of IEEE
11073, PHD
Diabetes –
.jpg file;
National
EDI
standards
COPD –
proprietary
Recommen
d use of
IEEE 11073
PHD
Proprietary -
Card Guard
Proprietary Proprietary Proprietary -
LifeScan
Manual
entry,
Proprietary-
Zenicor
Protocol IEEE 11073
PHD (11073-
20601)
Device
Observation
Reporter
(IEEE
11073-
10201)
Recommended
use of IEEE
11073, PHD
Recommen
d use of
IEEE 11073
PHD
Proprietary -
Card Guard
Proprietary Proprietary
wired and
wireless
Proprietary
– LifeScan –
Polymap
Wireless
Manual
Entry,
Proprietary-
Zenicor
Trans-
port
USB Personal
Health,
Bluetooth (BT)
Health Device
Profile (HDP)
Agnostic USB, BT USB Require
USB, BT or
Manual
entry as per
Continua
1.0
BT, Acoustic
with
telephone,
SDIO with PT
Plug
(Glucometer
module to
PDA)
BT, USB USB SSP,
Manual entry
RS232, BT
SPP
BT, USB Acoustic
coupling
with
telephone,
Manual
entry
Local Area Network (LAN) Interface
Data IEEE 11073
PHD (11073-
104ZZ)*
Device
Observation
Reporter
(IEEE
11073-
10101)
Recommended
use of IEEE
11073, PHD
Proprietary Recommen
d use of
IEEE 11073
PHD
Proprietary Proprietary Proprietary
D5.5 Technical recommendations for further deployment
Public Page 49 of 77 v1.0 / 18th December 2013
OSI
Layers Continua V.1 IHE Austria Denmark Finland Greece Germany Italy Norway Spain Sweden
Protocol IEEE 11073
PHD (11073-
20601)*
Device
Observation
Reporter
(IEEE
11073-
10201)
Recommended
use of IEEE
11073, PHD
Proprietary Recommen
d use of
IEEE 11073
PHD
Proprietary Proprietary
Trans-
port
ZigBee Health
Care Profile
(HCP) IEEE
802.15.4*
Agnostic USB, BT-ANT,
Manual entry
Require
USB, BT or
Manual
entry as per
Continua
1.0
BT, RFID
for Patient
Identificatio
n
BT Class
I, USB
Wide Area Network (WAN) Interface
Data HL7 v 2.6
messages*
HL7 v 2.6
messages
HL7 CDA R2,
L1, L2, L3
EDI and
proprietary
Proprietary -
Card Guard
Proprietary Proprietary Proprietary -
NST
Proprietar
y LinkCare
Proprietary
Protocol IHE-PCD-01* IHE-PCD-01 TCP/IP (VPN) TCP/IP Proprietary -
Card Guard
TCP/IP Proprietary TCP/IP Proprietar
y LinkCare
TCP/IP
Trans-
port
Web Services
WS-I Basic
Profile*
Agnostic GSM or web-
based, WiFi,
UMTS
GSM Web based GSM, GPRS,
telephone
GPRS GPRS,
UMTS, PSTN,
ADSL, GMS
GSM,
3G/Edge/G
PRS, WiFi
GPRS or
3G
GSM,
GPRS, Web
based
Health Reporting Network (HRN) Interface
Data HL7 CDA
R2/PHM*
HL7 CDA R2 HL7 CDA R2
L1, L2, L3
EDI (DIS-91
Medcom
Standard)
and
Proprietary
Recommend use of
PHMR as
per
Continua
guidelines -
must
interface
with Effica
EHR system
Proprietary -
Card Guard
Anticipate
CDA L2 R2
– do not
have
interface to
HIS portal
yet
HL7 CDA R2 Proprietary -
NST
Proprietar
y LinkCare
Manual -
Swedish
law
prohibits
electronic
interfacing
D5.5 Technical recommendations for further deployment
Public Page 50 of 77 v1.0 / 18th December 2013
OSI
Layers Continua V.1 IHE Austria Denmark Finland Greece Germany Italy Norway Spain Sweden
Protocol IHE
XDR/XDS.b*
IHE
XDR/XDS.b
Proprietary -
Card Guard
IHE XDS.b Proprietary -
NST
Proprietar
y LinkCare
Manual
Trans-
port
SOAP 1.2,
ebXML 3.0
(RIM, RSS),
MTOM, HTTP,
email*
SOAP 1.2,
ebXML 3.0
(RIM, RSS),
MTOM,
HTTP,
email, XOP
(ITI-TF2b,
Rev 6)
HTTP, XML,
DaMe+
HTTP, XML Web based Telephone SOAP,
XML,
HTTPS
SOAP 1.2,
ebXML 3.0
(RIM, RSS),
MTOM, HTTP
HTTPS and
XML-RPC
Manual
Among the key findings are:
Where data is transmitted electronically, proprietary, non-standards-compliant data transfer methods remain prevalent.
Mobile phones and smart phones will be important data hubs and transmitters. However, products using the Continua and IHE
standards are not readily available, i.e. there is a limited choice for the providers to choose from.
The variety of infrastructures and approaches among the pilots for similar services is considerable. Data types collected for the
same conditions vary considerably. Despite advances in telemedicine and interoperability, the telephone and manual entry
remain common features in many pilots.
There remain important legal and regulatory barriers, e.g. Norwegian and Swedish laws do not allow a patient-acquired
measurement to be directly and automatically transferred into an EHR that is government or healthcare organisation owned.
D5.5 Technical recommendations for further
deployment
Public Page 51 of 77 v1.0 / 18th December 2013
4.4 Local issues
4.4.1 Germany
Germany had originally used a Samsung 51 mobile phone, however they noticed
that the Bluetooth implementation caused frequent interruptions between the mobile
phone and medical device, so they replaced the mobile phone handset with an HTC
ChaCha.
Germany also experienced issues with one of their pulse oximeter devices in which
the firmware produced instability.
Lastly, Germany replaced the weight scale due to instability when the patient
stepped on it.
4.4.2 Norway
Norway identified issues with Windows Mobile 6.5, and found that the complexity
made the mobile phone user interface less friendly for the elderly population. In
addition, the selection of mobile phones available that had a user-friendly profile for
the elderly population was limited. This issue is solved by implementing a shell-
application that can be used on the phone which the user would prefer.
Norway also experienced a sudden stop in deliveries of HTC Touch 2, almost
overnight, although vendors had claimed it would stay available for quite a few more
months. The project therefore had to change to HTC HD Mini, resulting in having to
spend extra hours in rewriting code. Further, as of early 2013, the Few Touch
Application has been rewritten (ported) to work with the Android operating system.
Norway had several issues with their BlueTooth (BT) interfaces between the
glucometer and mobile phone. Two dealt with how the BT pairing occurred using a
PIN, and how this differed as the mobile phone handsets changed as mentioned
above. Two others dealt with the wireless adaptor for the glucometer; first the BT
connection would timeout before all of the data from the glucometer was transferred,
second, when original glucometer vendor updated their device, it did not have an
undocumented BT feature which would trigger a data transfer command upon
removal of the glucose strip, therefore, a new glucometer had to be procured.
Lastly, Norway noted that over the course of their project (1½ years) technology had
advanced rapidly which, in the eyes of their users, made their technology seem
outdated.
4.4.3 Greece
Greece experienced issues with the device to mobile phone, and mobile phone to
server interface. They did a pilot project which led them to procure a feature phone
(as opposed to a smart phone or PDA) because elderly users required a simple
user interface.
Greece experienced some issues with their Bluetooth interface between the medical
device and mobile phone. The weight scale had been enabled to automatically pair
D5.5 Technical recommendations for further
deployment
Public Page 52 of 77 v1.0 / 18th December 2013
with a BT enabled mobile phone; unfortunately, it would either pair with the first BT-
enabled mobile phone it ‘found’ or it cycled around trying unsuccessfully to pair with
any BT-enabled mobile phone within a certain range.
Greece also replaced their weight scale due to it ‘tipping over’ when patients did not
step on the centre.
Greece had issues with their glucometer coming with strips that required a larger
blood sample than what some of the patients used (1.8 ml versus 0.7 ml of blood for
sample); smaller sample strips were procured for use in the pilot.
Greece experienced difficulties with remote or tele-spirometry. Spirometry usually
requires significant effort on the part of the patient to ensure a quality measurement.
Greece had to provide extra training on the use of the spirometer at the patient’s
home.
Greece also used their pilot to address the clinical information workflow. They
devised a tele-cardiology centre where a cardiologist was on call to address patient
issues while a trained nurse would be reviewing the cardiology information being
received from the patient. This is similar to a tele-radiology concept. Proper alarm
and date filtering and delegation is necessary to efficiently utilise clinician specialty
resources, and hopefully bring about the proposed economic benefits of remote
monitoring.
4.4.4 Spain
Spain had issues with the device to mobile phone interface, and spent extra
resources to develop the data exchange interface.
Spain also had issues with the video teleconferencing quality due to bandwidth
issues in the patient's home.
4.4.5 Denmark
With regard to standards based infrastructure, Denmark had a very robust
standards based infrastructure using the Electronic Data Interfacing (EDI) standards
that have been developed for healthcare (examples are of MEDDIS, MEDREF and
others that have been developed by MedCom for Denmark and Sweden). However,
this is in direct competition with the HL7 standard which is used elsewhere and
recommended by Continua and IHE. It will be difficult to reconcile Europe-wide the
different messaging standards of EDI and HL7 unless there is a way to ‘envelope’
each for interoperability between systems.
4.4.6 Finland
Finland experienced some medical device to mobile phone interface integration
issues early on, similar to the experiences of the other pilot sites.
Finland also realised that their PHR application was not as scalable as it needed to
be to serve the EKSOTE region, so will be procuring a newer version of the PHR
application to ensure they can deploy it throughout the region.
D5.5 Technical recommendations for further
deployment
Public Page 53 of 77 v1.0 / 18th December 2013
4.4.7 Italy
Italy had to change vendors for their glucometers, due to availability. Unfortunately,
there was a 10% measurement variation between the two different vendors’
glucometer reading. This necessitated a change in the analysis and filtering ranges
used at the regional health centre for determining patient status and alarm
thresholds.
4.5 Industry
Many pilot projects had difficulties identifying medical devices on the market that
could interface with the mobile phones or use the data and network standards as
recommended by Continua and IHE-PHD. One participant mentioned that their
national market did not seem large enough for many competitors in this realm just
yet. Moreover, some of the legal issues regarding use of the native language in all
contractual and equipment information was a barrier for new international players to
enter their market.
The IAB prepared a country-by-country analysis of telemedicine vendors and
products to facilitate the identification of appropriate industry partners (see Appendix
B “State of the Industry”). At the beginning of the project, about 60% of the
telehealth market was “owned” by the services industry (telecommunications) and
40% was owned by the device manufacturers, and there seemed to be no one
market leader in any country, which led to intense competition. The market was full
of smaller and medium-sized players, some of whom may not belong to the
standards community of Continua and IHE. As of 2013, that has changed, with
Philips, Tunstall, GE Healthcare, BodyTel, Aerotel, Honeywell and Polycom
emerging as the dominant (listed in order of dominance) vendors across most of
Europe per Frost and Sullivan 2013 (European Remote Patient Monitoring Markets,
Report #M8D5-01).
There are three companies whose products are used in Renewing Health who are
also Continua members: Nonin, Omron and Polar. These companies might offer a
route to implementing Continua certified products in the future. However,
interoperability at device level may only have a minor overall impact. The EN-
ISO11073 standards included within the Continua Guidelines provide for
interoperability of devices, effectively allowing systems designers some choice of
the peripherals they recommend. IHE-PCD provides for some integration between
a remote monitoring service and an electronic clinical record, but again where health
services have been slow to adopt electronic records this solution is ahead of its
time. The market dynamics for remote monitoring would change if the patient-
provider interface was opened up – offering patients true choice in the hub device
they use, whether mobile phone or a highly usable bespoke device. There are a
number of factors that will make this a complex undertaking – including the absence
of agreed clinical protocol and the demands of device regulation.
The market for telemedicine products in Europe is consolidating and maturing;
however, the macroeconomic issues within Europe may slow this down
considerably intra-regionally as well as contribute to further fragmentation of the
market. The overall market size is a barrier to further investment by suppliers in
their products. Interoperability and integration are not yet seen as an engine of
growth. A wider range of offers and the realisation of economies of scale are likely to
occur when consumers rather than health systems are able to drive the market.
D5.5 Technical recommendations for further
deployment
Public Page 54 of 77 v1.0 / 18th December 2013
Payment systems and regulation act against this. In particular, regulators have yet
to clearly define requirements for interoperable systems, including both traditional
medical devices and software. This leaves suppliers managing their risk by retaining
proprietary interfaces to maintain control of their system.
D5.5 Technical recommendations for further
deployment
Public Page 55 of 77 v1.0 / 18th December 2013
5. IAB industry outreach: the shop talks
The IAB conducted a number of industry outreach initiatives to educate the industry
about the application of technology in real life settings, integration and other
technical issues on the user side, and the state of the market in general. The
principal initiatives were three events that featured presentations from Renewing
Health pilots of their telemedicine equipment. To maximise industry impact, these
Shop Talks were held in conjunction with industry events.
The first such event, called “industry meet users”, was held in conjunction with the
IHE-Europe Connectathon in Pisa, Italy, on 13th April 2011. IAB members Continua,
COCIR, Eucomed, GSMA, IHE-Italy and the Renewing Health Project Management
were represented, as well as a number of participating companies in the
Connectathon. Four pilot sites presented their equipment there: Finland, Italy,
Norway and Spain.
The second event, called Telemedicine Shop Talk, was held on 13 th October 2011
in Brussels, coinciding with Eucomed’s MedTech Forum, but held separately due to
limited space available in the MedTech Forum’s agenda. The event attracted a
significant turnout from interested companies as well as from the European
Commission. Three pilot sites (Austria, Denmark and Sweden) demonstrated their
technical systems. They then gave abridged versions of the presentations during a
side event of the MedTech Forum.
The third IAB meeting was held in conjunction with GSMA’s Mobile World Congress
on 29th February 2012 in Barcelona, Spain. Due to MWC agenda constraints and
cost, the event was held as a side event at Hospital del Mar (with coaches provided
for MWC attendees), and was supported by the Catalan Ministry of Health and the
TicSalut Foundation, which organised an overview of mHealth in Catalonia before
Renewing Health pilots from Germany and Greece presented their technical
solutions (which included data transfer over mobile phone networks).
A summary of all pilot technical demonstrations can be found in appendix D.
The IAB also reported on findings from the Renewing Health to member companies
of the Continua Health Alliance at Continua meetings in Belfast (2010) and
Edinburgh (2013).
D5.5 Technical recommendations for further
deployment
Public Page 56 of 77 v1.0 / 18th December 2013
6. Conclusions and recommendations
Renewing Health seeks to promote the use of international standards and the
progressive convergence towards common interoperable architectures with a view
to subsequent scaling up at national and European levels.
The analysis of the standards situation in section 4.3 indicates that few data
transmissions follow standardised electronic protocols. In the more advanced pilots,
proprietary systems seem the systems of choice. Some data is transmitted by voice
calls and manual data entry. Pilots reported difficulties during procurement in finding
devices that adhere to standards and protocols promulgated by Continua and IHE.
Standards compliance has not advanced much.
This is partly a matter of timing. Standards and protocols are recent developments
and have not yet had time to spread. Usually standards are written broadly to meet
a larger set of requirements. However, this means that there will be variability in the
information that comes across an interface in a standard format (standards usually
have mandatory and optional characteristics). As devices change in the evolution of
production, key features that an interface standard relies upon can be eliminated,
causing interface issues (example: Norway glucometer changes). Regional
differences may limit device availability in the market (language issues, logistic /
supply issues). Syntactic as well as semantic standardisation is crucial for a plug
and play environment. One example: using Continua’s Health Device Profile (HDP)
constrains the underlying standards so that there is less variability and better
conformance across interfaces.
Other factors are at play. It has turned out that users in search of standards-
compliant products have had difficulties finding them. Few vendors have brought
products to market, and if they have, they may not be compatible with local markets
where Renewing Health projects are required to buy. There may be a number of
reasons for this:
Medical device regulation acts to encourage closed end-to-end monitoring
systems by placing responsibility on the suppliers for assuring safety. Players
in the mobile industry have expressed concerns, partly driven by regulations in
other geographies, about the possibility that a mobile handset used in
monitoring could be considered as falling within the scope of medical device
regulations.
Regulation also means that the medical device industry typically works to
much longer product lifecycles than is common in IT-related industries.
Most monitoring systems on the market have been tailored to the complex
usability needs of older people. They usually consist of vertically integrated
specialised hubs. These hubs do not usually require the use of a smart
phone. Moreover, users (especially older people) are not always comfortable
with smart phones and their size and interfaces.
Current interoperability standards have focused on peripheral devices and
whole-system integration, and have yet to impact on areas that would truly
open up the consumer-provider interface and create fresh solutions.
Cost could also be a factor, where standards adoption is confined to the
premium end of the market and used as a differentiator.
D5.5 Technical recommendations for further
deployment
Public Page 57 of 77 v1.0 / 18th December 2013
The fragmented nature of the European markets, both nationally and in terms of the
purchasing organisations, also means that demand for interoperability has been
slow. Some local markets have been intensely competitive, but interoperability has
not been seen as a differentiator that would justify the additional investment involved
in modifying current systems.
Since the beginning of the Renewing Health project, the market for telemedicine
products (in Europe and beyond) has progressed to adolescence and vendor
consolidation across Europe. Frost & Sullivan’s 2013 report on the European
market for remote patient monitoring summarises it as “gaining momentum, but
uncertain times ahead,” mainly due to the economic downturn in several European
countries. The benefits of standards and interoperability are slowly proving their
value to the more educated buyers, who are asking about or mandating them in
their procurements. For others, there is still a learning curve with regard to the
benefits of standards based procurement for remote patient monitoring. As a result,
while standards-compliant products are in the pipeline, industry has mixed
incentives to bring them to market, dependent upon the region or country procuring
the equipment.
Policy makers, consumers, buyers and industry agree on the benefits of
interoperability, but the tipping point has not yet been reached European-wide.
Renewing Health represented a unique opportunity to create, even on a small scale,
common and coordinated action. Promoting standards and interoperability is a task
for all stakeholders, and the IAB addresses its recommendations to all.
Achieving better interoperability and scalability of services were beyond the scope
and time frame of the Renewing Health project. However, the project helped push
in the right direction. The IAB recommended a concerted effort among all players in
the project to help. Additionally, several of the pilot sites shared their findings and
recommendations with the follow-on project United4Health.
For healthcare providers: to support the advance of standards by
expressing their preference for standards-compliant products by purchasing
them. Where appropriate, this may include procurement documents stating a
preference for the use of specific standards and guidelines. Where possible,
the requirement for interoperability with other existing systems should also be
required. Where appropriate standards or guidelines are not available, remote
monitoring pilots should contract with such suppliers who commit to
convergence towards standards compliance.
For industry: to bring products to market that meet guidelines and protocols
where they exist, and to accelerate the development of guidelines and
protocols where they do not (especially for those use cases that lend
themselves to remote monitoring). Moreover, to understand that at either the
interface between the gateway and aggregation point for analysis, or the
interface between the aggregation point for analysis and the healthcare
enterprise, messaging standards and eventually data standards will be
demanded. Telehealth or remote monitoring system suppliers will need to
decide if they will invest in implementing standards at the data source, or
converting their information to standard designations at the interface to the
customer. Lastly, they may be asked to integrate not just technology but
clinical services on their side of the interface point. That interface point will be
at the output of either a home gateway or a telehealth service centre.
D5.5 Technical recommendations for further
deployment
Public Page 58 of 77 v1.0 / 18th December 2013
For the remote monitoring project and funders: to be realistic about the
state of the market(s), the status of applicable standards, and industry’s
capacity to deliver products that allow for subsequent scaling up within a
project’s time frame.
To assist Renewing Health pilots in promoting the demand for standards, the IAB
prepared a specification document which could be included in the pilot sites ’
procurement documents. Owing to the limited availability of products utilising the
standards in the market, the document specified a preference for the use of the
standards, rather than a mandatory requirement. The specification document is
shown in the Appendix C.
To make the case for industry, the IAB shared relevant information regarding the
RH pilots, their architectures and issues among the members of Continua and
industry, with the message to accelerate the development of standards and
protocols for the use cases proposed by pilots.
D5.5 Technical recommendations for further
deployment
Public Page 59 of 77 v1.0 / 18th December 2013
Appendix A - References
European Remote Patient Monitoring Markets, Report #M22C-56, Frost &
Sullivan, June 2008, www.frost .com.
European Remote Patient Monitoring Markets, Report #M8D5-01, Frost &
Sullivan, 8 Jan 2013, www.frost.com
Competitiveness and Innovation Framework Programme, ICT Policy and Support
Program, ICT-PSP/2009/3, Annex I, Description of Work, Renewing Health,
REgioNs of Europe WorkINg toGether for HEALTH, Grant agreement no.: 250487,
Version 9, 18 January 2010.
eHealth-INTEROP Report in response to eHealth Interoperability Standards
Mandate, SA/CEN/ENTR/000/2007-20 eHealth Mandate M/403-Phase 1, 10
February 2009, http://www.ehealth-interop.eu.
D5.5 Technical recommendations for further
deployment
Public Page 60 of 77 v1.0 / 18th December 2013
Appendix B - State of the Industry
The Industry Advisory Board consists of member of industries who are either
members of the Continua Health Alliance or affiliated with Integrating the Healthcare
Enterprise Europe (IHE-Europe). Both organisations are classified as standards
promulgation organisations, i.e. they recommend the use of standards based
products; and if a standard is not available to meet a need, then they assist in
developing a standard. The specific industries involved in the Renewing Health
project are a subset of the healthcare industry, namely the medical device industry,
the telecommunications industry, and the electronic / personal health record
industry. Renewing Health is further constrained to focus on remote telehealth
systems, which also includes the commercial wellness industry.
Telehealth is a fairly new technology in the healthcare industry, and by its
heterogeneous nature can make adoption more difficult. According to Frost and
Sullivan in June 2008, the European market for telehealth is projected to be “$240M
with a projected compound annual growth rate of 12.5%”. However, the industrial
barriers to adoption of telehealth were in order of priority: “lack of reimbursement,
fast changing technology acting as a setback, privacy/confidentiality issues clouding
the market, and resistance of the aged population to embrace the new technology”.
Moreover, the market restraints for telehealth in Europe were listed as: “healthcare
processes depending on the general practitioner for constant advice to patients,
lack of pan-European standards, and high costs curbing the adoption rate”. This
IAB can only indirectly affect healthcare processes and costs, but it can assist in
identifying the technologies that are changing, recommend which and when to adopt
those technologies, as well as help drive telehealth to be more standards-based and
promote pan-European standards for telehealth.
Frost & Sullivan in 2013 had the following to say about the European market:
“Chronic disease management has been the focus of many recent health and home
care innovations, offering a significant opportunity to retain independence, avert
health complications, and reduce expenditures. Remote Patient Monitoring (RPM)
technologies have enabled or supported many of these innovations. The RPM
applications market in Europe in 2011 was worth $587.5 million. About 12.3% of this
amount was contributed by the telehealth applications as these are usually
developed by the original equipment manufacturers (OEM) and limited third-party
developers. The RPM applications market is estimated to grow at a rate of 5.0%
between 2012 and 2016….and is mainly driven by the increasing adoption of these
technologies in order to reduce public expenditure on healthcare. Many global
companies have set a strong foothold in the European market for RPM
technologies”
Nevertheless, “the current economic scenario prevailing in Europe negatively affects
the rapid adoption of technology. The struggling economies, such as Spain, are now
adopting austerity measures to save the economy, which is expected to affect the
healthcare market to a large extent. There is an increased focus on countries such
as the United Kingdom and Germany due to the growth momentum in their
economies, as well as the government’s encouragement for these healthcare IT
devices and solutions.”
There are nine countries involved in the Renewing Health programme: Austria,
Denmark, Finland, Germany, Greece, Italy Norway, Spain and Sweden. According
D5.5 Technical recommendations for further
deployment
Public Page 61 of 77 v1.0 / 18th December 2013
to the previously referenced Frost and Sullivan 2008 report, the following vendors
have the primary market share for telehealth products in the countries listed.
Overall, the report also mentions that 60% of the telehealth market is owned by the
services industry (telecommunications) and 40% is owned by the device
manufacturers. Additionally, there is no one market leader which leads to intense
competition at European level to gain market lead.
Table 5: Leading Telehealth Vendors listed by Country - 2008
Country Telehealth Vendor
Austria Not analysed
Germany Philips Healthcare, Health Hero Network (now
Bosch), BodyTel Scientific Inc, and Docobo
Greece Not analysed
Italy Biotronik, Health Hero Network (Bosch), Tunstall
Healthcare Group, and Philips Healthcare
Spain Philips Medical Systems, Aerotel Medical Systems,
CardGuard AG and Viterion Telehealthcare LLC
Scandinavia: Finland,
Denmark, Norway, Sweden
Philips Medical Systems, Biotronik, CardGuard AG,
and Health Hero Network (Bosch)
Of the companies listed in Table 5, Philips Healthcare, Health Hero Network (now
Bosch) and Tunstall Healthcare Group AG are members of the Continua Health
Alliance, while Philips Healthcare is the only participating member in IHE-PCD.
There were some changes, mainly consolidation and dominance by the global
vendors, in the market in 2013, as per Frost & Sullivan with the participants shown
in the table below:
Table 6: Telehealth Vendors listed by Country - 2013
Country Telehealth Vendor: Major dominant
participants; other notable participants
Austria Not analysed
Germany Bosch, Tunstall, Philips: Aerotel, Bodytel
Greece Not analysed
Italy Philips, GE Healthcare, Honeywell; Aerotel,
Tynetec, Polycom
Spain Philips, GE Healthcare, Honeywell; Aerotel,
Tynetec, Polycom
Scandinavia – Finland,
Denmark, Norway, Sweden
Philips, GE Healthcare, Honeywell; Aerotel,
Tynetec, Polycom
Of the companies listed in Table 6, BodyTel, Bosch, GE Healthcare, Philips, Tunstall
and Tynetec are members of the Continua Health Alliance, while GE Healthcare and
Philips are the only participating member in IHE-PCD.
D5.5 Technical recommendations for further
deployment
Public Page 62 of 77 v1.0 / 18th December 2013
B.1 Continua Certified Products
At the beginning of the Renewing Health project and as identified in D5.1, in
November 2010 there were 16 devices on the market that were Continua certified.
At the time of this final document, (August 2013), there are 77 devices on the
market that are Continua certified. (For more information see
http://www.continuaalliance.org/products/product-showcase).
B.2 IHE-PCD 01 or IDCO Compliant Companies
This section identifies IHE-PCD 01 or IHE PCD IDCO compliant companies as of
August 2013 (for more information see
http://connectathon-results.ihe-europe.net/index.php?highlight=1_0
or http://product-registry.ihe.net/PR/searchHome.seam?cid=1136):
B.2.1 Device Enterprise Communication (DEC)
Device Enterprise Communication (DEC) IHE-PCD-01 as of European
Connectathon 2010, 2011 and 2013
Device
Observation
Consumer
Device
Observation
Filter
Device
Observation
Reporter
B. Braun Medical * *
CapsuleTech Inc. * *
Cardinal Health *
CareFusion * *
Cerner Corporation * *
Draeger Medical Systems, Inc. * *
Epic Systems Corporation *
Fresenius Kabi *
GE Healthcare * *
Hospira * *
Live Data *
Philips Medical Systems * *
RVC bv *
Spacelabs Healthcare *
Surgical Information Systems *
Welch Allyn, Inc *
D5.5 Technical recommendations for further
deployment
Public Page 63 of 77 v1.0 / 18th December 2013
B.2.2 IHE-PCD Implantable Device Cardiac Observation (IDCO)
"IHE-PCD Implantable Device Cardiac Observation (IDCO) as of European
Connectathon 2010 and August 2013"
Implantable
Device -
Cardiac -
Consumer
Implantable
Device -
Cardiac -
Reporter
Observation
Creator
Observation
Processor
BIOTRONIK *
Boston Scientific *
Epic Systems Corporation *
GE Healthcare * *
Lumedx Corp *
Medical Micrographics Inc *
Medtronic *
NextGen *
St. Jude Medical AB * *
D5.5 Technical recommendations for further
deployment
Public Page 64 of 77 v1.0 / 18th December 2013
Appendix C - Technical Specification for
Procurement
This section contains suggested Device and Health Data Interface Specifications for
partners of the Renewing Health project to use during procurement.
Preferred Device and Remote Monitoring Interoperability Standards
The following interoperability standards are recommended and preferred when
member countries are procuring technical equipment in support of the Renewing
Health Project. These standards are based on standards used for Continua
certification. If possible, buyers are best off procuring devices / products which are
certified or are in the process to being certified to meet the CHA Version 2010
Interoperability Guidelines (www.continuaalliance.org) and/or conform to the
referenced IHE-PCD devices profile
(wiki.ihe.net/index.php?title=Patient_Care_Devices) where Continua certification is
unavailable. With Continua certification, further constraints within the referenced
standards are specified. By promoting devices that conform to these specifications,
we move towards better interoperability between the different components of the
remote monitoring system. Figure 25 below shows a sample remote monitoring
system with the components and interfaces. The standards between the interfaces
are shown. Following the figure is a more complete listing of the standards that
Continua refers to in its guidelines for each of these interfaces. Note that the
Continua Guidelines specify additional constraints on top of the referenced
standards to guarantee interoperability: to promote full interoperability, not only
these standards but also the additional constraints as specified by the Continua
Guidelines need to be followed.
Figure 25: Sample remote monitoring system
D5.5 Technical recommendations for further
deployment
Public Page 65 of 77 v1.0 / 18th December 2013
1. Personal Area Network (PAN) / Local Area Network Interface (LAN)
a) Data
i) Blood Glucose Meters (ISO/IEEE 11073-10417)
ii) Blood Pressure meter (ISO/IEEE 11073-10407)
iii) Thermometers (ISO/IEEE 11073-10408
iv) Weight scale (ISO/IEEE 11073-10415)
v) Pulse Oximeter (ISO/IEEE 11073-10404)
vi) Automated pill dispensing systems – Medication Monitor (ISO/IEEE
11073-10471)
vii) Cardiovascular (ISO/IEEE 11073-10441)
viii) Strength (ISO/IEEE 11073-10442)
ix) Activity Hub (ISO-IEEE 11073-10471)
x) For the case of monitoring an implant, conformance to Integrating the
Healthcare Enterprise (IHE)-Patient Care Domain (PCD)- Implantable
Device – Cardiac- Observation (IDCO) is recommended
b) Transport – Optimised Data Exchange (ISO-IEEE 11073 – 20601/20601a)
c) Protocol
i) Wired – USB Personal Health
ii) Wireless PAN – Bluetooth (BT) Health Device Profile (HDP)
iii) Wireless LAN – ZigBee Health Care Profile (HCP), IEEE 802.15.4
2. Wide Area Network interface
The primary role of the WAN Interface is to establish an interoperable interface for
transferring measurements to backend services across a Wide Area Network such
as the internet.
a) Data – Health Level 7 (HL7) version 2.6 message.
b) Transport – conformance to Integrating the Healthcare Enterprise (IHE)-
Patient Care Devices (PCD)-01. The underlying standards should map the
data as specified above to the HL7 message.
c) Protocol – Web Services WS-I Basic profile.
D5.5 Technical recommendations for further
deployment
Public Page 66 of 77 v1.0 / 18th December 2013
3. Health Reporting Network Interface
This interface can be used to transfer health report summaries to and from various
types of electronic health records, such as a hospital’s Enterprise Health Record
(EHR), a physician’s Electronic Medical Record (EMR) or a Personal Health Record
service (PHR) used by the patient:
a) Data – HL7 Clinical Document Architecture (CDA) R2, Personal Healthcare
Monitoring Report (PHMR).
b) Transport – IHE Cross-Enterprise Document Reliable Interchange (XDR)/
Cross-Enterprise Document Sharing (XDS.b), Cross-Enterprise Document
Media Interchange (XDM).
c) Protocol – Simple Object Access Protocol (SOAP 1.2), Message
Transmission Optimisation Mechanism (MTOM), Hyper Text Transmission
Protocol (HTTP), and/or email.
D5.5 Technical recommendations for further
deployment
Public Page 67 of 77 v1.0 / 18th December 2013
Appendix D – Pilot Technical Demonstrations
Renewing Health pilot projects gave a public demonstration of their technical setup
in several Workshops over the length of the project. The first of these was called an
“Industry meet Users” event on 13th April 2011. The event was held as a satellite
meeting of the IHE-Europe Connect-a-thon in Europe and took place in the Stazione
Leopolda, Pisa, Italy, the Connect-a-thon site. Connect-a-thon participants had
been invited to attend. In addition, all IAB member organisations had broadcast the
invitation among their membership. About 40 to 50 people attended. Four pilot
sites demonstrated their technical systems: Finland, Norway, Italy and Spain.
The second of these was held in conjunction with the Eucomed MedTech Forum in
Brussels, Belgium, on 13th October 2011 and called “ShopTalk”. Several
representatives from the European Commission attended the event and three pilot
sites demonstrated their technical systems: Sweden, Denmark and Austria.
The third and final workshop called “mHealth in Action” was held in conjunction with
the GSM Association World Congress in Barcelona, Spain, on 29 th February 2012.
Participants were hosted by the Hospital del Mar. In addition to pilot demonstrations
by Germany and Greece, Catalonia also demonstrated three local regional mHealth
initiatives.
D.1 Finland Pilot Demo
Katya Rääpysjärvi showed Finland’s system using a mobile phone interface, web
personal health record application and a blood pressure meter using BlueTooth.
The main technical issues Finland had were that the glucometers they used are
from a variety of vendors, so standards for interoperability were not used, and in fact
the patient will be manually entering the glucometer data into the mobile phone
interface. This is the same issue with the weight scale.
D5.5 Technical recommendations for further
deployment
Public Page 68 of 77 v1.0 / 18th December 2013
Figure 26: Finland’s Equipment for Technical Demo: mobile phone and blood
pressure measurement device
Figure 27: Finland’s Personal Health Record application showing
physiological measurements
D5.5 Technical recommendations for further
deployment
Public Page 69 of 77 v1.0 / 18th December 2013
D.2 Norway Pilot Demo
Niklas Andersson showed Norway’s system using a glucometer, mobile phone
interface and research database health record. The information from the
glucometer was transferred via BlueTooth to the mobile phone. The mobile phone
had an application specifically built for diabetes tracking to include physiological
monitoring as well as a food and exercise diary along with educational materials.
Norway had several technical issues, mainly dealing with the glucometer and mobile
phone interface. First the BlueTooth driver had changed on the glucometer, which
had an undocumented feature regarding the sending commands from the
glucometer to the mobile phone. Then the mobile phone operating system did not
recognise or had changed the way in which it implemented the serial protocol with
BlueTooth. Last but not least, the mobile phone vendor decided to discontinue
distribution of the specific phone and mobile operating system that the Diabetes
tracking application had been coded for, so Norway had to rewrite the software
application to a new mobile phone operating system and hardware.
Figure 28: Niklas Andersson, Norway, showing mobile phone interface
D5.5 Technical recommendations for further
deployment
Public Page 70 of 77 v1.0 / 18th December 2013
Figure 29: Niklas Andersson, Norway, demonstrating glucometer
measurement
D.3 Italy Pilot Demo
Riccardo Maderna demonstrated Italy’s remote cardiovascular monitoring system
which comprised a blood pressure measurement device, weight scale, pulse
oximeter and a touchscreen computing for an interface. The medical devices used
BlueTooth to send the information to the Touchscreen device which displayed the
physiological value and then transferred it via a web portal to the electronic medical
record application.
D5.5 Technical recommendations for further
deployment
Public Page 71 of 77 v1.0 / 18th December 2013
Figure 30: Ricardo Maderna, Italy, demonstrating touchscreen interface with
blood pressure device
Figure 31: Italian pilot technical equipment: touchscreen interface, blood
pressure measurement device and pulse oximeter
D.4 Spain Pilot Demo
Dr Josep Roca and Lluis Solanell demonstrated Spain’s system which was a
module of their LinkCare remote monitoring program. They showed a blood
pressure monitor and pulse oximeter which used BlueTooth to send the
physiological information to a mobile phone which then interfaced with the LinkCare
database and electronic medical record system. Spain was also able to ‘push’
educational materials as well as questionnaires for the patient to the mobile phone
D5.5 Technical recommendations for further
deployment
Public Page 72 of 77 v1.0 / 18th December 2013
interface using the LinkCare database application. In earlier discussions with the
technical personnel from Spain, they had expressed some issues with the medical
device and mobile phone interface which were similar to those expressed by Finland
and Norway.
Figure 32: Spanish medical devices used in their pilot demonstration: blood
pressure measurement device, pulse oximeter, mobile phone and laptop
computer
Figure 33: View of Spanish mobile phone interface showing menu of action
items available for patient
D5.5 Technical recommendations for further
deployment
Public Page 73 of 77 v1.0 / 18th December 2013
D.5 Sweden Pilot Demo
Lennart Isaksson presented the Swedish Renewing Health pilot. The presentation
focused on specific Swedish requirements for using electronic means for gathering
patient information both diary-based and physiologically measurement-based.
Swedish has requirements for secure authentication of users of their electronic
medical records system. Moreover, all devices used for physiological
measurements must be CE-Medical marked. In the Swedish pilot, the patients were
responsible for providing their own medical devices and home computing devices.
Sweden had found that the use of the smaller mobile phone interface was difficult
for their elderly patients, so had ported their application to the iPad. Remote
measurement of a 1-lead EKG was demonstrated using the Swedish system.
Figure 34: Mr Isaksson during Swedish presentation showing medical devices
used
Figure 35: Swedish remote monitoring architecture for EKG
D5.5 Technical recommendations for further
deployment
Public Page 74 of 77 v1.0 / 18th December 2013
Figure 36: Zenicor EKG Device used for Swedish remote monitoring
demonstration
D.6 Denmark Pilot Demo
Claus Duedal Pederson demonstrated the MediSat system developed by Denmark
to provide remote monitoring support of COPD patients. The MediSat system is a
fully configured ‘suitcase’ which provides physiological measurement, video-
teleconferencing and telecommunication connectivity functionality. Denmark then
demonstrated a video teleconferencing real-time coaching session with spirometry.
Figure 37: Danish demonstration of spirometric measurement using video
teleconferencing coaching
D5.5 Technical recommendations for further
deployment
Public Page 75 of 77 v1.0 / 18th December 2013
Figure 38: Claus Duedal Pederson demonstrating Danish MediSat ‘suitcase’
The Danish MediSat ‘suitcase’ combines physiological measurements,
telecommunication connectivity and video capability.
D.7 Austria Pilot Demo
Hannes Steinberger discussed Austria’s architectures for support of Renewing
Health which ranged from remote monitoring using mobile architecture to home-
based nurses using other network based architectures. Another part of the
presentation highlighted ensuring the security of the transmissions as well as patient
data privacy. After the presentation, measurement of blood pressure was
demonstrated using the Austrian remote monitoring system.
Figure 39: Austrian presentation regarding use of mobile phone gateway with
medical device
D5.5 Technical recommendations for further
deployment
Public Page 76 of 77 v1.0 / 18th December 2013
Figure 40: Austrian demonstration of remote blood pressure measurement
D.8 Germany Pilot Demo
Karl Sussebach of Health Insight Solutions (HIS) presented the German
participation in Renewing Health through Pflegewerk, a private care organisation in
Berlin which provides ambulatory, social and other supportive care to residents. HIS
provides combined physiological and environmental monitoring for the residents.
Like other pilot sites, HIS had experienced some issues with Bluetooth, requiring
them to replace their mobile phone handset supporting Renewing Health. In
additon, they replaced their weight scale due to perceived instability when patients
stood on it. Following the presentation, remote glucose, pulse oximetry and blood
pressure monitoring were demonstrated using the HIS system.
Figure 41: Health Insight Solutions glucometer, mobile phone and pulse
oximeter used for remote monitoring demo – RH Germany
D5.5 Technical recommendations for further
deployment
Public Page 77 of 77 v1.0 / 18th December 2013
D.9 Greece Pilot Demo
Nansy Karanasiou of Vidavo presented the Greek Renewing Health telemonitoring
system. Greece is participating in all of the disease monitoring profiles of Renewing
Health so therefore is measuring all of the physiological parameters in all of the
clusters. Greece shared that they also had BlueTooth technical issues which
necessitated a change in the Bluetooth profile on the weight scales. They also had
issues with their glucometer strips requiring a larger sample of blood initially, which
they corrected by procuring strips that required less blood for sampling. Ergonomic
issues that were encountered included older patient difficulties with the mobile
phone interface (small keys and screens) and attainment of good spirometric
readings remotely. After the presentation, a demonstration of the system used by
Greece for remote monitoring of glucose and blood pressure was given.