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.

This is rarely used except for special cases where the representation deviates from the normal, which is done only very reluctantly, and can only be done in the base standard (and profiles must reproduce what the base standard does).

The name of this element definition (to refer to it from other element definitions using ElementDefinition.nameReference). This is a unique name referring to a specific set of constraints applied to this element. One use of this is to provide a name to different slices of the same element.

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

Indicates that the element is sliced into a set of alternative definitions (there are multiple definitions on a single element in the base resource). 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).

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.

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 te 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 definition that is shown in the generated XML format that summarizes profiles (used throughout the specification).

May change the term to provide language more appropriate to the context of the profile or to reflect slicing.

A full formal definition of the meaning of the data element. In human readable language. 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.

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.

Comments about the use of the element, including notes about how to use the data properly, exceptions to proper use, etc.

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

Explains why this element is needed and why it's been constrained as it has.

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.

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 which case the type is inherited from the resource. The type can only be listed in this field if it is an allowed option in the base resource.

Name of Data type or Resource that is a(or the) type used for this element.

If the element is a reference to another resource, this element contains "Reference", and the profile element refers to the profile of the allowed target of the resource, which may be a reference to the general definition of a resource (e.g. http://hl7.org/fhir/Profile/Patient). There would be one pair of type/code for each allowed target resource type.

Identifies a profile structure that SHALL hold for resources or datatypes referenced as the type of this element. Can be a local reference - to another structure in this profile, or a reference to a structure in another profile.

The reference might be a simple name in the form #[name], which is a reference to another named constraint in a resource - where the resource contains more than one constraint, or a URL which is a reference to a resource Profile, with a terminal #[name] which identifies a specific structure entry in the profile.

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

Identifies the name of a slice defined elsewhere in the profile whose constraints should be applied to the current element.

If child components of this element are defined, they act as constraints on the referenced slice.

The value that should be used if there is no value stated in the instance.

Default values can only be specified on a resource, data type, or extension definition, and never in a profile that applies to one of these. 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. For these reasons, default values are (and should be) used extremely sparingly.

The Implicit meaning that is to be understood when this element is missing.

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 it's use in profiles eliminates use cases as possibilities, not merely moving them out of scope.

Specifies a value that SHALL be exactly the value for this element in the instance. For purposes of comparison, non-signficant 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 the value in the instance SHALL follow - that is, any value in the pattern must be found in the instance. Other additional values may be found too. This is effectively constraint by example. The values of elements present in the pattern must match exactly (case-senstive, accent-sensitive, etc.).

Mostly used for fixing values of CodeableConcept.

An example value for this element.

If the example value are fully populated, the publication tool can generate an instance automatically.

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.

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.

Used to label the constraint in OCL or in short displays incapable of displaying the full human description.

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

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

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.

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.

If true, conformant resource authors SHALL be capable of providing a value for the element and resource consumers SHALL be capable of extracting and doing something useful with the data element. If false, the element may be ignored and not supported.

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

"Something useful" is context dependent. This flag is never set to true by the FHIR specification itself - it is only set to true in profiles, and when the profile sets it true, it SHALL describe what it means for applications to support the element. In general, the question is what would a reasonable observer expect of a system that explicitly claims to "support" this element?.

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 to false, it cannot be set to true 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.

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 summarised resources for optimal performance, so servers may not support per-profile use of the isSummary flag.

Binds to a value set if this element is coded (code, Coding, CodeableConcept).

A descriptive name for this - can be useful for generating implementation artifacts.

SHALL be unique within the profile. If the same name as an imported profile, will override the imported binding (and SHALL be a proper constraint on the imported binding).

If true, then conformant systems may use additional codes or (where the data type permits) text alone to convey concepts not covered by the set of codes identified in the binding. If false, then conformant systems are constrained to the provided codes alone.

When the binding use used for elements with a type of "code" (rather than Coding or CodableConcept), the binding is treated as non-extensible regardless of the value of this property.

Indicates the degree of conformance expectations associated with this binding.

Describes the intended use of this particular set of codes.

Points to the value set or external definition that identifies the set of codes to be used.

For value sets,the referenceResource, the display can contain the value set description. The reference may be version-specific or not.

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.

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.