As electronic health records (EHRs) have moved from paper to computers over the past decade — nearly 90% of office-based physicians now have an EHR — “Can’t you just look it up on the computer?” has become an increasing refrain from patients expecting their medical history to be at their physician’s digital fingertips. For integrated health care systems with robust electronic health records, access to information is profound. Providers can read notes, interpret labs, view imaging and beyond, all from a screen, instantaneously.
Across disparate institutions, however, the story is very different. Substantial effort has been made to achieve interoperability between organizations, such as through regional health information exchanges, among others, with meaningful results. Yet such efforts have assumed institutions at the center of interoperability. What if we empowered patients to be digital stewards of their health data — allowing them to cut across their myriad physician office visits, home health encounters, and increasingly retail services such as flu shots or blood pressure readings?
Under the Health Insurance Portability and Accountability Act (HIPAA), there is little ambiguity as to whether patients have the right to access their health information. The Privacy Rule requires that HIPAA-covered entities give individuals access to their data, upon request, with some exceptions such as psychotherapy notes. Before wide-scale adoption of EHRs, this usually entailed paper records, in-person requests to hospital health information management offices, and a fee. The increasing digitization of clinical records has improved access to some clinical data, through patient portals and initiatives such as OpenNotes. This has been motivated in part by regulatory incentives.
For example, the Center of Medicare and Medicaid Services (CMS) “Meaningful Use” program (recently rebranded “Promoting Interoperability”) has required progressively more electronic access to clinical data for patients — from electronic copies of data and discharge summaries (stage 1); to the ability to view, download, or transmit this information to a third party (stage 2); to the third and current stage, which requires patients have the ability to connect third-party applications to their medical records through Application Programming Interface (API) technology, a mechanism for software applications to communicate directly with EHRs. The 21st Century Cures Act accelerates this even further, defining interoperability (“access to a patient’s data . . . without special effort”) and spelling out an API requirement for the certification of EHRs.
In the context of this increased regulatory pressure, there has been a flurry of recent activity accelerating patient access to their electronic health data. In February 2017, the Health Level Seven (HL7) International Argonaut Project, a standards acceleration effort involving the major EHR vendors, released an industry-developed open API built on the HL7’s Fast Healthcare Interoperability Resources (FHIR) standard to be made freely available to any application developer or EHR vendor. In January 2018, Apple announced an update to their Health app that would enable consumers to directly retrieve medical data from the EHRs of participating providers that adopted that standard through consumer-facing APIs. This was followed by a June announcement of a forthcoming Apple Health Records API, which would enable a third-party ecosystem of consumer-facing applications to be built using these data in Apple iOS products.
In March, the U.S. Department of Veterans Administration, along with a consortium of providers and vendors, signed the Open API pledge to expand the set of data resources available to patients, physicians, and care teams through APIs standardized by the HL7 Argonaut Project. In a March speech at the Health Information and Management Systems Society (HIMSS) conference, Seema Verma, Administrator of CMS, stated: “CMS believes the future of health care depends on the development of open APIs.” She also announced several new initiatives designed to empower patients to gain access to their health data. Particularly exciting is that these efforts dock into the very same HL7 FHIR Argonaut Project, among other standards-based efforts. Finally, in an August event at the White House, Amazon, Google, IBM, Microsoft, Oracle, and Salesforce all pledged to further reduce interoperability barriers. While details are scant, this is yet more evidence of the industry’s convergence toward an open health care API standard.
Building a Sustainable Ecosystem of Safe, Patient-Driven Digital Health Care
We view increased patient access to clinical data as a positive direction, with numerous benefits. First, better access to data can help increase patient engagement — early evidence from the OpenNotes initiative, for example, suggests that providing patients with visit notes increases health understanding, relationships with providers, adherence, and self-care. A second benefit to increased access to data is around record portability. Patients would not have to rely on two doctor’s offices to exchange information — they could more easily bring this clinical information themselves when seeking care, reducing friction.
A third benefit is around enabling a patient-facing app ecosystem with the ability to exchange health information with EHRs. One of the first applications to use the Apple Health Records API, for example, is Medisafe, a company that enables patients to better manage their medications. Another example is an app that might notify family members when a patient is admitted to a hospital. A final use case is research participation. Patients could directly contribute their EHR data to research efforts. Sync for Science, a pilot program within the national “All of Us” research effort, is just one example of this.
Despite the recent public and private focus on this area, other areas will need further development to make patient-led data sharing successful and sustainable. First, the amount of data available to patients electronically will need to expand. The Office of the National Coordinator for Health IT (ONC) provides certification criteria for EHRs, which includes specific data requirements for APIs. The ONC 2015 Certification Criteria, for example, includes a definition of the Common Clinical Data Set (CCDS). The CCDS includes a total of 21 data fields for frequently used clinical data, such as demographics, medication lists, problem lists, and laboratory results. There are notable gaps, however. Not included in this data set are provider notes and imaging, which are absolutely essential for patient record portability. Also not required are appointment information and cost and payment data, important for patient engagement with a provider organization.
Recognizing the need to expand the baseline data requirement, the U.S. Core Data for Interoperability Task Force (part of the Health Information Technology Advisory Committee, established by the 21st Century Cures Act) has issued draft documentation outlining a mechanism for expanding U.S. Core Data for Interoperability beyond the CCDS — with an initial step to add clinical notes and provenance to the CCDS. A roadmap for numerous candidate data elements is also included in this draft documentation for items such as admission/discharge dates, functional status, care team members, encounter information, and imaging interpretations.
Anticipating these requirements, the HL7 Argonaut Project has picked up the hard work of mapping some of these data elements to FHIR, but it would benefit from greater industry demand for such standardization. That said, we anticipate that over the next 5 years, the amount of data made available to patients through EHR APIs will significantly expand.
A second area that will need further development is patient privacy. Provider organizations as data gatekeepers is a well understood paradigm, with carefully specified laws and regulations, like HIPAA. Moving data out of these organizations and directly into the digital hands of patients challenges this paradigm. The HIPAA privacy rule, for example, applies to narrowly defined covered entities, and does not include consumer applications, social media, fitness trackers, etc., nor health data as a class of data.
Third, while much of the acceleration of increased digital access to data has been motivated through regulation, continued incentives and/or a sustainable business model will be essential for long-term success. Major EHR vendors have already recognized the opportunity for revenue generation. For example, the Epic App Orchard and the Cerner App Gallery are nascent marketplaces for the purchasing of applications; similar to other app marketplaces (e.g., the Apple App Store or Google Play Store), the vendors receive a percentage of revenue generated from the purchase of software from their stores.
Additional digital health innovation platforms and marketplaces may emerge from outside the traditional health care information technology ecosystem. As mentioned above, Apple’s recently announced Health Records API product may exert pressure on health care systems — in the form of more than 80 million U.S. iPhone users — to increasingly allow patient access to data. For a nominal developer account fee, third-party developers can build iOS apps and access patients’ health information using the new Apple Health Records API. For patient-facing applications, Apple may be more cost effective and less restrictive than EHR vendor app stores. Application vetting — clinical content review, validation, and security audit — is yet another revenue generation opportunity.
These new marketplaces will need close, multi-stakeholder input to ensure revenue incentives do not lead to stifled innovation and information blocking. For example, the extent to which vendors or provider organizations should be allowed to charge for access to data beyond the minimum required set is unclear. There are also usability features — such as allowing an application “persistent” access to receive new EHR data automatically (without requiring that a patient log in every time) — that are at risk of being heavily monetized to the detriment of patients and application functionality. Further clarity from federal oversight organizations such as the ONC may be necessary to craft guardrails for vendors, provider organizations, and app developers.
Finally, we note that while much of the initial focus has been providing patients with improved access to their health data, these same APIs could be repurposed to allow for more traditional data exchange between other entities, such as employers, payers, or accountable care organizations. These groups often have contractual rights to exchange patient data, but currently operate with significantly more friction than the “plug and play” functionality associated with API access. In fact, the 2019 Medicare Inpatient Prospective Payment System’s proposed rule includes the development of a pilot program that would allow eligible hospitals to utilize APIs for population-level data exchange in exchange for credit under the Public Health and Clinical Data Exchange objective. In this model, APIs are the first point of interoperability and the main access point for electronic health data exchange between all stakeholders.
Ultimately, how this plays out — how costs and revenue are shared between vendors, hospitals, payers, software developers, and patients (while still meeting regulatory requirements around data access); or how privacy regulations are modernized in the face of new technologies; or how open EHRs truly become around electronic patient data access — is yet to be fully realized. But the pieces are in place for a truly disruptive shift in how patients can access and use their own clinical data to improve their health, increase record portability, enable the use of novel third-party applications, and facilitate participation in research studies.