German Dental FHIR Profiles (R4)
0.41.6 - trial-use Germany

German Dental FHIR Profiles (R4) - Local Development build (v0.41.6) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Use Cases

Use Cases

This page describes the primary workflows that this Implementation Guide supports. Each use case maps to one or more profiles defined in this IG.

1. PVS Data Migration (SWS 2.0)

Problem: When a dental practice switches PVS (Praxisverwaltungssystem), patient data must be migrated. The KZBV/Gematik Systemwechselschnittstelle 2.0 defines 13 Satzarten for this, but there is no FHIR mapping.

Solution: This IG provides FHIR R4 target profiles for all clinically relevant SWS 2.0 Satzarten:

SWS Satzart Content FHIR Profile
Satzart 5 Zahnschema / Odontogramm DentalFindingDE
Satzart 6 BEMA-Leistungen (GKV) BemaChargeItemDE
Satzart 7 GOZ/GOÄ-Leistungen (PKV) GozChargeItemDE
Satzart 8 HKP / KV DentalCarePlanDE (planType: hkp)
Satzart 9 PAR-Plan DentalCarePlanDE (planType: par)
Satzart 10 KFO-Plan DentalCarePlanDE (planType: kfo)
Satzart 11 ZE / Festzuschüsse DentalCarePlanDE (planType: ze)
Satzart 12 Röntgendiagnostik DentalImagingStudyDE
Satzart 13 Labordaten (BEL II / beb'97) DentalLabServiceRequestDE

See SWS 2.0 Mapping for the complete field-level mapping.

Actors: Source PVS (exporting), Target PVS (importing), optional FHIR server as intermediary.

2. Dental Billing (BEMA/GOZ)

Problem: German dental billing uses two parallel fee schedules — BEMA for GKV (statutory insurance) patients and GOZ for PKV (private insurance) patients. Billing data includes tooth references (FDI), surface codes, Befundklassen, and for GOZ additionally Steigerungsfaktoren with mandatory Begründungen above the threshold (2.3x).

Solution: Two dedicated ChargeItem profiles:

  • BemaChargeItemDE — BEMA billing position with:
    • BEMA code (e.g. 01, 13a, Ä925)
    • Befundklasse (c=conserving, k=KCH, f=filling, e=endo, b=PAR)
    • FDI tooth reference and surface codes
    • Quantity, date, and encounter reference
  • GozChargeItemDE — GOZ billing position with:
    • GOZ code (e.g. 2060, 5000)
    • Steigerungsfaktor (multiplier, with a §2 agreement path above 3.5x)
    • Begründungskategorie and Begründungstext
    • Analogleistung reference (§6 GOZ) for unlisted procedures
    • GOÄ positions for surgical components
  • DentalClaimDE mixed billing — BEMA and GOZ claim lines with typed ChargeItem links, care-type classification, coverage order, and versioned Festzuschuss evidence

Workflow:

  1. Practitioner documents treatment in the PVS
  2. PVS generates ChargeItem resources with billing codes, tooth references, and surfaces
  3. For GKV: ChargeItems are aggregated per quarter and encounter for KZV submission
  4. For PKV: ChargeItems form the basis of the patient invoice with Steigerungsfaktoren

3. Heil- und Kostenplan (HKP)

Problem: Before major dental work (Zahnersatz), the dentist must create an HKP with planned procedures and costs. Since 2022, the E-HKP is submitted digitally to the insurer via the EBZ-Verfahren. The plan includes KZBV Befundkürzel, Therapiekürzel, Festzuschuss calculations, and Eigenanteil estimates.

Solution: The DentalCarePlanDE (planType: hkp) profile models the complete HKP lifecycle:

  • Care alternatives: intent = option represents each not-yet-selected alternative; after selection, the executable care plan uses intent = plan without changing profiles or adding a vendor extension.
  • Befund: Per-tooth findings using KZBV DPF Befundkürzel (e.g. "f" = fehlend, "k" = Krone, "ww" = erhaltenswürdiger Zahn)
  • Therapie: Planned restorations using KZBV Therapiekürzel (e.g. "K" = Krone, "B" = Brückenglied, "TV" = Teleskop-Versorgung)
  • Festzuschüsse: Calculated insurance contributions based on Befund-Therapie combinations
  • Benefit level: 60% standard, 70% after the five-year evidence period, or 75% after the ten-year evidence period
  • Genehmigungsstatus: eingereicht / in-pruefung / genehmigt / abgelehnt

Workflow:

  1. Dentist documents Befund (clinical findings) per tooth
  2. ZMV (dental office manager) creates one or more alternatives with intent = option
  3. The selected alternative becomes the executable intent = plan
  4. E-HKP is submitted digitally to the insurer via EBZ
  5. Insurer returns approval/rejection (ClaimResponse)
  6. After approval, treatment can begin

4. PAR-Behandlungsplan (Parodontologie)

Problem: Since the PAR-Richtlinie reform (July 2021), parodontal treatment requires a structured PAR-Status with documented pocket depths, BOP (Bleeding on Probing), and furcation involvement. The treatment plan covers antiinfektive Therapie, chirurgische Therapie, and UPT (Unterstützende Parodontitistherapie) over up to 2 years.

Solution: The DentalCarePlanDE (planType: par) profile covers:

  • PAR-Status: Pocket depths (6 measurements per tooth), BOP, furcation grades (I-III)
  • PAR-Grading: Stadium (I-IV) and Grad (A/B/C) per current classification
  • Treatment phases: Mundhygienesitzung, subgingivale Instrumentierung, chirurgische Therapie, UPT
  • Approval workflow: Status submission to insurer with structured clinical data

5. KFO-Behandlungsplan (Kieferorthopädie)

Problem: Orthodontic treatment in Germany requires KIG (Kieferorthopädische Indikationsgruppen) classification for GKV coverage approval. Treatment spans multiple years with distinct phases (aktive Behandlung, Retention).

Solution: The DentalCarePlanDE (planType: kfo) profile models:

  • KIG classification: Points 1-5 (GKV covers only KIG 3-5)
  • Angle classification: Class I, II/1, II/2, III
  • Treatment phases: Diagnostik, aktive Behandlung (Multiband/Aligner), Retention
  • Apparatus types: Festsitzend (Brackets), herausnehmbar (Platten), Aligner, Retainer
  • Duration and cost planning across multiple treatment years

6. ZE-Versorgung (Zahnersatz)

Problem: Zahnersatz (dental prosthetics) in Germany follows a unique Festzuschuss system where the insurer pays a fixed subsidy per Befund regardless of the chosen therapy. The Regelversorgung defines the standard treatment; patients may choose gleichartige or andersartige Versorgung with private co-payment.

Solution: The DentalCarePlanDE (planType: ze) profile covers:

  • Befundkürzel: Standardized KZBV codes for the clinical finding per tooth
  • Therapiekürzel: Planned restoration type per tooth
  • Versorgungsart: Regelversorgung / gleichartig / andersartig
  • Festzuschuss-Berechnung: Based on Befund-Therapie-Zuordnung (FZ tables)
  • Bonus: Percentage uplift based on documented Vorsorge history

7. Dental Imaging and Lab Orders

Problem: Dental imaging (OPG, Einzelzahnaufnahmen, DVT) and lab work (Kronen, Brücken, Prothesen) require structured data exchange between practice, lab, and insurer. Internationally, no FHIR standard exists for clinical dental lab orders — existing standards (VDDS Laborschnittstelle, eLABZ) cover only billing data, while clinical information (shade, material, preparation type) is still communicated via free-text or paper.

Solution:

  • DentalImagingStudyDE — Dental radiograph metadata with modality (OPG/intraoral/DVT), tooth region (FDI), and findings reference
  • DentalLabServiceRequestDE — Complete lab order combining:
    • Administrative: BEL II / beb'97 billing positions (via ChargeItem), lab and patient references
    • Clinical: Restoration type, tooth shade (VITA Classical), material specification, preparation form, occlusion concept, implant/abutment details, antagonist situation
    • Digital assets: References to intraoral scans (STL), photos, bite registrations via supportingInfo

This is analogous to FHIR's VisionPrescription for optometry — structured clinical parameters for a custom-manufactured medical device. See the dedicated Clinical Lab Orders page for full documentation.

Workflow:

  1. Dentist prepares the tooth and documents clinical specifications (shade, material, preparation)
  2. PVS generates a DentalLabServiceRequestDE with clinical extensions and references to digital impressions
  3. Lab receives structured order — no ambiguity about shade (A3 not "yellowish"), material (Zirkon not "white ceramic"), or preparation (Stufe not "normal")
  4. Lab delivers restoration with BEL II / beb'97 billing data linked to the same ServiceRequest

8. AI-Assisted Dental Findings

Problem: Dental AI solutions (DentalXrai, Overjet, Pearl) analyze radiographs and produce structured findings (caries detection, bone loss measurement, periapical lesions). These findings need to be integrated into the clinical record using standardized FHIR resources.

Solution: The DentalFindingDE profile supports AI-generated findings through:

  • FDI tooth reference and surface codes for precise localization
  • Befund-Status (preliminary / differential / definitive) to distinguish AI suggestions from confirmed diagnoses
  • Category coding via the dental-category CodeSystem (Befund, Diagnose, Verlauf)
  • Reference to imaging via derivedFrom linking to DentalImagingStudyDE

This enables a workflow where AI analyzes an OPG, produces preliminary findings, and the dentist confirms or adjusts them before they become part of the official record.

9. Inter-Practice Communication (KIM/TIM)

Problem: Dental referrals (Überweisungen), consultation requests, and treatment reports need to be exchanged between practices, specialists, and labs using the Gematik KIM (Kommunikation im Medizinwesen) or TIM (TI-Messenger) infrastructure.

Solution: The DentalCommunicationDE profile enables structured dental messages that can be wrapped in ATF MessageHeader bundles for KIM/TIM transport. Typical scenarios:

  • Referral to oral surgeon with Zahnschema, relevant findings, and imaging
  • Lab order with tooth specifications, material requirements, and shade selection
  • Treatment report back to the referring dentist with procedure documentation

Bruxism screening

OralHealthScreeningDE keeps bruxism presence, circadian type, and diagnostic grade as independent components. Presence is a screening result. Circadian type distinguishes sleep and awake bruxism, while the diagnostic grade expresses the strength of the supporting clinical evidence. Consequences such as tooth wear remain separate findings, and a confirmed bruxism disorder remains a separate diagnosis; neither is inferred from a screening component alone.

Dental trauma

TraumaObservationDE carries one published ICD-11 NA0D classification, one FDI tooth, and the injury occurrence time. Multiple injuries at the same tooth and time are separate observations. Replantation, splinting, storage medium, and other interventions are represented with Procedure or supporting resources. A confirmed diagnosis may reference the trauma observations through Condition.evidence.detail; the finding itself is not the treatment record.