STU 3 Candidate
This page is part of the FHIR Specification (v1.4.0: STU 3 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions 
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.
This profile relies on the use of a number of other profiles, some required, others available for use "when necessary":
| Profiles: | |
| SDC-Element | Sets expectations for data elements registered or used as part of the structured data capture project |
| Examples: | |
| C-CDA-Gender | FHIR Gender with mapping to C-CDA |
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.
While DataElement.stringency has been introduced, a formal set of rules defining exactly what level of "tightness" must exist for a stringency 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.
| C-CDA-Gender | XML | JSON | FHIR Gender with mapping to C-CDA |
Additional examples of this profile can be found as contained resources within the following examples:
| 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.
© HL7.org 2011+. FHIR STU3 Candidate (v1.4.0-8139) generated on Thu, Mar 31, 2016 08:10+1100. QA Page
Links: Search 
|
Version History |
Table of Contents |
Compare to DSTU2 |
|
Propose a change