Validation review - DigiDOT Condition

Purpose

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

Current draft decisions

Area Current decision
Resource Use FHIR R4 Condition for clinically significant dental findings, diagnoses, problems and conditions that should be tracked or used as a reason for care.
Lifecycle clinicalStatus is authoritative and must be present unless verificationStatus is entered-in-error. verificationStatus preserves confirmation state when the source has it.
Core context identifier, lifecycle and verification status, clinical code, SCTpre, SCTpost, patient, encounter, timing, recorded date, asserter, body site and explicit observation evidence are MustSupport. If a source has a faithful value for an optional MustSupport element, it shall populate it.
Clinical code One precoordinated SNOMED CT concept (SCTpre) is required in Condition.code.
Extra precision One optional postcoordinated SNOMED CT expression (SCTpost) may add precision. It supplements the precoordinated concept and must not contradict status or bodySite.
Anatomy Condition.bodySite is the structured anatomy representation. A surface requires exactly one tooth in the same body site; several teeth may be recorded when no surface is recorded.
Supporting observations Condition.evidence.detail may reference only DigiDOT Observation. It represents an explicit clinical relationship, not an inferred association.
References Targets are named DigiDOT/no-basis profiles only. Generic base-resource target profiles are not permitted.
Extensions Root extensions and extensions on category, code and bodySite are 0..0. The current Condition profile has no BodyStructure extension.
Unbound fields severity, stage and evidence.code are 0..0 until a governed dental terminology and mapping rule is agreed.

Terminology binding

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

Condition.code and SCTpre have an extensible binding to the DigiDOT Dental Conditions ValueSet. The ValueSet resolves the version-locked Norwegian dental findings and disorders reference set:

598071000202105 | Norwegian dental care core list of findings and disorders simple reference set

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

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 Condition after a clinically significant dental state, finding or diagnosis has been identified. A supporting measurement, image assessment or patient-reported score remains an Observation. A planned treatment remains a ServiceRequest, and a performed or attempted action remains a Procedure.

Relevant external medical history retains its source-aware resource and provenance unless the dental service makes an explicit dental condition assertion.

Validation questions

  1. Clinical scope: confirm the Condition/Observation boundary for radiographic findings, patient-reported symptoms and periodontal or oral-mucosal conditions.
  2. Status: confirm the EHR mapping for clinical status, verification status, entered-in-error corrections and any corresponding postcoordinated context.
  3. Terminology: validate refset coverage and SCTpost expressions in Snowstorm using the agreed Norwegian SNOMED CT release.
  4. EHR mapping: test source identifiers, statuses, anatomy, timing, recorder, asserter and evidence links against representative dental-journal data.
  5. Closed elements: confirm that current workflows do not require ungoverned Condition severity, stage or evidence-type coding.
  6. Cross-resource handling: verify the intended links to Encounter, Observation, ServiceRequest and Procedure in the central storage workflow.

Technical evidence to record

  • The active profile is maintained as a FHIR R4 differential; Forge/Simplifier renders the snapshot from that differential.
  • Focused examples demonstrate one tooth with surfaces, several teeth without surfaces, and a Condition supported by an Observation in the complete test patient transaction.
  • All profile and example JSON must parse successfully before synchronization. Package-context validation must be run in Forge/Simplifier after synchronization.
  • The surface-to-one-tooth rule and the requirement for a SNOMED CT system and code on every bodySite coding are profile invariants. SNOMED CT code and postcoordinated-expression validation must be checked against the agreed terminology service.

References