D4.1 Pilot Level Service
Specification for CareWell
Services
WP4 INTEGRATED CARE ARCHITECTURE AND
SERVICE SPECIFICATION
Version 0.11, date 18th February 2015
a
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
DOCUMENT INFORMATION
ORGANISATION RESPONSIBLE
Osakidetza
AUTHORS
Faria, Angel (Osakidetza)
Gonzalez, Nicolás (Osakidetza)
Lewis, Leo (IRH)
CONTRIBUTING PARTNERS
Last name, First name (Organisation)
Last name, First name (Organisation)
Last name, First name (Organisation)
DELIVERY DATE
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
OUTSTANDING ISSUES
Full quality review
FILENAME
D4.1 v0.11 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.
v0.11 / 18th February 2015
Page 2 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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.
v0.11 / 18th February 2015
Page 3 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Table of Contents
EXECUTIVE SUMMARY
3
TABLE OF CONTENTS
4
1.
8
INTRODUCTION
1.1
Introduction to the project
8
1.2
Aims of this deliverable
8
1.3
Structure of the deliverable
8
1.4
Glossary
8
2.
METHODOLOGY
11
3.
CURRENT SERVICES AND TECHNOLOGICAL MODELS
16
3.1
Introduction
16
3.1.1
Current ICT-enabled service specification
17
3.1.2
Current IT architecture
18
3.2
Croatia
22
3.2.1
Current ICT-enabled service specification
22
3.2.2
Current IT architecture
23
3.3
Lower Silesia
25
3.3.1
Current ICT-enabled service specification
25
3.3.2
Current IT architecture
26
3.4
Veneto
28
3.4.1
Current ICT-enabled service specification
28
3.4.2
Current IT architecture
29
3.5
Puglia
30
3.5.1
Current ICT-enabled services specification
30
3.5.2
Current IT architecture
31
3.6
Wales
34
3.6.1
Current ICT-enabled service specification
34
3.6.2
Current IT architecture
35
3.7
4.
Analysis of current service specification vs IT systems
CAREWELL ICT-ENABLED SERVICE SPECIFICATION AND
IT ARCHITECTURES
4.1
Basque Country
38
40
40
4.1.1
CareWell service specification
40
4.1.2
CareWell IT architecture
41
4.2
Croatia
v0.11 / 18th February 2015
44
Page 4 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
4.2.1
CareWell service specification
44
4.2.2
CareWell IT architecture
45
4.3
Lower Silesia
48
4.3.1
CareWell service specification
48
4.3.2
CareWell IT architecture
50
4.4
Veneto
51
4.4.1
CareWell service specification
51
4.4.2
CareWell IT architecture
52
4.5
Puglia
54
4.5.1
CareWell service specification
54
4.5.2
CareWell IT architecture
56
4.6
Wales
57
4.6.1
CareWell service specification
57
4.6.2
CareWell IT architecture
58
5.
GUIDELINES TO ACHIEVE INTEROPERABLE AND
EFFICIENT IT SYSTEMS
5.1
Guidelines for the development of interoperable systems
60
60
5.1.1
Levels and environments of interoperability
60
5.1.2
Standards
62
5.2
Interoperability Tools in CareWell pilots
64
5.2.1
Basque Country
64
5.2.2
Croatia
66
5.2.3
Lower Silesia
66
5.2.4
Veneto
66
5.2.5
Puglia
67
5.2.6
Wales
67
6.
SECURITY AND CONFIDENTIALITY OF DATA
68
6.1
Basque country
68
6.2
Croatia
69
6.3
Lower Silesia
72
6.4
Veneto
73
6.5
Puglia
75
6.6
Wales
76
APPENDIX A: TECHNOLOGICAL TERMS
APPENDIX B: STANDARDS
79
102
B.1
Communication Protocols (general applications)
103
B.2
Syntax standards
103
v0.11 / 18th February 2015
Page 5 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
B.3
Format Specification
104
B.4
Services Specification
104
B.5
Process Specification
104
B.6
Communication Protocols (Health applications)
104
B.7
Terminology and health nomenclature
105
B.8
Clinical documentation
106
B.9
Models of information
106
B.10 Architecture of communication
106
B.11 Knowledge models
107
LIST OF TABLES
Table 1: Template - services vs applications
12
Table 2: Current ICT-enabled services of Basque Country
18
Table 3: Current ICT-enabled services of Croatia
23
Table 4: Current ICT-enabled services of Lower Silesia
26
Table 5: Current ICT-enabled services of Veneto
29
Table 6: Current services of Puglia
31
Table 7: Current ICT-enabled services of Wales
35
Table 8: Services Evolution Basque Country
41
Table 9: CareWell ICT-enabled services of Croatia
45
Table 10: Evolution of ICT-enabled services in Lower Silesia
49
Table 11: Evolution of ICT-enabled services in Veneto
52
Table 12: Evolution of ICT-enabled services in Puglia
55
Table 13: Evolution of ICT-enabled services in Wales
58
Table 14: Basque Country standards used
65
Table 15: Croatia standards used
66
Table 16: Lower Silesia standards used
66
Table 17: Veneto standards used
67
Table 18: Puglia standards used
67
Table 19: Wales standards used
67
Table 20: Veneto kinds of secure access
73
LIST OF FIGURES
Figure 1: Template Common CareWell Architecture
12
Figure 2: Architecture of Basque Country Pre-CareWell
18
Figure 3: Functional Architecture EHR in Primary Care (Osabide AP)
20
Figure 4: Functional Architecture EHR in Secondary Care (Osabide Global)
20
Figure 5: Architecture Basque e-Prescription system
21
Figure 6: Architecture Multichannel services centre support in Basque Country
22
Figure 7: Current IT architecture of Croatia
24
v0.11 / 18th February 2015
Page 6 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Figure 8: Functional Structure G2
25
Figure 9: Current Architecture of lower Silesia
27
Figure 10: Current Architecture of Veneto
29
Figure 11: Current Architecture of Puglia
32
Figure 12: Architecture of Nardino
33
Figure 13: Current Architecture of Wales
36
Figure 14: Communications channels of WCCG
37
Figure 15: Welsh Clinical Portal (WCG) Integration architecture
38
Figure 16: Wales: Level of development of ICT-enabled services
39
Figure 17: CareWell Architecture of Basque Country
42
Figure 18: New application modules
43
Figure 19: Common features
43
Figure 20: CareWell architecture Croatia
46
Figure 21: EMH chronic disease management system
47
Figure 22: FER Home Health Smart TV
48
Figure 23: CareWell IT Architecture Lower Silesia
50
Figure 24: CareWell IT architecture of Veneto
53
Figure 25: Veneto Territorial Information System
54
Figure 26: CareWell IT Architecture of Puglia
56
Figure 27: Communication exchange and information flows
defined.
Error! Bookmark not
Figure 28: CareWell IT Architecture of Wales
59
Figure 29: Standards v. interoperability levels
63
Figure 30: Interoperable platform
65
Figure 31: Secure architecture for external communications
69
Figure 32: PKI infrastructure e-health in Croatia
70
Figure 33: Layers of security communication channels Croatia pilot
71
Figure 34: Security architecture of data transmission channels in Lower Silesia
72
Figure 35: Security architecture of data transmission channels in Veneto
75
v0.11 / 18th February 2015
Page 7 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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
patient´s 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
Aims 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
This deliverable has been structured as follows:
This Introduction section is followed by Section 2 which 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 the gap
analysis detail for each sites’ CareWell implementation and 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 necessary.
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 to reader of document to understanding it. See
also Appendix A Technological Terms
v0.11 / 18th February 2015
Page 8 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
AReS Puglia
Agenzia Regionale Sanitaria Pugliese
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
v0.11 / 18th February 2015
Page 9 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
WP
Work Package
v0.11 / 18th February 2015
Page 10 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 only applications to be
developed during CareWell, it is important to understand and document the applications
or systems running before the commencement of CareWell which will have an impact on
any new applications or services.
The second stage involved the identification of the functionalities for
system/application: a summary of the features of each application and user roles.
each
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. Template
below:
v0.11 / 18th February 2015
Page 11 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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
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 Common CareWell Architecture
v0.11 / 18th February 2015
Page 12 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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:
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
v0.11 / 18th February 2015
Page 13 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
E. Secondary applications
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 for collecting
information about the pilot sites:
v0.11 / 18th February 2015
Page 14 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
o General Questionnaire: used to understand and document the current
situation in each pilot site together with their proposed CareWell objectives.
(Template in Annex 1)
o 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 applications

Understand any current issues with existing systems in each site from a
technical perspective

To understand the expectations and challenges in implementing the ICTenabled aspect of the CareWell project (service and IT point of view).
C. Technical Telcos
Several telcos were scheduled both one to one telcos 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
v0.11 / 18th February 2015
Page 15 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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, ie 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. Basque Country
v0.11 / 18th February 2015
Page 16 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
3.1.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 the 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 in order for the intensive followup, 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.
v0.11 / 18th February 2015
Page 17 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Table 2: Current ICT-enabled services of Basque Country
Basque Country
Before
ICT-enabled services
3.1.2
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
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
v0.11 / 18th February 2015
Page 18 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 clinic data from legacy systems for every hospital whereas
the Osabide Global is a newer version with more functionalities which extend beyond
view only.
Currently Osakidetza are performing a migration task to achieve a unique system to
provide EHR service not only in secondary care but also in primary care.
The e-Prescription service Presbide, is provided by a unique 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 programs (stop smoking program, monitoring sedentary lifestyles etc) and
collects data from questionnaires completed by patients in the PHF.
In addition there are distinct telemonitoring programs that are not focused on frail elderly
patients. These programs 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 the 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 for providing 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 following client/server architecture in high availability on
rack oracle database.
v0.11 / 18th February 2015
Page 19 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 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)
v0.11 / 18th February 2015
Page 20 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
 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 due to the development and implementation of the e-Prescription
being the responsibility of two organisations.
The Basque health service
(Osakidetza) has responsibility over the clinical aspect, ie the module for
documenting the prescriptions and storage in a central database, and the Health
Department having responsibility for the pharmacies and the dispensation process
(dispensation 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 in semantic and
syntactic levels but in organisational and business process too 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 offering 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 and below describes the most important features included in
CareWell:
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
v0.11 / 18th February 2015
Page 21 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services

Access to health reports (secondary and primary care)
CRM: This module is used by clinicians for managing the chronic health programs
and monitoring the health status of patients.
Web Appointment: web used for managing appointments in primary care by
patients.
Health Council: set of nurses for attending doubts or questions of citizens. Using a
solution based on OPA (Oracle Policy Automation) like decision making system.
Figure 6 below shows the functional structure of CSSM.
Figure 6: Architecture Multichannel services centre support in Basque Country
3.2
3.2.1
Croatia
Current ICT-enabled service specification
Stable Patients – out of hospital care
Older patients are cared for by primary care health professionals by either visiting their
GP practice or having a home visit from a field nurse who is covering 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-toknow 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 no
electronic exchange of information currently.
v0.11 / 18th February 2015
Page 22 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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.
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 nurse will liaise by telephone with the field
nursing 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
3.2.2
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
Current IT architecture
The current IT architecture of the Croatian pilot is illustrated below:
v0.11 / 18th February 2015
Page 23 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 not a 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).
Moreover, there are several legacy systems, such as LIS, HIS, RIS, in all hospitals. The
information of these legacy systems can be visualized 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 system providing services
oriented to patient empowerment and home-support pathway.
Relevant Systems / applications
Description of the principal systems in Croatia is detailed below:
 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 is running 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, for managing 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
v0.11 / 18th February 2015
Page 24 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 for managing all aspects
of hospital operation (medical, administrative, financial, legal etc). There is a
number of various vendors in Croatian market and therefore it is not possible to
describe the overall IT infrastructure.
3.3
3.3.1
Lower Silesia
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 and
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 and 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.
v0.11 / 18th February 2015
Page 25 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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
3.3.2
Operational
Maturity level
e-Prescription
YES
2
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
Current IT architecture
The current IT architecture of Lower Silesia pilot is illustrated below:
v0.11 / 18th February 2015
Page 26 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 the
hospitals by an internal Service bus. However, currently, it is not 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 available.
Patient Empowerment and Home Support- Services
Lower Silesia offers several web portals with information about the most common chronic
diseases (diabetes, heart failure etc). On the contrary, no platforms are focused on
patient/caregivers empowerment or targeted patient education.
Relevant Systems / applications
 HIS: Each hospital has its own HIS and it is not possible to access information held
in other 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 or other GP systems.
v0.11 / 18th February 2015
Page 27 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
3.4
3.4.1
Veneto
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
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 and 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 conditions are
deteriorating, the GP or the other professionals can activates 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 coordinated by the Social and Health care 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 selfmanage. 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 Social
and Health care District (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 communications 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 are 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:
v0.11 / 18th February 2015
Page 28 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Table 5: Current ICT-enabled services of Veneto
Veneto
Before
ICT-enabled services
3.4.2
Operational
Maturity level
e-Prescription
YES
5
Messaging clinician  Patients
NO
0
EHR
YES
1
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)
YES
5
Current IT architecture
Veneto has central databases for sharing information
(prescriptions, demographic data and clinical reports).
among
clinical
systems
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
v0.11 / 18th February 2015
Page 29 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Integrated Care Coordination Services
The e-Prescription service is provided by 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.
Patient Empowerment and Home Support-Services
This pathway is supported by a web portal providing the PHR service and some
educational materials together with the telecare service eg 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:
3.5
3.5.1

GP systems: to provide EHR service.

Pharmacy software: to provide an aspect of the e-Prescription.
Puglia
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 by 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 HER 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
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.
v0.11 / 18th February 2015
Page 30 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Inpatient - hospital care
When an ‘unstable’ patient is unable to 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, 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
giver. Information on the hospital episode of care is recorded on a medical chart by the
specialist and ward nurses and then synthesized 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 specialists prepares a
discharge letter summarizing the hospitalization 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
summarizing the hospitalization 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
3.5.2
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
Current IT architecture
The current IT architecture of Puglia pilot is illustrated below:
v0.11 / 18th February 2015
Page 31 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 health care system. Indeed, 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
summarizes 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 in 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 (from which extracts patients registry data), the Nardino
information system, (Puglia Care program software) which 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 chronic patients’ care. Each team member has a specific operational
profile, eg CM and GP. In particular, Care Puglia program software also implements a
back office system for managing user profiles and information structure for displaying
v0.11 / 18th February 2015
Page 32 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 utilities automatic. 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 the 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 Electronic
Health record (EHR), by which primary care health professionals (not the specialist)
share information about a patient.
The 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.
Presentation Layer: Script CGI, WEB GUI (html, JS - Jquery)
Standard: DICOM, HL7, SOAP …
Persistent Layer: Logging, Environment variables, Crypt CBC …
Repository
Registry
Figure 12: Architecture of Nardino
v0.11 / 18th February 2015
Page 33 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
3.6
3.6.1
Wales
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.
The patient’s GP or practice nurse undertake a scheduled review of their health and
wellbeing on an annual basis and 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 multidisciplinary 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 phone.
Inpatient - hospital care
Within Powys, patients can only be admitted to a community hospital and 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 the
hospital, they patients would be under the care of a GP and information 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 and 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 and 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.
v0.11 / 18th February 2015
Page 34 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
The table below summarises the current ICT-enabled services available in Wales:
Table 7: Current ICT-enabled services of Wales
Wales
Before
ICT-enabled services
3.6.2
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
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:
v0.11 / 18th February 2015
Page 35 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Figure 13: Current Architecture of Wales
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 interconsultation). 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 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
v0.11 / 18th February 2015
Page 36 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 GP System supplier specific (proprietary) 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 in the
above).
The illustration below shows the different connectors developed for the WCCG to achieve
the interoperability between GP systems and systems used in secondary care. It also
includes the specific module (GPs client) used by the GP system to connect with other
secondary care systems facilitated through WCCG.
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 view 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.
v0.11 / 18th February 2015
Page 37 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Figure 15: Welsh Clinical Portal (WCG) Integration architecture
 IHR (Individual Health Record): The IRH is a summary of the GP system EHR and 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.
 OOHS (Out-of-Hours Service): The IT system used by the Out-of-Hours GP is called
Adastra and 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.7
Analysis of current service specification vs IT
systems
The 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 of 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:
v0.11 / 18th February 2015
Page 38 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
4.00
e-prescription
3.50
Messaging clinician ßà
Patients
3.00
EHR
2.50
Interconsultation
2.00
1.50
Call Center
1.00
Virtual Conference
0.50
PHR
0.00
Nurse Information System
Educational Platform
Colaborative Platform
Figure 16: Wales: Level of development of ICT-enabled services
v0.11 / 18th February 2015
Page 39 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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
4.1.1
Basque Country
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 in to 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 followup/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 decisionmaking 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 and 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.
v0.11 / 18th February 2015
Page 40 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Table 8: Services Evolution Basque Country
Basque Country
Before
After
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
ICT-enabled service
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 unique 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 programs in EHR
 To improve the Business Intelligence to provide new functionalities for patients
stratification
 The development of an educational web platform for patients
The diagram below illustrates the CareWell architecture:
v0.11 / 18th February 2015
Page 41 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Figure 17: CareWell Architecture of Basque Country
The above technological improvements will result in new or enhanced applications and
functionalities described below.
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 utilise 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.
v0.11 / 18th February 2015
Page 42 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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
v0.11 / 18th February 2015
Page 43 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 standardization 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 database
(hospitalization, 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 algorithms 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 has 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
4.2.1
Croatia
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 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 information
to be updated easily within the system and new knowledge to be shared.
v0.11 / 18th February 2015
Page 44 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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’ and 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 selfcare 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
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
ICT-enabled service
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.
v0.11 / 18th February 2015
Page 45 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Figure 20: CareWell architecture Croatia
For this activity, the EMH has several adapters and viewers that enable it to run on
several platforms like 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 Ericsson Mobile Health chronic disease
management system (EMH), 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 for providing 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 will be developed by FER. Details of the functionality of the EMH and
home health Smart TV is given below.
v0.11 / 18th February 2015
Page 46 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 2 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 1 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 application
v0.11 / 18th February 2015
Page 47 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 bellows 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
4.3.1
Lower Silesia
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.
v0.11 / 18th February 2015
Page 48 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
 Patients will be able to access the e-Prescription and choose their dispensing
pharmacy.
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 and the 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, determine their
physiological parameters and frequency accordingly. Furthermore, the patient 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
Operational
Maturity
level
Operational
Maturity
level
e-prescription
YES
1
YES
2
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
ICT-enabled service
v0.11 / 18th February 2015
Page 49 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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.
Work will also be undertaken to implement an e-Prescription system for primary and
secondary care.
Figure 23: CareWell IT Architecture Lower Silesia
New systems or new functionalities
 Registration 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 by the patient results in HIS Portal.
 GP access to EHR and its 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.
 Patient access to PHR own tasks and supports the process of LSV teleCare
procedure.
 Implementation e-Prescription in SIM (P1) during the LSV teleCare procedure.
v0.11 / 18th February 2015
Page 50 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
 Call Centre staff access to their own tasks supporting the LSV teleCare procedure
process. Receive e-mail and SMS alerts.
 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
4.4.1
Veneto
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 be bringing 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 automatic feed from the patient ‘dashboard’.
 Home-care nurses will provide a monitoring service to patients and 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 question
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, webbased material will be available through the ULSS 2 authority website.
 Patients will be able to access the My Health Portal within the ULSS 2 website
where they will be able to enter information about their health and wellbeing,
search for some information in their health record 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, the 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.
v0.11 / 18th February 2015
Page 51 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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
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
4
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
ICT-enabled service
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 extend the use of
Territorial Information System to secondary care.
This challenge is not only represent the number of users, this challenge represent others
problems to resolve like:
 To implement data to storage and typology of the data
 To implement new roles of users
 To develop new interoperability connections
 Major risk of data duplicity and incremental cost of support and management
v0.11 / 18th February 2015
Page 52 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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.
 To develop a Teleconference system.
 To 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 and 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
customized by the providers and thus it is proprietary software.
v0.11 / 18th February 2015
Page 53 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Figure 25: Veneto Territorial Information System
4.5
4.5.1
Puglia
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 indeed, will be involved in sharing information by 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 recognizing symptom deterioration or
improvement, clarification on medications etc as well as, for instance monitoring wound
healing, e.g. a diabetic ulcer.
v0.11 / 18th February 2015
Page 54 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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. Furthermore, 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 and 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 stabilized patient is discharged from hospital back to his home. Hospital specialist
entrust 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
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
ICT-enabled service
v0.11 / 18th February 2015
Page 55 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Puglia
Before
After
Operational
Maturity
level
Operational
Maturity
level
PHR
NO
0
NO
0
Nurse Information System
YES
4
YES
5
NO
0
YES
4
YES
3
YES
4
Telemonitoring
YES
2
YES
4
Multichannel Centre
NO
0
NO
0
ICT-enabled service
(record of nursing care)
Educational Platform
Collaborative Platform
4.5.2
CareWell IT architecture
Below we have attached 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
v0.11 / 18th February 2015
Page 56 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
other members of the care plan. The platform is fully compliant with DICOM 3.0
standard, so CARE Puglia software will integrate a PACS for management of all forms of
diagnostic imaging to implement specific work flow or process a second opinion, or in
general, to support specialized 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 adaptation are also necessary, and they will be provided, to send therapeutic
recalls toward HUB; Furthermore, it will 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.
Moreover technical interventions both on platform and Hub software will be set to create
warning on the platform from extra range clinical parameters revealed by home devices.
4.6
4.6.1
Wales
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 to 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
patiens 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
v0.11 / 18th February 2015
Page 57 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
admission will increase as more patients are able to be managed by telemonitoring and
support in their own homes for minor exacerbations.
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
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
ICT-enabled service
The use of TotalMobile and Microsoft Lync by the community nursing team will facilitate
improved communication between the team and community hospital staff.
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 new developed systems will be adapted
for running on mobile devices such as Smartphones and tablets for the district and
specialist nurses to use when the make visits to patients’ homes.
 To implement a telemonitoring service.
 To develop a unique 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.
v0.11 / 18th February 2015
Page 58 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Below is an illustration of the CareWell IT architecture to be implemented in Powys:
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.
v0.11 / 18th February 2015
Page 59 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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. Below describes several cases to implement this solution
 Legacy systems which your database technology don’t allow to access of data for
sharing with other applications.
 Legacy systems which is not possible develop process for using data from others
applications.
 In cases of develop new systems, the normal guidelines is addressed to include the
major number of functionalities and services in the same application .(services
provided at the moment by others applications).
In any of the 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.
 Unique storage for data (avoiding data duplicity).
 Decrease of systems maintenance costs.
 To improve the performance of applications due to interoperable systems displaying
information in a more structured and easily readable way.
 To re-use resources.
 Standardisation of new developments (reducing costs).
5.1.1
Levels and environments of interoperability
To achieve the strong interoperability among systems we should to achieve an optimum
level of three interoperability levels (Syntactic, Semantic and Organisational).
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
v0.11 / 18th February 2015
Page 60 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 correctly information from these. 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: The viewing of 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.
 To calculate indicators, percentages, durations, etc.
 To look for information of patient: bibliography resources, etc.
v0.11 / 18th February 2015
Page 61 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
 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 processes 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 organizations
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 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 has interchanged data with other systems.
v0.11 / 18th February 2015
Page 62 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Figure 28: Standards v. interoperability levels
The importance of this schema is to visualize 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
utilization 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 picture 17, which are organized 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.
The following topics related to standards are discussed in more detail in Appendix B:
 Communication Protocols (general applications).
 Syntax standards.
v0.11 / 18th February 2015
Page 63 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
 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
We explain 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 our interoperability policy to SOA (Service Oriented
Architecture). In the central of this architecture had deployed a commercial bus service
(oracle Service Bus). Currently the Basque Country has deployed around 300 web
services for share clinical, demographic and administrative information among
corporative 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.
v0.11 / 18th February 2015
Page 64 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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,
https, ftp
CRM
LOINC, ICD 9/10
xml, pdf, Cades,
HL7, SOAP
PHR
https, PDF, HL7
xml,
http,
DICOM,
CDA1
Educational
Web
v0.11 / 18th February 2015
Page 65 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
5.2.2
Croatia
Interoperable platform
Croatia pilot have not deployed any interoperability platform. The unique 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,
Signature
5.2.3
Digital
Lower Silesia
Interoperable platform
Wroclaw pilot has a bus service in every hospital used for interoperability 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
implemented
not
yet
Client/Server
ICD9/ICD10
XML / HTML
Dictionaries, HL7
implemented
not
yet
Communicator
Not referred
Not referred
Not referred
5.2.4
Veneto
Interoperable platform
In the Local Health Authority is used Mirth Connect, a cross-platform HL7 interface
engine that enables bi-directional sending of HL7 messages between systems and
applications and 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 customized by the providers and thus it is proprietary software.
Standards Used in CareWell system
Below is the table containing information on the standards used in the Veneto pilot site:
v0.11 / 18th February 2015
Page 66 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Table 17: Veneto standards used
Application
Semantic
standards
Syntactic
Standards
e-Prescription/ GP and
Pharmacy’s software
LOINC, ICD 9/10
HL7,
xml,
https, SOAP
Organisational
Interoperability
http,
web site
html, http, https
Regional
Teleemergency Solution
HL7, DICOM, xml,
http, https, ftp
e4cure and Talete
5.2.5
LOINC, ICD 9/10
xml, pdf, Cades,
DICOM, HL7, SOAP
CDA2, IHE
IHE
Puglia
Interoperable platform
Puglia has 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)
Standards Used in CareWell system
Table 19: Wales standards used
Application
v0.11 / 18th February 2015
Semantic
standards
Syntactic
Standards
Page 67 of 107
Organisational
Interoperability
Public
D4.1 Pilot Level Service Specification for CareWell Services
6. Security and confidentiality of data
The main goal of this section is to describe the elements, tools and processes required for
data security management. For this purpose, three principal aspects are considered:
1. Identification, authentication and authorization of persons and devices: this aspect
ensures that all system users, not 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 audit processes should be
implemented regularly 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-section details a description of 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 authorization 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 match your 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 centralized system and an active user directory system
(not only professionals but other staff with access to the system).
The e-Prescription and the PHR systems in Osakidetza use an electronic personal
certificate with the e-Prescription also including a secure electronic signature for
prescriptions through the 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 secure 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 demilitarized zone (DMZ).
The diagram below shows the secure architecture for external communications:
v0.11 / 18th February 2015
Page 68 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 of
high level of security implements 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 authorization 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 authorization allowing access of G2
applications to central system.
 G2: Smart card authorization for each user, https, private networks (there are
several G2 market app).
v0.11 / 18th February 2015
Page 69 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
 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 their 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 a patient´s demographic information and the other contains anonymous
clinical data and measurements. Once the authorized user signs in with
username/password, a patient´s name is related to a specific set of medical data
(measurements, questionnaire 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 the
service delivery continuity.
In addition, system data transmission channels in Ericsson Mobile Health is protected on
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
v0.11 / 18th February 2015
Page 70 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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.
Furthermore, the EMH uses MySQL database that can allow auditing of the
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, the restoration
of the database is initiated when a corruption is identified (for this action, MySQL
workbench tool is used).
v0.11 / 18th February 2015
Page 71 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
6.3
Lower Silesia
Identification, Authentication and authorization of people and devices
Users
The Managing Access to the application in the CareWell monitoring system (LSV) will be
based on User / Password.
Devices used and its connections with Back-ends
Devices are using the Bluetooth connectivity protocol.
Security of stored and exchanged data
The sensitive data will be stored on the server in the organization that owns the data
(hospital) and 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 ensures 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, moreover the access to resources is carried out
also by VPN.
Figure 33: Security architecture of data transmission channels in Lower Silesia
v0.11 / 18th February 2015
Page 72 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 on the main Router -model VIGOR 2910G.
 Firewall allows to 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 protect against unauthorized access, minimized risk by using
professional software firewall (firewall) and a professional anti-virus program on
each computer and a 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 authorization of people and devices
Table 20: 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 a federated authentication. All
actors authenticate themselves to service 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
v0.11 / 18th February 2015
Page 73 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
through username, password and software’s certificates; as a result of this
authentication process, is issued a token that allows the accessibility 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 to database in
which there is all information about patients who have this service (https protocol).
 Medical interconsultation
This service allows the consultation between specialists. Physicians access the
software through username and password and can see clinical reports and patient
data carried by other specialist according 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 their 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’s
reports, anatomic pathology reports, and radiology and laboratory analysis reports,
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 and 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 by external attacks through firewall, proxy and
antivirus. Therefore, there are dedicated transmission channels in which operators’
access through specific tools like VPN and https protocol.
v0.11 / 18th February 2015
Page 74 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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
system administrators to various servers. Each application has its own log of the
activities (log in dates, log out dates). Therefore, for ePrescription service, the
system records authentication logs (user name, ID software, log in dates).
 Reactive Actions: In case corruption or fail in database the backup systems allow to
the recovery of the clinical data and reports. This process of backup/restore is
made by a system provider. Moreover for protect the systems against external
attacks, there are an Intrusion Prevention System (IPS) and an Intrusion Detection
System (IDS) which highlight and store anomalies in network traffic on 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 authorization 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 land line phone connection.
v0.11 / 18th February 2015
Page 75 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Security of stored and exchanged data
In the Puglia pilot, the data will be stored on a central server. Care Managers, General
practitioners and authorized data manager (DBA – data base administrator) have access
to it. All the access is controlled by ID and Password from Care Managers and DBA (weak
authentication), by CNS (strong authentication via digital certificate) from General
Practitioners. 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 for traceability and legal non-repudiation of access (for
strong authentication). Encrypted data will be transferred to authorized 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 the systems for auditing access are
available. A database register of access tracks what, when, from which client 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 authorization of people and devices
Users
Users of CareWell systems use user/password to access to systems.
Devices used and its connections with Back-ends
The devices use wifi or LAN connections to transfer the 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
v0.11 / 18th February 2015
Page 76 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 their 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 virtualized 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 in, 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
minimize 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 unauthorized
access.
Systems will be maintained to the latest approved standards to protect against software
bugs that could be used for unauthorized access.
A number of network management systems will be used to proactive monitor and
manage the data networks to identify risks or unauthorized access.
Audit processes will be undertake to ensure user access is appropriate to need and
removed when no longer required.
Reactive Actions
About active reactions in case failure database or system. The provision of multiple proxy
servers with failover provision to support access to internet resources. 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 Use of 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
enhance nature including power provision / security / failover. Applications will be
hosted, wherever possible, on virtualized systems to facilitate rapid changeover to new
hosts. Spare network equipment is maintain for emergency swap out. Standard
deployment is used wherever possible to enable users to log into any computer and to be
v0.11 / 18th February 2015
Page 77 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 unauthorized access

Mailmarshal to control email service

Webmarshal to control and manage access to internet resources

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, 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.
The Webmarshal application is used to monitor and control internet access to minimise
exposure to compromised websites.
The Mailmarshal service is used to protect email from messages containing viruses or
other risks.
v0.11 / 18th February 2015
Page 78 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 organize 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.
v0.11 / 18th February 2015
Page 79 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
The main advantage of a call centre to a company is that centralizes attention. If you do
not have a call centre, all calls arrive at different offices and be more difficult to decide
how they are channeled 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.
v0.11 / 18th February 2015
Page 80 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 businesscustomer 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.
v0.11 / 18th February 2015
Page 81 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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.
v0.11 / 18th February 2015
Page 82 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 authorized 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,
immunization 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 authorized providers in a digital format capable of being shared with other providers
across more than one health care organization. EHRs are built to share information with
other health care providers and organizations – 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.
v0.11 / 18th February 2015
Page 83 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Encryption
Encryption is the conversion of electronic data into another form, called ciphertext, which
cannot be easily understood by anyone except authorized 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.
v0.11 / 18th February 2015
Page 84 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 recognized 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 organization 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, utilization, 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:
v0.11 / 18th February 2015
Page 85 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
 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.
v0.11 / 18th February 2015
Page 86 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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, specialization.
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
specialized 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
v0.11 / 18th February 2015
Page 87 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 specialized 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 recognized 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.
v0.11 / 18th February 2015
Page 88 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 customized 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 organization. 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 specialize 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.
v0.11 / 18th February 2015
Page 89 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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.
v0.11 / 18th February 2015
Page 90 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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:
v0.11 / 18th February 2015
Page 91 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
 Server Central PACS: It consists of the main system hardware.
 Work Station PACS: Allows radiologists visualization 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.
v0.11 / 18th February 2015
Page 92 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
 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.
v0.11 / 18th February 2015
Page 93 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 recognize 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:
v0.11 / 18th February 2015
Page 94 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
 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 authorized 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.
v0.11 / 18th February 2015
Page 95 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
 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.
v0.11 / 18th February 2015
Page 96 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 recognized 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.
v0.11 / 18th February 2015
Page 97 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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.
v0.11 / 18th February 2015
Page 98 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
 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 organized 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 organization 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
v0.11 / 18th February 2015
Page 99 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 characterized 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.
v0.11 / 18th February 2015
Page 100 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 publickey 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.
v0.11 / 18th February 2015
Page 101 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
Appendix B: Standards
The need for interoperable systems is evident in every part of health sector organizations
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 visualize 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
utilization 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
v0.11 / 18th February 2015
Page 102 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
description of the standards presented in the map in picture 17, which are organized 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 organize 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
v0.11 / 18th February 2015
Page 103 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 Organization 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
organizations 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 computerized 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.
v0.11 / 18th February 2015
Page 104 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
 DICOM is an open standard managed by the National Electrical Manufacturers
Association (NEMA) and created by industry, consumers and others stakeholders to
allow the standardization 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 centralized 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. His organization,
structure and granularity depends on your purpose. For example, the rankings have
statistical purposes, while controlled vocabularies or thesauri seek to standardize the
clinical record. In any case, the objective is the normalization, 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 organize and find images, radiological and
clinical reports related records. It contains a lexicon to assist in natural language
processing. It complements other terminologies as Systematized 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
categorizes 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 Organization (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 Organization 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.).
v0.11 / 18th February 2015
Page 105 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
 Current Procedural Terminology (CPT) of AMA, Classification with codes and
descriptions for reporting medical services and procedures performed by physicians.
 Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT) of the
International Health Terminology Standards Development Organization (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 summarizing 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 standardized
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
v0.11 / 18th February 2015
Page 106 of 107
Public
D4.1 Pilot Level Service Specification for CareWell Services
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 organizing 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
categorize and organize resources) and establishing a basis for reasoning
(induction) of new information, among others.
v0.11 / 18th February 2015
Page 107 of 107
Public