Health Care in the Age of Interoperability Part 5: The Personal Health Record

Health Care in the Age of Interoperability Part 5: The Personal Health Record

This is the fifth in a series of articles on the dramatic transformation taking place in health informatics in large part because of the new Health Level 7 (HL7) Fast Healthcare Interoperability Resources (FHIR) standard. The first article provided the background on healthcare, electronic health record systems for physicians, and the challenges they both face along with the potential of interoperability to help overcome them. The second introduced the basics of the FHIR standard and some suggested resources for those who are interested in its further exploration. The third introduced SMART on FHIR, which, based on its wide adoption, has become the default standard FHIR app platform. The fourth looked at clinical decision support, arguably the single most important provider-facing use case for FHIR. This article introduces the personal health record and tools that can utilize the data stored in it as an important use case for FHIR in support of patients. The articles in this series are intended to introduce researchers from other fields to this one and assume no prior knowledge of health care or health informatics. They are abstracted from the author’s book Health Informatics on FHIR: How HL7’s New API is Transforming Healthcare (Springer International Publishing).

In the last article, we focused on clinical decision support (CDS) for physicians and other health care providers. In this one, we will look at how interoperability through Fast Healthcare Interoperability Resources (FHIR) could empower patients to become more involved in their own care and in maintaining their health.

The electronic health record (EHR) is the core informatics tool for providers. The analogous tool for patients is the personal health record (PHR). The term first appeared in a 1978 paper [1], but an automated PHR was not a practical concept until around 2000 with the dramatic decline in the cost of computing and the increasing availability of the Internet. Here, once again, although meaningful adoption of the PHR has yet to occur, this potential role for informatics was recognized early. In 1994, at the dawn of the Internet, Peter Szolovits, Jon Doyle, and William J. Long at MIT’s Laboratory for Computer Science, Isaac Kohane at Boston Children’s Hospital, and Stephen G. Pauker at New England Medical Center envisioned a lifelong patient-centered health information system. In their “manifesto” they “propose a major shift of primary focus away from information systems based on the hospital, clinic and medical practice, to one based on the individual.” The system, which they called “Guardian Angel” (GA), “integrates over a lifetime all health-related information about an individual (its “subject”), thus providing, at minimum, a comprehensive medical record that is often virtually impossible to reconstruct in a timely manner as the subject moves through life and work assignments” [2].

Until today’s EHRs existed and were widely deployed, the technical substrate for this vision didn’t exist. As we briefly discussed in the first article, widespread adoption didn’t occur until the Obama administration’s HITECH program provided the needed incentives and funding starting in 2009.

However, five years earlier, the Office of the National Coordinator for Health Information Technology (HIT) was created by the Bush administration, and Dr. David Brailer, the first National Coordinator for HIT, and the Secretary of Health and Human Services, Tommy Thompson, published a Framework for Strategic Action with a core mission of “Consumer-Centric and Information Rich Health Care” [3]. Encouraged by this publication, the same group at Boston Children’s Hospital that proposed GA described the Personal Internetworked Notary and Guardian (PING) [4], which it envisioned as a free, open-source Personally Controlled Health Record (PCHR). They designed PING to meet some key policy requirements and to support population-wide research. Chief among the policy objectives was that the PCHR exist outside the administrative structures of any particular health care institution. At the time (and this is frequently still true today) personal health record systems were often institution- or company-specific repositories for health information. PING was designed to be an interoperable, patient-controlled health record. It allowed each patient to maintain their own encrypted record in a storage site of their choosing. The group presciently envisioned that storage sites might be server farms or individual Internet accounts. Access, authentication, authorization, and encryption would be done by publicly accessible PING servers. A key goal was to shift control of the record entirely to the patient and away from any institution or care provider.

Subsequently, numerous attempts were made to create and successfully deploy a PHR. Google Health, launched in 2008 and discontinued in 2011, convinced many people that the concept was not viable. It was based on the Continuity of Care Record (CCR) one of Health Level 7 (HL7’s) pre-FHIR standards for rich clinical data that failed to achieve widespread adoption, as alluded to in the first article. In its announcement that the service was ending, Google said, “There has been adoption among certain groups of users like tech-savvy patients and their caregivers, and more recently fitness and wellness enthusiasts. But we haven’t found a way to translate that limited usage into widespread adoption in the daily health routines of millions of people” [5]. Microsoft launched its HealthVault PHR in 2007. One particularly interesting idea that the company pursued was HealthVault insights “with the goal of helping patients generate new insights about their health” [6]. However, it terminated further development of that effort in early 2018 and recently announced that HealthVault itself would be discontinued in November 2019.

So, given all of this, is the PHR an idea whose time will never come?

PHRs on FHIR

An honest answer to that question is probably that it’s still too early to be certain. There are numerous published studies that outline the factors that contribute to low adoption. All agree that, as with CDS, PHRs need to be easy and efficient to use if they are going to achieve widespread adoption. As was true of Google Health, HealthVault typically used a pre-FHIR HL7 document based standard. However, that is now rapidly changing.

The 21st Century Cures Act was signed by the President Obama in December 2016. Its primary goal was to help accelerate medical product development and bring new innovations and more rapidly and efficiently bring advances to patients. It was also designed to bring patient perspectives into the FDA’s decision-making process for development of drugs, biological products, and devices. As part of that aim, it requires that “[electronic health records] are able to be exchanged, accessed, and used through the use of application programming interfaces without special effort.” It specifically requires EHRs to provide application programming interfaces (APIs) toward that end to remain certified. It was widely anticipated that once the first normative version of the FHIR standard was released by HL7, the API requirement will specify FHIR. The R4 version of FHIR was released on 27 December 2018 and, as promised, it contained the first normative (e.g., in final form) content:

  • the RESTful API, the XML and JSON formats, and the basic datatypes;
  • the Terminology Layer (CodeSystem and ValueSet);
  • the Conformance Framework (StructureDefinition and CapabilityStatement);
  • the key resources Patient and Observation.

This new FHIR API landscape seemingly offers a solution to much of the ease of use problem that has kept PHR adoption from occurring, so might a FHIR enabled ecosystem of EHRs make creating and maintaining a PHR easier for patients? Several commercial vendors have developed FHIR-based app solutions based on this premise that allow patients to relatively easily aggregate data from all their providers. However, by far the most significant new development is Apple’s support of FHIR as the basis for its version of a PHR.

In March 2018, Apple announced that an “updated Health Records section within the Health app brings together hospitals, clinics and the existing Health app to make it easy for consumers to see their available medical data from multiple providers whenever they choose.” The announcement listed 12 well-known health care organizations that were participating in the beta test program for the new software and this number has subsequently grown to at least 500. The capability is implemented in the March 2018 11.3 version of iOS using FHIR.

In describing the new software, Apple said “consumers will have medical information from various institutions organized into one view covering allergies, conditions, immunizations, lab results, medications, procedures and vitals, and will receive notifications when their data is updated.” The company went on to say that “Health Records data is encrypted and protected with the user’s iPhone passcode.”

Figure 1. Screenshots from the Apple Health app illustrate that data are brought together from multiple providers (left) and can be viewed by the user in what the company claims is a clear to understand timeline view (right). (Photo courtesy of Apple.)

Figure 1. Screenshots from the Apple Health app illustrate that data are brought together from multiple providers (left) and can be viewed by the user in what the company claims is a clear to understand timeline view (right). (Photo courtesy of Apple.)

Figure 1 shows screen shots from the Apple Health app. The shot on the left illustrates that patients see an integrated view of their medical records even if they derive from multiple providers. The potential importance of this to patients with multiple chronic diseases cannot be overstated. Around 20% of Americans aged over 65 years and enrolled in the Medicare program have five or more chronic diseases. And according to an important article I often cite, “beneficiaries with 5 or more chronic conditions see almost 14 different physicians in a year and average 37 physician visits annually” [7]. The ability of each of these physicians to clearly know what all of the others have done for a patient is highly dependent on interoperability among their various EHRs. It has long been argued that the patient is the ideal point at which all of their medical data should be aggregated. Among other advantages, patients have the absolute right to share their data making conveying it all to a particular physician (or providing it for research) far simpler than in other scenarios.

The shot on the right shows how Apple organizes the data for each patient in what the company describes as “a clear, easy to understand timeline view.” FHIR plays a key role in doing this since EHRs are so user configurable that data may be represented differently even in the same EHR used by different hospitals.

Figure 2. Screenshots from the Medisafe app running on an iPhone illustrate that a patient’s medications, once brought together from multiple providers, can be imported into a third-party SMART app (left) and used to reconcile the physician’s instructions with the patient’s schedule (middle) in order to provide custom-tailored reminders (right). (Photo courtesy of Medisafe.)

Figure 2. Screenshots from the Medisafe app running on an iPhone illustrate that a patient’s medications, once brought together from multiple providers, can be imported into a third-party SMART app (left) and used to reconcile the physician’s instructions with the patient’s schedule (middle) in order to provide custom-tailored reminders (right). (Photo courtesy of Medisafe.)

In June 2018, Apple announced that it had “delivered a Health Records API for developers and researchers to create an ecosystem of apps that use health record data to better manage medications, nutrition plans, diagnosed diseases and more.” That announcement featured the Medisafe FHIR app, shown in Figure 2, which takes advantage of having a comprehensive view of a patient’s medications to help organize them and provide personalized reminders when it is time to take them. The figure illustrates key steps in this process from importing medications into the app (as FHIR resources), reconciling the directions with how and when the patient is taking each medication and creating a reminder calendar to encourage compliance with those directions. Once again this is of particular importance to patients with multiple chronic diseases who, according to [7], “fill almost 50 prescriptions in a year.” Taking these many medications properly and on time is a huge challenge for these typically elderly patients.

Tools to empower patients to stay well and better manage disease once they get it is an exploding area, and this brief discussion only hints at what is already available and likely to come in the future. A good example of this is AliveCor’s Kardia Mobile device that detects the electrocardiogram (ECG) heart trace and sends it to the company’s smartphone app where it can actually be interpreted to detect atrial fibrillation, the most common cardiac arrhythmia. Published studies [8] have shown this to be an effective screening technique for what can be an elusive diagnosis because of the sporadic nature of the arrhythmia in many patients.

This potential for empowering patients has gained enormous traction. Both the Medicare program and the U.S. Veteran’s Health Administration (VHA) now offer patients the ability to access their claims (in the case of Medicare) or VHA EHR data for use with FHIR apps of their own choosing.

We conclude with these remarks made by the Centers for Medicare and Medicaid Services (CMS) Administrator, Seema Verma, at the 2019 Health Information and Management Systems Society (HIMSS) Global Conference & Exhibition, which is by far the largest health information technology meeting in the world: “By identifying the FHIR standard to implement our policies, we are promoting scalable data sharing, not just an individual patient record from hospital to hospital but a model that supports the flow of information across the entire healthcare system. We encourage industry to align in this direction, because it is coming. Locking information into proprietary data models will soon be a thing of the past.” As this is being written, rules to implement this vision have been posted for public comment, so it seems likely today that the API for PHRs and other purposes will be FHIR.

In this article and the prior one, we looked in more detail at how FHIR can provide valuable tools for providers and their patients. In the final article, we will look at applications of FHIR to areas beyond direct patient care such as research.

References

  1. “Computerisation of personal health records,” Health Visitor, vol. 51, no. 6, p. 227, Jun. 1978.
  2. P. Szolovits et al., “Guardian Angel: Patient-centered health information systems,” MIT Lab. Comput. Sci., Cambridge, MA, USA, TR-604, May 1994. [Online].
  3. T. G. Thompson and D. J. Brailer, “The decade of health information technology: Delivering consumercentric and information-rich health care,” Jul. 2004. [Online].
  4. W. W. Simons, K. D. Mandl, and I. S. Kohane, “The PING personally controlled electronic medical record system: Technical architecture,” J. Amer. Med. Inform. Assoc., vol. 12, no. 1, pp. 47–54, Jan. 2005. [Online].
  5. A. Brown and B. Weihl, “An update on Google Health and Google PowerMeter,” Jun. 2011. [Online].
  6. Microsoft, “Microsoft HealthVault,” 2018. [Online].
  7. G. Anderson and J. Horvath, “The growing burden of chronic disease in America,” Public Health Rep., vol. 119, no. 3, pp. 263–270, May–Jun. 2004. [Online].
  8. J. P. J. Halcox et al., “Assessment of remote heart rhythm sampling using the AliveCor heart monitor to screen for atrial fibrillation,” Circulation, vol. 136, no. 19, pp. 1784–1794, Nov. 2017. [Online].