Why a security component is as critical to your FHIR ecosystem

A white paper was recently released to the FHIR community titled, “Playing with FHIR: Hacking and Securing FHIR APIs”. This white paper was authored by a cybersecurity expert in penetration testing and provides some interesting insights into the vulnerabilities of implementing FHIR.

First the good news – no vulnerabilities were found in the HL7 FHIR standard itself. All of the vulnerabilities actually lie on the implementation side of things. Here is a summary of four key findings from the report:

• 53% of mobile apps tested had hardcoded API keys and tokens which could be used to attack EHR APIs.
• 100% of FHIR APIs tested allowed API access to other patient's health data using one patient's credentials.
• 50% of clinical data aggregators did not implement database segmentation allowing access to patient records belonging to other apps developed on their platform for other providers.
• 100% of the mobile apps tested did not prevent person-in-the-middle attacks, enabling hackers to harvest credentials and steal or manipulate confidential patient data.

The bad news is that these vulnerabilities are relatively elementary when it comes to hacking. In fact, these vulnerabilities are covered in the OWASP top ten risks. The existence of such vulnerabilities in the early adoption of FHIR makes it clear that as much attention needs to be focused on securely implementing FHIR workflows as there is on leveraging the standard itself for innovation.

FHIR has tremendous upside potential to transform the way data is shared in healthcare over the next decade. The ONC and CMS have put their trust in FHIR by mandating its use in recent rules related to the exchange of data among patients, payers, and providers. Rather than being a stumbling block, it is hopeful that this report will push the industry forward with a tighter focus on the security of FHIR implementations moving forward.

In meeting the regulatory mandates and unleashing innovation in general, a well thought out FHIR ecosystem must deliver on a number of key items including:

1. Unlocking siloed legacy data in a FHIR-based way,
2. Exposing the FHIR data in a modern way for app usage, and
3. Securing the data at all points, especially during the last mile.

Securing data should be front-of-mind in any FHIR implementation. Implementing FHIR requires diligent implementation processes and an API security product, such as an API Gateway, to build your implementation strategy upon.

As for the discovered vulnerabilities in the report, a key focus area for any FHIR implementation should be to utilize the SMART on FHIR authentication framework. By enforcing SMART on FHIR authentication, which uses oAuth2 and scopes, one can limit access to only the authenticated patient and only the interactions allowed in the scope down policy. Thus, accessing multiple patient records from a single patient login account would be mitigated. In addition, appropriate oAuth2 grant types should be chosen for public applications, data should always be encrypted in-transit and at-rest, and of course database segmentation should be followed by aggregators.

While I think everyone in interoperability would like to see FHIR move forward at light-speed, there will undoubtedly be bumps in the road. I believe it can be a good thing that these vulnerabilities were identified, and hopefully it will put more focus on implementation and having the right security tools in place so that FHIR can move forward to change interoperability in the way that we hope.

Written by:

Rob Brull, Sr. Product Director