While the Fast Healthcare Interoperability Resources (FHIR) standard is widely adopted worldwide and serves as a standard of choice when defining regulations for secure and effective healthcare data exchange, FHIR security needs to be addressed.
The standard offers implementation guides (IGs), which are rules for using FHIR Resources and the building blocks of the standard. The FHIR Security and Privacy Considerations has a list of recommendations on areas of security an implementer should cover when leveraging the FHIR standard but no step-by-step guide on how to do that.
Not all the capabilities that FHIR enables may be appropriate or legal for use in some combinations of context and jurisdiction (e.g., HIPAA, GDPR). It is the responsibility of implementers to ensure that relevant regulations and other requirements are met.”
HL7 FHIR Security Specification
In this article, we will show you how Edenlab’s team implemented recommendations from the FHIR specification when building FHIR-first solutions for our clients.
FHIR Security Options
There are several popular options for securing FHIR servers from unauthorized access and protecting sensitive patient information. A protected FHIR server, which can be used for EHR systems or patient portals, requires building a security business layer. Okta and Keycloak are the two most popular tools for that purpose.
- Okta: a cloud-based identity and access management (IAM) system for authentication, authorization, and user management with various integration options and a user-friendly interface.
- Keycloak: an open-source IAM for authentication and user management. The system provides advanced customization functionality through plugins and extensions.
Okta and Keycloak support essential features such as single sign-on (SSO) and multi-factor authentication (MFA), providing users with secure access to applications and resources.
Another commonly used option for a protected FHIR server is the SMART on FHIR framework, designed for maintaining the security and integrity of healthcare systems. It leverages the OAuth protocol recommended in the Security Specification to ensure that only authorized users can access sensitive health information.
According to the FHIR specification, creators of health IT solutions will be in charge of developing the best security strategy for their systems. For that task, experience in FHIR protection and implementation and a deep understanding of the domain and its ever-changing requirements for protecting sensitive healthcare data are required.
Read also: FHIR vs HL7: Which is the best
Real-World Examples of FHIR Best Data Protection Practices Implementation
A major goal of data protection laws and the push for regulatory compliance in healthcare, especially for national regulations, is ensuring the ethical and safe use of healthcare information. Hence, to become a certified developer of health IT solutions, one should establish data security functionality defined in the requirements for certification in their region.
Moreover, non-compliance with regulations can cause reputational damage, lead to breaches and consequent leaks of sensitive personal data, and result in significant monetary loss due to possible penalties for failing to meet requirements under HIPAA and GDPR. So, here are the best ways to handle FHIR security and privacy concerns.
SMART on FHIR
Implementing the SMART on FHIR framework allows for interactions across various applications and systems and ensures compatibility with ONC requirements since the last update of the (HTI-1) Final Rule Certification Program Updates, Algorithm Transparency, and Information Sharing includes a requirement for the SMART on FHIR scopes 2x support.
The HL7 SMART App Launch Implementation Guide provides instructions on setting up and managing OAuth-based authentication in healthcare applications. It covers the authentication process, including requesting and managing access tokens, handling user consent, and securely exchanging information between clients and servers.
When deploying an FHIR-compliant solution with a custom clinical data mapper for Elation Health, our team implemented the SMART on FHIR functionality to the EHR platform so users could explore needed information via third-party applications without compromising the security of authorization and authentication processes.
As a result of ensuring support for the relevant USCDI (United States Core Data For Interoperability) version for EHR interoperability and SMART on FHIR functionality for security, our partners have successfully achieved ONC certification.
Service-Based Access Control
Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) are security models that manage access to FHIR resources through authentication and authorization mechanisms. The SMART on FHIR framework supports RBAC and ABAC.
RBAC sets access levels (patient, user, system), while ABAC uses the “launch” scope for decisions based on attributes like patient encounters or location contexts. Attributes include FHIR security tags, which define access policies and can require patient consent for further disclosure to protect sensitive medical data.
Our team has implemented ABAC in healthcare projects to ensure the highest security standards. For example, when building a national clinical data repository, ABAC was implemented to restrict doctors’ access to patient records to those created by their colleagues within the same institution, maintaining secure data boundaries.
For the national E-Health system, ABAC enabled flexible access policy configurations for patient medical data and empowered patients to decide who can access their medical information.
FHIR Login Events
Healthcare data is inherently sensitive, necessitating comprehensive logging and monitoring of system events and user actions. FHIR offers AuditEvent and Provenance resources to monitor system events and user actions when logging from third-party applications.
The AuditEvent resource is designed to record detailed information about actions within healthcare systems, focusing data viewing, creation, modification, and deletion. Edenlab’s FHIR experts implemented the IHE Basic Audit Log Profile (BALP) for audit events in the Kodjin FHIR Server to provide a robust framework for auditing activities in healthcare applications.
The Provenance resource records and manages metadata about the history of a FHIR resource. It provides detailed information about the origin, activity, and changes made to a resource, ensuring data integrity and supporting regulatory compliance. In the Kodjin FHIR Server, Provenance resources are generated by the client application, initiating actions such as creating or updating a resource.
Leveraging these FHIR resources and technologies can help organizations maintain data integrity and ensure a secure environment for managing sensitive healthcare information.
Digital Signatures
Digital signatures in FHIR allow for verifying medical data’s authenticity, integrity, and non-repudiation. These signatures bind specific data to a verified source, ensuring that recipients can trust the information’s origin and that any unauthorized changes render the signature invalid.
A digital signature applied to the data at the end of any modifications guarantees that any subsequent alterations invalidate the signature, which is crucial since FHIR resources can comprise parts of a patient’s medical record or other critical medical documentation.
Edenlab’s team used electronic digital signatures (EDS) and blockchain-like algorithms to ensure the data integrity and security of a Unified Registry of Healthcare Professionals as part of the e-Health project. In the unified registry, a clinic CEO enters an employee’s details, signs the request with EDS, and sends it for verification. The employee confirms via email, creates a password, and completes their registration.
The system is integrated with all accredited centers to certify digital signatures in Ukraine and guarantee the legitimacy of electronic signatures.
Security Labels
FHIR security labels allow the attachment of specific security metadata to resources or bundles. The access control decision engine uses labels to:
- Approve or deny read, change, and other operations
- Determine which resources return to the user
- Identify the handling caveats to convey with the data
Security labels ensure the secure flow of data by embedding policy rules directly within the resource data. Recipients of data with security tags must enforce these rules and carry the security labels forward to aid ABAC by linking attributes to resources that define access control policies, like requiring explicit patient consent for disclosure.
Labels guarantee that only authorized users can access sensitive medical information, ensuring compliance with regulations and building patient trust. FHIR security labels are most effective within a Mutual Trust Framework, where all trading partners agree to adhere to common policies.
Other HL7 FHIR Security Considerations
Complying with the requirements of data security standards (e.g., HIPAA, HITRUST, ISO 27001, GDPR, SOC-2) allows for addressing data protection concerns and creating a Mutual Trust Framework for protecting healthcare data from unauthorized access and breaches.
By following recommendations on security in FHIR from the Implementation Guide and complying with the above-mentioned standards, healthcare actors can achieve enhanced patient trust, legal adherence, reduced data breach risks, and FHIR protection against cyber threats.
Therefore, leveraging compliant data management solutions like the Kodjin FHIR server can significantly improve data privacy practices and guarantee compliance with regulations requiring the FHIR Application Programming Interface for healthcare data interoperability while ensuring FHIR API security.
Do not hesitate to consult our FHIR experts on the best FHIR security practices that will satisfy your project’s needs.
