Structured Data Capture
4.0.0-ballot - STU 4 ballot International flag

This page is part of the Structured Data Capture FHIR IG (v4.0.0-ballot: STU 4 Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. The current version which supersedes this version is 3.0.0. For a full list of available versions, see the Directory of published versions

SDC Home Page

Official URL: http://hl7.org/fhir/uv/sdc/ImplementationGuide/hl7.fhir.uv.sdc Version: 4.0.0-ballot
IG Standards status: Trial-use Maturity Level: 4 Computable Name: StructuredDataCapture
Other Identifiers: OID:2.16.840.1.113883.4.642.40.17

Contents:

This update provides a number of clarifications and enhancements to the SDC spec. A detailed list of key changes can be found [here](). Please note that this update relies on revisions to the FHIR Core extensions pack that have not yet been published. A dependency has been declared on the most current published release, but this release does not include some of the extensions (or updates to extensions) that have been made as part of revising this IG. If a hyperlink is encountered that doesn't work or to otherwise see the 'current' version of the extensions, you can browse the extensions here.

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.

Conformance expectations

Obviously all of the above represents a lot of capability and not all systems will necessarily need to take on all of these features. In fact, it is unlikely that any one system will support all of the features defined in this guide. Instead, each downstream implementation guide or implementer will choose the specific subset of SDC features of interest and build those only.

This guide defines a set of CapabilityStatements setting required and suggested RESTful interface capabilities for different types of systems that work with Questionnaires and QuestionnaireResponses. Most implementers of this guide SHOULD conform to at least one of these. The guide also defines profiles. These profiles fall into two categories:

  • Strict adherence profiles such as the population, extraction, adaptive forms, and modular forms profiles SHALL be complied with by systems that wish to implement the associated functionality and claim SDC compliance.
  • Advisory profiles MAY be used directly or derived from, but may also be used as the inspiration for other profiles that include the specific combinations of features that are needed. The elements marked as 'mustSupport' in those profiles are strongly encouraged to be supported, but a system that develops its own profiles that excludes some or all of the mustSupport elements can still be considered conformant with SDC.

In many cases, when complying with SDC, a system may wish to comply with multiple profiles at once. For example, an implementer may need advanced rendering, advanced behavior, population, and extraction all in a single Questionnaire. When creating a profile, it is not possible to inherit from multiple profiles at once. However, it is possible to use extensions in your profile, either to assert an expectation for compliance with additional profiles or to manually re-assert the same set of constraints and then assert that the elements in the profile meet the requirements of a reference profile.

This IG can also be used as a tool-box of extensions and approaches that an implementation or downstream IG could use as 'inspiration' to their own set of profiles and CapabilityStatements that don't declare conformance with SDC at all. (Though referencing SDC as a source of additional information and to provide credit is still encouraged.)

If you have used SDC in the definition of Questionnaires that are publicly available, we encourage you to provide links to them on our SDC Usage Confluence page. If you don't have edit access to HL7's Confluence site, you can submit a request to add a link with a post to the Questionnaire stream on http://chat.fhir.org.

Future versions of this IG may explore additional mechanisms to support implementers who wish to conform with specific common and useful subsets of SDC and combine them in arbitrary ways, likely using the obligation extension.

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.

  1. Project and participants section explains the project that led to this implementation guide and highlights some of those who were involved in the work.
  2. 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.
  3. Security sets base security expectations for systems claiming conformance with this implementation guide.
  4. 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.

  1. 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.
  2. Finding a Questionnaire describes expectations for systems serving as form repositories as well as clients who will need to search for forms.
  3. Advanced Rendering describes how to use various questions and the base capabilities of Questionnaire to render different types of form elements
  4. Form Behavior describes how to design 'active' forms that adjust what information is displayed and/or that perform calculations based on user input
  5. Questionnaire Population describes how to design questionnaires to support pre-population of answers and how to use services that support pre-populating forms
  6. Data Extraction describes how to design questionnaires to support converting completed forms into a FHIR resource or Bundle of FHIR resources for subsequent analysis
  7. Derived Forms describes the process for starting from one Questionnaire and creating a new Questionnaire and considerations around documenting and leveraging the relationship between the original and newly created form
  8. 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
  9. 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:

Implementation GuideVersion(s)Reason
FHIR Extensions Pack5.1.0
FHIR R4 package : Core4.0.1Imported by HL7 Terminology (THO) (and potentially others)
FHIR R4 package : Examples4.0.1
HL7 Terminology (THO)6.1.0

Automatically added as a dependency - all IGs depend on HL7 Terminology

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.