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

International Interoperability

International Interoperability

This page describes how the German Dental FHIR Profiles (fhir-dental-de) relate to international dental FHIR specifications and provides guidance for cross-border data exchange.

Version Baseline

This crosswalk is version-bound. The following releases were checked for this IG version:

DDEx 1.0.0 remains the stable package registry release. The crosswalk below uses DDEx 2.0.0-ballot as requested because it reflects the current ballot model, but implementations must not treat the CI output as stable. Producers and transformation specifications should record the exact DDEx version they target.

The local build is pinned to de.basisprofil.r4 1.5.4, kbv.basis 1.9.0, and de.cognovis.fhir.praxis 0.88.0. These are the tested compatibility versions for fhir-dental-de 0.41.0; they are not claims about the newest release available in every upstream registry.

The FDI World Dental Federation published a consensus statement on integrated EHRs in March 2025 advocating FHIR-based interoperability but does not author a FHIR IG.

Comparison with MedMij Dental Care IG (Netherlands)

The MedMij R4 Dental Care IG v1.0.0-rc.1 is maintained by Stichting MedMij and Nictiz. It takes a fundamentally different architectural approach: minimal dental-specific profiles with heavy reliance on shared nl-core base profiles. The release is explicitly still in its release-candidate phase.

Profile Correspondence

Terminology Comparison

Architectural Comparison

Harmonization Opportunities

Despite their different architectures, the two IGs share a common clinical foundation that can be harmonized:

1. SNOMED CT dental mapping — Both IGs use SNOMED CT for clinical concepts. A shared European SNOMED CT dental value set (covering caries risk, oral hygiene, periodontal findings, parafunctional habits) would benefit both IGs and any future European dental IG.

2. Periodontal assessment — fhir-dental-de's granular PeriodontalObservationDE (6-point probing, BOP, recession, furcation) and MedMij's aggregate PeriodicPeriodontalScreeningScore are complementary. An aligned approach could define a base screening level (NL-style PSI) with an optional detailed level (DE-style per-tooth components).

3. Procedure coding bridge — Neither BEMA/GOZ nor Vektis Mondzorg codes are internationally portable. SNOMED CT procedure concepts could serve as a European lingua franca, with national codes as primary bindings and SNOMED CT as secondary (similar to fhir-dental-de's dual-coding strategy for tooth identification).

4. FDI tooth identification — fhir-dental-de already uses FDI (ISO 3950) as the international standard. MedMij does not currently expose tooth-level data. Adopting FDI across both IGs would enable tooth-level data exchange without code system translation.

DDEx 2.0.0-ballot Profile Correspondence

The following table maps fhir-dental-de profiles to their closest equivalents in DDEx 2.0.0-ballot. The same seven profile families are present in the published DDEx 1.0.0 release, but implementers must validate differences against the release they actually exchange.

Terminology Mapping

Tooth Identification

Germany and most countries use the FDI two-digit notation (ISO 3950). The US uses ADA Universal Numbering. Both can be bridged via SNOMED CT anatomical tooth concepts.

fhir-dental-de uses FDI as the primary coding in bodySite and adds SNOMED CT as a secondary coding where a corresponding concept exists. This dual-coding strategy enables US IG consumers to interpret tooth references without understanding FDI notation.

Tooth Surfaces

Dental surfaces use different code sets and representation models across jurisdictions. Some concepts align exactly; others require a context-sensitive, potentially lossy transformation.

fhir-dental-de attaches a repeatable tooth-surfaces extension to the tooth-bearing bodySite CodeableConcept. DDEx does not represent multiple surfaces as repeated targetSiteCode values. DDEx 2.0.0-ballot keeps the FHIR R4 Observation.bodySite cardinality at 0..1 and instructs producers to use a single post-coordinated SNOMED CT expression when several teeth, surfaces, or oral areas apply.

Tooth Surface Transformation Matrix

This is a structural transformation, not a terminology-only ConceptMap. A StructureMap or adapter transformation may implement it, while a ConceptMap can only support the individual code correspondences.

Procedure Codes

There is no 1:1 mapping between BEMA/GOZ and CDT. The procedure concepts overlap clinically (e.g., "two-surface composite restoration" exists in both systems), but the code structures, numbering, and granularity differ fundamentally. Cross-system mapping requires clinical concept matching, not code translation.

Diagnosis Codes

Both ICD-10 variants share a common stem (WHO ICD-10) but diverge at the extension level. SNOMED CT can serve as a bridge terminology for clinical concepts, though coverage of dental diagnoses varies.

Clinical Semantics Transformation

Periodontal and Prophylaxis Crosswalk

The following correspondences are transformation guidance, not claims of profile equivalence. Direct terminology coding is used only where the international concept represents the same measurement or finding.

This IG deliberately does not add package dependencies on the MedMij release candidate or the mutable DDEx ballot build. Version-bound narrative mappings remain stable for publication; future executable transformations may add governed ConceptMaps for terminology and StructureMaps for resource shape.

Finding Codes

DentalFindingCodesVS is a curated, extensible set of common dental findings. The DDEx Dental Observation Codes value set includes all concepts below Clinical Finding from SNOMED CT and SNODENT and is therefore much broader. Identical SCTIDs map directly and do not require a ConceptMap. A code accepted by DDEx but absent from the curated local list may still be valid under the local extensible binding, provided its terminology edition and meaning are validated.

Observation and Condition Boundary

fhir-dental-de uses DentalFindingDE for raw measurements, odontogram states, plaque, risk observations, and other findings. DentalConditionDE is reserved for an asserted diagnosis and may reference supporting Observations through evidence.detail.

DDEx 2.0.0-ballot describes the same general Observation/Condition distinction, but its examples include plaque and caries risk as Conditions. Importers must therefore classify the source meaning rather than copy the DDEx resource type:

Lifecycle and Authorship

​The lifecycle values and invariant con-5 come from FHIR R4 Condition. This IG adds Must Support expectations but does not redefine the core semantics. The Praxis-DE diagnosis certainty contract is the shared mapping for the German G, V, Z, and A certainty markers; this IG does not duplicate that table.

DentalConditionDE.asserter is the dental professional responsible for the diagnosis, while recorder is the person or role that entered it. DDEx and KBV base profiles do not provide the same dental qualification restriction. For legacy AW-SST export, KBV_PR_AW_Diagnose requires encounter and prohibits both asserter and recorder. An exporter must therefore:

1. omit authorship fields only in the archive projection and record that loss;
2. populate the required encounter only from source-supported context; and
3. retain the original DentalConditionDE or equivalent provenance for audit.

​The Praxis-DE AW-SST and WeST crosswalk remains authoritative for the German practice export targets. This page only adds the dental-specific source-to-Praxis projection.

Dual-Coding Strategy

fhir-dental-de uses a dual-coding approach to maintain compatibility with the HL7 Dental Data Exchange IG while preserving native German coding:

1. FDI as primary coding – the standard in German dental practice and internationally (outside the US).
2. SNOMED CT as secondary coding – enables interoperability with the US IG, which uses SNOMED tooth concepts.

Example: bodySite with dual coding

{
  "bodySite": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/ex-tooth",
          "code": "36",
          "display": "Lower left first molar (FDI 36)"
        },
        {
          "system": "http://snomed.info/sct",
          "code": "38671000",
          "display": "Permanent lower left first molar"
        }
      ]
    }
  ]
}

Example: tooth-surfaces extension with dual coding

{
  "extension": [
    {
      "url": "https://fhir.cognovis.de/dental/StructureDefinition/tooth-surfaces",
      "valueCodeableConcept": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/FDI-surface",
            "code": "M",
            "display": "Mesial"
          },
          {
            "system": "http://snomed.info/sct",
            "code": "245647007",
            "display": "Structure of mesial surface of tooth"
          }
        ]
      }
    }
  ]
}

A system consuming data from fhir-dental-de can use the SNOMED CT tooth coding instead of the FDI coding when it needs US-oriented tooth identification. However, dual-coding alone is not sufficient for DDEx conformance when several teeth or surfaces are present; the representation transformation described above is still required.

Authorization and Billing Crosswalk

Selected Plan to Da Vinci PAS

DentalCarePlanDE.intent = option represents an unselected alternative. Only the selected intent = plan instance is eligible to become authorization input. Da Vinci PAS 2.2.1 uses a preauthorization Claim and ClaimResponse; DDEx does not define this workflow.

FHIR R4 Claim has no basedOn element. Consequently, documentation or implementations must not claim a DentalCarePlanDE to PASClaimDE.basedOn mapping. A future dental authorization profile can add a required Claim.supportingInfo.valueReference slice for the selected CarePlan or use a separately governed linkage extension. Until that contract is profiled, exporters should preserve the selected plan as supporting information without stamping an unsupported basedOn path.

Festzuschuss Adjudication

These are structural mappings. StructureDefinition.mapping, a narrative mapping table, or an executable StructureMap is appropriate. ConceptMap is reserved for terminology correspondences.

DentalClaimDE to Praxis, AW-SST, and WeST

DentalClaimDE is an operational, position-bearing mixed claim. The Praxis-DE package provides the shared Account, Coverage, preliminary/final Claim, and WeST/AW-SST export contracts. The dental projection is:

Export loss must be visible in adapter audit output or Provenance; an exporter must not silently discard dental-specific semantics.

Interoperability Assessment

Closely aligned

• Clinical findings (DentalFindingDE / Dental Finding) – both are Observation-based, but terminology breadth and multi-site representation require the rules above.
• Clinical conditions (DentalConditionDE / Dental Condition) – both are Condition-based, but importers must preserve the local finding-versus-diagnosis boundary.
• Tooth identification – FDI and Universal Numbering can map to SNOMED CT anatomical concepts; compound site expressions still require transformation.
• Communications (DentalCommunicationDE / Dental Communication) – structurally aligned, both based on Communication with dental category.

Partially compatible (same concepts, different code systems)

• Procedures – a two-surface composite restoration is clinically the same concept in BEMA, GOZ, and CDT. The procedure codes differ and cannot be translated mechanically. Cross-border exchange requires mapping at the clinical concept level (e.g., via SNOMED procedure concepts), not code-to-code translation.
• Diagnosis codes – ICD-10-GM and ICD-10-CM diverge at extension digits. Mapping is feasible for common dental diagnoses (e.g., K02.x caries codes share the same stem) but not guaranteed for all codes.

Not compatible (fundamentally different systems)

• Billing – German dental billing (BEMA for GKV, GOZ for PKV) and US dental billing (CDT + insurance claims) are structurally incompatible. Fee calculation (German point values / multiplier factors vs. US fee schedules), insurance workflows (KZV clearing vs. direct payer submission), and authorization processes (HKP Genehmigung vs. prior authorization) have no meaningful overlap. The ChargeItem-based profiles in fhir-dental-de (BemaChargeItemDE, GozChargeItemDE) have no equivalent in the US IG.
• Treatment plan authorization – German HKP/KV workflows (CarePlan-based with KZBV approval) differ fundamentally from US prior authorization (typically modeled via Da Vinci PAS or X12 278).

DACH Region Compatibility

This IG is scoped to the German healthcare system (jurisdiction: DE). However, the clinical profiles are designed to be extensible to the DACH region (Germany, Austria, Switzerland).

What is already DACH-compatible

The following profiles use international coding systems and can be adopted in Austria and Switzerland without modification:

• DentalFindingDE / PeriodontalObservationDE / ProphylaxisObservationDE — FDI tooth numbering (ISO 3950) is used in all three countries. DentalFindingDE exposes an SCTID-only SNOMED CT pick list; its extensible binding and the specialized profiles still permit internationally valid codes such as LOINC where the curated list does not represent the observation.
• DentalConditionDE — ICD-10-GM (German modification) shares a common WHO ICD-10 stem with the Austrian and Swiss variants. Dental diagnoses (K00-K14) are largely identical across all three national ICD-10 editions.
• DentalProcedureDE — The Procedure resource structure is country-neutral. Only the code binding (BEMA/GOZ) is Germany-specific.
• DentalImagingStudyDE — DICOM modality codes are international. FDI tooth numbering in series.bodySite works across DACH.
• DentalCommunicationDE — Structurally country-neutral.

What requires national adaptation

Extension strategy

A future DACH dental IG could be structured as:

dach-dental-core (clinical profiles, FDI, SNOMED CT)
├── de-dental (German billing, insurance, TI)
├── at-dental (Austrian billing, ELGA)
└── ch-dental (Swiss billing, EPR)

This IG (fhir-dental-de) could serve as the basis for dach-dental-core by extracting the clinical profiles into a country-neutral layer and keeping the billing/insurance profiles as the de-dental specialization.

Three-Way Comparison

The following table summarizes how the three compared dental FHIR IGs cover key clinical domains at the version baseline above:

References

• HL7 Dental Data Exchange IG v1.0.0 STU 1 – current published US Realm release
• HL7 Dental Data Exchange IG v2.0.0-ballot CI build – mutable ballot crosswalk target
• FHIR Package Registry: hl7.fhir.us.dental-data-exchange – published package versions
• MedMij R4 Dental Care IG v1.0.0-rc.1 – Dutch dental FHIR release candidate
• ADA Tooth Surface Codes (HL7 THO) – US tooth surface terminology
• FDI Two-Digit Notation (ISO 3950) – international tooth numbering standard
• SNOMED CT Dental Concepts – international clinical terminology with dental anatomy concepts
• Da Vinci Prior Authorization Support (PAS) v2.2.1 – current published US prior authorization IG
• German Base Profiles package registry (de.basisprofil.r4) – this IG is pinned to v1.5.4
• KBV Base Profiles v1.9.0 – pinned Condition base profile
• FDI EHR Consensus Statement (2025) – FDI advocacy for integrated dental EHRs
• CH Core IG – Swiss FHIR base profiles