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

Care Coordination, Plans, and Authorization

Care Coordination, Plans, and Authorization

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.

Shared payer-authorization lifecycle

FHIR Praxis DE uses one prior-authorization pattern:

  1. a clinical ServiceRequest or CarePlan;
  2. a PASClaimDE-derived request linked to a ServiceRequest through Claim.referral or to a CarePlan through the named supporting-information slice;
  3. a PASClaimResponseDE-derived decision linked through ClaimResponse.request; and
  4. a PASTaskDE-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.

Rehabilitation participation (e56)

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;
  • request, response, and task have distinct business identifiers;
  • the task input and output preserve the PAS correlation; and
  • payer approval and rejection remain independent of 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.

Domain treatment plans (e27, e62C, e70, and e70A)

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; and
  • AssistedReproductionFollowUpPlanDE for e70A.

e70A lifecycle

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.

Treatment-plan terminology

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:

Longitudinal coordinated-care orders

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.

Coordinated-care terminology disposition

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 repository baseline. Therefore ServiceRequest.code remains open and examples use text. Implementations may add system-qualified contract codes without changing the shared graph.

Source and envelope boundary

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:

  • normative e12/e26/e56/e62B/e63/e64 document envelopes and rendering;
  • payer-specific submission operations and signatures;
  • contract-specific service and decision-reason vocabularies; and
  • billing rules or automatic eligibility decisions.

Sources: