Connecting Cloud-Based Personal Health Records with an XDS Affinity Domain to Provide Additional Information at the Point-Of-Care

196 eHealth2014 – Health Informatics Meets eHealth A. Hörbst et al. (Eds.) © 2014 The authors and IOS Press. This article is published online with Open Access by IOS Press and distributed under the terms of the Creative Commons Attribution Non-Commercial License. doi:10.3233/978-1-61499-397-1-196 Connecting Cloud-Based Personal Health Records with an XDS Affinity Domain to Provide Additional Information at the Point-of-Care

Patrick HUBERa, Christoph MITSCHa, Stefan SABUTSCHb, Ursula SCHMIDT-ERFURTHa,1 a Medical University of Vienna, Department of Ophthalmology and Optometry bELGA GmbH, Architecture and Standards

Abstract. Due to the increasing use of Electronic Health Records by healthcare providers and the trend towards the use of Personal Health Records by patients the potential need to integrate these two types of medical documentation emerged. The introduction of the ELGA (Elektronische Gesundheitsakte, EHR) during the next few years is reason enough to propose possibilities to directly involve the patient into the data acquisition process in form of generating personal health data (e.g. vital signs, etc.) at home. In particular patients with chronic diseases will benefit from this integrated architecture. Furthermore, patients could archive all documents for their own use and responsibility. This article reviews literature about integration possibilities for personal and electronic health records and proposes an architecture which integrates data from patient-side into an affinity domains’ XDS document repository.

Keywords. Electronic Health Record, Personal Health Record, Integration, XDS Affinity Domain, MHD, FHIR

1. Introduction

With the spread of Electronic Health Records (EHR) in daily practice of healthcare providers (HCP), the patient involvement to access “his/her” personal data will be an important task. Many patients already maintain a Personal Health Record (PHR) in form of health and fitness tracking on their own [1]. These patient platforms are mostly cloud-based and in only few cases the PHR is stored locally. In the context of standard- based Health Information Exchange (HIE) we see a missing link in the implementation of these two systems working together. We think that there is a need to integrate Personal Health Record Systems (PHR-S) with Electronic Health Record Systems (EHR-S) for two key aspects: 1. Additional PHR information within the healthcare providers EHR-S to get a more integral insight to the patient health status. 2. The patient can “download” documents from the healthcare providers EHR-S to his own PHR for archiving and future sharing.

1 Corresponding Author: [email protected] P. Huber et al. / Connecting Cloud-Based Personal Health Records with an XDS Afﬁnity Domain 197

A recent publication [2] proposes a PHR cloud system architecture and adopts the IHE (Integrating the Healthcare Enterprise) XDS (Cross-Document Sharing) Integration Profile to provide continuous healthcare.

2. Methods

Due to the nature of this work as proof of concept, the main methods were an analysis of health IT system architecture, the relation and differences between EHR and PHR, and previous approaches to integrate such systems. Furthermore, the development of a conceptual solution complements the standards-, specification- and framework- literature review.

2.1. Health IT infrastructure

As already mentioned in the introduction, the idea is to integrate institution-managed EHRs and personally-managed PHRs for information exchange. Looking at the current nationwide health IT infrastructure in Austria, we identify the consistent usage of international standards and technical frameworks [3], like IHE Framework, HL7 CDA, LOINC or DICOM. Based on this information we derived the requirement of searching for IHE-compliant system architectures. The research includes IHE Technical Frameworks, especially of the IT Infrastructure domain.

2.2. Linking EHR and PHR

The important contextual difference of EHR and PHR is the fact that EHRs are maintained, managed and used by healthcare providers, whereas in the case of PHRs this is done by patients. It is important to distinguish the medical content quality of these two systems, but in many cases additional PHR information could provide a valuable resource for attending physicians. [4]

2.3. Current approaches of PHR integration

Two examples of Personal Health Record Systems are Microsoft HealthVault and HealthUnity Healthysite™ PHR which provide web-based user-interfaces to interact with the system. They also offer interfaces for third-party applications [5,6]. In HealthVault, patients can easily grant access to their whole PHR or PHR extracts. The main disadvantage of this system is that the granted user (e.g. primary-care physician) also needs a HealthVault account to log in with.

2.4. Development of conceptual system architecture

The proposed solution intends the seamless use of PHR information within the nationwide health information network, minimizing the user’s (e.g. physician) effort to access the patient’s PHR. The first step is to get an in-depth overview of available IHE Integration Profiles and relating Technical Frameworks. In addition to many final Technical Frameworks, 198 P. Huber et al. / Connecting Cloud-Based Personal Health Records with an XDS Afﬁnity Domain there are Supplements for Trial Implementation that have great potential for some interesting use cases. For better understanding of our proposed system architecture we provide a schematic representation at Section 3.

3. Results

3.1. Sample Use Case: Patient changes Primary Care Physician

Nowadays, if the patient uses a PHR-S like Microsoft HealthVault to manage his health records, the information is limited to patient-entered data. Documents generated by healthcare providers including primary care physicians (PCP) are currently not available in the PHR-S. If for some reason the patient changes his PCP, all health records remain at the EHR-S of his previous PCP. There is no way to provide his new PCP with his medical history. In this case the need for the integration of PHR-S outside an XDS Affinity Domain with EHR-S within an XDS Affinity Domain is valuable. Especially if the patient suffers from chronic disease, he likely has a long medical history with many documents. If this patient could have “imported” or “downloaded” his documents from his previous PCP’s EHR-S to his own PHR-S (e.g. HealthVault) he could provide additional information for distant future encounters. Despite of the document source, the responsibility of the PHR stays with the patient.

3.2. Literature Review

During the evaluation of the literature we discovered several approaches for connecting an external system with an XDS Affinity Domain. Nevertheless, not all architectures satisfy the requirement to seamlessly integrate a PHR-S with a XDS repository. Table 1 will show an overview of the different opportunities.

Table 1. Different system designs to integrate PHR-S with an XDS Affinity Domain.

Name Requirement for PHR-S Pro Contra

PHR-S as Document Source within XDS Profile Same Not every PHR-S XDS Implementation (Actors, functionality as can be a Transaction) HCP systems Document Repository PHR-S as XDS Affinity Domain XDS/XCA Profile Separate Own community (own Community) and connection Implementation (Actors, Affinity means own XDS through Cross-Community Access Transaction) Domain Registry (XCA) PHR-S uses an RESTful interface MHD Profile State-of-the-art Additional effort to an XDS environment based on Implementation (Actors, web technology, for existing XDS the Mobile access to Health Transaction) HL7 FHIR environments Documents Profile Exchange of Personal Health Implement other Profiles Content-level Currently no Records Content Integration Profile guidance detected (XPHR) P. Huber et al. / Connecting Cloud-Based Personal Health Records with an XDS Afﬁnity Domain 199

3.3. PHR-S as Document Source within XDS

One obvious approach is to put the PHR-S directly into an existing XDS Affinity Domain as another Document Source, so that the patient can also provide and register documents into the Document Repository and Document Registry. This idea is best described as a patient-maintained Document Source acting exactly like a healthcare provider’s information system (e.g. Hospital Information System). Although it is a straight-forward solution, it has some critical downsides. Every PHR-S needs to be a registered application within the specific XDS Affinity Domain. Assuming that patients host or deploy their own instance of PHR-S, several questions arise: Which XDS Affinity Domain will he/she choose to integrate his/her Document Source? In Austria, different XDS Affinity Domains are assigned to different healthcare providers, thus the location of individual “patient repositories” is a problem. Also, if every PHR-S will be positioned within a specific XDS Affinity Domain [7] security issues arise. This led to our next approach, introducing an own “patient community based” XDS Affinity Domain where patients can integrate their PHR-S on their own.

3.4. PHR-S as XDS Affinity Domain (own Community) and connection through Cross- Community Access (XCA)

Setting up an individual XDS Affinity Domain with its own Document Registry is a more promising architecture. The PHR-S lies in the “patient community based” XDS Affinity Domain which integrates with other Affinity Domains through Gateways. The IHE Integration Profile for Cross-Community Access (XCA) describes this use case. The problem with this approach is the missing functionality for the ELGA Affinity Domain to write into the PHR-S. The only function that can be used is read-only access from the ELGA Affinity Domain. An in-detail explanation with additional security considerations can be found in [7].

3.5. PHR-S uses an RESTful interface to an XDS environment based on the Mobile access to Health Documents Profile

One of the recent developments in healthcare interoperability is the IHE Integration Profile called Mobile access to Health Documents (MHD). “[It] defines one standardized interface to health documents for use by mobile devices so that deployment of mobile applications is more consistent and reusable.” [8] The intention is to use state-of-the-art web technologies like REST (Representational State Transfer) web services to serve modern web applications and native mobile apps which support these web standards out-of-the-box. Generally speaking, the profile defines a simple HTTP interface to an XDS like environment. The following transactions perfectly map to the REST methodology. The four actors (Document Source – Document Recipient, Document Consumer – Document Responder) shall implement one or more of the following transactions [8]: Put Document Dossier [ITI-65] – HTTP POST Get Document Dossier [ITI-66] – HTTP GET 200 P. Huber et al. / Connecting Cloud-Based Personal Health Records with an XDS Afﬁnity Domain

Figure 1. MHD Actors and Transactions [8].

Find Document Dossiers [ITI-67] – HTTP GET queries in accordance to RFC2616 (key/value pairs after the ‘?’ and before the ‘#’ in the HTTP action) Get Document [ITI-68] – HTTP GET

In order to support well-established profiles like XDS, all transactions have an equivalent XDS transaction. A graphical representation of the actor diagram is shown in Figure 1. The important part is that the MHD profile doesn’t replace the XDS; instead it supports the robust XDS infrastructure and integrates for some special use cases. Closing the loop to our proposed idea of connecting a PHR-S with an XDS environment, the MHD profile officially lists two example use cases that partly match our idea. “PHR publishing into a staging area for subsequent import into an EHR or HIE.” “Patient or provider application that is configured to securely connect to a PHR in order to submit Recording history document.”

We also have to consider grouping the MHD actors with an XDS (Figure 2) or XCA (Figure 3) infrastructure, having the MHD actors (Document Recipient and Document Responder) act as a proxy for the XDS environment [9].

Figure 2. MHD Actors grouped with XDS Actors to provide a seamless integration for RESTful clients. [8] P. Huber et al. / Connecting Cloud-Based Personal Health Records with an XDS Afﬁnity Domain 201

Figure 3. MHD Actors grouped with XCA Actors. [8]

In conjunction to the MHD profile, HL7 is working on a specification called FHIR (Fast Healthcare Interoperability Resources) [9,10]. It is more technical, but does not specify actors or transactions like IHE does. Like every IHE profile, the MHD recommends standards such as HL7 for standard-based communication. “The IHE MHD profile and the HL7 FHIR activities are working together to revise and enhance the transactions profiled here.” [8] In Figure 4 we show our proposed architecture which uses a FHIR Server on top of an XDS Repository. It is like a façade that provides a RESTful API to a XDS repository. On client side, the application has to implement a FHIR client. Therefore it makes no difference whether the PHR is an application with local or cloud-based storage. Either way the client has to implement web services. If the PHR has its own backend, this will act as the FHIR client.

3.6. Exchange of Personal Health Record Content Integration Profile (XPHR)

The IHE Integration Profile Exchange of Personal Health Record (XPHR) only specifies how interoperability between PHR-S used b patients and EHR-S used by healthcare providers can be achieved at the content-level. The sharing or transmission is not described in this Integration Profile and references to other profiles.

4. Discussion

We believe that the integration of cloud-based PHR-S with an XDS Affinity Domain to provide additional infrmation at the Point-of-care is an important and necessary step to actively encourage the patient to document his personal health status in a secure, simple and user-friendly way. Through our research we found different approaches for integration of PHR-S. The most suitable one was the IHE Integration Profile Mobile access to Health Documents. The profiles indicate the Document Source and Document Consumer as being the patient using a web app on a mobile device or PC to enter health-related information. Data persists locally as record in his individual PHR-S (locally on a device/PC or in the cloud), but is also sent to an XDS environment (MHD Document Source). The patient can also retrieve – “download” – documents from an XDS environment for display with the web app and this data additionally persists archived in his PHR-S (MHD Document Consumer). It can be called the “30-year patient retention period” for medical documents. The use of RESTful web services and other corresponding web

202 P. Huber et al. / Connecting Cloud-Based Personal Health Records with an XDS Afﬁnity Domain

Figure 4. Schematic representation of our proposed integration architecture. standards look promising and definitely will be a progress in the healthcare interoperability sector. Especially the HL7 FHIR specification looks like a game changer for the development of more patient-centric healthcare applications. The aim of this work was to look for integration possibilities of PHR-S and EHR-S in a theoretical manner. Based on standards, specifications and framework documents we propose a schematic solution to connect PHR-S with an XDS Affinity Domain.

References

[1] Canalys, “1.6 million smart bands shipped in H2 2013.” 2014. [2] C.-Y. Yang and C.-T. Liu, “Developing IHE-Based PHR Cloud Systems,” in 2013 International Conference on Social Computing, 2013, pp. 1022–1025. [3] ELGA GmbH, “ELGA – Technische Grundlagen.” [Online]. Available: http://www.elga.gv.at/index.php?id=24. [Accessed: 22-Jan-2014]. [4] HealthIT.gov, “What is the difference between a Personal Health Record, an Electronic Health Record, and an Electronic Medical Record?” [Online]. Available: http://www.healthit.gov/providers- professionals/faqs/what-are-differences-between-electronic-medical-records-electronic. [Accessed: 25- Mar-2014]. [5] Microsoft, “SDKs for HealthVault,” 2014. [Online]. Available: http://msdn.microsoft.com/en- us/healthvault/jj126730.aspx. [Accessed: 25-Mar-2014]. [6] HealthUnity Corporation, “Healthysite.” [Online]. Available: http://healthunity.com/Products.mvc.aspx/Healthysite. [Accessed: 25-Mar-2014]. [7] A. Mense and P. Urbauer, “Integration von Personal Health Records (PHR) in die österreichische elektronische Gesundheitsakte (ELGA),” in Proceedings of the eHealth2013, 2013. [8] Integerating the Healthcare Enterprise, “IHE IT Infrastructure Technical Framework Supplement Mobile access to Health Documents ( MHD ) Trial Implementation,” 2013. [9] D. Hay, “FHIR and XDS – an Overview,” 2013. [Online]. Available: http://fhirblog.com/2013/11/05/fhir-and-xds-an-overview/?relatedposts_exclude=267. [Accessed: 22- Jan-2014]. [10] FHIR development team, “FHIR - HL7Wiki.” [Online]. Available: http://wiki.hl7.org/index.php?title=FHIR. [Accessed: 22-Jan-2014].