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

Plan-Library vs. Rule-Execution Boundary

Plan-Library vs. Rule-Execution — IG Boundary

This Implementation Guide deliberately separates two concerns that share the same code-systems (EBM, GOÄ, BEMA, HZV) but operate on different semantic axes:

• Plan-Library — declarative, forward-directed templates ("what belongs together"): PlanDefinition, ActivityDefinition, CarePlan, EpisodeOfCare. This IG publishes the FHIR exchange and library contract for those resources. Ownership is layered: source systems and adapters provide evidence, catalog, and contract context; curated macros and Jobs are owned by the curated practice-library layer; producers and consumers exchange conformant Plan-Library resources. Adapters are not masters of curated Jobs.
• Rule-Execution — imperative validation ("what violates and when"): rule definitions, frequency limits, faktor-limits, Kassen-/Quartals-Constraints. Lives in downstream rule-execution services, not in FHIR.

The normative boundary and decision tables are in Architecture Overview.

Slots intentionally NOT populated

The following FHIR slots are out-of-profile-scope by intent in this IG and in conformant plan-library resources exchanged under this contract. Profile descriptions and validators MUST NOT treat them as semantically meaningful:

Resource	Slot	Reason
PlanDefinition	action.condition	Rule semantics live outside the IG, not in FHIR
PlanDefinition	action.input.condition	Same
PlanDefinition	action.dynamicValue	Same
PlanDefinition	library (rule-bearing CQL)	Descriptive uses still allowed; rule libraries excluded
ActivityDefinition	dynamicValue	Same
ChargeItemDefinition	applicability	Same

Consumers MUST NOT expect these slots to carry validation semantics.

Executable Job input/output binding is not carried in those slots. Per the accepted practice-workflow decision, Jobs bind answers to candidate outputs through a versioned HL7 SDC StructureMap referenced from the Job Questionnaire. That StructureMap is a separate artifact and is not a license to populate PlanDefinition computability slots.

Concept layers (catalog, contract, macro, Job)

Plan-library consumers MUST distinguish:

Layer	Carrier	Meaning
Billing catalog entry	ChargeItemDefinition (PraxisChargeItemDefinitionDE)	One billable code/rule
Authoritative contract applicability	Contract / regime / effectivePeriod evidence	Which codes a contract covers
Curated billing macro	PraxisBillingMacro	Normally billed codes for a situation (recommendation only)
Workflow template / Job	PraxisWorkflowDefinition + PraxisWorkflowInputQuestionnaire + StructureMap	Multi-output knowledge with typed inputs

topic codes from praxis-plan-topic remain a discovery aid (chain, job, …). They are not a substitute for the macro/Job profiles.

Billing activities are contract/version-specific

PraxisBillingActivity instances referenced from macros/Jobs MUST carry versioned ActivityDefinition.url|version and pin an exact versioned ChargeItemDefinition (url|version) for the resolved contract/regime. Unversioned CID pins and code-inferred CIDs are forbidden. Legacy PraxisBillingPattern stopfield/activity shapes remain readable during migration only.

Legacy PraxisBillingPattern (deprecated)

PraxisBillingPattern remains readable and is marked deprecated. Existing instances with stopfields continue to parse for migration. New macros and Jobs MUST NOT use it as the write target.

Migration guidance:

• Curated topic=chain plans → PraxisBillingMacro
• topic=job plans with stopfields → PraxisWorkflowDefinition + Questionnaire linkIds + versioned StructureMap
• Stopfields → Questionnaire items; do not extend stopfields as the successor model
• Never infer ChargeItem.service from matching billing codes

Filter examples:

• Macros: meta.profile = .../praxis-billing-macro
• Jobs: meta.profile = .../praxis-workflow-definition
• Legacy dual-read: meta.profile = .../praxis-billingpattern during migration only

Specialty and venue eligibility (useContext)

PraxisWorkflowDefinition and PraxisBillingMacro share one interpretation of PlanDefinition.useContext (ADR-010):

Axis	Code	Value	Rule
Eligible specialty	usage-context-type#user	CodeableConcept	Published system-qualified specialty coding (preferred: KBV BAR2-WBO). Matching is by system + code, never display. Zero, one, or many specialties are allowed.
Concrete venue	usage-context-type#venue	Reference(Organization)	Explicitly curated organization scope. Not a Location/CodeableConcept stand-in.

Specialty-to-organization resolution (for example correlating current PractitionerRole.specialty with PractitionerRole.organization) is non-authoritative candidate generation. It must preserve evidence and as-of time, honor contract/effective-date inputs, and require curator confirmation before concrete #venue references are published. No eligible specialty, no matching current role, ambiguous coding, or missing organization relation fails closed to no candidate venue. Source-system ownership, mandate, or tenant fields are never an authorization source for venue publication.

Specialty evidence never replaces contract-specific ChargeItemDefinition resolution (code system + code + contract/regime + service date). Job invocation never creates or proves a rendered service or billability.

What the Plan-Library DOES express

• Relationships between activities — PlanDefinition.action.relatedAction for "A implies B" chains
• Plan structure — nested actions, ordering, grouping
• Catalog references — action.definitionCanonical → ActivityDefinition → ChargeItemDefinition
• Typed Job inputs — Questionnaire linkIds on PraxisWorkflowInputQuestionnaire
• Executable Job binding — SDC targetStructureMap → versioned StructureMap producing in-memory candidate graphs
• Plan metadata — topic, useContext (specialty/venue per ADR-010), identifier, status, version
• Action-section markers — optional display/discovery labels via praxis-plan-section; never an adapter-enforced three-section schema and never an output-binding channel

Rendered-service lineage (v1)

When a materialized charge has documented rendered services, ChargeItem.service references each exact service resource (n:m). Allowed targets are the R4 ChargeItem.service Reference types. ChargeItem.context identifies Encounter/EpisodeOfCare; definitionCanonical records the applied ChargeItemDefinition. Missing performance evidence leaves service absent — it never triggers reverse inference from codes.

Rule derivation is explicit and versioned

When a downstream rule engine derives a RuleDefinition from a plan-library resource, the derivation is recorded via Provenance with target = derived RuleDefinition and entity[].what = source PlanDefinition canonical+version. The derived rule must reference the source plan URL and version, be re-runnable when the source plan changes, and carry a versioned meta.versionId on each regeneration. Implicit derivation without provenance is not allowed.