Securing API-based Access to Patient Data

By EHRA Standards & Interoperability Workgroup

One of the goals of the 21st Century Cures Act’s health IT provisions was to enable patients to have secure access to their electronic health information using Application Programming Interfaces (APIs). The Office of the National Coordinator for Health IT (ONC) advanced that objective when it published its May 2020 Final Rule, which specifies HL7(R) FHIR(R)-based standards that health IT developers (as well as provider organizations developing their own solutions) will be expected to implement so that patient can access their health data using apps of their choice, connected to APIs. But how can patients be assured that their health information is secure once it leaves the EHR? 

Health data are among an individual’s most sensitive information, obligating all members of the healthcare community to protect patient privacy by ensuring secure data exchange. This blog post will review how the ONC standards for patient access can enable best practices to securely share patient health data.

How Are Healthcare APIs Secured?

When a patient wants to let an app access their EHR data (using FHIR-based APIs), there is no technical reason why the patient couldn’t directly provide the app with the login and password for their patient portal account. However, that is generally not recommended. Directly providing an app with login credentials for another service or app results in security vulnerabilities should those credentials be compromised. That’s one of the reasons cybersecurity experts recommend everyone use unique passwords for each online account. 

So, if you aren’t supposed to share passwords across apps and patient portals, how can you provide an app with secure access to your data when it resides in another system? That’s where the OAuth 2.0 standard and tokens come in.

The SMART-on-FHIR implementation guide incorporates the OAuth 2.0 standard to mediate an app’s access to the EHR, when it uses FHIR APIs to connect. When the app requests access to a patient’s data, the EHR tells the patient what kind of data the app wants to access. If the patient authenticates — via the patient portal — and gives permission to share that data, the EHR issues the app two tokens:

  1. An access token that the app uses to connect with the API, as if it were the patient
  2. A refresh token that the app uses to maintain access by requesting additional access tokens

This approach is similar to how you might securely connect a personal budgeting app to your bank account in order to give it access to account balances and transaction information.

If an attacker can only steal a token instead of direct login credentials, then: 

  • An access token can only be used to get the subset of the patient’s data that the app needs.
  • An access token expires, so an attacker can’t keep using it to get new patient data.
  • A refresh token issued to an app only works with that app’s credentials.

The challenge is that depending on the kind of app, using refresh tokens may actually increase security risks. An app can be either: 

  • A confidential client in which the app is a web application, so that the server controlled by the app developer is responsible for fetching the data from an EHR
  • A public client, also referred to as a native app, is when the app resides on a general purpose device such as a phone or tablet, and is thus outside the app developer’s controlled server environment

A confidential client is typically better able to protect a client secret such as tokens. Web-hosted apps securely store their credentials, access tokens, and refresh tokens on web servers. Since patients use the app via a web browser, if a refresh token were to be stolen in transit the malicious actor wouldn’t be able to use it without also obtaining the client secret.

A public client or native app operating on a general purpose device, such as a smartphone or tablet, is controlled by the user, and may not always be up-to-date with the latest security controls. Consequently, there are different security risks associated with the software that have not been fully analyzed.

Next Steps For Secure Healthcare Apps

Because developers have reduced control over the security of the patient’s device, additional standardized guidance on securing API access is needed. Clear understanding of the potential risks is essential, given the expanded use of native apps, as well as the availability of technologies around refresh tokens, dynamic registration, and redirect_uris that can be used to mitigate risks in the context of threat models for the access, use, and exchange of health data.

The security of SMART “client-public” capability must be analyzed in the context of the different security risks, as compared to the risks of a confidential client. This analysis should leverage existing works from IETF publications on this topic, such as the OAuth 2.0 Threat Model and Considerations.  Standards development groups such as the Argonaut Project should prioritize projects that establish a clear and robust set of security expectations through guidance on required technologies for apps that access and handle patient data using APIs.

Raising the Floor for Security

Patients expect their private health information to be protected. The healthcare industry and its partners in government have the opportunity to raise the floor for cybersecurity and protect the privacy and security of health information. By requiring patient-facing apps that connect to FHIR APIs to meet a higher security bar, ONC can promote patient access to their health information while demonstrating leadership of the healthcare community by promoting cybersecurity best practices.

Leave a comment

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 169 other followers

  • Contact Us

    Kristi Feliksik
    kfeliksik @ ehra.org

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