Using DigiDOT Dental BodyStructure

Purpose

Use DigiDOT Dental BodyStructure to record patient-specific dental anatomy referenced by a Condition, Observation or Procedure.

This is a restricted FHIR R4 representation. It derives directly from the core R4 BodyStructure resource and uses the standard R5 includedStructure element backported to R4 as an extension. The information shape uses the EHDS BodyStructure logical model as a design starting point: anatomical structure, laterality and qualifiers are separate but remain grouped together. Direct derivation from core R4 avoids depending on an externally hosted base profile that Simplifier may be unable to resolve.

This is EHDS-inspired and HL7 Europe-based, not a claim of formal EHDS conformance. The current EHDS artefact is a technology-independent logical model published as a continuous build, while the HL7 Europe R4 profile is trial-use. DigiDOT deliberately adds stricter dental rules and requires a coded structure; unlike the broader HL7 Europe profile, it does not support a laterality-only record with an absent structure.

Clinical resource relationship

Use one populated bodySite for each tooth or oral structure. Each populated bodySite contains exactly one standard BodyStructure Reference extension:

"bodySite": [
  {
    "extension": [
      {
        "url": "http://hl7.org/fhir/StructureDefinition/bodySite",
        "valueReference": {
          "reference": "BodyStructure/procedure-123-site-1"
        }
      }
    ]
  }
]

bodySite is optional because not every clinical record has specific anatomy in the source. When anatomy is known, the source shall populate it. The extension has cardinality 1..1 inside each populated bodySite. No other bodySite extension, direct coding or text is permitted.

Procedure and Condition repeat bodySite and reference one BodyStructure per tooth or oral structure. Observation has one bodySite; use separate Observations when separate site-specific results apply to several structures. Do not put several anatomical structures in one BodyStructure.

The BodyStructure shall:

  • have its own FHIR identity and be stored separately, not as a contained resource;
  • reference the same patient as the clinical resource's subject;
  • contain exactly one includedStructure for one tooth or other oral structure;
  • keep each surface and laterality value inside that includedStructure.

Why Simplifier shows several levels

The levels are part of the standard R4 representation, not separate clinical concepts:

  • bodySite → extension → valueReference is the standard FHIR BodyStructure Reference extension;
  • includedStructure → structure/laterality/qualifier is the R5 BodyStructure element backported to R4 by the official cross-version extension package.

Implementers work with one clinical bodySite reference and one small BodyStructure. The nested extension, url and value[x] rows are FHIR's technical extension format and should not be exposed in the clinical user interface.

Simplifier must include and restore the dependency hl7.fhir.uv.xver-r5.r4#0.1.0. Without it, Simplifier reports the includedStructure canonical as unresolved. The canonical intentionally starts with http://; it is a stable FHIR identifier and must not be changed to https://.

Why a reference is used

The reference is intentional rather than a DigiDOT-specific workaround. The FHIR R4 bodySite elements used here are CodeableConcept; repeated coding values are alternate representations of the same concept, not separate semantic parts such as tooth, surface and laterality. Putting a tooth code and surface codes side by side in bodySite.coding would therefore lose the relationship between them and misuse the datatype.

A local complex extension could place tooth, surfaces and laterality directly inside bodySite, but every supplier would then have to implement a DigiDOT-only anatomy model. The standard BodyStructure Reference extension is already defined for Procedure.bodySite, Condition.bodySite and R4/R4B Observation.bodySite, and HL7 Europe uses it in its R4 Procedure profile. The separate BodyStructure gives one governed place to keep the anatomical structure and its qualifiers together and provides a migration path to later FHIR anatomy models.

The trade-off is one additional resource and reference. DigiDOT limits that complexity by requiring exactly one extension and one referenced structure per populated bodySite. A server may create and resolve these resources transparently; the clinical user interface does not need to expose the reference mechanics.

One tooth with surfaces

Use structure for the tooth and repeat qualifier for its surfaces:

{
  "resourceType": "BodyStructure",
  "id": "procedure-123-anatomy",
  "meta": {
    "profile": [
      "https://novari.no/fhir/digidot/StructureDefinition/digidot-DentalBodyStructure-no"
    ]
  },
  "extension": [
    {
      "url": "http://hl7.org/fhir/5.0/StructureDefinition/extension-BodyStructure.includedStructure",
      "extension": [
        {
          "url": "structure",
          "valueCodeableConcept": {
            "coding": [
              {
                "system": "http://snomed.info/sct",
                "version": "http://snomed.info/sct/51000202101/version/20260715",
                "code": "...",
                "display": "Tooth 26"
              }
            ]
          }
        },
        {
          "url": "qualifier",
          "valueCodeableConcept": {
            "coding": [
              {
                "system": "http://snomed.info/sct",
                "version": "http://snomed.info/sct/51000202101/version/20260715",
                "code": "...",
                "display": "Mesial surface"
              }
            ]
          }
        }
      ]
    }
  ],
  "patient": {
    "reference": "Patient/patient-1"
  }
}

Use one qualifier repetition per surface. A surface is allowed only when structure identifies a tooth. For several teeth, create one BodyStructure per tooth. Procedure and Condition repeat bodySite; Observation uses separate resources for separate site-specific results. Do not place surfaces in a common list outside their tooth.

Oral structure with laterality

Use laterality only when all of these conditions are met:

  • the structure is a member of 723264001 |Lateralisable body structure reference set| in the selected SNOMED CT release;
  • side is clinically relevant and is known in the source;
  • the structure concept does not already encode left or right;
  • the structure is not a numbered tooth.

The permitted values are left and right from the DigiDOT BodyStructure Laterality ValueSet. If both sides apply, create separate left and right BodyStructure resources. If side is unknown, omit laterality. Membership of the structures-permitting-laterality ValueSet is release-specific and shall be checked against the SNOMED CT release stated in Coding.version.

The larger Structures Permitting Laterality ValueSet is not presented to users as a laterality choice. It only checks whether the selected anatomical structure may be qualified with left or right. For example, a left parotid gland is represented by the side-neutral parotid-gland structure plus left:

"extension": [
  {
    "url": "structure",
    "valueCodeableConcept": {
      "coding": [
        {
          "system": "http://snomed.info/sct",
          "version": "http://snomed.info/sct/51000202101/version/20260715",
          "code": "45289007",
          "display": "Parotid gland structure"
        }
      ]
    }
  },
  {
    "url": "laterality",
    "valueCodeableConcept": {
      "coding": [
        {
          "system": "http://snomed.info/sct",
          "version": "http://snomed.info/sct/51000202101/version/20260715",
          "code": "7771000",
          "display": "Left"
        }
      ]
    }
  }
]

Do not add laterality to a numbered tooth, a midline/unpaired structure such as the mandible as a whole, or a concept that already states left or right. Omit laterality when the source does not know the side.

The profile contains terminology-dependent warning constraints so implementers can see these rules in profile tooling. The authoritative check is performed by the terminology-aware ingestion validator. This distinction is necessary because a portable FHIR validator cannot distinguish an invalid refset membership from a SNOMED CT expansion that is unavailable to that validator.

Coding rules

Part Cardinality Rule
includedStructure 1..1 Exactly one tooth or oral structure in each Dental BodyStructure.
structure 1..1 per included structure Exactly one direct, numeric and versioned SNOMED CT coding. Use the DigiDOT Teeth ValueSet for a tooth.
laterality 0..1 per included structure Left or right. The structure must be in the SNOMED CT structures-permitting-laterality reference set. Use separate BodyStructure resources for both sides. Do not use laterality for a numbered tooth or a structure that already states side.
qualifier 0..* per included structure One direct and versioned SNOMED CT tooth-surface code per repetition.

system, version and code are required in each coding. version identifies the published SNOMED CT edition release, and all codings in one Dental BodyStructure use the same release. Free text may supplement the codes but must not replace or contradict them.

Scope boundaries

  • Findings such as caries and lesions belong in Condition or Observation, not BodyStructure.morphology.
  • Images belong in the agreed imaging resources, not BodyStructure.image.
  • BodyStructure.location and locationQualifier are not used because includedStructure is the single structured anatomy representation.
  • A real SCTpost expression may repeat anatomy when it adds semantic precision, but it must remain consistent with the referenced BodyStructure.
  • Condition, Observation and Procedure use the same referenced BodyStructure model.

Consistency with SCTpost

FHIR profile validation checks the resource shape, cardinalities, reference target and release declarations. With a suitable terminology service it can also evaluate bindings and refset membership. It cannot by itself prove that a SNOMED CT compositional-grammar expression in a clinical resource has the same anatomy as a separate BodyStructure. DigiDOT therefore requires a terminology-aware ingestion step when Condition, Observation or Procedure references Dental BodyStructure.

The ingestion validator shall:

  1. Resolve the BodyStructure and verify that BodyStructure.patient equals the referencing resource's subject.
  2. Validate SCTpre, every structure, surface and laterality code, and SCTpost against the exact SNOMED CT edition release.
  3. When laterality exists, validate the structure against the lateralizable-body-structure reference set. When a surface exists, validate the associated structure against the DigiDOT Teeth ValueSet.
  4. Build an anatomy-projection expression from the primary code and referenced BodyStructures using terminology-approved SNOMED CT templates for the relevant finding, observable entity or procedure. Keep each structure and its surfaces together. Represent laterality on the structure itself, for example (<structure> : 272741003 |Laterality| = <side>). Select the applicable attribute from the MRCM for the focus concept.
  5. Validate both the anatomy projection and a real SCTpost expression with CodeSystem/$validate-code so syntax and MRCM rules are checked.
  6. Compare the anatomy projection with SCTpost using CodeSystem/$subsumes.

For step 6, call $subsumes with the anatomy projection as codeA and SCTpost as codeB:

Outcome DigiDOT interpretation
equivalent The structured and postcoordinated anatomy are semantically equivalent. Accept.
subsumes SCTpost contains the required anatomy and additional precision. Accept only after confirming that additional anatomical sites do not conflict with or exceed the BodyStructure record.
subsumed-by SCTpost is less specific and does not contain all structured anatomy. Reject or return for correction.
not-subsumed The representations differ or contradict each other. Reject or return for correction.

$subsumes proves that the required projected meaning is present; by itself it does not prove that every additional refinement is non-anatomical. The validator must therefore also inspect the normalized/classifiable expression or otherwise compare the procedure-site refinements before accepting a subsumes result. The anatomy-projection and extraction rules must be agreed with the SNOMED CT terminology work. A simple text search inside the expression is not sufficient.

This is an ingestion/API conformance rule rather than one FHIRPath invariant. It crosses resources and depends on SNOMED CT compositional grammar, MRCM and subsumption. The DigiDOT SnowstormX service exposes the required FHIR terminology operations, but the dental projection templates and the handling of additional anatomical refinements must be approved before this becomes a fully automated acceptance test.

When SCTpost repeats SCTpre, the same semantic comparison still applies. It passes only when the precoordinated concept already entails the BodyStructure anatomy. Otherwise the source must provide a valid postcoordinated expression containing the anatomy.

Examples

Design references