2nd DSTU Draft For Comment

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

Structured Data Capture Questionnaire Design (Conformance Package)

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.

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
Profiles:
StructuredDataCaptureFormDefines how Questionnaire is used to reflect form definitions to be used within the ONC's Structured Data Capture standard. : Structured Data Capture Questionnaire Design
Extensions:
questionnaire-sdc-endpointWhere to send answers :

The base URL for the server to which questionnaire answers associated with this questionnaire should be submitted.

questionnaire-sdc-specialGroupheader | footer :

If specified, indicates that the group should be rendered as a repeating header or footer on each "page" of the questionnaire.

questionnaire-sdc-optionalDisplayCan 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.

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:

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?

Interoperability with the IHE SDC specification

This FHIR profile is partially based on the IHE Structured Data Capture Technical Framework Supplement. While largely aligned, there are differences between them, driven in part by their different technologies. (FHIR tends to nail things down and only include those data elements that are essential to the use-case, while the IHE specification is somewhat looser in the content it supports. As the content of both specifications stabilizes, the project team intends to develop a set of XSLT transforms to support translation between the two syntaxes. These transforms should provide seamless conversion in the majority of circumstances and will be designed to raise warning messages where some content could not be safely converted.

Another source of difference is in the data types. The IHE specification supports arbitrary data types, though it enumerates a specific list of allowed types for text_field. Of these, most map cleanly to FHIR, though there are some exceptions:

  • Date and time: In FHIR there's no ability to transmit different date formats - formatting control is handled by an extension, but all dates and times are conveyed according to the w3c schema standard over the wire. As well, partial-precision times are not supported in FHIR and must be zero-filled down to the second
  • Durations in FHIR are limited to a single value and unit. E.g. "3.5 days" or "84 hours". There is no ability to convey "3d12h" as a single question answer
  • The Attachment data type in FHIR supports conveying attachments both embedded within the answer or as references (possibly to a Binary resource in a bundle or to some external location.
  • FHIR introduces a 'boolean' data type. (The IHE specification presumes this would be captured using a code.)

Open Issue: Should FHIR also support an open-ended set of data types? Why?