Using DigiDOT Procedure

Purpose

Use DigiDOT Procedure to record a dental action that has been performed, started, stopped, put on hold or documented as not done.

Lifecycle and care context

Use status for the lifecycle of the concrete procedure and performedDateTime or performedPeriod for when an action was performed or attempted. A not-done or entered-in-error procedure may omit performed[x] when no action occurred or a reliable time is unavailable. Link a clinically significant reason through reasonReference to a Condition; appointment or request lifecycle belongs in Appointment or ServiceRequest.

Link the procedure to the relevant context when known:

• subject identifies the patient.
• encounter identifies the contact where the action occurred.
• basedOn points to the DigiDOT ServiceRequest that planned or requested the work.
• reasonReference points to the DigiDOT Condition that clinically justified it.
• performer.actor identifies the individual clinician responsible for the action.
• location identifies a procedure-specific place only when the linked Encounter does not already represent it sufficiently.
• complicationDetail points to a separate DigiDOT Condition when a clinically significant complication was caused by the procedure.

Where a relevant DigiDOT or no-basis profile exists, the reference must resolve to that agreed profile. report remains a standard FHIR reference until DigiDOT defines a report profile. Map external source data to the agreed target profile before storing a canonical DigiDOT Procedure.

For treatment across several contacts, record one visit-level Procedure for each concrete action, each linked to its Encounter and to the same ServiceRequest. Use partOf only when an overall parent Procedure is clinically useful in addition to those visit-level records.

Source population and MustSupport

For this profile, an optional element marked MustSupport is optional in an individual Procedure, but the implementation must support it. If the source EHR has information that maps faithfully to a permitted optional MustSupport element, it shall populate that element. If the information is not known, not relevant or cannot be mapped without changing its meaning, omit it and record a mapping gap where needed; do not invent data.

The Central Storage Solution must accept, preserve and return supported data. Consumers must process it without error. MustSupport does not make an optional element mandatory and cannot by itself prove that a source system omitted information it held.

Clinical coding

Procedure.category is optional. When included, it always contains the canonical DigiDOT dental-procedure marker for consistent searching, sorting, display and comparison across systems. Procedure.code records the clinical procedure. Include one required precoordinated SNOMED CT concept (SCTpre) and add one optional postcoordinated SNOMED CT expression (SCTpost) when it adds clinically relevant precision. SCTpost can include SNOMED CT Procedure context for semantic retrieval; when present, it must be consistent with status. Both codings identify the published SNOMED CT edition release used. The Dental procedures ValueSet is an extensible refset-based starting point. The Procedure category ValueSet is not a clinical procedure terminology.

"code": {
  "coding": [
    {
      "system": "http://snomed.info/sct",
      "version": "http://snomed.info/sct/51000202101/version/20260715",
      "code": "234789004",
      "display": "Insertion of composite restoration into tooth"
    },
    {
      "system": "http://snomed.info/sct",
      "version": "http://snomed.info/sct/51000202101/version/20260715",
      "code": "234789004 : 363704007 = 36492000"
    }
  ]
}

Tooth and surface anatomy

Use Procedure.bodySite for tooth and surface context. A bodySite can contain zero or more tooth codings when no surface is recorded. When one or more surface codings are present, that same bodySite must contain exactly one tooth coding. Use one bodySite per tooth for surfaces on more than one tooth.

Devices and materials

Use optional focalDevice.manipulated for a patient-specific device that is implanted, removed or manipulated by the procedure, such as an implant, prosthesis or orthodontic appliance. Populate it only when the source records such a Device and the relationship maps faithfully. The clinical action belongs in Procedure.code and, where useful, SCTpost; focalDevice.action is not used.

Use optional usedReference only for a concrete DigiDOT Device that was used during the procedure and is clinically or traceability-relevant, such as a source-recorded imaging or treatment device. Do not create a Device resource for ordinary equipment that the source does not identify, and do not repeat a generic device type already represented in Procedure.code or SCTpost.

The current draft does not model material or medication-product traceability in Procedure. usedCode is not used. A future revision may add a documented model for materials and medication products when the relevant terminology, identifiers, provenance and lifecycle rules are agreed. Tariff, fee and reimbursement information belongs in the financial resources, not in Procedure.code.

performer.function, performer.onBehalfOf and report are not used in the current draft. Performer identity is represented once by performer.actor; organisation context belongs in Encounter, Location and Provenance. Reports remain separate resources until DigiDOT defines a specific report profile and linking policy.

See Procedure storage scope and element use for the complete element decisions, including extensions and the relation to SNOMED CT postcoordination.

See Procedure validation review for the current validation scope, terminology decisions and remaining review questions.

Examples

• Temporary filling with postcoordinated coding
• Staged treatment lifecycle
• Stopped procedure and replanning

See FHIR R4, R5 and R6 considerations for future-version mapping notes.