A code system resource specifies a set of codes drawn from one or more code systems.

An absolute URL that is used to identify this code system when it is referenced in a specification, model, design or an instance. This SHALL be a URL, SHOULD be globally unique, and SHOULD be an address at which this code system is (or will be) published. The URL SHOULD include the major version of the code system. For more information see Technical and Business Versions. This is used in [Coding]{datatypes.html#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.

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 useable business identifiers to be easily associated with the module.

Typically, this is used for identifiers that can go in an HL7 v3 II data type - e.g. to identify this code system outside of FHIR, where the logical URL is not possible to use.

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 are orderable. This is used in [Coding]{datatypes.html#Coding}.version.

There may be multiple different instances of a code system that have the same identifier but different versions.

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 & code generation.

The name is not expected to be globally unique. The name should be a simple alpha-numeric type name to ensure it is computable friendly.

A short, descriptive, user-friendly title for the code system.

The status of this code system. Enables tracking the life-cycle of the content.

Allows filtering of code system that are appropriate for use vs. not.

A flag 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 life-cycle as a production-level code system would.

Allows filtering of code system that are appropriate for use vs. not.

The name of the individual or organization 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.

The date (and optionally time) when the code system was published. The date must change when the business version changes, if it does, 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.

A free text natural language description of the code system from the consumer's perspective.

This description can be used to capture details such as why the code system 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 module as conveyed in the text field of the resource itself. This item SHOULD be populated unless the information is available from context.

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 of code system definitions.

Assist in searching for appropriate content.

When multiple usageContexts are specified, there is no expectation for whether all or any of the contexts apply.

A jurisdiction in which the code system is intended to be used.

Explains 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 (See, e.g, the comments element, or relatedArtifacts), rather it's for 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.

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

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

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

If code comparison is case sensitive when codes within this system are compared to each other.

If this value is missing, then it is not specified whether a code system is case sensitive or not. When the rule is not known, Postel's law should be followed: produce codes with the correct case, and accept codes in any case. This element is primarily provided to support validation software.

Canonical URL of value set that contains the entire code system.

Thedefinition of the value set SHALL include all codes from this code system, and it SHALL be immutable.

The meaning of the heirarchy of concepts.

True If code system defines a post-composition grammar.

Note that the code system resource does not define what the compositional grammar is, only whether or not there is one.

This flag is used to signify that the code system has not (or does not) maintain the definitions, and a version must be specified when referencing this code system.

Best practice is that code systems do not redefine concepts, or that if concepts are redefined, a new code system definition is created. But this is not always possible, so some code systems may be defined as 'versionNeeded'.

How much of the content of the code system - the concepts and codes it defines - are represented in this resource.

The total number of concepts defined by the code system. Where the code system has a compositional grammar, the count refers to the number of base (primitive) concepts.

The count of concepts defined in this resource cannot be more than this value, but may be less for several reasons - see the content value.

A filter that can be used in a value set compose statement when selecting concepts using a filter.

The code that identifies this filter when it is used in the instance.

A description of how or why the filter is used.

A list of operators that can be used with the filter.

A description of what the value for the filter should be.

A property defines an additional slot through which additional information can be provided about a concept.

A code that is used to identify the property. The code is used internally (in CodeSystem.concept.property.code) and also externally, such as in property filters.

Reference to the formal meaning of the property. One possible source of meaning is the Concept Properties code system.

A description of the property- why it is defined, and how it's value might be used.

The type of the property value. Properties of type "code" contain a code defined by the code system (e.g. a reference to anotherr defined concept).

Concepts that are in the code system. The concept definitions are inherently hierarchical, but the definitions must be consulted to determine what the meaning of the hierarchical relationships are.

If this is empty, it means that the code system resource does not represent the content of the code system.

A code - a text symbol - that uniquely identifies the concept within the code system.

A human readable string that is the recommended default way to present this concept to a user.

The formal definition of the concept. The code system resource does not make formal definitions required, because of the prevalence of legacy systems. However, they are highly recommended, as without them there is no formal meaning associated with the concept.

Additional representations for the concept - other languages, aliases, specialized purposes, used for particular purposes, etc.

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

The language this designation is defined for.

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

A code that details how this designation would be used.

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.

A code that is a reference to CodeSystem.property.code.

The value of this property.

Defines children of a concept to produce a hierarchy of concepts. The nature of the relationships is variable (is-a/contains/categorizes) - see hierarchyMeaning.