Generated Narrative: Requirements fromNarrative These requirements apply to the following actors: Consent Server System Consent Client System 1 SHALL SC-8?^client:this guide requires that an external identifier for those participants SHALL be populated. 2 SHALL SC-8?^client:this guide requires that an external identifier for those participants SHALL be populated. AE1 SHALL 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. AE2 SHALL The event SHALL be created regardless of whether the authorization decision was a permit or a deny. AE3 SHALL an external identifier for those participants SHALL be populated. ID1 SHALL 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 IN1 SHOULD 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. IN2 SHOULD 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. MS-1 SHALL 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-2 SHALL Consent Server systems SHALL be capable of processing resource instances containing data elements without generating an error or causing the application to fail. MS-3 SHALL 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-4 SHALL 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-5 SHALL 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. NR1 SHALL 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. NR2 SHALL Systems that ingest a Consent from another system SHALL preserve the manager extension value unchanged. NR3 SHALL NOT When sharing a Consent resource with another system, the originating or forwarding system SHALL NOT modify the manager extension value. NR4 SHOULD 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). OP1 SHALL 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. OP2 SHALL Along with these operations, Consent administration service systems SHALL support searching for consents OP3 SHALL Finally, a consent administration service SHALL support subscriptions to allow other systems to be informed when consents for a patient have changed. OP4 SHALL When filing a consent, the Consent status element SHALL be set to 'active'. OP5 SHALL After a consent has been revoked, the Consent status element for the revoked consent SHALL be set to 'inactive'. OP6 SHALL NOT A revoked consent SHALL NOT be deleted from the consent management system. OP7 SHALL To support searching for consents, the following search parameters SHALL be supported - patient, controller, manager, date, status, and scope. OP8 SHALL 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. OP9 SHALL 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 OP10 MAY Consent Server systems MAY return an OperationOutcome with a success when they wish to provide additional structured information alongside a successful operation response. OP11 SHOULD Consent Server systems SHOULD return an OperationOutcome with the details if an HTTP status code of 4xx or 5xx is returned. OP12 SHALL 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. OP13 SHOULD 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. OP14 SHOULD 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). OP15 SHOULD-NOT 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. OP16 SHOULD For disclosure events, implementers SHOULD follow the IHE Basic Audit Log Patterns (BALP) guide, specifically the patterns for data disclosure audit events. OP17 SHOULD 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-1 SHALL The following search parameters and search parameter combinations SHALL be supported: SC-2 SHALL SHALL support both read Consent by id AND Consent search using the _id search parameter: SC-3 SHALL SHALL support searching a consent by an identifier such as a CDA consent document using the identifier search parameter: SC-4 SHALL SHALL support searching a consent by a patient using the patient search parameter: SC-5 SHALL SHALL support searching using the combination of the patient and status search parameters: SC-6 SHOULD The following search parameter combinations SHOULD be supported: SC-7 SHOULD SHOULD support searching using the combination of the patient and date search parameters: SH1 SHOULD 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. SH2 SHALL 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.
HL7 International / Community Based Collaborative Care
Conformance statements found throughout the narrative of the IG consolidated into this computable resource for traceability purposes
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)](https://profiles.ihe.net/ITI/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](https://profiles.ihe.net/ITI/TF/Volume2/ITI-81.html) 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`](http://hl7.org/fhir/R4/search.html#id)** search parameter:
**SHALL** support searching a consent by an identifier such as a CDA consent document using the **[`identifier`](http://hl7.org/fhir/R4/search.html#token)** search parameter:
**SHALL** support searching a consent by a patient using the **[`patient`](http://hl7.org/fhir/R4/search.html#reference)** search parameter:
**SHALL** support searching using the combination of the **[`patient`](http://hl7.org/fhir/R4/search.html#reference)** and **[`status`](http://hl7.org/fhir/R4/search.html#token)** search parameters:
The following search parameter combinations **SHOULD** be supported:
**SHOULD** support searching using the combination of the **[`patient`](http://hl7.org/fhir/R4/search.html#reference)** and **[`date`](http://hl7.org/fhir/R4/search.html#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)](https://profiles.ihe.net/ITI/BALP/) patterns for FHIR Search and Read events.
systems **SHALL** record a [FAST Consent Audit Event](StructureDefinition-FASTConsentAuditEvent.html) 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.