Technology Integration in Home and Remote Care Services

Transcription

1 Technology Integration in Home and Remote Care Services - a case example of local development activities within national framework 1 01/09/2017 Jarkko Lumio,

2 Background and Need for change in technology-aided Home and Remote Care processes and technological integration required 2 01/09/2017

3 Background for the Need to Develop Technologyaided Processes in Home and Remote Care The amount of wellbeing technology used in home care services is in rapid growth. It means measuring the status of vital functions, physical performance, psyche and social interaction. remote care and self-management of health & increased safety Following slides describe: Possibilities opened by technology for high-quality and cost effective services through two study-based examples: 1. Cost of services for the elderly, case Tampere (slide 4) 2. Cost of service path of a heart care patient (slide 5) Wellbeing and telemonitoring technology used and / or tested in Tampere (slide 6) Current state of home care technology (slide 7) Technology vision for home care and the sought service system (slide 10) 3 19/09/2017

4 Net cost* of treatment for the city, cost elements Facilities / accommodation Medication Biness case 1. Services for the Elderly in Tampere Home care clients Home care clients approx / year, cost of care visits 30 M / year people over 65 YO Home care clients use 1/3 of hospital days of the elderly; yearly cost 30 M (total 90 M ) Cost savings available from care visits and hospital stays; cost impact same for both (total approx. 60 M ) Hospital stays for other than Home care clients 4,2 days/year (60 M ) Outpatient services Hospital stays Meals Treatment State share of costs Customer fees deducted from treatment costs Cost quartiles of the Clients Clients per quartile Length of hospital stay is largely dependent on the quality of care in post-discharge site of care Cost savings: IF hospital use can be reduced by 1 day/year Average price of a hospital day 400 1day X elderly people = 16 M Also under 65 year olds use hospital services: (For example 2x16 M = 32 M ) Largest cost savings available from shortening of hospital stays

5 EVERYDAY LIFE MORE DIFFICULT Business case 2. Service Path of a Heart Care Patient (Tampere University Hospital and the City of Tampere) COMMUNITY CLIENT Costs now Costs in ideal model Savings 20 % = 29 patients Total savings SELF-HELP CLIENT Costs now Costs in ideal model Savings 60 % = 87 patients Total savings EUR EUR EUR EUR EUR EUR EUR EUR MORE DEMANDING CARE NETWORK CLIENT Costs now Costs in ideal model Savings 10 % = 15 patients Total savings CO-OPERATION CLIENT Costs now Costs in ideal model Savings 10 % = 15 patients Total savings EUR EUR EUR EUR EUR EUR 100 EUR EUR NB: Time and travel costs not taken into account The primary health care unit of Tampere University Hospital and Non- Institutional care of the City of Tampere compared heart patient s alternative service paths and their costs Sample: 146 angioplasty patients, in years after event Costs Now EUR In ideal model EUR SAVINGS EUR Client segmentation and adapting service path based on need allow large savings care according to client s needs or wishes Prerequisites for benefits: 1) Existing bearings 2) Implemented bearings 3) Decision-makers and management committed to make changes in operation

6 Experiences from remote and/or wellbeing technology in Tampere Tampere has experience in using remote and wellbeing technology, and has thus gained an understanding of how operation and technology should be developed to realise the potential benefits Using: Emergency phone (Stella) allows user made emergency alerts Digital health desk services increase with Digital support for self-management of health project (ODA) Outpatient services in home care with a video phone (VideoVisit) two-way image and voice communication Automatic medicine dispensing service and telecare system (Evondos) sends messages to personnel if deviations in medicine taking 6 Testing: Indoor activity monitoring (9Solutions) allows emergency alerts and activity level change notifications Locator bracelet (Everon and Navigil) alerts when client crosses preset limit Bracelet collecting information on client wellbeing (Vivago Domi) notifications of changes in condition PEF-measurement used in asthma home monitoring (Elisa) Tiina Karttunen Home blood pressure monitoring (Elisa)

7 Current State of Home Care Technology Technology Firms Products Standards Service Providers Tampere Region Hospital District 3rd Sector Operator Client Guidance Infra Platform Integrator Ltd. Municipality City Home Care & Housing Services Hospitals EMERGENCY UNITS: Acuta PSAP / ambulance Tampere Region Hospital District Hatanpää, Rauhaniemi Night patrol / 3 in Tampere until 21:00 Ltd. For example Violakoti or Kuusela

8 Open Definition and its Implementation SMARTTAMPERE.FI #SMARTTAMPERE

9 Realising the Benefits of Technology Tampere has found through experience and research: Reaping the benefits of technology requires open-minded re-design of operational processes and technology that enables renewing them Introducing separate technology solutions does not suffice on the contrary, it might make operation more difficult and increase costs Solution was sought by defining a tool, i.e. a technology that allows introduction of new ways of working, which aim for better quality and more cost-effective care - example: arranging 24/7 emergency services for outpatient care An open definition process was carried out in co-operation with companies that answered the request for information published in a channel for public procurement (Hilma)

10 Problem to be Solved / Request for Information In order to curb the cost growth of Social and Health Services and to improve their quality, it is necessary to provide these services more extensively in the client s home environment. In the service system, sectorised and segmented service providers and technically incompatible technologies need to be fused into a whole that is coherent for the client and adaptable from the point of view of an individual service provider. Different service providers services must be combinable into entire service paths. Also, in order to ensure client s right of self-determination, the technologies used in different services have to be compatible, making in-home service provider replacement possible without the need for the client to give up value-added service they use because the service path would require other type of technology. The aim is to collect and combine data describing the vital functions, physical performances, status of psyche and social interaction of a person, gathered with diverse measuring devices, into a whole utilisable in various ways

11 Logic Behind the Definition Document SMARTTAMPERE.FI #SMARTTAMPERE

12 Expert interviews - How to avoid hospitalisation - Why cannot be discharged - Continuity of forms of treatment - Is service and care plan up to date - Support from health care personnel - Support for client s self-management of health Use cases - Self-care - Domiciliary care - Discharging from hospital - Acute treatment Constitutes an understanding of customer needs and derived requirements at the top level. VISION What is wanted to be achieved Logic architecture preliminary view Definition of architecture Initial data Other projects - ODA - Apotti and UNA - Kanta, Kvarkki - OmaKanta What is the project/system? How the project/system ids relevant to current definition work and to what extent work done there should / could be utilised? Constitutes an understanding: - KaPa - Isaacus - KODA - Virtual Hospital - whether project is related to current digital home care definition - What components and features it offers and when? An understanding of targeted architecture and its description is formed 1) Abstract description of the vision, where architecture is described on target level: grouping, abstract APIs, everything without manufacturer s or product names 2) Description of outlined architecture, where the vision is focused to medium term, more specific composition and APIs are introduced, but still without naming manufacturers/products or their versions. 3) Implementation level architecture for first stage implementation. On this level, solutions/products and their versions are named. This could be the first stage of implementation, where existing or already developed products are used, a part of the integration platform is implemented, and on top of it added-value services (e.g. patient s overall status and/or alerts).

13 Starting Points of Architecture Design 1/2 Modular multi-provider architecture There can be several home and remote care solution providers (platform defines integration APIs for future systems) Added-value services can be provided by many different providers There can be one or more providers for the Integration platform Architecture relies on existing and developed systems/solutions always when viable (e.g. Kanta and KAPA). Integration platform functionality as thin as possible, avoiding overlapping with functionality offered by other (national) systems If functionality of other systems is not available within desired implementation schedule, information flow between the Integration platform and sought home and remote care system is resolved, if needed, with Platform integration API, however so that in later versions of the system data is stored to those EHR/PHR systems that are relevant for the purpose.

14 Starting Points of Architecture Design 2/2 Architecture supports continuous development and evolution, and it must be open to support multi-provider environment Home and remote care systems will evolve and change over the next few years. The Integration platform must allow connecting new systems and changing connections to always meet the needs. Following principles for open architecture APIs between the Integration platform and value-added services as well as home and remote care systems are, in principle, open Open APIs here mean interfaces with roadmap, development and maintenance established in a multi-provider environment

15 Starting Points of Definition Work SMARTTAMPERE.FI #SMARTTAMPERE

16 Service Provider Needs for Realising Benefits of Technology 1/2 All devices and services provided for the client can be connected to the service provider s (public/private) own ERP and/or production control system. Technical compatibility with centralised systems used by the service provider must be ensured by specified standards (technology both from the service provider or acquired by the client) Alerts and messages from all technology used must be received at a single point. Medical alarms are to be received immediately through a single channel, the situation determined via remote connection, telephone or safety bracelet voice communication, and if needed, designated person sent to the client/patient to handle the situation. The service provider must be able to handle the data available from all devices and services, and with this information to draw conclusions for example pertaining to service structure design or prevention (leading with knowledge) Tiina Karttunen

17 Service Provider Needs for Realising Benefits of Technology 2/2 The same in-home service (from operator Y) can be integrated into a service path that is under the responsibility of (or sold by) different service providers (operator X) for example by subcontracting. As an example, length of hospital stay is reduced if telemonitoring enables the treatment of eligible patient groups to be completed at home. Service provider must offer device and user support effectively to everyone concerned, even if the client would use devices connected to different service systems or products. Possible user groups include clients/patients, their family, persons acting on their behalf, legal guardians, as well as health and social care professionals. Everyone must be guaranteed, if necessary, 24/7 technical and user support, as some measuring devices monitor safety and vital functions. Centralised service and/or communication channels for the client/patient Client/patient needs a single centralised user interface/digital service channel for all technological services they use, that can be personalised with their wellbeing technology Communication between the client and a health care professional is possible through the same channel Tiina Karttunen

18 Needs from Data Processing Perspective Service provider is authorised by the client to have access to the client s data when the client is provided with the service and monitoring devices Data produced by service systems is located in different systems in machine-readable format When analysing data, the Service provider must be able to include the data of all their clients in in the analysis. So statistical methods can be applied to a wider group of clients than an individual client history. EHR/PHR systems may not have a defined structural data grammar for all the data that is available from the service systems (devices + applications in illustration). In data analysis, the big question is, can it be assumed that all data significant for analysis would be stored in EHR/PHR systems? Client has the right to obtain data about themselves in machine-readable format and the possibility to release it for further use. When dealing with health data, special attention must be paid to client authorisation of further use of data, client understanding who collects the data and what data is shared. Client should be able to delimit data to be shared under no circumstances

19 Business Models Preliminary statements about the business models Clients own their data. A client has the right to data about themselves, and the client can offer it to the desired party on their own terms The service provider has the right to use the data in their own service The service provider (public or private) asks the client for rights and can use the client s data to provide services for the client, as well as for example in statistics about all their clients Regarding other business models, it is stated only that the integration platform probably needs to support, or the external system related to it should support data licensing so that different business models are not excluded in the future

20 Main Results of the Definiton Process SMARTTAMPERE.FI #SMARTTAMPERE

21 Operating Environment and User Needs Different home care patient groups have different needs to some extent, but problems are also largely common In order to organise operation cost-effectively, solutions should be implemented in a way that the client volumes become sufficiently large Special needs should also be taken into account in the process, so that hospital and other institutionalised care borderline is shifted towards home care. For example, when discharging a heart patient telemonitoring systems must be introduced, and the question of how to organise quick response to situations that require home patient status assessment by a nearby professional must be solved Client specific technology needs to be put into service in conjunction with an out-patient and home care system operating 24 hours a day. Functional work processes must be formed together with different service providers. Need for centralised health care on-call services and domiciliary visits on 24/7 basis Efficient device support to be established for clients, even when using devices connected with different service systems/products Home care needs have been approached using a hand analogy described in the next slide

22 Dementia etc. diagnosis, typical for several client groups Fingers: Home Care patient groups have different, somewhat overlapping, needs that can be met by wellbeing technology. Selection in well-being and monitoring technology is large. Wrist: Efficient use of well-being technology requires, regardless of the patient group, certain common background services and system services (e.g. data bank, authentication, data structures). Technical and professional support (centralised emergency services) Local operators of 24/7 on-call services Palm: Change in service system and the technological solution enabling user-friendly and cost-effective combining of fingers needs and wrist s services = integration platform, centralised alert management tool (dashboard) with possibility of 24/7 on-call home visits by health care professionals. Patient guidance

23 Reference Architecture National Architecture for Digital Services (KaPA): Law on National Architecture for Digital Services obligates state and municipal organisations to use National Architecture for Digital Services when they carry out duties prescribed by law. Home and Remote Care Integration Platform and services related to it must be integrated into the National Architecture for Digital Services (i.a. authentication through Suomi.fi, support for acting on behalf of someone else). National Archive for Personal Health Information, My Kanta (Omakanta): My Kanta Personal Health Record services and national data repository are acknowledged as sources of wellbeing data, whereby integrated applications and devices are available. Several future system projects (including ODA), will utilise My Kanta PHR as a part of their ecosystem. Consequently, the role of My Kanta is also emphasised by these projects. Self-care and Digital Value Services (ODA): Utilisation of data produced by ODA-services where patient stored data is transferred through FHIR APIs to National Archive for Health Information (Kanta). Utilisation of a messaging solution implemented in the ODA-project between a client and a health care professional, if it is ready within an acceptable time frame. When asked, the ODA-project could not yet determine when the solution will be available. Digital Outpatient Services to Support Living at Home (KODA): KODA-project and Digital Home Services complete each other and can benefit from each other s work. It has been discussed with KODA managing organisation, South Karelia Social and Health Care District, that as the KODA project defines the data repository, the Digital Home Services will not take definition of data content as far. The viewpoint of the Digital Home Services is in turn more technology-oriented. Digital Home Services can be seen as a local subproject within the KODA-project, enriching KODA while both benefit from each other s work. UNA (requirement specification project for integrated social and health care information systems): Development is monitored assessing whether UNA-core can act as one data source for the Integration Platform, what can be learned from UNA solutions when planning the Integration Platform, and if UNA is progressing in a direction that it can be used to solve the same problems the Integration Platform is meant to address. Digital Health Revolution project (DHR) (Health data licensing): The need for the implementation of an electronic licensing service should be assessed at the time of implementation in the framework of existing legislation and services provided by other projects

24 Target Architecture Value-added Services Local EHR and CRMs Client situation Alerts Device management Service management Secondary use of Data National Service Architecture Integration Platform for Home Services with Open Interfaces Service indext National Services Authentication Service Gateway Home and Remote Care Solutions Existing & planned solutions Measuring, remote control, diagnosing EHR Virtual Hospital Personal view to EHR data Self care solutions Changing set of integrated Products and Versions

25 Preliminary description of Integration platform Integration Platform Authentication Service management Alert management Data integration and harmonization Data processing and enrichment National data banks and Home and Remote Care data source systems as primary data repositories. Secondarily, platform s own can be used. Data Bank Integration of Home and Remote Care systems Integration with existing A Integration with existing b Measuring, telemonitoring and other forms of data collection Device management Na KaPA Access server Virtual Hospital integration APIs between the intergation platform, value-added services and home and remote care systems are, in National Service architecture; Identification etc.

26 Next Steps SMARTTAMPERE.FI #SMARTTAMPERE

27 Alternative Implementation Models of the Integration Platform Integration platform by one provider Open integration platform, implementation by one integrator Integration platform by open community Integration Integraatio Integration Integrator Integration Dashboard Dashboard Dashboard If several parallel implementations, only one user interface SMARTTAMPERE.FI #SMARTTAMPERE

28 These Implementations? (to be evaluated by functional versatility) 1. Home care client (sensors, safety bracelet, video connection, automated medication dispenser?) 2. Discharged from hospital (heart patient?) 3. Self care client (children and youth / asthma, diabetes?) 4. Organising 24/7 emergency services, operational changes 5. Defining architecture and integration platform (vs. national projects and general IoT platform framework) SMARTTAMPERE.FI #SMARTTAMPERE