External data and cache

DigiDOT should not become a duplicate master for national sources. The FHIR server should be authoritative for DigiDOT-owned dental data, while external sources remain authoritative for their own domains.

Source responsibilities

Source Recommended FHIR representation DigiDOT/HAPI role
Persontjenesten/Folkeregisteret no-basis-Patient Minimal cache/identity index
HPR no-basis-Practitioner, no-basis-PractitionerRole Clinician identity and role cache
SFM SFM List, MedicationStatement, Medication Medication context, not a DigiDOT medication profile
Kjernejournal/critical information AllergyIntolerance, Flag, Condition, DeviceUseStatement, Procedure, Consent Patient safety context
Disease history Condition, QuestionnaireResponse, DocumentReference, patient summary mappings Relevant context, not a separate DigiDOT master
Imaging ImagingStudy, DocumentReference, DiagnosticReport Metadata/index; images remain in PACS/DICOMweb/object storage

Patient opening

When a clinician opens a patient, the application should first load local DigiDOT dental history from the FHIR server. External context can then be refreshed synchronously or asynchronously depending on clinical risk and source availability.

Recommended order:

  1. Load local dental history: contacts, findings, observations, procedures, plans, recall and image metadata.
  2. Verify patient identity from the authoritative person source.
  3. Check HPR/role for the signed-in clinician.
  4. Check critical information status if that integration exists.
  5. Fetch active/relevant allergy, critical information, medication context, disease history, patient summary context and image metadata.
  6. Display source, last refreshed time and freshness status for external data.
  7. Store or reference external context when it affects planning or treatment.

FHIR cache rule

External information that is cached, searched, exchanged or used as decision context should be represented as FHIR. It should preserve:

  • external identifier
  • source in meta.source where available
  • profile in meta.profile
  • cache status in meta.tag
  • import/decision trace using Provenance
  • read/access trace using AuditEvent or equivalent audit logging

Do not merge clinical facts from several sources into one local resource unless there is an explicit reconciliation workflow.

ServiceRequest.supportingInfo

ServiceRequest.supportingInfo is the selected place for decision context that directly affects a dental plan. It can reference:

  • EpisodeOfCare
  • no-basis-AllergyIntolerance
  • relevant Condition
  • Flag
  • Consent
  • QuestionnaireResponse
  • SFM List or MedicationStatement
  • DeviceUseStatement
  • relevant Observation
  • DocumentReference
  • DiagnosticReport
  • ImagingStudy
  • Composition

Do not copy the full patient history into every ServiceRequest. Include only the context that affects the request.

Allergy

Use no-basis-AllergyIntolerance. Do not create a DigiDOT allergy profile now. AllergyIntolerance.patient is the main link to the patient. AllergyIntolerance.encounter is only used when the allergy was asserted, updated or refuted in the dental contact. If the allergy affects a planned dental service, reference it from ServiceRequest.supportingInfo.