Structured Data Capture, published by HL7 International / FHIR Infrastructure. This guide is not an authorized publication; it is the continuous build for version 3.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/sdc/ and changes regularly. See the Directory of published versions
Introduction
Paper forms exist all over healthcare. They get filled out by patients, relatives, administrators, clinicians - essentially everyone. The FHIR
standard defines some basic ways share forms (empty ones and completed ones), however it only supports the capabilities that almost all forms need
to have. This implementation guide defines additional capabilities, including the ability to automatically fill in some of the form answers with
information that might already have been entered somewhere else, the ability to automatically calculate certain fields like age, the ability to
better control what a form looks like, etc. It defines a wide variety of 'features' covering different aspects of forms (how forms look, how they
behave, what types of systems can use forms and what they can do with them, etc.) The intent is to help ensure that different types of systems that
implement the same 'feature' do so in the same way.
Scope and purpose
Questionnaires are used to capture administrative data, claims data, clinical information, research information,
for public health reporting - every type of data that is manipulated by healthcare systems. They provide a user-friendly mechanism for capturing data
in a consistent way. In FHIR, forms are represented using the Questionnaire resource and
completed forms are represented using the QuestionnaireResponse resource. The base FHIR
specification defines these resources but does not provide much guidance around how they should be used, nor does it set minimal expectations for
interoperation. This implementation guide provides a set of guidance around the use of Questionnaire and QuestionnaireResponse that support many
additional capabilities that provide benefits to providers, patients and other users. These capabilities cover 7 major areas:
- Workflow considerations: This section helps drive improved interoperability across different systems that make
use of questionnaires by helping to answer questions like these:
- What are the types of systems involved in designing, managing, completing, receiving, and otherwise processing forms?
- How should these types of systems be expected to interact and what capabilities should they have?
- How do you ask someone to fill out a form (and keep track of whether they have or not)?
- Finding Questionnaires: Typically, the form that needs to be filled out in a particular situation will be known
in advance. However, if you're dealing with an electronic registry of forms, there needs to be standards on how to find the appropriate
form to use.
- Rendering considerations: This extends and provides guidance about how to make form content appear to a user
in the way a form author intends. Examples include:
- How can questions be organized into a table?
- How can colors, formatting and graphics be added to a Questionnaire?
- How can I control the way check-boxes or radio-buttons are organized?
- Enhanced behavior gives guidance and defines additional capabilities that affect how a Questionnaire will interact
with a user - the objective being to only gather relevant information and ensure that 'rules' around the Questionnaire are enforced. For example:
- How can the questions, options or even the text of the questions be changed based on what other answers have already been provided
(or based on information the software already knows, such as age or gender of the patient).
- How can rules be enforced such as minimum and maximum values, required formatting for phone numbers, allowed targets for references, etc.?
- How can a Questionnaire automatically calculate scores or other values?
- Automatic population helps to reduce the pain of having to fill in the same information 'yet again' by allowing
a form to automatically fill in answers already known to the EHR or other data source. The user can then just verify that the information is still
correct (and revise if necessary) rather than needing to fill out the information all over again (and possibly accidentally omitting or incorrectly
entering some of it
- Data extraction allows data captured in a QuestionnaireResponse to be extracted and used to create or update other
FHIR resources - allowing the data to be more easily searched, compared and used by other FHIR systems
- Modular forms simplify the questionnaire maintenance process by allowing questions or sections of a Questionnaire to be
shared across multiple forms. This also increases the consistency of questions and allows data to be more comparable.
- Adaptive forms change form design from one where all questions and logic must be defined up-front and shared, to one
where the form filling tool simply calls an API to determine what the next question should be. This allows for form designs to be hidden and for
complex flow control logic to be managed even when the software rendering the questionnaire is very simple.
Obviously this represents a lot of capability and not all systems will necessarily need to take on all of these features.
The implementation guide is structured to allow implementers to pick and choose the capabilities they need and combine them as necessary.
Navigation
This implementation guide follows the FHIR pattern of being published as a web-based specification. This
allows easy navigation between the SDC-specific portion of the implementation guide and the resources,
data types, value sets and other specification components leveraged from the FHIR core specification. This
approach also allows implementers to easily navigate to the information needed to perform a task.
A Table of Contents page is provided that lists all of the pages defined as part of this implementation guide. (Do be aware
that some pages have multiple tabs.) A table of contents is also available for the full FHIR specification
if you really want to read absolutely everything. There's also an Artifact index that lists all formal FHIR artifacts
defined within this implementation guide. The Support menu provides links to the HL7 standards used by this implementation guide as well as
providing a downloads link to retrieve a local copy of this implementation guide and/or particular subsets of it.
Bread-crumb navigation is provided in the gray bar just below the menu at the top of each page, allowing
easy navigation back to the main SDC page.
This implementation guide is organized into two sets of sections: SDC Background and the SDC Specification
SDC Background
These sections provide information relevant to all SDC implementers, regardless of which SDC capabilities they're interested in using.
-
Project and participants section explains the project that led to this implementation guide and highlights some of those who were
involved in the work.
-
FHIR usage provides information about the FHIR and FHIRPath standards used by this IG and an overview of the resources used
and base conformance expectations.
-
Security sets base security expectations for systems claiming conformance with this implementation guide.
-
Using Expressions describes the use of FHIRPath and CQL within Questionnaires and defines additional contexts and
rules for using these technologies in FHIR Questionnaires. (These are technologies used to support several of the SDC capabilities.)
SDC Specification
These sections define the different use-cases supported by SDC, specify the profile(s) needed to meet the use-cases.
-
Workflow describes the expectations for systems managing the creation, discovery and completion of questionnaires.
Systems conforming to SDC are expected to conform to one of the CapabilityStatements defined in this section.
-
Finding a Questionnaire describes expectations for systems serving as form repositories as well as clients who will need
to search for forms.
-
Advanced Rendering describes how to use various questions and the base capabilities of Questionnaire to render
different types of form elements
-
Form Behavior describes how to design 'active' forms that adjust what information is displayed and/or that
perform calculations based on user input
-
Questionnaire Population describes how to design questionnaires to support pre-population of answers and how to use
services that support pre-populating forms
-
Data Extraction describes how to design questionnaires to support converting completed forms into a FHIR resource or
Bundle of FHIR resources for subsequent analysis
-
Modular Forms describes an architecture to support constructing forms from other sub-forms and/or from libraries of
pre-defined questions to ease form development and maintenance
-
Adaptive Forms describes an architecture to support completing forms where the questionnaire is not pre-defined and
instead is dynamically developed based on the user's answers
Boundaries and Relationships
In addition to defining its own extensions, this implementation guide leverages extensions defined in the core
specification. The definitions of these extensions can be found in the following sections. (Note - not all extensions from these sections are
relevant. Relevant extensions are noted in each SDC profile, along with an indication of whether the extensions must be supported or not.)
-
questionnaire-extensions defines several less common properties for
questionnaire, group and question, several of which are mandated for this profile.
-
element-extensions defines extensions describing constraints on the values for
data elements (e.g. field length, min and max values, etc.). These are used here to constrain the allowed values for questions.
-
general-extensions provides an extension for strings allowing the conveying of
translations, which may be relevant in some environments.
-
rendering-extensions defines properties to give fine-grained control over
how questions, labels and other strings are rendered, such as providing HTML or markdown equivalents.
-
codesystem-extensions defines several less common properties for value sets,
several of which are mandated for this profile. It also makes use of the rendering-extensions which define rendering information for
display names and labels of codes.
It is expected that a variety of IGs will refine various combinations of SDC functionality and publish additional profiles to meet the needs of
their specific Questionnaire and QuestionnaireResponse use-cases.
Dependencies
This guide also relies on a number of parent implementation guides:
This implementation guide defines additional constraints and usage expectations above and beyond the information found in these base specifications.
Intellectual Property Considerations
While this implementation guide and the underlying FHIR are licensed as public domain, this guide includes examples making use of terminologies such
as LOINC, SNOMED CT and others that have more restrictive licensing requirements. Implementers should make themselves familiar with licensing and
any other constraints of terminologies, questionnaires, and other components used as part of their implementation process. In some cases,
licensing requirements may limit the systems that data captured using certain questionnaires may be shared with.
This publication includes IP covered under the following statements.
- The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
Show Usage
- These codes are excerpted from ASTM Standard, E1762-95(2013) - Standard Guide for Electronic Authentication of Health Care Information, Copyright by ASTM International, 100 Barr Harbor Drive, West Conshohocken, PA 19428. Copies of this standard are available through the ASTM Web Site at www.astm.org.
Show Usage
- This material contains content from LOINC. LOINC is copyright © 1995-2020, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and is available at no cost under the license. LOINC® is a registered United States trademark of Regenstrief Institute, Inc.
Show Usage
- LOINC: AHRQMedicationQ1, Bundle/map-population-example... Show 14 more, CHF, FraminghamHCHD, MedicationorOtherSubstance, MultiSubject, PatientHealthQuestionnairePHQ9, QuestionnaireResponse/adaptive-questionnaireresponse-sdc-example-phq9, QuestionnaireResponse/questionnaireresponse-sdc-example-ussg-fht-answers, QuestionnaireResponse/questionnaireresponse-sdc-profile-example-loinc, QuestionnaireSdcProfileExampleHungerVitalSigns, SDCAdvancedRenderingExample, SDCPHQ9, SDOHCCQuestionnaireHungerVitalSign, USSurgeonGeneralFamilyHealthPortrait and WeightHeightTrackingPanel
- This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact https://www.snomed.org/get-snomed or info@snomed.org.
Show Usage
- This material derives from the HL7 Terminology (THO). THO is copyright ©1989+ Health Level Seven International and is made available under the CC0 designation. For more licensing information see: https://terminology.hl7.org/license.html
Show Usage