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: Structure Definitions Client Admin Service

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

Structure Definitions Requirements for Client Admin Service

Requirements Actor(s)

These requirements apply to the following actors:

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

Requirements Statement List

Specification: HL7 FAST Consent IG

Reference: https://build.fhir.org/ig/HL7/fhir-consent-management/StructureDefinition-FileConsentParameters.html

Conformance: SHALL

Specification: HL7 FAST Consent IG

Reference: https://build.fhir.org/ig/HL7/fhir-consent-management/StructureDefinition-UpdateConsentParameters.html

Conformance: SHALL

Specification: HL7 FAST Consent IG

Reference: https://build.fhir.org/ig/HL7/fhir-consent-management/StructureDefinition-RevokeConsentParameters.html

Conformance: SHALL

Specification: HL7 FAST Consent IG

Reference: https://build.fhir.org/ig/HL7/fhir-consent-management/StructureDefinition-RecordDisclosureParameters.html

Conformance: SHALL

Specification: HL7 FAST Consent IG

Reference: https://build.fhir.org/ig/HL7/fhir-consent-management/StructureDefinition-FASTSubscription.html

Conformance: SHALL

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

Notes: - No requirements to use this yet - The constraint that status is always "active" might not make sense. I think the client is supposed to POST it as "requested".

Specification: Subscriptions R5 Backport

Reference: https://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition-backport-subscription.html

Conformance: SHALL

Specification: HL7 FAST Consent IG

Reference: https://build.fhir.org/ig/HL7/fhir-consent-management/StructureDefinition-FASTConsent.html

Conformance: SHALL

Notes: Many nested profiles, including from US Core. Will be checked by validator.

Specification: HL7 FAST Consent IG

Reference: https://build.fhir.org/ig/HL7/fhir-consent-management/StructureDefinition-FASTDocumentReference.html

Conformance: SHALL

Notes: Many nested profiles, including from US Core. Will be checked by validator.

Specification: HL7 FAST Consent IG

Reference: https://build.fhir.org/ig/HL7/fhir-consent-management/StructureDefinition-FASTReference.html

Conformance: SHALL

Notes: Many nested profiles, including from US Core. Will be checked by validator.

Specification: HL7 FAST Consent IG

Reference: https://build.fhir.org/ig/HL7/fhir-consent-management/StructureDefinition-FASTConsentAuditEvent.html

Conformance: SHALL

Notes: Many nested profiles, including from US Core. Will be checked by validator.


These requirements apply to the following actors:

requirement-464SHALL

StructureDefinition FileConsentParameters

Links:

requirement-70SHALL

The FileConsent operation "consent" input parameter SHALL be 1..1 and conform to the FASTConsent profile

Links:

requirement-430SHALL

The FileConsent operation "document" input parameter SHALL be 1..1 and conform to either the us-core-questionnaireresponse or FASTDocumentReference profile

Links:

requirement-468SHALL

StructureDefinition UpdateConsentParameters

Links:

requirement-434SHALL

The UpdateConsent operation "consent" input parameter SHALL be 1..1 and conform to the FASTConsent profile

Links:

requirement-436SHALL

The UpdateConsent operation "document" input parameter SHALL be 1..1 and conform to either the us-core-questionnaireresponse or FASTDocumentReference profile

Links:

requirement-469SHALL

StructureDefinition RevokeConsentParameters

Links:

requirement-441SHALL

The RevokeConsent operation "consent" input parameter SHALL be 1..1 and conform to the FASTConsent profile

Links:

requirement-448SHALL

The RevokeConsent operation "patient" input parameter SHALL be 1..1 and conform to the us-core-patient profile

Links:

requirement-443SHALL

The RevokeConsent operation "document" input parameter SHALL be 0..1 and conform to either the us-core-questionnaireresponse or FASTDocumentReference profile

Links:

requirement-470SHALL

StructureDefinition RecordDisclosureParameters

Links:

requirement-452SHALL

The RecordDisclosure operation "disclosure" input parameter SHALL be 1..1 and conform to the FASTConsentAuditEvent profile

Links:

requirement-450SHALL

The RecordDisclosure operation "consent" input parameter SHALL be 1..1 and conform to the FASTConsent profile

Links:

requirement-477SHALL

StructureDefinition FASTSubscription<br/><br/>- No requirements to use this yet

  • The constraint that status is always "active" might not make sense. I think the client is supposed to POST it as "requested".

Links:

requirement-595SHALL

StructureDefinition BackportSubscription

Links:

requirement-597SHALL

StructureDefinition FASTConsent<br/><br/>Many nested profiles, including from US Core. Will be checked by validator.

Links:

requirement-599SHALL

StructureDefinition FASTDocumentReference<br/><br/>Many nested profiles, including from US Core. Will be checked by validator.

Links:

requirement-601SHALL

StructureDefinition FASTReference<br/><br/>Many nested profiles, including from US Core. Will be checked by validator.

Links:

requirement-598SHALL

StructureDefinition FASTConsentAuditEvent<br/><br/>Many nested profiles, including from US Core. Will be checked by validator.

Links: