DSTU2 QA Preview
This page is part of the FHIR Specification (v1.0.0: DSTU 2 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 
. Page versions: R3 R2
| Orders and Observations Work Group | Maturity Level: 3 | Compartments: Not linked to any defined compartments |
The formal description of a single piece of information that can be gathered and reported.
DataElement is an infrastructure resource that supports the defining individual pieces of data that might be collected or stored. While these definitions might apply to elements found in FHIR resources and profiles, they can also apply to questionnaire questions, elements in data stores, and non-FHIR specification (v2, CDA, CDISC, etc.) I.e. the definitions aren't FHIR-specific.
This resource covers two major use-cases:
The purpose of the first use-case is to allow systems to identify what types of lab orders, diagnostic studies and other types of observations may be requested or performed within a particular organization or other context. An ordering practitioner can query for a list of data elements by category name or other criteria and identify which, within a set of similar tests, they wish to request to be performed.
The focus of the second use-case is standardizing data capture and reporting. By defining standard names, data capture constraints, questions and other characteristics, the data gathered within and across organizations via questionnaires, as part of clinical studies, etc. can be made more consistent. When designing clinical studies, constructing questionnaires, building profiles or performing other tasks that involve determining what data will be captured or exchanged and how, designers can query to find pre-defined data element definitions they can leverage or map to. By encouraging consistency around data element definitions, data types, value sets, string lengths and other constraints, data becomes more easily exchangeable and comparable across systems. This benefits interoperability and clinical research. (For more discussion, see the section on standardization below.)
The scope covers base capabilities of the ISO 11179 Metadata Registries specification which defines DEs. It also covers observation definitions by ontologies such as LOINC. The term "observation" is interpreted in its broadest sense as "any element that might be thought of as the 'value' in a name-value pair". So it includes such concepts as patient gender, practitioner address and other data elements that would not typically be captured using the Observation resource.
This resource has significant overlap with StructureDefinition and Questionnaire.
StructureDefinition also defines data elements. However, it does so only in the context of FHIR-specific artifacts (FHIR resources, data types and profiles). As well, StructureDefinition typically identifies a number of data elements together in context. DataElement defines only a single data element and it does so in a manner that is not directly tied to FHIR. Data elements might define the value of an Observation, constrain the allowed answer to a question in a Questionnaire (including providing a list of permitted answers), describe the permitted value captured of an element in some other resource (Patient, FamilyMemberHistory, etc.) or even used outside FHIR entirely in a CDA document or HL7 v2 specification.
Questionnaire is to both define forms, surveys and other structures that can be filled out. Questionnaire also defines data elements. However, it does so only in the context of a particular questionnaire design. In contrast, DataElement is focused on defining data elements independent of their use in questionnaires and other structures. A single DataElement might be referenced in numerous Questionnaires, or even potentially in multiple places within a single Questionnaire. This reference might either be implicit or may be explicit through an extension. (For implementability reasons, the data constraints should still be explicitly exposed within the Questionnaire rather than being included "by reference" to the DataElement.)
Note: Extensions on DataElement that define the characteristics of a data element will typically also be applicable to Profile's ElementDefinition and Questionnaire's Question data element as both are also used to define the characteristics of a data element.
DSTU Note: Should a shared structure be used in StructureDefinition, Questionnaire and DataElement to capture constraints on data elements, or is it acceptable for them to continue to be maintained in a separate, but "similar" manner?
Feedback is welcome here
DataElement differs from Observation in that it describes what kind of observations can occur, while Observation focuses on a specific observation of a specific subject at a particular time that has occurred.
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
  DataElement | DomainResource | Resource data element | ||
  url | Σ | 0..1 | uri | Globally unique logical id for data element |
 identifier | Σ | 0..* | Identifier | Logical id to reference this data element |
| version | Σ | 0..1 | string | Logical id for this version of the data element |
| name | Σ | 0..1 | string | Descriptive label for this element definition |
| status | ?! Σ | 1..1 | code | draft | active | retired ConformanceResourceStatus (Required) |
| experimental | Σ | 0..1 | boolean | If for testing purposes, not real usage |
| publisher | Σ | 0..1 | string | Name of the publisher (Organization or individual) |
 contact | Σ | 0..* | BackboneElement | Contact details of the publisher |
 name | Σ | 0..1 | string | Name of a individual to contact |
 telecom | Σ | 0..* | ContactPoint | Contact details for individual or publisher |
| date | Σ | 0..1 | dateTime | Date for this version of the data element |
| useContext | Σ | 0..* | CodeableConcept | Content intends to support these contexts Context of Use ValueSet (Extensible) |
| copyright | 0..1 | string | Use and/or Publishing restrictions | |
| stringency | Σ | 0..1 | code | comparable | fully-specified | equivalent | convertable | scaleable | flexible DataElementStringency (Required) |
| mapping | 0..* | BackboneElement | External specification mapped to | |
| identity | 1..1 | id | Internal id when this mapping is used | |
| uri | 0..1 | uri | Identifies what this mapping refers to | |
| name | 0..1 | string | Names what this mapping refers to | |
| comments | 0..1 | string | Versions, Issues, Scope limitations etc | |
| element | Σ I | 1..* | ElementDefinition | Definition of element No base allowed No slicing allowed |
| Documentation for this format | ||||
UML Diagram
XML Template
<DataElement xmlns="http://hl7.org/fhir"><!-- from Resource: id, meta, implicitRules, and language --> <!-- from DomainResource: text, contained, extension, and modifierExtension --> <url value="[uri]"/><!-- 0..1 Globally unique logical id for data element --> <identifier><!-- 0..* Identifier Logical id to reference this data element --></identifier> <version value="[string]"/><!-- 0..1 Logical id for this version of the data element --> <name value="[string]"/><!-- 0..1 Descriptive label for this element definition --> <status value="[code]"/><!-- 1..1 draft | active | retired --> <experimental value="[boolean]"/><!-- 0..1 If for testing purposes, not real usage --> <publisher value="[string]"/><!-- 0..1 Name of the publisher (Organization or individual) --> <contact> <!-- 0..* Contact details of the publisher --> <name value="[string]"/><!-- 0..1 Name of a individual to contact --> <telecom><!-- 0..* ContactPoint Contact details for individual or publisher --></telecom> </contact> <date value="[dateTime]"/><!-- 0..1 Date for this version of the data element --> <useContext><!-- 0..* CodeableConcept Content intends to support these contexts --></useContext> <copyright value="[string]"/><!-- 0..1 Use and/or Publishing restrictions --> <stringency value="[code]"/><!-- 0..1 comparable | fully-specified | equivalent | convertable | scaleable | flexible --> <mapping> <!-- 0..* External specification mapped to --> <identity value="[id]"/><!-- 1..1 Internal id when this mapping is used --> <uri value="[uri]"/><!-- 0..1 Identifies what this mapping refers to --> <name value="[string]"/><!-- 0..1 Names what this mapping refers to --> <comments value="[string]"/><!-- 0..1 Versions, Issues, Scope limitations etc --> </mapping> <element><!-- 1..* ElementDefinition Definition of element --></element> </DataElement>
JSON Template
{
"resourceType" : "DataElement",
// from Resource: id, meta, implicitRules, and language
// from DomainResource: text, contained, extension, and modifierExtension
"url" : "<uri>", // Globally unique logical id for data element
"identifier" : [{ Identifier }], // Logical id to reference this data element
"version" : "<string>", // Logical id for this version of the data element
"name" : "<string>", // Descriptive label for this element definition
"status" : "<code>", // R! draft | active | retired
"experimental" : <boolean>, // If for testing purposes, not real usage
"publisher" : "<string>", // Name of the publisher (Organization or individual)
"contact" : [{ // Contact details of the publisher
"name" : "<string>", // Name of a individual to contact
"telecom" : [{ ContactPoint }] // Contact details for individual or publisher
}],
"date" : "<dateTime>", // Date for this version of the data element
"useContext" : [{ CodeableConcept }], // Content intends to support these contexts
"copyright" : "<string>", // Use and/or Publishing restrictions
"stringency" : "<code>", // comparable | fully-specified | equivalent | convertable | scaleable | flexible
"mapping" : [{ // External specification mapped to
"identity" : "<id>", // R! Internal id when this mapping is used
"uri" : "<uri>", // Identifies what this mapping refers to
"name" : "<string>", // Names what this mapping refers to
"comments" : "<string>" // Versions, Issues, Scope limitations etc
}],
"element" : [{ ElementDefinition }] // R! Definition of element
}
Structure
| Name | Flags | Card. | Type | Description & Constraints |
|---|---|---|---|---|
| DataElement | DomainResource | Resource data element | ||
| url | Σ | 0..1 | uri | Globally unique logical id for data element |
| identifier | Σ | 0..* | Identifier | Logical id to reference this data element |
| version | Σ | 0..1 | string | Logical id for this version of the data element |
| name | Σ | 0..1 | string | Descriptive label for this element definition |
| status | ?! Σ | 1..1 | code | draft | active | retired ConformanceResourceStatus (Required) |
| experimental | Σ | 0..1 | boolean | If for testing purposes, not real usage |
| publisher | Σ | 0..1 | string | Name of the publisher (Organization or individual) |
| contact | Σ | 0..* | BackboneElement | Contact details of the publisher |
| name | Σ | 0..1 | string | Name of a individual to contact |
| telecom | Σ | 0..* | ContactPoint | Contact details for individual or publisher |
| date | Σ | 0..1 | dateTime | Date for this version of the data element |
| useContext | Σ | 0..* | CodeableConcept | Content intends to support these contexts Context of Use ValueSet (Extensible) |
| copyright | 0..1 | string | Use and/or Publishing restrictions | |
| stringency | Σ | 0..1 | code | comparable | fully-specified | equivalent | convertable | scaleable | flexible DataElementStringency (Required) |
| mapping | 0..* | BackboneElement | External specification mapped to | |
| identity | 1..1 | id | Internal id when this mapping is used | |
| uri | 0..1 | uri | Identifies what this mapping refers to | |
| name | 0..1 | string | Names what this mapping refers to | |
| comments | 0..1 | string | Versions, Issues, Scope limitations etc | |
| element | Σ I | 1..* | ElementDefinition | Definition of element No base allowed No slicing allowed |
| Documentation for this format | ||||
XML Template
<DataElement xmlns="http://hl7.org/fhir">
JSON Template
{
"resourceType" : "DataElement",
// from Resource: id, meta, implicitRules, and language
// from DomainResource: text, contained, extension, and modifierExtension
"url" : "<uri>", // Globally unique logical id for data element
"identifier" : [{ Identifier }], // Logical id to reference this data element
"version" : "<string>", // Logical id for this version of the data element
"name" : "<string>", // Descriptive label for this element definition
"status" : "<code>", // R! draft | active | retired
"experimental" : <boolean>, // If for testing purposes, not real usage
"publisher" : "<string>", // Name of the publisher (Organization or individual)
"contact" : [{ // Contact details of the publisher
"name" : "<string>", // Name of a individual to contact
"telecom" : [{ ContactPoint }] // Contact details for individual or publisher
}],
"date" : "<dateTime>", // Date for this version of the data element
"useContext" : [{ CodeableConcept }], // Content intends to support these contexts
"copyright" : "<string>", // Use and/or Publishing restrictions
"stringency" : "<code>", // comparable | fully-specified | equivalent | convertable | scaleable | flexible
"mapping" : [{ // External specification mapped to
"identity" : "<id>", // R! Internal id when this mapping is used
"uri" : "<uri>", // Identifies what this mapping refers to
"name" : "<string>", // Names what this mapping refers to
"comments" : "<string>" // Versions, Issues, Scope limitations etc
}],
"element" : [{ ElementDefinition }] // R! Definition of element
}
Alternate definitions: Schema/Schematron, Resource Profile (XML, JSON), Questionnaire
| Path | Definition | Type | Reference |
|---|---|---|---|
| DataElement.status | The lifecycle status of a Value Set or Concept Map | Required | ConformanceResourceStatus |
| DataElement.useContext | Indicates the countries, regions, disciplines and other aspects of use this artifact is targeted for use within | Extensible | Context of Use ValueSet |
| DataElement.stringency | Indicates the degree of precision of the data element definition | Required | DataElementStringency |
One of the sources of the DataElement resource definition was the ISO 11179
Metadata Registries specification. It defines a logical model for the classification, identification, naming and registration of
Data Elements, Data Element Concepts and their associated Value and Conceptual Domains.
The DataElement resource can be used to represent both Data_Element and Data_Element_Concept in the ISO logical model.
(The ValueSet resource provides the details for Value_Domain and Conceptual_Domain for enumerated elements.)
The determination of whether a DataElement resource instance is an ISO 11179 Data_Element or Data_Element_Concept is determined by
whether the type property is specified - which corresponds to the ISO property Data_Element.domain.datatype which is required
for Data_Elements. I.e. If DataElement.type is present, the instance represents a 11179 data element. If DataElement.type is absent, the
instance represents a 11179 data element concept.
Unlike the 11179 logical specification, the DataElement resource does not require a linkage from data element to a distinct data element concept, though this linkage can be established through an extension if desired. The typical means of identification of the data element concept is expected to instead occur through the mapping of the data element to a particular code or reference model that formally defines the concept. It is possible this reference model could be based on ISO's Object_Class and Property mechanism. However, mappings to other reference models are also possible, for example:
reference model logical model or SNOMED
In the event of multiple codes and/or mappings, the "authoritative" mapping (the one formally defining the concept) is identified by either setting the "primary" element on the code or by specifying the "primary mapping" ISO 11179 extension.
It is possible to create instances that are "conforming", or even "strictly conforming" to the 11179 specification. However, doing so will require the use of extensions to convey certain properties that are not part of the core resource and data types. An initial starter ISO 11179 profile is included in the FHIR specification. It defines extensions that are relevant to the SDC DataElement profile. If there is sufficient interest, the existing starter set may be enhanced to contain a complete set of extensions and a full 11179 in a future release of the specification.
Data elements (and their registries) and codes (and their code systems) serve different purposes. Data elements describe the characteristics of a piece of data - identifier, name, definition, data type, length, permitted value set, usage notes, etc. On the other hand, while codes describe a particular concept including a symbol for use when exchanging the concept, display names, definitions and often relationships to other concepts. There is a subset of information that is common for both codes and data elements - identifier, name and definition. Because of this, a list of data elmements might sometimes be seen as a list of codes.
One of the purposes of data elements is to define variables, observations, or questions that include information about how to
collect a variable's value--including information about data types and guidance about the use of about answer lists and/or units of measure.
This function is typically done by code systems such as LOINC and
SNOMED CT . (Note that LOINC provides considerable detail about allowed answers, while most other code
systems such as SNOMED only allow identifying the question.) It would be possible to treat a registry of data elements using a common
identifier system/namespace as a code system. Similarly, data elements can be mapped to each other (and to codes) in the same manner as
codes can be mapped by making use of the ConceptMap resource.
That said, FHIR treats code systems as simple structures that provide identity, names and definitions. Code systems that provide significant additional detail (recommended doses for drugs, data types for data elements, etc.) are treated as a mix of a code system together with a supplementary resource to provide the details. Refer to the Code systems with detailed metadata section of ValueSet resource for additional discussion of the relationship between DataElement and code systems.
As noted in the introduction, one of the main purposes for the use of data elements is 'standardization' - gaining consistent (and thus comparable) data capture of data in questionnaires, observations and within other resources. However, merely defining data elements is not, in itself, sufficient to improve standardization. To ensure consistency of data, there needs to be several additional things:
Data Elements are a tool through which improved standardization can be achieved but without adequate processes, they will not achieve significant benefit.
Data elements can be defined at a wide variety of granularities. For example:
Coded data elements can be defined without value sets, with suggested value sets, with required but extensible value sets or with completely locked down value sets. Numeric values can be defined with or without allowed ranges. String data can be defined with or without patterns or lengths. All are valid data elements.
When defining data elements, it's important to decide what level of detail/granularity is appropriate for the intended purpose. The tighter the data element is defined, the greater interoperability of the data, however the smaller the set of systems that will be able to satisfy the constraints and the larger the number of data elements that will be required to cover a given domain. In some cases, multiple granularities may be appropriate, though this can introduce challenges in ensuring that the appropriate granularity is selected for a given use. As a rule, data elements should be defined as loosely as possible while still ensuring that all data captured using the data element will be sufficiently comparable to meet the needs of the group defining and using the data elements. A corollary to this is that data elements defined by one group will not always meet the needs of another group, even if they may be covering the same domain.
Two pieces of data don't necessarily need to be based on the same data element in order to be comparable or aggregatable. As noted above, it's possible for one data element to be a proper subset of another. In addition, it may be possible to convert data from being conformant with one data element to being conformant with another data element. This conversion could be lossless or may involve some loss of semantic precision. For example, a weight measurement captured in pounds can be seamlessly converted to kilograms. Similarly, coded data captured using one value set can be converted to another value set provided mappings are available. The nature of the mappings would determine whether any loss of semantics would occur.
The stringency element allows identifying the types of usages for which the data element is appropriate. Some uses (direct comparison of data, auto-population of data, etc.) are inappropriate with loose definitions of elements. On the other hand, overly-restrictive data elements can result in a large number of data elements and limited abilities to compare similar but not identical data. For now, the definition of what level of constraints are appropriate/necesssary for a given level of stringency is left to implementers, though future versions this specification may assert at least some level of guidance in this area.
Data elements provide their value by clearly defining the meaning and content of a particular type of data to be exchanged. This value depends on the meaning associated with the element being clear for all potential implementers of the element. I.e. For a data element to be useful, it needs to have a good quality definition. Characteristics of good quality definitions include:
notes or rationale elements.Because Data Elements define precise pieces of data that can be conveyed in a variety of places, they may form a useful mechanism for the definition of fine-grained data access controls. The base resource does not include mechanisms for linking access controls directly do data elements, however, an extension could allow a particular data element to be associated with particular Security Labels. Whether this level of control is appropriate may vary by implementation environment.
One of the primary purposes of the DataElement resource is to allow data conveyed in a variety of different forms to be "linked" to the data element and identified as being equivalent/comparable/semantically-aligned. There are a variety of different ways this can occur:
DataElement.element.code allows a data element to be linked as "semantically equivalent" to the specified code.DataElement.element.mapping allows a data element to be linked to a particular data structure such as a FHIR resource, a CDA template, an OpenEHR archetype, etc.Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.
| Name | Type | Description | Paths |
| code | token | A code for the data element (server may choose to do subsumption) | DataElement.element.code |
| context | token | A use context assigned to the data element | DataElement.useContext |
| date | date | The data element publication date | DataElement.date |
| description | string | Text search in the description of the data element. This corresponds to the definition of the first DataElement.element. | DataElement.element.definition |
| identifier | token | The identifier of the data element | DataElement.identifier |
| name | string | Name of the data element | DataElement.name |
| publisher | string | Name of the publisher of the data element | DataElement.publisher |
| status | token | The current status of the data element | DataElement.status |
| stringency | token | The stringency of the data element definition | DataElement.stringency |
| url | uri | The official URL for the data element | DataElement.url |
| version | string | The version identifier of the data element | DataElement.version |
© HL7.org 2011+. FHIR DSTU2 (v1.0.0-6850) generated on Tue, Sep 1, 2015 14:41+1000.
Links: What's a DSTU? |
Version History |
Table of Contents |
Compare to DSTU1 |
|
Propose a change