Command Grid
v2.4.0-stable
Total
663
Blocked
80
Busy
1
Idle
0
Social Stream
Task Activity Command Feed
Ready
175## Kontext (aus Interview 2026-03-08) ### Patient-Marker "P" ist NICHT verlässlich - Wird auch gesetzt bei IGeL-Leistungen (Privatleistung für Kassenpatienten) - Wurde massenhaft gesetzt durch Covid-Impfungen (Privatschein Bayerisches Landesamt für Gesundheit) - Jeder Kassenpatient kann Privatzahler sein (Selbstzahler) ### Verlässlicher Marker: Scheinart - Der letzte Privatschein ist der beste Indikator - Versicherungsverhältnis hängt AM SCHEIN (nicht am Patienten): - Beihilfe (eingeschränkte Steigerungssätze) - Basistarif - Alte Postbeamte / Bahnbeamte - Bundespolizei - Standard PKV ### Privatschein-Besonderheiten - **Keine Quartalslaufzeit** — Schein ist offen bis abgerechnet - Kann über Jahre offen sein - Verschiedene Abrechnungsrhythmen je Standort: - Neurologie: alle 2 Wochen (wegen Umsatz) - Kleine Standorte: 1x/Jahr - Kein Factoring (Klientel: niedrige Rechnungsbeträge, 3-7 EUR) - Rechnungen werden gesammelt bis Volumen zusammenkommt, mindestens 1x/Jahr ### TODO - Prüfen ob wir aktuell den Patient-Marker "P" irgendwo als PKV-Indikator verwenden - Sicherstellen dass Scheinart (Encounter.class / Encounter.type) der primäre Marker ist - Versicherungsverhältnis-Details vom Schein mappen (Beihilfe, Basistarif etc.) ### Key Quote "Ein Patient mit Marker P — der ist es nicht. Der ist nicht das, worauf du dich verlassen kannst." "Die Scheinart ist der gute Marker. Die Vergangenheit ist ein guter Marker."
~30 Abfragen pruefen ob eine Ziffer im Vorquartal abgerechnet war aber im aktuellen nicht (z.B. 03220 in VQ ohne 03220 aktuell, 21230 im VQ aber nicht laufend). Braucht: 1) RuleEncounter.previousQuartalCodes (Engine befuellt beim Encounter-Loading), 2) ziffer-check Template erweitern oder neues vorquartal-check Template, 3) Tier: quarterly. Historische Encounter-Daten sind via PVS-Sync in Aidbox vorhanden.
## Kontext Extrabudgetäre Leistungen werden nicht aus dem RLV/QZV-Budget bezahlt — sie sind 'freies Geld' das viele Praxen nicht ausschöpfen. Besonders TSVG (offene Sprechstunde) erfordert das KVDT-Feld 4103, ohne das die Vergütung verloren geht. ## Was MIRA braucht 1. **TSVG-Prüfung**: Bei Terminen ohne Überweisung prüfen ob Feld 4103 gesetzt ist 2. **Extrabudgetäre Ziffer-Erkennung**: Welche abgerechneten Leistungen sind extrabudgetär? 3. **Potenzial-Report**: Welche extrabudgetären Leistungen werden erbracht aber nicht korrekt gekennzeichnet? 4. **Katalog der extrabudgetären Leistungen**: Regional verschieden (17 KVen), Starter mit KV Bayern ## Typische extrabudgetäre Leistungen - TSVG offene Sprechstunde (Neupatienten, dringliche Überweisungen) - Präventionsleistungen (Gesundheitsuntersuchung, Hautkrebsscreening) - Substitutionsbehandlung - Ambulantes Operieren - Bestimmte Laborleistungen ## Acceptance Criteria - [ ] TSVG Feld-4103-Prüfung implementiert - [ ] Katalog extrabudgetärer Leistungen (mind. KV Bayern) - [ ] Report: Ungenutztes extrabudgetäres Potenzial pro Praxis - [ ] Hinweis bei Encounters die extrabudgetär abrechenbar wären ## Referenz - Research: TSVG fehlendes Feld 4103 → Geld weg - KV-Korrektur fügt nur wenige extrabudgetäre Zuschläge automatisch zu
In Progress
1Umbrella-Epic für alle Demo- und Evaluierungs-Szenarien. ## Szenarien - S1a: Diabetiker DMP (mira-ccs) - S1b: Kardio-Patient (mira-1ve) - S1c: Onkologie (mira-9j6) - S1d: Rheuma-Patient (mira-88v) - S2: GOÄ Privatpatient (mira-s7h) - S3: Rückforderungs-Prävention (mira-yje) - S4: Katalog-Recherche (mira-ycw) - S5: Quartalsvergleich (mira-wui) - S6: Multi-Arzt/Standort (mira-dud) - S7: RLV-Budget (mira-6bq) ## MCN-spezifisch - mira-co0: Blind-Test MCN Hackathon - mira-smu: Demo-Daten MCN Hackathon
Unblocks
S1b: Kardio-Patient — Belastungs-EKG + Langzeit-Diagnostik
+11 more
Blocked
82## Kontext pvs-adapter-x-isynet bekommt eine HTTP-API (pvs-h97). Dieses Bead implementiert die MIRA-seitigen Änderungen damit MIRA den externen Adapter per HTTP aufrufen kann. ## Scope (nur MIRA-Seite) Die Adapter-API selbst wird in pvs-h97 (pvs-adapter-x-isynet Repo) implementiert. Dieses Bead handhabt: 1. **HTTP-Client in sync-orchestrator.ts** — statt lokaler adapter.sync() → fetch() gegen Adapter-API 2. **MIRA /api/adapters Endpoints** — Registration + Heartbeat vom Adapter empfangen 3. **adapter_registry Nutzung** — Betrieb-ID → Adapter-URL auflösen 4. **Betrieb-Sequenzierung** — Betriebe nacheinander abarbeiten, pro Betrieb Adapter-API aufrufen 5. **NDJSON-Pfade aus Adapter-Response** → an aidbox-import.ts übergeben für \$import v2 6. **Deploy: docker-compose** — pvs-adapter als separaten Container, shared NDJSON-Volume ## API-Kontrakt (definiert in pvs-h97) ``` POST http://pvs-adapter:3100/api/sync/start Body: { betrieb: [20], quarters: 2, anonymize: false } Response: { ok: true, jobId: "sync-..." } GET http://pvs-adapter:3100/api/sync/status Response: { ok: true, data: { isRunning: false, result: { files: ["sync-xxx/Patient.ndjson.gz", ...], stats: [...] } } } ``` MIRA pollt /api/sync/status bis isRunning=false, nimmt dann files[] für Aidbox-Import. ## Akzeptanzkriterien 1. sync-orchestrator.ts: HTTP-Client statt lokaler Adapter-Aufruf 2. POST /api/adapters/register + POST /api/adapters/heartbeat Endpoints in MIRA 3. GET /api/adapters — Liste registrierter Adapter 4. Betrieb-ID → adapter_registry → Adapter-URL Auflösung 5. Betriebe sequentiell abarbeiten (Adapter lehnt concurrent ab) 6. NDJSON-Pfade aus Adapter-Response → aidbox-import.ts \$import v2 7. docker-compose mit pvs-adapter Container + shared Volume 8. Integration-Test: MIRA → Adapter-API → NDJSON → Aidbox-Import ## Abhängigkeiten - Hängt ab von: **pvs-h97** (Adapter-API in pvs-adapter-x-isynet) - Hängt ab von: **mira-mvst** (adapter_registry + sync_events Tabellen) - Blockiert: **mira-r2bn** (Import-Service mit pg_notify + Dedup)
Blocked By
[ARCH] MIRA Import-Service: pg_notify LISTEN + v2 + Deduplication
Unblocks
[ARCH] pvs-adapter-x-isynet: Neues Repo + Code-Extraktion + PvsAdapter-Interface
## Ziel Materialisierte View / Flat Table in mira_backend die aus FHIR-Daten (ChargeItem + Encounter) pro Mandant×Quartal×GOP aggregiert. ## Schema ```sql mira_backend.statistik_abrechnungsdaten ( mandant_id TEXT, quartal TEXT, -- z.B. "2026-Q1" gop_code TEXT, -- EBM-Ziffer fachgruppe TEXT, -- Fachgruppe des Mandanten anzahl INT, -- Wie oft abgerechnet wert DECIMAL, -- Gesamtbetrag EUR fallwert DECIMAL, -- Durchschnitt pro Fall fallzahl INT, -- Anzahl Scheine updated_at TIMESTAMPTZ ) ``` ## Befüllung - SQL-Aggregation über charge_item_flat + encounter_flat - Trigger: Nach Sync-Lauf oder täglich - Fachgruppe aus Mandant→Practitioner→Qualification ableiten ## Akzeptanzkriterien - [ ] Migration erstellt Tabelle in mira_backend - [ ] Aggregations-Query korrekt (Mandant×Quartal×GOP) - [ ] Refresh-Mechanismus (manuell + nach Sync) - [ ] 139 Betriebe × aktive Quartale korrekt aggregiert ## MoC | # | AK | MoC | Nachweis | |---|-----|-----|---------| | 1 | Schema | unit | Migration-Test | | 2 | Aggregation | integ | Query gegen MCN-Daten | | 3 | Refresh | unit | Trigger-Test | | 4 | Vollständigkeit | integ | Row-Count plausibel |
Blocked By
Internes MCN-Benchmarking: Fachgruppen-Durchschnitt berechnen
## Ziel Berechnung des MCN-internen Fachgruppendurchschnitts aus der Statistik Flat Table. 139 Betriebe → Mandanten nach Fachgruppe gruppieren → Durchschnittswerte pro GOP. ## Schema-Erweiterung ```sql mira_backend.statistik_benchmark ( fachgruppe TEXT, quartal TEXT, gop_code TEXT, -- Interner MCN-Benchmark fag_anzahl DECIMAL, -- Fachgruppen-Durchschnitt Anzahl fag_wert DECIMAL, -- Fachgruppen-Durchschnitt Wert fag_fallwert DECIMAL, -- Fachgruppen-Durchschnitt Fallwert fag_fallzahl DECIMAL, -- Fachgruppen-Durchschnitt Fallzahl mandanten_count INT, -- Wie viele Mandanten in Fachgruppe -- Optional: Externer Benchmark (Track B, später) ext_fag_wert DECIMAL, ext_source TEXT, -- 'kbv' | 'kvdt' | NULL updated_at TIMESTAMPTZ ) ``` ## Logik 1. Aus statistik_abrechnungsdaten alle Mandanten derselben Fachgruppe gruppieren 2. AVG/MEDIAN pro GOP berechnen 3. Pro Mandant: Abweichung = (eigener Wert - FAG) / FAG * 100 ## Akzeptanzkriterien - [ ] Benchmark-Berechnung für alle Fachgruppen mit ≥2 Mandanten - [ ] Abweichungs-% pro Mandant×GOP korrekt - [ ] API-Endpunkt: GET /api/billing/benchmark/:mandantId/:quartal - [ ] Fachgruppen-Zuordnung aus Practitioner-Daten abgeleitet ## MoC | # | AK | MoC | Nachweis | |---|-----|-----|---------| | 1 | Berechnung | unit | Test mit bekannten Werten | | 2 | Abweichung | unit | Formel-Test | | 3 | API | integ | Endpoint-Test gegen MCN | | 4 | Fachgruppen | integ | Zuordnung korrekt |
Blocked By
Regress-Risiko Engine: 4-Stufen-Kalkulation
Unblocks
Statistik Flat Table: Mandant×Quartal×GOP Aggregation
Deferred
0No tasks in deferred.
Done
405405 tasks hidden.
Agent Pool Monitor
No agents broadcasting