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 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: Appointment.basedOn points to ServiceRequest, including recall requests with category=dental-recall. Appointment.participant.actor points to Patient and optional actor/location.

Contact

Main use: Encounter subject/basedOn/appointment/episodeOfCare/participant/location/serviceProvider and health group extension.

Clinical registrations

Main use: Condition/Observation/Procedure subject points to Patient and encounter points to Encounter. Procedure.basedOn points to ServiceRequest. Procedure.reasonReference points to Condition.

Coding and anatomy

Main use: SCTpre and SCTpost use Coding helper profiles. Tooth and surface are named slices on bodySite.coding with required bindings to the Teeth and Tooth surfaces ValueSets. Tooth may repeat when no surface is specified. Surface requires exactly one tooth in the same bodySite.

Terminology

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

Device, substance and SFM

Main use: Device.patient/owner/location. Procedure.focalDevice and Procedure.usedReference. SFM list points to MedicationStatement, which points to the Medication product. Procedure.usedReference points to SFM Medication/Magistrell-Medication, not MedicationStatement.

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.
SFM medication association SFM medication list, MedicationStatement and Medication product reused in a DigiDOT treatment context.
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.