A TerminologyCapabilities resource documents a set of capabilities (behaviors) of a FHIR Terminology Server that may be used as a statement of actual server functionality or a statement of required or desired server implementation.

An absolute URI that is used to identify this terminology capabilities 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 an authoritative instance of this terminology capabilities is (or will be) published. This URL can be the target of a canonical reference. It SHALL remain the same when the terminology capabilities is stored on different servers.

Allows the terminology capabilities 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 determination of when to create a new version of a resource (same url, new version) vs. defining a new artifact is up to the author. Considerations for making this decision are found in Technical and Business Versions.

In some cases, the resource can no longer be found at the stated url, but the url itself cannot change. Implementations can use the meta.source element to indicate where the current master source of the resource can be found.

A formal identifier that is used to identify this terminology capabilities 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 terminology capabilities outside of FHIR, where it is not possible to use the logical URI.

The identifier that is used to identify this version of the terminology capabilities when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the terminology capabilities 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 terminology capabilities 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 terminology capabilities with the format [url]|[version]. The version SHOULD NOT contain a '#' - see Business Version.

A natural language name identifying the terminology capabilities. 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 terminology capabilities.

This name does not need to be machine-processing friendly and may contain punctuation, white-space, etc.

The status of this terminology capabilities. Enables tracking the life-cycle of the content.

Allows filtering of terminology capabilitiess that are appropriate for use versus not.This is not intended for use with actual capability statements, but where capability statements are used to describe possible or desired systems.

A Boolean value to indicate that this terminology capabilities 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 terminology capabilities.

Allows filtering of terminology capabilitiess that are appropriate for use versus not.

The date (and optionally time) when the terminology capabilities 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 terminology capabilities changes.

Note that this is not the same as the resource last-modified-date, since the resource may be a secondary representation of the terminology capabilities. 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 responsible for the release and ongoing maintenance of the terminology capabilities.

Helps establish the "authority/credibility" of the terminology capabilities. May also allow for contact.

Usually an organization but may be an individual. The publisher (or steward) of the terminology capabilities is the organization or individual primarily responsible for the maintenance and upkeep of the terminology capabilities. 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 terminology capabilities. 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 terminology capabilities from a consumer's perspective. Typically, this is used when the capability statement describes a desired rather than an actual solution, for example as a formal expression of requirements as part of an RFP.

This description can be used to capture details such as comments about misuse, instructions for clinical use and interpretation, literature references, examples from the paper world, etc. It is not a rendering of the terminology capabilities 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 terminology capabilities is presumed to be the predominant language in the place the terminology capabilities was created).This does not need to be populated if the description is adequately implied by the software or implementation details.

The content was developed with a focus and intent of supporting the contexts that are listed. These contexts may be general categories (gender, age, ...) or may be references to specific programs (insurance plans, studies, ...) and may be used to assist with indexing and searching for appropriate terminology capabilities 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 terminology capabilities is intended to be used.

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

Explanation of why this terminology capabilities is needed and why it has been designed as it has.

This element does not describe the usage of the terminology capabilities. 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 terminology capabilities.

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

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

The way that this statement is intended to be used, to describe an actual running instance of software, a particular product (kind, not instance of software) or a class of implementation (e.g. a desired purchase).

Allow searching the 3 modes.

Software that is covered by this terminology capability statement. It is used when the statement describes the capabilities of a particular software version, independent of an installation.

Name the software is known by.

The version identifier for the software covered by this statement.

If possible, a version should be specified, as statements are likely to be different for different versions of software.

Identifies a specific implementation instance that is described by the terminology capability statement - i.e. a particular installation, rather than the capabilities of a software program.

Information about the specific installation that this terminology capability statement relates to.

An absolute base URL for the implementation.

Whether the server supports lockedDate.

Identifies a code system that is supported by the server. If there is a no code system URL, then this declares the general assumptions a client can make about support for any CodeSystem resource.

The code system - identified by its system URL - may also be declared explicitly as a Code System Resource at /CodeSystem, but it might not be.

Canonical identifier for the code system, represented as a URI.

For the code system, a list of versions that are supported by the server.

Language translations might not be available for all codes.

For version-less code systems, there should be a single version with no identifier.

If this is the default version for this code system.

If the compositional grammar defined by the code system is supported.

Language Displays supported.

Filter Properties supported.

Code of the property supported.

Operations supported for the property.

Properties supported for $lookup.

The extent of the content of the code system (the concepts and codes it defines) are represented in this resource instance.

True if subsumption is supported for this version of the code system.

Information about the ValueSet/$expand operation.

Whether the server can return nested value sets.

Whether the server supports paging on expansion.

True if requests for incomplete expansions are allowed.

Supported expansion parameter.

Name of the supported expansion parameter.

Description of support for parameter.

Documentation about text searching works.

This documentation should cover things like case sensitivity, use of punctuation if not ignored, what wild cards are supported (if any), whether text is starts with or contains, and whether word order matters.

The degree to which the server supports the code search parameter on ValueSet, if it is supported.

See notes on the ValueSet resource.

Information about the ValueSet/$validate-code operation.

Whether translations are validated.

Information about the ConceptMap/$translate operation.

Whether the client must identify the map.

Whether the $closure operation is supported.

If cross-system closure is supported.