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

Change History

Page standards status: Informative

Changes for STU 2.1.0 (since V2.0.1)

The following issues are addressed in preparation for this STU Update:

  • Multiple changes have been incorporated to provide support for both US Core 3.1.1 and 6.1
  • FHIR-44930: extra period breaks out a requirement in section 7.10.2 of the formal spec
  • FHIR-45010: Why does OperationOutcome repeat
  • FHIR-46288: Identifying the minimum resource read access ought to be SHALL instead of 'will'
  • FHIR-45945: Clarify links to base FHIR resources in Background section
  • FHIR-45075: DTR should not point to CDS Hook security guide
  • FHIR-44929: Ambiguity within the formal specification on use of SMART on FHIR Backend Services
  • FHIR-42809: allowing linking to a portal rather than building out a questionnaire is not in line with regulation, legislation, or even the spirit of IG
  • FHIR-45020: $questionnaire-package Operation Definition incorrectly states to return warning in outer Bundle
  • FHIR-46627: Include Burden Reduction common narrative for Enforcement Discretion
  • FHIR-46569: Use EHR rather than EMR throughout
  • FHIR-46525: Discrepancy in DTR Package output definition
  • FHIR-44789: Can DTR be satisfied by a pre-existing QR?
  • FHIR-45967: questionnaire-package bundle needs to allow for QuestionnaireResponses
  • FHIR-46441: Add endpoint discovery expectations
  • FHIR-46285: Need to formalize expectation around use of 'questionnaire-adaptive' extension
  • FHIR-46002: Provide guidance on how to transmit FHIR resources to Adaptive Questionnaires

STU 2.0.1 Technical Correction

The following issues are addressed in this technical correction:

  • FHIR-43030: Information Origin Extension challenged to be supported by SMART

STU 1.1.0 Ballot Reconciliation Changes

The following issues are addressed resulting from this ballot:

  • FHIR-24714: This is a security risk as described in the last ballot. - DTR #60
  • FHIR-33328: Need clarification of what the DTR Task page is actually for
  • FHIR-36117: DTR Document Reference R4 Resource Profile Inappropriately Marks Elements As Must Support
  • FHIR-36220: CQL execution errors in an automated process should not require an end user to be notified
  • FHIR-36225: statement doesn't quite make sense
  • FHIR-36227: fix link (& therefore normative requirement) to DTR Questionnaire, instead of base CQF questionnaire
  • FHIR-36228: Need clearer expectations around reusing and refreshing the QuestionnaireResponse
  • FHIR-36355: Refactor the overview
  • FHIR-36371: Clarify 'required' documentation
  • FHIR-36378: Clarify CQL version expectations
  • FHIR-36481: STU note should go away
  • FHIR-36484: Remove SMART on FHIR applications and servers section
  • FHIR-36489: Requesting user identity stuff belongs in section on launch
  • FHIR-36522: add to sentence
  • FHIR-36523: change SHOULD to SHALL
  • FHIR-36525: Change MAY to SHALL
  • FHIR-36528: it is essential that payers create extensive CQL for payer rule automation
  • FHIR-36529: Change MAY to SHOULD
  • FHIR-36530: refine verbiage
  • FHIR-36532: Operation needs a detailed description
  • FHIR-36139: More clarity around how UM Payer multi party arrangements are handled
  • FHIR-36148: no template property is defined in appContext, and questionnaire is OPTIONAL
  • FHIR-36150: is a CRD server the same as a payer API?
  • FHIR-36433: Should be guidance about the use of versioning
  • FHIR-36439: Why do we mandate the use of library?
  • FHIR-36445: Caching guidance needs to be clarified
  • FHIR-36538: DTR Questionnaire should be removed
  • FHIR-36542: Context extension needs more definition
  • FHIR-36548: add guidance to value set
  • FHIR-36549: relaunch for other users
  • FHIR-36550: Add SHALL save DTR response in EMR to beginning of section
  • FHIR-36551: change SHOULDs to SHALLs in task creation
  • FHIR-36553: change from "needs to" to SHALL
  • FHIR-36555: limit scope
  • FHIR-36624: attestation concern
  • FHIR-34121: Provide a mechanism for Template to specify what to do when DTR ends
  • FHIR-33224: Add support for SDC Adaptive forms
  • FHIR-36276: Security review of SDC Adaptive Forms in DTR
  • FHIR-36492: Handling updates to Questionnaire.effectivePeriod
  • FHIR-36478: SDC questionnaire responses will always have a Questionnaire url somewhere
  • FHIR-36527: refine language
  • FHIR-36483: Need to clarify pruning expectations
  • FHIR-36390: Launch instructions need correction/clarification
  • FHIR-36491: Drop section on "usage sessions"
  • FHIR-36385: No guidance on CRD
  • FHIR-40438: Section on DTR use of US Core has link which points to general US Core page instead of 3.1.1
  • FHIR-24581: Identify the subject extension. - DTR #15
  • FHIR-36151: Again, DTR <-> Payer should use SMART backend services
  • FHIR-36365: Downloads should be a separate page
  • FHIR-36394: CQL logic guidance is misleading
  • FHIR-36367: Talk about DTR before you talk about CRD
  • FHIR-40549: Guidance regarding the Endpoint for adaptive form next question
  • FHIR-36470: Fix guidance on saving state
  • FHIR-36434: Revamp endpoint description a bit
  • FHIR-36369: Payer
  • FHIR-36376: Fix wording on SDC
  • FHIR-36374: Should be no conformance rules around CDS Hooks or CRD
  • FHIR-36377: Clarify language on CQL
  • FHIR-36435: Remove CRD paragraph
  • FHIR-36362: "CQL and FHIR Questionnaires SHALL be required" is unclear
  • FHIR-39504: Add guidance on endpoint discovery/configuration
  • FHIR-36539: DTR QuestionnaireResponse should be based on SDC
  • FHIR-36395: Context needs to talk about hierarchy of expression too.
  • FHIR-36380: Why is change history wrapped in an STU note?
  • FHIR-36386: DTR to payer security doesn't belong in CRD links section
  • FHIR-38837: Specific issues related to sensitive or patient restricted information
  • FHIR-36138: Clarify what information is in scope for FHIR CQL support
  • FHIR-36430: Clarify expectations on missing context
  • FHIR-36300: Who is responsible for provision of the token
  • FHIR-36482: Patient must always be in context
  • FHIR-21006: DTR should point to SDC, not CQIF Questionnaire
  • FHIR-36479: Provide proper details on authentication
  • FHIR-36392: Guidance on CQL isn't quite right
  • FHIR-36379: Spec *MUST* use mustSupport in its profiles
  • FHIR-36384: "Profiles" page doesn't really make sense as a page
  • FHIR-36382: Formal specification page should be revamped
  • FHIR-36447: Guidance on handling Questionnaire is insufficient
  • FHIR-36364: Home page should appear on the menu
  • FHIR-36465: DTR is repeating guidance better covered in SDC
  • FHIR-36360: Conformance statements don't belong on the home page
  • FHIR-36368: Conformance language doesn't belong on use-case page
  • FHIR-36410: Title and content don't jive
  • FHIR-36356: Adjust note to implementers
  • FHIR-37949: Remove all notion of storing work-in-progress on payer
  • FHIR-40421: Guidance on this page needs to be rewritten
  • FHIR-36450: Goal is overstated and user input always required
  • FHIR-36476: Refactor relaunch documentation
  • FHIR-36349: Split menu into background and spec
  • FHIR-36149: appContext should be a black box to EHR, use SMART launch param's instead
  • FHIR-36440: Remove the 'relaunch' section
  • FHIR-36517: Clarification on Tasks
  • FHIR-36531: Change SHOULD to SHALL and delete the MAY sentence that follows
  • FHIR-36146: Clarify that DTR app should authenticate to payer with SMART Backend Services
  • FHIR-36441: Remove FHIR version discussion
  • FHIR-36298: CRD linking to website versus a DTR solution
  • FHIR-36429: No appContext on stand-alone launch
  • FHIR-36547: data SHOULD NOT be stored on the payer server
  • FHIR-36540: Improve description of SDC Questionnaire profile
  • FHIR-36383: Are you using SDC or CQF?
  • FHIR-36361: Provenance expectations need more clarity
  • FHIR-36507: Correct and re-organize this section
  • FHIR-36533: Issues with lack of guidance on storage
  • FHIR-36129: Initial DTR Launches should not be restricted to CDS Hooks Cards within the CRD workflow.
  • FHIR-36988: Not clear where to get Requester Organization when creating PAS request
  • FHIR-36366: Actors are unclear and in wrong place
  • FHIR-36438: Questionnaire guidance is incorrect
  • FHIR-36537: DocumentReference profile isn't sufficient
  • FHIR-36253: DTR Spec needs a way to pass a questionnaire / response across organizations
  • FHIR-34151: Need an ability for DTR to store prior authorization
  • FHIR-39443: Add expectations about terminology mapping
  • FHIR-36119: DTR SDC Questionnaire For Adaptive Form Profile Inappropriately Marks Elements As Must Support
  • FHIR-36373: Clarify US Core expectations
  • FHIR-36299: Mapping CQLs to PA criteria
  • FHIR-36466: Provider Attestation guidance needs fixing
  • FHIR-34103: Clarify minimum Questionnaire capabilities
  • FHIR-33226: Formalize how DTR passes information to PAS, PAO or other exchange IG
  • FHIR-36219: The CDS Hooks Card Link object should not require a DTR launch URL
  • FHIR-36004: Change to use the CRD unsolicited prior auth profile
  • FHIR-36467: Need a section on privacy/security
  • FHIR-36346: Add 'support' menu item
  • FHIR-36118: DTR SDC Questionnaire Profile Inappropriately Marks Elements As Must Support
  • FHIR-36370: Clarify expectations on QR approval
  • FHIR-36372: Do we need a CRD & DTR section here?
  • FHIR-36393: Page names are overly long
  • FHIR-36432: Are DTR Questionnaire valuesets pre-expanded?
  • FHIR-36524: remove references to manual alternatives/solutions that do not leverage the specs
  • FHIR-34291: Deferring and relaunching DTR App
  • FHIR-37270: Access Token must not be included in appContext
  • FHIR-36443: How does an app notify the payer system
  • FHIR-36520: Change operation invocation
  • FHIR-36391: Need more launch details
  • FHIR-39492: Allow DTR to be used from CDex
  • FHIR-36543: Need a search parameter for new context extension
  • FHIR-36534: Correct operation adaptive expectations
  • FHIR-40605: Update Questionnaire package operation per discussions
  • FHIR-36431: Inconsistency in how value sets & libraries are returned
  • FHIR-36625: please clarify data access by payer
  • FHIR-34128: Allow passing 'order' context when launching DTR
  • FHIR-36436: Do better job of explaining HRex decision points
  • FHIR-36468: What's the point of distinguishing CQL vs. human-authored?
  • FHIR-36535: We need examples for operation inputs and outputs
  • FHIR-36437: Revamp payer authorization language
  • FHIR-36455: Utilization of CQL
  • FHIR-36375: Loosen rules on SMART
  • FHIR-36359: Need CapabilityStatements
  • FHIR-36331: Revamp expectations around launch parameters
  • FHIR-36192: Include CRD questionnaire workflow, not just prior auth questionnaire
  • FHIR-36412: Need more guidance on CDS Hooks launch
  • FHIR-36544: Examples are incomplete and have extras
  • FHIR-36409: EHR and DTR initiation
  • FHIR-36411: Organize interactions along likely HIT modules
  • FHIR-41557: Guidance on Referenced resources missing
  • FHIR-41576: Prohibit alternate use of 'next-question' data
  • FHIR-41168: "How DTR Passes Information" page is no longer accurate
  • FHIR-40421: Guidance on this page needs to be rewritten
  • FHIR-41854: DTR needs to be re-organized quite a bit