Da Vinci - Documentation Templates and Rules
2.1.0 - STU 2.1 United States of America flag

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

CapabilityStatement: Light DTR EHR - USCDI 1

Official URL: http://hl7.org/fhir/us/davinci-dtr/CapabilityStatement/light-dtr-ehr-311 Version: 2.1.0
Standards status: Trial-use Maturity Level: 2 Computable Name: LightDTREHR

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.

Raw OpenAPI-Swagger Definition file | Download

Light DTR EHR

  • Official URL:http://hl7.org/fhir/us/davinci-dtr/CapabilityStatement/light-dtr-ehr-311
  • Implementation Guide Version: 2.1.0-preview
  • FHIR Version: 4.0.1
  • Intended Use: Requirements
  • Supported Formats: JSON
  • Published: 2024-08-02
  • Published by: HL7 International / Clinical Decision Support
  • Status: Active

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.

Include And Support Everything In The Following CapabilityStatements:

FHIR Server RESTful Capabilities

EHR systems which leverage a SMART app to manage data capture and rules execution, but which must be able to launch the SMART app.

Security:

Implementations SHALL meet the general security requirements documented in the HRex implementation guide.

RESTful Capabilities by Resource/Profile:

Summary

♦ = SHALL expectation;⋄ = SHOULD expectation;▿ = MAY expectation;

Resource TypeSupported InteractionsSupported ProfilesSupported SearchesSupported _includesSupported _revincludesSupported Operations
QuestionnaireResponseread♦, create♦, update♦, search-type♦ DTR Questionnaire Response context♦, patient♦
Encounterread⋄ CRD Encounter
DeviceRequestread⋄ CRD Device Request
MedicationRequestread⋄ CRD Medication Request
NutritionOrderread⋄ CRD Nutrition Order
CommunicationRequestread⋄ CRD Communication Request
ServiceRequestread⋄ CRD Service Request
VisionPrescriptionread⋄ CRD Vision Prescription
Taskread⋄, create⋄, update⋄ PAS Task Profile

QuestionnaireResponse

Supported Profiles:

Profile Interaction Summary:

  • SHALL support read, create, update, search-type.

Modify Criteria:

  • A Server SHALL be capable of creating a QuestionnaireResponse resource using:POST [base]/QuestionnaireResponse/[id]{?_format=[mime-type]}
  • A Server SHALL be capable of updating an existing QuestionnaireResponse resource using:PUT [base]/QuestionnaireResponse/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

  • A Server SHALL be capable of returning a QuestionnaireResponse resource using:GET [base]/QuestionnaireResponse/[id]
  • A Server SHALL be capable of returning resources matching a search query using:GET [base]/QuestionnaireResponse/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

ConformanceParameterTypeExample
SHALLcontextreferenceGET [base]/QuestionnaireResponse?context=[type]/[id]
SHALLpatientreferenceGET [base]/QuestionnaireResponse?patient=[type]/[id]

Search Parameter Requirements (When Used Alone or in Combination):

  • context (reference):

    Allows retrieving QuestionnaireResponse for a context

  • patient (reference):

    Allows retrieving QuestionnaireResponse for a patient

Encounter

Supported Profiles:

Profile Interaction Summary:

  • SHOULD support read.

Fetch and Search Criteria:

  • A Server SHOULD be capable of returning an Encounter resource using:GET [base]/Encounter/[id]

DeviceRequest

Supported Profiles:

Profile Interaction Summary:

  • SHOULD support read.

Fetch and Search Criteria:

  • A Server SHOULD be capable of returning a DeviceRequest resource using:GET [base]/DeviceRequest/[id]

MedicationRequest

Supported Profiles:

Profile Interaction Summary:

  • SHOULD support read.

Fetch and Search Criteria:

  • A Server SHOULD be capable of returning a MedicationRequest resource using:GET [base]/MedicationRequest/[id]

NutritionOrder

Supported Profiles:

Profile Interaction Summary:

  • SHOULD support read.

Fetch and Search Criteria:

  • A Server SHOULD be capable of returning a NutritionOrder resource using:GET [base]/NutritionOrder/[id]

CommunicationRequest

Supported Profiles:

Profile Interaction Summary:

  • SHOULD support read.

Fetch and Search Criteria:

  • A Server SHOULD be capable of returning a CommunicationRequest resource using:GET [base]/CommunicationRequest/[id]

ServiceRequest

Supported Profiles:

Profile Interaction Summary:

  • SHOULD support read.

Fetch and Search Criteria:

  • A Server SHOULD be capable of returning a ServiceRequest resource using:GET [base]/ServiceRequest/[id]

VisionPrescription

Supported Profiles:

Profile Interaction Summary:

  • SHOULD support read.

Fetch and Search Criteria:

  • A Server SHOULD be capable of returning a VisionPrescription resource using:GET [base]/VisionPrescription/[id]

Task

Supported Profiles:

Profile Interaction Summary:

  • SHOULD support read, create, update.

Modify Criteria:

  • A Server SHOULD be capable of creating a Task resource using:POST [base]/Task/[id]{?_format=[mime-type]}
  • A Server SHOULD be capable of updating an existing Task resource using:PUT [base]/Task/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

  • A Server SHOULD be capable of returning a Task resource using:GET [base]/Task/[id]