"Payers SHALL require the DTR process to authenticate in order to retrieve resources when PHI is exchanged, and MAY required authentication in other situations. In the case that authentication is required, the following JSON structure SHALL be populated by the payer system. This JSON is based on the structure for FHIR Authorization in CDS Hooks."

A DTR app can't know if questions in a Questionnaire will include PHI.  Therefore, the presumption must be that all interactions will involve PHI.  Furthermore, writing to and accessing existing DocumentReferences could also expose PHI.  Therefore, all communication between a 'full' EHR or a SMART app and a payer must be over an authenticated connection.

Second, we shouldn't be inventing our own authorization mechanism here.  Instead, we should be using the SMART "backend services" protocol.  All we should be doing are pointing to that spec and listing the scopes needed - which are system/questionnaire.rs, system/valueset.rs and system/library.rs.  Those will be sufficient to invoke the DTR Questionnaire operation, $next-question, ValueSet/$expand and retrieval of libraries and value sets.  (The spec should explain that intention for that set of scopes.)  If the EHR can't handle in-progress results, then it also needs system/documentreference.cruds.