Seiteninhalt:
This page documents reusable record-level contracts for Annex 2b care coordination. The profiles support persistence, query, and graph validation. They are not normative form Bundles, payer wire protocols, Fachdienst APIs, signature profiles, or billing-eligibility rules.
PraxisProgramEnrollment is the one Core-derived EpisodeOfCare contract for
ambulatory HZV and DMP enrollment. It requires exactly one program type, bound
to PraxisProgramEnrollmentVS. The ValueSet includes the complete official KBV DMP
CodeSystem and adds the Praxis HZV discriminator; it does not copy KBV concepts,
displays, filters, or expansions. The historic KBV Coding version remains part of
the source fact: an adapter preserves a 1.06 generic obesity Coding verbatim and
must not default or rewrite it to a 1.07 Coding.
Core patient, status, period, statusHistory, careManager,
managingOrganization, and identifier retain their native EpisodeOfCare
meaning. In particular, an identifier is optional. hvg-datum-beantragt remains
an optional independent request-date fact; it is neither an enrollment status nor
an enrollment period substitute.
The released Praxis DMP/HZV participation CodeSystems and ValueSet, the
hzv-participation, hzv-einschreibedatum, hzv-abmeldedatum, and
hzv-rechnungsschema extensions, and the parallel HZV Flag representation are
not published in this package version. Emitters move each enrollment to
PraxisProgramEnrollment: use the Core status and period fields for lifecycle,
set exactly one program type, retain hvg-datum-beantragt only when the request
date is known, and link clinical contacts through Encounter.episodeOfCare.
Consumers that still resolve a removed canonical must keep the earlier released
Praxis package installed during their migration; removed canonicals have no
element-for-element successor resource in this package.
The retired local DMP enumeration is not reproduced in this package. Emitters use the official KBV DMP CodeSystem and preserve the source Coding system, version, and code; they must not infer a newer KBV version, a replacement code, or a program subtype from a local legacy label.
For HZV, the old participation state eingeschrieben maps to
EpisodeOfCare.status = active; its old enrollment date maps to period.start.
The old abgemeldet state maps to status = finished and its withdrawal date
to period.end. hzv-rechnungsschema does not move to the enrollment: retain
the contract destination on the HZV Coverage used by the billing case.
gesperrt and auslaufend have no safe one-to-one Core lifecycle mapping.
An adapter must not infer onhold, finished, or a period end from either
legacy state without source evidence. Likewise, a missing old enrollment or
withdrawal date must remain absent rather than being synthesized. The legacy
DMP codes represented only a subset of historical programs; compound programs
and the generic obesity Coding have no element-for-element local-code predecessor.
FHIR Praxis DE uses one prior-authorization pattern:
ServiceRequest or CarePlan;PASClaimDE-derived request linked to a ServiceRequest through
Claim.referral or to a CarePlan through the named supporting-information
slice;PASClaimResponseDE-derived decision linked through
ClaimResponse.request; andPASTaskDE-derived workflow carrier with typed request and response
references.Task completion records that the workflow activity finished. Approval,
partial approval, and rejection remain payer decisions in the
ClaimResponse, never task states.
A successfully processed rejection uses ClaimResponse.outcome = complete
with item-level adjudication containing a zero eligible value and a coded
domain decision reason. outcome = error is reserved for processing or
submission failures. A PAS task may exist without a response while payer
review is still in progress; its response output appears when the decision is
available.
RehabilitationParticipationRequestDE represents the clinical request for
rehabilitation sport or function training. It requires a business identifier,
patient, requester, authored date, clinical reason, and coverage. Its three PAS
profiles derive from the shared authorization contract and narrow every
reference to the e56 graph.
The published approval and rejection examples are non-normative collection Bundles. They prove:
Claim.referral references the clinical request;ClaimResponse.request references the claim;Task.status.The profile deliberately does not bind ServiceRequest.code or
Claim.item.productOrService to a local rehabilitation-service catalog.
Annex 2b identifies e56 and the distinction between rehabilitation sport and
function training, but no authoritative, versioned national FHIR value set for
the detailed services was identified. Implementations may send
system-qualified codes from an applicable contract or text while that
computability gap remains open.
The abstract DomainTreatmentPlanDE profile derives from
PraxisCarePlanDE. It makes the shared query contract required:
| Element | PraxisCarePlanDE |
Domain treatment-plan contract | Reason |
|---|---|---|---|
| Patient, status, and intent | Patient and status are required; intent is fixed to plan |
Reused unchanged | These are already stable and domain-neutral |
| Plan type | Required slice bound to PraxisCarePlanTypeVS |
Each thin profile fixes one source-versioned Annex 2b domain code | Queryable form/domain identity without a service catalog |
| Identifier | Must Support | 1..* |
Versions need a stable business identity |
| Title, period, created date, and author | Optional or Must Support | Each is 1..1 |
A versioned plan needs an authored scope and period |
| Goals and activities | Optional | Each is 1..*; every activity uses the standard CarePlan detail-or-reference rule |
The four forms are goal- and activity-bearing plans |
| Supporting information | Must Support | 1..*, narrowed to clinical evidence and documents |
Findings remain referenced, not copied into plan text |
| Replacement | Base R4 element | e70A requires exactly one prior e70 or e70A plan | One explicit successor convention |
The thin profiles add only their discriminator and, for e70A, the replacement rule:
SociotherapySupportPlanDE for e27;OutpatientIntensiveCareTreatmentPlanDE for e62C;AssistedReproductionTreatmentPlanDE for e70; andAssistedReproductionFollowUpPlanDE for e70A.R4 CarePlan.replaces is the only predecessor link used by this contract. An
e70A follow-up is a new CarePlan resource with a new business identifier. It
references exactly one prior e70 or e70A plan. The prior plan remains available
for history and normally moves to completed, revoked, or another accurate
native CarePlan status; partOf is not used as a version link.
The published positive example links e70A to e70. A negative fixture omits
replaces and is checked against the generated differential requiring
CarePlan.replaces with minimum cardinality one.
Annex2bCareDomainCS provides only the e27/e62C/e70/e70A plan discriminators,
versioned to the Annex 2b source date. Detailed sociotherapy activities,
outpatient-intensive-care goals, and assisted-reproduction procedures remain
unbound because no authoritative, versioned FHIR value sets were identified
for these profile slots. Implementations may use system-qualified codes from an
applicable contract while retaining text. The profiles do not encode treatment
eligibility, decision logic, or executable rules.
Relevant authoritative source boundaries are:
CoordinatedCareRequestDE applies the stable order/plan boundary from the
gemF_VO_HKP 1.0.0 crosswalk to all five cluster members. It requires the
business identifier, patient, authored order, care period, requester,
performer, diagnosis, care plan, insurance, and supporting information. Each
thin profile fixes only its Annex 2b discriminator and documented deviations:
| Form | Thin profile | Difference from the e12 baseline |
|---|---|---|
| e12 home nursing | HomeNursingRequestDE |
Uses the HKP correction convention: a new ServiceRequest version uses replaces and retains the common business identifier |
| e26 sociotherapy | SociotherapyOrderDE |
Narrows basedOn to SociotherapySupportPlanDE; no payer workflow is asserted by this profile |
| e62B outpatient intensive care | OutpatientIntensiveCareOrderDE |
Narrows basedOn to OutpatientIntensiveCareTreatmentPlanDE |
| e63 SAPV | SAPVOrderDE |
No profile-level difference beyond the Annex 2b discriminator |
| e64 preventive care | PreventiveCareOrderDE |
No profile-level difference beyond the Annex 2b discriminator |
The shared parent permits device context and family context through
supportingInfo, and permits an organization, practitioner role, healthcare
service, or CareTeam as performer. These are cluster-wide capabilities, not
form-specific constraints.
The e12 authorization leg derives HomeNursingPASClaimDE,
HomeNursingPASClaimResponseDE, and HomeNursingPASTaskDE from the shared PAS
profiles. Claim.referral points to the current home-nursing order, the named
care-plan supporting-information slice points to its plan,
ClaimResponse.request points to the claim, and the task preserves the typed
claim/response correlation. The examples use an approved response, but approval
remains an adjudication outcome and never a ServiceRequest or Task status.
One non-normative collection Bundle per form proves the complete reference graph. These Bundles are test fixtures and examples; they are not Annex 2b documents, signed submissions, payer messages, or Fachdienst payloads.
Annex2bCareDomainCS provides source-versioned form/domain discriminators only.
The e12 measure catalog and line semantics remain assigned to the responsible
BMV-A/GKV information models by gemF_VO_HKP; authoritative versioned FHIR
value sets for sociotherapy services, outpatient intensive-care measures, SAPV
services, and e64 preventive-care indications were not identified in the
declared public dependencies. Therefore ServiceRequest.code remains open and examples
use text. Implementations may add system-qualified contract codes without
changing the shared graph.
Annex2bCareDomainCS is versioned to the Annex 2b source date and provides only
stable form/domain discriminators. Its codes do not establish clinical
eligibility, approved quantities, performer qualification, or billability.
The following remain outside these profiles:
Sources: