Using DigiDOT Condition (NO)

Purpose

Use DigiDOT Condition for a clinically significant dental finding, diagnosis, problem or condition that should be assessed, tracked, managed or used as a reason for care.

Condition.subject identifies the patient. Use Condition.encounter when the dental contact in which the condition was recorded is known. Condition.clinicalStatus and Condition.verificationStatus describe the FHIR lifecycle and verification state. Condition.code carries the clinical meaning.

Core content and source population

MustSupport does not make an optional element mandatory in every instance. It means that an EHR and Central Storage implementation must be able to populate, accept, preserve and return that element.

If the source has information that maps faithfully to an optional MustSupport element, it shall populate it. If information is unknown, not relevant or cannot be mapped without changing its meaning, it may be omitted. Systems must not invent data.

Element How it is used
identifier Include the stable source business identifier with its assigning system when the source has one. Do not repeat the FHIR server resource id.
clinicalStatus Authoritative lifecycle status. It is present unless verificationStatus is entered-in-error.
verificationStatus Use for confirmed, provisional, differential, refuted or entered-in-error records when the source records that distinction.
category Optional one-code DigiDOT marker for cross-system filtering and comparison. It is never the diagnosis code.
code Required clinical meaning, with one required precoordinated SNOMED CT concept and one optional postcoordinated expression.
bodySite Structured tooth, surface or other dental anatomy. Populate it when the source records specific anatomy.
onset[x], abatement[x], recordedDate Preserve known onset, resolution and recording times without inventing precision.
recorder, asserter Identify the practitioner who recorded the condition and the patient or practitioner who clinically asserted it, when known.
evidence.detail Explicit link to a DigiDOT Observation that supports the condition, only when the source establishes that relationship.
note Limited clinical narrative that has no structured representation.

SNOMED CT coding

Condition.code.coding contains up to two codings:

  1. SCTpre is required. It is the primary, directly usable SNOMED CT concept. Its system is http://snomed.info/sct, its version identifies the SNOMED CT edition release and its code is a numeric SNOMED CT concept identifier.
  2. SCTpost is optional. Use it only when a SNOMED CT compositional-grammar expression adds material clinical precision beyond SCTpre, for example finding site or several relevant surfaces. It never replaces SCTpre.
"code": {
  "coding": [
    {
      "system": "http://snomed.info/sct",
      "version": "http://snomed.info/sct/51000202101/version/20260715",
      "code": "80967001",
      "display": "Dental caries"
    },
    {
      "system": "http://snomed.info/sct",
      "version": "http://snomed.info/sct/51000202101/version/20260715",
      "code": "80967001:{363698007=36492000}{363698007=83473006}",
      "display": "Dental caries in tooth 15, occlusal surface"
    }
  ]
}

Use the Dental conditions ValueSet when it covers the intended finding or diagnosis. Its binding is extensible: a broader SNOMED CT concept remains permitted only when the refset does not cover the intended clinical meaning.

Condition.clinicalStatus and Condition.verificationStatus remain the authoritative FHIR status fields. When an SCTpost expression includes equivalent context, it must not contradict those fields. Expression syntax and semantics are validated by the agreed terminology service.

Tooth and surface anatomy

Condition.bodySite is the structured anatomy representation. The profile uses named tooth and tooth-surface slices on bodySite.coding:

  • A bodySite may contain zero or more teeth when no surface is recorded. This supports findings affecting several teeth.
  • A bodySite with one or more surfaces must contain exactly one tooth.
  • For surfaces on more than one tooth, create one bodySite per tooth.
  • All coded anatomy uses SNOMED CT; a profile invariant requires both the SNOMED CT system and code. Tooth and surface codings use the required Teeth ValueSet and Tooth surfaces ValueSet. Another SNOMED CT body-structure concept may be used for relevant dental anatomy that is neither a tooth nor a tooth surface.

The same anatomy may be represented in an optional SCTpost expression for semantic precision. It must remain consistent with bodySite. Condition has no BodyStructure extension in the current draft.

Category and supporting evidence

Condition.category is optional. When supplied, it contains exactly one canonical coding:

https://novari.no/fhir/digidot/CodeSystem/digidot-condition-category | dental-finding

It supports cross-system searching, sorting, display and comparison. It does not replace the SNOMED CT clinical code.

Use Condition.evidence.detail only to reference one or more DigiDOT Observation resources that support the condition, such as a radiographic assessment. The result remains represented once as an Observation; the Condition carries the explicit clinical relationship.

Profile boundary

Use DigiDOT Observation for an examination observation or measurement. Use DigiDOT Procedure for treatment that has been performed. Allergy and intolerance information uses no-basis-AllergyIntolerance.

For a source assertion retained from another service, preserve source responsibility, provenance and freshness. A source record does not become a local dental assertion merely because it is stored or displayed in the dental context.

Examples and review material

  • example-digidot-condition-dental-caries shows one tooth with several surfaces and an optional postcoordinated expression.
  • example-digidot-condition-multiple-teeth-no-surface shows several teeth with no surface, which is valid.
  • example-digidot-complete-line-danser-transaction shows a resolved caries Condition with a supporting radiographic Observation, planned treatment, completed procedure and follow-up.
  • Condition storage scope and element use explains the central-storage contract.
  • Validation review - DigiDOT Condition records the review questions and draft decisions.