The CodeSystem resource is used to declare the existence of and describe a code system or code system supplement and its key properties, and optionally define a part or all of its content.

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

Allows the code system 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 code system 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 code system outside of FHIR, where it is not possible to use the logical URI. Note that HL7 defines at least three identifiers for many of its code systems - the FHIR canonical URL, the OID and the V2 Table 0396 mnemonic code.

The identifier that is used to identify this version of the code system when it is referenced in a specification, model, design or instance. This is an arbitrary value managed by the code system 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. This is used in Coding.version.

There may be different code system 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 code system with the format [url]|[version].

A natural language name identifying the code system. 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 code system.

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

The date (and optionally time) when the code system resource was created or revised.

Allows filtering of code systems that are appropriate for use versus not.

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

Allows filtering of code systems that are appropriate for use versus not.

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

Note that this is not the same as the resource last-modified-date, since the resource may be a secondary representation of the code system. 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 code system.

Helps establish the "authority/credibility" of the code system. May also allow for contact.

Usually an organization but may be an individual. The publisher (or steward) of the code system is the organization or individual primarily responsible for the maintenance and upkeep of the code system. 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 code system. 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 code system from a consumer's perspective.

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 code system instances.

Assist in searching for appropriate content.

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

Explanation of why this code system is needed and why it has been designed as it has.

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

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

... Sometimes, the copyright differs between the code system and the codes that are included. The copyright statement should clearly differentiate between these when required.

The code system defines a compositional (post-coordination) grammar.

大多数编码系统偶尔会在新版本中改进概念显示的名称。有些验证过概念显示名称的上下文可能要求为某些编码系统指定版本，这种情况而不使用此元素。

Many concept definition systems support multiple representations, in multiple languages, and for multiple purposes.

Concepts have both a display and an array of designation. The display is equivalent to a special designation with an implied designation.use of "primary code" and a language equal to the Resource Language.

In the absence of a language, the resource language applies.

If no use is provided, the designation can be assumed to be suitable for general display to a human user.

The text value for this designation.

A property value for this concept.

The value of this property.