V1 Scan-Code Klärfall- und Auftrags-Cockpit
Arbeitsannahme für einen schlanken ersten Produkt-Scope zwischen Pflegeheim, Apotheke und BlisterCenter. Der Fokus liegt auf Rückfragen, Freigabe, Status und Übergabe, nicht auf klinischer Entscheidung oder Maschinensteuerung.
Leitentscheidung für V1
Klärfall- und Auftragscockpit
Ein Vorgang sammelt Quelle, fehlende Angaben, Rückfragen, Freigabe und Übergabepaket.
Vollständiger Medikationsplattform
IXOS, Blimus, PAVEpro, Vivendi und MEDIFOX decken viele Teile bereits ab. V1 muss ergänzen, nicht ersetzen.
Scan-Code statt QR als Sammelbegriff
BMP nutzt 2D-/DataMatrix-Barcode. E-Rezept-Codes sind Token/Referenzen, nicht der komplette Medikationsplan.
Systembild
Vorgang starten
BMP-DataMatrix, PDF, Foto, Pflegeheimliste, Rezeptanforderung oder manuelle Info wird als Vorgang erfasst.
Strukturieren und klären
Quelle, Version, Bewohner, Medikationsstand, fehlende Felder, Rückfragen, Owner und Status werden sichtbar.
Prüfen und freigeben
Apotheke korrigiert, fordert fehlende Infos an und gibt den Vorgang erst nach menschlicher Prüfung frei.
Übernehmen und vorbereiten
Nur freigegebene Vorgänge werden als PDF/CSV/JSON/Druckliste oder später per Connector übergeben.
V1-Komponenten
- BMP-DataMatrix / Scan-Code
- PDF, Foto, Pflegeheimliste
- Rezeptanforderung oder Änderung
- Manuelle Ergänzung
- Vorgang pro Bewohner / Auftrag
- Pflichtfelder und fehlende Infos
- Klärfall-Chat pro Feld
- Audit-Trail und Versionen
- Apothekenfreigabe
- Übergabepaket
- PDF / CSV / JSON / Druckliste
- Später: AVS-/Pflege-/Blister-Connector
Statusmodell
Scope-Grenzen
In Scope
Vollständigkeit, Quelle, Version, Rückfrage, Freigabe, Status, Übergabepaket, Audit, Export. KI darf strukturieren und Vorschläge machen, aber nur als Assistenz.
Out Of Scope
AMTS-Prüfung, Wechselwirkungen, Dosierungsempfehlung, Therapieentscheidung, automatische Freigabe, TI/ePA/eRezept-Direktintegration, Maschinensteuerung.
Datenmodell V0
| Objekt | Zweck | V1-Frage |
|---|---|---|
| Organization | Pflegeheim, Apotheke, BlisterCenter | Wer ist im ersten Pilot wirklich beteiligt? |
| Resident / Patient | Bewohner/Patient im operationalen Kontext | Welche Stammdaten sind zwingend? |
| MedicationPlanVersion | Importierter oder erfasster Medikationsstand | Welche Quelle ist führend? |
| OrderCase | Arbeitsvorgang, Blisterauftrag oder Klärfall | Was ist der kleinste erfolgreiche Vorgang? |
| ClarificationThread | Feldbezogene Rückfrage mit Owner und Status | Welche Rückfragen kommen am häufigsten? |
| Approval | Apothekenseitige Freigabe | Wer darf final freigeben? |
| HandoffPackage | Export oder Übergabe ans BlisterCenter | PDF, CSV, JSON oder bestehendes Importformat? |
Roadmap-Annahme
Companion mit Export
Ein Heim, eine Apotheke, ein BlisterCenter. Keine tiefe Integration. Ziel: Rückfragen und Übergaben messbar verbessern.
Connectoren
Import/Export zu realen AVS-, Pflege- oder Blisterformaten. Erst nach echten Beispielvorgängen und Feldmapping.
ePA/eMP/eRezept und SaaS
Nur mit geklärter TI-/Primärsystemstrategie, Datenschutzrollen, regulatorischem Scope und realer Nachfrage.
Fragen für morgen
- Welcher Schmerz ist am teuersten: fehlende Rezepte, unklare Medikationsänderungen, Rückfragen, Lieferstatus, Produktionsstopps oder Dokumentation?
- Wer soll in V1 wirklich im System arbeiten: Pflegeheim, Apotheke, BlisterCenter oder nur intern?
- Welche 10 echten Beispielvorgänge können wir bekommen, inklusive Dokument, Rückfrage, Fehlerfall und heutigem Ergebnis?
- Wer ist fachlich die letzte Freigabeinstanz vor Übergabe an das BlisterCenter?
- Darf V1 bewusst als Companion-System mit Export starten, ohne tiefe Integration?
- Welche Kennzahl muss der Pilot in 14 Tagen verbessern?