Prior to completion, the DTR app will write information to the payer system (or whatever other system is responsible for the ‘app’) as a DocumentReference with relevant metadata with a contained QuestionnaireResponse. That can either be a direct user action (i.e. ‘save’) or in the background automatically. When launching DTR in stand-alone mode, the user would select the payer they want to search for DocumentReference against. The DocumentReference will have enough information to identify the patient, the coverage, the type of order and the date. If launched without explicit context provided by a CDS Hook card (but with context of the user (and their organization) and the patient, the SMART app will retrieve a list of all ‘open’ DocumentReferences to display to the user to ask which they want to continue. Once the QuestionnaireResponse has been saved in the EHR, the DocumentReference containing the work-in-progress will be deleted The system storing the DocumentReferences may ‘prune’ any that haven’t been touched in a long time (e.g. 3 months, 6 months). Security rules SSHALL prohibited using the information in such stored DocumentReferences for any purpose other than continuing a work-in-progress from a SMART app from the same organization that originally stored them. Will make clear that this only applies to DTR SMART app systems.  EHRs that perform DTR functionality internally can persist as they see fit (including using this mechanism if they wish) We will define the expected content of the DocumentReference including the document code to use, the metadata to surface for searching and how the 'binary' content of the document will encompass the QuestionnaireResponse and context. We will need to scope the app to payer connection to a single patient for security reasons