Da Vinci - Documentation Templates and Rules
2.2.0 - STU 2.2

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

## Artifact List

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

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

### Global Profiles

There are no Global profiles defined

### Terminology Parameters

Parameter | Value
--- | ---
profile-url | dc8fd4bd-091a-424a-8a3b-6198ef136891
system-version | SNOMED CT[US]

### Requirements: Actor Definitions

The following artifacts define the types of individuals and/or systems that will interact as part of the use cases covered by this implementation guide.

DTR Client | An app that communicates with a Payer's DTR Server.
DTR Server | A Payer server that provides DTR services to a client.

### Requirements: Formal Requirements

The following artifacts describe the specific requirements to be met by systems compliant with the implementation guide.

Narrative Conformance Statements | Conformance statements found throughout the narrative of the IG consolidated into this computable resource for traceability purposes

### Behavior: Capability Statements

The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.

DTR Payer Service | This capability statement defines the expected capabilities of payer systems that provide questionnaires to DTR clients. Such systems need only support server capabilities for the Questionnaire Package, ValueSet Expand, and Next Question operations.
Full DTR EHR - USCDI 1 | This statement defines the expected capabilities of EHRs that manage the form filling functions of DTR internally for USCDI 1 (US-Core 3.1.1). Such EHRs need only support client capabilities for the Questionnaire Package, ValueSet Expand, and Next Question operations.
Full DTR EHR - USCDI 3 & 4 | This statement defines the expected capabilities of EHRs that manage the form filling functions of DTR internally for USCDI 3 (US-Core 6.1) and USCDI 4 (US-Core 7.0). Such EHRs need only support client capabilities for the Questionnaire Package, ValueSet Expand, and Next Question operations.
Light DTR EHR - USCDI 1 | This statement defines the expected capabilities of EHRs that rely on a SMART on FHIR application for USCDI 1 (US-Core 3.1.1) to handle the form filling function of DTR. This requires the server to provide access to the specified resources to allow such an app to retrieve and edit QuestionnaireResponses and related resources.
Light DTR EHR - USCDI 3 & 4 | This statement defines the expected capabilities of EHRs that rely on a SMART on FHIR application for USCDI 3 (US-Core 6.1) and USCDI 4 (US-Core 7.0) to handle the form filling function of DTR. This requires the server to provide access to the specified resources to allow such an app to retrieve and edit QuestionnaireResponses and related resources.
SMART DTR Client | This statement defines the expected capabilities of DTR SMART on FHIR applications. Such apps require client support for retrieving and editing QuestionnaireResponse resources and related resources, as well as client support for the Questionnaire Package, ValueSet Expand, and Next Question operations.

### Behavior: Operation Definitions

These are custom operations that can be supported by and/or invoked by systems conforming to this implementation guide.

DTR Log Questionnaire Errors | The operation will pass a Questionnaire reference and an OperationOutcome detailing the issue(s) including where the error occurred back to the originating Payer.
DTR Next Question Operation | The Next Question operation is used for adaptive questionnaires. For specific details, see the SDC Next Question operation.
DTR Questionnaire Package | This operation returns a collection Bundle containing one or more Questionnaire-specific collection Bundles each consisting of a single Questionnaire resource as well as any dependency Library and ValueSet instances needed to allow a renderer to fully render and otherwise process the Questionnaire.
DTR Value Set Expansion | The definition of a value set is used to create a simple collection of codes suitable for use for data entry or validation. 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. An expanded value set will be returned, or an OperationOutcome with an error message. For more details regarding this operation, see the FHIR R4 `$expand` operation definition.

### Behavior: Search Parameters

These define the properties by which a RESTful server can be searched. They can also be used for sorting and including related resources.

qr-context | Allows finding QuestionnaireResponses that contain information relevant to a particular appointment, encounter or order.

### Structures: Logical Models

These define data models that represent the domain covered by this implementation guide in more business-friendly terms than the underlying FHIR resources.

DTR Metric Data | A logical model describing the information that should be captured by DTR implementers about every DTR invocation to support measures evaluating DTR implementation.

### Structures: Abstract Profiles

These are profiles on resources or data types that describe patterns used by other profiles but cannot be instantiated directly. I.e. instances can conform to profiles based on these abstract profiles, but do not declare conformance to the abstract profiles themselves.

DTR Base Questionnaire | Takes a subset of extensions and constraints from the SDC rendering, behavior, and population profiles, reflecting agreed expectations around which data elements might be relevant as well as which must be supported for DTR purposes.

### Structures: Resource Profiles

These define constraints on FHIR resources for systems conforming to this implementation guide.

DTR Log Questionnaire Errors Input Parameters | The Parameters profile used to define the inputs to the $log-questionnaire-errors operation.
DTR Next Question Input Parameters | Profile used to validate the parameters that are the input of the 'next question' adaptive questionnaire operation
DTR Next Question Output Parameters | Profile used to validate the parameters that are the output of the 'next question' adaptive questionnaire operation
DTR Questionnaire Package Bundle | This profile represents the Bundle of Questionnaires and Libraries returned in a $questionnaire-package response.
DTR Questionnaire Package Input Parameters | The Parameters profile used to define the inputs of the $questionnaire-package operation (also see 'Retrieving Questionnaire Packages'). If both orders and a context id are present, then the context id can be used to link to additional information retrieved during CRD and to expedite re-processing of which Questionnaires are needed. 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. If specific Questionnaires are requested as part of the DTR invocation, such additional checking is not expected.
DTR Questionnaire Package Output Parameters | A profile on Parameters indicating the expected response content of a $questionnaire-package operation.
DTR Questionnaire Response | Enforces DTR requirements on a completed or partially completed QuestionnaireResponse, including allowing the response to be linked to the relevant order, coverage, etc. and enforcing constraints applicable to the DTR context.
DTR Questionnaire Response Bundle | This profile represents the Bundle created by EHRs for transmission of a QuestionnaireResponse and associated resources to PAS, for claim submission, etc..
DTR Questionnaire Response for adaptive form | Enforces DTR requirements on a completed or partially completed Adaptive QuestionnaireResponse, including allowing the response to be linked to the relevant order, coverage, etc. and enforcing constraints applicable to the DTR context.
DTR Questionnaire for adaptive form | The DTR Adaptive Questionnaire is used to represent an adaptive Questionnaire when actually filling out a QuestionnaireResponse. NOTE: This profile does not realistically need the `questionnaireAdaptive` extension, but will remain intact due to potential impacts on Structured Data Capture (SDC) requirements. (Efforts will be made in an attempt to get the SDC requirements on this extension loosened in a future release)
DTR Questionnaire for adaptive form Search | The DTR adaptive Questionnaire is used to represent an adaptive Questionnaire when returning the empty Questionnaire in a Questionnaire package.
DTR Standard Questionnaire | Takes a subset of extensions and constraints from the SDC rendering, behavior, and population profiles, reflecting agreed expectations around which data elements might be relevant as well as which must be supported for DTR purposes.
DTR Supported Payers | A listing of payer organizations currently supported by the DTR app. The Payer Identifier used SHALL be the same as the ones that are returned by the endpoint discovery mechanism defined in HRex.

### Structures: Extension Definitions

These define constraints on FHIR data types for systems conforming to this implementation guide.

Active Role | An extension to indicate the active role(s) a practitioner is currently functioning in.
Alternative Expression | Provides an alternate expression containing the compiled JSON ELM for an expression. (NOTE: The expectation is that this extension will transition to the core extensions pack)
Contained Reference | Indicates that when filling a QuestionnaireResponse and selecting a reference, that the referenced resource should be included as a 'contained' resource within the QuestionnaireResponse
Estimated Completion Time | Provides information about the typical completion time for the form. (Refer to the Guidelines for estimated time to complete a DTR questionnaire)
Information Origin | Identifies the origin of the information in the answer and how it came to exist.
Intended Use | Indicates how the EHR is to use the information with respect to the associated orders/records. If the Adaptive QuestionnaireResponse includes a prior authorization number the `intendedUse` element should be set to 'retain-doc' and/or 'withorder'.
Questionnaire Audience | Provides a code to express the intended audience for the Questionnaire form.
Questionnaire Response Context | Identifies the orders and/or other resources associated with the specified QuestionnaireResponse. Allows finding the DTR responses associated with a particular Order/Encounter/Appointment for a particular insurance coverage.
Questionnaire Response Coverage | Identifies the coverages associated with the specified QuestionnaireResponse.
Request Specific Flag | If this flag is 'true' then a distinct QuestionnaireResponse is needed for each request where that Questionnaire is solicited. If false, then a single QuestionnaireResponse can be used across all requests where the specified Questionnaire url and version was solicited. (i.e., You can fill out the form once and re-use rather than completing multiple times. Typically, re-use of a form is limited to the scope of a single encounter)

### Terminology: Value Sets

These define sets of codes used by systems conforming to this implementation guide.

Audience Value Set | Codes defining audience of additional documentation to be captured
Conformance Statement Categories | Categories for conformance statements found in the DTR Implementation Guide
Information Human Origins Value Set | Questionnaire actions taken by human actors.
Information Origins Value Set | Codes describing the possible origination of information.
Metric Action | A list of codes indicating the DTR action performed by a system.
Metric Launch Mode | A list of codes indicating how DTR was launched.
Metric Source | A list of codes indicating the perspective from which metric data was captured.
Questionnaire Completion Time Value Set | Codes defining estimated completion times for a Questionnaire

### Terminology: Code Systems

These define new code systems used by systems conforming to this implementation guide.

DTR Completion Time Codes | Codes used within the Competion Time valueset.
DTR Conformance Statement Categories | Codes that help to categorize requirements statements
DTR Information Origin Codes | Codes used within the Information Origin valueset.
DTR Intended Audience Codes | Codes defining audience of additional documentation to be captured.
DTR Metric Codes | Codes used within 'code' elements in the DTR Metric logical model.

### Example: Example Instances

These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.

$log-questionnaire-errors Input Parameters Example | An example instance of Input Parameters that are supplied to the Log Questionnaire Errors operation.
$next-question Input Parameters Example | An example instance of input Parameters used by the Next Question operation.
$next-question Output Parameters Example | An example instance of output Parameters used by the Next Question operation.
$questionnaire-package Input Parameters Example | An example instance of Input Parameters for the QuestionnairePackage operation.
$questionnaire-package Output Parameters Example | An example instance of Output Parameters for the QuestionnairePackage operation.
AdaptiveSearchExample | An example Adaptive Form search instance.
CoverageExample | An instance of CRD Coverage
Home Oxygen Therapy Order Template | An example Standard questionnaire for Home Oxygen Therapy.
PatientExample | An example patient used in the example resources.
PractitionerExample | An example practitioner referred to by the example resources.
QUICK Model Definition | A sample library from the FHIR core spec to include in other examples in this IG to demonstrate the use of Library resources
Questionnaire Package Operation Results - Complex | An example of DTRQuestionnairePackageOperation returning a Bundle with only a multiple questionnaires, with references to other Library and ValueSet resources
Questionnaire Package Operation Results - Simple | An example of DTRQuestionnairePackageOperation returning a Parameters instance containing multiple Questionnaire bundles, each with references to other Library and ValueSet resources.
Referred Questionnaire for QuestionnaireResponse | Inline Questionnaire for QuestionnaireResponse
ServiceRequestExample | Example of ServiceRequest used in the Home Oxygen Therapy (home-o2-questionnaireresponse) example
Simple Questionnaire | An example base questionnaire.
SupportedPayers | An instance of Supported Payers list used in the example resources.
home-o2-adaptive-questionnaireresponse | An example QuestionnaireResponse for Adaptive Questionnaire.
home-o2-questionnairepackage-bundle | An example QuestionnaireResponseBundle for Home Oxygen Therapy.
home-o2-questionnairepackage-bundle-2 | An example QuestionnaireResponseBundle for Home Oxygen Therapy.
home-o2-questionnaireresponse | An example QuestionnaireResponse for Home Oxygen Therapy.
home-o2-questionnaireresponse-bundle | An example QuestionnaireResponseBundle for Home Oxygen Therapy.

### Other

These are resources that are used within this implementation guide that do not fit into one of the other categories.

Parameters - SNOMED US Version | Parameters - SNOMED US Version