If you've been staying on top of the latest news in healthcare interoperability, you've no doubt seen the results of the Approov research done by cybersecurity analyst Alissa Valentina Knight. Testing the vulnerability of three production Fast Healthcare Interoperability Resources (FHIR) APIs, Knight was able to access more than 4 million patient and clinician records. And she was able to do it easily. She also made clear that these vulnerabilities are not inherent in FHIR. Instead, she concluded that there are pervasive authorization vulnerabilities.
The research looked at organizations who exposed FHIR APIs without a full developer experience built in, and she found huge security gaps that all healthcare organizations need to address — or risk exposing sensitive patient data. That kind of breach would be a nightmare for your organization from a compliance, reputation, and financial standpoint.
FHIR alone is not enough
The healthcare industry has been scrambling hard to get FHIR stood up. Opening up your organization using FHIR will reduce costs, help you move faster, and give patients the ability to get their own data.
But while FHIR is a great enabler, it wasn't made to secure your enterprise. It can't enforce your organization's policies and procedures. It doesn't give you an audit trail of what's happened. You need to do that yourself because you also need to prove that you authenticated the person making a request, and authentication happens outside of FHIR.
It's like leaving the front door of your house unlocked. You have to be able to get things in and out, but you don't want the door to be left wide open. Anyone could misuse something or come in and take something. You need that lock, and you need a record of who's been in and out. People put cameras on their front doors because they want to know who came to the door. Even if the person didn't come in, you want to know who was there.
A secure layer on the front end of your FHIR APIs protects you and makes it easier for others to do business with you. And you need it to give you records that prove you didn't do anything wrong if someone says you were the source of a data breach.
An experience API layer—your front door security
A secure layer between your FHIR APIs and third-party developers is the lock and camera on your FHIR API front door.
That layer is a full lifecycle API management solution. With it, you can have security policies built in, giving you visibility into all data going out and coming in so you can detect attempted data breaches and prevent them from happening. You'll also have centralized control and monitoring of API access and be able to provide security while enabling widespread adoption and data exchange tracking.
Your FHIR APIs are your core APIs. Beyond that, you need to secure, register, and authorize third-party developers. You can put experience APIs in front of your FHIR APIs or put a policy engine into place that ensures that the person requesting has the proper credentials.
A security layer can "ask the right questions." Is this person authorized to use this? Does the combination of what he’s doing make sense? You can put a policy engine in place through security authentications and integrations with the rest of your organization that says, "If you're authorized to use the patient access, you should not be also using the provider access." You could also do this by asking for consent, using an API engine to call out and ask, "Do you have consent?" A policy engine gives you multiple ways to make sure that the FHIR API is being used properly.
Open APIs with confidence
Healthcare organizations realize that opening their data through APIs is essential to building infrastructure that can meet the requirements today and in the future. You can make sure your FHIR APIs are secure with just a little extra work. You just need to install that lock and that camera at your front door.
Learn more about how to secure your FHIR APIs. Get the ebook, "Open for innovation: Turning interoperability into opportunity."