Condition storage scope and element use
Central-storage contract
DigiDOT Condition stores a clinically significant dental finding, diagnosis, problem or condition as one searchable FHIR R4 resource.
The resource stores the accepted source content. The profile defines the minimum interoperable meaning and closes fields that would otherwise create ungoverned duplicate coding or reference models. MustSupport means systems must be able to populate, accept, preserve and return the element; it does not make optional elements mandatory when the source does not know them.
Allowed information
| Element | Central-storage use |
|---|---|
| identifier | Source business identifier for traceability, de-duplication and idempotent import. When a source has a stable identifier, include both its system and value. |
| clinicalStatus | Authoritative lifecycle state for a real condition. It is absent only when verificationStatus is entered-in-error. |
| verificationStatus | Confirmation state for a finding or diagnosis. Preserve it when the source distinguishes confirmed, provisional, differential, refuted or entered-in-error records. |
| category | Optional canonical dental-finding marker for cross-system comparison. It does not carry the clinical diagnosis. |
| code | One required precoordinated SNOMED CT finding/diagnosis and one optional postcoordinated SNOMED CT expression. |
| bodySite | Structured precoordinated SNOMED CT dental anatomy, including the selected SNOMED CT edition release. Tooth and surface use the DigiDOT ValueSets; other relevant dental body structures use SNOMED CT. |
| subject | Required no-basis Patient. |
| encounter | Optional DigiDOT Encounter where the condition was recorded. Populate it when known by the source. |
| onset[x], abatement[x], recordedDate | Preserve known clinical onset, abatement and recording dates without inventing precision. |
| recorder, asserter | Named no-basis Practitioner who recorded the condition, and named no-basis Practitioner or Patient who clinically asserted it. |
| evidence.detail | One or more DigiDOT Observations that explicitly support the condition. |
| note | Clinical narrative that has no structured equivalent. |
Terminology and anatomy
- The Dental conditions ValueSet is an extensible binding to the version-locked Norwegian dental findings and disorders refset. Use a refset concept when it covers the clinical meaning. A broader SNOMED CT concept is allowed only when the refset does not cover that meaning.
- SCTpost is not a fallback list. It is an optional, valid SNOMED CT expression that adds material precision to SCTpre.
- The named
toothandsurfaceslices conform to DigiDOT Coding - SNOMED CT Precoordinated. Any other open bodySite coding follows the same direct SNOMED CT system, edition-release and numeric-code rule. - clinicalStatus and verificationStatus remain authoritative FHIR status fields. A postcoordinated expression must not contradict them.
- A bodySite may contain several teeth only when it has no surface. A surface requires exactly one tooth in the same bodySite. Use a separate bodySite for each tooth when surfaces are recorded for several teeth.
- bodySite is the only Condition anatomy representation in the current R4 draft. The profile has no BodyStructure extension.
Explicit references
| Element | Permitted target | Purpose |
|---|---|---|
| subject | no-basis Patient | Patient with the condition. |
| encounter | DigiDOT Encounter | Dental contact where it was recorded. |
| recorder | no-basis Practitioner | Practitioner who entered or transferred the record. |
| asserter | no-basis Practitioner or no-basis Patient | Practitioner or patient responsible for the assertion. |
| evidence.detail | DigiDOT Observation | Observation that explicitly supports the condition. |
Generic base-resource targets are not permitted by the profile. External data must be mapped to these agreed representations before it becomes a canonical DigiDOT Condition in Central Storage.
Fields closed in the current draft
| Element | Reason |
|---|---|
| implicitRules, contained | The central store needs independently identifiable and searchable resources that follow the published DigiDOT rules. |
| Root extension and modifierExtension | No named and governed Condition extension is in scope. |
| Extensions on category, code and bodySite | Prevent unmanaged parallel meaning for the category marker, clinical code or anatomical context. |
| severity | No governed dental severity terminology or mapping is agreed. Use validated postcoordination when it carries the intended precision. |
| stage | No dental staging terminology, assessment model or mapping is agreed. |
| evidence.code | No governed evidence-type terminology is agreed. The supporting Observation is the structured evidence. |
These fields may be reopened only through a documented DigiDOT profile change with a clear clinical use, terminology and EHR mapping rule.
External source responsibility
Where a condition is received from another service, Central Storage retains the source resource, provenance, freshness and update responsibility according to the integration design. This profile is for a dental condition represented in the agreed DigiDOT format; storing a source resource does not automatically turn it into a local dental assertion.
Review questions
- Confirm that the closed severity and stage fields do not remove a current dental-journal use case. Any request to reopen them must include a terminology and mapping proposal.
- Confirm clinical coverage of the Dental conditions ValueSet and the agreed Snowstorm release/version policy.
- Test the source mappings for identifiers, statuses, anatomy, timing, asserter and supporting observations against representative dental EHR data.
- Reassess R4-to-later-FHIR anatomy mapping only when a future target release and patient-specific anatomy use case are agreed.