Alissa Knight on 'Standing Outside The FHIR'

We are delighted to be hosting some unique content from our friend and recovering hacker Alissa Knight who will be writing on the topic of healthcare API security. In this blog, Alissa provides a plain English explanation of FHIR from the perspective of a hacker. Enjoy!

Standing Outside The FHIR

Before I can fully explain what Fast Healthcare Interoperability Resources (FHIR) is and why it’s the target of my next phase of vulnerability research, I need to first demystify the different organizations involved here then cover a few definitions.

Demystifying HL7

Health Level Seven (HL7) is one of those organizations where the name is the same as the product. For example, Coca-Cola is the company whose product is, well, Coca-Cola. Health Level Seven International is an international standards organization whose most recent standard is called Health Level Seven or HL7. So now you’re probably wondering why HL7 is needed and what exactly it is?

The healthcare industry is made up of different entities, from hospitals to doctors’ offices (healthcare providers) to the payers (health insurance companies) and of course, the patients themselves. Within those organizations are a bastardized stack of different software applications that must be able to talk to each other and share data between them, both within the company and externally to the other entities. A “rosetta stone” if you will was needed in order to try and create a standard that all of these software applications used in order to speak the same language so that billing/back office data, electronic health records (EHR) and other data like could all be read and written by these disparate applications. Many of the applications these organizations use are legacy and use proprietary formats.For mobile traffic, it’s a little more complicated because the solution can’t challenge users so enterprise customers either need to reluctantly accept false positives or they need to find other solutions to circumvent those false positives. 

Enter HL7. The Health Level Seven International organization came on stage to create the necessary standards that all of these organizations could build their applications around in order for them to all talk — basically the rosetta stone that could glue all of these different platforms together and speak the same language. These HL7 standards were even adopted by the famous American National Standards Institute (ANSI) and International Organization for Standards (ISO).

Without trying to bore you to sleep, it is important that I also complicate this further by saying HL7 even has different versions. For example, one of the many standards HL7 International maintains are the Structured Product Labeling (SPL) standard which is what’s used to standardize the labeling on medication bottles and the Clinical Document Architecture (CDA), both of which are based on HL7 version 3. Now, fast forward to 2020 when one of the more recent standards came out of HL7 International — the Fast Healthcare Interoperability Resources (FHIR) standard — pronounced fire.

Lighting The FHIR

FHIR is simply a framework, a schematic for how data should be formatted and an application programming interface (API). Think of HL7 version 2 and 3 as the predecessors to FHIR as it's the data standard it grew up from. Think of an API as the rosetta stone or “Google translate” that allows different applications, especially legacy healthcare applications using different data formats to speak a single language. The data format can be XML (extended markup language), JSON, and RDF. The original premise of FHIR was to extend healthcare data to other providers and the patients themselves on any platform, from web browsers running on computers to apps running on mobile devices. Using FHIR, discrete data elements, such as pathology reports, allergy information, clinician reports, billing information, etc can all be exposed as HTTP services via their own unique URLs (E.g. https://api.company.com/patient/1001).

FHIR quickly gained steam (no pun intended) and adoption skyrocketed by large multinational corporations, including Apple in January of 2018 for Apple’s Health app, and other prominent companies in the healthcare informatics field. This is where it gets very interesting. In 2020, the Centers for Medicare and Medicaid Services (CMS), responsible for the administration of medicare and medicaid in the U.S., issued their Interoperability and Patient Access final rule, in response to the 21st Century Cures Act that officially required use of FHIR by the payers and providers regulated by the CMS. This final rule set into motion the mandated adoption of FHIR by providers and payers to facilitate EHR interoperability between providers, payers, and patients and set deadlines for compliance. The Patient Access API and Provider Directory API deadline is currently set for July 01, 2021, while the payer-to-payer data exchange deadline was set to January 01, 2022.

Why You Should Care

FHIR enables you as the patient to be able to access your patient data from any provider. This means if your data is accessible by you from any provider, your data is accessible by anyone other than you if the FHIR API isn’t properly secured.

In March of 2021, I published part one of my research after reverse engineering 30 mobile health (mHealth) apps and hacking their mobile APIs. This research highlighted systemic problems in the healthcare industry around the proper authentication and authorization of mHealth APIs through patient and clinician account access.

Implications Of Insecure FHIR APIs

As my research in part one demonstrated, when an API isn’t properly secured, an unauthorized individual can access your most vital information that, unlike a stolen credit card, it can’t be replaced. The reason protected healthcare information (PHI) is worth 1,000 times more on dark web marketplaces than a credit card number is because of how much data is contained in a single PHI record.

In the first part of this research, I was able to access thousands of pathology reports, allergy information, x-rays, photos, lab results, clinician reports, billing information, patient photos from hospital admissions, and more across all of the APIs tested. I did this by using a script to mimic genuine API traffic and was able to exploit broken object level authorization (BOLA) vulnerabilities. Because of a systemic failure of companies to implement authorization in addition to authenticating their API requests, simply having a valid account allowed me to access other patients’ records.

The purpose of this research is to underscore what can go wrong when companies hurriedly attempt to meet the CMS final rule deadlines without properly securing their APIs.

This is the first in a series of blogs. In the next article, I’ll cover mobile API authentication and authorization. In the third article, I’ll dig deeper into the security challenges facing those implementing FHIR APIs. Finally, in my last article of the series, I’ll summarize some of the vulnerability findings from this phase of my research into hacking FHIR APIs from the white paper published by Approov.

Sources

Policies and Technology for Interoperability and Burden Reduction | CMS. (n.d.). Centers for Medicare and Medicaid Services. Retrieved April 20, 2021, from https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index

Industry Voices—Forget credit card numbers. Medical records are the hottest items on the dark web. (2021, January 26). FierceHealthcare. https://www.fiercehealthcare.com/hospitals/industry-voices-forget-credit-card-numbers-medical-records-are-hottest-items-dark-web 

Wikipedia contributors. (2021, February 11). Health Level 7. Wikipedia. https://en.m.wikipedia.org/wiki/Health_Level_7

Wikipedia contributors. (2021c, February 27). Fast Healthcare Interoperability Resources. Wikipedia. https://en.m.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources

https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index