Da Vinci - Documentation Templates and Rules
2.2.0 - STU 2.2

Da Vinci - Documentation Templates and Rules, published by HL7 International / Clinical Decision Support. This guide is not an authorized publication; it is the continuous build for version 2.2.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-dtr/ and changes regularly. See the Directory of published versions

## Conformance Details

Page standards status: Trial-use | Highlight text changes?

This section contains a table listing all the free-text conformance statements found in the IG. This table is provided as a useful summary for implementers for the purpose of evaluating key features and to support testing. However, reading this table alone is insufficient to understand or successfully implement the specification:

1. The table only includes conformance expectations expressed as free text. It does not include the computable expectations represented in capability statements, profiles, value sets, etc.
2. The text text in the table only includes the 'formal' requirement. It does not provide the contextual language around the statement that will be needed for successful explanation. The 'id' of each statement is a hyperlink to the place it appears in the text to assist with gathering the needed context.

A few other notes:

- The ids are generally specific to the pages on which the requirements appear, but not always. If content is moved from one page to another, the id will remain the same.
- While ids start as contiguous, as the specification is updated, it is possible some conformance statements will be removed, which will create a gap in the numbers. This is not an error.
- Ids are not final until published in an official release. At that point, ids will not be changed.
- It is possible for the text of a given rules to change somewhat from one release to another so long as the intention of the rule is the same. If the intent has a significant change, the old rule will be removed and a new one added in its place.
- The actors are broken down into 'client' and 'server'. There may be multiple systems that actually compose those logical entities which will vary from implementation. It will be up to implementers to determine how the various conformance statements will apply to the actal systems in their architecture.
- The categorizations are general. In practice, all 'exchange', 'ui', and 'storage' requirements are some aspect of 'processing' requirements. The categories will give hints as to the architectural layer a requirement will apply to, but there is nothing definitive implied by the category(ies) listed.

The controls at the top of the table allow filtering the content to particular requirement subsets that may be of interest. As well, a computable representation (XML and JSON) of the requirements can be found here.

Id | Expectation | Conditional? | Actors | Categories | Rule
--- | --- | --- | --- | --- | ---
| SHALL SHALL NOT SHOULD MAY SHOULD NOT | Yes No Any | DTR Client DTR Server | business exchange processing storage ui |
§conf-1 | SHALL |  | DTR Client DTR Server | exchange | In order to conform to this implementation guide, in addition to adhering to any relevant 'SHALL' statements, a system SHALL conform to at least one of the appropriate CapabilityStatements listed here:
§conf-2 | SHALL |  | DTR Client DTR Server | exchange | Da Vinci DTR implementations SHALL conform to the HRex and US Core Guidance where applicable.
§conf-3 | SHALL |  | DTR Client | ui | DTR apps and EHRs that take on DTR app responsibility SHALL be able to render Questionnaires and QuestionnaireResponses.
§conf-4 | MAY |  | DTR Client | ui | DTR clients MAY adjust which client components expose which Questionnaire items, which Questionnaire items are exposed to which users and how those items are exposed as appropriate for the workflow so long as they retain the ability to render all `mustSupport` elements at least in some places within their client system(s).
§conf-5 | SHALL | X | DTR Client | ui | Specifically, apps and EHRs acting as form fillers SHALL be able to display:
§conf-6 | SHALL |  | DTR Client | ui | They SHALL also handle all mustSupport elements within the Questionnaire profile and provide visual cues where those elements impact expected user action (e.g., required answers, need for signatures, etc.)
§conf-7 | SHOULD |  | DTR Client | ui | Those same systems SHOULD be able to display `QuestionnaireResponse.item.itemMedia`
§conf-8 | SHALL NOT |  | DTR Server | exchange | When determining Questionnaire packages, processing adaptive forms via `$next-question`, or constructing population logic, DTR services SHALL NOT depend on or set expectations for the inclusion of resource instances not compliant with profiles defined in this guide, HRex, or US Core.
§conf-9 | SHALL NOT |  | DTR Server | exchange | Similarly, they SHALL NOT depend on or set expectations for the inclusion of any data elements not marked as mandatory (min cardinality >= 1) or `mustSupport` in those profiles.
§conf-10 | SHALL NOT SHALL |  | DTR Server | exchange | DTR servers SHALL NOT set expectations for systems to support Questionnaire rendering or response validation capabilities above those established in the DTR Questionnaire profiles and SHALL accept and successfully process any Questionnaire Response returned for a Questionnaire from that DTR server that is deemed valid against the rules expressed only as `mustSupport` in the Questionnaire profile.
§conf-11 | MAY | X | DTR Client DTR Server | business | If the proposed change is adopted and published in the DTR continuous integration build or the CI build of one of its dependencies (e.g., US Core), implementations MAY, by mutual agreement, pre-adopt the use of those additional profiles and/or `mustSupport` data elements and not be considered in violation of #1 or #2 above.
§conf-12 | SHALL NOT | X | DTR Client DTR Server | exchange | Where cardinality and other constraints present in profiles allow data elements to be omitted, DTR compliant systems SHALL NOT treat the omission of those elements as a conformance error - i.e., DTR services are expected to return appropriate questionnaire package responses, not system level errors (e.g., HTTP 4xx errors), and DTR clients are expected to render and allow completion of forms as normal.
§conf-13 | SHALL |  | DTR Client DTR Server | exchange | DTR clients and services and SHALL use standard DTR data elements (i.e., elements found within DTR-defined or inherited profiles and marked as mandatory or `mustSupport`) to communicate needed data if such elements are intended to convey such information.
§conf-14 | SHALL NOT MAY |  | DTR Client DTR Server | exchange | Organizations implementing DTR SHALL NOT publish guidance setting expectations for where certain data elements are conveyed within DTR and inherited data structures, but MAY submit change requests to DTR, CRD, HRex, or US Core requesting that additional guidance be provided to implementers on data structure usage to increase consistency across implementations.
§conf-15 | SHALL |  | DTR Client DTR Server | business | Such enhancements SHALL be submitted as a ticket for consideration for inclusion in a future version of the implementation guide.
§opcn-1 | SHOULD |  | DTR Client | ui | Picklist: questions that will normally not be pre-populated, SHOULD be answered 90% of the time from a predefined picklist supported by typeahead for long lists and allows for occasional text entries (average answer time of 5 seconds each)
§opcn-2 | SHOULD |  | DTR Client | ui | SHOULD be clinical questions but might include administrative questions if necessary to select appropriate clinical questions.
§oper-1 | SHALL |  | DTR Client DTR Server | exchange | This operation SHALL be supported by payers and DTR applications.
§oper-2 | SHALL NOT SHOULD |  | DTR Client | exchange | The input OperationOutcome resource SHOULD include information on the DTR application identity and version, date-time with time-zone offset, as well as the provider endpoint during which the error occurred, and it SHALL NOT contain information about the response or information retrieved from FHIR APIs that could potentially include PHI.
§oper-3 | SHOULD |  | DTR Client | exchange | The Questionnaire reference SHOULD be version-specific.
§oper-4 | SHALL |  | DTR Client | exchange | The operation is called at the resource level and a url SHALL be provided.
§oper-5 | SHALL |  | DTR Server | exchange | Additionally, the valueset SHALL use the current date as the expansion date and SHALL include only active codes.
§oper-6 | SHALL |  | DTR Client | exchange | The operation SHALL take as input the Coverage resource(s) identifying the member and the type(s) of Coverage for which additional information is needed and at least one of:
§oper-7 | SHALL | X | DTR Server | exchange | If multiple versions of a questionnaire are returned, each SHALL be associated with distinct orders or coverages in the associated QuestionnaireResponses (see below).
§oper-8 | SHALL | X | DTR Server | exchange | If this operation is invoked with a context id provided by CRD where the `coverage-information` extension indicated that additional documentation was required, but no questionnaires are returned by the operation, the operation SHALL return an OperationOutcome with clear instructions on how else to determine needed documentation or an indication that circumstances have changed and additional documentation is no longer necessary.
§oper-9 | SHALL | X | DTR Server | exchange | If any of the explicitly requested questionnaires cannot be found, a warning SHALL be provided in the `Outcome` element of the outer `Parameters` resource.
§oper-10 | SHALL | X | DTR Server | exchange | If the operation is successful, the response SHALL be a `Parameters` resource conformant to the DTRQuestionnairePackageOutputParameters profile.
§oper-11 | SHOULD | X | DTR Server | exchange | If the operation fails, the response payload SHOULD be an OperationOutcome.
§oper-12 | SHALL |  | DTR Server | exchange | The Bundle SHALL include the Questionnaire as the first entry along with all external Libraries referenced by the Questionnaire using the cqf-library extension, as well as a recursive retrieval of all `relatedArtifact` references of type 'depends-on'.
§oper-13 | SHALL |  | DTR Server | exchange | All Libraries SHALL include both CQL and EML representations.
§oper-14 | SHALL |  | DTR Server | exchange | The Bundle SHALL include all external ValueSet instances referenced by the Questionnaire.
§oper-15 | SHALL |  | DTR Server | exchange | All value sets with expansions under 40 entries SHALL be expanded as of the current date and using expansion parameters (such as SNOMED release) as deemed appropriate by the payer.
§oper-16 | SHALL |  | DTR Server | exchange | All references to Questionnaires, Libraries, and ValueSets within the Bundle SHALL be version specific, as breaking changes may occur between versions and would likely cause failures or inconsistent data.
§oper-17 | MAY |  | DTR Server | exchange | Multiple versions of a Library MAY be treated as an error, or MAY be handled by returning the 'most recent' version of the referenced versions.
§oper-18 | SHALL |  | DTR Server | exchange | As well, the Questionnaire Bundle SHALL contain one initial draft `QuestionnaireResponse` that references the `Questionnaire` for that Bundle and populate the subject as well as repetitions of the Context extension that identify the Coverage(s) and Request or Encounter resources the `Questionnaire` is to be completed for.
§oper-19 | MAY |  | DTR Server | exchange | The payer MAY opt to pre-populate some answers in the provided QuestionnaireResponses based on information the payer has in its own records or has from context from CRD or from other prior auth or claims submissions.
§oper-20 | SHALL | X | DTR Client | exchange | When resuming a work in progress questionnaire response the DTR client SHALL invoke the operation with the timestamp to see if the questionnaire package has changed since it was last retrieved, presuming that the `QuestionnaireResponse.meta.lastUpdated` element corresponds to the last package retrieval time.
§prof-1 | SHOULD |  | DTR Server | exchange | However, the system should check that the passed orders are the same as was processed at CRD time before presuming that the questionnaires needed will be the same and if the orders have changed, or there's a possibility that the rules governing which Questionnaires are needed might have changed, the system SHOULD re-check to determine the needed Questionnaires.
§prof-2 | SHALL |  | DTR Client | exchange | The Payer Identifier used SHALL be the same as the ones that are returned by the endpoint discovery mechanism defined in HRex.
§sec-1 | SHALL |  | DTR Client DTR Server | exchange | Implementers SHALL adhere to any security and privacy rules defined by:
§sec-2 | MAY |  | DTR Client DTR Server | exchange | This scope granted MAY provide the SMART on FHIR application access to more data than is needed for the specific situation.
§sec-3 | SHALL |  | DTR Server | exchange | For compliance with HIPAA Minimum Necessary, the CQL included in payer-defined Questionnaires SHALL limit requests for information from the EHR's API to only items that are relevant to the documentation requirements for which DTR was launched (e.g., documentation requirements for a service that does require prior authorization).
§sec-4 | SHALL NOT |  | DTR Server | exchange | Compliant Questionnaires SHALL NOT include hidden or read-only questions where the data is populated from the EHR.
§sec-5 | SHALL |  | DTR Client | exchange | DTR Clients SHALL appropriately manage access to data that is sensitive per policy and regulatory requirements when responding to queries from a DTR app.
§sec-6 | SHOULD |  | DTR Client | processing | Providers SHOULD ask the patient if they want to share the information with the payer prior to manually populating it in any QuestionnaireResponses.
§sec-7 | SHOULD |  | DTR Client | exchange | Any EHR with SMART on FHIR support SHOULD be prepared to deal with the implications of providing a client with the scopes they request.
§sec-8 | SHALL |  | DTR Client | exchange | For example, EHRs SHALL limit FHIR search capabilities for clients, requiring a patient ID in any search query to ensure the client can only access resources related to that patient.
§sec-9 | SHALL |  | DTR Server | exchange | Payer systems SHALL use information received during execution of the DTR `$questionnaire-package` operation solely for the purpose of satisfying the operation invoked, for audit, and to satisfy metric reporting needs.
§sec-10 | SHALL NOT | X | DTR Server | exchange | If a payer uses adaptive forms to gather information, the payer SHALL NOT persist or use the information shared as part of the `$next-question` operation for any purpose other than:
§spec-1 | SHALL NOT MAY |  | DTR Server | exchange | Payer DTR services SHALL NOT work preferentially with their own apps for IG-defined functionality, though clients and services MAY offer additional behavior above and beyond what's covered in this specification.
§spec-2 | MAY |  | DTR Client | business | This means that EHRs are free to choose which app they prefer and MAY switch apps as they see fit.
§spec-3 | MAY | X | DTR Client | business | In some cases, an EHR MAY opt to support multiple DTR SMART apps.
§spec-4 | SHALL |  | DTR Client | business | Similarly, all DTR apps SHALL be registered with the payer systems with which they communicate. If an EHR opts to interact with the payer directly without using an app, then the EHR itself will need to register.
§spec-5 | MAY |  | DTR Server | processing | Payers MAY have multiple back-end functions that handle different types of decision support and/or different types of services.
§spec-6 | SHALL |  | DTR Server | exchange | However, for the purpose of DTR conformance, payers SHALL have a single endpoint (managed by themselves or a delegate) that can handle responding to all DTR service calls.
§spec-7 | SHALL |  | DTR Client DTR Server | business | This registration process SHALL ensure that the DTR app or Full EHR (i.e., Native App):
§spec-8 | SHOULD |  | DTR Client DTR Server | exchange | Implementers of this IG SHOULD support the endpoint discovery mechanism defined in the HRex specification to allow discovery of the endpoints used in this IG - specifically the `$questionnaire-package` operation endpoint used to retrieve the Questionnaires and associated libraries, value sets, etc. to be completed.
§spec-9 | SHOULD MAY |  | DTR Client DTR Server | business | Even after an application has been successfully registered, payers and EHRs SHOULD monitor the application behavior and MAY suspend an application's access if it is suspected of malicious behavior.
§spec-10 | MAY |  | DTR Server | business | Some payers MAY create Questionnaires that rely on code systems that require licensing for use where there isn’t already a cross-U.S. license in place (e.g., UB, CPT).
§spec-11 | SHALL |  | DTR Client DTR Server | business | The expectations around licensing requirements SHALL be established as part of the configuration process between the parties.
§spec-12 | SHALL SHOULD |  | DTR Server | exchange | DTR services SHOULD have DTR questionnaires available for all covered items that require additional data collection to support prior auth submission, claim submission, or appropriate use documentation. (Future versions of this guide will likely tighten this expectation to a 'SHALL')
§spec-13 | MAY |  | DTR Server | exchange | DTR server organizations MAY surface their Questionnaires via a registry or some similar mechanism that allows DTR client organizations to pre-examine/pre-process Questionnaires to allow for more optimal handling when those Questionnaires are actually solicited.
§spec-14 | SHALL NOT |  | DTR Client | exchange | DTR clients SHALL NOT be dependent on such pre-availability in order to perform form completion.
§spec-15 | MAY |  | DTR Server | exchange | Payers MAY support either approach or opt to provide some Questionnaires using one approach and others using the second based on the requirements of the form.
§spec-16 | SHALL |  | DTR Client | exchange | DTR apps and Full EHRs SHALL support both types of Questionnaires.
§spec-17 | SHALL |  | DTR Server | exchange | Questionnaires, whether standard or adaptive, SHALL also use logic that ensures that only questions and answer choices which are required for the intended clinical or administrative purposes are included, based on what answers have already been provided/populated using elements such as `enableWhen` or `enableWhenExpression`.
§spec-18 | SHALL | X | DTR Server | exchange | When using elements with a data type of 'Expression' within Questionnaires to control flow or rendering, all logic SHALL be written in CQL.
§spec-19 | SHALL |  | DTR Client | exchange | The Elements flagged as mustSupport SHALL be supported by DTR Apps and Full EHRs.
§spec-20 | SHALL NOT SHOULD |  | DTR Client | exchange | These systems SHOULD also support all non `mustSupport` data extensions included in the differential of the DTR Questionnaire profiles as per SDC documentation for those elements and extensions, and non-support for an element SHALL NOT interfere with a user's ability to complete a QuestionnaireResponse.
§spec-21 | SHALL NOT |  | DTR Server | exchange | However, payers SHALL NOT rely on support for any of these elements in the design of their Questionnaire (i.e., a DTR client that ignores such elements cannot impact the successful collection of information acceptability of the information gathered).
§spec-22 | SHALL | X | DTR Server | processing | If there is a need to collect both patient or clinical data as well as administrative data, forms SHALL be designed in one of the two the following manners:
§spec-23 | SHALL | X | DTR Server | exchange | When a payer uses an Adaptive Form, they SHALL return a questionnaire instance compliant with the DTR AdaptiveQuestionnaire-Search profile.
§spec-24 | SHALL | X | DTR Server | exchange | If present, any `questionnaireAdaptive` url SHALL be a sub-url under the base for the payer and able to be accessed within the same SMART Backend Services connection as was established to make the $questionnaire-package call.
§spec-25 | SHALL |  | DTR Server | exchange | The QuestionnaireResponse included in the Questionnaire Package Bundle accompanying an adaptive Questionnaire SHALL follow the convention of referencing a contained Questionnaire `derivedFrom` the canonical for the Questionnaire being completed.
§spec-26 | MAY |  | DTR Server | exchange | Typically, the QuestionnaireResponse and contained Questionnaire will contain no answers (or corresponding questions), though the payer MAY opt to include a few pre-populated answers for user review prior to soliciting additional questions using the `$next-question` operation.
§spec-27 | MAY |  | DTR Server | exchange | Payers MAY define pre-populatable questions to extract such information, using CQL to access the Questionnaire's `launchContext` extension or performing any necessary data retrieval.
§spec-28 | MAY |  | DTR Server | exchange | There are three strategies payers can use – and payers MAY opt to combine strategies within a single Questionnaire:
§spec-29 | MAY |  | DTR Server | exchange | The payer MAY opt to include CQL Libraries and ValueSets in the package that are not actually referenced by any questions, on the prospect that they might be (or are likely to be) referenced by one of the questions at some point.
§spec-30 | MAY |  | DTR Server | exchange | The payer MAY add CQL Libraries and ValueSets as 'contained' resources inside the QuestionnaireResponse that are relevant to the questions that are part of the Questionnaire for each `$next-question` call, slowly building up the set of resources that happen to be relevant to the questions actually asked.
§spec-31 | MAY |  | DTR Server | exchange | Finally, the payer MAY opt to specify the CQL and codes without using Libraries or ValueSets at all – the CQL can be sent in-line within the various Expression elements, and the codes can be listed directly as answerOption Codings.
§spec-32 | SHOULD | X | DTR Server | exchange | Payers needing full resources to be returned SHOULD use the `containedReference` extension to indicate that the selected resource(s) for an answer of type reference should be included as contained resources within the QuestionnaireResponse.
§spec-33 | SHALL SHOULD | X | DTR Server | exchange | Implementers that support Adaptive Questionnaires SHOULD always include a `coverage-information` extension when the QuestionnaireResponse is deemed complete. (Future versions of this guide will likely tighten this expectation to a 'SHALL')
§spec-34 | MAY | X | DTR Server | exchange | The package returned by the `$questionnaire-package` operation MAY include Library and/or ValueSet instances that are not referenced by any of the returned questionnaires if at least one of those questionnaires is adaptive.
§spec-35 | SHALL | X | DTR Client | exchange | In this circumstance these additional resources are being made available, and SHALL be retained in the session, on the likelihood that a question in one of those adaptive questionnaires returned by the `$next-question` operation will need (and reference) these resources.
§spec-36 | SHOULD | X | DTR Server | exchange | When using adaptive forms, DTR servers SHOULD return as many items in a single call as possible (within reason), including questions that can be determined as enabled or disabled using simple 'enableWhen' logic.
§spec-37 | SHOULD | X | DTR Client | exchange | Calling the `$next-question` operation SHOULD only be necessary when the DTR client requires invocation of more complex or non-disclosable logic to determine the next set of items.
§spec-38 | SHALL |  | DTR Server | exchange | Conformant systems SHALL meet these timing expectations at least 90% of the time.
§spec-39 | SHALL | X | DTR Server | exchange | In an adaptive Questionnaire with clinical or patient questions, systems that know that, after submitting the answers to the current unanswered questions, there will be no further questions targeted to patient or clinician, those systems SHALL provide a display item indicating that patient/clinical questions are complete.
§spec-40 | SHOULD |  | DTR Server | exchange | Wherever possible, DTR services SHOULD leverage data retrieved from CRD and other mechanisms (claims data, PDex, etc.) to pre-populate answers in the QuestionnaireResponse returned to the client (regardless of whether the forms used are adaptive or standard).
§spec-41 | SHALL | X | DTR Server | exchange | If Adaptive Forms are being used, and a DTR service determines that prior authorization is both necessary and the requirements have been satisfied, then the final question in the form SHALL be a question that asks the user if they would like the prior authorization identifier to be issued, and indicate the appropriate response options.
§spec-42 | SHALL NOT |  | DTR Server | exchange | DTR Servers SHALL NOT provide a `satisfied-pa-id` in response to a DTR invocation that was triggered by a PAS request.
§spec-43 | SHALL |  | DTR Server | exchange | DTR payers SHALL ONLY use DTR adaptive forms to return a `coverage-information` extension when:
§spec-44 | SHALL | X | DTR Client | exchange | If an adaptive QuestionnaireResponse includes an unsolicited determination that authorization requirements have been "satisfied", the EHR SHALL allow the clinician to flag the provided determination number as "not valid".
§spec-45 | SHALL | X | DTR Server | exchange | If a payer receives a new invocation of an adaptive form for the same order, they SHALL treat the result of the new completion as replacing any previous completion from a prior coverage determination process.
§spec-46 | SHALL | X | DTR Client | exchange | If a final DTR QuestionnaireResponse includes a Coverage Information extension, the DTR Client SHALL associate the Coverage Information returned with the relevant Appointment, Encounter and/or Request resources and SHALL make the information provided in the extension available to their users for viewing.
§spec-47 | SHALL |  | DTR Client | exchange | For the purpose of determining whether to update or replace, the combination of the 'coverage' reference and the `coverage-assertion-id` SHALL be treated as a primary key (i.e., if the coverage and `coverage-assertion-id` is the same, then the expectation is to replace the existing `coverage-information` repetition. If either are different then the intention is to add an additional `coverage-information` extension repetition to the list.)
§spec-48 | SHOULD NOT |  | DTR Client | exchange | When updating an existing `coverage-information` instance, all elements other than the primary key may change, except that `doc-needed` and `doc-purpose` SHOULD NOT change to remove types of documentation needed merely to reflect forms that have already been completed.
§spec-49 | SHALL | X | DTR Client | ui | If an updated `coverage-information` lists more Questionnaires to fill out then the original, DTR clients SHALL expose additional forms to the user in their typical manner.
§spec-50 | MAY |  | DTR Server | business | In some cases, if there isn't specific data that can be retrieved computably from the EHR, it MAY be sufficient for a payer to merely have an attestation by the provider that certain documentation exists, that a certain patient condition exists, or that certain actions have been completed.
§spec-51 | SHOULD | X | DTR Server | business | Payers SHOULD design questionnaires to support attestation rather than discrete data where this is sufficient for the business requirements.
§spec-52 | MAY |  | DTR Server | exchange | Questionnaires MAY also support attaching reports or other supporting documentation (e.g., images, pathology reports, etc.) where providing question answers is not sufficient.
§spec-53 | SHOULD |  | DTR Server | exchange | Payers SHOULD use the `Questionnaire.effectivePeriod` element to describe the period over which the documentation templates and rules are valid.
§spec-54 | SHALL |  | DTR Server | exchange | Questionnaires SHALL include logic that supports population from the EHR where possible.
§spec-55 | SHOULD |  | DTR Server | exchange | Such logic SHOULD rely exclusively on data elements and search parameters defined either in US Core or HRex (including simple calculations there-on - e.g., age from birthdate).
§spec-56 | SHOULD |  | DTR Server | exchange | Ideally, the design of questions in payer forms SHOULD consider what data is likely to be available for pre-population purposes, with an objective of minimizing provider data entry effort.
§spec-57 | MAY |  | DTR Client DTR Server | exchange | Due to differences in workflows or information systems, clinical information MAY be represented in different FHIR resources or with different codes or code systems.
§spec-58 | MAY |  | DTR Server | exchange | Therefore, payer CQL MAY have to examine different resources or use value sets to find patient information.
§spec-59 | SHALL |  | DTR Client | exchange | Any supplied CQL SHALL be used as the basis for pre-populating elements using data gathered from the EHR.
§spec-60 | SHALL |  | DTR Client | exchange | DTR clients SHALL handle expressions in Questionnaires denoted as either CQL or FHIRPath (which is a proper subset of CQL).
§spec-61 | SHOULD |  | DTR Server | exchange | DTR servers SHOULD identify inline expressions that are valid FHIRPath as FHIRPath rather than CQL.
§spec-62 | SHALL |  | DTR Client | ui | Prior to exposing items from the draft QuestionnaireResponse to the user for completion and/or review, the DTR client SHALL attempt to perform the SDC population of all elements having `initialExpression`, `candidateExpression` and `calculatedExpression` extensions found in the Questionnaire for any enabled elements.
§spec-63 | MAY |  | DTR Client | processing | However, clients MAY use alternative mechanisms that take into account the data requirements expressed by the CQL.
§spec-64 | SHALL |  | DTR Client | processing | Such alternative mechanisms SHALL provide pre-population that is overall at least as complete and accurate as would be achieved through CQL execution.
§spec-65 | SHALL | X | DTR Client | processing | All items that are pre-populated (whether by the payer in the initial QuestionnaireResponse provided in the questionnaire package, or from data retrieved from the EHR) SHALL have their `origin.source` set to 'auto-server' (pre-populated by Payer) or 'auto-client' (pre-populated by EHR) within the required `information-origin` extension.
§spec-66 | SHALL |  | DTR Client | processing | DTR clients SHALL iterate as necessary until a steady state is reached.
§spec-67 | SHALL | X | DTR Client | processing | If dependencies are such that a steady state cannot be reached (e.g., an item that is enabled causes a value to be set which causes a different item to be enabled, that then disables the first item…), then the Questionnaire SHALL be treated as erroneous and attempts at automatic population SHALL end, with the user being informed of that.
§spec-68 | SHALL | X | DTR Client | exchange | If executing CQL directly, the DTR client SHALL retrieve the FHIR resources specified in the `dataRequirement` section of a Library.
§spec-69 | SHOULD |  | DTR Client | processing | Queries SHOULD be constructed to minimize the retrieval of information that is not necessary to answer the relevant questions (For example, queries for medications that only require active medications should have appropriate filters to retrieve active medications and not inactive medications).
§spec-70 | SHALL |  | DTR Client | processing | DTR clients SHALL support such an incremental population of adaptive QuestionnaireResponses.
§spec-71 | SHOULD | X | DTR Client | processing | If DTR is launched using a previously saved QuestionnaireResponse, the DTR client SHOULD re-execute CQL to populate all empty elements, as well as those with an `origin.source` of 'auto-client' or 'auto-server'.
§spec-72 | SHALL NOT SHALL | X | DTR Client | processing | Any answers with an `origin.source` of 'override' or 'manual' SHALL NOT be changed, though if pre-population would have asserted a value for an answer with an `origin.source` of 'manual', the `origin.source` SHALL be changed to 'override'.
§spec-73 | SHALL | X | DTR Client | processing | When executing CQL for population, DTR clients SHALL replace payer-prepopulated data unless the results of the CQL population is an empty set.
§spec-74 | SHALL | X | DTR Client | processing | If executing CQL directly, the engine SHALL make available to the execution context all such referenced CQL Libraries.
§spec-75 | SHOULD | X | DTR Client | processing | If not executing the CQL directly, alternative processes SHOULD consider the content of referenced libraries as well.
§spec-76 | SHALL NOT | X | DTR Client | processing | If the CQL is malformed (is not syntactically correct) in any way, a client directly executing the CQL SHALL NOT attempt any execution of the malformed CQL.
§spec-77 | SHOULD | X | DTR Client | processing | Clients not executing the CQL SHOULD be tolerant of malformed CQL.
§spec-78 | SHALL |  | DTR Client | exchange processing | In either case, the client SHALL report the error to the payer using the Log Questionnaire Errors operation in addition to performing its own internal logging processes.
§spec-79 | SHALL | X | DTR Client | ui | If the CQL in the Questionnaire is only used for form population purposes, the app SHALL:
§spec-80 | MAY | X | DTR Client | processing | If the CQL also includes questionnaire logic, such as whether certain elements are enabled, or other validation rules, the DTR client (potentially in consultation with the user) MAY attempt to determine if the questionnaire is sufficiently simple that it would be reasonable to allow the user to attempt completion with potentially improperly enabled items.
§spec-81 | SHALL | X | DTR Client | ui | If this is not possible, the client SHALL notify the user that there is an issue with the questionnaire and prohibit further completion of the form.
§spec-82 | SHALL NOT |  | DTR Client | exchange | A query for data that returns no results SHALL NOT be considered a failure.
§spec-83 | SHOULD |  | DTR Server | exchange | The table below is guidance that SHOULD be used when constructing questions with coded answers:
§spec-84 | SHOULD |  | DTR Client | processing | All value set expansions SHOULD be made by using the DTR Valueset Expand (`$expand`) operation.
§spec-85 | MAY |  | DTR Server | processing | This CQL MAY query for patient observations, conditions, or other discrete information within the EHR to use as part of the population process or logic.
§spec-86 | SHOULD |  | DTR Server | processing | The mime type that SHOULD be used for a CQL Identifier is "text/cql-identifier" and CQL expressions embedded in the Questionnaire SHOULD use this type and reference CQL found in libraries rather than including CQL inline. (See supporting information here)
§spec-87 | SHALL |  | DTR Server | exchange | All Libraries needed by a questionnaire SHALL be referenced by the `cqf-library` extension and included as part of the `$questionnaire-package` operation.
§spec-88 | SHOULD MAY |  | DTR Server | exchange | CQL logic SHOULD be partitioned to be specific to groups/questions/etc., when doing so will allow it to be more efficient - though consideration should also be given to whether performing significant data gathering at the outset (even if the data is unneeded) will produce a more positive experience than intermittent data retrieval 'on demand', when such retrieval MAY introduce user-interface delays.
§spec-89 | MAY |  | DTR Client | processing | This information MAY be gathered through a series of CQL statements.
§spec-90 | SHOULD |  | DTR Server | exchange | When constructing this CQL for DTR, these statements SHOULD be nested in conditionals to first check if the patient has diabetes before checking for information dependent on that condition.
§spec-91 | SHOULD |  | DTR Server | exchange | While CQL can either be embedded inline in Expression elements or packaged in Libraries, This guide strongly recommends that implementers SHOULD place CQL logic in libraries as it is much easier to edit and debug such logic when it is all in one place, rather than when it's scattered through many different expression elements throughout the Questionnaire.
§spec-92 | SHALL |  | DTR Server | exchange | The CQL SHALL be compatible with version CQL 1.5.
§spec-93 | SHALL |  | DTR Server | exchange | CQL SHALL have a context of "Patient".
§spec-94 | SHALL |  | DTR Server | exchange | Within the Questionnaire, CQL SHALL follow SDC rules for determining context.
§spec-95 | SHALL |  | DTR Server | exchange | Within Libraries, both raw CQL and compiled ELM (in JSON syntax – i.e., application/elm+json) SHALL be provided as separate content repetitions within the library.
§spec-96 | SHALL |  | DTR Server | exchange | Within Expression elements, the base expression CQL SHALL be accompanied by an Alternative Expression Extension containing the compiled JSON ELM for the expression.
§spec-97 | SHALL | X | DTR Server | exchange | If the Questionnaire depends on multiple Libraries (has multiple `cqf-library` elements), then any `valueExpression` referring to defined variables SHALL specify the library name as well as the statement name as follows: "LibraryName".statementName.
§spec-98 | SHALL SHOULD |  | DTR Server | exchange | Library names SHALL be unique within a Questionnaire package and SHOULD be unique across all Libraries made available by the payer (e.g., "expression": "LowerLimbProsthesis".PhysicalExaminationType where LowerLimbProsthesis is the library name and PhysicalExaminationType is the expression name).
§spec-99 | SHALL |  | DTR Server | exchange | FHIR Libraries SHALL send CQL and ELM using the `content.data` element.
§spec-100 | SHOULD |  | DTR Client | exchange | CQL tools SHOULD support additional FHIRPath variables and functions that are defined within SDC.
§spec-101 | SHALL | X | DTR Client | exchange | Entities deploying SMART on FHIR DTR apps SHALL define an endpoint maintaining a list of payers currently supported by that app.
§spec-102 | SHALL |  | DTR Client | exchange | This listing of Payers SHALL conform to the DTR Supported Payers profile also published in this IG.
§spec-103 | SHALL | X | DTR Client | exchange | EHRs using external DTR apps SHALL support accessing the endpoint.
§spec-104 | SHALL |  | DTR Client | exchange | Different endpoints SHALL be defined for different versions of the application in situations where support for payers varies by application version.
§spec-105 | SHALL |  | DTR Client | exchange | It is important to note that the Payer Identifier used in this file SHALL be the same as the ones that are returned by the endpoint discovery mechanism defined in HRex.
§spec-106 | SHALL |  | DTR Client DTR Server | exchange | Accessing the endpoint will be by a simple GET with an Accept header of application/json and SHALL be performed over TLS.
§spec-107 | SHALL |  | DTR Client | exchange | The `$questionnaire-package` operation SHALL include a `coverage-assertion-id` element of the `coverage-information` as the context value.
§spec-108 | MAY | X | DTR Client | exchange | DTR MAY error if invoked with CRD `coverage-assertion-id` where the Coverage-Information did not indicate that info was needed.
§spec-109 | SHALL |  | DTR Client | exchange | The `$questionnaire-package` operation SHALL include the TRN associated with the LOINC code as the context value.
§spec-110 | SHOULD | X | DTR Client | exchange | DTR SHOULD error if it is invoked with an unrecognized TRN value or one from a PAS response that did not specify such a LOINC code.
§spec-111 | SHALL |  | DTR Client | exchange | When the DTR process is being launched, the Electronic Health Record (EHR) system and DTR process SHALL follow the procedures established by the SMART App Launch Framework - specifically the SMART App Launch Framework's EHR launch sequence.
§spec-112 | SHALL |  | DTR Client | exchange | The openId, user, and patient launch contexts SHALL be requested and provided.
§spec-113 | SHOULD |  | DTR Client | exchange | In addition, the launch context SHOULD include fhirContext references as follows:
§spec-114 | MAY | X | DTR Client | exchange | If these are not passed in as part of context, then the app MAY either raise an error or guide the user to select the needed records.
§spec-115 | MAY |  | DTR Server | exchange | Payer-provided Questionnaires MAY require access to a wide range of resources.
§spec-116 | SHALL |  | DTR Client DTR Server | exchange | At a minimum, the DTR app and the HIT server SHALL support search access to the following resources via their FHIR RESTful API using the profiles defined by or referenced by this guide:
§spec-117 | SHALL | X | DTR Client | exchange | Resources referenced from the above via Must Support elements, including transitive references, SHALL also be supported.
§spec-118 | MAY |  | DTR Client | exchange | However, apps MAY opt to be more restrictive in their access requests if they are confident that they can do so while meeting payer CQL needs and EHRs indicate this is desirable.
§spec-119 | SHALL |  | DTR Client | exchange | Regardless of the scopes asked for and granted by the user, the EHR SHALL limit access to only that data they deem appropriate for use in automatically populating payer forms, in particular restricting sensitive data.
§spec-120 | SHALL |  | DTR Server | exchange | Payers SHALL require DTR apps and EHRs connecting to their endpoint to authenticate using SMART on FHIR Backend Services.
§spec-121 | SHALL | X | DTR Client | exchange | If the launch context did not include Coverages, a QuestionnaireResponse or a Request or Encounter, the DTR appSHALL either generate an error or allow the user to search to find one to use as context for the DTR session.
§spec-122 | SHALL | X | DTR Server | exchange | The `QuestionnaireResponse.questionnaire` SHALL point to the same canonical URL as the Questionnaire provided in the package Bundle.
§spec-123 | SHALL | X | DTR Client | exchange | If any of the retrieved Questionnaires have an `effectivePeriod` that ends prior to the current date, then the DTR client SHALL change the status of any retrieved work-in-progress QuestionnaireResponses for the expired Questionnaires to 'stopped' and notify the user that the previously recorded content has expired.
§spec-124 | SHOULD | X | DTR Client | exchange | If an expired Questionnaire is retrieved when it wasn't explicitly requested by referring to a canonical version, but instead by passing in the relevant order(s) and/or context id, the DTR client SHOULD report an error to the payer.
§spec-125 | SHALL NOT |  | DTR Client | exchange | Previously completed QuestionnaireResponses SHALL NOT be used by DTR clients to complete Questionnaires received due to concerns about currency of clinical information.
§spec-126 | SHALL | X | DTR Client | exchange | When launched after CRD, the context, Request and referenced resources SHALL be present.
§spec-127 | MAY |  | DTR Client | exchange | Questionnare canonicals MAY be present.
§spec-128 | SHALL |  | DTR Server | exchange | DTR servers SHALL allow for the possibility of minor changes in the order between CRD and DTR (e.g., changes to status, adding notes, etc.) that mean that the instances don't have to be identical to be considered the same order.
§spec-129 | MAY | X | DTR Server | exchange | DTR servers MAY raise an error if they receive an order that is unrelated to the provided context id.
§spec-130 | SHALL | X | DTR Server | exchange | If DTR is invoked and there are issues with the source data (e.g., the coverage cannot be found, the context id can't be found, etc.), then the DTR service SHALL return a 4xx error with an accompanying OperationOutcome.
§spec-131 | MAY |  | DTR Client | ui | In some cases, the population process MAY populate all answers to the Questionnaire.
§spec-132 | SHALL |  | DTR Client | ui processing | The DTR client SHALL provide the ability, but NOT a requirement, for providers to review, and if necessary revise, pre-populated answers prior to saving the resulting response for subsequent use within the EHR.
§spec-133 | SHOULD |  | DTR Client DTR Server | exchange | Implementers SHOULD review the advanced rendering, advanced behavior, population and adaptive forms portions of the SDC implementation guide, focusing on the elements and extensions included in the DTR profiles.
§spec-134 | SHOULD |  | DTR Client DTR Server | exchange | Implementers SHOULD also be familiar with the documentation about the Questionnaire and QuestionnaireResponse resources from the core FHIR specification.
§spec-135 | SHALL |  | DTR Client | ui processing | All DTR applications SHALL support rendering according to the `mustSupport` elements in the DTR Questionnaire profile according to all CQL found within Questionnaire extensions.
§spec-136 | SHALL |  | DTR Client | exchange | CQL and FHIR Questionnaires SHALL be required even when DTR is implemented within a DTR Native App as opposed to a DTR SMART App.
§spec-137 | SHALL | X | DTR Client | processing | When a user fills in a value or changes an answer in a QuestionnaireResponse, the DTR client SHALL populate the `information-origin` extension, setting the `author` property to the current user, and setting `source` to 'override' if the source was already 'override', 'auto-client', 'auto-server', or 'manual' otherwise.
§spec-138 | SHALL |  | DTR Client | exchange | DTR clients SHALL either provide a PractitionerRole in the SMART App launch of DTR or support transmitting the role by means of the `activeRole` extension within the Practitioner resource.
§spec-139 | SHALL |  | DTR Server | exchange | All references within the QuestionnaireResponse SHALL only point to either contained resources or to resources that reside on the DTR client's FHIR endpoint.
§spec-140 | SHALL |  | DTR Server | exchange | The only situation where a resource can be 'contained' SHALL be if the contained instance is provided by the payer either:
§spec-141 | SHALL |  | DTR Server | exchange | The only place 'contained' resource references are permitted SHALL be in `item.answer` references.
§spec-142 | SHALL |  | DTR Client | processing | The DTR client SHALL validate the QuestionnaireResponse on an ongoing basis as the user is reviewing and entering data.
§spec-143 | SHALL |  | DTR Client | ui | The client SHALL visually flag any elements that require adjustment to meet validation rules.
§spec-144 | SHALL MAY | X | DTR Client | ui | For Standard Questionnaires, when the QuestionnaireResponse is valid, the DTR client SHALL indicate that to the user and allow them to mark the QuestionnaireResponse as complete, though the user MAY opt to continue making changes or save the QuestionnaireResponse in draft form.
§spec-145 | SHALL NOT |  | DTR Client | processing | The DTR app SHALL NOT mark a Standard QuestionnaireResponse as 'complete' automatically.
§spec-146 | SHALL NOT |  | DTR Client | ui processing | The DTR client SHALL NOT allow the user to indicate they are ready for the next question/set of questions until the answers to the current QuestionnaireResponse pass validation rules.
§spec-147 | SHALL | X | DTR Server | exchange | If `$next-question` is invoked with a QuestionnaireResponse the payer determines is invalid based on the rules in the contained Questionnaire, it SHALL return an HTTP 400 error with an OperationOutcome indicating the circumstances where the QuestionnaireResponse is invalid.
§spec-148 | MAY |  | DTR Server | exchange | However, the QuestionnaireResponse MAY have a `coverage-information` extension added reflecting the payer's coverage assessment based on the information gathered in the QuestionnaireResponse.
§spec-149 | MAY |  | DTR Client | processing | In some cases, the answer to a question modified by a user MAY be the input to an expression driving other logic within the questionnaire.
§spec-150 | SHALL |  | DTR Client | processing | DTR clients SHALL monitor for changes to dependent questionnaire answers and re-execute logic, adjusting calculatedValues, enabling elements, adjusting validation rules, etc. based on changes made by the user.
§spec-151 | SHALL |  | DTR Client | processing storage | At any point prior to completion a DTR client SHALL be able to save the `in-progress` QuestionnaireResponse, both to ensure that work-in-progress is not lost, and to allow the user to close the session and then relaunch it later.
§spec-152 | SHALL | X | DTR Client | storage | When the QuestionnaireResponse has been marked as `completed`, the DTR client SHALL save the QuestionnaireResponse to the EHR.
§spec-153 | SHALL | X | DTR Client | processing storage | A DTR SMART App SHALL 'create' the record if it had not previously been stored, or 'update' if the record had already been saved at least once via the FHIR API.
§spec-154 | SHALL |  | DTR Client | processing | Upon storing a completed QuestionnaireResponse with one or more `coverage-information` extensions, the EHR SHALL propagate the `coverage-information` extensions to all non-Coverage resources included on the `qr-context` extension on the QuestionnaireResponse.
§spec-155 | SHALL | X | DTR Client | processing | If a `coverage-information` already exists on the target resource with the same `coverage-information.coverage` or `coverage-information.coverage-assertion-id`, it SHALL be overridden.
§spec-156 | SHALL |  | DTR Client | exchange | In those cases where a QuestionnaireResponse is to be used to convey information either to the payer or to downstream service providers, the DTR Client SHALL place the QuestionnaireResponse in a 'collection' Bundle complying with the questionnaireResponseBundle profile.
§spec-157 | SHALL |  | DTR Client | exchange | This Bundle SHALL include no more than one QuestionnaireResponse entry and it SHALL be the initial entry.
§spec-158 | SHALL |  | DTR Client | exchange | The bundle SHALL also include any resources that are referenced by the QuestionnaireResponse as answerReference that are not already contained within the QuestionnaireResponse.
§spec-159 | SHALL | X | DTR Server | exchange | If the initial `QuestionnaireResponse` has multiple purposes (e.g., for prior authorization, claim submission, and performer transmission), the DTR server organization SHALL ensure that the full completed QuestionnaireResponse package is appropriate for all uses. If there is a need to send different information to different recipients for different purposes, the DTR server organization SHALL produce distinct Questionnaires such that QuestionnaireResponses only contain information that can be shared without redaction for their listed purposes.
§spec-160 | SHALL | X | DTR Server | exchange | Such resources SHALL either be PDFs or XHTML pages that adhere to FHIR's 'safe' HTML rules (no active content or scripts)
§spec-161 | MAY |  | DTR Server | business | Some payers MAY require that attestations or other answers be 'signed' (the electronic equivalent of 'initialing' the answer).
§spec-162 | SHOULD | X | DTR Client | processing | The DTR client SHOULD use result caching so that results queried by CQL (or otherwise retrieved based on CQL) previously remain available after a subsequent call to $next-question.
§spec-163 | SHOULD NOT SHOULD |  | DTR Client | exchange | These value sets SHOULD be expanded by the client and therefore SHOULD NOT be included in the questionnaire package.
§spec-164 | SHOULD |  | DTR Server | exchange | Payers SHOULD design their questionnaires, value sets, and libraries with the knowledge that content which is too large may cause DTR clients to fail.
§spec-165 | SHALL NOT | X | DTR Server | exchange | Such contained Binary pages SHALL NOT point to other contained resources unless those resources are pointed to directly by other elements in the Questionnaire.
§spec-166 | MAY | X | DTR Server | exchange | Implementers MAY embed images or other content using the 'data' mechanism, or may opt to combine multiple files into a single instance to eliminate the need for inter-linking.