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 defines two related but distinct request contracts:
The contracts deliberately share standard FHIR elements instead of introducing an
IG-wide generic ServiceRequest parent. A source-level RuleSet keeps identical
cardinalities aligned for the concrete episodic profiles, while profile inheritance
is used only where the domain meaning is genuinely narrower.
PraxisLabServiceRequestDE is the single reusable laboratory-order model. A
PraxisCervicalScreeningServiceRequestDE is a derived laboratory order, not a
parallel e39 order model.
| Concern | Shared representation | Screening specialization |
|---|---|---|
| Stable order identity | required identifier[placerOrderId] with V2-0203 PLAC, system, and value; identity is the namespaced (system, value) tuple |
inherited unchanged |
| Patient and ordering party | subject, requester |
inherited unchanged |
| Intended laboratory | performer |
inherited unchanged |
| Requested test | code, permitting LOINC and versioned local laboratory catalogs |
purpose-specific extensible order binding |
| Indication | optional Must Support reasonReference to Condition |
inherited unchanged |
| Insurance | optional Must Support insurance to Coverage |
inherited unchanged |
| Specimen | optional ServiceRequest.specimen to PraxisSpecimen, because an order can precede collection |
narrowed to PraxisCervicalScreeningSpecimenDE when supplied |
| Result to order | DiagnosticReport.basedOn targets ServiceRequest; Observation.basedOn retains all base R4 workflow targets, with PraxisLabServiceRequestDE preferred locally |
both required and narrowed to the screening order |
| Specimen to order | Specimen.request |
required on the screening specimen |
The laboratory proof Bundle
example-lab-request-result-bundle contains one order, specimen, observation,
report, and every locally referenced supporting resource. The screening proof
Bundle example-cervical-screening-bundle demonstrates the same closed graph
with the narrower e39 profiles.
The IG does not prescribe one global identifier system. The required
placerOrderId slice identifies the order identifier by its V2-0203 PLAC
type, while FHIR identity remains the pair of an issuer-controlled
Identifier.system and its Identifier.value. Different practices,
laboratories, and referral systems therefore retain their own namespaces, and
additional identifiers remain allowed. Results correlate to the order through
basedOn rather than copying the order identifier into a result-side
identifier.
These are non-normative collection Bundles. They do not replace the PDF/A transport required for Annex 2b e10, e10A, or e39, and they do not claim conformance to an unreleased MIO Laborbefund package.
The G-BA organized cervical cancer screening program is the program source. It distinguishes annual cytology for ages 20 through 34 from three-year HPV and cytology co-testing from age 35.
| Semantic | Source and version | Disposition |
|---|---|---|
| Cytology and HPV order concepts | LOINC 2.82, verified through CodeSystem/$lookup on 2026-07-28 |
selected concepts in CervicalScreeningOrderCodeVS; extensible binding |
| Cytology and HPV observation concepts | LOINC 2.82, verified through CodeSystem/$lookup on 2026-07-28 |
selected concepts in CervicalScreeningObservationCodeVS; extensible binding |
| Cervical cytology report concept | LOINC 2.82, verified through CodeSystem/$lookup on 2026-07-28 |
selected concept in CervicalScreeningReportCodeVS; extensible binding |
| Uterine-cervix specimen | SNOMED CT International 2025-02-01, code 119395005; also present in the IPS result specimen ValueSet |
required on the screening specimen |
| German screening-program classification | G-BA program page, accessed 2026-07-28 | conveyed by the screening profile canonical; no unofficial national code invented |
| Laboratory-local order identifiers and catalog codes | ordering and performing systems' versioned namespaces/catalogs | permitted; examples use example.org only |
PraxisReferralDE now supports both incoming and outgoing reusable referral
records. PraxisSociotherapyIndicationReferralDE derives from it because e28 is
an indication referral. Hospital admission and patient transport are separate
thin ServiceRequest profiles because their intended performers and clinical
meaning are not referral specializations.
| Consumer requirement | Previous reusable element | Change |
|---|---|---|
| Stable order identity | identifier was unconstrained |
require one typed placer-order identifier with system and value; permit additional identifiers |
| Assignment type | no dedicated element contract | optional Must Support category with an extensible binding to ReferralAssignmentTypeVS; required and fixed for the e28 specialization |
| Structured diagnoses | reasonCode only documented |
make reasonReference to Condition optional Must Support; keep reasonCode optional |
| Structured findings and attachments | not constrained | mark supportingInfo and restrict it to clinical findings, reports, documents, or conditions |
| Urgency | base element only | optional Must Support priority; an importer does not invent urgency when the source form omits it |
| Ordering party | requester was optional | require requester |
| Referral recipient | only performerType was highlighted |
require target performer; retain performerType for specialty |
| Authored date and validity | optional Must Support | require authoredOn; keep occurrence[x] optional Must Support because sparse inbound forms may not state a validity period |
| Coverage context | unconstrained | make insurance to Coverage optional Must Support |
| Existing inbound optimization data | optional extensions | retained unchanged and optional |
ReferralAssignmentTypeCS is a local interoperable code system derived
from the assignment choices represented on current
KBV Muster 6.
It does not claim to be an official KBV code system.
| Form | Profile | Reused semantics | Domain-specific disposition |
|---|---|---|---|
| e02 hospital admission | PraxisHospitalAdmissionServiceRequestDE |
shared identifier, patient, requester, performer, date, indication, priority, insurance | reuses the existing hospital-admission extensions |
| e04 patient transport | PraxisPatientTransportServiceRequestDE |
same shared request contract | intended performer is an organization or HealthcareService; official transport and authorization remain out of scope |
| e28 sociotherapy indication referral | PraxisSociotherapyIndicationReferralDE |
inherits the full outgoing PraxisReferralDE contract |
fixes assignment type to consultation/indication assessment |
The KBV patient-transport guidance identifies Muster 4 as the official prescription and requires issuance before transport except in emergencies. The KBV sociotherapy guidance describes Muster 26 and 27 for treatment and planning. Annex 2b separately lists the e28 indication-referral form. These sources establish the form boundaries; they do not provide a released machine-readable FHIR service-code binding.
Therefore the three example orders use a clearly non-normative, versioned
example.org service catalog. Their code elements intentionally remain open
to authoritative or versioned local catalogs. No national code is inferred from
paper labels.
| Invariant | Result |
|---|---|
| Order identifiers | each profile in this request/result family requires a V2-0203 PLAC identifier slice with system and value; no identifier extension or positional "first identifier wins" rule was added |
| Request resource | all five order variants remain ServiceRequest; no custom request resource or broad local parent was added |
| Result correlation | laboratory and screening observations/reports use standard basedOn; no correlation extension was added |
| Specimen correlation | orders use ServiceRequest.specimen; screening specimens use standard Specimen.request |
| Referral reuse | e28 derives from PraxisReferralDE; it does not duplicate referral constraints |
| Shared episodic constraints | e02 and e04 insert the same closed RuleSet used to define identifier, subject, requester, performer, authored date, indication, priority, and insurance |
| Transport boundary | proof Bundles are collection examples only, never document or message transport profiles |
| Independent Annex 2b profiles | separately delivered Annex 2b resource clusters and pre-existing order profiles keep their own identifier contracts; this family does not retrofit PLAC slicing onto unrelated profiles |
Version 0.90.0 tightens PraxisReferralDE and is therefore a breaking profile
change. Instances that declared the earlier profile must add a namespaced
identifier typed as V2-0203 PLAC, target performer, and authoredOn before
declaring the 0.90.0 profile. Assignment category, priority, and
occurrence[x] remain optional Must Support data because an inbound Muster 6
record may not contain them; importers do not fabricate assignment, urgency, or
validity. When a category is supplied, the extensible ValueSet lets an issuer
preserve a different assignment vocabulary instead of inventing one of the
local codes. A structured diagnosis, supporting information, and insurance
context also remain optional Must Support data; this preserves asymptomatic,
self-pay, and minimally documented referral workflows.
The directly declared Cognovis dependencies were checked against
https://npm.cognovis.de on 2026-07-28. The installed pins were the newest
published stable versions: imaging 1.1.0, ESCO 1.0.0, KBV terminology 1.0.0, and
Heilmittel terminology 1.0.1.
Executable negative checks are provided in
test/Profile/request-result-semantics.http. The deterministic generated-artifact
cross-check is scripts/check-request-result-semantics.sh.