Consent Client SHALL query the consent administration service for the identifiers of the involved patients, practitioners, organizations, and related persons<br/><br/>Not testable yet - need lots more details about the lifecycle of relates resource instances. Query or match? Implies CAS is an MPI and similar for other resources? Doesn’t say what triggers these queries to occur, or what effect it has on workflows, or whether discovered identifiers are used in resources...

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<br/><br/>Because it's a SHOULD, assumes other ways; for now this is the only way we'll test.

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)<br/><br/>Because it's a SHOULD, assumes other ways; for now this is the only way we'll test.

This guide mandates that Subscriptions be used<br/><br/>Need conformance words - who does this apply to? Assuming clients, but which ones? What triggering actions? Are clients required to support only, or that they positively subscribe to specific other systems? Suggest referencing section with normative workflows.

Consent Client MAY subscribe to Consent topics as defined by the FAST Subscription Topic<br/><br/>- No conformance words "client will...", so not clear which actors SHALL or MAY support. For now, treating as MAY for both clients and servers - tests can be conditional.

• Nature of topic is it allows combinations of criteria. I'll call out each criterion below for traceability.
• TBD whether there need to be requirements for CAS to detect and fire Consent events or if implied by subs framework.

Systems conforming to this guide SHOULD NOT update an existing Consent resource in place using RESTful PUT or PATCH<br/><br/>Capturing because conformance verb, but can't test a negative.

Consent Client SHALL support AuditEvent search by Consent (entity)

Consent Client SHALL support AuditEvent search by patient<br/><br/>Implied - need requirement

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