Questionnaire - FHIR v5.0.0

Questionnaire - FHIR v5.0.0
Release 5
Foundation
Questionnaire
This page is part of the FHIR Specification (v5.0.0: R5 -
STU
). This is the current published version. For a full list of available versions, see the
Directory of published versions
Page versions:
R5
R4B
R4
R3
R2
Content
Examples
Detailed Descriptions
Mappings
Operations
Search Params
Profiles
Extensions
R4 Conversions
2.5
Resource Questionnaire - Content
FHIR Infrastructure
Work Group
Maturity Level
: 5
Trial Use
Security Category
: Business
Compartments
: No defined compartments
A structured set of questions intended to guide the collection of answers from end-users. Questionnaires provide detailed control over order, presentation, phraseology and grouping to allow coherent, consistent data collection.
2.5.1
Scope and Usage
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
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
which defines the additional descriptive characteristics for questionnaires and their groups and questions
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
provide guidance, extensions and operations
that support additional capabilities and allow the definition of more sophisticated questionnaires and their corresponding responses.
2.5.2
Boundaries and Relationships
Questionnaires
are intrinsically bound to
QuestionnaireResponses
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
because
Lists
group existing resources, while
Questionnaires
group
arbitrary questions.
Questionnaires are distinct from
Observations
and
DiagnosticReports
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
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
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
or
GraphDefinitions
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
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.
2.5.3
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
. 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
or
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
below discusses the issues of collecting data in such
loosely defined Questionnaires versus collecting data as well-defined separate Resources.
2.5.4
References to this Resource
Implements:
Definition
Resource References:
CarePlan
Communication
ConditionDefinition
Contract
FamilyMemberHistory
...
Show 6 more
ObservationDefinition
PlanDefinition
Procedure
itself
QuestionnaireResponse
and
RequestOrchestration
Extension References:
Complies with
Generated from
ServiceRequest Questionnaire Requested
Shall comply with
Triggered by
and
adheres to
2.5.5
Resource Content
Structure
UML
XML
JSON
Turtle
R4 Diff
All
Structure
Name
Flags
Card.
Type
Description & Constraints
Questionnaire
TU
DomainResource
A structured set of questions
+ Warning: Name should be usable as an identifier for the module by machine processing applications such as code generation
+ Rule: The link ids for groups and questions must be unique within the questionnaire
Elements defined in Ancestors:
id
meta
implicitRules
language
text
contained
extension
modifierExtension
Interfaces Implemented:
MetadataResource
url
0..1
uri
Canonical identifier for this questionnaire, represented as an absolute URI (globally unique)
+ Warning: URL should not contain | or # - these characters make processing canonical references problematic
identifier
0..*
Identifier
Business identifier for questionnaire
version
0..1
string
Business version of the questionnaire
versionAlgorithm[x]
0..1
How to compare versions
Binding:
Version Algorithm
Extensible
versionAlgorithmString
string
versionAlgorithmCoding
Coding
name
0..1
string
Name for this questionnaire (computer friendly)
title
0..1
string
Name for this questionnaire (human friendly)
derivedFrom
0..*
canonical
Questionnaire
Based on Questionnaire
status
?!
1..1
code
draft | active | retired | unknown
Binding:
PublicationStatus
Required
experimental
0..1
boolean
For testing purposes, not real usage
subjectType
0..*
code
Resource that can be subject of QuestionnaireResponse
Binding:
Resource Types
Required
date
0..1
dateTime
Date last changed
publisher
0..1
string
Name of the publisher/steward (organization or individual)
contact
0..*
ContactDetail
Contact details for the publisher
description
0..1
markdown
Natural language description of the questionnaire
useContext
TU
0..*
UsageContext
The context that the content is intended to support
jurisdiction
XD
0..*
CodeableConcept
Intended jurisdiction for questionnaire (if applicable)
Binding:
Jurisdiction ValueSet
Extensible
purpose
0..1
markdown
Why this questionnaire is defined
0..1
markdown
Use and/or publishing restrictions
copyrightLabel
0..1
string
Copyright holder and year(s)
approvalDate
0..1
date
When the questionnaire was approved by publisher
lastReviewDate
0..1
date
When the questionnaire was last reviewed by the publisher
effectivePeriod
0..1
Period
When the questionnaire is expected to be used
code
0..*
Coding
Concept that represents the overall questionnaire
Binding:
Questionnaire Question Codes
Example
item
0..*
BackboneElement
Questions and sections within the Questionnaire
+ Rule: Group items must have nested items when Questionanire is complete
+ Warning: Groups should have items
+ Rule: Display items cannot have child items
+ Rule: Display items cannot have a "code" asserted
+ Rule: A question cannot have both answerOption and answerValueSet
+ Rule: Only coding, decimal, integer, date, dateTime, time, string or quantity items can have answerOption or answerValueSet
+ Rule: Required and repeat aren't permitted for display items
+ Rule: Initial values can't be specified for groups or display items
+ Rule: Read-only can't be specified for "display" items
+ Rule: Maximum length can only be declared for simple question types
+ Rule: If one or more answerOption is present, initial cannot be present. Use answerOption.initialSelected instead
+ Rule: If there are more than one enableWhen, enableBehavior must be specified
+ Rule: Can only have multiple initial values for repeating items
+ Warning: Can only have answerConstraint if answerOption or answerValueSet are present. (This is a warning because extensions may serve the same purpose)
linkId
1..1
string
Unique id for item in questionnaire
+ Warning: Link ids should be 255 characters or less
definition
0..1
uri
ElementDefinition - details for the item
code
0..*
Coding
Corresponding concept for this item in a terminology
Binding:
Questionnaire Question Codes
Example
prefix
0..1
string
E.g. "1(a)", "2.5.3"
text
0..1
string
Primary text for the item
type
1..1
code
group | display | boolean | decimal | integer | date | dateTime +
Binding:
Questionnaire Item Type
Required
enableWhen
?!
0..*
BackboneElement
Only allow data when
+ Rule: If the operator is 'exists', the value must be a boolean
question
1..1
string
The linkId of question that determines whether item is enabled/disabled
operator
1..1
code
exists | = | != | > | < | >= | <=
Binding:
Questionnaire Item Operator
Required
answer[x]
1..1
Value for question comparison based on operator
Binding:
Questionnaire Answer Codes
Example
answerBoolean
boolean
answerDecimal
decimal
answerInteger
integer
answerDate
date
answerDateTime
dateTime
answerTime
time
answerString
string
answerCoding
Coding
answerQuantity
Quantity
answerReference
Reference
Any
enableBehavior
0..1
code
all | any
Binding:
Enable When Behavior
Required
disabledDisplay
0..1
code
hidden | protected
Binding:
Questionnaire Item Disabled Display
Required
required
0..1
boolean
Whether the item must be included in data results
repeats
0..1
boolean
Whether the item may repeat
readOnly
0..1
boolean
Don't allow human editing
maxLength
0..1
integer
No more than these many characters
answerConstraint
0..1
code
optionsOnly | optionsOrType | optionsOrString
Binding:
Questionnaire answer constraints value set
Required
answerValueSet
0..1
canonical
ValueSet
ValueSet containing permitted answers
answerOption
0..*
BackboneElement
Permitted answer
value[x]
1..1
Answer value
Binding:
Questionnaire Answer Codes
Example
valueInteger
integer
valueDate
date
valueTime
time
valueString
string
valueCoding
Coding
valueReference
Reference
Any
initialSelected
0..1
boolean
Whether option is selected by default
initial
0..*
BackboneElement
Initial value(s) when item is first rendered
value[x]
1..1
Actual value for initializing the question
Binding:
Questionnaire Answer Codes
Example
valueBoolean
boolean
valueDecimal
decimal
valueInteger
integer
valueDate
date
valueDateTime
dateTime
valueTime
time
valueString
string
valueUri
uri
valueAttachment
Attachment
valueCoding
Coding
valueQuantity
Quantity
valueReference
Reference
Any
item
0..*
see
item
Nested questionnaire items
Documentation for this format
See the Extensions
for this resource
UML Diagram
Legend
XML Template
Questionnaire
xmlns="http://hl7.org/fhir">

url
value="[
uri
]"/>

identifier

version
value="[
string
]"/>

versionAlgorithm[x]

name
value="[
string
]"/>

title
value="[
string
]"/>

derivedFrom

status
value="[
code
]"/>

experimental
value="[
boolean
]"/>

subjectType
value="[
code
]"/>

date
value="[
dateTime
]"/>

publisher
value="[
string
]"/>

contact

description
value="[
markdown
]"/>

useContext

jurisdiction

purpose
value="[
markdown
]"/>

value="[
markdown
]"/>

copyrightLabel
value="[
string
]"/>

approvalDate
value="[
date
]"/>

lastReviewDate
value="[
date
]"/>

effectivePeriod

code

item

linkId
value="[
string
]"/>

definition
value="[
uri
]"/>

code

prefix
value="[
string
]"/>

text
value="[
string
]"/>

type
value="[
code
]"/>

enableWhen

question
value="[
string
]"/>

operator
value="[
code
]"/>

answer[x]

enableBehavior
value="[
code
]"/>

disabledDisplay
value="[
code
]"/>

required
value="[
boolean
]"/>

repeats
value="[
boolean
]"/>

readOnly
value="[
boolean
]"/>

maxLength
value="[
integer
]"/>

answerConstraint
value="[
code
]"/>

answerValueSet

answerOption

value[x]

initialSelected
value="[
boolean
]"/>

initial

value[x]

item

JSON Template
"resourceType" : "
Questionnaire
",
// from
Resource
id
meta
implicitRules
, and
language
// from
DomainResource
text
contained
extension
, and
modifierExtension
url
" : "<
uri
>",
//
Canonical identifier for this questionnaire, represented as an absolute URI (globally unique)
identifier
" : [{
Identifier
}],
//
Business identifier for questionnaire
version
" : "<
string
>",
//
Business version of the questionnaire
// versionAlgorithm[x]:
How to compare versions
. One of these 2:
versionAlgorithmString
" : "<
string
>",
versionAlgorithmCoding
" : {
Coding
},
name
" : "<
string
>",
//
Name for this questionnaire (computer friendly)
title
" : "<
string
>",
//
Name for this questionnaire (human friendly)
derivedFrom
" : ["<
canonical
Questionnaire
)>"],
//
Based on Questionnaire
status
" : "<
code
>",
//
R!
draft | active | retired | unknown
experimental
" : <
boolean
>,
//
For testing purposes, not real usage
subjectType
" : ["<
code
>"],
//
Resource that can be subject of QuestionnaireResponse
date
" : "<
dateTime
>",
//
Date last changed
publisher
" : "<
string
>",
//
Name of the publisher/steward (organization or individual)
contact
" : [{
ContactDetail
}],
//
Contact details for the publisher
description
" : "<
markdown
>",
//
Natural language description of the questionnaire
useContext
" : [{
UsageContext
}],
//
The context that the content is intended to support
jurisdiction
" : [{
CodeableConcept
}],
//
Intended jurisdiction for questionnaire (if applicable)
purpose
" : "<
markdown
>",
//
Why this questionnaire is defined
" : "<
markdown
>",
//
Use and/or publishing restrictions
copyrightLabel
" : "<
string
>",
//
Copyright holder and year(s)
approvalDate
" : "<
date
>",
//
When the questionnaire was approved by publisher
lastReviewDate
" : "<
date
>",
//
When the questionnaire was last reviewed by the publisher
effectivePeriod
" : {
Period
},
//
When the questionnaire is expected to be used
code
" : [{
Coding
}],
//
Concept that represents the overall questionnaire
item
" : [{
//
Questions and sections within the Questionnaire
linkId
" : "<
string
>",
//
R!
Unique id for item in questionnaire
definition
" : "<
uri
>",
//
ElementDefinition - details for the item
code
" : [{
Coding
}],
//
Corresponding concept for this item in a terminology
prefix
" : "<
string
>",
//
E.g. "1(a)", "2.5.3"
text
" : "<
string
>",
//
Primary text for the item
type
" : "<
code
>",
//
R!
group | display | boolean | decimal | integer | date | dateTime +
enableWhen
" : [{
//
Only allow data when
question
" : "<
string
>",
//
R!
The linkId of question that determines whether item is enabled/disabled
operator
" : "<
code
>",
//
R!
exists | = | != | > | < | >= | <=
// answer[x]:
Value for question comparison based on operator
. One of these 10:
answerBoolean
" : <
boolean
>,
answerDecimal
" : <
decimal
>,
answerInteger
" : <
integer
>,
answerDate
" : "<
date
>",
answerDateTime
" : "<
dateTime
>",
answerTime
" : "<
time
>",
answerString
" : "<
string
>",
answerCoding
" : {
Coding
},
answerQuantity
" : {
Quantity
},
answerReference
" : {
Reference
Any
}],
enableBehavior
" : "<
code
>",
//
all | any
disabledDisplay
" : "<
code
>",
//
hidden | protected
required
" : <
boolean
>,
//
Whether the item must be included in data results
repeats
" : <
boolean
>,
//
Whether the item may repeat
readOnly
" : <
boolean
>,
//
Don't allow human editing
maxLength
" : <
integer
>,
//
No more than these many characters
answerConstraint
" : "<
code
>",
//
optionsOnly | optionsOrType | optionsOrString
answerValueSet
" : "<
canonical
ValueSet
)>",
//
ValueSet containing permitted answers
answerOption
" : [{
//
Permitted answer
// value[x]:
Answer value
. One of these 6:
valueInteger
" : <
integer
>,
valueDate
" : "<
date
>",
valueTime
" : "<
time
>",
valueString
" : "<
string
>",
valueCoding
" : {
Coding
},
valueReference
" : {
Reference
Any
},
initialSelected
" : <
boolean
//
Whether option is selected by default
}],
initial
" : [{
//
Initial value(s) when item is first rendered
// value[x]:
Actual value for initializing the question
. One of these 12:
valueBoolean
" : <
boolean
>,
valueDecimal
" : <
decimal
>,
valueInteger
" : <
integer
>,
valueDate
" : "<
date
>",
valueDateTime
" : "<
dateTime
>",
valueTime
" : "<
time
>",
valueString
" : "<
string
>",
valueUri
" : "<
uri
>",
valueAttachment
" : {
Attachment
},
valueCoding
" : {
Coding
},
valueQuantity
" : {
Quantity
},
valueReference
" : {
Reference
Any
}],
item
" : [{
Content as for Questionnaire.item
}]
//
Nested questionnaire items
}]
Turtle Template
@prefix fhir: .
[ a fhir:
Questionnaire
fhir:nodeRole fhir:treeRoot; # if this is the parser root

# from
Resource
.id
.meta
.implicitRules
, and
.language
# from
DomainResource
.text
.contained
.extension
, and
.modifierExtension
fhir:
url
uri
] ; # 0..1
Canonical identifier for this questionnaire, represented as an absolute URI (globally unique)
fhir:
identifier
( [
Identifier
] ... ) ; # 0..*
Business identifier for questionnaire
fhir:
version
string
] ; # 0..1
Business version of the questionnaire
versionAlgorithm[x]
: 0..1
How to compare versions
. One of these 2
fhir:
versionAlgorithm
[ a fhir:string ;
string
fhir:
versionAlgorithm
[ a fhir:Coding ;
Coding
fhir:
name
string
] ; # 0..1
Name for this questionnaire (computer friendly)
fhir:
title
string
] ; # 0..1
Name for this questionnaire (human friendly)
fhir:
derivedFrom
( [
canonical
Questionnaire
) ] ... ) ; # 0..*
Based on Questionnaire
fhir:
status
code
] ; # 1..1
draft | active | retired | unknown
fhir:
experimental
boolean
] ; # 0..1
For testing purposes, not real usage
fhir:
subjectType
( [
code
] ... ) ; # 0..*
Resource that can be subject of QuestionnaireResponse
fhir:
date
dateTime
] ; # 0..1
Date last changed
fhir:
publisher
string
] ; # 0..1
Name of the publisher/steward (organization or individual)
fhir:
contact
( [
ContactDetail
] ... ) ; # 0..*
Contact details for the publisher
fhir:
description
markdown
] ; # 0..1
Natural language description of the questionnaire
fhir:
useContext
( [
UsageContext
] ... ) ; # 0..*
The context that the content is intended to support
fhir:
jurisdiction
( [
CodeableConcept
] ... ) ; # 0..*
Intended jurisdiction for questionnaire (if applicable)
fhir:
purpose
markdown
] ; # 0..1
Why this questionnaire is defined
fhir:
markdown
] ; # 0..1
Use and/or publishing restrictions
fhir:
copyrightLabel
string
] ; # 0..1
Copyright holder and year(s)
fhir:
approvalDate
date
] ; # 0..1
When the questionnaire was approved by publisher
fhir:
lastReviewDate
date
] ; # 0..1
When the questionnaire was last reviewed by the publisher
fhir:
effectivePeriod
Period
] ; # 0..1
When the questionnaire is expected to be used
fhir:
code
( [
Coding
] ... ) ; # 0..*
Concept that represents the overall questionnaire
fhir:
item
( [ # 0..*
Questions and sections within the Questionnaire
fhir:
linkId
string
] ; # 1..1
Unique id for item in questionnaire
fhir:
definition
uri
] ; # 0..1
ElementDefinition - details for the item
fhir:
code
( [
Coding
] ... ) ; # 0..*
Corresponding concept for this item in a terminology
fhir:
prefix
string
] ; # 0..1
E.g. "1(a)", "2.5.3"
fhir:
text
string
] ; # 0..1
Primary text for the item
fhir:
type
code
] ; # 1..1
group | display | boolean | decimal | integer | date | dateTime +
fhir:
enableWhen
( [ # 0..*
Only allow data when
fhir:
question
string
] ; # 1..1
The linkId of question that determines whether item is enabled/disabled
fhir:
operator
code
] ; # 1..1
exists | = | != | > | < | >= | <=
answer[x]
: 1..1
Value for question comparison based on operator
. One of these 10
fhir:
answer
[ a fhir:boolean ;
boolean
fhir:
answer
[ a fhir:decimal ;
decimal
fhir:
answer
[ a fhir:integer ;
integer
fhir:
answer
[ a fhir:date ;
date
fhir:
answer
[ a fhir:dateTime ;
dateTime
fhir:
answer
[ a fhir:time ;
time
fhir:
answer
[ a fhir:string ;
string
fhir:
answer
[ a fhir:Coding ;
Coding
fhir:
answer
[ a fhir:Quantity ;
Quantity
fhir:
answer
[ a fhir:Reference ;
Reference
Any
) ]
] ... ) ;
fhir:
enableBehavior
code
] ; # 0..1
all | any
fhir:
disabledDisplay
code
] ; # 0..1
hidden | protected
fhir:
required
boolean
] ; # 0..1
Whether the item must be included in data results
fhir:
repeats
boolean
] ; # 0..1
Whether the item may repeat
fhir:
readOnly
boolean
] ; # 0..1
Don't allow human editing
fhir:
maxLength
integer
] ; # 0..1
No more than these many characters
fhir:
answerConstraint
code
] ; # 0..1
optionsOnly | optionsOrType | optionsOrString
fhir:
answerValueSet
canonical
ValueSet
) ] ; # 0..1
ValueSet containing permitted answers
fhir:
answerOption
( [ # 0..*
Permitted answer
value[x]
: 1..1
Answer value
. One of these 6
fhir:
value
[ a fhir:integer ;
integer
fhir:
value
[ a fhir:date ;
date
fhir:
value
[ a fhir:time ;
time
fhir:
value
[ a fhir:string ;
string
fhir:
value
[ a fhir:Coding ;
Coding
fhir:
value
[ a fhir:Reference ;
Reference
Any
) ]
fhir:
initialSelected
boolean
] ; # 0..1
Whether option is selected by default
] ... ) ;
fhir:
initial
( [ # 0..*
Initial value(s) when item is first rendered
value[x]
: 1..1
Actual value for initializing the question
. One of these 12
fhir:
value
[ a fhir:boolean ;
boolean
fhir:
value
[ a fhir:decimal ;
decimal
fhir:
value
[ a fhir:integer ;
integer
fhir:
value
[ a fhir:date ;
date
fhir:
value
[ a fhir:dateTime ;
dateTime
fhir:
value
[ a fhir:time ;
time
fhir:
value
[ a fhir:string ;
string
fhir:
value
[ a fhir:uri ;
uri
fhir:
value
[ a fhir:Attachment ;
Attachment
fhir:
value
[ a fhir:Coding ;
Coding
fhir:
value
[ a fhir:Quantity ;
Quantity
fhir:
value
[ a fhir:Reference ;
Reference
Any
) ]
] ... ) ;
fhir:
item
( [
See Questionnaire.item
] ... ) ; # 0..*
Nested questionnaire items
] ... ) ;
Changes from both R4 and R4B
Questionnaire
Questionnaire.versionAlgorithm[x]
Added Element
Questionnaire.subjectType
Remove codes
CatalogEntry
DeviceUseStatement
DocumentManifest
DomainResource
EffectEvidenceSynthesis
Media
MedicinalProduct
MedicinalProductAuthorization
MedicinalProductContraindication
MedicinalProductIndication
MedicinalProductIngredient
MedicinalProductInteraction
MedicinalProductManufactured
MedicinalProductPackaged
MedicinalProductPharmaceutical
MedicinalProductUndesirableEffect
RequestGroup
ResearchDefinition
ResearchElementDefinition
Resource
RiskEvidenceSynthesis
SubstanceSpecification
Add codes
ActorDefinition
AdministrableProductDefinition
ArtifactAssessment
BiologicallyDerivedProductDispense
Citation
ClinicalUseDefinition
ConditionDefinition
DeviceAssociation
DeviceDispense
DeviceUsage
EncounterHistory
EvidenceReport
FormularyItem
GenomicStudy
ImagingSelection
Ingredient
InventoryItem
InventoryReport
ManufacturedItemDefinition
MedicinalProductDefinition
NutritionIntake
NutritionProduct
PackagedProductDefinition
Permission
RegulatedAuthorization
RequestOrchestration
Requirements
SubscriptionStatus
SubscriptionTopic
SubstanceDefinition
TestPlan
Transport
Questionnaire.copyrightLabel
Added Element
Questionnaire.item.type
Remove codes
choice
open-choice
Add codes
question
coding
Questionnaire.item.disabledDisplay
Added Element
Questionnaire.item.answerConstraint
Added Element
See the
Full Difference
for further information
This analysis is available for R4 as
XML
or
JSON
and for R4B as
XML
or
JSON
See
R4 <--> R5 Conversion Maps
(status = See
Conversions Summary
.)
Additional definitions: Master Definition
XML
JSON
XML
Schema
Schematron
JSON
Schema
ShEx
(for
Turtle
) , the
spreadsheet version
& the
dependency analysis
2.5.5.1
Terminology Bindings
Path
ValueSet
Type
Documentation
Questionnaire.versionAlgorithm[x]
VersionAlgorithm
Extensible
Indicates the mechanism used to compare versions to determine which is more current.
Questionnaire.status
PublicationStatus
Required
The lifecycle status of an artifact.
Questionnaire.subjectType
ResourceType
Required
Concrete FHIR Resource Types
Questionnaire.jurisdiction
JurisdictionValueSet
Extensible
This value set defines a base set of codes for country, country subdivision and region for indicating where a resource is intended to be used.
Note: The codes for countries and country subdivisions are taken from
ISO 3166
while the codes for "supra-national" regions are from
UN Standard country or area codes for statistical use (M49)
Questionnaire.code
QuestionnaireQuestionCodes
(a valid code from
LOINC
Example
Example list of codes for questions and groups of questions. (Not necessarily complete or appropriate.)
Questionnaire.item.code
QuestionnaireQuestionCodes
(a valid code from
LOINC
Example
Example list of codes for questions and groups of questions. (Not necessarily complete or appropriate.)
Questionnaire.item.type
QuestionnaireItemType
Required
Distinguishes groups from questions and display text and indicates data type for questions.
Questionnaire.item.enableWhen.operator
QuestionnaireItemOperator
Required
The criteria by which a question is enabled.
Questionnaire.item.enableWhen.answer[x]
QuestionnaireAnswerCodes
(a valid code from
SNOMED CT
Example
Example list of codes for answers to questions. (Not complete or necessarily appropriate.)
Questionnaire.item.enableBehavior
EnableWhenBehavior
Required
Controls how multiple enableWhen values are interpreted - whether all or any must be true.
Questionnaire.item.disabledDisplay
QuestionnaireItemDisabledDisplay
Required
Codes that guide the display of disabled questionnaire items
Questionnaire.item.answerConstraint
QuestionnaireAnswerConstraint
(a valid code from
Questionnaire answer constraint codes
Required
Codes that describe the types of constraints possible on a question item that has a list of permitted answers
Questionnaire.item.answerOption.value[x]
QuestionnaireAnswerCodes
(a valid code from
SNOMED CT
Example
Example list of codes for answers to questions. (Not complete or necessarily appropriate.)
Questionnaire.item.initial.value[x]
QuestionnaireAnswerCodes
(a valid code from
SNOMED CT
Example
Example list of codes for answers to questions. (Not complete or necessarily appropriate.)
2.5.5.2
Constraints
UniqueKey
Level
Location
Description
Expression
cnl-0
Warning
(base)
Name should be usable as an identifier for the module by machine processing applications such as code generation
name.exists() implies name.matches('^[A-Z]([A-Za-z0-9_]){1,254}$')
cnl-1
Warning
Questionnaire.url
URL should not contain | or # - these characters make processing canonical references problematic
exists() implies matches('^[^|# ]+$')
que-1a
Rule
Questionnaire.item
Group items must have nested items when Questionanire is complete
(type='group' and %resource.status='complete') implies item.empty().not()
que-1b
Warning
Questionnaire.item
Groups should have items
type='group' implies item.empty().not()
que-1c
Rule
Questionnaire.item
Display items cannot have child items
type='display' implies item.empty()
que-2
Rule
(base)
The link ids for groups and questions must be unique within the questionnaire
descendants().linkId.isDistinct()
que-3
Rule
Questionnaire.item
Display items cannot have a "code" asserted
type!='display' or code.empty()
que-4
Rule
Questionnaire.item
A question cannot have both answerOption and answerValueSet
answerOption.empty() or answerValueSet.empty()
que-5
Rule
Questionnaire.item
Only coding, decimal, integer, date, dateTime, time, string or quantity items can have answerOption or answerValueSet
(type='coding' or type = 'decimal' or type = 'integer' or type = 'date' or type = 'dateTime' or type = 'time' or type = 'string' or type = 'quantity') or (answerValueSet.empty() and answerOption.empty())
que-6
Rule
Questionnaire.item
Required and repeat aren't permitted for display items
type!='display' or (required.empty() and repeats.empty())
que-7
Rule
Questionnaire.item.enableWhen
If the operator is 'exists', the value must be a boolean
operator = 'exists' implies (answer is boolean)
que-8
Rule
Questionnaire.item
Initial values can't be specified for groups or display items
(type!='group' and type!='display') or initial.empty()
que-9
Rule
Questionnaire.item
Read-only can't be specified for "display" items
type!='display' or readOnly.empty()
que-10
Rule
Questionnaire.item
Maximum length can only be declared for simple question types
(type in ('boolean' | 'decimal' | 'integer' | 'string' | 'text' | 'url')) or answerConstraint='optionOrString' or maxLength.empty()
que-11
Rule
Questionnaire.item
If one or more answerOption is present, initial cannot be present. Use answerOption.initialSelected instead
answerOption.empty() or initial.empty()
que-12
Rule
Questionnaire.item
If there are more than one enableWhen, enableBehavior must be specified
enableWhen.count() > 1 implies enableBehavior.exists()
que-13
Rule
Questionnaire.item
Can only have multiple initial values for repeating items
repeats=true or initial.count() <= 1
que-14
Warning
Questionnaire.item
Can only have answerConstraint if answerOption or answerValueSet are present. (This is a warning because extensions may serve the same purpose)
answerConstraint.exists() implies answerOption.exists() or answerValueSet.exists()
que-15
Warning
Questionnaire.item.linkId
Link ids should be 255 characters or less
$this.length() <= 255
2.5.6
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
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
CDA
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.
2.5.6.1
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)
. 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)
2.5.6.2
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
implementation guide.
2.5.6.3
Using Questionnaires versus using Resources
There is considerable overlap between the information covered by
Questionnaires
and other Resources (especially
FamilyMemberHistory
MedicationStatement
Observation
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
as part of an intake questionnaire. That data may then be propagated into the
Patient
resource (demographics),
FamilyMemberHistory
AllergyIntolerance
MedicationStatement
and/or
Observation
resources to allow the data to be queried and analyzed. The original
QuestionnaireResponse
instance can be retained for traceability purposes. If desired, a
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
with the appropriate
Observation.code
and the specified answer as the
Observation.valueQuantity
can be created.
2.5.6.4
Profiling Questionnaires
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.
2.5.6.5
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
from
the
Australian New South Wales blue book
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.
2.5.6.6
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.
2.5.6.7
LinkIds
LinkIds are globally unique in a Questionnaire and are how items in a
QuestionnaireResponse
are tied to their corresponding Questionnaire item.
The QuestionnaireResponse page includes a
diagram
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
. 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.
2.5.6.8
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
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
2.5.6.9
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
using
Questionnaire.item.definition
which provides details for the item. 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
) should propagate
Any extensions defined for Questionnaire.item that directly correspond to elements on ElementDefinition should also propagate. E.g.:
ElementDefinition.minValue[x] ->
minValue
ElementDefinition.maxValue[x] ->
maxValue
There are Questionnaire extensions defined in the
SDC IG
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
, 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
A reference to the standard Observation element
effectiveDateTime
A reference to the
logical model
"xxx" that represents a data element
A reference to slice
XXX
on the Observation
category
element on an Oedema Scale profile
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
resource.
Note that LOINC codes
implicitly
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
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.
2.5.6.10
Question types
The codes for the data type for each question are slightly different than the data types allowed in the
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
url
uri
coding
Coding
2.5.6.11
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
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
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.
2.5.6.12
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
: http://hl7.org/fhir/ValueSet/yesnodontknow
2.5.6.13
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.
2.5.6.14
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.
2.5.6.15
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
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
and
Documentation Template
topics in the Clinical Reasoning module.
2.5.6.16
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
. 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.
2.5.6.17
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
. However, some of the extensions are complex and work together in particular
ways. To support more advanced questionnaire implementation, the
Structured Data Capture (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.
2.5.7
Search Parameters
Search parameters for this resource. See also the
full list of search parameters for this resource
and check the
Extensions registry
for search parameters on extensions related to this resource.
The
common parameters
also apply. See
Searching
for more
information about searching in REST, messaging, and services.
Name
Type
Description
Expression
In Common
combo-code
token
A code that corresponds to one of its items in the questionnaire
Questionnaire.code | Questionnaire.item.code
context
token
A use context assigned to the questionnaire
(Questionnaire.useContext.value.ofType(CodeableConcept))
30 Resources
context-quantity
quantity
A quantity- or range-valued use context assigned to the questionnaire
(Questionnaire.useContext.value.ofType(Quantity)) | (Questionnaire.useContext.value.ofType(Range))
30 Resources
context-type
token
A type of use context assigned to the questionnaire
Questionnaire.useContext.code
30 Resources
context-type-quantity
composite
A use context type and quantity- or range-based value assigned to the questionnaire
On Questionnaire.useContext:
context-type: code
context-quantity: value.ofType(Quantity) | value.ofType(Range)
30 Resources
context-type-value
composite
A use context type and value assigned to the questionnaire
On Questionnaire.useContext:
context-type: code
context: value.ofType(CodeableConcept)
30 Resources
date
date
The questionnaire publication date
Questionnaire.date
30 Resources
definition
uri
ElementDefinition - details for the item
Questionnaire.item.definition
description
string
The description of the questionnaire
Questionnaire.description
28 Resources
effective
date
The time during which the questionnaire is intended to be in use
Questionnaire.effectivePeriod
12 Resources
identifier
token
External identifier for the questionnaire
Questionnaire.identifier
34 Resources
item-code
token
A code that corresponds to one of the items in the questionnaire
Questionnaire.item.code
jurisdiction
token
Intended jurisdiction for the questionnaire
Questionnaire.jurisdiction
26 Resources
name
string
Computationally friendly name of the questionnaire
Questionnaire.name
26 Resources
publisher
string
Name of the publisher of the questionnaire
Questionnaire.publisher
30 Resources
questionnaire-code
token
A code that matches one of the Questionnaire.code codings
Questionnaire.code
status
token
The current status of the questionnaire
Questionnaire.status
35 Resources
subject-type
token
Resource that can be subject of QuestionnaireResponse
Questionnaire.subjectType
title
string
The human-friendly name of the questionnaire
Questionnaire.title
27 Resources
url
uri
The uri that identifies the questionnaire
Questionnaire.url
34 Resources
version
token
The business version of the questionnaire
Questionnaire.version
30 Resources
FHIR ®© HL7.org 2011+. FHIR R5 hl7.fhir.core#5.0.0 generated on Sun, Mar 26, 2023 15:25+1100.
Links:
Version History
Contents
Glossary
QA
Compare to R4
Compare to R4B
Propose a change