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

STU 1.1.0 Ballot Reconciliation Changes (for STU 2.0.0 publication)

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