eRS-Specialty-CodeSystem-1

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]{datatypes.html#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 refrence to a particular business version of the code system with the format [url]|[version].

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.

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 system that are appropriate for use vs. not. This is labeled as "Is Modifier" because applications should not use an experimental code system in production.

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

Explaination 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.

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 must be able to determine any legal restrictions on the use of the code system and/or its content.

Systems are not required to have markdown support, and there is considerable variation in markdown syntax, so the text should be readable without markdown processing. The preferred markdown syntax is described here: http://daringfireball.net/projects/markdown/syntax (and tests here: http://daringfireball.net/projects/downloads/MarkdownTest_1.0.zip) Sometimes, the copyright differs between the code system and the codes that are included. The copyright statement should clearly differentiate between these when required. Sometimes, the copyright differs between the code system and the codes that are included. The copyright statement should clearly differentiate between these when required. 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.

The meaning of the hierarchy of concepts.

Note that FHIR strings may not exceed 1MB in size

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'.

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.

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.

Note that FHIR strings may not exceed 1MB in size

The language this designation is defined for.

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