Clinical coding
This page explains how Condition, Observation, Procedure and ServiceRequest use SNOMED CT in their clinical code fields. For teeth, surfaces and the relationship between a code and bodySite, continue to Dental anatomy.
Choose a concept or an expression
A precoordinated concept is one SNOMED CT concept whose defined meaning already covers the intended detail. A postcoordinated expression combines a focus concept and refinements using SNOMED CT compositional grammar. It is one coded meaning, not a list of unrelated codes. See SNOMED CT expressions.
| Clinical meaning | Coding choice |
|---|---|
| Dental caries with no more specific anatomy recorded | A suitable single caries concept can be enough. |
| Caries on the occlusal surface of tooth 46 | The complete code must also express the tooth and surface: use a sufficiently specific concept or a valid refinement. |
Do not discard known detail to make a broad concept appear sufficient. The name SCTextended does not mean that every code must be postcoordinated.
Read a postcoordinated expression
The caries finding in the recall-to-treatment scenario has this SCTextended.code:
| Part | How to read it in this example |
|---|---|
80967001 |
The focus concept: dental caries. |
: and {363698007=...} |
A refinement begins; the grouped attribute is finding site. |
866005003 |
Tooth 46, in the first Finding site group; matches bodySite.location. |
83473006 |
Occlusal surface, in the second Finding site group; matches bodySite.locationQualifier. |
The whole string is one expression in one Coding.code. Its structure helps a reader see the intended meaning; correct SNOMED grammar, allowed attributes, concept activity and clinical equivalence still need terminology validation. See the SNOMED expression syntax guide. Dental anatomy shows the same tooth and surface in bodySite.
How to read the two coding slices
The four profiles slice code.coding by the literal Coding.id, not by the SNOMED concept identifier in Coding.code:
Coding.id |
Cardinality when code is present |
Role |
|---|---|---|
SCTextended |
1..1 | The complete intended meaning: one sufficiently specific concept or a valid postcoordinated expression. |
SCTpre |
0..1 | An optional, compatible single-concept companion. It cannot replace a more precise SCTextended coding. |
Both codings use system = http://snomed.info/sct and identify the same SNOMED CT edition and release in version. If SCTpre is broader, it must not be mistaken for the full detail in SCTextended. The recall-to-treatment scenario uses only SCTextended for its caries finding; an SCTpre companion is not mandatory.
code is required in Condition, Observation and Procedure. ServiceRequest can omit it for a general recall identified by category and timing; when code is present, the two-slice pattern applies. See ServiceRequest use.
Similar detail, different clinical meaning
The case uses postcoordination in four kinds of record. The focus concept and the attribute describing a site depend on what the record means:
| Profile and case record | Read the expression as | Keep outside code |
|---|---|---|
| Condition: caries | A finding at tooth 46, occlusal surface | Clinical and verification status. |
| Observation: pocket depth | The assessment at tooth 25, distopalatal root surface | The result, 4 mm, in valueQuantity. |
| Procedure: restoration | An action performed at tooth 46, occlusal surface | Procedure status and time. |
| ServiceRequest: restoration request | A planned situation containing that intended action and site | Request status, intent and timing. |
The same tooth and surface appear in three different statements in this case:
This is a reading aid, not SNOMED expression syntax. Do not copy one record's code to another just because the anatomy matches. In the request, 363589002=(234789004:{...}) nests the intended restoration's coded meaning inside the planned Situation; it is not a FHIR reference to a performed Procedure. The separate Procedure record describes what was actually done. Likewise, the Observation expression identifies a pocket-depth assessment at tooth 25; its 4 mm result belongs in valueQuantity, outside the expression. Use each profile's binding and coding rules.
Exact `SCTextended.code` values in the case
Condition — caries finding:
Observation — pocket depth at tooth 25:
Procedure — composite restoration at tooth 46:
ServiceRequest — planned composite restoration at tooth 46:
These are the example Bundle's stored codes, not general templates. Their full MRCM, template, normal-form and clinical-equivalence validation has not been established; see Examples on Simplifier. Use the selected SNOMED edition and the relevant profile before generating another expression.
Validate the meaning and return a normal form
For postcoordinated expressions, the intended integration flow is:
- Build the close-to-user expression from the clinical choice and record its SNOMED CT edition and release.
- Validate the FHIR resource against the selected DigiDOT profile, including
Coding.idslices and the applicable ValueSet binding. - Send the expression to a SNOMED CT terminology service with postcoordination support, such as a suitably configured Snowstorm deployment. Check compositional grammar, active concepts in the stated release, MRCM rules and any applicable clinical template.
- Return the validated close-to-user expression and its necessary normal form. Put the close-to-user expression in
SCTextended.code; use the normal form for semantic comparison and queries, together with the release used to produce it. Report explicitly if the service cannot produce a normal form.
The necessary normal form is an inferred representation and can differ from what the clinician entered. Do not silently replace the close-to-user meaning with it. SNOMED expression forms explain the distinction. Snowstorm capabilities depend on the deployed product and configuration; SnowstormX postcoordination support is one documented implementation, not a guarantee for every endpoint.
The SCTextended profile checks only a basic code shape; a successful FHIR validation or expression parse cannot establish full clinical equivalence. The Dental anatomy page shows how to compare an expression's anatomical meaning with bodySite. The Examples on Simplifier page states which terminology checks remain open for the sample data.