4. Qualitätssicherungskonferenz des Gemeinsamen Bundesausschusses Weiterentwicklung und technische Anforderungen der QS-Software

Transkript

1 4. Qualitätssicherungskonferenz des Gemeinsamen Bundesausschusses Weiterentwicklung und technische Anforderungen der QS-Software Berlin, Sabine Löffler, Leitung AG QS, bvitg

2 WEITERENTWICKLUNG UND TECHNISCHE ANFORDERUNGEN DER QS-SOFTWARE 1. QSKH-Richtlinie PID FU-Verfahren Allgemeine Bestandsaufnahme Spezielle Anforderungen 16/1 und NEO Spezielle Anforderungen Datenfluss in QSKH- / Qesü-Richtlinie Basisanforderungen Spezifikation 3. Fazit und Ausblick 2

3 WEITERENTWICKLUNG UND TECHNISCHE ANFORDERUNGEN DER QS-SOFTWARE 1. QSKH-Richtlinie PID FU-Verfahren Allgemeine Bestandsaufnahme Spezielle Anforderungen 16/1 und NEO Spezielle Anforderungen Datenfluss in QSKH- / Qesü-Richtlinie Basisanforderungen Spezifikation 3. Fazit und Ausblick 3

4 QSKH-RL PID FU-VERFAHREN ALLGEMEINE BESTANDSAUFNAHME Module definiert: 17er, 16/1 und NEO Erfassung ab 2011 Infrastruktur aufgebaut (LE/LQS/Vertrauensstelle / Bundesauswertungsstelle) Verschlüsselung und Pseudonymisierung der relevanten Datensegmente geklärt und im Umlauf Software verfügbar PID-Integration? Software verfügbar Export XML? Teilnahmequote der LE? Umsetzungsquote SW/KH? Bilanzierung wünschenswert aus SWA-Sicht, Registrierung SWA bei AQUA? 4

5 QSKH-RL PID FU-VERFAHREN ALLGEMEINE BESTANDSAUFNAHME Datenflussmodell gemäß Qesü-RL 5

6 QSKH-RL PID FU-VERFAHREN ALLGEMEINE BESTANDSAUFNAHME Ziele bei Verschlüsselung aus Sicht SWA: maximaler Anwendungskomfort bei minimalem Fehlerpotential für Anwender vor Ort Erfordernisse Öffentliche Schlüssel LQS/DAS/Vertrauensstelle verfügbar: rechtzeitig, spezifikationsintegriert, verfahrensstabil Verfahrens- und Modulkennung plus Registriercode ermöglichen Automatismus ohne Fehlerquelle für Anwender Normenklarheit: Richtlinie mit verbindlicher Publikationsvorgabe öffentlicher Schlüssel in der Spezifikation 6

7 WEITERENTWICKLUNG UND TECHNISCHE ANFORDERUNGEN DER QS-SOFTWARE 1. QSKH-Richtlinie PID FU-Verfahren Allgemeine Bestandsaufnahme Spezielle Anforderungen 16/1 und NEO Spezielle Anforderungen Datenfluss in QSKH- / Qesü-Richtlinie Basisanforderungen Spezifikation 3. Fazit und Ausblick 7

8 Spezielle Anforderungen 16/1 und NEO Ziel QSKH-RL: PID-Daten aus 16/1 und NEO sollen längsschnittliche Qualitätsdatenzusammenführung ermöglichen => Fallzusammenführung zur Betrachtung im Zeitablauf über KV- Daten Mutter (Follow-Up) Aktueller Status: Probeverfahren zur Evaluation mit normativem Anspruch zur Implementierung. Bedenken und Hinweise zur Machbarkeit seitens der SWA bereits in 2010 gegenüber AQUA kommuniziert. 8

9 16/1 und NEO: Use Case Betrachtung Abrechnung Entbindung KV- Nummer der Mutter Mutter Geburt Gesunder Säugling KV-Karte der Mutter Abrechnung Entbindung KV- Nummer des Kindes Mutter Geburt Kranker Säugling KV-Karte des Kindes 9

10 16/1 und NEO: Use Case Betrachtung + = Sorgerecht Gesunder Säugling NN Monat Einweisung Kranker Säugling Krankenhaus Sorgerecht KV- Karte Kind 10

11 Spezielle Anforderungen 16/1 und NEO IST I: TechDok: Normativ: manuelle Erfassung der PID-Daten durch Anwender nicht zulässig, Ausnahme NEO Ausfüllhinweise: Deskriptiv: Muss-Vorgabe mit optionalem Charakter (muss, falls automatisch möglich) Softwarelandschaft LE: TechDok mit Hinweis: KH müssen mit SWA geeignete Wege finden, PID-Daten verfügbar zu machen (=> Integration / Schnittstelle) 11

12 Spezielle Anforderungen 16/1 und NEO IST - II: Geburtshilfe und NEO IT-Systemumgebung Schnittstelle zu KIS? Schnittstelle zwischen Geburtshilfe und NEO? Behandlungsvertrag? NEO-Fall mit Angabe Mutter de jure erlaubt? reicht die Vorgabe hier wirklich aus? reicht das Patienteninformationsblatt hier aus? 12

13 Spezielle Anforderungen 16/1 und NEO Pilotverfahren Verknüpfung ist machbar: AQUA /1 XML mit PID NEO XML mit PID % % % 16/1 - XML mit PID 16/1 - XML ohne PID 16/1 - kein XML % % % NEO - XML mit PID NEO - XML ohne PID NEO - kein XML Zu welchem Preis? 100% Abdeckung? PID-Daten probat bei 16/1 und NEO? Planungssicherheit für LE und SWA Manuelle Erfassung vorsehen? 13

14 WEITERENTWICKLUNG UND TECHNISCHE ANFORDERUNGEN DER QS-SOFTWARE 1. QSKH-Richtlinie PID FU-Verfahren Allgemeine Bestandsaufnahme Spezielle Anforderungen 16/1 und NEO Spezielle Anforderungen Datenfluss in QSKH- / Qesü-Richtlinie Basisanforderungen Spezifikation 3. Fazit und Ausblick 14

15 SPEZIELLE ANFORDERUNGEN DATENFLUSS IN 2013 Herausforderungen: csv-export parallel zu XML-Export FU Test mit Workflowelementen zur Rückprotokollierung bei bereits abgeschlossenem regulärem Verfahren Software steht für LE rechtzeitig zur Verfügung LE sind auf Test dieser Verfahrenskomponente vorbereitet Kernkomponente XML 2013 Fortsetzung der Erprobung des Exports im XML-Format im Rahmen des Sonderexportes in 2013 Test im Sinne der frühzeitigen Erprobung des neuen Exportformates für die Gesamtumstellung des Exportes auf XML in

16 SPEZIELLE ANFORDERUNGEN DATENFLUSS IN 2013 Wichtige Voraussetzungen und Essentials: Spezifikation unterstützt Bestätigungs- und Fehlermeldungsverfahren unter XML analog zu Access Meldungen auf Transaktions- und Vorgangsebene sind eindeutig referenzierbar und zwar zwischen allen Partnern im Datenfluss Testläufe vor Roll-Out der Software schließen rechtzeitig alle Partner mit ein Spezifikation Access bleibt Master und XML wird abgeleitet SWA / LE: Erprobung in 2013 nutzt Fehler im konstruktiven Dialog als Kernelement zur optimierten Weiterentwicklung für Produktivstart in

17 WEITERENTWICKLUNG UND TECHNISCHE ANFORDERUNGEN DER QS-SOFTWARE 1. QSKH-Richtlinie PID FU-Verfahren Allgemeine Bestandsaufnahme Spezielle Anforderungen 16/1 und NEO Spezielle Anforderungen Datenfluss in QSKH- / Qesü-Richtlinie Basisanforderungen Spezifikation 3. Fazit und Ausblick 17

18 QSKH- / QESÜ-RICHTLINIE BASISANFORDERUNGEN SPEZIFIKATION Spezifikation Technische Vorgaben: Access-DB bleibt Master; Vorgaben zum XML-Verfahren leiten sich 1:1 daraus ab Technische Dokumentationen präzisieren die Vorgaben der Datenbank, decken dabei die Vorgaben der Datenbank ab und gehen weder inhaltlich noch formal darüber hinaus Ziel Systemstabilität im Zeichen des Verfahrensausbaus: Routinen bei SWA auf zeitgerechte Umsetzung ausgelegt Dynamik der Modulerweiterung kann aufgefangen werden 18

19 QSKH- / QESÜ-RICHTLINIE BASISANFORDERUNGEN SPEZIFIKATION Spezifikation Modulauslösung - Normenklarheit: Präzise auf Modulebene, sowohl im Fallkontext stationär als auch ambulant Gleichermaßen für Auslösung nach QS-Filter Ein- und Ausschlussbedingungen sowie für die Fall-Grundmenge Denn: Abrechnungskontext muss ebenso klar aus QS- Filter-Algorithmus hervorgehen Ziel: QS-Filter muss weiterhin prozessbegleitend prüfen und auslösen können Workflow steht im Fokus + Sicherstellung Vollzähligkeit 19

20 QSKH- / QESÜ-RICHTLINIE BASISANFORDERUNGEN SPEZIFIKATION Probeverfahren / Testläufe: Zeitliche Taktung für Probeverfahren und Testläufe für neue und oder geänderte Spezifikationsanteile müssen sich in Regelbetrieb einfügen Cave: FU 2013 plus DekRisikoStatistik plus Soll-Statistik in 2014 werden Ressourcen auf SWA und LE-Seite binden Parallele Probeverfahren mit regionaler Begrenzung bei geringer LE-Dichte erschweren effektive Implementierung zur Erstevaluation Chancenabwägung SWA: Machbarkeitsprüfung Pilotierung im Bundesverfahren ohne Sanktionierung bei Regelbetrieb 20

21 QSKH- / QESÜ-RICHTLINIE BASISANFORDERUNGEN SPEZIFIKATION Verschlüsselung / Pseudonymisierung / Datenschutz: Vorgaben bei finalisierter Prüfung durch Bundesdatenschutz vor Regelbetrieb Workflowkomponenten im konstruktiven Dialog mit SWA und LE abbilden und für Regelbetrieb sicherstellen Beispiel: Schlüsselvergabe und Verteilung sowie Zuordnung für Module im Abrechnungskontext 21

22 WEITERENTWICKLUNG UND TECHNISCHE ANFORDERUNGEN DER QS-SOFTWARE 1. QSKH-Richtlinie PID FU-Verfahren Allgemeine Bestandsaufnahme Spezielle Anforderungen 16/1 und NEO Spezielle Anforderungen Datenfluss in QSKH- / Qesü-Richtlinie Basisanforderungen Spezifikation 3. Fazit und Ausblick 22

23 FAZIT UND AUSBLICK Ausreichende Zeitdimension für Integration von Modulen, Modulauslösung bei Beachtung der Schnittstellenkonzeptionen zwischen KIS und QS-Systemen inklusive Test und Einführung bei LE Absicherung der Datenschutzvorgaben liegt in Hoheit der Gesetzgebung, SWA und LE brauchen verlässliche Vorgaben Auslösung im Fallbezug und auf Ebene der Filteralgorithmen bedarf eindeutiger und im Gesetz verankerter Vorgaben Klare Spielregeln für Probeverfahren und Einführungszyklen mit Verbindlichkeit zwecks Planungssicherheit für SWA / LE Transparenz von Zeitlinien für verbindliche Einführung Spezifikationsentwicklung im Schulterschluss: inhaltliche, formale u. technische Aspekte plus Workflow und Integration 23

24 VIELEN DANK FÜR IHRE AUFMERKSAMKEIT FRAGEN UND ANREGUNGEN? 24

25 Quellen Datentransparenzverordnung, siehe: pdf%27] - Technische Dokumentation und Spezifikation

26 Wir sind gerne für Sie da! Bundesverband Gesundheits-IT bvitg e.v. Neustädtische Kirchstraße Berlin Tel: Fax: info@bvitg.de Web: 26