View raw Markdown
type: resourceresource: QuestionnaireResponse

QuestionnaireResponse

Introduction

Scope and Usage

QuestionnaireResponse provides a complete or partial list of answers to a set of questions filled when responding to a questionnaire. The questions may be included directly or by reference to a Questionnaire resource that defines the questions as well as the constraints on the allowed answers. In some cases, both formal rules for editing the questionnaire (via link to Questionnaire) as well as sufficient local information to allow rendering of the questionnaire may be provided.

Each time a questionnaire is completed for a different subject or at a different time, a distinct QuestionnaireResponse is generated, though it may be possible for a previously entered set of answers to be edited or updated.

Questionnaire responses cover the need to communicate data originating from forms used in medical history examinations, research questionnaires and sometimes full clinical specialty records. In many systems this data is collected using user-defined screens and forms. Questionnaire responses record specifics about data capture - exactly what questions were asked, in what order, what answers were given, etc. Each of these questions is part of the Questionnaire, and as such the Questionnaire is a separately identifiable Resource, whereas the individual questions are not.

Examples of Questionnaires include:

QuestionnaireResponse resources can be validated against their corresponding Questionnaire to verify that required groups and questions are answered and that answers fit constraints in terms of cardinality, data type, etc.

Boundaries and Relationships

The QuestionnaireResponse resource captures the responses to a questionnaire, while Questionnaire represents the definition of the questionnaire form, including what questions are asked, how they're organized and the constraints on the allowed answers.

While Observation, with its nested component structure, can create complex hierarchies of questions and answers, the focus is different. First, Observation is used primarily for capturing data elements that are "true" observations - lab measurements, vital signs, social assessments, etc., while QuestionnaireResponse can be used to capture any types of data, including data that would typically map to other resources (Procedure, Patient, MedicationStatement, etc.). Second, the focus of QuestionnaireResponse includes the specific phrasing and organization of the questions. All data must be explicitly captured as a question. With Observation, the focus is only on the meaning of the answer, not what question was asked (assuming a question was even asked at all). Additional information such as normal ranges, interpretation, date, etc., may also be captured.

Background and Context

Notes

Notes

Refer to additional guidance provided in the Questionnaire resource dealing with the design of questionnaires.

A QuestionnaireResponse may be stand-alone or may point to the definition of the questions in Questionnaire. If the QuestionnaireResponse refers to a Questionnaire:

A diagram showing a Questionnaire with multiple nested groups and items and the corresponding QuestionnaireResponse

The diagram above shows a Questionnaire with a hierarchy of group and question items, some marked as 'repeats'=true, and others false and with similar variation in 'required'=true and false. It also shows a hypothetical QuestionnaireResponse that is valid against that questionnaire with appropriate nesting of items and answers and linkIds showing the alignment between the Questionnaire and QuestionnaireResponse items.

Validating QuestionnaireResponses

Rules imposed by a Questionnaire about expectations for answers are not expected to be met until a Questionnaire is deemed to be 'completed' (or 'amended'). For example, items that are marked as 'required' may be omitted, minimum numbers of answers might not be met, length requirement for answers, co-occurrence constraints, etc. might all be violated when the QuestionnaireResponse is still in the process of being completed. QuestionnaireResponses may be stored in this 'incomplete' state. Such QuestionnaireResponses might also include data for disabled questions, entries and text for non-answered questions, etc. However, once a QuestionnaireResponse is marked as 'completed' (including if it is subsequently changed to 'amended'), all requirements of the associated Questionnaire must be met, all non-answered question items must be removed, all non-enabled items must be removed, etc. (Display items MAY be retained. Certain extensions on the Questionnaire item may mandate that a display item needed for a human reviewer to interpret the QuestionnaireResponse be retained in a completed QuestionnaireResponse.)

Nested Items

QuestioinnaireResponse has two different mechanisms to support nesting of items - item.item and item.answer.item. The former is used when nesting items within a 'group' and the latter is always used when nesting items within a question. This is because items nested within a question always nest within each answer to the question. If the question allows multiple answers, each will have its own set of nested items.

Security

QuestionnaireResponse resources can have answers with values of type Attachment. These attachments will typically be selected by the user answering the questionnaire and this selection may be done in an uncontrolled environment. Systems should ensure that the attachment is of the desired type and should take precautions before rendering or executing any attached content.

Access Control

For most resources, the type of information that can be conveyed in the resource is determined by the resource, and the key attributes that determine the sensitivity level of the information are also known; e.g., drug, observation type, clinical trial randomization status, etc. However, for QuestionnaireResponse, the sensitivity of an instance is dependent on what type of Questionnaire it is associated with. And the data elements that determine that sensitivity could be the answers to any of the questions. This makes automatically enforcing access control rules more challenging. Designers should take these challenges into account and may need to place stricter access controls around QuestionnaireResponse to ensure that access to information is not granted improperly.

Searching QuestionnaireResponses by answers

Until recently, there were no 'standard' SearchParameters defined to allow searching QuestionnaireResponse based on the answers within the response. A set of parameters have now been added. However, implementers using them should pay close attention to the following guidance:

Profiling QuestionnaireResponses

It is possible to profile QuestionnaireResponse in the same way as any other resource. However, such profiling should not be used to constrain QuestionnaireResponse to only be able to capture the answers associated with a single type of form - that is what the Questionnaire resource is for. Profiling QuestionnaireResponse is appropriate when there's a need to enforce that certain metadata is always present, to indicate limitations on what types of answers can be handled, etc. - independent of what Questionnaire is being completed.

FHIRPath Additions

When working with QuestionnaireResponses, there may be FHIRPath expressions defined on the associated Questionnaire that will be evaluated in the context of the QuestionnaireResponse. The following additional guidance applies to using FHIRPath with QuestionnaireResponses:

In addition, a couple of additional variables are defined for use with extensions evaluated in the context of a QuestionnaireResponse:

StructureDefinition

Elements (Simplified)

Mappings

Implementation Guide

implementationguide-QuestionnaireResponse-core.xml

<?xml version="1.0" encoding="UTF-8"?>

<ImplementationGuide xmlns="http://hl7.org/fhir">
  <id value="QuestionnaireResponse-core"/>
  <name value="CoreExtensionsForQuestionnaireResponse"/>
  <title value="Core extensions for  Questionnaire Response"/>
  <status value="draft"/>
  <date value="2013-07-04T00:00:00.000"/>
  <publisher value="HL7"/>
  <description value="Contains standard extensions for QuestionnaireResponse, amongst others for validation"/>
</ImplementationGuide>

Resource Packs

list-QuestionnaireResponse-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir">
  <id value="QuestionnaireResponse-packs"/>
  <status value="current"/>
  <mode value="working"/>
  <entry>
    <item>
      <reference value="ImplementationGuide/QuestionnaireResponse-core"/>
    </item>
  </entry>
</List>

Search Parameters

Full Search Parameters

Examples

Full Examples

Mapping Exceptions

questionnaireresponse-event-mapping-exceptions.xml

Divergent Elements

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. | resource=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 recorded date is NOT intended to be the same as a database.createdTimestamp - that would be captured as part of resource.meta or possibly Provenance.

It is possible for the same event to be disclosed to different systems at different times. E.g. a patient might tell two different clinicians about a historical event at different visits. If the disclosure is from the patient rather than record transfer from clinician A to B, the recorded date would be the date each respective clinician put the data in their record. If the data flowed from clinician A to B, the recorded date would remain the recorded date as initially set in clinician A's system. | resource=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.

Unmapped Elements

questionnaireresponse-fivews-mapping-exceptions.xml

Unmapped Elements