We will add the following search parameters (processingMode='other'): 1. QuestionnaireResponse-linkId based on QuestionnaireResponse.item.linkId  2. QuestionnaireResponse-answerConcept based on QuestionnaireResponse.item.answer.value.ofType(Coding, boolean) 3. QuestionnaireResponse-answerDate based on QuestionnaireResponse.item.answer.value.ofType(date, dateTime) 4. QuestionnaireResponse-answerQuantity based on QuestionnaireResponse.item.answer.value.ofType(Quantity, integer, decimal) 5. QuestionnaireResponse-answerReference based on QuestionnaireResponse.item.answer.value.ofType(Reference) 6. QuestionnaireResponse-answerString based on QuestionnaireResponse.item.answer.value.ofType(string) 7. QuestionnaireResponse-answerUri based on QuestionnaireResponse.item.answer.value.ofType(uri) 8. Additional search parameters corresponding to the various 'answer' ones called QuestionnaireResponse-questionAnswer [foo] that are a composite of the linkId search parameter and the corresponding answerFoo search parameter In the definitions of each of these will point to a notes section on Questionnaire called "Searching by answers" which we will add.  Will note on the linkId and answer search parameters to indicate that their primary purpose is for use on the composite and they should generally not be used on their own. The "Searching by answers" section will: indicate that the meaning of answers in a QuestionnaireResponse is often contextual based on other answers within the form, making it very difficult (and potentially risky) to infer information from the inclusion of a QuestionnaireResponse in response to a search Indicate that when searching based on linkId, the search SHOULD also filter by the Questionnaire, and typically a specific version of the Questionnaire because linkIds can be re-used across forms and mean very different things Searching for data in QuestionnaireResponses behaves in an opaque/proprietary way because Questionnaires are rarely standardized across organization.  Best practice for making data accessible for search is therefore to [extract] information from completed QuestionnaireResponses into other FHIR resources that are more standardized and can be better understood and searched for across organizations. Because of the complexity of indexing recursive data structures and the potential for large volumes of data elements, search parameters on linkId and answers may not be widely supported. Search on QuestionnaireResponses means that the server is often not aware of the 'meaning' of the data being searched or being returned.  This makes applying access control policies, consent, etc. more difficult or even impossible. Define an extension on Questionnnaire and Questionnaire.item called Questionnaire-index-answer of type boolean.  Description: "If set to true on an item, indicates a request for servers to index QuestionnaireResponses to allow search based on the answers for that specific item (i.e. with that linkId).  If set on the root of a Questionnaire, indicates a request to support searching on all answers within QuestionnaireResponses from all of this."