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:

Da Vinci DTR implementations SHALL conform to the HRex and US Core Guidance where applicable.

DTR apps and EHRs that take on DTR app responsibility SHALL be able to render Questionnaires and QuestionnaireResponses.

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

Specifically, apps and EHRs acting as form fillers SHALL be able to display:

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

Those same systems SHOULD be able to display QuestionnaireResponse.item.itemMedia

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.

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.

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.

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.

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.

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.

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.

Such enhancements SHALL be submitted as a ticket for consideration for inclusion in a future version of the implementation guide.

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)

SHOULD be clinical questions but might include administrative questions if necessary to select appropriate clinical questions.

This operation SHALL be supported by payers and DTR applications.

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.

The Questionnaire reference SHOULD be version-specific.

The operation is called at the resource level and a url SHALL be provided.

Additionally, the valueset SHALL use the current date as the expansion date and SHALL include only active codes.

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:

If multiple versions of a questionnaire are returned, each SHALL be associated with distinct orders or coverages in the associated QuestionnaireResponses (see below).

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.

If any of the explicitly requested questionnaires cannot be found, a warning SHALL be provided in the Outcome element of the outer Parameters resource.

If the operation is successful, the response SHALL be a Parameters resource conformant to the DTRQuestionnairePackageOutputParameters profile.

If the operation fails, the response payload SHOULD be an OperationOutcome.

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

All Libraries SHALL include both CQL and EML representations.

The Bundle SHALL include all external ValueSet instances referenced by the Questionnaire.

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.

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.

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.

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.

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.

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.

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.

The Payer Identifier used SHALL be the same as the ones that are returned by the endpoint discovery mechanism defined in HRex.

Implementers SHALL adhere to any security and privacy rules defined by:

This scope granted MAY provide the SMART on FHIR application access to more data than is needed for the specific situation.

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

Compliant Questionnaires SHALL NOT include hidden or read-only questions where the data is populated from the EHR.

DTR Clients SHALL appropriately manage access to data that is sensitive per policy and regulatory requirements when responding to queries from a DTR app.

Providers SHOULD ask the patient if they want to share the information with the payer prior to manually populating it in any QuestionnaireResponses.

Any EHR with SMART on FHIR support SHOULD be prepared to deal with the implications of providing a client with the scopes they request.

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.

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.

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:

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.

This means that EHRs are free to choose which app they prefer and MAY switch apps as they see fit.

In some cases, an EHR MAY opt to support multiple DTR SMART apps.

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.

Payers MAY have multiple back-end functions that handle different types of decision support and/or different types of services.

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.

This registration process SHALL ensure that the DTR app or Full EHR (i.e., Native App):

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.

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.

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

The expectations around licensing requirements SHALL be established as part of the configuration process between the parties.

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')

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.

DTR clients SHALL NOT be dependent on such pre-availability in order to perform form completion.

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.

DTR apps and Full EHRs SHALL support both types of Questionnaires.

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.

When using elements with a data type of 'Expression' within Questionnaires to control flow or rendering, all logic SHALL be written in CQL.

The Elements flagged as mustSupport SHALL be supported by DTR Apps and Full EHRs.

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.

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

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:

When a payer uses an Adaptive Form, they SHALL return a questionnaire instance compliant with the DTR AdaptiveQuestionnaire-Search profile.

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.

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.

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.

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.

There are three strategies payers can use – and payers MAY opt to combine strategies within a single Questionnaire:

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.

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.

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.

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.

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')

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.

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.

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.

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.

Conformant systems SHALL meet these timing expectations at least 90% of the time.

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.

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

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.

DTR Servers SHALL NOT provide a satisfied-pa-id in response to a DTR invocation that was triggered by a PAS request.

DTR payers SHALL ONLY use DTR adaptive forms to return a coverage-information extension when:

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

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.

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.

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

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.

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.

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.

Payers SHOULD design questionnaires to support attestation rather than discrete data where this is sufficient for the business requirements.

Questionnaires MAY also support attaching reports or other supporting documentation (e.g., images, pathology reports, etc.) where providing question answers is not sufficient.

Payers SHOULD use the Questionnaire.effectivePeriod element to describe the period over which the documentation templates and rules are valid.

Questionnaires SHALL include logic that supports population from the EHR where possible.

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

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.

Due to differences in workflows or information systems, clinical information MAY be represented in different FHIR resources or with different codes or code systems.

Therefore, payer CQL MAY have to examine different resources or use value sets to find patient information.

Any supplied CQL SHALL be used as the basis for pre-populating elements using data gathered from the EHR.

DTR clients SHALL handle expressions in Questionnaires denoted as either CQL or FHIRPath (which is a proper subset of CQL).

DTR servers SHOULD identify inline expressions that are valid FHIRPath as FHIRPath rather than CQL.

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.

However, clients MAY use alternative mechanisms that take into account the data requirements expressed by the CQL.

Such alternative mechanisms SHALL provide pre-population that is overall at least as complete and accurate as would be achieved through CQL execution.

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.

DTR clients SHALL iterate as necessary until a steady state is reached.

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.

If executing CQL directly, the DTR client SHALL retrieve the FHIR resources specified in the dataRequirement section of a Library.

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

DTR clients SHALL support such an incremental population of adaptive QuestionnaireResponses.

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

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

When executing CQL for population, DTR clients SHALL replace payer-prepopulated data unless the results of the CQL population is an empty set.

If executing CQL directly, the engine SHALL make available to the execution context all such referenced CQL Libraries.

If not executing the CQL directly, alternative processes SHOULD consider the content of referenced libraries as well.

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.

Clients not executing the CQL SHOULD be tolerant of malformed CQL.

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.

If the CQL in the Questionnaire is only used for form population purposes, the app SHALL:

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.

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.

A query for data that returns no results SHALL NOT be considered a failure.

The table below is guidance that SHOULD be used when constructing questions with coded answers:

All value set expansions SHOULD be made by using the DTR Valueset Expand ($expand) operation.

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.

The mime type that SHOULD be used for a CQL Identifier is "text/cql-identifier" and CQL expressions embedded in the Questionnaire SHOULD use this type and reference CQL found in libraries rather than including CQL inline. (See supporting information here)

All Libraries needed by a questionnaire SHALL be referenced by the cqf-library extension and included as part of the $questionnaire-package operation.

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.

This information MAY be gathered through a series of CQL statements.

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.

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.

The CQL SHALL be compatible with version CQL 1.5.

CQL SHALL have a context of "Patient".

Within the Questionnaire, CQL SHALL follow SDC rules for determining context.

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.

Within Expression elements, the base expression CQL SHALL be accompanied by an Alternative Expression Extension containing the compiled JSON ELM for the expression.

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.

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

FHIR Libraries SHALL send CQL and ELM using the content.data element.

CQL tools SHOULD support additional FHIRPath variables and functions that are defined within SDC.

Entities deploying SMART on FHIR DTR apps SHALL define an endpoint maintaining a list of payers currently supported by that app.

This listing of Payers SHALL conform to the DTR Supported Payers profile also published in this IG.

EHRs using external DTR apps SHALL support accessing the endpoint.

Different endpoints SHALL be defined for different versions of the application in situations where support for payers varies by application version.

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.

Accessing the endpoint will be by a simple GET with an Accept header of application/json and SHALL be performed over TLS.

The $questionnaire-package operation SHALL include a coverage-assertion-id element of the coverage-information as the context value.

DTR MAY error if invoked with CRD coverage-assertion-id where the Coverage-Information did not indicate that info was needed.

The $questionnaire-package operation SHALL include the TRN associated with the LOINC code as the context value.

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.

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.

The openId, user, and patient launch contexts SHALL be requested and provided.

In addition, the launch context SHOULD include fhirContext references as follows:

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.

Payer-provided Questionnaires MAY require access to a wide range of resources.

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:

Resources referenced from the above via Must Support elements, including transitive references, SHALL also be supported.

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.

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.

Payers SHALL require DTR apps and EHRs connecting to their endpoint to authenticate using SMART on FHIR Backend Services.

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.

The QuestionnaireResponse.questionnaire SHALL point to the same canonical URL as the Questionnaire provided in the package Bundle.

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.

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.

Previously completed QuestionnaireResponses SHALL NOT be used by DTR clients to complete Questionnaires received due to concerns about currency of clinical information.

When launched after CRD, the context, Request and referenced resources SHALL be present.

Questionnare canonicals MAY be present.

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.

DTR servers MAY raise an error if they receive an order that is unrelated to the provided context id.

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.

In some cases, the population process MAY populate all answers to the Questionnaire.

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.

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.

Implementers SHOULD also be familiar with the documentation about the Questionnaire and QuestionnaireResponse resources from the core FHIR specification.

All DTR applications SHALL support rendering according to the mustSupport elements in the DTR Questionnaire profile according to all CQL found within Questionnaire extensions.

CQL and FHIR Questionnaires SHALL be required even when DTR is implemented within a DTR Native App as opposed to a DTR SMART App.

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.

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.

All references within the QuestionnaireResponse SHALL only point to either contained resources or to resources that reside on the DTR client's FHIR endpoint.

The only situation where a resource can be 'contained' SHALL be if the contained instance is provided by the payer either:

The only place 'contained' resource references are permitted SHALL be in item.answer references.

The DTR client SHALL validate the QuestionnaireResponse on an ongoing basis as the user is reviewing and entering data.

The client SHALL visually flag any elements that require adjustment to meet validation rules.

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.

The DTR app SHALL NOT mark a Standard QuestionnaireResponse as 'complete' automatically.

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.

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.

However, the QuestionnaireResponse MAY have a coverage-information extension added reflecting the payer's coverage assessment based on the information gathered in the QuestionnaireResponse.

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.

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.

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.

When the QuestionnaireResponse has been marked as completed, the DTR client SHALL save the QuestionnaireResponse to the EHR.

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.

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.

If a coverage-information already exists on the target resource with the same coverage-information.coverage or coverage-information.coverage-assertion-id, it SHALL be overridden.

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.

This Bundle SHALL include no more than one QuestionnaireResponse entry and it SHALL be the initial entry.

The bundle SHALL also include any resources that are referenced by the QuestionnaireResponse as answerReference that are not already contained within the QuestionnaireResponse.

If the initial QuestionnaireResponse has multiple purposes (e.g., for prior authorization, claim submission, and performer transmission), the DTR server organization SHALL ensure that the full completed QuestionnaireResponse package is appropriate for all uses. If there is a need to send different information to different recipients for different purposes, the DTR server organization SHALL produce distinct Questionnaires such that QuestionnaireResponses only contain information that can be shared without redaction for their listed purposes.

Such resources SHALL either be PDFs or XHTML pages that adhere to FHIR's 'safe' HTML rules (no active content or scripts)

Some payers MAY require that attestations or other answers be 'signed' (the electronic equivalent of 'initialing' the answer).

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.

These value sets SHOULD be expanded by the client and therefore SHOULD NOT be included in the questionnaire package.

Payers SHOULD design their questionnaires, value sets, and libraries with the knowledge that content which is too large may cause DTR clients to fail.

Such contained Binary pages SHALL NOT point to other contained resources unless those resources are pointed to directly by other elements in the Questionnaire.

Implementers MAY embed images or other content using the 'data' mechanism, or may opt to combine multiple files into a single instance to eliminate the need for inter-linking.