This page is part of the Documentation Templates and Rules (v2.1.0-preview: QA Preview) based on FHIR (HL7® FHIR® Standard) R4. The current version which supersedes this version is 2.0.1. For a full list of available versions, see the Directory of published versions
Page standards status: Trial-use |
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
There are no Global profiles defined
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 USCDI 1 |
This statement defines the expected capabilities of payer systems that provide questionnaires to DTR clients for USCDI 1 (US-Core 3.1.1). Such systems need only support server capabilities for the Questionnaire Package, ValueSet Expand, and Next Question operations. |
DTR Payer Service USCDI 3 |
This statement defines the expected capabilities of payer systems that provide questionnaires to DTR clients for USCDI 3 (US-Core 6.1). 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 |
This statement defines the expected capabilities of EHRs that manage the form filling functions of DTR internally for USCDI 3 (US-Core 6.1). 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 |
This statement defines the expected capabilities of EHRs that rely on a SMART on FHIR application for USCDI 3 (US-Core 6.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. |
SMART DTR Client USCDI 1 |
This statement defines the expected capabilities of DTR SMART on FHIR applications for USCDI 1 (US-Core 3.1.1). 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. |
SMART DTR Client USCDI 3 |
This statement defines the expected capabilities of DTR SMART on FHIR applications for USCDI 3 (US-Core 6.1.0). 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. |
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 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. |
These define the properties by which a RESTful server can be searched. They can also be used for sorting and including related resources.
dtr-context |
Returns order(s) with a context extension matching the specified order. |
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. |
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 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. |
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 for adaptive form |
The DTR Adaptive Questionnaire is used to represent an adaptive Questionnaire when actually filling out a QuestionnaireResponse. |
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. |
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. |
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 |
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. |
Questionnaire Response Context |
Identifies the orders, coverages, 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. |
These define sets of codes used by systems conforming to this 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. |
These define new code systems used by systems conforming to this implementation guide.
DTR Temporary Codes |
Codes temporarily defined as part of the DTR implementation guide. These will eventually migrate into an officially maintained terminology (likely HL7's UTG code systems). |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
AdaptiveSearchExample |
An example adaptive form search instance. |
CoverageExample |
An instance of CRD Coverage |
DTRQuestionnairePackageOperationResultComplex |
An example of DTRQuestionnairePackageOperation returning a Bundle with only a multiple questionnaires, with references to other Library and ValueSet resources |
Home Oxygen Therapy Order Template |
An example Standard questionnaire for Home Oxygen Therapy. |
LogQuestionnaireErrorsInputParamsExample |
An example instance of Input Parameters that are supplied to the Log Questionnaire Errors operation. |
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 - Simple |
An example of DTRQuestionnairePackageOperation returning a Parameters instance containing multiple Questionnaire bundles, each with references to other Library and ValueSet resources. |
QuestionnairePackageInputParamsExample |
An example instance of Input Parameters for the QuestionnairePackage operation. |
QuestionnairePackageOutputParamsExample |
An example instance of Output Parameters for the QuestionnairePackage operation. |
ServiceRequestExample |
Example of ServiceRequest used in the Home Oxygen Therapy (home-o2-questionnaireresponse) example |
home-o2-adaptive-questionnaireresponse |
An example QuestionnaireResponse for Adaptive Questionnaire. |
home-o2-questionnairepackage-bundle |
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. |
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 |