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: SMART DTR Client USCDI 3

Official URL: http://hl7.org/fhir/us/davinci-dtr/CapabilityStatement/smart-dtr-client-610 Version: 2.1.0-preview
Standards status: Trial-use Maturity Level: 2 Computable Name: DTRSmartClient

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.

Raw OpenAPI-Swagger Definition file | Download

SMART on FHIR DTR Client

  • Official URL:http://hl7.org/fhir/us/davinci-dtr/CapabilityStatement/smart-dtr-client-610
  • 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 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.

Include And Support Everything In The Following CapabilityStatements:

FHIR Client RESTful Capabilities

A SMART on FHIR DTR Client provides an application conforming to the SMART on FHIR specification and related requirements declared in this Implementation Guide.

Security:

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

Summary of Client Wide Operations

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 - USCDI 3
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♦

QuestionnaireResponse

Supported Profiles:

Profile Interaction Summary:

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

Modify Criteria:

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

Fetch and Search Criteria:

  • A Client SHALL be capable of fetching a QuestionnaireResponse resource using:GET [base]/QuestionnaireResponse/[id]
  • A Client SHALL be capable of fetching 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:

  • SHALL support read.

Fetch and Search Criteria:

  • A Client SHALL be capable of fetching an Encounter resource using:GET [base]/Encounter/[id]

DeviceRequest

Supported Profiles:

Profile Interaction Summary:

  • SHALL support read.

Fetch and Search Criteria:

  • A Client SHALL be capable of fetching a DeviceRequest resource using:GET [base]/DeviceRequest/[id]

MedicationRequest

Supported Profiles:

Profile Interaction Summary:

  • SHALL support read.

Fetch and Search Criteria:

  • A Client SHALL be capable of fetching a MedicationRequest resource using:GET [base]/MedicationRequest/[id]

NutritionOrder

Supported Profiles:

Profile Interaction Summary:

  • SHALL support read.

Fetch and Search Criteria:

  • A Client SHALL be capable of fetching a NutritionOrder resource using:GET [base]/NutritionOrder/[id]

CommunicationRequest

Supported Profiles:

Profile Interaction Summary:

  • SHALL support read.

Fetch and Search Criteria:

  • A Client SHALL be capable of fetching a CommunicationRequest resource using:GET [base]/CommunicationRequest/[id]

ServiceRequest

Supported Profiles:

Profile Interaction Summary:

  • SHALL support read.

Fetch and Search Criteria:

  • A Client SHALL be capable of fetching a ServiceRequest resource using:GET [base]/ServiceRequest/[id]

VisionPrescription

Supported Profiles:

Profile Interaction Summary:

  • SHALL support read.

Fetch and Search Criteria:

  • A Client SHALL be capable of fetching a VisionPrescription resource using:GET [base]/VisionPrescription/[id]

Task

Profile Interaction Summary:

  • SHALL support read, create, update.

Modify Criteria:

  • A Client SHALL be capable of posting a Task resource using:POST [base]/Task/[id]{?_format=[mime-type]}
  • A Client SHALL be capable of putting an existing Task resource using:PUT [base]/Task/[id]{?_format=[mime-type]}

Fetch and Search Criteria:

  • A Client SHALL be capable of fetching a Task resource using:GET [base]/Task/[id]