A definition of a FHIR structure. This resource is used to describe the underlying resources, data types defined in FHIR, and also for describing extensions and constraints on resources and data types.

An absolute URI that is used to identify this structure definition when it is referenced in a specification, model, design or an instance; also called its canonical identifier. This SHOULD be globally unique and SHOULD be a literal address at which this structure definition is (or will be) published.

Allows the structure definition to be referenced by a single globally unique identifier.

Can be a urn:uuid: or a urn:oid: but real http: addresses are preferred. Multiple instances may share the same URL if they have a distinct version.

The URL SHOULD include the major version of the structure definition. For more information see Technical and Business Versions.

A formal identifier that is used to identify this structure definition when it is represented in other formats, or referenced in a specification, model, design or an instance.

Allows externally provided and/or usable business identifiers to be easily associated with the module.

Typically, this is used for identifiers that can go in an HL7 V3 II (instance identifier) data type, and can then identify this structure definition outside of FHIR, where it is not possible to use the logical URI.

The identifier that is used to identify this version of the structure definition when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the structure definition author and is not expected to be globally unique. For example, it might be a timestamp (e.g. yyyymmdd) if a managed version is not available. There is also no expectation that versions can be placed in a lexicographical sequence.

There may be different structure definition instances that have the same identifier but different versions. The version can be appended to the url in a reference to allow a reference to a particular business version of the structure definition with the format [url]|[version].

A natural language name identifying the structure definition. This name should be usable as an identifier for the module by machine processing applications such as code generation.

Support human navigation and code generation.

The name is not expected to be globally unique. The name should be a simple alphanumeric type name to ensure that it is machine-processing friendly.

A short, descriptive, user-friendly title for the structure definition.

This name does not need to be machine-processing friendly and may contain punctuation, white-space, etc. Applications don't have to use this name but can always fall back to it. The title also corresponds to the label for the root element.

The status of this structure definition. Enables tracking the life-cycle of the content.

Allows filtering of structure definitions that are appropriate for use versus not.

A Boolean value to indicate that this structure definition is authored for testing purposes (or education/evaluation/marketing) and is not intended to be used for genuine usage.

Enables experimental content to be developed following the same lifecycle that would be used for a production-level structure definition.

Allows filtering of structure definitions that are appropriate for use versus not.

The date (and optionally time) when the structure definition was published. The date must change when the business version changes and it must change if the status code changes. In addition, it should change when the substantive content of the structure definition changes.

Note that this is not the same as the resource last-modified-date, since the resource may be a secondary representation of the structure definition. Additional specific dates may be added as extensions or be found by consulting Provenances associated with past versions of the resource.

The name of the organization or individual that published the structure definition.

Helps establish the "authority/credibility" of the structure definition. May also allow for contact.

Usually an organization but may be an individual. The publisher (or steward) of the structure definition is the organization or individual primarily responsible for the maintenance and upkeep of the structure definition. This is not necessarily the same individual or organization that developed and initially authored the content. The publisher is the primary point of contact for questions or issues with the structure definition. This item SHOULD be populated unless the information is available from context.

Contact details to assist a user in finding and communicating with the publisher.

May be a web site, an email address, a telephone number, etc.

A free text natural language description of the structure definition from a consumer's perspective.

This description can be used to capture details such as why the structure definition was built, comments about misuse, instructions for clinical use and interpretation, literature references, examples from the paper world, etc. It is not a rendering of the structure definition as conveyed in the 'text' field of the resource itself. This item SHOULD be populated unless the information is available from context (e.g. the language of the profile is presumed to be the predominant language in the place the profile was created).

The 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 for appropriate structure definition instances.

Assist in searching for appropriate content.

When multiple useContexts are specified, there is no expectation that all or any of the contexts apply.

A legal or geographic region in which the structure definition is intended to be used.

It may be possible for the structure definition to be used in jurisdictions other than those for which it was originally designed or intended.

Explanation of why this structure definition is needed and why it has been designed as it has.

This element does not describe the usage of the structure definition. Instead, it provides traceability of ''why'' the resource is either needed or ''why'' it is defined as it is. This may be used to point to source materials or specifications that drove the structure of this structure definition.

A copyright statement relating to the structure definition and/or its contents. Copyright statements are generally legal restrictions on the use and publishing of the structure definition.

Consumers must be able to determine any legal restrictions on the use of the structure definition and/or its content.

A set of key words or terms from external terminologies that may be used to assist with indexing and searching of templates.

Assist in searching for appropriate StructureDefinitions.

The version of the FHIR specification on which this StructureDefinition is based - this is the formal version of the specification, without the revision number, e.g. [publication].[major].[minor], which is 3.3.0 for this version.

A StructureDefinition does not need to specify the target it applies to as StructureDefinitions will often be valid across multiple versions of FHIR. FHIR tooling can determine whether a StructureDefinition is consistent with a particular StructureDefinition if desired.

An external specification that the content is mapped to.

An Internal id that is used to identify this mapping set when specific mappings are made.

The specification is described once, with general comments, and then specific mappings are made that reference this declaration.

An absolute URI that identifies the specification that this mapping is expressed to.

A formal identity for the specification being mapped to helps with identifying maps consistently.

A name for the specification that is being mapped to.

Comments about this mapping, including version notes, issues, scope limitations, and other important notes for usage.

Defines the kind of structure that this definition is describing.

Whether structure this definition describes is abstract or not - that is, whether the structure is not intended to be instantiated. For Resources and Data types, abstract types will never be exchanged between systems.

Abstract Resources cannot be instantiated - a concrete sub-type must be used. Abstract datatypes and extensions cannot be used in an instance. For logical models, the exact implication of "abstract" will rest with the author, depending how the logical model is used. Flagging a constraint structure as abstract conveys design intent but makes no difference to how the structure definition is handled. Note that inline declared elements that are given the type "Element" in the profile, but have children described, are anonymous concrete types that specialize Element.

Identifies the types of resource or data type elements to which the extension can be applied.

Defines how to interpret the expression that defines what the context of the extension is.

An expression that defines where an extension can be used in resources.

A set of rules as FHIRPath Invariants about when the extension can be used (e.g. co-occurrence variants for the extension). All the rules must be true.

The rules are only evaluated when the extension is present. When evaluating the invariant, the FHIRPath focus is the element that holds the extension, and %extension refers to the extension itself.

The type this structure describes. If the derivation kind is 'specialization' then this is the master definition for a type, and there is always one of these (a data type, an extension, a resource, including abstract ones). Otherwise the structure definition is a constraint on the stated type (and in this case, the type cannot be an abstract type). 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.

Note that in the case of constraints, the type could be determined by chasing through the baseDefinition references until a concrete structure (derivation = specialization) is reached, or by looking at the path of the first element in the snapshot - if present - but providing the type directly makes for simpler tooling and indexing.

The type must match the elements defined in the differential and the snapshot. For all FHIR defined types, the path name of the element will start with the type name. For logical models, where the type is a URL, the type name SHOULD start with the tail of the type URL where required.

An absolute URI that is the base structure from which this type is derived, either by specialization or constraint.

If differential constraints are specified in this structure, they are applied to the base in a "differential" fashion. If there is no base, then the differential constraints cannot be provided (snapshot only). Differential structures are useful for the editing perspective, and snapshot structures are suitable for operational use. The FHIR Project provides a number of tools/services to populate snapshots from differential constraints. Logical Models have a base of "Element" or another logical model.

How the type relates to the baseDefinition.

If the definition is a specialization, then it adds new elements in the differential, and the snapshot includes the inherited elements. If the definition is a constraint, then it cannot define new elements, it can only make new rules about existing content (see Profiling Resources).

A snapshot view is expressed in a standalone form that can be used and interpreted without considering the base StructureDefinition.

Captures constraints on each element within the resource.

A differential view is expressed relative to the base StructureDefinition - a statement of differences that it applies.

Captures constraints on each element within the resource.