An EHR Perspective on the Consumer-Focused API/App Landscape

By Hans Buitendijk
EHRA Executive Committee member
Chair, Interoperability & Standards Workgroup

kevin-grieve-712217-unsplashONC’s 2015 Certification Edition for EHRs began supporting consumer access to their health data beyond patient portals. Open APIs were required to enable consumer Apps to access data from the Common Clinical Data Set. Because at the time there were no standards sufficiently mature to establish as a base, the requirement allowed for access by any means as long as the technical specifications, including terms and conditions, were made publicly available to enable App developers to write their Apps on top of these APIs.

A lot has happened since then.

The HL7® FHIR® standard started to take hold and is now seen by many as the desired format to express APIs. A collaboration of various EHR vendors and providers created the Argonaut Project to establish implementation guidance on top of the HL7® FHIR® standard, taking a first step towards achieving consistent interpretation and implementations of the standard.  

And last year a major consumer-focused vendor, Apple, rolled out a capability to access data that used the Argonaut implementation guide, while other consumer App vendors started to create connections with EHRs based on EHR vendors’ technical specifications. While we don’t have comprehensive statistics, based on initial data points, millions of API-based interactions using 2015 Certified Edition APIs have already occurred.

There are four areas of particular interest to highlight on the progress made, and progress still to be made:

  • API Formats
  • App Development Environments
  • Consumer and App Authentication
  • App Registration

API Formats

In January 2019, EHRA polled our members to get a sense of what path EHR vendors had chosen to support the open API requirements.  Of the 15 companies that responded (43 percent of EHRA membership):

  • 6 are basing their APIs on FHIR DSTU 2, of which 3 used the Argonaut Data Query Implementation Guide Version 1.0.0
  • 4 are basing their APIs on FHIR STU 3
  • 4 are basing their APIs on a proprietary format

With the proposed ONC rule on conditions of certification, ONC has suggested establishing HL7® FHIR® DSTU 2 as the base; however, given current adoption, progress made to date, and the anticipated timelines when the open APIs are expected to go into effect, we believe that HL7® FHIR® R4 provides a more suitable base to be the first named standard for open API content to support the proposed USCDI. In combination with a process along the lines of the proposed Standards Version Advancement Process, such approach would create a stronger base, with opportunities to advance beyond an already 3+ year old standard with two new versions since that time, while enabling further innovation.

App Development and Test Environments

App developers have the opportunity to further develop and test their Apps in a number of different vendor sandboxes. Half of the respondents to EHRA’s survey already have or have plans to create a development environment, while nine have a test environment or plan to deploy one to validate interactions with the API. Additional services may be offered to provide assistance, though they are not required.

Validation is critical to an App developer, to raise their level of comfort that the App will work as intended for consumers. The entry of API brokers and aggregators, such as Apple, and convergence on a common, base standard may provide additional opportunities for App developers to test their capabilities, depending on the validation offered and/or required.  

It is important to note that any such testing would not address the use of the data provided to the consumer’s App. The consumer must at all times be aware and appropriately consent to the App and the App developer’s use of their data. The CARIN Alliance is developing a Code of Conduct designed to provide consumers a higher level of trust when selecting an App from a third-party developer that has signed on to the Code, once finalized. But even then, consumers must be educated so they understand that they are ultimately responsible for the the privacy of their health data, once it’s been shared by the healthcare provider through the App or EHR portal.  

Consumer and App Authentication

Along with HL7® FHIR®, the use of OAuth and OpenID has taken hold as well to create a secure/trusted connection.  From the same January 2019 survey of EHRA members, we found that 11 use OAuth and OpenID, of whom 10 use the SMART implementation guidance for OAuth and OpenID. One uses SAML2 as well. Clearly, OAuth and OpenID provide a common platform to aim for as the base to collectively move forward, particularly using the SMART implementation guidance.

App Registration

Connecting a patient’s App of choice with their providers’ EHRs will ultimately realize the data exchange benefits being sought. Each stakeholder plays an important role:

  • The patient must indicate to the provider their desire to connect an App to the provider’s EHR/IT infrastructure
  • The provider needs to work with their EHR vendor to indicate which App(s) are to be connected to their infrastructure
  • The App developer needs to ensure their App works with the EHR vendor, register the App, and obtain the appropriate tokens to connect to the EHR
  • The patient then must authorize the App to access data on their behalf

Clearly each step is essential to ensure that the patient, their App, and the provider’s EHR are correctly connected. One ideal future state involves “dynamic registration” where the patient presents their App to the provider’s IT infrastructure and everything flows from there automatically without manual steps. That, or a similar automated process, is not yet a reality.  

When surveying EHRA membership we found that 15 out of 15 respondents require one or more manual steps by the provider and/or their EHR vendor. There are different models in play, with 8 of the 15 respondents registering an App for each provider, while 4 register the App to enable access to all their providers but still require other activation steps.

ONC recognized this in the 2015 Certification Edition by not requiring the use of dynamic registration, and continues to recognize this in their proposed rule. In lieu of dynamic registration, ONC proposes that EHR vendors have the ability to verify the authenticity of the App developer, recognizing the risks of a malicious App developer to spoof another App developer’s legitimate App, and propose timelines on when validation and connections are completed.  

Additionally, ONC proposes that healthcare providers have the sole authority and autonomy to unilaterally permit connections to their health IT. This implies that an EHR vendor could not restrict nor grant access to APIs without a provider’s express authorization, or beyond the considerations under the proposed information blocking provisions for reasonable and necessary exclusions. OCR also further clarified through the HIPAA Omnibus rule of 2013 and more recent FAQs that covered entities, thus by extension organizations (such as EHR vendors) operating under a Business Associate agreement with that covered entity, would not be liable for the actions of any Apps a patient selects once they receive the data. Considering concerns on how to establish reliable, trusted connections, this is a prudent approach.

For many this simplifies the registration process, while ensuring the patient, the provider, and the EHR vendor have the necessary involvement in the process of turning on an App for a given patient. In addition to a technology component, process and contractual components are necessary to enable rapid and scalable registration. It is encouraging to see national networks starting to address accelerated scaling of FHIR-based data access at a national level, which has the opportunity to reduce the friction in this space.

Summary

Much has happened since the 2015 Certification Edition was published. The foundation has been laid.  Now we need to continue to learn and build together to expand on the capabilities while scaling deployment to enable our clients, healthcare providers, and their clients, the patients, to reach the goals we have collectively set.

Leave a comment

1 Comment

  1. EHR Developers are Aligned with Goals of Cures NPRM, Hope ONC will Remove Ambiguity and Reassess Timeline | EHRA Blog

Share your thoughts on this topic!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  • Categories

  • Follow EHRA on Twitter

  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 154 other followers

  • Contact Us

    Elinore Boeke
    Communications and Media
    elinore @ kecommunications.net
%d bloggers like this: