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
This page documents the normative architecture decisions that shape the design of this Implementation Guide. Published IG pages are self-contained contracts; decision outcomes are stated here rather than delegated to internal repository documents.
| Status: Accepted | Date: 2026-07-28 |
PASClaimDE, PASClaimResponseDE, and PASTaskDE form the shared,
domain-neutral payer-authorization lifecycle. Downstream domains derive thin
profiles: the claim links to a clinical ServiceRequest through referral and
may link to a CarePlan through the named
supportingInfo[carePlanReference] slice; the response links to the claim
through request; and the task carries both through its named input and output
slices.
FHIR Praxis DE owns the shared lifecycle and PAS task terminology. The
consuming implementation guide owns domain services, indications, reasons, and
additional constraints. Task completion is never interpreted as payer
approval; the decision remains in ClaimResponse.outcome and item
adjudication.
Compatibility is additive: compatible downstream changes narrow references, add Must Support or cardinality requirements, and add open slices. Changing a shared element's role, removing a code, or closing an open slice is breaking and requires a shared-contract version change.
| Status: Accepted | Date: 2026-07-28 |
Dental administration uses separate carriers for separate facts: ZANR on
Practitioner.identifier, chamber qualifications on
Practitioner.qualification, the current organization and site on
PraxisPractitionerRoleDE, and practitioner- or site-bound approval evidence
on Praxis-owned Basic resources. Patient-specific payer decisions remain in
derived PAS profiles.
Identity, qualification, role, approval evidence, and computed billing eligibility must not be collapsed into a broad dental authorization code system. Approval evidence records issuer, period, subject, location or organization scope, and source evidence; downstream billing services calculate eligibility without persisting it as another authorization fact.
| Status: Accepted | Date: 2026-07-27 |
This IG uses the official gematik DiPagRechnung profile in
de.gematik.dipag#1.0.8 directly. DiPag is the exchange contract for digital
patient invoices, including GOAE, GOAE-new, and GOZ invoices. The redundant
PraxisInvoiceDE canonical was removed.
Specialty IGs can derive directly from DiPagRechnung and add only justified
specialty restrictions, such as narrowing invoice line references to a dental
ChargeItem profile. They must not redefine DiPag monetary semantics.
The former Praxis invoice-level tax category, exemption reason, and
Kleinunternehmer notice flag are not part of the invoice contract. Optional tax
category and exemption defaults remain only on
ChargeItemDefinition.propertyGroup.priceComponent; the invoicing system uses
them as input when calculating the final DiPag invoice.
| Status: Accepted | Date: 2026-05-18 |
Summary: The IG treats KBV AW-SST/PVS-AWS as a semantic crosswalk target for
archive and system-change export, not as a profile parent layer. Local profiles
must not derive from KBV_PR_AW_*, and kbv.ita.aws remains outside direct
package dependencies. The main implementation follow-up is an AW-aligned local
Claim profile set while preserving the local ChargeItem/Claim/Invoice
separation.
Crosswalk: AW-SST Crosswalk
| Decision | Rationale |
|---|---|
| No AW parent inheritance | AW-SST is archive/export-shaped and would remove needed live-workflow semantics |
No direct kbv.ita.aws dependency |
The published package stack is older than this IG stack and is not needed for local validation |
| AW as crosswalk target | AW-SST remains the official semantic reference for PVS archive/change export |
| Claim implementation required | AW's preliminary/final Claim split is useful and should be reflected in local billing Claim profiles |
| Scope kept narrow | Follow-up is tracked as one AW bead, not a broad profile-harmonization program |
| Status: Accepted | Date: 2026-04-27 | Amended: 2026-07-20 |
Summary: The IG separates Plan-Library resources (PlanDefinition, ActivityDefinition, CarePlan)
from downstream Rule-Execution services. Computability slots (condition, applicability,
dynamicValue) are intentionally not populated in plan-library resources. Executable Job
input/output binding uses a versioned HL7 SDC StructureMap (separate artifact), not those slots.
| Decision | Rationale |
|---|---|
| Plan-Library in FHIR | Declarative, forward-directed templates belong in FHIR with mature profile support |
| Rule-Execution outside the IG | Billing validation rules are not necessarily CQL-shaped; operational stores can meet performance targets |
| No CPG adoption | EBM/BEMA/HZV rules are quartalsbezogen and Kassen-specific — not mappable to CQL phenotypes |
| Distinct macro and Job profiles | PraxisBillingMacro and PraxisWorkflowDefinition replace single-carrier PraxisBillingPattern for new content; topic remains discovery-only |
Specialty and venue on useContext |
#user = eligible specialty (system+code); #venue = curated Organization reference; resolution is advisory and curator-confirmed (ADR-010) |
| SDC StructureMap binding | Deterministic, versioned QuestionnaireResponse → candidate graph without proprietary binding DSL |
Explicit ChargeItem.service lineage |
n:m rendered-service links are authored; never inferred from billing codes |
No hkp-status extension |
Da Vinci PAS dual-lifecycle (CarePlan + Claim/ClaimResponse) is already present since v0.40.0 |
PraxisBillingMacro, PraxisWorkflowDefinition, workflow Questionnaire + StructureMap; legacy PraxisBillingPattern deprecated for read compatibility