This page is talking about multiple things and grouping it under 'profiles' doesn't really make sense.

The points I think we need to get across:

• Payers SHALL expose their rules using FHIR Questionnaires that comply with either the DTR SDC Questionnaire profile or the DTR Adaptive Questionnaire profile.
• These Questionnaires SHOULD include logic that supports population from the EHR where possible.
• Such logic SHOULD rely exclusively on data elements and search parameters defined either in US Core or HRex.
• These Questionnaires SHOULD also include logic that ensures that only 'relevant' questions are displayed, based on what answers have already been provided/populated.
• 'full' EHRs and SMART apps SHALL handle rendering Questionnaires and executing the logic found within all mustSupport Questionnaire data elements.
• These systems SHOULD also support all non mustSupport data elements found in the differential of the profiles as per SDC documentation for those elements and extensions and SHALL gracefully handle the presence of these elements if not supported.  (I.e. non-support for an element SHALL NOT interfere with a user's ability to complete a QuestionnaireResponse.)
• When using 'expression' elements within Questionnaires, all logic SHALL be written in CQL unless there is a site-to-site agreement to support x-fhir-query and/or FHIRPath-based logic.  (x-fhir-query and FHIRPath are actually easier to write and support than CQL, so providing a path to their use is appropriate)

This would be the appropriate place to inject expectations about user review, ability for CQL to be in-line, etc.

Please revamp the language to reflect these conformance expectations - ideally on the main 'specification' page.