A structured set of questions and their answers. The questions are ordered and grouped into coherent subsets, corresponding to the structure of the grouping of the questionnaire being responded to.

To support structured, hierarchical reporting of data gathered using digital forms and other questionnaires.

The QuestionnaireResponse contains enough information about the questions asked and their organization that it can be interpreted somewhat independently from the Questionnaire it is based on. I.e. You don't need access to the Questionnaire in order to extract basic information from a QuestionnaireResponse.

Business identifiers assigned to this questionnaire response by the performer and/or other systems. These identifiers remain constant as the resource is updated and propagates from server to server.

Allows identification of the questionnaire response as it is known by various participating systems and in a way that remains consistent across servers.

Note: This is a business identifier, not a resource identifier (see discussion).

A plan, proposal or order that is fulfilled in whole or in part by this questionnaire response. For example, a ServiceRequest seeking an intake assessment or a decision support recommendation to assess for post-partum depression.

Supports traceability of responsibility for the questionnaire response and allows linkage of the response to the proposals/recommendations acted upon.

A procedure or observation that this questionnaire was performed as part of the execution of. For example, the surgery a checklist was executed as part of.

Not to be used to link an questionnaire response to an Encounter - use 'context' for that.

Composition of questionnaire responses will be handled using the Assemble operation defined in the SDC IG. For relationships to referrals, and other types of requests, use basedOn.

The Questionnaire that defines and organizes the questions for which answers are being provided.

Needed to allow editing of the questionnaire response in a manner that enforces the constraints of the original form.

If a QuestionnaireResponse references a Questionnaire that can be resolved, then the QuestionnaireResponse structure must be consistent with the Questionnaire (i.e. questions must be organized into the same groups, nested questions must still be nested, etc.). It is possible to have a QuestionnaireResponse whose 'questionnaire' element does not resolve. It is also possible for the questionnaire element to not have a value but only extensions (e.g. conveying the title or identifier for the questionnaire). This may happen for legacy data. If there is no formally defined Questionnaire, it is undefined what the 'correct' values for the linkId elements should be and it is possible that linkIds might be inconsistent for QuestionnaireResponses for the same form if captured by distinct systems.

The current state of the questionnaire response.

The information on Questionnaire resources may possibly be gathered during multiple sessions and altered after considered being finished.

Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is.

The subject of the questionnaire response. This could be a patient, organization, practitioner, device, etc. This is who/what the answers apply to, but is not necessarily the source of information.

Links the questionnaire response to the Patient context. May also affect access control.

If the Questionnaire declared a subjectType, the resource pointed to by this element must be an instance of one of the listed types.

The Encounter during which this questionnaire response was created or to which the creation of this record is tightly associated.

Links the questionnaire response to the Encounter context. May also affect access control.

This will typically be the encounter the questionnaire response was created during, but some questionnaire responses may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter (e.g. pre-admission forms). A questionnaire that was initiated during an encounter but not fully completed during the encounter would still generally be associated with the encounter.

The date and/or time that this questionnaire response was last modified by the user - e.g. changing answers or revising status.

Clinicians need to be able to check the date that the information in the questionnaire was collected, to derive the context of the answers.

May be different from the lastUpdateTime of the resource itself, because that reflects when the data was known to the server, not when the data was captured.

This element is optional to allow for systems that might not know the value, however it SHOULD be populated if possible.

The individual or device that received the answers to the questions in the QuestionnaireResponse and recorded them in the system.

Need to know who interpreted the subject's answers to the questions in the questionnaire, and selected the appropriate options for answers.

Mapping a subject's answers to multiple choice options and determining what to put in the textual answer is a matter of interpretation. Authoring by device would indicate that some portion of the questionnaire had been auto-populated. Device should only be used if it directly determined the answers, not if it was merely used as a capture tool to record answers provided by others. In the latter case, information about the physical device, software, etc. would be captured using Provenance.

The individual or device that answered the questions about the subject.

When answering questions about a subject that is minor, incapable of answering or an animal, another human source may answer the questions.

If not specified, no inference can be made about who provided the data. Device should only be used if it directly determined the answers, not if it was merely used as a capture tool to record answers provided by others. In the latter case, information about the physical device, software, etc. would be captured using Provenance.

A group or question item from the original questionnaire for which answers are provided.

Groups cannot have answers and therefore must nest directly within item. When dealing with questions, nesting must occur within each answer because some questions may have multiple answers (and the nesting occurs for each answer).\nWhen dealing with repeating items, each group repetition will be handled by a separate item. However, repeating questions are handled with a single question item and potentially multiple answers.

The item from the Questionnaire that corresponds to this item in the QuestionnaireResponse resource.

Items can repeat in the answers, so a direct 1..1 correspondence by position might not exist - requiring correspondence by identifier.

A reference to an ElementDefinition that provides the details for the item.

A common pattern is to define a set of data elements, and then build multiple different questionnaires for different circumstances to gather the data. This element provides traceability to the common definition.

The ElementDefinition must be in a StructureDefinition, and must have a fragment identifier that identifies the specific data element by its id (Element.id). E.g. http://hl7.org/fhir/StructureDefinition/Observation#Observation.value[x].

There is no need for this element if the item pointed to by the linkId has a definition listed.

Text that is displayed above the contents of the group or as the text of the question being answered.

Allows the questionnaire response to be read without access to the questionnaire.

The text for an item SHOULD be identical to the text from the corresponding Questionnaire.item. This can't be strictly enforced because it's possible for the Questionnaire to be updated subsequent to the QuestionnaireResponse having been created, however the intention is that the text in the QuestionnaireResponse reflects what the user saw when completing the Questionnaire.

The respondent's answer(s) to the question.

The value is nested because we cannot have a repeating structure that has variable type.

The answer (or one of the answers) provided by the respondent to the question.

Ability to retain a single-valued answer to a question.

More complex structures (Attachment, Resource and Quantity) will typically be limited to electronic forms that can expose an appropriate user interface to capture the components and enforce the constraints of a complex data type. Additional complex types can be introduced through extensions. Must match the datatype specified by Questionnaire.item.type in the corresponding Questionnaire. Note that a question is answered using one of the possible choices defined with answerOption, answerValueSet or some other means and the answer has a complex data type, all elements within the answer in the QuestionnaireResponse SHOULD match the elements defined corresponding choice value in the Questionnaire. However, it is possible that not all elements will be propagated. Also, some systems might use language translations resulting in different displays. Comparison of value to the values defined in the Questionnaire (whether by answerOption, answerValueSet or answerExpression) SHALL NOT pay attention to Coding.display, Reference.display, Quantity.unit unless those are the only elements present. As well, systems are not required to check for a match on any extensions (e.g. ordinal values, translations, etc.). Systems MAY enforce that if extensions such as ordinal values are present in both Questionnaire and QuestionnaireResponse, they match.

Nested groups and/or questions found within this particular answer.

It is useful to have "sub-questions", questions which normally appear when certain answers are given and which collect additional details.

Only used when nesting beneath a question - see item.item for nesting beneath groups

Sub-questions, sub-groups or display items nested beneath a group.

Reports can consist of complex nested groups.

Only used when nesting beneath a group - see item.answer.item for nesting beneath questions