D4.1 Pilot Level Service Specification for CareWell Services

106
The CareWell project is co-funded by the European Commission within the ICT Policy Support Programme of the Competitiveness and Innovation Framework Programme (CIP). Grant Agreement No.: 620983 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 D4.1 Pilot Level Service Specification for CareWell Services WP4 INTEGRATED CARE ARCHITECTURE AND SERVICE SPECIFICATION Version 1.0, date 23 rd July 2015 a

Transcript of D4.1 Pilot Level Service Specification for CareWell Services

Page 1: D4.1 Pilot Level Service Specification for CareWell Services

The CareWell project is co-funded by the European Commission within the ICT Policy Support Programme of the Competitiveness and Innovation Framework Programme (CIP). Grant Agreement No.: 620983

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

D4.1 Pilot Level Service

Specification for CareWell

Services

WP4 INTEGRATED CARE ARCHITECTURE AND SERVICE SPECIFICATION

Version 1.0, date 23rd July 2015

a

Page 2: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 2 of 106 Public

DOCUMENT INFORMATION

ORGANISATION RESPONSIBLE

Osakidetza

AUTHORS

Faria, Angel (Osakidetza)

Gonzalez, Nicolás (Osakidetza)

Lewis, Leo (IRH)

CONTRIBUTING PARTNERS

DELIVERY DATE

31st December 2014

DISSEMINATION LEVEL

P Public

VERSION HISTORY

Version Date Changes made By

0.1 08/10/2014 Changes in Index Angel Faria

0.2 20/11/2014 Structure of document Angel Faria

0.25 15/12/2014 Updated Methodology Angel Faria

0.3 19/01/2015 Sections 3.1, 3.2, and 4.1, 4.2 added Angel Faria,

Leo Lewis

0.4 28/01/2015 Section 6, 1.4, 5.1 added; updates following

review by pilot sites

Angel Faria

0.9 12/02/2015 Further updates Leo Lewis

0.10 13/02/2015 Section 1.4.2 moved to Appendix A, much of

section 5.2 moved to Appendix B; formatting

standardised

John Oates

0.11 18/02/2015 Revised figures Ane Fullaondo

0.12 7/07/2015 Update from Veneto and LSV Kazimierz

Frączkowski,

Francesco Marchet

1.0 23/7/2015 Version for issue John Oates

OUTSTANDING ISSUES

Full quality review

FILENAME

D4.1 v1.0 Pilot level Service Specification for CareWell service

STATEMENT OF ORIGINALITY

This deliverable contains original unpublished work except where clearly indicated

otherwise. Acknowledgement of previously published material and of the work of

others has been made through appropriate citation, quotation or both.

Page 3: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 3 of 106 Public

Executive Summary This deliverable defines the CareWell ICT-enabled service specification and IT

architecture in terms of examining the current situation in relation to information and

communication mechanisms and technologies, and those which will be implemented in

each pilot site to support the implementation of the care pathways.

In addition, it provides details of standards and other relevant technical guidance,

together with information on the security and confidentiality processes followed by each

of the pilot site.

Page 4: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 4 of 106 Public

Table of Contents

EXECUTIVE SUMMARY 3

TABLE OF CONTENTS 4

1. INTRODUCTION 8

1.1 Introduction to the project 8

1.2 Aim of this deliverable 8

1.3 Structure of the deliverable 8

1.4 Glossary 8

2. METHODOLOGY 10

3. CURRENT SERVICES AND TECHNOLOGICAL MODELS 15

3.1 Introduction 15

3.2 Basque Country 16

3.2.1 Current ICT-enabled service specification 16

3.2.2 Current IT architecture 17

3.3 Croatia 21

3.3.1 Current ICT-enabled service specification 21

3.3.2 Current IT architecture 22

3.4 Lower Silesia 24

3.4.1 Current ICT-enabled service specification 24

3.4.2 Current IT architecture 25

3.5 Veneto 26

3.5.1 Current ICT-enabled service specification 26

3.5.2 Current IT architecture 28

3.6 Puglia 29

3.6.1 Current ICT-enabled services specification 29

3.6.2 Current IT architecture 30

3.7 Wales 32

3.7.1 Current ICT-enabled service specification 32

3.7.2 Current IT architecture 34

3.8 Analysis of current service specification vs IT systems 37

4. CAREWELL ICT-ENABLED SERVICE SPECIFICATION AND

IT ARCHITECTURES 39

4.1 Basque Country 39

4.1.1 CareWell service specification 39

4.1.2 CareWell IT architecture 40

Page 5: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 5 of 106 Public

4.2 Croatia 43

4.2.1 CareWell service specification 43

4.2.2 CareWell IT architecture 44

4.3 Lower Silesia 47

4.3.1 CareWell service specification 47

4.3.2 CareWell IT architecture 49

4.4 Veneto 50

4.4.1 CareWell service specification 50

4.4.2 CareWell IT architecture 51

4.5 Puglia 53

4.5.1 CareWell service specification 53

4.5.2 CareWell IT architecture 55

4.6 Wales 56

4.6.1 CareWell service specification 56

4.6.2 CareWell IT architecture 57

5. GUIDELINES TO ACHIEVE INTEROPERABLE AND

EFFICIENT IT SYSTEMS 59

5.1 Guidelines for the development of interoperable systems 59

5.1.1 Levels and environments of interoperability 59

5.1.2 Standards 61

5.2 Interoperability Tools in CareWell pilots 63

5.2.1 Basque Country 63

5.2.2 Croatia 65

5.2.3 Lower Silesia 65

5.2.4 Veneto 65

5.2.5 Puglia 66

5.2.6 Wales 66

6. SECURITY AND CONFIDENTIALITY OF DATA 67

6.1 Basque country 67

6.2 Croatia 68

6.3 Lower Silesia 71

6.4 Veneto 72

6.5 Puglia 74

6.6 Wales 75

APPENDIX A: TECHNOLOGICAL TERMS 78

APPENDIX B: STANDARDS 101

B.1 Communication Protocols (general applications) 102

Page 6: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 6 of 106 Public

B.2 Syntax standards 102

B.3 Format Specification 103

B.4 Services Specification 103

B.5 Process Specification 103

B.6 Communication Protocols (Health applications) 103

B.7 Terminology and health nomenclature 104

B.8 Clinical documentation 105

B.9 Models of information 105

B.10 Architecture of communication 105

B.11 Knowledge models 106

LIST OF TABLES

Table 1: Template - services vs applications 10

Table 2: Current ICT-enabled services of Basque Country 17

Table 3: Current ICT-enabled services of Croatia 22

Table 4: Current ICT-enabled services of Lower Silesia 25

Table 5: Current ICT-enabled services of Veneto 27

Table 6: Current services of Puglia 30

Table 7: Current ICT-enabled services of Wales 34

Table 8: Services Evolution Basque Country 40

Table 9: CareWell ICT-enabled services of Croatia 44

Table 10: Evolution of ICT-enabled services in Lower Silesia 48

Table 11: Evolution of ICT-enabled services in Veneto 51

Table 12: Evolution of ICT-enabled services in Puglia 54

Table 13: Evolution of ICT-enabled services in Wales 57

Table 14: Basque Country standards used 64

Table 15: Croatia standards used 65

Table 16: Lower Silesia standards used 65

Table 17: Veneto standards used 66

Table 18: Puglia standards used 66

Table 19: Veneto kinds of secure access 72

LIST OF FIGURES

Figure 1: Template for common CareWell architecture 11

Figure 2: Architecture of Basque Country Pre-CareWell 17

Figure 3: Functional Architecture EHR in Primary Care (Osabide AP) 19

Figure 4: Functional architecture EHR in secondary care (Osabide Global) 19

Figure 5: Architecture Basque e-Prescription system 20

Figure 6: Architecture Multichannel services centre support in Basque Country 21

Figure 7: Current IT architecture of Croatia 23

Figure 8: Functional Structure G2 24

Page 7: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 7 of 106 Public

Figure 9: Current Architecture of lower Silesia 26

Figure 10: Current Architecture of Veneto 28

Figure 11: Current Architecture of Puglia 31

Figure 12: Architecture of Nardino 32

Figure 13: Current Architecture of Wales 34

Figure 14: Communications channels of WCCG 36

Figure 15: Welsh Clinical Portal (WCG) Integration architecture 36

Figure 16: Wales: Level of development of ICT-enabled services 38

Figure 17: CareWell Architecture of Basque Country 41

Figure 18: New application modules 42

Figure 19: Common features 42

Figure 20: CareWell architecture Croatia 45

Figure 21: EMH chronic disease management system 46

Figure 22: FER Home Health Smart TV 47

Figure 23: CareWell IT Architecture Lower Silesia 49

Figure 24: CareWell IT architecture of Veneto 52

Figure 25: Veneto Territorial Information System 53

Figure 26: CareWell IT Architecture of Puglia 55

Figure 27: CareWell IT Architecture of Wales 58

Figure 28: Standards v. interoperability levels 62

Figure 29: Interoperable platform 64

Figure 30: Secure architecture for external communications 68

Figure 31: PKI infrastructure e-health in Croatia 69

Figure 32: Layers of security communication channels Croatia pilot 70

Figure 33: Security architecture of data transmission channels in Lower Silesia 71

Figure 34: Security architecture of data transmission channels in Veneto 74

Figure 35: Standards v. interoperability levels 101

Page 8: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 8 of 106 Public

1. Introduction

1.1 Introduction to the project

Frail elderly patients are characterised as having complex health and social care needs,

being at risk of hospital or residential care home admission, and requiring a range of high

level interventions due to their frailty and multiple chronic conditions. These patients

typically demand an integrated care approach where all care practitioners working in the

different levels of care have to be tightly coordinated, and special emphasis is put on patients' empowerment. CareWell aims to enable the delivery of integrated care for frail

elderly patients supported by ICT-based technologies and platforms and associated new

ways of working.

1.2 Aim of this deliverable

This deliverable describes the current and CareWell ICT (information, communication and technologies) enabled service model and technical infrastructure available in each of the

pilot sites. The information has been obtained through onsite pilot site visits as well as

completed questionnaires and workshops held as part of WP2 and WP3 work. In

addition, the deliverable includes guidance on achieving interoperability between the different IT systems in use in the sites and security and confidentiality processes and

considerations.

1.3 Structure of the deliverable

Section 2 describes the methodology that has been adopted to take forward the different

tasks within WP4.

Section 3 details the current service model available in each of the pilot sites, including how communication takes place between the different members of the care team in the

various care settings involved. Information contained in D2.2 and D3.1 includes details

of the gap analysis for each site's CareWell implementation; this has not been duplicated

within this deliverable. The deliverable also describes and illustrates the technical infrastructure currently available in each of the pilot sites, including what IT systems are

implemented in each of the care settings.

Section 4 provides describes how the service model will be enhanced through the

implementation of both new or improved ICT and associated new ways of working in

each of the care settings. Diagrams illustrating the new technical infrastructure and IT systems are provided with descriptions of the new components where appropriate.

Section 5 details guidance on achieving interoperability between the different IT systems

across the care settings, and provides a high level illustration of the generic CareWell

architecture.

Section 6 concludes with a description of how each pilot site ensures the security and

confidentiality of patient identifiable information within the IT systems and other methods

of communication between the care team members.

1.4 Glossary

The objective of this glossary is to help readers of the document to understanding it. See

also Appendix A Technological Terms.

AReS Puglia Agenzia Regionale Sanitaria Pugliese

Page 9: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 9 of 106 Public

BP Blood Pressure

BM Body Mass

COPD Chronic Obstructive Pulmonary Disease

CRM Customer Relationship Management service (see also Appendix A)

DICOM Digital Imaging and Communication in Medicine (see also Appendix A)

EC European Commission

ECG Electrocardiography

EHR Electronic Health Record (see also Appendix A)

EU European Union

ENT Ericsson Nikola Tesla D.D.

FAQs Frequently asked questions

F.O.C. Free of charge

GP General Practitioner

HIS Health Information System (see also Appendix A)

ICCM Integrated Chronic Care Model

ICCP Integrated Care Coordination Pathway

ICD Implantable Cardioverter-Defibrillator

ICT Information Communication Technology

IHR Individual Health Record

IKP Individual Patient Account (Lower Silesia)

IMCR Intelligent Mobile Movement Sensor (Lower Silesia)

INR International Normalised Ratio

IT Information Technology

LHA Local Health Authority

LIS Laboratory Information System (see also Appendix A)

LSV Urzad Marszalkowski Wojewodztwa Dolnoslaskiego (Lower Silesia Marshall's office

PAS Patient Administration System

PC Personal Computer

PDAs Personal Digital Assistants

PEHP Patient Empowerment and Home-care Pathway

PHB Powys teaching Local Health Board

PHR Personal Health Record (see also Appendix A)

PKI Public Key Infrastructure (see also Appendix A)

RIS Radiology Information System (see also Appendix A)

ULSS nr2 Unita Locale Socio-Sanitaria Number 2

VPN Virtual Private Network (see also Appendix A)

WiFi Wireless local area network

WoW Ways of Working

WP Work Package

Page 10: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 10 of 106 Public

2. METHODOLOGY The methodology adopted in this WP followed a ‘bottom up’ approach as illustrated

below:

In order to describe the IT systems or applications involved, not just the applications to

be developed during CareWell, it is important to understand and document the

applications or systems running before the start of CareWell which will have an impact on any new applications or services.

The second stage involved the identification of the functionalities for each system /

application: a summary of the features of each application and user roles.

This was followed by the identification of services provided by each application: the

outcome of this task is a table mapping ICT-enabled services and applications. A template was prepared to capture this information, see Table 1 below.

Table 1: Template - services vs applications

Services App1 App2 App3 App4

EHR

E-prescription

Teleconference Professional –

Professional (audio /movie)

Teleconference Professional –

Patient (audio /video)

PHR

Collaborative Web

Educational Web

Page 11: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 11 of 106 Public

Services App1 App2 App3 App4

Telecare service

Clinical interconsultation

Analysis and Exploitation of clinical

and management data

The use cases developed in WP2 were then linked to the ICT-enabled services, where one

service could be included in more than one aspect of a use case.

The information and communication flows were then mapped onto the pathways with the current use cases provided for each pilot. The outcome of this task was a first draft of the

structure of pathways in each pilot site.

In order to achieve the same global structure for each pilot site, a common template of

architecture for every pilot site was prepared.

Figure 1: Template for common CareWell architecture

The next step was to document the new or enhanced ICT-enabled services which would

be provided in each pilot site. The technological challenge for pilots was to examine and

document this aspect of the work package, following a common CareWell architecture,

and the interoperability /security guidelines.

The final step was to describe how the new or enhanced ICT-enabled services would

impact on the service specification in each of the care settings in each pilot site.

Common template for architecture pictures

Below is a description of each component included in the Common IT Architecture

diagrams:

Page 12: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 12 of 106 Public

A. Pathway: The pathway element is identified by a rectangle. In CareWell there are

two pathways.

Rectangle orange: pathway ‘Integrated Care Coordination Services’

Rectangle Blue: pathway ‘Patient Empowerment And Home Support Services’

These elements form the basis for the introduction of the ICT-enabled services.

B. Main Services:

EHR: green rectangle.

C. Level of care (primary, secondary/specialised)

D. Main applications

E. Secondary applications

Page 13: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 13 of 106 Public

F. Legacy Systems

G. Interoperability platform

Work package information collection

The work package was taken forward using a number of different methods to elicit the

necessary information to support the steps in the methodology described above.

A. Questionnaires

During the WP, two questionnaires were designed and administered to collect

information about the pilot sites:

General Questionnaire: used to understand and document the current

situation in each pilot site together with their proposed CareWell objectives. (Template in Annex 1).

Security Questionnaire: used to collect information about the security

elements used by pilots. (Template in Annex 2).

B. Study Visits

Visits to each pilot site were scheduled after the completion of the General

Questionnaire. The aim of these visits was to:

Clarify information reported in the questionnaire.

Analyse the current technological situation for each pilot through discussions

with the technical team.

Observe the main applications which would be included in the CareWell

solution and analyse the main issues or improve guidelines.

Observe the performance and common user requirements of each application.

Understand any current issues with existing systems in each site from a technical perspective.

Page 14: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 14 of 106 Public

Understand the expectations and challenges in implementing the ICT-enabled

aspect of the CareWell project (service and IT point of view).

C. Technical Telcos

Several telcos were scheduled both one-to-one with each pilot site to clarify specific

issues, as well as general telcos to share the approach, generic issues and present

new actions.

D. Technical Workshops

Two technical workshops were held:

Barcelona: The main objectives of this workshop were:

To define the action plan and establish working groups.

To present the general questionnaire and approval of work plan.

Palma de Mallorca: The objectives of this workshop were:

To establish and analyse the IT diagrams pre CareWell for each pilot.

Page 15: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 15 of 106 Public

3. Current services and technological models

3.1 Introduction

This chapter describes the current situation in each pilot site, not only from a

technological perspective, but also functional, where the service specification in each of the care settings is documented.

The information is divided into two sub sections as follows:

Current services provided: This information was captured using the table below. Each

pilot site was asked to indicate whether or not their current service delivery was supported by each of the ICT-enabled services, together with the implementation

maturity level.

Pilot Site Name Before

ICT-enabled services Operational Maturity level

e-Prescription

Messaging clinician Patients

EHR

Interconsultation

Call Centre

Virtual Conference

PHR

Nursing Information System

Educational Platform

Collaborative Platform

Telemonitoring

Multichannel Centre

(Management Telecare Programs)

The maturity level was assessed using the following criteria:

0 = not implemented.

1 = service implemented and being tested.

2 = service 25% implemented.

3 = service 50% implemented.

4 = service 75% implemented.

5 = service 100% implemented, .e. fully operational with all potential users and

CareWell patients involved.

Current IT architecture: This section describes the current ICT tools deployed in each

pilot site, together with the communication channels and different care practitioners

involved in the care settings within each pathway.

Page 16: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 16 of 106 Public

3.2 Basque Country

3.2.1 Current ICT-enabled service specification

Stable Patients – out of hospital care

Currently, the care of a ‘stable’ patient with complex needs is undertaken by the patient’s

GP and GP practice nurse. Together, these care professionals assess the patient’s needs, draw up the care plan and medication regime, offer patient education, deliver any

necessary interventions either in the GP practice or patient’s home, monitor, review and

reassess the needs of the patient in a planned way, as well as respond to any unplanned

events or deterioration unless emergency services are sought through the eHealth centre.

Information is shared between the care professionals and patient in face-to-face (F2F)

contacts as well as by phone. Care professionals are able to share patient-related

information through the EHR and e-Prescription, and do have periodic multi-disciplinary team meetings F2F and by phone.

Although the GP and GP practice nurse provide a case management service, the actual

co-ordination of care is undertaken by the Telecare Centre, as it acts as a hub for both

health and social care practitioners. The Centre is able to activate additional services by following agreed protocols in response to telemonitoring alerts and alarms, as well as

emergency services if the situation is deemed to require such intervention.

Unstable Patients – out of hospital care

When a patient’s health status deteriorates, either the GP or GP practice nurse will

proactively case manage the patient in their own home, and involve additional healthcare professionals to provide clinical interventions, including those from specialists, as

necessary.

Inpatient – hospital care

If a patient has an emergency admission to hospital, the reference internist takes responsibility for co-ordinating the care for the patient. This will include ordering tests

and investigations, drawing up the care plan in consultation with other healthcare

professionals, reviewing the medication regime and making adjustments as necessary,

co-ordinating any additional specialist input into the patient’s care, as well as communicating information on the hospital admission to the patient’s GP. The internists

will also involve the hospital social care team if the patient requires a social care

assessment with a view to requiring support at home post discharge. If the patient

requires longer term hospitalisation to facilitate rehabilitation, for example, the internists

will arrange the necessary referral.

Inpatient – hospital discharge preparation

The hospital liaison nurse works closely with the reference internist to supervise the

patient’s discharge from hospital. Information, such as the updated care plan and

medication regime, is shared with the GP practice nurse for the intensive follow-up, including home visits when necessary, to monitor the patient’s recovery appropriately. A

frailty assessment will be carried out, and support from social care services activated if

required. In addition, the patient is given information on their care plan, and education

on its content and medication regime.

Page 17: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 17 of 106 Public

Table 2: Current ICT-enabled services of Basque Country

Basque Country Before

ICT-enabled services Operational Maturity level

e-Prescription YES 3

Messaging clinician Patients YES 1

EHR YES 3

Interconsultation YES 3

Call Centre YES 2

Virtual Conference NO 0

PHR YES 3

Nursing Information System YES 3

Educational Platform NO 0

Collaborative Platform NO 0

Telemonitoring YES 2

Multichannel Centre

(Management Telecare Programs) YES 2

3.2.2 Current IT architecture

Osakidetza has services in both the Integrated Care and Coordination and Patient

Empowerment and Home-Support pathways and these services are provided by several

systems. These systems are able to share information through the interoperability

platform (Oracle business service). The figure below illustrates the current IT architecture.

Figure 2: Architecture of Basque Country Pre-CareWell

Page 18: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 18 of 106 Public

Integrated Care Coordination Services

The Basque Country provides the EHR service through different systems, depending on

the health sector where the service is implemented (primary or secondary care). In primary care, Osabide AP is used, whereas in secondary care there are two systems

deployed - Clinic and Osabide Global. This duplication is due to the Clinic system being

an older viewer which receives clinical data from legacy systems for every hospital,

whereas Osabide Global is a newer version with more functionalities which extend beyond view only.

Currently, Osakidetza are performing a migration task to achieve a single system to

provide EHR services not only in secondary care but also in primary care.

The e-Prescription servic, Presbide, is provided by a single system in both care sectors. This system has been integrated as a module within the EHR systems (Osabide Global

and Osabide AP).

In addition, Osabide AP and Osabide Global provide the interconsultation functionality

which enables care practitioners in primary and secondary care settings to share the most relevant clinical information.

Patient Empowerment and Home-Support Services

This pathway is composed of the PHR service provided through the Health Folder system,

which is integrated within the Multichannel Services Centre (MSC). The MSC manages

several health programmes (stop smoking programme, monitoring sedentary lifestyles, etc.) and collects data from questionnaires completed by patients in the PHF.

In addition, there are distinct telemonitoring programmes that are not focused on frail

elderly patients. These programmes are not connected to the EHR systems, nor MSC,

but use an external monitoring and management console.

Relevant Systems / applications

E-Osabide: is the hospital information system deployed in all hospitals to provide

administrative information (e.g. appointments, demographic data) and clinical

activity data.

Osabide AP: is used in primary care to provide the EHR service. It also has the

Presbide module to provide the e-Prescription service. This system was developed

in .net, has a client/server architecture, and runs on a Citrix platform.

Osabide Global: is a secondary care application providing several services:

EHR;

E-Prescription implement specific module (Presbide);

Interconsultation.

It is developed in java using client/server architecture in high availability on rack

oracle database.

Page 19: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 19 of 106 Public

Figure 3: Functional Architecture EHR in Primary Care (Osabide AP)

Both systems (Osabide Global and Osabide AP) are connected to legacy systems through the Intranet business service. Examples of legacy systems connected to the EHR are

LIS, RIS, anatomic pathology, HIS, etc.

The following picture shows the distinct connections between the EHR used in secondary

care and the legacy systems. These connections are the same for the primary care sector systems.

Figure 4: Functional architecture EHR in secondary care (Osabide Global)

Page 20: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 20 of 106 Public

Presbide: is a module integrated in Osabide Global and Osabide AP EHR systems

(secondary and primary care). It is developed in java on an Oracle database. The major

difficulty of this tool was the construction, because it requires the implementation of interoperability tools with internal systems as well as external systems.

This complexity is because the development and implementation of e-Prescription is the

responsibility of two organisations: the Basque health service (Osakidetza) has

responsibility over the clinical aspect, i.e. the module for documenting the prescriptions and storage in a central database, and the Health Department has responsibility for the

pharmacies and the dispensing process (dispensing module, erezeta) and Vademecun

which is a set of services which offer information about medicines (products, posology,

composition, etc.).

To date, the e-Prescription project provides interoperability not only at semantic and

syntactic levels, but also at organisational and business process level between two

different organisations (with different systems). The figure below illustrates this

functional integration.

Figure 5: Architecture Basque e-Prescription system

Other elements of the figure:

B38 VDM: Vademecun, set of services which offers information about medicines

(products, posology, composition, etc.).

A53 E-Osabide: is the HIS of Osakidetza with administrative, demographic data.

N12 SWAP: Catalogue of web services for integration with EHR of primary care (Osabide AP).

Zain: Corporate e-signature platform.

B500 impression: Corporate printing system.

CSSM (Multichannel Services Centre Support): is composed of several applications and modules. The most important features included in CareWell are:

Health Folder: this app provides the PHR service. The patients access their health

folder through the link deployed on the corporate Web site. The main functionalities

of the health folder are:

Access to prescriptions (active and historical).

Access to future clinical appointments.

Completed health questionnaires.

Access to health reports (secondary and primary care).

Page 21: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 21 of 106 Public

CRM: This module is used by clinicians to manage the chronic health programmes

and monitoring the health status of patients.

Web Appointment: used to manage appointments in primary care by patients.

Health Council: set of nurses to answer doubts or questions of citizens. Using a

solution based on OPA (Oracle Policy Automation), a decision making system.

Figure 6 below shows the functional structure of CSSM.

Figure 6: Architecture Multichannel services centre support in Basque Country

3.3 Croatia

3.3.1 Current ICT-enabled service specification

Stable Patients – out of hospital care

Older patients are cared for by primary care health professionals, either by visiting their

GP practice, or having a home visit from a field nurse who covers dedicated geographical

areas, where she might have to cooperate with multiple GP practices. The patient’s GP will meet with the field nurse F2F from time to time as necessary, and a patient’s care

plan and medication regime will be adjusted accordingly. Field nurses will refer a patient

for assessment by social care services if they are considered to have social needs.

Currently, information on the care the field nurses deliver to patients is recorded in paper-based records, and the information is shared with the patient’s GP on a need-to-

know basis. The GP may choose to enter relevant information relating to the field nurse

activities and care into their electronic record system.

Unstable Patients – out of hospital care

If a patient becomes ‘unstable’, a patient can contact the field nurse in the healthcare

centre (call centre) during a one-hour period first thing in the morning. The nurse will

often increase their home visits, or home visits will be initiated for a patient who was

previously able to visit the GP in their practice. The GP will refer the patient for tests,

investigations, and specialist consultations from hospital services where necessary, and again, adjust the patient’s care plan and medication regime accordingly. There is

currently no electronic exchange of information.

Inpatient - hospital care

Patients admitted to hospital are cared for by specialists and dedicated hospital nurses. If the GP refers the patient for admission, information is sent by paper with the patient.

Page 22: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 22 of 106 Public

Inpatient – hospital discharge preparation

Discharge information, including care plan and medication regime, is prepared from the

hospital records by a dedicated nurse, and a paper letter is given to the patient for them to give to their GP. When this information has been received by the GP, it will be entered

into the GP electronic clinical record. The discharge nurse will liaise by telephone with

the field nurse using the call centre facility available each morning.

The table below summarises the current ICT-enabled service provision in the Croatian pilot site.

Table 3: Current ICT-enabled services of Croatia

Croatia Before

ICT-enabled services Operational Maturity level

e-Prescription YES 5

Messaging clinician Patients NO 0

EHR NO 0

Interconsultation NO 0

Call Centre NO 0

Virtual Conference NO 0

PHR NO 0

Nurse Information System

(record of nursing care) NO 0

Educational Platform NO 0

Collaborative Platform NO 0

Telemonitoring NO 0

Multichannel Centre (Management Telecare Programs) NO 0

3.3.2 Current IT architecture

The current IT architecture of the Croatian pilot is illustrated below:

Page 23: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 23 of 106 Public

Figure 7: Current IT architecture of Croatia

Integrated Care Coordination Services

The architecture shows typical elements required to provide simple channels of

communication between services of different health care sectors (primary, secondary and

tertiary). Although there is no global EHR service, the Croatian pilot has distinct GP

systems containing health information (G2 or GP system) and a network for sharing

some information between primary and secondary care (G1).

There are several legacy systems, such as LIS, HIS, RIS, in all hospitals. The information

of these legacy systems can be viewed in secondary care through specific programs,

which can differ from one hospital to another. Primary care professionals can access the

information of legacy systems through VPN connection from G2 to G1.

Patient Empowerment and Home-Support Services

Currently, the Croatian pilot does not have any ICT-enabled systems providing services

oriented to patient empowerment and home-support pathway.

Relevant Systems / applications

The principal systems in Croatia are:

G1 System: This application is also called the ‘Health networking information

exchange system’. It is a central communication and processing platform used for

communication between all stakeholders (IT systems) within the national healthcare system in Croatia. This application runs on a complex set of servers.

G2 application: This application is also known as the GP office application. It is used

by GP and his assisting nurse, to manage patient data as well as business

administration of GP office. There are many G2 applications supplied by various

vendors that run on different platforms, ranging from a PC as a client application

Page 24: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 24 of 106 Public

that communicates with G1, up to those that have separate servers and clients

where communication to G1 is executed from a local server.

Figure 8: Functional Structure G2

Hospital IT System: Integration information system used to manage all aspects of

hospital operation (medical, administrative, financial, legal. etc.). There are a

number of vendors in Croatian market; it is therefore not possible to describe the

overall IT infrastructure.

3.4 Lower Silesia

3.4.1 Current ICT-enabled service specification

Stable Patients – out of hospital care

Co-ordination of care is currently undertaken by the GP, and is reliant on the relevant

information held in paper-based systems being shared by letter, fax or phone to inform

decision-making.

Unstable Patients – out of hospital care

Environmental nurses visit patients at home at the request of GPs, and they assess a

patient’s needs and provide the necessary care. Again, information from paper-held

records is shared with the relevant healthcare practitioners, except for the electronic transmission of ECG to hospital by the emergency services. Patients and informal carers

are reliant on signposting to support services, as there is currently no ‘directory of

services’ available to help people find appropriate care to meet their needs.

Inpatient - hospital care

A patient will be admitted to hospital if necessary, following an assessment in the emergency room. They will have their needs assessed by a multi-disciplinary team; this

assessment includes frailty for older people. Information on the patient’s tests,

investigations, care and treatment is recorded in a range of hospital IT systems and

paper records; communication between the care practitioners is via these record systems and F2F. If the frailty assessment outcome indicates that the patient will require social

care, home care, nursing care or long term care, the hospital social worker will make the

necessary referrals.

Page 25: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 25 of 106 Public

Inpatient – hospital discharge preparation

A hospital discharge card containing information on recommendations for on-going care

and support is prepared by a nurse on the hospital ward, and given to the patient on discharge.

The table below summarises the current ICT-enabled services available in Lower Silesia.

Table 4: Current ICT-enabled services of Lower Silesia

Lower Silesia Before

ICT-enabled services Operational Maturity level

e-Prescription NO 0

Messaging clinician Patients NO 0

EHR YES 2

Interconsultation NO 0

Call Centre NO 0

Virtual Conference NO 0

PHR YES 2

Nurse Information System (record of nursing care) NO 0

Educational Platform NO 0

Collaborative Platform NO 0

Telemonitoring NO 0

Multichannel Centre

(Management Telecare Programs) NO 0

3.4.2 Current IT architecture

The current IT architecture of Lower Silesia pilot is illustrated below:

Page 26: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 26 of 106 Public

Figure 9: Current Architecture of lower Silesia

Integrated Care Coordination Services

In Lower Silesia, the EHR service / system is connected to legacy systems in all hospitals

by an internal service bus. However, it is not currently possible to exchange health

information between hospitals electronically. In primary care, the clinical information is

managed by GPs, who use different EHR applications with a local data store.

Patient Empowerment and Home Support- Services

Lower Silesia offers several web portals with information about the most common chronic

diseases (diabetes, heart failure, etc.). However, no platforms are focused on patient /

caregivers empowerment or targeted patient education.

Relevant Systems / applications

HIS: Each hospital has its own HIS; it is not possible to access information held in

another hospital HIS. The information stored in these systems is clinical and

administrative. HIS is integrated with other hospital legacy systems through a

service bus. The HIS provides the EHR and e-Prescription services.

GP system: There several applications providing GP systems in Lower Silesia. The

EHR within the GP system is not shared with secondary care, nor other GP systems.

3.5 Veneto

3.5.1 Current ICT-enabled service specification

Stable Patients – out of hospital care

Patients with complex needs are currently assessed by a multi-disciplinary team in the multidimensional assessment unit following a GP referral or referral following a hospital

Page 27: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 27 of 106 Public

admission. From this assessment, which is informed by collecting information from the

various care practitioners involved, a personalised care plan and medication regime is

drawn up on paper; this is shared with the appropriate people. The GP and primary care territorial services co-ordinate the care of the patient. Some patients may have telecare

services such as panic buttons or community alarms.

Unstable Patients – out of hospital care

If a patient has previously had a multi-disciplinary assessment, but their condition deteriorates, the GP or the other professionals can activate a new multi-disciplinary

assessment. The new evaluation can lead to additional home care interventions and

support through the territorial social workers, home-care nurses. The GP can also refer

the patient for new tests, investigations or specialist consultation. The home care is co-ordinated by the Social and Healthcare District services, among which there is also the

Territorial Operational Centre (TOC). A home-care nurse provides a case management

service, and delivers additional patient education to help the person self-care and self-

manage. In the event that a telecare alarm has been activated, the response centre can arrange transportation to the hospital emergency room if considered necessary.

The GP will refer the patient for the multi-dimensional assessment unit if their health and

wellbeing has significantly deteriorated. As a result of the agreed care plan, the TOC will

co-ordinate the care of the interventions in the care plan, and ensure communication

takes places between the various care givers.

The Client Resource Management (CRM) in the TOC collects and shares information

between the different territorial health and social care services including, the hospital

laboratory and diagnostics, with communication between other services and care givers

being by phone, email, paper/fax or F2F.

Inpatient - hospital care

Whilst a patient is in hospital, a patient is case managed by a hospital doctor with nurses

delivering care, administering drugs, co-ordinating services and interventions. The doctor

draws up a care plan, and the nurse makes arrangements for any home care interventions required. Information is recorded in the CRM with communication between

the healthcare practitioners being undertaken F2F.

Inpatient – hospital discharge preparation

When a patient is ready for discharge, the hospital doctor and nurse liaise with the TOC

or the Home Care Nursing Service by phone, and any necessary home-care services are scheduled. A referral to the multi-dimensional assessment unit can be made, a care plan

is drawn up, and information is given to the patient and any informal carers to help with

self-care and self-management. The patient’s GP receives information on the care plan

by phone and/or fax from the TOC or the hospital, and, if required, visits to the patient at home are arranged.

Below is the table summarising the current ICT-enabled services available in Veneto:

Table 5: Current ICT-enabled services of Veneto

Veneto Before

ICT-enabled services Operational Maturity level

e-Prescription YES 5

Messaging clinician Patients NO 0

EHR YES 1

Interconsultation NO 0

Page 28: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 28 of 106 Public

Veneto Before

ICT-enabled services Operational Maturity level

Call Centre NO 0

Virtual Conference NO 0

PHR NO 0

Nurse Information System

( record of nursing care) NO 0

Educational Platform NO 0

Collaborative Platform NO 0

Telemonitoring NO 0

Multichannel Centre (Management Telecare Programs) YES 5

3.5.2 Current IT architecture

Veneto has central databases for sharing information among clinical systems

(prescriptions, demographic data and clinical reports).

In addition, there are several interoperability platforms, such as the Mirth platform or Bus service, which uses HL7 to build the messages between systems (HL7, SOAP,

DICOM, etc.).

Figure 10: Current Architecture of Veneto

Integrated Care Coordination Services

The e-Prescription service is provided by the same system in both care sectors (primary

and secondary), and it has a central repository of prescriptions. The EHR is provided in primary care by the Territorial Information System. In secondary care, the hospitals have

a HIS with two modules, one for administrative management, and another for

documenting medical information – the e4cure module which is a proprietary EMR

solution, together with the e-Prescription.

Page 29: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 29 of 106 Public

Patient Empowerment and Home Support-Services

This pathway is supported by a web portal providing the interaction between the local

health authority and the citizen/patient and some educational materials, together with the telecare service e.g. panic buttons and community alarms provided by the Regional

Tele-emergency solution.

Relevant Systems / applications

The current application / systems running in Veneto have been developed following two types of architecture:

Three layers (Web applications): composed by presentation layer, business layer

and persistence layer. This architecture comprises:

e-Prescription to provide the e-prescription support.

Web site of LHA provides the PHR service.

Regional Tele-emergency solution provides telecare service.

e4cure and Talete (EMR) provides interconsultation service.

Territorial Information System provides EHR service.

Client / Server application: This architecture comprises:

GP systems: to provide EHR service.

Pharmacy software: to provide an aspect of the e-Prescription.

3.6 Puglia

3.6.1 Current ICT-enabled services specification

Stable Patients – out of hospital care

Patients are currently cared for by their GP in collaboration with nurses and specialists in outpatient clinics (not hospital outpatient clinics). Information is shared by phone and

written documents. In addition, the integrated EHR is used to record and share

information between the care manager and GPs. Specialists, to date, are not involved in

sharing information through the EHR. Patient empowerment comes from the counselling given by the care manager.

Unstable Patients – out of hospital care

Patients with complex needs are case managed in the outpatient clinic by a primary care

specialist nurse (CM), GP and specialists. The care delivered to patients who are ‘unstable’ is the same, although the frequency and intensity of some or all the care plan

interventions would change. The GP and CM use the EHR to share information about the

patient, but the specialists usually contact the team by phone. An integrated frailty

assessment is undertaken, and the patient follows their defined chronic care pathway and

is often referred to community and home care nursing services and/or any necessary social care service. All care and support is co-ordinated by the CM. Telemonitoring for

patients is only in an emergency (when the A&E department is involved), and consists of

the ambulance paramedic sharing information with the A&E doctors.

Inpatient - hospital care

When an ‘unstable’ patient is cannot be managed in the primary care setting, the GP or

specialist refers them for hospital care. When admitted to hospital, the patient is

assessed by a hospital specialist, using information from the GP if possible

(communication is provided by phone, email and SMS). The hospital specialist arranges for any tests and investigations, and draws up the care plan and associated medications.

Day-to-day care is provided by the ward nurses supported by the family or informal care

Page 30: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 30 of 106 Public

giver. Information on the hospital episode of care is recorded on a medical chart by the

specialist and ward nurses, and then synthesised into a discharge sheet, ICD9 CM

codified, and uploaded into the regional health information system (Edotto). In turn, this feeds the national administrative database held by the Health Ministry and Economic

Ministry. When a patient is deemed to be stable, the hospital specialist prepares a

discharge letter summarising the hospitalisation event, and shares this clinical

information with the GP.

Inpatient – hospital discharge preparation

The ‘stabilised’ patient is discharge from hospital back to their home. The hospital

specialist transitions the patient to the territorial CM, and gives them a discharge letter

summarising the hospitalisation event to share the clinical information with their GP. The professionals only communicate via paper documentation.

Below is the table of current ICT-enabled services available in Puglia:

Table 6: Current services of Puglia

Puglia Before

ICT-enabled services Operational Maturity level

e-Prescription NO 0

Messaging clinician Patients NO 0

EHR YES 4

Interconsultation NO 0

Call Centre NO 0

Virtual Conference NO 0

PHR NO 0

Nurse Information System ( record of nursing care)

YES 5

Educational Platform NO 0

Collaborative Platform NO 0

Telemonitoring YES 3

Multichannel Centre (Management Telecare Programs)

YES 2

3.6.2 Current IT architecture

The current IT architecture of Puglia pilot is illustrated below:

Page 31: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 31 of 106 Public

Figure 11: Current Architecture of Puglia

Integrated Care Coordination Services

Puglia has an ICT architecture (Apulia WAN RUPAR) that provides connection services

and brokering access with strong authentication to all operators of the Public

Administration, and in particular to the nodes of the healthcare system. The Apulia

RUPAR houses the Regional Health Information System, named Edotto, which collects, informed by local Health Authorities, administrative and clinical data for the

management, governance and epidemiological investigations in the field of health. Edotto

summarises data coming from different health domains (primary care, hospital

discharges, outpatients clinics data, A&E flows, pharmaceutical consumptions, mental health, pathologic dependences, etc.) both automatically into the system, or migrated

from other information systems working on SPcoop standards (interoperability standards

for public administrations). Many of data flows uploaded into Edotto feed the national

administrative database of the Health Ministry and Economic Ministry.

Patient Empowerment and Home Support-Services

Patient empowerment and home-support services are currently provided by the CM

through counselling the patient.

Relevant Systems / applications

In cooperation with Edotto (which extracts patients registry data), the Nardino information system (Puglia Care program software) provides the EHR for the primary

care team. The Nardino program is a web-based platform that provides management

services to support the delivery of care for patients with chronic conditions. It is

implemented on the WAN RUPAR directly, or by a VPN enciphered connection. The information system, built with open source technology, manages the access profiles of all

those involved in the care of chronic patients. Each team member has a specific

operational profile, e.g. CM, GP. In particular, Care Puglia program software also

implements a back office system for managing user profiles and information structure for

Page 32: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 32 of 106 Public

displaying reports and indicators. The back office activities for the management of the

user community are delegated to specific users’ administrative access, that can create

new profiles or delete an existing one with the help of wizards and automatic utilities. The framework for reporting ensures the consultation of a list of approximately 150

indicators of process, outcome, and quality, processed and presented in real time. It also

has a utility for downloading whole report in CSV format.

The system maintains a clinical framework that builds an information folder containing the patient's medical history, clinical evaluations and nursing, therapy, diaries notes, and

a complex system for planning, co-ordination and follow-up of the typical activities of the

CM. The Care Puglia program is also equipped with standard interfaces for web services

that use SOAP and SOA architecture with native support for HL7.

Clinical information coming from Care Puglia program platform represents the EHR by

which primary care health professionals (not the specialist) share information about a

patient.

Cardiac remote monitoring information collected in an emergency is not included in Edotto or Nardino. It is only seen by the hospital clinician in the A&E department.

Figure 12: Architecture of Nardino

3.7 Wales

3.7.1 Current ICT-enabled service specification

Stable Patients – out of hospital care

Patients with complex needs are cared for by primary and community care services with

the co-ordination usually undertaken by either a community district or specialist nurse.

Presentation Layer: Script CGI, WEB GUI (html, JS - Jquery)

Standard: DICOM, HL7, SOAP …

Persistent Layer: Logging, Environment variables, Crypt CBC …

Registry

Repository

Page 33: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 33 of 106 Public

The patient’s GP or practice nurse undertakes a scheduled review of their health and

wellbeing on an annual basis; they may also be seen routinely in hospital outpatient

appointments. Information on assessment, care plans and interventions is recorded in the GP clinical information system (EHR) and health board patient administration system,

as well as the nurses using some paper record keeping systems. Communication is by

F2F, phone or email (patient identifiable information cannot currently be exchanged via

email). Referrals to hospitals can be undertaken via the Welsh Clinical Communications Gateway (WCCG).

Social care services can be accessed by the patient, family or informal carer by F2F

communications or via the call centre. Healthcare professionals can also make a formal

referral for an assessment by social care services.

Patients also have access to My Health Online, which is a summary personal health

record. Currently patients can order prescriptions, book GP practice appointments and

view and update the demographic details of their PHR.

Unstable Patients – out of hospital care

If a patient’s health and wellbeing deteriorates, additional community services can be

accessed through the community resource team (CRT). This team will undertake a multi-

disciplinary assessment, revise the care plan accordingly, and monitor the recovery of

the patient for a period of time. Most community nurses have access to information in

the GP clinical information systems (EHR), but communication between the care team is usually F2F or by phone.

Inpatient - hospital care

Within Powys, patients can only be admitted to a community hospital; they would go

outside the area if their health needs were severe. The GP would arrange a community hospital admission, often involving the ambulance service for transport. Whilst in

hospital, patients would be under the care of a GP; information is entered into the

Myrddin patient administration system. The GP assesses the patient, can order basic

laboratory and radiology tests, and adjust medication. Rehabilitation services are also available if required. Information from the GP clinical system is usually available to

provide the medical history of the patient. The GP and hospital nurses use the health

board’s patient administration system, Myrddin, and paper records to record the care

delivered. Communication is mainly by phone between the GP practice and hospital.

Inpatient – hospital discharge preparation

A care transfer co-ordinator is responsible for making the necessary arrangements for

hospital discharge; this will be recorded in the patient’s notes and patient administration

system. This person will liaise by phone with the patient’s GP, community and/or

specialist nurse, community therapy services if required, and reablement services. The Co-ordinator has F2F meetings with the hospital nurses and doctor to gain the necessary

assessment and care planning information.

The GP will refer the patient to a secondary care specialist via the WCCG if necessary.

The GP will also enter information about the patient’s hospital admission into their EHR and prepare any e-Prescriptions as necessary.

The table below summarises the current ICT-enabled services available in Wales:

Page 34: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 34 of 106 Public

Table 7: Current ICT-enabled services of Wales

Wales Before

ICT-enabled services Operational Maturity level

e-Prescription YES 5

Messaging clinician Patients NO 0

EHR YES 5

Interconsultation NO 0

Call Centre YES N/A

Virtual Conference NO 0

PHR YES 4

Nurse Information System (record of nursing care) NO 0

Educational Platform YES 2

Collaborative Platform YES 3

Telemonitoring NO 0

Multichannel Centre (Management Telecare Programs) NO 0

3.7.2 Current IT architecture

Currently, the Powys pilot has more IT architecture and ICT-enabled services to support

the integrated care coordination pathway rather than the patient empowerment pathway.

The current IT architecture of Powys pilot is illustrated below:

Figure 13: Current Architecture of Wales

Page 35: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 35 of 106 Public

Integrated Care Coordination Services

The integration care pathway is based on three elements (GP system, WCP, and WCCG).

These three elements cover the most important services (EHR, e-Prescription, and inter-consultation). The EHR is provided through the WCP in secondary care and the GP

system is the EHR in primary care. In addition, the WCCG provides the interoperability

tool for sending referral information from primary care to secondary care. Currently, it is

only is possible send electronic referrals to secondary care, with the referral being populated automatically from the GP clinical system (EHR) together with free text.

Patient Empowerment and Home Support- Services

The pathway for Patient Empowerment has three important applications / systems as

follows:

My Health On line (MHOL): this app provides the PHR service.

Myrddin: this system provides the district and specialist nurses with their home visit

schedule and activities.

Draig: This is the current IT system to support the delivery of social care services in Powys. During CareWell, this system will be replaced by an integrated social and

health care administrative IT system (CCIS).

Relevant Systems / applications

GP systems: this system is used in primary care for recording clinical information

and providing e-Prescription service.

WCCG (Welsh Communications Gateway): this system allows GP system users to

execute electronic referrals to secondary care. The solution implemented is based

on software developed by NHS Scotland. The user accesses the WCCG via a button

or link within the GP system user interface. When the user ‘clicks’ on the button / link, an external application is started, which is displayed in a browser on the user’s

PC.

The WCCG will extract patient demographic and clinical data for inclusion in the

referral from the GP system. The WCCG application is also able to write back data into the GP system via a proprietary GP system supplier specific interface.

The integration of WCCG and National Applications is under the ‘control’ of NWIS.

There is a dependency on development resources with NHS Scotland, but this is

seen as a very low risk. This allows changes to the integration of applications

between WCCG API and any other application in the future (as displayed above).

The illustration below shows the different connectors developed for the WCCG to

achieve interoperability between GP systems and systems used in secondary care.

It also includes the specific module (GP client) used by the GP system to connect

with other secondary care systems facilitated through WCCG.

Page 36: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 36 of 106 Public

Figure 14: Communications channels of WCCG

WCP (Welsh Clinical Portal): The WCP is a web application used in secondary care

for clinical communications with primary care and views individual patients records. Moreover WCP allows making prescriptions, reports, request etc.

Figure 15 below shows the several (internal and external) connectors developed to

achieve interoperability with legacy systems within the hospitals and with external

services through WCCG.

Figure 15: Welsh Clinical Portal (WCG) Integration architecture

IHR (Individual Health Record): The IRH is a summary of the GP system EHR. It is

derived and updated automatically each day. Currently, the IRH is used to support the GP out-of-hours service. Patients are able to ‘opt out’ of their GP EHR being

used to create the IHR.

Page 37: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 37 of 106 Public

OOHS (Out-of-Hours Service): The IT system used by the Out-of-Hours GP is called

Adastra; this enables access to the IHR on a view only basis.

eMPI (electronic Master Patient Index): The eMPI is the national (all Wales) database of patient demographic details. IT systems in hospitals and GP practices

can access the eMPI to read patient details and feed updated information back into

the local IT system. Not all systems have full access to the eMPI, but as new

systems are implemented, the use of the eMPI is extended.

Myrddin (Patient Administration System): Myrddin is the name of the PAS used in

secondary care (community hospitals) in Powys. It contains demographic, inpatient

and outpatient contacts and activities for healthcare practitioners. The MPI within

Myrddin provides demographic feeds to the eMPI and other clinical information systems.

3.8 Analysis of current service specification vs IT systems

Analysis of the current situation in relation to the level of service specification and ICT-

enabled services and architecture available in each of the pilot sites indicates that the

sites can be divided into two groups:

Pilot sites with many deployed systems that are an integral part of the CareWell solution, and therefore a level of integration or interoperability is required.

Pilot sites whose CareWell solution is less dependent on any existing deployed

systems, and therefore the requirement for integration and interoperability is much

less.

Below is a diagram illustrating the level of development of ICT-enabled services in

CareWell:

Page 38: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 38 of 106 Public

Figure 16: Wales: Level of development of ICT-enabled services

0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00 e-prescription

Messaging clinician ßà Patients

EHR

Interconsultation

Call Center

Virtual Conference

PHR

Nurse Information System

Educational Platform

Colaborative Platform

Page 39: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 39 of 106 Public

4. CareWell ICT-enabled service specification and IT architectures

This section describes the services, IT systems or IT architecture elements adapted

within CareWell project.

4.1 Basque Country

4.1.1 CareWell service specification

Stable patients – out of hospital care

The current service model will be enhanced in a number of ways:

Wider deployment of the reference internist and hospital liaison nurse into other

hospitals in the region.

Developing and implementing procedures to provide messaging between patients and healthcare practitioners through the electronic Personal Health Folder.

Further develop the care pathways for frail older people to extend the eHealth

Centre and Telecare Centre to provide improved telemonitoring and follow-up /

response calls.

Provide symptom management questionnaires in the Personal Health Folder to

further support self-care and self-management.

Rolling out the electronic prescription to additional healthcare professionals

including pharmacists.

Provision of self-care and self-management educational material through the

Personal Health Folder and Osakidetza web portal.

Unstable Patients – out of hospital care

In addition to the above service model enhancement for the ‘stable’ patient, healthcare

professionals will have improved access to near-time information to assist with decision-making when a patient’s health status deteriorates. The enhanced role of the eHealth

and Telecare Centres will enable easier continued follow-up of the patient during their

recovery period, thus reducing the need for F2F visits.

Inpatient - hospital care

Healthcare professionals in the hospitals will have richer information to understand the

nature of a patient’s deterioration leading up to their emergency admission, including

telemonitoring information and symptom management questionnaire responses. It is

likely that the acuity of patients requiring hospital admission will increase as more patients are able to be managed by telemonitoring and support in their own homes for

minor exacerbations.

Inpatient – hospital discharge preparation

The information entered into the CRM by the hospital liaison nurse will be able to be

viewed by all healthcare practitioners involved in a patient’s care team; this will provide a much improved, streamlined and safer service model.

Tailoring telemonitoring and self-care and self-management information and education to

the individual patient will be facilitated through defining the telemonitoring parameters

and educational material provided to the patient and their family / informal care givers through the Personal Health Folder.

Page 40: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 40 of 106 Public

Table 8: Services Evolution Basque Country

Basque Country Before After

ICT-enabled service Operational Maturity

level Operational Maturity

level

e-prescription YES 3 YES 5

Messaging clinician Patients YES 1 YES 4

EHR YES 3 YES 4

Interconsultation YES 3 YES 4

Call Centre YES 2 YES 2

Virtual Conference No 0 NO 0

PHR YES 3 YES 4

Nurse Information System

(record of nursing care) YES 3 YES 3

Educational Platform No 0 YES 4

Collaborative Platform No 0 NO 0

Telemonitoring YES 2 YES 3

Multichannel Centre

(Management Telecare Programs) YES 2 YES 3

4.1.2 CareWell IT architecture

As described in 4.1.1 above, the Basque Country is making a number of changes to

improve their services:

Integration into the EHR data from the hospital pharmacy.

Integration of systems to provide EHR in a single system for both care sectors

(primary and secondary care).

Messaging between patients (PHR) and clinicians (EHR).

Integration of the clinical information from the CareWell chronic programmes in

EHR.

Improve the Business Intelligence to provide new functionalities for patient

stratification.

Development of an educational web platform for patients.

The diagram below illustrates the CareWell architecture:

Page 41: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 41 of 106 Public

Figure 17: CareWell Architecture of Basque Country

The above technological improvements will result in new or enhanced applications and functionalities described below.

4.1.2.1 New systems or new functionalities

Integration in EHR data of hospital pharmacy

The e-Prescription service in secondary care will be extended to include primary care with a shared database. This will be achieved through the deployment of several web services

designed to recover and upload data to the central e-Prescription database irrespective of

whether the prescription request is made from the module in the primary or secondary

care IT system.

System integrated of both primary and secondary care EHRs

The interface of the application integrating both EHRs is equal to that used in secondary

care. The major challenge, therefore, is the implementation of this application in primary

care, where practitioners can be reluctant to use new applications. In order to avoid this

situation, a contingency measure has been established which defines a progressive functional adaptation for primary care users. This plan outlines how the functional

modules only present in the primary care EHR can be gradually added to the new

application, although the interface visualisation will be slightly different.

The picture below shows the modules deployed in the new application during the first phase of the integration process.

Page 42: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 42 of 106 Public

Figure 18: New application modules

The following diagram shows the common features shared by primary care EHR and secondary care EHR.

Figure 19: Common features

Integration within the EHR of the clinical information collected from the

telemonitoring platform

MSC is the main element of the integration, since it functions as a bridge between the

EHR and the telemonitoring platform where the CareWell program is stored. The

procedure consists of three steps: firstly, the clinical data is transmitted to the MSC; secondly, the MSC publishes a new web service; and thirdly, the EHR system requests

the information from the patient’s CareWell program to the web service.

Messaging between patients an clinicians

In order to provide this service, new versions of both the EHR and PHR systems will be developed. The EHR system has its own system of messaging, which allows for

Page 43: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 43 of 106 Public

messages to be sent to the PHR through a service bus using a web service specifically

created for this purpose.

In addition, the PHR system will present a client which enables calling to web service and recovering the message from the EHR system. Additional minor changes have been

incorporated into the graphical environment in order to define the user’s interface. The

existing database will be adapted to store minimum historical messages.

Development and standardisation of the data collection to automate the risk stratification score calculation

The independent variables needed to calculate the risk stratification score developed in

the Basque Country come from several administrative and clinical databases

(hospitalisation, emergency visits, consultation, prescription, diagnosis, prescription, demographic data, etc). All this data needs to be linked at patient level. During the

CareWell project, a Data Business Warehouse has been developed which allows data to

be collected from several databases in a standardised way.

Through this data collection process, the prediction risk algorithm is applied manually, and the outcome of the risk stratification at patient level is uploaded into the EHR.

The risk stratification score is used in the CareWell pathway to identify patients with high

complex needs who are most likely to benefit from the CareWell pathways and services.

Develop a new educational web

New educational materials and documentation have been added to the Basque Health Service’s web portal. There is a specific section in the portal called ‘Health School’ where

distinct content aiming to foster patient / caregiver empowerment are described:

Actions in case patient health worsened.

Healthy lifestyles.

Information about your disease.

4.2 Croatia

4.2.1 CareWell service specification

Stable Patients – out of hospital care

The service model will predominantly be enhanced through the deployment of new ICT,

and resultant new ways of working between the GPs and field nurses, social workers and patients in the following ways:

Development and implementation of the Ericsson Mobile Health chronic disease

management system (EMH) system for the field nurses to record the care they

provide to patients. This information will be immediately available to the GP if

necessary.

The implementation of the EMH system will enable GPs to review a patient’s care,

and provide advice or a change in a patient’s care plan or medication regime

through the system rather than having to meet the nurse F2F.

Field nurses will be able to communicate with the social care workers through the EMH system.

Patient information to support self-care and self-management will be developed and

made available through the EMH system for the nurses to pass on to the patient.

This should ensure consistent quality of educational content, and enable

Page 44: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 44 of 106 Public

information to be updated easily within the system, and new knowledge to be

shared.

Unstable Patients – out of hospital care

The EMH system will facilitate the field nurses obtaining additional support and advice

from the patient’s GP practice if they become ‘unstable’; a patient’s care plan will be

optimised to manage the ‘deterioration’ quicker that is the case currently. The nurses will

also be able to provide the patient with additional educational material to help them self- care and self-manage their health and wellbeing during the period when they are

considered ‘unstable’ and not requiring hospital admission.

Inpatient - hospital care

If a patient does have to be admitted to hospital, the GP will be able to provide the hospital with up-to-date information to support the admission and medical history of the

patient.

Inpatient – hospital discharge preparation

The introduction of the EMH system will facilitate the discharge of patients, as hospital

healthcare professionals will be aware that patients can be more closely monitored in their own homes and be better supported to self-care and self-manage.

Below is the table summarising the evolution of ICT-enabled services in CareWell.

Table 9: CareWell ICT-enabled services of Croatia

Croatia Before After

ICT-enabled service Operational

Maturity

level Operational

Maturity

level

e-prescription YES 5 YES 5

Messaging clinician Patients NO 0 YES 1

EHR NO 0 NO 0

Interconsultation NO 0 NO 0

Call Centre YES 3 YES 3

Virtual Conference NO 0 NO 0

PHR NO 0 YES 1

Nurse Information System

(record of nursing care) NO 0 NO 0

Educational Platform NO 0 YES 1

Collaborative Platform NO 0 NO 0

Telemonitoring NO 0 YES 1

Multichannel Centre

(Management Telecare Programs) NO 0 NO 0

4.2.2 CareWell IT architecture

The main challenge for Croatia pilot during CareWell is to develop and deploy the architecture required to deliver the patient empowerment and home-support services

pathway. The core of this architecture is Ericcson Mobile Health chronic disease

management system.

Page 45: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 45 of 106 Public

Figure 20: CareWell architecture Croatia

For this activity, the EMH has several adapters and viewers that enable it to run on

several platforms such as tablet, PC or TV (Smart TV).

Main Technological Changes during CareWell

The Croatian pilot will focus on the following technological developments:

To adapt and deploy to a pilot population the EMH system consisting of a number of

modules to support chronic conditions management and the provision of digital

educational tools for patients.

To integrate the telemonitoring data from the EMH into the GP patient record within

the GP application (G2).

Develop and implement the Home Health Smart TV viewer to enable patients and

informal caregivers to access the telemonitoring data collected by the field nurses

using EMH.

Ericsson Mobile Health Chronic disease management system

This is a platform to provide remote health services, applicable for various use cases in

healthcare, self-care and wellbeing, to be implemented for the purpose of CareWell

project. EMH will receive input from physiological measurement devices and record the data into the PHR, which will be viewable on the android application running on a tablet

or Home Health Smart TV. This data will also be sent to G1.

The roles able to use EMH will be GP/Nurse, Field Nurse, Social Care Worker, Caregiver,

and Patient.

In the scope of the project, there are novel features for Smart TV-based information and

warning system which will be developed by FER. Details of the functionality of the EMH

and home health Smart TV is given below.

Page 46: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 46 of 106 Public

Figure 21: EMH chronic disease management system

FER Home Health Smart TV

FER Home Health Smart TV will provide easy access to the valuable EMH data to patients.

FER Home Health Smart TV is deployed on Android 4.2 Set Top Box which enables the execution of the application on any type of TV device. The system consists of two main

components:

FER Home Health TV application.

Adapter service.

Using the carefully designed application, patients and their caregivers can access and view their medical data such as medical measurements, warnings and messages, and

educational materials provided by medical experts. For the purpose of Croatia pilot, FER

Home Health TV will enable only one role – patient. In order to improve the

interoperability of FER Home Health TV system, the adapter service is designed and integrated. Using the adapter service, internal application methods are adapted to the

Page 47: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 47 of 106 Public

application programming interface of appropriate eHealth service provider which enables

the integration of FER Home Health TV system in different environments and eHealth

systems. Adapter service in the scope of CareWell project communicates with EMH Technical node REST API using HTTPS protocol.

The advantage of adapter service is that it would be easily installed in other CareWell

pilot sites if there was interest.

The diagram below shows the ‘track and trend’ view of a patient’s physiological measurements within the Home Health Smart TV application.

Figure 22: FER Home Health Smart TV

4.3 Lower Silesia

4.3.1 CareWell service specification

Stable Patients – out of hospital care

The implementation of the CareWell integrated pathway will enable to following

developments to the service model:

Better understanding of the roles and responsibilities of the different care practitioners involved in delivering services and interventions within the care

pathway.

Integrating the hospitalisation of those patients who require it as part of the care

pathway to provide better patient care transition experiences across the different sectors and professionals.

Introduction of telemonitoring for patients who require this service.

Easier access to healthcare response service for patients through the platform.

ECR will provide an improved communication mechanism through the email box,

and thus enhance the co-ordination of a patient’s care.

The platform will provide a directory of services for patients, family members and

informal care givers, as well as professionals, to search for appropriate quality

assured health and wellbeing services that are available.

Page 48: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 48 of 106 Public

Unstable Patients – out of hospital care

The above enhancement for the ‘stable’ patient will also be relevant for the ‘unstable’

patient. In addition, virtual consultations will be able to be activated, if necessary, between the hospital specialists, nurses and GPs via the email box when a patient’s

health and wellbeing deteriorates.

Inpatient - hospital care

The hospital information system (HIS) will be integrated into the ECR; healthcare professionals will have access to the information (anonymised) in the platform if a patient

gets admitted. Selected doctors involved in CareWell will have access not only to the

information in the HIS, but also to the LSV CareWell platform. If the doctor is interested

in the information uploaded by the patient, they will ask permission from the patient to look at this data. This should provide improved information on the patient’s medical

history and the events and care leading up to the hospital admission.

The educational platform in this phase of the project is not targeted at hospital doctors,

but they will be able to access the information in the platform if they are interested in it.

Inpatient – hospital discharge preparation

The hospital will be able to refer the patient for telemonitoring if they are not already

receiving the intervention according to the defined CareWell criteria, and determine their

physiological parameters and frequency accordingly. In addition, patients will be

signposted to appropriate patient empowerment services and educational content through the platform.

For patients who were receiving telemonitoring prior to their admission, it is expected

that they will return to receive the telemonitoring service upon discharge from the

hospital.

Table 10: Evolution of ICT-enabled services in Lower Silesia

Lower Silesia Before After

ICT-enabled service Operational

Maturity

level Operational

Maturity

level

e-prescription NO 1 NO 1

Messaging clinician Patients NO 0 YES 3

EHR YES 1 YES 3

Interconsultation NO 0 YES 4

Call Centre NO 0 YES 3

Virtual Conference NO 0 YES 4

PHR YES 1 YES 3

Nurse Information System

(record of nursing care) NO 0 YES 2

Educational Platform NO 0 YES 3

Collaborative Platform NO 0 YES 3

Telemonitoring NO 0 YES 4

Multichannel Centre (Management Telecare Programs) NO 0 YES 3

Page 49: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 49 of 106 Public

4.3.2 CareWell IT architecture

As Lower Silesia currently does not have many IT systems implemented to support the

delivery of care or share information, both CareWell pathways will be significantly improved with the proposed ICT-enabled services and functionality.

The development of a platform to provide interoperability between the different IT

systems used in primary and secondary care will enable information to be shared

between the different care practitioners and patients.

Figure 23: CareWell IT Architecture Lower Silesia

New systems or new functionalities

Registration of patient referrals for home care telemedicine (TOP). This is the first

task in the process of LSV teleCare.

Logged user access in Information Portal to Integration Platform.

Patients Registry Update Service in HIS by Integration Platform.

Service of research results transfer by HIS Patient Portal to Integration Platform.

Registration of performed patient results in HIS Portal.

GPs access to EHR and their own tasks supporting the process of LSV teleCare

procedure.

Nurses access to the EHR, and their task of process that supports the LSV teleCare

procedure.

Patients access to their own PHR tasks supports the process of LSV teleCare

procedure.

Implementation e-Prescription in SIM (P1) during the LSV teleCare procedure.

Call Centre staff access to their own tasks supporting the LSV teleCare procedure

process. Receive e-mail and SMS alerts.

Page 50: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 50 of 106 Public

Doctor, nurse and patient access to the Information and Education Portal.

Call Centre staff access to the Information and Education Portal.

Some of the developments and changes will revolve around the new interoperability platform Integratis.

4.4 Veneto

4.4.1 CareWell service specification

Stable Patients – out of hospital care

The service model underpinning the multi-disciplinary care pathways already

implemented in Veneto will be further enhanced in the following ways through CareWell:

An online patient’s ‘dashboard’ will be created; it will bring together the relevant

information from health and social care records, home-care service records, and

hospital records. This ‘dashboard’ will be accessible to all care practitioners involved

in a patient’s care through a role-based access model.

The care pathway data collection that informs the multi-dimensional assessment

will be enhanced through the patient ‘dashboard’.

Home-care nurses will provide a monitoring service to patients; the information will

be shared with relevant healthcare practitioners via the Territorial ICT system.

The home-care nurses will provide a telemonitoring service responding to patients

entering their physiological measurements and symptom management

questionnaire answers into the system.

The home-care nurses’ monitoring systems will include educational material to

assist the patient to self-care and self-manage.

In addition to the educational material available in the monitoring system, web-

based material will be available through the ULSS 2 authority website.

Patients will be able to access the interactive portal within the ULSS 2 website,

where they will be able to provide and receive information about their health and wellbeing, search for some information in their health reports, and download results

of tests and investigations and book appointments.

The Territorial ICT system will facilitate the sharing of information, care plans,

patient monitoring measurements and self-management materials with all those in the care team.

Unstable Patients – out of hospital care

All the above functionality and enhancement to the service model will be available for the

‘unstable’ patient. Any deterioration in the patient’s condition should be able to be

responded to more appropriately as there will be much greater near-time information available to the relevant care practitioners. In addition, telemonitoring will allow

patients, assisted by a nurse, to receive a teleconsultation with the specialist if

necessary.

Inpatient - hospital care

Hospital healthcare professionals will have access to the patient ‘dashboard’, and should

improve the information supporting decision-making in assessing and drawing up the

care plan for the patient.

Page 51: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 51 of 106 Public

Inpatient – hospital discharge preparation

The availability of the home-care nurses monitoring and telemonitoring services will

facilitate the hospital discharge of a patient. In addition, the continuity of care across the different care sectors will be improved through the implementation of the patient

‘dashboard’ and consistency in education material to support the patient to self-care and

self-manage.

Table 11: Evolution of ICT-enabled services in Veneto

Veneto Before After

ICT-enabled service Operational

Maturity

level Operational

Maturity

level

e-prescription YES 5 YES 5

Messaging clinician Patients NO 0 NO 0

EHR YES 1 YES 4

Interconsultation NO 0 YES 4

Call Centre NO 0 YES 3

Virtual Conference NO 0 YES 4

PHR NO 0 YES 3

Nurse Information System

(record of nursing care) NO 0 NO 0

Educational Platform NO 0 YES 4

Collaborative Platform NO 0 NO 0

Telemonitoring NO 0 YES 4

Multichannel Centre

(Management Telecare Programs) YES 5 YES 5

4.4.2 CareWell IT architecture

The most important challenge for Veneto pilot during CareWell is the integration the EHR

in primary and secondary care. This integration is possible thanks to extending the use of

Territorial Information System to secondary care.

This challenge is not only the number of users, this challenge represents others problems to resolve such as:

To implement new roles of users.

To share information among services and levels of care;

To develop new interoperability connections.

Major risk of data duplication and incremental cost of support and management.

Page 52: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 52 of 106 Public

Figure 24: CareWell IT architecture of Veneto

The patient empowerment and home-support services pathway will include the following

IT architecture developments:

Develop a personal health folder.

Develop the educational web site.

In order to achieve the integration of the Territorial Information System at all clinical

levels, the Veneto Pilot will use Mirth Connect, a cross-platform HL7 interface engine that

enables bi-directional sending of HL7 messages between systems and applications; it

allows interoperability between health systems. In addition, there are some applications that use ESB (Enterprise Service Bus), that is an open source solution, but it has been

customised by the providers, and it is thus proprietary software.

Page 53: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 53 of 106 Public

Figure 25: Veneto Territorial Information System

4.5 Puglia

4.5.1 CareWell service specification

CareWell will facilitate the development and implementation of additional care pathways

for chronic diseases.

Stable Patients – out of hospital care

CareWell will facilitate the development and implementation of additional services for chronic diseases. Therapeutic recall to improve adherence will be provided together with

educational services that can be accessed by patient from a web based platform (Nardino

enhancement). Patients will be cared for in a more integrated way by their GP in

collaboration with nurses and specialists in outpatient clinics who can share information through the EHR. Specialists will be involved in sharing information through EHR and to

consult and update patient's information in EHR. Messaging and picture sending service

(8 a.m. – 8 p.m.) between informal care giver and Care Manager will be put in place

according to a protocol. This can be useful to support the patient in self-care and self-

management, particularly in relation to recognising symptom deterioration or improvement, clarification on medications, etc., as well as e.g. monitoring wound

healing, say a diabetic ulcer.

Page 54: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 54 of 106 Public

Unstable Patients – out of hospital care

As with the stable patient, a patient considered to be ‘unstable’ will be cared for by the

same team, and will benefit from the same new services mentioned above, with an increased frequency of delivery, needing additional monitoring and assessments,

frequent adjustments of therapy, or additional counselling. In addition, additional

services specified below will be implemented:

Each health professional involved in delivering the care and support of the care plan, thanks to his own log-in profile, can join a virtual ‘community of health

professionals’ using the online platform to discuss specific clinical problems of their

patients.

Each professional engaged in a patient’s clinical management will participate in periodic and planned briefings via videoconference to assess the general clinical

status of patients, according to a specific protocol agreed with the quality team.

Home monitoring will be introduced to measure blood pressure, weight, oxygen and

glucose in blood, from devices used by the patients in their homes, interfaced to

the Nardino software. All clinical measurements will be uploaded to the EHR.

Additional consultations / advice through the EHR will be provided according to a

defined protocol in response to alerts generated from the telemonitoring

technologies.

Inpatient - hospital care

When an ‘unstable’ patient is unable to be managed at home through the integrated care

pathway in primary care, the GP or specialist will refer the patient to the hospital for an

admission. When a patient is admitted to a reference hospital, the EHR information will

be available to the healthcare practitioners involved in CareWell; this should improve decision making and inform the assessment and care planning process. The integrated

care pathway will be enhanced with a more active specialist participation (even the

hospital specialist). They will be able to refer a patient who has been admitted to

hospital inappropriately to the primary care team, suggesting home telemonitoring, as this has the potential to increase the patient’s confidence to self-care and self-manage,

and provide the primary care team with additional information for decision support in the

event of a patient reporting deteriorating symptoms.

Inpatient – hospital discharge preparation

The stabilised patient is discharged from hospital back to his home. Hospital specialist entrusts the patient to territorial Care Manager, and clinical information for the territorial

care team is provided by EHR. Services for stable patient as above will be provided.

Below is the summary of ICT-enabled services which will be implemented within

CareWell:

Table 12: Evolution of ICT-enabled services in Puglia

Puglia Before After

ICT-enabled service Operational

Maturity

level Operational

Maturity

level

Messaging clinician Patients NO 0 YES 4

EHR YES 3 YES 4

Interconsultation NO 0 YES 4

Call Centre NO 0 NO 0

Virtual Conference NO 0 YES 3

Page 55: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 55 of 106 Public

Puglia Before After

ICT-enabled service Operational

Maturity

level Operational

Maturity

level

PHR NO 0 NO 0

Nurse Information System YES 4 YES 5

(record of nursing care)

Educational Platform NO 0 YES 4

Collaborative Platform YES 3 YES 4

Telemonitoring YES 2 YES 4

Multichannel Centre NO 0 NO 0

4.5.2 CareWell IT architecture

Below is the CareWell IT architecture of Puglia, illustrating the communication exchange and information flows:

Figure 26: CareWell IT Architecture of Puglia

New systems or new functionalities

During the CareWell implementation, the CARE Puglia Program platform will be enhanced

to support new service delivery; and will undergo many technical adaptations.

A new clinical profile will be created to allow specialists to access the EHR and share information with the Care Manager and GP. A new user role will be defined giving them

the possibility to update information on patients and consult information uploaded from

other members of the care plan. The platform is fully compliant with DICOM 3.0

Page 56: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 56 of 106 Public

standard, so CARE Puglia software will integrate with PACS for management of all forms

of diagnostic imaging to implement specific work flow or process a second opinion, or in

general, to support specialised activities.

Technological adaptation will be provided to create an interface between the

telemonitoring device hub software (at patient’s home) and Care Puglia software and to

create conditions for platform to receive clinical parameters from home monitoring;

platform adaptations are also necessary, and they will be provided to send therapeutic recalls toward HUB; it will also be enhanced to support the release of educational tools

for patients and their informal caregiver (by their own PC), and to upload images coming

from messaging service between patients and Care Manager. Technical interventions

both on platform and Hub software will be set to create warning on the platform from out-of-range clinical parameters revealed by home devices.

4.6 Wales

4.6.1 CareWell service specification

Stable Patients – out of hospital care

The care pathway and service model for ‘stable’ patients living with complex needs will

be enhanced through the following ICT functionality and associated new ways of working:

MSDi case finding tool to target CareWell service at patients most likely to benefit.

Access to the Individual Health Record (IHR) for community nursing and therapy

staff through TotalMobile.

Video conferencing communication within the community nursing team through

Microsoft Lync.

Community nursing team able to access the GP EHR to record contacts,

measurements taken, and care given.

Comprehensive directory of health and wellbeing services available for patients in

Powys through the Info Engine.

Community nursing team will provide a telemonitoring service in response to

patients taking and uploading their own physiological measurements at home.

GP practice websites to include chronic conditions management educational content

to support patients to self-care and self-manage.

Patients will have access to My Health Online where they will be able to view a

subset of their GP EHR, book GP practice consultations, order repeat prescriptions,

and update their demographic details if necessary.

Unstable Patients – out of hospital care

All of the above functionality will be available to support improved team working and response services for patients who experience a deterioration in their health and

wellbeing.

Inpatient - hospital care

Healthcare professionals in the community hospitals will have richer information to understand the nature of a patient’s deterioration leading up to their emergency

admission, including telemonitoring information and any symptom management

questionnaire responses. It is likely that the acuity of patients requiring hospital

admission will increase, as more patients are able to be managed by telemonitoring and support in their own homes for minor exacerbations.

Page 57: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 57 of 106 Public

The use of TotalMobile and Microsoft Lync by the community nursing team will facilitate

improved communication between the team and community hospital staff.

Inpatient – hospital discharge preparation

The availability of the community nursing team’s telemonitoring service will facilitate the

hospital discharge of a patient. In addition, the patient will be signposted to the relevant

chronic conditions management educational content on the GP practice website, and any

additional support services available from searching the Info Engine.

Below is the table of CareWell ICT-enabled services:

Table 13: Evolution of ICT-enabled services in Wales

Wales Before After

ICT-enabled service Operational Maturity

level Operational Maturity

level

e-Prescription YES 5 YES 5

Messaging clinician Patients NO 0 YES 5

EHR YES 5 YES 5

Interconsultation NO 0 YES 2

Call Centre YES 2 YES 2

Virtual Conference NO 0 YES 5

PHR YES 4 YES 5

Nurse Information System (record of nursing care) YES 2 YES 2

Educational Platform YES 2 YES 4

Collaborative Platform YES 3 YES 5

Telemonitoring NO 0 YES 4

Multichannel Centre

(Management Telecare Programs) NO 0 NO 0

4.6.2 CareWell IT architecture

The most significant changes in the IT architecture will be those to deliver the patient

empowerment and home-support services pathway.

Changes or new systems (pathway empowerment and home support):

Access mobile to EHR app: The current and newly developed systems will be

adapted to run on mobile devices such as Smartphones and tablets for the district

and specialist nurses to use when the make visits to patients’ homes.

Implement a telemonitoring service.

Develop a single database with social and clinical information for community

services which is currently undergoing a national procurement.

Educational materials and information available on GP practice websites.

Below is an illustration of the CareWell IT architecture to be implemented in Powys:

Page 58: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 58 of 106 Public

Figure 27: CareWell IT Architecture of Wales

The integrated and coordination services pathway will be enhanced in the following ways:

Implement Interconsultation message (referrals) through EHR between clinicians.

Implement live communication tool between community nurses and GP.

Implement videoconference.

Page 59: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 59 of 106 Public

5. Guidelines to achieve interoperable and efficient IT systems

5.1 Guidelines for the development of interoperable systems

In order to effectively provide integrated care services, it is necessary to be able to share

information between the various stakeholders. Over many years, the healthcare organisations in the CareWell pilot sites have implemented a variety of IT systems to

provide business and clinical care functionality in the different care settings, but the

extent to which data and information stored in these systems is shared with other

systems and users is variable.

There are two distinct terms used to describe ways of sharing information electronically:

Systems integration.

Systems interoperability: The IEEE defines interoperability as the ability of two or

more systems or components to exchange information and to use the information

that has been exchanged.

Systems integration is the common solution when two or more systems are not

interoperable. Several cases to implement this solution are:

Legacy systems where database technology does not allow access to data for

sharing with other applications.

Legacy systems where it is not possible develop processes to use data from other

applications.

In cases of developing new systems, the normal guidelines include the major

functionalities and services in the same application (services provided at the moment by others applications).

In any of these three cases, and especially in the last, the trend is the creation of the

integrated system needed and the provision of the technology required to turn it into an

interoperable system, and therefore able to share information to provide benefits such

as:

Easier functional scalability.

Single storage for data (avoiding data duplication).

Decrease of systems maintenance costs.

Improving the performance of applications due to interoperable systems displaying information in a more structured and easily readable way.

Re-use of resources.

Standardisation of new developments (reducing costs).

5.1.1 Levels and environments of interoperability

To achieve strong interoperability among systems, we should achieve an optimum level of three interoperability levels: Syntactic, Semantic and Organisational.

Page 60: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 60 of 106 Public

5.1.1.1 Syntactic interoperability

If two or more systems are capable of communicating and exchanging data, they are

exhibiting syntactic interoperability. Specified data formats, communication protocols and the like are fundamental. XML or SQL standards are among the tools of syntactic

interoperability. This is also true for lower-level data formats, such as ensuring

alphabetical characters are stored in a same variation of ASCII or a Unicode format (for

English or international text) in all the communicating systems.

Syntactical interoperability is a necessary condition for further interoperability.

5.1.1.2 Semantic interoperability

Beyond the ability of two or more computer systems to exchange information, semantic

interoperability is the ability to automatically interpret the information exchanged

meaningfully and accurately in order to produce useful results, as defined by the end users of both systems. To achieve semantic interoperability, both sides must use a

common information exchange reference model. The content of the information

exchanged must be unambiguously defined: what is sent is the same as what is

understood.

In the field of health information, achieving semantic interoperability is even more

important and difficult.

Semantic interoperability has two subparts:

Overall semantic interoperability implies the ability to communicate with other systems and interpret information from these correctly. This is possible thanks to

the application of standards to define concepts (content) and logical rules.

Distributed processing is the most common form of semantic interoperability.

This implies that systems are implemented to meet standards to communicate and

interpret information that are not able to make logical deductions. These systems implement a rigid set of standards for information exchange which cover, by prior

arrangement, what information is exchanged, how and in what format, among

others. The name refers to distributed processing of the information generated in a

system that communicates with another to generate some kind of result value. Changes in the exchanged messages often require changes to software, which is

clearly not desirable.

The main objective is to achieve semantic interoperability, because it has a direct impact

on the daily work of health professionals and citizens; this interoperability makes it possible to exchange and use information. This interoperability has two levels:

1. Semantic interoperability for viewing: Viewing information is the most common need

of health information systems, because often the information held in one system

needs to be viewed in another. For example, the results of laboratory tests need to be

viewed in an EHR system.

For the correct interpretation of information displayed in a different system, there are

three main aspects to consider:

How to display the information.

How the user is accustomed to see the information.

What device is used to view the information?

2. Semantic interoperability for processing. The automatic processing of information is

one of main principles of IT, and one of processes that improves the value of health

IT. The objectives of automatic processing of information include:

Quality assessment: correction and completeness of information.

Page 61: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 61 of 106 Public

To calculate indicators, percentages, durations, etc.

To look for information of patient: bibliography resources, etc.

Derivation: analysis to find new information from the current system.

Decisions support, validations secure card, rules evaluation, alarms, etc.

Processing, consolidation, communication and storage.

To achieve automatic processing of information, this information should be correctly

structured.

5.1.1.3 Organisational or business interoperability

To achieve such interoperability, business process rules must be specified together with

actors involved. Defining business rules requires analysis of various areas within an

organisation (emergency, inpatient, outpatient, laboratories, pharmacies and others),

their needs, their structure, their responsibilities and their products. The only way to have a clear vision of the entire organisation is through formal definition of its

components and the information they generate and consume. The same concept can be

applied to the health system as a whole, with its components (actors), rules (laws), goals

(welfare, trainers, research and regulators) and the interdependencies between them.

5.1.2 Standards

The need for interoperable systems is evident in every part of health sector

organisations, as effective delivery of healthcare requires a constant exchange of

information among health professionals, including service institutions, insurers and

government, between medical staff and patients, between auxiliary imaging systems and laboratories, with electronic medical records systems and between public health systems,

just to mention some interactions.

Consequently, effective communication between these actors requires a common

framework that allows interaction and coordination of care sharing. The framework is provided by the standards, which provide uniformity in the name of the components of

the health system, whether diagnoses, people, procedures, interventions, and how it is

transmitted, to ensure that data in one part of the system health are available and have

meaning not only through the variety of clinical settings and public health but also administratively.

In Figure 28 we have a map with the most common standards and protocols (grouped by

areas). These standards can be considered as an infrastructure of every IT system which

interchanges data with other systems.

Page 62: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 62 of 106 Public

Figure 28: Standards v. interoperability levels

The importance of this schema is to visualise that the use of a single standard is not enough to achieve the different types of interoperability; it is necessary to look for

additional standards and with different foci, which together enable communication and

use of information.

Effective use of information through a set of information systems is not achieved only

with the pact that the systems can communicate; this is not possible even if the same standard of communications used. This problem is inherent in the information itself, as

well as the way it is obtained, processed and stored.

Therefore, for effective interpretation and processing of information it is necessary to

apply standards that allow representation of the context of information. Below is a brief description of the standards presented in the map in Figure 28, which are organised by

foci or areas of application, its aims and relations it performs.

Communication infrastructure: In this area are the standards and protocols that enable

physical and logical communication between computers and networks.

Protocols that underlie the Internet are listed (Interoperability Toolkit (ITK) of the

National Health System (NHS) in the UK).

Ethernet is a protocol link layer (layer 2 Open System Interconnection model or

OSI) that allows two devices connected via a link (cable) data exchange higher layer protocols.

TCP / IP protocols are the most used in the world. TCP is a transport protocol (layer

4 of the OSI model) that allows you to create logical connections over an IP

network between two physically distant computers. IP is a network layer protocol

(layer 3 of the OSI model). These protocols enabled the implementation of Internet.

The following topics related to standards are discussed in more detail in Appendix B:

Page 63: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 63 of 106 Public

Communication Protocols (general applications).

Syntax standards.

Format Specification.

Services Specification.

Process Specification.

Communication Protocols (Health applications).

Terminology and health nomenclature.

Clinical documentation.

Models of information.

Architecture of communication.

Knowledge models.

5.2 Interoperability Tools in CareWell pilots

This section describes at the level of implementation the interoperable tools in CareWell pilot, focusing on two points:

What interoperable platform is used by the pilot?

What standards are used in the CareWell systems?

5.2.1 Basque Country

Interoperable platform

Basque Country has addressed its interoperability policy to SOA (Service Oriented

Architecture). Central to this architecture is the deployment of a commercial bus service

(oracle Service Bus). Currently the Basque Country has deployed around 300 web

services to share clinical, demographic and administrative information among corporate systems.

The main applications to provide web services are:

E-Osabide : Hospital Information System (Administrative Tool).

SAP: Commercial tool for management of financial and RRHH.

CRM: Web services for Telecare and telemonitoring.

Presbide: e-Prescription system.

Page 64: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 64 of 106 Public

Figure 29: Interoperable platform

Standards Used in CareWell system

Below is a table which describes the standards used in the Basque Country pilot site.

Table 14: Basque Country standards used

Application Semantic

standards

Syntactic Standards Organisational

Interoperability

e-Prescription LOINC, ICD 9/10 HL7, xml, http, https, SOAP CDA1,

Osabide AP ICD 9/10 DICOM, html, http, https,

XML, FTP

CDA1

Osabide Global ICD 9/10 HL7, DICOM, xml, http,

https, ftp

CRM LOINC, ICD 9/10 xml, pdf, Cades, DICOM,

HL7, SOAP

PHR https, PDF, HL7 CDA1

Educational

Web

Page 65: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 65 of 106 Public

5.2.2 Croatia

Interoperable platform

Croatia pilot has not deployed any interoperability platform. The single system for interconnecting systems or providing access to clinical data in secondary care from

primary care IT systems is a VPN connection.

Standards Used in CareWell system

Below is a table which describes the standards in use in the Croatia pilot site:

Table 15: Croatia standards used

Application Semantic

standards

Syntactic Standards Organisational

Interoperability

EMH LOINC, ICD 9/10 HL7v3, HL7v2, XML, SOAP,

HTTPS

CDA1, Digital

Signature

5.2.3 Lower Silesia

Interoperable platform

Wroclaw pilot has a bus service in every hospital used for interoperability of legacy

systems with HIS.

Standards Used in CareWell system

Below is the table containing the standards used in the Lower Silesia pilot site:

Table 16: Lower Silesia standards used

Application Semantic

standards

Syntactic

Standards

Organisational

Interoperability

Mobile ICD9/ICD10 XML / HTML Dictionaries, HL7

Web ICD9/ICD10 XML / HTML Dictionaries, HL7 not yet

implemented

Client/Server ICD9/ICD10 XML / HTML Dictionaries, HL7 not yet implemented

Communicator Not referred Not referred Not referred

5.2.4 Veneto

Interoperable platform

The Local Health Authority uses Mirth Connect, a cross-platform HL7 interface engine that enables bi-directional sending of HL7 messages between systems and applications; it

allows interoperability between health systems. In addition, there are some applications

that use ESB (Enterprise Service Bus); this is an open source solution, but it has been

customised by the providers and is thus proprietary software.

Standards Used in CareWell system

Below is the table containing information on the standards used in the Veneto pilot site:

Page 66: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 66 of 106 Public

Table 17: Veneto standards used

Application Semantic

standards

Syntactic

Standards

Organisational

Interoperability

e-Prescription/ GP and

Pharmacy’s software

LOINC, ICD 9/10 HL7, xml, http,

https, SOAP

CDA2, IHE

web site html, http, https

Regional Tele-emergency Solution

HL7, DICOM, xml, http, https, ftp

e4cure and Talete LOINC, ICD 9/10 xml, pdf, Cades,

DICOM, HL7, SOAP

IHE

5.2.5 Puglia

Interoperable platform

Puglia has an open source interoperability platform.

Standards Used in CareWell system

Below is the table containing information on the standards used in the Puglia pilot site:

Table 18: Puglia standards used

Application Semantic

standards

Syntactic

Standards

Organisational

Interoperability

CARE Puglia Program SOAP WSDL XML ebBPSS

5.2.6 Wales

Interoperable platform

Powys (Wales) has an internal interoperability platform (WCCG).

Page 67: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 67 of 106 Public

6. Security and confidentiality of data This section describes the elements, tools and processes required for data security

management. For this purpose, three principal aspects are considered:

1. Identification, authentication and authorisation of persons and devices: this aspect

ensures that all system users, no matter what device they use, are able to be identified and given the appropriate level of access to only the information that is

relevant for that defined role.

2. Security of stored and exchanged data: all information shared electronically and

stored in IT systems must comply with legal and ethical legislation and guidance.

The level of security varies for example, according to who the exchange is between, whether the information exchange is person identifiable, contains any sensitive

information, encryption regulations and patient consent.

3. Establishment of guidelines, standards and best practices to ensure effective

management of risks and threats: in order to ensure the security of health information systems and communications, appropriate regular audit processes should

be implemented, and immediate steps taken to rectify any threats and breaches,

together with remedial action to minimise future breaches in security and

confidentiality of patient-held data.

The next sub-sections detail how the above three key aspects of security and

confidentiality of data are approached in each pilot site.

6.1 Basque country

Identification, authentication and authorisation of persons and devices

The Basque Health Service is gradually adopting a policy-based user management

identity management and access through SSO (single sign on), so that once the user is authenticated in the OS of their computer, the system operative in charge of passing

credentials matches the user identity to each application that is incorporated in the

system. This process is underpinned by role-based access protocols.

To support this, Osakidetza has a centralised system and an active user directory system, not only for professionals but also other staff with access to the system.

The e-Prescription and the PHR systems in Osakidetza use an electronic personal

certificate, with e-Prescription also including a secure electronic signature for

prescriptions through PKI architecture.

Security of stored and exchanged data

In Osakidetza there are two levels of security implemented, depending on whether the

data is being exchanged between internal or external systems. If the exchange includes

external systems, all communication of data is secured through the use of HTTPS (HTTP

over SSL or HTTP Secure). Information and data exchanged between internal systems is secured through the individual and role-based identification and authentication process.

In addition, Osakidetza has other tools implemented to protect their communications

such as the demilitarised zone (DMZ).

The diagram below shows the secure architecture for external communications:

Page 68: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 68 of 106 Public

Figure 30: Secure architecture for external communications

To ensure secure storage, security protocols for Osakidetza demand making incremental

backups every day. These backup copies are stored in a different location to cpd.

Actions for effective management of risks and threats

Preventive Actions (Audit systems): An audit system is implemented as a

preventive action. In the Basque health service, the systems which manage data

with a high level of security implement audit systems supported by a basic server log that has information on user actions and activities: user, role, and time of

access.

In addition, Osakidetza uses ORACLE databases that can allow auditing of the

activities, depending on the edition of the database.

Reactive Actions: There is a system to monitor the network against external attacks in operation every day. There is also a document with all necessary protocols and

processes to execute in case of external attack.

6.2 Croatia

Identification, authentication and authorisation of persons and devices

Users

CareWell systems implemented are:

G1: Different levels of security including physical access control, private networks,

network data encryption, as well as smart card authorisation allowing access of G2

applications to central system.

Page 69: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 69 of 106 Public

G2: Smart card authorisation for each user, https, private networks (there are

several G2 market app).

Ericsson Mobile Health: This system is protected with user name / password secure access for each user on web application and Android device.

Devices used and connections with back-ends

The communication between the Android devices and the back-end system uses HTTPS

protocol and encrypted communication channel by SSL.

Security of stored and exchanged data

All clinical reports providing clinical data, which are reported to G1, are digitally signed.

Digital signature is provided with the same smart card used for secure access using the

e-health national PKI infrastructure.

The system is shown in the figure below.

Figure 31: PKI infrastructure e-health in Croatia

Regarding stored data, data is stored in two separate databases on the back-end system;

one includes patient demographic information, and the other contains anonymous clinical

data and measurements. Once the authorised user signs in with username / password, a

patient's name is related to a specific set of medical data (measurements, questionnaires, etc.). Security data backups are made on a regular basis to protect data

from being lost. In addition, a redundant EMH server is used to secure service delivery

continuity.

In addition, system data transmission channels in Ericsson Mobile Health are protected at

four levels in Ericsson Mobile Health:

Medical Sensors -> Gateway

Standard Bluetooth authentication (PIN based).

Gateway -> Back-end Server

HTTPS protocol.

Back-end server

Physical separation of data.

Session and Role-based security.

Back-end server -> Web application

HTTPS protocol.

Page 70: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 70 of 106 Public

Figure 32: Layers of security communication channels Croatia pilot

Actions for effective management of risks and threats

Preventive Actions (Audit systems): An audit system is implemented as a

preventive action. In Croatia, the EMH system has a basic server log that has

information on user actions and activities: user, role, and time of access.

In addition, the EMH uses MySQL database that can allow auditing of activities,

depending on the edition of the database (Enterprise edition has auditing features). For the CareWell project, MySQL Standard edition will be used which does not allow

for auditing.

Reactive Actions: A monitoring system against external attacks is deployed and

tested in both provider and client environments. The system is secured in the intranet, and entry is protected by a firewall. The back-end system only accepts

connections from registered devices on particular ports. In addition, restoration of

the database is initiated when a corruption is identified (for this action, MySQL

workbench tool is used).

Page 71: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 71 of 106 Public

6.3 Lower Silesia

Identification, authentication and authorisation of people and devices

Users

Managing access to the application in the CareWell monitoring system (LSV) will be based on user / password.

Devices used and connections with back-ends

Devices use the Bluetooth connectivity protocol.

Security of stored and exchanged data

Sensitive data will be stored on the server in the organisation that owns the data

(hospital); for databases containing sensitive data, secure backup copies will made every

day.

In the data centre, backup copies are made in full: –daily, incremental –weekly and

monthly scheduled.

Lower Silesia secures the data transmission channels by SSL (https). The diagram below

illustrates the security channels architecture. In the data centre, the data transmission

channels are protected by SSL certificate; access to resources is also carried out by VPN.

Figure 33: Security architecture of data transmission channels in Lower Silesia

Page 72: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 72 of 106 Public

Actions for effective management of risks and threats

Preventive Actions (Audit systems): The Lower Silesia Integration platform, which

implements the procedure for telemedicine and telecare services, will keep a log file in a database recording the following data on the operations performed on the

system: who?, when? and what kind of operation was performed? This will include

the login to the application.

Reactive Actions: In the data centre, there is a full system backup, which allows data to be restored after a loss or malfunction. The CareWell monitoring system

integrator will develop a procedure for restoring databases after a crash.

In relation to monitoring systems against external attacks, the hospital policy is based

on:

Accessing the WAN (Internet) is possible for staff only; patients do not have access

to internet.

Local Area Network is protected against intrusion from the network (wide) external

using hardware firewall in the main router (model VIGOR 2910G).

Firewall allows filter packets (SPI), call filter, data filter, protection against DoS /

DDoS filter, IM / P2P filter, URL content filter and Web content filter.

In order to reduce the possibility of infecting computers in the local network by

viruses, and to protect against unauthorised access and minimise risk, professional

firewall software (firewall) and professional anti-virus program are used on each computer; the server at the hospital has ESET Smart Security Software.

The data centre has a Cisco IPS and IronPort system.

6.4 Veneto

Identification, authentication and authorisation of people and devices

Table 19: Veneto kinds of secure access

App Secure access Kind of secure access

ePrescription/ GP and Pharmacy’s

software

Yes user/password

web site Only for some services

like reports download

user/password

Regional Telemergency Solution Yes user/password

Territorial Information System Yes user/password

e4cure and Talete Yes user/password

ACG and Qlickview Yes user/password

App7 Yes User/password

Users

Referring to CareWell systems, the services that are already implemented are:

ePrescription

The prescribing physicians authenticate themselves on a security infrastructure

created at regional level. The architecture uses federated authentication. All actors

authenticate themselves to services through a system of identity management,

located in all local health authorities of Veneto region. The system of access is

declined in two levels. The authentication in the system takes place through

Page 73: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 73 of 106 Public

username, password and software certificates; as a result of this authentication

process, a token is issued that allows access to service and delivers all useful

information. This token has a period of validity.

Telecare

Patients have an emergency button to communicate through E.R. Social assistants

of Local Health Authority have username and password to access database in which

there is all information about patients who have this service (https protocol).

Medical interconsultation

This service allows consultation between specialists. Physicians access the software

through username and password, and can see clinical reports and patient data

carried by other specialist in accordance with Italian privacy law. The information sharing is within the LAN of the Local Health Authority so data are protected from

external attacks.

Devices used and connections with back-ends

The CareWell system devices that will be used by nurses when delivering services at the patient home are: portable ECG, oximeter, portable glycosylated haemoglobin device,

portable spirometer, and portable blood gas analyser, tablet/PC, webcam digital camera.

The connection for the import of data from devices to ICT system will use bluetooth, wifi

or USB protocol depending on the technical features of the specific device. For the

telecare service, patients have an emergency button which communicates with E.R. through the PSTN (Public Switched Telephone Network).

Security of stored and exchanged data

In Veneto, the following reports are signed: emergency reports, hospital discharge

reports, anatomical pathology reports, radiology and laboratory analysis reports, and discharge summaries.

Systems of Veneto pilot do not store sensitive data in devices; this data is stored only in

the server of local health authority of ULSS N.2; the data backups are collected every

day.

The Local Health Authority has different procedures to protect data transmission. The

transmission in the LAN is protected from external attacks through firewall, proxy and

antivirus. There are dedicated transmission channels in which operators access through

specific tools such as VPN and https protocol.

Page 74: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 74 of 106 Public

Figure 34: Security architecture of data transmission channels in Veneto

Actions for effective management of risks and threats

Preventive Actions (Audit systems): There is an appliance that records all access by

system administrators to various servers. Each application has its own log of

activities (log in dates, log out dates). For ePrescription service, the system records

authentication logs (user name, ID software, log in dates).

Reactive Actions: In case corruption or failure of database, the backup systems allow the recovery of the clinical data and reports. This process of backup / restore

is made by a system provider. To protect the systems against external attacks,

there is an Intrusion Prevention System (IPS) and an Intrusion Detection System

(IDS) which highlight and store anomalies in network traffic in the firewall. In addition, there is an active control on the availability of the systems that forwards

alarms if the systems are not available.

6.5 Puglia

Identification, authentication and authorisation of people and devices

Users

In Puglia, the applications use user / password authentication, while some systems use

CNS via digital certificates.

Devices used and their connections with back-ends

Clinical data will flow from wireless medical devices (weight scale, blood pressure and

glucose monitor, pulse oximeter) to a hub via bluetooth connection; data will flow from the hub to the web platform via 3G (mobile network) or landline phone connection.

Page 75: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 75 of 106 Public

Security of stored and exchanged data

In the Puglia pilot, the data will be stored on a central server. Care Managers, GPs and

authorised data manager (DBA, data base administrator) have access to it. All accesses are controlled by ID and password from Care Managers and DBA (weak authentication),

and by CNS (strong authentication via digital certificate) from GPs. To guarantee the data

stored on the central server, IT Puglia make two kinds of data backup:

Weekly backup (complete backup).

Daily backup (incremental backup).

In relation to the security of the data exchange channels in Puglia, the access to data

takes place from workstations connected to RUPAR, the public administrations network of

Apulia region, or from mobile stations by encrypted VPN. Access to data is controlled by ID and password, or digital certificates on smart cards. National certification and

registration Authorities guarantee traceability and legal non-repudiation of access (for

strong authentication). Encrypted data will be transferred to authorised partners for

processing and analysis; communication of results will be anonymous and macro aggregated.

Actions for effective management of risks and threats

Preventive Actions (Audit systems): In Puglia, systems for auditing access are

available. A database register of accesses tracks what, when, from which client the

access is undertaken.

Reactive Actions: In case of corruption, data will be taken from the daily and

weekly backup. Fault tolerance procedures (redundant storage and redundant

disks) are available. Moreover, the IT architecture has a CISCO CCNA certification

in each procedure.

6.6 Wales

Identification, authentication and authorisation of people and devices

Users

Users of CareWell systems use user id / password to access systems.

Devices used and connections with back-ends

The devices use wifi or LAN connections to transfer data to the back-end.

Security of stored and exchanged data

File storage:

Network storage on Microsoft domain.

Password protection using active directory.

SQL servers, firebird servers, and oracle servers.

Transmission of data:

WAN/LAN networks.

NWIS secure file sharing portal.

NHS.net.

MS Lync.

VPN.

Page 76: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 76 of 106 Public

Database backup is assured through a number of measures to safeguard information

stored in systems on Health Board networks. Where data is stored in remote locations,

such data will be replicated back to a central data store. Shadow copy functionality is enabled on file stores to enable easy end user recovery of data. Access to such

information will be accessed via DFS shares to enable easy switch over to alternative

physical storage with minimal interruption to service. Data is backed up from replicated

data storage to backup to disc storage. Those backups will also have offsite data stores and physical tape storage for weekly backups. Backup processes will also enable the

complete virtualised servers to new hosting hardware where deemed appropriate.

Regarding protection of data transmission channels, the network hardware will be housed

in suitably secure environments. On hospital sites, these may be restricted access locations with a locked data cabinet housing the equipment.

Critical systems will be held in secure hosting environments. These rooms will be secured

against unauthorised access with appropriate entry controls and intruder detection

systems where necessary. They will also have a number of environmental controls covering fire suppression, power, and air conditioning, as necessary.

UPS devices will be provided following an assessment to ensure equipment is powered

during switchover to generator cover.

For authentication, the network will use RSA SecurID tokens. Authorised users will be

supplied with a unique user ID, a PIN and the token. The PIN and number displayed on the SecurID token forms a one use only password (the SecurID token number will

change very minute). The user account will be disabled after three failed attempts.

Actions for effective management of risks and threats

Preventive Actions (Audit systems)

The IT Operations Department will manage the Health Board’s information assets to

minimise risks to data and systems.

Computer systems will be configured with protection software and standard policies.

These will be designed to restrict access to systems and to monitor for unauthorised access.

Systems will be maintained to the latest approved standards to protect against software

bugs that could be used for unauthorised access.

A number of network management systems will be used to proactive monitor and

manage the data networks to identify risks or unauthorised access.

Audit processes will be undertake to ensure user access is appropriate to need, and

removed when no longer required.

Reactive Actions

With regard to active reactions in case failure database or system, there is provision of multiple proxy servers with failover provision to support access to internet resources,

together with a number of domain controllers to facilitate rapid authentication of users

onto the network. Major sites are provided with file servers that provide local file storage,

computer address provision, printing services. DFS (Distributed File System) is used both as a virtual access point to data, and as a method of replicating data between data

stores. National or regional data centres are used whenever possible to host applications

to reduce dependencies on local data storage; generally the service provision from such

locations will be of an enhanced nature including power provision / security / failover. Applications will be hosted, wherever possible, on virtualised systems to facilitate rapid

changeover to new hosts. Spare network equipment is maintained for emergency swap

out. Standard deployment is used wherever possible to enable users to log into any

Page 77: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 77 of 106 Public

computer, and to be able to access their applications. Processes are in place to support

rapid deployment of applications.

Regarding protecting systems against external attacks, the Powys pilot site uses a number of applications to monitor networks and end user devices to ensure compliance

with standards, identify issues before they cause major incidents, to enable remote

support and application deployment.

The systems used will include:

Microsoft System Centre to maintain software and hardware asset inventories and

to monitor asset compliance with standards. There is a further role to support the

deployment of applications or updates.

Microsoft Update Services which is used to manage the deployment of security updates to end user devices across the network.

Solarwinds to monitor network performance and to identify performance issues.

Wireless security and monitoring systems.

ePO to manage the security of devices and protect networks from malicious software.

Safend Management Console to manage removable media.

McAfee Endpoint Encryption to protect data storage from unauthorised access.

Mailmarshal service to protect email from messages containing viruses or other

risks.

Webmarshal to monitor and control internet access to minimise exposure to

compromised websites.

Controls through active directory are used to determine what can be installed and

used on computers to increase the security of the network.

Management systems are used to monitor computer systems and to protect them from

malware. The management system will provide updates and configuration changes from

a central location.

Operating System protection such as local firewalls is used to reduce the risks to devices.

Standard policies are applied to computers to restrict the ability to install, run

applications and restrict access to operating system files as appropriate.

Page 78: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 78 of 106 Public

Appendix A: Technological Terms .Net

NET is an integral part of many applications running on Windows and provides common

functionality for those applications to run. This download is for people who need .NET to

run an application on their computer. For developers, the .NET Framework provides a comprehensive and consistent programming model for building applications that have

visually stunning user experiences and seamless and secure communication.

Applet

An applet is a component of an application running in the context of another program, for

example in a web browser. The applet must run in a container, which provides a host program, through a plugin, 1 or applications such as mobile phones supporting

programming model ‘applets’

Unlike a program, an applet cannot run independently, provides graphical information

and sometimes interacts with the user, typically lacks session and have restricted security privileges. An applet normally takes within a very specific function that lacks

independent use. The term was introduced in 1993 in AppleScript

Common examples of applets are Java applets and Flash animations. Another example is

the Windows Media Player used to display video files embedded in browsers like Internet Explorer. Other plugins allow you to display 3D models that work with an applet.

A Java applet is a Java code that lacks a main method, so it is mainly used for work sites,

since it is a small program that is used in a HTML page represented by a small graphic

display within it.

Moreover, the difference between a JAVA applet and application is how to run. To load an

application JAVA interpreter (pcGRASP of Auburn University, Visual J ++ from Microsoft,

Sun Forte Visual Café) is used. Instead, an applet can be loaded and run from any

browser that supports Java (Internet Explorer, Mozilla Firefox, Google Chrome, Netscape

etc).

Call Centre

This is the office where a group of specifically trained people is responsible for providing

some care or telephone service. Importantly, the call centre can be operated by the

company itself or outsourced to an external company. There are companies that are dedicated to establishing call centres (with the necessary infrastructure and trained

personnel) and market such provision. There are essentially two ways you can organise a

call centre: dedicating one or more physical spaces (offices) of their activities,

earmarking a box to each of its employees; hiring people to perform work remotely. The latter is increasingly common, thanks to the amenities offered by Internet, allowing to

constantly monitor via instant messaging systems and send documents containing

relevant information to employees without any delay.

Page 79: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 79 of 106 Public

The main advantage of a call centre to a company is that centralises attention. If you do

not have a call centre, all calls arrive at different offices and be more difficult to decide

how they are channelled and recorded. The call centre, however, is intended solely to facilitate communication. Operators are trained to resolve issues on their own and newly

derived the call to an executive in exceptional cases

Client / server application

A client/server application is a piece of software that runs on a client computer and makes requests to a remote server. Many such applications are written in high-level

visual programming languages where UI, forms, and most business logic reside in the

client application. Often such applications are database applications that make database

queries to a remote central database server (this can, however, get much more complicated than that and involve other communication methods).

This screen shot shows an example of a client /server application running locally on a

computer. This is the same application shown running remotely in some of the Terminal

Server and Citrix screen shots in the previous section.

A client / server application can be cross platform if it is written in a cross platform

language, or it can be platform specific. In the case of a cross platform language there is

an advantage that the application can potentially provide a user interface that is native in

appearance to the OS or platform environment it is running under.

An issue of client/server is that the application must be installed on each user’s computer. Depending on the complexity of the program, the environment it is written in,

and the care the developer took to package the program, this can be as easy as creating

a shortcut to an executable on a shared network drive or it can be as hard as spending

hours installing and configuring runtime software and components on each client computer.

Page 80: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 80 of 106 Public

Client / server applications, either run locally on a client computer or through something

like Terminal Server, Citrix, or VNC, can work closely with the underlying OS to provide a rich, powerful, robust, easy to use interface.

By running locally on a client computer applications can also work with other local

hardware such as scanners, bar code readers, modems, removable media, accelerated

video for multimedia, or 3d video acceleration.

CRM

Customer relationship management (CRM) entails all aspects of interaction that a

company has with its customers, whether it is sales or service-related. While the phrase

customer relationship management is most commonly used to describe a business-customer relationship (B2C), CRM systems are also used to manage business to business

to business (B2B) relationships. Information tracked in a CRM system includes contacts,

clients, contract wins and sales leads and more.

DICOM

DICOM (Digital Imaging and Communication in Medicine) is world renowned for the exchange of medical tests, designed for handling, display, storage, printing and

transmission standard. Includes defining a file format and a network communication

protocol. The communication protocol is an application protocol that uses TCP / IP to

communicate between systems. The DICOM files can be exchanged between two entities

that are able to receive images and patient data in DICOM format.

DICOM enables the integration of scanners, servers, workstations, printers and network

hardware from multiple vendors within a storage system and image communication. The

different machines, servers and workstations have a DICOM Conformance Statement

(conformance statements) which clearly establishes the DICOM classes they support. DICOM has been widely adopted by hospitals and is making foray into small office

application dentists and doctors.

Page 81: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 81 of 106 Public

Digital Signature

A digital signature (not to be confused with a digital certificate) is a mathematical

technique used to validate the authenticity and integrity of a message, software or digital document.

The digital equivalent of a handwritten signature or stamped seal, but offering far more

inherent security, a digital signature is intended to solve the problem of tampering and

impersonation in digital communications. Digital signatures can provide the added assurances of evidence to origin, identity and status of an electronic document,

transaction or message, as well as acknowledging informed consent by the signer.

In many countries, including the United States, digital signatures have the same legal

significance as the more traditional forms of signed documents. The United States Government Printing Office publishes electronic versions of the budget, public and private

laws, and congressional bills with digital signatures.

Digital signatures are based on public key cryptography, also known as asymmetric

cryptography. Using a public key algorithm such as RSA, one can generate two keys that are mathematically linked: one private and one public. To create a digital signature,

signing software (such as an email program) creates a one-way hash of the electronic

data to be signed. The private key is then used to encrypt the hash. The encrypted hash

-- along with other information, such as the hashing algorithm -- is the digital signature.

The reason for encrypting the hash instead of the entire message or document is that a hash function can convert an arbitrary input into a fixed length value, which is usually

much shorter. This saves time since hashing is much faster than signing.

The value of the hash is unique to the hashed data. Any change in the data, even

changing or deleting a single character, results in a different value. This attribute enables others to validate the integrity of the data by using the signer's public key to decrypt the

hash. If the decrypted hash matches a second computed hash of the same data, it

proves that the data hasn't changed since it was signed. If the two hashes don't match,

the data has either been tampered with in some way (integrity) or the signature was created with a private key that doesn't correspond to the public key presented by the

signer (authentication).

A digital signature can be used with any kind of message -- whether it is encrypted or

not -- simply so the receiver can be sure of the sender's identity and that the message

arrived intact. Digital signatures make it difficult for the signer to deny having signed something (non-repudiation) -- assuming their private key has not been compromised --

as the digital signature is unique to both the document and the signer, and it binds them

together. A digital certificate, an electronic document that contains the digital signature

of the certificate-issuing authority, binds together a public key with an identity and can be used to verify a public key belongs to a particular person or entity.

Page 82: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 82 of 106 Public

Most modern email programs support the use of digital signatures and digital certificates,

making it easy to sign any outgoing emails and validate digitally signed incoming messages. Digital signatures are also used extensively to provide proof of authenticity,

data integrity and non-repudiation of communications and transactions conducted over

the Internet.

Electronic Health Record

An electronic health record (EHR) is a digital version of a patient’s paper chart. EHRs are

real-time, patient-centred records that make information available instantly and securely

to authorised users. While an EHR does contain the medical and treatment histories of

patients, an EHR system is built to go beyond standard clinical data collected in a provider’s office and can be inclusive of a broader view of a patient’s care. EHRs can:

Contain a patient’s medical history, diagnoses, medications, treatment plans,

immunisation dates, allergies, radiology images, and laboratory and test results

Allow access to evidence-based tools that providers can use to make decisions about a patient’s care

Automate and streamline provider workflow

One of the key features of an EHR is that health information can be created and managed

by authorised providers in a digital format capable of being shared with other providers

across more than one health care organisation. EHRs are built to share information with other health care providers and organisations – such as laboratories, specialists, medical

imaging facilities, pharmacies, emergency facilities, and school and workplace clinics – so

they contain information from all clinicians involved in a patient’s care.

Page 83: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 83 of 106 Public

Encryption

Encryption is the conversion of electronic data into another form, called ciphertext, which

cannot be easily understood by anyone except authorised parties.

The primary purpose of encryption is to protect the confidentiality of digital data stored

on computer systems or transmitted via the Internet or other computer networks.

Modern encryption algorithms play a vital role in the security assurance of IT systems

and communications as they can provide not only confidentiality, but also the following

key elements of security:

Authentication: the origin of a message can be verified.

Integrity: proof that the contents of a message have not been changed since it was

sent.

Non-repudiation: the sender of a message cannot deny sending the message

ePrescription

EPS allows prescribers - such as doctors and practice nurses - to send prescriptions

electronically to a dispenser (as a pharmacy) patient choice. This makes the process of

prescribing and more efficient and convenient for patients and staff dispensation.

Page 84: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 84 of 106 Public

Functionalities

In information technology, functionality is the sum or any aspect of what a product, such

as a software application or computing device, can do for a user.

A product's functionality is used by marketers to identify product features and enables a

user to have a set of capabilities. Functionality may or may not be easy to use.

HL7

HL7 and its members provide a framework (and related standards) for the exchange, integration, sharing, and retrieval of electronic health information. These standards

define how information is packaged and communicated from one party to another,

setting the language, structure and data types required for seamless integration between

systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services, and are recognised as the most commonly used in the

world.

HL7 standards are grouped into reference categories:

Section 1: Primary Standards - Primary standards are considered the most popular standards integral for system integrations, inter-operability and compliance. Our

most frequently used and in-demand standards are in this category.

Section 2: Foundational Standards - Foundational standards define the fundamental

tools and building blocks used to build the standards, and the technology

infrastructure that implementers of HL7 standards must manage.

Section 3: Clinical and Administrative Domains - Messaging and document

standards for clinical specialties and groups are found in this section. These

standards are usually implemented once primary standards for the organisation are

in place.

Section 4: EHR Profiles - These standards provide functional models and profiles

that enable the constructs for management of electronic health records.

Section 5: Implementation Guides - This section is for implementation guides

and/or support documents created to be used in conjunction with an existing standard. All documents in this section serve as supplemental material for a parent

standard.

Section 6: Rules and References - Technical specifications, programming structures

and guidelines for software and standards development.

Section 7: Education & Awareness - Find HL7's Draft Standards for Trial Use (DSTUs) and current projects here, as well as helpful resources and tools to further

supplement understanding and adoption of HL7 standards.

All HL7 Standards can also be located by other classifications such as ANSI/ISO/HITSP

approval and various search variables in our Master Grid.

HL7 encompasses the complete life cycle of a standards specification including the

development, adoption, market recognition, utilisation, and adherence. Please refer to

our IP Policy for more information about how members and non-members can use the

standards.

Hospital Information System (HIS)

A hospital information system is defined as the socio-technical subsystem of a hospital,

which comprises all information processing as well as the associated human or technical

actors involved in their respective information processing roles

Typical HIS components are:

Page 85: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 85 of 106 Public

Enterprise functions (i.e. hospital functions),

Business processes,

Application components,

physical data processing systems

The goal of a hospital information system is to sufficiently enable the adequate execution

of hospital functions for patient care, including patient administration, taking into account

economic hospital management as well as legal (e.g. data protection or reimbursement aspects) and other requirements

Hospital information systems have to consider various areas of a hospital, such as:

Wards and outpatient units

Service units: diagnostic (e.g., laboratory department, radiology department), therapeutic (e.g., operation room) and others (e.g., pharmacy, patient records

archive, library, blood bank)

Hospital administration areas (e.g., patient administration department, patient

record archive, department of quality management, financial and controlling department, department of facility management, information management

department, general administration department, human resources department)

Offices and writing services for (clinical) report writing

HTTPS

HTTPS stands for HyperText Transfer Protocol over SSL (Secure Socket Layer). It is a TCP/IP protocol used by Web servers to transfer and display Web content securely. The

data transferred is encrypted so that it cannot be read by anyone except the recipient.

HTTPS is used by any Web site that is collecting sensitive customer data such as banking

information or purchasing information. If you are making a transaction online, you should make sure that it is done over HTTPS so that the data remains secure.

IHE

IHE created and operates a process through which interoperability of health care IT

systems can be improved. The group gathers case requirements, identifies available standards, and develops technical guidelines which manufacturers can implement. IHE

also stages ‘connectathons’ and ‘interoperability showcases’ in which vendors assemble

to demonstrate the interoperability of their products.

IHE integration profiles describe a clinical information need or workflow scenario and

document how to use established standards to accomplish it. A group of systems that implement the same integration profile address the need/scenario in a mutually

compatible way.

For example, the Digital Imaging and Communications in Medicine (DICOM) standards

specify many different formats for image data. A given set of images that might comply with some optional parts of the standards might still not be accepted by an application in

use by a particular radiologist. Profiles reduce the chances of these incompatibilities.

The Logical Observation Identifiers Names and Codes (LOINC) standard codes for use in

databases are often used in IHE profiles.

A model for cross-enterprise document sharing called XDS allows hospitals to share

electronic records that use the Health Level 7 (HL7) standards and LOINC codes. The

United States Department of Veterans Affairs revised its plans in 1999 to adopt IHE

recommendations.

Page 86: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 86 of 106 Public

IHE integration statements are prepared and published by a vendor to list the IHE

profiles supported by a specific release of a specific product.

IHE technical frameworks are detailed documents which specify the integration profiles and associated actors (systems) and transactions. For example, one specification is for a

common way of binding identification numbers to patients.

IHE connectathons are annual events where equipment vendors bring products with IHE

profiles and test them with other vendors. The term ‘connectathon’ was coined in the 1980s by Sun Microsystems for similar vendor-neutral interoperability testing of the

Network File System protocols and related technologies. The events are held in Europe as

well as the US.

In 2008, an agreement was announced for cooperation with the Continua Health Alliance.

In 2012, a guide was published on access to health data from mobile devices.

Although in 2004 an estimate was that complete interoperability could be completed in

ten years, by 2013 results were still mixed.

In 2013, co-chairs were David Mendelson, director of clinical informatics at Mount Sinai Medical Centre and Elliot B. Sloane of the Centre for Healthcare Information Research

and Policy and research professor at Drexel University.

Interconsultation

A consultation is communication between two medical professionals with different areas

of expertise in which the applicant requires the review pathology of the patient to a consultant who gives its opinion on the case. Interconsultation usually occurs without the

presence of the patient by any communication system. The medical seeks advice

regarding a specific problem of a patient, either by complexity, severity, specialisation.

The ‘expert’ medical responds to the applicant issuing the judgment and recommendations on the care and treatment to be consulted about the problem. We

distinguish the following types:

Conventional Interconsultations. These are made based on a preprinted form where

the petitioner records data concerning the case and answerable to the interconsultation advice on treatment criteria or tests to be performed to the

patient.

Interconsultation of pre-application assessment appointment. Some specialties

have established a system of prior assessment of patients before requesting a

quote from initial consultations. In these cases the MAP, forwards the assessment form and the specialist responds by making express reference to the desirability of

quoting the patient in consultation and priority A&E appointment .

Interconsultation images. They are made by a computer system in which images or

electronic records to conventional data is attached. Serve to support telemedicine systems.

We addressing the scope, differences can those in the hospital setting (inpatient,

emergency room or served in queries) differentiated between levels: primary care and

specialised care.

Generally the consults are performed asynchronously between the applicant and the

consultant, having a delay time previously agreed response. Maximum time is generally

agreed in based on the priority of the case and the circumstances of the patient

(admitted in emergencies, etc.)

The process of consults, like any healthcare process, from the point of view of

information systems, should be part of the EHR. All data recorded on a consultation, they

Page 87: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 87 of 106 Public

have to be part of the patient's history and therefore must be stored in a structured

repository of the HCE.

The valuation (report) as part of the same care act should be part of the data warehouse EHR, and be available to professionals in both the specialised care setting as primary

care

Interoperability platform

In computing, cross-platform, or multi-platform, is an attribute conferred to computer software or computing methods and concepts that are implemented and inter-operate on

multiple computer platforms. The software and methods are also said to be platform

independent. Cross-platform software may be divided into two types; one requires

individual building or compilation for each platform that it supports, and the other one can be directly run on any platform without special preparation, e.g., software written in

an interpreted language or pre-compiled portable bytecode for which the interpreters or

run-time packages are common or standard components of all platforms.

JAVA

Java is a programming language expressly designed for use in the distributed

environment of the Internet. It was designed to have the ‘look and feel’ of the C++

language, but it is simpler to use than C++ and enforces an object-oriented

programming model. Java can be used to create complete applications that may run on a

single computer or be distributed among servers and clients in a network. It can also be used to build a small application module or applet for use as part of a Web page. Applets

make it possible for a Web page user to interact with the page.

The major characteristics of Java are:

The programs you create are portable in a network. (See portability.) Your source

program is compiled into what Java calls bytecode, which can be run anywhere in a network on a server or client that has a Java virtual machine. The Java virtual

machine interprets the bytecode into code that will run on the real computer

hardware. This means that individual computer platform differences such as

instruction lengths can be recognised and accommodated locally just as the program is being executed. Platform-specific versions of your program are no

longer needed.

The code is robust, here meaning that, unlike programs written in C++ and

perhaps some other languages, the Java objects can contain no references to data external to themselves or other known objects. This ensures that an instruction

cannot contain the address of data storage in another application or in the

operating system itself, either of which would cause the program and perhaps the

operating system itself to terminate or ‘crash.’ The Java virtual machine makes a

number of checks on each object to ensure integrity.

Java is object-oriented, which means that, among other characteristics, an object

can take advantage of being part of a class of objects and inherit code that is

common to the class. Objects are thought of as ‘nouns’ that a user might relate to

rather than the traditional procedural ‘verbs.’ A method can be thought of as one of the object's capabilities or behaviours.

In addition to being executed at the client rather than the server, a Java

applet has other characteristics designed to make it run fast.

Relative to C++, Java is easier to learn.

Java was introduced by Sun Microsystems in 1995 and instantly created a new sense of

the interactive possibilities of the Web. Both of the major Web browsers include a Java

virtual machine. Almost all major operating system developers (IBM, Microsoft, and

others) have added Java compilers as part of their product offerings.

Page 88: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 88 of 106 Public

The Java virtual machine includes an optional just-in-time compiler that dynamically

compiles bytecode into executable code as an alternative to interpreting one bytecode

instruction at a time. In many cases, the dynamic JIT compilation is faster than the virtual machine interpretation.

JavaScript should not be confused with Java. JavaScript, which originated at Netscape, is

interpreted at a higher level, is easier to learn than Java, but lacks some of the

portability of Java and the speed of bytecode. Because Java applets will run on almost any operating system without requiring recompilation and because Java has no operating

system-unique extensions or variations, Java is generally regarded as the most strategic

language in which to develop applications for the Web. (However, JavaScript can be

useful for very small applications that run on the Web client or server.)

Legacy System

A legacy system, in the context of computing, refers to outdated computer systems,

programming languages or application software that are used instead of available

upgraded versions.

LIS

A laboratory information system (LIS) is a class of software that receives, processes, and

stores information generated by medical laboratory processes. These systems often must

interface with instruments and other information systems such as hospital information

systems (HIS). A LIS is a highly configurable application which is customised to facilitate a wide variety of laboratory workflow models. Deciding on an LIS vendor is a major

undertaking for all labs. Vendor selection typically takes months of research and

planning. Installation takes from a few months to a few years depending on the

complexity of the organisation. There are as many variations of LIS as there are types of lab work. Some vendors offer a full-service solution capable of handling a large hospital

lab's needs; others specialise in specific modules. Disciplines of laboratory science

supported by LIS include haematology, chemistry, immunology, blood bank (Donor and

Transfusion Management), surgical pathology, anatomical pathology, flow cytometry and microbiology. This article covers clinical lab which encompasses haematology, chemistry

and immunology.

LIS can be used by doctors to track every part of a patient's visit to them. They can be

used to manage patient check-ins, order and manage different tests, processing, order

and result entries, patient demographics, etc. All of the information from a patient's visit will be stored in the database for future reference and will update with every future visit.

Page 89: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 89 of 106 Public

Medical Device

A medical device is an instrument, apparatus, implant, in vitro reagent, or similar or related article that is used to diagnose, prevent, or treat disease or other conditions, and

does not achieve its purposes through chemical action within or on the body (which

would make it a drug). Whereas medicinal products (also called pharmaceuticals) achieve

their principal action by pharmacological, metabolic or immunological means, medical devices act by other means like physical, mechanical, or thermal means.

Medical devices vary greatly in complexity and application. Examples range from simple

devices such as tongue depressors, medical thermometers, and disposable gloves to

advanced devices such as computers which assist in the conduct of medical testing, implants, and prostheses. The design of medical devices constitutes a major segment of

the field of biomedical engineering.

Medical Health Record (MHR)

MHR are a digital version of the paper charts in the clinician’s office. An EMR contains the medical and treatment history of the patients in one practice. EMRs have advantages

over paper records. For example, EMRs allow clinicians to:

Track data over time.

Easily identify which patients are due for preventive screenings or checkups.

Check how their patients are doing on certain parameters—such as blood pressure readings or vaccinations.

Monitor and improve overall quality of care within the practice.

Page 90: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 90 of 106 Public

But the information in EMRs does not travel easily out of the practice. In fact, the

patient’s record might even have to be printed out and delivered by mail to specialists

and other members of the care team. In that regard, EMRs are not much better than a paper record.

Mirth

Mirth Connect is a cross-platform HL7 interface engine that enables bi-directional sending

of HL7 messages between systems and applications over multiple transports available under the Mozilla Public License (MPL) 1.1 license. On September 9th, 2013 Mirth

Corporation announced they were acquired by Quality Systems.

Mirth Connect uses a channel-based architecture to connect HIT systems and allow

messages to be filtered, transformed, and routed based on user-defined rules. Channels consist of connectors (both inbound and outbound), filters, and transformers. Multiple

filters and a chain of transformers can be associated with a channel.

Endpoints are used to configure connections and their protocol details. Source connectors

are used to designate the type of listener to use for incoming messages, such as TCP/IP or a web service. Destination connectors are used to designate the destination of

outgoing messages, such as an application server, a JMS queue, or a database. All

messages and transactions are optionally logged to an internal database. Mirth Connect

can be also configured to auto-generate an HL7 acknowledgement response (ACK).

Mirth Connect supports sending and receiving healthcare messages over a variety of protocols:

TCP/MLLP.

Database (MySQL, PostgreSQL, Oracle, Microsoft SQL Server, ODBC).

File (local file system and network shares).

PDF and RTF documents.

JMS.

FTP/SFTP.

HTTP.

SMTP.

SOAP (over HTTP).

An open architecture allows for the easy addition of custom and legacy interfaces.

The Certification Commission for Healthcare Information Technology (CCHIT), in a push

to ensure interoperability standards between electronic health records, has adopted Laika, an open source standards software program. At the 2009 Annual HIMSS

Conference, Mirth was selected as one of the testing tools for the coming interoperability

tests.

PACS

A PACS is a system of digital storage, transmission and download of radiological images.

The PACS systems consist of software and hardware parts, which directly communicate

with modalities and get pictures of them. The images are transferred to a workstation

(workstation) for viewing and issuing radiological reports. The PACS viewer is a software that is installed on the workstation that uses the radiologist to receive and display

radiological images. The images are then archived in the PACS server for later download

to workstations.

Architecture PACS: The basic components of a PACS system are:

Page 91: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 91 of 106 Public

Server Central PACS: It consists of the main system hardware.

Work Station PACS: Allows radiologists visualisation and analysis of digital images.

Database System: Responsible for managing the store all the information and pictures of PACS.

DICOM Server: Responsible for all communication with DICOM imaging modalities

(such as CT or MRI), other PACS DICOM workstations and servers.

Storage System: The hardware required to store DICOM images from PACS system.

Interfaces to RIS / HIS: Consolidate all patient information from different sources,

allowing a flow of qualified labour.

Web Server for Remote Access: Essential for teleradiology. Using the Web Access,

images and information stored in the PACS server can be accessed via a web browser such as Internet Explorer, Mozilla Firefox, Safari, etc.

Personal Health Record (PHR)

The PHR is a tool that you can use to collect, track and share past and current

information about your health or the health of someone in your care. Sometimes this

information can save you the money and inconvenience of repeating routine medical

tests. Even when routine procedures do need to be repeated, your PHR can give medical

care providers more insight into your personal health story.

Remember, you are ultimately responsible for making decisions about your health. A PHR

can help you accomplish that.

Important points to know about a Personal Health Record:

You should always have access to your complete health information.

Information in your PHR should be accurate, reliable, and complete.

Page 92: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 92 of 106 Public

You should have control over how your health information is accessed, used, and

disclosed.

A PHR may be separate from and does not normally replace the legal medical record of any provider.

Medical records and your personal health record (PHR) are not the same thing. Medical

records contain information about your health compiled and maintained by each of your

healthcare providers. A PHR is information about your health compiled and maintained by you. The difference is in how you use your PHR to improve the quality of your healthcare.

Take an active role in monitoring your health and healthcare by creating your own PHR.

PHRs are an inevitable and critical step in the evolution of health information

management (HIM). The book ‘The Personal Health Record’ assists new users of PHRs in getting started, addressing current PHR trends and processes.

PKI Architecture

A public key infrastructure (PKI) is a set of hardware, software, people, policies, and

procedures needed to create, manage, distribute, use, store, and revoke digital certificates.

In cryptography, a PKI is an arrangement that binds public keys with respective user

identities by means of a certificate authority (CA). The user identity must be unique

within each CA domain. The third-party validation authority (VA) can provide this

information on behalf of the CA. The binding is established through the registration and issuance process, which, depending on the assurance level of the binding, may be carried

out by software at a CA or under human supervision. The PKI role that assures this

binding is called the registration authority (RA), which ensures that the public key is

bound to the individual to which it is assigned in a way that ensures non-repudiation.

Public key cryptography is a cryptographic technique that enables users to securely

communicate on an insecure public network, and reliably verify the identity of a user via

digital signatures.

A public key infrastructure (PKI) is a system for the creation, storage, and distribution of digital certificates which are used to verify that a particular public key belongs to a

certain entity. The PKI creates digital certificates which map public keys to entities,

securely stores these certificates in a central repository and revokes them if needed.

A PKI consists of:

A certificate authority (CA) that both issues and verifies the digital certificates.

A registration authority which verifies the identity of users requesting information

from the CA.

A central directory—i.e., a secure location in which to store and index keys.

A certificate management system.

A certificate policy.

Page 93: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 93 of 106 Public

Protocol

In information technology, a protocol is the special set of rules that end points in a

telecommunication connection use when they communicate. Protocols specify

interactions between the communicating entities.

Protocols exist at several levels in a telecommunication connection. For example, there

are protocols for the data interchange at the hardware device level and protocols for data

interchange at the application program level. In the standard model known as Open

Systems Interconnection (OSI), there are one or more protocols at each layer in the

telecommunication exchange that both ends of the exchange must recognise and observe. Protocols are often described in an industry or international standard.

The TCP/IP Internet protocols, a common example, consist of:

Transmission Control Protocol (TCP), which uses a set of rules to exchange

messages with other Internet points at the information packet level.

Internet Protocol (IP), which uses a set of rules to send and receive messages at

the Internet address level.

Additional protocols that include the Hypertext Transfer Protocol (HTTP) and File

Transfer Protocol (FTP), each with defined sets of rules to use with corresponding programs elsewhere on the Internet.

There are many other Internet protocols, such as the Border Gateway Protocol

(BGP) and the Dynamic Host Configuration Protocol (DHCP).

RIS

A radiology information system (RIS) is a networked software suite for managing medical imagery and associated data. An RIS is especially useful for managing radiological

records and associated data in a multiple locations and is often used in conjunction with a

picture archiving and communication system (PACS) to manage work flow and billing.

An RIS has several basic functions:

Page 94: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 94 of 106 Public

Patient management: An RIS can track a patient’s entire workflow within the

radiology department; images and reports can be added to and retrieved from

electronic medical records (EMRs) and viewed by authorised radiology staff.

Scheduling: Appointments can be made for both in- and out-patients with specific

radiology staff.

Patient tracking: A patient’s entire radiology history can be tracked from admission

to discharge. The history can be coordinated with past, present and future appointments.

Results reporting: An RIS can generate statistical reports for a single patient, group

of patients or particular procedure.

Film tracking: An RIS can track individual films and their associate data.

Billing: An RIS facilitates detailed financial record-keeping, electronic payments and

automated claims submission.

RPM System

RPM Package Manager (RPM) (originally Red Hat Package Manager; now a recursive initialism) is a package management system. The name RPM variously refers to the .rpm

file format, files in this format, software packaged in such files, and the package

manager itself. RPM was intended primarily for Linux distributions; the file format is the

baseline package format of the Linux Standard Base.

Even though it was created for use in Red Hat Linux, RPM is now used in many GNU/Linux distributions. It has also been ported to some other operating systems, such

as Novell NetWare (as of version 6.5 SP3) and IBM's AIX (as of version 4).

An RPM package can contain an arbitrary set of files. The larger part of RPM files

encountered are ‘binary RPMs’ (or BRPMs) containing the compiled version of some software. RPM files however may also contain the source code, then called ‘source RPMs’

(or SRPMs) used to produce a package. SRPMs have an appropriate tag in the file header

that distinguishes them from normal (B)RPMs, causing them to be extracted to /usr/src

on installation. SRPMs also customarily carry the file extension ‘.src.rpm’ (.spm on file systems limited to 3 extension characters, i.e. old DOS FAT).

Service Bus

An enterprise service bus (ESB) is software architecture for middleware that provides

fundamental services for more complex architectures. For example, an ESB incorporates

the features required to implement a service-oriented architecture (SOA). In a general sense, an ESB can be thought of as a mechanism that manages access to applications

and services (especially legacy versions) to present a single, simple, and consistent

interface to end-users via Web- or forms-based client-side front ends.

In essence, ESB does for distributed heterogeneous back end services and applications and distributed heterogeneous front-end users and information consumers what

middleware is really supposed to do: hide complexity, simplify access, allow developers

to use generic, canonical forms of query, access and interaction, handling the complex

details in the background. The key to ESB's appeal, and possibly also its future success, lies in its ability to support incremental service and application integration as driven by

business requirements, not as governed by available technology.

One of the major vendors of ESB, IBM, promotes it as a way to meet the challenges of

integrating applications and provide a single, unified architecture —- built around IBM WebSphere —- that can:

Distribute information across an enterprise quickly and easily.

Page 95: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 95 of 106 Public

Mask differences among underlying platforms, software architectures, and network

protocols.

Ensure information delivery even when some systems or networks may go off-line from time to time.

Re-route, log, and enrich information without requiring applications to be rewritten.

Provide incremental solution implementations so all enterprise services and

applications need not change immediately or all at once.

According to IBM, ‘ESB is not a new software product – it's a new way of looking at how

to integrate applications, coordinate resources, and manipulate information

Smartphone

A smartphone combines cellular telephone, Internet access for e-mail and Web, music and movie player, camera and camcorder, GPS navigation system and a voice search for

asking a question about anything (see personal assistant). A smartphone is much more

personal than a personal computer, because it is with you all the time when traveling and

nearby if you use it as your main phone.

SMART TV

A smart TV, sometimes referred to as connected TV or hybrid TV, (not to be confused

with IPTV, Internet TV, or with Web TV) is a television set or set-top box with integrated

Internet and Web 2.0 features, and is an example of technological convergence between

computers and television sets and set-top boxes. Besides the traditional functions of television sets and set-top boxes provided through traditional broadcasting media, these

devices can also provide online interactive media, Internet TV, over-the-top content, as

well as on-demand streaming media, and home networking access.

The software that runs smart TVs can be preloaded into the device, or updated or installed on demand via an app store or app marketplace, in a similar manner to how the

Internet, Web widgets, and software applications (in this context commonly just referred

to as ‘apps’) are integrated in modern smartphones.

SOA (Service Oriented Architecture)

Service-oriented architecture (SOA) is a design pattern based on distinct pieces of

software providing application functionality as services to other applications via a

protocol. This is known as service-orientation. It is independent of any vendor, product or

technology.

A service is a self-contained unit of functionality, such as retrieving an online bank statement. Services can be combined by other software applications to provide the

complete functionality of a large software application. SOA makes it easy for computers

connected over a network to cooperate. Every computer can run an arbitrary number of

services, and each service is built in a way that ensures that the service can exchange information with any other service in the network without human interaction and without

the need to make changes to the underlying program itself.

Page 96: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 96 of 106 Public

SSSL

SSL (pronounced as separate letters) is short for Secure Sockets Layer, a protocol

developed by Netscape for transmitting private documents via the Internet. SSL uses a

cryptographic system that uses two keys to encrypt data − a public key known to

everyone and a private or secret key known only to the recipient of the message. Both Netscape Navigator and Internet Explorer support SSL, and many Web sites use the

protocol to obtain confidential user information, such as credit card numbers. By

convention, URLs that require an SSL connection start with https: instead of http:.

Another protocol for transmitting data securely over the World Wide Web is Secure HTTP (S-HTTP). Whereas SSL creates a secure connection between a client and a server, over

which any amount of data can be sent securely, S-HTTP is designed to transmit individual

messages securely. SSL and S-HTTP, therefore, can be seen as complementary rather

than competing technologies. Both protocols have been approved by the Internet Engineering Task Force (IETF) as a standard.

Standard

A document, established by consensus and approved by a recognised body that provides

for common and repeated use, rules, guidelines or characteristics for activities or their

results, aimed at the achievement of the optimum degree of interoperability between information systems.

Standards are necessary for interworking, portability, and reusability. They may be de

facto standards for various communities, or officially recognised nationally or

internationally.

Telecare

Telecare is the continuous, automatic and remote monitoring of real time emergencies

and lifestyle changes over time in order to manage the risks associated with independent

living.

Page 97: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 97 of 106 Public

Telemonitoring

It is a medical practice that involves remotely monitoring patients who are not at the

same location as the health care provider. In general, a patient will have a number of monitoring devices at home, and the results of these devices will be transmitted via

telephone to the health care provider. Telemonitoring is a convenient way for patients to

avoid travel and to perform some of the more basic work of healthcare for themselves.

In addition to objective technological monitoring, most telemonitoring programs include subjective questioning regarding the patient's health and comfort. This questioning can

take place automatically over the phone, or telemonitoring software can help keep the

patient in touch with the health care provider. The provider can then make decisions

about the patient's treatment based on a combination of subjective and objective information similar to what would be revealed during an on-site appointment.

Some of the more common things that telemonitoring devices keep track of include blood

pressure, heart rate, weight, blood glucose, and hemoglobin. Telemonitoring is capable of

providing information about any vital signs, as long as the patient has the necessary monitoring equipment at his or her location. Depending on the severity of the patient's

condition, the provider may check these statistics on a daily or weekly basis to determine

the best course of treatment.

Telemonitoring is common for patients with diabetes or hypertension. These patients can

take advantage of regular vital sign monitoring and regular provider feedback without having to commute to the health care provider. Telemonitoring is particularly effective for

people with diabetes and hypertension, because it is extremely important for the vital

statistics of such patients to be consistently observed.

There are a number of advantages of telemonitoring for both the patient and the health care provider. For the health care provider, telemonitoring is an efficient way to gather

necessary patient information without a great time commitment. This efficient means of

gathering information is also relevant to disease-based research, because a large amount

of information can be gathered and recorded with little effort. Telemonitoring is useful to patients because they can receive health care provider feedback on their vital statistics

much more often than they otherwise might. Also, because the patient is more involved

in his or her own treatment, the patient will become more aware of his or her vital

statistics and possibly gain a better sense of what affects these statistics and how the

statistics in turn affect how he or she feels.

Three-tier architecture

A Three-tier architecture is a client-server architecture in which the functional process

logic, data access, computer data storage and user interface are developed and

maintained as independent modules on separate platforms. Three-tier architecture is a software design pattern and a well-established software architecture.

Three-tier architecture allows any one of the three tiers to be upgraded or replaced

independently. The user interface is implemented on a desktop PC and uses a standard

graphical user interface with different modules running on the application server. The relational database management system on the database server contains the computer

data storage logic. The middle tiers are usually multi-tiered.

The three tiers in a three-tier architecture are:

Presentation Tier: Occupies the top level and displays information related to services available on a website. This tier communicates with other tiers by sending

results to the browser and other tiers in the network.

Application Tier: Also called the middle tier, logic tier, business logic or logic tier,

this tier is pulled from the presentation tier. It controls application functionality by

performing detailed processing.

Page 98: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 98 of 106 Public

Data Tier: Houses database servers where information is stored and retrieved. Data

in this tier is kept independent of application servers or business logic.

A 3-tier application is an application program that is organised into three major parts, each of which is distributed to a different place or places in a network. The three parts

are:

The workstation or presentation interface.

The business logic.

The database and programming related to managing it.

In a typical 3-tier application, the application user's workstation contains the

programming that provides the graphical user interface (GUI) and application-specific

entry forms or interactive windows. (Some data that is local or unique for the workstation user is also kept on the local hard disk.)

Business logic is located on a local area network (LAN) server or other shared computer.

The business logic acts as the server for client requests from workstations. In turn, it

determines what data is needed (and where it is located) and acts as a client in relation to a third tier of programming that might be located on a mainframe computer.

The third tier includes the database and a program to manage read and write access to

it. While the organisation of an application can be more complicated than this, the 3-tier

view is a convenient way to think about the parts in a large-scale program.

A 3-tier application uses the client/server computing model. With three tiers or parts, each part can be developed concurrently by different team of programmers coding in

different languages from the other tier developers. Because the programming for a tier

can be changed or relocated without affecting the other tiers, the 3-tier model makes it

easier for an enterprise or software packager to continually evolve an application as new needs and opportunities arise. Existing applications or critical parts can be permanently

or temporarily retained and encapsulated within the new tier of which it becomes a

component.

VPN

A virtual private network, VPN, or VPN stands for Virtual Private Network, is a networking

technology that allows a secure extension of the local network (LAN) over a public or

uncontrolled network such as the Internet. Allows the computer on the network to send

and receive data on shared or public networks like a private network with full

functionality, security and management policies of a private network. This is done by establishing a virtual point-to- point by use of dedicated connections, encryption or a

combination of both methods.

Common examples are the ability to connect two or more branches of a company using

as Internet connection, allowing team members support the connection from home to data centre, or a user can access their home computer from a remote site such as a

hotel, all using the Internet infrastructure.

The VPN connection via Internet is technically a union wide area network (WAN) between

the sites but the user does seem like a private- link from there the ‘virtual private network’ designation.

WDSL

WSDL is an XML format for describing network services as a set of endpoints operating

on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete

network protocol and message format to define an endpoint. Related concrete endpoints

are combined into abstract endpoints (services). WSDL is extensible to allow description

Page 99: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 99 of 106 Public

of endpoints and their messages regardless of what message formats or network

protocols are used to communicate, however, the only bindings described in this

document describe how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME.

Web application

A Web application (Web app) is an application program that is stored on a remote server

and delivered over the Internet through a browser interface.

Web services are Web apps by definition and many, although not all, websites contain

Web apps.

Within the mobile computing sector, Web apps are sometimes contrasted with native

apps, which are applications that are developed specifically for a particular platform or device and installed on that device. However, the two are not mutually exclusive because

many applications contain elements of both native and Web apps. Programs that combine

the two approaches are sometimes referred to as hybrid application.

Web Service

Web services are client and server applications that communicate over the World Wide

Web’s (WWW) HyperText Transfer Protocol (HTTP). As described by the World Wide Web

Consortium (W3C), web services provide a standard means of interoperating between

software applications running on a variety of platforms and frameworks. Web services

are characterised by their great interoperability and extensibility, as well as their machine-processable descriptions, thanks to the use of XML. Web services can be

combined in a loosely coupled way to achieve complex operations. Programs providing

simple services can interact with each other to deliver sophisticated added-value

services.

WSSL

The Secure Sockets Layer (SSL) is a computer networking protocol that manages server

authentication, client authentication and encrypted communication between servers and

clients.

SSL uses a combination of public-key and symmetric-key encryption to secure a

connection between two machines, typically a Web or mail server and a client machine,

communicating over the Internet or an internal network.

Using the OSI reference model as context, SSL runs above the TCP/IP protocol, which is

responsible for the transport and routing of data over a network, and below higher-level protocols such as HTTP and IMAP, encrypting the data of network connections in the

application layer of the Internet Protocol suite. The ‘sockets’ part of the term refers to

the sockets method of passing data back and forth between a client and a server

program in a network, or between program layers in the same computer.

Page 100: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 100 of 106 Public

The Transport Layer Security (TLS) protocol evolved from SSL and has largely

superseded it, although the terms SSL or SSL/TLS are still commonly used; SSL is often

used to refer to what is actually TLS. The combination of SSL/TLS is the most widely deployed security protocol used today and is found in applications such as Web browsers,

email and basically any situation where data needs to be securely exchanged over a

network, like file transfers, VPN connections, instant messaging and voice over IP.

The SSL protocol includes two sub-protocols: the record protocol and the ‘handshake’ protocol. These protocols allow a client to authenticate a server and establish an

encrypted SSL connection. In what's referred to as the ‘initial handshake process,’ a

server that supports SSL presents its digital certificate to the client to authenticate the

server's identity. Server certificates follow the X.509 certificate format that is defined by the Public-Key Cryptography Standards (PKCS). The authentication process uses public-

key encryption to validate the digital certificate and confirm that a server is in fact the

server it claims to be.

Once the server has been authenticated, the client and server establish cipher settings and a shared key to encrypt the information they exchange during the remainder of the

session. This provides data confidentiality and integrity. This whole process is invisible to

the user. For example, if a webpage requires an SSL connection, the URL will change

from HTTP to HTTPS and a padlock icon appears in the browser once the server has been

authenticated.

The handshake also allows the client to authenticate itself to the server. In this case,

after server authentication is successfully completed, the client must present its

certificate to the server to authenticate the client's identity before the encrypted SSL

session can be established.

Page 101: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 101 of 106 Public

Appendix B: Standards The need for interoperable systems is evident in every part of health sector organisations

as effective delivery of healthcare requires a constant exchange of information among

health professionals, including service institutions, insurers and government, between

medical staff and patients, between auxiliary imaging systems and laboratories, with electronic medical records systems and between public health systems, just to mention

some interactions.

Consequently, effective communication between these actors requires that a common

framework that allows interaction and coordination of care sharing. Framework provided

by the standards, which provide uniformity in the name of the components of the health system whether diagnoses, people, procedures, interventions and how it is transmitted,

to ensure that data in one part of the system health are available and have meaning not

only through the variety of clinical settings and public health but also administratively.

In the figure below we have a map with the most common standards and protocols (grouped by areas); these standards can be considered as an infrastructure of every IT

system which has interchanged data with other systems.

Figure 35: Standards v. interoperability levels

The importance of this schema is to visualise that the use of a single standard is not enough to achieve the different types of interoperability and it is necessary to look for

additional standards and with different foci which together enable communication and

utilisation of information.

Effective use of information through a set of information systems is not achieved only

with the pact that the systems can communicate; this is not possible even if the same standard of communications used. This problem is inherent in the information itself as

well as the way it is obtained, processed and stored.

Therefore, for effective interpretation and processing of information it is necessary to

apply standards that allow representation of the context of information. Below is a brief

Page 102: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 102 of 106 Public

description of the standards presented in the map in picture 17, which are organised by

foci or areas of application, its aims and relations it performs.

Communication infrastructure: In this area are the standards and protocols that enable physical and logical communication between computers and networks.

Protocols that underlie the Internet are listed (Interoperability Toolkit (ITK) of the

National Health System (NHS) in the UK).

Ethernet is a protocol link layer (layer 2 Open System Interconnection model or OSI) that allows two devices connected via a link (cable) data exchange higher

layer protocols.

TCP / IP protocols are most used in the world. TCP is a transport protocol (layer 4

of the OSI model) that allows you to create logical connections over an IP network between two physically distant computers. IP is a network layer protocol (layer 3 of

the OSI model). These protocols enabled the implementation of Internet.

B.1 Communication Protocols (general applications)

Simple Mail Transfer Protocol (SMTP). It is based on plain text messages to send

emails protocol. Allowed the implementation of large-scale email.

File Transfer Protocol (FTP). It is the protocol par excellence to transferring files between computers connected over a TCP network (such as the Internet). It is

designed to obtain maximum connection speed because the files represent large

amounts of data.

Simple Mail Transfer Protocol (SMTP). It is based on plain text messages to email protocol. It allowed the implementation of large-scale email.

Hypertext Transfer Protocol (HTTP). This protocol allows the transfer of resources

(files, text, images, videos, sounds, etc.) on the Internet. It is based on the request

/ response model where each request made by a client computer to a server, it sends a message in response which may include the requested resources.

Simple Objet Access Protocol (SOAP): A protocol that accepts objects in different

systems to communicate with each other by exchanging XML messages over HTTP.

It is one of the protocols that allow implementing web services.

B.2 Syntax standards

Hypertext Markup Language (HTML) of World Wide Web Consortium (W3C): Multimedia format documents on the Internet. It is based on labels that can be read

by a human form. These labels are used to organise the content of the documents

and give them a format. Attaches different types of multimedia content through

references (URLs), and also link documents together. The last families of HTML and XHTML documents (HTML1-1991, HTML5-201X) are also XML documents.

Electronic Data Interchange (EDI) of American National standards Institute (ANSI

1979): It is the format for exchanging electronic documents between computer

systems. It aims to represent electronic documentation replacing the paper.

JavaScript Object Notation (JSON) of internet Engineering Task Force (IETF): It is a very popular format on the Internet to represent structured objects. The main

rationale for using JSON instead of XML is that to represent a single structure is

much lighter (which is a necessity in networks with low bandwidth).

eXtensible Markup Language (XML) of World Wide Web Consortium (W3C): Extensible meta tags based on plaintext used to represent structured data. XML

does not define a particular format, it is rather a way of defining formats (eg SOAP

Page 103: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 103 of 106 Public

is based on XML). In turn, these individuals serve as syntax formats for the

exchange of information between applications generally run on different computers.

Yet another Markup Language (YAML), For representing structured information that enables computer processing time and is friendly format for reading by humans.

B.3 Format Specification

XML Schema, It is a language used to define XML structures and restrictions on the

data that will contain; also defines particular uses of XML format. Web Service

Definition Language (WSDL) uses it to define formats of web services and items that are exchanged via SOAP.

B.4 Services Specification

Web Service Definition Language (WSDL): The format eXtensible Markup Language

(XML) to describe Web services as a set of interfaces that operate on messages

containing document-oriented or process information.

B.5 Process Specification

Both Guides clinical practice as clinical protocols are implementable way of computing processes using the standards for the specification process. Analogously, administrative

and managerial processes can also be implemented with these standards. One feature of

the processes in health are interdependent, so its informatics Formal definition allows

better communication and management of the entire system, making visible processes and controlling their execution by quality parameters.

Business Process Execution Language (BPEL). A standard of the Organisation for

the Advancement of Structured Information Standards (OASIS) of a language that

can be implemented and used to specify actions within the business processes of

organisations through web services. Specify integrated processes between the services provided by different information systems.

Business Process Definition Metamodel (BPMD. It is a standard of the Object

Management Group (OMG) with the ability to represent and model business

processes, regardless of the notation or methodology. To achieve a metamodel, which is kind of vocabulary processes with well-defined connections between terms

and concepts used? XML notation used to represent processes.

ebXML Business Process Specification Schema (ebBPSS). An OASIS standard that

establishes a set of nominal elements and specifications necessary to establish a collaboration between business partners and provide configuration parameters for

systems at runtime to achieve collaboration among a set of systems.

B.6 Communication Protocols (Health applications)

HL7 v2: is a messaging standard based on the EDI format for the exchange of

messages between computerised information systems in health. The latest versions

include messaging in XML format.

X12, is a US communication protocol for communication applied in different areas

of government and industry, including health. These protocols use EDI and XML

messaging and are based on the definition of sets formed by electronic messages

with predefined formats transactions.

National Council for Prescription Drug Program (NCPDP), is an American standard

that provides transactions involving prescription, dispensing and billing of drugs.

Page 104: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 104 of 106 Public

DICOM is an open standard managed by the National Electrical Manufacturers

Association (NEMA) and created by industry, consumers and others stakeholders to

allow the standardisation of digital imaging records and communication between systems.

HL7 v3, is a messaging standard based on the HL7 Reference Model (Informative

Reference Model or RIM) and XML format. HL7 v3 messages are divided into

domains such as accounting and billing, healthcare, claims and reimbursement for clinical decision support, clinical document architecture, clinical genomics, clinical

claims, laboratory orders and reports of public health, among others.

CEN/ISO 13606 is the standard CEN / ISO for communication of digital clinical

documents between EHR systems or between them and centralised repositories of clinical information. The standard is divided into five parts: model reference

exchange archetypes, vocabularies and terminology, safety and specification of

interfaces.

B.7 Terminology and health nomenclature

There are different types of health terminologies and nomenclatures. Their organisation,

structure and granularity depend on purpose. For example, the rankings have statistical purposes, while controlled vocabularies or thesauri seek to standardise the clinical

record. In any case, the objective is the normalisation, which enables interoperability

(American Health Information Management Association, 2008; Merabti and others, 2009;

Kranthammer, s / f; Powell and Willis, 2005).

Radiology Lexicon (RadLex) of the Radiology Society of North America (RSNA),

Terminology for radiology that serves to organise and find images, radiological and

clinical reports related records. It contains a lexicon to assist in natural language

processing. It complements other terminologies as Systematised Nomenclature of Medicine-Clinical Terms (SNOMED CT) and DICOM.

Unified Medical Language System (UMLS) Of the National Library of Medicine of

United States. It is a medical terminology consists of three sources of knowledge:

meta-thesaurus (database with a vocabulary), a semantic network (which

categorises and related terms vocabulary) and the SPECIALIST lexicon that contains information to assist the natural language processing. Includes data

sources such as Medical Subject Headings (MeSH), Current Procedural Terminology

(CPT) of the American Medical Association (AMA), International Classification of

Diseases (ICD), Logical Observation Identifiers Names and Codes (LOINC) and SNOMED CT.

Medical Subject Headings (MeSH) of the National Library of Medicine (NLM) of

United States. Terminology reduced with preferred by NLM cataloguing books and

library materials and index items to include in databases related to health, such as MEDLINE terms.

International Classification of Disease (CIE) of World Health Organisation (WHO). It

is a statistical classification of clinical terms as diseases, signs, symptoms, findings,

complaints, social circumstances and external causes of injury or disease. The

version 9 Amendments Clinics (ICD 9 CM) contains a list of terms for diagnostic, surgical and therapeutic procedures. The version 10 with Modifications Clinics (ICD

10 CM) contains, in addition, codes that combine diagnosis and symptom codes

needed to reduce expressing a given condition.

International Classification of Primary Care (CIAP2) of the World Organisation of Family Doctors (WONCA). Sort and encoding processes as well as signs and

symptoms, infections, tumours, injuries, congenital anomalies and other diagnoses,

all classified by (digestive, ear, circulatory, etc.).

Page 105: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 105 of 106 Public

Current Procedural Terminology (CPT) of AMA, Classification with codes and

descriptions for reporting medical services and procedures performed by physicians.

Systematised Nomenclature of Medicine Clinical Terms (SNOMED CT) of the International Health Terminology Standards Development Organisation (IHTSDO).

Terminology controlled clinical multi-language exhaustive and covers diseases,

clinical findings, etiologies, procedures, living organisms and clinical information

used to record results. The content is based on relationships between concepts, their attributes and context information for expressing each concept to a fine

granular level, enabling consistent record level between different health

professionals.

Logical Observation Identifiers Names and Codes (LOINC) of the Regenstrief Institute. Facilitates the exchange and sharing of results of para-clinical studies,

both for medical assistance and for the management or research results. Includes

terms for laboratory, microbiology, toxicology, radiology, haemodynamics and other

clinical observations.

B.8 Clinical documentation

Continuity of Care Record (CCR), ASTM standard for the representation of documents summarising the healthcare Starring in order to ensure continuity of

care while the patient is treated at various centres.

ISO 13606-1, Specifies a model of clinical information that structure documents for

communication between systems with the ability to communicate extracts complete records residing in electronic medical record systems.

Data Elements for Emergency Department Systems (DEEDS), Standard of the

National Centre for Injury Prevention and Control (NPC) for the standardised

registration information in emergency departments, in order to reuse the information for other purposes such as public health and education.

Clinical Document Architecture (CDA), HL7 standard to represent any kind of clinical

documentation through its reference model and then express them in XML format

for communication.

B.9 Models of information

HL7 RIM is a model reference information HL7 v3. Its aim is to provide a basis for consistent definition of HL7 v3 messages for communication of clinical,

administrative and accounting information.

OMG COAS (Clinical Observation Access Service), It is an OMG standard that

specifies a detailed clinical observations useful for the definition of services and communication of information on these comments model, including diagnoses, vital

signs, para-clinical studies, etc.

OpenEHR RM, is a reference model of open systems standard electronic medical

history. openEHR defines a generic model based on a process of resolution of

clinical problems that can model any type of medical attention completely with its context and semantics.

B.10 Architecture of communication

Integrating the Healthcare Enterprise (IHE), It is an initiative by healthcare

professionals and industry in order to improve computer systems in healthcare

share information. IHE defines a set of technicians to implement communication

Page 106: D4.1 Pilot Level Service Specification for CareWell Services

D4.1 Pilot Level Service Specification for CareWell Services

v1.0 / 23rd July 2015 Page 106 of 106 Public

between systems in diverse areas such as laboratory, radiology, cardiology and

coordination of patient care among other profiles.

National Health System Interoperability Toolkit (ITK), This toolkit aims to connect existing systems rather than replacing them. This consists of a set of standards and

interoperability frameworks covering transactional and analytical services to

accelerate the provision of health services.

B.11 Knowledge models

Archetypes allow you to specify structures about a generic model information. These specifications can be shared, translated and integrated with international

terminologies and coding systems for interagency agreements specify semantics,

structure and content of information to be exchanged. The openEHR and ISO 13606

standards archetypes used as a mechanism to specify and share clinical concepts

between institutions. openEHR proposes Agent Definition Language (ADL) such as computer-readable format for the definition of archetypes.

The ontologies are ways of organising the elements of reality comprehensible and

accurate manner, generating a semantic base capable of being processed by

computers. By defining ontologies for basics that make health systems, such as people, users, professionals, institutions, services and facilities, it is possible to

construct a semantic basis consistent for the entire health system from which to

generate information and services capable of Global business semantics and

interoperability. The standard Web Ontology Language (OWL) of the World Wide Web Consortium (W3C) allows the expression of ontologies in computer runnable

format. The ontologies defined in OWL, in combination with inference tools are able

to derive logical reasoning to find new rules and information based on them and

current information.

Resource Definition Framework (RDF) is a simple model for the representation of

metadata. The purpose of RDF is to add semantic processing capacity to identify

and define allowing web properties on the resources of this (documents, images,

videos, etc.). By treating the clinical documentation as a resource, the application

of RDF for semantic processing of information in the area of health is promising. Some of their specific applications refer to the integration of metadata (different

vocabularies / schemes), greater accuracy in the search of information (ability to

categorise and organise resources) and establishing a basis for reasoning

(induction) of new information, among others.