This page is part of the Structured Data Capture FHIR IG (v1.6: STU 2 Ballot 1) based on FHIR v1.6.0. . For a full list of available versions, see the Directory of published versions
This is a pre-release of a future version of SDC (expected to be STU 2). The current version is STU 2.
For a full list of available versions, see the Directory of published versions .
This is a pre-release of a future version of SDC (expected to be STU 2). The current version is STU 2.
For a full list of available versions, see the Directory of published versions .
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.
This profile relies on the use of a number of other profiles, some required, others available for use "when necessary":
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-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 item from display to the user. |
sdc-questionnaire-provenanceSignatureRequired |
Is associated Provenance needed? : If true, indicates that QuestionnaireResponse instances created against this questionnaire must have an associated Provenance record. |
Examples: | |
SDC - Combination |
Set of several examples - medication, AHRQ and NCI forms |
SDC-Pathology |
Cancer pathology questionnaire with flow-control extensions |
SDC-LOINC AHRQ |
LOINC perspective on the AHRQ form found in the SDC - Combination set of questionnaires |
SDC-LOINC USSG Family History |
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 |
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:
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?
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.