Security

Patient Privacy Considerations

Infoway has developed a privacy primer, Privacy as an Enabler, that provides an introduction to interoperability, an overview of Canadian privacy laws and some practical approaches to privacy for interoperability. It delves into the role privacy plays in the creation of interoperable health systems. It addresses the myth that privacy laws mean patient data can’t be shared. The primer outlines how privacy laws enable the sharing of patient data by providing guidance on how to share health data safely with a patient’s consent, and the responsibilities of both parties when patient information is shared.

This specification depends on Smart App Launch which profiles an OAuth 2.0 authorization process, such that the user decides what access to grant to the application that they are using.

Patient Safety

Accessing Patient records raises many questions about safety. Accessing the wrong patient records, missing correct records, displaying records incorrectly, or having non-authorized actors access records can create real harm to patients. The Implementer Safety Checklist page gathers clinical safety advice acquired from experience of accessing health records across FHIR APIs like this one.

Patient Matching

When synchronizing a patient record, it’s important to match not just on a pre-existing patient identifier, but also to match patient demographics. Additional care should be taken for patient merge and un-merge scenarios.

Security Considerations

Fast Healthcare Interoperability Resources (FHIR) is not a security protocol, nor does it define any security-related functionality. However, FHIR does define exchange protocols and content models that need to be used with various security protocols defined elsewhere. FHIR interactions defined as part of the CA:FeX implementation pattern often make use of patient-specific information which could be exploited by malicious actors resulting in exposure of patient data. For this reason, all FHIR interactions must be secured appropriately with access to limited authorized individuals, data protected in transit, and appropriate audit measures.

The following security expectations are intended to apply to CA:FeX IG:

In alignment with the Base FHIR Specification recommendation, The Smart-On-FHIR profile on OAuth is a recommended method for using OAuth.

Future releases will evaluate further constraints regarding SMART App Launch Framework and the use of IUA. Reviewers are encouraged to provide feedback on the incorporation of these constraints.

SMART standard describes a set of foundational patterns based on OAuth 2.0 for applications to authorize, authenticate, and integrate with FHIR-based data systems. SMART defines a discovery document available at .well-known/smart-configuration relative to a FHIR Server Base URL, allowing clients to learn the authorization endpoint URLs and features a server supports. This information helps client direct authorization requests to the right endpoint, and helps clients construct an authorization request that the server can support.

SMART uses the OpenID Connect identity management protocol, which allows applications to request access to clinical data. This access might be simple read-only access to a few records, broad read/write access to an entire EHR, or anything in between. The SMART specifications describe a specific flavor of OpenID Connect that is customized for use in the health context.

Exchange Security

  • Transport Level Security (TLS): Systems SHALL use TLS version 1.2 or higher for all transmissions not taking place over a secure network connection. (Using TLS even within a secured network environment is still encouraged to provide defense in depth.)
  • Identity Verification and Authorization: For identity validation, use one or more mechanisms below:

CA:FeX Cross Profile Considerations

For implementers looking to enhance functionality around Network Security, Authentication, Authorization, and Auditing, it is important to note that the CA:FeX specification offers further guidance on groupings between CA:FeX actors and other IHE profiles, such as IUA and ATNA (CA:Sec and CA:Aud). This strategic grouping enables additional security features and functionalities. Specifically, there is a dedicated CA:Sec implementation guidance that supports secure communications extensively. To leverage these advanced security capabilities, CA:FeX actors can be grouped with CA:Sec actors, allowing for a robust and secure integration that meets rigorous compliance and security standards in healthcare information exchanges. For further information please refer here.

Authentication

Authentication is the process of confirming that a user is the owner of a given identity. This is usually done by asking the user to provide credentials proving the ownership. Such credentials can be passwords, second factors of authentication (like push notifications or one-time passwords), or biometrics.

Previously, authentication was defined as a proof that users are who they say they are, but more recently standards like NIST make a distinction between authentication and identity proofing, which is a process of verifying a person’s identity using knowledge-based user attributes, document verification, wallet-based factors, ID verification, or national identity systems.

OpenID Connect is a simple identity layer built on top of the OAuth 2.0 protocol, which allows Clients to verify the identity of an end-user based on the authentication performed by the authorization server, as well as to obtain basic profile information about the end-user.

Authorization

Authorization is the process of determining what information an authenticated user can or cannot access. Authorization can be implemented using policies and rules, as it is the case for role-based access control (RBAC). Frameworks like OAuth 2.0 describe standard authorization flows that can be used for handling delegated authorization.

OAuth2 is an authorization protocol that enables a user to authenticate to an application using their credentials from another application, for example "Login using Google". As part of this authorization standard, the application can also have Scopes that define the permissions to perform specific functions, for example application requesting to "access my contacts".

For more details please refer to the Reference Architecture specification - Authentication and Authorization and SMART on FHIR pages

Implementers should be aware of the security considerations associated with FHIR interactions, particularly those related to: