Captures constraints on each element within the resource, profile, or extension.

The path identifies the element and is expressed as a "."-separated list of ancestor elements, beginning with the name of the resource or extension.

Codes that define how this element is represented in instances, when the deviation varies from the normal case. No extensions are allowed on elements with a representation of 'xmlAttr', no matter what FHIR serialization format is used.

In resources, this is rarely used except for special cases where the representation deviates from the normal, and can only be done in the base standard (and profiles must reproduce what the base standard does). This element is used quite commonly in Logical models when the logical models represent a specific serialization format (e.g. CDA, v2 etc.).

The name of this element definition slice, when slicing is working. The name must be a token with no dots or spaces. This is a unique name referring to a specific set of constraints applied to this element, used to provide a name to different slices of the same element.

May also be used for code generation purposes.

The name SHALL be unique within the structure within the context of the constrained resource element. (Though to avoid confusion, uniqueness across all elements is recommended.).

If true, indicates that this slice definition is constraining a slice definition with the same name in an inherited profile. If false, the slice is not overriding any slice in an inherited profile. If missing, the slice might or might not be overriding a slice in an inherited profile, depending on the sliceName.

Allows detection of a situation where an ancestor profile adds or removes slicing with the same name where that might impact the child profile.

If set to true, an ancestor profile SHALL have a slicing definition with this name. If set to false, no ancestor profile is permitted to have a slicing definition with this name.

A single preferred label which is the text to display beside the element indicating its meaning or to use to prompt for the element in a user display or form.

See also the extension (http://hl7.org/fhir/StructureDefinition/elementdefinition-question)[extension-elementdefinition-question.html].

A code that has the same meaning as the element in a particular terminology.

Links the meaning of an element to an external terminology, and is very useful for searching and indexing.

The concept SHALL be properly aligned with the data element definition and other constraints, as defined in the code system, including relationships, of any code listed here. Where multiple codes exist in a terminology that could correspond to the data element, the most granular code(s) should be selected, so long as they are not more restrictive than the data element itself. The mappings may be used to provide more or less granular or structured equivalences in the code system.

Indicates that the element is sliced into a set of alternative definitions (i.e. in a structure definition, there are multiple different constraints on a single element in the base resource). Slicing can be used in any resource that has cardinality ..* on the base resource, or any resource with a choice of types. The set of slices is any elements that come after this in the element sequence that have the same path, until a shorter path occurs (the shorter path terminates the set).

The first element in the sequence, the one that carries the slicing, is the definition that applies to all the slices. This is based on the unconstrained element, but can apply any constraints as appropriate. This may include the common constraints on the children of the element.

Designates which child elements are used to discriminate between the slices when processing an instance. If one or more discriminators are provided, the value of the child elements in the instance data SHALL completely distinguish which slice the element in the resource matches based on the allowed values for those elements in each of the slices.

If there is no discriminator, the content is hard to process, so this should be avoided.

How the element value is interpreted when discrimination is evaluated.

pattern' is deprecated - it works exactly the same as 'value'.

A FHIRPath expression, using the simple subset of FHIRPath, that is used to identify the element on which discrimination is based.

A human-readable text description of how the slicing works. If there is no discriminator, this is required to be present to provide whatever information is possible about how the slices can be differentiated.

If it's really not possible to differentiate them, the design should be re-evaluated to make the content usable.

If the matching elements have to occur in the same order as defined in the profile.

Order should only be required when it is a pressing concern for presentation. Profile authors should consider making the order a feature of the rules about the narrative, not the rules about the data - requiring ordered data makes the profile much less re-usable.

Whether additional slices are allowed or not. When the slices are ordered, profile authors can also say that additional slices are only allowed at the end.

Allowing additional elements makes for a much for flexible template - it's open for use in wider contexts, but also means that the content of the resource is not closed, and applications have to decide how to handle content not described by the profile.

A concise description of what this element means (e.g. for use in autogenerated summaries).

It is easy for a different short definition to change the meaning of an element and this can have nasty downstream consequences. Please be careful when providing short definitions in a profile.

Provides a complete explanation of the meaning of the data element for human readability. For the case of elements derived from existing elements (e.g. constraints), the definition SHALL be consistent with the base definition, but convey the meaning of the element in the particular context of use of the resource. (Note: The text you are reading is specified in ElementDefinition.definition).

To allow a user to state the usage of an element in a particular context.

It is easy for a different definition to change the meaning of an element and this can have nasty downstream consequences. Please be careful when providing definitions in a profile.

Explanatory notes and implementation guidance about the data element, including notes about how to use the data properly, exceptions to proper use, etc. (Note: The text you are reading is specified in ElementDefinition.comment).

If it is possible to capture usage rules using constraints, that mechanism should be used in preference to this element.

This element is for traceability of why the element was created and why the constraints exist as they do. This may be used to point to source materials or specifications that drove the structure of this element.

This element does not describe the usage of the element (that's done in comments), rather it's for traceability of why the element is either needed or why the constraints exist as they do. This may be used to point to source materials or specifications that drove the structure of this data element.

Identifies additional names by which this element might also be known.

Allows for better easier recognition of the element by multiple communities, including international communities.

The minimum number of times this element SHALL appear in the instance.

The maximum number of times this element is permitted to appear in the instance.

Information about the base definition of the element, provided to make it unnecessary for tools to trace the deviation of the element through the derived and related profiles. When the element definition is not the original definition of an element - i.g. either in a constraint on another type, or for elements from a super type in a snap shot - then the information in provided in the element definition may be different to the base definition. On the original definition of the element, it will be same.

The base information does not carry any information that could not be determined from the path and related profiles, but making this determination requires both that the related profiles are available, and that the algorithm to determine them be available. For tooling simplicity, the base information must always be populated in element definitions in snap shots, even if it is the same.

The Path that identifies the base element - this matches the ElementDefinition.path for that element. Across FHIR, there is only one base definition of any element - that is, an element definition on a StructureDefinition without a StructureDefinition.base.

Minimum cardinality of the base element identified by the path.

This is provided for consistency with max, and may affect code generation of mandatory elements of the base resource are generated differently (some reference implementations have done this).

Maximum cardinality of the base element identified by the path.

This is provided to code generation, since the serialization representation in JSON differs depending on whether the base element has max > 1. Also, some forms of code generation may differ.

Identifies an element defined elsewhere in the definition whose content rules should be applied to the current element. ContentReferences bring across all the rules that are in the ElementDefinition for the element, including definitions, cardinality constraints, bindings, invariants etc.

ContentReferences can only be defined in specializations, not constrained types, and they cannot be changed and always reference the non-constrained definition.

The data type or resource that the value of this element is permitted to be.

The Type of the element can be left blank in a differential constraint, in which case the type is inherited from the resource. Abstract types are not permitted to appear as a type when multiple types are listed. (I.e. Abstract types cannot be part of a choice).

URL of Data type or Resource that is a(or the) type used for this element. References are URLs that are relative to http://hl7.org/fhir/StructureDefinition e.g. "string" is a reference to http://hl7.org/fhir/StructureDefinition/string. Absolute URLs are only allowed in logical models.

If the element is a reference to another resource, this element contains "Reference", and the targetProfile element defines what resources can be referenced. The targetProfile may be a reference to the general definition of a resource (e.g. http://hl7.org/fhir/StructureDefinition/Patient).

Identifies a profile structure or implementation Guide that applies to the datatype this element refers to. If any profiles are specified, then the content must conform to at least one of them. The URL can be a local reference - to a contained StructureDefinition, or a reference to another StructureDefinition or Implementation Guide by a canonical URL. When an implementation guide is specified, the type SHALL conform to at least one profile defined in the implementation guide.

It is possible to profile backbone element (e.g. part of a resource), using the profile-element extension.

Used when the type is "Reference" or "canonical", and identifies a profile structure or implementation Guide that applies to the target of the reference this element refers to. If any profiles are specified, then the content must conform to at least one of them. The URL can be a local reference - to a contained StructureDefinition, or a reference to another StructureDefinition or Implementation Guide by a canonical URL. When an implementation guide is specified, the target resource SHALL conform to at least one profile defined in the implementation guide.

If the type is a reference to another resource, how the resource is or can be aggregated - is it a contained resource, or a reference, and if the context is a bundle, is it included in the bundle.

See Aggregation Rules for further clarification.

Whether this reference needs to be version specific or version independent, or whether either can be used.

The base specification never makes a rule as to which form is allowed, but implementation guides may do this. See Aggregation Rules for further clarification.

The value that should be used if there is no value stated in the instance (e.g. 'if not otherwise specified, the abstract is false').

Specifying a default value means that the property can never been unknown - it must always have a value. Further, the default value can never be changed, or changed in constraints on content models. Defining default values creates many difficulties in implementation (e.g. when is a value missing?). For these reasons, default values are (and should be) used extremely sparingly.

No default values are ever defined in the FHIR specification, nor can they be defined in constraints ("profiles") on data types or resources. This element only exists so that default values may be defined in logical models.

The Implicit meaning that is to be understood when this element is missing (e.g. 'when this element is missing, the period is ongoing').

Implicit meanings for missing values can only be specified on a resource, data type, or extension definition, and never in a profile that applies to one of these. An implicit meaning for a missing value can never be changed, and specifying one has the consequence that constraining its use in profiles eliminates use cases as possibilities, not merely moving them out of scope.

If present, indicates that the order of the repeating element has meaning and describes what that meaning is. If absent, it means that the order of the element has no meaning.

This element can only be asserted on repeating elements and can only be introduced when defining resources or data types. It can be further refined profiled elements but if absent in the base type, a profile cannot assert meaning.

Specifies a value that SHALL be exactly the value for this element in the instance, if present. For purposes of comparison, non-significant whitespace is ignored, and all values must be an exact match (case and accent sensitive). Missing elements/attributes must also be missing.

This is not recommended for Coding and CodeableConcept since these often have highly contextual properties such as version or display.

Specifies a value that each occurrence of the element in the instance SHALL follow - that is, any value in the pattern must be found in the instance, if the element has a value. Other additional values may be found too. This is effectively constraint by example.

When pattern[x] is used to constrain a primitive, it means that the value provided in the pattern[x] must match the instance value exactly.

When an element within a pattern[x] is used to constrain an array, it means that each element provided in the pattern[x] must (recursively) match at least one element from the instance array.

When pattern[x] is used to constrain a complex object, it means that each property in the pattern must be present in the complex object, and its value must recursively match -- i.e.,

1. If primitive: it must match exactly the pattern value
2. If a complex object: it must match (recursively) the pattern value
3. If an array: it must match (recursively) the pattern value

If a pattern[x] is declared on a repeating element, the pattern applies to all repetitions. If the desire is for a pattern to apply to only one element or a subset of elements, slicing must be used. See Examples of Patterns for examples of pattern usage and the effect it will have.

Mostly used for fixing values of CodeableConcept. In general, pattern[x] is not intended for use with primitive types, where is has the same meaning as fixed[x].

A sample value for this element demonstrating the type of information that would typically be found in the element.

Examples will most commonly be present for data where it's not implicitly obvious from either the data type or value set what the values might be. (I.e. Example values for dates or quantities would generally be unnecessary.) If the example value is fully populated, the publication tool can generate an instance automatically.

Describes the purpose of this example amoung the set of examples.

The actual value for the element, which must be one of the types allowed for this element.

The minimum allowed value for the element. The value is inclusive. This is allowed for the types date, dateTime, instant, time, decimal, integer, and Quantity.

Except for date/date/instant, the type of the minValue[x] SHALL be the same as the specified type of the element. For the date/dateTime/instant values, the type of minValue[x] SHALL be either the same, or a Duration which specifies a relative time limit to the current time. The duration value is positive, and is subtracted from the current clock to determine the minimum allowable value. A minimum value for a Quantity is interpreted as an canonical minimum - e.g. you cannot provide 100mg if the minimum value is 10g.

The maximum allowed value for the element. The value is inclusive. This is allowed for the types date, dateTime, instant, time, decimal, integer, and Quantity.

Except for date/date/instant, the type of the maxValue[x] SHALL be the same as the specified type of the element. For the date/dateTime/instant values, the type of maxValue[x] SHALL be either the same, or a Duration which specifies a relative time limit to the current time. The duration value is positive, and is added to the current clock to determine the maximum allowable value. A maximum value for a Quantity is interpreted as an canonical maximum - e.g. you cannot provide 10g if the maximum value is 50mg.

Indicates the maximum length in characters that is permitted to be present in conformant instances and which is expected to be supported by conformant consumers that support the element. maxLength SHOULD only be used on primitive data types that have a string representation (see Datatype characteristics).

Receivers are not required to reject instances that exceed the maximum length. The full length could be stored. In some cases, data might be truncated, though truncation should be undertaken with care and an understanding of the consequences of doing so. If not specified, there is no conformance expectation for length support.

A reference to an invariant that may make additional statements about the cardinality or value in the instance.

Formal constraints such as co-occurrence and other constraints that can be computationally evaluated within the context of the instance.

Constraints should be declared on the "context" element - the lowest element in the hierarchy that is common to all nodes referenced by the constraint.

Allows identification of which elements have their cardinalities impacted by the constraint. Will not be referenced for constraints that do not affect cardinality.

Description of why this constraint is necessary or appropriate.

To be used if the reason for the constraint might not be intuitive to all implementers.

Identifies the impact constraint violation has on the conformance of the instance.

This allows constraints to be asserted as "shall" (error) and "should" (warning).

If true, indicates that the warning or best practice guideline should be suppressed.

This element should only be present in a derived profile where a warning or hint has been determined to be spurious/incorrect. E.g. a warning encouraging the inclusion of an element that the profile explicitly prohibits.

Text that can be used to describe the constraint in messages identifying that the constraint has been violated.

Should be expressed in business terms as much as possible.

A FHIRPath expression of constraint that can be executed to see if this constraint is met.

Used by validation tooling tests of the validity of the resource.

In the absense of an expression, the expression is likely not enforceable by validators, and might be missed by many systems.

An XPath expression of constraint that can be executed to see if this constraint is met.

Used in Schematron tests of the validity of the resource.

Elements SHALL use "f" as the namespace prefix for the FHIR namespace, and "x" for the xhtml namespace, and SHALL NOT use any other prefixes. Note: XPath is generally considered not useful because it does not apply to JSON and other formats and because of XSLT implementation issues, and may be removed in the future.

A reference to the original source of the constraint, for traceability purposes.

This is used when, e.g. rendering, where it is not useful to present inherited constraints when rendering the snapshot.

If true, implementations that produce or consume resources SHALL provide "support" for the element in some meaningful way. If false, the element may be ignored and not supported. If false, whether to populate or use the data element in any way is at the discretion of the implementation.

Allows a profile to set expectations for system capabilities beyond merely respecting cardinality constraints.

"Something meaningful" is context dependent and impossible to describe in the base FHIR specification. For this reason, the mustSupport flag is never set to true by the FHIR specification itself - it is only set to true in profiles. A profile on a type can always make mustSupport = true if it is false in the base type but cannot make mustSupport = false if it is true in the base type. This is done in Resource Profiles, where the profile labels an element as mustSupport=true. When a profile does this, it SHALL also make clear exactly what kind of "support" is required, as this can mean many things. Note that an element that has the property IsModifier is not necessarily a "key" element (e.g. one of the important elements to make use of the resource), nor is it automatically mustSupport - however both of these things are more likely to be true for IsModifier elements than for other elements.

If true, the value of this element affects the interpretation of the element or resource that contains it, and the value of the element cannot be ignored. Typically, this is used for status, negation and qualification codes. The effect of this is that the element cannot be ignored by systems: they SHALL either recognize the element and process it, and/or a pre-determination has been made that it is not relevant to their particular system.

Allows elements to be introduced into a specification that can't safely be ignored by applications that don't recognize them.

Only the definition of an element can set IsModifier true - either the specification itself or where an extension is originally defined. Once set, it cannot be changed in derived profiles. An element/extension that has isModifier=true SHOULD also have a minimum cardinality of 1, so that there is no lack of clarity about what to do if it is missing. If it can be missing, the definition SHALL make the meaning of a missing element clear.

Explains how that element affects the interpretation of the resource or element that contains it.

Whether the element should be included if a client requests a search with the parameter _summary=true.

Allow clients to search through large resources quickly.

Some resources include a set of simple metadata, and some very large data. This element is used to reduce the quantity of data returned in searches. Note that servers may pre-cache summarized resources for optimal performance. When a request is made with _summary=true, serializers only include elements marked as 'isSummary = true'. With a few exceptions (listed below), all datatype properties are included in the summary form. In resource and datatype definitions, if an element has a descendant marked as isSummary=true or if it satisfies both of the following conditions, it must be marked as isSummary=true:

• is at the root or has a parent that is 'mustSupport'
• has a minimum cardinality of 1 or is a modifier element

The following datatype properties are exceptions, and are not marked as isSummary:

• Attachment.data
• Signature.data, Signature.targetFormat, Signature.sigFormat
• Narrative.status, Narrative.div
• SampledData.data.

Binds to a value set if this element is coded (code, Coding, CodeableConcept, Quantity), or the data types (string, uri).

For a CodeableConcept, when no codes are allowed - only text, use a binding of strength "required" with a description explaining that no coded values are allowed and what sort of information to put in the "text" element.

Indicates the degree of conformance expectations associated with this binding - that is, the degree to which the provided value set must be adhered to in the instances.

For further discussion, see Using Terminologies.

Describes the intended use of this particular set of codes.

Refers to the value set that identifies the set of codes the binding refers to.

The reference may be version-specific or not (e.g. have a |[version] at the end of the canonical URL).

Identifies a concept from an external specification that roughly corresponds to this element.

Provides guidance to implementers familiar with or converting content from other specifications.

Mappings are not necessarily specific enough for safe translation.

An internal reference to the definition of a mapping.

Identifies the computable language in which mapping.map is expressed.

If omitted, then there can be no expectation of computational interpretation of the mapping.

Expresses what part of the target specification corresponds to this element.

For most mappings, the syntax is undefined. Syntax will be provided for mappings to the RIM. Multiple mappings may be possible and may include constraints on other resource elements that identify when a particular mapping applies.

Comments that provide information about the mapping or its use.