Questionnaire - FHIR v4.3.0 - Máy Ép Cám Nổi | Dây Chuyền Sản Xuất Thức Ăn Thủy Sản Tối Ưu

This page is part of the FHIR Specification (v4.3.0: R4B – STU). This is the current published version. For a full list of available versions, see the Directory of published versions

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.37.1

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 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.)

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.37.2

Boundaries and Relationships

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).

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.

2.37.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.

This resource is referenced by CarePlan, Communication, Contract, FamilyMemberHistory, PlanDefinition, Procedure, itself and QuestionnaireResponse.

This resource implements the Definition pattern.

2.37.5

Resource Content

See the Profiles & Extensions and the alternate definitions:
Master Definition XML + JSON,
XML Schema/Schematron + JSON
Schema, ShEx (for Turtle) + see the extensions & the dependency analysis

2.37.5.1

Terminology Bindings

2.37.5.2

Constraints idLevelLocationDescriptionExpressionque-0Warning (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_]){0,254}’)

que-1aRule Questionnaire.itemGroup items must have nested items when Questionanire is complete

(type=’group’ and %resource.status=’complete’) implies item.empty().not()

que-1bWarning Questionnaire.itemGroups should have items

type=’group’ implies item.empty().not()

que-1cRule Questionnaire.itemDisplay items cannot have child items

type=’display’ implies item.empty()

que-2Rule (base)The link ids for groups and questions must be unique within the questionnaire

descendants().linkId.isDistinct()

que-3Rule Questionnaire.itemDisplay items cannot have a “code” asserted

type!=’display’ or code.empty()

que-4Rule Questionnaire.itemA question cannot have both answerOption and answerValueSet

answerOption.empty() or answerValueSet.empty()

que-5Rule Questionnaire.itemOnly ‘choice’ and ‘open-choice’ items can have answerValueSet

(type =’choice’ or type = ‘open-choice’ 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-6Rule Questionnaire.itemRequired and repeat aren’t permitted for display items

type!=’display’ or (required.empty() and repeats.empty())

que-7Rule Questionnaire.item.enableWhenIf the operator is ‘exists’, the value must be a boolean

operator = ‘exists’ implies (answer is boolean)

que-8Rule Questionnaire.itemInitial values can’t be specified for groups or display items

(type!=’group’ and type!=’display’) or initial.empty()

que-9Rule Questionnaire.itemRead-only can’t be specified for “display” items

type!=’display’ or readOnly.empty()

que-10Rule Questionnaire.itemMaximum length can only be declared for simple question types

que-11Rule Questionnaire.itemIf one or more answerOption is present, initial[x] must be missing

answerOption.empty() or initial.empty()

que-12Rule Questionnaire.itemIf there are more than one enableWhen, enableBehavior must be specified

enableWhen.count() > 1 implies enableBehavior.exists()

que-13Rule Questionnaire.itemCan only have multiple initial values for repeating items

repeats=true or initial.count() <= 1

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.37.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.37.6.2

Adaptive Questionnaires

Some questionnaires might not provide a full listing of questions, instead relying on a service to interactively sending 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.37.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 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.37.6.4

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’s 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.37.6.5

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.37.6.6

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:

concept (from ElementDefinition.code)
type (from ElementDefinition.type)
required (from ElementDefinition.min)
repeats (from ElementDefinition.max)
maxLength (from ElementDefinition.maxLength)
answerValueSet (from ElementDefinition.binding.valueSet)

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 definitionExplanation
http://hl7.org/fhir/StructureDefinition/Observation#Observation.commentA reference to the standard Observation element comment
http://example.org/definitions/xxxA reference to the logical model “xxx” that represents a data element
http://example.org/StructureDefinition/Oedema#Observation.category:XXXA reference to slice XXX on the Observation category element on an Oedema Scale profile
http://example.org/StructureDefinition/Oedema|2.0#Observation.category:XXXA 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.

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.37.6.7

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

choice
Coding

open-choice
Coding (if choosing from one of the listed choices) or string (if a different value is provided)

2.37.6.8

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.37.6.9

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:

2.37.6.10

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.37.6.11

Questionnaires with Math

Many questionnaires involve computations on questionnaire answers, e.g. tabulating scores.

To help with associating numeric values to coded answers, the ordinalValue
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.37.6.12

Questionnaire – FHIR v4.3.0

Viết một bình luận Hủy