Agree to accept changes as described below: The launch content shouldn't be specific to CRD.  It should be a requirement for launching DTR period (whether the system claims to conform with CRD or not).  The invoking language needs to clearly differentiate the process of launching from CRD vs. a stand-alone launch requiring human intervention. Explain why we're standardizing - so that EHRs can swap what SMART apps are used or can choose to use the information from a CDS Hooks service for local DTR implementation Should provide an explanation of why there are multiples - specifically "In most cases, a card that results in the launch of DTR will deal with only one patient coverage, multiple orders, one Questionnaire and (possibly) one initial QuestionnaireResponse.  However, there may be edge cases where more than one of these is possible." There should be a constraint that any QuestionnaireResponses provided must either be adaptive forms or must correspond to a specified Questionnaire I think we may need two elements for order - one an array of objects and one an array of orders.  I don't think JSON allows intermingling those things. (To be determined if this is actually used) The rules should make clear that you'll receive the full order in those cases where the order isn't yet persisted and available on the RESTful interface. We may need to rename 'order' to something more generic - because the hook could trigger for an Appointment or an Encounter, not just for orders.  If we don't rename, we need to make clear that 'order' can include these resources too. (To be determined) There will be examples included of what this will actually look like