Da Vinci - Documentation Templates and Rules
2.1.0-preview - STU 2 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-preview 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-preview
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: 1.1.0-ci-build
  • FHIR Version: 4.0.1
  • Intended Use: Requirements
  • Supported Formats: JSON
  • Published: 2023-08-31
  • Published by: HL7 Clinical Decision Support Work Group
  • Status: Active

This statement defines the expected capabilities of EHRs that rely on a SMART on FHIR application 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
Coverageread♦, create♦, update♦, search-type♦ Coverage context♦, patient♦
Encounterread⋄ DeviceRequest
DeviceRequestread⋄ DeviceRequest
MedicationRequestread⋄ MedicationRequest
NutritionOrderread⋄ NutritionOrder
CommunicationRequestread⋄ CommunicationRequest
ServiceRequestread⋄ ServiceRequest
VisionPrescriptionread⋄ CRD Vision Prescription
Taskread⋄, create⋄, update⋄

Coverage

Conformance Expectation:(conformance expectation undefined)

Supported Profiles:

Profile Interaction Summary:

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

Modify Criteria:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

ConformanceParameterTypeExample
SHALLcontextreferenceGET [base]/Coverage?context=[type]/[id]
SHALLpatientreferenceGET [base]/Coverage?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

Conformance Expectation:(conformance expectation undefined)

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

Conformance Expectation:(conformance expectation undefined)

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

Conformance Expectation:(conformance expectation undefined)

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

Conformance Expectation:(conformance expectation undefined)

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

Conformance Expectation:(conformance expectation undefined)

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

Conformance Expectation:(conformance expectation undefined)

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

Conformance Expectation:(conformance expectation undefined)

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

Conformance Expectation:(conformance expectation undefined)

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]