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

## TestPlan: Scalable Consent Management 0.1.0 Test Plan

Official URL: http://hl7.org/fhir/us/consent-management-tg/TestPlan/fhir-consent-management-0.1.0-test-plan | Version: 0.1.0
Standards status: Trial-use | Maturity Level: 1 | Computable Name: fhir-consent-management-0.1.0-test-plan

The Scalable Consent Management Testing Guide defines the testing artifacts used to verify and validate implementations declaring conformance to and against the Scalable Consent Management Implementation Guide.

Contact: (HL7 International / Community Based Collaborative Care: http://www.hl7.org/Special/com...)

## Test Case

### Test Plan Dependency:

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: Client sends a conformant read to CAS using the known ID. This is unconstrained, e.g. the "_format" parameter may be present. Verify the request is valid according to the linked requirements. [No requirements yet, but something like this: CAS verifies the request is valid.] CAS returns a conformant response containing the resource. Verify the response is valid according to the linked requirements, including that the Consent declares and conforms to the FASTConsent profile. Post-condition: None

### Assertion

Type | Content | Result
Required Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

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: Client sends a conformant search request to CAS using some combination of the search criteria required to be supported. Verify the request is valid according to the linked requirements. [No requirements yet, but something like this: CAS verifies the request is valid.] CAS returns a conformant response containing the matching resource(s). Verify the response is valid according to the linked requirements. Verify that at least one Consent resource is returned, and that each returned Consent declares and conforms to the FASTConsent profile. Post-condition: None

### Assertion

Type | Content | Result
Required Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Conditional Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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: Client sends a conformant read to CAS using the known ID. This is unconstrained, e.g. the "_format" parameter may be present. Verify the request is valid according to the linked requirements. [No requirements yet, but something like this: CAS verifies the request is valid.] CAS returns a conformant response containing the resource. Verify the response is valid according to the linked requirements, including that the AuditEvent declares and conforms to the FASTConsentAuditEvent profile. Post-condition: None

### Assertion

Type | Content | Result
Required Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

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: Client sends a conformant search request to CAS using some combination of the search criteria required to be supported. Verify the request is valid according to the linked requirements. [No requirements yet, but something like this: CAS verifies the request is valid.] CAS returns a conformant response containing the matching resource(s). Verify the response is valid according to the linked requirements. Verify that at least one AuditEvent resource is returned, and that each returned AuditEvent declares and conforms to the FASTConsentAuditEvent profile. Post-condition: None

### Assertion

Type | Content | Result
Required Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Conditional Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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: Client sends a conformant read to CAS using the known ID. This is unconstrained, e.g. the "_format" parameter may be present. Verify the request is valid according to the linked requirements. [No requirements yet, but something like this: CAS verifies the request is valid.] CAS returns a conformant response containing the resource. 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

### Assertion

Type | Content | Result
Required Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

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: Optional: Consent Client discovers subscription support at the CAS. Execute test case "Obtain server CapabilityStatement". Client POSTs a conformant Subscription to the CAS. [note no requirement for it to be FASTSubscription] Verify the request is valid according to the linked requirements. CAS verifies the request is valid. CAS returns a conformant response indicating the new Subscription location and optionally the resource in the body. Verify the response is valid according to the linked requirements. 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". Optional: Consent Client GETs the new Subscription to confirm it is active. Execute test case "Read a Subscription". 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.

### Assertion

Type | Content | Result
Required Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Conditional Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

Error: Create a Subscription - rest-hook - unsupported backport-channel-type Actors: Consent Client, CAS Pre-condition: None Narrative: Consent Client POSTs a Subscription to the CAS using the backport-channel-type extension with a nonsense value. CAS returns a conformant response indicating the Subscription request was rejected. Verify the response is valid according to the linked requirements. Post-condition: The Subscription has not been created at the CAS.

### Assertion

Type | Content | Result
Required Error | ?? | ??

## Test Case

### Test Plan Dependency:

Error: Create a Subscription - rest-hook - unsupported filter Actors: Consent Client, CAS Pre-condition: None Narrative: Consent Client POSTs a Subscription to the CAS using a filter with a nonsense value. CAS returns a conformant response indicating the Subscription request was rejected. Verify the response is valid according to the linked requirements. Post-condition: The Subscription has not been created at the CAS.

### Assertion

Type | Content | Result
Required Error | ?? | ??

## Test Case

### Test Plan Dependency:

Error: Create a Subscription - rest-hook - unsupported content level Actors: Consent Client, CAS Pre-condition: None Narrative: Consent Client POSTs a Subscription to the CAS using a content level the server does not support. CAS returns a conformant response indicating the Subscription request was rejected. Verify the response is valid according to the linked requirements. Post-condition: The Subscription has not been created at the CAS.

### Assertion

Type | Content | Result
Conditional Error | ?? | ??

## Test Case

### Test Plan Dependency:

Error: Create a Subscription - rest-hook - unsupported topic Actors: Consent Client, CAS Pre-condition: None Narrative: Consent Client POSTs a Subscription to the CAS using a nonsense topic. CAS returns a conformant response indicating the Subscription request was rejected. Verify the response is valid according to the linked requirements. Post-condition: The Subscription has not been created at the CAS.

### Assertion

Type | Content | Result
Required Error | ?? | ??

## Test Case

### Test Plan Dependency:

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: Client PUTs an updated, conformant Subscription to the CAS. [note no requirement for it to be FASTSubscription] Verify the request is valid according to the linked requirements. CAS verifies the request is valid. CAS returns a conformant response indicating the new Subscription location and optionally the resource in the body. Verify the response is valid according to the linked requirements. 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". Optional: Consent Client GETs the new Subscription to confirm it is active. Execute test case "Read a Subscription". 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.

### Assertion

Type | Content | Result
Required Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Conditional Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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: An actor performs an action at the CAS that should trigger a notification for this Subscription. CAS POSTs a conformant R4 Topic-Based Subscription Notification Bundle to the Consent Client's Notification Endpoint. Verify the notification is valid according to the linked requirements. The Consent Client verifies the notification and returns a valid 200 response. Verify the response. Optional: Consent Client GETs a new or modified Consent. Execute test case "Read a Consent". Post-condition: None

### Assertion

Type | Content | Result
Required Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

Operation: Get Subscription Status Actors: Consent Client, CAS Pre-condition: None Narrative: Client POSTs to CAS: [base]/Subscription/$status. Verify input parameters are valid according to linked requirements. CAS returns a response. Verify response is valid according to linked requirements. Post-condition: None

### Assertion

Type | Content | Result
Conditional Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

Operation: File a Consent Actors: Consent Client, CAS Pre-condition: None Narrative: Client POSTs to CAS: [base]/Consent/$fileConsent [unconstrained, e.g. the "document" parameter may be either flavor]. Verify input parameters are valid according to linked requirements. [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.] CAS returns a response. 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.]

### Assertion

Type | Content | Result
Required Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

Operation: Revoke a Consent Actors: Consent Client, CAS Pre-condition: None Narrative: Client POSTs to CAS: [base]/Consent/$revokeConsent [unconstrained, e.g. the "document" parameter may be either flavor]. Verify input parameters are valid according to linked requirements. [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.] CAS returns a response. 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.]

### Assertion

Type | Content | Result
Required Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

Operation: Record a Disclosure Actors: Consent Client, CAS Pre-condition: None Narrative: Client POSTs to CAS: [base]/AuditEvent/$recordDisclosure [unconstrained]. Verify input parameters are valid according to linked requirements. [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.] CAS returns a response. 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.]

### Assertion

Type | Content | Result
Required Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

Obtain server CapabilityStatement Actors: Consent client, CAS Pre-condition: None Narrative: Client sends a metadata request to the CAS, requesting the FHIR 4.0 CS by using the fhirVersion Accept header. Verify the request is valid according to the linked requirements. [No requirements yet, but something like this: CAS verifies the request is valid.] CAS returns a conformant response containing the system CapabilityStatement. Verify the response is valid according to the linked requirements. Verify the CapabilityStatement includes the normative aspects defined in the ConsentAdministrativeServer CapabilityStatement. Additional aspects are permitted but will not be evaluated. Post-condition: None

### Assertion

Type | Content | Result
Required Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Required Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

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: Client sends a metadata request to the CAS. [unconstrained; may or may not use the fhirVersion Accept header] Verify the request is valid according to the linked requirements. [No requirements yet, but something like this: CAS verifies the request is valid.] CAS returns a conformant response containing the system CapabilityStatement. Verify the response is valid according to the linked requirements. 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.

### Assertion

Type | Content | Result
Provisional Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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: Client sends a metadata request to the CAS without the fhirVersion Accept header. Verify the request is valid according to the linked requirements. CAS returns a conformant response containing an STU3 system CapabilityStatement. 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)

### Assertion

Type | Content | Result
Conditional Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

Test client CapabilityStatement Actors: Consent client Pre-condition: None Narrative: Obtain the client CapabilityStatement. Verify the CapabilityStatement includes the normative aspects defined in the ConsentClient CapabilityStatement. Additional aspects are permitted but will not be evaluated. Post-condition: None

### Assertion

Type | Content | Result
Conditional Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Conditional Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Conditional Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

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: Execute test case "Create a Subscription - rest-hook". 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. Execute test case "Notify for a Subscription - rest-hook". The trigger is step 2 above. Additionally verify the notification as "event-notification". Client DELETEs the FASTSubscription at the CAS. The CAS deletes the Subscription. Verify the response is valid according to the linked requirements. 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. 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.

### Assertion

Type | Content | Result
Required Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Conditional Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Conditional Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Conditional Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Conditional Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Conditional Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Conditional Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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.

### Assertion

Type | Content | Result
Conditional Alternate success | ?? | ??

## Test Case

### Test Plan Dependency:

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: 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. Data Holder determines a Consent managed at the CAS affects this disclosure decision. 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. 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. Data Holder discloses the PHI. This is the completion of whatever was started in step 1, e.g. a GET response. Verify information was disclosed. 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.

### Assertion

Type | Content | Result
Required Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

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: 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). A proper user experience enables the consenter to sign the consent form [VERIFY: inspection]. Execute test case "Operation: File a Consent". The consenter can see the change in the status of the consent to become active [VERIFY: inspection]. 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.

### Assertion

Type | Content | Result
Provisional Basic success | ?? | ??

## Test Case

### Test Plan Dependency:

Validate FHIR resources This is a base test case that will be added to all others. Actors: Any Pre-condition: None Narrative: Test tool or manual evaluator captures any message under test. Call the FHIR Validator on the top level resources in the message. Post-condition: None

### Assertion

Type | Content | Result
Required Basic success | ?? | ??