EHDS, EHRxF and national alignment
DigiDOT is a Norwegian dental FHIR model. It is not a full EHDS/EHRxF implementation, but the test profiles are designed so dental information can be used in an EHDS/EHRxF-oriented architecture.
The correct maturity statement is:
DigiDOT is FHIR R4 based, reuses no-basis and SFM, and is prepared for later EHDS/EHRxF mapping. It should not be described as fully EHDS/EHRxF conformant until mapping, access, audit, source/provenance, imaging and export/import requirements have been made explicit.
EHDS/EHRxF priority categories
| EHRxF category | DigiDOT relevance | Current direction |
|---|---|---|
| Patient summaries | Dental conditions, procedures, observations, devices, allergies, medication context, alerts and relevant medical history. | Use a Composition/summary view that assembles DigiDOT and external FHIR resources without making DigiDOT the master for all patient data. |
| Electronic prescriptions | Dental prescribing context, contraindications and medication risk. | Reuse SFM/PLL and reference relevant medication context. Do not create DigiDOT medication profiles. |
| Electronic dispensations | Dispensed medication that affects dental treatment. | Consume from SFM/national medication sources when relevant. |
| Medical imaging studies and reports | Dental X-ray, OPG, CBCT, clinical images and image reports. | Use ImagingStudy, DocumentReference and optionally DiagnosticReport for metadata and reports. Store large images in PACS/VNA/DICOMweb/object storage, not primarily in HAPI. |
| Medical test results and diagnostic reports | Dental measurements, diagnostic observations and grouped reports. | Use DigiDOT Observation for individual dental observations; use DiagnosticReport when observations are reported together. |
| Discharge reports | External hospital/healthcare reports that affect dental care. | Consume as DocumentReference/Composition when relevant. |
Helse-NIM mapping
Helse-NIM for oppsummerende helseopplysninger is especially relevant because it uses Patient Summary and EHDS-oriented thinking. DigiDOT should map to these categories:
| Helse-NIM category | DigiDOT/FHIR direction |
|---|---|
| Tilstander | DigiDOT Condition for dental conditions; external Condition for relevant medical history. |
| Overfolsomhet / allergies | no-basis-AllergyIntolerance or Kjernejournal AllergyIntolerance. |
| Prosedyrehistorikk | DigiDOT Procedure for completed dental procedures; external Procedure where relevant. |
| Medisinsk utstyr | DigiDOT Device; DeviceUseStatement for active patient device/implant context. |
| Behandlingsbegrensninger | External Consent from Kjernejournal/critical information when relevant. |
| Varslinger | Flag for alerts; it does not replace the underlying allergy, condition or consent. |
Modelling guidance
Patientis the main anchor for retrieving patient context, but opening a patient should return more than demographics.Encounteris the completed dental contact. It should not be used as a container for the entire patient history.ServiceRequestis the planning anchor. UsereasonCode/reasonReferencefor why the treatment is planned, andsupportingInfofor relevant decision context such as allergy, SFM medication, critical information or medical history.- External information should remain source-aware. Keep source identifier, source system, last fetched, last changed, cache status and provenance.
- Use
Provenanceand operational audit/logging for external lookups, transformations, exports and clinical decision snapshots.
Recommended next work
- Formalize mapping from DigiDOT resources and examples to EHDS/EHRxF and Helse-NIM categories.
- Decide export/import packaging for patient summary, imaging/report metadata and relevant dental history.
- Define source, provenance, audit and cache freshness rules for external data used in clinical decisions.
- Complete terminology governance and Snowstorm/Snowstorm-X validation.
- Finalize
CapabilityStatementand$digidot-contextbehavior, including security, consent and authorization expectations. - Add KPR TANN mapping from
Encounter,Condition,Observation,Procedure,ChargeItemandClaim. - Keep all promoted artifacts consistently on canonical base
https://novari.no/fhir/digidot.
Sources
- EHDS Regulation: https://eur-lex.europa.eu/eli/reg/2025/327/oj/eng
- EU Commission EHDS overview: https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space-regulation-ehds_en
- EHRxF: https://ehr-exchange-format.eu/what-is-ehrxf/
- Helse-NIM: https://www.helsedirektoratet.no/digitalisering-og-e-helse/e-helsestandarder-og-standardiseringstiltak/plan-for-internasjonale-e-helsestandarder/helse-nim
- Helse-NIM for oppsummerende helseopplysninger: https://www.helsedirektoratet.no/horinger/nasjonal-informasjonsmodell-helse-nim-for-oppsummerende-helseopplysninger
- no-basis: https://simplifier.net/packages/hl7.fhir.no.basis/latest
- SFM Basis: https://utviklerportal.nhn.no/informasjonstjenester/sentral-forskrivningsmodul/sfm-basis-integration/sfm-basis-fhir-implementation-guide-ig
- Kjernejournal critical information API: https://utviklerportal.nhn.no/informasjonstjenester/kjernejournal/kritisk-informasjon/kritisk-info-fhir-api/hit-critical-information/docs/api-methods/status-critical-infomd
- KPR TANN: https://www.fhi.no/he/kpr/tannhelse/