Scalable Consent Management
0.1.0 - ci-build United States of America flag

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 0.1.0 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

Overview

Official URL: http://hl7.org/fhir/us/consent-management/ImplementationGuide/hl7.fhir.us.consent-management Version: 0.1.0
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 mangement repository as well as between repositories. 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 consent ceremony, as well as a high-level API (e.g., defining custom FHIR operations) to cover use cases for consent management.

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 consent ceremony, as well as a high-level API (e.g., defining custom FHIR operations) to cover use cases for consent management.

Use Cases

Patient Consent management is the central component in a consent ecosystem and at the core of a scalable consent architecture. This project is about answering the question "is it possible to determine if payer/provider X have authority to view healthcare data Y about patient Z?". This FAST project will be dealing with how to handle the use cases across a set of consent management repositories in a scaleable fashion.

Our initial set of potential use cases are:

  1. Provider-Initiated Request to Consent
  2. Patient-Initiated Consent
  3. Review Consent
  4. File/Sign Consent
  5. Delegate Consent
  6. Revoke Consent
  7. Propagation of Revocation
  8. Disclosure Audit
  9. Query Consent Decision
  10. Enforce Consent Decision

NOTE: The actual authentication (is the consumer who they say they are) and data authorization (does the consumer have access to patient health data) is not in scope of this IG. We will provide the operations to gather and request consent and answer the question on whether a consumer has been granted consent to a patient's specific set healthcare data. The question of whether the consumer can actually access a patient's health data based on legal, corporate, and other policies and the granted consent is not in scope.

Scope of the Implementation Guide
Scope of the Implementation Guide

Definitions

Consent: The FHIR Consent resource defines consent as "A record of a healthcare consumer’s choices or choices made on their behalf by a third party, which permits or denies identified recipient(s) or recipient role(s) to perform one or more actions within a given policy context, for specific purposes and periods of time." For the purposes of this Implementation Guide, we further constrain the definition to only include policies / actions pertaining to granting access to data associated with a patient. In this context it does not include patient wishes, such as consent for treatment or Do Not Resuscitate orders.

Authorization: The process of granting access to data. The broader question of authorization is NOT in scope for this project, except that portion which overlaps with "Query Consent Decision" and "Enforce Consent Decision" above.

Authentication: The process of assuring a user's identity. This is NOT in scope for this project.

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
    • Reading this IG points to key pages in the FHIR spec and other source specifications that must be understood in order to understand this guide
    • *Use Case Pages - each use case page describes the intent use case, gives examples of its use, and provides a high-level overview of expected process flow
    • 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
  • FHIR Artifacts
    • ​Overview introduces and provides links to the profiles, search parameters and other FHIR artifacts used in this implementation guide
    • Artifacts points to the complete list of artifacts defined in this 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 Dashoard 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, PAS 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
Bulk Data Access IG2.0.0Imported by US Core (and potentially others)
FHIR Extensions Pack5.2.0

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

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)6.2.0

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

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.