Conformance Expectations

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-snapshot 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

Page standards status: Trial-use

Highlight text changes?

Conformance to this Implementation Guide
MustSupport
Interoperability Expectations
Conformance Details

This implementation guide uses specific terminology such as SHALL, SHOULD, MAY to flag statements that have relevance for the evaluation of conformance with the guide. 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 and general Da Vinci-wide expectations are defined in HRex.

Additional conformance expectations specific to this guide are as follows:

Conformance to this Implementation Guide

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-1

Light DTR EHR (for US Core 3.1.1 / US Core 6.1/7.0)
Full DTR EHR (for US Core 3.1.1 / US Core 6.1/7.0)
SMART DTR Client
DTR Payer Service

MustSupport

This IG marks elements with the Must Support flag in its profiles. In addition to the expectations provided in the HRex section referenced above, the following additional considerations apply:

The FHIR specification makes it clear that when profiling another profile, a MustSupport flag can be constrained further (i.e., taken from 'false' to 'true') but cannot be loosened (i.e., changed from 'true' to 'false').

Da Vinci DTR implementations SHALL conform to the HRex and US Core Guidance where applicable. ^§conf-2

DTR apps and EHRs that take on DTR app responsibility SHALL be able to render Questionnaires and QuestionnaireResponses. ^§conf-3 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-4 Specifically, apps and EHRs acting as form fillers SHALL be able to display: ^§conf-5

QuestionnaireResponse.questionnaire.questionnaireDisplay/Questionnaire.title
QuestionnaireResponse.authored
QuestionnaireResponse.author.resolve().name
QuestionnaireResponse.source.resolve().name
QuestionnaireResponse.item.text
QuestionnaireResponse.item.value - all data types
The same for all nested items

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-6

Those same systems SHOULD be able to display QuestionnaireResponse.item.itemMedia ^§conf-7

Interoperability Expectations

For the DTR specification to work successfully at scale, it is essential that DTR clients and servers be able to interoperate with each other without custom expectations or deviations driven by EHR-specific or payer-specific requirements. The following rules are intended to help drive such consistency:

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-8 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-9
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-10
In the event a need to communicate data structures or elements not covered as required or mustSupport in the specification, the organization identifying the requirement are expected to submit change requests proposing adding the relevant profiles and/or mustSupport elements to a future version of the DTR specification. 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-11
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-12
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-13 (If an organization believes they have a requirement for a data element not marked as mustSupport in the DTR or inherited profiles, they should raise the requirement for discussion on the DTR stream on chat.fhir.org.)
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-14

This guidance does not prevent trading partners from agreeing to exchange additional information as long as the implementation does not prevent transactions compliant with the implementation guide from being appropriately processed. Such enhancements SHALL be submitted as a ticket for consideration for inclusion in a future version of the implementation guide. ^§conf-15

Conformance Details

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:

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

Id Expectation Conditional? CSTABLE_HEAD_ACTOR CSTABLE_HEAD_CAT 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 system level and a url SHALL be provided.

§oper-5 SHALL DTR Client 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 Client 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 Client 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 Client 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 Client 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 business This registration process SHALL ensure that the DTR app or Full EHR (i.e., Native App):

§spec-8 SHOULD DTR Client 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 Client 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 Client 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 Client 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 descriptions 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 Client 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 Client 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 Client
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 Client 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 Client 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 Client 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 Client 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 Client 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 Client 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 Client 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 Client 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 Client 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".

§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 Server 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 Server 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-ids where the Coverage-Information did not indicate that info was needed.

§spec-109 SHALL DTR Server 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
DTR Server 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 Client 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 app SHALL 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 Client exchange If a QuestionnaireResponse is returned, 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 supported 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 Client 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. Conformance with DTR requires conformance with the relevant portions of the SDC implementation guide.

§spec-135 SHALL DTR Client ui
processing All DTR applications SHALL support rendering according to the mustSupport elements in the DTR Questionnaire profile as well as executing 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 Client 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 Client 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, 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 Client exchange If there is a desire to send different content to different recipients, then distinct QuestionnaireResponses SHALL be used.

§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.

Id	Expectation	Conditional?	CSTABLE_HEAD_ACTOR	CSTABLE_HEAD_CAT	Rule
§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 system level and a url SHALL be provided.
§oper-5	SHALL		DTR Client	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 Client	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 Client	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 Client	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 Client	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	business	This registration process SHALL ensure that the DTR app or Full EHR (i.e., Native App):
§spec-8	SHOULD		DTR Client	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 Client	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 Client	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 Client	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 descriptions 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 Client	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 Client	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 Client 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 Client	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 Client	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 Client	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 Client	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 Client	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 Client	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 Client	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 Client	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 Client	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".
§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 Server	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 Server	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-ids where the Coverage-Information did not indicate that info was needed.
§spec-109	SHALL		DTR Server	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 DTR Server	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 Client	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 app SHALL 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 Client	exchange	If a QuestionnaireResponse is returned, 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 supported 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 Client	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. Conformance with DTR requires conformance with the relevant portions of the SDC implementation guide.
§spec-135	SHALL		DTR Client	ui processing	All DTR applications SHALL support rendering according to the `mustSupport` elements in the DTR Questionnaire profile as well as executing 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 Client	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 Client	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`, 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 Client	exchange	If there is a desire to send different content to different recipients, then distinct QuestionnaireResponses SHALL be used.
§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.