Connecting mhealth with the healthcare system

Transcription

1 Connecting mhealth with the healthcare system Technical recommendations Prepared by Bridget Moorman and Michael Strübin 16 October 2014 Version 09 Abstract: This paper provides technical and implementation recommendations for healthcare organisations (ie public healthcare systems) on how to integrate patient generated data (ie from mobile apps) into an electronic health record. It discusses a number of concerns from healthcare professionals, and discusses examples from Europe and the United States to illustrate how such concerns have been addressed. The principal recommendations are to develop a reference architecture with a federated approach, to keep patient generated data and data generated by the health system in separate repositories, to use web interfaces to merge both types of data, and to mandate the adherence to industry standards at key interfaces.

2 Table of Contents Introduction... 3 Interoperability... 4 Existing mhealth/patient Generated Data Integration Practices... 5 GSMA... 5 Southern Norway Strict regulatory and data constraints... 6 Aragon (Spain) Integrating Telehealth Data into the EHR... 8 Basque Country (Spain) Single Service Oriented Architecture Integration Engine to the EHR Catalonia, Spain Evolving from a Personal Health Folder to a Personal Health Channel Estonia Nationwide ehealth System Boston, Massachusetts (USA) Co-mingling of Device Data in Separate Repository with Integrated Viewing in a Patient Context Veteran s Administration (USA) Federated System Approach with Integrated Viewing in EHR and EHR Web-client Analysis Relevant Standards and Standards Organisations The Personal Connected Health Alliance Continua Guidelines Integrating the Healthcare Enterprise (IHE) Reference architectures USA IS Veteran s Administration Home Telehealth HL7 Functions Overview Specification Denmark Reference Architecture for Collecting Health Data from Citizens DICOM Example Recommendations for healthcare providers/healthcare ministries Appendix - Mobile Industry Perspectives Mobile Operators Handset Vendors Mobile Application Developers Telehealth Market Predictions Consumer Use of Self-Monitoring and mhealth Applications Connecting mhealth with the healthcare system Version 09

3 Table of Figures Figure 1: GSMA Suggested System Architecture for mhealth Data Integration into PHR/EHR... 6 Figure 2: Norwegian United4Health System Architecture... 7 Figure 3: Norwegian Service Based Architecture of Information Integration Platform... 8 Figure 4: Aragon SALUD ICT Architecture... 9 Figure 5: United4Health Clinical system Architecture for Congestive Heart Failure Figure 6: Basque Country System Architecture to Include Telemonitoring Figure 7: Catalan Personal Health Channel Interfaces Figure 8: Estonia ehealth Architecture Figure 9: Veteran s Administration Home TeleHealth Architecture with HL7 Functional Relationships Figure 10: Continua End-to-End Architecture Figure 11: IS77 System Architecture Figure 12: Danish Remote Monitoring System Architecture Connecting mhealth with the healthcare system (v9) Page 2

4 Introduction mhealth is getting real. There is an evolving market of mobile devices, apps and solutions that collect user biometric data or health data, provide recommendations and coaching, enable communication between patients and health professionals, and empower users to better manage their health. The data ranges from simple textual information (such as pedometry, heart rate, weight, blood pressure, glucose level, oxygen level) to graphical (eg, EKG and EEG) to visual imagery (pictures and video). These solutions have the potential to promote healthy lifestyles and to improve the lives of patients and their carers. However, these solutions remain outside the traditional healthcare enterprise and infrastructure. While there is growing adoption among consumers in the wellness and fitness domains (popular devices include the Fitbit, Jawbone, Nike Fuelband ), the data is communicated via proprietary data and messaging protocols, and it remains in personal and vendor data stores (cloud) and does not penetrate the traditional healthcare data stores, the electronic medical record/health record applications and databases. For these solutions to become relevant for healthcare, data needs to be credible and consistent, and collected and stored securely in a trusted electronic health record (whether institutional or personal) with managed access for the patient, carers, and healthcare professionals. Incorporating this remotely generated or patient generated data could improve the delivery of healthcare and facilitate research into diseases for alleviation and cures through big data analytics. What are the barriers that prevent the incorporation of remotely generated data into healthcare systems? We see the following barriers: 1. Data quality: Many clinicians question the veracity and validity of the data as there is less control over the environment and source of the sensor data. 2. Data management: There is a concern among clinicians that they will be overwhelmed with data and held liable if they miss to act on critical information. 3. Security: There is a concern regarding security and privacy, including security of the data along the path of transmission, and controlling that data is accessed and used in line with the relevant regulatory and privacy requirements. 4. Financing: The traditional payment and reimbursement mechanisms for healthcare services have been slow to keep up with the emergence of patient generated data and their subsequent management and action. 5. Interoperability/standardisation: Much of the data is not in a standard format and therefore requires more resources and time to integrate into electronic medical/healthcare record applications. For this data to be useful in big data analytics, it needs to be cleaned up and harmonised (standardised). This paper will focus on the last concern. It will focus on the specific interface between remotely generated data systems and the electronic health/medical record interface. We will include some discussion of the first three issues when reviewing integration projects which have been implemented. Connecting mhealth with the healthcare system (v9) Page 3

5 Discussion of the financial and economic aspects go beyond the scope of this paper. The principal topic of this paper is the issue of technical interoperability. Interoperability In healthcare, the Health Information Management Systems Society (HIMSS) offers the following definition of interoperability: the ability of different information technology systems and software applications to communicate, exchange data, and use the information that has been exchanged. 1 HIMSS further defines interoperability into three successive levels, each of which relies upon the lower level to ultimately achieve full interoperability: foundational, structural and semantic. 2 An example of foundational interoperability is the ability of a smartphone to connect to a network. An example of structural interoperability is the ability of a remote monitoring system to send a message to an electronic medical record (EMR) system and have the EMR recognise it. Semantic interoperability is the ability of the EMR system to understand the type of data in the message and appropriately place it where it is best used within the application. In addition to these levels of interoperability, there are interoperability domains which can define the type integration required for interoperability. These domains are local, enterprise and community. Each succeed with different approaches to interoperability. 3 In the case where a remote monitoring solution would integrate patient generated data into an electronic health record (EHR), we suggest a community domain approach. Within the community domain, governance is typically established by following the principle of federation, which recognises the existence of independent domains governed by their own authorities, while providing agreed interaction standards between these domains. 4 One way to bring about community interoperability is to adopt open standards published by Standards Development Organisations (national or international). In a community domain, the vendor of a remote monitoring solution and the healthcare enterprise are autonomous entities. ICT architectures can also affect how interoperability is attained. As with most technology and services, there is a dynamic between centralised and de-centralised implementations. Centralised solutions can become unwieldy and difficult to scale, while de-centralised solutions can foster too much independence and not allow easy aggregation and standardisation. This has led to the evolution of data standards in healthcare and the realisation that a federated approach will be necessary to access all relevant healthcare data about a patient and/or a population. Moreover, interoperability also deals with clinical workflows and how they can interoperate with technology, and vice-versa. There is an iterative cycle with the adoption of technology systems in 1 HIMSS Dictionary of Healthcare Information Technology Terms, Acronyms and Organizations, 2nd Edition, 2010, Appendix B, p190, original source: Wikipedia The traditional definition of an enterprise is a hospital or hospital system. In Europe, an enterprise and community may overlap, as a region-wide hospital system could act as an enterprise and community. In an enterprise the infrastructure is under a central control, whereas in a community there are disparate infrastructures that need to interface. 4 NEHTA, Interoperability Framework, Version 2.0, 17 Aug 2007, p121, Connecting mhealth with the healthcare system (v9) Page 4

6 healthcare: to be truly interoperable, the technology should not disrupt the clinical workflow. If remote monitoring data is to be integrated into an EHR, then the process by which it is integrated should not be an added burden to the clinical workflow. Ideally it will improve or enhance the workflow. The underlying technical interoperability brings about better clinical interoperability. This can be seen with some projects fostering integrated care: by enabling care givers to use a common ICT platform, care becomes more integrated as the data is shared amongst the different stakeholders. In the following section we describe examples of organisations integrating remotely generated/patient generated data including the relevant system architecture, key interfaces and any standards they use for the interfaces. All of these examples share the following key similarities: the use of distributed architectures, the use of messaging standards at the system interfaces, and segregation of the remotely generated/patient generated data in a separate repository while offering an integrated view (usually in a web environment) in an EHR that s specific to the patient. At the time of preparation, there are very few organisations that are integrating remote generated/patient generated data into an EHR. However, the ones highlighted below are chosen for their experience and/or solutions which addressed known challenges. Existing mhealth/patient Generated Data Integration Practices GSMA One resource which tracks mhealth product development and use is the GSMA mobile health tracker. 5 The entries are self-reported, so they may not represent a full accounting of all that is available, but the tracker may present an indicative picture of what is available around the world. As of July 2014, there were 1,074 mhealth products listed over the categories of diagnosis, health systems, health worker empowerment, monitoring, prevention, treatment and wellness. Monitoring accounts for 235 products or 22% of the total, with the most being in the USA (77), closely followed by Europe (63) and Africa (50). A deeper review of the products listed shows that very few of these are integrated with EHRs. In Asia and Africa, most of the mhealth solutions are stand-alone and regional in nature. The integrated and larger systems are mainly in Europe and the USA. GSMA has also developed remotely generated/patient generated data system architecture using mobile telecommunications infrastructure. 5 Connecting mhealth with the healthcare system (v9) Page 5

7 Figure 1: GSMA Suggested System Architecture for mhealth Data Integration into PHR/EHR 6 In this case the mhealth sensor (medical device) has a low range wireless networking capability to send information to a smartphone with an mhealth application. The application then sends information via mobile telecommunications network, using an internet protocol, to an mhealth platform. The sensor may also connect to a home telecommunications hub. The mhealth sensor could also have mobile networking capability (radio to connect to mobile telecommunication network). In another configuration, the sensor functionality could be embedded in the smartphone. The mhealth platform provides intermediary services both native to the mobile industry and possibly specific to healthcare applications (personal health record/electronic health record). Some of the native services could include customer billing, infrastructure maintenance (to include software updates over the air - OTA ), and inherent network security. Southern Norway Strict regulatory and data constraints The region of Southern Norway is a participant in the partly EU-funded United4Health project. Their telehealth solution needed to comply with tough patient data security and privacy requirements. After reviewing several commercial products available, they built their own system. A depiction of the architecture and data flows is below. 6 Moorman, B, with R. Cockle, Medical Device Integration Using Mobile Telecommunications Infrastructure, Biomedical Instrumentation and Technology, May/June 2013, Vol. 47, No. 3, pp Connecting mhealth with the healthcare system (v9) Page 6

8 Figure 2: Norwegian United4Health System Architecture Norway has some of the most restrictive regulatory constraints regarding the inclusion of remote generated/patient generated data into the National Health Network and hospital EHRs. All data which is contained in an EHR must have been validated by a clinician, and currently it must be validated manually. Moreover, there are strict requirements for ICT security within the National Health Network. This environment led them to develop a telehealth system with a stripped down Windows tablet that had only the medical application available to the use; served as the sensor display and the hub for the network connection, stored data in encrypted form on the table; and contained security software that prevented any other unwanted use. Additionally, de-identified, not anonymised, information is transmitted from the tablet to the health service, secured with two-factor authentication methods. Southern Norway also built a dedicated new electronic health record called a Treatment Pathway Record. There are future plans to include this service in the Norwegian Health Portal, however, currently this information is not integrated into their EHR. In addition to the two factor authentication, the system to system network connection from the home to the National Health Network is via a virtual private network (VPN). Southern Norway is also using a web based approach to provide the remote monitoring service. Their information integration platform uses RESTful 7 services for their interfaces between the information providers, integration broker and consumers as seen below. 7 Note: RESTful refers to the use of representational state transfer (REST) techniques. Abstractly, it means use of a web-based architecture to provide services. REST is an architecture, not a standard. REST uses underlying standards like HTTP (hyper-text transfer protocol), XML (extensible markup language) and URI (uniform resource identifiers). Connecting mhealth with the healthcare system (v9) Page 7

9 Figure 3: Norwegian Service Based Architecture of Information Integration Platform This architecture is platform independent and is general enough to integrate any type of information of interest. At present, Norway does not require the use of data standards, however, the country is investigating requiring the use of Continua-certified devices for remotely monitored/patient generated data systems. 8 Aragon (Spain) Integrating Telehealth Data into the EHR Aragon is a region in Northeast Spain and home to about 1.4m people. The region has been joining EU projects including SmartCare to integrate remote monitoring into their regional EHR application. SmartCare s goal is to build a combined technology platform for data sharing of both clinical and social needs. Aragon has already built in some functionality for providing cross-domain combined care-giving with their existing healthcare electronic infrastructure. 8 See Helsedirektoratet (Norway), Anbefaling på valg av standarder/rammeverk for velferdsteknologi [Recommendations on the selection of standards / frameworks for welfare technology], June 2014, Connecting mhealth with the healthcare system (v9) Page 8

10 Figure 4: Aragon SALUD ICT Architecture The specific module in the Aragon SALUD ICT Architecture which provides remote monitoring integration into their EHR is the OMI-AP which services primary care providers and clinics. There is also a home telemonitoring platform which, through the telemonitoring portal, is integrated into the SALUD ICT through the OMI-AP. This home telemonitoring portal remotely monitors alarms and physiological parameters in a patient s home. According to the ICT SALUD representative in Aragon, they use HL7 messaging between the different modules and the middleware interface (IBM Rhapsody) to the EHR. They also use SNOMED for documents classification and management, and the SCP-ECG standard for echocardiograms. The telemonitoring service is a legacy system that has its own database, and not all telemonitoring data are included in the patient s EHR: only values out of range (example: those values being collected for CHF which lead to a determination of decompensation) are of interest to the clinicians. 9 The data collection and recording process is as follows: the telemonitoring platform records all data coming from the biomedical devices into a dedicated database. The telemonitoring data to be integrated into the EHR system is selected at an application level by a nurse, who validates that the values out of range have a medical reasons (rather than being the result of bad measuring practices or technical issues). Upon validation, this data is formatted into an HL7 message and sent to Rhapsody, 9 July conversation with Aragon Salud representative. Connecting mhealth with the healthcare system (v9) Page 9

11 which then records information into OMI. OMI-AP, the telemonitoring portal and the middleware are on the same SALUD network. This data workflow has a human validation step between two electronic steps, and thereby addressed the concern of data overload and quality. Moreover, by using a separate interface broker/portal for the telemonitoring service, Aragon remains platform independent with regard to integrating remotely/patient generated data. Basque Country (Spain) Single Service Oriented Architecture Integration Engine to the EHR The Basque Country is also an autonomous region in Spain, located in the north of Spain (capital: Bilbao) and home to 2.1m people. The Basque health service, represented by Osakidetza, the operational arm of the Basque health service, is using their participation in the United4Health EU project to facilitate integration with respect to the remote monitoring use case of Congestive Heart Failure (CHF). A generalised diagram of the clinical use case is below. Figure 5: United4Health Clinical system Architecture for Congestive Heart Failure In developing their solution for providing the CHF remote monitoring service, Osakidetza relied upon several requirements: contracting out the telemonitoring and telecare services, use of mobile and non-mobile solutions (i.e. platform independent), use of the existing corporate technology platforms, and presenting all relevant telemonitoring information in the EHR application so that healthcare professionals did not have to use different applications. Connecting mhealth with the healthcare system (v9) Page 10

12 Osakidetza integrated the telemonitoring application via Service Oriented Application Protocol (SOAP)- based web services and through a web application firewall to the Osakidetza Electronic Health Record. Osakidetza uses a single interface for integration, regardless of the number of systems and the technological nature of the systems that are connected. This integration complies with Osakidetza s strategic criteria that clinical information coming from a patient's home or healthcare professionals must be managed through Osakidetza s systems, thereby reducing the number of interactions between professionals and distinct applications and interfaces. Communication between the telehealth centre systems and the Osakidetza is bi-directional. Regarding standards, Osakidetza is using messaging (HL7), XML, network and transmission standards and web service standards. In a recent survey of their desire for standards, they were interested in messaging standards using web services with different data exchange standards (XML, HL7...) which publish or consume information through a bus or service concentrator. They also wanted standards regarding events which use real-time event subscription and publication to update data and notify of events among different information systems. Osakidetza is interested in migrating to using more service oriented architecture concepts when integrating data from disparate sources into the EHR. An overview of the Basque Country system architecture follows. Figure 6: Basque Country System Architecture to Include Telemonitoring Connecting mhealth with the healthcare system (v9) Page 11

13 Catalonia, Spain Evolving from a Personal Health Folder to a Personal Health Channel The Catalan Health system, which serves the autonomous region of Catalonia with 7.6 million inhabitants, uses a decentralised ICT system with federated principles. Multi-provider centres are integrated into a single system of public use, with each centre maintaining its autonomy and choosing its own information systems. Interoperability is enforced at the interfaces between the centres. As part of the Health Plan of Catalonia , ICT tools are being implemented to move towards a patientcentred delivery of healthcare. The tools being built with this plan are a Catalonia EHR and a Personal Health Channel. The Catalonia EHR provides an organised and integrated access to relevant information from the different EHR applications at the multi-provider centres in Catalonia. The Personal Health Channel deploys a multichannel network to communicate and interact with the citizen. It is in the Personal Health Channel where remote monitoring and mhealth applications will interface. The goal of the Personal Health Channel is for citizens/patients to become co-responsible for their health. Moreover, the Personal Health Channel moves towards providing services to facilitate health within a common security framework versus just providing access to data. Citizens access their Personal Health Folder through the Personal Health Channel. Access is provided through the use of electronic ID and other digital certificates, use of a chip and PIN technology; robust user/pass with previous face-to-face recognition; and (in the future) the use of credentials for smart phone (for instance integrated in smart cards) as recommended by the Mobile World Capital framework, TICSalut Foundation and the Department of Health. Figure 7: Catalan Personal Health Channel Interfaces The Personal Health Channel will integrate mobile apps and provide the interface to the mhealth ecosystem. Data from mobile apps become part of the health services, support the work of health professionals, and become another resource to support a patient s treatment. A doctor can determine that the use of an app can benefit a patient s health, and prescribe its use. This means, however, that mhealth apps will need to go through an approval process before they can be prescribed. Connecting mhealth with the healthcare system (v9) Page 12

14 Estonia Nationwide ehealth System Estonia, an EU member state with 1.3 million inhabitants, has been building a nationwide Health Information Exchange (HIE) system beginning in 2009 as part of their nationwide ehealth System. The ehealth system relies upon a government ICT infrastructure which assists in providing most public services across the country. One key component of the system is the citizens compulsory use of a smart ID card to establish an electronic identity. The card uses a chip and PIN technology to establish identity, authentication and a digital signature. Estonia has also implemented the use of a Mobile ID service that allows a client to use a mobile phone as a form of secure electronic ID. Mobile ID uses a specialised Mobile-ID SIM card in a mobile phone providing the same functionality as the identity card. Private encryption keys are stored on the mobile SIM card along with a small application for authentication and digital signatures. The first four main modules interconnected by the HIE were the Electronic Health Record (EHR), Digital Images, Digital Prescription and Digital Registration. This has expanded to include a Patient Portal and other ehealth services. Some key decisions were made during the procurement phase 10 to aid in interoperability: Use of Health Level Seven International (HL7) v3 (extended) Documents are kept in Extensible Markup Language (XML) format HL7 Clinical Document Architecture (CDA) All structured data fields have Object Identifiers (OID) Use of DICOM for Digital Image Archiving Only final versions of clinical documents are sent into the central system Use of existing national ICT infrastructure, including the national ID card for identification and X- Road for secure communication By insisting on adherence to the standards, all ehealth services have been interoperable and the building of new services in the future will be cheaper because the necessary core services are already in place Connecting mhealth with the healthcare system (v9) Page 13

15 Figure 8: Estonia ehealth Architecture The National Patient Portal was upgraded in 2013 and allows patients access to their medical data as well as services provided through the HIE. Key Estonian ehealth experts believe the HIE is the designated service where a personal health record (PHR) will reside for Estonian citizens. The main implementation of PHR services will include a standard interface for the inclusion of personal data into the PHR to include self-monitored data from devices, genetic data and wellness data. However a political decision and legislative changes will need to occur to implement this module of the HIE. As seen above in the Estonian ehealth Architecture figure, the PHR is part of the HIE and the Patient Portal. Boston, Massachusetts (USA) Co-mingling of Device Data in Separate Repository with Integrated Viewing in a Patient Context In the USA, one of the more progressive organisations with regard to remote monitoring is the Center for Connected Health in Boston, MA, which is affiliated with Partners Health, a conglomeration of three area hospitals. In a June 2013 press release, the Center for Connected Health announced that patient data collected at home, including vital signs such as blood pressure, weight and blood glucose, are now being transmitted electronically and viewable through the Partners HealthCare medical records system, making this important data accessible within the established clinical workflow. Partners' healthcare providers are now able to easily and seamlessly access personal Connecting mhealth with the healthcare system (v9) Page 14

16 health data for patients enrolled in connected health programs, which is transmitted securely via computer, smartphone or tablet to the Center s remote monitoring database. 11 A clinician can view the remote monitoring data being collected in their Remote Monitoring Data Repository (RMDR) jointly with the EMR data in a patient context. However, the remote data will not be integrated into the EMR application (EPIC): there are issues over data rights within the EMR application, and intellectual property rights over the clinical algorithms in the RMDR. 12 The EMR is a medical-legal document, so extreme care is necessary for data entry. As a result, they have opted for a shared viewing environment. Furthermore, HL7 is being used as a messaging standard, but not necessarily the data standards associated with medical devices (IEEE 11073). Transmission and network standards used are those that were available by the networking vendors. All data from all medical devices, both outside the healthcare enterprise and inside, is being collected in a separate database for future research purposes. The usual workflow for an inpatient flow chart is for the clinician to choose from the physiological values of interest presented over a certain timeframe for documentation. Many of the inpatient device integration systems are able to send medical device data at 30 second intervals. Even in high acuity environments, the highest frequency of charting specific parameters is usually once every 15 minutes, so much of the medical device data available to the EMR application is not used. It is anticipated that in the future, a clinician may wish to delve into all of the data available, so having a separate repository available outside of the EMR database will facilitate that data access. The physiological data elements being collected are the same, just in different environments and at different frequencies. The concern regarding the co-mingling of this data from different environments highlights that the current data standards for patient generated data are not informative enough regarding the environment in which the data was collected and the quality of the medical device. Many times clinicians will not trust or discount the validity and veracity of a physiological measurement made outside of a controlled clinical environment. Having extra contextual information regarding where the measurement was taken, a data provenance, along with the status of the device helps the clinician with regard to their trust level of the data. There is also the issue of biometric authenticity: does the data really come from the patient or is it some other entity (cat, maid, children, proxy, etc). Even though there are device specific data element standards available, the Center for Connected Health desires that a standard set of data to be sent from a specific type of device. For example, a glucometer might be able to report a glucose reading, the time and date of the reading as well as patient information. It could also report data from a food diary and activity log. However, not all glucometers are able to send this complete set of data nor is there an agreement on what a complete set of data is amongst device vendors. Most standards for device data do offer optional fields which may cover other types of data points which may be of interest to patients and clinicians Jul 2014 telecon with a Center for Connected Health representative Connecting mhealth with the healthcare system (v9) Page 15

17 Lastly, and most interestingly, the Center for Connected Health finds that every remote monitoring vendor is sending their messages and data in a proprietary format. In their current solution, they built an interface for each vendor s device data and parse out what they will display. Ideally, they d like to have one interface that is vendor independent. However, the vendors are not sending similar data elements in a standard format, let alone a standard data set. Veteran s Administration (USA) Federated System Approach with Integrated Viewing in EHR and EHR Web-client The United States Veteran s Administration (VA) serves 5.45 million veterans and is considered a trailblazer in embracing the use of telehealth services which 600k veterans reportedly used in The VA has implemented these types of healthcare solutions for over ten years. In a recent solicitation the VA was embarking on a second generation of home telehealth services. According to the Federal Telemedicine News, integration of the remote monitoring data is being integrated into the VA VisTA EHR application with... biometric remote patient monitoring devices to measure blood pressure, blood glucose, weight, heart rate, temperature, and oxygen saturation for patients to use at home. Data will be automatically transmitted wirelessly to AMC s Health s secure web portal or to any integrated EHR. 13 Another vendor, Authentidate, is integrating information from their Electronic House Call telehealth solution, which remotely monitors patients vital signs and gathers qualitative information about their patients health, into VisTA. 14 In reviewing the solicitation for the telehealth system, there were no messaging or data standards specified. 15 However, in the architecture diagrams specified for VisTA, the Home Telehealth module relies upon the Health Data Repository (HDR) which is viewed using VistAWeb, available through the Computerized Patient Records System (CPRS) by using the Remote Data View (RDV) function. 16 The VA requires that all VA Home Telehealth Vendors use their Home Telehealth HL7 Functions Overview Specification. The VA uses a distributed architecture which allows it to expand as clinical services are added. They use a federated approach with regard to the services being provided, i.e. an outside vendor provides the telehealth services and then integrates the data collected into the HDR for viewing by the VA clinicians. The VA does not require that the telehealth system use any particular platform (mobile or otherwise). The interface requirements between a vendor server and the HDR are also platform independent (other than noting in the HL7 message what type of platform and device is being used). All communication is done by HL7 messages, some in XML format and some in a view= Connecting mhealth with the healthcare system (v9) Page 16

18 subscription service, with embedded data standards. Since the VA started Home Telehealth in 2004, the standards specified were those the VA devised and not necessarily ones currently internationally approved (IEEE 11073). There is discussion within the VA to migrate to those standards, however, as with most technology decisions regarding legacy systems, the resource requirements for backwardscompatibility can be prohibitive. The architecture and message flow is shown below: Figure 9: Veteran s Administration Home TeleHealth Architecture with HL7 Functional Relationships For the overall workflow, if a clinician determines a patient is a good home telehealth candidate, then VisTA sends a patient sign up and medical order submission to the home telehealth vendor server. The home telehealth vendor then subscribes to the master patient index server with regard to that patient for demographic updates. The home telehealth kit is issued to the patient. Then, after a sensor measurement, the data is sent to the vendor server and then forwarded to the HDR. This data is viewable in VisTA by the VA clinician. The home telehealth vendor can also send analysis of the data in the form of a progress note directly to the VisTA system. All data is tagged with its source, i.e. it is recorded whether the information was sent from the device or manually entered, and what clinical system provided the data. Questionable data received at the vendor server is not allowed to flow to the HDR. Such data includes out of date range, illegal value or overly dramatic change. If the data change is dramatic (but not within the overly dramatic change), then the data is tagged as dramatic change and elevated for review. Connecting mhealth with the healthcare system (v9) Page 17

19 The VisTA EMR system has two components: a local version which functions like a traditional EMR application, and an enterprise version, VisTA web, which aggregates data from all sources that hold patient data and presents it as a single source (that is, the clinician can see a graph of all glucose readings no matter where it was collected). Therefore, the data is held separately for management and interfacing purposes, but can be seen in an integrated view from a patient context. Currently, all HL7 communication done behind the VA firewall is unencrypted. Otherwise, a virtual private network (VPN) connection is required for any trans-firewall access to any VA systems which includes encryption. System-to-system traffic is trusted using system privileges, while user to system traffic is trusted using user privileges. Analysis Each of these examples of integrating remote/patient generated data into EHRs/HIEs has relied upon a federated approach (i.e. allowing autonomy within the different components) while strictly enforcing standards at the interfaces. All want to incorporate patient generated data in electronic health records, but are struggling with how to do that. There is a shared concern about security to establish data validity and veracity as well as trust amongst the stakeholders. So far, security has mainly been established by secure ICT transmission infrastructures and secure identification mechanisms. All of these health organisations realise that establishing and enforcing standards at the different system interfaces allows for interoperability as well as better data identification for analysis across systems. The standards used are mainly in the messaging and network transmission realm. Most of these health organisations keep patient generated data in separate repositories than data generated from inside a hospital or clinic, but they are allowing an integrated view of the data for a patient using web viewing technologies. All understand that mobile health apps will generate a large part of what will be Big Data, however, they want to ensure that apps and data that will be relevant for clinicians are vetted. Lastly, most of the healthcare organisations are migrating towards web and service oriented interfaces for data gathering and viewing. They allow a modular approach towards development of the services and architecture. They also lend themselves to data and service provisioning within most web browser applications, which scale from mobile phones to tablets and other computing platforms. Relevant Standards and Standards Organisations There are several organisations in the healthcare industry which promulgate standards and standards guidelines for different interfaces. The guidelines specify standards at interfaces along the data path continuum to provide foundational, structural and semantic interoperability at the interfaces. The implementation of the different standards depends on where a vendor or healthcare enterprise provides services along the data path. Connecting mhealth with the healthcare system (v9) Page 18

20 The Personal Connected Health Alliance Continua Guidelines One of the organisations in this arena is the Personal Connected Health Alliance which develops the Continua Guidelines. 17 Depicted below is their current end-to-end architecture. At each interface, there are standards identified to facilitate interoperability across that interface. For the purposes of this paper, the interface of most interest is the Health Record Network (HRN) interface. Figure 10: Continua End-to-End Architecture If one looks closely at the diagram, one notices that the HRN interface depends on the downstream interfaces also being interoperable and ultimately depends upon the sensor sending its data in a standard format over a standard transmission protocol. This standard data is then aggregated into a standard messaging format and again transmitted over a standard transmission protocol. At the HRN interface, the Continua Guidelines specify either the Integrating the Healthcare Enterprise (IHE) Patient Care Devices (PCD) Domain-01 profile, or the Continua Personal Health Monitoring Report (PHMR), which is an HL7 CDA-2 based document with the underlying standard for medical device data of IEEE In 2014 the Continua Health Alliance merged with other entities to form the Personal Connected Health Alliance (PCHA). With that merger the Continua Health Alliance ceased to exist as a formal entity, but the technical and policy work for interoperability lives on under the umbrella of the PCHA. Connecting mhealth with the healthcare system (v9) Page 19

21 Integrating the Healthcare Enterprise (IHE) The other main standards promulgation organisation in this interface space is Integrating the Healthcare Enterprise (IHE), which offers profiles of clinical use cases which identify actors and their interfaces and then specifies standards for interaction across those interfaces. In the case of remote monitoring or mhealth, the main IHE profiles of interest are the IHE-PCD 01 and the draft IHE ITI Technical Framework Supplement, Mobile access to Health Document (MHD). Both of these profiles rely upon underlying standards, however, the MHD document is much less specific at the data level, with the stated purpose of MHD being provision of an XDS-like environment to send and receive health document using RESTful techniques. However, the MHD does not specify any underlying data or messaging standards other than those required by the XDS document, which does not specify HL7 messaging nor IEEE data standards. XDS ensures that patient ID information be supplied and a modicum of security wrapping the document during transmission. Therefore, the document in question would not necessarily be searchable outside of as a whole based on a patient ID. In a further development, a draft standard has been issued by the IHE ITI subcommittee of the Patient Demographics Query as a Mobile App (PDQm) as part of the HL7 FHIR Standard. This draft profile supplement defines a lightweight RESTful interface to a patient demographics supplier leveraging technologies readily available to mobile applications and lightweight browser based applications.(and possible use cases are): A health portal securely exposing demographics data to browser based plugins, Medical devices which need to access patient demographic information, Mobile devices used by physicians (example bedside echarts) which need to establish patient context by scanning a bracelet, Web based EHR/EMR applications which wish to provide dynamic updates of patient demographic information such as a non-postback search, additional demographic detail, etc., Any low resource application which exposes patient demographic search functionality. Any application using the MHD profile to access documents may use PDQm to find an appropriate patient identifier. 18 As it is in draft format, it still needs vetting, however, there is recognition by IHE that there needs to be a deeper dive into the message with regards to data standards identification to bring about semantic interoperability. Reference architectures One of the ways healthcare organisations and authorities can make their desires known to the market is to develop specifications regarding their requirements. In the case of clinical services delivered outside of the healthcare enterprise controlled environment, use of a reference architecture document or specification is recommended. The reference architecture document describes the interfaces, 18 Connecting mhealth with the healthcare system (v9) Page 20

22 messaging and data requirements along with the expected clinical workflow for the remotely or patient generated data systems. Three of these documents are described below. USA IS77 Early on in the United States efforts to define meaningful use (MU) for EHR certification as required by the Health Information Technology for Economic and Clinical Health (HITECH) act, the Health Information Technology Standards Panel (HITSP) specified standards for remote monitoring which resulted in the publication of IS77 in IS77 depicts a framework of actors and interfaces with information and data items which would flow across the interfaces. Standards are identified for the format of those information and data items. IEEE as a medical device data standard figures heavily in the standards identified. Moreover, IHE-PCD-01 is also specified at the EHR and/or Health Information Exchange (HIE, which is defined as an EHR to EHR interface). IS 77 was not officially adopted for the first stage of MU, however, as stated in the goals for Stage 5 MU, medical device interoperability is an implied requirement and IS 77 is a base document upon which remote monitoring data standards can be specified in the overall integration of medical device information into EHR applications. Security is considered a pre-condition with regard to implementing the architecture and relied upon standards identified in other documents for security audit (HITSP/T15), secured communication channels (HITSP/T17), and access control (HITSP/TP15). Below is a diagram of the reference architecture as depicted in IS77. Figure 11: IS77 System Architecture 19 Connecting mhealth with the healthcare system (v9) Page 21

23 Veteran s Administration Home Telehealth HL7 Functions Overview Specification 20 As described above, the Veteran s Administration has developed an HL7 Functions Overview specification that all of the VA Home Telehealth Vendors must use to integrate their system data into the VisTa EMR system. It is an evolving document which was first developed in Due to that date of development, many of the data standards developed since then have not been adopted in the document. Nevertheless, the similar ideas of using a distributed system, separate data repositories, an integrated patient context view, sensor platform independence with regard to data integration, and the use of HL7 messaging for interface communication hold. Moreover, the document describes the clinical workflow, functional architecture and interface messaging requirements of the VisTA system, the vendor telehealth system, HDR and MPI. Denmark Reference Architecture for Collecting Health Data from Citizens In 2013, the Danish Government published their Reference Architecture for Collecting Health Data from Citizens. This document aims to provide a framework for the collection of health data from Danish citizens making it available to healthcare providers. The interface is defined as between the citizen and the health record network and specifies the Continua Guidelines HRN standards and IHE-PCD-01. Again, the underlying medical device data standards are IEEE (specifically those for personal health devices) and HL7 CDA-2 as expressed by the PHMR. Moreover, for imaging, DICOM is specified. There is an understanding that the context with which the data is collected must also be transmitted, hence their insistence on including metadata with all data transmissions. 21 In the Danish reference architecture, there is a recognition that the environment in which health data from citizens is measured and collected has and will migrate to wearable sensors that can send the data to the EHR. As a next-step the reference architecture foresees bi-directional communication where an EHR application or other data gathering application could request data from a wearable sensor. Ensuring a standardised framework over which the data can be collected and recognised will help the Danes in their ability to mine the data for patient and public health purposes, and to drive down the costs of healthcare, especially those related to over-hospitalisation. Security is addressed in the Danish document. It does not require a specific security framework, but states that integrity and confidentiality are the most important from an information security perspective for remote monitoring from a patient home. There is an over-arching belief that the data responsibility will always be with the person or actor acting as the data controller. Denmark requires that the data controller undertake a risk assessment, and recommends that personal data be made personally identifiable as late as possible and preferably not until the data is within the national infrastructure, with its good security measures. The specific security standard they espouse in the 20 Can be obtained by request from Professor George Blankenship, [email protected] 21 %20dansk/Sundhedsdata%20og%20it/NationalSundhedsIt/Standardisering/Referencearchitecture%20for%20colle cting%20health%20data%20from%20citizens%20v%201%200.ashx Connecting mhealth with the healthcare system (v9) Page 22

24 reference architecture is the IHE IT Infrastructure TF Vol 2, Appendix V Rev 6.0; WSI-I Basic Security Profile, TLS and IHE ATNA. Figure 12: Danish Remote Monitoring System Architecture The figure above shows the system architecture as envisioned by the Danes. DICOM Example According to Wikipedia 22, the first large implementation of the precursor to DICOM was by US Army and Air Force, as part of the MDIS (Medical Diagnostic Imaging Support) program run out of Ft. Detrick, Maryland. The request for Proposal specified that the contractor shall install ACR/NEMA interfaces to all digital imaging systems identified for the MDIS network. 23 In 1997, the Defense Logistics Agency released a solicitation for a proposal for a Digital Imaging Network-Picture Archival Communication System (DIN-PACS) for the Military Healthcare Services System and the support of Radiology which specified the DICOM and HL7 standards images and messaging. 24 These actions by a large healthcare organisation and the US government are believed to have brought about the near universal adoption of DICOM worldwide for medical images by vendors and healthcare organisations which persist to this day pg Connecting mhealth with the healthcare system (v9) Page 23

25 Recommendations for healthcare providers/healthcare ministries Implement a separate data repository: Those healthcare organisations that have attempted to gather and integrate remote patient data have migrated towards using a separate data repository for the remotely generated data. The integration of the data is then done via a viewing mechanism with the same patient context. If the remote data is migrated to the EHR application, it is done via manual means to maintain a clinical validity step for medical-legal purposes and allows the EMR/EHR to remain a medical-legal document. Define the need: Understand what the desire is for patient generated and/or remotely generated healthcare data, i.e. how will it be used. Understand and/or define the clinical workflow which will drive your integrated data collection activities. As in the case of the Center for Connected Health, anticipate future requirements of Big Data by possibly co-mingling similar types of data. Moreover, also understand that the introduction of technology into a clinical workflow can start an iterative process which changes the technology and then the workflow, etc. Develop a reference architecture: Identifying a reference architecture with expectations will help with directing the efforts towards collecting and using patient/remotely generated health data. Make the reference architecture platform independent and define the requirements at the interfaces. This allows future-proofing of your interfaces with regard to the evolution of technology. As mobile and smart phones become wearable sensors, your interface will focus on the messaging and data allowing the sensor and transmission changes to minimally affect your systems. Build in a middle data validation step in your workflow before allowing patient/remotely generated data integration into the EHR. This is already done in the inpatient setting, so is a familiar workflow step. This addresses the data validity and veracity concerns of the clinicians. Moreover, identifying the source of the data when being viewed in an integrated fashion within a single patient context will help the clinician properly assess the data for their purposes. Federate: Understand and use a federated model for interoperability by adoption of open standards for patient/remotely generated healthcare data transmission over interfaces. Specify and mandate these standards while referring to a reference architecture in your acquisition documents. Relax: Realise that the provision of healthcare is moving outside the locus of the geographical healthcare enterprise and be prepared for less control over those environments (centralised to decentralised). Using web based and service oriented approaches for data integration and/or viewing will enable the healthcare enterprise the best way to access and use the patient/remotely generated healthcare data. Select standards and enforce compliance: In general, you have the most control over the specific aspects of your industry, in this case the healthcare data and messaging. Other industries share similar elements and requirements of the ICT infrastructure, so resolution of interoperability, integration and standardisation on those similar items comes quickly, for example on network and physical connectivity. You are the arbiters of the health data and messaging, so you should be setting and enforcing those Connecting mhealth with the healthcare system (v9) Page 24

26 standards. Keep in mind that DICOM, the imaging interoperability standard, became well known and vendor adopted once it was specified as a requirement in US DOD government documents. Be very diligent in the procurement phase to identify the standards you require and only award business to the vendors who meet those standards. Connecting mhealth with the healthcare system (v9) Page 25

27 Appendix - Mobile Industry Perspectives Mobile Operators The mobile operators are keen to be involved in the healthcare market and to disrupt it. They have a unique proposition in that they have a one-to-one relationship with their customers and have developed back-end business infrastructures and processes which facilitate that relationship. Moreover, they have managed to build their customer base from ~1 million to ~7 billion worldwide by identifying and enforcing standards adherence beginning with the 3G/PP initiative (which started in 1998, the same year HL7 was started!). Standards are in the operators DNA: the mobile operators would not allow a handset that did not adhere to the standards to connect to their transmission network. This is due to the mobile operators insisting on data standards for a specific use. Because the standards were specified and enforced, interoperability soared and market penetration and size soared as well. By defining the end points, the device manufacturers could build their product once and then connect to multiple endpoints. 25 For the application manufacturers, they didn t worry too much about the sensors and hardware as those had standard interfaces as well. 26 Handset Vendors Other developments have occurred with the handset manufacturers and other technology companies. All of them have announced some type of health data aggregation product with development kits for entrepreneurs (Apple Healthkit, Samsung Digital Health Initiative, Google Fit, Microsoft HealthVault, and others). While several initiatives by some of the same companies have failed in the past, many believe now is the tipping point for involvement in mhealth. There is recognition that leveraging the ubiquitous mobile telecommunications infrastructure to solve some of more pressing healthcare issues should be a winning proposition. What the mobile industry has demonstrated is that by insisting on the use of standards at the interfaces, they ensure that solutions can scale over the infrastructure providing the maximum benefit to their customer base. Additionally, by providing a standardised environment for transmission, entrepreneurs can focus on providing other services of value to their customers. Mobile Application Developers In a recent report by research2guidance, mhealth App Developer Economics, , two of the perceived problems with mhealth app development were lack of data security and standards. Nevertheless, the app categories that were believed to have the highest market potential in the near future were remote monitoring and consultation apps with the biggest impact on healthcare costs being in reduction of non-compliance and hospital readmissions. Interestingly, remote consultation and 25 Examples of required standards for 3G/PP include transmission protocols, security requirements (encryption), and user identification (uniqueness). See Connecting mhealth with the healthcare system (v9) Page 26

28 monitoring only comprise 0.6% of the category share of mhealth apps currently available with medical condition management comprising 6.6% of the category share. Fitness apps comprise 30.9% of the category share. Additionally, the mhealth apps are marketed mainly to chronically ill patients (31%) with physicians being targeted users at 14%. According to this same report, patient monitoring data is collected on 5 million patients in 2014, with medical examination data collected on 1 million patients. The distinction between patient monitoring data and medical examination data is generally based on the complexity of the sensor needed to obtain the data. Simpler ones like weight, blood pressure and glucose are considered patient monitoring data, while respiration rate, EKG, EEG and lab tests are considered medical examination data. Telehealth Market Predictions In Berg Insight mhealth and Home Health reports from 2011 to , there was in increase in the use of a home monitoring service with an integrated connectivity using a PC or mobile phone from 2.2 million patients to 3 million patients worldwide. The three most common types of remote monitoring are cardiac rhythm management of implantables, sleep therapy and ambulatory EKG. The CRM remote monitoring market has decreased from 74.3% to 65% of the market over that time, with sleep therapy comprising 18% of the market in In the 2013 report, they state that cellular connectivity has replaced PTSN and LAN connectivity and the de-facto standard. They also state that three catalysts for the increase in the use of remote monitoring are incentives from payers, insurance companies and national or regional health systems that support remote monitoring and performance based care models. 31 Consumer Use of Self-Monitoring and mhealth Applications However, is there consistent usage of monitoring by the consumers/patients? For fitness applications, the rate of engagement decreases to 50% after 18 months of activity tracking according to a study by Rock Health. 32 In another survey by Mobiquity, 33 participants were asked why they had stopped using their fitness devices and most said they had forgotten to use them, it took too much time, was too hard to use or had reached their goal. 61% of these participants also cited privacy concerns as the primary reason stopping them from using apps even more than they were. Additionally, the Rock Health reports surmised that the use cases for the applications had been left up to the consumer to figure out versus having a suggested use case by a device or healthcare professional. So, the behaviour of consumers/patients can also lead to disinterest in remote monitoring and therefore nothing being integrated into an EHR unless there is prodding and an assurance of data privacy Ibid Connecting mhealth with the healthcare system (v9) Page 27

29 In a survey report by Deloitte University Press 34, a longitudinal study of the US healthcare consumer showed a decrease in the desire to use self-monitoring tools from from 72%-41%, respectively. The four main reasons given for not wanting to self-monitor were: prefer to communicate with doctor by phone or in-person (50%), don t have a smartphone or tablet (43%), privacy and security of information might be at risk (31%) and that kind of service would probably cost too much (23%) Connecting mhealth with the healthcare system (v9) Page 28