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

MIO Crosswalks

This page records how fhir-praxis-de profiles relate to KBV MIO and WeST target profiles. Everything on this page is a crosswalk — a mapping intent for export, import, and future alignment. None of these targets is a package dependency, and no local profile inherits from a MIO/WeST profile.

Crosswalk, Not Dependency

The KBV MIOs that overlap our domain (Laborbefund, WeST, Impfpass, eBild) plus the document-oriented profiles (Überleitungsbogen ULB, Krankenhaus-Entlassbrief KHE, Patientenkurzakte PKA) are draft, pre-binding, or version-incompatible with the pinned kbv.basis. Per the KBV-base alignment decision (ADR-008):

  • R3 — mirror, do not reinvent. Where a MIO/WeST profile already models a concept, we mirror its form and reuse its terminology rather than building a divergent local model.
  • R4 — model form now, package dependency later. We adopt the MIO shape (for example the two-tier Laborbefund Observation form) immediately; a hard package dependency waits until the upstream package is released and stable.
  • R10 — released-and-usable decides adopt vs crosswalk. Only kbv.basis itself is adopted/reparented. Draft or version-breaking packages (WeST, Laborbefund, eBild, ULB/KHE/PKA, MIO Impfpass 1.1.0) stay crosswalk-only: we express the mapping as a ConceptMap and/or a documented profile-level correspondence, and reference target canonical URLs as strings.

MIO/WeST canonical URLs all live under https://fhir.kbv.de/. ConceptMaps in this IG reference those target code systems by canonical URL string only.

Profile-Level Crosswalks

Local profile KBV MIO / WeST target Kind Transform note
PraxisLabObservation KBV_PR_MIO_LAB_Observation_Laboratory_Study (+ _Study_Group) Form mirrored Two-tier shape (see below). LOINC code, UCUM units, SNOMED-coded results. hasMember groups member Study observations into a Study_Group panel.
PraxisSpecimen KBV_PR_MIO_LAB_Specimen Form mirrored SNOMED specimen type (mandatory), optional LDT material code. Collection method/site/container carried through.
PraxisLabDiagnosticReport KBV_PR_MIO_LAB_DiagnosticReport_Laboratory_Result Form mirrored result points at the Study_Group panel observation (two-tier). LAB/MB/PAT category slices.
PraxisComposition KBV_PR_MIO_LAB_Composition and other MIO Compositions Document-specific A Composition profile is document-type specific (Laborbefund vs ULB vs KHE vs PKA). Map PraxisComposition.type and section structure to the matching MIO Composition per document class.
PraxisCarePlanDE ULB / KHE CarePlan Form mirrored Überleitungsbogen and Krankenhaus-Entlassbrief CarePlan profiles. Map category[planType] to the document-specific care-plan intent; WeST also plans a CarePlan surface.
PraxisReferralDE KBV_PR_WEST_ServiceRequest / MIO Lab KBV_PR_MIO_LAB_ServiceRequest Crosswalk Referral (Überweisung) as ServiceRequest. Requester carries LANR/BSNR; map to the WeST/LAB ServiceRequest request shape on export.
PraxisTherapeuticRemedyDE KBV_PR_WEST_ServiceRequest Crosswalk Heilmittelverordnung (Muster 13) as ServiceRequest. WeST models remedy/prescription orders as ServiceRequest; map order code + diagnosis group.
PraxisImmunization KBV_PR_MIO_Vaccination_* (MIO Impfpass, Immunization) Crosswalk-only (R10) MIO Impfpass 1.1.0 pulls an incompatible de.basisprofil.r4 transitive version, so PraxisImmunization stays on core Immunization. It binds the MIO vaccine vocabulary extensibly and supplied target diseases to KBV_VS_MIO_Vaccination_TargetDisease with required strength, while preserving optional cardinalities for historical data.
PraxisMedicationAdministration KBV_PR_WEST_MedicationStatement Crosswalk — resource-type differs We model in-practice drug administration as MedicationAdministration; WeST models medication history as MedicationStatement. The crosswalk changes resource type: an administration event projects to a MedicationStatement statement of what was given.
PraxisAnamneseFreeTextObservationDE KBV_PR_WEST_Observation-Anamnese / KHE Section_Anamnesis Crosswalk Freetext anamnesis Observation.valueString. Map to the WeST anamnesis observation or the KHE discharge-letter anamnesis section.
PraxisBefundFreeTextObservationDE KHE finding Observations (Assessment_Free / Comment / Clinical_Examination_Report) / PKA ObservationNote Crosswalk Freetext finding Observation.valueString. Map to the KHE/PKA finding observation per report class.
SmokingStatusDE KBV_PR_WEST_Observation-Anamnese / KHE finding Observations Crosswalk Social-history smoking status (LOINC 72166-2). Crosswalks to the WeST anamnesis / KHE finding observation family.
PraxisHealthcareServiceDE KHE HealthcareService_Contact_Discharge_Management Crosswalk (weak) Discharge-management contact is KHE-specific; map only the discharge-management use case.

MIO Laborbefund — Two-Tier Observation Shape

MIO Laborbefund models lab results in two tiers, which PraxisLabObservation now mirrors (additively — flat single observations remain valid):

DiagnosticReport (KBV_PR_MIO_LAB_DiagnosticReport_Laboratory_Result)
  .result --> Study_Group panel Observation (KBV_PR_MIO_LAB_Observation_Laboratory_Study_Group)
                .hasMember --> individual Study Observation (KBV_PR_MIO_LAB_Observation_Laboratory_Study)
                .hasMember --> individual Study Observation
                ...
  • A panel observation (Study_Group) groups member Study observations via Observation.hasMember.
  • The DiagnosticReport references the panel observation in result, not the individual members.
  • Each member is a single Study observation with a LOINC code and a UCUM-coded value.

PraxisLabObservation.hasMember is 0..* and optional. A flat single-result report simply references a member-style observation directly in DiagnosticReport.result and omits hasMember. Both patterns validate. LOINC and UCUM remain first-class on every observation.

Terminology Crosswalks

Laterality (Seitenlokalisation)

DiagnoseSeiteCS / DiagnoseSeiteVS are retained as crosswalk-only laterality vocabulary (they are not bound in any profile — profiles use http://fhir.de/StructureDefinition/seitenlokalisation directly). Two ConceptMaps carry the full chain:

ConceptMap Source Target
DiagnoseSeiteToKbvSeitenlokalisationCM DiagnoseSeiteCS (L/R/B) KBV KBV_CS_SFHIR_ICD_SEITENLOKALISATION (L/R/B) — 1:1 equivalent
SeitenlokalisationToSnomedLateralityCM KBV KBV_CS_SFHIR_ICD_SEITENLOKALISATION SNOMED CT laterality: left 7771000, right 24028007, bilateral 51440002

Dauerdiagnose ↔ WeST istDauerdiagnose

The local DauerdiagnoseExt boolean marker (on the open Condition.extension slot) is semantically aligned with, and maps 1:1 to, the WeST extension KBV_EX_WEST_Diagnose_istDauerdiagnose (istDauerdiagnose). It is a mirrored crosswalk marker, not a WeST binding or package dependency (ADR-008 R3/R10). Downstream adapters translate the local marker to/from the WeST extension.

WeST Diagnose/Leistung terminology — adopt when needed

WeST defines code systems for diagnosis and service classification. This IG does not currently model these concepts (there is no source-PVS field that populates them and no dental use case requires them), so — per ADR-008 R3 — we do not invent local equivalents. They are recorded here as adopt-when-needed: if a future workflow needs one of these axes, adopt the WeST code system directly rather than minting a divergent local one.

WeST code system Concept Status in this IG
KBV_CS_WEST_Diagnoseart Diagnosis kind (Diagnoseart) Not modelled — adopt WeST CS when a source field appears
KBV_CS_WEST_Diagnosekategorie Diagnosis category (Diagnosekategorie) Not modelled — adopt WeST CS when needed
KBV_CS_WEST_Leistungsart Service kind (Leistungsart) Not modelled — adopt WeST CS when needed

Boundaries

  • No Parent: KBV_PR_MIO_* or Parent: KBV_PR_WEST_* anywhere in input/fsh/. Our profiles and the WeST profiles are siblings on kbv.basis (ADR-008).
  • kbv.mio.laborbefund, kbv.mio.west, and MIO Impfpass are not in sushi-config.yaml dependencies.
  • ConceptMaps reference MIO/WeST/SNOMED code systems by canonical URL string only.
  • See the Vererbungsarchitektur and AW-SST Crosswalk pages for the wider KBV-base alignment and the WeST-successor export mapping.