This page is part of the FHIR Specification (v1.0.2: DSTU (v3.0.2: STU 2). 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 R3 R2

• Content
• Examples
• Detailed Descriptions
• Mappings
• Profiles & Extensions
• R2 Conversions

6.20 5.7 Resource DataElement - Content

Orders and Observations Work Group

Maturity Level : 1

Trial Use

Compartments : Not linked to any defined compartments

The formal description of a single piece of information that can be gathered and reported.

6.20.3 5.7.3 Resource Content

 

Alternate definitions: Schema / Schematron , Resource Profile Master Definition ( XML , JSON ), Questionnaire XML Schema / Schematron (for ) + JSON Schema , ShEx (for Turtle )

6.20.3.1 5.7.3.1 Terminology Bindings

DataElement.useContext

Path	Definition	Type	Reference
DataElement.status	The lifecycle status of a Value Set or Concept Map.	Required	ConformanceResourceStatus PublicationStatus
DataElement.jurisdiction	Indicates the countries, regions, disciplines Countries and other aspects of use regions within which this artifact is targeted for use. use	Extensible	Context of Use Jurisdiction ValueSet
DataElement.stringency	Indicates the degree of precision of the data element definition.	Required	DataElementStringency

6.20.3.2 5.7.3.2 Constraints

• dae-1 : On DataElement.element: No base allowed (xpath ( expression on f:DataElement/f:element: DataElement.element: not(exists(f:base)) base.empty() )
• dae-2 : On DataElement.element: No slicing allowed (xpath ( expression on f:DataElement/f:element: DataElement.element: not(exists(f:slicing)) slicing.empty() )
• dae-3 : On DataElement.mapping: At least one of name or uri SHALL be present ( expression on DataElement.mapping: uri.exists() or name.exists() )

6.20.3.3 5.7.3.3 Relationship to ISO 11179

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

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:

• HL7's Reference Information Model
• Open EHR's reference model
• the BRIDG logical model
• terminologies such as LOINC or SNOMED CT

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.

6.20.3.4 5.7.3.4 Data Elements vs. Codes

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 elements 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 CT 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.

6.20.3.5 5.7.3.5 Standardization through governance and registries

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:

• There must be a shared repository of data elements that will be consulted and used by the community where improved interoperability is targeted. Numerous groups will define and register data elements in a wide variety of repositories for a wide variety of purposes. To improve interoperability, everyone in the target community needs to be working from the same set.
• There must be governance over the repository of data elements to ensure consistency of granularity and reference structures - those designing questionnaires, profiles, etc. need to be able to find the appropriate data element easily within the repository and there should ideally only be one data element for a given purpose. If a repository accepts 15 data elements defining different ways of capturing the same piece of information, there will be no improvement in interoperability.
• There must be incentives or governance processes in place that encourage or require the use of data elements from the shared repository when defining forms, profiles and other structures where improved interoperability is desired.
• There must be allowance for (and a transition path for) legacy systems that capture data or have existing data that is not in alignment with the approved data elements.

Data Elements are a tool through which improved standardization can be achieved but without adequate processes, they will not achieve significant benefit.

6.20.3.6 5.7.3.6 Data Element granularity and hierarchy

Data elements can be defined at a wide variety of granularities. For example:

• Systolic Blood pressure
• Systolic Blood pressure (sitting)
• Systolic Blood pressure (sitting, pressure cuff)
• Systolic Blood pressure (sitting, pressure cuff) mmHg

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.

6.20.3.7 5.7.3.7 Comparability and conversion of data elements

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.

6.20.3.8 5.7.3.8 Data Element stringency

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/necessary 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.

6.20.3.9 5.7.3.9 Definitions

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:

• The definition does not use the name of the element as part of the definition - it should provide additional information above and beyond the name.
• The definition should be more than one or two words.
• Ideally, the definition should be phrased in a manner such that the definition could be substituted for the data element name in a sentence; e.g. "gender" might be defined as "the sexual identity of a person as used for administrative purposes"
• If the data element does not have a value set and does not make use of a simple type such as date, integer or boolean, it should list several example values as part of the definition.
• Information about the rationale for the element or additional usage notes should not be conveyed as part of the definition but should instead make use of the notes or rationale elements.

6.20.3.10 5.7.3.10 Data Elements and Access Control

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.

6.20.3.11 5.7.3.11 References to and from Data Elements

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.
• The Questionnaire extension deReference Questionnaire.item.definition allows a particular question in a questionnaire to be linked to a data element definition deemed to correspond to that question. This mechanism supports population of questionnaire instances on the basis of known data elements. The intent is that a server will populate anything it recognizes by data elements. However servers may not know all the data elements, and won't populate ones that they don't know.

STU Note: The FHIR Infrastructure work group is considering rolling the DataElement resource into the StructureDefinition resource. If this is done, DataElement will be treated as a type of logical model (whether there will be a distinct 'type' for it is unclear).

Implementers wishing to provide their feedback on the proposed change are invited to make comments on the associated Tracker item .

6.20.4 5.7.4 Search Parameters

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 Expression	In Common
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 External identifier of for the data element	DataElement.identifier
jurisdiction	token	Intended jurisdiction for the data element	DataElement.jurisdiction
name	string	Name Computationally friendly 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
title	string	The human-friendly name of the data element	DataElement.title
url	uri	The official URL for uri that identifies the data element	DataElement.url
version	string token	The business version identifier of the data element	DataElement.version