D4.6 Integrated ICT Infrastructure Version 2€¦ · 4.2 HealthCare ICT Infrastructure 17 4.3...

The SmartCare 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.: 325158

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.6 Integrated ICT Infrastructure Version 2

WP4: System Implementation and Test

Version 1.2, 10th March 2016


Public of 73 v1.2, 10th March 2016

Document information

Organisation responsible

Vidavo S.A.

Author(s)

Eleftheria Vellidou (Vidavo)

Contributing partners

Andrea Di Lenarda, Donatella Radini, Kira stellato, Matteo Apuzzo (FVG)

Marlene Harkis (NHS24)

Rosana Angles Barbastro (Salud Aragon)

Maria Hardt Schønnemann (South Denmark)

Milan Vukovic (Kraljevo)

Katja Raapysjarvi (South Karelia)

Doris Kaljuste (Tallinn)

Luk Vervenne (Noord Braband)

Reviewed by

John Oates (HIMSA)

Dissemination level

PU Public

Version history

Version Date Changes made By

0.0 16th December 2014 D4.3 used as starting point John Oates

0.1 15th February 2015 Second wave sites added Eleftheria Vellidou

0.2 9th March 2015 Revisions to section 10 John Oates

1.0 9th March 2015 Version for issue John Oates

1.1 14th September 2105 New section 2 overview and Appendix A added Bridget Moorman

1.2 10th March 2016 Section 11 for the Netherlands updated Wil Rijnen

Outstanding Issues

None

Filename

D4.6 v1.2 SmartCare Integrated ICT Infrastructure (V2)

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.



Executive summary

This deliverable describes in detail the integrated ICT infrastructure for each deployment site as finally implemented to run their deployment services. The term integration in the context of the SmartCare project refers to the optimum cooperation and exchange of information over ICT between at least the social and health care services for the deployment site. The third sector might be also involved depending on the original architecture.

The document is organised in chapters by deployment site. Each chapter has the same structure detailing the description of the various infrastructures and how these are implemented in the SmartCare solution.

The nature of this deliverable is quite dynamic as it depends on the progress achieved per site. At this stage, all sites are operational, so the descriptions provided here are considered stable, well tested and fully functional.



Table of Contents

Document information 2

Executive summary 3

Table of Contents 4

1 Introduction 8

1.1 Purpose of this document 8

1.2 Structure of document 8

1.3 Glossary 8

2 Overview 10

2.1 Summary 10

2.2 Detail 11

3 Prototype FVG (1st wave) 13

3.1 Introduction, Scope and Objectives 13

3.2 Healthcare ICT Infrastructure 14

3.3 Social Care ICT Infrastructure 15

3.4 ICT Infrastructure for SmartCare 16

4 Prototype Aragon (1st wave) 17


4.2 HealthCare ICT Infrastructure 17



5 Prototype Scotland (1st wave) 19




5.4 Information sharing hubs 23

5.5 Living it Up self-management hub 24

5.6 ICT infrastructure for SmartCare 25

5.6.1 Integration with existing local statutory systems 26

5.6.2 Integration with the LiU platform 27

5.6.3 Elements of development on LiU to support SmartCare 28

5.6.4 Development plan of new components 28

6 Prototype RSD (1st wave) 29







7 Prototype Tallinn (2nd

wave) 37





8 Prototype Kraljevo – Serbia (2nd

wave) 43


8.1.1 Introduction 43

8.1.2 Scope 43

8.1.3 Objectives 43


8.2.1 Hardware infrastructure 43

8.2.2 Software in operation 44



9 Prototype South Karelia Social and Health Care District (2nd

wave) 46





9.4.1 Technical adaptation of existing ICT components / systems 47

10 Prototype Attica (2nd

wave) 49





11 Prototype Noord-Brabant (2nd

wave) 53







12 Conclusions 56

Appendix A: Functional Blocks and SmartCare ICT Implementation Overview 57

A.1 Table: Enrolment and Consent Functional Block 57

A.2 Table: Care Plan Functional Block 60

A.3 Table: Onsite Provision of Care Functional Block 62

A.4 Table: Remote Provision of Care and Support Functional Block 64

A.5 Table: Documentation of Care Functional Block 67

A.6 Table: Assessment and Re-assessment of Care Functional Block 68

A.7 Table: Exit from SmartCare System Functional Block 70

A.8 Additional notes for Scotland 71

Table of Tables

Table 1: Information sharing hubs in the SmartCare areas 23

Table 2: Core capabilities for information sharing hubs 24

Table of Figures

Figure 1: FVG SmartCare ICT infrastructure 16

Figure 2: Aragon SmartCare ICT infrastructure schema 18

Figure 3: Aragon SmartCare ICT infrastructure overview 18

Figure 4: Outline architecture for Scotland 21

Figure 5: Concept of the SmartCare applications 26

Figure 6: Potential linkages between SmartCare applications and LiU 27

Figure 7: Roadmap for SmartCare technical development 28

Figure 8: RSD electronic messaging 29

Figure 9: Danish Health Data Network 30

Figure 10: RSD architecture of the Shared Care platform 33

Figure 11: RSD integration architecture 33

Figure 12: RSD hardware architecture 34

Figure 13: RSD Shared Care platform elements (1) 34

Figure 14: RSD Shared Care platform elements (2) 35

Figure 15: RSD Use case scenarios (1) 35

Figure 16: RSD Use case scenarios (2) 36

Figure 17: Estonian SmartCare portal - the main social and medical care components 37



Figure 18: View from the E-Tervis webpage 38

Figure 19: Estonia - X-Road set-up 39

Figure 20: Estonian national mandatory ID-card 40

Figure 21: Example of the home monitoring set 41

Figure 22: Smartcard being used in public transport 42

Figure 23: Kraljevo current hardware infrastructure 44

Figure 24: Kraljevo revised hardware infrastructure 45

Figure 25: South Karelia patient data flows 47

Figure 26: Hyvis.fi portal 48

Figure 27: Healthcare pathway 50

Figure 28: Social care pathway 51

Figure 29: High level architecture of integration between health and social care 52

Figure 30: FLOW, the Integrated Care Centre for Rehabilitation & Prevention 53

Figure 31: FLOW Cardio system architecture 54

Figure 32: Functional architecture 55



1 Introduction

1.1 Purpose of this document

This document provides detailed descriptions of the integrated ICT infrastructure for each deployment site as finally implemented to run their deployment services. The term integration in the context of the SmartCare project refers to the optimum cooperation and exchange of information over ICT between at least the social and health care services for the deployment site. The third sector might be also involved depending on the original architecture.

The nature of this deliverable is quite dynamic as it depends on the progress achieved per site. At this stage, all sites are operational, so the descriptions provided here are considered stable, well tested and fully functional.

1.2 Structure of document

There is one section for each deployment site. The structure of information for each site is identical. The topics discussed are the following:

Introduction, Scope and Objectives: This section is dedicated to explain briefly the scope of each site and to state the objectives as set out in the Technical Annex. This set of objectives, materialised into technical and functional specifications, is the guideline against which performance will be measured.

Healthcare ICT infrastructure: According to each site’s starting point and architecture, the healthcare ICT infrastructure already in place will be described in order to demonstrate the capacity to provide healthcare services in general.

Social care ICT Infrastructure: According to each site’s starting point and architecture, the social care ICT infrastructure already in place will be described in order to demonstrate the capacity to provide social care services in general.

ICT Infrastructure for SmartCare: This section is dedicated to provide the coexistence of health and social care services over ICT in the SmartCare context. Based on the descriptions of the aforementioned analytic sections per component, here the final synthesis is described where the site is operational.

Finally a Conclusions section is included for wrap up and discussion of the individual and collective achievements of the members of the SmartCare consortium.

1.3 Glossary

API Application Programming Interface

COPD Chronic Obstructive Pulmonary Disease

CR Care Recipient

EHR Electronic Healthcare Record

FVG Friuli Venezia Giulia

GP General Practitioner

HC Health Care

HCP Healthcare Professional

ICT Information and Communication Technology



IS Information Systems

LiU Living it Up (Scotland)

NYHA New York Heart Association; a classification developed by them

RSD Region of Southern Denmark

SC Social Care

SCP Social Care Professional



2 Overview

This section presents an overview across sites.

2.1 Summary

As outlined in the tables in Appendix A for each SmartCare functionality by deployment site, there were quite a few commonalities with regard to the type of systems and interfacing that were done with the SmartCare project to facilitate the integrative approach to delivery of care. The paragraphs below compare and contrast the different approaches with each of the basic functionalities that were to be provided with SmartCare based on the table data and the system descriptions in this document.

Three of the four first wave deployment sites (Aragon, Scotland and RSD Denmark) had large, integrated and established legacy HIS systems in which they used the SmartCare project to integrate the GP and Social Care systems to the HIS system for the provision of integrated care amongst the different care givers. The SmartCare project is seen providing interactive combined view web portals with backend software links integrating between large databases or information systems. The focus with the SmartCare project was to provide additional functionality which supported specific clinical aims (Scotland) or rounded out more functionality in their existing integrated platforms (Aragon, Scotland and RSD). The fourth first wave deployment site (FVG Italy) used SmartCare to develop further a previous EU project (DREAMING) and added mobile hardware platform capability and home computer platform capability along with interactive questionnaires services; the system is stand-alone, as there are no large established healthcare or social care ICT systems in FVG with which to integrate.

Most of the second wave deployment sites did not have large legacy health and social care ICT systems to integrate. Therefore they tended to build a separate SmartCare system to provide the integrated functionality or built either the healthcare or social ICT capability and integrated it. The main exceptions to this in the second wave deployment sites were South Karelia (Finland) and Tallinn (Estonia). In the case of South Karelia, they have a robust ICT framework for multi-user access to health services and social services, so SmartCare provided integration between those two care systems. In the case of Tallinn, they have separate national healthcare and social care systems, so SmartCare provided a way to integrate information from the two systems for user based access along with deployment of a home remote monitoring system.

The other second wave sites focused on specific disease management systems such as diabetes for Attica (Greece) and CHF for Noord-Brabant (Netherlands). In the case of Kraljevo (Serbia), outdated isolated healthcare and social hardware and software systems were upgraded and integrated. In all cases, they provide access to the myriad of users identified by the SmartCare project: care recipients, social care worker, informal caregivers, and clinicians.

With regard to the types of ICT used by the deployment sites, they tended to rely upon hardware interfaces that could provide web or service oriented applications. This allowed for application portability to many different hardware platforms: mobile phone, tablet and PC. In most cases any sensor data was either automatically uploaded to a mobile platform or manually entered. If the data was manually entered, it was usually derived from a care recipient owned device. This ‘bring your own device’ philosophy has been expanding as many care recipients own their own mobile phones, computers and in some cases, simple medical device sensors. Scotland and South Karelia specifically designed their SmartCare systems to be able to accommodate this philosophy. If the end-sensor was provided by the SmartCare service, the sensor data was usually automatically sent to the gateway for



transmission to the SmartCare database and application, or to the corresponding healthcare / social system for subsequent viewing by the SmartCare portal / service. In this case, the gateway was for the most part locked down to provide only the gateway application and/or SmartCare services.

The different network technologies used reflected those which were most prevalent in each region. Home-based computers usually used WiFi or GPRS; mobile phones and tablets tended to use 3G/4G GSM mobile network transmission. Short range networking to the home gateway (mobile phone or home computer) was usually provided by BlueTooth, ANT+, or in the case of some home environmental sensors, Z-wave. The short range network transmission was to the home gateway, for long-range transmission to the aggregate system (healthcare, social care or SmartCare specific). In the case of Tallinn, NFC was used as a short range network transmission protocol for user identification with their national ‘smart-card’ ID cards. TCP/IP was used for the network protocols in the computer based systems (and in some cases with the mobile platforms), with 3G/4G used in the mobile based systems.

With regard to the standards used for interoperability, all of the sites used some type of networking standards as described above. For data and messaging standards, most sites used HL7 for messaging interfaces. A few complied with IEEE 11073 for medical device data standards and/or used Continua certified personal health devices, which are compliant to IEEE 11073, HL7 and IHE-PCD data standards, messaging standards and profiles, respectively. Denmark has a robust standard system for messaging and data called MedCom that they have been using for twenty years. It originally relied upon EDIFACT for messaging; however, they are harmonising that with HL7, the IHE profiles and Continua for personal health care device data inclusion into their HIS. In the case of social care data, there were no specific standards identified outside of a messaging construct. Social care data standards are not yet prevalently available for use in many regions.

With the web services provided by the SmartCare implementations, there was a mix of service-oriented protocols used: http, https, sFTP, JSON (for structured data) and REST (for some web transactions). Other document and service standards included pdf (for scanned documents), iCal (for calendaring functions), and XML as defined by ISO 12967 (middleware architecture for system integration).

For security standards, https and SSL were used along with user controlled access at the application level. In all regions, user based access to the SmartCare information was required, with concomitant verification against a caregiver or care recipient master list held at a regional or national level for some sites. Additionally, Scotland employed transport layer security for their web services.

In conclusion, the SmartCare project either provided the integration framework between existing health and social care systems, or built a specific clinical condition based care oriented system which spanned the health and social support requirements for that particular clinical condition. Almost all of the deployment sites used mobile computing technologies and/or web services to provide the SmartCare functionalities. All deployment sites provided integrated information views across the healthcare and social care requirements for the care recipient, with those views being tailored to the particular user.

2.2 Detail

All the details by functional block and by site are presented in the tables Appendix A. These tables take as their starting point the functional blocks defined in deliverable D3.2, and identify for each block and each site:



Status: Provided by:

o existing system;

o modified existing system; or

o newly developed for SmartCare.

System Type, and which parts were newly developed for SmartCare: E.g. separate database application; web portal to application; paper; Vital parameter measurement, telecare / smart home measurements and alarms, educational / training information / content, alerting of out of range parameters, virtual coaching (audio / video).

Systems Interfaced, and which interfaces were developed for SmartCare: E.g. Healthcare Record System; GP Record System; Telehealth / telecare system, call centre, community health and social care record (SmartCare database?); paper based; wireless or wired, a configured device, PC based or mobile handset; interface to hub could be a specific application or web-based.

Name of component(s) in your system that provides the functional requirement: This lists the name of the component or components that perform the functional requirement as it is named in the deployment site system description in the relevant section below; this will allow people reading the table to trace back to the deployment site system description what each component does the functionally.

Communication Methods / Standards Used: E.g. Database based; electronic message based (e-mail, text message, phone call, fax); wireless or wired, a configured device, PC based or mobile handset; interface to hub could be a specific application or web-based; TCP/IP; web-based protocols; wireless (Bluetooth, ZigBee, WiFi, GSM (2G/3G/4G)), wired (PSTN, ISDN).

Data/Messaging Standards Used: E.g. HL7 CDA R2; IHE ITI XCA, XDM, XDE, XDS, XDS-SD, PDQ, PDQv3, PIX, PIXv3; IHE PCC MS, XPHR, CM; IEEE 11073 PHD data standards, HL7 CDA R2; Continua certification; IHE PCD DEC, RTM, ACM; IEEE802.15.4 (ZigBee).

Notes.



3 Prototype FVG (1st wave)

3.1 Introduction, Scope and Objectives

SmartCare Project focuses on frail end-users in FVG, who require integrated health and social care through the coordinated and integrated role of District teams made up of formal and informal stakeholders, including HC/SC professionals as well as Third Sector and caregivers. The project aims to deliver effective, integrated and sustainable care through an ICT-based platform to support a complex territorial HC/SC setting constituted of frail users with complex HC/SC needs. The ultimate goal is to create, assess and implement new models of integrated care in the FVG region, organised as follows.

Enrolled care recipients are aged 50 and above and suffer from a chronic disease (heart failure NYHA II-IV, COPD, diabetes). They have a high probability of complications and/or destabilisation. Multiple comorbidities are the rule in this population. The end user accesses the SmartCare integration infrastructure to look up and enter care related data in a personal record. Information accessible to the end user also includes diagnosis, instrumental and laboratory data, measurements taken by professional caregivers, as well as narrative data, e.g. on lifestyle and social issues notes, activities, goals, emotional self-monitoring, symptoms and contact persons.

Upon consent by the end user, relatives and/or friends have access to the electronic data through the SmartCare integration infrastructure. In principle, they perform all tasks for the end users on the permission the person they care for.

A social care worker employed by the municipality provides home-based social care such as cleaning, food delivery, bathing, shopping, etc., as well as help in the procedures needed to obtain financial support from the municipality / state. They access selected information about the end user’s disease and self-care capabilities through the SmartCare integration infrastructure; the information is provided by other care providers such as hospital staff and GPs. They also leave notes in the end user’s personal record, set up goals together with the patient, and fill out questionnaires (which may be filled out as self reports or on behalf of the CR).

Members of a multi-disciplinary healthcare team (specialists, GPs, nurses, psychologists, physical therapists, etc.) share data from their individual systems and use the SmartCare integration infrastructure to support their workflow across existing unit boundaries. They also view data from all other care providers. Information shared may include lab results, measurements, notes, symptoms, diagnosis, goals set with the patient, activities, questionnaires, reports and self-care indicators provided by end users.

Trained staff and/or volunteers from a non-profit organisation, a citizen association (“active citizenship”) and/or a social cooperative provide support to the patients as far as needed. This includes participation in multi-disciplinary meetings or entering (with end user’s consent) data relevant to end user’s well-being (e.g. home support, social support, emotional changes in well-being, etc.) into his/her personal record through the SmartCare integration infrastructure.

Video conferencing is made available, in selected cases, to end users who live in remote areas.



3.2 Healthcare ICT Infrastructure

Methodology

Testing was carried out with five end users, involving 10 professionals from Health Authority No1 and No5.

The objective of the testing was to verify the efficiency, usability and reliability of the H&S Qualità nel Software Health-Social Platform providing an interface between the end users’ home devices and the central database storing the information acquired through a concentrator called “HUB Hermes”.

Kit delivered to the end users was chosen according to the protocol of medical treatments and monitoring schedules established by healthcare and social service institutions. For the HC part, they included tablets, weight scale (Bluetooth data transmission), glucose monitoring system (Bluetooth data transmission), EEG.

End user’s scheduling built from personal clinical and social chart was an important function to be tested, for it allows planning the activities to be performed, such as in-person or phone interventions, remote alert / reminders for medication intake, or requests for clinical exams based on the data collected through the devices to be forwarded to health and social care services.

Users, Time and Location:

The testing phase lasted from end of July through end of October 2014. Criteria and selection process for the end users participating in the field tests were those defined in SmartCare FVG protocol: age >50 with at least one chronic disease (heart failure, COPD, diabetes mellitus), and with moderate to severe impairment, and social needs identified according to Barthel Index of Daily Living (at least one ability missing). Participants were identified among end users already under the Districts’ health and social care.

Testing phase and training were carried out simultaneously under the supervision of the H&S representative and our SmartCare team HC regional coordinator, along the line of an action-research intervention. At home, on site testing of the HC/SC platform & devices was integrated by ‘classroom’ group testing to identify glitches and further improve the effectiveness and flexibility of the ICT-platform through the direct involvement of all stakeholders. Telephone follow-ups were carried out to monitor day-by-day acquaintance with the platform.

Evaluation:

A check list of main evaluation points was drafted to include: actual functioning of devices, ease-of-use, age-appropriate functionality, flexibility, likeability, psychological impact.

The ICT-based SmartCare platform was well liked by all stakeholders. A problem was raised by an end-user concerning the usability of the electronic weight scale, which was difficult for older service users to use because of slower movement and balance issues. A longer recording time was needed to allow user to step on the scale.

Improvements were made to the platform with the contribution of HC/SC professionals to make it even more tailor-made to the integration needs and goals.



Conclusions:

The SmartCare Integrated Platform fully captures the goals set at the beginning of the project. However, even if the testing phase is over, the evaluation process will continue over the next few months to monitor future developments and adjust the platform to any possible unidentified needs which might arise through its use.

3.3 Social Care ICT Infrastructure

Testing was carried out on five end users, involving 10 professionals Health Authority No1 and No5.

The objective of the testing was to verify the efficiency, usability and reliability of the H&S Qualità nel Software Health-Social Platform providing an interface between the end users’ home devices and the central database storing the information acquired through a concentrator called “HUB Hermes”.

Kit delivered to the end users were chosen according to protocols and monitoring schedules established by their healthcare and social service institutions and for the social care aspects; it includes sensors of various physical and environmental parameters (motion, temperature, humidity, light, smoke).

Users, Time and Location:

The testing phase lasted from end of July through end of October 2014. Criteria and selection process for the end users participating in the field tests were those defined in SmartCare FVG protocol: age >50 with at least one chronic disease (heart failure, COPD, diabetes mellitus), and with moderate to severe impairment, and social needs identified according to Barthel Index of Daily Living (at least one ability missing). Participants were identified among end users already under the Districts’ health and social care.

Testing phase and training were carried out simultaneously under the supervision of the H&S representative and our SmartCare team HC/SC regional coordinators, along the line of an action-research intervention. At home, on site testing of the HC/SC platform & devices was integrated by ‘classroom’ group testing to identify glitches and further improve the effectiveness and flexibility of the ICT-platform through the direct involvement of all stakeholders. Telephone follow-ups were carried out to monitor day-by-day acquaintance with the platform.

Evaluation:

A check list of main evaluation points was drafted to include: actual functioning of devices, ease-of-use, age-appropriate functionality, flexibility, likeability, psychological impact.

The ICT-based SmartCare platform was well liked by all stakeholders. Improvements were made to the platform with the contribution of HC/SC professionals to make it even more tailor-made to the integration needs and goals.

Conclusions:

The SmartCare Integrated Platform fully captures the goals set at the beginning of the project. However, even if the testing phase is over, the evaluation process will continue in the following months to monitor future developments and adjust the platform to any possible unidentified needs which might arise through its use.



3.4 ICT Infrastructure for SmartCare

Figure 1: FVG SmartCare ICT infrastructure

The Health Care-Social Care Platform was specifically devised for the SmartCare project, drawing from the experience of DREAMING project. Thanks to previous experience and to the accurate, team-based assessment of actual needs clearly expressed in the procurement phase, the final platform fully and exhaustively embodies the goals and vision of an integrated, ICT-based platform for a shared, secure, quick, effective and flexible monitoring and self-monitoring. All stakeholders are satisfied. However, monitoring and evaluation will continue in the following months to assess future developments and adjust the platform to any possible unidentified needs which might arise through its use. Training will also continue, as needed, to reinforce skills, deepen knowledge, and ensure compliance and satisfaction of both end users and formal/informal carers alike.



4 Prototype Aragon (1st wave)


There are no changes according to the planning of the integrated ICT infrastructure that will be used in SmartCare in Aragon.

Sharing of information among healthcare and social providers, common identification of users, record of activity and integration of already existing information systems, when possible, are the objectives of the common ICT infrastructure.

4.2 HealthCare ICT Infrastructure

Healthcare ICT Infrastructure in place in Aragon is described on Deliverable D4.1 SmartCare System Integration Architecture (V1), Section 2.

As described in deliverable D4.1, SALUD information systems are available for the SmartCare project, including the users' databases, the unified Electronic Health Record, departmental applications, communication tools and medical help desk.


Social care ICT infrastructure in place in Aragon is described on Deliverable D4.1 SmartCare System Integration Architecture (V1), Section 2.

It is important to note that some social providers have their own tools and ICT infrastructure to register their activity. That is the case of the Red Cross, that makes their ICT described in D4.1 available to the project. Other social providers however do not own information systems, or are unable to open them to the project due to the lack of IT departments; therefore they will be using the ICT infrastructure developed for the project.


For further information on the Aragon ICT Infrastructure for SmartCare, refer to D3.1 Deployment Level Service Specification, D3.2 SmartCare Service Specification, D4.1 SmartCare System Integration Architecture (V1), and D4.2 SmartCare Field Test Report (V1).



Figure 2: Aragon SmartCare ICT infrastructure schema

Figure 3: Aragon SmartCare ICT infrastructure overview



5 Prototype Scotland (1st wave)


The Scottish local partnership areas (LPAs) involved in SmartCare are North Ayrshire, East Ayrshire and South Ayrshire, Renfrewshire and East Renfrewshire, and North and South Lanarkshire, who are responsible for recruitment, service redesign, local business change management and local project manager's line management.

Coordination, programme management, and financial governance for the SmartCare Programme in Scotland: the lead role for this within NHS 24 is being undertaken by the Scottish Centre for Telehealth & Telecare. Additional improvement support is being provided by the Joint Improvement Team (JIT).

Vision: SmartCare aims to improve the health, care and wellbeing of 10,000 people aged 50+ within Ayrshire, Arran and Clyde Valley, by enabling a better co-ordinated and more effective approach to falls prevention and management by focusing on the role that ICT services and applications can play in supporting integrated care.

Scotland agreed to adopt both a prevention and recovery approach to effectively manage our demographic challenges and lifestyles. We will use technology to enable effective care pathways for people (aged 65+) to support health, care and wellbeing ‘at scale’.

In addition, Scotland will also engage with a younger population (aged 50+) and include their ‘circles of care’ to effect change on a preventative care basis, and share experiences with the wider SmartCare collaboration. This is because the 50+ age group is much larger in number than the existing ‘older’ population, they are anticipated to live longer, and are expected to create a significant challenge to existing health and care services if their behaviours and health do not improve. They are also higher adopters of technology, are significant providers of informal care, and may better engage with self management and preventative care approaches.

SmartCare will deliver to 6,000 users, 2,000 carers and engage 2,000 health and care professionals across the identified 7 LPAs in Scotland. Recruitment will be undertaken on a phased basis over the three-year project period, and will be complete by end February 2016.

High level objectives of SmartCare in Scotland

SmartCare will make an active contribution to the Scottish Government's anticipated outcomes for health and social care integration as detailed below.

Outcome 1: People are able to look after and improve their own health and wellbeing and live in good health for longer.

Outcome 2: People, including those with disabilities or long term conditions, or who are frail, are able to live, as far as reasonably practicable, independently and at home or in a homely setting in their community.

Outcome 3. People who use health and social care services have positive experiences of these services, and have their dignity respected.

Outcome 4. Health and social care services are centred on helping to maintain or improve the quality of life of people who use these services.

Outcome 5. Health and social care services contribute to reducing health inequalities



Outcome 6. People who provide unpaid care are supported to look after their own health and wellbeing, including reducing any negative impact of their caring role on their own health and well-being.

Outcome 7. People who use health and social care services are safe from harm.

Outcome 8. People who work in health and social care services feel engaged with the work they do, and are supported to continuously improve the information, support, care and treatment they provide.

Outcome 9. Resources are used effectively and efficiently in the provision of health and social care services.

A SmartCare Implementation Sub Group was established in November 2013, and involves the Programme Manager, local Project Managers and other support resources as appropriate. The group has scoped out the service improvement opportunities and gaps which need to be addressed by ICT in support of better integration and co-ordination of the falls management and prevention pathways. In particular, the group has reviewed how existing technology and platforms can be opened to cross sectoral teams (acknowledging many of the challenges around data governance and the plethora of IT systems within the public sector). It was agreed that suitable technology and platforms need to support:

Increased collaboration across agencies to develop the local falls service to address common aims as set out in national guidance.

Improved data collection which indicates the number of fallers and nature of outcome.

improved ability of service users and carers to better manage chronic health conditions at home and deal with increasing frailty.

SmartCare Service Model

All of the work to date has helped inform the service and technical requirements of the SmartCare Model.

This consists of 4 main components:

Community Connections: SmartCare will support self management and well being by linking staff, users and carers to relevant information, services and products in their chosen community. SmartCare will use the existing Living it Up (LiU) digital platform which currently operates across five geographic regions in Scotland as a cost effective and innovative solution (www.livingitup.org.uk) to link them to their ‘circles of care’. LiU has functionality to support an intuitive information search engine which will pull personalised information, services and products towards the person and their interests based on information captured within a personal profile. Scoping of the relevant information, products and services in relation to falls management and prevention is already underway.

Care Co-ordination: In support of more effective care planning and co-ordination for the individual and their carers, a web-based digital diary / calendar and associated tools will be developed. Initially, the health and/or care professional will work in collaboration with the individual and their family and friends to complete a person centred diary which is then shareable with a range of relevant care providers and the person’s ‘circle of care’. We are exploring the best links with health and care systems in the local areas with a view to supporting service providers to make appointments, send reminders, and share information. The diary will be designed in a way which recognises the challenges for family carers and people living with dementia.

http://www.livingitup.org.uk/



Person Held File (PHF): This digital file will support the person to retain information on their health, care and wellbeing. Updates from GPs, community nurses, social workers, etc., can be stored in the PHF. It is anticipated this can be used in emergency situations, out of hours etc., to help prevent inappropriate admissions to hospitals and care home. The person’s anticipatory care plan (ACP) and Key Information Summary (KIS) could also be stored in the PHF for review and updating over time.

FallsAssistant (Digital Tools for Independence and Re-enablement): Digital tools for self assessment, screening and multi-factorial assessment will be developed to ensure an accurate assessment of need. Service delivery programmes of intervention will be supported by exercise apps using gaming techniques and personal outcomes to sustain motivation and improve confidence.

The Living it Up (LiU) platform has been adjusted to support recruitment of SmartCare users for the go-live date in May 2014. We now have 360 SmartCare users benefitting from the existing platform.

The strategy for the prototype in Scotland is to leverage existing ICT assets and add incremental developments to support the interventions of the SmartCare service.

As a result, re-use will be made of the LiU platform as a self-management hub and existing installations of ICT systems that are used by professionals in health and social care. This includes the Scottish MyAccount as the method of choice for login to online public services.

At a very high level, the architecture is as shown in Figure 4 below. The green colouring (boxes and integration lines) indicates the scope of new development for SmartCare. The rest is re-use of existing infrastructure which itself will also be developed via other initiatives.

Figure 4: Outline architecture for Scotland

Key objectives of this work are as follows:

Provide service users with a wider range of self-help tools to reduce reliance on professional resources.



Provide service users with the ability to manage their records and control sharing of these records to bring about more effective information sharing within their circle of care:

o Capture their own records, such as pen picture and schedule of activities.

o Connect statutory records, such as care plan and visitor schedules.

Maintain alignment with national strategies and architectures in the Scottish public sector.

Provide components with a degree of interoperability that facilitates wider use in a different context.


Health Boards in Scotland have autonomy in selecting their preferred systems; this has resulted in a variety of solutions being used across the seven geographic SmartCare areas, although in some cases the same system was acquired.

In addition, there are a number of national systems that are used by all Health Boards.

Healthcare IT systems in Figure 4 above are line of business systems aimed to support professionals in office locations, in some cases with remote access to support mobile working. This includes, for example, hospital patient management systems and GP primary care systems.

Telehealth systems are remote monitoring systems for deployment in people's homes. For health, deployments are being taken forward through the United 4 Health project.

Information sharing hubs act in effect as proxies that provide access to a range of systems at the cost of a single integration. For example, these can be clinical portals that provide a virtual view across a number of underlying systems. These hubs are discussed in more detail in section 5.4 below.


The situation for social care is very similar to healthcare.

Local Authorities have autonomy in selecting their preferred systems, which resulted in a variety of solutions being used across the seven geographic SmartCare areas.

Social care IT systems in Figure 4 above are line of business systems aimed to support professionals in office locations, in some cases with remote access to support mobile working. This includes, for example, social care case management systems.

Telecare systems are remote monitoring systems for deployment in people's homes.

Local Authorities participate in the information sharing architecture around hubs, primarily to support children's services, with the intention to widen this to all services.

Local Authority websites are various public facing websites in the local areas, which are part of local strategies to deliver public services electronically. In some instances, these sites may simply provide information, but increasingly transactional services can be found. They are mentioned because local SmartCare areas have expressed a particular interest for these sites to play a role in the project.



5.4 Information sharing hubs

The public sector in Scotland is pursuing a strategic initiative to improve information sharing between public sector organisations via information sharing hubs.

A survey of the current deployment of supporting electronic solutions was done in 20131. The survey identified that local areas, via their autonomous approach, have in effect adopted one of five architectural patterns. In the SmartCare area, the following can be found:

Table 1: Information sharing hubs in the SmartCare areas

Geographic area Pattern Solution

Ayrshire (NHS and three Local Authorities)

Integrated Central Store AyrShare

Lanarkshire (NHS and two Local Authorities)

Integrated Central Store Multi Agency Store

Renfrewshire (NHS and two Local Authorities)

Portal Orion Portal

All of West of Scotland To be determined – expect central messaging hub

New initiative

Work is now in progress to pursue a wider vision which would lead to these hubs being developed further, or superseded by a single West of Scotland hub. The following provides a general idea of the hub architecture.

The basic structure is a hub with a number of connected nodes that communicate via an asynchronous request-response pattern.

Nodes are IT systems, and determine internally which members of staff (or roles) have access to information requests and responses. Some nodes can be very basic, such as delivery to an email inbox. This indicates that some request–response cycles can be long running.

A hub can see other hubs as nodes. In that instance, the interfaces must follow a national standard (all hubs talk to each other in the same language). Other nodes may follow different standards and even be proprietary. A hub can be seen as a black box. There is free choice of implementation technology as long as the externally required specification is met.

The most basic hub must have the capabilities set out in Table 2 below. More extended capabilities are possible.

1 http://www.ehealth.scot.nhs.uk/wp-content/documents/Information-Architecture-Review-Final.pdf



Table 2: Core capabilities for information sharing hubs

Capability What it does Comments

Routing Routes messages to nodes who can then decide how to respond.

Various levels of routing intelligence could be implemented. A hub could simply broadcast a request, and broadcast the response. A hub could also remember the originator of the request to direct the response.

Node list Records details of locally connected nodes (including communication and security protocols, local ID schema). Each connected node must have a unique Node ID across the architecture to facilitate direct targeting. Ideally Node Ids are unique across Scotland.

The node list is a means to enable the hub to know where messages can be routed to.

Request-response messaging

Receives requests, returns responses, asynchronous pattern.

Including message receipts and fault messages.

Audit trail Classic recording of events to support hub operations such as help with fault analysis.

5.5 Living it Up self-management hub

The delivery of Living it Up services (Shine, Discover, Connect, Flourish) is supported by a technical platform operator (currently NHS 24) which is in essence an Internet business.

In common with typical internet setups, the platform includes a home portal, a social media presence, content, a database of user profiles, and management tools.

LiU applications are designed very much for a consumer market in the health and wellbeing area. The platform technology reflects this, and is there to help consumers put together a personal set of trustworthy content and tools.

The platform is provided by a set of four core technical partners which in turn build on a number of other internet services for hosting, functionality and content. There is an additional partner which provides the Community Support Office, and within that provides a first line service desk. The whole platform is cloud-based, and can be provided as a service, sustained through revenue funding.

New entrants can use their own applications and content, and link to this platform in order to extend the reach and value of their assets. APIs and policies are provided to support a connection and define rules of participation. SmartCare is an example of one such new entrant.

Social Media Database (users)

ContentManagement

Tools

Portal



In turn, the participation of new entrants adds to the reach and value of the Living it Up platform itself. In particular, additional compelling applications and content will contribute to recruitment and retention of the user base.

The underlying idea is more or less to establish a federal system where participants are largely self-governed and self-directed with their own applications, and choose to adhere

to a set of common rules for mutual benefit2. The Living it Up platform defines policies and guidance for new entrants to ensure that participating applications are interoperable. The rules reflect the brand values of Living it Up as a business, and give the platform operator a degree of authority for decision making and the right to police adherence. The platform also adheres to these rules itself.

The idea of interoperability applies to two kinds of scenarios that are reflected in design principles (refer to Technical Design Principles document):

It should be easy for people to adopt Living it Up using familiar consumer technologies

It should be easy for new entrants to link their applications to the Living it Up platform.

Joining as a new entrant requires an assessment to identify those rules that are relevant. Implementing this subset will then form part of the contract for joining.

Some of the interoperability rules are of a softer nature (outcomes to be achieved, such as browser compatibility); some are more prescriptive (detailed technical specifications for use of APIs). Open standards were adopted where relevant, and chosen by the technical partners to keep the threshold for adoption low so that participants can draw on familiar specifications, patterns and development tools.

5.6 ICT infrastructure for SmartCare

A key element of new development will be a small set of SmartCare applications that offer a person held file to build an integrated record for care provision, a care diary / calendar, and digital tools for self assessment and independence.

This will be in addition to information (content) about events and activities to promote wellbeing, as well as tools that are already present on the Living it Up platform.

The applications are expected to be browser based (HTML5, adaptive design) or simple apps for mobile devices, designed for use by the general public on consumer devices. They will include suitable security for holding sensitive personal information and for user authentication supported by the LiU infrastructure. They are also expected to support integration with systems in the statutory domain.

The Scottish SmartCare concept emphasises that the applications contain information owned by the user, with access by other parties controlled by the user. The person held file and diary in particular will be become the location of an integrated record to allow a more timely and informed response by professionals.

2 Sometimes this is also referred to as an 'ecosystem'.



SmartCare

applications

Person held

file

Diary tool

Citizen

Use

as p

erso

nal to

ol

Contro

l acce

ss

Care professionalAcc

ess

as

perm

itted

Health professional

Acc

ess

as

perm

itted

Friends and family

(informal support)

Acc

ess as

perm

itted

Local statutory

systems

Electronic transfer of summary

messages – avoid duplicate data

entry – build an integrated record

Acce

ss as

curre

ntly

Acce

ss as

curre

ntly

Assessment

tools

Care

plan

Third sector worker

Access as

permitted

Figure 5: Concept of the SmartCare applications

5.6.1 Integration with existing local statutory systems

Integration with existing local statutory systems is intended to avoid duplicate data entry and timely availability of summary information.

As a general policy, SmartCare expects its new applications to support open interoperability standards natively. We may decide to carry out development with successful bidders in the procurement to add open standards APIs to otherwise good products in order to bring them into compliance with this policy.

Further analysis is needed to identify relevant standards, because they depend on details of the summary messages to be exchanged, and whether a fit for purpose standard is available. In the healthcare domain, this may well lead to standards from the HL7 area. For scheduling information, we are aiming for integration via CalDAV. Equally, we will need to consider relevant health and social care integration standards being developed in the UK (including Scotland) between the NHS and Local Authorities.

We identified the existence of information sharing hubs in the partnership areas. Integration with these hubs would ensure that SmartCare is strategically aligned with the Scottish Health and Social Care information sharing architecture. It is also likely to simplify the challenge of integrating with underlying health and social care IT systems because there are only three (potentially just one) hubs with relatively modern technology to take into account. The above mentioned Health and Social Care integration standards would be found on these hubs.

Apart from that, it would be difficult for us to mandate specific standards, because we need more information to identify relevant standards in the first instance. We may find some level of constraint around standards support by what is available from systems that are already deployed in the Scottish environment. In this case, we will seek to use



integration technologies to build adapters rather than attempt to introduce bespoke extension into existing products. In the case of NHS Scotland, we will be able to build on the national investment in an integration product. For Local Authorities, the situation remains unclear at the moment. Some of these concerns and complexities may disappear as a result of relying on the information sharing hubs as a façade to underlying systems.

We have also detected a strong interest by the local partners to involve their Local Authority websites. Consequently, we anticipate some level of integration, for example the sharing of LiU content via APIs and mutual hyperlinks.

5.6.2 Integration with the LiU platform

In order to participate in the LiU ecosystem, the SmartCare applications will need to meet a number of non-functional requirements to ensure interoperability. Some of these will require integration with the platform API. Some are policies that need to be reflected in the way the application is designed and delivered. Details will be determined by stepping through the LiU interoperability use cases that were developed as a reference for any new entrant such as SmartCare.

When integrating with LiU, then in some scenarios (use cases) the compliance with open standards becomes a necessity. However, the scenarios themselves have options; adoption of scenarios, options and relevant standards will depend on the overall proposed solution.

The model in Figure 6 illustrates the potential integration points and other developments that need to be considered when linking a SmartCare application to the platform.

Generic LiU Application

Application

Data

Data Access

Business Logic

User Interface

Potential development to participate

in LiU

LiU platform

APIs

Authentication and

Authorisation Services

Authentication

and Authorisation

APIs

Business

Intelligence APIs

Google

Analytics

LiU UX and brand

Management Information

Services

Services relying on user

data, for example, User

RegistrationProfile APIs

Application APIs

LiU

Application

APIsContent APIsContent Services

Cross-platform support

Figure 6: Potential linkages between SmartCare applications and LiU



As a minimum we expect that

A user can log on to the new SmartCare applications using external Identity Providers via WS Federation. In the context of LiU, this means being able to reuse an existing LiU logon.

There is user friendly navigation that allows a user to move between the SmartCare applications and the rest of LiU in a straightforward manner.

Cross-platform support on mainstream consumer devices.

5.6.3 Elements of development on LiU to support SmartCare

In order to support SmartCare, a number of related developments will take place on the LiU platform itself.

Provision of content aimed at the SmartCare user population.

Adding support for SmartCare management information

5.6.4 Development plan of new components

The development plan takes an incremental approach to developing the new components. The overall roadmap is shown in Figure 7 below.

timeline

SmartCare content development - iterative

Launch

on LiU v3

SmartCare

management

informationSmartCare applications – iterative

Procure

ment

complete

V1

deployed

V2

deployed

Integration with local systems - iterative

...

Now

Figure 7: Roadmap for SmartCare technical development

At the time of writing, procurement is complete and work has started on developing version 1 of:

Person held file.

Diary / calendar.

Self-assessment tool.

This work is planned to complete in January 2015. It is expected to have integration with the LiU platform and a simple form of integration with statutory systems.

All new elements, once deployed as an initial release, will continue to be refined and expanded in response to requirements and priorities.

There will also be ongoing development of the LiU platform as part of its own lifecycle if and when required to support SmartCare, in particular to offer the Scottish MyAccount as Identity Provider.



6 Prototype RSD (1st wave)


The Danish SmartCare service consists of both the existing system of electronic messages provided by MedCom as well as the Shared Care platform that is meant to supplement the existing communication. See Figure 8 below for the entire service.

Figure 8: RSD electronic messaging

The history of MedCom - the Danish Health Data Network (DHDN) - goes back to the late 1980s, when interest in electronic communication among healthcare providers grew. It is a long-term project that enables effective data transfer between several actors of the health service, including stakeholders of the community-based social care system. This national network allows fast information flow in the form of reliable data exchange of EDIFACT or XML-based messages among the respective software systems of the participating healthcare providers. Agreements on interface specifications as well as certification of software compliance with agreed standards and syntax allow for optimal interoperability. Data transfer begins at the point of care for patients and GPs. From there, services that citizens may need access to include pharmacists, diagnostic services and specialist consultation at hospitals, referral to and discharge from a hospital, and transfer to home care and residential care services. Effective access to these by citizens depends on the efficient exchange of messages between health and social care providers and other actors.



Figure 9: Danish Health Data Network

It began with electronic exchange of messages between healthcare professionals via MedCom, nationally agreed, standards (www.medcom.dk). Communications such as prescriptions, referrals, laboratory orders and responses, etc., are exchanged daily. In January 2010, more than 5 million communications were exchanged. Over the years, the repertoire of communications has expanded considerably, and the infrastructure has been extended to include more and more aspects of the healthcare services. Concurrent with this, Internet technology has been adopted, so now communications also include web services, and telemedicine solutions are rapidly being developed. Throughout the development process, efforts have remained focused on giving healthcare professionals access to flexible knowledge searches and internal communications, and, at the same time, enhancing the quality of the services that the healthcare sector is able to offer to citizens.

The Shared Care platform is building on top of this existing infrastructure, enabling the care providers and patients to have access to relevant information in a shared care record at any given time. The Shared Care platform will need to accommodate existing standards, integration to existing systems and databases, and be both fast and reliable on the DHDN.


Today, the healthcare sector uses MedCom messages to share relevant information during the pathway. This works well; however, is not sufficient for complex patients in need of even more coordinated care between sectors. The healthcare actors each receive messages in their individual systems: for the hospital the Cosmic HIS, and for GPs in their individual systems – in all six different systems available. These systems work well for getting an overview of the patient's treatment within their own sector, however not as efficiently when it comes to sharing information across sectors. In additon, the MedCom messages that they send and receive from their individual systems only give them a picture of the patient at that exact time, and does not allow for further information than what can fit in a very limited form. This is why the Shared Care platform has been developed as an always updated and available version of the patient’s information accessible to all relevant care professionals, regardless of their individual systems, either via the internet or via integration from their own systems.

Today when additional information is needed, the care professionals have to contact either the patients themselves, or the other caregivers by phone or safe e-mails, which is more time consuming for everyone. The Shared Care platform will allow both professionals and



patients to get easy access to more updated, relevant and structured data. By also designing the platform to support workflows as described in the Health Agreements and chronic care pathways, the system ensures quality and collaboration across sectors. And allowing patients to get access means they are more safe and involved in their own treatment.

To facilitate the easy use of the platform, integrations are being made to make sure that the care professionals can enter the platform directly from their individual systems without having to type passwords and patient identifications again. Also, the integrations will enable users to copy relevant data either from or to their individual systems, so that they will not need to double register. The integrations and architecture of the Shared Care Platform are described in section 6.4 below.


The social care professionals use individual systems and MedCom messages to communicate with other caregivers from other sectors. The patients would get paper based information, and also carry this between the sectors. In the Danish SmartCare setting, the social care provider is represented by the municipality; this is a large organisation with a wide range of sub-departments with different systems. Not all of these systems can exchange MedCom messages, and therefore they do not have access to this information even though they are part of the treatment of these patients.

Therefore the Shared Care platform provides the social care provider organisation with access to otherwise unavailable information, and also to get more socially relevant data than before. The plan is also to integrate the Shared Care Platform with the largest social care system for those care professionals that use this to avoid double registering, while still allowing other departments to access the platform via the internet.

The fact that patients also have access to the platform allows the social care providers to work closer with them in setting goals and motivating them by making them a more active part of their own disease management.


The Shared Care platform is a web application built on these requirements:

Function inter-regionally and cross-sector, and not be tied by specific systems. The solution supports a lot of different stakeholders by providing data to be fed into and across a lot of different systems.

Support a multiple supplier strategy when it is controlled by a third party. In the same way, maintenance and development of new modules can be done by another supplier.

Focus on the fact that a lot of different actors need to be able to access the platform. This is something that cannot be done to the same extentd if using a client-server system.

To avoid double registrations, and to make it is possible for the involved parties to work within their own systems as much as possible, a system for synchronising all the relevant systems involved is necessary as a part of the solution to ensure that all the systems have the relevant information regardless of where the data originally comes from.



To be flexible, configurable, scalable and portable:

o Flexibility means that the data in the interface is based on roles and the specific course of disease. The solution can also support a multiple channel strategy and mobility. The view of the data has to be configured to specific units – both static and mobile units.

o Configurability means that the view of the data should be configurable to fit specific roles through a portlet-technology. In addition, it will be possible to configure the rules and the patient pathways.

o Scalability means that the solution has to be able to be scaled when the number of patients rises. The solution is based in components that enable development over time, e.g. if a simple module has to be changed to a more advanced module to support new needs. The supplier has developed a wide range of standard components to support flexible patient pathways, modelling processes, rule based engine and integrations that have been well-proven through tests and can function on a large scale.

o Portability means that the solution can function on several IT platforms, and e.g. be moved from Linux to UNIX or Windows with little effort.

Will be based on confidentiality and security regarding patient related data.

Include a number of integrations from the CPR register (Register of Social Security Numbers) to the systems in the hospitals and the systems used by specialists, GPs and also a home monitoring database. Therefore it is a solution with a great deal of integrations. These integrations mostly have to follow the MedCom standards including "the good web service", and are essential to get a solution that can be used cross-sectorially, regionally and nationally.

Deliver IT support to the patient pathways with focus on chronic conditions.

Give access to a common set of data when having cross-sectorial and cross-disciplinary patient pathways.

Be a common tool for health professionals in the different sectors, for patients, and for management.

Support the coordination of the individual pathways, starting with the patient pathways and the support of the decision makers.

Give the patient the opportunity to become an active participant in his/her own pathway, including the possibility of home monitoring.

Be able to integrate with existing and future relevant systems e.g. Electronic Patient Record (EPR) systems, systems used by GPs and the specialists, Electronic Care Record (ECR) systems, laboratory systems, etc.

Has to function as both an integrated tool for the existing EPR, GP, specialist, and ECR systems, and as an individual system for those actors who do not use another relevant IT-system, e.g. the patient.

Use the existing open standards.

Offer a high level of accessibility.

Support a multi-supplier strategy.

Finally the system must support the regulatory requirements in handling personal data.

The model below illustrates the architecture of the Shared Care platform.



Figure 10: RSD architecture of the Shared Care platform

The platform is highly focused on integration with existing systems and databases; the following systems are to be included:

Integration with Cosmic via CloverLeaf (not an individual module because the integration is made through standard integrations in a basic module).

Integration with the systems used by GPs and specialists through Sentinel data gathering.

Integration with the laboratory portal.

Integration with data provided by home monitoring.

Integration with Shared Medication Record.

Integration with the client’s CPR component.

Integration with NemLog-in (a secure and personal access for all individuals).

Figure 11 below illustrates the integration architecture:

Figure 11: RSD integration architecture



Figure 12 illustrates the set-up of the solution.

Figure 12: RSD hardware architecture

The Shared Care platform consists of different elements illustrated in Figure 13 below. There are five different user types, a range of functionality, and a range of possible disease areas in addition to heart disease, which is the current focus of SmartCare, as well as a list of integrations.

Figure 13: RSD Shared Care platform elements (1)

In Figure 14 below, the elements are depicted in a more coherent way.



Figure 14: RSD Shared Care platform elements (2)

The following use case scenarios show two examples of how the data is created by the users. They log into the system either via their individual systems and existing log-ins, or by using their digital signature (for professionals) or Nem-ID (patients and relatives).

Figure 15: RSD Use case scenarios (1)



Figure 16: RSD Use case scenarios (2)



7 Prototype Tallinn (2nd

wave)


In Estonia, healthcare services tend to be delivered mainly by publicly owned hospitals under private regulation and private primary care units. Responsibility for social care rests with more than 200 municipalities throughout the country. According to Estonian family law, relatives are responsible of providing social aid, and the municipality is a secondary care provider.

The relative independence of health and social care providers in operational decision-making represents a key feature of the Estonian health and welfare system. Following a healthcare reform in the 1990's, various efforts have been pursued to modernise the service delivery infrastructure, including the implementation of a nation-wide electronic health information system.

The SmartCare service will build a connection between health and social care providers. The service will be implemented in Tallinn, and addresses older people suffering from chronic heart failure, diabetes or COPD, aged 65 years and above. A study will be conducted with 100 participants (half of them in the control group), five healthcare providers, and five social care providers. About 50 informal carers are also expected to participate.

The main element is the SmartCare portal, where all actions at care recipient’s home (visits, health measurements) will be documented. In addition, other information can be added to the portal. All parties participating in providing care to the CR can have access to the portal and the information it contains. The already existing Social Alarm Services will also be connected to SmartCare. Nurses and social workers who work in the contact centre monitor activity every workday from 8:00 – 16:30.

Figure 17: Estonian SmartCare portal - the main social and medical care components



In the future, the SmartCare service should also be connected to the Estonian National Health Information System (E-Tervis) and Data Registry of Social Services and Benefits (STAR). The SmartCare portal with main components of social and medical care is seen in Figure 17.

The main objective of the SmartCare service is to improve the independence and well-being of elderly care recipients who suffer from different chronic diseases. An improved health situation and a stronger sense of security is expected from using the SmartCare integration infrastructure. Bringing together social and medical care givers, and sharing information about the care recipient between SCP, HCP and I/FCP, is also a very important aspect for creating the portal.


Today, healthcare is provided by hospitals and private primary care units. On-site healthcare is provided by home nurses, but free home nursing is allocated only to patients who are in a difficult condition. Currently, healthcare providers do not have access to the information uploaded by the social care providers, but they do have a national database for information sharing.

Figure 18: View from the E-Tervis webpage

In Estonia, the national database for healthcare is E-Tervis - Estonian National Health Information System. According to the Health Information System Statute, the processor of the Estonian National Health Information System is the Ministry of Social Affairs and the authorised processor is the Estonian eHealth Foundation. The healthcare service providers



have to conclude a contract with the Estonian eHealth Foundation in order to be interfaced with the Estonian National Health Information System. The view from the E-Tervis webpage can be seen in Figure 18.

The health information system is a database that is a part of the state information system. Healthcare related data is processed in this database in order to conclude and execute the healthcare services provision contract, ensure patients’ rights, protect public health and quality of healthcare services, to maintain the registers of health conditions, as well as to manage healthcare3.

The cornerstone for successful Estonian e-solutions is a modern e-state infrastructure, commonly known as “X-Road”. X-Road is an environment that allows the nation’s various e-services databases, both in the public and private sector, to link up and operate together. X-Road is the all-important connection between these databases, the tool that allows them to work together for maximum impact. All of the Estonian e-solutions that use multiple

databases use X-Road4. The X-Road scheme is represented in Figure 19.

Figure 19: Estonia - X-Road set-up


Currently in Estonia, it is mainly relatives (98% of times) who take care of the elderly on-site, doing all the required social care activities. Relatives can register themselves as informal carers and receive a monthly salary (~25 euro per month). There is no ICT infrastructure for these relatives to use for data exchange.

3 The Health Services Organisation Act and Associated Acts Amendment Act, §59¹ section 1

4 http://e-estonia.com/component/x-road/

http://e-estonia.com/component/x-road/



If there are no relatives, or relatives are living far away, the municipality will provide social home help to elderly. In Estonia, the national database for municipality provided social care is STAR. STAR stands for the Data Registry of Social Services and Benefits. This is an information system and central state database. STAR is mainly used by local government social workers and social service providers. Today, STAR has approximately 850 users. The aim of STAR’s implementation is to assist case work, administer and exchange information on clients, and also collect statistical data about the social sphere.

Local Governments are the main users of STAR. In a longer term perspective, all social services provided and paid allowances must be registered in STAR, since this is essential for a better understanding about the help the person / family has received, and to collect statistical information on the services and benefits provided. STAR is connected with several other state databases via X-Road. This facilitates data exchange, and reduces both the need for clients to present documents, and the administrative load of other institutions to issue these documents.

In Tallinn city, a social alarm service (SAS) is also provided, but currently only for 200 elderly. If there is alarm activation, the SAS contacts the elderly person or relatives, and if there is a need, a SAS brigade involving two social workers will make a home visit. The documentation in the SAS is mainly in a paper form, due to the strict requirements for electronic databases.


The main component of the SmartCare service is a SmartCare portal. The portal will combine health measurements, visit reports, diary entries, reminders and documents added by users. The portal is a tool for care providers to have a combined overview of the CR’s health and social condition, and care provided by other actors.

The security of the web based SmartCare software is based on the national ID-card (Figure 20) solution which is mandatory for all Estonian citizens. Using that, all users can securely access the SmartCare portal through the web.

Figure 20: Estonian national mandatory ID-card

Although all the stakeholders have access to the web portal, the main users of the portal are the SmartCare contact centre (SCC) workers. The SCC workers will regularly overview and analyse the measurements and entries done by other stakeholders. They are also the first to react to the alarms. For other stakeholders, access to the infrastructure is needed to upload new information about the care recipient, and to receive a well-documented overview of the measured health status and sensor data both present and past. Through sharing information between the stakeholders, their work can be planned more efficiently.

The general functions of the SC portal are:



Administering users.

Displaying general information about CRs.

Displaying sensors data (tables, graphics).

Management of:

o Diary posts;

o Reminders;

o Medications;

o Reports;

o Documents;

o Alarm thresholds.

Notification in case of alarms.

Storing information about medical and social interventions.

The CR will access the SmartCare integration infrastructure by using the SmartCare equipment installed by the SmartCare technical personnel. The equipment involves the central unit (CU), social alarm button and two different types of sensors – medical sensors and environmental sensors. The medical sensors may involve blood pressure meter, glucometer, weight scale and pulse oximeter. The environmental sensor is the movement detector. An example of a home monitoring set can be seen in Figure 21.

Figure 21: Example of the home monitoring set

The CU is an Android tablet with SmartCare application that receives information from sensors and transmits data. CRs need to access the infrastructure to perform health measurements according to the integrated care plan and answer questions. The general functions of the CU are:

receive and transmit sensors data;

display sensors data;

display reminders (measurements, medications, doctor visits);

enter and display care recipients diary posts;

register on-site interventions.



The CU transmits the data over the web to the web-based SmartCare portal where it is stored. The SmartCare portal is a tool used by medical, social and informal (relatives) care providers. The care providers can register their visits using a smartcard. Smartcard connects to the CU using the near field communication (NFC) technology, and is very common amongst the Tallinn residents because the same card is used to validate journeys in public transport (Figure 22).

Figure 22: Smartcard being used in public transport5

5 source http://tallinncity.postimees.ee/



8 Prototype Kraljevo – Serbia (2nd

wave)


8.1.1 Introduction

Currently there is no electronic communication (through ICT) between:

Institution Health Centre Studenica (HCP - Health Care Provider) and Centre for social work Kraljevo (SCP - Social Care Provider).

Primary healthcare department / GP information system (PHC) and module for admission / discharge of health information system.

CR and/or I/FC (Informal/Family Carer) and SCP/HCP information systems.

Infrastructure includes hardware and software (a set of applications) that enable effective communication and information sharing between Health Centre Kraljevo (HC), Centre for Social Work Kraljevo (SC), and Care Recipients (CR) and Informal Carers (IC).

8.1.2 Scope

Operation planning was developed jointly by Health Centre, Centre for Social Work Kraljevo, and Belit; they prepared the development plan that is described in D4.1. The development plan was then further discussed with subcontracting company MNO. From the beginning, both social and health care providers were involved in operation planning.

8.1.3 Objectives

The main objective is to create an infrastructure to connect HC and SC, and to allow Care Recipients (CR) and Informal Carers (IC) to participate in care and make a connection with HCP and SCP.


8.2.1 Hardware infrastructure

Health Centre has two application servers and one database server. All servers are quite outdated (2 core CPU and 4GB RAM). Servers have their own storage (hard disks) and no external storage (SAS or NAS).

HC has 160 workstations which are quite out-of-date, with an average 6-7 years old. They are mainly single core processors from 7.7-2.2GHz and 256-512MB ddr1.

HC has 25 remote locations that are connected by VPN connection to the main building of the health centre. Some locations have workstations (should be servers) used for synchronised data in case of poor internet infrastructure.

The current hardware infrastructure is shown below.



Figure 23: Kraljevo current hardware infrastructure

8.2.2 Software in operation

Software in operation at Health Centre Studenica:

PHC: primary healthcare information system.

Helliant: software for secondary healthcare.

PHC software is the basis for SmartCare portal; the main functionalities are set out in D4.1

There is currently no interoperability between applications in primary and secondary healthcare.


SC has a legacy system (server and application); all workstation in SC are quite out-of-date. Legacy software will be replaced with new software at national level. All SCPs have had training for the new software, but the new software not yet in operation.


The ICT infrastructure for SmartCare should upgrade and replace old servers, and add new components such as notebooks, smart phones and tablets to support more efficient daily work for HSPs and SCPs, new age communication (video calls), and sharing information. SmartCare will upgrade current information systems in primary healthcare, and implement new services, SmartCare portal, Notification centre services, Mobile application (described in deliverables D4.1 and D3.2)

HC will be the host for all the new services; access for services should be secured by VPN between institutions and HTTPS for external access.



New SmartCare servers will support all SmartCare services, upgraded PHC application, new SmartCare Portal and relevant databases, Notification Centre application and services, services for interoperability with secondary healthcare information system, services for interoperability with mobile devices and mobile application.

Servers will contain:

1. Database server. 2. PHC app server. 3. Smart Care app server. 4. Notification Centre server.

Figure 24: Kraljevo revised hardware infrastructure



9 Prototype South Karelia Social and Health Care District (2

nd wave)


South Karelia Social and Health Care District (Eksote) provides health services, family and social welfare services, and services for senior citizens. SmartCare project´s main purpose is to integrate the EHRs of social and health care services. However, due to the legislation of Finland, the electronic healthcare and social care records cannot be integrated. The aim of SmartCare in South Karelia site is to integrate social and health care services more tightly together. This will be done by integrating SmartCare system with part of the home care services. Remodelling of home care processes will be the main goal of the SmartCare project. Eksote is also implementing video connection between the elderly and social / health professionals, informal carers, and GPs with help alarm.


All healthcare professionals, doctors, registered nurses, practice nurses (included home care nurses) in primary and hospital care have access to the same electronic healthcare record, Effica. The EHR (Effica) includes care documentation, patient management, decision support, order management, medication management, reporting, scheduling, pricing & billing, homecare documentation & management, digital dictation, and eHealth services. In order to improve information access across organisational boundaries, the same electronic patient record system (Effica) is used in the healthcare centres and hospitals of all eight communities of Eksote. Nurses can send messages to GPs, and GPs to specialists. This supports continuity in the care process, and saves time for both patients and healthcare personnel. The home care record is part of the EHR, but also includes some social information, e.g. who has help alarms or video connection, what kind of services this specific customer has (service decisions).


All social care professionals have access to social care records, SocialEffica. Based on the Finland laws, the social care record and healthcare records cannot be integrated. But home care is the exception, where both social and health related data will be stored in the same record (EHR). However, some of decisions are made in the social care record; for example, the decision about the shuttle service for the elderly is made by social workers using SocialEffica.


South Karelia Social and Health Care District has developed, together with four other districts, a local eService platform called Hyvis.fi. The Hyvis.fi portal functions as the interface for the electronic services on the Internet. It allows citizens to obtain reliable health information, assess and monitor their own health, as well as use online services. In addition to providing reliable health information, the service includes risk tests, health history forms, a secure dialogue between a professional and a customer, as well as appointments, self-care and SMS services. The portal supports the citizens' responsibility for their own health, and encourages choices that enhance wellbeing in everyday life. Hyvis.fi for professionals supports professional decision-making, and functions as a communication channel with customers. The Hyvis.fi services will be used to implement national and regional objectives and strategies for the promotion of health and well-being.



The services will be integrated to form a single, functional and secure entity from the point of view of citizens, customers and professionals alike.

Figure 25 below shows how the patient data will be moved between different stakeholders, and how this will tightly integrate the social and health sectors. The SmartCare portal will be integrated into the eHealth platform of South Karelia Social and Health Care District. On the portal, there will be a professional view for both social workers and healthcare workers, while citizens and their relatives will have their own view. During the summer of 2014, the development work on electronic services and care plan (provided by Tieto Oy) has been prepared. The service and care plan will be integrated into Hyvis portal, where it will be seen by the professionals. The remote monitoring system has been developed during 2014. The remote monitoring system is in use, but it will not be integrated into SmartCare system until the deployment of the system starts.

Figure 25: South Karelia patient data flows

9.4.1 Technical adaptation of existing ICT components / systems

Existing components which will be part of the SmartCare are:

Electronic social care record, Effica.

eService platform, Hyvis which includes:

o electronic shared care plan;

o secure messaging between customer / relative and professional.



Figure 26: Hyvis.fi portal



10 Prototype Attica (2nd

wave)


The SmartCare service addresses citizens suffering of diabetes type 2 who are aged 50 years and above.

The care recipient (CR) receives personalised information and guidelines in community settings from social and health care professionals in an integrated manner and in various forms. This includes information on condition and status readily available in community settings (data in electronic format) together with a set of generic and personalised guidelines for the self-management of his/her condition.

A family member receives the same personalised information and guidelines as the care recipient; in addition, a set of guidelines is available addressing the specific problems of the cared for person and how to better manage his/her condition in the community through a personalised care regime involving the family carer.


The CR has access to the following data and information that are stored in electronic format in the Integrated Care Socio-Medical Electronic Record (ICSMER) and the ATTICA portal:

Demographic profile.

Family history.

Absolute numbers and changes in basic biological indicators related to diabetes, i.e. blood glucose levels, AP, HbA1c, body weight, height and BMI, and other basic haematological and biochemical indicators.

Medication related to diabetes.

Referrals to specialists.

Clinical follow up.

Clinical alerts.

Nutritional assessment.

Nutritional diabetes education – cognitive nutritional therapy.

Nutritional follow up.

Anthropometrical alerts.

The CR has access to ICSMER and the portal through tablets that use 3G/4G technology. Telecommunication fees for access to ICSMER and the portal are covered by the site’s budget. It is expected that the CR will benefit by engaging in a continuous learning process that aims to influence a change in their behaviour and habits (lifestyle related) related to self-management of the disease and empowerment.

The informal carer has access to the following information / data in the ICSMER and the ATTICA portal:

Absolute numbers and changes in basic biological indicators related to diabetes i.e. blood glucose levels, AP, HbA1c, body weight, height and BMI, and other basic haematological and biochemical indicators



Medication related to diabetes.

Referrals to specialists.

Clinical follow up.

Clinical Alerts.

Nutritional assessment.

Nutritional diabetes education – cognitive nutritional therapy.

Nutritional follow up.

Anthropometrical alerts.

The informal carer has access to ICSMER and the portal through tablets that are delivered to CR and use 3G/4G technology. Telecommunication fees for access to ICSMER and the portal are covered by the site’s budget.

It is expected that the informal carer will benefit by being able to follow better the schedule of the CR, cooperate more effectively with him/her, but also with the multidisciplinary team and thus decrease the burden of caring.

A diabetologist performs a clinical assessment of the care recipient, provides prescription for medication, recommends other therapeutic approaches (e.g. counselling), performs follow-up of the CR’s health status, and suggests referral to specialists when needed. The diabetologist has the right to veto the social carer’s decision. Through the SmartCare integration infrastructure, he/she accesses the CR’s demographic data, medical history, habits, activities of daily living, symptoms, diagnostic tests, medication, complications, etc., all describing the patient's current condition as well as information on follow up. In addition, he/she receives automatic alerts when patterns in biological indicator measurements indicate deviation from normality, and hence require actions. The diabetologist has access to ICSMER and the ATTICA SmartCare portal through 3G/4G technology.

Additionally, a specialised team of healthcare professionals consisting of nurses, nutritionists and of course the care coordinator assist the diabetologist in his/her task; they are always in contact with the care recipients and informal carers as can be seen in the following picture.

Figure 27: Healthcare pathway




The care recipient has access to the following data and information that are stored in electronic format in ICSMER and the ATTICA portal:

Experiences and personal stories of peers.

Entitlement to social benefits, allowances, medical devices and consumables.

Possibilities for social inclusion activities within the pilot or at Regional level.

The informal carer has access to the following information / data in the ICSMER and the ATTICA portal:

Experiences and personal stories of other carers.

Entitlement to social benefits, allowances, medical devices and consumables for care recipients.

Possibilities for respite care within the pilot or at Regional level.

Social care staff employed by the municipality provides guidance and support to the CR and/or the informal carer regarding maximising social inclusion. More specifically, social workers will be involved in supporting the carer through posting regular information on the portal about allowances, benefits, reimbursable devices, and consumables, as well as information about relevant social activities at the local level, such as healthy eating events, sports events and culture. In addition, they will be engaged real time during work hours in chat rooms with carers and CRs in order to discuss with them issues such as amelioration of burn out, empowerment, etc. Social care staff can also veto decisions made by other parties involved in integrated care delivery; for example, if during the enrolment phase the CR has no interest in engaging in social inclusion activities as mentioned above. The social care pathway is depicted in the following schema.

Figure 28: Social care pathway


SmartCare in Attica consists of a series of applications and modules all combined in an integrated care network targeted at diabetic patients over 50 years of age. The following picture shows the high level architecture of integration between health and social care provision.



Figure 29: High level architecture of integration between health and social care

The list of SmartCare modules is:

1) ATTICA portal dedicated to diabetes patients (http://www.likestinygeia.eu/).

2) Blood glucose tele-monitoring application for smartphones / tablets to be used by patients while at home.

3) Remote access to data by professionals (through the use of smartphones / tablets).

4) Web based Electronic Health Record.

5) Nutritional assessment.

6) Nutritional diabetes education – cognitive nutritional therapy.

7) Nutritional follow up.

8) Anthropometrical alerts.

9) Experiences and personal stories of peers.

10) Entitlement to social benefits, allowances, medical devices and consumables.

11) Possibilities for social inclusion activities within the pilot or at Regional level.

http://www.likestinygeia.eu/



11 Prototype Noord-Brabant (2nd

wave)


The Dutch SmartCare service consists of the cooperation of FLOW, the Integrated Care Centre for Rehabilitation & Prevention of the Máxima Medical Centre, as a set of integrated care services.

This unique medical centre offers fitness, lifestyle, development and science, and develops innovative programmes to prevent a decline in the quality of life of the chronically ill and an increase in hospitalisations.

Figure 30: FLOW, the Integrated Care Centre for Rehabilitation & Prevention

The increasing number of chronically ill patients is one of the major healthcare challenges. In the Netherlands; 4.5 million people have a chronic disease, and 1.3 million people have a multimorbid condition, leading to a significant decrease in the quality of life, and increased healthcare costs and indirect costs to society. This number will increase in the coming years by 50%.

Much is to still be gained in the care of the chronically ill. Patients notably experience (1) insufficient consistency in care, (2) insufficient communication of information, (3) inadequate continuity of care, (4) lack of meaningful consultation between healthcare providers, and (5) an overlap in diagnosis and care in general.

As such, FLOW anticipates this predicted explosion in the number of patients with complex multimorbidity by providing rehabilitation and counselling according to national guidelines. Its multidisciplinary team includes sports physicians, pulmonologists, cardiologists, oncologists, psychologists, specialist nurses, dieticians and physiotherapists.



The centre works closely with doctors and first line paramedics, ensuring personalised treatment care programmes and cost effectiveness. Finally, FLOW also appeals to the empowerment and responsibility of patients to maximise engagement and results.


Within SmartCare, FLOW focuses on cardiac rehabilitation for coronary artery disease (CAD) . The supporting SmartCare portal services are twofold:

At intake, the case manager guides the patient through a multi-module application where the rehabilitation goals, actions, medication and current progress are input and monitored. Both care manager and patient have access to this application, and revisit it during the rehab period.

A tele-monitoring application allows the cardiologist to follow-up patients at home in terms of their medical condition. In the preliminary SmartCare EU study, access to a portal with a real-time view of the patient’s integrated medical data is realised. During the later SmartCare RCT study, secure web-based video communication and viewing of heart rate and accelerometer sensor analysis showing the physical exercise actually performed are added as functionalities.

Figure 31: FLOW Cardio system architecture



Figure 32: Functional architecture

While the current heart failure applications are only the start of the FLOW services, the functional architecture picture above shows the ecosystem capability of facilitating many more services and care providers. The portal enables the care providers and patients to have access to relevant information in a shared care record at any given time.


In the Netherlands, as of 1st January 2015, the local municipalities are responsible for social care. As such, we are working towards an agreement with the Eindhoven regional municipalities to add social care to the ‘flow’ of integrated care.

CAD patients might also use social care that supports the lifestyle change needed, and involvement of social carers is facilitated. They will get limited and personalised access to the SmartCare application. In addition, with the municipalities joining the integrated care process as the social care provider, we expect the social care services to further extend. Within the scope of the SmartCare pilot, patients are motivated to include both health, social and informal caregivers.


The portal’s architecture is based on personal data management with the goal introducing the patient / citizen as a genuine stakeholder, and the ethical integration point of his own (health) data.



12 Conclusions

We have reached the stage when all sites have commenced their operation, or they are ready to launch, hence their integrated ICT infrastructures have been stabilised, and can be fully described in detail. The differentiating factor between D4.6 and D4.3 is the addition of the following deployment sites' contributions:

Tallinn.

Kraljevo.

South Karelia.

Attica.

Noord Braband.

The sites vary considerably in their implementation, as some have decided to focus on specific pathologies (Tallinn with chronic heart failure, diabetes and COPD, and Attica with diabetes); South Karelia and Noord Braband have opted for the generic spectrum of chronic conditions, and Kraljevo pursued integration between primary and secondary health, and social care.

Tallinn and South Karelia have as a common reference point the national infrastructure for both health and social care, enhanced with the addition of electronic health records and smart cards to access all services; however, they differ significantly as to the level of integration, as in South Karelia it is forbidden to integrate health and social care data, with the sole exception of homecare.

Attica, Kraljevo and Noord Braband operate in niches of implementation; these are site specific, and also limited. There is no national ICT implementation system either for social or health care at present; whatever is implemented will remain as a legacy for the local level of operation, hence interoperability and potential upgrade / interconnection issues were strongly taken into consideration.

The common ground for all sites and members of the SmartCare family remains the central portal where access privileges are granted according to roles (care recipient, informal carer, healthcare professional, social care professional, third sector), and information are shared freely according to the specificities and needs of each role for the duration of the project.



Appendix A: Functional Blocks and SmartCare ICT Implementation Overview

A.1 Table: Enrolment and Consent Functional Block

Deployment Site

Status System Type Systems Interfaced Name of component(s) in your system that provides the functional requirement

Communication Methods / Standards Used

Data/Messaging Standards Used

Notes:

FVG Modified existing

System with SmartCare;

Web portal to

application

Mobile handset for operators Patient's enrolment and

initial set of surveys have been inserted for Smart Care

Aragon Newly developed by SmartCare

Web application;

Web portal with access to database.

Healthcare record system;

GP record system;

Telehealth / telecare system,

call centre, community health and social care record (SmartCare database);

Paper;

Configured devices.

Identification of users was key: SmartCare developed the

integration with the already existing databases of the Aragon Government (SALUD database of users and Social Department database of users) to identify uniquely the uses by their id.

Identification of users into the SCP depended on the IS existing and their identification methods. Some SCP identified users by National ID, other’s didn’t have IS, and therefore, the consent and records where paper made.

Linking users between telehealth systems (monitoring of data) and SmartCare users was also developed.

SmartCare Database;

SALUD-BDUS;

SCP integration;

SCP IS;

Database based

Electronic message based

HL7 Newly developed by SmartCare



Deployment Site




Notes:

Scotland Combination of newly developed by SmartCare and modified existing system

See general notes (Appendix A.8)

Modifications to LiU:

- added personal profile fields for user type, pick lists for SmartCare regions, and

promotional content

The new applications are integrated with the modified existing application in order to have a shared user login

New:

1. SmartCare Person Held File and Diary

2. Falls Assistant

Modified:

Living it Up

TCP/IP over any available internet connection

WS Federation, secured via TLS

Functionality of new and modified systems can be accessed from mainstream consumer devices with mainstream browsers

Enrolment to SmartCare is defined as the take up of

one of the new SmartCare applications (SmartCare PHF and Falls Assistant), or take up of the modified LiU system (in connection with SmartCare) by a Care Recipient. This is the new set of tools provided as part of SmartCare. The addition of a person to the falls pathway on an existing system would not be seen as enrolment.

RSD The Shared Care Platform was modified during the SmartCare project period and the project team made sure that it fit the legal and national requirements for consent to be entered into the system. Consent forms for participation in the SmartCare evaluation is done on paper.

The Shared Care Platform is a web portal and the consent is a check box with informational text that the nurse reads to the patient and marks if the patient accepts.

For the messaging MedCom system consent is taken as a given and no further consent is required.

The Shared Care Platform is linked to the Regional social security database as well as the HIS. This means that some information on the patient can be automatically generated from the social security number and the information already registered in the HIS. Information such as name, address, birthday, primary disease, etc.

Shared Care Platform

HIS

Regional social security database

SOR database of professionals and organisations

Web based protocols.

We use the standard called the “good web service” to integrate to i.e. the lab database and the national service platform.

Furthermore we use MedCom standards, such as

FNUX (a Danish HL7 standard) to communicate data to other systems where we do not have data integration (web service) and the XDIS messages to send information to other systems.

HL7, IHE and XDS standards

Patient gives the nurse the information on the first visit to the out-patient clinic and she enters the data for the patient.

Tallinn Newly developed by SmartCare

Enrolment papers, consent form

Paper based Informed consent form Paper form, scanned and e-mailed

-



Deployment Site




Notes:

Kraljevo New developed by SmartCare

Web portal, Notification Centre (msg, reminders, alerts…)

SmartCare database Service for notification HCP/SCP about enrolment and consent. Service for upload document for consent.

Integration between Primary Health Care system and

Secondary (hospital) system (Admission and Discharge)

DB based and web-based protocols

N/A N/A

Attica Developed by SmartCare

Developed by SmartCare Online consent form

Telehealth / telecare system

EHR Database based https, SSL,

South Karelia

Modified existing system with

SmartCare.

Web portal (back ground system) GPS and

video connection (developed in SC)

EHR (existed)

ESR (social, existed)

GPS (developed in SC)

Virtual connection between professionals and elderly (developed in SC).

Effica (EHR)

SocialEffica (electrical social

record)

Hyvis.fi (eService platform)

Database based, paper based

Web service Consent forms are paper based because the using

group of SC in South Karelia - Finland do not use computers by themselves.

Noord-Brabant

SmartCare developed

Ecosystem PaaS platform entailing multi-tenant Drupal portal, ecosystem service bus and other middleware components from www.WSO2.com, NOSQL database for personal data as big data, NodeJS intake App, Remote monitoring single page web app with 3 embedded APIs: RTC video communication, latest EHR info from MMC, and a two sensor overlay graph (heart rate meter + activity meter.

Hospital HER integration (now still using file/folder scanning & downloading, and - depending on vendor commitment – full integration.

Tele-health / home monitoring app, one intake and follow-up app for 360 degree lifestyle & activity, well-being.

Interfaces planned to homecare and social care (Q4 2015)

All web-based – strong security & privacy (see: Kantara UMA + www,.tas3.eu)

- Drupal portal

- 20 WSO2.com middleware components (not all are used)

- Accumulo NoSQL personal data store

- end2end trust assurance

- federated IdM

- Kantara UMA

- real time audit framework – XACML policy framework

- fully pairwise pseudonymisation (instead of public identifiers)

Email

Messages (ecosystem service Bus)

Semantic defined sensor service descriptions, using results from Make it ReAAL CIP project

Events,

Bluetooth, Wi-Fi

Web-protocols.

Integrated wireframe of open standards technical trust, security & privacy protocols as defined in the open architecture of www.tas3.eu. (ws-*, SAML, …)

Kantara UMA specification.

HL7v3; UniversAAL, JSON

Home gateway provided.

Any Wi-Fi / Bluetooth device

(in this case: Actiigraph activity meter en Mio heart rate meter)

http://www.tas3.eu/



A.2 Table: Care Plan Functional Block

Deploymen

t Site

Status: System Type Systems Interfaced Name of component(s) in

your system that provides the functional requirement

Communication

Methods / Standards Used

Data/Messaging

Standards Used:

Notes

FVG mobile handset (modifying existing); IT Platform developed by SmartCare

web portal to application

mobile handset for operators

The care plan protocol is defined inside the Smart Care project

Aragon Newly developed for integrated care.

It did not exist in SALUD, it does exist for RedCross, does not exist for other SCPs

Web portal with access to database;

paper based; Healthcare recorded system;

GP record system

Functional modules Electronic message based

HL7

Scotland Combination of newly developed by SmartCare and existing systems


Social Care Record Systems:

1. CM2000

2. SWIFT

3. local file storage

New:


2. Falls Assistant

See existing systems list (Appendix A.8)


sFTP

JSON (structured data)

iCal (calendars)

PDF (human readable files)


Aspirations for further development:

ability for users to share their person held file section with other users

implement integration via HL7 FHIR

integration with Emergency Care Summary (Health Record System)



Deployment Site

Status: System Type Systems Interfaced Name of component(s) in your system that provides the functional requirement


Data/Messaging Standards Used:

Notes

RSD The MedCom messaging system provides different templates to be filled out and sent automatically at different points of the treatment. For instance the Rehabilitation Plan which is

sent from the physical therapists and nurses from the hospitals to the care coordinator and physical therapists at the municipality. This has not been changed in SmartCare.

In the newly developed Shared Care Platform the nurse enters information in the template made for the visits at the put-patient clinic and the social care sector enters information in their templates. Both can see

information relevant to them from the different sector automatically in the templates and in the Shared Care Platform in general. Some of this functionality has been made by SmartCare

resources.

The MedCom messaging system is made up of EDIFACT messages sent through the health data net.

The Shared Care

Platform is a web based system with access either from the HIS or via the internet.

The patient can see the care plan by logging in with their personal ID card via the internet.

Some information that goes into the care plan in the Shared Care Platform comes from the integration with the HIS, the lab portal or the social security

database.

Both HIS, social care information systems and GPs are able to receive and send MedCom messages.


HIS


Lab portal

MedCom messaging system



Furthermore we use MedComs standards, such as FNUX (a Danish HL7 standard) to communicate data to other systems where we do not have data integration (web service) and the XDIS messages to send information to other systems.


The patients are themselves responsible for the internet connection to see the care plan from their home.


Care plan on paper, separate database for uploading care plan

Paper based, uploaded to SmartCare database

Care Plan Paper form, scanned and e-mailed, uploaded to SmartCare database

HL7 CDA R2; IEEE 11073 PHD data standards; Continua certification

Kraljevo Upgraded on GP software and New developed by Smart

Care

Web Portal (Integrated Care plan,

Task, Activities)

Mob app. (msg, measurement, tasks, activities, calls, reminders)

Integrated Care Record – SmartCare data base

Mob app

SmartCare portal.

Integration between Primary

Health Care system (PHC) and Secondary (hospital) system.

Integration between PHC and SmartCare portal.

Services for Tasks, Activities, plans

DB Based

LAN, Internet (Wi-Fi,

3G)

VPN

Provided by us:

JSON, XML guided by

HISA (ISO 12967) and HL7

N/A



Deployment Site

Status: System Type Systems Interfaced Name of component(s) in your system that provides the functional requirement


Data/Messaging Standards Used:

Notes

Attica Modified an existing system with SmartCare

Added questionnaires on mobile application and web portal

Telehealth / telecare system Questionnaires

EHR / Mobile app https, SSL,

South Karelia

Modified existing system with SmartCare.

Care plans in EHR.

GPS and virtual connections added to

care plan (developed by SC).

EHR (existed)

eService platform (shared care plans)

Effica (EHR)

Hyvis.fi (eService platform)

Database based Web service Care plans are able to see in eService platform by clients and relatives (shared

care plans).

But the end user group do not use computers, only relatives.

Noord-Brabant

SmartCare developed Ecosystem PaaS platform entailing multi-tenant Drupal

portal, ecosystem service bus and other middleware components from www.WSO2.com, NOSQL database for personal data as big data, NodeJS intake App, Remote monitoring single page web app with 3 embedded APIs: RTC video communication, latest EHR info from MMC, and a two sensor overlay graph (heart rate meter + activity meter.

SmartCare Developed Workflow of intake and follow-up, including home monitoring sensor app.

NodeJS – MySQL web-application

MySQL, NodeJS application

Personal data is send

to NoSQL based PDS

Web -based

A.3 Table: Onsite Provision of Care Functional Block

Deployment Site




Notes

FVG mobile handset (modifying existing);



Z-Wave protocol Kit composition ( in terms of medical devices), number of measures and thresholds for each patient

are defined in Smart Care project



Deployment Site




Notes

Aragon Newly developed by SmartCare

Separate database, application, vital parameter measurement. Social alarm service was

modified as a part of SmartCare service

Telehealth/ telecare system, wireless data transport, tablet with SmartCare application

SmartCare equipment Bluetooth, GSM HL7 CDA R2; IEEE 11073 PHD data standards; Continua certification

Informal carers can use their own smartcard, if they don’t have it, they will be provided with one

Scotland Existing systems See general notes (Appendix A.8)

n/a See existing systems list (Appendix A.8)

TCP/IP over internal LAN/WAN

n/a none

RSD The hospital staff and the GPs are able to see the Shared Care Platform via links from their own systems (HIS and GPs system) and data is also automatically transferred from their systems and into the Shared Care Platform. Social Care staff is, for now, forced to log-in to the Platform itself to see and enter information. The integration to the HIS

has been made in the SmartCare project period.

MedCom messages can be seen from all the professionals’ systems as this is a

requirement.


The Shared Care Platform is a web based system with access either from the HIS, the GPs system or via the internet.

Some information that goes into the Shared Care Platform comes from the integration with the HIS, the lab portal or the social security database.



HIS

GP Systems (Sentinel)





Furthermore we use MedCom standards, such as FNUX (a Danish HL7 standard) to communicate data to other systems where we do not have data integration (web service) and the XDIS messages to send information to other systems.


The hospital staff and the GPs are able to see the Shared Care Platform via links from their own systems (HIS and GPs system) and data is also automatically transferred from their systems and into the Shared Care Platform. Social Care staff is, for now, forced to log-in to the Platform itself to see and enter information. The integration to the HIS has been made in the SmartCare project period.

MedCom messages can be seen from all the professionals’ systems as this is a requirement.


Care plan on paper, separate database for uploading care plan

Paper based, uploaded to SmartCare database

Care Plan Paper form, scanned and e-mailed, uploaded to SmartCare database

HL7 CDA R2; IEEE 11073 PHD data standards; Continua certification



Deployment Site




Notes

Kraljevo New developed by Smart Care

Web Portal Integrated Care Record – SmartCare data base

Mob app.

Services for measurement, tasks, activities, calls, reminders.

DB Based

LAN, Internet (Wi-Fi, 3G)

VPN

Provided by us:

JSON, XML guided by HISA (ISO 12967) and HL7

N/A

Attica newly developed by Smart Care

modification to an existing system

Mobile application EHR / Mobile app https, SSL,

South Karelia

Modified existing system with SmartCare.

Access to EHR database. Web portal to GPS and video connection back ground system.

Healthcare record system (3G,4G).

Effica (EHR)

Hyvis.fi

Database based (EHR), wireless 3G/4G/WiFi (GPS, EHR, virtual connection) or wired if necessary (virtual connection) connections. Web based

protocols + VPN encryption.

Web service

Noord-Brabant

Partly provided by Existing system.

Additional service provided by SmartCare.

Web portal, Statistics from home measurements, virtual coaching, Statistics from Training information

From Health care record system (Hospital), To and from Video communications, Wireless, wired, configured device, PC

PDS, Portal, Sensor (Actigraph, Polar, Mio), Social communication platform.

Database, PC based, TCP/IP, HTTPS, ANT+, Bluetooth, Wifi

IEEE11073, HL7 v3;

Patient uses their own device or a pre- configured tablet will be issued

A.4 Table: Remote Provision of Care and Support Functional Block

Deployment Site




Notes

FVG Mobile handset (modifying existing); IT platform developed by SmartCare. The call centre protocol for each kind of alarm or call is defined in Smart Care Project

Alerting of out of range parameters, virtual coaching (audio / video) – developed by SmartCare; web portal to application

Mobile handset for operators

Z-Wave protocol We inserted Zwave protocol for SmartCare to interface required environment sensors



Deployment Site




Notes

Aragon Modification of existing system


Vital parameter measurement;

paper;

alerting of out of range parameters,

telecare / smart home measurements and alarms,

educational / training information / content,

Interfaces with SALUD IS (as the health agenda or telemonitoring app, Healthcare Record System;

GP Record System).

Interfaces with Red Cross

IS

Interfaces with SCPs recording (paper / or PC based databases)

Telehealth / telecare system, call centre;

wireless or wired, configured device, mobile handset;

HIS, EHR, OMI, telemonitoring portal

Database based; Web based protocols; TCP/IP; wireless( Bluetooth, Wifi, GSM), wired; wireless or wired mobile handset,

HL7 CDA R2;

IEEE 802.15.1;

Scotland Combination of newly developed by SmartCare, modified existing system and existing systems


Modifications to LiU:

- added SmartCare-related self-help content (articles, local resource directory entries)

(Falls Assistant and LiU are involved to provide access to self-help resources online)

Local support resources directory (ALISS)

New:

1. Falls Assistant

Modified:

Living it Up

See Existing system list ((Appendix A.8,Telecare systems only)


Telecare systems may still rely on PSTN

REST-based web service to the support resources directory


Aspirations for further development:

- motivational and educational games in the Falls Assistant



Deployment Site




Notes

RSD The patient can enter the Shared Care Platform from home by using their personal ID-card. Staff entering the home can also access

the Shared Care Platform via the internet and their digital signature.

A home monitoring solution connected to the Shared Care Platform is being tested at this point and has been partially funded by SmartCare resources.

The patients do not have access to the MedCom messages.

The Shared Care Platform is a web based system with access either from the HIS, the GPs system or via the internet.

The patient can see the

information and enter values manually by logging in with their personal ID card via the internet.

We will use Continua certified devices and communicate via PHMR-standards.

We also have an integration to the national KIH database


(Continua devices)



Furthermore we use

MedCom standards, such as FNUX (a Danish HL7 standard) to communicate data to other systems where we do not have data integration (web service) and the XDIS messages to send information to other systems.


The patient can enter the Shared Care Platform from home by using their personal ID-card. Staff entering the home can also access the Shared Care Platform via the internet and their digital

signature.

A home monitoring solution connected to the Shared Care Platform is being tested at this point and has been partially funded by SmartCare resources.

The patients do not have access to the MedCom messages.


Separate database, web-portal to application, alerting of out of range parameters

Call centre, PC based, SmartCare portal

SmartCare portal Web-based portal HL7 CDA R2; IEEE 11073 PHD data standards; Continua certification

Stakeholders need to use their ID-card to log in to the SmartCare portal


Web Portal and mob app.


Mobile app.

Services for measurement, tasks, activities, calls, reminders.

DB Based


VPN

Provided by us:


N/A

Attica existing system New mobile application Mobile application EHR wireless Bluetooth, SPP

South Karelia

Modified existing system.

Virtual connections between clients and professionals or relatives. Also connections between nurse and GP.

EHR

Virtual connections (developed by SC)

GPS (developed by SC)

Effica (EHR)

Hyvis.fi

Database based, virtual connections (3G/4G/wired connection), GPS (3G/4G)

Web service

Continua certification

Remote monitoring available in Hyvis.fi, but end users do not use computers/internet by themselves. Remote monitoring is “bring your own device” based

Noord-Brabant

Fully provided by SmartCare

Web portal, home measurements, virtual coaching, Training information

From Health care record system (Hospital), To and from Video communications, Wireless, wired, configured device, PC

PDS, Portal, Sensor, (Actigraph, Polar, Mio) Social communication platform.

Database, PC based, TCP/IP, HTTPS, ANT+, Bluetooth, Wifi

IEEE11073, HL7 v3 Patient uses their own device or a pre- configured tablet will be issued



A.5 Table: Documentation of Care Functional Block

Deployment

Site

Status System Type Systems Interfaced Name of component(s) in


Communication Methods /

Standards Used

Data/Messaging

Standards Used

Notes

FVG IT Platform for integrated care and documentation collection developed by SmartCare


community health and social care record (newly developed by SmartCare)

Aragon Newly developed (Integration of agendas from SALUD, not existing IS in SCPs)


Interfaces with SALUD IS (Data included on the EHR (Healthcare &GP Record System).

EHR, OMI TCP/IP; HL7 CDA R2



Social Care Record Systems:

1. CM2000

2. SWIFT

3. local file storage

New:


2. Falls Assistant

See Existing systems list (Appendix A.8)


sFTP

JSON (structured data)

iCal (calendars)

PDF (human readable files)


RSD At each point in the treatment plan there is a template to be filled out either via MedCom

messaging or in the Shared Care Platform, where the information is more specific to the chronic disease. MedCom messages are automatically sent via EDIFACT and this system

has been running for many years. The information in the Shared Care Platform is viewable for the other sectors if it is relevant for them in both their templates and in the platform itself. Information in particular for the social care sector was largely developed and funded by the SmartCare project.

The MedCom messaging system is made up of EDIFACT messages

sent through the health data net.

The Shared Care Platform is a web based system with access either from the HIS, the GP

system or via the internet.

The patient can see and enter information by logging in with their personal ID card via the internet.

Some information that goes into the Shared Care Platform comes from the integration with the HIS,

the lab portal or the social security database.



HIS

GP System (Sentinel)

The lab portal




Furthermore we use MedCom standards, such as FNUX (a Danish HL7 standard) to communicate data to other systems where we do not

have data integration (web service) and the XDIS messages to send information to other systems.


.


Separate database for uploading documents and diary entries

SmartCare database SmartCare portal, documents upload, diary

Web-based portal HL7 CDA R2; IEEE 11073 PHD data standards; Continua certification




Deployment Site




Notes

Kraljevo Upgraded PHC and New developed by Smart Care

Vital parameter measurements, notification and reminders


Mobile app.

Services for review of the plan and plan implementation and also tasks.

DB Based


VPN

Provided by us:


N/A


New mobile application, WEB

portal

Mobile application EHR Database based, GSM, WiFi https, SSL,

South Karelia

Modified existing system. Separate database (EHR)



Effica (EHR) Database based. available at office and also at home visit (3G,4G).

Noord-Brabant

All transactions are logged & audited.

Planned: patient journey app.

See left See left See left See left See left See left

A.6 Table: Assessment and Re-assessment of Care Functional Block

Deployment Site




Notes

FVG mobile handset (modifying existing);



For Smart Care, we added a lot of surveys for data not collected from medical devices

Aragon Newly developed Web portal with access to database;

Interfaces with SALUD IS (Data included on

the EHR (Healthcare &GP Record System).

Functional modules Database based;



(Falls Assistant is involved via its functionality to do a self-assessment)

n/a New:

1. Falls Assistant

See Existing systems list (Appendix A.8)


n/a Functionality of new and modified systems can be accessed from mainstream consumer devices with mainstream browsers

Aspiration for development:

Integration between Falls Assistant and PHF



Deployment Site




Notes

RSD This is mostly handled in the MedCom messaging system where referrals are also sent. Typically after the first year where the patient is in the care of the GP.

During the first 3-6 months the patient is in contact with both the health and social care staff regularly and they can see information in the Shared Care Platform at any time. Parts of this information were developed in the SmartCare project.


The Shared Care Platform is a web

based system with access either from the HIS, the GP system or via the internet.

Some information that goes into the Shared Care Platform comes from the integration with the HIS, the lab portal or the social security database.



HIS

GP Systems (Sentinel)

Lab portal




Furthermore we use MedCom standards, such as FNUX (a Danish HL7 standard) to communicate data to other systems where we do not have data integration (web service) and the XDIS messages to send information to other systems.



Separate database for uploading diary entries

SmartCare database SmartCare portal, diary Web-based portal HL7 CDA R2; IEEE 11073 PHD data standards; Continua certification



SmartCare portal (based in Care Plan and Tasks)


Vital parameter measurements via SmartCare portal and mobile app.

DB Based


VPN

Provided by us:


N/A

Attica newly developed by

Smart Care

New mobile application Wireless EHR / Mobile app Database based, GSM,

WiFi, ISDN

https, SSL,

South Karelia

Modified existing system. Separate database (EHR)

RAI (Resident assessment instrument/MDS minimum data set), exciting before SC

Effica (EHR)

RAI

database based, 3G, 4G Web service

Noord-Brabant

Dual test with and without system

Cardiologist – PhD is graduating on this project with comparative study



A.7 Table: Exit from SmartCare System Functional Block

Deployment

Site

Status System Type Systems Interfaced Name of component(s) in


Communication Methods /

Standards Used

Data/Messaging

Standards Used

Notes

FVG

Aragon Newly developed Web portal with access to database;

Notifies the exit of the program to GP Record System.

Functional modules TCP/IP; HL7

Scotland Combination of newly developed by SmartCare, modified existing system


n/a New:


2. Falls Assistant

Modified:

Living it Up


n/a Functionality of new and modified systems can be accessed from mainstream consumer devices with mainstream browsers.

Exit from SmartCare is defined as a Care Recipient stopping to use all of the new and modified systems

RSD The patient can at any given time choose to be taken out of the SmartCare evaluation or the Shared Care Platform. At this

point their consent is withdrawn and their data is made inaccessible for the professionals. This functionality was developed during the SmartCare project.

The Shared Care Platform is a web based system with access either from the HIS, the GP

system or via the internet.

Shared Care Platform Web based protocols.


Furthermore we use MedCom standards, such as FNUX (a Danish HL7 standard) to communicate data to other systems where we do not have data integration (web service) and the XDIS messages to send information to other

systems.



Separate database for uploading diary entries

SmartCare database SmartCare portal, diary Web-based portal HL7 CDA R2; IEEE 11073 PHD data standards; Continua certification



SmartCare portal, PHC

SmartCare data base Removing/Archiving CR from SmartCare data-base.

DB Based


VPN

N/A Exit is applicable only if CR pass-away or willingly go out


Web portal Telehealth / telecare system

EHR Database based, GSM, WiFi, ISDN



Deployment Site




Notes

South Karelia

Modified existing system. Separate databases EHR



Effica (EHR)

Virtual connections background system

GPs background system

Database based. Available at office and also at home visit (3G,4G).

Web service

Noord-

Brabant

Volunteer in/out

System logout

Data is kept as user

data in PDS

Kantara UMA : user

managed data

Kantara UMA driven http/ rest web This project is first part of

the user’s Life Management Ecosystem.

A.8 Additional notes for Scotland

Enrolment to SmartCare is defined as the take up of one of the new SmartCare applications (SmartCare PHF and FallsAssistant), or take up of the modified LiU system (in connection with SmartCare) by a Care Recipient. This is the new set of tools provided as part of SmartCare. The addition of a person to the falls pathway on an existing system would not be seen as enrolment.

Similarly, exit from SmartCare is defined as a Care Recipient stopping to use all of the new and modified systems.

Existing systems

SmartCare relies on existing line of business systems for some functional blocks (in addition to the new and modified systems). These are shown under the shorthand of 'Existing systems' and include a set of Health and Social Care Line of Business systems that support the professional workflows. (User types HCP, SCP and TSCP).

The mainstream of these systems includes

Social Care Record System

o CM2000 o SWIFT o Care First o SWISS

Telecare System

o PNC6 o Jontek o SAM



GP Record System

o EMIS o Vision

Health Care Records System (hospitals)

o TrakCare

Telehealth System

o None so far

All

o local file storage

The System Type for existing applications is always a 'database' application. This can take various forms. Some are web-based, some have a 'thick' client.

These existing systems may be integrated with each other to a degree via information sharing hubs, but no modifications were made for SmartCare. The integration typically follows proprietary approaches involving secured web services or sFTP. In some areas HL7 v2 is used. This type of integration is not shown in the tables above to draw a clearer distinction with the development that was achieved in the SmartCare project.

New developments by SmartCare

These new developments are aimed at the user types Care Recipient and Informal Carers (CR and I/FC).

The System Type for the 'new development by SmartCare' is a 'web portal' and 'database', plus an additional integration component that provides

connectivity to records in statutory systems. There are two such web-based applications6. Some functional blocks are supported by both applications. A few building blocks are supported by only one of these applications.

The information sharing hubs mentioned in section 5 were not made available as existing systems. This was discovered as the project progressed; SmartCare responded by developing a new simple hub for the purpose of the project. Instead of linking to Information Sharing Hubs as originally

6 SmartCare Person Held File and Diary: Stores a person held file and calendars. Functionality to view information (own and shared by other users), enter and edit personal information, share the calendar, transfer information in from other connected (statutory) systems.

FallsAssistant: Stores self-help resources, assessment questionnaire and personal action plans. Functionality to browse resources, self-assessment of falls risk and to create and manage a personal action plan.



intended, SmartCare now needs to link directly to the underlying systems. In the interest of simplicity and given the terminology of the tables above, the SmartCare Information Sharing Hub is presented as part of the SmartCare PHF application.

Modified existing system

There is only one such system, Living it Up (LiU). It is used by all SmartCare user types for enrolment, login and publication of/access to support resources.

System Type is a combination of 'web portal' and 'database'.

D4.6 Integrated ICT Infrastructure Version 2€¦ · 4.2 HealthCare ICT Infrastructure 17 4.3...

Documents

Transcript of D4.6 Integrated ICT Infrastructure Version 2€¦ · 4.2 HealthCare ICT Infrastructure 17 4.3...