View raw Markdown
type: datatypedatatype: CodeableConcept

CodeableConcept

Overview

See also Examples, Detailed Descriptions, Mappings, Profiles and Extensions

A CodeableConcept represents a value that is usually supplied by providing a reference to one or more terminologies or ontologies but may also be defined by the provision of text. This is a common pattern in healthcare data.

This datatype can be bound to a ValueSet.

[%dt CodeableConcept 3%]

Multiple Codings

When a CodeableConcept contains multiple codings, each coding (sometimes called a 'translation') is a representation of the concept as described above. There is no meaning associated with the ordering of coding within a CodeableConcept and systems should not expect or enforce any particular order. The codes in the codings may have different granularities, whether they are from different code systems, or the same code system.

When multiple codes are present, the intersection of their meanings SHALL NOT be empty. (Strictly, based on ISO 704, the intersection of their 'extensions' is not empty.) This rule cannot, in general, be tested in a computable way and implementers SHOULD choose the granularities used with care, particularly in the context of negation.

For instance, a CodeableConcept containing two codes, the LOINC code 8867-4 (Heart rate) and the SNOMED CT code 364075005 (Heart Rate) is a combination, suitable for use by consuming applications that understand either LOINC or SNOMED CT (or both). On the other hand, a CodeableConcept containing LOINC 9279-1 (Respiratory Rate) and the SNOMED CT code 364075005 (Heart Rate) is not valid because the two concepts do not have any intersection - there's no concept that is both a respiratory rate and a heart rate.

Each coding stands alone in expressing the meaning of the concept. It is not appropriate to send a coding of "severe" with a coding of "rash" to convey the concept represents a "severe rash".

If expressing codes with differing levels of granularity, the granularity chosen must still be appropriate for the definition and purpose of the element. For example, with Observation.code, it would not be appropriate to send a SNOMED CT code of 138875005 (SNOMED CT Concept) - which covers procedures, body parts, and lots of other things that aren't observations. That is, the union of the meanings of the codes (ISO 704 extensions) SHALL not include concepts outside the scope of the definition of the element in which the code is found. Note that this also is not suitable for computable testing. It would also not be appropriate to send a code like SNOMED CT 118227000 (Vital Sign Finding) with a Quantity value because the purpose of Observation.code is to explain the meaning of the Observation.value, and merely knowing that the Quantity is a vital sign isn't enough to have any useful understanding of the meaning of the value.

On the other hand, having one coding that says Body Weight (SCT 27113001) and another that says Post-dialysis body weight (SCT 1162420002) would be fine. Both codes are sufficient to understand what the value means, though one provides more context than the other.

Note that when granularities are significantly different, interpretation of the meaning for each of the codes will result in differences that might not be safe. For instance, a prescription for "APO Amoxicillin 250 mg capsule" (needed to fill the order) could safely also have an additional coding of "Broad-spectrum Penicillin" (perhaps needed to trigger antibiotic monitoring protocols). On the other hand, if there were an order that said "Do not administer APO Amoxicillin 250 mg capsule", adding a translation of "broad-spectrum Penicillin" could be incorrectly interpreted as a prohibition against all broad-spectrum penicillins.

Multiple codings can be present for several reasons:

Typical behavior is to expose all codings known that some portion of the interface clients are likely to have uses for.

Implementers should use codes obtained from the various codings in a CodeableConcept based on thorough analysis of their target applications and real world use cases, noting that the nature of FHIR means resources are often distributed far beyond the original trading partners. For this reason, it is always better to include appropriate codes from well known public CodeSystems whenever possible. This specification and other applicable IGs may make specific rules requiring the presence of particular combinations of codes to make specific uses of FHIR Resources possible and/or safer.

As an example, many qualitative laboratory test results values are typically represented with coded presence/absence concepts. Using the coded value for 'negative' with a standard SNOMED CT code translation, valueCodeableConcept would be:

"valueCodeableConcept": { "coding": [ { "system": "http://snomed.info/sct", "code": "260385009", "display": "Negative" }, { "system": "https://acme.lab/resultcodes", "code": "NEG", "display": "Negative" } ], "text": "Negative for Chlamydia Trachomatis rRNA" }

Note that these concepts may be cross mapped using the ConceptMap resource instead of or in addition to being represented as translations directly in the in CodeableConcept.

Using Text in CodeableConcept

The text is the representation of the concept as entered or chosen by the user, and which most closely represents the intended meaning of the user or concept. Very often the text is the same as a display of one of the codings. One or more of the codings may be flagged as the user selected code - the code or concept that the user actually selected directly. Note that in all but a few cases, only one of the codings may be flagged as the coding.userSelected = true - the code or concept that the user actually selected directly. If more than one code is marked as user selected, this means the user explicitly chose multiple codes. When none of the coding elements is marked as user selected, the text (if present) is the preferred source of meaning. Even if a coding is flagged as user-selected, it is good practice to put the specific text the user chose in CodeableConcept.text.

A free text only representation of the concept without any coding elements is permitted if there is no appropriate code and only free text is available (and not prohibited by the implementation). For example, using text only, the Observation.valueCodeableConcept element would be:

"valueCodeableConcept": {
    "text": "uncoded free text result"
}

Constraints

[%dt.constraints CodeableConcept%]

The context of use usually makes rules about what codes and systems are allowed or required in a particular context by binding the element to a value set.

CodeableConcept is used in the following places: [%dtusage CodeableConcept%]

Elements

Requirements

Comments

Mappings