Dental anatomy
bodySite makes a tooth or oral structure and its qualifiers available as structured data inside a clinical record. The clinical SCTextended code must express the same intended anatomical scope. This page shows the relationship; Clinical coding explains the SNOMED CT slices and validation workflow.
Open Dental BodySite profile on Simplifier ↗
Dental BodySite is a profiled CodeableConcept, not a separate patient resource. Its single body-structure extension holds the anatomical fields.
location, locationQualifier and laterality are MustSupport, although each remains optional. Use the three required bindings when the corresponding field is populated:
| Field | Required ValueSet | Selection guidance |
|---|---|---|
location |
SNOMED CT Body Structures | Select the tooth or other appropriate oral structure. For a numbered tooth, use the Norwegian teeth reference set within this broader hierarchy. |
locationQualifier |
Anatomical Location Qualifier Values | Use an appropriate qualifier value for each surface or region, in the same group as its tooth. |
laterality |
Anatomical Laterality | Use Left or Right only for a structure that can have a side and whose location code does not already specify it. |
The Norwegian tooth-surface reference set supplies body-structure concepts for sites in SNOMED CT clinical expressions. It is not the locationQualifier binding: that field uses qualifier values. Membership in these ValueSets does not by itself establish that a qualifier is suitable for a particular structure or that bodySite and SCTextended express the same anatomy.
One finding, two matching representations
code.coding:SCTextended80967001 |Dental caries| :
{ 363698007 |Finding site| =
866005003 |Structure of permanent mandibular right first molar tooth| }
{ 363698007 |Finding site| =
83473006 |Structure of occlusal surface of tooth| }bodySite
location- Tooth 46 (ISO 3950)SNOMED CT:
866005003
Structure of permanent mandibular right first molar tooth locationQualifier- Occlusal surfaceSNOMED CT:
710098004
Occlusal (qualifier value)
locationSurface ↔ locationQualifierSame colour links the corresponding anatomical meaning. Yellow marks tooth 46 in both representations; blue marks its occlusal surface. The tooth uses the same body structure code in both places. The surface uses a body structure code in the postcoordinated expression and a qualifier value in bodySite; the codes differ while the intended surface agrees.
Labels between |...| make the expression readable; they do not change the concept identifiers. The JSON below uses the compact expression and adds readable display and text values.
The recall-to-treatment scenario contains this finding as a Condition. SCTextended carries its complete coded meaning; bodySite exposes the anatomy separately for uses such as a tooth chart. Generate both from the same source and review both if the site changes.
Expression format and validation
The example uses two separate groups, each containing one Finding site: tooth 46 first, then the occlusal surface. Their display order mirrors location and locationQualifier; changing group order alone does not change the coded meaning. Commas between adjacent groups are optional in SNOMED CT compositional grammar. This format differs from combining concepts with +; the two forms must not be assumed equivalent.
Snowstorm-X CodeSystem/$validate-code accepted this expression against Norwegian release 20260715 on 28 September 2026. This is an illustration pending semantic review: acceptance does not establish an approved dental template, verified normal form or clinical equivalence with bodySite. Separate site groups do not themselves encode which surface belongs to which tooth. That relationship must be confirmed in the terminology/template review, especially for multiple teeth. See example validation scope.
The JSON uses the published edition release required by the current profiles. Snowstorm also accepts http://snomed.info/xsct/11000003104, but that value does not satisfy the current SCTextended.version or Condition anatomy-release constraints.
See example in JSON: SCTextended and matching bodySite
This is a fragment of the Condition in the scenario. Coding.id = SCTextended selects the slice; Coding.code contains the postcoordinated expression. All codings use the same SNOMED CT edition and release. The surface is 83473006 |Structure of occlusal surface of tooth| in the expression and 710098004 |Occlusal| in bodySite. This is a meaning-based correspondence, not code equality. display and text help the reader but do not establish semantic equivalence by themselves.
{
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"version": "http://snomed.info/sct/51000202101/version/20260715",
"code": "80967001:{363698007=866005003}{363698007=83473006}",
"display": "Dental caries on the occlusal surface of tooth 46",
"id": "SCTextended"
}
],
"text": "Dental caries, tooth 46, occlusal surface"
},
"bodySite": [
{
"extension": [
{
"url": "https://novari.no/fhir/digidot/StructureDefinition/digidot-ehds-body-structure",
"extension": [
{
"url": "location",
"valueCodeableConcept": {
"coding": [
{
"system": "http://snomed.info/sct",
"version": "http://snomed.info/sct/51000202101/version/20260715",
"code": "866005003",
"display": "Structure of permanent mandibular right first molar tooth"
}
],
"text": "Tooth 46 (ISO 3950)"
}
},
{
"url": "locationQualifier",
"valueCodeableConcept": {
"coding": [
{
"system": "http://snomed.info/sct",
"version": "http://snomed.info/sct/51000202101/version/20260715",
"code": "710098004",
"display": "Occlusal (qualifier value)"
}
],
"text": "Occlusal surface"
}
}
]
}
]
}
]
}
View the complete example on Simplifier or open the complete scenario for the full Condition with patient, status and contact references.
Keep each tooth with its surfaces
For a record concerning tooth 15 with three surfaces, the tooth is the location. Each surface is a locationQualifier in the same group. A second tooth has its own group; its surfaces must remain attached to that tooth.
The containing resource determines whether anatomy can repeat. Condition, Procedure and ServiceRequest can carry several bodySite groups; Observation has one bodySite and separate site-specific results use separate Observations.
JSON: one tooth with three surfaces
{
"bodySite": [
{
"extension": [
{
"url": "https://novari.no/fhir/digidot/StructureDefinition/digidot-ehds-body-structure",
"extension": [
{
"url": "location",
"valueCodeableConcept": {
"coding": [
{
"system": "http://snomed.info/sct",
"version": "http://snomed.info/sct/51000202101/version/20260715",
"code": "36492000",
"display": "Structure of permanent maxillary right second premolar tooth"
}
],
"text": "Tooth 15 (ISO 3950)"
}
},
{
"url": "locationQualifier",
"valueCodeableConcept": {
"coding": [
{
"system": "http://snomed.info/sct",
"version": "http://snomed.info/sct/51000202101/version/20260715",
"code": "710099007",
"display": "Mesial (qualifier value)"
}
],
"text": "Mesial surface"
}
},
{
"url": "locationQualifier",
"valueCodeableConcept": {
"coding": [
{
"system": "http://snomed.info/sct",
"version": "http://snomed.info/sct/51000202101/version/20260715",
"code": "710098004",
"display": "Occlusal (qualifier value)"
}
],
"text": "Occlusal surface"
}
},
{
"url": "locationQualifier",
"valueCodeableConcept": {
"coding": [
{
"system": "http://snomed.info/sct",
"version": "http://snomed.info/sct/51000202101/version/20260715",
"code": "46053002",
"display": "Distal (qualifier value)"
}
],
"text": "Distal surface"
}
}
]
}
]
}
]
}
This is an anatomical fragment, not a complete clinical record. The recall-to-treatment scenario shows anatomy with its clinical code in complete records.
Representation and meaning
The inline extension can also describe morphology, laterality and a textual description. Open its definition for permitted fields and cardinalities. The nested JSON is deliberate: FHIR R4 permits a complex extension with named child extensions. Here the outer extension keeps one anatomical group together; its children carry the five Xt-EHR fields. The group is an inline value, not a separate BodyStructure resource.
The general datatype permits more than numbered-tooth anatomy. Its structural flexibility does not establish that any combination is clinically suitable or supported by a terminology template. Preserve the source meaning; do not silently drop unsupported qualifiers.
For a posterior tooth, the examples map a vestibular surface to 261062005 |Buccal| in bodySite; the postcoordinated clinical code retains the body-structure site code. The pocket-depth example uses 46053002 |Distal| and 261145003 |Palatal| as qualifiers. Its inline description also says root surface: the current five-field structure has no verified qualifier-value code for that additional detail. The coded bodySite therefore does not capture all of the expression's root-surface precision; this mapping needs terminology review before it is used as a supplier pattern.
When bodySite is present, check that SCTextended covers the same complete anatomical scope. A single sufficiently specific SNOMED concept is enough if it already expresses that meaning; otherwise use a validated postcoordinated expression. For several teeth, keep each tooth with its own qualifiers and check the full coded scope. Clinical coding covers the expression validation and normal-form workflow.
The inline anatomy design remains under review. It draws on the Xt-EHR logical body-structure model; it is not a claim of EHDS or exchange-profile conformance.