STU3 Candidate

This page is part of the FHIR Specification (v1.8.0: STU 3 Draft). 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: n/a

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:

6.0.2.1 FHIR Implementation Guidance and Principles:

6.0.2.2 FHIR Resources:

6.0.2.3 FHIR Datatypes:

6.0.3 Security

Security in FHIR includes the set of considerations required to ensure that data can be discovered, accessed, or altered only in accordance with expectations and policies. FHIR includes implementation guidance 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 considerations and principles, see Security.

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 preferences. 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 (ref) 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 details, see Security: Binding.

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: 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. For details, see Security: Audit + add reference to ATNA for conseptual background (GG).

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:

  • More specific implementation guidance for particular Authorization scenarios (for example, we may incorporate the SMART on FHIR authorization specification for user-authorized apps).
  • 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.