Healthcare and Cyber Security: The (Technical) Breakdown of How FHIR Protects Sensitive Information
Written by Randy Salazar, Security Engineer
March 25, 2021
A little more than a decade ago, the U.S. had a great idea: To incentivize healthcare providers to upgrade from paper-based patient records to electronic medical records (EMRs). The logic is easy to understand.
Patient records stored digitally are searchable, easier to access, and easier to share with other care team members or with a doctor in another city or state caring for the patient during an emergency. The U.S. passed the American Recovery and Reinvestment Act (ARRA), including the Electronic Medical Records (EMR) Mandate, in 2009, but that left healthcare providers with two big questions to answer:
- How to do it
- How to do it securely
Fast Healthcare Interoperability Resources (FHIR), the standard for healthcare data exchange, provides the answer.
FHIR gives healthcare providers the data exchange framework they need, even if they’re sharing patient data with providers using different systems or storing data in different ways. Through the REST approach, FHIR gives healthcare organizations a workable way to standardize data transfer – much like the system that apps and web applications use – and make it easier and faster.
FHIR covers sharing data with patients. Patients, who are also internet surfers, e-commerce shoppers, and social media users, expect to interact with their healthcare providers easily and access information conveniently on digital channels. And healthcare organizations, especially those in competitive regions, want to deliver.
Furthermore, healthcare is coming out of its worst year so far regarding the number of data breaches – reporting 616 data breaches to HHS in 2020. With all eyes on security, healthcare organizations are not only looking at FHIR for how to transfer data but how to do it securely.
FHIR’s Security Controls
To increase healthcare data exchange security, FHIR outlines 11 security controls:
- Time Keeping. Any legitimate request for data will come from a system with the right time settings. This control requires synchronization using Network Time Protocol (NTP) or Simple Network Time Protocol (SNTP) – and a healthcare system should never share data with a system with the wrong settings.
- Communication Security. All data should be secured with a form of Transport Layer Security (TLS), a “handshake” protocol that allows a client and a server to authenticate each other.
- Authentication. It makes sense to authenticate all user identities. FHIR recommends OAuth for web-centric systems and SMART on FHIR for apps that use sensitive information or share it with external systems.
- Authorization/Access Control. FHIR’s framework uses a security label infrastructure for access control. Accurate labels will result in accurate searches. And, the correct labels will ensure that only the data requested is shared, and additional information is kept private. Also, it’s smart for healthcare organizations to follow the principle of least privilege, giving people access only when they need it to provide care or services. The logic here is that if a hacker were somehow able to steal their login and passwords, they’d only have access to limited systems or data.
- Audit. When it comes to sensitive information, it makes sense to know who has seen it or used it. Healthcare providers should be able to track where data originated, who authored it, its status, who has accessed it. However, you need to be careful – logs themselves shouldn’t contain any sensitive information that unauthorized people could see.
- Digital Signatures. FHIR requires digital signatures, as well as where they should be located on requests to prove that they’re legitimate.
- Attachments. FHIR allows file attachments, but because malware can be delivered through attachments, the framework recommends that healthcare organizations use other security measures, such as virus scanners and anti-malware.
- Labels. The FHIR framework allows healthcare organizations to label data with security-related tags for better control. However, they must be careful to ensure that if hackers learn the labeling system, they wouldn’t have carte blanche to access any data in the system. Again, healthcare providers should take the principle of least privilege to heart as well as test thoroughly to prove that sensitive information is safe.
- Data Management Policies. FHIR isn’t a security protocol itself, and it doesn’t cover all requirements of HIPAA or other regulations, such as the EU’s General Data Protection Regulation (GDPR). Following the FHIR framework can be a part of a healthcare organization’s ability to comply, but it defers to those regulations for specific requirements.
- Narrative. This control is a reminder that FHIR resources shouldn’t contain or display sensitive information, especially when unauthorized people could access it freely.
- Input Validation. Any input into a healthcare providers’ system must be validated. Otherwise, the organization is taking the risk that it could cause vulnerabilities or put data at risk. The Open Web Application Security Project (OWASP) provides a helpful Input Validation Cheat Sheet that offers guidance on the topic.
Building Security into Healthcare Applications
It’s important to protect any organization’s data, but in healthcare, it truly can be a matter of life or death. Security should be baked into the applications you develop, shifting security left so that it’s part of the very fiber of your software.
Developers can simplify the process by using a tool that analyzes Infrastructure as Code (IaC) so that as they create cloud-native applications, they’re sure that they meet FHIR standards. Every FHIR security control that your application addresses will lower the chances that a bad actor will find a way to access, steal, or corrupt data that healthcare organizations and their patients rely on.
Put the FHIR framework to work to protect healthcare data used in your applications.
(Photo by: https://icons8.com/)