Scalable Consent Management
1.0.0-preview - STU 1 PReview US

Scalable Consent Management, published by HL7 International / Community Based Collaborative Care. This guide is not an authorized publication; it is the continuous build for version 1.0.0-preview built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-consent-management/ and changes regularly. See the Directory of published versions

Plain Language Summary goes here

Overview

Official URL: http://hl7.org/fhir/us/consent-management/ImplementationGuide/hl7.fhir.us.consent-management Version: 1.0.0-preview
IG Standards status: Trial-use Maturity Level: 1 Computable Name: ScalableConsentManagement

Introduction

This guide details the consent management use cases as well as the required custom FHIR operations and profiles to exchange the required consent data elements both between the user and the consent management repository as well as between repositories.

Rationale

There is currently some support for some basic consent management use cases in the existing specifications, including FHIR Core and the IHE.ITI Privacy Consent on FHIR (PCF), mostly at the basic operations for creating, reading, and updating consent resources. Consent management, however, needs more implementation guidance and standardized specifications that are still missing. This includes the interactions between patients and the consent management system in the process of soliciting, navigating, and executing consents, which is sometimes referred to as a Consent Ceremony (see Definitions below), as well as a high-level API (e.g., defining custom FHIR operations) to cover use cases for consent management.

Definitions

Privacy Consent — As used in this guide, a Consent refers specifically to a Privacy Consent: an authorization by a patient (or someone acting on the patient's behalf) governing how the patient's health information may be collected, used, or disclosed. This guide constrains the FHIR Consent resource to represent privacy consents only. Other consent types defined in the FHIR Consent resource — such as research consent or treatment consent — are not in scope.

Consent Ceremony — The end-to-end process through which a patient's consent is solicited, reviewed, executed, and filed. This typically includes presenting a consent form or policy, allowing the patient (or their authorized representative) to review it, obtaining the patient's agreement or refusal, and recording the result as a FHIR Consent resource in a consent administration system.

Scope

Patient Consent management is the central component in a consent ecosystem and at the core of a scalable consent architecture. At a high-level, consent management covers all the use cases necessary to ensure that valid patient consents are collected and maintained. Our initial set of potential use cases are:

  1. Request Consent
  2. Review Consent
  3. File/Sign Consent
  4. Revoke Consent
  5. Delegate Consent
  6. Review Consent Provenance
  7. Propagate Consent Events
  8. Disclosure Audit

Permit and Deny; Opt-in and Opt-out

A consent recorded using this guide can express either a permit (the patient authorizes a specified use or disclosure) or a deny (the patient refuses or restricts a specified use or disclosure), as represented by the provision.type element of the FHIR Consent resource. Both permit and deny consents are within the scope of this guide.

Two related but distinct concepts — opt-in and opt-out — describe the default posture a jurisdiction or organization takes in the absence of an explicit patient consent decision:

  • Opt-in (explicit consent required): data may not be used or shared unless the patient has actively consented. A filed, active Consent with provision.type = permit represents the patient opting in.
  • Opt-out (consent assumed unless refused): data may be used or shared unless the patient has actively refused. A filed, active Consent with provision.type = deny represents the patient opting out.

Determining whether a particular data exchange requires opt-in or opt-out consent — and what the default behavior is in the absence of an explicit patient decision — depends on overarching jurisdictional and organizational policies and is out of scope for this guide. This guide provides the mechanisms to record, manage, and exchange the consent decision once it has been made; the policy framework that determines when and whether consent is required is handled in the Policy Administration environment surrounding this IG.

The following diagram provides a high-level overview of the consent administration system and its use cases within the context of other adjacent services and highlights what is in scope for this IG. At a high-level, there are four broad areas of service as discussed below. These are well-established concepts in access control and authorization literature, for example, the definitions of Policy Administration Point (PAP), Policy Decision Point (PDP), and Policy Enforcement Point (PEP) in the OASIS Extensible Access Control Markup Language (XACML).

  • Policy Administration covers all the processes and activities for creating, updating, and maintaining authorization policies. Consents are part of the authorization policies authored by the patient (or someone on the patient's behalf). The policy administration functions related to consents are within the primary focus on this IG and within its scope. Consents as referenced in this IG are assumed to be FHIR Consent resources. The management and administration of other types of policies (e.g., jurisdictional and organizational policies) are NOT in the scope of this IG. In particular, jurisdictional privacy rules and regulations — such as laws governing what data may be shared without patient consent — are considered part of the overarching policy environment and are handled outside this IG. This guide is explicitly scoped to patient consent: each Consent resource must be linked to a specific patient (Consent.patient is required), and use cases involving aggregate, population-level, or purely jurisdictional data sharing without patient involvement are out of scope.

  • Authorization is the process of permitting or denying access to a user based on policies. This IG standardizes the representation and communication of patient consent so that authorization enforcement components — which are themselves out of scope — can use that consent information to make access control decisions. In other words, this IG ensures that consent data is expressed in a consistent, machine-readable form and can be reliably exchanged between systems; the act of applying that consent to permit or deny a specific data request is handled by authorization infrastructure outside this guide. Authorization is often divided into two areas: policy decision, where it is determined whether the user should be granted access (including the scope of access and any conditions), and policy enforcement, where the policy decision is applied. Both are generally out of scope for this IG. However, the consent disclosure audit use case relies on collecting audit events generated at the point of policy decision, so policy decision shares an interface with the consent administration service defined here.

  • Authentication is the process of verifying a user's identity and is an essential step in making authorization decisions. Authentication methods, protocols, and all of the related topics constitute an extensive area and are NOT in scope for this IG. However, authentication is a required precondition for implementing the operations defined here — systems cannot securely exchange consent resources without an underlying authentication layer establishing the identity of the communicating parties. Implementers should ensure that appropriate authentication mechanisms are in place before deploying this IG's operations in a production environment. OAuth-based authentication considerations, including compatibility with SMART App Launch, are discussed in the Underlying Specifications.

Scope of the Implementation Guide
Scope of the Implementation Guide

Content and Organization

This implementation guide (and the menu for it) is organized into the following sections:

  • Background - Supporting informative pages that do not set conformance expectations
    • Underlying Specifications describes the specifications this guide builds on — FHIR R4, US Core, Subscriptions R5 Backport, IHE-PCF, and IHE-BALP — and what portions must be understood before reading the normative content
    • Use Cases - each use case page describes an intended use case, gives examples of its use, and provides a high-level overview of expected process flow
    • Implementation Notes - supplementary notes to support the understanding and implementation of this Implementation Guide and the use cases in its scope
    • Project and Participants gives a high-level overview of FAST and identifies the individuals and organizations involved in developing this implementation guide
  • Specification - Pages that set conformance expectations
    • Conformance Expectations defines base language and expectations for declaring conformance with the guide
    • Technical Specification defines the specific conformance requirements for systems wishing to conform to this implementation guide.
    • Information Sharing defines the conformance requirements for sharing consent information between consent management systems.
    • Privacy, Safety, and Security covers considerations around data access, protection, and similar concepts that apply to all implementations
  • FHIR Artifacts
    • Artifacts Overview introduces and provides links to all profiles, extensions, search parameters, operations, and examples defined in this implementation guide
  • Base Specifications - Quick links to the various specifications this guide derives from
  • Support - Links to help with use of this guide
    • Discussion Forum is a place to ask questions about the guide, discuss potential issues, and search through prior discussions
    • Project Home includes information about project calls, agendas, past minutes, and instructions for how to participate
    • Project Dashboard shows new and historical issues that have been logged against the specification, proposed dispositions, unapplied changes, etc.
    • Propose a Change allows formal submission of requests for change to the specification. (Consider raising on the discussion forum first.)
    • Downloads allows download of this and other specifications, as well as other useful files

Dependencies

At present, FAST Consent is based on FHIR R4. In addition, Consent is dependent on the US Core 6.1 (FHIR R4) implementation guides.

In addition, this guide uses content from the following FHIR-related specifications and implementation guides:

In addition, this guide also relies on a number of parent implementation guides:

Implementation GuideVersion(s)Reason
Basic Audit Log Patterns (BALP)1.1.4
Bulk Data Access IG2.0.0Imported by US Core (and potentially others)
Extensions for Using Data Elements from FHIR R5 in FHIR R40.1.0
FHIR Extensions Pack5.3.0

Automatically added as a dependency - all IGs depend on the HL7 Extension Pack

5.2.0Imported by HL7 Terminology (THO) (and potentially others)
1.0.0Imported by US Core (and potentially others)
FHIR R4 package : Core4.0.1Imported by HL7 Terminology (THO) (and potentially others)
HL7 Terminology (THO)7.1.0

Automatically added as a dependency - all IGs depend on HL7 Terminology

6.5.0Imported by Basic Audit Log Patterns (BALP) (and potentially others)
5.3.0Imported by Privacy Consent on FHIR (PCF) (and potentially others)
5.0.0Imported by US Core (and potentially others)
IHE FormatCode Vocabulary1.1.0Imported by US Core (and potentially others)
Privacy Consent on FHIR (PCF)1.1.0
Public Health Information Network Vocabulary Access and Distribution System (PHIN VADS)0.12.0Imported by US Core (and potentially others)
SMART App Launch2.1.0Imported by US Core (and potentially others)
Structured Data Capture3.0.0Imported by US Core (and potentially others)
Subscriptions R5 Backport1.1.0
US Core6.1.0
Value Set Authority Center (VSAC)0.9.0Imported by Privacy Consent on FHIR (PCF) (and potentially others)
0.11.0Imported by US Core (and potentially others)

This implementation guide defines additional constraints and usage expectations above and beyond the information found in these base specifications.

Intellectual Property Considerations

This implementation guide and the underlying FHIR specification are licensed as public domain under the FHIR license. The license page also describes rules for the use of the FHIR name and logo.

This publication includes IP covered under the following statements.