---
type: "resource"
title: "Questionnaire"
resource: "Questionnaire"
---
# Questionnaire
## Introduction
## Scope and Usage
A **Questionnaire** is an organized collection of questions intended to solicit information from patients, providers or other individuals involved in the healthcare domain. They may be simple flat lists of questions or can be hierarchically organized in groups and sub-groups, each containing questions. The **Questionnaire** defines the questions to be asked, how they are ordered and grouped, any intervening instructional text and what the constraints are on the allowed answers. The results of a **Questionnaire** can be communicated using the [QuestionnaireResponse](questionnaireresponse) resource.
Questionnaires 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. Questionnaires define specifics about data capture - exactly what questions were asked, in what order, what choices for answers were, 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. (Questionnaire questions can be linked to shared data elements using the `Questionnaire.item.definition` element.)
In addition to its use as a means for capturing data, Questionnaires can also be useful as a mechanism of defining a standardized 'presentation' of data that might already exist. For example, a peri-natal form or diabetes management form. In this use, the benefit is to expose a large volume of data in a predictable way that can be defined outside the user-interface design of the relevant system. The form might allow data to be edited or might be read-only. In some cases, the QuestionnaireResponse might not be intended to be persisted.
Examples of Questionnaires include:
- Past medical history (PMH)
- Family diseases
- Social history
- Research questionnaires/Clinical research forms (CRFs)
- Quality and evaluation forms
- Patient intake form (e.g. clipboard)
- Forms to support insurance claims
This resource is limited in scope to support the characteristics of simple questionnaires. However, common extensions have been defined to allow more sophisticated behavior. This includes:
- [Questionnaire core extensions](questionnaire-core) which defines the additional descriptive characteristics for questionnaires and their groups and questions
- [Element extensions](element-extensions) which can describe additional constraints on allowed answers for questionnaires such as string length and date and numeric ranges
Additional implementation guides, in particular the [Structured Data Capture Questionnaire IG](#sdc) provide guidance, extensions and operations that support additional capabilities and allow the definition of more sophisticated questionnaires and their corresponding responses.
## Boundaries and Relationships
**Questionnaires** are intrinsically bound to [QuestionnaireResponses](questionnaireresponse) in that a Questionnaire defines the questions and rules for answering them that are used in completing the QuestionnaireResponse. The main difference between them is that Questionnaires define 'permitted' answers and are subject and time-independent, while QuestionnaireResponses define a specific user's answers to a Questionnaire at a particular time-point and are focused on a specific subject. As well, the QuestionnaireResponse doesn't convey any of the rules or 'potential' answers the way Questionnaire does. It only conveys the answers selected by the user.
Questionnaires differ from [Lists](list) because [Lists](list) group existing resources, while **Questionnaires** group arbitrary questions. Questionnaires are distinct from [Observations](observation) and [DiagnosticReports](diagnosticreport) in that both of these resources are intended to capture only certain types of information (lab, imaging, vitals, etc.) and should not be used to capture the full breadth of healthcare information (allergies, medications, care plans, etc.), while Questionnaires are able to capture any information at all. More importantly, Observation and DiagnosticReport focus on capturing the discrete information in a standardized form so that the information can be used consistently regardless of where or how it is captured. Questionnaire focuses on information capture. The same information can be captured using a wide variety of questionnaires with differently phrased questions organized in different manners. As such, the Questionnaire resource provides a means to standardize the information gathering process (how information is captured), but not how data is interoperably compared, analyzed or computed upon (typically managed using Observation, DiagnosticReport as well as other resources).
Questionnaires are similar to [ObservationDefinitions](observationdefinition) in that both are about defining structures for capturing certain information and setting constraints on what allowed answers are. They can also define hierarchical constructs containing multiple layers of 'arbitrary' nested data elements. However, ObservationDefinitions are instantiated by Observations and are intended to be limited to only those data elements typically captured as Observations, while Questionnaires can describe any element at all and are instantiated by QuestionnaireResponses. Questionnaires also have significantly more power to identify rules around what data can be captured and when, as well as allowed answers. While both support nesting, ObservationDefinition nesting is focused on panels and is limited to a single level within the resource, while Questionnaire can define nesting of arbitrary depth for any purpose.
Questionnaires are similar to [Compositions](composition) in that both organize collections of items and can have a hierarchical structure. They're also intended to help guide 'human' presentation of data. However, Compositions organize resources, while Questionnaires organize specific elements. Also, a Questionnaire represents data 'to be gathered' and is subject-independent, while Compositions represent collections of data that are complete and are about a particular subject. It is possible for [StructureDefinitions](structuredefinition) or [GraphDefinitions](http://build.fhir.org/HL7/api-incubator/StructureDefinition-GraphDefinition) to act as 'templates' for FHIR documents that guide what data is collected for a particular purpose (e.g. a referral), but this differs from the gathering process that a Questionnaire provides where there are specific questions that must be asked and answered and rules that guide which questions are enabled in which circumstances.
Questionnaire supports data-collection workflow to a limited extent, in that - once triggered - a Questionnaire can guide a user through a data collection process that ensures appropriate information is collected based on answers to particular questions. However, Questionnaire doesn't provide support for capturing sets of information at different times or highly interactive data capture. Broader workflow is typically managed using PlanDefinition and Task or using other mechanisms such as CDSHooks.
Questionnaires are similar to the notion of "logical models" supported by the [StructureDefinition](structuredefinition) resource. Both support the representation of a collection of data points with labels, data types and hierarchy. It will be common to find the two of them mapped together. The primary difference is that Questionnaire is focused on user-facing data collection. It describes specific questions and includes information such as what number/label should be displayed beside each question, conditions in which questions should be displayed (or not), what instructions should be provided to the user, etc. StructureDefinition, on the other hand, merely defines a data structure with no guidance on display or rules around capture mechanism, only what data should exist in the end. As well, logical models are not intended to capture data directly. Rather, they provide a basis for mapping between data capture structures.
Questionnaires are excellent tools for data capture. They allow tight control over what data is gathered and ensure information is gathered consistently across multiple users. However, data gathered using different questionnaires - or even different versions of the same questionnaire - is often not comparable. It is also not very searchable or easily integrated with discrete data sources. Because of this, the general recommendation in FHIR is to use questionnaires for raw data capture but then to convert the resulting QuestionnaireResponse instances into other FHIR resources - Observations, MedicationStatements, FamilyMemberHistories, etc. This allows the data gathered to then be easily combined with other data into FHIR documents and messages and exposed over FHIR REST interfaces.
## Background and Context
Groups and questions that make up a Questionnaire can use the `definition` element to refer to data elements in external code systems and [StructureDefinitions](structuredefinition). In this way, it's possible to leverage standard definitions of questions and their associated data types and answer sets across questionnaires. This also allows extraction of the data from a questionnaire response into other data structures (e.g. populating a [ServiceRequest](servicerequest) or [CarePlan](careplan) from information in a completed questionnaire response. It can also support other sorts of post-processing of the data contained in a questionnaire response. However, use of the definition element is not required and Questionnaires may be quite loosely defined. The section [Questionnaire versus Resources](#qversusr) below discusses the issues of collecting data in such loosely defined Questionnaires versus collecting data as well-defined separate Resources.
## Notes
## Notes:
- Questionnaires may be used to represent predefined forms or panels, referenced using items of type "group"
- Questions may be nested. The Questionnaire resource supports nested items beneath both items of type "group" (which doesn't capture an answer of its own) as well as beneath questions
- Groups and Questions may have linkIds allowing groups and question answers captured in a [QuestionnaireResponse](questionnaireresponse) to be associated with their corresponding group or question.
- Questionnaire allows for flexible naming and structuring of its contents to reflect the flexible and varying nature of forms and questionnaires. It explicitly does not try to standardize or streamline exchange of its contents outside its context of use, although exchanging partners may further constrain its structure and flexibility using profiles to define standardized, reusable forms.
- Because of the lack of explicit support for Questionnaires in [HL7 v3](https://www.hl7.org/implement/standards/product_brief.cfm?product_id=186), [CDA](http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7) Documents frequently used named sections with Observations to model Questionnaires. Such use cases should now use the Questionnaire Resource instead.
- The order of questions within groups, groups within groups and groups within questions is relevant and must be retained for display and capture.
- Display items allow the inclusion of instructions, background information and similar content within a questionnaire.
- In cases where it is necessary or appropriate to capture the reason why a response is missing (that is, why a particular question was not answered), there should be an explicit child item defined for the relevant question(s) in the Questionnaire; e.g. add a child question of "Reason not specified:" with an enableWhen operator "not exists" to the parent question.
### Structured Data Capture
The base questionnaire resource is aimed at the capabilities of "most" healthcare systems that deal with forms and questionnaires. While the resource structure supports a reasonable degree of complexity, it doesn't provide the degree of control over rendering, question flow and data management needed by some portions of the healthcare space. Many of these more sophisticated requirements are addressed by a supplemental implementation guide called [Structured Data Capture (SDC)](http://hl7.org/fhir/uv/sdc/). This implementation guide covers the following capabilities, plus several others:
- Rendering grids of questions, multi-column drop-downs, multi-language questionnaires, and other 'advanced' formatting capabilities
- Advanced dynamic questionnaires including calculated scores, enabling of questions and groups based on complex logic, drop-downs driven by answers to other questions
- Support for populating questionnaires from existing clinical data based on the current patient, encounter, etc., including the ability to render the form as HTML or to redirect to a website to complete unanswered items
- Support for extracting information from a completed QuestionnaireResponse to generate other FHIR resources such as Observations, MedicationStatements, etc.
- Support for completing 'adaptive' questionnaires (see below)
### Adaptive Questionnaires
Some questionnaires might not provide a full listing of questions, instead relying on a service to interactively send partially completed forms to a server which generates the next set of questions. As such, some questionnaires might be 'active' but have either no questions or an insufficient set of questions for their purpose. Further guidance on the use of such forms, can be found in the [SDC](#sdc) implementation guide.
### Using Questionnaires versus using Resources
There is considerable overlap between the information covered by **Questionnaires** and other Resources (especially [FamilyMemberHistory](familymemberhistory), [MedicationStatement](medicationstatement), [Observation](observation), [Procedure](procedure), etc.). **Questionnaire's** flexible structure can easily be misused to capture any data, even data that should be captured as separate Resources. The choice between using **Questionnaires** or separate Resources may be dictated by the procedure of collection and recording; e.g. if the data is captured as a physician-agreed (electronic) form, it might be impossible or undesirable to distill separate resources from it and capturing the data in a **Questionnaire** would be most appropriate.
However, data captured only in **Questionnaires** can be difficult to query after-the-fact. Queries against other Resources will not return data captured only in **Questionnaires** and querying against **Questionnaires** directly might not find all desired data, depending on how the questions may have been phrased or encoded over time or by different clinicians. Moreover, interoperability of such **Questionnaires** is limited, as interpretation of its contents is only known to the circle of parties that were involved in its definition: encoding data from such **Questionnaires** using more specific resources increases the availability of the information they contain.
It is entirely possible for data to exist in both QuestionnaireResponse and in other resources. For example, data may be captured in [QuestionnaireResponse](questionnaireresponse) as part of an intake questionnaire. That data may then be propagated into the [Patient](patient) resource (demographics), [FamilyMemberHistory](familymemberhistory), [AllergyIntolerance](allergyintolerance), [MedicationStatement](medicationstatement) and/or [Observation](observation) resources to allow the data to be queried and analyzed. The original [QuestionnaireResponse](questionnaireresponse) instance can be retained for traceability purposes. If desired, a [Provenance](provenance) resource can be used to identify the Questionnaire as the data source for the other resources. For example, if a questionnaire question asks "what is your weight", an [Observation](observation) with the appropriate `Observation.code` and the specified answer as the `Observation.valueQuantity` can be created.
### Profiling Questionnaires
[Profiling](profiling) can be used to define the constraints of a set of Questionnaires - for example that a particular system only supports Questionnaires where answers have certain data types, only recognizes certain extensions, mandates the presence of certain metadata, etc. However, profiling should NOT be used to define the content of a specific Questionnaire instance. To define a Questionnaire instance, simply create an instance of Questionnaire as you would any other resource.
### Structure of the Questionnaire
A Questionnaire is built out of two components, Questionnaire and item:
- The main component is Questionnaire, which holds information _about_ the Questionnaire, like the identifier, publisher, date authored, title, etc. The Questionnaire contains zero or more items which define the content of the questionnaire (zero items allows for the possibility of narrative-only questionnaires, though these provide little computable information).
- Items have one of three sub-types, distinguished by the `type` element:
- **display** items convey text to be rendered on the form that won't capture data and which won't contain nested items. This might include copyright or authorship information, instructions or other background information.
- **group** items organize content of the questionnaire into sections, sub-sections, etc. Groups don't have answers associated with them directly, but generally contain child 'question' items which do.
- **question** items ask a specific question to which an answer may be given. There isn't a single `type` for question items. Instead, the type conveys the data type of the answer for the question. If an item isn't a 'display' or a 'group', then it is a question which allows a particular type of answer to be gathered. Questions may also have nested content - groups and/or other questions. This way, one can model "panels" of questions which would only be relevant (and thus would only be displayed) depending on the answers of a parent question; e.g. a question "Did the patient receive treatment in the past six months?" would contain a nested group of questions asking for further details about the treatment. See an [example](questionnaire-example-bluebook.xml) from the [Australian New South Wales blue book](http://www.health.nsw.gov.au/Kids/Publications/my-personal-health-record.pdf)
Specific controls on dynamic display of groups, questions, etc. based on the answers to other questions is outside the scope of the base resource and are handled using extensions.
Group text is intended to provide a "label" for a collection of nested items. The text will often be rendered in a "heading" style. As such, it should be kept relatively short. Detailed instructions should be conveyed by a nested "display" item. It's not necessary to create groups in order to relate an instruction to a collection of questions - you can simply intermix display items and questions or groups, with the expectation that users will see the display text before encountering the following questions.
### Group properties
Some properties defined at the 'group' level will impact the behavior of everything within the group. For example, if a 'group' item is marked as readOnly=true, then all items within that group are automatically treated as readOnly - even if they explicitly declare readOnly=false. The same holds for enableWhen. If a group is 'disabled' based on its enableWhen settings, then all child items are automatically disabled - regardless of whether they have enableWhen declared or how those enableWhen conditions might resolve. Some extensions (e.g. the SDC 'hidden' extension) behave in the same manner. Systems MAY choose to raise errors or warnings if questionnaires have conflicting settings. E.g. if a group is marked as readOnly=true and a descendant item explicitly declares readOnly=false. This wouldn't be because the behavior is unclear, but more to draw the author's attention to the fact that their desired behavior for the child will not be realized due to the setting of the ancestor group.
Behavior of parent 'question' items (i.e. questions with child groups or questions) can also influence descendant elements, but not as strongly. If a question is readOnly, that doesn't mean that child items are also readOnly. However, if a question is disabled, all descendant items are also disabled. Similarly, a 'hidden' question, would hide child elements as well.
### LinkIds
LinkIds are globally unique in a Questionnaire and are how items in a [QuestionnaireResponse](questionnaireresponse) are tied to their corresponding Questionnaire item. The QuestionnaireResponse page includes a [diagram](questionnaire#link) showing how response items are linked to their corresponding Questionnaire items. Questions and their responses are tied together by their linkIds. LinkIds are unique across all items in a Questionnaire, but can sometimes appear multiple times within a [QuestionnaireResponse](questionnaireresponse). The diagram on the right 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.
### Identifiers within Questionnaire
There are three different "identifying" elements within Questionnaire: `identifier`, `id` and `linkId`. Each serves very distinct purposes:
- The **identifier** element is used to reference the overall questionnaire in business terms. It is the number printed across the top of the form or listed beside the form when making a choice between alternate forms.
- The **id** attribute supported on each element is used for references within a resource, for example linking narrative to discrete elements. Ids are not generally displayed to end users
- The **linkId** element on questions and groups establishes a link between elements in a [QuestionnaireResponse](questionnaireresponse) and their definition inside a Questionnaire. This is the _only_ way to link between the groups and questions in a Questionnaire and QuestionnaireResponse. These are also not displayed to end users
### Question Definitions
Questionnaires can be crafted using any questions the author can conceive and can be phrased in whatever manner is appropriate or convenient. However, standardization of questions and the constraints enforced on the accompanying answers increases the ability to compare data gathered across questionnaires. Items can be directly linked to an [ElementDefinition](elementdefinition) using `Questionnaire.item.definition` which provides details for the item. The SDC guide has defined an [assembly](https://build.fhir.org/ig/HL7/sdc/en/modular.html) process to support retrieving and injecting information from definitions into a Questionnaire. In most cases, systems rendering forms can't be expected to do this automatically as part of form display without a separate workflow step. If a definition is provided, then the following element values can be derived from the definition:
- code (from ElementDefinition.code)
- text (from ElementDefinition.label)
- required (inferred from ElementDefinition.min)
- repeats (inferred from ElementDefinition.max)
- maxLength (from ElementDefinition.maxLength)
- answerValueSet (from ElementDefinition.binding.valueSet)
- initial.value\[x\] or fixed\[x\] (from ElementDefinition.defaultValue\[x\] - depending on whether readOnly is set)
QuestionnaireResponse.item.type corresponds to ElementDefinition.type, however item.type is mandatory in Questionnaire, so it can't be 'populated' because it must exist for the item to exist at all. However, the values specified for item.type and ElementDefinition.type do need to correspond. Complex types such as Address or anything based on BackboneElement would correspond to 'group', while simple types would normally map directly.
In addition, extensions and elements that have corresponding extensions should also propagate. Specifically:
- Any extensions that have a context of both ElementDefinition and Questionnaire.item (e.g. [maxSize]([%extensions-location%]StructureDefinition-maxSize)) should propagate
- Any extensions defined for Questionnaire.item that directly correspond to elements on ElementDefinition should also propagate. E.g.:
- ElementDefinition.minValue\[x\] -> [minValue]([%extensions-location%]StructureDefinition-minValue)
- ElementDefinition.maxValue\[x\] -> [maxValue]([%extensions-location%]StructureDefinition-maxValue)
- There are Questionnaire extensions defined in the [SDC IG](http://hl7.org/fhir/uv/sdc) that correspond to min, max, type.targetProfile and constraint
Any information provided in these elements overrides the information from the definition, and some are always required to be populated so that invariants can be enforced, etc. The url refers to an ElementDefinition in [StructureDefinition](structuredefinition), and always starts with the canonical URL for the target resource. When referring to a StructureDefinition, a fragment identifier is used to specify the element definition by its id (Element.id). E.g. http://hl7.org/fhir/StructureDefinition/Observation#Observation.value\[x\]. In the absence of a fragment identifier, the first/root element definition in the target is the matching element definition. Examples:
| Value of definition | Explanation |
| --- | --- |
| `http://hl7.org/fhir/StructureDefinition/Observation#Observation.effectiveDateTime` | A reference to the standard Observation element `effectiveDateTime` |
| `http://example.org/definitions/xxx` | A reference to the [logical model](structuredefinition#logical) "xxx" that represents a data element |
| `http://example.org/StructureDefinition/Oedema#Observation.category:XXX` | A reference to slice `XXX` on the Observation `category` element on an Oedema Scale profile |
| `http://example.org/StructureDefinition/Oedema|2.0#Observation.category:XXX` | A reference to slice `XXX` on the Observation `category` element on an Oedema Scale profile, specifying version 2.0 |
The definitions may also be used to automatically pre-populate answers, or extract data from a corresponding pre-existing [QuestionnaireResponse](questionnaireresponse) resource.
Note that LOINC codes [implicitly](https://terminology.hl7.org/LOINC.html) define logical models whose elements can be considered question definitions.
NOTE: Even if a standard question definition is provided, information such as the question text, data type and value set SHOULD still be declared for the question. Systems processing the questionnaire might not have access to or support the ability to look up the question definitions from external sources. If the information is not included in-line within the questionnaire, other systems might not be able to render or use the Questionnaire. The [questionnaire-definitionBased]([%extensions-location%]StructureDefinition-questionnaire-definitionBased) extension can be used to flag that a questionnaire requires the ability to resolve and use item.definition information to fully understand the Questionnaire. Systems that validate, render or otherwise process the questionnaire SHOULD check for this extension.
If an external definition is included along with question information such as question text, data type or value set, it is expected that the content for the question and the referenced definition would be in alignment. However, FHIR does not dictate what degree of alignment is required; e.g. Does the question text need to match exactly? Is it legitimate for a question to constrain the allowed value set of possible answers? These rules will need to be established within implementation environments.
### Question types
The codes for the data type for each question are slightly different than the data types allowed in the [QuestionnaireResponse](questionnaireresponse) resource. Where the names are the same (ignoring case), the "answer" must use the specified type. Where the names are different, the mappings are as follows:
| Questionnaire AnswerFormat code | QuestionnaireResponse data type |
| --- | --- |
| text | [string](datatypes#string) |
| url | [uri](datatypes#uri) |
| coding | [Coding](datatypes#Coding) |
### Permitted values for questions
Many questionnaires place constraints on the allowed list of values for a given question. FHIR supports this notion through the `item.answerValueSet` or the `item.answerOption` element.
The "answerOption" mechanism is simplest - all possible answers are listed in-line with the question using the `item.answerOption` element. Maintenance of the set of permitted question answers involves maintenance of the questionnaire itself.
The "answerValueSet" mechanism is more sophisticated. Rather than listing the possible answers directly, the `item.answerValueSet` element refers to a [ValueSet](valueset) resource. This approach adds complexity for questionnaires having a simple list of strings as choices for a question, but provides several benefits, including:
- Questionnaires that reference codes from externally defined code systems have a means of doing so
- Answer sets can be shared across questions (and there are many questionnaires where this capability is useful)
- The full capability of value sets can be brought into play, including the ability to use ConceptMap to link and translate from questionnaire-specific codes to other codes, the use of multiple display names (e.g. different languages), the ability to use coded ordinals, and the ability to allow choices from larger value sets (e.g. "all SNOMED CT procedure codes")
In many cases, the set of code choices will be specific to a given questionnaire and should be maintained as part of the questionnaire. In this case, the referenced ValueSet can be included as a [contained](references#contained) resource. All contained ValueSets are listed together and then are referenced by the individual questions as necessary. Alternatively, the `item.answerValueSet` element can reference the value set in a version-specific manner. This ensures that the Questionnaire will not adopt a new version of the referenced value set without revising the Questionnaire to point to that new version - putting the author of the Questionnaire in control of any changes.
### Useful Value Sets
Many questions have a common set of possible codes for their answer. These value sets may be useful to help, and when referenced by full URL, do not need to be provided as part of the questionnaire:
- [Yes | No | Don't Know](valueset-example-yesnodontknow): http://hl7.org/fhir/ValueSet/yesnodontknow
### Handling Boolean Answers
In a questionnaire response, a question of type 'boolean' can have 3 possible states - unanswered, answered true, and answered false. Users will generally need to be able to toggle through all three states. If a default value is specified and the element is mandatory, a simple control with only true and false options (e.g. traditional check-box) will suffice. However, if a three-state selection is required, the typical controls used in HTML and other rendering technologies for booleans might not be appropriate. E.g. a checkbox that can only convey 'true' or 'false' will not be able to differentiate 'unanswered' and thus is generally not appropriate. If a tri-state control is available, that would work well. Alternatively, a set of radio buttons allow choices of true, false or "no answer" could also work.
As well, when enableWhen expressions are used that reference boolean elements, designers should consider whether "non-answered" is a possible value for boolean questions and design their enableWhen logic accordingly.
### Questions with multiple answer types
In some questionnaires, it may be possible to respond to a question with multiple types of answers. For example, capturing a coded answer plus free text, capturing a coded value plus a numeric priority, etc. In FHIR, this is handled through nested questions. Each question has a single data type. However, each question can have nested child questions. These nested child questions can have text (e.g. "Please specify") or can have no text at all if the appropriate guidance is provided by the parent question or group.
### Questionnaires with Math
Many questionnaires involve computations on questionnaire answers, e.g. tabulating scores. To help with associating numeric values to coded answers, the [itemweight]([%extensions-location%]StructureDefinition-itemWeight) extension can be used to define the numeric weighting of a code defined in a value set or in the questionnaire itself.
In addition, there are extensions for defining the dynamic value of an element using expressions. For more information, see the [Using Expressions](clinicalreasoning-topics-using-expressions) and [Documentation Template](clinicalreasoning-knowledge-artifact-representation#documentation-template) topics in the Clinical Reasoning module.
### Questionnaire workflow
Once a Questionnaire is defined, there's often a need to 'assign' a Questionnaire to a particular individual to request them to complete it. This is not done using the Questionnaire resource directly. Instead, the Questionnaire is referenced as an 'input' or argument using one of FHIR's [workflow patterns](workflow-communications). The most common mechanism is by defining a stand-alone Task that references the Questionnaire and seeks completion. The SDC implementation guide defines profiles and guidance for using this mechanism.
### More advanced questionnaires
The capabilities of the Questionnaire resource are fairly simple and try to adhere to what most systems that deal with questionnaires would be capable of. However, there are lots of systems that require more sophisticated capabilities, such as:
- Greater control over rendering, including tables, read-only values, hidden answers, multi-column drop-downs
- Greater control over question flow, including formula-based rules for conditional display of elements
- Ability to pre-populate forms with data found in the client system
- Ability to define how to convert a completed QuestionnaireResponse for a Questionnaire into a collection of Observations and/or other resources
Extensions have been defined for all of these purposes and many more. (Questionnaire has the most 'core' extensions of any resource to-date.) A list of these extensions can be found [here](questionnaire-profiles#extensions). However, some of the extensions are complex and work together in particular ways. To support more advanced questionnaire implementation, the [Structured Data Capture (SDC)](http://hl7.org/fhir/uv/sdc) implementation guide has been created to provide non-country-specific guidance on the use of most of these extensions and sets expectations for systems wishing to support more complex forms.
## StructureDefinition
### Elements (Simplified)
- **[Questionnaire](/questionnaire-definitions#Questionnaire)** [0..*]: - A structured set of questions
- **[Questionnaire.url](/questionnaire-definitions#Questionnaire.url)** [0..1]: [uri](/uri) Canonical identifier for this questionnaire, represented as an absolute URI (globally unique)
- **[Questionnaire.identifier](/questionnaire-definitions#Questionnaire.identifier)** [0..*]: [Identifier](/Identifier) Business identifier for questionnaire
- **[Questionnaire.version](/questionnaire-definitions#Questionnaire.version)** [0..1]: [string](/string) Business version of the questionnaire
- **[Questionnaire.versionAlgorithm[x]](/questionnaire-definitions#Questionnaire.versionAlgorithm%5Bx%5D)** [0..1]: [string](/string), [Coding](/Coding) extensible:[version-algorithm](/valueset-version-algorithm) How to compare versions
- **[Questionnaire.name](/questionnaire-definitions#Questionnaire.name)** [0..1]: [string](/string) Name for this questionnaire (computer friendly)
- **[Questionnaire.title](/questionnaire-definitions#Questionnaire.title)** [0..1]: [string](/string) Name for this questionnaire (human friendly)
- **[Questionnaire.derivedFrom](/questionnaire-definitions#Questionnaire.derivedFrom)** [0..*]: [canonical](/canonical) Based on Questionnaire
- **[Questionnaire.status](/questionnaire-definitions#Questionnaire.status)** [1..1]: [code](/code) required:[publication-status](/valueset-publication-status) draft | active | retired | unknown
- **[Questionnaire.experimental](/questionnaire-definitions#Questionnaire.experimental)** [0..1]: [boolean](/boolean) For testing only - never for real usage
- **[Questionnaire.subjectType](/questionnaire-definitions#Questionnaire.subjectType)** [0..*]: [code](/code) required:[resource-types](/valueset-resource-types) Resource that can be subject of QuestionnaireResponse
- **[Questionnaire.date](/questionnaire-definitions#Questionnaire.date)** [0..1]: [dateTime](/dateTime) Date last changed
- **[Questionnaire.publisher](/questionnaire-definitions#Questionnaire.publisher)** [0..1]: [string](/string) Name of the publisher/steward (organization or individual)
- **[Questionnaire.contact](/questionnaire-definitions#Questionnaire.contact)** [0..*]: [ContactDetail](/ContactDetail) Contact details for the publisher
- **[Questionnaire.description](/questionnaire-definitions#Questionnaire.description)** [0..1]: [markdown](/markdown) Natural language description of the questionnaire
- **[Questionnaire.useContext](/questionnaire-definitions#Questionnaire.useContext)** [0..*]: [UsageContext](/UsageContext) The context that the content is intended to support
- **[Questionnaire.jurisdiction](/questionnaire-definitions#Questionnaire.jurisdiction)** [0..*]: [CodeableConcept](/CodeableConcept) extensible:[jurisdiction](/valueset-jurisdiction) Jurisdiction of the authority that maintains the questionnaire (if applicable)
- **[Questionnaire.purpose](/questionnaire-definitions#Questionnaire.purpose)** [0..1]: [markdown](/markdown) Why this questionnaire is defined
- **[Questionnaire.copyright](/questionnaire-definitions#Questionnaire.copyright)** [0..1]: [markdown](/markdown) Notice about intellectual property ownership, can include restrictions on use
- **[Questionnaire.copyrightLabel](/questionnaire-definitions#Questionnaire.copyrightLabel)** [0..1]: [string](/string) Copyright holder and year(s)
- **[Questionnaire.approvalDate](/questionnaire-definitions#Questionnaire.approvalDate)** [0..1]: [date](/date) When the questionnaire was approved by publisher
- **[Questionnaire.lastReviewDate](/questionnaire-definitions#Questionnaire.lastReviewDate)** [0..1]: [date](/date) When the questionnaire was last reviewed by the publisher
- **[Questionnaire.effectivePeriod](/questionnaire-definitions#Questionnaire.effectivePeriod)** [0..1]: [Period](/Period) When the questionnaire is expected to be used
- **[Questionnaire.code](/questionnaire-definitions#Questionnaire.code)** [0..*]: [Coding](/Coding) example:[questionnaire-questions](/valueset-questionnaire-questions) Concept that represents the overall questionnaire
- **[Questionnaire.item](/questionnaire-definitions#Questionnaire.item)** [0..*]: [BackboneElement](/BackboneElement) Questions and sections within the Questionnaire
- **[Questionnaire.item.linkId](/questionnaire-definitions#Questionnaire.item.linkId)** [1..1]: [string](/string) Unique id for item in questionnaire
- **[Questionnaire.item.definition](/questionnaire-definitions#Questionnaire.item.definition)** [0..*]: [uri](/uri) ElementDefinition - details for the item
- **[Questionnaire.item.code](/questionnaire-definitions#Questionnaire.item.code)** [0..*]: [Coding](/Coding) example:[questionnaire-questions](/valueset-questionnaire-questions) Corresponding concept for this item in a terminology
- **[Questionnaire.item.prefix](/questionnaire-definitions#Questionnaire.item.prefix)** [0..1]: [string](/string) E.g. "1(a)", "2.5.3"
- **[Questionnaire.item.text](/questionnaire-definitions#Questionnaire.item.text)** [0..1]: [string](/string) Primary text for the item
- **[Questionnaire.item.type](/questionnaire-definitions#Questionnaire.item.type)** [1..1]: [code](/code) required:[item-type-useable](/valueset-item-type-useable) group | display | boolean | decimal | integer | date | dateTime +
- **[Questionnaire.item.enableWhen](/questionnaire-definitions#Questionnaire.item.enableWhen)** [0..*]: [BackboneElement](/BackboneElement) Only allow data when
- **[Questionnaire.item.enableWhen.question](/questionnaire-definitions#Questionnaire.item.enableWhen.question)** [1..1]: [string](/string) The linkId of question that determines whether item is enabled/disabled
- **[Questionnaire.item.enableWhen.operator](/questionnaire-definitions#Questionnaire.item.enableWhen.operator)** [1..1]: [code](/code) required:[questionnaire-enable-operator](/valueset-questionnaire-enable-operator) exists | = | != | > | < | >= | <=
- **[Questionnaire.item.enableWhen.answer[x]](/questionnaire-definitions#Questionnaire.item.enableWhen.answer%5Bx%5D)** [1..1]: [boolean](/boolean), [decimal](/decimal), [integer](/integer), [date](/date), [dateTime](/dateTime), [time](/time), [string](/string), [Coding](/Coding), [SimpleQuantity](/SimpleQuantity), Reference([Resource](/Resource)), [uri](/uri), [Attachment](/Attachment) example:[questionnaire-answers](/valueset-questionnaire-answers) Value for question comparison based on operator
- **[Questionnaire.item.enableBehavior](/questionnaire-definitions#Questionnaire.item.enableBehavior)** [0..1]: [code](/code) required:[questionnaire-enable-behavior](/valueset-questionnaire-enable-behavior) all | any
- **[Questionnaire.item.disabledDisplay](/questionnaire-definitions#Questionnaire.item.disabledDisplay)** [0..1]: [code](/code) required:[questionnaire-disabled-display](/valueset-questionnaire-disabled-display) hidden | protected
- **[Questionnaire.item.required](/questionnaire-definitions#Questionnaire.item.required)** [0..1]: [boolean](/boolean) Whether the item must be included in data results
- **[Questionnaire.item.repeats](/questionnaire-definitions#Questionnaire.item.repeats)** [0..1]: [boolean](/boolean) Whether the item may repeat
- **[Questionnaire.item.readOnly](/questionnaire-definitions#Questionnaire.item.readOnly)** [0..1]: [boolean](/boolean) Don't allow human editing
- **[Questionnaire.item.maxLength](/questionnaire-definitions#Questionnaire.item.maxLength)** [0..1]: [integer](/integer) No more than these many characters
- **[Questionnaire.item.answerConstraint](/questionnaire-definitions#Questionnaire.item.answerConstraint)** [0..1]: [code](/code) required:[questionnaire-answer-constraint](/valueset-questionnaire-answer-constraint) optionsOnly | optionsOrType | optionsOrString
- **[Questionnaire.item.answerValueSet](/questionnaire-definitions#Questionnaire.item.answerValueSet)** [0..1]: [canonical](/canonical) ValueSet containing permitted answers
- **[Questionnaire.item.answerOption](/questionnaire-definitions#Questionnaire.item.answerOption)** [0..*]: [BackboneElement](/BackboneElement) Permitted answer
- **[Questionnaire.item.answerOption.value[x]](/questionnaire-definitions#Questionnaire.item.answerOption.value%5Bx%5D)** [1..1]: [decimal](/decimal), [integer](/integer), [date](/date), [dateTime](/dateTime), [time](/time), [string](/string), [uri](/uri), [Coding](/Coding), [SimpleQuantity](/SimpleQuantity), Reference([Resource](/Resource)) example:[questionnaire-answers](/valueset-questionnaire-answers) Answer value
- **[Questionnaire.item.answerOption.initialSelected](/questionnaire-definitions#Questionnaire.item.answerOption.initialSelected)** [0..1]: [boolean](/boolean) Whether option is selected by default
- **[Questionnaire.item.initial](/questionnaire-definitions#Questionnaire.item.initial)** [0..*]: [BackboneElement](/BackboneElement) Initial value(s) when item is first rendered
- **[Questionnaire.item.initial.value[x]](/questionnaire-definitions#Questionnaire.item.initial.value%5Bx%5D)** [1..1]: [boolean](/boolean), [decimal](/decimal), [integer](/integer), [date](/date), [dateTime](/dateTime), [time](/time), [string](/string), [uri](/uri), [Attachment](/Attachment), [Coding](/Coding), [SimpleQuantity](/SimpleQuantity), Reference([Resource](/Resource)) example:[questionnaire-answers](/valueset-questionnaire-answers) Actual value for initializing the question
- **[Questionnaire.item.item](/questionnaire-definitions#Questionnaire.item.item)** [0..*]: - Nested questionnaire items
## Mappings
- [Questionnaire Mappings](/questionnaire-mappings) — 88 mapping entries
## Implementation Guide
### implementationguide-Questionnaire-core.xml
```xml
```
## Resource Packs
### list-Questionnaire-packs.xml
```xml
-
```
## Search Parameters
- [questionnaire-code](/questionnaire-search#questionnaire-code) — **token** — A code that matches one of the Questionnaire.code codings — `Questionnaire.code`
- [item-code](/questionnaire-search#item-code) — **token** — A code that corresponds to one of the items in the questionnaire — `Questionnaire.repeat(item).code`
- [combo-code](/questionnaire-search#combo-code) — **token** — A code that corresponds to one of its items in the questionnaire — `Questionnaire.code | Questionnaire.repeat(item).code`
- [context](/questionnaire-search#context) — **token** — A use context assigned to the questionnaire — `(Questionnaire.useContext.value.ofType(CodeableConcept))`
- [context-quantity](/questionnaire-search#context-quantity) — **quantity** — A quantity- or range-valued use context assigned to the questionnaire — `(Questionnaire.useContext.value.ofType(Quantity)) | (Questionnaire.useContext.value.ofType(Range))`
- [context-type](/questionnaire-search#context-type) — **token** — A type of use context assigned to the questionnaire — `Questionnaire.useContext.code`
- [context-type-quantity](/questionnaire-search#context-type-quantity) — **composite** — A use context type and quantity- or range-based value assigned to the questionnaire — `Questionnaire.useContext`
- [context-type-value](/questionnaire-search#context-type-value) — **composite** — A use context type and value assigned to the questionnaire — `Questionnaire.useContext`
- [date](/questionnaire-search#date) — **date** — The questionnaire publication date — `Questionnaire.date`
- [definition](/questionnaire-search#definition) — **uri** — ElementDefinition - details for the item — `Questionnaire.repeat(item).definition`
- [description](/questionnaire-search#description) — **string** — The description of the questionnaire — `Questionnaire.description`
- [effective](/questionnaire-search#effective) — **date** — The time during which the questionnaire is intended to be in use — `Questionnaire.effectivePeriod`
- [identifier](/questionnaire-search#identifier) — **token** — External identifier for the questionnaire — `Questionnaire.identifier`
- [jurisdiction](/questionnaire-search#jurisdiction) — **token** — Jurisdiction of the authority that maintains the the questionnaire — `Questionnaire.jurisdiction`
- [name](/questionnaire-search#name) — **string** — Computationally friendly name of the questionnaire — `Questionnaire.name`
- [publisher](/questionnaire-search#publisher) — **string** — Name of the publisher of the questionnaire — `Questionnaire.publisher`
- [status](/questionnaire-search#status) — **token** — The current status of the questionnaire — `Questionnaire.status`
- [subject-type](/questionnaire-search#subject-type) — **token** — Resource that can be subject of QuestionnaireResponse — `Questionnaire.subjectType`
- [title](/questionnaire-search#title) — **string** — The human-friendly name of the questionnaire — `Questionnaire.title`
- [url](/questionnaire-search#url) — **uri** — The uri that identifies the questionnaire — `Questionnaire.url`
- [version](/questionnaire-search#version) — **token** — The business version of the questionnaire — `Questionnaire.version`
- [experimental](/questionnaire-search#experimental) — **token** — Whether the Questionnaire is experimental — `Questionnaire.experimental`
[Full Search Parameters](/questionnaire-search)
## Examples
- [3141](/questionnaire-example-3141) — questionnaire-example — General questionnaire example
- [bb](/questionnaire-example-bb) — questionnaire-example-bluebook — Neonate record from New South Wales, Australia "My Personal Health Record" example
- [child-rel-demo](/questionnaire-example-child-rel-demo) — questionnaire-child-rel-demo — Questionnaire with a variety of child item types (as used in the QuestionnaireResponse page links section)
- [example-practitioner-info](/questionnaire-example-example-practitioner-info) — questionnaire-example-practitioner-info — Questionnaire for Practitioner information with metadata inferred from definitions
- [f201](/questionnaire-example-f201) — questionnaire-example-f201-lifelines — Real-world lifelines questionnaire (fictively taken from the patient)
- [gcs](/questionnaire-example-gcs) — questionnaire-example-gcs — Glasgow Coma Score example form
- [questionnaire-example](/questionnaire-example-questionnaire-example) — questionnaire-example
- [questionnaire-example-bluebook](/questionnaire-example-questionnaire-example-bluebook) — questionnaire-example-bluebook
- [questionnaire-example-cms](/questionnaire-example-questionnaire-example-cms) — questionnaire-example-cms
- [questionnaire-example-f201-lifelines](/questionnaire-example-questionnaire-example-f201-lifelines) — questionnaire-example-f201-lifelines
- [questionnaire-example-gcs](/questionnaire-example-questionnaire-example-gcs) — questionnaire-example-gcs
- [questionnaire-example-practitioner-info](/questionnaire-example-questionnaire-example-practitioner-info) — questionnaire-example-practitioner-info
- [questionnaire-examples-header](/questionnaire-example-questionnaire-examples-header) — questionnaire-examples-header
- [ussg-fht](/questionnaire-example-ussg-fht) — questionnaire-profile-example-ussg-fht — LOINC US Surgeon General family history including value sets
- [zika-virus-exposure-assessment](/questionnaire-example-zika-virus-exposure-assessment) — questionnaire-zika-virus-exposure-assessment — Example instrument for assessing Zika virus exposure potential
[Full Examples](/questionnaire-examples)
## Mapping Exceptions
### questionnaire-definition-mapping-exceptions.xml
### Divergent Elements
- **Definition.url** → **Questionnaire.url**
- commentsUnmatched | reason=Incorporates content from profile with context-specific wording | pattern=Can be a `urn:uuid:` or a `urn:oid:` but real `http/s:` addresses are preferred. Multiple instances may share the same URL if they have a distinct version.
The determination of when to create a new version of a resource (same url, new version) vs. defining a new artifact is up to the author. Considerations for making this decision are found in [Technical and Business Versions](resource.html#versions).
In some cases, the resource can no longer be found at the stated url, but the url itself cannot change. Implementations can use the [meta.source](resource.html#meta) element to indicate where the current master source of the resource can be found. | resource=Can be a urn:uuid: or a urn:oid: but real http: addresses are preferred. Multiple instances may share the same URL if they have a distinct version.
The determination of when to create a new version of a resource (same url, new version) vs. defining a new artifact is up to the author. Considerations for making this decision are found in [Technical and Business Versions](resource.html#versions).
In some cases, the resource can no longer be found at the stated url, but the url itself cannot change. Implementations can use the [meta.source](resource.html#meta) element to indicate where the current master source of the resource can be found.
The name of the referenced questionnaire can be conveyed using the http://hl7.org/fhir/StructureDefinition/display extension.
Questionnaire.url SHOULD always be populated unless the Questionnaire is a contained resource (in which case it will be pointed to by the containing resource using id, not url. E.g. QuestionnaireResponse.questionnaire using '#[ContainedQuestionnaire.id]')
- **Definition.identifier** → **Questionnaire.identifier**
- commentsUnmatched | reason=Removed information not relevant to this resource | pattern=Typically, this is used for identifiers that can go in an HL7 V3 II (instance identifier) data type, and can then identify this questionnaire outside of FHIR, where it is not possible to use the logical URI.
- **Definition.derivedFromCanonical** → **Questionnaire.derivedFrom**
- missingTypes | reason=Derivation is only relevant/possible from other questionnaires | pattern=canonical(Definition)
- extraTypes | reason=Derivation is only relevant/possible from other questionnaires
- shortUnmatched | reason=Incorporates content from profile with context-specific wording | pattern=Based on FHIR protocol or definition | resource=Based on Questionnaire
- definitionUnmatched | reason=Incorporates content from profile with context-specific wording | pattern=The canonical URL pointing to another FHIR-defined protocol, guideline, orderset or other definition that is adhered to in whole or in part by this definition. | resource=The URL of a Questionnaire that this Questionnaire is based on.
- requirementsUnmatched | reason=Incorporates content from profile with context-specific wording | pattern=Protocols and order sets may be refinements of more generic protocols and order sets. | resource=Allows a Questionnaire to be created based on another Questionnaire.
- **Definition.subject** → **Questionnaire.subjectType**
- missingTypes | reason=The missing type(s) never apply in any context where this resource is used | pattern=CodeableReference(Group)
- extraTypes | reason=For Questionnaires, only need to identify type of subject based on resource type, so can be tighter.
- bindingStrength | reason=For Questionnaires, only need to identify type of subject based on resource type, so can be tighter. | pattern=example
- shortUnmatched | reason=Incorporates content from profile with context-specific wording | pattern=Type of individual the defined service is for | resource=Resource that can be subject of QuestionnaireResponse
- definitionUnmatched | reason=Incorporates content from profile with context-specific wording | pattern=A code or group definition that describes the intended subject of instantiations of this definition. | resource=The types of subjects that can be the subject of responses created for the questionnaire.
- requirementsUnmatched | reason=Incorporates content from profile with context-specific wording | pattern=Many protocols, order sets and guidelines are intended for use only with specific types of patients or subjects. | resource=Allows enforcing that a QuestionnaireResponse only has a .subject element of the appropriate type.
- **Definition.jurisdiction** → **Questionnaire.jurisdiction**
- shortUnmatched | reason=Unknown | pattern=Intended jurisdiction for questionnaire (if applicable) | resource=Jurisdiction of the authority that maintains the questionnaire (if applicable)
- definitionUnmatched | reason=Unknown | pattern=A legal or geographic region in which the questionnaire is intended to be used. | resource=A legal or geographic region in which the authority that maintains the resource is operating. In general, the jurisdiction is also found in the useContext. The useContext may reference additional jurisdictions because the defining jurisdiction does not necessarily limit the jurisdictions of use.
- commentsUnmatched | reason=Fixed small typo | pattern=It may be possible for the questionnaire to be used in jurisdictions other than those for which it was originally designed or intended
DEPRECATION NOTE: For consistency, implementations are encouraged to migrate to using the new 'jurisdiction' code in the useContext element. (I.e. useContext.code indicating http://terminology.hl7.org/CodeSystem/usage-context-type#jurisdiction and useContext.valueCodeableConcept indicating the jurisdiction.). | resource=It may be possible for the questionnaire to be used in jurisdictions other than those for which it was originally designed or intended.
DEPRECATION NOTE: For consistency, implementations are encouraged to migrate to using the new 'jurisdiction' code in the useContext element. (I.e. useContext.code indicating http://terminology.hl7.org/CodeSystem/usage-context-type#jurisdiction and useContext.valueCodeableConcept indicating the jurisdiction.)
- **Definition.effectivePeriod** → **Questionnaire.effectivePeriod**
- commentsUnmatched | reason=Incorporates content from profile with context-specific wording | pattern=The effective period for a questionnaire determines when the content is applicable for usage and is independent of publication and review dates. For example, a measure intended to be used for the year 2016 might be published in 2015. | resource=The effective period for a questionnaire determines when the content is applicable for usage and is independent of publication and review dates. For example, a questionnaire intended to be used for the year 2016 might be published in 2015.
See guidance around (not) making local changes to elements [here](canonicalresource.html#localization).
- **Definition.code** → **Questionnaire.code**
- missingTypes | reason=We use Coding rather than CodeableConcept because we don't want text | pattern=CodeableConcept
- extraTypes | reason=We use Coding rather than CodeableConcept because we don't want text
- shortUnmatched | reason=Incorporates content from profile with context-specific wording | pattern=Service to be done | resource=Concept that represents the overall questionnaire
- definitionUnmatched | reason=Incorporates content from profile with context-specific wording | pattern=A code that identifies the specific service or action that was or is being performed. | resource=An identifier for this collection of questions in a particular terminology such as LOINC.
### Unmapped Elements
- **Definition.product** — Questionnaires aren't tied to any particular product
- **Definition.derivedFromUri** — Not relevant for this resource
- **Definition.performerType** — Not relevant for this resource
- **Definition.partOf** — Composition of questionnaires is handled via extensions in the SDC IG
- **Definition.topic** — Handled as part of useContext
### questionnaire-fivews-mapping-exceptions.xml
### Unmapped Elements
- **FiveWs.what** — Unknown
- **FiveWs.actor** — Not relevant for this resource
- **FiveWs.cause** — Not relevant for this resource
- **FiveWs.witness** — Unknown
- **FiveWs.where** — Not relevant for this resource
- **FiveWs.context** — Unknown
- **FiveWs.init** — Not relevant for this resource
- **FiveWs.source** — Unknown
- **FiveWs.grade** — Not relevant for this resource
- **FiveWs.planned** — Not relevant for this resource
- **FiveWs.done** — Not relevant for this resource
- **FiveWs.subject** — Unknown