SC-8?^client:this guide requires that an external identifier for those participants SHALL be populated.

SC-8?^client:this guide requires that an external identifier for those participants SHALL be populated.

A 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.

The event SHALL be created regardless of whether the authorization decision was a permit or a deny.

an external identifier for those participants SHALL be populated.

For 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

A 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.

a 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.

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.

Consent Server systems SHALL be capable of processing resource instances containing data elements without generating an error or causing the application to fail.

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.

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.

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.

When the Consent record is created on System A, System A's system identifier SHALL be recorded in the manager extension of the Consent instance.

Systems that ingest a Consent from another system SHALL preserve the manager extension value unchanged.

When sharing a Consent resource with another system, the originating or forwarding system SHALL NOT modify the manager extension value.

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

To satisfy the business use cases for consent management, two operations are defined that a consent administration service SHALL support: File Consent and Revoke Consent.

Along with these operations, Consent administration service systems SHALL support searching for consents

Finally, a consent administration service SHALL support subscriptions to allow other systems to be informed when consents for a patient have changed.

When filing a consent, the Consent status element SHALL be set to 'active'.

After a consent has been revoked, the Consent status element for the revoked consent SHALL be set to 'inactive'.

A revoked consent SHALL NOT be deleted from the consent management system.

To support searching for consents, the following search parameters SHALL be supported - patient, controller, manager, date, status, and scope.

Along 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.

To 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

Consent Server systems MAY return an OperationOutcome with a success when they wish to provide additional structured information alongside a successful operation response.

Consent Server systems SHOULD return an OperationOutcome with the details if an HTTP status code of 4xx or 5xx is returned.

Systems 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.

To 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.

To 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).

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.

For disclosure events, implementers SHOULD follow the IHE Basic Audit Log Patterns (BALP) guide, specifically the patterns for data disclosure audit events.

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.

The following search parameters and search parameter combinations SHALL be supported:

SHALL support both read Consent by id AND Consent search using the _id search parameter:

SHALL support searching a consent by an identifier such as a CDA consent document using the identifier search parameter:

SHALL support searching a consent by a patient using the patient search parameter:

SHALL support searching using the combination of the patient and status search parameters:

The following search parameter combinations SHOULD be supported:

SHOULD support searching using the combination of the patient and date search parameters:

Systems 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.

systems 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.