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 an open FHIR core with selected prohibitions. It defines the minimum DigiDOT content 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
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 Use the DigiDOT tooth and surface slices. 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.
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
identifier Permitted Retains the source EHR business identifier for traceability, de-duplication and idempotent import. It is not the FHIR server id. A later inbound-exchange rule should require a stable system and value where the source has an identifier.
basedOn, reasonReference, encounter, performer, location Permitted and documented These are the main links between plan, clinical reason, contact, responsible actor and place. Where a DigiDOT or no-basis target profile exists, the reference is constrained to that profile; external source data must be mapped before it is stored as a canonical DigiDOT Procedure. The links remain optional where imported historical data lacks the information.
performed[x] Permitted and documented Supports a date or period for new records, while allowing less structured timing only for imported history.
report, note Permitted and documented report links a direct report or document. note 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.
focalDevice.manipulated Permitted Identifies a concrete device affected by the procedure.
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 0..0 Product, material, medication-product and non-focal-device traceability are outside the current Procedure scope until a national model is agreed.
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.
code.extension, bodySite.extension, focalDevice.extension, focalDevice.modifierExtension 0..0 These structured elements already have agreed representations for procedure meaning, anatomy 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 or no-basis Procedure Parent procedure when an overall procedure is clinically useful.
encounter DigiDOT Encounter Contact in which the action occurred.
recorder, asserter no-basis Patient, Practitioner or PractitionerRole Person or role that recorded or asserted the procedure.
performer.actor no-basis Practitioner, PractitionerRole or Organization Responsible clinician, role or organisation.
performer.onBehalfOf no-basis Organization Organisation on whose behalf the action was performed.
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.
report Standard FHIR DiagnosticReport, DocumentReference or Composition Direct report or document. It remains unconstrained by profile until a DigiDOT report profile is defined.

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 code, bodySite and focalDevice, where they could create an unmanaged second representation of clinical meaning, anatomy 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 traceability is needed for a later exchange scope. If so, define the resource types, identifiers, provenance, lifecycle and relationship to SNOMED CT before reopening usedReference.
  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. Validate the decisions with representative EHR data and dental users before marking the profile Draft complete.

References