Connecting Cloud-Based Personal Health Records with an XDS Affinity Domain to Provide Additional Information at the Point-Of-Care
Total Page:16
File Type:pdf, Size:1020Kb
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 Affinity 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 nation- wide 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 Affinity 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 Affinity 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