Scalable Consent Management Testing Guide
0.1.0 - ci-build

Scalable Consent Management Testing Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

## Test Cases

Page standards status: Informative

### RTM - Test Cases

This page displays the Requirements Traceability Matrix (RTM) from the perspective of the test cases. All test cases defined are included, whether or not they are traced. Each test case may be expanded to show its details as well as its traced requirements.

#### 1: Read a Consent

- Flow: Basic success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Read a Consent

Actors: Consent Client, CAS

Pre-condition: A Consent conforming to the FASTConsent profile exists at the CAS, and its ID is known.

Narrative:

1. Client sends a conformant read to CAS using the known ID. This is unconstrained, e.g. the "_format" parameter may be present.
2. Verify the request is valid according to the linked requirements.
3. [No requirements yet, but something like this: CAS verifies the request is valid.]
4. CAS returns a conformant response containing the resource.
5. Verify the response is valid according to the linked requirements, including that the Consent declares and conforms to the FASTConsent profile.

Post-condition:

- None

- Notes: Base test case. Mostly unconstrained, so it can be used in the widest variety of cases.

- Traced Requirements:
  - 69: Consent Administration Service MAY return OperationOutcome for a successful operation
  - 43: Consent Administration Service SHALL support Consent resource
  - 35: Consent Administration Service SHALL support Consent resources that conform to FASTConsent profile
  - 331: Consent Administration Service SHALL mark with profile assertions Consent resources that conform to the FASTConsent profile
  - 333: Consent Client SHALL support Consent resource
  - 52: Consent Client SHALL support Consent resources that conform to FASTConsent profile
  - 36: Consent Administration Service SHALL support Consent read
  - 56: Consent Client SHALL support Consent read

#### 2: Search for a Consent

- Flow: Basic success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for a Consent

Actors: Consent Client, CAS

Pre-condition: At least one Consent conforming to the FASTConsent profile exists at the CAS, and details about it sufficient to search are known.

Narrative:

1. Client sends a conformant search request to CAS using some combination of the search criteria required to be supported.
2. Verify the request is valid according to the linked requirements.
3. [No requirements yet, but something like this: CAS verifies the request is valid.]
4. CAS returns a conformant response containing the matching resource(s).
5. Verify the response is valid according to the linked requirements.
6. Verify that at least one Consent resource is returned, and that each returned Consent declares and conforms to the FASTConsent profile.

Post-condition:

- None

- Notes: Base test case. Mostly unconstrained, so it can be used in the widest variety of cases.

- Traced Requirements:
  - 69: Consent Administration Service MAY return OperationOutcome for a successful operation
  - 43: Consent Administration Service SHALL support Consent resource
  - 35: Consent Administration Service SHALL support Consent resources that conform to FASTConsent profile
  - 331: Consent Administration Service SHALL mark with profile assertions Consent resources that conform to the FASTConsent profile
  - 333: Consent Client SHALL support Consent resource
  - 52: Consent Client SHALL support Consent resources that conform to FASTConsent profile
  - 63: Consent Administration Service SHALL support Consent search
  - 37: Consent Administration Service SHALL support Consent search
  - 57: Consent Client SHALL support Consent search

#### 144: Search for Consent by FASTConsentController - JSON

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by FASTConsentController - JSON

This test case extends test case "Search for a Consent".

Pre-condition: FASTConsentController details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the FASTConsentController criteria and requests JSON.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as JSON.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 364: Consent Administration Service SHALL support Consent search by FASTConsentController
  - 199: Consent Administration Service SHALL support Consent search by FASTConsentController
  - 58: Consent Client SHALL support Consent search by FASTConsentController
  - 472: SearchParameter FASTConsentController

#### 145: Search for Consent by FASTConsentController - XML

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by FASTConsentController - XML

This test case extends test case "Search for a Consent".

Pre-condition: FASTConsentController details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the FASTConsentController criteria and requests XML.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as XML.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 364: Consent Administration Service SHALL support Consent search by FASTConsentController
  - 199: Consent Administration Service SHALL support Consent search by FASTConsentController
  - 58: Consent Client SHALL support Consent search by FASTConsentController
  - 472: SearchParameter FASTConsentController

#### 146: Search for Consent by date - JSON

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by date - JSON

This test case extends test case "Search for a Consent".

Pre-condition: date details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the date criteria and requests JSON.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as JSON.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 365: Consent Administration Service SHALL support Consent search by date
  - 72: Consent Administration Service SHALL support Consent search by date
  - 369: Consent Client SHALL support Consent search by date

#### 147: Search for Consent by date - XML

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by date - XML

This test case extends test case "Search for a Consent".

Pre-condition: date details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the date criteria and requests XML.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as XML.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 365: Consent Administration Service SHALL support Consent search by date
  - 72: Consent Administration Service SHALL support Consent search by date
  - 369: Consent Client SHALL support Consent search by date

#### 148: Search for Consent by FASTConsentGrantee - JSON

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by FASTConsentGrantee - JSON

This test case extends test case "Search for a Consent".

Pre-condition: FASTConsentGrantee details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the FASTConsentGrantee criteria and requests JSON.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as JSON.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 38: Consent Administration Service SHALL support Consent search by FASTConsentGrantee
  - 370: Consent Client SHALL support Consent search by FASTConsentGrantee
  - 473: SearchParameter FASTConsentGrantee

#### 149: Search for Consent by FASTConsentGrantee - XML

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by FASTConsentGrantee - XML

This test case extends test case "Search for a Consent".

Pre-condition: FASTConsentGrantee details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the FASTConsentGrantee criteria and requests XML.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as XML.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 38: Consent Administration Service SHALL support Consent search by FASTConsentGrantee
  - 370: Consent Client SHALL support Consent search by FASTConsentGrantee
  - 473: SearchParameter FASTConsentGrantee

#### 150: Search for Consent by FASTConsentManager - JSON

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by FASTConsentManager - JSON

This test case extends test case "Search for a Consent".

Pre-condition: FASTConsentManager details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the FASTConsentManager criteria and requests JSON.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as JSON.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 367: Consent Administration Service SHALL support Consent search by FASTConsentManager
  - 200: Consent Administration Service SHALL support Consent search by FASTConsentManager
  - 371: Consent Client SHALL support Consent search by FASTConsentManager
  - 474: SearchParameter FASTConsentManager

#### 151: Search for Consent by FASTConsentManager - XML

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by FASTConsentManager - XML

This test case extends test case "Search for a Consent".

Pre-condition: FASTConsentManager details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the FASTConsentManager criteria and requests XML.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as XML.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 367: Consent Administration Service SHALL support Consent search by FASTConsentManager
  - 200: Consent Administration Service SHALL support Consent search by FASTConsentManager
  - 371: Consent Client SHALL support Consent search by FASTConsentManager
  - 474: SearchParameter FASTConsentManager

#### 152: Search for Consent by FASTConsentOrganizationId - JSON

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by FASTConsentOrganizationId - JSON

This test case extends test case "Search for a Consent".

Pre-condition: FASTConsentOrganizationId details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the FASTConsentOrganizationId criteria and requests JSON.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as JSON.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 39: Consent Administration Service SHALL support Consent search by FASTConsentOrganizationId
  - 59: Consent Client SHALL support Consent search by FASTConsentOrganizationId
  - 475: SearchParameter FASTConsentOrganizationId

#### 153: Search for Consent by FASTConsentOrganizationId - XML

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by FASTConsentOrganizationId - XML

This test case extends test case "Search for a Consent".

Pre-condition: FASTConsentOrganizationId details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the FASTConsentOrganizationId criteria and requests XML.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as XML.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 39: Consent Administration Service SHALL support Consent search by FASTConsentOrganizationId
  - 59: Consent Client SHALL support Consent search by FASTConsentOrganizationId
  - 475: SearchParameter FASTConsentOrganizationId

#### 154: Search for Consent by patient - JSON

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by patient - JSON

This test case extends test case "Search for a Consent".

Pre-condition: patient details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the patient criteria and requests JSON.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as JSON.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 71: Consent Administration Service SHALL support Consent search by patient
  - 40: Consent Administration Service SHALL support Consent search by patient
  - 60: Consent Client SHALL support Consent search by patient

#### 155: Search for Consent by patient - XML

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by patient - XML

This test case extends test case "Search for a Consent".

Pre-condition: patient details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the patient criteria and requests XML.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as XML.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 71: Consent Administration Service SHALL support Consent search by patient
  - 40: Consent Administration Service SHALL support Consent search by patient
  - 60: Consent Client SHALL support Consent search by patient

#### 156: Search for Consent by FASTConsentPatientId - JSON

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by FASTConsentPatientId - JSON

This test case extends test case "Search for a Consent".

Pre-condition: FASTConsentPatientId details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the FASTConsentPatientId criteria and requests JSON.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as JSON.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 368: Consent Administration Service SHALL support Consent search by FASTConsentPatientId
  - 372: Consent Client SHALL support Consent search by FASTConsentPatientId
  - 476: SearchParameter FASTConsentPatientId

#### 157: Search for Consent by FASTConsentPatientId - XML

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by FASTConsentPatientId - XML

This test case extends test case "Search for a Consent".

Pre-condition: FASTConsentPatientId details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the FASTConsentPatientId criteria and requests XML.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as XML.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 368: Consent Administration Service SHALL support Consent search by FASTConsentPatientId
  - 372: Consent Client SHALL support Consent search by FASTConsentPatientId
  - 476: SearchParameter FASTConsentPatientId

#### 158: Search for Consent by scope - JSON

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by scope - JSON

This test case extends test case "Search for a Consent".

Pre-condition: scope details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the scope criteria and requests JSON.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as JSON.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 201: Consent Administration Service SHALL support Consent search by scope
  - 42: Consent Administration Service SHALL support Consent search by scope
  - 47: Consent Client SHALL support Consent search by scope

#### 159: Search for Consent by scope - XML

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by scope - XML

This test case extends test case "Search for a Consent".

Pre-condition: scope details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the scope criteria and requests XML.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as XML.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 201: Consent Administration Service SHALL support Consent search by scope
  - 42: Consent Administration Service SHALL support Consent search by scope
  - 47: Consent Client SHALL support Consent search by scope

#### 160: Search for Consent by status - JSON

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by status - JSON

This test case extends test case "Search for a Consent".

Pre-condition: status details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the status criteria and requests JSON.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as JSON.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 73: Consent Administration Service SHALL support Consent search by status
  - 41: Consent Administration Service SHALL support Consent search by status
  - 61: Consent Client SHALL support Consent search by status

#### 161: Search for Consent by status - XML

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for Consent by status - XML

This test case extends test case "Search for a Consent".

Pre-condition: status details are known by which at least one Consent would match and at least one Consent would not match at the CAS.

- In step 1, the client includes the status criteria and requests XML.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as XML.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 73: Consent Administration Service SHALL support Consent search by status
  - 41: Consent Administration Service SHALL support Consent search by status
  - 61: Consent Client SHALL support Consent search by status

#### 166: Search for Consent by FASTConsent profile - JSON

- Flow: Alternate success
- Systems Under Test:
  - Client: Conditional - Client can search by _profile
  - Server: Required
- Test Details:

Search for Consent by FASTConsent profile - JSON

This test case extends test case "Search for a Consent".

Pre-condition: At least one Consent declaring the FASTConsent profile and at least one Consent not declaring it exist at the CAS.

- In step 1, the client includes the FASTConsent profile criteria and requests JSON.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as JSON.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 331: Consent Administration Service SHALL mark with profile assertions Consent resources that conform to the FASTConsent profile
  - 332: Consent Administration Service SHALL support searching by the _profile parameter for Consent resources that conform to the FASTConsent profile

#### 167: Search for Consent by FASTConsent profile - XML

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Conditional - Client can search by _profile
- Test Details:

Search for Consent by FASTConsent profile - XML

This test case extends test case "Search for a Consent".

Pre-condition: At least one Consent declaring the FASTConsent profile and at least one Consent not declaring it exist at the CAS.

- In step 1, the client includes the FASTConsent profile criteria and requests XML.
- In step 6, verify that only matching Consent resources are returned.
- In all steps, evaluate FHIR content as XML.

- Parent: 2: Search for a Consent
- Traced Requirements:
  - 331: Consent Administration Service SHALL mark with profile assertions Consent resources that conform to the FASTConsent profile
  - 332: Consent Administration Service SHALL support searching by the _profile parameter for Consent resources that conform to the FASTConsent profile

#### 141: Read an AuditEvent

- Flow: Basic success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Read an AuditEvent

Actors: Consent Client, CAS

Pre-condition: An AuditEvent conforming to the FASTConsentAuditEvent profile exists at the CAS, and its ID is known.

Narrative:

1. Client sends a conformant read to CAS using the known ID. This is unconstrained, e.g. the "_format" parameter may be present.
2. Verify the request is valid according to the linked requirements.
3. [No requirements yet, but something like this: CAS verifies the request is valid.]
4. CAS returns a conformant response containing the resource.
5. Verify the response is valid according to the linked requirements, including that the AuditEvent declares and conforms to the FASTConsentAuditEvent profile.

Post-condition:

- None

- Notes: Base test case. Mostly unconstrained, so it can be used in the widest variety of cases.

- Traced Requirements:
  - 69: Consent Administration Service MAY return OperationOutcome for a successful operation
  - 661: Consent Administration Service SHALL support Subscription resource
  - 397: Consent Administration Service SHALL support AuditEvent resource
  - 398: Consent Administration Service SHALL support AuditEvent resources that conform to FASTConsentAuditEvent profile
  - 399: Consent Administration Service SHALL mark with profile assertions AuditEvent resources that conform to the FASTConsentAuditEvent profile
  - 401: Consent Client SHALL support AuditEvent resource
  - 402: Consent Client SHALL support AuditEvent resources that conform to FASTConsentAuditEvent profile
  - 404: Consent Administration Service SHALL support AuditEvent read
  - 405: Consent Client SHALL support AuditEvent read
  - 513: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile
  - 514: Consent Administration Service SHALL mark with profile assertions Subscription resources that conform to the BackportSubscription profile

#### 142: Search for an AuditEvent

- Flow: Basic success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for an AuditEvent

Actors: Consent Client, CAS

Pre-condition: At least one AuditEvent conforming to the FASTConsentAuditEvent profile exists at the CAS, and details about it sufficient to search are known.

Narrative:

1. Client sends a conformant search request to CAS using some combination of the search criteria required to be supported.
2. Verify the request is valid according to the linked requirements.
3. [No requirements yet, but something like this: CAS verifies the request is valid.]
4. CAS returns a conformant response containing the matching resource(s).
5. Verify the response is valid according to the linked requirements.
6. Verify that at least one AuditEvent resource is returned, and that each returned AuditEvent declares and conforms to the FASTConsentAuditEvent profile.

Post-condition:

- None

- Notes: Base test case. Mostly unconstrained, so it can be used in the widest variety of cases.

- Traced Requirements:
  - 69: Consent Administration Service MAY return OperationOutcome for a successful operation
  - 661: Consent Administration Service SHALL support Subscription resource
  - 397: Consent Administration Service SHALL support AuditEvent resource
  - 398: Consent Administration Service SHALL support AuditEvent resources that conform to FASTConsentAuditEvent profile
  - 399: Consent Administration Service SHALL mark with profile assertions AuditEvent resources that conform to the FASTConsentAuditEvent profile
  - 401: Consent Client SHALL support AuditEvent resource
  - 402: Consent Client SHALL support AuditEvent resources that conform to FASTConsentAuditEvent profile
  - 407: Consent Administration Service SHALL support AuditEvent search
  - 406: Consent Administration Service SHALL support AuditEvent search
  - 408: Consent Client SHALL support AuditEvent search
  - 513: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile
  - 514: Consent Administration Service SHALL mark with profile assertions Subscription resources that conform to the BackportSubscription profile

#### 162: Search for AuditEvent by FASTAuditEventConsent - JSON

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for AuditEvent by FASTAuditEventConsent - JSON

This test case extends test case "Search for an AuditEvent".

Pre-condition: FASTAuditEventConsent details are known by which at least one AuditEvent would match and at least one AuditEvent would not match at the CAS.

- In step 1, the client includes the FASTAuditEventConsent criteria and requests JSON.
- In step 6, verify that only matching AuditEvent resources are returned.
- In all steps, evaluate FHIR content as JSON.

- Parent: 142: Search for an AuditEvent
- Traced Requirements:
  - 266: Consent Administration Service SHALL support AuditEvent search by FASTAuditEventConsent
  - 409: Consent Administration Service SHALL support AuditEvent search by FASTAuditEventConsent
  - 267: Consent Client SHALL support AuditEvent search by FASTAuditEventConsent
  - 411: Consent Client SHALL support AuditEvent search by FASTAuditEventConsent
  - 471: SearchParameter FASTAuditEventConsent

#### 163: Search for AuditEvent by FASTAuditEventConsent - XML

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for AuditEvent by FASTAuditEventConsent - XML

This test case extends test case "Search for an AuditEvent".

Pre-condition: FASTAuditEventConsent details are known by which at least one AuditEvent would match and at least one AuditEvent would not match at the CAS.

- In step 1, the client includes the FASTAuditEventConsent criteria and requests XML.
- In step 6, verify that only matching AuditEvent resources are returned.
- In all steps, evaluate FHIR content as XML.

- Parent: 142: Search for an AuditEvent
- Traced Requirements:
  - 266: Consent Administration Service SHALL support AuditEvent search by FASTAuditEventConsent
  - 409: Consent Administration Service SHALL support AuditEvent search by FASTAuditEventConsent
  - 267: Consent Client SHALL support AuditEvent search by FASTAuditEventConsent
  - 411: Consent Client SHALL support AuditEvent search by FASTAuditEventConsent
  - 471: SearchParameter FASTAuditEventConsent

#### 164: Search for AuditEvent by patient - JSON

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for AuditEvent by patient - JSON

This test case extends test case "Search for an AuditEvent".

Pre-condition: patient details are known by which at least one AuditEvent would match and at least one AuditEvent would not match at the CAS.

- In step 1, the client includes the patient criteria and requests JSON.
- In step 6, verify that only matching AuditEvent resources are returned.
- In all steps, evaluate FHIR content as JSON.

- Parent: 142: Search for an AuditEvent
- Traced Requirements:
  - 298: Consent Administration Service SHALL support AuditEvent search by patient
  - 412: Consent Administration Service SHALL support AuditEvent search by patient
  - 299: Consent Client SHALL support AuditEvent search by patient
  - 414: Consent Client SHALL support AuditEvent search by patient

#### 165: Search for AuditEvent by patient - XML

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Search for AuditEvent by patient - XML

This test case extends test case "Search for an AuditEvent".

Pre-condition: patient details are known by which at least one AuditEvent would match and at least one AuditEvent would not match at the CAS.

- In step 1, the client includes the patient criteria and requests XML.
- In step 6, verify that only matching AuditEvent resources are returned.
- In all steps, evaluate FHIR content as XML.

- Parent: 142: Search for an AuditEvent
- Traced Requirements:
  - 298: Consent Administration Service SHALL support AuditEvent search by patient
  - 412: Consent Administration Service SHALL support AuditEvent search by patient
  - 299: Consent Client SHALL support AuditEvent search by patient
  - 414: Consent Client SHALL support AuditEvent search by patient

#### 168: Search for AuditEvent by FASTConsentAuditEvent profile - JSON

- Flow: Alternate success
- Systems Under Test:
  - Client: Conditional - Client can search by _profile
  - Server: Required
- Test Details:

Search for AuditEvent by FASTConsentAuditEvent profile - JSON

This test case extends test case "Search for an AuditEvent".

Pre-condition: At least one AuditEvent declaring the FASTConsentAuditEvent profile and at least one AuditEvent not declaring it exist at the CAS.

- In step 1, the client includes the FASTConsentAuditEvent profile criteria and requests JSON.
- In step 6, verify that only matching AuditEvent resources are returned.
- In all steps, evaluate FHIR content as JSON.

- Parent: 142: Search for an AuditEvent
- Traced Requirements:
  - 399: Consent Administration Service SHALL mark with profile assertions AuditEvent resources that conform to the FASTConsentAuditEvent profile
  - 400: Consent Administration Service SHALL support searching by the _profile parameter for AuditEvent resources that conform to the FASTConsentAuditEvent profile
  - 514: Consent Administration Service SHALL mark with profile assertions Subscription resources that conform to the BackportSubscription profile
  - 515: Consent Administration Service SHALL support searching by the _profile parameter for Subscription resources that conform to the BackportSubscription profile

#### 169: Search for AuditEvent by FASTConsentAuditEvent profile - XML

- Flow: Alternate success
- Systems Under Test:
  - Client: Required
  - Server: Conditional - Client can search by _profile
- Test Details:

Search for AuditEvent by FASTConsentAuditEvent profile - XML

This test case extends test case "Search for an AuditEvent".

Pre-condition: At least one AuditEvent declaring the FASTConsentAuditEvent profile and at least one AuditEvent not declaring it exist at the CAS.

- In step 1, the client includes the FASTConsentAuditEvent profile criteria and requests XML.
- In step 6, verify that only matching AuditEvent resources are returned.
- In all steps, evaluate FHIR content as XML.

- Parent: 142: Search for an AuditEvent
- Traced Requirements:
  - 399: Consent Administration Service SHALL mark with profile assertions AuditEvent resources that conform to the FASTConsentAuditEvent profile
  - 400: Consent Administration Service SHALL support searching by the _profile parameter for AuditEvent resources that conform to the FASTConsentAuditEvent profile
  - 514: Consent Administration Service SHALL mark with profile assertions Subscription resources that conform to the BackportSubscription profile
  - 515: Consent Administration Service SHALL support searching by the _profile parameter for Subscription resources that conform to the BackportSubscription profile

#### 199: Read a Subscription

- Flow: Basic success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Read a Subscription

Actors: Consent Client, CAS

Pre-condition: A Subscription [optionally conforming to the FASTSubscription profile] exists at the CAS, and its ID is known.

Narrative:

1. Client sends a conformant read to CAS using the known ID. This is unconstrained, e.g. the "_format" parameter may be present.
2. Verify the request is valid according to the linked requirements.
3. [No requirements yet, but something like this: CAS verifies the request is valid.]
4. CAS returns a conformant response containing the resource.
5. Verify the response is valid according to the linked requirements [note no rqmt that the Subscription declares and conforms to the FASTSubscription profile].

Post-condition:

- None

- Notes: Base test case. Mostly unconstrained, so it can be used in the widest variety of cases.

- Traced Requirements:
  - 69: Consent Administration Service MAY return OperationOutcome for a successful operation
  - 64: Consent Administration Service SHALL support Consent subscriptions (as defined by the FAST Subscription Topic for FHIR R4 with Subscriptions Backport)
  - 377: Consent Administration Service SHALL support Consent subscriptions as defined by the FASTConsentSubscriptionTopic for FHIR R4 with Subscriptions Backport
  - 381: Consent Client SHALL support Consent subscriptions as defined by the FASTConsentSubscriptionTopic for FHIR R4 with Subscriptions Backport
  - 496: Consent Administration Service SHALL support Subscription read
  - 505: Consent Administration Service SHALL support Subscription read
  - 565: Consent Administration Service SHOULD NOT use cross version extensions on R4 subscriptions to describe any elements also described by this guide
  - 567: Consent Administration Service SHOULD NOT use cross version extensions on R4 subscriptions to describe any elements also described by this guide
  - 513: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile
  - 517: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile
  - 514: Consent Administration Service SHALL mark with profile assertions Subscription resources that conform to the BackportSubscription profile
  - 537: Subscription.criteria SHALL contain the canonical URL for the Subscription Topic

#### 232: Workflow: Create a Subscription - rest-hook

- Flow: Basic success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Workflow: Create a subscription - rest-hook

This is a wide-open workflow that can be used as the base for many variations.

Actors: Consent Client, CAS, Notification Endpoint

Pre-condition: CAS has advertised its support for subscriptions in its CapabilityStatement. Consent Client has prepared its Notification Endpoint to receive notifications.

Narrative:

1. Optional: Consent Client discovers subscription support at the CAS. Execute test case "Obtain server CapabilityStatement".
2. Client POSTs a conformant Subscription to the CAS. [note no requirement for it to be FASTSubscription]
3. Verify the request is valid according to the linked requirements.
4. CAS verifies the request is valid.
5. CAS returns a conformant response indicating the new Subscription location and optionally the resource in the body.
6. Verify the response is valid according to the linked requirements.
7. Optional: CAS sends a handshake. Execute test case "Notify for a Subscription - rest-hook". The trigger in step 1 is the creation of the Subscription. Verify the notification as "handshake".
8. Optional: Consent Client GETs the new Subscription to confirm it is active. Execute test case "Read a Subscription".
9. Optional: Consent Client executes $status against the new Subscription to confirm it is active. Execute test case "Operation: Get Subscription Status".

Post-condition:

- The new Subscription exists at the CAS.

- Included Test Cases:
  - 199: Read a Subscription
  - 265: Notify for a Subscription - rest-hook
  - 266: Operation: Get Subscription Status
  - 101: Obtain server CapabilityStatement
- Notes:
- Base test case. Mostly unconstrained, so it can be used in the widest variety of cases.
- https://hl7.org/fhir/R4/subscription-definitions.html#Subscription.status: A client can only submit subscription resources in the requested or off state. Only the server can move a subscription from requested to active, and then to error. Either the server or the client can turn a subscription off.

- Traced Requirements:
  - 69: Consent Administration Service MAY return OperationOutcome for a successful operation
  - 64: Consent Administration Service SHALL support Consent subscriptions (as defined by the FAST Subscription Topic for FHIR R4 with Subscriptions Backport)
  - 377: Consent Administration Service SHALL support Consent subscriptions as defined by the FASTConsentSubscriptionTopic for FHIR R4 with Subscriptions Backport
  - 381: Consent Client SHALL support Consent subscriptions as defined by the FASTConsentSubscriptionTopic for FHIR R4 with Subscriptions Backport
  - 265: This guide mandates that Subscriptions be used
  - 378: Consent Administration Service SHALL support Subscription create
  - 382: Consent Client SHALL support Subscription create
  - 497: Consent Administration Service SHALL support Subscription write
  - 503: Consent Administration Service SHOULD support Subscription write via POST or PUT
  - 499: Consent Administration Service SHOULD support Subscription topic discovery via the CapabilityStatement SubscriptionTopic Canonical extension
  - 500: Consent Administration Service SHALL support at least one Subscription channel type, and SHOULD include one from Subscriptions R5 Backport IG
  - 501: Consent Administration Service SHALL support at least one Subscription Payload Type
  - 512: Consent Client SHOULD NOT use cross version extensions on R4 subscriptions to describe any elements also described by this guide
  - 566: Consent Client SHOULD NOT use cross version extensions on R4 subscriptions to describe any elements also described by this guide
  - 513: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile
  - 517: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile
  - 506: Consent Administration Service SHALL be able to read values in the backport-channel-type extension
  - 529: Consent Administration Service SHALL be able to read values in the backport-filter-criteria extension
  - 532: Consent Client SHALL be able to write values in the backport-filter-criteria extension
  - 533: Consent Administration Service SHALL be able to read values in the backport-payload-content extension
  - 536: Consent Client SHALL be able to write values in the backport-payload-content extension
  - 564: Consent Client SHALL be able to process a valid R4 Backported R5 SubscriptionStatus resource without errors
  - 537: Subscription.criteria SHALL contain the canonical URL for the Subscription Topic
  - 538: Consent Administration Service SHALL be able to read values in Subscription.criteria for subscription topics referenced by it
  - 540: Consent Client SHALL be able to write subscription topic URLs in Subscription.criteria

#### 305: Workflow: Create a Subscription - rest-hook PUT

- Flow: Alternate success
- Systems Under Test:
  - Client: Conditional - System supports create as PUT
  - Server: Conditional - System supports create as PUT
- Test Details:

Workflow: Create a subscription - rest-hook PUT

This test case extends test case "Workflow: Create a subscription - rest-hook".

- In step 2, Consent Client PUTs a conformant Subscription to the CAS.
- In step 3, verify the resource id passed in was used.

- Parent: 232: Workflow: Create a Subscription - rest-hook
- Traced Requirements:
  - 503: Consent Administration Service SHOULD support Subscription write via POST or PUT

#### 308: Error: Create a Subscription - rest-hook - unsupported backport-channel-type

- Flow: Error
- Systems Under Test:
  - Server: Required
- Test Details:

Error: Create a Subscription - rest-hook - unsupported backport-channel-type

Actors: Consent Client, CAS

Pre-condition: None

Narrative:

1. Consent Client POSTs a Subscription to the CAS using the backport-channel-type extension with a nonsense value.
2. CAS returns a conformant response indicating the Subscription request was rejected.
3. Verify the response is valid according to the linked requirements.

Post-condition: The Subscription has not been created at the CAS.

- Traced Requirements:
  - 68: Consent Administration Service SHOULD return OperationOutcome with details of which business rules did not allow an operation to be successful if an HTTP status code of 4xx or 5xx is returned
  - 507: Consent Administration Service SHALL reject the subscription request if a client requests an unsupported channel via the backport-channel-type extension

#### 309: Error: Create a Subscription - rest-hook - unsupported filter

- Flow: Error
- Systems Under Test:
  - Server: Required
- Test Details:

Error: Create a Subscription - rest-hook - unsupported filter

Actors: Consent Client, CAS

Pre-condition: None

Narrative:

1. Consent Client POSTs a Subscription to the CAS using a filter with a nonsense value.
2. CAS returns a conformant response indicating the Subscription request was rejected.
3. Verify the response is valid according to the linked requirements.

Post-condition: The Subscription has not been created at the CAS.

- Traced Requirements:
  - 68: Consent Administration Service SHOULD return OperationOutcome with details of which business rules did not allow an operation to be successful if an HTTP status code of 4xx or 5xx is returned
  - 531: Consent Administration Service SHALL reject the subscription request if any filters are unsupported

#### 310: Error: Create a Subscription - rest-hook - unsupported content level

- Flow: Error
- Systems Under Test:
  - Server: Conditional - Server can be configured not to support a given content level (this may require specific test data)
- Test Details:

Error: Create a Subscription - rest-hook - unsupported content level

Actors: Consent Client, CAS

Pre-condition: None

Narrative:

1. Consent Client POSTs a Subscription to the CAS using a content level the server does not support.
2. CAS returns a conformant response indicating the Subscription request was rejected.
3. Verify the response is valid according to the linked requirements.

Post-condition: The Subscription has not been created at the CAS.

- Traced Requirements:
  - 535: Consent Administration Service SHALL reject the subscription request if a client asks for a content level the server does not intend to support (e.g., does not meet security requirements)

#### 311: Error: Create a Subscription - rest-hook - unsupported topic

- Flow: Error
- Systems Under Test:
  - Server: Required
- Test Details:

Error: Create a Subscription - rest-hook - unsupported topic

Actors: Consent Client, CAS

Pre-condition: None

Narrative:

1. Consent Client POSTs a Subscription to the CAS using a nonsense topic.
2. CAS returns a conformant response indicating the Subscription request was rejected.
3. Verify the response is valid according to the linked requirements.

Post-condition: The Subscription has not been created at the CAS.

- Traced Requirements:
  - 539: Consent Administration Service SHALL reject the subscription request if it does not support a requested topic or will not honor the subscription otherwise

#### 306: Workflow: Update a Subscription - rest-hook

- Flow: Basic success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Workflow: Update a Subscription - rest-hook

This is a wide-open workflow that can be used as the base for many variations.

Actors: Consent Client, CAS, Notification Endpoint

Pre-condition: Consent Client has an existing Subscription at the CAS.

Narrative:

1. Client PUTs an updated, conformant Subscription to the CAS. [note no requirement for it to be FASTSubscription]
2. Verify the request is valid according to the linked requirements.
3. CAS verifies the request is valid.
4. CAS returns a conformant response indicating the new Subscription location and optionally the resource in the body.
5. Verify the response is valid according to the linked requirements.
6. Optional: CAS sends a handshake. Execute test case "Notify for a Subscription - rest-hook channel". The trigger in step 1 is the creation of the Subscription. Verify the notification as "handshake".
7. Optional: Consent Client GETs the new Subscription to confirm it is active. Execute test case "Read a Subscription".
8. Optional: Consent Client executes $status against the new Subscription to confirm it is active. Execute test case "Operation: Get Subscription Status".

Post-condition:

- The updated Subscription exists at the CAS.

- Parent: 306: Workflow: Update a Subscription - rest-hook
- Traced Requirements:
  - 379: Consent Administration Service SHALL support Subscription update
  - 383: Consent Client SHALL support Subscription update
  - 509: Consent Administration Service SHOULD support Subscription update via PUT or PATCH

#### 307: Workflow: Update a Subscription - rest-hook PATCH

- Flow: Alternate success
- Systems Under Test:
  - Client: Conditional - Client and server support update as PATCH
  - Server: Conditional - Client and server support update as PATCH
- Test Details:

Workflow: Update a Subscription - rest-hook PATCH

This test case extends test case "Workflow: Update a Subscription - rest-hook".

- In step 1, Consent Client PATCHs an updated, conformant Subscription to the CAS.
- At the end of the test case, verify the resource was updated appropriately.

- Traced Requirements:
  - 509: Consent Administration Service SHOULD support Subscription update via PUT or PATCH

#### 265: Notify for a Subscription - rest-hook

- Flow: Basic success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Workflow: Notify for a Subscription - rest-hook

This is a wide-open workflow that can be used as the base for many variations. Each variation needs to specify what the trigger in step 1 is.

Actors: Consent Client, CAS, Notification Endpoint

Pre-condition: Consent Client has successfully made a Subscription at the CAS, with the rest-hook channel type.

Narrative:

1. An actor performs an action at the CAS that should trigger a notification for this Subscription.
2. CAS POSTs a conformant R4 Topic-Based Subscription Notification Bundle to the Consent Client's Notification Endpoint.
3. Verify the notification is valid according to the linked requirements.
4. The Consent Client verifies the notification and returns a valid 200 response.
5. Verify the response.
6. Optional: Consent Client GETs a new or modified Consent. Execute test case "Read a Consent".

Post-condition:

- None

- Included Test Cases:
  - 1: Read a Consent
- Traced Requirements:
  - 69: Consent Administration Service MAY return OperationOutcome for a successful operation
  - 331: Consent Administration Service SHALL mark with profile assertions Consent resources that conform to the FASTConsent profile
  - 64: Consent Administration Service SHALL support Consent subscriptions (as defined by the FAST Subscription Topic for FHIR R4 with Subscriptions Backport)
  - 377: Consent Administration Service SHALL support Consent subscriptions as defined by the FASTConsentSubscriptionTopic for FHIR R4 with Subscriptions Backport
  - 381: Consent Client SHALL support Consent subscriptions as defined by the FASTConsentSubscriptionTopic for FHIR R4 with Subscriptions Backport
  - 265: This guide mandates that Subscriptions be used
  - 500: Consent Administration Service SHALL support at least one Subscription channel type, and SHOULD include one from Subscriptions R5 Backport IG
  - 501: Consent Administration Service SHALL support at least one Subscription Payload Type
  - 565: Consent Administration Service SHOULD NOT use cross version extensions on R4 subscriptions to describe any elements also described by this guide
  - 567: Consent Administration Service SHOULD NOT use cross version extensions on R4 subscriptions to describe any elements also described by this guide
  - 513: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile
  - 517: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile
  - 514: Consent Administration Service SHALL mark with profile assertions Subscription resources that conform to the BackportSubscription profile
  - 506: Consent Administration Service SHALL be able to read values in the backport-channel-type extension
  - 529: Consent Administration Service SHALL be able to read values in the backport-filter-criteria extension
  - 530: Consent Administration Service SHALL be able to apply filters as described by any Subscription Topics the server advertises support for
  - 534: Consent Administration Service SHALL include information in notifications as described in this guide based on the value of the backport-payload-content extension
  - 562: Notification bundles SHALL contain a FHIR R4 Parameters resource, conforming to the R4 Backported R5 SubscriptionStatus profile, as the first entry
  - 563: Consent Administration Service SHALL be able to generate a valid and correct R4 Backported R5 SubscriptionStatus resource for each notification
  - 564: Consent Client SHALL be able to process a valid R4 Backported R5 SubscriptionStatus resource without errors

#### 266: Operation: Get Subscription Status

- Flow: Basic success
- Systems Under Test:
  - Client: Conditional - Client can call $status
  - Server: Required
- Test Details:

Operation: Get Subscription Status

Actors: Consent Client, CAS

Pre-condition: None

Narrative:

1. Client POSTs to CAS: [base]/Subscription/$status.
2. Verify input parameters are valid according to linked requirements.
3. CAS returns a response.
4. Verify response is valid according to linked requirements.

Post-condition:

- None

- Notes: I haven't seen a requirement clients must support or call this yet.

- Traced Requirements:
  - 498: Consent Administration Service SHALL support $status operation against Subscription resource
  - 508: Consent Administration Service SHALL support $status operation against Subscription resource
  - 564: Consent Client SHALL be able to process a valid R4 Backported R5 SubscriptionStatus resource without errors

#### 68: Operation: File a Consent

- Flow: Basic success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Operation: File a Consent

Actors: Consent Client, CAS

Pre-condition: None

Narrative:

1. Client POSTs to CAS: [base]/Consent/$fileConsent [unconstrained, e.g. the "document" parameter may be either flavor].
2. Verify input parameters are valid according to linked requirements.
3. [No requirements yet, but something like this: CAS verifies inputs, generates and persists the Consent and related resources. CAS may retain external references (e.g. to Patient), or replace with references to new or matched existing resources.]
4. CAS returns a response.
5. Verify response is valid according to linked requirements.

Post-condition:

- [No requirements yet, but something like this: The Consent and related resources are persisted and available at the CAS.]

- Traced Requirements:
  - 69: Consent Administration Service MAY return OperationOutcome for a successful operation
  - 35: Consent Administration Service SHALL support Consent resources that conform to FASTConsent profile
  - 52: Consent Client SHALL support Consent resources that conform to FASTConsent profile
  - 334: Consent Client SHALL mark with profile assertions Consent resources that conform to the FASTConsent profile
  - 62: Consent Administration Service SHALL support File Consent operation
  - 46: Consent Administration Service SHALL support $fileConsent operation against Consent resource
  - 53: Consent Client SHALL support $fileConsent operation against Consent resource
  - 463: OperationDefinition FileConsent
  - 133: The FileConsent operation is invoked as [base]/Consent/$fileConsent
  - 134: The FileConsent operation input parameters SHALL conform to the FileConsentParameters profile
  - 135: The FileConsent operation "consent" input parameter SHALL be 1..1 and a Consent resource
  - 166: The FileConsent operation "document" input parameter SHALL be 1..1 and any resource
  - 168: The FileConsent operation "return" output parameter SHALL be 0..1 and be an OperationOutcome
  - 464: StructureDefinition FileConsentParameters
  - 70: The FileConsent operation "consent" input parameter SHALL be 1..1 and conform to the FASTConsent profile
  - 430: The FileConsent operation "document" input parameter SHALL be 1..1 and conform to either the us-core-questionnaireresponse or FASTDocumentReference profile

#### 70: Operation: Revoke a Consent

- Flow: Basic success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Operation: Revoke a Consent

Actors: Consent Client, CAS

Pre-condition: None

Narrative:

1. Client POSTs to CAS: [base]/Consent/$revokeConsent [unconstrained, e.g. the "document" parameter may be either flavor].
2. Verify input parameters are valid according to linked requirements.
3. [No requirements yet, but something like this: CAS verifies inputs, persists the revoked Consent and related resources. CAS may retain external references (e.g. to Patient), or replace with references to new or matched existing resources.]
4. CAS returns a response.
5. Verify response is valid according to linked requirements.

Post-condition:

- [No requirements yet, but something like this: The revoked Consent and related resources are persisted and available at the CAS.]

- Traced Requirements:
  - 69: Consent Administration Service MAY return OperationOutcome for a successful operation
  - 35: Consent Administration Service SHALL support Consent resources that conform to FASTConsent profile
  - 52: Consent Client SHALL support Consent resources that conform to FASTConsent profile
  - 334: Consent Client SHALL mark with profile assertions Consent resources that conform to the FASTConsent profile
  - 101: Consent Administration Service SHALL support Revoke Consent operation
  - 374: Consent Administration Service SHALL support $revokeConsent operation against Consent resource
  - 376: Consent Client SHALL support $revokeConsent operation against Consent resource
  - 466: OperationDefinition RevokeConsent
  - 438: The RevokeConsent operation is invoked as [base]/Consent/$revokeConsent
  - 439: The RevokeConsent operation input parameters SHALL conform to the RevokeConsentParameters profile
  - 440: The RevokeConsent operation "consent" input parameter SHALL be 1..1 and conform to the FASTConsent profile
  - 447: The RevokeConsent operation "patient" input parameter SHALL be 1..1 and conform to the us-core-patient profile
  - 442: The RevokeConsent operation "document" input parameter SHALL be 0..1 and any resource
  - 444: The RevokeConsent operation "return" output parameter SHALL be 0..1 and be an OperationOutcome
  - 469: StructureDefinition RevokeConsentParameters
  - 441: The RevokeConsent operation "consent" input parameter SHALL be 1..1 and conform to the FASTConsent profile
  - 448: The RevokeConsent operation "patient" input parameter SHALL be 1..1 and conform to the us-core-patient profile
  - 443: The RevokeConsent operation "document" input parameter SHALL be 0..1 and conform to either the us-core-questionnaireresponse or FASTDocumentReference profile

#### 69: Operation: Record a Disclosure

- Flow: Basic success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Operation: Record a Disclosure

Actors: Consent Client, CAS

Pre-condition: None

Narrative:

1. Client POSTs to CAS: [base]/AuditEvent/$recordDisclosure [unconstrained].
2. Verify input parameters are valid according to linked requirements.
3. [No requirements yet, but something like this: CAS verifies inputs, generates and persists the AuditEvent and related resources. CAS may retain external references (e.g. to Patient), or replace with references to new or matched existing resources.]
4. CAS returns a response.
5. Verify response is valid according to linked requirements.

Post-condition:

- [No requirements yet, but something like this: The AuditEvent and related resources are persisted and available at the CAS.]

- Traced Requirements:
  - 69: Consent Administration Service MAY return OperationOutcome for a successful operation
  - 52: Consent Client SHALL support Consent resources that conform to FASTConsent profile
  - 334: Consent Client SHALL mark with profile assertions Consent resources that conform to the FASTConsent profile
  - 415: Consent Administration Service SHALL support $recordDisclosure operation against AuditEvent resource
  - 416: Consent Client SHALL support $recordDisclosure operation against AuditEvent resource
  - 398: Consent Administration Service SHALL support AuditEvent resources that conform to FASTConsentAuditEvent profile
  - 402: Consent Client SHALL support AuditEvent resources that conform to FASTConsentAuditEvent profile
  - 403: Consent Client SHALL mark with profile assertions AuditEvent resources that conform to the FASTConsentAuditEvent profile
  - 467: OperationDefinition RecordDisclosure
  - 445: The RecordDisclosure operation is invoked as [base]/AuditEvent/$recordDisclosure
  - 446: The RecordDisclosure operation input parameters SHALL conform to the RecordDisclosureParameters profile
  - 451: The RecordDisclosure operation "disclosure" input parameter SHALL be 1..1 and an AuditEvent resource
  - 449: The RecordDisclosure operation "consent" input parameter SHALL be 1..1 and conform to the FASTConsent profile
  - 453: The RecordDisclosure operation "return" output parameter SHALL be 0..1 and be an OperationOutcome
  - 470: StructureDefinition RecordDisclosureParameters
  - 452: The RecordDisclosure operation "disclosure" input parameter SHALL be 1..1 and conform to the FASTConsentAuditEvent profile
  - 450: The RecordDisclosure operation "consent" input parameter SHALL be 1..1 and conform to the FASTConsent profile
  - 513: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile

#### 101: Obtain server CapabilityStatement

- Flow: Basic success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Obtain server CapabilityStatement

Actors: Consent client, CAS

Pre-condition: None

Narrative:

1. Client sends a metadata request to the CAS, requesting the FHIR 4.0 CS by using the fhirVersion Accept header.
2. Verify the request is valid according to the linked requirements.
3. [No requirements yet, but something like this: CAS verifies the request is valid.]
4. CAS returns a conformant response containing the system CapabilityStatement.
5. Verify the response is valid according to the linked requirements.
6. Verify the CapabilityStatement includes the normative aspects defined in the ConsentAdministrativeServer CapabilityStatement. Additional aspects are permitted but will not be evaluated.

Post-condition:

- None

- Notes: Some questions/assumptions:
- How should we address FHIR versions? Clients request using the fhirVersion Accept header? For now, yes in this test.
- Should we also test the CS returned in other versions? For now no.
- We will test adherence to the CS in other tests.
- We will not test adherence to the actual system CS, rather to the IG CS only. For example, if the system removes required support in its CS we will still hold it to the IG's CS.

- Traced Requirements:
  - 69: Consent Administration Service MAY return OperationOutcome for a successful operation
  - 1: Consent Administration Service SHALL implement the server CapabilityStatement
  - 43: Consent Administration Service SHALL support Consent resource
  - 35: Consent Administration Service SHALL support Consent resources that conform to FASTConsent profile
  - 36: Consent Administration Service SHALL support Consent read
  - 37: Consent Administration Service SHALL support Consent search
  - 199: Consent Administration Service SHALL support Consent search by FASTConsentController
  - 72: Consent Administration Service SHALL support Consent search by date
  - 38: Consent Administration Service SHALL support Consent search by FASTConsentGrantee
  - 200: Consent Administration Service SHALL support Consent search by FASTConsentManager
  - 39: Consent Administration Service SHALL support Consent search by FASTConsentOrganizationId
  - 40: Consent Administration Service SHALL support Consent search by patient
  - 368: Consent Administration Service SHALL support Consent search by FASTConsentPatientId
  - 42: Consent Administration Service SHALL support Consent search by scope
  - 41: Consent Administration Service SHALL support Consent search by status
  - 46: Consent Administration Service SHALL support $fileConsent operation against Consent resource
  - 374: Consent Administration Service SHALL support $revokeConsent operation against Consent resource
  - 377: Consent Administration Service SHALL support Consent subscriptions as defined by the FASTConsentSubscriptionTopic for FHIR R4 with Subscriptions Backport
  - 378: Consent Administration Service SHALL support Subscription create
  - 379: Consent Administration Service SHALL support Subscription update
  - 380: Consent Administration Service SHALL support Subscription delete
  - 415: Consent Administration Service SHALL support $recordDisclosure operation against AuditEvent resource
  - 397: Consent Administration Service SHALL support AuditEvent resource
  - 398: Consent Administration Service SHALL support AuditEvent resources that conform to FASTConsentAuditEvent profile
  - 404: Consent Administration Service SHALL support AuditEvent read
  - 406: Consent Administration Service SHALL support AuditEvent search
  - 409: Consent Administration Service SHALL support AuditEvent search by FASTAuditEventConsent
  - 412: Consent Administration Service SHALL support AuditEvent search by patient
  - 509: Consent Administration Service SHOULD support Subscription update via PUT or PATCH
  - 511: Consent Administration Service SHOULD support Subscription search
  - 602: Consent Administration Service SHALL support Subscription search by url
  - 604: Consent Administration Service SHOULD support Subscription search by status
  - 694: Consent Administration Service MAY support $events operation against Subscription resource
  - 499: Consent Administration Service SHOULD support Subscription topic discovery via the CapabilityStatement SubscriptionTopic Canonical extension
  - 504: Consent Administration Service SHOULD declare conformance with the BackportSubscriptionCapabilityStatementR4 using CapabilityStatement.instantiates
  - 513: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile

#### 136: Obtain server CapabilityStatement - JSON

- Flow: Basic success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Obtain server CapabilityStatement - JSON

This test case extends test case "Obtain server CapabilityStatement".

- In step 1, the client requests JSON.
- In step 5, verify the CapabilityStatement is JSON.
- In all steps, evaluate FHIR content as JSON.

- Parent: 101: Obtain server CapabilityStatement
- Traced Requirements:
  - 2: Consent Administration Service SHALL support JSON FHIR
  - 49: Consent Client SHALL support JSON FHIR

#### 137: Obtain server CapabilityStatement - XML

- Flow: Basic success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Obtain server CapabilityStatement - XML

This test case extends test case "Obtain server CapabilityStatement".

- In step 1, the client requests XML.
- In step 5, verify the CapabilityStatement is XML.
- In all steps, evaluate FHIR content as XML.

- Parent: 101: Obtain server CapabilityStatement
- Traced Requirements:
  - 34: Consent Administration Service SHALL support XML FHIR
  - 50: Consent Client SHALL support XML FHIR

#### 133: Obtain and handle conformant variations of server CapabilityStatement

- Flow: Alternate success
- Systems Under Test:
  - Client: Provisional
- Test Details:

Obtain and handle conformant variations of server CapabilityStatement

This tests the ability of a client to handle legal variants of CSs.

Actors: Consent Client, Simulated CAS

Pre-condition: None

Narrative:

1. Client sends a metadata request to the CAS. [unconstrained; may or may not use the fhirVersion Accept header]
2. Verify the request is valid according to the linked requirements.
3. [No requirements yet, but something like this: CAS verifies the request is valid.]
4. CAS returns a conformant response containing the system CapabilityStatement.
5. Verify the response is valid according to the linked requirements.
6. Verify the CapabilityStatement includes the normative aspects defined in the ConsentAdministrativeServer CapabilityStatement. Additional aspects are permitted but will not be evaluated.

Post-condition:

- The client should be able to communicate with this server per the workflows in this IG.

- Notes:
- The idea here is to have a set of conformant CSs the client consumes before starting on a workflow.
- Need to think about how we want to test clients' responsibility to process and ability to handle variant or error CSs.
- Should we expect they obtain and parse a CS and have a go/nogo decision before continuing with any flows?
- How should they react if a server doesn't support aspects they expect?

#### 135: Obtain and handle STU3 version server CapabilityStatement

- Flow: Alternate success
- Systems Under Test:
  - Client: Conditional - Client does not explicitly request fhirVersion by default
- Test Details:

Obtain and handle STU3 version server CapabilityStatement

This tests the ability of a client to handle an STU3 CS.

Actors: Consent Client, Simulated CAS

Pre-condition: None

Narrative:

1. Client sends a metadata request to the CAS without the fhirVersion Accept header.
2. Verify the request is valid according to the linked requirements.
3. CAS returns a conformant response containing an STU3 system CapabilityStatement.
4. Verify the client detects the version mismatch and resolves somehow, e.g. notifies the user, retries the request including the fhirVersion Accept header, etc.

Post-condition:

- None (yet)

- Notes: No requirements on what clients should do in this case; hence provisional

#### 134: Test client CapabilityStatement

- Flow: Basic success
- Systems Under Test:
  - Client: Conditional - Client maintains and makes available a system CapabilityStatement
- Test Details:

Test client CapabilityStatement

Actors: Consent client

Pre-condition: None

Narrative:

1. Obtain the client CapabilityStatement.
2. Verify the CapabilityStatement includes the normative aspects defined in the ConsentClient CapabilityStatement. Additional aspects are permitted but will not be evaluated.

Post-condition:

- None

- Notes: There are no standardized ways to obtain a client CS, but "Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements." Not sure if that means maintain a client CS or just attest conformance in some other way.

- Traced Requirements:
  - 48: Consent Client SHALL implement the client CapabilityStatement
  - 333: Consent Client SHALL support Consent resource
  - 52: Consent Client SHALL support Consent resources that conform to FASTConsent profile
  - 56: Consent Client SHALL support Consent read
  - 57: Consent Client SHALL support Consent search
  - 58: Consent Client SHALL support Consent search by FASTConsentController
  - 369: Consent Client SHALL support Consent search by date
  - 370: Consent Client SHALL support Consent search by FASTConsentGrantee
  - 371: Consent Client SHALL support Consent search by FASTConsentManager
  - 59: Consent Client SHALL support Consent search by FASTConsentOrganizationId
  - 60: Consent Client SHALL support Consent search by patient
  - 372: Consent Client SHALL support Consent search by FASTConsentPatientId
  - 47: Consent Client SHALL support Consent search by scope
  - 61: Consent Client SHALL support Consent search by status
  - 53: Consent Client SHALL support $fileConsent operation against Consent resource
  - 376: Consent Client SHALL support $revokeConsent operation against Consent resource
  - 381: Consent Client SHALL support Consent subscriptions as defined by the FASTConsentSubscriptionTopic for FHIR R4 with Subscriptions Backport
  - 382: Consent Client SHALL support Subscription create
  - 383: Consent Client SHALL support Subscription update
  - 384: Consent Client SHALL support Subscription delete
  - 416: Consent Client SHALL support $recordDisclosure operation against AuditEvent resource
  - 401: Consent Client SHALL support AuditEvent resource
  - 402: Consent Client SHALL support AuditEvent resources that conform to FASTConsentAuditEvent profile
  - 405: Consent Client SHALL support AuditEvent read
  - 408: Consent Client SHALL support AuditEvent search
  - 411: Consent Client SHALL support AuditEvent search by FASTAuditEventConsent
  - 414: Consent Client SHALL support AuditEvent search by patient

#### 138: Test client CapabilityStatement - JSON

- Flow: Basic success
- Systems Under Test:
  - Client: Conditional - Client maintains and makes available a system CapabilityStatement
- Test Details:

Test client CapabilityStatement - JSON

This test case extends test case "Test client CapabilityStatement".

- In step 1, obtain the JSON CapabilityStatement.
- In step 2, evaluate FHIR content as JSON.

- Parent: 134: Test client CapabilityStatement
- Traced Requirements:
  - 49: Consent Client SHALL support JSON FHIR

#### 139: Test client CapabilityStatement - XML

- Flow: Basic success
- Systems Under Test:
  - Client: Conditional - Client maintains and makes available a system CapabilityStatement
- Test Details:

Test client CapabilityStatement - XML

This test case extends test case "Test client CapabilityStatement".

- In step 1, obtain the XML CapabilityStatement.
- In step 2, evaluate FHIR content as XML.

- Parent: 134: Test client CapabilityStatement
- Traced Requirements:
  - 50: Consent Client SHALL support XML FHIR

#### 100: Workflow: Consent subscription and notification

- Flow: Basic success
- Systems Under Test:
- Test Details:

Workflow: Consent subscription and notification

This is a wide-open workflow that can be used as the base for many variations.

Actors: Consent Client, CAS, Notification Endpoint, Tester

Pre-condition: CAS has advertised its support for subscriptions in its CapabilityStatement. Consent Client has prepared its Notification Endpoint to receive notifications. There are no current subscriptions between this CAS and this Endpoint.

Narrative:

1. Execute test case "Create a Subscription - rest-hook".
2. Tester performs an action at the CAS that should trigger a notification for this Subscription. This may be a local action or an API action.
3. Execute test case "Notify for a Subscription - rest-hook". The trigger is step 2 above. Additionally verify the notification as "event-notification".
4. Client DELETEs the FASTSubscription at the CAS.
5. The CAS deletes the Subscription.
6. Verify the response is valid according to the linked requirements.
7. Tester performs an action at the CAS that should trigger a notification for the previous Subscription. This may be a local action or an API action.
8. Verify the CAS does not POST an "event-notification" R4 Topic-Based Subscription Notification Bundle to the Endpoint.

Post-condition:

- Any Subscriptions created at the CAS have been deleted. Other changes at the CAS (new Consents, etc.) may or may not have been deleted.

- Included Test Cases:
  - 232: Workflow: Create a Subscription - rest-hook
  - 265: Notify for a Subscription - rest-hook
- Notes:
- This base workflow includes setup and teardown of the subscription as well as notification, as that lends itself well to good coverage and clean testing (not leaving subscriptions laying around).
- To handle the optional steps, will create multiple test instances that prescribe specific combinations.

- Traced Requirements:
  - 64: Consent Administration Service SHALL support Consent subscriptions (as defined by the FAST Subscription Topic for FHIR R4 with Subscriptions Backport)
  - 377: Consent Administration Service SHALL support Consent subscriptions as defined by the FASTConsentSubscriptionTopic for FHIR R4 with Subscriptions Backport
  - 381: Consent Client SHALL support Consent subscriptions as defined by the FASTConsentSubscriptionTopic for FHIR R4 with Subscriptions Backport
  - 202: Consent Client MAY subscribe to Consent topics as defined by the FAST Subscription Topic
  - 265: This guide mandates that Subscriptions be used
  - 380: Consent Administration Service SHALL support Subscription delete
  - 384: Consent Client SHALL support Subscription delete
  - 510: Consent Administration Service SHOULD support Subscription delete
  - 500: Consent Administration Service SHALL support at least one Subscription channel type, and SHOULD include one from Subscriptions R5 Backport IG
  - 501: Consent Administration Service SHALL support at least one Subscription Payload Type
  - 513: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile
  - 517: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile
  - 534: Consent Administration Service SHALL include information in notifications as described in this guide based on the value of the backport-payload-content extension
  - 541: Informative: Consent Client and Consent Administration Service generally follow the subscription workflow for R4 systems in section 2.3.3
  - 600: Consent Administration Service SHALL trigger a notification for every Consent create, unless filtered out
  - 606: Consent Administration Service SHALL trigger a notification for every Consent update, unless filtered out
  - 607: Consent Administration Service SHALL trigger a notification for every Consent delete, unless filtered out

#### 298: Workflow: Consent subscription and notification - FASTConsentPatientId

- Flow: Alternate success
- Systems Under Test:
  - Client: Conditional - Client can subscribe by FASTConsentPatientId
  - Server: Required
- Test Details:

Workflow: Consent subscription and notification - FASTConsentPatientId

This test case extends test case "Workflow: Consent subscription and notification".

Test data: Data for 2 conformant FASTConsents for an existing patient known at the CAS. No existing Consents for this patient at the CAS. Each Consent differs by where it identifies the patient: patient.identifier element or patient.extension additionalIdentifier.

- In step 1, Consent Client creates a Subscription at the CAS filtering only on FASTConsentPatientId, for the known patient in the test data.
- Repeat steps 2-3 as follows:
- In step 2, Tester creates each Consent at the CAS using this test data.
- In step 3, verify notification for each per this subscription and trigger.
- In step 2, Tester updates each Consent at the CAS.
- In step 3, verify notification for each per this subscription and trigger.
- In step 2, Tester deletes the Consent at the CAS.
- In step 3, verify notification for each per this subscription and trigger.
- Continue with steps 4-6.
- Repeat steps 7-8 as follows:
- In step 7, Tester creates each Consent at the CAS using this test data.
- In step 7, Tester updates each Consent at the CAS.
- In step 7, Tester deletes each Consent at the CAS.

Additional Post-condition:

- Any Consents created at the CAS have been deleted.

- Parent: 100: Workflow: Consent subscription and notification
- Traced Requirements:
  - 603: Consent Administration Service SHALL support Consent notification filter by SearchParameter FASTConsentPatientId
  - 635: Consent Client MAY support Consent notification filter by SearchParameter FASTConsentPatientId

#### 299: Workflow: Consent subscription and notification - FASTConsentOrganizationId

- Flow: Alternate success
- Systems Under Test:
  - Client: Conditional - Client can subscribe by FASTConsentOrganizationId
  - Server: Required
- Test Details:

Workflow: Consent subscription and notification - FASTConsentOrganizationId

This test case extends test case "Workflow: Consent subscription and notification".

Test data: Data for 4 conformant FASTConsents for an existing organization known at the CAS. No existing Consents for this organization at the CAS. Each Consent differs by where it identifies the organization: the extensions grantee, manager, controller or the provision.actor.role.reference.

- In step 1, Consent Client creates a Subscription at the CAS filtering only on FASTConsentOrganizationId, for the known organization in the test data.
- Repeat steps 2-3 as follows:
- In step 2, Tester creates each Consent at the CAS using this test data.
- In step 3, verify notification for each per this subscription and trigger.
- In step 2, Tester updates each Consent at the CAS.
- In step 3, verify notification for each per this subscription and trigger.
- In step 2, Tester deletes the Consent at the CAS.
- In step 3, verify notification for each per this subscription and trigger.
- Continue with steps 4-6.
- Repeat steps 7-8 as follows:
- In step 7, Tester creates each Consent at the CAS using this test data.
- In step 7, Tester updates each Consent at the CAS.
- In step 7, Tester deletes each Consent at the CAS.

Additional Post-condition:

- Any Consents created at the CAS have been deleted.

- Parent: 100: Workflow: Consent subscription and notification
- Traced Requirements:
  - 628: Consent Administration Service SHALL support Consent notification filter by SearchParameter FASTConsentOrganizationId
  - 636: Consent Client MAY support Consent notification filter by SearchParameter FASTConsentOrganizationId

#### 300: Workflow: Consent subscription and notification - actor

- Flow: Alternate success
- Systems Under Test:
  - Client: Conditional - Client can subscribe by actor
  - Server: Required
- Test Details:

Workflow: Consent subscription and notification - actor

This test case extends test case "Workflow: Consent subscription and notification".

Test data: Data for a conformant FASTConsent for an existing Consent actor (Consent.provision.actor.reference - see the actor search parameter) known at the CAS. No existing Consents for this actor at the CAS.

- In step 1, Consent Client creates a Subscription at the CAS filtering only on actor, for the known actor in the test data.
- Repeat steps 2-3 as follows:
- In step 2, Tester creates the Consent at the CAS using this test data.
- In step 3, verify notification per this subscription and trigger.
- In step 2, Tester updates the Consent at the CAS.
- In step 3, verify notification per this subscription and trigger.
- In step 2, Tester deletes the Consent at the CAS.
- In step 3, verify notification per this subscription and trigger.
- Continue with steps 4-6.
- Repeat steps 7-8 as follows:
- In step 7, Tester creates the Consent at the CAS using this test data.
- In step 7, Tester updates the Consent at the CAS.
- In step 7, Tester deletes the Consent at the CAS.

Additional Post-condition:

- Any Consents created at the CAS have been deleted.

- Parent: 100: Workflow: Consent subscription and notification
- Traced Requirements:
  - 629: Consent Administration Service SHALL support Consent notification filter by actor identifier
  - 637: Consent Client MAY support Consent notification filter by actor identifier

#### 301: Workflow: Consent subscription and notification - status

- Flow: Alternate success
- Systems Under Test:
  - Client: Conditional - Client can subscribe by status
  - Server: Required
- Test Details:

Workflow: Consent subscription and notification - status

This test case extends test case "Workflow: Consent subscription and notification".

Test data: Data for a conformant FASTConsent for an existing patient known at the CAS. No existing Consents for this patient at the CAS. Note that it may not be possible for there to be no existing Consents having this status at the CAS, so there may be false positives the tester will need to examine.

- In step 1, Consent Client creates a Subscription at the CAS filtering only on status, for the known status in the test data.
- Repeat steps 2-3 as follows:
- In step 2, Tester creates the Consent at the CAS using this test data.
- In step 3, verify notification per this subscription and trigger.
- In step 2, Tester updates the Consent at the CAS, changing a field other than status.
- In step 3, verify notification per this subscription and trigger.
- In step 2, Tester updates the Consent at the CAS, changing the status field.
- In step 3, status should not match, so no notification should occur.
- In step 2, Tester updates the Consent at the CAS, changing the status field back to the matching value.
- In step 3, verify notification per this subscription and trigger.
- In step 2, Tester deletes the Consent at the CAS.
- In step 3, verify notification per this subscription and trigger.
- Continue with steps 4-6.
- Repeat steps 7-8 as follows:
- In step 7, Tester creates the Consent at the CAS using this test data.
- In step 7, Tester updates the Consent at the CAS.
- In step 7, Tester deletes the Consent at the CAS.

Additional Post-condition:

- Any Consents created at the CAS have been deleted.

- Parent: 100: Workflow: Consent subscription and notification
- Traced Requirements:
  - 630: Consent Administration Service SHALL support Consent notification filter by status
  - 638: Consent Client MAY support Consent notification filter by status

#### 302: Workflow: Consent subscription and notification - scope

- Flow: Alternate success
- Systems Under Test:
  - Client: Conditional - Client can subscribe by scope
  - Server: Required
- Test Details:

Workflow: Consent subscription and notification - scope

This test case extends test case "Workflow: Consent subscription and notification".

Test data: Data for a conformant FASTConsent for an existing patient known at the CAS. No existing Consents for this patient at the CAS. Note that it may not be possible for there to be no existing Consents having this scope at the CAS, so there may be false positives the tester will need to examine.

- In step 1, Consent Client creates a Subscription at the CAS filtering only on scope, for the known scope in the test data.
- Repeat steps 2-3 as follows:
- In step 2, Tester creates the Consent at the CAS using this test data.
- In step 3, verify notification per this subscription and trigger.
- In step 2, Tester updates the Consent at the CAS, changing a field other than scope.
- In step 3, verify notification per this subscription and trigger.
- In step 2, Tester updates the Consent at the CAS, changing the scope field.
- In step 3, scope should not match, so no notification should occur.
- In step 2, Tester updates the Consent at the CAS, changing the scope field back to the matching value.
- In step 3, verify notification per this subscription and trigger.
- In step 2, Tester deletes the Consent at the CAS.
- In step 3, verify notification per this subscription and trigger.
- Continue with steps 4-6.
- Repeat steps 7-8 as follows:
- In step 7, Tester creates the Consent at the CAS using this test data.
- In step 7, Tester updates the Consent at the CAS.
- In step 7, Tester deletes the Consent at the CAS.

Additional Post-condition:

- Any Consents created at the CAS have been deleted.

- Parent: 100: Workflow: Consent subscription and notification
- Traced Requirements:
  - 631: Consent Administration Service SHALL support Consent notification filter by scope
  - 639: Consent Client MAY support Consent notification filter by scope

#### 303: Workflow: Consent subscription and notification - no filters

- Flow: Alternate success
- Systems Under Test:
  - Client: Conditional - Client can subscribe by no filters
  - Server: Required
- Test Details:

Workflow: Consent subscription and notification - no filters

This test case extends test case "Workflow: Consent subscription and notification".

Test data: Data for a conformant FASTConsent for an existing patient known at the CAS. No existing Consents for this patient at the CAS. Note that it may not be possible for there to be no existing Consents at the CAS, so there may be false positives the tester will need to examine.

- In step 1, Consent Client creates a Subscription at the CAS with no filters.
- Repeat steps 2-3 as follows:
- In step 2, Tester creates the Consent at the CAS using this test data.
- In step 3, verify notification per this subscription and trigger.
- In step 2, Tester updates the Consent at the CAS.
- In step 3, verify notification per this subscription and trigger.
- In step 2, Tester deletes the Consent at the CAS.
- In step 3, verify notification per this subscription and trigger.
- Continue with steps 4-6.
- Repeat steps 7-8 as follows:
- In step 7, Tester creates the Consent at the CAS using this test data.
- In step 7, Tester updates the Consent at the CAS.
- In step 7, Tester deletes the Consent at the CAS.

Additional Post-condition:

- Any Consents created at the CAS have been deleted.

- Parent: 100: Workflow: Consent subscription and notification
- Traced Requirements:
  - 64: Consent Administration Service SHALL support Consent subscriptions (as defined by the FAST Subscription Topic for FHIR R4 with Subscriptions Backport)
  - 377: Consent Administration Service SHALL support Consent subscriptions as defined by the FASTConsentSubscriptionTopic for FHIR R4 with Subscriptions Backport
  - 381: Consent Client SHALL support Consent subscriptions as defined by the FASTConsentSubscriptionTopic for FHIR R4 with Subscriptions Backport
  - 202: Consent Client MAY subscribe to Consent topics as defined by the FAST Subscription Topic
  - 265: This guide mandates that Subscriptions be used
  - 380: Consent Administration Service SHALL support Subscription delete
  - 384: Consent Client SHALL support Subscription delete
  - 510: Consent Administration Service SHOULD support Subscription delete
  - 500: Consent Administration Service SHALL support at least one Subscription channel type, and SHOULD include one from Subscriptions R5 Backport IG
  - 501: Consent Administration Service SHALL support at least one Subscription Payload Type
  - 513: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile
  - 517: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile
  - 534: Consent Administration Service SHALL include information in notifications as described in this guide based on the value of the backport-payload-content extension
  - 541: Informative: Consent Client and Consent Administration Service generally follow the subscription workflow for R4 systems in section 2.3.3

#### 304: Workflow: Consent subscription and notification - all filters

- Flow: Alternate success
- Systems Under Test:
  - Client: Conditional - Client can subscribe by all filters
  - Server: Required
- Test Details:

Workflow: Consent subscription and notification - all filters

This test case extends test case "Workflow: Consent subscription and notification".

TBD - define background test data that:

- matches on all fields in the subscription
- matches on all but one field in the subscription - do this for each field

Additional Post-condition:

- Any Consents created at the CAS have been deleted.

- Parent: 100: Workflow: Consent subscription and notification
- Traced Requirements:
  - 632: Consent Administration Service SHALL support Consent notification filter combinations
  - 640: Consent Client MAY support Consent notification filter combinations

#### 67: Workflow: Utilize Consent For Disclosure

- Flow: Basic success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Workflow: Utilize Consent For Disclosure

This is a wide-open workflow that can be used as the base for many variations.

Actors: Data Consumer, Data Holder with Consent Client, CAS

Pre-condition: Data holder has PHI for a patient. CAS has a valid, active Consent associated with that patient. [The rest is undefined: Data Holder may already have the Consent and know it is managed at this particular CAS, Data Holder may not know about the Consent or the CAS and discover it at the time the disclosure is requested.]

Narrative:

1. Data Holder is triggered to disclose PHI for the patient to the Data Consumer. This is unconstrained; it could be a request from the Consumer to the Holder, a push, etc.
2. Data Holder determines a Consent managed at the CAS affects this disclosure decision.
3. Optional: If needed, the Data Holder's Consent Client obtains the Consent from the CAS. This is unconstrained; it could be a read, search, etc. Execute the appropriate test cases.
4. Data Holder uses the Consent to make a determination to disclose. This is unconstrained; the determination could be based on multiple factors of which the Consent is only one part.
5. Data Holder discloses the PHI. This is the completion of whatever was started in step 1, e.g. a GET response.
6. Verify information was disclosed.
7. Data Holder's Consent Client records a disclosure at the CAS. Execute test case "Operation: Record a Disclosure".

Post-condition:

- The disclosure AuditEvent exists at the CAS.

- Included Test Cases:
  - 69: Operation: Record a Disclosure
- Notes: This is a very wide-open test to confirm the workflow functions. It may be specialized by alternate flows that add specificity.

No direct requirements for actors to support this yet, but the capability is defined.

- Traced Requirements:
  - 331: Consent Administration Service SHALL mark with profile assertions Consent resources that conform to the FASTConsent profile
  - 167: If a system accesses a Consent instance for determining whether information can be accessed, the Record Disclosure Operation SHALL be used

#### 34: UC: Sign and File Consent

- Flow: Basic success
- Systems Under Test:
  - Client: Provisional
  - Server: Provisional
- Test Details:

Use Case: Sign and File Consent

Actors: Consenter, Consent Client, CAS

Pre-condition: A consent form has been reviewed and completed (see use case Review Consent).

Narrative:

1. The consenter expresses their wish to sign and enact the consent [VERIFY: inspection]. The user experience provides a mechanism [VERIFY: inspection] to ensure the patient is making this decision in an informed way (and not by accident).
2. A proper user experience enables the consenter to sign the consent form [VERIFY: inspection].
3. Execute test case "Operation: File a Consent".
4. The consenter can see the change in the status of the consent to become active [VERIFY: inspection].
5. The consenter can review the finalized consent [VERIFY: inspection] and download a human-readable or print-friendly copy [VERIFY: inspection].

Post-condition:

- A signed consent form is retained for future review. [Q: Is this optional based on whether QR or DR were passed in?]
- A computable consent resource is extracted based on the finalized consent form and is stored in the consent store FHIR server.

- Included Test Cases:
  - 68: Operation: File a Consent
- Notes: Base happy path. This encompasses the whole use case workflow, including non-system-system behaviors.

#### 140: Validate FHIR resources

- Flow: Basic success
- Systems Under Test:
  - Client: Required
  - Server: Required
- Test Details:

Validate FHIR resources

This is a base test case that will be added to all others.

Actors: Any

Pre-condition: None

Narrative:

1. Test tool or manual evaluator captures any message under test.
2. Call the FHIR Validator on the top level resources in the message.

Post-condition:

- None

- Notes: Not sure if this is worth it to separate, but might be easier than saying "Call the FHIR Validator" in every test.

- Traced Requirements:
  - 477: StructureDefinition FASTSubscription
  - 595: StructureDefinition BackportSubscription
  - 597: StructureDefinition FASTConsent
  - 599: StructureDefinition FASTDocumentReference
  - 601: StructureDefinition FASTReference
  - 598: StructureDefinition FASTConsentAuditEvent
  - 596: SubscriptionTopic FASTConsentSubscriptionTopic