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 Data Element (Conformance Package)

Scope and Usage

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

The focus of this profile is on those characteristics of Data Elements which are necessary to support the definition of forms (questionnaires) that can support auto-population or pre-population of content on the basis of referenced data elements.

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 DataElement. 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":

  • datalement-11179 which defines extensions for ISO-11179-specific concepts, such as ObjectClass and Property
  • 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
Profiles:
SDCElementSets expectations for data elements registered or used as part of the structured data capture project : Structured Data Capture Data Element

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