Generated Narrative: TestPlan fhir-consent-management-1.0.0-ballot-test-plan Contact: (HL7 International / Community Based Collaborative Care: http://www.hl7.org/Special/com...) Test Case Test Plan Dependency: Read a Consent Test a client and server to verify support for the Consent read interaction and the return of a valid Consent resource conforming to the FASTConsent profile. This scenario is generic and can be used with any FHIR format and query parameters. Actors: Consent Client, CAS Pre-condition: A Consent conforming to the FASTConsent profile exists at the CAS, and its ID is known. Narrative: Client sends a conformant read to CAS using the known ID. This is unconstrained, e.g. the "_format" parameter may be present. Verify the request is valid according to the linked requirements. [No requirements yet, but something like this: CAS verifies the request is valid.] CAS returns a conformant response containing the resource. Verify the response is valid according to the linked requirements, including that the Consent declares and conforms to the FASTConsent profile. Post-condition: None Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/01-Read-Simple-Search-All-SUT&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Basic success ?? ?? Test Case Test Plan Dependency: Search for a Consent Test a client and server to verify support for the Consent search interaction and the return of at least one valid Consent resource conforming to the FASTConsent profile. This scenario is generic and can be used with any FHIR format and query parameters. Actors: Consent Client, CAS Pre-condition: At least one Consent conforming to the FASTConsent profile exists at the CAS, and details about it sufficient to search are known. Narrative: Client sends a conformant search request to CAS using some combination of the search criteria required to be supported. Verify the request is valid according to the linked requirements. [No requirements yet, but something like this: CAS verifies the request is valid.] CAS returns a conformant response containing the matching resource(s). Verify the response is valid according to the linked requirements. Verify that at least one Consent resource is returned, and that each returned Consent declares and conforms to the FASTConsent profile. Post-condition: None Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/01-Read-Simple-Search-All-SUT&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Basic success ?? ?? Test Case Test Plan Dependency: Search for Consent by FASTConsentController - JSON This test case extends test case "Search for a Consent". Pre-condition: FASTConsentController details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the FASTConsentController criteria and requests JSON. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as JSON. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-JSON&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by FASTConsentController - XML This test case extends test case "Search for a Consent". Pre-condition: FASTConsentController details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the FASTConsentController criteria and requests XML. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as XML. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-XML&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by date - JSON This test case extends test case "Search for a Consent". Pre-condition: date details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the date criteria and requests JSON. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as JSON. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-JSON&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by date - XML This test case extends test case "Search for a Consent". Pre-condition: date details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the date criteria and requests XML. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as XML. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-XML&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by FASTConsentGrantee - JSON This test case extends test case "Search for a Consent". Pre-condition: FASTConsentGrantee details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the FASTConsentGrantee criteria and requests JSON. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as JSON. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-JSON&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by FASTConsentGrantee - XML This test case extends test case "Search for a Consent". Pre-condition: FASTConsentGrantee details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the FASTConsentGrantee criteria and requests XML. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as XML. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-XML&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by FASTConsentManager - JSON This test case extends test case "Search for a Consent". Pre-condition: FASTConsentManager details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the FASTConsentManager criteria and requests JSON. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as JSON. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-JSON&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by FASTConsentManager - XML This test case extends test case "Search for a Consent". Pre-condition: FASTConsentManager details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the FASTConsentManager criteria and requests XML. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as XML. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-XML&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by FASTConsentOrganizationId - JSON This test case extends test case "Search for a Consent". Pre-condition: FASTConsentOrganizationId details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the FASTConsentOrganizationId criteria and requests JSON. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as JSON. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-JSON&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by FASTConsentOrganizationId - XML This test case extends test case "Search for a Consent". Pre-condition: FASTConsentOrganizationId details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the FASTConsentOrganizationId criteria and requests XML. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as XML. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-XML&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by patient - JSON This test case extends test case "Search for a Consent". Pre-condition: patient details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the patient criteria and requests JSON. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as JSON. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-JSON&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by patient - XML This test case extends test case "Search for a Consent". Pre-condition: patient details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the patient criteria and requests XML. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as XML. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-XML&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by FASTConsentPatientId - JSON This test case extends test case "Search for a Consent". Pre-condition: FASTConsentPatientId details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the FASTConsentPatientId criteria and requests JSON. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as JSON. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-JSON&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by FASTConsentPatientId - XML This test case extends test case "Search for a Consent". Pre-condition: FASTConsentPatientId details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the FASTConsentPatientId criteria and requests XML. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as XML. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-XML&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by scope - JSON This test case extends test case "Search for a Consent". Pre-condition: scope details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the scope criteria and requests JSON. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as JSON. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-JSON&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by scope - XML This test case extends test case "Search for a Consent". Pre-condition: scope details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the scope criteria and requests XML. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as XML. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-XML&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by status - JSON This test case extends test case "Search for a Consent". Pre-condition: status details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the status criteria and requests JSON. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as JSON. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-JSON&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by status - XML This test case extends test case "Search for a Consent". Pre-condition: status details are known by which at least one Consent would match and at least one Consent would not match at the CAS. In step 1, the client includes the status criteria and requests XML. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as XML. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-XML&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by FASTConsent profile - JSON This test case extends test case "Search for a Consent". Pre-condition: At least one Consent declaring the FASTConsent profile and at least one Consent not declaring it exist at the CAS. In step 1, the client includes the FASTConsent profile criteria and requests JSON. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as JSON. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-JSON&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Conditional Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by FASTConsent profile - XML This test case extends test case "Search for a Consent". Pre-condition: At least one Consent declaring the FASTConsent profile and at least one Consent not declaring it exist at the CAS. In step 1, the client includes the FASTConsent profile criteria and requests XML. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as XML. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-XML&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by _id - JSON This test case extends test case "Search for a Consent". Pre-condition: id of a Consent is known. In step 1, the client includes the id and requests JSON. In step 6, verify that only the matching Consent resource is returned. In all steps, evaluate FHIR content as JSON. Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by _id - XML This test case extends test case "Search for a Consent". Pre-condition: id of a Consent is known. In step 1, the client includes the id and requests XML. In step 6, verify that only the matching Consent resource is returned. In all steps, evaluate FHIR content as XML. Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by identifier - JSON This test case extends test case "Search for a Consent". Pre-condition: identifier of a Consent is known. In step 1, the client includes the identifier and requests JSON. In step 6, verify that only the matching Consent resource is returned. In all steps, evaluate FHIR content as JSON. Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by identifier - XML This test case extends test case "Search for a Consent". Pre-condition: identifier of a Consent is known. In step 1, the client includes the identifier and requests XML. In step 6, verify that only the matching Consent resource is returned. In all steps, evaluate FHIR content as XML. Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by patient and status - JSON This test case extends test case "Search for a Consent". Pre-condition: patient and 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 patient and status criteria and requests JSON. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as JSON. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-JSON&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by patient and status - XML This test case extends test case "Search for a Consent". Pre-condition: patient and 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 patient and status criteria and requests XML. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as XML. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-XML&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by patient and date - JSON This test case extends test case "Search for a Consent". Pre-condition: patient and 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 patient and date criteria and requests JSON. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as JSON. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-JSON&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for Consent by patient and date - JSON This test case extends test case "Search for a Consent". Pre-condition: patient and 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 patient and date criteria and requests JSON. In step 6, verify that only matching Consent resources are returned. In all steps, evaluate FHIR content as JSON. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/02-Consent-Search-All-SUT-XML&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Read an AuditEvent Test a client and server to verify support for the AuditEvent read interaction and the return of a valid AuditEvent resource conforming to the FASTConsentAuditEvent profile. This scenario is generic and can be used with any FHIR format and query parameters. Actors: Consent Client, CAS Pre-condition: An AuditEvent conforming to the FASTConsentAuditEvent profile exists at the CAS, and its ID is known. Narrative: Client sends a conformant read to CAS using the known ID. This is unconstrained, e.g. the "_format" parameter may be present. Verify the request is valid according to the linked requirements. [No requirements yet, but something like this: CAS verifies the request is valid.] CAS returns a conformant response containing the resource. Verify the response is valid according to the linked requirements, including that the AuditEvent declares and conforms to the FASTConsentAuditEvent profile. Post-condition: None Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/01-Read-Simple-Search-All-SUT&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Basic success ?? ?? Test Case Test Plan Dependency: Search for an AuditEvent Test a client and server to verify support for the AuditEvent search interaction and the return of at least one valid AuditEvent resource conforming to the FASTConsentAuditEvent profile. This scenario is generic and can be used with any FHIR format and query parameters. Actors: Consent Client, CAS Pre-condition: At least one AuditEvent conforming to the FASTConsentAuditEvent profile exists at the CAS, and details about it sufficient to search are known. Narrative: Client sends a conformant search request to CAS using some combination of the search criteria required to be supported. Verify the request is valid according to the linked requirements. [No requirements yet, but something like this: CAS verifies the request is valid.] CAS returns a conformant response containing the matching resource(s). Verify the response is valid according to the linked requirements. Verify that at least one AuditEvent resource is returned, and that each returned AuditEvent declares and conforms to the FASTConsentAuditEvent profile. Post-condition: None Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/01-Read-Simple-Search-All-SUT&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Basic success ?? ?? Test Case Test Plan Dependency: Search for AuditEvent by FASTAuditEventConsent - JSON This test case extends test case "Search for an AuditEvent". Pre-condition: FASTAuditEventConsent details are known by which at least one AuditEvent would match and at least one AuditEvent would not match at the CAS. In step 1, the client includes the FASTAuditEventConsent criteria and requests JSON. In step 6, verify that only matching AuditEvent resources are returned. In all steps, evaluate FHIR content as JSON. Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for AuditEvent by FASTAuditEventConsent - XML This test case extends test case "Search for an AuditEvent". Pre-condition: FASTAuditEventConsent details are known by which at least one AuditEvent would match and at least one AuditEvent would not match at the CAS. In step 1, the client includes the FASTAuditEventConsent criteria and requests XML. In step 6, verify that only matching AuditEvent resources are returned. In all steps, evaluate FHIR content as XML. Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for AuditEvent by patient - JSON This test case extends test case "Search for an AuditEvent". Pre-condition: patient details are known by which at least one AuditEvent would match and at least one AuditEvent would not match at the CAS. In step 1, the client includes the patient criteria and requests JSON. In step 6, verify that only matching AuditEvent resources are returned. In all steps, evaluate FHIR content as JSON. Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for AuditEvent by patient - XML This test case extends test case "Search for an AuditEvent". Pre-condition: patient details are known by which at least one AuditEvent would match and at least one AuditEvent would not match at the CAS. In step 1, the client includes the patient criteria and requests XML. In step 6, verify that only matching AuditEvent resources are returned. In all steps, evaluate FHIR content as XML. Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Search for AuditEvent by FASTConsentAuditEvent profile - JSON This test case extends test case "Search for an AuditEvent". Pre-condition: At least one AuditEvent declaring the FASTConsentAuditEvent profile and at least one AuditEvent not declaring it exist at the CAS. In step 1, the client includes the FASTConsentAuditEvent profile criteria and requests JSON. In step 6, verify that only matching AuditEvent resources are returned. In all steps, evaluate FHIR content as JSON. Assertion Type Content Result Conditional Alternate success ?? ?? Test Case Test Plan Dependency: Search for AuditEvent by FASTConsentAuditEvent profile - XML This test case extends test case "Search for an AuditEvent". Pre-condition: At least one AuditEvent declaring the FASTConsentAuditEvent profile and at least one AuditEvent not declaring it exist at the CAS. In step 1, the client includes the FASTConsentAuditEvent profile criteria and requests XML. In step 6, verify that only matching AuditEvent resources are returned. In all steps, evaluate FHIR content as XML. Assertion Type Content Result Required Alternate success ?? ?? Test Case Test Plan Dependency: Read a Subscription Test a client and server to verify support for the Subscription read interaction and the return of a valid Subscription resource conforming to the FASTSubscription profile. This scenario is generic and can be used with any FHIR format and query parameters. Actors: Consent Client, CAS Pre-condition: A Subscription conforming to the FASTSubscription profile exists at the CAS, and its ID is known. Narrative: Client sends a conformant read to CAS using the known ID. This is unconstrained, e.g. the "_format" parameter may be present. Verify the request is valid according to the linked requirements. [No requirements yet, but something like this: CAS verifies the request is valid.] CAS returns a conformant response containing the resource. Verify the response is valid according to the linked requirements, including that the Consent declares and conforms to the FASTSubscription profile. Post-condition: None Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/01-Read-Simple-Search-All-SUT&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Basic success ?? ?? Test Case Test Plan Dependency: Operation: File a Consent Actors: Consent Client, CAS Pre-condition: None Narrative: Client POSTs to CAS: [base]/Consent/$fileConsent [unconstrained, e.g. the "document" parameter may be either flavor]. Verify input parameters are valid according to linked requirements. Tester: Since the $fileConsent response does not identify the new Consent, retain the identifier from the $fileConsent request. [No requirements yet, but something like this: CAS verifies inputs, generates and persists the Consent and related resources. CAS may retain external references (e.g. to Patient), or replace with references to new or matched existing resources.] CAS returns a response. Verify response is valid according to linked requirements. Search for the Consent by the identifier saved from the $fileConsent request. Verify the Consent is found and has status "active". Post-condition: [No requirements yet, but something like this: The Consent and related resources are persisted and available at the CAS.] Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/03-Operations-All-SUT&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Basic success ?? ?? Test Case Test Plan Dependency: Operation: Revoke a Consent Actors: Consent Client, CAS Pre-condition: None Narrative: Client POSTs to CAS: [base]/Consent/$revokeConsent [unconstrained, e.g. the "document" parameter may be either flavor]. Verify input parameters are valid according to linked requirements. Tester: Since the $revokeConsent response does not identify the revoked Consent, retain the identifier from the $revokeConsent request. [No requirements yet, but something like this: CAS verifies inputs, persists the revoked Consent and related resources. CAS may retain external references (e.g. to Patient), or replace with references to new or matched existing resources.] CAS returns a response. Verify response is valid according to linked requirements. Search for the Consent by the identifier saved from the $revokeConsent request. Verify the Consent is found and has status "inactive". Post-condition: [No requirements yet, but something like this: The revoked Consent and related resources are persisted and available at the CAS.] Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/03-Operations-All-SUT&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Basic success ?? ?? Test Case Test Plan Dependency: Operation: Record a Disclosure Actors: Consent Client, CAS Pre-condition: None Narrative: Client POSTs to CAS: [base]/AuditEvent/$recordDisclosure [unconstrained]. Verify input parameters are valid according to linked requirements. [No requirements yet, but something like this: CAS verifies inputs, generates and persists the AuditEvent and related resources. CAS may retain external references (e.g. to Patient), or replace with references to new or matched existing resources.] CAS returns a response. Verify response is valid according to linked requirements. Post-condition: [No requirements yet, but something like this: The AuditEvent and related resources are persisted and available at the CAS.] Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/03-Operations-All-SUT&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Basic success ?? ?? Test Case Test Plan Dependency: Operation: Get Subscription Status Actors: Consent Client, CAS Pre-condition: A Subscription exists on the CAS. Narrative: Client POSTs to CAS: [base]/Subscription/[id]/$status. Verify input parameters are valid according to linked requirements. CAS returns a response. Verify response is valid according to linked requirements. Post-condition: None Test Run 1 Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/04-Basic-REST-hook-Subs-All-SUT&activeOnly=false&contentEntry=TEST_SCRIPTS Test Run 2 Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/04-Basic-REST-hook-Subs-All-SUT&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Conditional Basic success ?? ?? Test Case Test Plan Dependency: Obtain server CapabilityStatement Actors: Consent client, CAS Pre-condition: None Narrative: Client sends a metadata request to the CAS, requesting the FHIR 4.0 CS by using the fhirVersion Accept header. Verify the request is valid according to the linked requirements. [No requirements yet, but something like this: CAS verifies the request is valid.] CAS returns a conformant response containing the system CapabilityStatement. Verify the response is valid according to the linked requirements. Verify the CapabilityStatement includes the normative aspects defined in the ConsentAdministrativeServer CapabilityStatement. Additional aspects are permitted but will not be evaluated. Post-condition: None Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/FHIR4-0-1-Consent/Consent-1-0-0-ballot/00-Capabilities&activeOnly=true&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Basic success ?? ?? Test Case Test Plan Dependency: Obtain server CapabilityStatement - JSON This test case extends test case "Obtain server CapabilityStatement". In step 1, the client requests JSON. In step 5, verify the CapabilityStatement is JSON. In all steps, evaluate FHIR content as JSON. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/FHIR4-0-1-Consent/Consent-1-0-0-ballot/00-Capabilities&activeOnly=true&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Basic success ?? ?? Test Case Test Plan Dependency: Obtain server CapabilityStatement - XML This test case extends test case "Obtain server CapabilityStatement". In step 1, the client requests XML. In step 5, verify the CapabilityStatement is XML. In all steps, evaluate FHIR content as XML. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/FHIR4-0-1-Consent/Consent-1-0-0-ballot/00-Capabilities&activeOnly=true&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Basic success ?? ?? Test Case Test Plan Dependency: Obtain and handle conformant variations of server CapabilityStatement This tests the ability of a client to handle legal variants of CSs. Actors: Consent Client, Simulated CAS Pre-condition: None Narrative: Client sends a metadata request to the CAS. [unconstrained; may or may not use the fhirVersion Accept header] Verify the request is valid according to the linked requirements. [No requirements yet, but something like this: CAS verifies the request is valid.] CAS returns a conformant response containing the system CapabilityStatement. Verify the response is valid according to the linked requirements. Verify the CapabilityStatement includes the normative aspects defined in the ConsentAdministrativeServer CapabilityStatement. Additional aspects are permitted but will not be evaluated. Post-condition: The client should be able to communicate with this server per the workflows in this IG. Assertion Type Content Result Provisional Alternate success ?? ?? Test Case Test Plan Dependency: Obtain and handle STU3 version server CapabilityStatement This tests the ability of a client to handle an STU3 CS. Actors: Consent Client, Simulated CAS Pre-condition: None Narrative: Client sends a metadata request to the CAS without the fhirVersion Accept header. Verify the request is valid according to the linked requirements. CAS returns a conformant response containing an STU3 system CapabilityStatement. Verify the client detects the version mismatch and resolves somehow, e.g. notifies the user, retries the request including the fhirVersion Accept header, etc. Post-condition: None (yet) Assertion Type Content Result Conditional Alternate success ?? ?? Test Case Test Plan Dependency: Test client CapabilityStatement Actors: Consent client Pre-condition: None Narrative: Obtain the client CapabilityStatement. Verify the CapabilityStatement includes the normative aspects defined in the ConsentClient CapabilityStatement. Additional aspects are permitted but will not be evaluated. Post-condition: None Assertion Type Content Result Conditional Basic success ?? ?? Test Case Test Plan Dependency: Test client CapabilityStatement - JSON This test case extends test case "Test client CapabilityStatement". In step 1, obtain the JSON CapabilityStatement. In step 2, evaluate FHIR content as JSON. Assertion Type Content Result Conditional Basic success ?? ?? Test Case Test Plan Dependency: Test client CapabilityStatement - XML This test case extends test case "Test client CapabilityStatement". In step 1, obtain the XML CapabilityStatement. In step 2, evaluate FHIR content as XML. Assertion Type Content Result Conditional Basic success ?? ?? Test Case Test Plan Dependency: Workflow: Utilize Consent For Disclosure This is a wide-open workflow that can be used as the base for many variations. Actors: Data Consumer, Data Holder with Consent Client, CAS Pre-condition: Data holder has PHI for a patient. CAS has a valid, active Consent associated with that patient. [The rest is undefined: Data Holder may already have the Consent and know it is managed at this particular CAS, Data Holder may not know about the Consent or the CAS and discover it at the time the disclosure is requested.] Narrative: Data Holder is triggered to disclose PHI for the patient to the Data Consumer. This is unconstrained; it could be a request from the Consumer to the Holder, a push, etc. Data Holder determines a Consent managed at the CAS affects this disclosure decision. Optional: If needed, the Data Holder's Consent Client obtains the Consent from the CAS. This is unconstrained; it could be a read, search, etc. Execute the appropriate test cases. Data Holder uses the Consent to make a determination to disclose. This is unconstrained; the determination could be based on multiple factors of which the Consent is only one part. Data Holder discloses the PHI. This is the completion of whatever was started in step 1, e.g. a GET response. Verify information was disclosed. Data Holder's Consent Client records a disclosure at the CAS. Execute test case "Operation: Record a Disclosure". Post-condition: The disclosure AuditEvent exists at the CAS. Assertion Type Content Result Required Basic success ?? ?? Test Case Test Plan Dependency: Create a subscription - rest-hook This is a wide-open test case that can be used as the base for many variations. Actors: Consent Client, CAS, Notification Endpoint Pre-condition: Consent Client has prepared its Notification Endpoint to receive notifications. Narrative: Client POSTs a conformant Subscription to the CAS. [note no requirement for it to be FASTSubscription] Verify the request is valid according to the linked requirements. CAS verifies the request is valid. CAS returns a conformant response indicating the new Subscription location and optionally the resource in the body. Verify the response is valid according to the linked requirements. Optional: CAS sends a handshake. Execute test case "Notify for a Subscription - rest-hook". The trigger in step 1 is the creation of the Subscription. Verify the notification as "handshake". Optional: Consent Client GETs the new Subscription to confirm it is active. Execute test case "Read a Subscription". Optional: Consent Client executes $status against the new Subscription to confirm it is active. Execute test case "Operation: Get Subscription Status". Post-condition: The new Subscription exists at the CAS. Test Run Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/04-Basic-REST-hook-Subs-All-SUT&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Basic success ?? ?? Test Case Test Plan Dependency: Create a subscription - rest-hook PUT This test case extends test case "Create a subscription - rest-hook". In step 1, Consent Client PUTs a conformant Subscription to the CAS. In step 2, verify the resource id passed in was used. Assertion Type Content Result Conditional Alternate success ?? ?? Test Case Test Plan Dependency: Error: Create a Subscription - rest-hook - unsupported backport-channel-type Actors: Consent Client, CAS Pre-condition: None Narrative: Consent Client POSTs a Subscription to the CAS using the backport-channel-type extension with a nonsense value. CAS returns a conformant response indicating the Subscription request was rejected. Verify the response is valid according to the linked requirements. Post-condition: The Subscription has not been created at the CAS. Assertion Type Content Result Required Error ?? ?? Test Case Test Plan Dependency: Error: Create a Subscription - rest-hook - unsupported filter Actors: Consent Client, CAS Pre-condition: None Narrative: Consent Client POSTs a Subscription to the CAS using a filter with a nonsense value. CAS returns a conformant response indicating the Subscription request was rejected. Verify the response is valid according to the linked requirements. Post-condition: The Subscription has not been created at the CAS. Assertion Type Content Result Required Error ?? ?? Test Case Test Plan Dependency: Error: Create a Subscription - rest-hook - unsupported content level Actors: Consent Client, CAS Pre-condition: None Narrative: Consent Client POSTs a Subscription to the CAS using a content level the server does not support. CAS returns a conformant response indicating the Subscription request was rejected. Verify the response is valid according to the linked requirements. Post-condition: The Subscription has not been created at the CAS. Assertion Type Content Result Conditional Error ?? ?? Test Case Test Plan Dependency: Error: Create a Subscription - rest-hook - unsupported topic Actors: Consent Client, CAS Pre-condition: None Narrative: Consent Client POSTs a Subscription to the CAS using a nonsense topic. CAS returns a conformant response indicating the Subscription request was rejected. Verify the response is valid according to the linked requirements. Post-condition: The Subscription has not been created at the CAS. Assertion Type Content Result Required Error ?? ?? Test Case Test Plan Dependency: Update a Subscription - rest-hook This is a wide-open test case that can be used as the base for many variations. Actors: Consent Client, CAS, Notification Endpoint Pre-condition: Consent Client has an existing Subscription at the CAS. Narrative: Client PUTs an updated, conformant Subscription to the CAS. [note no requirement for it to be FASTSubscription] Verify the request is valid according to the linked requirements. CAS verifies the request is valid. CAS returns a conformant response indicating the new Subscription location and optionally the resource in the body. Verify the response is valid according to the linked requirements. Optional: CAS sends a handshake. Execute test case "Notify for a Subscription - rest-hook channel". The trigger in step 1 is the creation of the Subscription. Verify the notification as "handshake". Optional: Consent Client GETs the new Subscription to confirm it is active. Execute test case "Read a Subscription". Optional: Consent Client executes $status against the new Subscription to confirm it is active. Execute test case "Operation: Get Subscription Status". Post-condition: The updated Subscription exists at the CAS. Assertion Type Content Result Required Basic success ?? ?? Test Case Test Plan Dependency: Update a Subscription - rest-hook PATCH This test case extends test case "Update a Subscription - rest-hook". In step 1, Consent Client PATCHs an updated, conformant Subscription to the CAS. At the end of the test case, verify the resource was updated appropriately. Assertion Type Content Result Conditional Alternate success ?? ?? Test Case Test Plan Dependency: Notify for a Subscription - rest-hook This is a wide-open test case that can be used as the base for many variations. Each variation needs to specify what the trigger in step 1 is. Actors: Consent Client, CAS, Notification Endpoint Pre-condition: Consent Client has successfully made a Subscription at the CAS, with the rest-hook channel type. Narrative: An actor performs an action at the CAS that should trigger a notification for this Subscription. CAS POSTs a conformant R4 Topic-Based Subscription Notification Bundle to the Consent Client's Notification Endpoint. Verify the notification is valid according to the linked requirements. The Consent Client verifies the notification and returns a valid 200 response. Verify the response. Post-condition: None Test Run 1 Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/04-Basic-REST-hook-Subs-All-SUT&activeOnly=false&contentEntry=TEST_SCRIPTS Test Run 2 Language Source[x] FHIR TestScript - Touchstone profile https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/FAST/Sandbox-FASTDevelopers/Joe-Lamy/FHIR4-0-1-Consent/Consent-1-0-0-ballot/04-Basic-REST-hook-Subs-All-SUT&activeOnly=false&contentEntry=TEST_SCRIPTS Assertion Type Content Result Required Basic success ?? ?? Test Case Test Plan Dependency: Workflow: Consent subscription and notification This is a wide-open workflow that can be used as the base for many variations. Actors: Consent Client, CAS, Notification Endpoint, Tester Pre-condition: CAS has advertised its support for subscriptions in its CapabilityStatement. Consent Client has prepared its Notification Endpoint to receive notifications. There are no current subscriptions between this CAS and this Endpoint. Narrative: Execute test case "Create a Subscription - rest-hook". Tester performs an action at the CAS that should trigger a notification for this Subscription. This may be a local action or an API action. Execute test case "Notify for a Subscription - rest-hook". The trigger is step 2 above. Additionally verify the notification as "event-notification". Optional: Client GETs the new or modified Consent. Execute test case "Read a Consent". Client DELETEs the FASTSubscription at the CAS. The CAS deletes the Subscription. Verify the response is valid according to the linked requirements. Tester performs an action at the CAS that should trigger a notification for the previous Subscription. This may be a local action or an API action. Verify the CAS does not POST an "event-notification" R4 Topic-Based Subscription Notification Bundle to the Endpoint. Post-condition: Any Subscriptions created at the CAS have been deleted. Other changes at the CAS (new Consents, etc.) may or may not have been deleted. Assertion Type Content Result Required Basic success ?? ?? Test Case Test Plan Dependency: Workflow: Consent subscription and notification - FASTConsentPatientId This test case extends test case "Workflow: Consent subscription and notification". Test data: Data for 2 conformant FASTConsents for an existing patient known at the CAS. No existing Consents for this patient at the CAS. Each Consent differs by where it identifies the patient: patient.identifier element or patient.extension additionalIdentifier. In step 1, Consent Client creates a Subscription at the CAS filtering only on FASTConsentPatientId, for the known patient in the test data. Repeat steps 2-3 as follows: In step 2, Tester creates each Consent at the CAS using this test data. In step 3, verify notification for each per this subscription and trigger. In step 2, Tester updates each Consent at the CAS. In step 3, verify notification for each per this subscription and trigger. In step 2, Tester deletes the Consent at the CAS. In step 3, verify notification for each per this subscription and trigger. Continue with steps 4-7. Repeat steps 8-9 as follows: In step 8, Tester creates each Consent at the CAS using this test data. In step 8, Tester updates each Consent at the CAS. In step 8, Tester deletes each Consent at the CAS. Additional Post-condition: Any Consents created at the CAS have been deleted. Assertion Type Content Result Conditional Alternate success ?? ?? Test Case Test Plan Dependency: Workflow: Consent subscription and notification - FASTConsentOrganizationId This test case extends test case "Workflow: Consent subscription and notification". Test data: Data for 4 conformant FASTConsents for an existing organization known at the CAS. No existing Consents for this organization at the CAS. Each Consent differs by where it identifies the organization: the extensions grantee, manager, controller or the provision.actor.role.reference. In step 1, Consent Client creates a Subscription at the CAS filtering only on FASTConsentOrganizationId, for the known organization in the test data. Repeat steps 2-3 as follows: In step 2, Tester creates each Consent at the CAS using this test data. In step 3, verify notification for each per this subscription and trigger. In step 2, Tester updates each Consent at the CAS. In step 3, verify notification for each per this subscription and trigger. In step 2, Tester deletes the Consent at the CAS. In step 3, verify notification for each per this subscription and trigger. Continue with steps 4-7. Repeat steps 8-9 as follows: In step 8, Tester creates each Consent at the CAS using this test data. In step 8, Tester updates each Consent at the CAS. In step 8, Tester deletes each Consent at the CAS. Additional Post-condition: Any Consents created at the CAS have been deleted. Assertion Type Content Result Conditional Alternate success ?? ?? Test Case Test Plan Dependency: Workflow: Consent subscription and notification - actor This test case extends test case "Workflow: Consent subscription and notification". Test data: Data for a conformant FASTConsent for an existing Consent actor (Consent.provision.actor.reference - see the actor search parameter) known at the CAS. No existing Consents for this actor at the CAS. In step 1, Consent Client creates a Subscription at the CAS filtering only on actor, for the known actor in the test data. Repeat steps 2-3 as follows: In step 2, Tester creates the Consent at the CAS using this test data. In step 3, verify notification per this subscription and trigger. In step 2, Tester updates the Consent at the CAS. In step 3, verify notification per this subscription and trigger. In step 2, Tester deletes the Consent at the CAS. In step 3, verify notification per this subscription and trigger. Continue with steps 4-7. Repeat steps 8-9 as follows: In step 8, Tester creates each Consent at the CAS using this test data. In step 8, Tester updates each Consent at the CAS. In step 8, Tester deletes each Consent at the CAS. Additional Post-condition: Any Consents created at the CAS have been deleted. Assertion Type Content Result Conditional Alternate success ?? ?? Test Case Test Plan Dependency: Workflow: Consent subscription and notification - 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-7. Repeat steps 8-9 as follows: In step 8, Tester creates each Consent at the CAS using this test data. In step 8, Tester updates each Consent at the CAS. In step 8, Tester deletes each Consent at the CAS. Additional Post-condition: Any Consents created at the CAS have been deleted. Assertion Type Content Result Conditional Alternate success ?? ?? Test Case Test Plan Dependency: Workflow: Consent subscription and notification - 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-7. Repeat steps 8-9 as follows: In step 8, Tester creates each Consent at the CAS using this test data. In step 8, Tester updates each Consent at the CAS. In step 8, Tester deletes each Consent at the CAS. Additional Post-condition: Any Consents created at the CAS have been deleted. Assertion Type Content Result Conditional Alternate success ?? ?? Test Case Test Plan Dependency: Workflow: Consent subscription and notification - 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-7. Repeat steps 8-9 as follows: In step 8, Tester creates each Consent at the CAS using this test data. In step 8, Tester updates each Consent at the CAS. In step 8, Tester deletes each Consent at the CAS. Additional Post-condition: Any Consents created at the CAS have been deleted. Assertion Type Content Result Conditional Alternate success ?? ?? Test Case Test Plan Dependency: Workflow: Consent subscription and notification - full-resource payload This test case extends test case "Workflow: Consent subscription and notification". In step 1, Consent Client creates a Subscription at the CAS requesting full-resource payloads. After step 3, additionally verify the notification contains the full Consent resource(s). Continue through step 7. The test case ends - no additional steps are needed. Assertion Type Content Result Conditional Alternate success ?? ?? Test Case Test Plan Dependency: Workflow: Consent subscription and notification - id only payload This test case extends test case "Workflow: Consent subscription and notification". In step 1, Consent Client creates a Subscription at the CAS requesting full-resource payloads. After step 3, additionally verify the notification contains only the id of the Consent resource(s). Continue through step 7. The test case ends - no additional steps are needed. Assertion Type Content Result Conditional Alternate success ?? ?? Test Case Test Plan Dependency: Workflow: Consent subscription and notification - empty payload This test case extends test case "Workflow: Consent subscription and notification". In step 1, Consent Client creates a Subscription at the CAS requesting full-resource payloads. After step 3, additionally verify the notification is empty. Continue through step 7. The test case ends - no additional steps are needed. Assertion Type Content Result Conditional Alternate success ?? ?? Test Case Test Plan Dependency: Use Case: Sign and File Consent Actors: Consenter, Consent Client, CAS Pre-condition: A consent form has been reviewed and completed (see use case Review Consent). Narrative: The consenter expresses their wish to sign and enact the consent [VERIFY: inspection]. The user experience provides a mechanism [VERIFY: inspection] to ensure the patient is making this decision in an informed way (and not by accident). A proper user experience enables the consenter to sign the consent form [VERIFY: inspection]. Execute test case "Operation: File a Consent". The consenter can see the change in the status of the consent to become active [VERIFY: inspection]. The consenter can review the finalized consent [VERIFY: inspection] and download a human-readable or print-friendly copy [VERIFY: inspection]. Post-condition: A signed consent form is retained for future review. [Q: Is this optional based on whether QR or DR were passed in?] A computable consent resource is extracted based on the finalized consent form and is stored in the consent store FHIR server. Assertion Type Content Result Provisional Basic success ?? ?? Test Case Test Plan Dependency: Validate FHIR resources This is a base test case that will be added to all others. Actors: Any Pre-condition: None Narrative: Test tool or manual evaluator captures any message under test. Call the FHIR Validator on the top level resources in the message. Post-condition: None Assertion Type Content Result Required Basic success ?? ??
Scalable Consent Management 1.0.0-ballot Test Plan
HL7 International / Community Based Collaborative Care
The Scalable Consent Management Testing Guide defines the testing artifacts used to verify and validate implementations declaring conformance to and against the Scalable Consent Management Implementation Guide.
**Read a Consent** Test a client and server to verify support for the Consent read interaction and the return of a valid Consent resource conforming to the FASTConsent profile. This scenario is generic and can be used with any FHIR format and query parameters. **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](https://hl7.org/fhir/R4/http.html#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** Test a client and server to verify support for the Consent search interaction and the return of at least one valid Consent resource conforming to the FASTConsent profile. This scenario is generic and can be used with any FHIR format and query parameters. **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](https://hl7.org/fhir/R4/http.html#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.
**Search for Consent by \_id - JSON** This test case extends test case "Search for a Consent". **Pre-condition:** id of a Consent is known. - In step 1, the client includes the id and requests JSON. - In step 6, verify that only the matching Consent resource is returned. - In all steps, evaluate FHIR content as JSON.
**Search for Consent by \_id - XML** This test case extends test case "Search for a Consent". **Pre-condition:** id of a Consent is known. - In step 1, the client includes the id and requests XML. - In step 6, verify that only the matching Consent resource is returned. - In all steps, evaluate FHIR content as XML.
**Search for Consent by identifier - JSON** This test case extends test case "Search for a Consent". **Pre-condition:** identifier of a Consent is known. - In step 1, the client includes the identifier and requests JSON. - In step 6, verify that only the matching Consent resource is returned. - In all steps, evaluate FHIR content as JSON.
**Search for Consent by identifier - XML** This test case extends test case "Search for a Consent". **Pre-condition:** identifier of a Consent is known. - In step 1, the client includes the identifier and requests XML. - In step 6, verify that only the matching Consent resource is returned. - In all steps, evaluate FHIR content as XML.
**Search for Consent by patient and status - JSON** This test case extends test case "Search for a Consent". **Pre-condition:** patient and 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 patient and 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 patient and status - XML** This test case extends test case "Search for a Consent". **Pre-condition:** patient and 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 patient and 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 patient and date - JSON** This test case extends test case "Search for a Consent". **Pre-condition:** patient and 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 patient and date criteria and requests JSON. - In step 6, verify that only matching Consent resources are returned. - In all steps, evaluate FHIR content as JSON.
**Read an AuditEvent** Test a client and server to verify support for the AuditEvent read interaction and the return of a valid AuditEvent resource conforming to the FASTConsentAuditEvent profile. This scenario is generic and can be used with any FHIR format and query parameters. **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](https://hl7.org/fhir/R4/http.html#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** Test a client and server to verify support for the AuditEvent search interaction and the return of at least one valid AuditEvent resource conforming to the FASTConsentAuditEvent profile. This scenario is generic and can be used with any FHIR format and query parameters. **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](https://hl7.org/fhir/R4/http.html#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** Test a client and server to verify support for the Subscription read interaction and the return of a valid Subscription resource conforming to the FASTSubscription profile. This scenario is generic and can be used with any FHIR format and query parameters. **Actors:** Consent Client, CAS **Pre-condition:** A Subscription conforming to the FASTSubscription profile exists at the CAS, and its ID is known. **Narrative:** 1. Client sends a conformant [read](https://hl7.org/fhir/R4/http.html#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 FASTSubscription profile. **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. Tester: Since the $fileConsent response does not identify the new Consent, retain the identifier from the $fileConsent request. 4. \[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.\] 5. CAS returns a response. 6. Verify response is valid according to linked requirements. 7. Search for the Consent by the identifier saved from the $fileConsent request. 8. Verify the Consent is found and has status "active". **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. Tester: Since the $revokeConsent response does not identify the revoked Consent, retain the identifier from the $revokeConsent request. 4. \[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.\] 5. CAS returns a response. 6. Verify response is valid according to linked requirements. 7. Search for the Consent by the identifier saved from the $revokeConsent request. 8. Verify the Consent is found and has status "inactive". **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.\]
**Operation: Get Subscription Status** **Actors:** Consent Client, CAS **Pre-condition:** A Subscription exists on the CAS. **Narrative:** 1. Client POSTs to CAS: \[base\]/Subscription/\[id\]/$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
**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: 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.
**Create a subscription - rest-hook** This is a wide-open test case that can be used as the base for many variations. **Actors:** Consent Client, CAS, Notification Endpoint **Pre-condition:** Consent Client has prepared its Notification Endpoint to receive notifications. **Narrative:** 1. Client POSTs a 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". 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 new Subscription exists at the CAS.
**Create a subscription - rest-hook PUT** This test case extends test case "Create a subscription - rest-hook". - In step 1, Consent Client PUTs a conformant Subscription to the CAS. - In step 2, 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.
**Update a Subscription - rest-hook** This is a wide-open test case 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.
**Update a Subscription - rest-hook PATCH** This test case extends test case "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.
**Notify for a Subscription** **- rest-hook** This is a wide-open test case 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. **Post-condition:** - None
**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. Optional: Client GETs the new or modified Consent. Execute test case "Read a Consent". 5. Client DELETEs the FASTSubscription at the CAS. 6. The CAS deletes the Subscription. 7. Verify the response is valid according to the linked requirements. 8. 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. 9. 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-7. - Repeat steps 8-9 as follows: - In step 8, Tester creates each Consent at the CAS using this test data. - In step 8, Tester updates each Consent at the CAS. - In step 8, 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-7. - Repeat steps 8-9 as follows: - In step 8, Tester creates each Consent at the CAS using this test data. - In step 8, Tester updates each Consent at the CAS. - In step 8, 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-7. - Repeat steps 8-9 as follows: - In step 8, Tester creates each Consent at the CAS using this test data. - In step 8, Tester updates each Consent at the CAS. - In step 8, Tester deletes each 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-7. - Repeat steps 8-9 as follows: - In step 8, Tester creates each Consent at the CAS using this test data. - In step 8, Tester updates each Consent at the CAS. - In step 8, Tester deletes each 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-7. - Repeat steps 8-9 as follows: - In step 8, Tester creates each Consent at the CAS using this test data. - In step 8, Tester updates each Consent at the CAS. - In step 8, Tester deletes each 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-7. - Repeat steps 8-9 as follows: - In step 8, Tester creates each Consent at the CAS using this test data. - In step 8, Tester updates each Consent at the CAS. - In step 8, Tester deletes each Consent at the CAS. **Additional Post-condition:** - Any Consents created at the CAS have been deleted.
**Workflow: Consent subscription and notification - full-resource payload** This test case extends test case "Workflow: Consent subscription and notification". - In step 1, Consent Client creates a Subscription at the CAS requesting full-resource payloads. - After step 3, additionally verify the notification contains the full Consent resource(s). - Continue through step 7. - The test case ends - no additional steps are needed.
**Workflow: Consent subscription and notification - id only payload** This test case extends test case "Workflow: Consent subscription and notification". - In step 1, Consent Client creates a Subscription at the CAS requesting full-resource payloads. - After step 3, additionally verify the notification contains only the id of the Consent resource(s). - Continue through step 7. - The test case ends - no additional steps are needed.
**Workflow: Consent subscription and notification - empty payload** This test case extends test case "Workflow: Consent subscription and notification". - In step 1, Consent Client creates a Subscription at the CAS requesting full-resource payloads. - After step 3, additionally verify the notification is empty. - Continue through step 7. - The test case ends - no additional steps are needed.
**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](https://build.fhir.org/ig/HL7/fhir-consent-management/usecases.html#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