ICT PSP Accessibility, Ageing and Social Integration …v1.0+RH... · The information in this...

77
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 / 18 th 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

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.