Vom Befund zum
verantworteten Handeln.
Wie ABS-Arbeit organisiert wird, wo der Workspace unterstützt und welche Daten, Menschen und Voraussetzungen eine tragfähige Umsetzung braucht.
Demo mit synthetischen KlinikdatenÖffentliche Fachübersicht · Redaktionsstand 2026-10-12 · Inventar 2026-10-12.1
Klinische Entscheidungen liegen bei qualifiziertem Personal.
Quelle, Nenner, Zeitraum und Datenlücken gehören dazu.
Technische Funktion ist noch keine klinische Freigabe.
01ABS ist ein kontinuierlicher Prozess
Antibiotic Stewardship unterstützt eine verantwortete Antibiotikaanwendung. Daten werden geprüft, gemeinsam eingeordnet und in nachvollziehbare Maßnahmen übersetzt. Eine App schafft Arbeitsgrundlagen; sie ersetzt keine Fachkompetenz oder klinische Bewertung.
Fachliche Empfehlung RKI und Kommission ART beschreiben ABS als interprofessionelle Aufgabe mit Leitung, Ressourcen, lokaler Bewertung und kontinuierlicher Umsetzung. Die folgende Darstellung ist eine kompakte organisatorische Umsetzung dieses Gedankens.
- 1
Mandat & Ziele
Klinikleitung und ABS-Leitung vereinbaren Auftrag, Geltungsbereich, Zielbild und verfügbare Zeit. Vertretung und Eskalationsweg sind geklärt.
- 2
Daten erfassen & validieren
Apotheke und Mikrobiologie liefern geeignete Aggregate. Einheiten, Nenner, Zeiträume, Strata und Mappings werden geprüft; Lücken bleiben sichtbar.
- 3
Verbrauch & Resistenzen bewerten
Das ABS-Team bewertet Trends und lokale Befunde mit den Fachbereichen. Case-Mix, Erhebungsbasis und Populationsunterschiede begrenzen Vergleiche.
- 4
Maßnahmen & Hausleitlinien festlegen
Befunde werden zu konkreten Arbeitsaufträgen mit Owner, Ziel, Termin und Messgröße. Fachliche Empfehlungen durchlaufen einen verantworteten Review.
- 5
Kommunizieren & umsetzen
Stationen, Pflege und weitere Beteiligte werden informiert und geschult. Zuständigkeit und Umsetzung werden festgehalten.
- 6
Wirkung & Qualität prüfen
Vergleichbare Zeitfenster und Datenqualität erneut prüfen. Veränderungen beobachten, klinische Qualität separat bewerten; zwei Aggregate belegen keine Kausalität.
- 7
Dokumentieren & fortführen
Berichte, Quellenstände und offene Aufgaben sichern. Erkenntnisse führen zu angepassten Zielen und zum nächsten Durchlauf.
↻ Erkenntnisse aus Schritt 7 fließen in Mandat, Ziele und den nächsten Datendurchlauf zurück.
02Was das Klinikum konkret organisiert
| Aufgabe | Verantwortliche Funktion | Input | Ergebnis / Nachweis | Beispielhafter Turnus |
|---|---|---|---|---|
| Mandat, Zielbild, Geltungsbereich und Eskalation festlegen | Klinikleitung / Sponsor | Versorgungsauftrag, Ressourcen, Risiko- und Zielbild | Dokumentierter Auftrag, Zuständigkeit und Ressourcenzusage | Zum Start; bei wesentlichen Änderungen |
| Programm koordinieren, Vertretung und Zeitbudget sichern | Ärztliche ABS-Leitung | Mandat, Team, Stationsbedarfe | Arbeitsplan, Vertretung, abgestimmte Termine | Beispiel: monatliche Koordination |
| Verbrauchs- und Aktivitätsdaten bereitstellen | Krankenhausapotheke / Controlling | Menge, Wirkstoff/ATC, Route, Erhebungsbasis, Patiententage | Validierte monatliche Aggregate mit Mappingnachweis | Beispiel: monatliche Lieferung |
| Lokale Resistenzaggregate fachlich prüfen | Mikrobiologie | Material/Population, klinisch vs. Screening, n/S/I/R, Normversion | Antibiogramm mit Deduplicationsmethode und Lücken | Nach lokalem Datenplan; Beispiel: jährlicher Gesamtstand |
| Befunde im klinischen Kontext bewerten und Maßnahmen umsetzen | Fachabteilungen / Stations- und Pflegevertretung | ABS-Auswertung, Case-Mix, Stationsabläufe | Begründete Arbeitsaufträge und Rückmeldung zur Umsetzung | Beispiel: monatliche/vierteljährliche Besprechung |
| Hausleitlinien reviewen, fortbilden und Maßnahmen bewerten | ABS-Team / verantwortliche Fachautoren | Geprüfte Quellen, lokale Anforderungen, messbare Ziele | Fachlicher Review, Freigabeidentität, Schulungs- und Bewertungsnachweis | Anlassbezogen; Reviewdatum lokal vereinbaren |
| Dokumentation, Nachverfolgung und Bericht unterstützen | Qualitätsmanagement | Maßnahmenstatus, Datenstand, Freigaben | Nachvollziehbarer Bericht und offenes Follow-up | Beispiel: Monatsbericht / Quartalsreview |
| Pilot-Datenflüsse, Rechte und Betriebsfreigabe klären | IT / Informationssicherheit / Datenschutz | Schnittstelleninventar, Schutzbedarf, Zweckbestimmung | Geprüfte Rollen, Betriebs- und Datenschutzkonzept | Vor Pilot; danach Änderungen und Risiken reviewen |
Lokale Organisationsempfehlung Monats- und Quartalstermine sind Beispiele, keine erfundenen gesetzlichen Fristen. Umfang, Frequenz und Zuständigkeit richten sich nach Haus, Versorgung und Datenlage.
Besetzung mit klaren Aufgaben
Kernteam, eng angebundene Fachpartner und organisatorische Ergänzungen brauchen ein abgestimmtes Mandat. Die Matrix fordert weder für jede Rolle eine neue Vollzeitstelle noch einen pauschalen Personalschlüssel.
| Funktion | Einordnung | Kompetenz / Aufgabe | Mandat / Vertretung | Benötigte Zugänge |
|---|---|---|---|---|
| Klinikleitung / Sponsor | Auftraggeber | Zielbild, Mandat, Ressourcen und Eskalation | Benannter Sponsor und entscheidungsfähige Vertretung | Berichte und Entscheidungsgrundlagen |
| Qualifizierte ärztliche ABS-Leitung / Infektiologie | Kernteam | Fachkompetenz, Koordination und verantwortete klinische Bewertung | Schriftlicher Auftrag, Vertretung, organisatorisches Zeitbudget | Auswertungen, Maßnahmen, Reviews; Demo-Freigaben nach Rolle |
| Klinische Pharmazie | Kernteam | Arzneimitteldaten, ATC-/Route-Mapping, Erhebungsbasis und Verbrauchsmethodik | Benannte Datenverantwortung und Vertretung | Verbrauch und berechtigte Importe im lokalen/pilotierten System |
| Mikrobiologie | Kernteam / enger Fachpartner | Erreger-/Antibiotikamapping, Normversion, Strata und Deduplication | Verantwortliche Laboransprechperson | Resistenzdaten und fachliche Quellenprüfung |
| Krankenhaushygiene | Fachpartner im ABS-Netzwerk | Infektionsprävention und Einordnung der Resistenzsurveillance | Geregelte Schnittstelle zur Hygieneorganisation | Relevante Auswertungen, keine pauschalen Administrationsrechte |
| Klinische Fach-/Stationsvertretung | Umsetzungspartner | Case-Mix und klinische Abläufe; Umsetzung und Rückmeldung | Benannte Pilotstationsvertretung und Vertretungsregel | Eigener Umfang, zugewiesene Maßnahmen |
| Pflegevertretung | Umsetzungspartner | Praktische Abläufe, Kommunikation und Schulungsbedarfe | Organisatorisch eingebundene Ansprechpartner | Relevante freigegebene Informationen und Aufgaben |
| Qualitätsmanagement | Organisatorische Ergänzung / Schnittstelle | Nachweise, Termine und Berichtsorganisation | Abgestimmte Unterstützung, keine klinische Freigabe allein aus QM-Rolle | Berichte, Aufgaben und freigegebene Dokumente |
| IT / Betrieb | Technischer Schnittstellenpartner | Schnittstellen, Identität, Updates, Sicherung und Wiederanlauf | Betriebsverantwortung mit Vertretung und Incident-Weg | Least-Privilege-Betriebszugriff, keine unnötigen Klinikdaten |
| Datenschutz / Informationssicherheit | Prüfende Schnittstellenpartner | Datenflüsse, Schutzbedarf, Rechtsgrundlagen und Risikoprüfung | Einbindung vor Pilot und bei Änderungen | Konzept-/Nachweiseinsicht, kein pauschaler Inhaltsvollzugriff |
§23 IfSG: aufzeichnen, bewerten, Schlussfolgerungen umsetzen
Für die in §23 Abs.3 Nr.1–3 erfassten Einrichtungen umfasst Abs.4 die fortlaufende zusammengefasste Aufzeichnung des Antibiotikaverbrauchs, dessen Bewertung unter Berücksichtigung der lokalen Resistenzsituation sowie Schlussfolgerungen, Kommunikation und Umsetzung. Die Aufzeichnungen nach Abs.4 Sätzen 1 und 2 sind zehn Jahre ab Anfertigung aufzubewahren. Diese Frist gilt nicht automatisch für jedes technische Log oder jede Nutzereingabe.
Infektions- und Resistenzsurveillance haben einen weitergehenden gesetzlichen Umfang als diese App. Ein Verbrauchsdashboard belegt keine vollständige Erfüllung des §23. Zuständigkeit, Dokumentationsumfang und einschlägige Landesregeln müssen vor einem konkreten Pilot geprüft werden. Ohne festgelegtes Bundesland wird hier keine landesrechtliche Freigabe behauptet.
§ 23 IfSG: Surveillance, Bewertung und Aufbewahrung ↗ (Abruf 2026-10-12)Fachlicher Stand: Das ART-Papier 2020 und die Empfehlungen zur Leitlinienimplementierung sind berücksichtigt. Bei AWMF 092-001 ist Version 2.1 (2019), gültig bis 30.01.2024, verifiziert. Eine aktuell gültige Nachfolgefassung konnte beim Abruf nicht bestätigt werden; die ältere Fassung wird ausdrücklich als abgelaufen geführt. Diese Übersicht ist keine Rechtsberatung oder Compliance-Freigabe.
Praktische Einführung
- Verantwortlichkeiten, Mandat und Vertretungen festlegen
- Dateninventar und bestehende Schnittstellen erfassen
- Methodik, Einheiten, Strata und Mappings vereinbaren
- Pilotstationen und vergleichbare Zeitfenster auswählen
- Rollen, Freigaben und Datenzugriffe festlegen
- Nutzer schulen und Restprüfungen erklären
- Referenzen und Fachberechnungen unabhängig validieren
- Datenschutz, Sicherheit und Betrieb freigeben
- Nutzung, Datenqualität und Maßnahmen regelmäßig reviewen
Generische Checkliste zur Orientierung. Hier werden keine realen Klinikfreigaben gespeichert.
03Prozesse verbessern – Nutzen transparent rechnen
Weniger Tabellenabgleich, wiederauffindbare Quellen und klar verfolgte Aufgaben können administrative Arbeit erleichtern. Wie viel Zeit entsteht, hängt vom tatsächlichen Ablauf ab. Der Rechner macht diese Annahmen prüfbar.
Zeitpotenzial als nachvollziehbares Szenario
Es liegt noch keine gemessene Zeitersparnis dieser App im Krankenhaus vor. Starten Sie leer oder laden Sie das Rechenbeispiel. Alle Eingaben und Exporte werden ausschließlich in Ihrem Browser verarbeitet.
Eigene Annahmen – keine gemessene Klinikprognose
1 · Kontext und ausdrücklich wählbare Eingabehilfen
Größenangaben beschreiben den Kontext. Sie verändern das Zeitpotenzial nicht automatisch.
Stationsberichte hochrechnen
Stationen × Berichte je Station und Monat × 12. Krankenhaus-Gesamtberichte sind ein anderer Vorgang.
Patiententage / Fälle nur als Schätzung
Schätzung: Betten × Auslastung × Kalendertage = Nicht berechenbar Patiententage. Fälle = Patiententage / Verweildauer: Nicht berechenbar. Keine Übernahme als gemessene Aktivität und kein Einfluss auf die Effizienzrechnung.
2 · Prozesspakete auswählen und Annahmen eingeben
App-Minuten enthalten die nötige Restprüfung und Nacharbeit. Pakete dürfen sich nicht überschneiden: Bei separat gezählter Auswertung enthält „Bericht“ nur den zusätzlichen Berichtsschritt. Bereits im Import gezählte Pflege nicht nochmals als Zusatzaufwand erfassen.
3 · Zusätzlicher laufender Aufwand – Stunden pro Monat
Nur zusätzliche, oben noch nicht erfasste Arbeit. Im Jahresergebnis wird dieser Aufwand genau zwölfmal abgezogen.
4 · Einmalige Einführung – Stunden
Nur einmal im ersten Jahr abgezogen; keine Doppelzählung als laufender Aufwand.
5 · Optionale Kosten und Kapazitätsäquivalent
Jede betroffene Rolle braucht ihre eigene eingegebene Vollkostenrate. Keine erfundene Mischrate. Freie Zeit ist kein automatisch zahlungswirksamer Effekt. Hostingbeträge sind Ihre Eingaben, keine Sliplane-Preisliste.
Szenariobericht · 13.10.2026
Kontext: Betten: nicht angegeben · Stationen: nicht angegeben · Standorte: nicht angegeben · ABS-Mitwirkende: nicht angegeben · Fälle/Jahr: nicht angegeben · Patiententage/Jahr: nicht angegeben · Kalenderjahr: nicht angegeben · Auslastung %: nicht angegeben · Verweildauer Tage: nicht angegeben
| Prozess / Rolle | Vorgänge / Ist min | Konservativ App min / Abdeckung | Mittel App min / Abdeckung | Ambitioniert App min / Abdeckung |
|---|
Laufender Zusatzaufwand: keine Pakete aktiviert.
Einführung: keine Pakete aktiviert.
Betriebskosten: Nicht berechenbar €/Monat · Externe Einmalkosten: Nicht berechenbar € · Produktive Jahresstunden je Vollzeitkapazität: Nicht berechenbar h. Nicht aktivierte Pakete sind ausdrücklich ausgeschlossen. Fehlende Angaben begründen keine Nullannahme.
Ihr Annahmenszenario
Wählen Sie mindestens ein Prozesspaket und ergänzen Sie seine Eingaben. Ohne Eingaben entsteht keine Klinikprognose.
| Szenario | Brutto h/Jahr | Netto h/Jahr | Jahr 1 h |
|---|---|---|---|
| Konservativ | Nicht berechenbar | Nicht berechenbar | Nicht berechenbar |
| Mittel | Nicht berechenbar | Nicht berechenbar | Nicht berechenbar |
| Ambitioniert | Nicht berechenbar | Nicht berechenbar | Nicht berechenbar |
- Wiederkehrender Kapazitätswert vor Gebühren
- Nicht berechenbar
- Szenario-Nutzen nach Betriebskosten
- Nicht berechenbar
- FTE-Kapazitätsäquivalent (kein Stellenabbau)
- Nicht berechenbar
- Rechnerischer Payback
- Nicht berechenbar / kein positiver monetärer Nutzen
Payback = (rollenbewertete Einführungsstunden + explizite externe Einmalkosten) / positiver monatlicher Szenario-Nutzen. Er ist ein hypothetischer Kapazitätsvergleich, kein zugesicherter Cash-Payback. Fehlende Rollenraten, Betriebs- oder Einmalkosten verhindern die jeweilige Geldrechnung.
Offene Rechenregeln
Brutto_h = Σ Vorgänge × (Istmin − Appmin) × Abdeckung / 100 / 60
Netto_h = Brutto_h − 12 × Zusatzstunden/Monat
Netto_h_Jahr1 = Netto_h − Einführungsstunden
Kapazitätswert = Σ rollenbezogene Nettostunden × eingegebene €/h
Szenario-Nutzen = Kapazitätswert − 12 × monatliche Betriebskosten
Szenariobericht · 13.10.2026 · Berechnungsversion abs-efficiency-1.0 · Alle Werte sind Annahmen.
Reale Effizienz hängt von Schnittstellen, CSV-Nacharbeit, Datenqualität, Mapping, Stations-/Standortzahl, Berichtsumfang, vorhandenen Werkzeugen, beteiligten Rollen, Nutzung und Fachreview ab. Messen Sie eine kleine vergleichbare Stichprobe vorher und nachher bei gleichem Qualitätsanspruch; Einführung und laufende Arbeit getrennt erfassen. Klinische Effekte, Antibiotikakosten und Resistenzentwicklung benötigen eine separate Bewertung. Weniger DDD erzeugen hier keinen finanziellen Nutzen. Individuelle 48–72-Stunden-Therapie-Reviews sind nicht implementiert und werden nicht eingerechnet.
04Was der Workspace tatsächlich kann
Die Funktionsmatrix beschreibt den bestehenden modularen Monolithen mit echter Persistenz. Reifegrad meint technische PoC-Funktion, keine klinische Validierung. Ein Login schützt alle fachlichen Arbeitsdaten; Besucher der gehosteten Demo haben standardmäßig Leserechte.
| Funktion | Was tut sie? | Nutzer | Input | Output | Reifegrad / Grenze |
|---|---|---|---|---|---|
| Anmeldung und Rollen | Serverseitige Sessions, sechs Rollen, Organisationsumfang und Widerruf | Alle berechtigten Nutzer | Getrennt vergebene Konten / Mitgliedschaft | Autorisierte Ansichten und geschützte Vorgänge | Lokal getestet; Hosting separat geprüft |
| Organisation | Krankenhaus, Standort, Bereich und Station; begrenzte Stammdatenpflege | Administration / ABS-Leitung | Synthetische Organisationsstruktur | Eindeutiger Umfang für Daten und Rechte | Implementiert; kein vollständiger Account-Lebenszyklus |
| Verbrauch / DDD / AWaRe | Mengen, gewichtete DDD/100 Patiententage, Trends und Abdeckung | ABS / Pharmazie | Menge, Route, Erhebungsbasis, Nenner, belegte Referenzversion | Auswertung mit Einheiten, Methoden und Herkunft | Getestet; gehostete WHO-AWaRe-Zuordnung bis Rechteklärung ausgesetzt |
| Antibiogramme | Lokale S/I/R-Aggregate, R-Anteil, Wilson-Intervall und getrennte öffentliche Referenz | Mikrobiologie / ABS | Testzählungen, Population, Normversion, Methodik | Matrix mit Detailnachweis und Datenlücken | Getestet; keine MIC-/Hemmhofentscheidung |
| Datenimporte | CSV/XLSX, Mapping, Vorschau, Validierung, atomare Übernahme und Idempotenz | Berechtigte Fachrollen | Aggregierte Dateien und explizite Mappings | Importhistorie, Qualitätsbefunde und Herkunft | Lokal getestet; Besucheruploads in Hosting-Demo gesperrt |
| Maßnahmen | Owner, Termine, Status, Meilensteine, eingefrorene Baseline und manuelle Bewertung | ABS-Leitung / zugewiesene Mitwirkende | Nachvollziehbarer Auslöser, Ziele, Aufgaben | Verantwortete Nachverfolgung und beobachtete Veränderung | Getestet; keine Kausalitätsbehauptung |
| Hausleitlinien | Entwurf, separater Review, Demo-Freigabe, unveränderliche Version und Historie | Autoren / berechtigte Reviewer | Organisatorischer Text, Quellen, Review-Termin | Versionierter Freigabenachweis im Demo-Workflow | Getestet; keine klinische Inhaltsvalidierung |
| ABS-Team | Fiktive Teammitglieder, Mandate, Zeitbudgets, Qualifikationen, Fortbildung und Teilnahme | ABS-Leitung / Administration | Synthetische Personal- und Nachweisdaten | Übersicht und organisatorische Nachverfolgung | Getestet; kein Personal-Compliance-Nachweis |
| Berichte | Archivierte Datenstände mit Filter-/Quellenstand, PDF und CSV | ABS-Leitung / berechtigte Leser | Geprüfte Auswertungen und organisatorischer Status | Unveränderlicher Snapshot mit tatsächlichem Export | Getestet; kein zertifiziertes Langzeitarchiv |
| Erweiterungen | Konfigurierbare Regeln / Stationsvergleich teilweise vorhanden | Späterer Pilot | Anforderungs- und Fachprüfung | OIDC, Live-KIS/LIS und individuelle Therapie-Reviews als Ausblick | OIDC und individuelle 48–72h-Reviews nicht implementiert |
Der Demo-Ablauf führt von einer synthetischen Carbapenem-Auffälligkeit über Drill-down und Resistenzvergleich zur Maßnahme, zum getrennten organisatorischen Hausleitlinien-Review und zum archivierten PDF-/CSV-Bericht. Freitext-Schreibdemonstrationen sind ausschließlich ausdrücklich berechtigten verantwortlichen Nutzern vorbehalten und müssen synthetisch bleiben.
Geschützten Workspace öffnen05Referenzdaten sind keine lokalen Klinikbefunde
Die App trennt synthetische lokale Beobachtungen von tatsächlichen öffentlichen Quellen. Die folgenden Zählungen stammen aus dem freigegebenen versionierten Inventar; der öffentliche Überblick liest dafür keine Datenbank und liefert keine privaten Originaldateien aus.
| Quelle / Fassung | Zeitraum / Gültigkeit | Umfang | Zweck | Nutzungsstatus | Grenze |
|---|---|---|---|---|---|
| WIdO GKV ATC/DDDApril 2026, WIdO e-Paper 10 | Ausgabe 2026-04; keine erfundene Tagesgültigkeit | 73 routebezogene DDD-Zeilen / 54 ATC-Codes | Statistische Verbrauchsnormalisierung für geeignete Erwachsenenpopulationen | CC BY 4.0; Attribution und Bearbeitungsvermerk | Separate GKV-Fassung, ausdrücklich nicht amtliche BfArM-Klassifikation |
| WHO AWaRe2025 B09489 | Veröffentlicht 05.09.2025 | 384 Einträge im lokalen Referenzpaket | Monitoring-Klassifikation; keine individuelle Therapieempfehlung | CC BY-NC-SA 3.0 IGO; Hosting-Nutzung in UNITY-Demo gesondert zu klären | Gehostete Originale und Zuordnungen bis Rechteklärung ausgeschlossen; Anzeige unklassifiziert. Lokaler nichtkommerzieller Stand separat erhalten. |
| ECDC EARS-NetAER 2024, publiziert 18.11.2025, Tabelle 9b | 2020–2024 | 50 EU/EWR-Quellenraten, zehn Kombinationen | Getrennte öffentliche Resistenzreferenz invasiver Blut-/Liquorisolate | Konkreter Reproduktionsnachweis mit ECDC-/Datenlieferantenattribution | Populationsgewichtete Raten, keine künstlichen S/I/R-Zahlen; nicht direkt als Klinikbenchmark geeignet |
| Amtliche BfArM ATC/DDD2026 amtlich | 01.01.–31.12.2026 | 0 importierte Zeilen | Vorgesehene amtliche Klassifikation | RESTRICTED; Nutzungsfreigabe für Datenbank-/Weiterverwendung offen | Nur Metadaten/Link; kein geschütztes Original und keine daraus übernommenen Werte in der Demo |
| EUCAST Clinical Breakpoint Tables16.1 | 24.06.–31.12.2026 | 0 verifizierte Originale im Seed | Vollständiges versioniertes Referenzdokument | Originaldownload blockiert; zulässige lokale Bereitstellung und Prüfung offen | Kein Grenzwertexplorer und keine automatische Empfindlichkeitsentscheidung |
| RKI AntibioResDE / AVSKonkretes importierbares Paket nicht verifiziert | Keine hochgerechneten Werte für 2026 | 0 importierte RKI-Raten | Weitere nationale Referenz / Verbrauchsmethodik | Konkreter Repository-/Lizenzpfad unverifiziert; AVS nur Methodenreferenz | ECDC-Fallback bleibt separat; keine erfundenen Klinik-/NRW-Benchmarks |
Methodische Leitplanken
- DDD ist eine statistische Erwachseneneinheit, keine Patientendosis. Pädiatrische Stationen erhalten keine gleichgesetzte DDD-Bewertung.
- DDD/100 Patiententage verwendet die Summe der DDD und passende, eindeutig gezählte Nenner. Beschaffung, Abgabe und tatsächliche Verabreichung sind unterschiedliche Erhebungsarten.
- AWaRe ist eine Monitoring-Klassifikation. Fehlende Zuordnungen bleiben unklassifiziert und sichtbar; keine stillschweigende Entfernung aus dem Nenner.
- R% = 100 × R/(S+I+R) nur bei validen vollständigen Zählungen. EUCAST I bedeutet empfindlich bei erhöhter Exposition; I wird nicht pauschal zu R addiert. Historische Normsemantik bleibt erhalten.
- ECDC zeigt eine invasive EU/EWR-Referenzpopulation mit Gewichtung. Ein Vergleich mit einer lokalen Intensivstation ist keine unmittelbare Qualitätsbewertung. Fehlende Tests, kleine Fallzahlen und Datenlücken sind keine Nullwerte.
06Welche Daten gespeichert werden
Die Demo verwendet ausschließlich synthetische Klinik- und Personalinhalte. Tatsächliche Kontodaten und technisch notwendige Betriebslogs sind gesondert zu behandeln. Aggregiert, pseudonymisiert und anonym sind keine Synonyme. Kleine Aggregate und Beschäftigtendaten können Personenbezug haben; eine reale Übernahme benötigt eine eigene Prüfung.
| Kategorie | Zweck | Herkunft | Personenbezug | Zugriff | Speicherort / Retention-Konzept |
|---|---|---|---|---|---|
| Organisation / Stationen | Umfang und Zuordnung | Synthetischer Seed / kontrollierte Pflege | Namen/Zuordnungen können real organisations- oder personenbezogen sein | Eigene Organisation, Administration schreibt | Eigene PostgreSQL-DB; Pilot-Stammdatenkonzept offen |
| Nutzer / Rollen / Sessions | Identität, Rechte und Anmeldung | Getrennte Demo-Konten | Kontodaten sind personenbezogen; sichere Passwort-Hashes, keine Klartextpasswörter in der DB | Nutzer / berechtigte Administration, serverseitige Sessions | DB; Sessionablauf 8h, Widerruf; Kontolöschung/Aufbewahrung im Pilot definieren |
| Verbrauch und Aktivität | Mengen/Route/ATC/DDD, Erhebungsbasis und eindeutige Monatsnenner | Synthetische Mengen und Patiententage, erlaubte Referenzen | Aggregate sind nicht automatisch anonym; kleine Strata fachlich prüfen | Berechtigte Nutzer im Organisationsumfang | DB; fachlichen §23-Aufzeichnungssatz und zehnjährige Archivierung für Pilot definieren |
| Lokale Antibiogramme | S/I/R/n, Material, Population, Zeitraum, Norm und Deduplication | Ausschließlich synthetische lokale Aggregate | Kleine Aggregate können in realem Kontext Personenbezug haben | Eigene Organisation / berechtigte Fachrollen | DB; keine realen Patienten-IDs, Retention anhand Zweck und Pflichtumfang |
| Öffentliche Referenzen | Quelle, Fassung, Asset/Link, SHA-256 und Herkunft | Offizielle überprüfte Publikationen | Öffentliche fachliche Referenzwerte; gesonderte Datenrechte | Freigegebene Metadaten öffentlich; zulässige Dateien nur geschützt | Versioniertes Paket / DB; gesperrte Assets ausgeschlossen, Versionen mit Berichten erhalten |
| Importbatches / Mapping | Validierung, Fehler, Originalwerte und Herkunftshistorie | Explizite synthetische lokale Importe | In Pilotdaten können Rohdateien trotz Aggregation identifizierbar sein | Nur berechtigte Importrollen; Hosted-Besucher dürfen nicht hochladen | DB / eigenes Assetvolume; Quarantäne- und Löschfristen gesondert festlegen |
| Maßnahmen | Zuständigkeit, Frist, Kommentare, Kennzahlen und Bewertung | Fiktive Demo-Arbeitsaufträge | Zuständigkeiten und Freitext können Beschäftigtenbezug enthalten | Organisationsumfang, Rollen und Zuordnung | DB; in Demo nur synthetische freie Eingaben durch verantwortliche Lead-Nutzer |
| Leitlinienversionen | Text, Quellen, Review und Freigabeidentität | Organisatorische Demo-Dokumente | Autor-/Revieweridentität ist kontobezogen | Freigegebene Versionen lesbar, getrennte Autor-/Reviewerrechte | DB; unveränderliche Freigabeversion, fachliches Archivkonzept offen |
| Team / Qualifikationen | Mandat, Funktion, Zeitbudget, Nachweise und Teilnahme | Fiktive Personen / Demo-Eingaben | Bei realem Personal Beschäftigtendaten, nicht anonym | Berechtigte Nutzer im Organisationsumfang | DB; Nachweiszweck, Aktualisierung und Löschung vor Pilot regeln |
| Berichte / Audit / Exporte | Eingefrorener Datenstand und nachvollziehbare Vorgänge | Fachmodell, Freigaben und technische Ereignisse | Audit kann Konto-/Aktionsbezug haben; Exporte behalten Datenklasse | Geschützte Serverpfade; keine öffentlichen Berichte | DB-Snapshots, bedarfsweise generierte Dateien; Backups ersetzen kein gesetzliches Archiv |
| Rechnerinputs | Lokale Szenariorechnung | Nur Eingaben im Browser | Klinikparameter könnten vertraulich sein; kein Serverempfang vorgesehen | Nur aktueller Browser; lokales Speichern ausschließlich opt-in | Arbeitsspeicher / optional localStorage mit Löschfunktion; JSON-Export lokal |
| Technische Betriebslogs | Verfügbarkeit / Fehlerdiagnose | App und Hostingplattform | IP-/Zugriffsmetadaten können personenbezogen sein | Betriebsverantwortliche; keine Anzeige im öffentlichen Überblick | Minimiert; Plattform-Logfrist separat, keine pauschale Übernahme der zehnjährigen §23-Frist |
Der öffentliche Rechner sendet seine Szenariowerte weder an eine API noch an Analytics. Seine optionale lokale Speicherung ist eine ausdrückliche Browserentscheidung mit Löschfunktion. Ein heruntergeladener JSON-Bericht bleibt unter Ihrer Kontrolle.
07Von der Demo zum verantworteten Betrieb
Eine zeitlich begrenzte synthetische Demo kann mit geprüfter passwortgeschützter Anmeldung betrieben werden. Ein Pilot mit echten Daten und der klinische Regelbetrieb brauchen zusätzliche fachliche, organisatorische und technische Entscheidungen.
| Anforderung | Aktuelle Demo / Status | Pilot mit echten Daten – offen | Klinischer Regelbetrieb – offen | Verantwortung | Evidenz / Grenze |
|---|---|---|---|---|---|
| Zweckbestimmung / MDR-IVDR | Organisatorischer PoC, keine patientenbezogene Entscheidung; keine regulatorische Freigabe | Tatsächliche Funktionen, Claims und Einsatzkontext bewerten | Dokumentierte Einordnung und erforderliche regulatorische Nachweise | Produktverantwortung / klinische Leitung / Regulatorik | MDCG 2019-11 Rev.1; technische Abgrenzung |
| Fachmodell und Referenzpflege | DDD-/Nenner-/SIR-Testorakel vorhanden; Pflichtreferenzen teilweise offen | Unabhängige Mappings-/Kohortenprüfung, Verantwortliche für Aktualisierung | Geregelte fachliche Freigabe, Versionspflege und Änderungsprüfung | ABS / Pharmazie / Mikrobiologie | Fachtests, Quellenregister, getrennte Referenzblocker |
| Identität / Rechte / Audit | Serverseitige Rollen, Organisation und Sessionwiderruf; Hosted-Gate mit negativen API-Tests | Klinik-IdP/OIDC und risikogerechtes MFA nach Klinikvorgaben planen | Betriebener Account-Lebenszyklus, Rezertifizierung und geregelte Freigaben | IT / Fachverantwortung / Informationssicherheit | Login-, Isolation-, Viewer- und Freigabetests; OIDC offen |
| Datenschutz | Synthetische Klinik-/Personalinhalte; Kontodaten und Betriebslogs separat | Verantwortlicher/AVV, Rechtsgrundlage, Art.9 bei Gesundheitsdaten, Löschung und Informationen klären | Verbindliche Verträge, Datenschutzprozess und risikobasierte DSFA-Prüfung | Datenschutz / Träger / Betrieb | DSGVO Art.5,6,9,13/14,28,32,35; kein pauschaler Compliance-Claim |
| Region / Datenflüsse | Demo nur auf freigegebenen bestehenden Ressourcen; Betriebsdetails nicht öffentlich | EU-/DE-Anforderung vereinbaren; Standort, Supportzugriff und Transfers getrennt prüfen | Verbindliche Datenfluss-/Subprozessoren- und Transferkontrolle | Träger / Einkauf / Datenschutz | DSGVO verlangt nicht pauschal Deutschland |
| Technische Schutzmaßnahmen | HTTPS-Gate, eigene private DB, getrennte Secrets, sichere Cookies, CSP und geschützte Exporte | Bedrohungsanalyse, Schnittstellenhärtung, Update- und Schwachstellenprozess | Kontinuierliche Prüfung, Monitoring, Incident-Prozess und Least Privilege | IT / Informationssicherheit | Automatisierte Auth-/API-Tests, Dependency-Audit, keine öffentlichen Ops-Pfade |
| Backup / Wiederanlauf | DB-konsistenter Dump und Restore in separater Test-DB; Plattformvolume allein genügt nicht | Verschlüsselte Aufbewahrung, Schlüsselverantwortung, RPO/RTO und Wiederanlauf testen | Vertragliche Ziele, überwachte Jobs, Restore-Übungen und Incident-Bereitschaft | Betrieb / Klinikleitung | Demo-Ziel: Dump vor Schemawechsel, Wiederanlauf prüfen; kein Pilot-SLA zugesichert |
| Archivierung / Retention | Unveränderliche Berichtssnapshots im Anwendungspfad; kein zertifiziertes Archiv | Einschlägige §23-Aufzeichnungen ab Anfertigung zehn Jahre abgrenzen, Export/Löschung planen | Tragfähiges Archiv- und Nachweiskonzept für tatsächlichen Pflichtumfang | Fachverantwortung / QM / Datenschutz / Betrieb | §23 Abs.4 S.3 IfSG; DB-Backup ersetzt Archivkonzept nicht |
| Asset- und Datenrechte | Original-UNITY-Asset dokumentiert; Systemfonts; WIdO/ECDC mit Attribution; WHO remote ausgesetzt | Nutzungsnachweise für Logo, Quellen, Fonts und geplante Verbreitung prüfen | Nachweis und Pflege aller erforderlichen Rechte | Projektverantwortung / Recht / Datenverantwortliche | Assetmanifest; WHO-Hostingrechte bleiben offen |
öffentliche Orientierung / geschützter WorkspaceHTTPS · Anwendung
Session, Rollen, FachmodellPrivate Datenbank
eigene Rolle / eigene persistente Assets
Der Hoster terminiert HTTPS. Eine private Datenbank ist nicht öffentlich adressierbar; auf einem gemeinsam genutzten Server ersetzt das private Netz weder eigene Zugangsdaten noch Berechtigungen. Secrets gehören in den vorgesehenen geschützten Konfigurationsweg. Exportdateien und zulässige Originalassets bleiben hinter der Anmeldung.
Bei persistenten Volumes kann ein Redeploy kurz unterbrechen. Ein Dateisystem-/Volumebackup einer aktiv beschriebenen Datenbank ist nicht automatisch konsistent: Datenbanksicherung, getrennte Restore-Probe, verschlüsselte Aufbewahrung und klarer Wiederanlauf sind eigene Betriebsaufgaben. RPO/RTO und Verfügbarkeit müssen vor einem Pilot vereinbart werden; hier wird kein klinisches SLA zugesichert.
Quellen und redaktioneller Stand
Direkte Primärquellen, Abruf jeweils am angegebenen Datum. Rechtsnorm, fachliche Empfehlung, lokale Gestaltungsentscheidung und Schätzannahme sind unterschiedliche Aussagen. Eine künftige Quellenänderung ersetzt keine verantwortete Inhaltsprüfung.
- § 23 IfSG: Surveillance, Bewertung und Aufbewahrung ↗Abrufbare Gesetzesfassung vom 12.10.2026 · Abruf 2026-10-12
- RKI: Antibiotic Stewardship ↗Webseite; eigenes Aktualisierungsdatum nicht ausgewiesen · Abruf 2026-10-12
- Kommission ART: Implementierung infektiologischer Leitlinien ↗Positionspapier, Stand 16.02.2017 · Abruf 2026-10-12
- Kommission ART: Strukturelle und personelle Voraussetzungen ↗Bundesgesundheitsblatt 2020;63:749–760; DOI 10.1007/s00103-020-03152-5 · Abruf 2026-10-12
- AWMF 092-001: Register und Statusprüfung ↗Version 2.1; Stand 31.01.2019; Gültigkeit endete 30.01.2024 · Abruf 2026-10-12
- AWMF: Veröffentlichung und Gültigkeit der Version 2.1 ↗Veröffentlicht 17.04.2019; Stand 31.01.2019; gültig bis 30.01.2024 · Abruf 2026-10-12
- Datenschutz-Grundverordnung (EU) 2016/679 ↗Verordnung vom 27.04.2016, Amtsblatt L119 vom 04.05.2016 · Abruf 2026-10-12
- MDCG 2019-11 Rev.1: Qualifikation und Klassifikation von Software ↗Revision 1, Juni 2025 · Abruf 2026-10-12
- WIdO: GKV-Arzneimittelindex April 2026 ↗April 2026; WIdO e-Paper 10 (2026) · Abruf 2026-10-12
- WHO AWaRe classification 2025 ↗2025; B09489; Veröffentlichung 05.09.2025 · Abruf 2026-10-12
- WHO: Copyright, Licensing and Permissions ↗Webbedingungen, geprüft 12.10.2026 · Abruf 2026-10-12
- ECDC: EARS-Net Annual Epidemiological Report 2024 ↗AER 2024, veröffentlicht 18.11.2025; Tabelle 9b: 2020–2024 · Abruf 2026-10-12
- ECDC: Rechte an Inhalten und Daten Dritter ↗Webbedingungen, geprüft 12.10.2026 · Abruf 2026-10-12
- Sliplane: Deploying a Service ↗Dokumentation, geprüft 12.10.2026 · Abruf 2026-10-12
- Sliplane: SSL und HTTPS ↗Dokumentation, geprüft 12.10.2026 · Abruf 2026-10-12
- Sliplane: Private Networking ↗Dokumentation, geprüft 12.10.2026 · Abruf 2026-10-12
- Sliplane: Persistente Volumes und Backups ↗Dokumentation, geprüft 12.10.2026 · Abruf 2026-10-12
- Sliplane: Volume-Anbindung an Dienste ↗Dokumentation, geprüft 12.10.2026 · Abruf 2026-10-12
Kein Zugriff auf Klinikdaten, Mitgliederlisten oder technische Betriebsdetails aus dieser Übersicht. UNITY-Logo als unverändertes originales Bildasset; Schriftarten aus dem lokalen System, keine externen Font- oder Trackinganfragen.