Start here

This page is the entry point for the DigiDOT FHIR R4 package for the Norwegian public dental service. It supports model review, supplier dialogue and validation of the proposed FHIR modelling choices.

DigiDOT describes how public dental services can represent planning, recall, appointment/contact, clinical registrations, relevant external patient context and preliminary finance/reimbursement in FHIR. It is not a production conformance statement yet.

The current resource series is digidot-*. The older pilot-digidot-* resources are retained only for comparison with an earlier modelling iteration.

The main modelling principle is reuse first:

  • use no-basis for Norwegian administrative resources such as patient, clinician, role, organization, location and appointment
  • use SFM for medication information instead of creating separate DigiDOT medication profiles
  • use no-basis-AllergyIntolerance and source-specific FHIR resources for allergies, critical information, relevant medical history, patient summaries, consent, alerts, documents and imaging metadata
  • keep external source data source-aware and cache it as FHIR context only where it is needed for local workflows, search, display or decision support
  • create DigiDOT profiles only where dental care needs scoped constraints, terminology, examples or clearer relationships

The selection rules for national base-profile reuse, including the Appointment decision, are described in Using Norwegian base profiles.

The DigiDOT canonical base, naming pattern, Simplifier claim procedure and release rules are described in Canonical URL governance.

The core flow is:

Patient -> external context -> plan/recall -> appointment -> contact -> clinical registrations -> device/material -> finance

In FHIR terms this means:

  • ServiceRequest represents planned/requested dental work.
  • ServiceRequest.supportingInfo links planned care to selected decision context such as allergy, critical information, medication, medical history, documents, imaging and patient summary content.
  • ServiceRequest with category=dental-recall represents the next recall need or due window.
  • Appointment represents proposed or booked scheduling.
  • Encounter represents the actual dental contact.
  • Condition, Observation and Procedure represent the clinical content.
  • Device, Substance and SFM resources represent implants/materials and medication context by reuse and reference.
  • ChargeItem and draft Claim keep financial information separate from clinical procedure coding.
  • CapabilityStatement and $digidot-context describe a draft way to retrieve relevant patient-opening context.

Visual profile overview

Simplifier renders guide pages as Markdown/Text, so this page avoids inline HTML/SVG. Visual diagrams are rendered from PlantUML resources, and direct navigation is provided through the reference tables.

Area Main profiles/resources Main purpose
Patient and person no-basis-Patient, no-basis-Person Common subject/patient anchor.
Plan, episode and recall DigiDOT EpisodeOfCare, DigiDOT ServiceRequest Planning, recall needs and requested dental work. Recall is a ServiceRequest with category=dental-recall.
Appointment and contact no-basis-Appointment, DigiDOT Encounter Appointment is scheduling. Encounter is the completed contact.
Clinical data DigiDOT Condition, DigiDOT Observation, DigiDOT Procedure Findings, measurements and performed/planned procedures.
External patient context no-basis-AllergyIntolerance, Flag, Consent, QuestionnaireResponse, Composition, DocumentReference, DiagnosticReport, ImagingStudy Source-aware context from national/external services that may affect dental treatment.
Medication SFM List, SFM MedicationStatement, SFM Medication Reuse SFM medication information instead of creating a separate DigiDOT medication profile.
Finance DigiDOT ChargeItem, DigiDOT Claim Fee item and preliminary reimbursement/settlement model.
API/context DigiDOT CapabilityStatement, $digidot-context Draft capability and patient-opening context operation.

Profile references

The references below are the main resources used by the DigiDOT package. The diagrams show the logical flow; these lists provide the clickable navigation.

Patient / person

Main use: common subject/patient anchor for plan, recall, contact, clinical registrations, device, charge and claim.

External patient context

Main use: patient safety and decision context that should be shown when a patient is opened or when dental treatment is planned. External data should keep source, freshness and provenance. DigiDOT should not become the master for Persontjenesten, HPR, SFM, Kjernejournal or image archives.

  • no-basis-AllergyIntolerance
  • Condition for relevant external medical history
  • Flag for alerts that point to underlying clinical/safety information
  • Consent for relevant restrictions or critical information context
  • QuestionnaireResponse for structured patient-reported history
  • Composition for Helse-NIM/patient-summary style views
  • DocumentReference, DiagnosticReport and ImagingStudy for documents, reports and image metadata
  • Provenance and audit logging for fetched, transformed or cached source data

Actors and place

Main use: encounter participant/location/provider, ServiceRequest requester/performer/location, Procedure performer/location, Claim provider/facility.

Plan, episode and recall

Main use: ServiceRequest subject/reason/bodySite/supportingInfo. Recall uses category dental-recall and native occurrenceTiming.repeat for 12-month recall.

Appointment

Main use: DigiDOT currently reuses no-basis-Appointment directly. Appointment.basedOn points to the planned ServiceRequest, Appointment.supportingInformation can reference the episode, and participants identify the patient, optional practitioner and location. Encounter.appointment points to the appointment when the scheduled event results in an actual contact. See Using Norwegian base profiles for the reuse decision and criteria for a future DigiDOT child profile.

Contact

Main use: Encounter subject/basedOn/appointment/episodeOfCare/participant/location/serviceProvider and an optional health group extension. The current health group ValueSet contains only a test code and needs governance before wider use.

Clinical registrations

Main use: Condition, Observation and Procedure subject points to Patient and encounter points to Encounter. Observation.basedOn and Procedure.basedOn can point to ServiceRequest. Procedure.reasonReference points to Condition; Condition.evidence.detail can point to the Observation that supports it.

Coding and anatomy

Main use: SCTpre and SCTpost use Coding helper profiles. Condition and Procedure use refset-based SNOMED CT ValueSets as extensible starting points, while Observation uses its observation-codes ValueSet. Condition, Observation, Procedure and ServiceRequest use the same tooth and surface slices on bodySite.coding, with required bindings to the Teeth and Tooth surfaces ValueSets. A bodySite may contain multiple teeth only when no surface is specified. A bodySite with one or more surfaces must contain exactly one tooth; use one bodySite per tooth when surfaces are recorded for more than one tooth. The active Condition, Observation and Procedure drafts use bodySite as their only anatomical representation.

Terminology

Main use: supporting ValueSets. Terminology governance and SNOMED CT validation remain subject to formal agreement.

Device, substance and SFM

Main use: optional, identifiable device context. Use Procedure.focalDevice.manipulated for an implant, prosthesis or appliance affected by a procedure, and optional Procedure.usedReference for a concrete device used during a procedure when the source records it and its identity is clinically or traceability-relevant. SFM resources remain relevant for medication history; materials and medication products are not linked through Procedure.usedReference in the current Procedure scope.

Finance

Main use: ChargeItem subject/context/service. Claim patient/provider/facility/procedure/item.encounter. There is no direct Claim-to-ChargeItem reference in the current model.

Detailed profile map

The profile map below shows relationships between DigiDOT profiles, no-basis reuse, SFM reuse, external source-aware context, summary resources, imaging/report references and terminology resources.

Profile and ValueSet map

The map below shows the active DigiDOT profiles, the ValueSets they bind to, reused no-basis/SFM/FHIR resources, and legacy comparison artifacts kept in the package.

Example view

The example view below shows the recall-to-treatment path at instance level. It is meant as a readable supplement to the JSON Bundle.

Example association maps

The diagrams below explain concrete example bundles. They are rendered from PlantUML for Simplifier compatibility. Use the table links for direct navigation to the example resources.

Example What it shows
Recall examination with findings Recall need, booked appointment, completed contact, DMFT observation, caries finding, new treatment plan and next recall.
Emergency contact and treatment Patient-initiated emergency contact with finding, patient-reported observation, treatment plan, performed procedure and charge line.
External critical context Allergy/critical information, alert, consent, questionnaire history, device context and provenance linked to a planned dental service.
Helse-NIM patient summary context Patient-summary style view combining dental and external clinical context with allergies, medication, conditions, procedures and devices.
Imaging context Dental imaging metadata using ImagingStudy, DocumentReference, DiagnosticReport, Observation and Provenance.
Financial association ChargeItem fee lines and draft Claim without a direct Claim-to-ChargeItem reference.

Recall examination with findings

Emergency contact and treatment

SFM medication association

Financial association

Profile mindmap

Recall and invitation workflow

Financial workflow

Notes

  • Green boxes are DigiDOT profiles or DigiDOT-specific elements.
  • Blue boxes are reused no-basis profiles.
  • Purple boxes are reused SFM resources.
  • Yellow boxes are terminology/value sets.
  • Orange boxes are draft or unresolved areas.
  • Grey boxes are native FHIR/base resources without a DigiDOT profile.