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 . Page versions: R3 R2

6.20 Resource DataElement - Content

This resource maintained by the FHIR Management Group Work Group

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

6.20.1 Scope and Usage

This resource covers two major use-cases:

  1. Definitions of types of measurements or observations that may be requested or performed. In HL7, these are sometimes referred to as service, test or observation "master files"
  2. Definitions of "data elements" (DEs) that may be used in questionnaires (survey instruments and data collection forms) and profiles and potentially mapped to elements in other resources and profiles

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.

6.20.2 Boundaries and Relationships

This resource has significant overlap with Profile and Questionnaire.

Profile also defines data elements. However, it does so only in the context of constraints or extensions on FHIR resources. As well, Profile 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. Authors of Profiles may leverage (and reference) DataElements when defining the data elements with the Profile. (For implementability reasons, the data constraints should still be explicitly exposed within the Profile rather than being included "by reference" to the DataElement.)

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 Ballot Issue: Should a shared structure be used in Profile, 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?

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.

6.20.3 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. DataElement DomainResourceResource data element
... url Σ0..1uriGlobally unique logical id for data element
... identifier Σ0..1IdentifierLogical id to reference this data element
... version Σ0..1stringLogical id for this version of the data element
... name Σ0..1stringDescriptive label for this element definition
... useContext Σ0..*CodeableConceptContent intends to support these contexts
ConformanceUseContext (Extensible)
... experimental Σ0..1booleanIf for testing purposes, not real usage
... status ?! Σ1..1codedraft | active | retired
ConformanceResourceStatus (Required)
... date Σ0..1dateTimeDate for this version of the data element
... copyright 0..1stringUse and/or Publishing restrictions
... publisher Σ0..1stringName of the publisher (Organization or individual)
... contact Σ0..*ElementContact details of the publisher
.... name Σ0..1stringName of a individual to contact
.... telecom Σ0..*ContactPointContact details for individual or publisher
... specificity Σ0..1codecomparable | fully-specified | equivalent | convertable | scaleable | flexible
DataElementSpecificity (Required)
... mapping 0..*ElementExternal specification mapped to
.... identity 1..1idInternal id when this mapping is used
.... uri 0..1uriIdentifies what this mapping refers to
.... name 0..1stringNames what this mapping refers to
.... comments 0..1stringVersions, Issues, Scope limitations etc
... element 1..*ElementDefinitionDefinition of element

UML Diagram

DataElement (DomainResource)An absolute uri that is used to identify this element when it is referenced in a specification, model, design or an instance (should be globally unique URI, and an be urn:uuid: or urn:oid:)url : uri 0..1Formal identifier that is used to identify this data element when it is represented in other formats, or referenced in a specification, model, design or an instanceidentifier : Identifier 0..1The identifier that is used to identify this version of the data element when it is referenced in a StructureDefinition, Questionnaire or instance. This is an arbitrary value managed by the definition author manuallyversion : string 0..1The term used by humans to refer to the data element. Should ideally be unique within the context in which the data element is expected to be usedname : string 0..1The content was developed with a focus and intent of supporting the contexts that are listed. These terms may be used to assist with indexing and searching of data element definitionsuseContext : CodeableConcept 0..* « Indicates the countries, regions, disciplines and other aspects of use this artifact is targeted for use withinConformanceUseContext+ »A flag to indicate that this search data elemnt definition is authored for testing purposes (or education/evaluation/marketing), and is not intended to be used for genuine usageexperimental : boolean 0..1The status of the data element (this element modifies the meaning of other elements)status : code 1..1 « The lifecycle status of a Value Set or Concept MapConformanceResourceStatus »The date that the status for this business version of the data element became effective. (I.e. Date the draft was created, date element became active or date element became retired)date : dateTime 0..1A copyright statement relating to the definition of the data element. Copyright statements are generally legal restrictions on the use and publishing of the details of the definition of the data elementcopyright : string 0..1The name of the individual or organization that published the data elementpublisher : string 0..1Identifies how precise the data element is in its definitionspecificity : code 0..1 « Indicates the degree of precision of the data element definitionDataElementSpecificity »Defines the structure, type, allowed values and other constraining characteristics of the data elementelement : ElementDefinition 1..*ContactThe name of an individual to contact regarding the data elementname : string 0..1Contact details for individual (if a name was provided) or the publishertelecom : ContactPoint 0..*MappingAn Internal id that is used to identify this mapping set when specific mappings are made on a per-element basisidentity : id 1..1An absolute URI that identifies the specification that this mapping is expressed touri : uri 0..1A name for the specification that is being mapped toname : string 0..1Comments about this mapping, including version notes, issues, scope limitations, and other important notes for usagecomments : string 0..1Contacts to assist a user in finding and communicating with the publishercontact0..*Identifies a specification (other than a terminology) that the elements that make up the DataElement hav some correspondance withmapping0..*

XML Template

<DataElement xmlns="http://hl7.org/fhir"> doco
 <!-- 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..1 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 -->
 <useContext><!-- 0..* CodeableConcept Content intends to support these contexts --></useContext>
 <experimental value="[boolean]"/><!-- 0..1 If for testing purposes, not real usage -->
 <status value="[code]"/><!-- 1..1 draft | active | retired -->
 <date value="[dateTime]"/><!-- 0..1 Date for this version of the data element -->
 <copyright value="[string]"/><!-- 0..1 Use and/or Publishing restrictions -->
 <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>
 <specificity 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

{doco
  "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
  "useContext" : [{ CodeableConcept }], // Content intends to support these contexts
  "experimental" : <boolean>, // If for testing purposes, not real usage
  "status" : "<code>", // R!  draft | active | retired
  "date" : "<dateTime>", // Date for this version of the data element
  "copyright" : "<string>", // Use and/or Publishing restrictions
  "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
  }],
  "specificity" : "<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

NameFlagsCard.TypeDescription & Constraintsdoco
.. DataElement DomainResourceResource data element
... url Σ0..1uriGlobally unique logical id for data element
... identifier Σ0..1IdentifierLogical id to reference this data element
... version Σ0..1stringLogical id for this version of the data element
... name Σ0..1stringDescriptive label for this element definition
... useContext Σ0..*CodeableConceptContent intends to support these contexts
ConformanceUseContext (Extensible)
... experimental Σ0..1booleanIf for testing purposes, not real usage
... status ?! Σ1..1codedraft | active | retired
ConformanceResourceStatus (Required)
... date Σ0..1dateTimeDate for this version of the data element
... copyright 0..1stringUse and/or Publishing restrictions
... publisher Σ0..1stringName of the publisher (Organization or individual)
... contact Σ0..*ElementContact details of the publisher
.... name Σ0..1stringName of a individual to contact
.... telecom Σ0..*ContactPointContact details for individual or publisher
... specificity Σ0..1codecomparable | fully-specified | equivalent | convertable | scaleable | flexible
DataElementSpecificity (Required)
... mapping 0..*ElementExternal specification mapped to
.... identity 1..1idInternal id when this mapping is used
.... uri 0..1uriIdentifies what this mapping refers to
.... name 0..1stringNames what this mapping refers to
.... comments 0..1stringVersions, Issues, Scope limitations etc
... element 1..*ElementDefinitionDefinition of element

UML Diagram

DataElement (DomainResource)An absolute uri that is used to identify this element when it is referenced in a specification, model, design or an instance (should be globally unique URI, and an be urn:uuid: or urn:oid:)url : uri 0..1Formal identifier that is used to identify this data element when it is represented in other formats, or referenced in a specification, model, design or an instanceidentifier : Identifier 0..1The identifier that is used to identify this version of the data element when it is referenced in a StructureDefinition, Questionnaire or instance. This is an arbitrary value managed by the definition author manuallyversion : string 0..1The term used by humans to refer to the data element. Should ideally be unique within the context in which the data element is expected to be usedname : string 0..1The content was developed with a focus and intent of supporting the contexts that are listed. These terms may be used to assist with indexing and searching of data element definitionsuseContext : CodeableConcept 0..* « Indicates the countries, regions, disciplines and other aspects of use this artifact is targeted for use withinConformanceUseContext+ »A flag to indicate that this search data elemnt definition is authored for testing purposes (or education/evaluation/marketing), and is not intended to be used for genuine usageexperimental : boolean 0..1The status of the data element (this element modifies the meaning of other elements)status : code 1..1 « The lifecycle status of a Value Set or Concept MapConformanceResourceStatus »The date that the status for this business version of the data element became effective. (I.e. Date the draft was created, date element became active or date element became retired)date : dateTime 0..1A copyright statement relating to the definition of the data element. Copyright statements are generally legal restrictions on the use and publishing of the details of the definition of the data elementcopyright : string 0..1The name of the individual or organization that published the data elementpublisher : string 0..1Identifies how precise the data element is in its definitionspecificity : code 0..1 « Indicates the degree of precision of the data element definitionDataElementSpecificity »Defines the structure, type, allowed values and other constraining characteristics of the data elementelement : ElementDefinition 1..*ContactThe name of an individual to contact regarding the data elementname : string 0..1Contact details for individual (if a name was provided) or the publishertelecom : ContactPoint 0..*MappingAn Internal id that is used to identify this mapping set when specific mappings are made on a per-element basisidentity : id 1..1An absolute URI that identifies the specification that this mapping is expressed touri : uri 0..1A name for the specification that is being mapped toname : string 0..1Comments about this mapping, including version notes, issues, scope limitations, and other important notes for usagecomments : string 0..1Contacts to assist a user in finding and communicating with the publishercontact0..*Identifies a specification (other than a terminology) that the elements that make up the DataElement hav some correspondance withmapping0..*

XML Template

<DataElement xmlns="http://hl7.org/fhir"> doco
 <!-- 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..1 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 -->
 <useContext><!-- 0..* CodeableConcept Content intends to support these contexts --></useContext>
 <experimental value="[boolean]"/><!-- 0..1 If for testing purposes, not real usage -->
 <status value="[code]"/><!-- 1..1 draft | active | retired -->
 <date value="[dateTime]"/><!-- 0..1 Date for this version of the data element -->
 <copyright value="[string]"/><!-- 0..1 Use and/or Publishing restrictions -->
 <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>
 <specificity 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

{doco
  "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
  "useContext" : [{ CodeableConcept }], // Content intends to support these contexts
  "experimental" : <boolean>, // If for testing purposes, not real usage
  "status" : "<code>", // R!  draft | active | retired
  "date" : "<dateTime>", // Date for this version of the data element
  "copyright" : "<string>", // Use and/or Publishing restrictions
  "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
  }],
  "specificity" : "<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)

6.20.3.1 Terminology Bindings

PathDefinitionTypeReference
DataElement.useContext Indicates the countries, regions, disciplines and other aspects of use this artifact is targeted for use withinExtensiblehttp://hl7.org/fhir/vs/use-context
DataElement.status The lifecycle status of a Value Set or Concept MapRequiredhttp://hl7.org/fhir/conformance-resource-status
DataElement.specificity Indicates the degree of precision of the data element definitionRequiredhttp://hl7.org/fhir/dataelement-specificity

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

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:

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.3 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 while codes describe a particular concept (often in relation to other concepts). However, because data elements provide a definition of the meaning of a particular element, they can be thought of as being codes. One of their purpose 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.

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.4 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.5 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.6 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.7 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/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.

6.20.3.8 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.9 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.10 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 allows a particular question in a questionnaire to be linked to a data element deemed to correspond to that question. This mechanism supports population of questionnaire instances on the basis of known data elements

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

NameTypeDescriptionPaths
codetokenA code for the data element (server may choose to do subsumption)DataElement.element.code
contexttokenA use context assigned to the data elementDataElement.useContext
datedateThe data element publication dateDataElement.date
descriptionstringText search in the description of the data element. This corresponds to the definition of the first DataElement.element.DataElement.element.definition
identifiertokenThe identifier of the data elementDataElement.identifier
namestringName of the data elementDataElement.name
publisherstringName of the publisher of the data elementDataElement.publisher
statustokenThe current status of the data elementDataElement.status
urluriThe official URL for the data elementDataElement.url
versionstringThe version identifier of the data elementDataElement.version