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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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

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

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

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.

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.

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.

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)

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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