Scalable Consent Management
1.0.0-preview - STU 1 PReview 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 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

Conformance Expectations

Page standards status: Trial-use

Systems

The FAST Consent implementation guide defines the responsibilities of two types of systems involved in a consent solution. These are the canonical Consent Client System and Consent Server System actors defined in this guide.

Consent Client systems are systems responsible for gathering patient consent decisions and filing them with a consent administration service. They are typically Electronic Medical Record (EHR) systems or patient portals, but can be any system that invokes the File Consent and Revoke Consent operations on behalf of a patient or authorized representative.

Consent Server systems are consent administration services that store consent records, service search requests, manage subscriptions, and persist audit events for consent access decisions.

Conformance Verbs

The conformance verbs — SHALL, SHOULD, MAY — used in this guide are defined in FHIR Conformance Rules.

MustSupport

Profiles in this implementation guide make use of the mustSupport element. Base expectations for mustSupport are set in the FHIR core specification. Also see the mustSupport rules for US Core, which apply to content adhering to data elements profiled in those guides.

The following rule defines the meaning of mustSupport in this guide:

  • Consent Client systems SHALL be capable of populating a mustSupport element when sharing resources compliant with the profile. I.e., the system must be able to demonstrate the population and sharing of the element, but it is acceptable to omit the element if the system doesn’t have values in a particular instance. A system that is incapable of ever sharing the element would be non-conformant.§MS-1

General Conformance Rules

The following rules apply to all elements in profiles defined in this guide, not only mustSupport elements:

  • Consent Server systems SHALL be capable of processing resource instances containing data elements without generating an error or causing the application to fail.§MS-2
  • If the minimum cardinality of an element is greater than 0 — i.e., the element is required — then the element SHALL be present in the instance and SHALL have a value.§MS-3
  • Consent Server systems SHALL interpret missing data elements within resource instances as data not being present in the sending system or not being shareable for privacy or other business reasons.§MS-4
  • Consent Server systems SHALL be able to process resource instances containing data elements that have extensions in place of a value where such extensions are declared as part of the profile.§MS-5

Conformance Statements in this Guide

IdExpectationActorsRule
 SHALL
 SHOULD
 SHALL NOT
 MAY
 SHOULD NOT		 Client
 Consent Server
§1SHALLSC-8?^client:this guide requires that an external identifier for those participants SHALL be populated.
§2SHALL SC-8?^client:this guide requires that an external identifier for those participants SHALL be populated.§1
§AE1SHALLConsent ServerA FAST Consent Audit Event SHALL be created by the system that evaluates a Consent resource to determine whether a request to access patient information should be permitted or denied.
§AE2SHALLConsent ServerThe event SHALL be created regardless of whether the authorization decision was a permit or a deny.
§AE3SHALLConsent Serveran external identifier for those participants SHALL be populated.
§ID1SHALLClientFor that reason, this guide mandates that Consent Client systems SHALL query the consent administration service for the identifiers of the involved patients, practitioners, organizations, and related persons
§IN1SHOULDConsent ServerA consent administration service receiving a POST Subscription request SHOULD verify that the subscribing system is authorized to access the consents it is requesting to be notified about.
§IN2SHOULDClienta system that cannot maintain a subscription to the consent management source SHOULD fetch a fresh copy of the consent at the time of each authorization decision rather than rely on a cached copy.
§MS-1SHALLClientConsent Client systems SHALL be capable of populating a mustSupport element when sharing resources compliant with the profile. I.e., the system must be able to demonstrate the population and sharing of the element, but it is acceptable to omit the element if the system doesn’t have values in a particular instance. A system that is incapable of ever sharing the element would be non-conformant.
§MS-2SHALLConsent ServerConsent Server systems SHALL be capable of processing resource instances containing data elements without generating an error or causing the application to fail.
§MS-3SHALLClient
Consent Server		If the minimum cardinality of an element is greater than 0 — i.e., the element is required — then the element SHALL be present in the instance and SHALL have a value.
§MS-4SHALLConsent ServerConsent Server systems SHALL interpret missing data elements within resource instances as data not being present in the sending system or not being shareable for privacy or other business reasons.
§MS-5SHALLConsent ServerConsent Server systems SHALL be able to process resource instances containing data elements that have extensions in place of a value where such extensions are declared as part of the profile.
§NR1SHALLConsent ServerWhen the Consent record is created on System A, System A's system identifier SHALL be recorded in the manager extension of the Consent instance.
§NR2SHALLClient
Consent Server		Systems that ingest a Consent from another system SHALL preserve the manager extension value unchanged.
§NR3SHALL NOTClient
Consent Server		When sharing a Consent resource with another system, the originating or forwarding system SHALL NOT modify the manager extension value.
§NR4SHOULDClient
Consent Server		A system that receives a shared Consent resource SHOULD establish a FHIR Subscription with the system identified in the manager extension to receive updates to that Consent (e.g., revocations).
§OP1SHALLConsent ServerTo satisfy the business use cases for consent management, two operations are defined that a consent administration service SHALL support: File Consent and Revoke Consent.
§OP2SHALLConsent ServerAlong with these operations, Consent administration service systems SHALL support searching for consents
§OP3SHALLConsent ServerFinally, a consent administration service SHALL support subscriptions to allow other systems to be informed when consents for a patient have changed.
§OP4SHALLClientWhen filing a consent, the Consent status element SHALL be set to 'active'.
§OP5SHALLConsent ServerAfter a consent has been revoked, the Consent status element for the revoked consent SHALL be set to 'inactive'.
§OP6SHALL NOTConsent ServerA revoked consent SHALL NOT be deleted from the consent management system.
§OP7SHALLConsent ServerTo support searching for consents, the following search parameters SHALL be supported - patient, controller, manager, date, status, and scope.
§OP8SHALLConsent ServerAlong with the business use cases of consent management, consent administration services SHALL be able to record and retrieve disclosures of when a consent was accessed to determine whether patient information could be accessed.
§OP9SHALLConsent ServerTo allow systems to document and retrieve consent authorization decision events — including for disclosure to patients and requesting authorities — systems SHALL support searching for FAST Consent Audit Events
§OP10MAYConsent ServerConsent Server systems MAY return an OperationOutcome with a success when they wish to provide additional structured information alongside a successful operation response.
§OP11SHOULDConsent ServerConsent Server systems SHOULD return an OperationOutcome with the details if an HTTP status code of 4xx or 5xx is returned.
§OP12SHALLConsent ServerSystems SHALL create a FAST Consent Audit Event via a RESTful FHIR POST AuditEvent whenever a Consent instance is accessed to determine whether patient information can be accessed.
§OP13SHOULDClientTo search for consents by organization identifier, implementers SHOULD use the controller:identifier chained search parameter (e.g., GET [base]/Consent?controller:identifier=|1234567890) rather than a custom organization ID search parameter.
§OP14SHOULDClientTo search for consents by patient identifier, implementers SHOULD use the patient:identifier chained search parameter (e.g., GET [base]/Consent?patient:identifier=http://example.org/mrn|M1230041).
§OP15SHOULD NOTClient
Consent Server		This guide does not define an Update Consent operation, and systems conforming to this guide SHOULD NOT update an existing Consent resource in place using RESTful PUT or PATCH.
§OP16SHOULDConsent ServerFor disclosure events, implementers SHOULD follow the IHE Basic Audit Log Patterns (BALP) guide, specifically the patterns for data disclosure audit events.
§OP17SHOULDClient
Consent Server		For disclosure events (cases where health information was actually shared following a permit decision), implementers SHOULD follow IHE-BALP patterns and the ITI-81 Retrieve ATNA Audit Event transaction for querying those events.
§SC-1SHALLConsent ServerThe following search parameters and search parameter combinations SHALL be supported:
§SC-2SHALLConsent ServerSHALL support both read Consent by id AND Consent search using the _id search parameter:
§SC-3SHALLConsent ServerSHALL support searching a consent by an identifier such as a CDA consent document using the identifier search parameter:
§SC-4SHALLConsent ServerSHALL support searching a consent by a patient using the patient search parameter:
§SC-5SHALLConsent ServerSHALL support searching using the combination of the patient and status search parameters:
§SC-6SHOULDConsent ServerThe following search parameter combinations SHOULD be supported:
§SC-7SHOULDConsent ServerSHOULD support searching using the combination of the patient and date search parameters:
§SH1SHOULDConsent ServerSystems that return a Consent resource in a search result or read interaction SHOULD record a standard FHIR AuditEvent following the IHE Basic Audit Log Patterns (BALP) patterns for FHIR Search and Read events.
§SH2SHALLConsent Serversystems SHALL record a FAST Consent Audit Event via a RESTful FHIR POST to the AuditEvent endpoint whenever a Consent record was consulted, no matter whether that led to health information sharing or not.