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

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		 Consent Client System
 Consent Server System
§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 Server SystemA 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 Server SystemThe event SHALL be created regardless of whether the authorization decision was a permit or a deny.
§AE3SHALLConsent Server Systeman external identifier for those participants SHALL be populated.
§ID1SHALLConsent Client SystemFor 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 Server SystemA 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.
§IN2SHOULDConsent Client Systema 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-1SHALLConsent Client SystemConsent 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 Server SystemConsent Server systems SHALL be capable of processing resource instances containing data elements without generating an error or causing the application to fail.
§MS-3SHALLConsent Client System
Consent Server System		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 Server SystemConsent 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 Server SystemConsent 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 Server SystemWhen the Consent record is created on System A, System A's system identifier SHALL be recorded in the manager extension of the Consent instance.
§NR2SHALLConsent Client System
Consent Server System		Systems that ingest a Consent from another system SHALL preserve the manager extension value unchanged.
§NR3SHALL NOTConsent Client System
Consent Server System		When sharing a Consent resource with another system, the originating or forwarding system SHALL NOT modify the manager extension value.
§NR4SHOULDConsent Client System
Consent Server System		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 Server SystemTo 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 Server SystemAlong with these operations, Consent administration service systems SHALL support searching for consents
§OP3SHALLConsent Server SystemFinally, a consent administration service SHALL support subscriptions to allow other systems to be informed when consents for a patient have changed.
§OP4SHALLConsent Client SystemWhen filing a consent, the Consent status element SHALL be set to 'active'.
§OP5SHALLConsent Server SystemAfter a consent has been revoked, the Consent status element for the revoked consent SHALL be set to 'inactive'.
§OP6SHALL NOTConsent Server SystemA revoked consent SHALL NOT be deleted from the consent management system.
§OP7SHALLConsent Server SystemTo support searching for consents, the following search parameters SHALL be supported - patient, controller, manager, date, status, and scope.
§OP8SHALLConsent Server SystemAlong 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 Server SystemTo 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 Server SystemConsent Server systems MAY return an OperationOutcome with a success when they wish to provide additional structured information alongside a successful operation response.
§OP11SHOULDConsent Server SystemConsent Server systems SHOULD return an OperationOutcome with the details if an HTTP status code of 4xx or 5xx is returned.
§OP12SHALLConsent Server SystemSystems 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.
§OP13SHOULDConsent Client SystemTo 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.
§OP14SHOULDConsent Client SystemTo 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 NOTConsent Client System
Consent Server System		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 Server SystemFor disclosure events, implementers SHOULD follow the IHE Basic Audit Log Patterns (BALP) guide, specifically the patterns for data disclosure audit events.
§OP17SHOULDConsent Client System
Consent Server System		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 Server SystemThe following search parameters and search parameter combinations SHALL be supported:
§SC-2SHALLConsent Server SystemSHALL support both read Consent by id AND Consent search using the _id search parameter:
§SC-3SHALLConsent Server SystemSHALL support searching a consent by an identifier such as a CDA consent document using the identifier search parameter:
§SC-4SHALLConsent Server SystemSHALL support searching a consent by a patient using the patient search parameter:
§SC-5SHALLConsent Server SystemSHALL support searching using the combination of the patient and status search parameters:
§SC-6SHOULDConsent Server SystemThe following search parameter combinations SHOULD be supported:
§SC-7SHOULDConsent Server SystemSHOULD support searching using the combination of the patient and date search parameters:
§SH1SHOULDConsent Server SystemSystems 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 Server Systemsystems 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.