This page is part of the FHIR Specification (v0.4.0: DSTU 2 Draft). 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
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.
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 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, FamilyHistory, 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.
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.
Structure
Name | Flags | Card. | Type | Description & Constraints |
---|---|---|---|---|
DataElement | I | DomainResource | Resource data element Can have a maximum of one definitional binding or primary concept | |
url | Σ | 0..1 | uri | Globally unique logical id for data element |
identifier | Σ | 0..1 | Identifier | Logical id to reference this data element |
version | Σ | 0..1 | string | Logical id for this version of the data element |
publisher | Σ | 0..1 | string | Name of the publisher (Organization or individual) |
contact | Σ | 0..* | Element | Contact details of the publisher |
name | Σ | 0..1 | string | Name of a individual to contact |
telecom | Σ | 0..* | ContactPoint | Contact details for individual or publisher |
status | M Σ | 1..1 | code | draft | active | retired ResourceDataElementStatus (Required) |
experimental | Σ | 0..1 | boolean | If for testing purposes, not real usage |
date | Σ | 0..1 | dateTime | Date for this version of the data element |
name | Σ | 0..1 | string | Descriptive label for this element definition |
category | Σ | 0..* | CodeableConcept | Assist with indexing and finding |
granularity | Σ | 0..1 | code | comparable | fully-specified | equivalent | convertable | scaleable | flexible DataElementGranularity (Required) |
code | Σ | 0..* | Coding | Identifying concept |
question | Σ | 0..1 | string | Prompt for element phrased as question |
label | Σ | 0..1 | string | Name for element to display with or prompt for element |
definition | 0..1 | string | Definition/description as narrative text | |
copyright | 0..1 | string | Use and/or Publishing restrictions | |
comments | 0..1 | string | Comments about the use of this element | |
requirements | 0..1 | string | Why is this needed? | |
synonym | 0..* | string | Other names | |
type | 0..1 | code | Name of Data type DataType (Required) | |
example[x] | 0..1 | * | Example value: [as defined for type] | |
maxLength | 0..1 | integer | Length for strings | |
units[x] | Units to use for measured value Units (Incomplete) | |||
unitsCodeableConcept | 0..1 | CodeableConcept | ||
unitsReference | 0..1 | ValueSet | ||
binding | I | 0..1 | Element | ValueSet details if this is coded Example value sets are always extensible provide either a valueSet or a description (or both) |
isExtensible | I | 1..1 | boolean | Can additional codes be used? |
conformance | I | 0..1 | code | required | preferred | example BindingConformance (Required) |
description | I | 0..1 | string | Human explanation of the value set |
valueSet | I | 0..1 | ValueSet | Source of value set |
mapping | I | 0..* | Element | Map element to another set of definitions Must have at a name or a uri (or both) |
uri | I | 0..1 | uri | Identifies what this mapping refers to |
definitional | 0..1 | boolean | True if mapping defines element | |
name | I | 0..1 | string | Names what this mapping refers to |
comments | 0..1 | string | Versions, Issues, Scope limitations etc | |
map | 1..1 | string | Details of the mapping |
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..1 Identifier Logical id to reference this data element --></identifier> <version value="[string]"/><!-- 0..1 Logical id for this version of the data element --> <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> <status value="[code]"/><!-- 1..1 draft | active | retired --> <experimental value="[boolean]"/><!-- 0..1 If for testing purposes, not real usage --> <date value="[dateTime]"/><!-- 0..1 Date for this version of the data element --> <name value="[string]"/><!-- 0..1 Descriptive label for this element definition --> <category><!-- 0..* CodeableConcept Assist with indexing and finding --></category> <granularity value="[code]"/><!-- 0..1 comparable | fully-specified | equivalent | convertable | scaleable | flexible --> <code><!-- 0..* Coding Identifying concept --></code> <question value="[string]"/><!-- 0..1 Prompt for element phrased as question --> <label value="[string]"/><!-- 0..1 Name for element to display with or prompt for element --> <definition value="[string]"/><!-- 0..1 Definition/description as narrative text --> <copyright value="[string]"/><!-- 0..1 Use and/or Publishing restrictions --> <comments value="[string]"/><!-- 0..1 Comments about the use of this element --> <requirements value="[string]"/><!-- 0..1 Why is this needed? --> <synonym value="[string]"/><!-- 0..* Other names --> <type value="[code]"/><!-- 0..1 Name of Data type --> <example[x]><!-- 0..1 * Example value: [as defined for type] --></example[x]> <maxLength value="[integer]"/><!-- 0..1 Length for strings --> <units[x]><!-- 0..1 CodeableConcept|Reference(ValueSet) Units to use for measured value --></units[x]> <binding> <!-- 0..1 ValueSet details if this is coded --> <isExtensible value="[boolean]"/><!-- 1..1 Can additional codes be used? --> <conformance value="[code]"/><!-- 0..1 required | preferred | example --> <description value="[string]"/><!-- 0..1 Human explanation of the value set --> <valueSet><!-- 0..1 Reference(ValueSet) Source of value set --></valueSet> </binding> <mapping> <!-- 0..* Map element to another set of definitions --> <uri value="[uri]"/><!-- 0..1 Identifies what this mapping refers to --> <definitional value="[boolean]"/><!-- 0..1 True if mapping defines element --> <name value="[string]"/><!-- 0..1 Names what this mapping refers to --> <comments value="[string]"/><!-- 0..1 Versions, Issues, Scope limitations etc --> <map value="[string]"/><!-- 1..1 Details of the mapping --> </mapping> </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 "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 }], "status" : "<code>", // R! draft | active | retired "experimental" : <boolean>, // If for testing purposes, not real usage "date" : "<dateTime>", // Date for this version of the data element "name" : "<string>", // Descriptive label for this element definition "category" : [{ CodeableConcept }], // Assist with indexing and finding "granularity" : "<code>", // comparable | fully-specified | equivalent | convertable | scaleable | flexible "code" : [{ Coding }], // Identifying concept "question" : "<string>", // Prompt for element phrased as question "label" : "<string>", // Name for element to display with or prompt for element "definition" : "<string>", // Definition/description as narrative text "copyright" : "<string>", // Use and/or Publishing restrictions "comments" : "<string>", // Comments about the use of this element "requirements" : "<string>", // Why is this needed? "synonym" : ["<string>"], // Other names "type" : "<code>", // Name of Data type // example[x]: Example value: [as defined for type]. One of these 23: "exampleInteger" : <integer>, "exampleDecimal" : <decimal>, "exampleDateTime" : "<dateTime>", "exampleDate" : "<date>", "exampleInstant" : "<instant>", "exampleString" : "<string>", "exampleUri" : "<uri>", "exampleBoolean" : <boolean>, "exampleCode" : "<code>", "exampleBase64Binary" : "<base64Binary>", "exampleCoding" : { Coding }, "exampleCodeableConcept" : { CodeableConcept }, "exampleAttachment" : { Attachment }, "exampleIdentifier" : { Identifier }, "exampleQuantity" : { Quantity }, "exampleRange" : { Range }, "examplePeriod" : { Period }, "exampleRatio" : { Ratio }, "exampleHumanName" : { HumanName }, "exampleAddress" : { Address }, "exampleContact" : { Contact }, "exampleSchedule" : { Schedule }, "exampleReference" : { Reference }, "maxLength" : <integer>, // Length for strings // units[x]: Units to use for measured value. One of these 2: "unitsCodeableConcept" : { CodeableConcept }, "unitsReference" : { Reference(ValueSet) }, "binding" : { // ValueSet details if this is coded "isExtensible" : <boolean>, // C? R! Can additional codes be used? "conformance" : "<code>", // C? required | preferred | example "description" : "<string>", // C? Human explanation of the value set "valueSet" : { Reference(ValueSet) } // C? Source of value set }, "mapping" : [{ // Map element to another set of definitions "uri" : "<uri>", // C? Identifies what this mapping refers to "definitional" : <boolean>, // True if mapping defines element "name" : "<string>", // C? Names what this mapping refers to "comments" : "<string>", // Versions, Issues, Scope limitations etc "map" : "<string>" // R! Details of the mapping }] }
Structure
Name | Flags | Card. | Type | Description & Constraints |
---|---|---|---|---|
DataElement | I | DomainResource | Resource data element Can have a maximum of one definitional binding or primary concept | |
url | Σ | 0..1 | uri | Globally unique logical id for data element |
identifier | Σ | 0..1 | Identifier | Logical id to reference this data element |
version | Σ | 0..1 | string | Logical id for this version of the data element |
publisher | Σ | 0..1 | string | Name of the publisher (Organization or individual) |
contact | Σ | 0..* | Element | Contact details of the publisher |
name | Σ | 0..1 | string | Name of a individual to contact |
telecom | Σ | 0..* | ContactPoint | Contact details for individual or publisher |
status | M Σ | 1..1 | code | draft | active | retired ResourceDataElementStatus (Required) |
experimental | Σ | 0..1 | boolean | If for testing purposes, not real usage |
date | Σ | 0..1 | dateTime | Date for this version of the data element |
name | Σ | 0..1 | string | Descriptive label for this element definition |
category | Σ | 0..* | CodeableConcept | Assist with indexing and finding |
granularity | Σ | 0..1 | code | comparable | fully-specified | equivalent | convertable | scaleable | flexible DataElementGranularity (Required) |
code | Σ | 0..* | Coding | Identifying concept |
question | Σ | 0..1 | string | Prompt for element phrased as question |
label | Σ | 0..1 | string | Name for element to display with or prompt for element |
definition | 0..1 | string | Definition/description as narrative text | |
copyright | 0..1 | string | Use and/or Publishing restrictions | |
comments | 0..1 | string | Comments about the use of this element | |
requirements | 0..1 | string | Why is this needed? | |
synonym | 0..* | string | Other names | |
type | 0..1 | code | Name of Data type DataType (Required) | |
example[x] | 0..1 | * | Example value: [as defined for type] | |
maxLength | 0..1 | integer | Length for strings | |
units[x] | Units to use for measured value Units (Incomplete) | |||
unitsCodeableConcept | 0..1 | CodeableConcept | ||
unitsReference | 0..1 | ValueSet | ||
binding | I | 0..1 | Element | ValueSet details if this is coded Example value sets are always extensible provide either a valueSet or a description (or both) |
isExtensible | I | 1..1 | boolean | Can additional codes be used? |
conformance | I | 0..1 | code | required | preferred | example BindingConformance (Required) |
description | I | 0..1 | string | Human explanation of the value set |
valueSet | I | 0..1 | ValueSet | Source of value set |
mapping | I | 0..* | Element | Map element to another set of definitions Must have at a name or a uri (or both) |
uri | I | 0..1 | uri | Identifies what this mapping refers to |
definitional | 0..1 | boolean | True if mapping defines element | |
name | I | 0..1 | string | Names what this mapping refers to |
comments | 0..1 | string | Versions, Issues, Scope limitations etc | |
map | 1..1 | string | Details of the mapping |
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..1 Identifier Logical id to reference this data element --></identifier> <version value="[string]"/><!-- 0..1 Logical id for this version of the data element --> <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> <status value="[code]"/><!-- 1..1 draft | active | retired --> <experimental value="[boolean]"/><!-- 0..1 If for testing purposes, not real usage --> <date value="[dateTime]"/><!-- 0..1 Date for this version of the data element --> <name value="[string]"/><!-- 0..1 Descriptive label for this element definition --> <category><!-- 0..* CodeableConcept Assist with indexing and finding --></category> <granularity value="[code]"/><!-- 0..1 comparable | fully-specified | equivalent | convertable | scaleable | flexible --> <code><!-- 0..* Coding Identifying concept --></code> <question value="[string]"/><!-- 0..1 Prompt for element phrased as question --> <label value="[string]"/><!-- 0..1 Name for element to display with or prompt for element --> <definition value="[string]"/><!-- 0..1 Definition/description as narrative text --> <copyright value="[string]"/><!-- 0..1 Use and/or Publishing restrictions --> <comments value="[string]"/><!-- 0..1 Comments about the use of this element --> <requirements value="[string]"/><!-- 0..1 Why is this needed? --> <synonym value="[string]"/><!-- 0..* Other names --> <type value="[code]"/><!-- 0..1 Name of Data type --> <example[x]><!-- 0..1 * Example value: [as defined for type] --></example[x]> <maxLength value="[integer]"/><!-- 0..1 Length for strings --> <units[x]><!-- 0..1 CodeableConcept|Reference(ValueSet) Units to use for measured value --></units[x]> <binding> <!-- 0..1 ValueSet details if this is coded --> <isExtensible value="[boolean]"/><!-- 1..1 Can additional codes be used? --> <conformance value="[code]"/><!-- 0..1 required | preferred | example --> <description value="[string]"/><!-- 0..1 Human explanation of the value set --> <valueSet><!-- 0..1 Reference(ValueSet) Source of value set --></valueSet> </binding> <mapping> <!-- 0..* Map element to another set of definitions --> <uri value="[uri]"/><!-- 0..1 Identifies what this mapping refers to --> <definitional value="[boolean]"/><!-- 0..1 True if mapping defines element --> <name value="[string]"/><!-- 0..1 Names what this mapping refers to --> <comments value="[string]"/><!-- 0..1 Versions, Issues, Scope limitations etc --> <map value="[string]"/><!-- 1..1 Details of the mapping --> </mapping> </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 "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 }], "status" : "<code>", // R! draft | active | retired "experimental" : <boolean>, // If for testing purposes, not real usage "date" : "<dateTime>", // Date for this version of the data element "name" : "<string>", // Descriptive label for this element definition "category" : [{ CodeableConcept }], // Assist with indexing and finding "granularity" : "<code>", // comparable | fully-specified | equivalent | convertable | scaleable | flexible "code" : [{ Coding }], // Identifying concept "question" : "<string>", // Prompt for element phrased as question "label" : "<string>", // Name for element to display with or prompt for element "definition" : "<string>", // Definition/description as narrative text "copyright" : "<string>", // Use and/or Publishing restrictions "comments" : "<string>", // Comments about the use of this element "requirements" : "<string>", // Why is this needed? "synonym" : ["<string>"], // Other names "type" : "<code>", // Name of Data type // example[x]: Example value: [as defined for type]. One of these 23: "exampleInteger" : <integer>, "exampleDecimal" : <decimal>, "exampleDateTime" : "<dateTime>", "exampleDate" : "<date>", "exampleInstant" : "<instant>", "exampleString" : "<string>", "exampleUri" : "<uri>", "exampleBoolean" : <boolean>, "exampleCode" : "<code>", "exampleBase64Binary" : "<base64Binary>", "exampleCoding" : { Coding }, "exampleCodeableConcept" : { CodeableConcept }, "exampleAttachment" : { Attachment }, "exampleIdentifier" : { Identifier }, "exampleQuantity" : { Quantity }, "exampleRange" : { Range }, "examplePeriod" : { Period }, "exampleRatio" : { Ratio }, "exampleHumanName" : { HumanName }, "exampleAddress" : { Address }, "exampleContact" : { Contact }, "exampleSchedule" : { Schedule }, "exampleReference" : { Reference }, "maxLength" : <integer>, // Length for strings // units[x]: Units to use for measured value. One of these 2: "unitsCodeableConcept" : { CodeableConcept }, "unitsReference" : { Reference(ValueSet) }, "binding" : { // ValueSet details if this is coded "isExtensible" : <boolean>, // C? R! Can additional codes be used? "conformance" : "<code>", // C? required | preferred | example "description" : "<string>", // C? Human explanation of the value set "valueSet" : { Reference(ValueSet) } // C? Source of value set }, "mapping" : [{ // Map element to another set of definitions "uri" : "<uri>", // C? Identifies what this mapping refers to "definitional" : <boolean>, // True if mapping defines element "name" : "<string>", // C? Names what this mapping refers to "comments" : "<string>", // Versions, Issues, Scope limitations etc "map" : "<string>" // R! Details of the mapping }] }
Alternate definitions: Schema/Schematron, Resource Profile (XML, JSON), Questionnaire
Path | Definition | Type | Reference |
---|---|---|---|
DataElement.status | The lifecycle status of a Resource data element | Fixed | http://hl7.org/fhir/resource-observation-def-status |
DataElement.granularity | Indicates the degree of precision of the data element definition | Fixed | http://hl7.org/fhir/dataelement-granularity |
DataElement.type | The type of an element - one of the FHIR data types | Fixed | http://hl7.org/fhir/valueset/data-types |
DataElement.units[x] | Type of measurement system used to express a value | Incomplete | http://hl7.org/fhir/vs/units |
DataElement.binding.conformance | Binding conformance for applications | Fixed | http://hl7.org/fhir/binding-conformance |
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.
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.
In practice, it is generally best to maintain a separate code system whose codes can be referenced in the code
element
of a Data Element rather than to treat the data element identifier itself as a code. Most systems designed to handle code
systems will not be able to handle the additional data associated with a data element. As well, the maintenance and versioning process
for data elements may not align well with the maintenance and versioning processes for codes.
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.
Clem to add section
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.
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.
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 |
category | token | A category assigned to the data element (server may choose to do subsumption) | DataElement.category |
code | token | A code for the data element (server may choose to do subsumption) | DataElement.code |
date | date | The data element publication date | DataElement.date |
description | string | Text search in the description of the data element | DataElement.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 |
version | string | The version identifier of the data element | DataElement.version |