Many elements in the FHIR resources have a coded value, of which one of the more common types is the codeableConcept. (The other two are the code and the coding datatypes – which we’ll meet shortly). Coded data allows for precision of data collection, more accurate reporting, and lays the foundation for Decision Support and so is very important in the recording of healthcare information.
(I’m going to preface this discussion by stating that coding clinical data is a complex topic, and this post does not go into all the details of coding data – it is intended to make sure that you have a basic understanding of how to use this datatype in FHIR. There are lots of links where you can go to get more information if you need it.)
In the words of the specification: “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”. It’s actually quite well described in the specification (as most things are, in truth), but I thought I’d write a short note about it – mostly because I said I would at the end of the last post – but also because it’s so commonly used in FHIR that’s it’s worth being familiar with it.
Examples of where you might use it include:
and there are lots of other situations as well – apart from a string it’s probably the most commonly used datatype in FHIR (I should write a short program to check that – perhaps I’ll leave it as ‘an exercise for the reader’!)
If you look at the definition of the codeableConcept, you will see that is actually a combination datatype:
- a text property of type string
- 0 or more coding properties of type coding
Evidently the coding datatype does most of the work. This structure allows you to capture the clinical information that is being coded (ie the description in plain text) as well as multiple representations of that text in the coding system of choice.
Confused? Well, imagine that the clinician entered “atopic asthma” and you wanted to represent that in a problem list. You might want to code that as “Allergic Asthma” in snomed (389145006) and “Extrinsic asthma – unspecified” in ICD-9 (493.00). The codeableConcept allows you to have both of these codes, plus the original text entered by the clinician, and upon which the encoding was performed.
The coding datatype is the actual representation of the code in the coding system of choice. It has the following properties – all of them optional.
So, lets create a rendering of the asthma example given above, assuming that we are placing this in a condition resource in the code property:
<code>
<!-- SNOMED code -->
<coding>
<system value="http://snomed.info/id"/>
<version value="International Release – 20130731"/>
<code value="389145006"/>
<display value="Allergic Asthma"/>
<primary value="true"/>
</coding>
<!-- ICD code -->
<coding>
<system value="urn:oid:2.16.840.1.113883.6.42"/>
<version value="9"/>
<code value="493.00"/>
<display value="Extrinsic asthma - unspecified"/>
<primary value="false"/>
</coding>
<text value="Atopic Asthma"/>
</code>
From this we can tell that the clinician entered ‘atopic asthma’ but accepted the SNOMED code of allergic asthma.
When a terminology or codeset is associated with a particular resource property, this is called a binding. Each resource description in FHIR displays the bindings that are defined for that resource immediately below the description of the resource content. Each binding has the following properties:
- Path. The resource property that is being bound.
- Definition. Describes the binding.
- Type. The ‘strength’ of the bindings. Options are:
- Fixed means that there is a specific set of values defined in the spec than cannot be extended. Usually this is for ‘code’ datatypes (see below)
- Incomplete means there is a recommended set of values but can be extended by implementers
- Example – it is really up to each implementation to decide
- Unknown – not yet decided
- Reference. A link to the terminology or codeset.
Some other things to note:
- In theory a resource could have a property with a datatype of coding – in practice this is not often done (if at all). The codeableConcept is far more flexible than coding – for example, it would support a property that *can* be coded, but for some reason is not in this specific instance – such a patient problem/condition where the problem description has been captured, but not yet formally coded.
- There is also a code datatype that many resources employ. Generally this is used for ‘workflow’ type purposes, and the codeset from which it is drawn is defined – and fixed – by the designers of the resource. The mode property of the List resource is an example of this – it is important that any user of a List resource should be able to correctly interpret this property on any list, with clinical safety issues if not.
- The equivalent to the codeableConcept in v3 (or CDA) is the CD – Concept Descriptor – datatype. CD is more complex than codeableConcept, though the extra functionality it offers (such as translations) are not often needed in practice (which is why it was simplified in FHIR). Should you find that you need to do so, then the FHIR extension mechanism can be applied to datatypes as well as resources.
So, enjoy the codeableConcept!
Recent Comments