Scalable Consent Management
1.0.0-preview - STU 1 PReview 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 1.0.0-preview 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: Technical Specification Consent Server

Official URL: http://hl7.org/fhir/us/consent-management/Requirements/technical-specification-consent-server Version: 1.0.0-preview
Standards status: Trial-use Maturity Level: 1 Computable Name: TechnicalSpecificationConsentServer

Technical Specification Requirements for Consent Server

Requirements Actor(s)

These requirements apply to the following actors:

  • Consent Server An application or product that implements the Consent Server.

Requirements Statement List

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: MAY

Notes: I believe they are referring only to extended operations defined by the IG.

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHOULD

Notes: I believe they are referring only to extended operations defined by the IG.

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHALL

Related Requirement: 463: Requirements-extended-operations-client-consent-server.html#requirement-463

Notes: Redundant with CapStmt

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHALL

Related Requirement: 466: Requirements-extended-operations-client-consent-server.html#requirement-466

Notes: Redundant with CapStmt

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHALL

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/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."

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHALL

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHALL

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHALL

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHALL

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHALL

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHALL

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHALL

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHALL

Notes: - Need to clarify which system has the responsibility for calling this - assuming Consent Client, calling the CAS. - For now, assuming client calls after accessing.

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHALL

Notes: - Need to clarify which system has the responsibility for calling this - assuming Consent Client, calling the CAS. - For now, assuming client calls after accessing.

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHALL

Notes: See 7.2.6.1 - not always the Consent Admin Service, so if we test this in a workflow with a CAS, need to allow a different configurable actor to be the one that POSTs.

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHOULD

Notes: Requires a separate analysis task

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHALL

Specification: HL7 FAST Consent IG

Link to Text: https://build.fhir.org/ig/HL7/fhir-consent-management/en/technical.html

Conformance: SHALL

Notes: Need to specify actor(s). For now, assuming CAS SHALL support and Consent Client MAY support


Language: en

These requirements apply to the actor Consent Server

requirement-69MAY

Consent Administration Service MAY return OperationOutcome for a successful operation<br/><br/>I believe they are referring only to extended operations defined by the IG.

Links:

requirement-68SHOULD

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<br/><br/>I believe they are referring only to extended operations defined by the IG.

Links:

requirement-62SHALL

Consent Administration Service SHALL support File Consent operation<br/><br/>Redundant with CapStmt

Links:

requirement-101SHALL

Consent Administration Service SHALL support Revoke Consent operation<br/><br/>Redundant with CapStmt

Links:

requirement-63SHALL

Consent Administration Service SHALL support Consent search

Links:

requirement-64SHALL

Consent Administration Service SHALL support Consent subscriptions (as defined by the FAST Subscription Topic for FHIR R4 with Subscriptions Backport)<br/><br/>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."

Links:

requirement-727SHALL

Consent Administration Service SHALL set Consent status element to 'active' when a File Consent operation has succeeded.

Links:

requirement-634SHALL

Consent Administration Service SHALL set Consent status element to 'inactive' when a Revoke Consent operation has succeeded.

Links:

requirement-760SHALL

Consent Administration Service SHALL NOT delete a Consent resource as a result of a Revoke Consent operation.

Links:

requirement-71SHALL

Consent Administration Service SHALL support Consent search by patient

Links:

requirement-364SHALL

Consent Administration Service SHALL support Consent search by FASTConsentController

Links:

requirement-367SHALL

Consent Administration Service SHALL support Consent search by FASTConsentManager

Links:

requirement-365SHALL

Consent Administration Service SHALL support Consent search by date

Links:

requirement-73SHALL

Consent Administration Service SHALL support Consent search by status

Links:

requirement-201SHALL

Consent Administration Service SHALL support Consent search by scope

Links:

requirement-827SHALL

Consent Administration Service SHALL be able to record disclosures of when a consent was accessed to determine whether patient information could be accessed<br/><br/>- Need to clarify which system has the responsibility for calling this - assuming Consent Client, calling the CAS.

  • For now, assuming client calls after accessing.

Links:

requirement-828SHALL

Consent Administration Service SHALL be able to retrieve disclosures of when a consent was accessed to determine whether patient information could be accessed<br/><br/>- Need to clarify which system has the responsibility for calling this - assuming Consent Client, calling the CAS.

  • For now, assuming client calls after accessing.

Links:

requirement-1166SHALL

Systems SHALL create a FAST Consent Audit Event via a RESTful FHIR POST AuditEvent whenever a Consent instance is accessed to determine whether patient information can be accessed<br/><br/>See 7.2.6.1 - not always the Consent Admin Service, so if we test this in a workflow with a CAS, need to allow a different configurable actor to be the one that POSTs.

Links:

requirement-1163SHOULD

For disclosure events, implementers SHOULD follow the IHE Basic Audit Log Patterns (BALP) guide, specifically the patterns for data disclosure audit events. This guide does not define a custom profile for disclosure events; IHE-BALP patterns should be used directly.<br/><br/>Requires a separate analysis task

Links:

requirement-1164SHALL

Consent Administration Service SHALL support AuditEvent search by Consent (entity)

Links:

requirement-298SHALL

Consent Administration Service SHALL support AuditEvent search by patient<br/><br/>Need to specify actor(s). For now, assuming CAS SHALL support and Consent Client MAY support

Links: