D4.1 Pilot Level Service Specification for CareWell Services
Transcript of D4.1 Pilot Level Service Specification for CareWell Services
The CareWell project is co-funded by the European Commission within the ICT Policy Support Programme of the Competitiveness and Innovation Framework Programme (CIP). Grant Agreement No.: 620983
The information in this document is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability
D4.1 Pilot Level Service
Specification for CareWell
Services
WP4 INTEGRATED CARE ARCHITECTURE AND SERVICE SPECIFICATION
Version 1.0, date 23rd July 2015
a
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 2 of 106 Public
DOCUMENT INFORMATION
ORGANISATION RESPONSIBLE
Osakidetza
AUTHORS
Faria, Angel (Osakidetza)
Gonzalez, Nicolás (Osakidetza)
Lewis, Leo (IRH)
CONTRIBUTING PARTNERS
DELIVERY DATE
31st December 2014
DISSEMINATION LEVEL
P Public
VERSION HISTORY
Version Date Changes made By
0.1 08/10/2014 Changes in Index Angel Faria
0.2 20/11/2014 Structure of document Angel Faria
0.25 15/12/2014 Updated Methodology Angel Faria
0.3 19/01/2015 Sections 3.1, 3.2, and 4.1, 4.2 added Angel Faria,
Leo Lewis
0.4 28/01/2015 Section 6, 1.4, 5.1 added; updates following
review by pilot sites
Angel Faria
0.9 12/02/2015 Further updates Leo Lewis
0.10 13/02/2015 Section 1.4.2 moved to Appendix A, much of
section 5.2 moved to Appendix B; formatting
standardised
John Oates
0.11 18/02/2015 Revised figures Ane Fullaondo
0.12 7/07/2015 Update from Veneto and LSV Kazimierz
Frączkowski,
Francesco Marchet
1.0 23/7/2015 Version for issue John Oates
OUTSTANDING ISSUES
Full quality review
FILENAME
D4.1 v1.0 Pilot level Service Specification for CareWell service
STATEMENT OF ORIGINALITY
This deliverable contains original unpublished work except where clearly indicated
otherwise. Acknowledgement of previously published material and of the work of
others has been made through appropriate citation, quotation or both.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 3 of 106 Public
Executive Summary This deliverable defines the CareWell ICT-enabled service specification and IT
architecture in terms of examining the current situation in relation to information and
communication mechanisms and technologies, and those which will be implemented in
each pilot site to support the implementation of the care pathways.
In addition, it provides details of standards and other relevant technical guidance,
together with information on the security and confidentiality processes followed by each
of the pilot site.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 4 of 106 Public
Table of Contents
EXECUTIVE SUMMARY 3
TABLE OF CONTENTS 4
1. INTRODUCTION 8
1.1 Introduction to the project 8
1.2 Aim of this deliverable 8
1.3 Structure of the deliverable 8
1.4 Glossary 8
2. METHODOLOGY 10
3. CURRENT SERVICES AND TECHNOLOGICAL MODELS 15
3.1 Introduction 15
3.2 Basque Country 16
3.2.1 Current ICT-enabled service specification 16
3.2.2 Current IT architecture 17
3.3 Croatia 21
3.3.1 Current ICT-enabled service specification 21
3.3.2 Current IT architecture 22
3.4 Lower Silesia 24
3.4.1 Current ICT-enabled service specification 24
3.4.2 Current IT architecture 25
3.5 Veneto 26
3.5.1 Current ICT-enabled service specification 26
3.5.2 Current IT architecture 28
3.6 Puglia 29
3.6.1 Current ICT-enabled services specification 29
3.6.2 Current IT architecture 30
3.7 Wales 32
3.7.1 Current ICT-enabled service specification 32
3.7.2 Current IT architecture 34
3.8 Analysis of current service specification vs IT systems 37
4. CAREWELL ICT-ENABLED SERVICE SPECIFICATION AND
IT ARCHITECTURES 39
4.1 Basque Country 39
4.1.1 CareWell service specification 39
4.1.2 CareWell IT architecture 40
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 5 of 106 Public
4.2 Croatia 43
4.2.1 CareWell service specification 43
4.2.2 CareWell IT architecture 44
4.3 Lower Silesia 47
4.3.1 CareWell service specification 47
4.3.2 CareWell IT architecture 49
4.4 Veneto 50
4.4.1 CareWell service specification 50
4.4.2 CareWell IT architecture 51
4.5 Puglia 53
4.5.1 CareWell service specification 53
4.5.2 CareWell IT architecture 55
4.6 Wales 56
4.6.1 CareWell service specification 56
4.6.2 CareWell IT architecture 57
5. GUIDELINES TO ACHIEVE INTEROPERABLE AND
EFFICIENT IT SYSTEMS 59
5.1 Guidelines for the development of interoperable systems 59
5.1.1 Levels and environments of interoperability 59
5.1.2 Standards 61
5.2 Interoperability Tools in CareWell pilots 63
5.2.1 Basque Country 63
5.2.2 Croatia 65
5.2.3 Lower Silesia 65
5.2.4 Veneto 65
5.2.5 Puglia 66
5.2.6 Wales 66
6. SECURITY AND CONFIDENTIALITY OF DATA 67
6.1 Basque country 67
6.2 Croatia 68
6.3 Lower Silesia 71
6.4 Veneto 72
6.5 Puglia 74
6.6 Wales 75
APPENDIX A: TECHNOLOGICAL TERMS 78
APPENDIX B: STANDARDS 101
B.1 Communication Protocols (general applications) 102
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 6 of 106 Public
B.2 Syntax standards 102
B.3 Format Specification 103
B.4 Services Specification 103
B.5 Process Specification 103
B.6 Communication Protocols (Health applications) 103
B.7 Terminology and health nomenclature 104
B.8 Clinical documentation 105
B.9 Models of information 105
B.10 Architecture of communication 105
B.11 Knowledge models 106
LIST OF TABLES
Table 1: Template - services vs applications 10
Table 2: Current ICT-enabled services of Basque Country 17
Table 3: Current ICT-enabled services of Croatia 22
Table 4: Current ICT-enabled services of Lower Silesia 25
Table 5: Current ICT-enabled services of Veneto 27
Table 6: Current services of Puglia 30
Table 7: Current ICT-enabled services of Wales 34
Table 8: Services Evolution Basque Country 40
Table 9: CareWell ICT-enabled services of Croatia 44
Table 10: Evolution of ICT-enabled services in Lower Silesia 48
Table 11: Evolution of ICT-enabled services in Veneto 51
Table 12: Evolution of ICT-enabled services in Puglia 54
Table 13: Evolution of ICT-enabled services in Wales 57
Table 14: Basque Country standards used 64
Table 15: Croatia standards used 65
Table 16: Lower Silesia standards used 65
Table 17: Veneto standards used 66
Table 18: Puglia standards used 66
Table 19: Veneto kinds of secure access 72
LIST OF FIGURES
Figure 1: Template for common CareWell architecture 11
Figure 2: Architecture of Basque Country Pre-CareWell 17
Figure 3: Functional Architecture EHR in Primary Care (Osabide AP) 19
Figure 4: Functional architecture EHR in secondary care (Osabide Global) 19
Figure 5: Architecture Basque e-Prescription system 20
Figure 6: Architecture Multichannel services centre support in Basque Country 21
Figure 7: Current IT architecture of Croatia 23
Figure 8: Functional Structure G2 24
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 7 of 106 Public
Figure 9: Current Architecture of lower Silesia 26
Figure 10: Current Architecture of Veneto 28
Figure 11: Current Architecture of Puglia 31
Figure 12: Architecture of Nardino 32
Figure 13: Current Architecture of Wales 34
Figure 14: Communications channels of WCCG 36
Figure 15: Welsh Clinical Portal (WCG) Integration architecture 36
Figure 16: Wales: Level of development of ICT-enabled services 38
Figure 17: CareWell Architecture of Basque Country 41
Figure 18: New application modules 42
Figure 19: Common features 42
Figure 20: CareWell architecture Croatia 45
Figure 21: EMH chronic disease management system 46
Figure 22: FER Home Health Smart TV 47
Figure 23: CareWell IT Architecture Lower Silesia 49
Figure 24: CareWell IT architecture of Veneto 52
Figure 25: Veneto Territorial Information System 53
Figure 26: CareWell IT Architecture of Puglia 55
Figure 27: CareWell IT Architecture of Wales 58
Figure 28: Standards v. interoperability levels 62
Figure 29: Interoperable platform 64
Figure 30: Secure architecture for external communications 68
Figure 31: PKI infrastructure e-health in Croatia 69
Figure 32: Layers of security communication channels Croatia pilot 70
Figure 33: Security architecture of data transmission channels in Lower Silesia 71
Figure 34: Security architecture of data transmission channels in Veneto 74
Figure 35: Standards v. interoperability levels 101
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 8 of 106 Public
1. Introduction
1.1 Introduction to the project
Frail elderly patients are characterised as having complex health and social care needs,
being at risk of hospital or residential care home admission, and requiring a range of high
level interventions due to their frailty and multiple chronic conditions. These patients
typically demand an integrated care approach where all care practitioners working in the
different levels of care have to be tightly coordinated, and special emphasis is put on patients' empowerment. CareWell aims to enable the delivery of integrated care for frail
elderly patients supported by ICT-based technologies and platforms and associated new
ways of working.
1.2 Aim of this deliverable
This deliverable describes the current and CareWell ICT (information, communication and technologies) enabled service model and technical infrastructure available in each of the
pilot sites. The information has been obtained through onsite pilot site visits as well as
completed questionnaires and workshops held as part of WP2 and WP3 work. In
addition, the deliverable includes guidance on achieving interoperability between the different IT systems in use in the sites and security and confidentiality processes and
considerations.
1.3 Structure of the deliverable
Section 2 describes the methodology that has been adopted to take forward the different
tasks within WP4.
Section 3 details the current service model available in each of the pilot sites, including how communication takes place between the different members of the care team in the
various care settings involved. Information contained in D2.2 and D3.1 includes details
of the gap analysis for each site's CareWell implementation; this has not been duplicated
within this deliverable. The deliverable also describes and illustrates the technical infrastructure currently available in each of the pilot sites, including what IT systems are
implemented in each of the care settings.
Section 4 provides describes how the service model will be enhanced through the
implementation of both new or improved ICT and associated new ways of working in
each of the care settings. Diagrams illustrating the new technical infrastructure and IT systems are provided with descriptions of the new components where appropriate.
Section 5 details guidance on achieving interoperability between the different IT systems
across the care settings, and provides a high level illustration of the generic CareWell
architecture.
Section 6 concludes with a description of how each pilot site ensures the security and
confidentiality of patient identifiable information within the IT systems and other methods
of communication between the care team members.
1.4 Glossary
The objective of this glossary is to help readers of the document to understanding it. See
also Appendix A Technological Terms.
AReS Puglia Agenzia Regionale Sanitaria Pugliese
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 9 of 106 Public
BP Blood Pressure
BM Body Mass
COPD Chronic Obstructive Pulmonary Disease
CRM Customer Relationship Management service (see also Appendix A)
DICOM Digital Imaging and Communication in Medicine (see also Appendix A)
EC European Commission
ECG Electrocardiography
EHR Electronic Health Record (see also Appendix A)
EU European Union
ENT Ericsson Nikola Tesla D.D.
FAQs Frequently asked questions
F.O.C. Free of charge
GP General Practitioner
HIS Health Information System (see also Appendix A)
ICCM Integrated Chronic Care Model
ICCP Integrated Care Coordination Pathway
ICD Implantable Cardioverter-Defibrillator
ICT Information Communication Technology
IHR Individual Health Record
IKP Individual Patient Account (Lower Silesia)
IMCR Intelligent Mobile Movement Sensor (Lower Silesia)
INR International Normalised Ratio
IT Information Technology
LHA Local Health Authority
LIS Laboratory Information System (see also Appendix A)
LSV Urzad Marszalkowski Wojewodztwa Dolnoslaskiego (Lower Silesia Marshall's office
PAS Patient Administration System
PC Personal Computer
PDAs Personal Digital Assistants
PEHP Patient Empowerment and Home-care Pathway
PHB Powys teaching Local Health Board
PHR Personal Health Record (see also Appendix A)
PKI Public Key Infrastructure (see also Appendix A)
RIS Radiology Information System (see also Appendix A)
ULSS nr2 Unita Locale Socio-Sanitaria Number 2
VPN Virtual Private Network (see also Appendix A)
WiFi Wireless local area network
WoW Ways of Working
WP Work Package
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 10 of 106 Public
2. METHODOLOGY The methodology adopted in this WP followed a ‘bottom up’ approach as illustrated
below:
In order to describe the IT systems or applications involved, not just the applications to
be developed during CareWell, it is important to understand and document the
applications or systems running before the start of CareWell which will have an impact on any new applications or services.
The second stage involved the identification of the functionalities for each system /
application: a summary of the features of each application and user roles.
This was followed by the identification of services provided by each application: the
outcome of this task is a table mapping ICT-enabled services and applications. A template was prepared to capture this information, see Table 1 below.
Table 1: Template - services vs applications
Services App1 App2 App3 App4
EHR
E-prescription
Teleconference Professional –
Professional (audio /movie)
Teleconference Professional –
Patient (audio /video)
PHR
Collaborative Web
Educational Web
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 11 of 106 Public
Services App1 App2 App3 App4
Telecare service
Clinical interconsultation
Analysis and Exploitation of clinical
and management data
The use cases developed in WP2 were then linked to the ICT-enabled services, where one
service could be included in more than one aspect of a use case.
The information and communication flows were then mapped onto the pathways with the current use cases provided for each pilot. The outcome of this task was a first draft of the
structure of pathways in each pilot site.
In order to achieve the same global structure for each pilot site, a common template of
architecture for every pilot site was prepared.
Figure 1: Template for common CareWell architecture
The next step was to document the new or enhanced ICT-enabled services which would
be provided in each pilot site. The technological challenge for pilots was to examine and
document this aspect of the work package, following a common CareWell architecture,
and the interoperability /security guidelines.
The final step was to describe how the new or enhanced ICT-enabled services would
impact on the service specification in each of the care settings in each pilot site.
Common template for architecture pictures
Below is a description of each component included in the Common IT Architecture
diagrams:
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 12 of 106 Public
A. Pathway: The pathway element is identified by a rectangle. In CareWell there are
two pathways.
Rectangle orange: pathway ‘Integrated Care Coordination Services’
Rectangle Blue: pathway ‘Patient Empowerment And Home Support Services’
These elements form the basis for the introduction of the ICT-enabled services.
B. Main Services:
EHR: green rectangle.
C. Level of care (primary, secondary/specialised)
D. Main applications
E. Secondary applications
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 13 of 106 Public
F. Legacy Systems
G. Interoperability platform
Work package information collection
The work package was taken forward using a number of different methods to elicit the
necessary information to support the steps in the methodology described above.
A. Questionnaires
During the WP, two questionnaires were designed and administered to collect
information about the pilot sites:
General Questionnaire: used to understand and document the current
situation in each pilot site together with their proposed CareWell objectives. (Template in Annex 1).
Security Questionnaire: used to collect information about the security
elements used by pilots. (Template in Annex 2).
B. Study Visits
Visits to each pilot site were scheduled after the completion of the General
Questionnaire. The aim of these visits was to:
Clarify information reported in the questionnaire.
Analyse the current technological situation for each pilot through discussions
with the technical team.
Observe the main applications which would be included in the CareWell
solution and analyse the main issues or improve guidelines.
Observe the performance and common user requirements of each application.
Understand any current issues with existing systems in each site from a technical perspective.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 14 of 106 Public
Understand the expectations and challenges in implementing the ICT-enabled
aspect of the CareWell project (service and IT point of view).
C. Technical Telcos
Several telcos were scheduled both one-to-one with each pilot site to clarify specific
issues, as well as general telcos to share the approach, generic issues and present
new actions.
D. Technical Workshops
Two technical workshops were held:
Barcelona: The main objectives of this workshop were:
To define the action plan and establish working groups.
To present the general questionnaire and approval of work plan.
Palma de Mallorca: The objectives of this workshop were:
To establish and analyse the IT diagrams pre CareWell for each pilot.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 15 of 106 Public
3. Current services and technological models
3.1 Introduction
This chapter describes the current situation in each pilot site, not only from a
technological perspective, but also functional, where the service specification in each of the care settings is documented.
The information is divided into two sub sections as follows:
Current services provided: This information was captured using the table below. Each
pilot site was asked to indicate whether or not their current service delivery was supported by each of the ICT-enabled services, together with the implementation
maturity level.
Pilot Site Name Before
ICT-enabled services Operational Maturity level
e-Prescription
Messaging clinician Patients
EHR
Interconsultation
Call Centre
Virtual Conference
PHR
Nursing Information System
Educational Platform
Collaborative Platform
Telemonitoring
Multichannel Centre
(Management Telecare Programs)
The maturity level was assessed using the following criteria:
0 = not implemented.
1 = service implemented and being tested.
2 = service 25% implemented.
3 = service 50% implemented.
4 = service 75% implemented.
5 = service 100% implemented, .e. fully operational with all potential users and
CareWell patients involved.
Current IT architecture: This section describes the current ICT tools deployed in each
pilot site, together with the communication channels and different care practitioners
involved in the care settings within each pathway.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 16 of 106 Public
3.2 Basque Country
3.2.1 Current ICT-enabled service specification
Stable Patients – out of hospital care
Currently, the care of a ‘stable’ patient with complex needs is undertaken by the patient’s
GP and GP practice nurse. Together, these care professionals assess the patient’s needs, draw up the care plan and medication regime, offer patient education, deliver any
necessary interventions either in the GP practice or patient’s home, monitor, review and
reassess the needs of the patient in a planned way, as well as respond to any unplanned
events or deterioration unless emergency services are sought through the eHealth centre.
Information is shared between the care professionals and patient in face-to-face (F2F)
contacts as well as by phone. Care professionals are able to share patient-related
information through the EHR and e-Prescription, and do have periodic multi-disciplinary team meetings F2F and by phone.
Although the GP and GP practice nurse provide a case management service, the actual
co-ordination of care is undertaken by the Telecare Centre, as it acts as a hub for both
health and social care practitioners. The Centre is able to activate additional services by following agreed protocols in response to telemonitoring alerts and alarms, as well as
emergency services if the situation is deemed to require such intervention.
Unstable Patients – out of hospital care
When a patient’s health status deteriorates, either the GP or GP practice nurse will
proactively case manage the patient in their own home, and involve additional healthcare professionals to provide clinical interventions, including those from specialists, as
necessary.
Inpatient – hospital care
If a patient has an emergency admission to hospital, the reference internist takes responsibility for co-ordinating the care for the patient. This will include ordering tests
and investigations, drawing up the care plan in consultation with other healthcare
professionals, reviewing the medication regime and making adjustments as necessary,
co-ordinating any additional specialist input into the patient’s care, as well as communicating information on the hospital admission to the patient’s GP. The internists
will also involve the hospital social care team if the patient requires a social care
assessment with a view to requiring support at home post discharge. If the patient
requires longer term hospitalisation to facilitate rehabilitation, for example, the internists
will arrange the necessary referral.
Inpatient – hospital discharge preparation
The hospital liaison nurse works closely with the reference internist to supervise the
patient’s discharge from hospital. Information, such as the updated care plan and
medication regime, is shared with the GP practice nurse for the intensive follow-up, including home visits when necessary, to monitor the patient’s recovery appropriately. A
frailty assessment will be carried out, and support from social care services activated if
required. In addition, the patient is given information on their care plan, and education
on its content and medication regime.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 17 of 106 Public
Table 2: Current ICT-enabled services of Basque Country
Basque Country Before
ICT-enabled services Operational Maturity level
e-Prescription YES 3
Messaging clinician Patients YES 1
EHR YES 3
Interconsultation YES 3
Call Centre YES 2
Virtual Conference NO 0
PHR YES 3
Nursing Information System YES 3
Educational Platform NO 0
Collaborative Platform NO 0
Telemonitoring YES 2
Multichannel Centre
(Management Telecare Programs) YES 2
3.2.2 Current IT architecture
Osakidetza has services in both the Integrated Care and Coordination and Patient
Empowerment and Home-Support pathways and these services are provided by several
systems. These systems are able to share information through the interoperability
platform (Oracle business service). The figure below illustrates the current IT architecture.
Figure 2: Architecture of Basque Country Pre-CareWell
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 18 of 106 Public
Integrated Care Coordination Services
The Basque Country provides the EHR service through different systems, depending on
the health sector where the service is implemented (primary or secondary care). In primary care, Osabide AP is used, whereas in secondary care there are two systems
deployed - Clinic and Osabide Global. This duplication is due to the Clinic system being
an older viewer which receives clinical data from legacy systems for every hospital,
whereas Osabide Global is a newer version with more functionalities which extend beyond view only.
Currently, Osakidetza are performing a migration task to achieve a single system to
provide EHR services not only in secondary care but also in primary care.
The e-Prescription servic, Presbide, is provided by a single system in both care sectors. This system has been integrated as a module within the EHR systems (Osabide Global
and Osabide AP).
In addition, Osabide AP and Osabide Global provide the interconsultation functionality
which enables care practitioners in primary and secondary care settings to share the most relevant clinical information.
Patient Empowerment and Home-Support Services
This pathway is composed of the PHR service provided through the Health Folder system,
which is integrated within the Multichannel Services Centre (MSC). The MSC manages
several health programmes (stop smoking programme, monitoring sedentary lifestyles, etc.) and collects data from questionnaires completed by patients in the PHF.
In addition, there are distinct telemonitoring programmes that are not focused on frail
elderly patients. These programmes are not connected to the EHR systems, nor MSC,
but use an external monitoring and management console.
Relevant Systems / applications
E-Osabide: is the hospital information system deployed in all hospitals to provide
administrative information (e.g. appointments, demographic data) and clinical
activity data.
Osabide AP: is used in primary care to provide the EHR service. It also has the
Presbide module to provide the e-Prescription service. This system was developed
in .net, has a client/server architecture, and runs on a Citrix platform.
Osabide Global: is a secondary care application providing several services:
EHR;
E-Prescription implement specific module (Presbide);
Interconsultation.
It is developed in java using client/server architecture in high availability on rack
oracle database.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 19 of 106 Public
Figure 3: Functional Architecture EHR in Primary Care (Osabide AP)
Both systems (Osabide Global and Osabide AP) are connected to legacy systems through the Intranet business service. Examples of legacy systems connected to the EHR are
LIS, RIS, anatomic pathology, HIS, etc.
The following picture shows the distinct connections between the EHR used in secondary
care and the legacy systems. These connections are the same for the primary care sector systems.
Figure 4: Functional architecture EHR in secondary care (Osabide Global)
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 20 of 106 Public
Presbide: is a module integrated in Osabide Global and Osabide AP EHR systems
(secondary and primary care). It is developed in java on an Oracle database. The major
difficulty of this tool was the construction, because it requires the implementation of interoperability tools with internal systems as well as external systems.
This complexity is because the development and implementation of e-Prescription is the
responsibility of two organisations: the Basque health service (Osakidetza) has
responsibility over the clinical aspect, i.e. the module for documenting the prescriptions and storage in a central database, and the Health Department has responsibility for the
pharmacies and the dispensing process (dispensing module, erezeta) and Vademecun
which is a set of services which offer information about medicines (products, posology,
composition, etc.).
To date, the e-Prescription project provides interoperability not only at semantic and
syntactic levels, but also at organisational and business process level between two
different organisations (with different systems). The figure below illustrates this
functional integration.
Figure 5: Architecture Basque e-Prescription system
Other elements of the figure:
B38 VDM: Vademecun, set of services which offers information about medicines
(products, posology, composition, etc.).
A53 E-Osabide: is the HIS of Osakidetza with administrative, demographic data.
N12 SWAP: Catalogue of web services for integration with EHR of primary care (Osabide AP).
Zain: Corporate e-signature platform.
B500 impression: Corporate printing system.
CSSM (Multichannel Services Centre Support): is composed of several applications and modules. The most important features included in CareWell are:
Health Folder: this app provides the PHR service. The patients access their health
folder through the link deployed on the corporate Web site. The main functionalities
of the health folder are:
Access to prescriptions (active and historical).
Access to future clinical appointments.
Completed health questionnaires.
Access to health reports (secondary and primary care).
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 21 of 106 Public
CRM: This module is used by clinicians to manage the chronic health programmes
and monitoring the health status of patients.
Web Appointment: used to manage appointments in primary care by patients.
Health Council: set of nurses to answer doubts or questions of citizens. Using a
solution based on OPA (Oracle Policy Automation), a decision making system.
Figure 6 below shows the functional structure of CSSM.
Figure 6: Architecture Multichannel services centre support in Basque Country
3.3 Croatia
3.3.1 Current ICT-enabled service specification
Stable Patients – out of hospital care
Older patients are cared for by primary care health professionals, either by visiting their
GP practice, or having a home visit from a field nurse who covers dedicated geographical
areas, where she might have to cooperate with multiple GP practices. The patient’s GP will meet with the field nurse F2F from time to time as necessary, and a patient’s care
plan and medication regime will be adjusted accordingly. Field nurses will refer a patient
for assessment by social care services if they are considered to have social needs.
Currently, information on the care the field nurses deliver to patients is recorded in paper-based records, and the information is shared with the patient’s GP on a need-to-
know basis. The GP may choose to enter relevant information relating to the field nurse
activities and care into their electronic record system.
Unstable Patients – out of hospital care
If a patient becomes ‘unstable’, a patient can contact the field nurse in the healthcare
centre (call centre) during a one-hour period first thing in the morning. The nurse will
often increase their home visits, or home visits will be initiated for a patient who was
previously able to visit the GP in their practice. The GP will refer the patient for tests,
investigations, and specialist consultations from hospital services where necessary, and again, adjust the patient’s care plan and medication regime accordingly. There is
currently no electronic exchange of information.
Inpatient - hospital care
Patients admitted to hospital are cared for by specialists and dedicated hospital nurses. If the GP refers the patient for admission, information is sent by paper with the patient.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 22 of 106 Public
Inpatient – hospital discharge preparation
Discharge information, including care plan and medication regime, is prepared from the
hospital records by a dedicated nurse, and a paper letter is given to the patient for them to give to their GP. When this information has been received by the GP, it will be entered
into the GP electronic clinical record. The discharge nurse will liaise by telephone with
the field nurse using the call centre facility available each morning.
The table below summarises the current ICT-enabled service provision in the Croatian pilot site.
Table 3: Current ICT-enabled services of Croatia
Croatia Before
ICT-enabled services Operational Maturity level
e-Prescription YES 5
Messaging clinician Patients NO 0
EHR NO 0
Interconsultation NO 0
Call Centre NO 0
Virtual Conference NO 0
PHR NO 0
Nurse Information System
(record of nursing care) NO 0
Educational Platform NO 0
Collaborative Platform NO 0
Telemonitoring NO 0
Multichannel Centre (Management Telecare Programs) NO 0
3.3.2 Current IT architecture
The current IT architecture of the Croatian pilot is illustrated below:
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 23 of 106 Public
Figure 7: Current IT architecture of Croatia
Integrated Care Coordination Services
The architecture shows typical elements required to provide simple channels of
communication between services of different health care sectors (primary, secondary and
tertiary). Although there is no global EHR service, the Croatian pilot has distinct GP
systems containing health information (G2 or GP system) and a network for sharing
some information between primary and secondary care (G1).
There are several legacy systems, such as LIS, HIS, RIS, in all hospitals. The information
of these legacy systems can be viewed in secondary care through specific programs,
which can differ from one hospital to another. Primary care professionals can access the
information of legacy systems through VPN connection from G2 to G1.
Patient Empowerment and Home-Support Services
Currently, the Croatian pilot does not have any ICT-enabled systems providing services
oriented to patient empowerment and home-support pathway.
Relevant Systems / applications
The principal systems in Croatia are:
G1 System: This application is also called the ‘Health networking information
exchange system’. It is a central communication and processing platform used for
communication between all stakeholders (IT systems) within the national healthcare system in Croatia. This application runs on a complex set of servers.
G2 application: This application is also known as the GP office application. It is used
by GP and his assisting nurse, to manage patient data as well as business
administration of GP office. There are many G2 applications supplied by various
vendors that run on different platforms, ranging from a PC as a client application
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 24 of 106 Public
that communicates with G1, up to those that have separate servers and clients
where communication to G1 is executed from a local server.
Figure 8: Functional Structure G2
Hospital IT System: Integration information system used to manage all aspects of
hospital operation (medical, administrative, financial, legal. etc.). There are a
number of vendors in Croatian market; it is therefore not possible to describe the
overall IT infrastructure.
3.4 Lower Silesia
3.4.1 Current ICT-enabled service specification
Stable Patients – out of hospital care
Co-ordination of care is currently undertaken by the GP, and is reliant on the relevant
information held in paper-based systems being shared by letter, fax or phone to inform
decision-making.
Unstable Patients – out of hospital care
Environmental nurses visit patients at home at the request of GPs, and they assess a
patient’s needs and provide the necessary care. Again, information from paper-held
records is shared with the relevant healthcare practitioners, except for the electronic transmission of ECG to hospital by the emergency services. Patients and informal carers
are reliant on signposting to support services, as there is currently no ‘directory of
services’ available to help people find appropriate care to meet their needs.
Inpatient - hospital care
A patient will be admitted to hospital if necessary, following an assessment in the emergency room. They will have their needs assessed by a multi-disciplinary team; this
assessment includes frailty for older people. Information on the patient’s tests,
investigations, care and treatment is recorded in a range of hospital IT systems and
paper records; communication between the care practitioners is via these record systems and F2F. If the frailty assessment outcome indicates that the patient will require social
care, home care, nursing care or long term care, the hospital social worker will make the
necessary referrals.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 25 of 106 Public
Inpatient – hospital discharge preparation
A hospital discharge card containing information on recommendations for on-going care
and support is prepared by a nurse on the hospital ward, and given to the patient on discharge.
The table below summarises the current ICT-enabled services available in Lower Silesia.
Table 4: Current ICT-enabled services of Lower Silesia
Lower Silesia Before
ICT-enabled services Operational Maturity level
e-Prescription NO 0
Messaging clinician Patients NO 0
EHR YES 2
Interconsultation NO 0
Call Centre NO 0
Virtual Conference NO 0
PHR YES 2
Nurse Information System (record of nursing care) NO 0
Educational Platform NO 0
Collaborative Platform NO 0
Telemonitoring NO 0
Multichannel Centre
(Management Telecare Programs) NO 0
3.4.2 Current IT architecture
The current IT architecture of Lower Silesia pilot is illustrated below:
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 26 of 106 Public
Figure 9: Current Architecture of lower Silesia
Integrated Care Coordination Services
In Lower Silesia, the EHR service / system is connected to legacy systems in all hospitals
by an internal service bus. However, it is not currently possible to exchange health
information between hospitals electronically. In primary care, the clinical information is
managed by GPs, who use different EHR applications with a local data store.
Patient Empowerment and Home Support- Services
Lower Silesia offers several web portals with information about the most common chronic
diseases (diabetes, heart failure, etc.). However, no platforms are focused on patient /
caregivers empowerment or targeted patient education.
Relevant Systems / applications
HIS: Each hospital has its own HIS; it is not possible to access information held in
another hospital HIS. The information stored in these systems is clinical and
administrative. HIS is integrated with other hospital legacy systems through a
service bus. The HIS provides the EHR and e-Prescription services.
GP system: There several applications providing GP systems in Lower Silesia. The
EHR within the GP system is not shared with secondary care, nor other GP systems.
3.5 Veneto
3.5.1 Current ICT-enabled service specification
Stable Patients – out of hospital care
Patients with complex needs are currently assessed by a multi-disciplinary team in the multidimensional assessment unit following a GP referral or referral following a hospital
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 27 of 106 Public
admission. From this assessment, which is informed by collecting information from the
various care practitioners involved, a personalised care plan and medication regime is
drawn up on paper; this is shared with the appropriate people. The GP and primary care territorial services co-ordinate the care of the patient. Some patients may have telecare
services such as panic buttons or community alarms.
Unstable Patients – out of hospital care
If a patient has previously had a multi-disciplinary assessment, but their condition deteriorates, the GP or the other professionals can activate a new multi-disciplinary
assessment. The new evaluation can lead to additional home care interventions and
support through the territorial social workers, home-care nurses. The GP can also refer
the patient for new tests, investigations or specialist consultation. The home care is co-ordinated by the Social and Healthcare District services, among which there is also the
Territorial Operational Centre (TOC). A home-care nurse provides a case management
service, and delivers additional patient education to help the person self-care and self-
manage. In the event that a telecare alarm has been activated, the response centre can arrange transportation to the hospital emergency room if considered necessary.
The GP will refer the patient for the multi-dimensional assessment unit if their health and
wellbeing has significantly deteriorated. As a result of the agreed care plan, the TOC will
co-ordinate the care of the interventions in the care plan, and ensure communication
takes places between the various care givers.
The Client Resource Management (CRM) in the TOC collects and shares information
between the different territorial health and social care services including, the hospital
laboratory and diagnostics, with communication between other services and care givers
being by phone, email, paper/fax or F2F.
Inpatient - hospital care
Whilst a patient is in hospital, a patient is case managed by a hospital doctor with nurses
delivering care, administering drugs, co-ordinating services and interventions. The doctor
draws up a care plan, and the nurse makes arrangements for any home care interventions required. Information is recorded in the CRM with communication between
the healthcare practitioners being undertaken F2F.
Inpatient – hospital discharge preparation
When a patient is ready for discharge, the hospital doctor and nurse liaise with the TOC
or the Home Care Nursing Service by phone, and any necessary home-care services are scheduled. A referral to the multi-dimensional assessment unit can be made, a care plan
is drawn up, and information is given to the patient and any informal carers to help with
self-care and self-management. The patient’s GP receives information on the care plan
by phone and/or fax from the TOC or the hospital, and, if required, visits to the patient at home are arranged.
Below is the table summarising the current ICT-enabled services available in Veneto:
Table 5: Current ICT-enabled services of Veneto
Veneto Before
ICT-enabled services Operational Maturity level
e-Prescription YES 5
Messaging clinician Patients NO 0
EHR YES 1
Interconsultation NO 0
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 28 of 106 Public
Veneto Before
ICT-enabled services Operational Maturity level
Call Centre NO 0
Virtual Conference NO 0
PHR NO 0
Nurse Information System
( record of nursing care) NO 0
Educational Platform NO 0
Collaborative Platform NO 0
Telemonitoring NO 0
Multichannel Centre (Management Telecare Programs) YES 5
3.5.2 Current IT architecture
Veneto has central databases for sharing information among clinical systems
(prescriptions, demographic data and clinical reports).
In addition, there are several interoperability platforms, such as the Mirth platform or Bus service, which uses HL7 to build the messages between systems (HL7, SOAP,
DICOM, etc.).
Figure 10: Current Architecture of Veneto
Integrated Care Coordination Services
The e-Prescription service is provided by the same system in both care sectors (primary
and secondary), and it has a central repository of prescriptions. The EHR is provided in primary care by the Territorial Information System. In secondary care, the hospitals have
a HIS with two modules, one for administrative management, and another for
documenting medical information – the e4cure module which is a proprietary EMR
solution, together with the e-Prescription.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 29 of 106 Public
Patient Empowerment and Home Support-Services
This pathway is supported by a web portal providing the interaction between the local
health authority and the citizen/patient and some educational materials, together with the telecare service e.g. panic buttons and community alarms provided by the Regional
Tele-emergency solution.
Relevant Systems / applications
The current application / systems running in Veneto have been developed following two types of architecture:
Three layers (Web applications): composed by presentation layer, business layer
and persistence layer. This architecture comprises:
e-Prescription to provide the e-prescription support.
Web site of LHA provides the PHR service.
Regional Tele-emergency solution provides telecare service.
e4cure and Talete (EMR) provides interconsultation service.
Territorial Information System provides EHR service.
Client / Server application: This architecture comprises:
GP systems: to provide EHR service.
Pharmacy software: to provide an aspect of the e-Prescription.
3.6 Puglia
3.6.1 Current ICT-enabled services specification
Stable Patients – out of hospital care
Patients are currently cared for by their GP in collaboration with nurses and specialists in outpatient clinics (not hospital outpatient clinics). Information is shared by phone and
written documents. In addition, the integrated EHR is used to record and share
information between the care manager and GPs. Specialists, to date, are not involved in
sharing information through the EHR. Patient empowerment comes from the counselling given by the care manager.
Unstable Patients – out of hospital care
Patients with complex needs are case managed in the outpatient clinic by a primary care
specialist nurse (CM), GP and specialists. The care delivered to patients who are ‘unstable’ is the same, although the frequency and intensity of some or all the care plan
interventions would change. The GP and CM use the EHR to share information about the
patient, but the specialists usually contact the team by phone. An integrated frailty
assessment is undertaken, and the patient follows their defined chronic care pathway and
is often referred to community and home care nursing services and/or any necessary social care service. All care and support is co-ordinated by the CM. Telemonitoring for
patients is only in an emergency (when the A&E department is involved), and consists of
the ambulance paramedic sharing information with the A&E doctors.
Inpatient - hospital care
When an ‘unstable’ patient is cannot be managed in the primary care setting, the GP or
specialist refers them for hospital care. When admitted to hospital, the patient is
assessed by a hospital specialist, using information from the GP if possible
(communication is provided by phone, email and SMS). The hospital specialist arranges for any tests and investigations, and draws up the care plan and associated medications.
Day-to-day care is provided by the ward nurses supported by the family or informal care
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 30 of 106 Public
giver. Information on the hospital episode of care is recorded on a medical chart by the
specialist and ward nurses, and then synthesised into a discharge sheet, ICD9 CM
codified, and uploaded into the regional health information system (Edotto). In turn, this feeds the national administrative database held by the Health Ministry and Economic
Ministry. When a patient is deemed to be stable, the hospital specialist prepares a
discharge letter summarising the hospitalisation event, and shares this clinical
information with the GP.
Inpatient – hospital discharge preparation
The ‘stabilised’ patient is discharge from hospital back to their home. The hospital
specialist transitions the patient to the territorial CM, and gives them a discharge letter
summarising the hospitalisation event to share the clinical information with their GP. The professionals only communicate via paper documentation.
Below is the table of current ICT-enabled services available in Puglia:
Table 6: Current services of Puglia
Puglia Before
ICT-enabled services Operational Maturity level
e-Prescription NO 0
Messaging clinician Patients NO 0
EHR YES 4
Interconsultation NO 0
Call Centre NO 0
Virtual Conference NO 0
PHR NO 0
Nurse Information System ( record of nursing care)
YES 5
Educational Platform NO 0
Collaborative Platform NO 0
Telemonitoring YES 3
Multichannel Centre (Management Telecare Programs)
YES 2
3.6.2 Current IT architecture
The current IT architecture of Puglia pilot is illustrated below:
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 31 of 106 Public
Figure 11: Current Architecture of Puglia
Integrated Care Coordination Services
Puglia has an ICT architecture (Apulia WAN RUPAR) that provides connection services
and brokering access with strong authentication to all operators of the Public
Administration, and in particular to the nodes of the healthcare system. The Apulia
RUPAR houses the Regional Health Information System, named Edotto, which collects, informed by local Health Authorities, administrative and clinical data for the
management, governance and epidemiological investigations in the field of health. Edotto
summarises data coming from different health domains (primary care, hospital
discharges, outpatients clinics data, A&E flows, pharmaceutical consumptions, mental health, pathologic dependences, etc.) both automatically into the system, or migrated
from other information systems working on SPcoop standards (interoperability standards
for public administrations). Many of data flows uploaded into Edotto feed the national
administrative database of the Health Ministry and Economic Ministry.
Patient Empowerment and Home Support-Services
Patient empowerment and home-support services are currently provided by the CM
through counselling the patient.
Relevant Systems / applications
In cooperation with Edotto (which extracts patients registry data), the Nardino information system (Puglia Care program software) provides the EHR for the primary
care team. The Nardino program is a web-based platform that provides management
services to support the delivery of care for patients with chronic conditions. It is
implemented on the WAN RUPAR directly, or by a VPN enciphered connection. The information system, built with open source technology, manages the access profiles of all
those involved in the care of chronic patients. Each team member has a specific
operational profile, e.g. CM, GP. In particular, Care Puglia program software also
implements a back office system for managing user profiles and information structure for
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 32 of 106 Public
displaying reports and indicators. The back office activities for the management of the
user community are delegated to specific users’ administrative access, that can create
new profiles or delete an existing one with the help of wizards and automatic utilities. The framework for reporting ensures the consultation of a list of approximately 150
indicators of process, outcome, and quality, processed and presented in real time. It also
has a utility for downloading whole report in CSV format.
The system maintains a clinical framework that builds an information folder containing the patient's medical history, clinical evaluations and nursing, therapy, diaries notes, and
a complex system for planning, co-ordination and follow-up of the typical activities of the
CM. The Care Puglia program is also equipped with standard interfaces for web services
that use SOAP and SOA architecture with native support for HL7.
Clinical information coming from Care Puglia program platform represents the EHR by
which primary care health professionals (not the specialist) share information about a
patient.
Cardiac remote monitoring information collected in an emergency is not included in Edotto or Nardino. It is only seen by the hospital clinician in the A&E department.
Figure 12: Architecture of Nardino
3.7 Wales
3.7.1 Current ICT-enabled service specification
Stable Patients – out of hospital care
Patients with complex needs are cared for by primary and community care services with
the co-ordination usually undertaken by either a community district or specialist nurse.
Presentation Layer: Script CGI, WEB GUI (html, JS - Jquery)
Standard: DICOM, HL7, SOAP …
Persistent Layer: Logging, Environment variables, Crypt CBC …
Registry
Repository
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 33 of 106 Public
The patient’s GP or practice nurse undertakes a scheduled review of their health and
wellbeing on an annual basis; they may also be seen routinely in hospital outpatient
appointments. Information on assessment, care plans and interventions is recorded in the GP clinical information system (EHR) and health board patient administration system,
as well as the nurses using some paper record keeping systems. Communication is by
F2F, phone or email (patient identifiable information cannot currently be exchanged via
email). Referrals to hospitals can be undertaken via the Welsh Clinical Communications Gateway (WCCG).
Social care services can be accessed by the patient, family or informal carer by F2F
communications or via the call centre. Healthcare professionals can also make a formal
referral for an assessment by social care services.
Patients also have access to My Health Online, which is a summary personal health
record. Currently patients can order prescriptions, book GP practice appointments and
view and update the demographic details of their PHR.
Unstable Patients – out of hospital care
If a patient’s health and wellbeing deteriorates, additional community services can be
accessed through the community resource team (CRT). This team will undertake a multi-
disciplinary assessment, revise the care plan accordingly, and monitor the recovery of
the patient for a period of time. Most community nurses have access to information in
the GP clinical information systems (EHR), but communication between the care team is usually F2F or by phone.
Inpatient - hospital care
Within Powys, patients can only be admitted to a community hospital; they would go
outside the area if their health needs were severe. The GP would arrange a community hospital admission, often involving the ambulance service for transport. Whilst in
hospital, patients would be under the care of a GP; information is entered into the
Myrddin patient administration system. The GP assesses the patient, can order basic
laboratory and radiology tests, and adjust medication. Rehabilitation services are also available if required. Information from the GP clinical system is usually available to
provide the medical history of the patient. The GP and hospital nurses use the health
board’s patient administration system, Myrddin, and paper records to record the care
delivered. Communication is mainly by phone between the GP practice and hospital.
Inpatient – hospital discharge preparation
A care transfer co-ordinator is responsible for making the necessary arrangements for
hospital discharge; this will be recorded in the patient’s notes and patient administration
system. This person will liaise by phone with the patient’s GP, community and/or
specialist nurse, community therapy services if required, and reablement services. The Co-ordinator has F2F meetings with the hospital nurses and doctor to gain the necessary
assessment and care planning information.
The GP will refer the patient to a secondary care specialist via the WCCG if necessary.
The GP will also enter information about the patient’s hospital admission into their EHR and prepare any e-Prescriptions as necessary.
The table below summarises the current ICT-enabled services available in Wales:
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 34 of 106 Public
Table 7: Current ICT-enabled services of Wales
Wales Before
ICT-enabled services Operational Maturity level
e-Prescription YES 5
Messaging clinician Patients NO 0
EHR YES 5
Interconsultation NO 0
Call Centre YES N/A
Virtual Conference NO 0
PHR YES 4
Nurse Information System (record of nursing care) NO 0
Educational Platform YES 2
Collaborative Platform YES 3
Telemonitoring NO 0
Multichannel Centre (Management Telecare Programs) NO 0
3.7.2 Current IT architecture
Currently, the Powys pilot has more IT architecture and ICT-enabled services to support
the integrated care coordination pathway rather than the patient empowerment pathway.
The current IT architecture of Powys pilot is illustrated below:
Figure 13: Current Architecture of Wales
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 35 of 106 Public
Integrated Care Coordination Services
The integration care pathway is based on three elements (GP system, WCP, and WCCG).
These three elements cover the most important services (EHR, e-Prescription, and inter-consultation). The EHR is provided through the WCP in secondary care and the GP
system is the EHR in primary care. In addition, the WCCG provides the interoperability
tool for sending referral information from primary care to secondary care. Currently, it is
only is possible send electronic referrals to secondary care, with the referral being populated automatically from the GP clinical system (EHR) together with free text.
Patient Empowerment and Home Support- Services
The pathway for Patient Empowerment has three important applications / systems as
follows:
My Health On line (MHOL): this app provides the PHR service.
Myrddin: this system provides the district and specialist nurses with their home visit
schedule and activities.
Draig: This is the current IT system to support the delivery of social care services in Powys. During CareWell, this system will be replaced by an integrated social and
health care administrative IT system (CCIS).
Relevant Systems / applications
GP systems: this system is used in primary care for recording clinical information
and providing e-Prescription service.
WCCG (Welsh Communications Gateway): this system allows GP system users to
execute electronic referrals to secondary care. The solution implemented is based
on software developed by NHS Scotland. The user accesses the WCCG via a button
or link within the GP system user interface. When the user ‘clicks’ on the button / link, an external application is started, which is displayed in a browser on the user’s
PC.
The WCCG will extract patient demographic and clinical data for inclusion in the
referral from the GP system. The WCCG application is also able to write back data into the GP system via a proprietary GP system supplier specific interface.
The integration of WCCG and National Applications is under the ‘control’ of NWIS.
There is a dependency on development resources with NHS Scotland, but this is
seen as a very low risk. This allows changes to the integration of applications
between WCCG API and any other application in the future (as displayed above).
The illustration below shows the different connectors developed for the WCCG to
achieve interoperability between GP systems and systems used in secondary care.
It also includes the specific module (GP client) used by the GP system to connect
with other secondary care systems facilitated through WCCG.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 36 of 106 Public
Figure 14: Communications channels of WCCG
WCP (Welsh Clinical Portal): The WCP is a web application used in secondary care
for clinical communications with primary care and views individual patients records. Moreover WCP allows making prescriptions, reports, request etc.
Figure 15 below shows the several (internal and external) connectors developed to
achieve interoperability with legacy systems within the hospitals and with external
services through WCCG.
Figure 15: Welsh Clinical Portal (WCG) Integration architecture
IHR (Individual Health Record): The IRH is a summary of the GP system EHR. It is
derived and updated automatically each day. Currently, the IRH is used to support the GP out-of-hours service. Patients are able to ‘opt out’ of their GP EHR being
used to create the IHR.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 37 of 106 Public
OOHS (Out-of-Hours Service): The IT system used by the Out-of-Hours GP is called
Adastra; this enables access to the IHR on a view only basis.
eMPI (electronic Master Patient Index): The eMPI is the national (all Wales) database of patient demographic details. IT systems in hospitals and GP practices
can access the eMPI to read patient details and feed updated information back into
the local IT system. Not all systems have full access to the eMPI, but as new
systems are implemented, the use of the eMPI is extended.
Myrddin (Patient Administration System): Myrddin is the name of the PAS used in
secondary care (community hospitals) in Powys. It contains demographic, inpatient
and outpatient contacts and activities for healthcare practitioners. The MPI within
Myrddin provides demographic feeds to the eMPI and other clinical information systems.
3.8 Analysis of current service specification vs IT systems
Analysis of the current situation in relation to the level of service specification and ICT-
enabled services and architecture available in each of the pilot sites indicates that the
sites can be divided into two groups:
Pilot sites with many deployed systems that are an integral part of the CareWell solution, and therefore a level of integration or interoperability is required.
Pilot sites whose CareWell solution is less dependent on any existing deployed
systems, and therefore the requirement for integration and interoperability is much
less.
Below is a diagram illustrating the level of development of ICT-enabled services in
CareWell:
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 38 of 106 Public
Figure 16: Wales: Level of development of ICT-enabled services
0.00
0.50
1.00
1.50
2.00
2.50
3.00
3.50
4.00 e-prescription
Messaging clinician ßà Patients
EHR
Interconsultation
Call Center
Virtual Conference
PHR
Nurse Information System
Educational Platform
Colaborative Platform
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 39 of 106 Public
4. CareWell ICT-enabled service specification and IT architectures
This section describes the services, IT systems or IT architecture elements adapted
within CareWell project.
4.1 Basque Country
4.1.1 CareWell service specification
Stable patients – out of hospital care
The current service model will be enhanced in a number of ways:
Wider deployment of the reference internist and hospital liaison nurse into other
hospitals in the region.
Developing and implementing procedures to provide messaging between patients and healthcare practitioners through the electronic Personal Health Folder.
Further develop the care pathways for frail older people to extend the eHealth
Centre and Telecare Centre to provide improved telemonitoring and follow-up /
response calls.
Provide symptom management questionnaires in the Personal Health Folder to
further support self-care and self-management.
Rolling out the electronic prescription to additional healthcare professionals
including pharmacists.
Provision of self-care and self-management educational material through the
Personal Health Folder and Osakidetza web portal.
Unstable Patients – out of hospital care
In addition to the above service model enhancement for the ‘stable’ patient, healthcare
professionals will have improved access to near-time information to assist with decision-making when a patient’s health status deteriorates. The enhanced role of the eHealth
and Telecare Centres will enable easier continued follow-up of the patient during their
recovery period, thus reducing the need for F2F visits.
Inpatient - hospital care
Healthcare professionals in the hospitals will have richer information to understand the
nature of a patient’s deterioration leading up to their emergency admission, including
telemonitoring information and symptom management questionnaire responses. It is
likely that the acuity of patients requiring hospital admission will increase as more patients are able to be managed by telemonitoring and support in their own homes for
minor exacerbations.
Inpatient – hospital discharge preparation
The information entered into the CRM by the hospital liaison nurse will be able to be
viewed by all healthcare practitioners involved in a patient’s care team; this will provide a much improved, streamlined and safer service model.
Tailoring telemonitoring and self-care and self-management information and education to
the individual patient will be facilitated through defining the telemonitoring parameters
and educational material provided to the patient and their family / informal care givers through the Personal Health Folder.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 40 of 106 Public
Table 8: Services Evolution Basque Country
Basque Country Before After
ICT-enabled service Operational Maturity
level Operational Maturity
level
e-prescription YES 3 YES 5
Messaging clinician Patients YES 1 YES 4
EHR YES 3 YES 4
Interconsultation YES 3 YES 4
Call Centre YES 2 YES 2
Virtual Conference No 0 NO 0
PHR YES 3 YES 4
Nurse Information System
(record of nursing care) YES 3 YES 3
Educational Platform No 0 YES 4
Collaborative Platform No 0 NO 0
Telemonitoring YES 2 YES 3
Multichannel Centre
(Management Telecare Programs) YES 2 YES 3
4.1.2 CareWell IT architecture
As described in 4.1.1 above, the Basque Country is making a number of changes to
improve their services:
Integration into the EHR data from the hospital pharmacy.
Integration of systems to provide EHR in a single system for both care sectors
(primary and secondary care).
Messaging between patients (PHR) and clinicians (EHR).
Integration of the clinical information from the CareWell chronic programmes in
EHR.
Improve the Business Intelligence to provide new functionalities for patient
stratification.
Development of an educational web platform for patients.
The diagram below illustrates the CareWell architecture:
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 41 of 106 Public
Figure 17: CareWell Architecture of Basque Country
The above technological improvements will result in new or enhanced applications and functionalities described below.
4.1.2.1 New systems or new functionalities
Integration in EHR data of hospital pharmacy
The e-Prescription service in secondary care will be extended to include primary care with a shared database. This will be achieved through the deployment of several web services
designed to recover and upload data to the central e-Prescription database irrespective of
whether the prescription request is made from the module in the primary or secondary
care IT system.
System integrated of both primary and secondary care EHRs
The interface of the application integrating both EHRs is equal to that used in secondary
care. The major challenge, therefore, is the implementation of this application in primary
care, where practitioners can be reluctant to use new applications. In order to avoid this
situation, a contingency measure has been established which defines a progressive functional adaptation for primary care users. This plan outlines how the functional
modules only present in the primary care EHR can be gradually added to the new
application, although the interface visualisation will be slightly different.
The picture below shows the modules deployed in the new application during the first phase of the integration process.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 42 of 106 Public
Figure 18: New application modules
The following diagram shows the common features shared by primary care EHR and secondary care EHR.
Figure 19: Common features
Integration within the EHR of the clinical information collected from the
telemonitoring platform
MSC is the main element of the integration, since it functions as a bridge between the
EHR and the telemonitoring platform where the CareWell program is stored. The
procedure consists of three steps: firstly, the clinical data is transmitted to the MSC; secondly, the MSC publishes a new web service; and thirdly, the EHR system requests
the information from the patient’s CareWell program to the web service.
Messaging between patients an clinicians
In order to provide this service, new versions of both the EHR and PHR systems will be developed. The EHR system has its own system of messaging, which allows for
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 43 of 106 Public
messages to be sent to the PHR through a service bus using a web service specifically
created for this purpose.
In addition, the PHR system will present a client which enables calling to web service and recovering the message from the EHR system. Additional minor changes have been
incorporated into the graphical environment in order to define the user’s interface. The
existing database will be adapted to store minimum historical messages.
Development and standardisation of the data collection to automate the risk stratification score calculation
The independent variables needed to calculate the risk stratification score developed in
the Basque Country come from several administrative and clinical databases
(hospitalisation, emergency visits, consultation, prescription, diagnosis, prescription, demographic data, etc). All this data needs to be linked at patient level. During the
CareWell project, a Data Business Warehouse has been developed which allows data to
be collected from several databases in a standardised way.
Through this data collection process, the prediction risk algorithm is applied manually, and the outcome of the risk stratification at patient level is uploaded into the EHR.
The risk stratification score is used in the CareWell pathway to identify patients with high
complex needs who are most likely to benefit from the CareWell pathways and services.
Develop a new educational web
New educational materials and documentation have been added to the Basque Health Service’s web portal. There is a specific section in the portal called ‘Health School’ where
distinct content aiming to foster patient / caregiver empowerment are described:
Actions in case patient health worsened.
Healthy lifestyles.
Information about your disease.
4.2 Croatia
4.2.1 CareWell service specification
Stable Patients – out of hospital care
The service model will predominantly be enhanced through the deployment of new ICT,
and resultant new ways of working between the GPs and field nurses, social workers and patients in the following ways:
Development and implementation of the Ericsson Mobile Health chronic disease
management system (EMH) system for the field nurses to record the care they
provide to patients. This information will be immediately available to the GP if
necessary.
The implementation of the EMH system will enable GPs to review a patient’s care,
and provide advice or a change in a patient’s care plan or medication regime
through the system rather than having to meet the nurse F2F.
Field nurses will be able to communicate with the social care workers through the EMH system.
Patient information to support self-care and self-management will be developed and
made available through the EMH system for the nurses to pass on to the patient.
This should ensure consistent quality of educational content, and enable
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 44 of 106 Public
information to be updated easily within the system, and new knowledge to be
shared.
Unstable Patients – out of hospital care
The EMH system will facilitate the field nurses obtaining additional support and advice
from the patient’s GP practice if they become ‘unstable’; a patient’s care plan will be
optimised to manage the ‘deterioration’ quicker that is the case currently. The nurses will
also be able to provide the patient with additional educational material to help them self- care and self-manage their health and wellbeing during the period when they are
considered ‘unstable’ and not requiring hospital admission.
Inpatient - hospital care
If a patient does have to be admitted to hospital, the GP will be able to provide the hospital with up-to-date information to support the admission and medical history of the
patient.
Inpatient – hospital discharge preparation
The introduction of the EMH system will facilitate the discharge of patients, as hospital
healthcare professionals will be aware that patients can be more closely monitored in their own homes and be better supported to self-care and self-manage.
Below is the table summarising the evolution of ICT-enabled services in CareWell.
Table 9: CareWell ICT-enabled services of Croatia
Croatia Before After
ICT-enabled service Operational
Maturity
level Operational
Maturity
level
e-prescription YES 5 YES 5
Messaging clinician Patients NO 0 YES 1
EHR NO 0 NO 0
Interconsultation NO 0 NO 0
Call Centre YES 3 YES 3
Virtual Conference NO 0 NO 0
PHR NO 0 YES 1
Nurse Information System
(record of nursing care) NO 0 NO 0
Educational Platform NO 0 YES 1
Collaborative Platform NO 0 NO 0
Telemonitoring NO 0 YES 1
Multichannel Centre
(Management Telecare Programs) NO 0 NO 0
4.2.2 CareWell IT architecture
The main challenge for Croatia pilot during CareWell is to develop and deploy the architecture required to deliver the patient empowerment and home-support services
pathway. The core of this architecture is Ericcson Mobile Health chronic disease
management system.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 45 of 106 Public
Figure 20: CareWell architecture Croatia
For this activity, the EMH has several adapters and viewers that enable it to run on
several platforms such as tablet, PC or TV (Smart TV).
Main Technological Changes during CareWell
The Croatian pilot will focus on the following technological developments:
To adapt and deploy to a pilot population the EMH system consisting of a number of
modules to support chronic conditions management and the provision of digital
educational tools for patients.
To integrate the telemonitoring data from the EMH into the GP patient record within
the GP application (G2).
Develop and implement the Home Health Smart TV viewer to enable patients and
informal caregivers to access the telemonitoring data collected by the field nurses
using EMH.
Ericsson Mobile Health Chronic disease management system
This is a platform to provide remote health services, applicable for various use cases in
healthcare, self-care and wellbeing, to be implemented for the purpose of CareWell
project. EMH will receive input from physiological measurement devices and record the data into the PHR, which will be viewable on the android application running on a tablet
or Home Health Smart TV. This data will also be sent to G1.
The roles able to use EMH will be GP/Nurse, Field Nurse, Social Care Worker, Caregiver,
and Patient.
In the scope of the project, there are novel features for Smart TV-based information and
warning system which will be developed by FER. Details of the functionality of the EMH
and home health Smart TV is given below.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 46 of 106 Public
Figure 21: EMH chronic disease management system
FER Home Health Smart TV
FER Home Health Smart TV will provide easy access to the valuable EMH data to patients.
FER Home Health Smart TV is deployed on Android 4.2 Set Top Box which enables the execution of the application on any type of TV device. The system consists of two main
components:
FER Home Health TV application.
Adapter service.
Using the carefully designed application, patients and their caregivers can access and view their medical data such as medical measurements, warnings and messages, and
educational materials provided by medical experts. For the purpose of Croatia pilot, FER
Home Health TV will enable only one role – patient. In order to improve the
interoperability of FER Home Health TV system, the adapter service is designed and integrated. Using the adapter service, internal application methods are adapted to the
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 47 of 106 Public
application programming interface of appropriate eHealth service provider which enables
the integration of FER Home Health TV system in different environments and eHealth
systems. Adapter service in the scope of CareWell project communicates with EMH Technical node REST API using HTTPS protocol.
The advantage of adapter service is that it would be easily installed in other CareWell
pilot sites if there was interest.
The diagram below shows the ‘track and trend’ view of a patient’s physiological measurements within the Home Health Smart TV application.
Figure 22: FER Home Health Smart TV
4.3 Lower Silesia
4.3.1 CareWell service specification
Stable Patients – out of hospital care
The implementation of the CareWell integrated pathway will enable to following
developments to the service model:
Better understanding of the roles and responsibilities of the different care practitioners involved in delivering services and interventions within the care
pathway.
Integrating the hospitalisation of those patients who require it as part of the care
pathway to provide better patient care transition experiences across the different sectors and professionals.
Introduction of telemonitoring for patients who require this service.
Easier access to healthcare response service for patients through the platform.
ECR will provide an improved communication mechanism through the email box,
and thus enhance the co-ordination of a patient’s care.
The platform will provide a directory of services for patients, family members and
informal care givers, as well as professionals, to search for appropriate quality
assured health and wellbeing services that are available.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 48 of 106 Public
Unstable Patients – out of hospital care
The above enhancement for the ‘stable’ patient will also be relevant for the ‘unstable’
patient. In addition, virtual consultations will be able to be activated, if necessary, between the hospital specialists, nurses and GPs via the email box when a patient’s
health and wellbeing deteriorates.
Inpatient - hospital care
The hospital information system (HIS) will be integrated into the ECR; healthcare professionals will have access to the information (anonymised) in the platform if a patient
gets admitted. Selected doctors involved in CareWell will have access not only to the
information in the HIS, but also to the LSV CareWell platform. If the doctor is interested
in the information uploaded by the patient, they will ask permission from the patient to look at this data. This should provide improved information on the patient’s medical
history and the events and care leading up to the hospital admission.
The educational platform in this phase of the project is not targeted at hospital doctors,
but they will be able to access the information in the platform if they are interested in it.
Inpatient – hospital discharge preparation
The hospital will be able to refer the patient for telemonitoring if they are not already
receiving the intervention according to the defined CareWell criteria, and determine their
physiological parameters and frequency accordingly. In addition, patients will be
signposted to appropriate patient empowerment services and educational content through the platform.
For patients who were receiving telemonitoring prior to their admission, it is expected
that they will return to receive the telemonitoring service upon discharge from the
hospital.
Table 10: Evolution of ICT-enabled services in Lower Silesia
Lower Silesia Before After
ICT-enabled service Operational
Maturity
level Operational
Maturity
level
e-prescription NO 1 NO 1
Messaging clinician Patients NO 0 YES 3
EHR YES 1 YES 3
Interconsultation NO 0 YES 4
Call Centre NO 0 YES 3
Virtual Conference NO 0 YES 4
PHR YES 1 YES 3
Nurse Information System
(record of nursing care) NO 0 YES 2
Educational Platform NO 0 YES 3
Collaborative Platform NO 0 YES 3
Telemonitoring NO 0 YES 4
Multichannel Centre (Management Telecare Programs) NO 0 YES 3
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 49 of 106 Public
4.3.2 CareWell IT architecture
As Lower Silesia currently does not have many IT systems implemented to support the
delivery of care or share information, both CareWell pathways will be significantly improved with the proposed ICT-enabled services and functionality.
The development of a platform to provide interoperability between the different IT
systems used in primary and secondary care will enable information to be shared
between the different care practitioners and patients.
Figure 23: CareWell IT Architecture Lower Silesia
New systems or new functionalities
Registration of patient referrals for home care telemedicine (TOP). This is the first
task in the process of LSV teleCare.
Logged user access in Information Portal to Integration Platform.
Patients Registry Update Service in HIS by Integration Platform.
Service of research results transfer by HIS Patient Portal to Integration Platform.
Registration of performed patient results in HIS Portal.
GPs access to EHR and their own tasks supporting the process of LSV teleCare
procedure.
Nurses access to the EHR, and their task of process that supports the LSV teleCare
procedure.
Patients access to their own PHR tasks supports the process of LSV teleCare
procedure.
Implementation e-Prescription in SIM (P1) during the LSV teleCare procedure.
Call Centre staff access to their own tasks supporting the LSV teleCare procedure
process. Receive e-mail and SMS alerts.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 50 of 106 Public
Doctor, nurse and patient access to the Information and Education Portal.
Call Centre staff access to the Information and Education Portal.
Some of the developments and changes will revolve around the new interoperability platform Integratis.
4.4 Veneto
4.4.1 CareWell service specification
Stable Patients – out of hospital care
The service model underpinning the multi-disciplinary care pathways already
implemented in Veneto will be further enhanced in the following ways through CareWell:
An online patient’s ‘dashboard’ will be created; it will bring together the relevant
information from health and social care records, home-care service records, and
hospital records. This ‘dashboard’ will be accessible to all care practitioners involved
in a patient’s care through a role-based access model.
The care pathway data collection that informs the multi-dimensional assessment
will be enhanced through the patient ‘dashboard’.
Home-care nurses will provide a monitoring service to patients; the information will
be shared with relevant healthcare practitioners via the Territorial ICT system.
The home-care nurses will provide a telemonitoring service responding to patients
entering their physiological measurements and symptom management
questionnaire answers into the system.
The home-care nurses’ monitoring systems will include educational material to
assist the patient to self-care and self-manage.
In addition to the educational material available in the monitoring system, web-
based material will be available through the ULSS 2 authority website.
Patients will be able to access the interactive portal within the ULSS 2 website,
where they will be able to provide and receive information about their health and wellbeing, search for some information in their health reports, and download results
of tests and investigations and book appointments.
The Territorial ICT system will facilitate the sharing of information, care plans,
patient monitoring measurements and self-management materials with all those in the care team.
Unstable Patients – out of hospital care
All the above functionality and enhancement to the service model will be available for the
‘unstable’ patient. Any deterioration in the patient’s condition should be able to be
responded to more appropriately as there will be much greater near-time information available to the relevant care practitioners. In addition, telemonitoring will allow
patients, assisted by a nurse, to receive a teleconsultation with the specialist if
necessary.
Inpatient - hospital care
Hospital healthcare professionals will have access to the patient ‘dashboard’, and should
improve the information supporting decision-making in assessing and drawing up the
care plan for the patient.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 51 of 106 Public
Inpatient – hospital discharge preparation
The availability of the home-care nurses monitoring and telemonitoring services will
facilitate the hospital discharge of a patient. In addition, the continuity of care across the different care sectors will be improved through the implementation of the patient
‘dashboard’ and consistency in education material to support the patient to self-care and
self-manage.
Table 11: Evolution of ICT-enabled services in Veneto
Veneto Before After
ICT-enabled service Operational
Maturity
level Operational
Maturity
level
e-prescription YES 5 YES 5
Messaging clinician Patients NO 0 NO 0
EHR YES 1 YES 4
Interconsultation NO 0 YES 4
Call Centre NO 0 YES 3
Virtual Conference NO 0 YES 4
PHR NO 0 YES 3
Nurse Information System
(record of nursing care) NO 0 NO 0
Educational Platform NO 0 YES 4
Collaborative Platform NO 0 NO 0
Telemonitoring NO 0 YES 4
Multichannel Centre
(Management Telecare Programs) YES 5 YES 5
4.4.2 CareWell IT architecture
The most important challenge for Veneto pilot during CareWell is the integration the EHR
in primary and secondary care. This integration is possible thanks to extending the use of
Territorial Information System to secondary care.
This challenge is not only the number of users, this challenge represents others problems to resolve such as:
To implement new roles of users.
To share information among services and levels of care;
To develop new interoperability connections.
Major risk of data duplication and incremental cost of support and management.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 52 of 106 Public
Figure 24: CareWell IT architecture of Veneto
The patient empowerment and home-support services pathway will include the following
IT architecture developments:
Develop a personal health folder.
Develop the educational web site.
In order to achieve the integration of the Territorial Information System at all clinical
levels, the Veneto Pilot will use Mirth Connect, a cross-platform HL7 interface engine that
enables bi-directional sending of HL7 messages between systems and applications; it
allows interoperability between health systems. In addition, there are some applications that use ESB (Enterprise Service Bus), that is an open source solution, but it has been
customised by the providers, and it is thus proprietary software.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 53 of 106 Public
Figure 25: Veneto Territorial Information System
4.5 Puglia
4.5.1 CareWell service specification
CareWell will facilitate the development and implementation of additional care pathways
for chronic diseases.
Stable Patients – out of hospital care
CareWell will facilitate the development and implementation of additional services for chronic diseases. Therapeutic recall to improve adherence will be provided together with
educational services that can be accessed by patient from a web based platform (Nardino
enhancement). Patients will be cared for in a more integrated way by their GP in
collaboration with nurses and specialists in outpatient clinics who can share information through the EHR. Specialists will be involved in sharing information through EHR and to
consult and update patient's information in EHR. Messaging and picture sending service
(8 a.m. – 8 p.m.) between informal care giver and Care Manager will be put in place
according to a protocol. This can be useful to support the patient in self-care and self-
management, particularly in relation to recognising symptom deterioration or improvement, clarification on medications, etc., as well as e.g. monitoring wound
healing, say a diabetic ulcer.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 54 of 106 Public
Unstable Patients – out of hospital care
As with the stable patient, a patient considered to be ‘unstable’ will be cared for by the
same team, and will benefit from the same new services mentioned above, with an increased frequency of delivery, needing additional monitoring and assessments,
frequent adjustments of therapy, or additional counselling. In addition, additional
services specified below will be implemented:
Each health professional involved in delivering the care and support of the care plan, thanks to his own log-in profile, can join a virtual ‘community of health
professionals’ using the online platform to discuss specific clinical problems of their
patients.
Each professional engaged in a patient’s clinical management will participate in periodic and planned briefings via videoconference to assess the general clinical
status of patients, according to a specific protocol agreed with the quality team.
Home monitoring will be introduced to measure blood pressure, weight, oxygen and
glucose in blood, from devices used by the patients in their homes, interfaced to
the Nardino software. All clinical measurements will be uploaded to the EHR.
Additional consultations / advice through the EHR will be provided according to a
defined protocol in response to alerts generated from the telemonitoring
technologies.
Inpatient - hospital care
When an ‘unstable’ patient is unable to be managed at home through the integrated care
pathway in primary care, the GP or specialist will refer the patient to the hospital for an
admission. When a patient is admitted to a reference hospital, the EHR information will
be available to the healthcare practitioners involved in CareWell; this should improve decision making and inform the assessment and care planning process. The integrated
care pathway will be enhanced with a more active specialist participation (even the
hospital specialist). They will be able to refer a patient who has been admitted to
hospital inappropriately to the primary care team, suggesting home telemonitoring, as this has the potential to increase the patient’s confidence to self-care and self-manage,
and provide the primary care team with additional information for decision support in the
event of a patient reporting deteriorating symptoms.
Inpatient – hospital discharge preparation
The stabilised patient is discharged from hospital back to his home. Hospital specialist entrusts the patient to territorial Care Manager, and clinical information for the territorial
care team is provided by EHR. Services for stable patient as above will be provided.
Below is the summary of ICT-enabled services which will be implemented within
CareWell:
Table 12: Evolution of ICT-enabled services in Puglia
Puglia Before After
ICT-enabled service Operational
Maturity
level Operational
Maturity
level
Messaging clinician Patients NO 0 YES 4
EHR YES 3 YES 4
Interconsultation NO 0 YES 4
Call Centre NO 0 NO 0
Virtual Conference NO 0 YES 3
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 55 of 106 Public
Puglia Before After
ICT-enabled service Operational
Maturity
level Operational
Maturity
level
PHR NO 0 NO 0
Nurse Information System YES 4 YES 5
(record of nursing care)
Educational Platform NO 0 YES 4
Collaborative Platform YES 3 YES 4
Telemonitoring YES 2 YES 4
Multichannel Centre NO 0 NO 0
4.5.2 CareWell IT architecture
Below is the CareWell IT architecture of Puglia, illustrating the communication exchange and information flows:
Figure 26: CareWell IT Architecture of Puglia
New systems or new functionalities
During the CareWell implementation, the CARE Puglia Program platform will be enhanced
to support new service delivery; and will undergo many technical adaptations.
A new clinical profile will be created to allow specialists to access the EHR and share information with the Care Manager and GP. A new user role will be defined giving them
the possibility to update information on patients and consult information uploaded from
other members of the care plan. The platform is fully compliant with DICOM 3.0
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 56 of 106 Public
standard, so CARE Puglia software will integrate with PACS for management of all forms
of diagnostic imaging to implement specific work flow or process a second opinion, or in
general, to support specialised activities.
Technological adaptation will be provided to create an interface between the
telemonitoring device hub software (at patient’s home) and Care Puglia software and to
create conditions for platform to receive clinical parameters from home monitoring;
platform adaptations are also necessary, and they will be provided to send therapeutic recalls toward HUB; it will also be enhanced to support the release of educational tools
for patients and their informal caregiver (by their own PC), and to upload images coming
from messaging service between patients and Care Manager. Technical interventions
both on platform and Hub software will be set to create warning on the platform from out-of-range clinical parameters revealed by home devices.
4.6 Wales
4.6.1 CareWell service specification
Stable Patients – out of hospital care
The care pathway and service model for ‘stable’ patients living with complex needs will
be enhanced through the following ICT functionality and associated new ways of working:
MSDi case finding tool to target CareWell service at patients most likely to benefit.
Access to the Individual Health Record (IHR) for community nursing and therapy
staff through TotalMobile.
Video conferencing communication within the community nursing team through
Microsoft Lync.
Community nursing team able to access the GP EHR to record contacts,
measurements taken, and care given.
Comprehensive directory of health and wellbeing services available for patients in
Powys through the Info Engine.
Community nursing team will provide a telemonitoring service in response to
patients taking and uploading their own physiological measurements at home.
GP practice websites to include chronic conditions management educational content
to support patients to self-care and self-manage.
Patients will have access to My Health Online where they will be able to view a
subset of their GP EHR, book GP practice consultations, order repeat prescriptions,
and update their demographic details if necessary.
Unstable Patients – out of hospital care
All of the above functionality will be available to support improved team working and response services for patients who experience a deterioration in their health and
wellbeing.
Inpatient - hospital care
Healthcare professionals in the community hospitals will have richer information to understand the nature of a patient’s deterioration leading up to their emergency
admission, including telemonitoring information and any symptom management
questionnaire responses. It is likely that the acuity of patients requiring hospital
admission will increase, as more patients are able to be managed by telemonitoring and support in their own homes for minor exacerbations.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 57 of 106 Public
The use of TotalMobile and Microsoft Lync by the community nursing team will facilitate
improved communication between the team and community hospital staff.
Inpatient – hospital discharge preparation
The availability of the community nursing team’s telemonitoring service will facilitate the
hospital discharge of a patient. In addition, the patient will be signposted to the relevant
chronic conditions management educational content on the GP practice website, and any
additional support services available from searching the Info Engine.
Below is the table of CareWell ICT-enabled services:
Table 13: Evolution of ICT-enabled services in Wales
Wales Before After
ICT-enabled service Operational Maturity
level Operational Maturity
level
e-Prescription YES 5 YES 5
Messaging clinician Patients NO 0 YES 5
EHR YES 5 YES 5
Interconsultation NO 0 YES 2
Call Centre YES 2 YES 2
Virtual Conference NO 0 YES 5
PHR YES 4 YES 5
Nurse Information System (record of nursing care) YES 2 YES 2
Educational Platform YES 2 YES 4
Collaborative Platform YES 3 YES 5
Telemonitoring NO 0 YES 4
Multichannel Centre
(Management Telecare Programs) NO 0 NO 0
4.6.2 CareWell IT architecture
The most significant changes in the IT architecture will be those to deliver the patient
empowerment and home-support services pathway.
Changes or new systems (pathway empowerment and home support):
Access mobile to EHR app: The current and newly developed systems will be
adapted to run on mobile devices such as Smartphones and tablets for the district
and specialist nurses to use when the make visits to patients’ homes.
Implement a telemonitoring service.
Develop a single database with social and clinical information for community
services which is currently undergoing a national procurement.
Educational materials and information available on GP practice websites.
Below is an illustration of the CareWell IT architecture to be implemented in Powys:
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 58 of 106 Public
Figure 27: CareWell IT Architecture of Wales
The integrated and coordination services pathway will be enhanced in the following ways:
Implement Interconsultation message (referrals) through EHR between clinicians.
Implement live communication tool between community nurses and GP.
Implement videoconference.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 59 of 106 Public
5. Guidelines to achieve interoperable and efficient IT systems
5.1 Guidelines for the development of interoperable systems
In order to effectively provide integrated care services, it is necessary to be able to share
information between the various stakeholders. Over many years, the healthcare organisations in the CareWell pilot sites have implemented a variety of IT systems to
provide business and clinical care functionality in the different care settings, but the
extent to which data and information stored in these systems is shared with other
systems and users is variable.
There are two distinct terms used to describe ways of sharing information electronically:
Systems integration.
Systems interoperability: The IEEE defines interoperability as the ability of two or
more systems or components to exchange information and to use the information
that has been exchanged.
Systems integration is the common solution when two or more systems are not
interoperable. Several cases to implement this solution are:
Legacy systems where database technology does not allow access to data for
sharing with other applications.
Legacy systems where it is not possible develop processes to use data from other
applications.
In cases of developing new systems, the normal guidelines include the major
functionalities and services in the same application (services provided at the moment by others applications).
In any of these three cases, and especially in the last, the trend is the creation of the
integrated system needed and the provision of the technology required to turn it into an
interoperable system, and therefore able to share information to provide benefits such
as:
Easier functional scalability.
Single storage for data (avoiding data duplication).
Decrease of systems maintenance costs.
Improving the performance of applications due to interoperable systems displaying information in a more structured and easily readable way.
Re-use of resources.
Standardisation of new developments (reducing costs).
5.1.1 Levels and environments of interoperability
To achieve strong interoperability among systems, we should achieve an optimum level of three interoperability levels: Syntactic, Semantic and Organisational.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 60 of 106 Public
5.1.1.1 Syntactic interoperability
If two or more systems are capable of communicating and exchanging data, they are
exhibiting syntactic interoperability. Specified data formats, communication protocols and the like are fundamental. XML or SQL standards are among the tools of syntactic
interoperability. This is also true for lower-level data formats, such as ensuring
alphabetical characters are stored in a same variation of ASCII or a Unicode format (for
English or international text) in all the communicating systems.
Syntactical interoperability is a necessary condition for further interoperability.
5.1.1.2 Semantic interoperability
Beyond the ability of two or more computer systems to exchange information, semantic
interoperability is the ability to automatically interpret the information exchanged
meaningfully and accurately in order to produce useful results, as defined by the end users of both systems. To achieve semantic interoperability, both sides must use a
common information exchange reference model. The content of the information
exchanged must be unambiguously defined: what is sent is the same as what is
understood.
In the field of health information, achieving semantic interoperability is even more
important and difficult.
Semantic interoperability has two subparts:
Overall semantic interoperability implies the ability to communicate with other systems and interpret information from these correctly. This is possible thanks to
the application of standards to define concepts (content) and logical rules.
Distributed processing is the most common form of semantic interoperability.
This implies that systems are implemented to meet standards to communicate and
interpret information that are not able to make logical deductions. These systems implement a rigid set of standards for information exchange which cover, by prior
arrangement, what information is exchanged, how and in what format, among
others. The name refers to distributed processing of the information generated in a
system that communicates with another to generate some kind of result value. Changes in the exchanged messages often require changes to software, which is
clearly not desirable.
The main objective is to achieve semantic interoperability, because it has a direct impact
on the daily work of health professionals and citizens; this interoperability makes it possible to exchange and use information. This interoperability has two levels:
1. Semantic interoperability for viewing: Viewing information is the most common need
of health information systems, because often the information held in one system
needs to be viewed in another. For example, the results of laboratory tests need to be
viewed in an EHR system.
For the correct interpretation of information displayed in a different system, there are
three main aspects to consider:
How to display the information.
How the user is accustomed to see the information.
What device is used to view the information?
2. Semantic interoperability for processing. The automatic processing of information is
one of main principles of IT, and one of processes that improves the value of health
IT. The objectives of automatic processing of information include:
Quality assessment: correction and completeness of information.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 61 of 106 Public
To calculate indicators, percentages, durations, etc.
To look for information of patient: bibliography resources, etc.
Derivation: analysis to find new information from the current system.
Decisions support, validations secure card, rules evaluation, alarms, etc.
Processing, consolidation, communication and storage.
To achieve automatic processing of information, this information should be correctly
structured.
5.1.1.3 Organisational or business interoperability
To achieve such interoperability, business process rules must be specified together with
actors involved. Defining business rules requires analysis of various areas within an
organisation (emergency, inpatient, outpatient, laboratories, pharmacies and others),
their needs, their structure, their responsibilities and their products. The only way to have a clear vision of the entire organisation is through formal definition of its
components and the information they generate and consume. The same concept can be
applied to the health system as a whole, with its components (actors), rules (laws), goals
(welfare, trainers, research and regulators) and the interdependencies between them.
5.1.2 Standards
The need for interoperable systems is evident in every part of health sector
organisations, as effective delivery of healthcare requires a constant exchange of
information among health professionals, including service institutions, insurers and
government, between medical staff and patients, between auxiliary imaging systems and laboratories, with electronic medical records systems and between public health systems,
just to mention some interactions.
Consequently, effective communication between these actors requires a common
framework that allows interaction and coordination of care sharing. The framework is provided by the standards, which provide uniformity in the name of the components of
the health system, whether diagnoses, people, procedures, interventions, and how it is
transmitted, to ensure that data in one part of the system health are available and have
meaning not only through the variety of clinical settings and public health but also administratively.
In Figure 28 we have a map with the most common standards and protocols (grouped by
areas). These standards can be considered as an infrastructure of every IT system which
interchanges data with other systems.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 62 of 106 Public
Figure 28: Standards v. interoperability levels
The importance of this schema is to visualise that the use of a single standard is not enough to achieve the different types of interoperability; it is necessary to look for
additional standards and with different foci, which together enable communication and
use of information.
Effective use of information through a set of information systems is not achieved only
with the pact that the systems can communicate; this is not possible even if the same standard of communications used. This problem is inherent in the information itself, as
well as the way it is obtained, processed and stored.
Therefore, for effective interpretation and processing of information it is necessary to
apply standards that allow representation of the context of information. Below is a brief description of the standards presented in the map in Figure 28, which are organised by
foci or areas of application, its aims and relations it performs.
Communication infrastructure: In this area are the standards and protocols that enable
physical and logical communication between computers and networks.
Protocols that underlie the Internet are listed (Interoperability Toolkit (ITK) of the
National Health System (NHS) in the UK).
Ethernet is a protocol link layer (layer 2 Open System Interconnection model or
OSI) that allows two devices connected via a link (cable) data exchange higher layer protocols.
TCP / IP protocols are the most used in the world. TCP is a transport protocol (layer
4 of the OSI model) that allows you to create logical connections over an IP
network between two physically distant computers. IP is a network layer protocol
(layer 3 of the OSI model). These protocols enabled the implementation of Internet.
The following topics related to standards are discussed in more detail in Appendix B:
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 63 of 106 Public
Communication Protocols (general applications).
Syntax standards.
Format Specification.
Services Specification.
Process Specification.
Communication Protocols (Health applications).
Terminology and health nomenclature.
Clinical documentation.
Models of information.
Architecture of communication.
Knowledge models.
5.2 Interoperability Tools in CareWell pilots
This section describes at the level of implementation the interoperable tools in CareWell pilot, focusing on two points:
What interoperable platform is used by the pilot?
What standards are used in the CareWell systems?
5.2.1 Basque Country
Interoperable platform
Basque Country has addressed its interoperability policy to SOA (Service Oriented
Architecture). Central to this architecture is the deployment of a commercial bus service
(oracle Service Bus). Currently the Basque Country has deployed around 300 web
services to share clinical, demographic and administrative information among corporate systems.
The main applications to provide web services are:
E-Osabide : Hospital Information System (Administrative Tool).
SAP: Commercial tool for management of financial and RRHH.
CRM: Web services for Telecare and telemonitoring.
Presbide: e-Prescription system.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 64 of 106 Public
Figure 29: Interoperable platform
Standards Used in CareWell system
Below is a table which describes the standards used in the Basque Country pilot site.
Table 14: Basque Country standards used
Application Semantic
standards
Syntactic Standards Organisational
Interoperability
e-Prescription LOINC, ICD 9/10 HL7, xml, http, https, SOAP CDA1,
Osabide AP ICD 9/10 DICOM, html, http, https,
XML, FTP
CDA1
Osabide Global ICD 9/10 HL7, DICOM, xml, http,
https, ftp
CRM LOINC, ICD 9/10 xml, pdf, Cades, DICOM,
HL7, SOAP
PHR https, PDF, HL7 CDA1
Educational
Web
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 65 of 106 Public
5.2.2 Croatia
Interoperable platform
Croatia pilot has not deployed any interoperability platform. The single system for interconnecting systems or providing access to clinical data in secondary care from
primary care IT systems is a VPN connection.
Standards Used in CareWell system
Below is a table which describes the standards in use in the Croatia pilot site:
Table 15: Croatia standards used
Application Semantic
standards
Syntactic Standards Organisational
Interoperability
EMH LOINC, ICD 9/10 HL7v3, HL7v2, XML, SOAP,
HTTPS
CDA1, Digital
Signature
5.2.3 Lower Silesia
Interoperable platform
Wroclaw pilot has a bus service in every hospital used for interoperability of legacy
systems with HIS.
Standards Used in CareWell system
Below is the table containing the standards used in the Lower Silesia pilot site:
Table 16: Lower Silesia standards used
Application Semantic
standards
Syntactic
Standards
Organisational
Interoperability
Mobile ICD9/ICD10 XML / HTML Dictionaries, HL7
Web ICD9/ICD10 XML / HTML Dictionaries, HL7 not yet
implemented
Client/Server ICD9/ICD10 XML / HTML Dictionaries, HL7 not yet implemented
Communicator Not referred Not referred Not referred
5.2.4 Veneto
Interoperable platform
The Local Health Authority uses Mirth Connect, a cross-platform HL7 interface engine that enables bi-directional sending of HL7 messages between systems and applications; it
allows interoperability between health systems. In addition, there are some applications
that use ESB (Enterprise Service Bus); this is an open source solution, but it has been
customised by the providers and is thus proprietary software.
Standards Used in CareWell system
Below is the table containing information on the standards used in the Veneto pilot site:
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 66 of 106 Public
Table 17: Veneto standards used
Application Semantic
standards
Syntactic
Standards
Organisational
Interoperability
e-Prescription/ GP and
Pharmacy’s software
LOINC, ICD 9/10 HL7, xml, http,
https, SOAP
CDA2, IHE
web site html, http, https
Regional Tele-emergency Solution
HL7, DICOM, xml, http, https, ftp
e4cure and Talete LOINC, ICD 9/10 xml, pdf, Cades,
DICOM, HL7, SOAP
IHE
5.2.5 Puglia
Interoperable platform
Puglia has an open source interoperability platform.
Standards Used in CareWell system
Below is the table containing information on the standards used in the Puglia pilot site:
Table 18: Puglia standards used
Application Semantic
standards
Syntactic
Standards
Organisational
Interoperability
CARE Puglia Program SOAP WSDL XML ebBPSS
5.2.6 Wales
Interoperable platform
Powys (Wales) has an internal interoperability platform (WCCG).
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 67 of 106 Public
6. Security and confidentiality of data This section describes the elements, tools and processes required for data security
management. For this purpose, three principal aspects are considered:
1. Identification, authentication and authorisation of persons and devices: this aspect
ensures that all system users, no matter what device they use, are able to be identified and given the appropriate level of access to only the information that is
relevant for that defined role.
2. Security of stored and exchanged data: all information shared electronically and
stored in IT systems must comply with legal and ethical legislation and guidance.
The level of security varies for example, according to who the exchange is between, whether the information exchange is person identifiable, contains any sensitive
information, encryption regulations and patient consent.
3. Establishment of guidelines, standards and best practices to ensure effective
management of risks and threats: in order to ensure the security of health information systems and communications, appropriate regular audit processes should
be implemented, and immediate steps taken to rectify any threats and breaches,
together with remedial action to minimise future breaches in security and
confidentiality of patient-held data.
The next sub-sections detail how the above three key aspects of security and
confidentiality of data are approached in each pilot site.
6.1 Basque country
Identification, authentication and authorisation of persons and devices
The Basque Health Service is gradually adopting a policy-based user management
identity management and access through SSO (single sign on), so that once the user is authenticated in the OS of their computer, the system operative in charge of passing
credentials matches the user identity to each application that is incorporated in the
system. This process is underpinned by role-based access protocols.
To support this, Osakidetza has a centralised system and an active user directory system, not only for professionals but also other staff with access to the system.
The e-Prescription and the PHR systems in Osakidetza use an electronic personal
certificate, with e-Prescription also including a secure electronic signature for
prescriptions through PKI architecture.
Security of stored and exchanged data
In Osakidetza there are two levels of security implemented, depending on whether the
data is being exchanged between internal or external systems. If the exchange includes
external systems, all communication of data is secured through the use of HTTPS (HTTP
over SSL or HTTP Secure). Information and data exchanged between internal systems is secured through the individual and role-based identification and authentication process.
In addition, Osakidetza has other tools implemented to protect their communications
such as the demilitarised zone (DMZ).
The diagram below shows the secure architecture for external communications:
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 68 of 106 Public
Figure 30: Secure architecture for external communications
To ensure secure storage, security protocols for Osakidetza demand making incremental
backups every day. These backup copies are stored in a different location to cpd.
Actions for effective management of risks and threats
Preventive Actions (Audit systems): An audit system is implemented as a
preventive action. In the Basque health service, the systems which manage data
with a high level of security implement audit systems supported by a basic server log that has information on user actions and activities: user, role, and time of
access.
In addition, Osakidetza uses ORACLE databases that can allow auditing of the
activities, depending on the edition of the database.
Reactive Actions: There is a system to monitor the network against external attacks in operation every day. There is also a document with all necessary protocols and
processes to execute in case of external attack.
6.2 Croatia
Identification, authentication and authorisation of persons and devices
Users
CareWell systems implemented are:
G1: Different levels of security including physical access control, private networks,
network data encryption, as well as smart card authorisation allowing access of G2
applications to central system.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 69 of 106 Public
G2: Smart card authorisation for each user, https, private networks (there are
several G2 market app).
Ericsson Mobile Health: This system is protected with user name / password secure access for each user on web application and Android device.
Devices used and connections with back-ends
The communication between the Android devices and the back-end system uses HTTPS
protocol and encrypted communication channel by SSL.
Security of stored and exchanged data
All clinical reports providing clinical data, which are reported to G1, are digitally signed.
Digital signature is provided with the same smart card used for secure access using the
e-health national PKI infrastructure.
The system is shown in the figure below.
Figure 31: PKI infrastructure e-health in Croatia
Regarding stored data, data is stored in two separate databases on the back-end system;
one includes patient demographic information, and the other contains anonymous clinical
data and measurements. Once the authorised user signs in with username / password, a
patient's name is related to a specific set of medical data (measurements, questionnaires, etc.). Security data backups are made on a regular basis to protect data
from being lost. In addition, a redundant EMH server is used to secure service delivery
continuity.
In addition, system data transmission channels in Ericsson Mobile Health are protected at
four levels in Ericsson Mobile Health:
Medical Sensors -> Gateway
Standard Bluetooth authentication (PIN based).
Gateway -> Back-end Server
HTTPS protocol.
Back-end server
Physical separation of data.
Session and Role-based security.
Back-end server -> Web application
HTTPS protocol.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 70 of 106 Public
Figure 32: Layers of security communication channels Croatia pilot
Actions for effective management of risks and threats
Preventive Actions (Audit systems): An audit system is implemented as a
preventive action. In Croatia, the EMH system has a basic server log that has
information on user actions and activities: user, role, and time of access.
In addition, the EMH uses MySQL database that can allow auditing of activities,
depending on the edition of the database (Enterprise edition has auditing features). For the CareWell project, MySQL Standard edition will be used which does not allow
for auditing.
Reactive Actions: A monitoring system against external attacks is deployed and
tested in both provider and client environments. The system is secured in the intranet, and entry is protected by a firewall. The back-end system only accepts
connections from registered devices on particular ports. In addition, restoration of
the database is initiated when a corruption is identified (for this action, MySQL
workbench tool is used).
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 71 of 106 Public
6.3 Lower Silesia
Identification, authentication and authorisation of people and devices
Users
Managing access to the application in the CareWell monitoring system (LSV) will be based on user / password.
Devices used and connections with back-ends
Devices use the Bluetooth connectivity protocol.
Security of stored and exchanged data
Sensitive data will be stored on the server in the organisation that owns the data
(hospital); for databases containing sensitive data, secure backup copies will made every
day.
In the data centre, backup copies are made in full: –daily, incremental –weekly and
monthly scheduled.
Lower Silesia secures the data transmission channels by SSL (https). The diagram below
illustrates the security channels architecture. In the data centre, the data transmission
channels are protected by SSL certificate; access to resources is also carried out by VPN.
Figure 33: Security architecture of data transmission channels in Lower Silesia
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 72 of 106 Public
Actions for effective management of risks and threats
Preventive Actions (Audit systems): The Lower Silesia Integration platform, which
implements the procedure for telemedicine and telecare services, will keep a log file in a database recording the following data on the operations performed on the
system: who?, when? and what kind of operation was performed? This will include
the login to the application.
Reactive Actions: In the data centre, there is a full system backup, which allows data to be restored after a loss or malfunction. The CareWell monitoring system
integrator will develop a procedure for restoring databases after a crash.
In relation to monitoring systems against external attacks, the hospital policy is based
on:
Accessing the WAN (Internet) is possible for staff only; patients do not have access
to internet.
Local Area Network is protected against intrusion from the network (wide) external
using hardware firewall in the main router (model VIGOR 2910G).
Firewall allows filter packets (SPI), call filter, data filter, protection against DoS /
DDoS filter, IM / P2P filter, URL content filter and Web content filter.
In order to reduce the possibility of infecting computers in the local network by
viruses, and to protect against unauthorised access and minimise risk, professional
firewall software (firewall) and professional anti-virus program are used on each computer; the server at the hospital has ESET Smart Security Software.
The data centre has a Cisco IPS and IronPort system.
6.4 Veneto
Identification, authentication and authorisation of people and devices
Table 19: Veneto kinds of secure access
App Secure access Kind of secure access
ePrescription/ GP and Pharmacy’s
software
Yes user/password
web site Only for some services
like reports download
user/password
Regional Telemergency Solution Yes user/password
Territorial Information System Yes user/password
e4cure and Talete Yes user/password
ACG and Qlickview Yes user/password
App7 Yes User/password
Users
Referring to CareWell systems, the services that are already implemented are:
ePrescription
The prescribing physicians authenticate themselves on a security infrastructure
created at regional level. The architecture uses federated authentication. All actors
authenticate themselves to services through a system of identity management,
located in all local health authorities of Veneto region. The system of access is
declined in two levels. The authentication in the system takes place through
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 73 of 106 Public
username, password and software certificates; as a result of this authentication
process, a token is issued that allows access to service and delivers all useful
information. This token has a period of validity.
Telecare
Patients have an emergency button to communicate through E.R. Social assistants
of Local Health Authority have username and password to access database in which
there is all information about patients who have this service (https protocol).
Medical interconsultation
This service allows consultation between specialists. Physicians access the software
through username and password, and can see clinical reports and patient data
carried by other specialist in accordance with Italian privacy law. The information sharing is within the LAN of the Local Health Authority so data are protected from
external attacks.
Devices used and connections with back-ends
The CareWell system devices that will be used by nurses when delivering services at the patient home are: portable ECG, oximeter, portable glycosylated haemoglobin device,
portable spirometer, and portable blood gas analyser, tablet/PC, webcam digital camera.
The connection for the import of data from devices to ICT system will use bluetooth, wifi
or USB protocol depending on the technical features of the specific device. For the
telecare service, patients have an emergency button which communicates with E.R. through the PSTN (Public Switched Telephone Network).
Security of stored and exchanged data
In Veneto, the following reports are signed: emergency reports, hospital discharge
reports, anatomical pathology reports, radiology and laboratory analysis reports, and discharge summaries.
Systems of Veneto pilot do not store sensitive data in devices; this data is stored only in
the server of local health authority of ULSS N.2; the data backups are collected every
day.
The Local Health Authority has different procedures to protect data transmission. The
transmission in the LAN is protected from external attacks through firewall, proxy and
antivirus. There are dedicated transmission channels in which operators access through
specific tools such as VPN and https protocol.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 74 of 106 Public
Figure 34: Security architecture of data transmission channels in Veneto
Actions for effective management of risks and threats
Preventive Actions (Audit systems): There is an appliance that records all access by
system administrators to various servers. Each application has its own log of
activities (log in dates, log out dates). For ePrescription service, the system records
authentication logs (user name, ID software, log in dates).
Reactive Actions: In case corruption or failure of database, the backup systems allow the recovery of the clinical data and reports. This process of backup / restore
is made by a system provider. To protect the systems against external attacks,
there is an Intrusion Prevention System (IPS) and an Intrusion Detection System
(IDS) which highlight and store anomalies in network traffic in the firewall. In addition, there is an active control on the availability of the systems that forwards
alarms if the systems are not available.
6.5 Puglia
Identification, authentication and authorisation of people and devices
Users
In Puglia, the applications use user / password authentication, while some systems use
CNS via digital certificates.
Devices used and their connections with back-ends
Clinical data will flow from wireless medical devices (weight scale, blood pressure and
glucose monitor, pulse oximeter) to a hub via bluetooth connection; data will flow from the hub to the web platform via 3G (mobile network) or landline phone connection.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 75 of 106 Public
Security of stored and exchanged data
In the Puglia pilot, the data will be stored on a central server. Care Managers, GPs and
authorised data manager (DBA, data base administrator) have access to it. All accesses are controlled by ID and password from Care Managers and DBA (weak authentication),
and by CNS (strong authentication via digital certificate) from GPs. To guarantee the data
stored on the central server, IT Puglia make two kinds of data backup:
Weekly backup (complete backup).
Daily backup (incremental backup).
In relation to the security of the data exchange channels in Puglia, the access to data
takes place from workstations connected to RUPAR, the public administrations network of
Apulia region, or from mobile stations by encrypted VPN. Access to data is controlled by ID and password, or digital certificates on smart cards. National certification and
registration Authorities guarantee traceability and legal non-repudiation of access (for
strong authentication). Encrypted data will be transferred to authorised partners for
processing and analysis; communication of results will be anonymous and macro aggregated.
Actions for effective management of risks and threats
Preventive Actions (Audit systems): In Puglia, systems for auditing access are
available. A database register of accesses tracks what, when, from which client the
access is undertaken.
Reactive Actions: In case of corruption, data will be taken from the daily and
weekly backup. Fault tolerance procedures (redundant storage and redundant
disks) are available. Moreover, the IT architecture has a CISCO CCNA certification
in each procedure.
6.6 Wales
Identification, authentication and authorisation of people and devices
Users
Users of CareWell systems use user id / password to access systems.
Devices used and connections with back-ends
The devices use wifi or LAN connections to transfer data to the back-end.
Security of stored and exchanged data
File storage:
Network storage on Microsoft domain.
Password protection using active directory.
SQL servers, firebird servers, and oracle servers.
Transmission of data:
WAN/LAN networks.
NWIS secure file sharing portal.
NHS.net.
MS Lync.
VPN.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 76 of 106 Public
Database backup is assured through a number of measures to safeguard information
stored in systems on Health Board networks. Where data is stored in remote locations,
such data will be replicated back to a central data store. Shadow copy functionality is enabled on file stores to enable easy end user recovery of data. Access to such
information will be accessed via DFS shares to enable easy switch over to alternative
physical storage with minimal interruption to service. Data is backed up from replicated
data storage to backup to disc storage. Those backups will also have offsite data stores and physical tape storage for weekly backups. Backup processes will also enable the
complete virtualised servers to new hosting hardware where deemed appropriate.
Regarding protection of data transmission channels, the network hardware will be housed
in suitably secure environments. On hospital sites, these may be restricted access locations with a locked data cabinet housing the equipment.
Critical systems will be held in secure hosting environments. These rooms will be secured
against unauthorised access with appropriate entry controls and intruder detection
systems where necessary. They will also have a number of environmental controls covering fire suppression, power, and air conditioning, as necessary.
UPS devices will be provided following an assessment to ensure equipment is powered
during switchover to generator cover.
For authentication, the network will use RSA SecurID tokens. Authorised users will be
supplied with a unique user ID, a PIN and the token. The PIN and number displayed on the SecurID token forms a one use only password (the SecurID token number will
change very minute). The user account will be disabled after three failed attempts.
Actions for effective management of risks and threats
Preventive Actions (Audit systems)
The IT Operations Department will manage the Health Board’s information assets to
minimise risks to data and systems.
Computer systems will be configured with protection software and standard policies.
These will be designed to restrict access to systems and to monitor for unauthorised access.
Systems will be maintained to the latest approved standards to protect against software
bugs that could be used for unauthorised access.
A number of network management systems will be used to proactive monitor and
manage the data networks to identify risks or unauthorised access.
Audit processes will be undertake to ensure user access is appropriate to need, and
removed when no longer required.
Reactive Actions
With regard to active reactions in case failure database or system, there is provision of multiple proxy servers with failover provision to support access to internet resources,
together with a number of domain controllers to facilitate rapid authentication of users
onto the network. Major sites are provided with file servers that provide local file storage,
computer address provision, printing services. DFS (Distributed File System) is used both as a virtual access point to data, and as a method of replicating data between data
stores. National or regional data centres are used whenever possible to host applications
to reduce dependencies on local data storage; generally the service provision from such
locations will be of an enhanced nature including power provision / security / failover. Applications will be hosted, wherever possible, on virtualised systems to facilitate rapid
changeover to new hosts. Spare network equipment is maintained for emergency swap
out. Standard deployment is used wherever possible to enable users to log into any
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 77 of 106 Public
computer, and to be able to access their applications. Processes are in place to support
rapid deployment of applications.
Regarding protecting systems against external attacks, the Powys pilot site uses a number of applications to monitor networks and end user devices to ensure compliance
with standards, identify issues before they cause major incidents, to enable remote
support and application deployment.
The systems used will include:
Microsoft System Centre to maintain software and hardware asset inventories and
to monitor asset compliance with standards. There is a further role to support the
deployment of applications or updates.
Microsoft Update Services which is used to manage the deployment of security updates to end user devices across the network.
Solarwinds to monitor network performance and to identify performance issues.
Wireless security and monitoring systems.
ePO to manage the security of devices and protect networks from malicious software.
Safend Management Console to manage removable media.
McAfee Endpoint Encryption to protect data storage from unauthorised access.
Mailmarshal service to protect email from messages containing viruses or other
risks.
Webmarshal to monitor and control internet access to minimise exposure to
compromised websites.
Controls through active directory are used to determine what can be installed and
used on computers to increase the security of the network.
Management systems are used to monitor computer systems and to protect them from
malware. The management system will provide updates and configuration changes from
a central location.
Operating System protection such as local firewalls is used to reduce the risks to devices.
Standard policies are applied to computers to restrict the ability to install, run
applications and restrict access to operating system files as appropriate.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 78 of 106 Public
Appendix A: Technological Terms .Net
NET is an integral part of many applications running on Windows and provides common
functionality for those applications to run. This download is for people who need .NET to
run an application on their computer. For developers, the .NET Framework provides a comprehensive and consistent programming model for building applications that have
visually stunning user experiences and seamless and secure communication.
Applet
An applet is a component of an application running in the context of another program, for
example in a web browser. The applet must run in a container, which provides a host program, through a plugin, 1 or applications such as mobile phones supporting
programming model ‘applets’
Unlike a program, an applet cannot run independently, provides graphical information
and sometimes interacts with the user, typically lacks session and have restricted security privileges. An applet normally takes within a very specific function that lacks
independent use. The term was introduced in 1993 in AppleScript
Common examples of applets are Java applets and Flash animations. Another example is
the Windows Media Player used to display video files embedded in browsers like Internet Explorer. Other plugins allow you to display 3D models that work with an applet.
A Java applet is a Java code that lacks a main method, so it is mainly used for work sites,
since it is a small program that is used in a HTML page represented by a small graphic
display within it.
Moreover, the difference between a JAVA applet and application is how to run. To load an
application JAVA interpreter (pcGRASP of Auburn University, Visual J ++ from Microsoft,
Sun Forte Visual Café) is used. Instead, an applet can be loaded and run from any
browser that supports Java (Internet Explorer, Mozilla Firefox, Google Chrome, Netscape
etc).
Call Centre
This is the office where a group of specifically trained people is responsible for providing
some care or telephone service. Importantly, the call centre can be operated by the
company itself or outsourced to an external company. There are companies that are dedicated to establishing call centres (with the necessary infrastructure and trained
personnel) and market such provision. There are essentially two ways you can organise a
call centre: dedicating one or more physical spaces (offices) of their activities,
earmarking a box to each of its employees; hiring people to perform work remotely. The latter is increasingly common, thanks to the amenities offered by Internet, allowing to
constantly monitor via instant messaging systems and send documents containing
relevant information to employees without any delay.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 79 of 106 Public
The main advantage of a call centre to a company is that centralises attention. If you do
not have a call centre, all calls arrive at different offices and be more difficult to decide
how they are channelled and recorded. The call centre, however, is intended solely to facilitate communication. Operators are trained to resolve issues on their own and newly
derived the call to an executive in exceptional cases
Client / server application
A client/server application is a piece of software that runs on a client computer and makes requests to a remote server. Many such applications are written in high-level
visual programming languages where UI, forms, and most business logic reside in the
client application. Often such applications are database applications that make database
queries to a remote central database server (this can, however, get much more complicated than that and involve other communication methods).
This screen shot shows an example of a client /server application running locally on a
computer. This is the same application shown running remotely in some of the Terminal
Server and Citrix screen shots in the previous section.
A client / server application can be cross platform if it is written in a cross platform
language, or it can be platform specific. In the case of a cross platform language there is
an advantage that the application can potentially provide a user interface that is native in
appearance to the OS or platform environment it is running under.
An issue of client/server is that the application must be installed on each user’s computer. Depending on the complexity of the program, the environment it is written in,
and the care the developer took to package the program, this can be as easy as creating
a shortcut to an executable on a shared network drive or it can be as hard as spending
hours installing and configuring runtime software and components on each client computer.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 80 of 106 Public
Client / server applications, either run locally on a client computer or through something
like Terminal Server, Citrix, or VNC, can work closely with the underlying OS to provide a rich, powerful, robust, easy to use interface.
By running locally on a client computer applications can also work with other local
hardware such as scanners, bar code readers, modems, removable media, accelerated
video for multimedia, or 3d video acceleration.
CRM
Customer relationship management (CRM) entails all aspects of interaction that a
company has with its customers, whether it is sales or service-related. While the phrase
customer relationship management is most commonly used to describe a business-customer relationship (B2C), CRM systems are also used to manage business to business
to business (B2B) relationships. Information tracked in a CRM system includes contacts,
clients, contract wins and sales leads and more.
DICOM
DICOM (Digital Imaging and Communication in Medicine) is world renowned for the exchange of medical tests, designed for handling, display, storage, printing and
transmission standard. Includes defining a file format and a network communication
protocol. The communication protocol is an application protocol that uses TCP / IP to
communicate between systems. The DICOM files can be exchanged between two entities
that are able to receive images and patient data in DICOM format.
DICOM enables the integration of scanners, servers, workstations, printers and network
hardware from multiple vendors within a storage system and image communication. The
different machines, servers and workstations have a DICOM Conformance Statement
(conformance statements) which clearly establishes the DICOM classes they support. DICOM has been widely adopted by hospitals and is making foray into small office
application dentists and doctors.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 81 of 106 Public
Digital Signature
A digital signature (not to be confused with a digital certificate) is a mathematical
technique used to validate the authenticity and integrity of a message, software or digital document.
The digital equivalent of a handwritten signature or stamped seal, but offering far more
inherent security, a digital signature is intended to solve the problem of tampering and
impersonation in digital communications. Digital signatures can provide the added assurances of evidence to origin, identity and status of an electronic document,
transaction or message, as well as acknowledging informed consent by the signer.
In many countries, including the United States, digital signatures have the same legal
significance as the more traditional forms of signed documents. The United States Government Printing Office publishes electronic versions of the budget, public and private
laws, and congressional bills with digital signatures.
Digital signatures are based on public key cryptography, also known as asymmetric
cryptography. Using a public key algorithm such as RSA, one can generate two keys that are mathematically linked: one private and one public. To create a digital signature,
signing software (such as an email program) creates a one-way hash of the electronic
data to be signed. The private key is then used to encrypt the hash. The encrypted hash
-- along with other information, such as the hashing algorithm -- is the digital signature.
The reason for encrypting the hash instead of the entire message or document is that a hash function can convert an arbitrary input into a fixed length value, which is usually
much shorter. This saves time since hashing is much faster than signing.
The value of the hash is unique to the hashed data. Any change in the data, even
changing or deleting a single character, results in a different value. This attribute enables others to validate the integrity of the data by using the signer's public key to decrypt the
hash. If the decrypted hash matches a second computed hash of the same data, it
proves that the data hasn't changed since it was signed. If the two hashes don't match,
the data has either been tampered with in some way (integrity) or the signature was created with a private key that doesn't correspond to the public key presented by the
signer (authentication).
A digital signature can be used with any kind of message -- whether it is encrypted or
not -- simply so the receiver can be sure of the sender's identity and that the message
arrived intact. Digital signatures make it difficult for the signer to deny having signed something (non-repudiation) -- assuming their private key has not been compromised --
as the digital signature is unique to both the document and the signer, and it binds them
together. A digital certificate, an electronic document that contains the digital signature
of the certificate-issuing authority, binds together a public key with an identity and can be used to verify a public key belongs to a particular person or entity.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 82 of 106 Public
Most modern email programs support the use of digital signatures and digital certificates,
making it easy to sign any outgoing emails and validate digitally signed incoming messages. Digital signatures are also used extensively to provide proof of authenticity,
data integrity and non-repudiation of communications and transactions conducted over
the Internet.
Electronic Health Record
An electronic health record (EHR) is a digital version of a patient’s paper chart. EHRs are
real-time, patient-centred records that make information available instantly and securely
to authorised users. While an EHR does contain the medical and treatment histories of
patients, an EHR system is built to go beyond standard clinical data collected in a provider’s office and can be inclusive of a broader view of a patient’s care. EHRs can:
Contain a patient’s medical history, diagnoses, medications, treatment plans,
immunisation dates, allergies, radiology images, and laboratory and test results
Allow access to evidence-based tools that providers can use to make decisions about a patient’s care
Automate and streamline provider workflow
One of the key features of an EHR is that health information can be created and managed
by authorised providers in a digital format capable of being shared with other providers
across more than one health care organisation. EHRs are built to share information with other health care providers and organisations – such as laboratories, specialists, medical
imaging facilities, pharmacies, emergency facilities, and school and workplace clinics – so
they contain information from all clinicians involved in a patient’s care.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 83 of 106 Public
Encryption
Encryption is the conversion of electronic data into another form, called ciphertext, which
cannot be easily understood by anyone except authorised parties.
The primary purpose of encryption is to protect the confidentiality of digital data stored
on computer systems or transmitted via the Internet or other computer networks.
Modern encryption algorithms play a vital role in the security assurance of IT systems
and communications as they can provide not only confidentiality, but also the following
key elements of security:
Authentication: the origin of a message can be verified.
Integrity: proof that the contents of a message have not been changed since it was
sent.
Non-repudiation: the sender of a message cannot deny sending the message
ePrescription
EPS allows prescribers - such as doctors and practice nurses - to send prescriptions
electronically to a dispenser (as a pharmacy) patient choice. This makes the process of
prescribing and more efficient and convenient for patients and staff dispensation.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 84 of 106 Public
Functionalities
In information technology, functionality is the sum or any aspect of what a product, such
as a software application or computing device, can do for a user.
A product's functionality is used by marketers to identify product features and enables a
user to have a set of capabilities. Functionality may or may not be easy to use.
HL7
HL7 and its members provide a framework (and related standards) for the exchange, integration, sharing, and retrieval of electronic health information. These standards
define how information is packaged and communicated from one party to another,
setting the language, structure and data types required for seamless integration between
systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services, and are recognised as the most commonly used in the
world.
HL7 standards are grouped into reference categories:
Section 1: Primary Standards - Primary standards are considered the most popular standards integral for system integrations, inter-operability and compliance. Our
most frequently used and in-demand standards are in this category.
Section 2: Foundational Standards - Foundational standards define the fundamental
tools and building blocks used to build the standards, and the technology
infrastructure that implementers of HL7 standards must manage.
Section 3: Clinical and Administrative Domains - Messaging and document
standards for clinical specialties and groups are found in this section. These
standards are usually implemented once primary standards for the organisation are
in place.
Section 4: EHR Profiles - These standards provide functional models and profiles
that enable the constructs for management of electronic health records.
Section 5: Implementation Guides - This section is for implementation guides
and/or support documents created to be used in conjunction with an existing standard. All documents in this section serve as supplemental material for a parent
standard.
Section 6: Rules and References - Technical specifications, programming structures
and guidelines for software and standards development.
Section 7: Education & Awareness - Find HL7's Draft Standards for Trial Use (DSTUs) and current projects here, as well as helpful resources and tools to further
supplement understanding and adoption of HL7 standards.
All HL7 Standards can also be located by other classifications such as ANSI/ISO/HITSP
approval and various search variables in our Master Grid.
HL7 encompasses the complete life cycle of a standards specification including the
development, adoption, market recognition, utilisation, and adherence. Please refer to
our IP Policy for more information about how members and non-members can use the
standards.
Hospital Information System (HIS)
A hospital information system is defined as the socio-technical subsystem of a hospital,
which comprises all information processing as well as the associated human or technical
actors involved in their respective information processing roles
Typical HIS components are:
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 85 of 106 Public
Enterprise functions (i.e. hospital functions),
Business processes,
Application components,
physical data processing systems
The goal of a hospital information system is to sufficiently enable the adequate execution
of hospital functions for patient care, including patient administration, taking into account
economic hospital management as well as legal (e.g. data protection or reimbursement aspects) and other requirements
Hospital information systems have to consider various areas of a hospital, such as:
Wards and outpatient units
Service units: diagnostic (e.g., laboratory department, radiology department), therapeutic (e.g., operation room) and others (e.g., pharmacy, patient records
archive, library, blood bank)
Hospital administration areas (e.g., patient administration department, patient
record archive, department of quality management, financial and controlling department, department of facility management, information management
department, general administration department, human resources department)
Offices and writing services for (clinical) report writing
HTTPS
HTTPS stands for HyperText Transfer Protocol over SSL (Secure Socket Layer). It is a TCP/IP protocol used by Web servers to transfer and display Web content securely. The
data transferred is encrypted so that it cannot be read by anyone except the recipient.
HTTPS is used by any Web site that is collecting sensitive customer data such as banking
information or purchasing information. If you are making a transaction online, you should make sure that it is done over HTTPS so that the data remains secure.
IHE
IHE created and operates a process through which interoperability of health care IT
systems can be improved. The group gathers case requirements, identifies available standards, and develops technical guidelines which manufacturers can implement. IHE
also stages ‘connectathons’ and ‘interoperability showcases’ in which vendors assemble
to demonstrate the interoperability of their products.
IHE integration profiles describe a clinical information need or workflow scenario and
document how to use established standards to accomplish it. A group of systems that implement the same integration profile address the need/scenario in a mutually
compatible way.
For example, the Digital Imaging and Communications in Medicine (DICOM) standards
specify many different formats for image data. A given set of images that might comply with some optional parts of the standards might still not be accepted by an application in
use by a particular radiologist. Profiles reduce the chances of these incompatibilities.
The Logical Observation Identifiers Names and Codes (LOINC) standard codes for use in
databases are often used in IHE profiles.
A model for cross-enterprise document sharing called XDS allows hospitals to share
electronic records that use the Health Level 7 (HL7) standards and LOINC codes. The
United States Department of Veterans Affairs revised its plans in 1999 to adopt IHE
recommendations.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 86 of 106 Public
IHE integration statements are prepared and published by a vendor to list the IHE
profiles supported by a specific release of a specific product.
IHE technical frameworks are detailed documents which specify the integration profiles and associated actors (systems) and transactions. For example, one specification is for a
common way of binding identification numbers to patients.
IHE connectathons are annual events where equipment vendors bring products with IHE
profiles and test them with other vendors. The term ‘connectathon’ was coined in the 1980s by Sun Microsystems for similar vendor-neutral interoperability testing of the
Network File System protocols and related technologies. The events are held in Europe as
well as the US.
In 2008, an agreement was announced for cooperation with the Continua Health Alliance.
In 2012, a guide was published on access to health data from mobile devices.
Although in 2004 an estimate was that complete interoperability could be completed in
ten years, by 2013 results were still mixed.
In 2013, co-chairs were David Mendelson, director of clinical informatics at Mount Sinai Medical Centre and Elliot B. Sloane of the Centre for Healthcare Information Research
and Policy and research professor at Drexel University.
Interconsultation
A consultation is communication between two medical professionals with different areas
of expertise in which the applicant requires the review pathology of the patient to a consultant who gives its opinion on the case. Interconsultation usually occurs without the
presence of the patient by any communication system. The medical seeks advice
regarding a specific problem of a patient, either by complexity, severity, specialisation.
The ‘expert’ medical responds to the applicant issuing the judgment and recommendations on the care and treatment to be consulted about the problem. We
distinguish the following types:
Conventional Interconsultations. These are made based on a preprinted form where
the petitioner records data concerning the case and answerable to the interconsultation advice on treatment criteria or tests to be performed to the
patient.
Interconsultation of pre-application assessment appointment. Some specialties
have established a system of prior assessment of patients before requesting a
quote from initial consultations. In these cases the MAP, forwards the assessment form and the specialist responds by making express reference to the desirability of
quoting the patient in consultation and priority A&E appointment .
Interconsultation images. They are made by a computer system in which images or
electronic records to conventional data is attached. Serve to support telemedicine systems.
We addressing the scope, differences can those in the hospital setting (inpatient,
emergency room or served in queries) differentiated between levels: primary care and
specialised care.
Generally the consults are performed asynchronously between the applicant and the
consultant, having a delay time previously agreed response. Maximum time is generally
agreed in based on the priority of the case and the circumstances of the patient
(admitted in emergencies, etc.)
The process of consults, like any healthcare process, from the point of view of
information systems, should be part of the EHR. All data recorded on a consultation, they
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 87 of 106 Public
have to be part of the patient's history and therefore must be stored in a structured
repository of the HCE.
The valuation (report) as part of the same care act should be part of the data warehouse EHR, and be available to professionals in both the specialised care setting as primary
care
Interoperability platform
In computing, cross-platform, or multi-platform, is an attribute conferred to computer software or computing methods and concepts that are implemented and inter-operate on
multiple computer platforms. The software and methods are also said to be platform
independent. Cross-platform software may be divided into two types; one requires
individual building or compilation for each platform that it supports, and the other one can be directly run on any platform without special preparation, e.g., software written in
an interpreted language or pre-compiled portable bytecode for which the interpreters or
run-time packages are common or standard components of all platforms.
JAVA
Java is a programming language expressly designed for use in the distributed
environment of the Internet. It was designed to have the ‘look and feel’ of the C++
language, but it is simpler to use than C++ and enforces an object-oriented
programming model. Java can be used to create complete applications that may run on a
single computer or be distributed among servers and clients in a network. It can also be used to build a small application module or applet for use as part of a Web page. Applets
make it possible for a Web page user to interact with the page.
The major characteristics of Java are:
The programs you create are portable in a network. (See portability.) Your source
program is compiled into what Java calls bytecode, which can be run anywhere in a network on a server or client that has a Java virtual machine. The Java virtual
machine interprets the bytecode into code that will run on the real computer
hardware. This means that individual computer platform differences such as
instruction lengths can be recognised and accommodated locally just as the program is being executed. Platform-specific versions of your program are no
longer needed.
The code is robust, here meaning that, unlike programs written in C++ and
perhaps some other languages, the Java objects can contain no references to data external to themselves or other known objects. This ensures that an instruction
cannot contain the address of data storage in another application or in the
operating system itself, either of which would cause the program and perhaps the
operating system itself to terminate or ‘crash.’ The Java virtual machine makes a
number of checks on each object to ensure integrity.
Java is object-oriented, which means that, among other characteristics, an object
can take advantage of being part of a class of objects and inherit code that is
common to the class. Objects are thought of as ‘nouns’ that a user might relate to
rather than the traditional procedural ‘verbs.’ A method can be thought of as one of the object's capabilities or behaviours.
In addition to being executed at the client rather than the server, a Java
applet has other characteristics designed to make it run fast.
Relative to C++, Java is easier to learn.
Java was introduced by Sun Microsystems in 1995 and instantly created a new sense of
the interactive possibilities of the Web. Both of the major Web browsers include a Java
virtual machine. Almost all major operating system developers (IBM, Microsoft, and
others) have added Java compilers as part of their product offerings.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 88 of 106 Public
The Java virtual machine includes an optional just-in-time compiler that dynamically
compiles bytecode into executable code as an alternative to interpreting one bytecode
instruction at a time. In many cases, the dynamic JIT compilation is faster than the virtual machine interpretation.
JavaScript should not be confused with Java. JavaScript, which originated at Netscape, is
interpreted at a higher level, is easier to learn than Java, but lacks some of the
portability of Java and the speed of bytecode. Because Java applets will run on almost any operating system without requiring recompilation and because Java has no operating
system-unique extensions or variations, Java is generally regarded as the most strategic
language in which to develop applications for the Web. (However, JavaScript can be
useful for very small applications that run on the Web client or server.)
Legacy System
A legacy system, in the context of computing, refers to outdated computer systems,
programming languages or application software that are used instead of available
upgraded versions.
LIS
A laboratory information system (LIS) is a class of software that receives, processes, and
stores information generated by medical laboratory processes. These systems often must
interface with instruments and other information systems such as hospital information
systems (HIS). A LIS is a highly configurable application which is customised to facilitate a wide variety of laboratory workflow models. Deciding on an LIS vendor is a major
undertaking for all labs. Vendor selection typically takes months of research and
planning. Installation takes from a few months to a few years depending on the
complexity of the organisation. There are as many variations of LIS as there are types of lab work. Some vendors offer a full-service solution capable of handling a large hospital
lab's needs; others specialise in specific modules. Disciplines of laboratory science
supported by LIS include haematology, chemistry, immunology, blood bank (Donor and
Transfusion Management), surgical pathology, anatomical pathology, flow cytometry and microbiology. This article covers clinical lab which encompasses haematology, chemistry
and immunology.
LIS can be used by doctors to track every part of a patient's visit to them. They can be
used to manage patient check-ins, order and manage different tests, processing, order
and result entries, patient demographics, etc. All of the information from a patient's visit will be stored in the database for future reference and will update with every future visit.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 89 of 106 Public
Medical Device
A medical device is an instrument, apparatus, implant, in vitro reagent, or similar or related article that is used to diagnose, prevent, or treat disease or other conditions, and
does not achieve its purposes through chemical action within or on the body (which
would make it a drug). Whereas medicinal products (also called pharmaceuticals) achieve
their principal action by pharmacological, metabolic or immunological means, medical devices act by other means like physical, mechanical, or thermal means.
Medical devices vary greatly in complexity and application. Examples range from simple
devices such as tongue depressors, medical thermometers, and disposable gloves to
advanced devices such as computers which assist in the conduct of medical testing, implants, and prostheses. The design of medical devices constitutes a major segment of
the field of biomedical engineering.
Medical Health Record (MHR)
MHR are a digital version of the paper charts in the clinician’s office. An EMR contains the medical and treatment history of the patients in one practice. EMRs have advantages
over paper records. For example, EMRs allow clinicians to:
Track data over time.
Easily identify which patients are due for preventive screenings or checkups.
Check how their patients are doing on certain parameters—such as blood pressure readings or vaccinations.
Monitor and improve overall quality of care within the practice.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 90 of 106 Public
But the information in EMRs does not travel easily out of the practice. In fact, the
patient’s record might even have to be printed out and delivered by mail to specialists
and other members of the care team. In that regard, EMRs are not much better than a paper record.
Mirth
Mirth Connect is a cross-platform HL7 interface engine that enables bi-directional sending
of HL7 messages between systems and applications over multiple transports available under the Mozilla Public License (MPL) 1.1 license. On September 9th, 2013 Mirth
Corporation announced they were acquired by Quality Systems.
Mirth Connect uses a channel-based architecture to connect HIT systems and allow
messages to be filtered, transformed, and routed based on user-defined rules. Channels consist of connectors (both inbound and outbound), filters, and transformers. Multiple
filters and a chain of transformers can be associated with a channel.
Endpoints are used to configure connections and their protocol details. Source connectors
are used to designate the type of listener to use for incoming messages, such as TCP/IP or a web service. Destination connectors are used to designate the destination of
outgoing messages, such as an application server, a JMS queue, or a database. All
messages and transactions are optionally logged to an internal database. Mirth Connect
can be also configured to auto-generate an HL7 acknowledgement response (ACK).
Mirth Connect supports sending and receiving healthcare messages over a variety of protocols:
TCP/MLLP.
Database (MySQL, PostgreSQL, Oracle, Microsoft SQL Server, ODBC).
File (local file system and network shares).
PDF and RTF documents.
JMS.
FTP/SFTP.
HTTP.
SMTP.
SOAP (over HTTP).
An open architecture allows for the easy addition of custom and legacy interfaces.
The Certification Commission for Healthcare Information Technology (CCHIT), in a push
to ensure interoperability standards between electronic health records, has adopted Laika, an open source standards software program. At the 2009 Annual HIMSS
Conference, Mirth was selected as one of the testing tools for the coming interoperability
tests.
PACS
A PACS is a system of digital storage, transmission and download of radiological images.
The PACS systems consist of software and hardware parts, which directly communicate
with modalities and get pictures of them. The images are transferred to a workstation
(workstation) for viewing and issuing radiological reports. The PACS viewer is a software that is installed on the workstation that uses the radiologist to receive and display
radiological images. The images are then archived in the PACS server for later download
to workstations.
Architecture PACS: The basic components of a PACS system are:
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 91 of 106 Public
Server Central PACS: It consists of the main system hardware.
Work Station PACS: Allows radiologists visualisation and analysis of digital images.
Database System: Responsible for managing the store all the information and pictures of PACS.
DICOM Server: Responsible for all communication with DICOM imaging modalities
(such as CT or MRI), other PACS DICOM workstations and servers.
Storage System: The hardware required to store DICOM images from PACS system.
Interfaces to RIS / HIS: Consolidate all patient information from different sources,
allowing a flow of qualified labour.
Web Server for Remote Access: Essential for teleradiology. Using the Web Access,
images and information stored in the PACS server can be accessed via a web browser such as Internet Explorer, Mozilla Firefox, Safari, etc.
Personal Health Record (PHR)
The PHR is a tool that you can use to collect, track and share past and current
information about your health or the health of someone in your care. Sometimes this
information can save you the money and inconvenience of repeating routine medical
tests. Even when routine procedures do need to be repeated, your PHR can give medical
care providers more insight into your personal health story.
Remember, you are ultimately responsible for making decisions about your health. A PHR
can help you accomplish that.
Important points to know about a Personal Health Record:
You should always have access to your complete health information.
Information in your PHR should be accurate, reliable, and complete.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 92 of 106 Public
You should have control over how your health information is accessed, used, and
disclosed.
A PHR may be separate from and does not normally replace the legal medical record of any provider.
Medical records and your personal health record (PHR) are not the same thing. Medical
records contain information about your health compiled and maintained by each of your
healthcare providers. A PHR is information about your health compiled and maintained by you. The difference is in how you use your PHR to improve the quality of your healthcare.
Take an active role in monitoring your health and healthcare by creating your own PHR.
PHRs are an inevitable and critical step in the evolution of health information
management (HIM). The book ‘The Personal Health Record’ assists new users of PHRs in getting started, addressing current PHR trends and processes.
PKI Architecture
A public key infrastructure (PKI) is a set of hardware, software, people, policies, and
procedures needed to create, manage, distribute, use, store, and revoke digital certificates.
In cryptography, a PKI is an arrangement that binds public keys with respective user
identities by means of a certificate authority (CA). The user identity must be unique
within each CA domain. The third-party validation authority (VA) can provide this
information on behalf of the CA. The binding is established through the registration and issuance process, which, depending on the assurance level of the binding, may be carried
out by software at a CA or under human supervision. The PKI role that assures this
binding is called the registration authority (RA), which ensures that the public key is
bound to the individual to which it is assigned in a way that ensures non-repudiation.
Public key cryptography is a cryptographic technique that enables users to securely
communicate on an insecure public network, and reliably verify the identity of a user via
digital signatures.
A public key infrastructure (PKI) is a system for the creation, storage, and distribution of digital certificates which are used to verify that a particular public key belongs to a
certain entity. The PKI creates digital certificates which map public keys to entities,
securely stores these certificates in a central repository and revokes them if needed.
A PKI consists of:
A certificate authority (CA) that both issues and verifies the digital certificates.
A registration authority which verifies the identity of users requesting information
from the CA.
A central directory—i.e., a secure location in which to store and index keys.
A certificate management system.
A certificate policy.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 93 of 106 Public
Protocol
In information technology, a protocol is the special set of rules that end points in a
telecommunication connection use when they communicate. Protocols specify
interactions between the communicating entities.
Protocols exist at several levels in a telecommunication connection. For example, there
are protocols for the data interchange at the hardware device level and protocols for data
interchange at the application program level. In the standard model known as Open
Systems Interconnection (OSI), there are one or more protocols at each layer in the
telecommunication exchange that both ends of the exchange must recognise and observe. Protocols are often described in an industry or international standard.
The TCP/IP Internet protocols, a common example, consist of:
Transmission Control Protocol (TCP), which uses a set of rules to exchange
messages with other Internet points at the information packet level.
Internet Protocol (IP), which uses a set of rules to send and receive messages at
the Internet address level.
Additional protocols that include the Hypertext Transfer Protocol (HTTP) and File
Transfer Protocol (FTP), each with defined sets of rules to use with corresponding programs elsewhere on the Internet.
There are many other Internet protocols, such as the Border Gateway Protocol
(BGP) and the Dynamic Host Configuration Protocol (DHCP).
RIS
A radiology information system (RIS) is a networked software suite for managing medical imagery and associated data. An RIS is especially useful for managing radiological
records and associated data in a multiple locations and is often used in conjunction with a
picture archiving and communication system (PACS) to manage work flow and billing.
An RIS has several basic functions:
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 94 of 106 Public
Patient management: An RIS can track a patient’s entire workflow within the
radiology department; images and reports can be added to and retrieved from
electronic medical records (EMRs) and viewed by authorised radiology staff.
Scheduling: Appointments can be made for both in- and out-patients with specific
radiology staff.
Patient tracking: A patient’s entire radiology history can be tracked from admission
to discharge. The history can be coordinated with past, present and future appointments.
Results reporting: An RIS can generate statistical reports for a single patient, group
of patients or particular procedure.
Film tracking: An RIS can track individual films and their associate data.
Billing: An RIS facilitates detailed financial record-keeping, electronic payments and
automated claims submission.
RPM System
RPM Package Manager (RPM) (originally Red Hat Package Manager; now a recursive initialism) is a package management system. The name RPM variously refers to the .rpm
file format, files in this format, software packaged in such files, and the package
manager itself. RPM was intended primarily for Linux distributions; the file format is the
baseline package format of the Linux Standard Base.
Even though it was created for use in Red Hat Linux, RPM is now used in many GNU/Linux distributions. It has also been ported to some other operating systems, such
as Novell NetWare (as of version 6.5 SP3) and IBM's AIX (as of version 4).
An RPM package can contain an arbitrary set of files. The larger part of RPM files
encountered are ‘binary RPMs’ (or BRPMs) containing the compiled version of some software. RPM files however may also contain the source code, then called ‘source RPMs’
(or SRPMs) used to produce a package. SRPMs have an appropriate tag in the file header
that distinguishes them from normal (B)RPMs, causing them to be extracted to /usr/src
on installation. SRPMs also customarily carry the file extension ‘.src.rpm’ (.spm on file systems limited to 3 extension characters, i.e. old DOS FAT).
Service Bus
An enterprise service bus (ESB) is software architecture for middleware that provides
fundamental services for more complex architectures. For example, an ESB incorporates
the features required to implement a service-oriented architecture (SOA). In a general sense, an ESB can be thought of as a mechanism that manages access to applications
and services (especially legacy versions) to present a single, simple, and consistent
interface to end-users via Web- or forms-based client-side front ends.
In essence, ESB does for distributed heterogeneous back end services and applications and distributed heterogeneous front-end users and information consumers what
middleware is really supposed to do: hide complexity, simplify access, allow developers
to use generic, canonical forms of query, access and interaction, handling the complex
details in the background. The key to ESB's appeal, and possibly also its future success, lies in its ability to support incremental service and application integration as driven by
business requirements, not as governed by available technology.
One of the major vendors of ESB, IBM, promotes it as a way to meet the challenges of
integrating applications and provide a single, unified architecture —- built around IBM WebSphere —- that can:
Distribute information across an enterprise quickly and easily.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 95 of 106 Public
Mask differences among underlying platforms, software architectures, and network
protocols.
Ensure information delivery even when some systems or networks may go off-line from time to time.
Re-route, log, and enrich information without requiring applications to be rewritten.
Provide incremental solution implementations so all enterprise services and
applications need not change immediately or all at once.
According to IBM, ‘ESB is not a new software product – it's a new way of looking at how
to integrate applications, coordinate resources, and manipulate information
Smartphone
A smartphone combines cellular telephone, Internet access for e-mail and Web, music and movie player, camera and camcorder, GPS navigation system and a voice search for
asking a question about anything (see personal assistant). A smartphone is much more
personal than a personal computer, because it is with you all the time when traveling and
nearby if you use it as your main phone.
SMART TV
A smart TV, sometimes referred to as connected TV or hybrid TV, (not to be confused
with IPTV, Internet TV, or with Web TV) is a television set or set-top box with integrated
Internet and Web 2.0 features, and is an example of technological convergence between
computers and television sets and set-top boxes. Besides the traditional functions of television sets and set-top boxes provided through traditional broadcasting media, these
devices can also provide online interactive media, Internet TV, over-the-top content, as
well as on-demand streaming media, and home networking access.
The software that runs smart TVs can be preloaded into the device, or updated or installed on demand via an app store or app marketplace, in a similar manner to how the
Internet, Web widgets, and software applications (in this context commonly just referred
to as ‘apps’) are integrated in modern smartphones.
SOA (Service Oriented Architecture)
Service-oriented architecture (SOA) is a design pattern based on distinct pieces of
software providing application functionality as services to other applications via a
protocol. This is known as service-orientation. It is independent of any vendor, product or
technology.
A service is a self-contained unit of functionality, such as retrieving an online bank statement. Services can be combined by other software applications to provide the
complete functionality of a large software application. SOA makes it easy for computers
connected over a network to cooperate. Every computer can run an arbitrary number of
services, and each service is built in a way that ensures that the service can exchange information with any other service in the network without human interaction and without
the need to make changes to the underlying program itself.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 96 of 106 Public
SSSL
SSL (pronounced as separate letters) is short for Secure Sockets Layer, a protocol
developed by Netscape for transmitting private documents via the Internet. SSL uses a
cryptographic system that uses two keys to encrypt data − a public key known to
everyone and a private or secret key known only to the recipient of the message. Both Netscape Navigator and Internet Explorer support SSL, and many Web sites use the
protocol to obtain confidential user information, such as credit card numbers. By
convention, URLs that require an SSL connection start with https: instead of http:.
Another protocol for transmitting data securely over the World Wide Web is Secure HTTP (S-HTTP). Whereas SSL creates a secure connection between a client and a server, over
which any amount of data can be sent securely, S-HTTP is designed to transmit individual
messages securely. SSL and S-HTTP, therefore, can be seen as complementary rather
than competing technologies. Both protocols have been approved by the Internet Engineering Task Force (IETF) as a standard.
Standard
A document, established by consensus and approved by a recognised body that provides
for common and repeated use, rules, guidelines or characteristics for activities or their
results, aimed at the achievement of the optimum degree of interoperability between information systems.
Standards are necessary for interworking, portability, and reusability. They may be de
facto standards for various communities, or officially recognised nationally or
internationally.
Telecare
Telecare is the continuous, automatic and remote monitoring of real time emergencies
and lifestyle changes over time in order to manage the risks associated with independent
living.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 97 of 106 Public
Telemonitoring
It is a medical practice that involves remotely monitoring patients who are not at the
same location as the health care provider. In general, a patient will have a number of monitoring devices at home, and the results of these devices will be transmitted via
telephone to the health care provider. Telemonitoring is a convenient way for patients to
avoid travel and to perform some of the more basic work of healthcare for themselves.
In addition to objective technological monitoring, most telemonitoring programs include subjective questioning regarding the patient's health and comfort. This questioning can
take place automatically over the phone, or telemonitoring software can help keep the
patient in touch with the health care provider. The provider can then make decisions
about the patient's treatment based on a combination of subjective and objective information similar to what would be revealed during an on-site appointment.
Some of the more common things that telemonitoring devices keep track of include blood
pressure, heart rate, weight, blood glucose, and hemoglobin. Telemonitoring is capable of
providing information about any vital signs, as long as the patient has the necessary monitoring equipment at his or her location. Depending on the severity of the patient's
condition, the provider may check these statistics on a daily or weekly basis to determine
the best course of treatment.
Telemonitoring is common for patients with diabetes or hypertension. These patients can
take advantage of regular vital sign monitoring and regular provider feedback without having to commute to the health care provider. Telemonitoring is particularly effective for
people with diabetes and hypertension, because it is extremely important for the vital
statistics of such patients to be consistently observed.
There are a number of advantages of telemonitoring for both the patient and the health care provider. For the health care provider, telemonitoring is an efficient way to gather
necessary patient information without a great time commitment. This efficient means of
gathering information is also relevant to disease-based research, because a large amount
of information can be gathered and recorded with little effort. Telemonitoring is useful to patients because they can receive health care provider feedback on their vital statistics
much more often than they otherwise might. Also, because the patient is more involved
in his or her own treatment, the patient will become more aware of his or her vital
statistics and possibly gain a better sense of what affects these statistics and how the
statistics in turn affect how he or she feels.
Three-tier architecture
A Three-tier architecture is a client-server architecture in which the functional process
logic, data access, computer data storage and user interface are developed and
maintained as independent modules on separate platforms. Three-tier architecture is a software design pattern and a well-established software architecture.
Three-tier architecture allows any one of the three tiers to be upgraded or replaced
independently. The user interface is implemented on a desktop PC and uses a standard
graphical user interface with different modules running on the application server. The relational database management system on the database server contains the computer
data storage logic. The middle tiers are usually multi-tiered.
The three tiers in a three-tier architecture are:
Presentation Tier: Occupies the top level and displays information related to services available on a website. This tier communicates with other tiers by sending
results to the browser and other tiers in the network.
Application Tier: Also called the middle tier, logic tier, business logic or logic tier,
this tier is pulled from the presentation tier. It controls application functionality by
performing detailed processing.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 98 of 106 Public
Data Tier: Houses database servers where information is stored and retrieved. Data
in this tier is kept independent of application servers or business logic.
A 3-tier application is an application program that is organised into three major parts, each of which is distributed to a different place or places in a network. The three parts
are:
The workstation or presentation interface.
The business logic.
The database and programming related to managing it.
In a typical 3-tier application, the application user's workstation contains the
programming that provides the graphical user interface (GUI) and application-specific
entry forms or interactive windows. (Some data that is local or unique for the workstation user is also kept on the local hard disk.)
Business logic is located on a local area network (LAN) server or other shared computer.
The business logic acts as the server for client requests from workstations. In turn, it
determines what data is needed (and where it is located) and acts as a client in relation to a third tier of programming that might be located on a mainframe computer.
The third tier includes the database and a program to manage read and write access to
it. While the organisation of an application can be more complicated than this, the 3-tier
view is a convenient way to think about the parts in a large-scale program.
A 3-tier application uses the client/server computing model. With three tiers or parts, each part can be developed concurrently by different team of programmers coding in
different languages from the other tier developers. Because the programming for a tier
can be changed or relocated without affecting the other tiers, the 3-tier model makes it
easier for an enterprise or software packager to continually evolve an application as new needs and opportunities arise. Existing applications or critical parts can be permanently
or temporarily retained and encapsulated within the new tier of which it becomes a
component.
VPN
A virtual private network, VPN, or VPN stands for Virtual Private Network, is a networking
technology that allows a secure extension of the local network (LAN) over a public or
uncontrolled network such as the Internet. Allows the computer on the network to send
and receive data on shared or public networks like a private network with full
functionality, security and management policies of a private network. This is done by establishing a virtual point-to- point by use of dedicated connections, encryption or a
combination of both methods.
Common examples are the ability to connect two or more branches of a company using
as Internet connection, allowing team members support the connection from home to data centre, or a user can access their home computer from a remote site such as a
hotel, all using the Internet infrastructure.
The VPN connection via Internet is technically a union wide area network (WAN) between
the sites but the user does seem like a private- link from there the ‘virtual private network’ designation.
WDSL
WSDL is an XML format for describing network services as a set of endpoints operating
on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete
network protocol and message format to define an endpoint. Related concrete endpoints
are combined into abstract endpoints (services). WSDL is extensible to allow description
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 99 of 106 Public
of endpoints and their messages regardless of what message formats or network
protocols are used to communicate, however, the only bindings described in this
document describe how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME.
Web application
A Web application (Web app) is an application program that is stored on a remote server
and delivered over the Internet through a browser interface.
Web services are Web apps by definition and many, although not all, websites contain
Web apps.
Within the mobile computing sector, Web apps are sometimes contrasted with native
apps, which are applications that are developed specifically for a particular platform or device and installed on that device. However, the two are not mutually exclusive because
many applications contain elements of both native and Web apps. Programs that combine
the two approaches are sometimes referred to as hybrid application.
Web Service
Web services are client and server applications that communicate over the World Wide
Web’s (WWW) HyperText Transfer Protocol (HTTP). As described by the World Wide Web
Consortium (W3C), web services provide a standard means of interoperating between
software applications running on a variety of platforms and frameworks. Web services
are characterised by their great interoperability and extensibility, as well as their machine-processable descriptions, thanks to the use of XML. Web services can be
combined in a loosely coupled way to achieve complex operations. Programs providing
simple services can interact with each other to deliver sophisticated added-value
services.
WSSL
The Secure Sockets Layer (SSL) is a computer networking protocol that manages server
authentication, client authentication and encrypted communication between servers and
clients.
SSL uses a combination of public-key and symmetric-key encryption to secure a
connection between two machines, typically a Web or mail server and a client machine,
communicating over the Internet or an internal network.
Using the OSI reference model as context, SSL runs above the TCP/IP protocol, which is
responsible for the transport and routing of data over a network, and below higher-level protocols such as HTTP and IMAP, encrypting the data of network connections in the
application layer of the Internet Protocol suite. The ‘sockets’ part of the term refers to
the sockets method of passing data back and forth between a client and a server
program in a network, or between program layers in the same computer.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 100 of 106 Public
The Transport Layer Security (TLS) protocol evolved from SSL and has largely
superseded it, although the terms SSL or SSL/TLS are still commonly used; SSL is often
used to refer to what is actually TLS. The combination of SSL/TLS is the most widely deployed security protocol used today and is found in applications such as Web browsers,
email and basically any situation where data needs to be securely exchanged over a
network, like file transfers, VPN connections, instant messaging and voice over IP.
The SSL protocol includes two sub-protocols: the record protocol and the ‘handshake’ protocol. These protocols allow a client to authenticate a server and establish an
encrypted SSL connection. In what's referred to as the ‘initial handshake process,’ a
server that supports SSL presents its digital certificate to the client to authenticate the
server's identity. Server certificates follow the X.509 certificate format that is defined by the Public-Key Cryptography Standards (PKCS). The authentication process uses public-
key encryption to validate the digital certificate and confirm that a server is in fact the
server it claims to be.
Once the server has been authenticated, the client and server establish cipher settings and a shared key to encrypt the information they exchange during the remainder of the
session. This provides data confidentiality and integrity. This whole process is invisible to
the user. For example, if a webpage requires an SSL connection, the URL will change
from HTTP to HTTPS and a padlock icon appears in the browser once the server has been
authenticated.
The handshake also allows the client to authenticate itself to the server. In this case,
after server authentication is successfully completed, the client must present its
certificate to the server to authenticate the client's identity before the encrypted SSL
session can be established.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 101 of 106 Public
Appendix B: Standards The need for interoperable systems is evident in every part of health sector organisations
as effective delivery of healthcare requires a constant exchange of information among
health professionals, including service institutions, insurers and government, between
medical staff and patients, between auxiliary imaging systems and laboratories, with electronic medical records systems and between public health systems, just to mention
some interactions.
Consequently, effective communication between these actors requires that a common
framework that allows interaction and coordination of care sharing. Framework provided
by the standards, which provide uniformity in the name of the components of the health system whether diagnoses, people, procedures, interventions and how it is transmitted,
to ensure that data in one part of the system health are available and have meaning not
only through the variety of clinical settings and public health but also administratively.
In the figure below we have a map with the most common standards and protocols (grouped by areas); these standards can be considered as an infrastructure of every IT
system which has interchanged data with other systems.
Figure 35: Standards v. interoperability levels
The importance of this schema is to visualise that the use of a single standard is not enough to achieve the different types of interoperability and it is necessary to look for
additional standards and with different foci which together enable communication and
utilisation of information.
Effective use of information through a set of information systems is not achieved only
with the pact that the systems can communicate; this is not possible even if the same standard of communications used. This problem is inherent in the information itself as
well as the way it is obtained, processed and stored.
Therefore, for effective interpretation and processing of information it is necessary to
apply standards that allow representation of the context of information. Below is a brief
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 102 of 106 Public
description of the standards presented in the map in picture 17, which are organised by
foci or areas of application, its aims and relations it performs.
Communication infrastructure: In this area are the standards and protocols that enable physical and logical communication between computers and networks.
Protocols that underlie the Internet are listed (Interoperability Toolkit (ITK) of the
National Health System (NHS) in the UK).
Ethernet is a protocol link layer (layer 2 Open System Interconnection model or OSI) that allows two devices connected via a link (cable) data exchange higher
layer protocols.
TCP / IP protocols are most used in the world. TCP is a transport protocol (layer 4
of the OSI model) that allows you to create logical connections over an IP network between two physically distant computers. IP is a network layer protocol (layer 3 of
the OSI model). These protocols enabled the implementation of Internet.
B.1 Communication Protocols (general applications)
Simple Mail Transfer Protocol (SMTP). It is based on plain text messages to send
emails protocol. Allowed the implementation of large-scale email.
File Transfer Protocol (FTP). It is the protocol par excellence to transferring files between computers connected over a TCP network (such as the Internet). It is
designed to obtain maximum connection speed because the files represent large
amounts of data.
Simple Mail Transfer Protocol (SMTP). It is based on plain text messages to email protocol. It allowed the implementation of large-scale email.
Hypertext Transfer Protocol (HTTP). This protocol allows the transfer of resources
(files, text, images, videos, sounds, etc.) on the Internet. It is based on the request
/ response model where each request made by a client computer to a server, it sends a message in response which may include the requested resources.
Simple Objet Access Protocol (SOAP): A protocol that accepts objects in different
systems to communicate with each other by exchanging XML messages over HTTP.
It is one of the protocols that allow implementing web services.
B.2 Syntax standards
Hypertext Markup Language (HTML) of World Wide Web Consortium (W3C): Multimedia format documents on the Internet. It is based on labels that can be read
by a human form. These labels are used to organise the content of the documents
and give them a format. Attaches different types of multimedia content through
references (URLs), and also link documents together. The last families of HTML and XHTML documents (HTML1-1991, HTML5-201X) are also XML documents.
Electronic Data Interchange (EDI) of American National standards Institute (ANSI
1979): It is the format for exchanging electronic documents between computer
systems. It aims to represent electronic documentation replacing the paper.
JavaScript Object Notation (JSON) of internet Engineering Task Force (IETF): It is a very popular format on the Internet to represent structured objects. The main
rationale for using JSON instead of XML is that to represent a single structure is
much lighter (which is a necessity in networks with low bandwidth).
eXtensible Markup Language (XML) of World Wide Web Consortium (W3C): Extensible meta tags based on plaintext used to represent structured data. XML
does not define a particular format, it is rather a way of defining formats (eg SOAP
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 103 of 106 Public
is based on XML). In turn, these individuals serve as syntax formats for the
exchange of information between applications generally run on different computers.
Yet another Markup Language (YAML), For representing structured information that enables computer processing time and is friendly format for reading by humans.
B.3 Format Specification
XML Schema, It is a language used to define XML structures and restrictions on the
data that will contain; also defines particular uses of XML format. Web Service
Definition Language (WSDL) uses it to define formats of web services and items that are exchanged via SOAP.
B.4 Services Specification
Web Service Definition Language (WSDL): The format eXtensible Markup Language
(XML) to describe Web services as a set of interfaces that operate on messages
containing document-oriented or process information.
B.5 Process Specification
Both Guides clinical practice as clinical protocols are implementable way of computing processes using the standards for the specification process. Analogously, administrative
and managerial processes can also be implemented with these standards. One feature of
the processes in health are interdependent, so its informatics Formal definition allows
better communication and management of the entire system, making visible processes and controlling their execution by quality parameters.
Business Process Execution Language (BPEL). A standard of the Organisation for
the Advancement of Structured Information Standards (OASIS) of a language that
can be implemented and used to specify actions within the business processes of
organisations through web services. Specify integrated processes between the services provided by different information systems.
Business Process Definition Metamodel (BPMD. It is a standard of the Object
Management Group (OMG) with the ability to represent and model business
processes, regardless of the notation or methodology. To achieve a metamodel, which is kind of vocabulary processes with well-defined connections between terms
and concepts used? XML notation used to represent processes.
ebXML Business Process Specification Schema (ebBPSS). An OASIS standard that
establishes a set of nominal elements and specifications necessary to establish a collaboration between business partners and provide configuration parameters for
systems at runtime to achieve collaboration among a set of systems.
B.6 Communication Protocols (Health applications)
HL7 v2: is a messaging standard based on the EDI format for the exchange of
messages between computerised information systems in health. The latest versions
include messaging in XML format.
X12, is a US communication protocol for communication applied in different areas
of government and industry, including health. These protocols use EDI and XML
messaging and are based on the definition of sets formed by electronic messages
with predefined formats transactions.
National Council for Prescription Drug Program (NCPDP), is an American standard
that provides transactions involving prescription, dispensing and billing of drugs.
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 104 of 106 Public
DICOM is an open standard managed by the National Electrical Manufacturers
Association (NEMA) and created by industry, consumers and others stakeholders to
allow the standardisation of digital imaging records and communication between systems.
HL7 v3, is a messaging standard based on the HL7 Reference Model (Informative
Reference Model or RIM) and XML format. HL7 v3 messages are divided into
domains such as accounting and billing, healthcare, claims and reimbursement for clinical decision support, clinical document architecture, clinical genomics, clinical
claims, laboratory orders and reports of public health, among others.
CEN/ISO 13606 is the standard CEN / ISO for communication of digital clinical
documents between EHR systems or between them and centralised repositories of clinical information. The standard is divided into five parts: model reference
exchange archetypes, vocabularies and terminology, safety and specification of
interfaces.
B.7 Terminology and health nomenclature
There are different types of health terminologies and nomenclatures. Their organisation,
structure and granularity depend on purpose. For example, the rankings have statistical purposes, while controlled vocabularies or thesauri seek to standardise the clinical
record. In any case, the objective is the normalisation, which enables interoperability
(American Health Information Management Association, 2008; Merabti and others, 2009;
Kranthammer, s / f; Powell and Willis, 2005).
Radiology Lexicon (RadLex) of the Radiology Society of North America (RSNA),
Terminology for radiology that serves to organise and find images, radiological and
clinical reports related records. It contains a lexicon to assist in natural language
processing. It complements other terminologies as Systematised Nomenclature of Medicine-Clinical Terms (SNOMED CT) and DICOM.
Unified Medical Language System (UMLS) Of the National Library of Medicine of
United States. It is a medical terminology consists of three sources of knowledge:
meta-thesaurus (database with a vocabulary), a semantic network (which
categorises and related terms vocabulary) and the SPECIALIST lexicon that contains information to assist the natural language processing. Includes data
sources such as Medical Subject Headings (MeSH), Current Procedural Terminology
(CPT) of the American Medical Association (AMA), International Classification of
Diseases (ICD), Logical Observation Identifiers Names and Codes (LOINC) and SNOMED CT.
Medical Subject Headings (MeSH) of the National Library of Medicine (NLM) of
United States. Terminology reduced with preferred by NLM cataloguing books and
library materials and index items to include in databases related to health, such as MEDLINE terms.
International Classification of Disease (CIE) of World Health Organisation (WHO). It
is a statistical classification of clinical terms as diseases, signs, symptoms, findings,
complaints, social circumstances and external causes of injury or disease. The
version 9 Amendments Clinics (ICD 9 CM) contains a list of terms for diagnostic, surgical and therapeutic procedures. The version 10 with Modifications Clinics (ICD
10 CM) contains, in addition, codes that combine diagnosis and symptom codes
needed to reduce expressing a given condition.
International Classification of Primary Care (CIAP2) of the World Organisation of Family Doctors (WONCA). Sort and encoding processes as well as signs and
symptoms, infections, tumours, injuries, congenital anomalies and other diagnoses,
all classified by (digestive, ear, circulatory, etc.).
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 105 of 106 Public
Current Procedural Terminology (CPT) of AMA, Classification with codes and
descriptions for reporting medical services and procedures performed by physicians.
Systematised Nomenclature of Medicine Clinical Terms (SNOMED CT) of the International Health Terminology Standards Development Organisation (IHTSDO).
Terminology controlled clinical multi-language exhaustive and covers diseases,
clinical findings, etiologies, procedures, living organisms and clinical information
used to record results. The content is based on relationships between concepts, their attributes and context information for expressing each concept to a fine
granular level, enabling consistent record level between different health
professionals.
Logical Observation Identifiers Names and Codes (LOINC) of the Regenstrief Institute. Facilitates the exchange and sharing of results of para-clinical studies,
both for medical assistance and for the management or research results. Includes
terms for laboratory, microbiology, toxicology, radiology, haemodynamics and other
clinical observations.
B.8 Clinical documentation
Continuity of Care Record (CCR), ASTM standard for the representation of documents summarising the healthcare Starring in order to ensure continuity of
care while the patient is treated at various centres.
ISO 13606-1, Specifies a model of clinical information that structure documents for
communication between systems with the ability to communicate extracts complete records residing in electronic medical record systems.
Data Elements for Emergency Department Systems (DEEDS), Standard of the
National Centre for Injury Prevention and Control (NPC) for the standardised
registration information in emergency departments, in order to reuse the information for other purposes such as public health and education.
Clinical Document Architecture (CDA), HL7 standard to represent any kind of clinical
documentation through its reference model and then express them in XML format
for communication.
B.9 Models of information
HL7 RIM is a model reference information HL7 v3. Its aim is to provide a basis for consistent definition of HL7 v3 messages for communication of clinical,
administrative and accounting information.
OMG COAS (Clinical Observation Access Service), It is an OMG standard that
specifies a detailed clinical observations useful for the definition of services and communication of information on these comments model, including diagnoses, vital
signs, para-clinical studies, etc.
OpenEHR RM, is a reference model of open systems standard electronic medical
history. openEHR defines a generic model based on a process of resolution of
clinical problems that can model any type of medical attention completely with its context and semantics.
B.10 Architecture of communication
Integrating the Healthcare Enterprise (IHE), It is an initiative by healthcare
professionals and industry in order to improve computer systems in healthcare
share information. IHE defines a set of technicians to implement communication
D4.1 Pilot Level Service Specification for CareWell Services
v1.0 / 23rd July 2015 Page 106 of 106 Public
between systems in diverse areas such as laboratory, radiology, cardiology and
coordination of patient care among other profiles.
National Health System Interoperability Toolkit (ITK), This toolkit aims to connect existing systems rather than replacing them. This consists of a set of standards and
interoperability frameworks covering transactional and analytical services to
accelerate the provision of health services.
B.11 Knowledge models
Archetypes allow you to specify structures about a generic model information. These specifications can be shared, translated and integrated with international
terminologies and coding systems for interagency agreements specify semantics,
structure and content of information to be exchanged. The openEHR and ISO 13606
standards archetypes used as a mechanism to specify and share clinical concepts
between institutions. openEHR proposes Agent Definition Language (ADL) such as computer-readable format for the definition of archetypes.
The ontologies are ways of organising the elements of reality comprehensible and
accurate manner, generating a semantic base capable of being processed by
computers. By defining ontologies for basics that make health systems, such as people, users, professionals, institutions, services and facilities, it is possible to
construct a semantic basis consistent for the entire health system from which to
generate information and services capable of Global business semantics and
interoperability. The standard Web Ontology Language (OWL) of the World Wide Web Consortium (W3C) allows the expression of ontologies in computer runnable
format. The ontologies defined in OWL, in combination with inference tools are able
to derive logical reasoning to find new rules and information based on them and
current information.
Resource Definition Framework (RDF) is a simple model for the representation of
metadata. The purpose of RDF is to add semantic processing capacity to identify
and define allowing web properties on the resources of this (documents, images,
videos, etc.). By treating the clinical documentation as a resource, the application
of RDF for semantic processing of information in the area of health is promising. Some of their specific applications refer to the integration of metadata (different
vocabularies / schemes), greater accuracy in the search of information (ability to
categorise and organise resources) and establishing a basis for reasoning
(induction) of new information, among others.