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

Scalable Consent Management, published by HL7 International / Community Based Collaborative Care. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-consent-management/ and changes regularly. See the Directory of published versions

Requirements: CapStmt Admin Service

Official URL: http://hl7.org/fhir/us/consent-management/Requirements/capstmt-admin-service Version: 0.1.0
Standards status: Trial-use Maturity Level: 1 Computable Name: CapStmtAdminService

CapStmt Requirements for Admin Service

Requirements Actor(s)

These requirements apply to the following actors:

  • Admin Service An application or product that implements the Admin Service.

Requirements Statement List

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.

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/CapabilityStatement-ConsentAdministrativeServerCapabilities.json.html

Conformance: SHALL

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

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/CapabilityStatement-ConsentAdministrativeServerCapabilities.json.html

Conformance: SHALL

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

Specification: HL7 FHIR R4

Link to Text: https://hl7.org/fhir/R4/profiling.html

Conformance: SHALL

Related Requirement: Requirements-structure-definitions-client-admin-service.html#requirement-597

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.

Specification: HL7 FHIR R4

Link to Text: https://hl7.org/fhir/R4/profiling.html

Conformance: SHALL

Related Requirement: Requirements-structure-definitions-client-admin-service.html#requirement-597

Notes: Base FHIR requirement, applies because of declaring supportedProfile

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/CapabilityStatement-ConsentAdministrativeServerCapabilities.json.html

Conformance: SHALL

Related Requirement: Requirements-search-parameters-client-admin-service.html#requirement-473

Notes: Missing corresponding req in Tech spec 6.2.3.4

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/CapabilityStatement-ConsentAdministrativeServerCapabilities.json.html

Conformance: SHALL

Related Requirement: Requirements-search-parameters-client-admin-service.html#requirement-475

Notes: Matches identifier of grantee, manager, controller or the provision.actor.reference Missing corresponding req in Tech spec 6.2.3.4

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/CapabilityStatement-ConsentAdministrativeServerCapabilities.json.html

Conformance: SHALL

Related Requirement: Requirements-search-parameters-client-admin-service.html#requirement-476

Notes: Matches patient.identifier or patient.extension additionalIdentifier Missing corresponding req in Tech spec 6.2.3.4

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/CapabilityStatement-ConsentAdministrativeServerCapabilities.json.html

Conformance: SHALL

Notes: For now, testing limited to the topic declared in the CapStmt

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.

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

Specification: Subscriptions R5 Backport

Link to Text: https://hl7.org/fhir/uv/subscriptions-backport/CapabilityStatement-backport-subscription-server-r4.html

Conformance: SHALL

Specification: Subscriptions R5 Backport

Link to Text: https://hl7.org/fhir/uv/subscriptions-backport/CapabilityStatement-backport-subscription-server-r4.html

Conformance: SHOULD

Notes: - "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

Specification: Subscriptions R5 Backport

Link to Text: https://hl7.org/fhir/uv/subscriptions-backport/CapabilityStatement-backport-subscription-server-r4.html

Conformance: SHOULD

Specification: Subscriptions R5 Backport

Link to Text: https://hl7.org/fhir/uv/subscriptions-backport/CapabilityStatement-backport-subscription-server-r4.html

Conformance: SHOULD

Specification: Subscriptions R5 Backport

Link to Text: https://hl7.org/fhir/uv/subscriptions-backport/CapabilityStatement-backport-subscription-server-r4.html

Conformance: SHOULD

Notes: Not testing at this time

Specification: Subscriptions R5 Backport

Link to Text: https://hl7.org/fhir/uv/subscriptions-backport/CapabilityStatement-backport-subscription-server-r4.html

Conformance: SHOULD

Notes: Not testing at this time

Specification: Subscriptions R5 Backport

Link to Text: https://hl7.org/fhir/uv/subscriptions-backport/CapabilityStatement-backport-subscription-server-r4.html

Conformance: SHOULD

Notes: Not testing at this time

Specification: Subscriptions R5 Backport

Link to Text: https://hl7.org/fhir/uv/subscriptions-backport/CapabilityStatement-backport-subscription-server-r4.html

Conformance: SHALL

Specification: Subscriptions R5 Backport

Link to Text: https://hl7.org/fhir/uv/subscriptions-backport/CapabilityStatement-backport-subscription-server-r4.json

Conformance: SHALL

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.

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


These requirements apply to the actor Admin Service

requirement-1SHALL

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.

Links:

requirement-2SHALL

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.

Links:

requirement-34SHALL

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.

Links:

requirement-43SHALL

Consent Administration Service SHALL support Consent resource

Links:

requirement-35SHALL

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

Links:

requirement-331SHALL

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.

Links:

requirement-332SHALL

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

Links:

requirement-36SHALL

Consent Administration Service SHALL support Consent read

Links:

requirement-37SHALL

Consent Administration Service SHALL support Consent search

Links:

requirement-199SHALL

Consent Administration Service SHALL support Consent search by FASTConsentController

Links:

requirement-72SHALL

Consent Administration Service SHALL support Consent search by date

Links:

requirement-38SHALL

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

Links:

requirement-200SHALL

Consent Administration Service SHALL support Consent search by FASTConsentManager

Links:

requirement-39SHALL

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

Links:

requirement-40SHALL

Consent Administration Service SHALL support Consent search by patient

Links:

requirement-368SHALL

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

Links:

requirement-42SHALL

Consent Administration Service SHALL support Consent search by scope

Links:

requirement-41SHALL

Consent Administration Service SHALL support Consent search by status

Links:

requirement-46SHALL

Consent Administration Service SHALL support $fileConsent operation against Consent resource

Links:

requirement-373SHALL

Consent Administration Service SHALL support $updateConsent operation against Consent resource

Links:

requirement-374SHALL

Consent Administration Service SHALL support $revokeConsent operation against Consent resource

Links:

requirement-377SHALL

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

Links:

requirement-378SHALL

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

Links:

requirement-379SHALL

Consent Administration Service SHALL support Subscription update

Links:

requirement-380SHALL

Consent Administration Service SHALL support Subscription delete

Links:

requirement-415SHALL

Consent Administration Service SHALL support $recordDisclosure operation against AuditEvent resource

Links:

requirement-397SHALL

Consent Administration Service SHALL support AuditEvent resource

Links:

requirement-398SHALL

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

Links:

requirement-399SHALL

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.

Links:

requirement-400SHALL

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

Links:

requirement-404SHALL

Consent Administration Service SHALL support AuditEvent read

Links:

requirement-406SHALL

Consent Administration Service SHALL support AuditEvent search

Links:

requirement-409SHALL

Consent Administration Service SHALL support AuditEvent search by FASTAuditEventConsent

Links:

requirement-412SHALL

Consent Administration Service SHALL support AuditEvent search by patient

Links:

requirement-505SHALL

Consent Administration Service SHALL support Subscription read

Links:

requirement-503SHOULD

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

Links:

requirement-509SHOULD

Consent Administration Service SHOULD support Subscription update via PUT or PATCH

Links:

requirement-510SHOULD

Consent Administration Service SHOULD support Subscription delete

Links:

requirement-511SHOULD

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

Links:

requirement-602SHOULD

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

Links:

requirement-604SHOULD

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

Links:

requirement-508SHALL

Consent Administration Service SHALL support $status operation against Subscription resource

Links:

requirement-517SHALL

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

Links:

requirement-514SHALL

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.

Links:

requirement-515SHALL

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

Links: