Scope and purpose

Questionnaires and forms are found everywhere in healthcare. They 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. This section defines standard expectations around searching for forms:
  • 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)?
• 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 Questionnare 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 event 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.

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

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.