This Implementation Guide deliberately separates two concerns that share the same code-systems (EBM, GOÄ, BEMA, HZV) but operate on different semantic axes:
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.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 (PraxisChargeItemDefinitionDE) |
applicability |
The base catalog profile carries no rule semantics; typed declarative rules use the dedicated PraxisBillingRuleChargeItemDefinition profile |
Consumers MUST NOT expect these Plan-Library 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.
The dedicated billing-rule contract is a separate boundary. Relational and
aggregate rules use PraxisBillingRuleSetLibrary; typed declarative code-local rules use the closed modifier-extension slices of
PraxisBillingRuleChargeItemDefinition.applicability. Executable expressions,
FHIRPath, CQL, and arbitrary modifier extensions remain forbidden. See
Billing-Rule Exchange Contract.
Plan-library consumers MUST distinguish:
| Layer | Carrier | Meaning |
|---|---|---|
| Billing catalog entry | ChargeItemDefinition (PraxisChargeItemDefinitionDE) |
One billable code |
| Billing rule definition | PraxisBillingRuleSetLibrary or PraxisBillingRuleChargeItemDefinition |
Source-neutral, versioned rule exchange; not a macro or Job |
| 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.
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.
PraxisBillingPattern remains
readable for stored resources but is not an authoring contract. Authored content
uses PraxisBillingMacro or PraxisWorkflowDefinition with Questionnaire
linkIds and a versioned StructureMap. Never infer ChargeItem.service from
matching billing codes.
useContext)PraxisWorkflowDefinition and
PraxisBillingMacro share one
interpretation of PlanDefinition.useContext:
| 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.
PlanDefinition.action.relatedAction for "A implies B" chainsaction.definitionCanonical → ActivityDefinition → ChargeItemDefinitionlinkIds on PraxisWorkflowInputQuestionnairetargetStructureMap → versioned StructureMap producing in-memory candidate graphstopic, useContext (specialty/venue), identifier, status, versionWhen 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.
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.