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

Structured Data Capture, published by HL7 International / FHIR Infrastructure. This guide is not an authorized publication; it is the continuous build for version 4.0.0-ballot 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

Form Derivation

Page standards status: Trial-use

Sometimes there is a desire to use an existing form, but adapt it in some way from the base form to meet more localized requirements. There are three types of derivation - extends, compliesWith and inspiredBy, which are described in detail here in the code system for the questionnaire-derivationType extension. When creating one form from another, the newly created form SHOULD include a derivedFrom element that points to the source Questionnaire and SHOULD make use of the extension to communicate the nature of the relationship. This relationship indicates how a resulting QuestionnaireResponse can be used, as shown in the following table:

Relationship Type Instance of Validates against original Questionnaire Validates against derived Questionnaire
extends derived not usually yes
original yes Possibly (if extended items are optional)
compliesWith derived yes yes
original yes Possibly (depending on nature of constraints)
inspiredBy derived no yes
original yes no

Note that even if a derived Questionnaire 'compliesWith' the rules of the base Questionnaire, that does not mean that answers gathered against the derived Questionnaire would be considered 'valid' as results against the parent Questionnaire. Instrument validity often depends on specific answer choices and questions being available. However, in some cases an instrument might be designed in a way that allows for certain questions to be removed via a derivation process and for the resulting QuestionnaireResponses to still be considered 'valid' against the original Questionnaire. This is done using the optionalDisplay extension. The presence of this extension on a non-required item means that a derived Questionnaire can omit the element and still be considered valid against its parent.

One common use-case for the creation of 'valid' derived Questionnaires that doesn't require the use of optionalDisplay is where the derivation doesn't change the questions or answer rules of the form at all, but instead merely adds supplementl information, such as item.code or item.value elements, extensions to support population or extraction, or similar metadata. Creating a translation of a form is another example, though technically this may call into question the validity of the data gathered in the alternate language and is best done by the author of the instrument.

A derived Questionnaire is considered a distinct Questionnaire instance, even if it complies with, or even is considered 'valid' against the original Questionnaire. As such, the derived Questionnaire SHALL have a distinct canonical url and be versioned as a distinct instance. However, implementations MAY choose to populate the QuestionnaireResponse.questionnaire with the canonical of the parent Questionnaire if the Questionnaire that was completed is considered to be valid against the parent.

Note that derived forms are distinct from Modular forms. In modular forms, a form is authored in a manner that involves referencing various sub-forms and/or data elements and then is 'assembled' into a complete Questionnaire. However, the assembled and unassembled are still considered to the the 'same' Questionnaire and logically contain identical information. For that reason, the canonical URLs are the same. With derived Questionnaires, there is at least some sort of difference with the parent Questionnaire and thus the canonicals are different.

An example of a Questionnaire that defines derivation expectations can be found here and a derived form that is valid against it can be found here.