Validation review - DigiDOT Procedure

Purpose

This page records the current draft decisions and the remaining validation questions for DigiDOT Procedure. It is intended to support clinical, terminology and EHR review. It is not a final approval or production-conformance statement.

Current draft decisions

Area Current decision
Resource Use FHIR R4 Procedure for a clinical action performed, attempted, stopped, put on hold or documented as not done within public dental-service care.
Core context subject and status are required. identifier, code, SCTpre, SCTpost, encounter, basedOn, partOf, reasonReference, performed[x], performer.actor and bodySite are MustSupport. If a source has faithful information for an optional MustSupport element, it shall populate it.
Core references References use the named DigiDOT or no-basis target profile only. performer.actor is a concrete no-basis Practitioner; Procedure does not use PractitionerRole, Organization or unprofiled reports as substitutes.
Clinical code One precoordinated SNOMED CT concept (SCTpre) is required in Procedure.code.
Extra precision One optional postcoordinated SNOMED CT expression (SCTpost) may add valid semantic precision. It supplements the precoordinated concept and must not contradict Procedure.status or bodySite.
Anatomy Procedure.bodySite is the only anatomical representation. It uses the DigiDOT tooth and tooth-surface slices. A surface requires exactly one tooth in the same bodySite; use one bodySite per tooth when surfaces are recorded for several teeth.
Extensions Root extension and modifierExtension, plus extensions on category, code, bodySite, performer and focalDevice, are 0..0. No Procedure extension is in scope.
Source identity identifier is MustSupport. A stable source identifier with system and value shall be supplied when the source has one.
Status reason, reason, outcome, complication and follow-up statusReason, reasonCode, outcome, complication and followUp are 0..0 because the current draft has no agreed DigiDOT terminology for them. Use Procedure.status, references to Condition, ServiceRequest and Appointment instead.
Duplicate material coding usedCode and focalDevice.action are 0..0. The clinical action is represented once in Procedure.code and optional SCTpost.
Materials and products usedCode remains 0..0. Product, material and medication-product traceability require a separate agreed model.
Procedure device context Optional focalDevice.manipulated identifies a device affected by the procedure. Optional usedReference identifies a separate, concrete DigiDOT Device used during the procedure when the source records it and the identity is clinically or traceability-relevant.
Performer and reports performer.function, performer.onBehalfOf and report are 0..0. Use a named Practitioner for the performer; retain organisation and source context through Encounter, Location and Provenance.
Complications complication is 0..0. A clinically significant complication may be represented as a DigiDOT Condition linked through optional complicationDetail.

Terminology binding

When Procedure.category is populated, it has a required binding to the one-code DigiDOT Procedure Category ValueSet and uses dental-procedure as the interoperable marker. It does not replace the clinical SNOMED CT code.

Procedure.code and SCTpre use an extensible binding to the DigiDOT Dental Procedure ValueSet. The ValueSet resolves the version-locked Norwegian dental-care core-list procedure reference set:

598061000202101 | Norwegian dental care core list of procedures simple reference set |

An extensible binding does not provide a technical fallback search. It means that a refset concept must be used when it covers the intended meaning. A SNOMED CT concept outside the refset is permitted only when no applicable refset concept covers the clinical meaning.

Do not add a broad SNOMED CT hierarchy as an implicit second choice in this ValueSet. If a wider list is needed for clinical selection, create a separate ValueSet after the terminology review has agreed its SNOMED CT hierarchy, release/version policy and relationship to reporting.

An EHR user interface may present the core refset first and then offer terminology-server search in an agreed broader selection ValueSet. That is a user-interface decision; it does not change the conformance meaning of the Procedure ValueSet binding.

SCTpost is not bound to the refset. Its compositional grammar, concept validity and semantic coherence must be validated against the agreed Snowstorm terminology service and SNOMED CT edition/version.

Scope boundary

Use DigiDOT Procedure for procedures recorded as part of public dental-service care. It is not a general profile for imported procedure history from another care provider. Preserve external history in its source-aware resource and provenance unless DigiDOT makes its own clinical procedure assertion.

A supporting action performed within dental care can use this profile when the dental workflow, responsible performer and terminology are agreed. A separate profile is needed only when that procedure class has a different responsibility, mandatory context or terminology policy.

Validation questions

  1. Clinical scope: Confirm which supporting procedures, if any, belong in the public dental-service procedure record.
  2. Terminology: Validate the reference-set membership and the SCTpost expressions in Snowstorm using the agreed Norwegian SNOMED CT release.
  3. EHR mapping: Test source identifiers, procedure status, timing, performer, plan/staged-procedure links, reason, anatomy and notes against representative dental-journal data.
  4. Devices and materials: Confirm whether national storage needs product-level material or medication-product traceability in a later scope. Confirm the use of focalDevice.manipulated and usedReference with the DigiDOT Device profile.
  5. Cross-resource handling: Verify the intended links to ServiceRequest, Condition, Encounter, Device and external source/provenance records.

Technical evidence recorded

  • The Procedure snapshot has been regenerated from the current differential.
  • All JSON artefacts in the current Simplifier project parse locally.
  • The complete Line Danser transaction declares the expected DigiDOT and no-basis target profiles for its Procedure references. The focused implant example includes a no-basis Patient and a DigiDOT Device.
  • Firely Terminal can regenerate the snapshot from the current differential. Full package-context validation must be run in Forge/Simplifier after synchronization.
  • Local terminology validation cannot expand the Norwegian SNOMED CT refsets. Terminology conformance must therefore be checked against the agreed Snowstorm service.

References