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

Change History

Release 2.1.0

The following issues are addressed resulting from the STU Update Comment period review:

• FHIR-46554: Include questionnaire details in the example
• FHIR-46646: Conformance requirement on subjective determination
• FHIR-46750: Clarify that CQL expectations are for app/EHR, not payer
• FHIR-46754: $questionnaire-package narrative and DTRQuestionnairePackageBundle do not align.
• FHIR-47250: Clarify adaptive architecture
• FHIR-47706: Add support for US Core 7
• FHIR-47995: Must Support guidance section should be moved from Specification page to a 'Conformance Expectations' page
• FHIR-48314: providers need a way to indicate if they want pre-emptive prior auth as part of adaptive forms
• FHIR-48487: Replace EHR with Provider HIT
• FHIR-48488: Ambiguous SHALL on resource support requirement
• FHIR-48490: $questionnaire-response output parameter name inconsistency
• FHIR-48494: Include CMS requirements
• FHIR-48495: CMS enforcement discretion comes out of nowhere
• FHIR-48499: add or staff to better capture people who populate
• FHIR-48501: Change SHOULD to SHALL
• FHIR-48504: Questionnaire-package Bundle Example not updated to only have one questionnaire
• FHIR-48506: SHOULD have CQL logic
• FHIR-48508: change conformance language for the retrieving launch context
• FHIR-48510: suggest adding "including appeals"
• FHIR-48511: Change SHOULD to SHALL
• FHIR-48513: No examples of Questionnaire Package Bundles with a QuestionnaireResponse
• FHIR-48515: Explain Reasoning behind the difference in Questionnaire Adaptive extension cardinality
• FHIR-48516: Clarify QuestionnaireResponse contained Questionnaire Requirements for adaptive questionnaires
• FHIR-48517: Library and ValueSet Caching requirements for DTR Apps and Full EHRs
• FHIR-48518: Are there required DTR client responses to an added coverage-information extension?
• FHIR-48519: Clarify whether FHIRPath is allowed in pre-population expressions
• FHIR-48520: Clarify use of PH Alternate Expression Extension
• FHIR-48521: Determining support for payer questionnaires
• FHIR-48523: Is the "Retrieving Launch Context Information" informational?
• FHIR-48524: Constraining Queries example clarification
• FHIR-48686: Profile $next-question (or create a new operation) so there's an actual use for the DTR adaptive questionnaire profile
• FHIR-48694: Clarify ValueSet and $expand Guidance
• FHIR-48703: Coverage context search parameter inconsistencies
• FHIR-48728: Inconsitency between contexts in CRD and DTR
• FHIR-48744: Align endpoint discovery language w/ CRD

Release 2.1.0-preview

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

Release 2.0.0

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