This page is part of the Scalable Consent Management (v1.0.0-ballot: STU 1 Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. No current official version has been published yet. For a full list of available versions, see the Directory of published versions

Conformance Expectations

Systems

The FAST Consent implementation guide defines the responsibilities of the two types of systems involved in a Consent solution:

Client systems are typically Electronic Medical Record (EHR) systems but could theoretically be any system responsible for gathering consent records.

Server systems (or servers) are consent administration systems.

MustSupport

This implementation guide uses specific terminology to flag statements that have relevance for the evaluation of conformance with the guide:

• SHALL indicates requirements that must be met to be conformant with the specification.

• SHOULD indicates behaviors that ought to be adhered to to avoid suboptimal interoperability but which do not, for this version of the specification, affect the determination of specification conformance.

• MAY describes optional behaviors that are free to consider but where there is no recommendation for or against adoption.

As well, profiles in this implementation guide make use of the mustSupport element. Base expectations for the intepretations of these terms are set in the FHIR core specification. Also see the mustSupport rules for the US Core implementation guides, which apply to content adhering to data elements profiled in those guides.

Along with those expectations, the following rules on MustSupport are also required:

• Data Sources SHALL be capable of populating the data element when sharing resources compliant with the profile. I.e. the system must be able to demonstrate the population and sharing of the element, but it is acceptable to omit the element if the system doesn't have values in a particular instance. A system that is incapable of ever sharing the element would be non-conformant. ^§MS-1
• Data Consumers SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail. ^§MS-2
• 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. ^§MS-3
• 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. ^§MS-4
• 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. ^§MS-5

Conformance Statements in this Guide

• §MS-1 : Data Sources SHALL be capable of populating the data element when sharing resources compliant with the profile. I.e. the system must be able to demonstrate the population and sharing of the element, but it is acceptable to omit the element if the system doesn't have values in a particular instance. A system that is incapable of ever sharing the element would be non-conformant.
• §MS-2 : Data Consumers SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail.
• §MS-3 : 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.
• §MS-4 : 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.
• §MS-5 : 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.
• §ID1 : client systems SHALL query the consent administration service for the identifiers of the involved patients, practitioners, organizations, and related persons
• §OP10 : Systems MAY return an OperationOutcome with a success to be consistent.
• §OP11 : Systems SHOULD return an OperationOutcome with the details if an HTTP status code of 4xx or 5xx is returned.
• §OP1 : To satisfy the business use cases for consent management, two operations are defined that a consent administration service SHALL support: File Consent and Revoke Consent.
• §OP2 : consent administration service systems SHALL support searching for consents
• §OP3 : a consent administration service SHALL support subscriptions to allow other systems to be informed when consents for a patient have changed.
• §OP4 : When filing a consent, the Consent status element SHALL be set to 'active'.
• §OP5 : After a consent has been revoked, the Consent status element for the revoked consent SHALL be set to 'inactive'.
• §OP6 : A revoked consent SHALL NOT be deleted from the consent management system.
• §OP7 : To support searching for consents, the following search parameters SHALL be supported - patient, controller, manager, date, status, and scope.
• §OP8 : consent administration services SHALL be able to record and retrieve disclosures of when a consent was accessed to determine whether patient information could be accessed.
• §OP12 : The Record Disclosure Operation SHALL be used when a system accesses a Consent instance for determining whether informtion can be accessed.
• §OP9 : To allow systems to document disclosures to requesting authorities (including a patient), systems SHALL support the searching for FAST Audit Events