German Practice Management FHIR Profiles (R4)
0.90.0 - STU1 Germany

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

Vererbungsarchitektur

Vererbungsarchitektur (Inheritance Architecture)

This page documents the profile inheritance strategy used in de.cognovis.fhir.praxis and its downstream Implementation Guides.

KBV Base is the Default

Per ADR-008 (KBV-Basis als Fundament), de.cognovis.fhir.praxis inherits the KBV German base profiles (kbv.basis) directly wherever a matching KBV_PR_Base_* profile exists. There is no "just-in-case" Praxis* wrapper layer. A thin Praxis* wrapper survives only where a justified, locally-populated field or constraint exists that KBV base does not already model.

The rule (ADR-008 R1/R2): a Praxis* profile or field is kept only if we populate it from the PVS source or need it for a downstream specialty IG (e.g. fhir-dental). If neither applies, the resource uses the KBV base profile directly.

graph TD
    subgraph L1["KBV Base (kbv.basis)"]
        KBV_C["KBV_PR_Base_Condition_Diagnosis"]
        KBV_P["KBV_PR_Base_Patient"]
        KBV_PR["KBV_PR_Base_Practitioner"]
        KBV_PROC["KBV_PR_Base_Procedure"]
        KBV_ENC["KBV_PR_Base_Encounter"]
        KBV_O["KBV_PR_Base_Organization"]
        KBV_CT["KBV_PR_Base_CareTeam"]
    end

    subgraph USE["Used directly (no wrapper)"]
        C["Condition (Diagnosen)"]
        P["Patient"]
        PR["Practitioner"]
        PROC["Procedure"]
    end

    subgraph WRAP["Justified praxis-de wrappers"]
        ENCP["EncounterPraxis"]
        PORG["PraxisOrganizationDE"]
        CTDE["CareTeamDE"]
    end

    KBV_C --> C
    KBV_P --> P
    KBV_PR --> PR
    KBV_PROC --> PROC

    KBV_ENC --> ENCP
    KBV_O --> PORG
    KBV_CT --> CTDE

Resources Using KBV Base Directly

These resources previously carried thin Praxis* wrappers. Per ADR-008 the wrappers were dissolved; the resources now inherit KBV base directly:

Resource KBV base profile Why no wrapper
Diagnoses KBV_PR_Base_Condition_Diagnosis asserter/evidence not sourced from the PVS (recorder is set instead); Dauerdiagnose carried by the local DauerdiagnoseExt boolean marker on open Condition.extension, a 1:1 crosswalk to WeST istDauerdiagnose
Patient KBV_PR_Base_Patient VSD lands on standard fields (Name/KVID/Coverage); own-name/Ortsteil were redundant
Practitioner KBV_PR_Base_Practitioner Telematik-ID not populated; ZANR moved to the dental IG
Procedure KBV_PR_Base_Procedure OPS + Seitenlokalisation inherited from KBV
AllergyIntolerance KBV_PR_Base_AllergyIntolerance KBV has the stronger SNOMED/ASK binding
Device KBV_PR_Base_Device GDT-8402 identifier is carried directly on the KBV base Device instance

Surviving praxis-de Wrappers (Justified Fields)

A Praxis* profile is retained only where it adds a field we actually populate. All surviving wrappers now derive from KBV base directly:

Profile KBV parent Justified addition
EncounterPraxis (+ HZV/PoPP variants) KBV_PR_Base_Encounter Wegegeld (EntfernungZurPraxis + Zonenkennzeichen), accountAccountPraxisSchein (billing case), ISiK-Location
PraxisOrganizationDE KBV_PR_Base_Organization Kleinunternehmerregelung § 19 UStG (KleinunternehmerregelungExt); KV-Sitz and AI-marker removed
CareTeamDE KBV_PR_Base_CareTeam KBV care-team roles on participant.role; Fachgruppe moved to PractitionerRole.specialty
PraxisPractitionerRoleDE KBV_PR_Base_PractitionerRole takes Fachgruppe (BAR2-WBO) as specialty
PraxisLabDiagnosticReport KBV_PR_Base_DiagnosticReport mirrors the MIO-Laborbefund form (LOINC/UCUM, two-stage Observation)

Dauerdiagnose, Pflegegrad, AI Provenance

  • Dauerdiagnose is expressed via the local DauerdiagnoseExt boolean marker on the open Condition.extension slot (not a wrapper-profile field). The marker is semantically aligned with the WeST istDauerdiagnose extension and maps 1:1 to it (crosswalk, mirrored form — no WeST package dependency; see the MIO Crosswalks page).
  • Pflegegrad is a KBV Observation_Care_Level Observation downstream, not a patient master-data modifier extension.
  • AI provenance uses the local bounded compatibility profile against the accepted FHIR resource while retaining the official HL7 AI Transparency AI-Device target constraint. Application proposal state is outside FHIR, and ordinary non-AI audit events use base Provenance.

KBV Snapshot Generation

KBV publishes kbv.basis without snapshots (a known KBV publishing oversight). The CI pipeline runs the generate-kbv-basis-snapshots composite action (.github/actions/generate-kbv-basis-snapshots/) before SUSHI to inject snapshots, enabling inheritance from KBV base profiles. See bead fpde-shp.5.

CI Test Profiles

The directory input/fsh/tests/ contains CI-only test profiles (IDs prefixed with test-); these are included in the published package tarball as tripwires to verify profile inheritance compiles correctly end-to-end. Downstream consumers of de.cognovis.fhir.praxis should filter out any profile IDs matching test-* — they are not intended for clinical use.

Cross-Reference: fhir-dental-de (fdde-pax)

The downstream IG de.cognovis.fhir.dental (fhir-dental-de) previously extended this IG's middle-layer profiles. Per ADR-008 those wrappers are gone, so the dental profiles reparent onto KBV base directly:

  • DentalConditionDEKBV_PR_Base_Condition_Diagnosis (adds ICD-10-GM dental specifics)
  • DentalPatientDEKBV_PR_Base_Patient (adds dental-specific patient identifiers)
  • DentalPractitionerDEKBV_PR_Base_Practitioner (adds ZANR Must Support, which moved to dental)
  • DentalOrganizationDEPraxisOrganizationDE (still inherits the Kleinunternehmer tax layer)

When bumping this IG, check for breaking changes affecting fhir-dental-de. The dental IG pins de.cognovis.fhir.praxis in its sushi-config.yaml and must be updated when a new version of this IG is published.