FHIR Release 3 (STU)

This page is part of the FHIR Specification (v3.0.2: STU 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3

Work Group FHIR Infrastructure & Security Ballot Status: Informative

6.0 Security and Privacy Module

6.0.1 Introduction

The Security and Privacy Module describes how to protect a FHIR server (through access control and authorization), how to document what permissions a user has granted (consent), and how to keep records about what events have been performed (audit logging and provenance). FHIR does not mandate a single technical approach to security and privacy; rather, the specification provides a set of building blocks that can be applied to create secure, private systems.

6.0.2 Index

The Security and Privacy module includes the following materials:

Resources Datatypes Implementation Guidance and Principles

6.0.3 Security

FHIR is focused on the data access methods and encoding leveraging existing Security solutions. Security in FHIR needs to focus on the set of considerations required to ensure that data can be discovered, accessed, or altered only in accordance with expectations and policies. Implementation should leverage existing security standards and implementations to ensure that:

  • All communications can be encrypted to prevent unauthorized access.
  • No information leaks when errors occur
  • No active script content can be injected into narrative resources
  • Full audit trails can be constructed and used to detect anomalous access patterns

For general security considerations and principles, see Security. Please leverage mature Security Frameworks cover device security, cloud security, big-data security, service-to-service security, etc. See NIST Mobile Device Security and OWASP Mobile Secuity . These security frameworks include prioritized lists of most important concerns.

6.0.4 Privacy

Privacy in FHIR includes the set of considerations required to ensure that individual data are treated according to an individual's Privacy Principles. FHIR includes implementation guidance to ensure that:

  • Individual preferences can be communicated through standards-based protocols (e.g., OAuth, User-Managed Access) or using an explicit FHIR representation (Consent)
  • Resources can be tagged to indicate the sensitivity or confidentiality of the data they represent (Security Labels)
  • Data access records and audit logs can be shared with individuals, e.g. for accounting of disclosures (Audit Event)

6.0.5 Common Use Cases

6.0.5.1 Authorization and Access Control

Use case: A FHIR server should ensure that API access is allowed for authorized requests, and denied for unauthorized requests.

Approach: Authorization details can vary according to local policy, and according to the access scenario (e.g. sharing data among institution-internal subsystems vs. sharing data with trusted partners vs. sharing data with third-party user-facing apps). In general, FHIR enables a separation of concerns between the FHIR REST API and standards-based authorization protocols like OAuth. For the use case of user-facing third-party app authorization, we recommend the OAuth-based SMART protocol see Security: Authentication as an externally-reviewed authorization mechanism with a real-world deployment base — but we note that community efforts are underway to explore a variety of approaches to authorization. For further details, see Security: Authorization and Access Control.

6.0.5.2 Audit Logging

Use case: "A FHIR server should keep a complete, tamper-proof log of all API access and other security- and privacy-relevant events".

Approach: FHIR provides an AuditEvent resource suitable for use by FHIR clients and servers to record when a security or privacy relevant event has occurred. This form of audit logging records as much detail as reasonable at the time the event happened. The FHIR AuditEvent is aligned and cross-referenced with IHE Audit Trail and Node Authentication (ATNA) Profile. For details, see Security: Audit.

6.0.5.3 Privacy Consent

Use case: "Documentation of a Patient's Privacy Consent Directive - rules for Collection, Use, and Disclosure of their health data."

Approach: FHIR provides a Consent resource suitable for use by FHIR clients and servers to record current Privacy Consent state. The meaning of a consent or the absence of the consent is a local policy concern. The Privacy Consent may be a pointer to privacy rules documented elsewhere, such as a policy identifier or identifier in XACML. The Privacy Consent has the ability to point at a scanned image of an ink-on-paper signing ceremony, and supports digital signatures through use of Provenance. The Privacy Consent has the ability to include some simple FHIR centric base and exception rules.

All uses of FHIR Resources would be security/privacy relevant and thus should be recorded in an AuditEvent. Those access qualifying as a Disclosure should additionally be recorded as a Disclosure, see Disclosure Audit Event Example.

For Privacy Consent guidance and examples, see Consent Resource.

6.0.5.4 Provenance

Use case: "All FHIR Resources should be capable of having the Provenance fully described."

Approach: FHIR provides the Provenance resource suitable for use by FHIR clients and servers to record the full provenance details: who, what, where, when, and why. A Provenance resource can record details for Create, Update, and Delete; or any other activity. Generally Read operations would be recorded using AuditEvent. Many Resources include these elements within, this is done when that provenance element is critical to the use of that Resource. This is overlap is expected and cross-referenced on the W5 report. For details, see Provenance Resource.

6.0.5.5 Signature

Use case: "Digital Signature is needed to prove authenticity, integrity, and non-repudiation."

Approach: FHIR Resources are often parts of Medical Record, or are communicated as part of formal Medical Documentation. As such there is a need to cryptographically bind a signature so that the receiving or consuming actor can verify authenticity, integrity, and non-repudiation. This functionality is provided through the signature element in Provenance Resource. Where the signature can be any local policy agreed to signature including Digital Signature methods and Electronic Signature. For details, see Security: Digital Signatures.

6.0.6 Developmental Roadmap

In the STU3 release, FHIR includes building blocks and principles for creating secure, privacy-oriented health IT systems; FHIR does not mandate a single technical approach to security and privacy.

In future releases, we are anticipate including guidance on:

  • incorporate the SMART on FHIR authorization specification, for user-authorized apps,
  • methods for organization-to-organization authorization,
  • more details about how to use digital Signatures for data integrity and non-repudiation, including an approach that supports some level of manipulation of resources (e.g. separating the entries in a bundle, or conversion between XML and JSON during processing),
  • more detailed Consent management, including support for specific consent use cases.