Therapeutic Remedy Line Contract

Therapeutic Remedy Prescription Contract

PraxisTherapeuticRemedyDE represents one ordered therapeutic-remedy line as a ServiceRequest. Each line carries one or more source-provided codings. Quantity and occurrence or frequency remain independently representable when they are supplied. Imported legacy lines may omit quantity or occurrence. Several coding entries describe the same line; they do not create several ordered positions.

The profile retains portable clinical reason and insurance coverage fields. It does not identify a source-system catalog, select a remedy, or validate a terminology code.

Terminology capability boundary

1. Storage and round trip. A FHIR server can persist and return the source-provided Coding.system and Coding.code without this guide installing the source CodeSystem.
2. Terminology validation. Validation of a remedy code is not available until a lawful terminology source is explicitly admitted and installed.
3. Catalog expansion and selection. Catalog expansion and selectable authoring are not available. This guide neither publishes nor chooses a replacement catalog.

Consumers identify a therapeutic-remedy line through its meta.profile declaration for PraxisTherapeuticRemedyDE. The removed category discriminator is not replaced with another in-instance catalog marker.

The worked example uses a clearly non-production coding fixture owned by its example producer. It is evidence of the storage shape only, not evidence that the fixture code is clinically valid or selectable.

Local prescription and handover graph

Newly authored prescriptions use TherapeuticRemedyPrescriptionDE, a RequestGroup with a stable producer-issued identifier, patient, author, and authoring date. Every action references exactly one PraxisTherapeuticRemedyDE line. Each referenced line in an authored graph must carry a source-provided remedy coding, quantity, and Timing frequency. The aggregate can optionally reference TherapeuticRemedyCaseDE, a longitudinal CarePlan with its own producer-issued identifier, patient, lifecycle status, period, and coded diagnosis references. A missing case link does not permit consumers to infer case identity from diagnoses or dates.

Creation uses a FHIR transaction Bundle containing the case when present, the aggregate, all lines, creation Provenance, and the initial handover Task. This is local authoring and storage evidence for Aidbox persistence and round-trip behavior. It is not a gematik TI transport payload, an E-Rezept API operation, a signature container, or a request to contact a PVS directly.

TherapeuticRemedyHandoverTaskDE focuses on the aggregate. Standard Task status is interpreted as follows: requested, accepted, and in-progress mean pending; completed means handed over; and failed means failed. A failed Task records details through standard statusReason, without a vendor status code. If no matching Task exists, handover state is unknown.

Catalog validation, expansion, selectable catalog authoring, signatures, correction exchanges, performed-service documentation, therapy reports, and ePA exchange remain outside this contract.