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

Profiles

Profiles

This Implementation Guide is primarily extension-focused, but it also defines selected custom StructureDefinition profiles where routing, slicing, or validation rules need to be explicit on top of standard FHIR R4 and German base profiles.

The IG therefore combines reusable extensions and terminology with a small number of targeted profiles for patient demographics, coverage routing, laboratory exchange, procedures, and related ambulatory workflows.

Extended Resources by Domain

Billing / Abrechnung

Budget / RLV

Remittance / Honorarbescheid

Clinical

Administrative

PraxisCondition — ICD-10-GM mit Diagnosesicherheit

The PraxisCondition profile extends the base FHIR Condition resource to standardize diagnosis recording in German ambulatory practice with mandatory KV billing requirements (KVDT 6.06).

Core Elements

Praxis Extensions

ICD-10-GM Diagnosesicherheit (KVDT 6.06 Compliance)

The KV requires all diagnoses submitted in billing claims to carry a diagnosesicherheit code:

PVS systems must extract and populate this extension on every diagnosis before sending the claim to the KV. The binding is required.

Integration with German Base Profiles

PraxisCondition applies to the standard FHIR R4 Condition resource (from de.basisprofil.r4 or FHIR R4 core). It does not constrain base Condition elements, but requires support for:

• ICD-10-GM coding via BFARM CodeSystem
• Upstream KBV extension for diagnosesicherheit
• One local extension (dauerdiagnose)

Example Use Cases

1. Confirmed diagnosis for KV claim: A patient with diabetes mellitus Type 2 (E11.9) marked as gesichert (G), dauerdiagnose=true.
2. Ruled-out differential: A suspected infection ruled out during workup, marked as ausgeschlossen (A).
3. Suspected condition pending confirmation: A provisional diagnosis marked as verdacht (V).
4. Post-treatment status: Patient with resolved fractured arm marked as zustand nach (Z).

PVS Implementation Note

When recording a diagnosis in the PVS:

1. Create or retrieve a Condition resource
2. Populate ICD-10-GM code from the EBM/clinical context
3. Always set the diagnosesicherheit extension based on clinical judgment (G/A/V/Z)
4. If chronic: set dauerdiagnose=true so EHR auto-carries to next quarter
5. Validate against PraxisCondition profile before submission

See example example-diagnose for a complete instance.

AnamneseQuestionnaire — Anamneseboegen-Profil

The AnamneseQuestionnaire profile extends the base FHIR Questionnaire resource to standardize ambulatory history-taking forms (Anamneseboegen) in practice management systems. It supports multiple questionnaire types (initial intake, pain assessment, preventive health screening, and follow-up) with structured groups of clinical questions.

Supported Questionnaire Types

Profiling Rules

• status: Required, must be #active for active templates
• title: Required, human-readable name of the questionnaire
• subjectType: Required, must be #Patient
• useContext[bogentyp]: Required slice (1..*) to classify the questionnaire type via AnamneseBogentypVS
• extension[kategorie]: Optional extension for clinical specialty (e.g., "Allgemeinmedizin", "Orthopädie")
• item.extension[clinicalAlert]: Optional (0..1, Must-Support) boolean flag to mark a questionnaire item as clinically critical. Use cases include allergy questions (e.g., "Bekannte Allergien"), anticoagulant medication items, and endocarditis risk screening items. When set to true, PVS systems should surface the item prominently in the clinical workflow.
• item: Required (1..*), each item has linkId, type, and optional required flag

Supported Question Types

Standard FHIR Questionnaire item types including: group, display, boolean, decimal, integer, date, dateTime, time, string, text, url, choice, open-choice, attachment, reference, quantity.

Integration with QuestionnaireResponse

Patients complete these questionnaires via a QuestionnaireResponse-Builder interface. Each response is linked to the template via QuestionnaireResponse.questionnaire reference. PVS systems can then:

• Extract structured data from responses (e.g., previous illnesses, medication, social history)
• Pre-populate clinical note templates
• Track questionnaire completion as part of encounter workflow
• Support both paper-based and digital intake workflows

See example example-anamnese-erstanamnese for a complete three-group Erstanamnese template (Previous Conditions, Medication, Social History).

InsurancePlanDE — GKV/PKV Tarif-Profile

The InsurancePlanDE profile extends the base FHIR InsurancePlan resource with slicing on plan to distinguish GKV (statutory health insurance) and PKV (private health insurance) tariffs.

Plan Slices

Coverage.class → InsurancePlan Reference Pattern (AK3)

FHIR R4 does not provide a direct reference element from Coverage to InsurancePlan. The recommended pattern for this IG is to use Coverage.class to link a patient's Coverage to the specific InsurancePlan tariff by identifier:

Coverage.class[type=plan].value  →  InsurancePlan.identifier (Tarif-Identifier)
Coverage.class[type=plan].name   →  InsurancePlan.name (human-readable label)

Example: A GKV patient with AOK Bayern PZR Satzungsleistung:

Coverage.class[0].type  = http://terminology.hl7.org/CodeSystem/coverage-class#plan
Coverage.class[0].value = "aok-bayern-pzr"
Coverage.class[0].name  = "AOK Bayern — Basis + PZR Satzungsleistung"

The value "aok-bayern-pzr" matches the InsurancePlan.identifier of the corresponding InsurancePlanDE instance. Systems can look up the full tariff details (benefit limits, GOÄ-Faktoren, Satzungsleistungen) from the referenced InsurancePlan resource using this identifier.

See example-coverage-aok-tarif for a complete example.

CareTeamDE — Behandler-Teams

The CareTeamDE profile models treatment teams (Behandler-Teams) in German ambulatory care. It supports interdisciplinary care coordination with role-based participant slicing.

Core Structure

Participant Slicing

Participants are sliced on the role element to distinguish treatment roles:

Each participant[behandler] slice must include:

• A role from BehandlerRolleVS (Zahnarzt, Arzt, ZFA, MFA, WB-Assistent, Physiotherapeut)
• A member Reference to the Practitioner, PractitionerRole, or Organization holding that role
• Optionally, a period (start/end) for that participant's engagement

Use Cases

1. Dental Practice Team: A Zahnarztpraxis with a dentist (Zahnarzt), dental assistant (ZFA), and training resident (WB-Assistent), covering Q1 2024.
2. General Medical Team: A GP practice with physician (Arzt) and medical assistant (MFA).
3. Inactive Historical Team: An archived team from 2023 with status=inactive.
4. Multidisciplinary Center (MVZ): An MVZ with 5+ participants across dental, medical, physiotherapy disciplines.

PVS Integration Pattern

A PVS adapter should:

1. Create a CareTeamDE instance for each patient-facing treatment team.
2. Populate participant slices by extracting role information from the PVS's internal role/function tables.
3. Use period.start / period.end to track when the team composition was active.
4. Reference patient, practitioners, and the managing organization via FHIR identifiers.

See examples: example-care-team, example-care-team-small, example-care-team-inactive, example-care-team-mvz.

PraxisDevice — Medizingeräte und Laboranalyzatoren

The PraxisDevice profile extends the base FHIR Device resource for medical devices and lab analyzers in German ambulatory practice. It integrates with GDT 3.5 device data (FK 8402 Gerätekennung) and provides structured coding for device identification.

Core Structure

Use Cases

1. Lab Analyzer: A fully-automated clinical chemistry analyzer (e.g., Roche Cobas 6000) with complete identification and version tracking.
2. ECG Device: A portable EKG device (e.g., Schiller AT-102) with minimal required fields.
3. PVS Device Registry: Practice management systems maintain a registry of devices with GDT identifiers for test ordering and result routing.

GDT Integration Pattern

GDT 3.5 device data (FK 8402 Gerätekennung) maps to PraxisDevice.identifier[gdtId].value. The practice management system uses this identifier to:

• Route lab orders to the correct device
• Match incoming GDT results (Satzart 6310) to the originating device
• Track device metadata (manufacturer, model, version) for quality assurance

See examples: example-cobas-6000, example-schiller-at102.

PVS Integration Pattern

A PVS adapter should:

1. Create a PraxisDevice instance for each device managed by the practice.
2. Populate the identifier[gdtId].value with the GDT device identifier from the PVS.
3. Use deviceName, manufacturer, modelNumber, version, and type to encode device metadata.
4. Update device status (active / inactive) to reflect the device's current operational state in the practice.

ProcedureAmbulantDE — Ambulante Eingriffe mit OPS-Kodierung

The ProcedureAmbulantDE profile extends the base FHIR Procedure resource to support ambulatory procedures (Eingriffe) in German practice management. Procedure coding uses the OPS (Operationen- und Prozedurenschlüssel) via the CodingOPS profile from de.basisprofil.r4, which includes the Seitenlokalisation extension for laterality.

Must-Support Elements

OPS Seitenlokalisation

Laterality (Seitenlokalisation) is modeled as an extension on the code.coding[ops] element, as defined by the CodingOPS profile:

code.coding[ops].extension[seitenlokalisation].valueCoding
  system: https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_ICD_SEITENLOKALISATION
  code: L | R | B

The bodySite element may additionally carry more granular anatomical location information (e.g., for multi-site procedures).

Use Cases

1. Ambulante Koloskopie: A diagnostic colonoscopy coded as OPS 1-650.1, status completed, linked to a GKV patient.
2. Wundversorgung links: A wound care procedure (OPS 5-916.00) with Seitenlokalisation = L (links) recorded as an extension on the OPS coding.

See examples: example-procedure-koloskopie, example-procedure-wundversorgung-links.

FPDEPatient — Patient-Demografie-Erweiterungen

The FPDEPatient profile extends the base FHIR Patient resource to support German-specific demographic attributes required by practice management systems. It adds support for maiden name (Geburtsname) and district/neighborhood (Ortsteil) information.

Core Elements

Supported Extensions

humanname-own-name — Maiden Name (Geburtsname)

The FHIR standard extension http://hl7.org/fhir/StructureDefinition/humanname-own-name is used to capture the patient's maiden name when name.use = #maiden. This extension is defined in the base FHIR specification and allows recording the original family name before marriage.

Example:

name[1].use = #maiden
name[1].family = "Schmidt"
name[1]._family.extension[0].url = "http://hl7.org/fhir/StructureDefinition/humanname-own-name"
name[1]._family.extension[0].valueString = "Schmidt"

iso21090-ADXP-precinct — District/Neighborhood (Ortsteil)

The ISO 21090 standard extension http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-precinct is used to capture the neighborhood or district (Ortsteil, Stadtteil) as part of the patient's address. This is a German-common requirement where practices need to differentiate between districts of larger cities.

Example:

address[0].extension[0].url = "http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-precinct"
address[0].extension[0].valueString = "Kreuzberg"

Use Cases

1. Patient with maiden name: Anna Mueller (official) formerly Schmidt (maiden) — recorded with two name entries, the second using use=maiden with the humanname-own-name extension.
2. Patient with district: Maria Gonzalez living in Berlin-Kreuzberg — the Ortsteil is captured in the address extension.
3. Patient with both: Patient has official name, maiden name, and resides in a specific neighborhood — all three attributes are captured.
4. Patient without maiden name: Thomas Bauer — maiden name is optional; patients without it validate correctly.

PVS Implementation Note

When recording patient demographics in a PVS:

1. Create a Patient resource
2. Populate name[0] with the official name (use=official)
3. If the patient provides a maiden name, add name[1] with use=maiden and populate name[1].family with the maiden name. Add the humanname-own-name extension to name[1]._family to explicitly store the value.
4. For the address, populate standard address elements (line, city, postalCode, country).
5. If the patient's residence includes a district/neighborhood, add the iso21090-ADXP-precinct extension to address[].extension.
6. Validate the instance against FPDEPatient before submission.

See examples: example-patient-geburtsname, example-patient-ohne-geburtsname, example-patient-ortsteil.

FPDECoverageGKV — GKV Insurance with Wohnortprinzip (WOP)

The FPDECoverageGKV profile extends the base FHIR Coverage resource to support German statutory health insurance (GKV — gesetzliche Krankenversicherung) with the Wohnortprinzip (WOP — residence-based principle) designation. The WOP indicates the regional KV (Kassenärztliche Vereinigung) responsible for the patient's care based on their place of residence.

Core Elements

Supported Extension

gkv/wop — Wohnortprinzip (WOP)

The extension http://fhir.de/StructureDefinition/gkv/wop from de.basisprofil.r4 is used to specify the regional KV responsible for the patient. The value is a Coding from the KBV CodeSystem https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_ITA_WOP, which lists all German KV regions (e.g., 38 = Nordrhein, 17 = Westfalen-Lippe).

Example:

extension[0].url = "http://fhir.de/StructureDefinition/gkv/wop"
extension[0].valueCoding.system = "https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_ITA_WOP"
extension[0].valueCoding.code = "38"
extension[0].valueCoding.display = "Nordrhein"

WOP Codes (Auswahl)

Use Cases

1. Patient with GKV coverage in Nordrhein: Coverage for AOK Rheinland/Hamburg with WOP=38 (Nordrhein).
2. Patient moving to different KV region: Update coverage with new WOP code reflecting the new region of residence.
3. Multi-regional insurance: A patient may have multiple Coverage entries with different WOP codes if they have special arrangements.
4. Coverage without WOP: GKV coverage may be recorded without a WOP extension (WOP is optional); the profile validates correctly in both cases.

PVS Implementation Note

When recording GKV coverage in a PVS:

1. Create a Coverage resource
2. Set status = #active (or appropriate status)
3. Populate type with GKV coding from http://fhir.de/CodeSystem/versicherungsart-de-basis
4. Set beneficiary to a Reference(Patient)
5. Set payor to the insurance carrier (Krankenkasse) name or reference
6. If the patient's residence is within a specific KV region, add the gkv/wop extension with the appropriate WOP code
7. Validate the instance against FPDECoverageGKV before submission

Upstream Dependency: The gkv/wop extension is provided by the de.basisprofil.r4 package and is not redefined in this IG. It is reused as-is.

See examples: example-coverage-gkv-wop, example-coverage-gkv-wop-west.

FPDECoveragePrivat — Private / Self-Pay Coverage Routing

The FPDECoveragePrivat profile constrains Coverage for private billing scenarios where routing to an external billing service (PVS) is decided per Coverage. This is the critical modeling choice: a patient can have multiple Coverage resources, and only some of them may route receivables to a third-party biller.

de.basisprofil.r4 version 1.6.0-ballot2 does not currently publish a dedicated coverage-de-pkv profile. This IG therefore derives FPDECoveragePrivat from coverage-de-basis and requires a German insurance type coding of PKV or SEL.

Core Elements

Routing Pattern

1. The selected Coverage is the source of truth for external billing routing.
2. If extension[billing-assignment] is present, the referenced Organization is the PVS / billing service for that coverage.
3. Downstream claim generation maps that organization to Claim.payee.type = other and Claim.payee.party.
4. If the extension is absent, direct patient/self-pay remains valid and no external payee needs to be derived.

Use Cases

1. PKV with factoring: Private insurance coverage routes receivables to a PVS via billing-assignment.
2. Self-pay without PVS: Coverage validates without the extension when the patient pays directly.
3. Mixed coverage stack: The same patient can keep GKV coverage without routing extensions and a separate private/self-pay coverage with PVS routing.

PVS Implementation Note

When recording private billing coverage in a PVS:

1. Create a Coverage resource based on FPDECoveragePrivat
2. Populate type with PKV or SEL from VersicherungsartDeBasis
3. Set beneficiary to the covered patient and payor to the insurer or direct payer
4. Add billing-assignment only when receivables are assigned to an external billing service
5. Capture the corresponding patient consent as a separate Consent resource scoped to the same Coverage
6. Validate the instance against FPDECoveragePrivat before submission

See examples: ExampleCoveragePrivat, ExamplePvsOrganization, ExampleConsentBillingAssignment.

PraxisSpecimen — Probenmaterial für xDT-Adapter

The PraxisSpecimen profile extends the base FHIR Specimen resource to standardize specimen (Probenmaterial) documentation in German ambulatory practice. It is designed for xDT adapters (LDT, GDT 3.5) that exchange laboratory order and result information. The profile ensures that specimen identifiers and material types are captured in a PVS-agnostic manner, compatible with laboratory systems.

Core Elements

Specimen Identifier Pattern (No Shared NamingSystem)

Specimen identifiers are lab-specific. No shared NamingSystem is defined for specimen identifiers. Each laboratory assigns identifiers using its own system URL:

identifier[0].system = "https://<lab-specific-url>/proben-id"
identifier[0].value  = "<lab-specific-specimen-id>"

Example: A specimen from "Labor Beispiel" might use:

system = "https://labor-beispiel.de/proben-id"
value  = "BL-2026-00147"

Different laboratories can have different URL structures; there is no registry of these URLs — they are internal to each laboratory system.

Material Type Coding: SNOMED-CT + LDT

SNOMED-CT (extensible) provides internationally recognized coding for specimen types:

• 122555007 — Venous blood specimen
• 122575003 — Urine specimen
• 258529004 — Throat swab
• etc. (see ProbenmaterialSnomedVS)

LDT FK 8428 (optional) adds German-specific material designation from the KBV LDT3 specification:

• EDTA-Blut — EDTA-Blut (venous blood in EDTA tube)
• Serum — Blutserum
• Urin-MSU — Mittelstrahl urine
• Abstrich — Swab / smear
• Liquor — Cerebrospinal fluid
• Stuhl — Stool sample

Both coding systems can coexist; SNOMED-CT is mandatory, LDT is optional. xDT adapters can map between the two at transformation time.

Integration with KBV Labor Befund

The kbv.mio.laborbefund (KBV MIO Laboratory Report) ImplementationGuide defines specimen handling for laboratory results in Germany. PraxisSpecimen is inspired by KBV_PR_MIO_LAB_Specimen but is not constrained to it because:

1. The KBV parent profile lacks a published snapshot in some package versions
2. PraxisSpecimen must remain PVS-agnostic — applicable to any ambulatory practice system, not tied to a specific MIO workflow
3. The profile uses the base FHIR Specimen resource as parent, ensuring broad compatibility

Refer to the KBV MIO Laboratory Report guide for context on laboratory workflow integration.

PVS Implementation Note

When capturing specimen information in a PVS:

1. Create a Specimen resource
2. Always populate type.coding[snomed] with the appropriate SNOMED-CT code
3. Optionally add type.coding[ldt] if the PVS maintains LDT material designations
4. Populate subject with a reference to the patient
5. Record collection metadata (collection.collectedDateTime, collection.method, collection.bodySite)
6. Container information (container.type) aids downstream laboratory processing
7. Validate the instance against PraxisSpecimen before transmission

Use Cases

1. Venous blood for laboratory analysis: SNOMED-CT 122555007 (Venous blood specimen) + LDT EDTA-Blut (EDTA-Blut), collected by venipuncture, in EDTA tube.
2. Urine culture: SNOMED-CT 122575003 (Urine specimen) + LDT Urin-MSU (Mittelstrahl urine), mid-stream collection.
3. Throat swab for microbiology: SNOMED-CT 258529004 (Throat swab), collected by swab technique from pharynx.

See examples: example-specimen-blut-edta, example-specimen-urin-msu, example-specimen-rachenabstrich.

PraxisLabObservation — Laborergebnisse mit LOINC/LDT-Codierung

The PraxisLabObservation profile extends the base FHIR Observation resource to standardize laboratory result documentation in German ambulatory practice. It is designed for in-practice and rapid laboratory testing with flexible result types (quantitative, qualitative, coded) and dual coding support for LOINC and LDT test identifiers.

Core Structure

Code Slicing — LOINC + LDT-Testkennung

The profile enforces flexible coding with at least one code slice present:

LOINC (Slice: loinc):

• System: http://loinc.org
• International standard codes (e.g., 4548-4 for HbA1c)
• Recommended where LOINC mappings exist

LDT FK 8420 (Slice: ldt):

• System: https://fhir.cognovis.de/praxis/NamingSystem/ldt-testkennungen
• German KBV LDT3 test identifiers (e.g., 03034000 for HbA1c)
• Supports practice-specific tests without LOINC mappings

Invariant praxis-lab-obs-code:

code.coding.where(system = 'http://loinc.org').exists() 
  OR code.coding.where(system = 'https://fhir.cognovis.de/praxis/NamingSystem/ldt-testkennungen').exists()

At least one coding slice must be present; severity is #error.

Result Value Types

The profile allows three forms of result representation:

1. Quantitative (valueQuantity): Numeric value with unit (UCUM).
   • Example: HbA1c = 6.1 %
   • Must comply with UCUM for unit system
2. Qualitative (valueString): Free text or predefined text result.
   • Example: "negativ" (negative), "Leukozyten: gering" (slight)
   • Used for rapid tests or text-based findings
3. Coded (valueCodeableConcept): Structured coded result.
   • Example: SNOMED-CT or local CodeSystem for presence/absence
   • Used when specific result codes are defined

Interpretation and Reference Ranges

Interpretation (MS):

• Binds to HL7 ObservationInterpretation ValueSet (extensible)
• Common codes: H (High), L (Low), N (Normal), NEG (Negative), POS (Positive)
• Maps to clinical judgment: abnormal high, abnormal low, normal, critical, etc.

Reference Range (MS):

• Both low and high bounds must use UCUM-constrained units
• System is fixed to http://unitsofmeasure.org
• Supports age-specific or gender-specific ranges via referenceRange.age (optional)

Integration with LDT/GDT

The profile is designed for xDT adapter workflows:

• LDT Result Mapping (Satzart 6310): Incoming results from LDT order/result systems map to PraxisLabObservation:
  • FK 8420 (test code) → code.coding[ldt]
  • FK 8421 (result value) → value[x] (Quantity, string, or CodeableConcept)
  • FK 8410 (collection date) → specimen.collection.collectedDateTime
  • FK 8450 (result interpretation) → interpretation
• GDT Device Reference: Lab analyzers (PraxisDevice) can be identified via device extension (future work)

Use Cases

1. Point-of-Care HbA1c: In-practice LOINC-coded quantitative result with reference range and high interpretation.
2. Rapid Urine Test: Qualitative (string) result "negativ", SNOMED-CT and LDT coding, no reference range.
3. Practice-Specific Rapid Test: LDT-only coding (no LOINC), quantitative result, typical when commercial rapid tests lack LOINC mappings.
4. Historical Lab Result: Imported lab result with both LOINC and LDT coding, full metadata (specimen, device, range).

PVS Implementation Note

When capturing lab results in a PVS:

1. Create an Observation resource of type PraxisLabObservation
2. Populate status as #final (or #preliminary if not yet verified)
3. Set category[laboratory] to the fixed laboratory code
4. Populate code.coding:
   • Add code.coding[loinc] if a LOINC mapping exists for the test
   • Add code.coding[ldt] if the test is identified by LDT FK 8420 code
   • At least one must be present
5. Set subject to Reference(Patient)
6. Populate effective[x] with the test date/time
7. Populate value[x] with the appropriate result type (Quantity, string, or CodeableConcept)
8. Add interpretation (e.g., #H, #L, #N) if provided by the analyzer or lab
9. If quantitative: populate referenceRange with normal range limits using UCUM units
10. If specimen was collected: Reference it via specimen = Reference(PraxisSpecimen)
11. Validate the instance against PraxisLabObservation before submission

Examples

• HbA1c (Quantitative): lab-obs-example-hba1c — LOINC + LDT coding, 6.1 %, high interpretation, EDTA-Blut specimen
• Urine Leukocytes (Qualitative): lab-obs-example-leukozyten-urin — LOINC + LDT coding, "negativ" result, normal interpretation
• Practice Rapid Test (LDT-only): lab-obs-example-ldt-only-custom — LDT coding only, quantitative in mg/dL, custom test without LOINC

See examples: lab-obs-example-hba1c, lab-obs-example-leukozyten-urin, lab-obs-example-ldt-only-custom.

PraxisLabDiagnosticReport — Laborbefund-Profil

The PraxisLabDiagnosticReport profile extends the base FHIR DiagnosticReport resource to standardize laboratory result reporting in German ambulatory practice. It supports multiple laboratory report variants (standard lab, microbiology, pathology) via category slices, and accommodates both single-point and cumulative reporting patterns through separate DiagnosticReport instances.

Core Structure

Category Slicing — LAB / MB / PAT

The profile enforces report classification via open slicing on category with three named slices:

LAB (Standard Laboratory):

• Fixed value: http://terminology.hl7.org/CodeSystem/v2-0074#LAB
• Use case: routine blood work, chemistry panels, routine urinalysis, blood cultures
• Example code: LOINC 58410-2 (CBC panel)

MB (Microbiology):

• Fixed value: http://terminology.hl7.org/CodeSystem/v2-0074#MB
• Use case: bacterial/fungal/viral identification, antibiogram, culture results
• Example code: LOINC 630-4 (Bacteria identified in Urine by Culture)

PAT (Pathology):

• Fixed value: http://terminology.hl7.org/CodeSystem/v2-0074#PAT
• Use case: histology, cytology, tissue diagnosis
• Example code: LOINC 60568-3 (Pathology Synoptic report)

Invariant praxis-lab-dr-category:

category.coding.where(system = 'http://terminology.hl7.org/CodeSystem/v2-0074' 
  and (code = 'LAB' or code = 'MB' or code = 'PAT')).exists()

At least one category slice must be present; severity is #error.

Report Variants Supported

1. Einzelbefund (Single-Point Report): A complete lab report from a single collection date.
   • One DiagnosticReport instance per specimen collection
   • Status typically #final
   • Common for acute workup or routine panel
2. Kumulativbefund (Cumulative Report): Multiple measurements of the same analyte over time.
   • Represented as separate DiagnosticReport instances, one per time point
   • All instances reference the same test code (e.g., LOINC 4548-4 for HbA1c)
   • Same patient, different effectiveDateTime values
   • Allows practices to display trend data by querying all DiagnosticReports for that code
   • No special FHIR grouping mechanism needed — temporal ordering is implicit
3. Mikrobiologie (Microbiology Report): Culture and sensitivity results.
   • Category slice [mb] set to #MB
   • Results include organism identification + antibiogram
   • PraxisLabObservation results use SNOMED-CT or coded interpretation
4. Pathologie (Pathology/Histology Report): Tissue diagnosis.
   • Category slice [pat] set to #PAT
   • presentedForm typically contains detailed PDF report
   • May include gross description + microscopic findings + diagnosis conclusion

Reference Constraints

Specimen References:

• specimen must reference only PraxisSpecimen resources
• Multiple specimens allowed (e.g., serum + urine in same panel)

Result References:

• result must reference only PraxisLabObservation resources
• Each Observation should match the category of the report (e.g., microbiology Observations for MB category)

Cumulative Reporting Pattern

For practices tracking longitudinal trends (e.g., quarterly HbA1c, monthly INR):

1. Create a new DiagnosticReport instance for each measurement date
2. Use the same test code (LOINC) in all instances
3. Vary only effectiveDateTime and issued
4. Link via basedOn references if part of a managed condition (e.g., diabetes follow-up order)
5. Query pattern: GET /fhir/DiagnosticReport?code=4548-4&subject=Patient/123&sort=-date

This pattern avoids FHIR-level grouping complexity and relies on clients to assemble trends via code + date filtering.

Use Cases

1. Routine Blood Panel (LAB): Complete blood count with differential, chemistry panel, single collection.
2. Urine Culture (MB): Bacterial culture with organism identification and antibiogram; multiple result Observations.
3. Skin Biopsy Histology (PAT): Tissue diagnosis (basal cell carcinoma); presentedForm contains detailed pathology PDF.
4. HbA1c Trend (LAB, Kumulativbefund): Three DiagnosticReport instances for Q1, Q2, Q3 with same code but different dates.
5. Partial Result (LAB, preliminary): Early report while additional tests are in progress; status #preliminary, no presenter form yet.

PVS Implementation Note

When capturing lab reports in a PVS:

1. Create a DiagnosticReport resource of type PraxisLabDiagnosticReport
2. Set status to #final (for complete reports) or #preliminary (for partial/early reports)
3. Populate category:
   • For routine/blood/chemistry: use category[lab]
   • For cultures/microbiology: use category[mb]
   • For histology/tissue: use category[pat]
   • At least one category slice must be present
4. Set code to the report code (typically LOINC, e.g., 58410-2 for CBC)
5. Set subject to Reference(Patient)
6. Populate effective[x] with specimen collection date as dateTime
7. Populate issued with report authorization/release date
8. Link result to all relevant PraxisLabObservation resources
9. Link specimen to all relevant PraxisSpecimen resources
10. Add resultsInterpreter Reference for the responsible physician
11. Optionally add conclusion with clinical summary or interpretation
12. If report is attached (PDF): add presentedForm with contentType + URL or base64
13. For cumulative reports: create separate DiagnosticReport instances per date (not grouped in one instance)
14. Validate the instance against PraxisLabDiagnosticReport before submission

Examples

• CBC (Blutbild) Einzelbefund: example-lab-dr-blutbild — LAB category, LOINC 58410-2, final status, EDTA blood specimen
• Urine Culture Mikrobiologie: example-lab-dr-urinkultur — MB category, E. coli with antibiogram, final status
• Skin Histology Pathologie: example-lab-dr-histologie — PAT category, basal cell carcinoma diagnosis, PDF report, final status
• Kreatinin Preliminary: example-lab-dr-preliminary — LAB category, preliminary status (result not yet complete)
• HbA1c Kumulativbefund Q1: example-lab-dr-hba1c-jan — LAB category, final, Q1 2026 date
• HbA1c Kumulativbefund Q2: example-lab-dr-hba1c-apr — LAB category, final, Q2 2026 date (demonstrates trend pattern)
• HbA1c Kumulativbefund Q3: example-lab-dr-hba1c-q3 — LAB category, final, Q3 2026 date (completes quarterly series)

See examples: example-lab-dr-blutbild, example-lab-dr-urinkultur, example-lab-dr-histologie, example-lab-dr-preliminary, example-lab-dr-hba1c-jan, example-lab-dr-hba1c-apr, example-lab-dr-hba1c-q3.

Note on Resource Choice

The choice of base resource follows FHIR R4 semantics:

• Contract for RLV budgets: Contract represents a binding agreement between KV and physician — the budget allocation is exactly that.
• Basic for KV benchmarks: Benchmark data has no natural FHIR resource; Basic is the designated catch-all.
• PaymentReconciliation for Honorarbescheid: This normative R4 resource represents payment advice from a payer, which is the function of the Honorarbescheid.
• Provenance for AI tracking: Provenance records "who did what" — an AI system generating content is a provenance event.
• Device for medical equipment: Device is the FHIR R4 standard resource for medical instruments, analyzers, and other equipment used in clinical care. The PraxisDevice profile constrains it for German ambulatory practice with GDT integration.