Scalable Consent Management Testing Guide
0.1.0 - ci-build United States of America flag

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 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

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

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

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

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

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

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

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

  • 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?

  • 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

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

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

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

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

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

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

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

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

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

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

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

  • 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:
  • 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.

  • 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:
  • Notes: Base happy path. This encompasses the whole use case workflow, including non-system-system behaviors.

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