Playing with FHIR, Safely - How Particle Balances Access, Security and Privacy

There’s a nervous energy in the Twittersphere over Playing with FHIR, Alissa Knight’s findings of FHIR API vulnerabilities across a number of mobile apps and data aggregators. Alissa’s yearlong research project, which I’ll call the Knight Report, has made an immediate impact among our fellow FHIR fans. Check it out, but a lot can be summed up with this statement from the report: 

The findings in this report will show that of the three FHIR APIs I tested, which comprised an app ecosystem of 48 total FHIR apps, and aggregated EHR data from over 25,000 healthcare providers and payers, the FHIR APIs contained pervasive authorization vulnerabilities that allowed me to access over 4 million patient and clinician records with my own patient login.

The good news is that reputable apps have no cause for alarm. The better news is that her report has started a discussion that should rightfully be had throughout the health IT industry. 

I wanted to take a moment and discuss which technologies are under fire in the Knight Report, why Particle has never elected to use such technologies, and where the industry is headed next. I’d also like to touch on Particle’s approach towards achieving the right balance of access, security, and privacy.

The Knight Report and Why We Should Talk About It

I had never heard of Alissa Knight or Approov before this report. After doing a little research, I found them to be a really interesting team focused on highlighting incredibly important weaknesses in a tech industry that tends to move faster on development than on security.

New legislation is pushing healthcare stakeholders to adopt consumer tech-friendly APIs, but this hasn’t been free from controversy. A major point of friction is how to provide access, privacy, and security at the same time.

The healthcare industry needs to maintain these three interconnected elements at a level that matches what existed before widespread interoperability. We’ll never be assured of privacy if security is lacking. Concerningly, most organizations default to taking the security component for granted.

In 2021 alone, the number of data breaches outside of healthcare has been staggering:

• Colonial Pipeline
• Facebook
• Bonobos
• Kroger
• Parler
• T-Mobile
• Volkswagen & Audi
  

(just to name a few).

While these breaches have been harmful, their impact is often swept under the rug due to the low perceived value of the stolen data. Breached companies pay for identity theft monitoring and move on.

In comparison, health data is irreplaceable. We can argue that its personal impact is enormous - the Knight Report even demonstrated an attacker’s ability to change active prescriptions. A single medical record on the black market can sell for $250, or 50 times the cost of a financial record. The special importance of this data requires extra attention to security.

By now, healthcare organizations know that they are not off limits. In the first six months of 2021 alone, an astonishing 343 healthcare organizations reported a security breach. A rather disastrous example was Memorial Health System, whose 64 clinics and hospitals were held hostage with encryption for about a week in August. Hackers threatened to leak patient data unless a ransom was paid.

In light of this report, new access points - credential-based FHIR APIs - present a lucrative new opportunity for hackers. What is it about these APIs that make it so easy for groups like Knight’s team to slip in?

Why Particle Has Elected Not to Leverage These Credential-Based APIs

While hospitals and EMRs had built portals to address Meaningful Use policies, they’ve recently evolved those access functions into APIs in accordance with Info Sharing rules. 

These access points connect to applications and allow the user to log into their accounts (using a username and password) at a hospital, for example, and share some of their EMR data with that application. This is what we call credential-based access, and here’s where the problems start.

First off, applications don’t truly know who is logging into which account. We know that password security is not the best. It’s not hard for someone to guess a username. Even in the most mundane cases, a family member might find or even ask for the info and inadvertently log into an application later - resulting in data sharing without consent.

Secondly, from a more practical standpoint, people just don’t remember their passwords for all the providers they’ve seen over the years. While credentials work for things like connecting my Venmo to Bank of America, I couldn’t tell you which hospitals, practices and clinics I’ve been to over the course of my life.

What happens when you forget your password? Some organizations use knowledge based questions, typically backed by groups like Equifax: 

The issue here is, you can pretty easily buy basic identity info online. The Equifax breach made an unimaginable amount of this information available to malicious groups to simply purchase.  

You can also reset your password via a 2FA method like your email - which comes with its own security holes - or you can call into your provider and ask. In practice, most providers will reset account access for anyone who can answer a few knowledge-based questions over the phone. 

This debate between credential-based access and its competitor, identity-based access, has been burning among the interoperability camps for years.

For some context, I wrote a blog post last year called Interoperability 3.0 outlining the evolution of health data sharing. It explains why and how Particle has positioned itself as the developer’s choice in a growing ecosystem of health data. In short, the choice to incentivize well-thought-out interoperability over messy portal scraping comes from practical and security concerns we’ve engaged with since our founding.

What exactly do I mean by messy? Let me share one example from page 16 of the Knight Report:

With one patient engagement app, the API endpoint sent me all the patient and clinician records in its database, indicating it was using the mobile app to filter out just my record.

Suffice it to say, that was not a thoughtfully built API. 

At Particle, however, we don’t allow just anybody to connect to our platform. Additionally, network-based data sharing is not tied to a centralized repository of information, but rather a federated network that creates on-demand records of patients upon a successful patient match. 

To be clear, the HL7 FHIR standard itself remains theoretically secure. The issue is that applications that connect to EHR data through poorly built APIs were shown to lack elementary security standards.

Where the Industry is Headed On Secure Access

Most reputable developers know what not to do. Their challenge remains how to share the medical data we’re entitled to without sacrificing security and privacy.

From Particle’s vantage point, there are two competing schools of thought: 

1. Identity-based access 
2. Credential-based access 
   

I talked a bit about #2 above, but identity-based access isn’t perfect either. In fact, there is no real “perfect” solution seriously being considered. The best bet is for the industry to adopt a unique identifier (kind of like an SSN) for every person in the US that’s only used for sharing medical data - but we can save that for another time.  

So this brings us to the only other option really on the table - identity-based access. What does identity-based access entail, why is preferable to credentials, and where is it now? 

Identity-based access, the way Particle works today, is by using five demographic points (like name and birthdate) to match against existing healthcare databases. When these tightly-controlled databases find really high confidence matches, we download the data and return it to the requesting provider.

This method works really well because it reduces the level of burden on the patient to basically nothing. Before a patient shows up to their appointment, we’ve already found + returned their data to their provider and inserted it into the record or displayed it for the provider. 

The missing piece here is that the provider can act as a bit of a security gatekeeper. We’ve never heard of returning a wrong record, but if we did, clinical staff would be ready to filter it out.

Identity-based access is an additional step we can implement that ensures a patient is really who they say they are. You might know many vendors doing this today - groups like Clear and ID.me meet IAL2 level identity controls, using things like the DMV databases and facial recognition. In practice, it looks like this: 

1. Alice downloads her cool new app
2. App asks permission to pull Alice’s medical data
3. App uses IAL2 identity vendor to confirm Alice’s identity (typically a selfie + driver’s license scan)
4. Identity + demographics sent to Particle to query for records after Alice’s ID authenticated
   

While this flow is oversimplified, it is far more simple and secure than asking a patient to log into a bunch of different portal accounts from a personal device as demonstrated in the Knight Report.

The #1 reason we hear providers say that identity-based access isn’t happening? Providers are incredibly nervous about sending the wrong record to the wrong patient.

While Particle can send an Identity + Demographics payload, the provider system itself might not know which medical record in their system maps to that particular identity. For those that know about the Birthday Paradox, this presents a challenge with patient matching.

For now, this is as far as groups like Particle can go. We can’t influence every US provider to update their patient matching technology, adopt new policies (e.g. including more demographics to match better), or try something different. 

The Info Sharing rule mandates that patients should be able to access their records in technically feasible ways. This gives providers a bit of a conundrum; they have the credential-based access method and the ability to respond to identity-based requests.

FHIR Security: How You Can Prevent Wild FHIRs

Fortunately, TEFCA is rolling out next year. TEFCA mandates that national networks allow for individual access requests (as well as other use cases). This means that individuals can receive their EHI and send it directly to another entity. 

So, entities will have to begin improving their capabilities around individual access. Eligible entities are not limited to healthcare providers, which means that groups outside of the FHIR ecosystem will start addressing these issues as well.

We don’t know if TEFCA-compatible networks will rely on identity-based security, credential-based security, or both. 

The Knight Report recommends that RESTful security measures like Particle provides - plus security investments like our SOC2 achievement and the Penetration Testing bounty program we set up for whitehat hackers - should be the status quo.

We hope its conclusions will help shape the decisions being made.