Scalable Consent Management Testing Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Requirements
RTM - Requirements
This page displays the Requirements Traceability Matrix (RTM) from the perspective of the requirements. All requirements captured are included, whether or not they are traced. Each requirement may be expanded to show the requirements details as well as the traced test cases.
Requirements-components-admin-service
565: Consent Administration Service SHOULD NOT use cross version extensions on R4 subscriptions to describe any elements also described by this guide
Requirements-components-client
512: Consent Client SHOULD NOT use cross version extensions on R4 subscriptions to describe any elements also described by this guide
Requirements-capstmt-admin-service
1: Consent Administration Service SHALL implement the server CapabilityStatement
- Specification: HL7 FAST Consent IG
- Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/artifacts.html
- Conformance: SHALL
- Notes: Does this mean a conforming system has to reference the "requirements" CS here, or could they just have their own CS that happens to be compatible?
Also, what test should this be traced to? I'm thinking this traces to test procedure that ensures the right complement of tests are applied to a given system.
- Traced Test Cases:
2: Consent Administration Service SHALL support JSON FHIR
34: Consent Administration Service SHALL support XML FHIR
43: Consent Administration Service SHALL support Consent resource
35: Consent Administration Service SHALL support Consent resources that conform to FASTConsent profile
331: Consent Administration Service SHALL mark with profile assertions Consent resources that conform to the FASTConsent profile
332: Consent Administration Service SHALL support searching by the _profile parameter for Consent resources that conform to the FASTConsent profile
36: Consent Administration Service SHALL support Consent read
37: Consent Administration Service SHALL support Consent search
199: Consent Administration Service SHALL support Consent search by FASTConsentController
72: Consent Administration Service SHALL support Consent search by date
38: Consent Administration Service SHALL support Consent search by FASTConsentGrantee
200: Consent Administration Service SHALL support Consent search by FASTConsentManager
39: Consent Administration Service SHALL support Consent search by FASTConsentOrganizationId
40: Consent Administration Service SHALL support Consent search by patient
368: Consent Administration Service SHALL support Consent search by FASTConsentPatientId
42: Consent Administration Service SHALL support Consent search by scope
41: Consent Administration Service SHALL support Consent search by status
46: Consent Administration Service SHALL support $fileConsent operation against Consent resource
374: Consent Administration Service SHALL support $revokeConsent operation against Consent resource
661: Consent Administration Service SHALL support Subscription resource
377: Consent Administration Service SHALL support Consent subscriptions as defined by the FASTConsentSubscriptionTopic for FHIR R4 with Subscriptions Backport
378: Consent Administration Service SHALL support Subscription create
379: Consent Administration Service SHALL support Subscription update
380: Consent Administration Service SHALL support Subscription delete
415: Consent Administration Service SHALL support $recordDisclosure operation against AuditEvent resource
397: Consent Administration Service SHALL support AuditEvent resource
398: Consent Administration Service SHALL support AuditEvent resources that conform to FASTConsentAuditEvent profile
399: Consent Administration Service SHALL mark with profile assertions AuditEvent resources that conform to the FASTConsentAuditEvent profile
- Specification: HL7 FHIR R4
- Link to Text: https://hl7.org/fhir/R4/profiling.html
- Conformance: SHALL
- Notes: Base FHIR requirement, applies because of declaring supportedProfile. Not marking as fully tested because I will continue to need to trace this to every transaction that applies.
- Traced Test Cases:
400: Consent Administration Service SHALL support searching by the _profile parameter for AuditEvent resources that conform to the FASTConsentAuditEvent profile
- Specification: HL7 FHIR R4
- Link to Text: https://hl7.org/fhir/R4/profiling.html
- Conformance: SHALL
- Notes: Base FHIR requirement, applies because of declaring supportedProfile
- Traced Test Cases:
404: Consent Administration Service SHALL support AuditEvent read
406: Consent Administration Service SHALL support AuditEvent search
409: Consent Administration Service SHALL support AuditEvent search by FASTAuditEventConsent
412: Consent Administration Service SHALL support AuditEvent search by patient
505: Consent Administration Service SHALL support Subscription read
503: Consent Administration Service SHOULD support Subscription write via POST or PUT
509: Consent Administration Service SHOULD support Subscription update via PUT or PATCH
510: Consent Administration Service SHOULD support Subscription delete
511: Consent Administration Service SHOULD support Subscription search
602: Consent Administration Service SHALL support Subscription search by url
604: Consent Administration Service SHOULD support Subscription search by status
508: Consent Administration Service SHALL support $status operation against Subscription resource
694: Consent Administration Service MAY support $events operation against Subscription resource
695: Consent Administration Service MAY support $get-ws-binding-token operation against Subscription resource
517: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile
514: Consent Administration Service SHALL mark with profile assertions Subscription resources that conform to the BackportSubscription profile
- Specification: HL7 FHIR R4
- Link to Text: https://hl7.org/fhir/R4/profiling.html
- Conformance: SHALL
- Notes: Base FHIR requirement, applies because of declaring supportedProfile. Not marking as fully tested because I will continue to need to trace this to every transaction that applies.
- Traced Test Cases:
515: Consent Administration Service SHALL support searching by the _profile parameter for Subscription resources that conform to the BackportSubscription profile
- Specification: HL7 FHIR R4
- Link to Text: https://hl7.org/fhir/R4/profiling.html
- Conformance: SHALL
- Notes: Base FHIR requirement, applies because of declaring supportedProfile
- Traced Test Cases:
Requirements-capstmt-client
48: Consent Client SHALL implement the client CapabilityStatement
- Specification: HL7 FAST Consent IG
- Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/artifacts.html
- Conformance: SHALL
- Notes: - Interpreting this as: a client doesn't necessarily have to maintain and make available a client CS, but does have to implement the functionality therein. So specific requirements from the CS are traced to tests that exercise them.
- Does this mean a conforming system has to reference the "requirements" CS here, or could they just have their own CS that happens to be compatible?
49: Consent Client SHALL support JSON FHIR
50: Consent Client SHALL support XML FHIR
333: Consent Client SHALL support Consent resource
52: Consent Client SHALL support Consent resources that conform to FASTConsent profile
334: Consent Client SHALL mark with profile assertions Consent resources that conform to the FASTConsent profile
56: Consent Client SHALL support Consent read
57: Consent Client SHALL support Consent search
58: Consent Client SHALL support Consent search by FASTConsentController
369: Consent Client SHALL support Consent search by date
370: Consent Client SHALL support Consent search by FASTConsentGrantee
371: Consent Client SHALL support Consent search by FASTConsentManager
59: Consent Client SHALL support Consent search by FASTConsentOrganizationId
60: Consent Client SHALL support Consent search by patient
372: Consent Client SHALL support Consent search by FASTConsentPatientId
47: Consent Client SHALL support Consent search by scope
61: Consent Client SHALL support Consent search by status
53: Consent Client SHALL support $fileConsent operation against Consent resource
376: Consent Client SHALL support $revokeConsent operation against Consent resource
381: Consent Client SHALL support Consent subscriptions as defined by the FASTConsentSubscriptionTopic for FHIR R4 with Subscriptions Backport
382: Consent Client SHALL support Subscription create
383: Consent Client SHALL support Subscription update
384: Consent Client SHALL support Subscription delete
416: Consent Client SHALL support $recordDisclosure operation against AuditEvent resource
401: Consent Client SHALL support AuditEvent resource
402: Consent Client SHALL support AuditEvent resources that conform to FASTConsentAuditEvent profile
403: Consent Client SHALL mark with profile assertions AuditEvent resources that conform to the FASTConsentAuditEvent profile
- Specification: HL7 FHIR R4
- Link to Text: https://hl7.org/fhir/R4/profiling.html
- Conformance: SHALL
- Notes: Base FHIR requirement, applies because of declaring supportedProfile. Not marking as fully tested because I will continue to need to trace this to every transaction that applies.
- Traced Test Cases:
405: Consent Client SHALL support AuditEvent read
408: Consent Client SHALL support AuditEvent search
411: Consent Client SHALL support AuditEvent search by FASTAuditEventConsent
414: Consent Client SHALL support AuditEvent search by patient
Requirements-technical-specification-admin-service
68: Consent Administration Service SHOULD return OperationOutcome with details of which business rules did not allow an operation to be successful if an HTTP status code of 4xx or 5xx is returned
69: Consent Administration Service MAY return OperationOutcome for a successful operation
- Specification: HL7 FAST Consent IG
- Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/technical.html
- Conformance: MAY
- Notes: - Right now, linking to each transaction. But rather than link many generic requirements to every transaction, should I create generic tests that each transaction uses?
• For now, no, but consider iterating into this. Once everything traces, can consider refactoring traces.
• An argument for doing this: every time we add a new transaction, we need to add those traces.
- Traced Test Cases:
63: Consent Administration Service SHALL support Consent search
364: Consent Administration Service SHALL support Consent search by FASTConsentController
365: Consent Administration Service SHALL support Consent search by date
367: Consent Administration Service SHALL support Consent search by FASTConsentManager
71: Consent Administration Service SHALL support Consent search by patient
201: Consent Administration Service SHALL support Consent search by scope
73: Consent Administration Service SHALL support Consent search by status
62: Consent Administration Service SHALL support File Consent operation
101: Consent Administration Service SHALL support Revoke Consent operation
64: Consent Administration Service SHALL support Consent subscriptions (as defined by the FAST Subscription Topic for FHIR R4 with Subscriptions Backport)
- Specification: HL7 FAST Consent IG
- Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/technical.html
- Conformance: SHALL
- Notes: Fix: "a consent administration service SHALL support subscriptions to allow other systems to be informed when consents for a patient have changed." - this should be more precise, like "a consent administration service SHALL support subscriptions as defined by the FAST Subscription Topic, e.g. to allow other systems to be informed when consents for a patient have changed."
- Traced Test Cases:
407: Consent Administration Service SHALL support AuditEvent search
266: Consent Administration Service SHALL support AuditEvent search by FASTAuditEventConsent
298: Consent Administration Service SHALL support AuditEvent search by patient
Requirements-technical-specification-client
67: Consent Client SHALL query the consent administration service for the identifiers of the involved patients, practitioners, organizations, and related persons
- Specification: HL7 FAST Consent IG
- Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/technical.html
- Conformance: SHALL
- Notes: Not testable yet - need lots more details about the lifecycle of relates resource instances.
Query or match?
Implies CAS is an MPI and similar for other resources?
Doesn’t say what triggers these queries to occur, or what effect it has on workflows, or whether discovered identifiers are used in resources…
- Traced Test Cases:
202: Consent Client MAY subscribe to Consent topics as defined by the FAST Subscription Topic
- Specification: HL7 FAST Consent IG
- Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/technical.html
- Conformance: MAY
- Notes: - No conformance words "client will…", so not clear which actors SHALL or MAY support. For now, treating as MAY for both clients and servers - tests can be conditional.
- Nature of topic is it allows combinations of criteria. I'll call out each criterion below for traceability.
- TBD whether there need to be requirements for CAS to detect and fire Consent events or if implied by subs framework.
265: This guide mandates that Subscriptions be used
- Specification: HL7 FAST Consent IG
- Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/technical.html
- Conformance: SHALL
- Notes: Need conformance words - who does this apply to? Assuming clients, but which ones? What triggering actions? Are clients required to support only, or that they positively subscribe to specific other systems? Suggest referencing section with normative workflows.
- Traced Test Cases:
167: If a system accesses a Consent instance for determining whether information can be accessed, the Record Disclosure Operation SHALL be used
267: Consent Client SHALL support AuditEvent search by FASTAuditEventConsent
299: Consent Client SHALL support AuditEvent search by patient
Requirements-subscriptiontopic-fastconsentsubscriptiontopic-admin-service
600: Consent Administration Service SHALL trigger a notification for every Consent create, unless filtered out
606: Consent Administration Service SHALL trigger a notification for every Consent update, unless filtered out
607: Consent Administration Service SHALL trigger a notification for every Consent delete, unless filtered out
603: Consent Administration Service SHALL support Consent notification filter by SearchParameter FASTConsentPatientId
628: Consent Administration Service SHALL support Consent notification filter by SearchParameter FASTConsentOrganizationId
629: Consent Administration Service SHALL support Consent notification filter by actor identifier
630: Consent Administration Service SHALL support Consent notification filter by status
631: Consent Administration Service SHALL support Consent notification filter by scope
632: Consent Administration Service SHALL support Consent notification filter combinations
633: Consent Administration Service MAY support Consent notification filters by search parameters not listed by FASTConsentSubscriptionTopic
Requirements-subscriptiontopic-fastconsentsubscriptiontopic-client
635: Consent Client MAY support Consent notification filter by SearchParameter FASTConsentPatientId
- Specification: HL7 FAST Consent IG
- Conformance: MAY
- Traced Test Cases:
636: Consent Client MAY support Consent notification filter by SearchParameter FASTConsentOrganizationId
- Specification: HL7 FAST Consent IG
- Conformance: MAY
- Traced Test Cases:
637: Consent Client MAY support Consent notification filter by actor identifier
- Specification: HL7 FAST Consent IG
- Conformance: MAY
- Traced Test Cases:
638: Consent Client MAY support Consent notification filter by status
- Specification: HL7 FAST Consent IG
- Conformance: MAY
- Traced Test Cases:
639: Consent Client MAY support Consent notification filter by scope
- Specification: HL7 FAST Consent IG
- Conformance: MAY
- Traced Test Cases:
640: Consent Client MAY support Consent notification filter combinations
- Specification: HL7 FAST Consent IG
- Conformance: MAY
- Traced Test Cases:
496: Consent Administration Service SHALL support Subscription read
497: Consent Administration Service SHALL support Subscription write
498: Consent Administration Service SHALL support $status operation against Subscription resource
499: Consent Administration Service SHOULD support Subscription topic discovery via the CapabilityStatement SubscriptionTopic Canonical extension
500: Consent Administration Service SHALL support at least one Subscription channel type, and SHOULD include one from Subscriptions R5 Backport IG
501: Consent Administration Service SHALL support at least one Subscription Payload Type
502: Consent Administration Service SHALL conform to the BackportSubscriptionCapabilityStatementR4 CapabilityStatement
567: Consent Administration Service SHOULD NOT use cross version extensions on R4 subscriptions to describe any elements also described by this guide
504: Consent Administration Service SHOULD declare conformance with the BackportSubscriptionCapabilityStatementR4 using CapabilityStatement.instantiates
513: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile
506: Consent Administration Service SHALL be able to read values in the backport-channel-type extension
507: Consent Administration Service SHALL reject the subscription request if a client requests an unsupported channel via the backport-channel-type extension
529: Consent Administration Service SHALL be able to read values in the backport-filter-criteria extension
530: Consent Administration Service SHALL be able to apply filters as described by any Subscription Topics the server advertises support for
531: Consent Administration Service SHALL reject the subscription request if any filters are unsupported
533: Consent Administration Service SHALL be able to read values in the backport-payload-content extension
534: Consent Administration Service SHALL include information in notifications as described in this guide based on the value of the backport-payload-content extension
535: Consent Administration Service SHALL reject the subscription request if a client asks for a content level the server does not intend to support (e.g., does not meet security requirements)
- Specification: Subscriptions R5 Backport
- Link to Text: https://hl7.org/fhir/uv/subscriptions-backport/conformance.html
- Conformance: SHALL
- Notes: This cannot be fully tested for a given system unless we know its specific requirements, but we can hit it with each content level as an exploratory test.
- Traced Test Cases:
563: Consent Administration Service SHALL be able to generate a valid and correct R4 Backported R5 SubscriptionStatus resource for each notification
538: Consent Administration Service SHALL be able to read values in Subscription.criteria for subscription topics referenced by it
539: Consent Administration Service SHALL reject the subscription request if it does not support a requested topic or will not honor the subscription otherwise
566: Consent Client SHOULD NOT use cross version extensions on R4 subscriptions to describe any elements also described by this guide
516: Consent Client MAY support the backport-channel-type extension
532: Consent Client SHALL be able to write values in the backport-filter-criteria extension
536: Consent Client SHALL be able to write values in the backport-payload-content extension
564: Consent Client SHALL be able to process a valid R4 Backported R5 SubscriptionStatus resource without errors
540: Consent Client SHALL be able to write subscription topic URLs in Subscription.criteria
Requirements-subscriptiontopic-fastconsentsubscriptiontopic-client-admin-ser
596: SubscriptionTopic FASTConsentSubscriptionTopic
- Specification: HL7 FAST Consent IG
- Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/SubscriptionTopic-FASTConsentSubscriptionTopic.html
- Conformance: SHALL
- Notes: This topic is defined as an auto-backported R5 SubscriptionTopic (see note below), so this means the requirements for processing it are defined in the captured R5 requirements below. Note: its raw representation (https://build.fhir.org/ig/HL7/fhir-consent-management/SubscriptionTopic-FASTConsentSubscriptionTopic.json) is as a Basic resource.
- Traced Test Cases:
Requirements-structure-definitions-client-admin-service
464: StructureDefinition FileConsentParameters
70: The FileConsent operation "consent" input parameter SHALL be 1..1 and conform to the FASTConsent profile
430: The FileConsent operation "document" input parameter SHALL be 1..1 and conform to either the us-core-questionnaireresponse or FASTDocumentReference profile
469: StructureDefinition RevokeConsentParameters
441: The RevokeConsent operation "consent" input parameter SHALL be 1..1 and conform to the FASTConsent profile
448: The RevokeConsent operation "patient" input parameter SHALL be 1..1 and conform to the us-core-patient profile
443: The RevokeConsent operation "document" input parameter SHALL be 0..1 and conform to either the us-core-questionnaireresponse or FASTDocumentReference profile
470: StructureDefinition RecordDisclosureParameters
452: The RecordDisclosure operation "disclosure" input parameter SHALL be 1..1 and conform to the FASTConsentAuditEvent profile
450: The RecordDisclosure operation "consent" input parameter SHALL be 1..1 and conform to the FASTConsent profile
477: StructureDefinition FASTSubscription
595: StructureDefinition BackportSubscription
597: StructureDefinition FASTConsent
599: StructureDefinition FASTDocumentReference
601: StructureDefinition FASTReference
598: StructureDefinition FASTConsentAuditEvent
562: Notification bundles SHALL contain a FHIR R4 Parameters resource, conforming to the R4 Backported R5 SubscriptionStatus profile, as the first entry
- Specification: Subscriptions R5 Backport
- Link to Text: https://hl7.org/fhir/uv/subscriptions-backport/conformance.html
- Conformance: SHALL
- Notes: Not sure why, but this requirement is nearly repeated a couple sentences later as "The status entry SHALL be the first entry of each notification bundle." No need to capture that.
- Traced Test Cases:
537: Subscription.criteria SHALL contain the canonical URL for the Subscription Topic
Requirements-workflow-client-admin-service
541: Informative: Consent Client and Consent Administration Service generally follow the subscription workflow for R4 systems in section 2.3.3
Requirements-search-parameters-client-admin-service
472: SearchParameter FASTConsentController
473: SearchParameter FASTConsentGrantee
474: SearchParameter FASTConsentManager
475: SearchParameter FASTConsentOrganizationId
476: SearchParameter FASTConsentPatientId
471: SearchParameter FASTAuditEventConsent
Requirements-extended-operations-client-admin-service
463: OperationDefinition FileConsent
133: The FileConsent operation is invoked as [base]/Consent/$fileConsent
134: The FileConsent operation input parameters SHALL conform to the FileConsentParameters profile
135: The FileConsent operation "consent" input parameter SHALL be 1..1 and a Consent resource
166: The FileConsent operation "document" input parameter SHALL be 1..1 and any resource
168: The FileConsent operation "return" output parameter SHALL be 0..1 and be an OperationOutcome
466: OperationDefinition RevokeConsent
438: The RevokeConsent operation is invoked as [base]/Consent/$revokeConsent
439: The RevokeConsent operation input parameters SHALL conform to the RevokeConsentParameters profile
440: The RevokeConsent operation "consent" input parameter SHALL be 1..1 and conform to the FASTConsent profile
447: The RevokeConsent operation "patient" input parameter SHALL be 1..1 and conform to the us-core-patient profile
442: The RevokeConsent operation "document" input parameter SHALL be 0..1 and any resource
444: The RevokeConsent operation "return" output parameter SHALL be 0..1 and be an OperationOutcome
467: OperationDefinition RecordDisclosure
445: The RecordDisclosure operation is invoked as [base]/AuditEvent/$recordDisclosure
446: The RecordDisclosure operation input parameters SHALL conform to the RecordDisclosureParameters profile
451: The RecordDisclosure operation "disclosure" input parameter SHALL be 1..1 and an AuditEvent resource
449: The RecordDisclosure operation "consent" input parameter SHALL be 1..1 and conform to the FASTConsent profile
453: The RecordDisclosure operation "return" output parameter SHALL be 0..1 and be an OperationOutcome