FI-3584: Allow User Provided Questionnaire Package Responses

[vanessuniq]

Summary

This update introduces the ability for users to provide a custom questionnaire package response for the Static Questionnaire workflow test, applicable to both Full EHR and SMART APP Suite. The test logic has been updated to handle the validation of the provided QuestionnaireResponse, and the attestation statements have been adjusted to reflect these changes.

Test Guidance

• Presets for Testing: Presets include examples like the respiratory device and dinner order questionnaires.
• Scenarios to Test:
  1. No Custom Response Provided: All four validation tests for the custom response should result in "omit."
  2. Invalid Custom Response Provided: If the custom response has no bundle or is of the wrong resource type, the first custom validation should be "fail," and the subsequent three should be "skip."
  3. QuestionnaireResponse Validation with Custom Response: If a custom response is provided but the referenced questionnaire (QuestionnaireResponse.questionnaire) is not in the custom response package, the validation should be skipped.

[karlnaden]

Do you have an example questionnaire package response that you've used with this functionality? Walking through an example of how to use it would help with the review.

[vanessuniq]

Do you have an example questionnaire package response that you've used with this functionality? Walking through an example of how to use it would help with the review.

I tested with the bundle we use for the Respiratory Assist Device workflow and also this output parameter from the IG

[tstrass]

I think I mostly know what I need to do, but any testing guidance for this? Edit: I guess Karl asked a related question above so I'll just go off of that if there's nothing else.

[karlnaden]

Seeing this in practice, I don’t think that changing the dinner static tests to accommodate user-specified $questionnapire-package responses is the right approach. In the SMART tests in particular, we’re able to verify significantly more detail when we know the Questionnaire and the data available to pre-populate it and changing the tests to assume that we don’t know that level of detail is a big step back. I think instead, we should make these completely new tests that test the smaller scope in the basic workflows section and move the dinner static ones elsewhere, like into the Questionnaire Functionality Coverage section.

In addition to that, I think that even though we can’t validate that the client does things like pre-populate correctly, I think we can and should change that all of the “source” values are present: auto, manual, and override.