Electronic Health Information (EHI) Export API

Starting on December 31, 2023, patients will have the right to request and download a comprehensive digital copy of their EHR. Mandated by the 21st Cures Act Rule from the Office of the National Coordinator for Health Information Technology (ONC), the data must be available in a publicly documented, machine-readable format. 

While this marks important progress in affording patients autonomy over their EHI, the current regulations do not require Application Programming Interface (API) access. Hence, the burden on patients to access, manage and use the data may be prohibitive.

As mandated by the 21st Century Cures Act Rule today, any patient can, via the SMART on FHIR API, download the 100 or so elements in the U.S. Core for Data Interoperability. The Apple Health App and the CommonHealth App make this process extremely easy. And patients can further share those data with caretakers, providers, researchers, or other apps.  

The Cures Act Final Rule EHR provisions become much more powerful if patients can likewise use apps to make API requests for their complete EHI. And for as much of those data as possible to be in the familiar FHIR format. Example use cases include: 

  • Sharing healthcare data with a clinician for a second opinion,
  • Subjecting one’s health data to artificial intelligence-based processes to provide personalized decision support,
  • Donating one’s EHI for research and innovation purposes.

To this end, the SMART Health IT team has proposed and led development of a standards-based EHI Export API specification as part of Health Level Seven’s (HL7’s) Argonaut Project. The resulting draft implementation guide (IG) was built with four overall design goals: 

  • Support integration with manual workflow steps such as medical records staff review, redaction, or format conversion; 
  • Support vendor-specific capabilities and provider-specific forms to filter or limit the volume of data sent when users make that choice; 
  • Support returning EHI data with consistent FHIR-based metadata wrapping an combination of standardized or proprietary export files;
  • Support internal use of the API by IT or automated systems to stitch together data from multiple certified EHR systems.

This work, funded by cooperative agreement 90AX0022 from the Office of the National Coordinator of Health Information Technology, builds on the EHI Export API’s draft IG, creating a sample patient-facing web application for making EHI export requests, a reference implementation of an EHI server storing synthetic patient data, and a UI for medical records staff to manage export requests on the EHI server. 

In addition to deploying these demonstration capabilities publicly, the code for these implementations have been published as open source software. Releasing these, we aim to lower barriers for health systems adhering to this new information blocking language and to improve interoperability of EHI export implementations, promulgating open standards and technologies that build off of previous successes in HL7 standards. A standard EHI Export API can lead to a vibrant ecosystem of interoperable, patient-facing export capabilities, empowering patients data ownership and improved patient decision making driven by the complete data in their medical record.

Figure 1: An architecture diagram visualizing the relationships of our project’s three central components: sample patient-facing application, EHI export server, and admin export management application.

Resources: 

  • Draft IG for EHI Export API

  • EHI Server

  • Sample Patient Application: The Second Opinion App

    • Code: https://github.com/smart-on-fhir/ehi-app 
    • Demo: https://ehi-app.herokuapp.com/ 
    • About: A sample patient-facing application implementing the EHI Export API’s client interactions. Consisting of a UI and its own backend server, our second opinion application allows users to create new EHI export requests, check on in-progress exports, and download completed exports containing synthetic patient data directly onto their machines. 

  • EHI Export Management Application

    • Code: The same repo as the second opinion app, https://github.com/smart-on-fhir/ehi-app 
    • Demo: https://ehi-app.herokuapp.com/admin/ 
    • About: Our admin export management application demonstrates how medical records staff (“admins”) can view EHI export requests, add EHI attachments manually to them, and review them using custom EHI server API endpoints. Though these endpoints and UI interactions are not prescribed by the EHI Export API IG, they allow exploration of organization-specific EHI export workflow choices.