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.

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 Internet User Authorization (IUA) Profile provides support for user authentication, app authentication, and authorization decisions. To allow for these features, CA:FeX actors can be grouped with IUA actors.

The following security expectations are considered to be applied to CA:FeX IG:

• Systems SHALL conform to FHIR Security requirements.

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.

Additionally, many FHIR transactions using HTTP REST will include query parameters that would be identifiers, quasi-identifiers, or sensitive health topics. For example, it is common for patient identifier to be a query parameter. With this URL pattern, the query parameters are typically visible in the server audit log or browser history. The risk from this visibility should be mitigated in system or operational design, by protecting the logs as sensitive data, or by designing other measures into the system to prevent inappropriate exposure.

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:
  • the SMART App Launch Authorization,
  • mutually authenticated TLS,
  • the FAST HL7 UDAP Security for Scalable Registration, Authentication, and Authorization IG, or
  • the OAuth Server to Server Authentication as defined in SMART Back-end Services.
  • When using UDAP, OAuth tokens issued SHALL be tied to the client system's certificate

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:

• Communications
• Authentication
• Authorization/Access Control
• Audit Logging
• Digital Signatures
• Security Labels
• Narrative