Will define a new “SMART launch context” called “order” which is the local reference to the Request that is currently in context.  Will indicate that DTR must support this new context and will allow retrieval of the DTR session associated with that order.   The order will be identified within 'stored context' using the Request.identifier with an Identifier.type of 'placer'.  Thus even if the original order did not have a .id or the .id changes between "in memory" and "persisted order", identity resolution can happen using the Request.identifier which is required to be consistent throughout the lifetime of the order. Will add a section on DTR launch that the launch SHALL occur in the context of a specific patient and SHOULD occur in the context of a specific encounter and ideally a specific order.  DTR will check to see if there is already work-in-progress by looking for an existing QuestionnaireResponse (on the EHR) or DocumentReference (on the payer) for the specified order.  If no order is specified, DTR will allow the user to select one of the existing "work-in-progress" sessions.  If an order was selected and there was no work in progress: -   If there are multiple coverages whose payers are supported by the DTR app, the app will allow the user to select the coverage(s) to use DTR for.  (Each coverage selected would result in a separate QuestionnaireResponse.) -  the DTR app will hit an operation endpoint on the payer (likely similar to that used internally by the CRD service) passing the order and coverage to determine the DTR ruleset.  Note: this operation will not have a token allowing the payer to access any information other than what's in the order.  This means that the ruleset will often be broader (i.e. more questions and more questionnaire logic) than when the ruleset is determined within CRD.