Procedure storage scope and element use

Purpose

This page records the current scope decisions for DigiDOT Procedure. The profile is designed for a national dental storage model: store a structured clinical procedure once, retain useful source context, and avoid parallel representations of the same meaning.

The current approach is a constrained FHIR core with selected prohibitions. It defines the minimum DigiDOT content, limits references to agreed profiles and closes elements that are unsuitable for the shared storage model or would create an unmanaged duplicate. It does not attempt to close every unused R4 element.

Clinical meaning, identity and SNOMED CT

Information Representation Rule
Interoperable category Procedure.category Optional canonical DigiDOT dental-procedure coding for comparison, searching, sorting and display across systems. When included, it is fixed to this code and is not the clinical procedure code.
Clinical dental action Procedure.code with required SCTpre The precoordinated SNOMED CT concept is the primary clinical procedure code.
Additional clinical precision optional SCTpost Use for valid SNOMED CT compositional grammar, for example anatomy, method or Procedure context. It supplements, never replaces, SCTpre.
Procedure lifecycle Procedure.status This is the authoritative FHIR lifecycle status. Procedure context in SCTpost, when used, must follow the agreed DigiDOT status mapping.
Dental anatomy Procedure.bodySite The tooth and surface slices use the DigiDOT precoordinated SNOMED CT Coding profile. Any other open anatomy coding follows the same direct SNOMED CT system, edition-release and numeric-code rule. SCTpost may repeat the same anatomy only when it adds valid semantic precision; it must not contradict bodySite.
Patient-specific device focalDevice.manipulated Keep the reference when the actual implant, prosthesis or appliance must be identified. A SNOMED CT expression can describe a device type, but cannot identify a particular FHIR Device instance.
Device used during a procedure usedReference Keep the reference only when a concrete DigiDOT Device used during the procedure is recorded in the source and is clinically or traceability-relevant. This is different from a focal device affected by the procedure.
Product or material identity Not in the current Procedure scope A SNOMED CT expression may describe clinical material type when terminology supports it. Product, batch and medication-product traceability require a separate agreed model and are not accepted through Procedure.usedReference in this draft.

Element decisions

Element Current decision Reason
category, category.coding Optional, constrained when present When category is included, exactly one canonical dental-procedure coding makes Procedure instances comparable across systems.
identifier Permitted, MustSupport Retains the source EHR business identifier for traceability, de-duplication and idempotent import. If the source has a stable identifier, it shall include system and value. It is not the FHIR server id.
basedOn, partOf, reasonReference, encounter, performed[x], performer.actor, bodySite Permitted, MustSupport These are the main links between plan, staged procedure, clinical reason, contact, timing, responsible individual and anatomy. If the source has a faithful value, it shall populate the element. The links remain optional where the information is not known, not relevant or cannot be mapped without changing its meaning.
complicationDetail Permitted, optional Use when a clinically significant procedure complication is represented as a separate DigiDOT Condition and the source establishes the relationship.
note Permitted and documented Carries limited narrative that cannot be represented structurally; it must not duplicate structured data.
statusReason 0..0 No agreed DigiDOT terminology exists for a separate status-reason code. status is the lifecycle state; a clinically significant reason is a linked Condition, while appointment or request lifecycle belongs in Appointment or ServiceRequest.
reasonCode 0..0 No agreed DigiDOT terminology exists for a separate coded reason. Use reasonReference to a relevant Condition when a clinically significant finding or diagnosis justifies the procedure.
outcome 0..0 No agreed DigiDOT outcome terminology exists. Lifecycle is represented by status; clinically significant results belong in Condition, Observation or a referenced report.
complication 0..0 No agreed DigiDOT complication terminology exists. A clinically significant complication is recorded once as a Condition and linked through complicationDetail.
followUp 0..0 Planned dental care is represented through ServiceRequest and, when booked, Appointment.
performer.function 0..0 No agreed DigiDOT terminology binding exists for a performer-function code.
performer.onBehalfOf 0..0 Organisation context belongs in Encounter, Location and Provenance. This avoids a second performer representation and an R4/R5 difference.
report 0..0 No DigiDOT report profile and link policy is agreed. Reports remain separate resources until that scope is defined.
focalDevice.manipulated Permitted, optional Identifies a concrete device affected by the procedure when the source represents the Device and the relationship maps faithfully.
focalDevice.action 0..0 The clinical action is represented once in Procedure.code and optional SCTpost. Closing this field avoids a second device-action value that could conflict with the procedure coding.
usedReference Permitted, optional, MustSupport References an identifiable DigiDOT Device used during the procedure only when the source records it and its identity is clinically or traceability-relevant. It does not represent generic equipment categories, consumable materials or medication products.
usedCode 0..0 DigiDOT has no agreed material terminology, ValueSet or mapping rule for a separate coded used-item field.
contained 0..0 Relevant resources must have their own FHIR identity, provenance, version history and searchable references in the central store.
implicitRules 0..0 A Procedure must be interpretable using the published DigiDOT profile, terminology release and agreed exchange documentation, not an undocumented rule set.
modifierExtension 0..0 A modifier extension can change the meaning of a Procedure. No such extension is defined for the current DigiDOT scope.
regular extension 0..0 No Procedure extension is in scope for the current DigiDOT draft. A future extension requires a documented use case, a named and governed definition, and an explicit profile change.
category.extension, code.extension, bodySite.extension, performer.extension, performer.modifierExtension, focalDevice.extension, focalDevice.modifierExtension 0..0 These structured elements already have agreed representations for category, procedure meaning, anatomy, performer identity and focal-device identity. Closing nested extensions prevents ungoverned parallel semantics.

Core reference targets

The core clinical references are constrained to agreed DigiDOT or no-basis profiles. This makes the canonical storage representation predictable while allowing each source system to map its own records before import.

Element Permitted target profile Use
subject no-basis Patient Patient receiving the procedure.
basedOn DigiDOT ServiceRequest Planned or requested procedure.
partOf DigiDOT Procedure Parent procedure when an overall procedure is clinically useful.
encounter DigiDOT Encounter Contact in which the action occurred.
recorder no-basis Practitioner Individual who recorded the clinical statement.
asserter no-basis Patient or Practitioner Individual asserting that the procedure occurred.
performer.actor no-basis Practitioner Individual who performed or was clinically responsible for the procedure.
location no-basis Location Relevant clinic, room or other place.
reasonReference, complicationDetail DigiDOT Condition Clinical reason or separately recorded complication.
focalDevice.manipulated DigiDOT Device Concrete device that was implanted, removed or manipulated.
usedReference DigiDOT Device Concrete device used during the procedure when the source records a clinically or traceability-relevant instance.

Extensions

FHIR extensions are the standard mechanism for additional, published information. No root-level Procedure extension is in scope for the current DigiDOT draft, so regular extensions are prohibited. Extensions are also closed on category, code, bodySite, performer and focalDevice, where they could create an unmanaged second representation of category, clinical meaning, anatomy, performer context or device context. A future extension must first have a documented dental use case, a named and governed definition, and an explicit profile change. This keeps the central storage representation predictable.

Unknown modifier extensions are different: they can alter the meaning of the resource. They are prohibited until DigiDOT defines a named, governed modifier-extension slice and its processing rules.

Discussion points for later validation

  1. Confirm which device data must be retained nationally for implants, prostheses and orthodontic appliances, and complete the related DigiDOT Device review.
  2. Confirm whether product-level material and medication-product traceability is needed for a later exchange scope. If so, define the resource types, identifiers, provenance, lifecycle and relationship to SNOMED CT before opening a separate representation.
  3. Agree and test the mapping between Procedure.status and SNOMED CT Procedure context before requiring Procedure context in every SCTpost expression.
  4. Reconsider patient-specific anatomy only when a concrete dental use case requires a separately identifiable BodyStructure. The R4 target-body-structure extension is not part of the current Procedure profile.
  5. Review any proposed additional extension as a named profile change before it is accepted in an exchange.
  6. Confirm whether the Condition category ValueSet needs an explicit category for procedure complications before the profile is marked Draft complete.
  7. Validate the decisions with representative EHR data and dental users before marking the profile Draft complete.

References