CDex now expects to leverage DTR functionality.  That means some changes to the DTR specification.  Specifically: Update the introduction to the IG and use-cases to talk about being invoked for purposes other than specific burden reduction use-cases, including explicitly making a reference (not a dependency) to CDex as an IG that will be using DTR Make the inclusion of 'order' as part of context conditional - don't need an order if we've got a Questionnaire or ID string from CRD or PAS. - Note: SHOULD pass order with ID string from CRD in the event of a change. Do not require the resulting QuestionnaireResponse to have an extension that links to the relevant 'order' (as there might not be one) When we talk about mechanisms for the results of the completed QuestionnaireResponse getting to the payer, note that other IGs might provide additional mechanisms for transmitting such information and that the client that launches DTR is responsible for understanding the context of the launch, and thus what to do with any QuestionnaireResponses persisted as a result of that launch. Need reference in DTR to Task profile in CDex - Note:  Task profile in CDex will need to be updated to include ID string as Task.input. NOTE : Smart doesn't really have a good way to flag data that was stored as a result of a SMART launch as being a 'result' of that SMART launch, so we're going to have to think a bit about how EHRs should manage that context matching.