{"findings":[{"severity":"Important","file":"scripts/health/dashboard_v5/read_api.py","line":3568,"issue":"The API classifies every prescription except explicitly ended ones as current. Because preserved legacy prescriptions have unknown status, and paused prescriptions also pass this filter, the UI presents ambiguous or paused prescriptions under “Aktuelle Medikamente” and offers the same immediate administration action. This turns unknown/paused prescription state into an implicit current-plan cue despite retaining an unknown status chip.","remediation":"Populate current_prescriptions only from explicitly active prescriptions. Present paused and unknown prescriptions in separately labelled groups, and avoid an action styled as a current-plan action for them; if historical administration capture must remain possible, expose it as neutral documentation independent of prescription currency."},{"severity":"Important","file":"scripts/health/assets/health-assets/dashboard-v5-record.js","line":735,"issue":"medicationDose falls back from actual dose to planned dose and then legacy dose without preserving which semantic field supplied the value. An administered event may legally have blank actual fields after plan-value confirmation, so the administered history and doctor report can display its planned dose under a generic “Dosis” column as though it were the actual administered dose.","remediation":"Use status-specific rendering. For administered events, show structured actual dose only; if the user explicitly confirmed administration according to plan, persist a dedicated confirmation/provenance field and label it accordingly rather than substituting planned fields. Keep planned and legacy free-text doses visibly separate and never parse or promote legacy text into actual dose."},{"severity":"Important","file":"scripts/health/dashboard_v5/medication_schema.py","line":165,"issue":"Append-only protection applies only when the origin row itself has business_revision. The UI permits corrections of legacy rows, but after a structured correction references a legacy origin, that origin can still be updated because its business_revision is NULL. A runtime probe successfully changed the corrected origin's event_type and dose, allowing correction history to be rewritten beneath the immutable correction record.","remediation":"Add update/delete triggers that also reject mutation whenever the row is referenced by any correction, regardless of the origin's business_revision. Add regression tests that correct a legacy row and then prove all origin fields and the correction row are immutable."},{"severity":"Important","file":"scripts/health/assets/health-assets/dashboard-v5-record.js","line":765,"issue":"Correcting a planned event sends the same event as both planned_event_ref and correction_target_ref, while line 763 uses correction_preview_revision generated by the API for a context containing only the correction target. The worker recomputes the revision with both contexts and rejects it as stale, so append-only correction of planned events cannot succeed.","remediation":"For correction mode, leave planned_event_ref empty and bind only correction_target_ref, or generate and verify the exact same dual-reference context on both API and worker sides. Add an end-to-end regression that successfully appends a correction to a planned event while leaving the original unchanged."},{"severity":"Important","file":"scripts/health/assets/health-assets/dashboard-v5-record.js","line":842,"issue":"The doctor report renders planned, administered, missed, and corrected buckets but silently omits the API's unknown bucket. It also labels correction rows only as corrected without showing effective_status, so an ambiguous legacy event disappears from the report and a correction does not disclose whether the target status is planned, administered, or missed. The backend completeness calculation likewise excludes unknown events at read_api.py lines 4364-4366.","remediation":"Add an explicit “Status unbekannt” report section, include unknown rows in completeness accounting, and display each correction's corrected target status and reference relationship. Preserve neutral wording and never infer a status for unknown legacy events."},{"severity":"Important","file":"scripts/health/dashboard_v5/read_api.py","line":4179,"issue":"Medication history is selected by default for doctor reports, and the report API reuses the full medication-record payload. Consequently the default JSON response includes optional private fields such as notes, lot numbers, injection region/side/detail, and original route even though the printable report does not use them. A synthetic runtime probe confirmed these fields are present in the default report response.","remediation":"Build a dedicated minimal report projection containing only explicitly required fields, excluding notes, lot/injection details, original route, provenance, action revisions, and opaque action references by default. Require a separate explicit opt-in for each optional-detail class and test the default serialized payload for their absence."}],"verdict":"BLOCK"}