Consent Administration Service SHALL implement the server CapabilityStatement<br/><br/>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.

Consent Administration Service SHALL support JSON FHIR<br/><br/>- Plan is to have JSON and XML flavors of all tests, but explicitly tracing each of those back to these requirements is probably not necessary.

Consent Administration Service SHALL support XML FHIR<br/><br/>- Plan is to have JSON and XML flavors of all tests, but explicitly tracing each of those back to these requirements is probably not necessary.

Consent Administration Service SHALL support Consent resource

Consent Administration Service SHALL support Consent resources that conform to FASTConsent profile

Consent Administration Service SHALL mark with profile assertions Consent resources that conform to the FASTConsent profile<br/><br/>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.

Consent Administration Service SHALL support searching by the _profile parameter for Consent resources that conform to the FASTConsent profile<br/><br/>Base FHIR requirement, applies because of declaring supportedProfile

Consent Administration Service SHALL support Consent read

Consent Administration Service SHALL support Consent search

Consent Administration Service SHALL support Consent search by FASTConsentController

Consent Administration Service SHALL support Consent search by date

Consent Administration Service SHALL support Consent search by FASTConsentGrantee<br/><br/>Missing corresponding req in Tech spec 6.2.3.4

Consent Administration Service SHALL support Consent search by FASTConsentManager

Consent Administration Service SHALL support Consent search by FASTConsentOrganizationId<br/><br/>Matches identifier of grantee, manager, controller or the provision.actor.reference Missing corresponding req in Tech spec 6.2.3.4

Consent Administration Service SHALL support Consent search by patient

Consent Administration Service SHALL support Consent search by FASTConsentPatientId<br/><br/>Matches patient.identifier or patient.extension additionalIdentifier Missing corresponding req in Tech spec 6.2.3.4

Consent Administration Service SHALL support Consent search by scope

Consent Administration Service SHALL support Consent search by status

Consent Administration Service SHALL support $fileConsent operation against Consent resource

Consent Administration Service SHALL support $revokeConsent operation against Consent resource

Consent Administration Service SHALL support Subscription resource

Consent Administration Service SHALL support Consent subscriptions as defined by the FASTConsentSubscriptionTopic for FHIR R4 with Subscriptions Backport

Consent Administration Service SHALL support Subscription create<br/><br/>For now, testing limited to the topic declared in the CapStmt

Consent Administration Service SHALL support Subscription update

Consent Administration Service SHALL support Subscription delete

Consent Administration Service SHALL support $recordDisclosure operation against AuditEvent resource

Consent Administration Service SHALL support AuditEvent resource

Consent Administration Service SHALL support AuditEvent resources that conform to FASTConsentAuditEvent profile

Consent Administration Service SHALL mark with profile assertions AuditEvent resources that conform to the FASTConsentAuditEvent profile<br/><br/>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.

Consent Administration Service SHALL support searching by the _profile parameter for AuditEvent resources that conform to the FASTConsentAuditEvent profile<br/><br/>Base FHIR requirement, applies because of declaring supportedProfile

Consent Administration Service SHALL support AuditEvent read

Consent Administration Service SHALL support AuditEvent search

Consent Administration Service SHALL support AuditEvent search by FASTAuditEventConsent

Consent Administration Service SHALL support AuditEvent search by patient

Consent Administration Service SHALL support Subscription read

Consent Administration Service SHOULD support Subscription write via POST or PUT<br/><br/>- "After POSTing the subscription, the client parses the Location header and saves the new Subscription's logical id for use in subsequent operations." - implies server should always return Location

Consent Administration Service SHOULD support Subscription update via PUT or PATCH<br/><br/>The CapStmt and the rendered page disagree - the raw CS does not include patch and the page does. Not testing patch at this time.

Consent Administration Service SHOULD support Subscription delete

Consent Administration Service SHOULD support Subscription search<br/><br/>Not testing search at this time

Consent Administration Service SHALL support Subscription search by url<br/><br/>Not testing search at this time. Also, the raw CapStmt (linked) and the rendered page for the CapStmt disagree: the raw says SHALL, the page says SHOULD. See: http://hl7.org/fhir/uv/subscriptions-backport/CapabilityStatement-backport-subscription-server-r4.html#:~:text=Search%20Parameter%20Summary,uri

Consent Administration Service SHOULD support Subscription search by status<br/><br/>Not testing search at this time

Consent Administration Service SHALL support $status operation against Subscription resource

Consent Administration Service MAY support $events operation against Subscription resource<br/><br/>Not testing at this time

Consent Administration Service MAY support $get-ws-binding-token operation against Subscription resource<br/><br/>Not testing at this time

Consent Administration Service SHALL support Subscription resources that conform to BackportSubscription profile

Consent Administration Service SHALL mark with profile assertions Subscription resources that conform to the BackportSubscription profile<br/><br/>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.

Consent Administration Service SHALL support searching by the _profile parameter for Subscription resources that conform to the BackportSubscription profile<br/><br/>Base FHIR requirement, applies because of declaring supportedProfile