DSTU2 Ballot Source

This page is part of the FHIR Specification (v0.5.0: DSTU 2 Ballot 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

6.20.12 Structured Data Capture Data Element (Profile)

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

6.20.12.2 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

6.20.12.3 Content

Profiles:
SDCElementSets expectations for data elements registered or used as part of the structured data capture project
Examples:
dataelement-sdc-profile-example

FHIR Gender with mapping to CCDA

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

6.20.12.5 Open Issues

While DataElement.specificity has been introduced, a formal set of rules defining exactly what level of "tightness" must exist for a specificity code, and in particular, what the rules are for data elements intended for use in auto-population/pre-population has not yet been defined. For example, if a data element supports a subset of the answer codes that the question does, is that acceptable? Must the question text be word-for-word identical? Is it acceptable if the data element length is shorter than the permitted length for the question? Is it acceptable if units of measure are not an exact match so long as conversion factors are known?

Opinions on these and related questions of stringency are welcome.