Skip to main content
In Development

This section is in development and is not complete or ready for review.

Actors in the Use Cases

  • Patient
  • RelatedPerson
  • Person
  • Group
  • Practitioner
  • Organisation

Security And Privacy

The appropriate protections for Privacy and Security are specific to the risks to Privacy and the risks to Security of that data being protected. This concept of appropriate protections is a very specific thing to the actual data. Any declaration of 'required' or 'optional' requirements that could be mentioned here are only recommendations for that kind of Resource in general for the most dominant use of that Resource. Where one uses the Resource in a way that is different than this most dominant use, one will have different risks and thus need different protections. Each Resource is indicated with the dominant "Security Category", and all of the Resources Security Category is shown on the Resource Types page with the Security Category tab.

Security​

  • Resources
  • Authentication
  • Authorisation

Resources​

Individual Sensitive These identities are needed to enable the practice of healthcare. These identities are identities under general privacy regulations, and thus must consider Privacy risk. Often access to these other identities are covered by business relationships. For this purpose, access to these Resources will tend to be Role specific using methods such as RBAC or ABAC.

No Dominant Some Resources can be used for a wide scope of use-cases that span very sensitive to very non-sensitive. These Resources do not fall into any of the above classifications, as their sensitivity is highly variable. These Resources will need special handling. These Resources often contain metadata that describes the content in a way that can be used for Access Control decisions.

Authentication​

Except when no patient data are involved such as Provider Directories and test sandbox systems, FHIR servers need to authenticate the client system and trust it, or authenticate the individual user by a variety of techniques. For web-centric environments it is recommended to use OpenID Connect icon (or other suitable authentication protocol) to confirm the identity of the authenticated end user, where it is necessary that end-users be identified to the application.

For scalable security, either UDAP Consumer-Facing icon or UDAP Business-to-Business icon should be implemented, as appropriate. The Registration and Discovery sections of UDAP Security icon should also be implemented to securely scale the addition of new client and server endpoints. Tiered OAuth for User Authentication icon should be implemented to securely scale trust with new OIDC credential issuers.

All systems shall protect authenticator mechanisms, and select the type of credential/strength of authenticator based on use-case and risk management.

Authorisation​

From Client (GET, PUT etc) From Server (GET) client creating a resource through a PUT/POST, as much as it is true for a server returning resources on a GET.

Correctly identifying:

  • People
  • Devices
  • Locations
  • Organizations
Object Type

Authentication

Authorisation

Access Control

People

OpenID Connect

1

ABAC

RBAC

Devices

*1

1

digital Signature

Locations

* 1

1

2

Organisations

* 1

1

2

Role-Based Access Control (RBAC)​

  • Permissions are Operations on an object that a user wishes to access
  • Grouped into roles
  • A role characterizes the functions a user can perform
  • Roles are assigned to users
  • FHIR Operations - CRUDE
    • Create
    • Read
    • Update
    • Delete
    • Execute

Attribute-Based Access Control (ABAC)​

  • Access request is granted or denied based on a set of access control policies that are specified in terms of attributes and conditions.
  • Resource can have attributes associated with them
    • Client
      • Identity
      • Role
      • Location
      • Level of Assurance
    • Resource
      • Security tags
      • confidentiality
      • sensitivity
      • type of data
      • data range
      • author
    • Patient
      • Identity
      • Patient relationship with user
      • Patient Consent policies
    • environment conditions / Context of transaction
    • SYstem Identity
    • Time of day
    • Token expiration
    • Token Scope
    • Purpose of Use Workflow state Transport Security
    • ....

A policy is defined.... tag x = not to be further disclosed without explicit consent from the patient.

Access Control

Cross-Community Access for Imaging(XCA) Cross Enterprise Document Sharing (XDS)

Examples

Internal Resource Security: Within a hospital access to a patient's medical data is restricted to personnel who are involved with the patient's medical treatment and the corresponding administrative activities (e.g., billing). Access to certain sensitive information is further limited to certain functional roles in order to ensure that this information is only disclosed to people who need to know it for a dedicated purpose.

Patient Privacy Consent: Within a regional healthcare network the ability is provided to exchange medical patient data among the participating medical organizations. A patient may determine which organizations are allowed to access to their medical data.

Secondary Use: A patient grants access to certain of his medical data to a medical study provided that all data is pseudonymized before use.

Break Glass: In case of an emergency, access restrictions from patient provided policies and internal security regulations are overridden by a dedicated emergency policy which allows a physician to access all medical data of the patient. Part of this emergency policy is the obligation that a specific entry is written to a secure audit trail.

Individual Opt-Out: A nurse is scheduled for a surgery in the hospital where she works. She does not want staff members working in the same department to get any insight into her administrative and medical data.

Infrastructure​

TLS​

NTP​

Firewalls​

Security Labels​

approve read, change, and other operations determine what resources can be returned determine what handling caveats must be conveyed with the data

The intent of a security label is that the recipient of resources or bundles with security-tags is obligated to enforce the handling caveats of the tags and carry the security labels forward as appropriate.

Policies​

Obligations​

Mutual Trust Framework​

Local agreements and implementation profiles for the use security labels should describe how the security labels connect to the relevant consent and policy statements

Which Security Labels are able to be used What to do if a resource has an unrecognized security label on it Authoring obligations around security labels Operational implications of security labels This specification defines a basic set of labels for the most common use cases trading partners, and a wider array of security labels that allow much finer grained management of the information.

Tags

  • Context of User
  • Data Sensitivity
  • Control o fLow
  • Break Glass

Provenance​

AuditEvent​

Permissions​

Smart on FHIR​

Out of Scope​

Extend Claims in ID Token to include FHIR security tags