Questionnaire-sdc - FHIR v1.0.2

DSTU2

This page is part of the FHIR Specification (v1.0.2: DSTU 2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

B.4.0 Structured Data Capture Questionnaire Design

B.4.0.1 Scope and Usage

This profile sets expectations for use of the Questionnaire resource within the Structured Data Capture implementation guide. This includes identifying which core elements and extensions must be supported.

For the purposes of this profile, Supported means that clients SHALL be capable of processing the element/extension and use the information to control the display and information capture associated with the Questionnaire. It means that servers SHALL be capable of persisting those elements and returning them in response to requests.

B.4.0.2 Boundaries and Relationships

This profile relies on the use of a number of other profiles, some required, others available for use "when necessary":

questionnaire-extensions which defines a number of less common properties for questionnaire, group and question, several of which are mandated for this profile.
element-extensions which defines extensions describing constraints on the values for data elements. There are used here to constrain the allowed values for questions.
iso-21090 provides extensions for strings allowing the conveying of language and translation extensions which may be relevant in some environment
rendering-extensions which defines properties to give fine-grained control over how questions, labels and other strings are rendered

B.4.0.3 Content

Profiles:
SDC-Questionnaire	Defines how Questionnaire is used to reflect form definitions to be used within the ONC's Structured Data Capture standard.
Extensions:
sdc-questionnaire-endpoint	Where to send answers : The base URL for the server to which questionnaire response associated with this questionnaire should be submitted.
sdc-questionnaire-specialGroup	header \| footer : If specified, indicates that the group should be rendered as a repeating header or footer on each "page" of the questionnaire.
sdc-questionnaire-optionalDisplay	Can suppress from display to user : If set to true, it means that the system displaying the form (or the individual encoding the form for data capture) can choose to omit the question from display to the user.
sdc-questionnaire-provenanceSignatureRequred	Is associated Provenance needed? : If true, indicates that QuestionnaireResponse instances created against this questionnaire must have an associated Provenance record.

B.4.0.4 Language and translations

In some environments, it may be necessary for a questionnaire to support multiple languages. The rendering tool would select the appropriate language based on a configuration setting, or perhaps would display all available languages and the user would read the one they are familiar with. Systems MAY choose to provide support for identifying language and translations. If they do, they MAY do so using the generic language and translation extensions FHIR defines based on the ISO21090 data type specification:

http://hl7.org/Profile/iso21090#language allows the language of a particular (or any other data type) to be identified
http://hl7.org/Profile/iso21090#string-translation allows additional repetitions in alternate languages to be communicated. (The language for each translation would be communicated using the above #language extension)

These extensions can be used on absolutely any string element on Questionnaire, ValueSet, one of the data types or any other resource. The base string should be the primary language of the questionnaire. It is what will be rendered by systems that do not support the translation extension or by systems whose language preference is other than one of the languages provided.

The ISO 19763 specification permits declaring language on questionnaire titles, descriptions, display names for codes and many other strings. It also supports capturing multiple variants of these strings with distinct languages. These capabilities can be mirrored using the above extensions.

An alternative is to define an extension to the Questionnaire providing a pointer to an externally maintained set of extensions. This approach allows the translations to be maintained independently of the resource which has both positive and negative impacts, particularly with respect to resource signature.

Open Issue: Should this profile define such an extension and/or a resource for managing such translations?

B.4.0.5 Example List

SDC - Combination	XML	JSON	Set of several examples - medication, AHRQ and NCI forms
SDC-Pathology	XML	JSON	Cancer pathology questionnaire with flow-control extensions
SDC-LOINC AHRQ	XML	JSON	LOINC perspective on the AHRQ form found in the SDC - Combination set of questionnaires
SDC-LOINC USSG Family History	XML	JSON	LOINC US Surgeon General family history including data elements & value sets. Note: This example isn't strictly valid against SDC as data elements do not have definitions and don't include mappings to SDC-approved specificaitons for auto-population

Usage note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of the specification.