Scalable Consent Management Testing Guide - Local Development build (v1.0.0-ballot) 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
633: Consent Administration Service MAY support Consent notification filters by search parameters not listed by FASTConsentSubscriptionTopic
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
2: Consent Administration Service SHALL support JSON FHIR
34: Consent Administration Service SHALL support XML FHIR
397: Consent Administration Service SHALL support AuditEvent resource
398: Consent Administration Service SHALL support AuditEvent resources that conform to FASTConsentAuditEvent profile
406: Consent Administration Service SHALL support AuditEvent search
404: Consent Administration Service SHALL support AuditEvent read
409: Consent Administration Service SHALL support AuditEvent search by FASTAuditEventConsent
412: Consent Administration Service SHALL support AuditEvent search by patient
415: Consent Administration Service SHALL support $recordDisclosure operation against AuditEvent resource
43: Consent Administration Service SHALL support Consent resource
35: Consent Administration Service SHALL support Consent resources that conform to FASTConsent profile
37: Consent Administration Service SHALL support Consent search
36: Consent Administration Service SHALL support Consent read
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
377: Consent Administration Service SHALL support Consent subscriptions as defined by the FASTConsentSubscriptionTopic for FHIR R4 with Subscriptions Backport
661: Consent Administration Service SHALL support Subscription resource
959: Consent Administration Service SHALL support Subscription resources that conform to FASTSubscription profile
378: Consent Administration Service SHALL support Subscription create
379: Consent Administration Service SHALL support Subscription update
380: Consent Administration Service SHALL support Subscription delete
331: Consent Administration Service SHALL mark with profile assertions Consent resources that conform to the FASTConsent profile
961: Consent Administration Service SHALL support searching by the _profile parameter for Subscription resources that conform to the FASTSubscription profile
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:
332: Consent Administration Service SHALL support searching by the _profile parameter for Consent resources that conform to the FASTConsent profile
515: Consent Administration Service SHALL support searching by the _profile parameter for Subscription resources that conform to the BackportSubscription profile
960: Consent Administration Service SHALL mark with profile assertions Subscription resources that conform to the FASTSubscription profile
514: Consent Administration Service SHALL mark with profile assertions Subscription resources that conform to the BackportSubscription 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:
508: Consent Administration Service SHALL support $status operation against Subscription resource
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
517: Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile
602: Consent Administration Service SHALL support Subscription search by url
- Specification: Subscriptions R5 Backport
- Link to Text: https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/CapabilityStatement-backport-subscription-server-r4.json
- Conformance: SHALL
- Notes: Not testing search at this time, as the Consent IG doesn't require/use it. Also, the raw CapStmt (linked) and the rendered page for the CapStmt disagree: the raw says SHALL, the page says SHOULD. See: https://hl7.org/fhir/uv/subscriptions-backport/CapabilityStatement-backport-subscription-server-r4.html#:~:text=Search%20Parameter%20Summary,uri
- Traced Test Cases:
604: Consent Administration Service SHOULD support Subscription search by status
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
Requirements-capstmt-client
49: Consent Client SHALL support JSON FHIR
50: Consent Client SHALL support XML FHIR
401: Consent Client SHALL support AuditEvent resource
402: Consent Client SHALL support AuditEvent resources that conform to FASTConsentAuditEvent profile
408: Consent Client SHALL support AuditEvent search
405: Consent Client SHALL support AuditEvent read
414: Consent Client SHALL support AuditEvent search by patient
411: Consent Client SHALL support AuditEvent search by FASTAuditEventConsent
416: Consent Client SHALL support $recordDisclosure operation against AuditEvent resource
333: Consent Client SHALL support Consent resource
52: Consent Client SHALL support Consent resources that conform to FASTConsent profile
57: Consent Client SHALL support Consent search
56: Consent Client SHALL support Consent read
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
991: Consent Client SHALL support Subscription resource
962: Consent Client SHALL support Subscription resources that conform to FASTSubscription profile
382: Consent Client SHALL support Subscription create
383: Consent Client SHALL support Subscription update
384: Consent Client SHALL support Subscription delete
334: Consent Client SHALL mark with profile assertions Consent resources that conform to the FASTConsent profile
958: Consent Client SHALL mark with profile assertions Subscription resources that conform to the FASTSubscription 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:
Requirements-technical-specification-admin-service
69: Consent Administration Service MAY return OperationOutcome for a successful operation
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
62: Consent Administration Service SHALL support File Consent operation
101: Consent Administration Service SHALL support Revoke Consent operation
63: Consent Administration Service SHALL support Consent search
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://hl7.org/fhir/us/consent-management/2026Jan/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:
727: Consent Administration Service SHALL set Consent status element to 'active' when a File Consent operation has succeeded.
634: Consent Administration Service SHALL set Consent status element to 'inactive' when a Revoke Consent operation has succeeded.
760: Consent Administration Service SHALL NOT delete a Consent resource as a result of a Revoke Consent operation.
71: Consent Administration Service SHALL support Consent search by patient
364: Consent Administration Service SHALL support Consent search by FASTConsentController
367: Consent Administration Service SHALL support Consent search by FASTConsentManager
365: Consent Administration Service SHALL support Consent search by date
73: Consent Administration Service SHALL support Consent search by status
201: Consent Administration Service SHALL support Consent search by scope
827: Consent Administration Service SHALL be able to record disclosures of when a consent was accessed to determine whether patient information could be accessed
828: Consent Administration Service SHALL be able to retrieve disclosures of when a consent was accessed to determine whether patient information could be accessed
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://hl7.org/fhir/us/consent-management/2026Jan/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:
265: This guide mandates that Subscriptions be used
- Specification: HL7 FAST Consent IG
- Link to Text: https://hl7.org/fhir/us/consent-management/2026Jan/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:
202: Consent Client MAY subscribe to Consent topics as defined by the FAST Subscription Topic
- Specification: HL7 FAST Consent IG
- Link to Text: https://hl7.org/fhir/us/consent-management/2026Jan/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.
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-structure-definitions-admin-service
1030: Consent Administration Service SHALL support Consent read
1024: Consent Administration Service SHALL support FASTConsent search by _id
1026: Consent Administration Service SHALL support Consent search by identifier
1028: Consent Administration Service SHALL support FASTConsent search by patient
1032: Consent Administration Service SHALL support Consent search by the combination of the patient and status search parameters
1034: Consent Administration Service SHOULD support Consent search by the combination of the patient and date search parameters
632: Consent Administration Service SHALL support Consent notification filter combinations, and they combine as AND
Requirements-structure-definitions-client
1031: Consent Client SHALL support Consent read
1025: Consent Client SHALL support Consent search by _id
1027: Consent Client SHALL support Consent search by identifier
1029: Consent Client SHALL support Consent search by patient
1033: Consent Client SHALL support Consent search by the combination of the patient and status search parameters
1035: Consent Client SHOULD support Consent search by the combination of the patient and date search parameters
640: Consent Client SHALL support Consent notification filter combinations, and they combine as AND
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
925: Consent Administration Service SHALL include information in notifications as described in this guide based on the value of the backport-payload-content extension
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-artifacts-summary-admin-service
1: Consent Administration Service SHALL implement the server CapabilityStatement
- Specification: HL7 FAST Consent IG
- Link to Text: https://hl7.org/fhir/us/consent-management/2026Jan/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:
Requirements-artifacts-summary-client
48: Consent Client SHALL implement the client CapabilityStatement
- Specification: HL7 FAST Consent IG
- Link to Text: https://hl7.org/fhir/us/consent-management/2026Jan/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?
Requirements-subscription-topics-admin-service
1090: Consent Administration Service SHALL support Consent notification triggers based on create, update, and delete
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
600: Consent Administration Service SHALL trigger a notification for every Consent create, unless filtered out
607: Consent Administration Service SHALL trigger a notification for every Consent delete, unless filtered out
606: Consent Administration Service SHALL trigger a notification for every Consent update, unless filtered out
Requirements-subscription-topics-client
635: Consent Client SHALL support Consent notification filter by SearchParameter FASTConsentPatientId
636: Consent Client SHALL support Consent notification filter by SearchParameter FASTConsentOrganizationId
637: Consent Client SHALL support Consent notification filter by actor identifier
638: Consent Client SHALL support Consent notification filter by status
639: Consent Client SHALL support Consent notification filter by scope
Requirements-technical-specification-client-admin-service
826: Defined filter criteria for the FAST Subscription Topic
Requirements-structure-definitions-client-admin-service
597: StructureDefinition FASTConsent
829: FASTConsent must support extension:manager
830: FASTConsent must support extension:controller
831: FASTConsent must support policy
832: FASTConsent must support provision.actor
833: FASTConsent must support provision.purpose
834: FASTConsent must support provision.provision
598: StructureDefinition FASTConsentAuditEvent
835: FASTConsentAuditEvent must support outcomeDesc
836: FASTConsentAuditEvent must support purposeOfEvent
837: FASTConsentAuditEvent must support agent:client.policy
838: FASTConsentAuditEvent must support agent:user.role
839: FASTConsentAuditEvent must support agent:user.name
840: FASTConsentAuditEvent must support agent:user.policy
841: FASTConsentAuditEvent must support agent:user.purposeOfUse
842: FASTConsentAuditEvent must support agent:userorg.purposeOfUse
599: StructureDefinition FASTDocumentReference
859: FASTDocumentReference must support identifier
860: FASTDocumentReference must support date
861: FASTDocumentReference must support author
862: FASTDocumentReference must support author as a US Core Practitioner
863: FASTDocumentReference must support content.attachment.contentType
864: FASTDocumentReference must support content.attachment.data
865: FASTDocumentReference must support content.attachment.url
866: FASTDocumentReference must support content.format
867: FASTDocumentReference must support context
868: FASTDocumentReference must support context.encounter
869: FASTDocumentReference must support context.period
477: StructureDefinition FASTSubscription
870: FASTSubscription must support extension:filterCriteria
871: FASTSubscription must support extension:customChannelType
601: StructureDefinition FASTReference
872: FASTReference must support extension:additionalIdentifier
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
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
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
595: StructureDefinition BackportSubscription
892: StructureDefinition R4 Topic-Based Subscription Notification Bundle
893: StructureDefinition R4 Backported R5 SubscriptionStatus
535: ValueSet BackportContentValueSet
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
562: Notification bundles SHALL contain a FHIR R4 Parameters resource, conforming to the R4 Backported R5 SubscriptionStatus profile, as the first entry
537: Subscription.criteria SHALL contain the canonical URL for the Subscription Topic
1057: For each field marked MustSupport, Data Sources SHALL be capable of populating the data element when sharing resources compliant with the profile.
1058: For each field marked MustSupport, Data Consumers SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail
1059: For each field marked MustSupport, if the minimum cardinality of an element is greater than 0 – i.e. the element is ‘required’, then the element SHALL be present in the instance and SHALL have a value
1060: For each field marked MustSupport, Data Consumers SHALL interpret missing data elements within resource instances as data not being present in the Data Source’s systems or was not deemed to be shareable with the Data Consumer for privacy or other business reasons
1061: For each field marked MustSupport, Data Consumers SHALL be able to process resource instances containing data elements that have extensions in place of a value where such extensions are declared as part of the profile
Requirements-subscription-topics-client-admin-service
596: SubscriptionTopic FASTConsentSubscriptionTopic
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
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
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
Requirements-search-parameters-client-admin-service
471: SearchParameter FASTAuditEventConsent
472: SearchParameter FASTConsentController
473: SearchParameter FASTConsentGrantee
474: SearchParameter FASTConsentManager
475: SearchParameter FASTConsentOrganizationId
476: SearchParameter FASTConsentPatientId