This page is part of the Documentation Templates and Rules (v2.0.1: STU 2.0) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Change History

This ballot addresses several additions, modifications, technical corrections, errata, and clarifications listed below. They have been reviewed and voted on by the members of the HL7 Clinical Decision Support WorkGroup, which is sponsoring this ballot release and reconciliation of the comments.

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