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

Profiles

Profiles

Annex 2b independent resource contracts

The assessment/attestation, device-order, and non-prescription medication recommendation profiles are documented together on Annex 2b Independent Resource Contracts. The crosswalk explains why QuestionnaireResponse/DiagnosticReport/ Composition, VisionPrescription/DeviceRequest, and MedicationRequest remain separate resource families.

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 coverage routing, laboratory exchange, billing, and related ambulatory workflows. Demographic, diagnosis, procedure, allergy, and device resources inherit the KBV base profiles directly per ADR-008 (KBV-Basis als Fundament) — see the inheritance architecture page.

Extended Resources by Domain

Billing / Abrechnung

Practice workflow migration and lineage rules: Plan-Library vs. Rule-Execution Boundary.

Budget / RLV

Remittance / Honorarbescheid

Clinical

PraxisImmunization — optional target disease

PraxisImmunization remains a profile on base FHIR Immunization, not a KBV MIO Immunization profile. protocolApplied and protocolApplied.targetDisease are Must Support but preserve their base 0..* cardinalities, so historical records without evidenced target diseases remain conformant. When a target disease is supplied, it must be coded from https://fhir.kbv.de/ValueSet/KBV_VS_MIO_Vaccination_TargetDisease|1.1.0 with required binding strength. A legal-documentation workflow using KBV MIO Record_Prime or Record_Addendum may impose mandatory target-disease requirements independently of this generic profile.

Administrative

Diagnoses — KBV_PR_Base_Condition_Diagnosis (Directly)

Diagnoses are recorded on KBV_PR_Base_Condition_Diagnosis directly. Per ADR-008 (KBV-Basis als Fundament) the former Praxis-specific Condition wrappers were dissolved: the asserter/evidence constraints were not sourced from the PVS (the recorder is set instead), and the Dauerdiagnose flag is carried by the local DauerdiagnoseExt boolean marker on the open Condition.extension slot — a marker semantically aligned with, and a 1:1 crosswalk to, the WeST istDauerdiagnose extension (mirrored, not a WeST package dependency).

KBV base already carries the German diagnosis requirements needed for KV billing (KVDT 6.06):

• ICD-10-GM coding (BfArM CodeSystem)
• Diagnosesicherheit (A/G/V/Z) via the upstream http://fhir.de/StructureDefinition/icd-10-gm-diagnosesicherheit extension — required by the KV on billing claims
• Seitenlokalisation and Mehrfachcodierungskennzeichen

The KVDT diagnosis-certainty semantics map to Condition status as follows:

PVS systems must populate the Diagnosesicherheit on every diagnosis before submitting the claim to the KV. See the Claim Diagnosis Contract for how these Conditions project onto Claim.diagnosis.

Other Resources on KBV Base Directly (ADR-008)

The following resources also dropped their Praxis* wrappers and now use the KBV base profile directly. See the inheritance architecture page for the full rationale.

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.

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, 20 = 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.5.4 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
• 119364003 — Serum specimen
• 258450006 — Cerebrospinal fluid specimen
• 119339001 — Stool specimen
• 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 (KBV_PR_Base_Device) 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

PraxisTherapeuticRemedyDE — Heilmittelverordnung (Muster 13)

The PraxisTherapeuticRemedyDE profile models a German statutory Heilmittelverordnung (therapeutic remedy prescription, form Muster 13) as a ServiceRequest with intent = order. This is a remedy order — prescribing physiotherapy, occupational therapy, speech therapy, podiatry, or nutritional therapy — and is intentionally distinct from PraxisReferralDE (reusable incoming or outgoing referral) and from laboratory or imaging ServiceRequest variants.

Terminology dependencies: de.cognovis.terminology.heilmittel (gevko EVO_VS_HLM_* mirror) and de.cognovis.terminology.kbv (KBV_VS_SFHIR_HM_DIAGNOSEGRUPPE). See example-therapeutic-remedy-physio for a complete instance.

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. Per ADR-008 devices use KBV_PR_Base_Device directly; the GDT-8402 Gerätekennung is carried as Device.identifier (system gdt-device-id).