[Seite 1]
Leistungsbeschreibung
zum Vergabeverfahren
Software zur Krankenhaus-Rechnungsprüfung
Vergabenummer: 1005162
Seite 1 von 60
[Seite 2]
Inhaltsverzeichnis
1 DAK-Gesundheit ..................................................................................................... 6
1.1 Portrait der DAK-Gesundheit......................................................................... 6
1.2 Portrait des Fachbereiches ........................................................................... 7
2 Ausgangssituation ................................................................................................... 7
2.1 Gegenstand der Beschaffung ....................................................................... 7
2.2 Leistungsbeginn ............................................................................................. 8
2.3 Lizenzumfang................................................................................................. 8
3 Technische Rahmenbedingungen .......................................................................... 8
3.1 Betrieb in Citrix-, Terminalserver- und Cloud-Arbeitsplatzumgebungen ..... 9
4 Benutzerfreundlichkeit........................................................................................... 10
4.1 Bedienbarkeit ............................................................................................... 10
4.2 Wahrnehmbarkeit ........................................................................................ 10
4.3 Verständlichkeit............................................................................................ 11
4.4 Assistenz und Unterstützung....................................................................... 11
4.5 Systemintegration und Navigation .............................................................. 11
5 Anforderungen an die Prüfsoftware ...................................................................... 11
5.1 Allgemeines und Zertifizierung .................................................................... 11
5.1.1 Administrationsmöglichkeiten der Software ............................................ 12
5.2 Schnittstellen stationär / ambulant .............................................................. 13
5.2.1 Krankenhaus-Datenaustausch-Verfahren (DA) ...................................... 13
5.2.2 Medizinischer Dienst (MD)-Datenaustausch (DA) .................................. 14
5.2.3 Automatisierte Vorlage ............................................................................. 15
5.2.4 MD-Portal .................................................................................................. 15
5.2.5 Verwaltungsprozess ................................................................................. 16
5.2.6 Stammdaten ............................................................................................. 17
5.3 Fallbearbeitung ............................................................................................ 18
5.3.1 Rechnungsprüfung ................................................................................... 18
5.3.2 Fallkonstellationen und Datenumfang für die Rechnungsprüfung.......... 18
5.3.3 Anforderung an Simulation ...................................................................... 20
5.3.4 Besondere Fallkonstellationen ................................................................. 21
5.3.5 Prüf- und Regelwerk................................................................................. 21
Seite 2 von 60
[Seite 3]
5.3.6 Modul zur Prüfregelerstellung .................................................................. 23
5.3.7 Durchführung der Rechnungsprüfung ..................................................... 26
5.3.8 Unauffällige Fälle ...................................................................................... 27
5.3.9 Auffällige Fälle .......................................................................................... 27
5.3.10 Anzeige aller Fälle über Filter/Spezifikation ......................................... 28
5.3.11 Dokumentation ...................................................................................... 29
5.3.12 TP4a-Nachrichten ................................................................................. 30
5.3.13 Schriftverkehr ........................................................................................ 31
5.3.14 Terminvorlage ....................................................................................... 31
5.3.15 Export der Fälle über Filterkriterien ...................................................... 32
5.3.16 Übergabe von Zahlungsinformationen ................................................. 32
5.3.17 Anzeige / Einsichtnahme in Fremd- oder DAK-Dokumente ................ 32
5.3.18 Ad-Hoc-Reporting ................................................................................. 32
5.3.19 Plausibilitätsprüfung .............................................................................. 32
5.4 Analysetool (Regelentwicklung und Bewertung) ........................................ 33
6 Maschinelles Erkennen von Prüfpotenzialen (KI) ................................................ 33
6.1 Anbindung externer KI-Modelle ................................................................... 34
6.1.1 Allgemein .................................................................................................. 34
6.1.2 Verarbeitung von KI-Ergebnissen ............................................................ 35
6.1.3 Fehlerhandling und Resilienz................................................................... 35
6.1.4 Fallback-Mechanismen bei der KI-Anbindung ........................................ 36
7 Schriftwechsel und Dokumentenmanagementsystem (DMS) ............................. 37
8 Anbindung an HyperDoc der Firma IQDoQ GmbH und M/Text als Option ........ 37
8.1 Anbindung an HyperDoc der Firma IQDoQ GmbH .................................... 38
8.2 Übergabe von Dokumenten an das DMS aus der Software heraus.......... 38
8.3 Aufruf von Dokumenten im DMS aus der Software heraus ....................... 38
9 Controlling Modul .................................................................................................. 41
9.1 Zielsetzung ................................................................................................... 41
9.2 Funktionale Anforderungen ......................................................................... 42
9.2.1 Kennzahlen- und KPI-System .................................................................. 42
9.2.2 Analyse- und Auswertungsfunktionen ..................................................... 42
9.2.3 Reporting und Dashboards ...................................................................... 43
9.2.4 Budget- und Maßnahmensteuerung ........................................................ 43
9.2.5 Schnittstellen ............................................................................................ 43
Seite 3 von 60
[Seite 4]
9.3 Anbindung externes DWH ........................................................................... 44
9.4 Datenqualität und Revisionssicherheit ........................................................ 44
9.5 Es muss eine Historisierung und Dokumentation der Kennzahlen sowie die Durchführung von Plausibilitätsprüfungen gewährleistet werden. Performance- und Skalierbarkeit ..................................................................................................... 45
9.6 Abbildung der Prüfstufen und Auswertbarkeit der Teilergebnisse ............. 45
Abbildung der Prüfstufen ...................................................................................... 45
Abweisung einer Rechnung aus formalen Gründen ............................................ 45
Alternative Klärverfahren ...................................................................................... 46
MD-Verfahren ........................................................................................................ 46
Erörterungsverfahren ............................................................................................ 46
Rückwirkende Rechnungsprüfung ........................................................................ 47
9.7 Ergebnisse und Wirksamkeit je Prüfstufe ................................................... 47
9.8 Gesamtfallbetrachtung stationär ................................................................. 48
9.9 Gesamtfallbetrachtung vertragsärztliche Hybrid-DRG ............................... 48
9.10 Berichtswesen und Analyseanforderungen ................................................ 48
9.11 Revisionssicherheit und Nachvollziehbarkeit ............................................. 50
10 Entwicklungsbegleitung und Test ...................................................................... 50
10.1 Software-Anpassungen ............................................................................... 51
11 Datenschutz ........................................................................................................ 51
12 Migration ............................................................................................................. 51
13 Dokumentation der Software.............................................................................. 52
14 Schulungen / Schulungssystem ......................................................................... 53
14.1 Anwenderschulung ...................................................................................... 53
14.2 Schulung Prüfregelerstellung ...................................................................... 54
14.3 Schulung Administratoren ........................................................................... 55
15 Anforderungen an Service und Support ............................................................ 55
16 Betrieb von Software auf der OpenShift-Containerplattform ............................ 56
16.1 Gegenstand der Leistung ............................................................................ 56
16.2 Leistungsumfang ......................................................................................... 56
16.3 Technische und fachliche Anforderungen .................................................. 57
16.4 Lieferung und Bereitstellung........................................................................ 58
16.5 Dokumentation ............................................................................................. 58
16.6 Mitwirkungspflichten des Auftragnehmers .................................................. 58
16.7 Verbindlichkeit.............................................................................................. 58 Seite 4 von 60
[Seite 5]
17 Abkürzungsverzeichnis ...................................................................................... 59
Seite 5 von 60
[Seite 6]
1 DAK-Gesundheit
1.1 Portrait der DAK-Gesundheit
Die DAK-Gesundheit gehört zu Deutschlands größten Krankenkassen: über 5,6
Millionen Menschen schenken uns ihr Vertrauen. Wir unterstützen unsere Versicherten auf vielfältige Weise sowohl beim Gesundwerden als auch beim Gesundbleiben – und
das bereits seit 250 Jahren. Eine hochwertige Versorgung der Versicherten,
ausgezeichnete Leistungen und ein umfassender Kundenservice stehen bei der DAK-
Gesundheit im Mittelpunkt. Die DAK-Gesundheit ist eine Körperschaft des öffentlichen Rechts mit Selbstverwaltung.
Sie unterliegt dem Solidarprinzip. Das heißt: allen Versicherten stehen die gleichen
Leistungen zu; Beitrag, persönliche gesundheitliche Risiken, Eintrittsalter oder Familienstand spielen keine Rolle. Als große bundesweite gesetzliche Krankenkasse
gleicht die DAK-Gesundheit intern die unterschiedliche wirtschaftliche Leistungsfähigkeit
der verschiedenen Regionen Deutschlands aus. Jedes Mitglied der DAK-Gesundheit hat somit, egal wo es wohnt, die gleichen Ansprüche und profitiert von den Diensten und
Kenntnissen einer bundesweit agierenden Kasse.
Die DAK-Gesundheit verfolgt das Ziel, zur Erhöhung der Attraktivität ihrer
Dienstleistungen, ihren Versicherten und Partnern, ständig verbesserte digitale Service- Angebote zu unterbreiten. Dabei geht es bei den digitalen Lösungen nicht nur um die
Kommunikation mit der Krankenkasse. Genauso wichtig ist, dass wichtige Dokumente
nicht nur nicht mehr verloren gehen, sondern deren Inhalte für alle Akteure im Gesundheitswesen komfortabel und sinnvoll nutzbar sind. Behandlungen können auch
per Video durchgeführt oder z.B. von Spezialisten aus der Ferne begleitet werden.
Nutzerfreundliche Apps (egal ob verordnet oder optional) ergänzen die Behandlung
sowie die Vorsorge. Künstliche Intelligenz hilft an zahlreichen Stellen sowohl den Kunden als auch Leistungserbringern oder Krankenkassen.
Name: DAK-Gesundheit Rechtsform: Körperschaft des öffentlichen Rechts
Anschrift Zentrale: DAK-Gesundheit
Nagelsweg 27 – 31 20097 Hamburg
Versicherte: 5,6 Millionen
Mitglieder 4,6 Millionen
Seite 6 von 60
[Seite 7]
Geschäftsstellen: Rund 300 bundesweit
Mitarbeiter: 10.700
1.2 Portrait des Fachbereiches
Zu den Aufgaben der DAK-Gesundheit gehört auch die Prüfung der Rechnungen, die
uns die Krankenhäuser für die ambulante und stationäre Versorgung unserer
Versicherten übermitteln. Die DAK-Gesundheit kommt damit Ihrem gesetzlichen Auftrag einer wirtschaftlichen Leistungsgewährung und Mittelverwendung nach.
Die Steuerung der ca. 2 Mio. Krankenhausfälle/Jahr erfolgt durch 400 Mitarbeiter in der
Rechnungsprüfung. Weitere 100 Personen sind mit der Regelentwicklung und -analyse betraut. Momentan werden täglich bis zu 40.000 Meldungseingänge verarbeitet.
2 Ausgangssituation
Die Rechnungsprüfung und die Regelentwicklung und -analyse werden derzeit mit der Software „Kolumbus“ der Firma Innovas durchgeführt.
2.1 Gegenstand der Beschaffung
Gegenstand dieser Ausschreibung ist die Überlassung einer vollumfänglich
bestehenden Prüfsoftware (mit diversen Modulen) in Form der Miete.
Einleitend werden zur Orientierung folgende Anforderungen an die Software und
den Anbieter gestellt (Details folgen in der Leistungsbeschreibung):
- Maschinelle Unterstützung bei der Bearbeitung von Rechnungen der Krankenhäuser, der ambulant operierenden Ärzte am Krankenhaus sowie die
vertragsärztlichen Ärzte.
- Installation und Konfiguration der Softwarebestandteile im Test-, Schulungs- und Echtsystem bei dem AG,
- Beratung und Unterstützung der Administratoren und der Auftraggeberin (AG), sowie
- Softwarepflege, -aktualisierung und Support über die Vertragslaufzeit.
Seite 7 von 60
[Seite 8]
2.2 Leistungsbeginn Die Leistungserbringung beginnt am 24.01.2027.
Zu diesem Zeitpunkt müssen die, in dieser Leistungsbeschreibung definierten, Anforderungen vollumfänglich zur Verfügung stehen, sofern nicht anders geregelt.
Der Betrieb der Software ist nicht Bestandteil dieser Ausschreibung. Der Betrieb erfolgt für die Auftraggeberin durch die Bitmarck GmbH.
2.3 Lizenzumfang
Es werden Lizenzen für 15 Admin-User und 425 Lizenzen mit Schreib-/Leserechten
benötigt.
3 Technische Rahmenbedingungen
Die Daten werden der AG performant, gem. der in Punkt 15 definierten Servicelevel zur Verfügung gestellt. Der AN sichert der AG zu, dass bei Produktivsetzung der
Software alle Anwender der AG performant (15) arbeiten können.
Die Anwendung unterstützt OAuth 2.0 basiertes SSO oder MFA mit TOTP oder
Passkeys (z.B. FIDO2 Sticks, Windows Hello)
Die Software ermöglicht die Rechtesteuerung der Anwender über das Abrufen von Berechtigungsstufen aus dem Microsoft EntraID.
Die Anwendung erlaubt an alle relevanten Stellen den Einsatz von Transportverschlüsselung nach Stand der Technik (TLS1.2 oder höher)
Bei nicht containerbasierten Datenbankkomponenten wird Encryption at Rest unterstützt (z.B. durch TDE).
Die Anwendung protokolliert sicherheitsrelevante Ereignisse (z.B. u.A.
fehlgeschlagene Logins, Rechteänderungen, Verwendung von administrativen Benutzer, Löschung von Datensätzen mitsamt Benutzernamen, Zeitstempel,
alter/neuer Wert).
Seite 8 von 60
[Seite 9]
Die Software muss zwingend immer auf den aktuellen Release-Stand des Stammsystems BITMARCK_21c|ng kostenlos aktualisiert werden.
Es muss ein Testsystem vorgehalten werden, welches pseudonymisierte Daten aus dem Produktivsystem verarbeiten und vorhalten kann.
3.1 Betrieb in Citrix-, Terminalserver- und Cloud- Arbeitsplatzumgebungen
Die angebotene Software muss für den Einsatz in einer Citrix- bzw. Microsoft Remote Desktop Services (RDS) Umgebung geeignet sein und die nachfolgenden
Anforderungen erfüllen:
- Die Client-Software muss vom Hersteller für den Betrieb auf einer Citrix- Terminalserverfarm sowie auf Microsoft Remote Desktop Services freigegeben
sein.
- Die Software muss den gleichzeitigen Betrieb durch mehrere Benutzer auf einem
gemeinsamen Terminalserver (Multi-User-Betrieb) ohne funktionale Einschränkungen unterstützen.
- Die anwendungsbezogene Datenhaltung darf nicht lokal auf dem Terminalserver
erfolgen. Sämtliche produktiven Anwendungs- und Benutzerdaten müssen auf externen Systemen oder zentralen Speicherorten abgelegt werden können.
- Die zu installierenden Client-Komponenten müssen für ein automatisiertes
Softwaredeployment geeignet sein und eine unbeaufsichtigte Installation (Silent Installation) unterstützen.
- Sofern die Software browserbasiert genutzt wird, müssen mindestens die aktuell
unterstützten Versionen der Browser Microsoft Edge und Google Chrome
unterstützt werden. 6. Die Software muss in Umgebungen mit Roaming-Profilen bzw. vergleichbaren
Profilmanagement-Lösungen (z. B. FSLogix) lauffähig sein, ohne dass
Benutzerprofile dauerhaft lokal auf dem jeweiligen System vorgehalten werden müssen.
- Die Software muss mindestens auf Microsoft Windows Server 2022 lauffähig sein
und vom Hersteller für zukünftige Versionen der Windows-Server-Plattform
fortlaufend unterstützt werden. Insbesondere muss ein Upgrade auf aktuelle bzw.
Seite 9 von 60
[Seite 10]
zukünftige Serverversionen (derzeit Windows Server 2025) ohne
Herstellerwechsel oder grundlegende Produktanpassungen möglich sein. 8. Die Software muss auf Cloud-Arbeitsplätzen, insbesondere in Microsoft Azure
Virtual Desktop (AVD)-Umgebungen, installierbar und voll funktionsfähig sein.
- Die Software muss über Microsoft Intune bzw. vergleichbare Enterprise- Softwareverteilungslösungen automatisiert bereitgestellt, aktualisiert und verwaltet
werden können.
4 Benutzerfreundlichkeit
Die Software muss die Anforderungen der Web Content Accessibility Guidelines
(WCAG) der jeweils aktuellen Version mindestens Konformitätsstufe AA sowie der
Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) erfüllen.
4.1 Bedienbarkeit
4.1.1 Die vollständige Bedienung der Software muss ohne Maus ausschließlich über
Tastatur möglich sein.
4.1.2 Alle interaktiven Elemente (z. B. Eingabefelder, Register, Buttons) müssen fokussierbar, logisch angeordnet und eindeutig erkennbar sein.
4.1.3 Die Fokusreihenfolge muss einer nachvollziehbaren und konsistenten
Navigationslogik folgen.
4.1.4 Es dürfen keine Tastaturfallen entstehen.
4.2 Wahrnehmbarkeit
4.2.1 Inhalte müssen für Nutzerinnen und Nutzer klar erkennbar und ausreichend
kontrastreich dargestellt werden (gemäß den Anforderungen der WCAG). 4.2.2 Texte und Benutzeroberflächen müssen bis mindestens 200 % skalierbar sein,
ohne dass Informationen oder Funktionen verloren gehen.
4.2.3 Die Darstellung darf nicht von festen Pixel- oder physikalischen Maßeinheiten
abhängig sein, sondern muss sich geräte- und auflösungsunabhängig anpassen (responsive Darstellung).
4.2.4 Schriftgrößen und Bedienelemente müssen so gestaltet sein, dass eine gut
lesbare Darstellung bei üblichen Betrachtungsabständen gewährleistet ist.
Seite 10 von 60
[Seite 11]
4.3 Verständlichkeit
4.3.1 Die Benutzeroberfläche muss konsistent, selbsterklärend und intuitiv bedienbar
sein. 4.3.2 Für alle wesentlichen Funktionen sind kontextbezogene Hilfen bereitzustellen,
z.B.: Tooltips, integrierte Hilfeseitenkontext, sensitiver Hilfeaufruf
4.3.3 Fehlermeldungen müssen verständlich formuliert sein und konkrete Hinweise zur Behebung enthalten.
4.4 Assistenz und Unterstützung
4.4.1 Die Software muss die Nutzung durch assistive Technologien (z. B.
Screenreader) unterstützen. 4.4.2 Alle Inhalte und Funktionen müssen programmatisch eindeutig identifizierbar sein
(z.B. durch semantische Strukturierung).
4.5 Systemintegration und Navigation
4.5.1: Die Software muss die Möglichkeit bieten, direkt in verknüpfte Systeme bzw. relevante Masken zu wechseln (Deep-Linking).
4.5.2: Navigationswege müssen nachvollziehbar, konsistent und benutzerfreundlich gestaltet sein.
5 Anforderungen an die Prüfsoftware
5.1 Allgemeines und Zertifizierung
Die Software muss in deutscher Sprache zur Verfügung gestellt werden.
Die Software muss die Auftraggeberin (AG) bei den Prozessen, die im Rahmen einer
Krankenhausabrechnungsprüfung, einer Prüfung der Hybrid-DRG Abrechnung und Beanstandungsfallbearbeitung entstehen, unterstützen. Dies muss durch einen
zertifizierten Grouper für die Abrechnungsbereiche DRG, PEPP und Hybrid-DRG Seite 11 von 60
[Seite 12]
sichergestellt sein. Außerdem muss der Leistungsgruppen-Grouper gemäß KHTG,
V1.0 zur Verfügung gestellt werden, sobald dieser abschließend entwickelt wurde.
Das ist insbesondere eine Unterstützung im Rahmen der unterschiedlichen
Datenaustausch-Verfahren (DA), der Rechnungsprüfung und Regelwerkbereitstellung sowie -weiterentwicklung, der Anlage und Bearbeitung von Beanstandungsfällen, des
Erstellens von Schriftverkehr, der Abwicklung des Prüfverfahrens gemäß § 275c Abs.
1 SGB V i. V. m. der PrüfvV, sowie aller weiteren gesetzlichen und vertraglichen Vorschriften. Außerdem muss es eine Möglichkeit geben, Fälle gemäß § 115b bis 120
SGB V zu prüfen. Weiterhin muss die Software die AG bei der Konsolidierung von
wichtigen Abrechnungsdaten (Controlling) unterstützen.
Der AN stellt für die AG und der Bitmarck Technik GmbH ein Ticket-Tool zur Verfügung,
mit dem Fehler und auch Weiterentwicklungsanforderungen durch die AG oder der
Bitmarck Technik GmbH an den AN gemeldet werden können. Anpassungen, die sich aus gesetzlichen Änderungen ergeben, müssen zeitgerecht mit
Inkrafttreten umgesetzt und Adressatenbezogen kommuniziert werden.
5.1.1 Administrationsmöglichkeiten der Software
Für folgende Kriterien müssen eigenständige Administrationsmöglichkeiten für die AG
über die operative Oberfläche zur Verfügung stehen. Diese müssen ohne Einbindung
des Softwareherstellers bedienbar sein. Das Know-How zur eigenständigen Administration muss durch den AN innerhalb einer Schulung vermittelt werden. (s.
Punkt 14)
-
Benutzerberechtigungen (s. Punkt 5.2.5)
-
Prüfquotenverwaltung und Import der GKV-SV-Daten
-
Entgelte
-
Vordruckverwaltung
-
Textbausteine
-
Individuelle Zahlungsziele
-
Krankenhaus- und Versicherteninformationen
-
Aufgabenverwaltung (Fristen, Workflows usw.)
-
Teamverwaltung / Abbildung der internen Organisation
-
Verwaltung der Aufgabensteuerung und Zuteilung
Seite 12 von 60
[Seite 13]
- Möglichkeit zur individuellen Dokumentenablage innerhalb des Systems (bspw.
Arbeitsanleitungen / fachliche Zusatzinformationen des AN)
Eine Erweiterung der Administrationsmöglichkeiten muss bei Bedarf oder
Notwendigkeit möglich sein.
5.2 Schnittstellen stationär / ambulant
Die Software des AN muss vollumfänglich über die KHFM-Schnittstelle der
Branchensoftware BITMARCK_21c|ng Daten beziehen und zurückschreiben.
Es muss sichergestellt sein, dass die Software die Daten zu jedem Zeitpunkt konsistent
vorhält und diese an das Stammsystem BITMARCK_21c|ng zu jedem Zeitpunkt über
die Schnittstelle übermitteln kann. Sämtliche zahlungsrelevante Informationen müssen als Zahlungsvorschlag über die
Schnittstelle an das Stammsystem BITMARCK_21c|ng zurückgegeben und von dort
zur Auszahlung gebracht werden können.
Die Software muss ein paralleles, Online-Arbeiten gem. der in Punkt 15 definierten
Servicelevel während des Batch-Datenimports sicherstellen.
5.2.1 Krankenhaus-Datenaustausch-Verfahren (DA)
Im Rahmen der Schnittstelle zum Stammsystem BITMARCK_21c|ng stellt die Software
die Weiterverarbeitung der eingehenden Krankenhaus-DA Datensätze, insbesondere im Hinblick auf § 301 SGB V, des Prüfverfahrens gemäß § 275c Abs. 1 SGB V und
allen gesetzlichen und vertraglichen Vorschriften sicher.
Des Weiteren muss eine Schnittstelle zum Stammsystem BITMARCK_21c|ng zur Verfügung gestellt werden. Die Weiterverarbeitung und Prüfung der eingehenden
Abrechnungen des niedergelassenen Bereichs, insbesondere im Hinblick auf § 295
SGB V Datenaustausch TP1 müssen durch die Software sichergestellt werden.
Die Software fasst die Textsegmente der KAIN- bzw. INKA-Datensätze zu einem
fortlaufenden Text zusammen. Der Text muss gedruckt, kopiert oder im Datenaustausch mit dem Medizinischen Dienst (MD) weiterverwendet werden können.
Seite 13 von 60
[Seite 14]
Die Nutzung mehrerer Textsegmente ist beispielsweise bei der Begründung der
leistungsrechtlichen Entscheidung gemäß § 8 PrüfvV (=KAIN-Datensatz) und bei der Durchführung des Bestreitens / Erörterungsverfahrens gemäß § 9 PrüfvV (=INKA-
Datensatz) erforderlich. Es muss daher auch möglich sein, den Inhalt dieser
Textsegmente unkompliziert in den Datensatz für eine Folgebeauftragung des MD übernehmen zu können.
Alle weiteren relevanten Schnittstellen des Stammsystems BITMARCK_21c|ng, welche für die Bearbeitung von Prozessen im Rahmen einer Krankenhausabrechnung,
einer Abrechnung von Hybrid-DRGs nach §115f SGB V und ggf. bei der Übermittlung
von Daten benötigt werden, müssen von der Software unterstützt werden.
Hinweis: Schnittstellenbeschreibungen werden von der Bitmarck GmbH in
Releasezyklen aktualisiert und liegen den Kooperationspartnern in der aktuellen
Fassung vor. Sollten Schnittstellenbeschreibungen unbekannt sein, können diese auf Anfrage zur Verfügung gestellt werden.
5.2.2 Medizinischer Dienst (MD)-Datenaustausch (DA)
Die Software muss die Durchführung des Datenaustauschs mit den Medizinischen
Diensten der Krankenversicherung (MD) ermöglichen, d.h. die Beauftragung des MD mit der Fallprüfung durch die Krankenkasse und die Annahme der entsprechenden
Begutachtungsergebnisse und Gutachten, die der MD nach der Fallprüfung an die AG
zurücksendet. Der Datenaustausch muss über die KHFM-Schnittstelle der AG laufen.
Technische Grundlage sind die „Anlagen zum elektronischen Datenaustausch
zwischen Krankenkassen und Medizinischen Diensten der Krankenversicherung im
Bereich Krankenhaus“ in der jeweils durch den GKV-Spitzenverband veröffentlichten Fassung.
Maßgebliche Referenz ist die zum Zeitpunkt der Angebotsabgabe veröffentlichte
Version abrufbar unter:
https://www.vdek.com/vertragspartner/Datenaustausch_GKV-
SPV_MDK/Krankenhaus_1-
12/_jcr_content/par/download_1894179866/file.res/Anl1Anh1_DA_GKV_MD_KH_V1 _12_B_3_20261001oA.pdf).
Seite 14 von 60
[Seite 15]
Die Software muss darüber hinaus in der Lage sein, zukünftige Änderungen dieser
Anlagen innerhalb der vorgegebenen Frist nach deren Veröffentlichung umzusetzen.
Die Kodierempfehlungen der SEG 4 (Sozialmedizinische Expertengruppe „Vergütung
und Abrechnung“) des MD müssen in der Software integriert sein. Der AN muss die Kodierempfehlungen der SEG 4 laufend bei Anpassungen, spätestens innerhalb von 4
Wochen, aktualisieren.
Es muss die Möglichkeit bestehen, MD-Anfragen automatisch aus den
Simulationsergebnissen zu erstellen / zu erzeugen.
Die AG muss die Möglichkeit haben, die Textbausteine im Einzelfall weiter zu
bearbeiten, zu ergänzen oder zu löschen.
Die AG muss die Möglichkeit haben, die jeweils automatisch angelegten
Prüfgegenstände, Kranzfragen und Auffälligkeiten in den MD-Aufträgen weiter zu bearbeiten, zu ergänzen oder zu löschen.
In der Software besteht die Möglichkeit, weitere Datenaustauschverfahren mit dem MD
anzubinden (z.B. WBB).
5.2.3 Automatisierte Vorlage
Die Software muss ermöglichen, dass MD-DA-Aufträge über Regeln/Bedingungen
automatisch erstellt werden können.
5.2.4 MD-Portal
Die Software muss die Durchführung des Dokumentenaustauschs mit den
Medizinischen Diensten der Krankenversicherung (MD) über das MD-Portal zur Durchführung des Erörterungsverfahrens ermöglichen.
Dazu gehören die Anforderungen von Dokumenten, Stornierungen als auch die
Annahme von Dokumenten sowie deren Ver- und Entschlüsselung. Die Bereitstellung muss fallbezogen abgebildet werden. Zusätzlich besteht die
Möglichkeit der Zusammenfassung / Zusammenführung einzelner Dokumente. Ebenso
muss eine manuelle als auch maschinelle Löschung von Dokumenten aus dem Leistungsfall möglich sein.
Seite 15 von 60
[Seite 16]
Technische Grundlage sind die jeweils gültigen Anlagen zum elektronischen
Datenaustausch zwischen Krankenkassen und Medizinischen Diensten der Krankenversicherung im Bereich Krankenhaus für das MD-Portal und die elektronische
Vorgangsübermittlungs-Vereinbarung (eVV).
Im folgenden Link stehen alle zitierten und relevanten Vereinbarungen und technischen
Beschreibungen in der aktuellen Fassung zur Verfügung:
spitzenverband.de/krankenversicherung/krankenhaeuser/krankenhaeuser_abr
echnung/abrechnungspruefung/abrechnungspruefung.jsp#collapse163858
5.2.5 Verwaltungsprozess
Es muss die Möglichkeit bestehen, für die unterschiedlichen Nutzer der verschiedenen
Software-Module separate Zugriffe und Rollen zu vergeben. Regelmäßige Audits und Rechte-Aktualisierungen müssen durch die Software technisch unterstützt werden. Die
Software bietet ein RBAC basiertes Berechtigungssystem, um unterschiedlichen
Benutzergruppen zu verwalten.
Die Software bietet die Möglichkeit, Administrationsrechte abzustufen. Es muss
möglich sein, für unterschiedliche Benutzergruppen modulbezogen nur Lese- oder
Schreibrechte zu erteilen.
Seite 16 von 60
[Seite 17]
Die Software muss über Funktionen zur Fristenüberwachung, Aufgabenerzeugung und
–steuerung sowie Automatisierungsmöglichkeiten verfügen. Die Zuordnung der Aufgaben muss team-, mitarbeiter- oder rollenbezogen flexibel von der AG
administrierbar sein.
Dabei müssen die Aufgaben nach
-
formalen Kriterien wie z.B. IK, Standortnummer und Name
-
fachlichen Kriterien wie z.B. Entgeltbereiche (z.B. DRG, H-DRG, PEPP, stationsäquivalente Behandlung (StäB)),
-
Prüfregeln
-
Fachabteilungen
-
Leistungsgruppen
-
Hauptdiagnosen
zugeordnet werden können.
Zu bestimmten Vorgängen (z.B. PrüfvV-Fristen, Eingang MD-Gutachten, offene
Rechnungen usw.) müssen sogenannte Terminvorlagen automatisch erzeugt werden.
Die Konfiguration der Terminvorlagen ist von der AG administrierbar.
Einzelne oder mehrere Aufgaben oder Terminvorlagen müssen an andere Anwender
oder Teams mit geringem Bedienaufwand weitergeleitet werden können.
Dies ist insbesondere erfüllt, wenn die Weiterleitung mit maximal drei/vier/fünf
Benutzerinteraktionen durchgeführt werden kann und
- keine erneute manuelle Eingabe bereits vorhandener Daten erforderlich ist
5.2.6 Stammdaten
Die Software muss eine Importfunktion für Stamm-, Struktur- und Vertragspartnerdaten
bereitstellen, die von verschiedenen Institutionen oder Systemen (vdek, 21c|ng) zur
Verfügung gestellt werden. Der Ladeprozess muss automatisiert erfolgen können. Die Daten müssen über die Oberfläche eingesehen und bei Bedarf gepflegt werden
können. Die Bereitstellung muss täglich erfolgen bzw. aktualisiert werden können.
Übersicht über Dateiformate:
Seite 17 von 60
[Seite 18]
Manuell angelegte / geänderte Einträge in den Stammdaten dürfen durch Updates nicht überschrieben bzw. eine Konfigurationsmöglichkeit vorgehalten werden.
5.3 Fallbearbeitung
5.3.1 Rechnungsprüfung
Die Software muss die AG befähigen, sämtliche stationäre Krankenhausfälle sowie
Fälle nach §115b-§120 SGB V inhaltlich zu prüfen und im Rahmen dieser Prüfung durch maschinelle Fallsimulationen mögliche Retaxierungspotenziale je Prüfregel
auszuweisen. Bei den Fällen nach §115b-§120 SGB V muss die AG die Möglichkeit
erhalten, über Konfigurationseinstellungen alle oder mehrere der AMBO-/SÜV-
Prüfbereiche deaktivieren zu können.
Die Software muss maschinell zeitüberschneidende bzw. übergreifende
Fallkonstellationen zwischen Hybrid-DRG und tagesgleichen vollstationären Aufenthalten sowie tagesgleichen Abrechnungen nach §115b Ambulantes Operieren
am Krankenhaus ausweisen, um Doppelabrechnung zu identifizieren.
Die nachfolgend dargestellten Anforderungen an Prüfregeln und deren Inhalte,
Abdeckung und Berechnung gelten sowohl für die maschinelle Rechnungsprüfung im
Batchverfahren als auch im Rahmen von manuellen Fallsimulationen durch den
Anwender.
5.3.2 Fallkonstellationen und Datenumfang für die
Rechnungsprüfung
Im Rahmen der stationären Rechnungsprüfung müssen sämtliche vor-/teil-
/vollstationären Fälle / Hybrid-DRG (z.B. Somatik/PEPP/StäB/BPflValt) in allen
Seite 18 von 60
[Seite 19]
Fallzuständen (mit/ohne Entlassungsanzeige, mit/ohne Schlussrechnung) durch die
Software prüfbar sein. Hierfür sind entsprechende Regelwerkstrukturen und Berechnungslogiken vorzuhalten. Es ist eine Trennung des Regelwerkes für die
Fallzustände abzubilden.
Die Darstellung der Fallzustände basiert darauf, dass ein Fall als prüffähig einzustufen
ist, sobald eine Rechnung im Fall vorliegt. Entsprechend kann ein Fall in der
einfachsten Form aus den Meldungen “Aufnahmeanzeige und Zwischenrechnung” bestehen. Für diese Konstellation muss definiert sein, wie der Fall zu prüfen bzw. zu
berechnen ist (wie ist die Verweildauer des Falles zu berechnen, wie sind die Entgelte
zu ermitteln, soll der Fall bspw. an den Grouper übergeben werden).
Das Prüfregelwerk ist in der Lage, die Leistungsdaten aus anderen Leistungsbereichen
des Stammsystems BITMARCK_21c|ng, z.B. amb. Leistungen, Arznei-, Heil-,
Hilfsmittel und Pflegedaten (AHHP), sämtliche Informationen nach §301 SGB V zum Prüffall sowie die Krankenhausfallhistorie des Versicherten, soweit diese im
Stammsystem enthalten ist, zu integrieren.
Für die Prüfung der AHHP und der Krankenhaus-Fallhistorie können
Zeiträume/Intervalle durch die Software berechnet und Fallverläufe über Prüfregeln
abgebildet werden.
Die Software muss besondere Regelkriterien und -strukturen zur Prüfung von Fällen
aus dem IK-Bereich von Nordrhein-Westfalen vorhalten. Die Software muss neben
dem inek-Leistungsgruppengrouper Bund eine Grouperlösung für NRW- Leistungsgruppen zur Verfügung stellen, um die inhaltliche Richtigkeit, der vom KH
abgerechneten Leistungsgruppen prüfen zu können.
Außerdem muss die Software Regelkriterien und -strukturen zur Prüfung von Fällen nach §115b bis 120 SGB V anbieten. Die Software muss einen Grouper für Hybrid-
DRG am Krankenhaus und vertragsärztliche Hybrid-DRG Abrechnungen zur
Verfügung stellen, um die inhaltliche Richtigkeit der Hybrid-DRG prüfen zu können.
Die Prüfaspekte müssen nach Priorität konfigurierbar sein. Diese müssen in einer
Rangfolge (Priorität) festgelegt, sortiert und dann in der Prüfung hintereinander gemäß Rangfolge angezeigt und ausgewertet werden können. Regeln oder Regelwerke mit
Seite 19 von 60
[Seite 20]
höherer Priorität müssen auf die Prüfergebnisse von Regelwerken mit gleicher oder
niedriger Priorität zugreifen können
5.3.3 Anforderung an Simulation
Die Software muss im Regelwerk die Möglichkeit bereitstellen, in einer Regel eine
Simulation des Falles abzubilden, den Fall entsprechend dieser Simulationsvorgabe
fiktiv berechnen zu lassen und das Delta in Euro zwischen den vom Krankenhaus
eingereichten Entgelten und den von der Software ermittelten Entgelten auszugeben. Die Simulation muss auch eine Fallzusammenführung abbilden können. Diese
Anforderung betrifft zunächst die Verwendung von Fällen, die noch nicht einer
Fallzusammenführung unterzogen wurden und entsprechend noch keine Pseudo- Fachabteilung 0001 oder 0002 besitzen. Die Verwendung von Fällen, die bereits eine
Zusammenführung beinhalten, ist zunächst auszuschließen.
Die Regelsimulation muss Veränderungen im Prüffall ermöglichen, die grundsätzlich
alle groupierungsrelevanten Kriterien abdecken. Im Rahmen der Simulation ist auch die Beziehung zu anderen Leistungsfällen (z.B. Krankenhaus-Fälle, ambulante Fälle)
zu berücksichtigen (bspw., wenn sich die Verweildauer im Prüffall geändert hat und
sich dadurch die Beziehung zu einem Vor-/Nachfall des Versicherten hinsichtlich der Frage einer Verlegung ändert).
Für die Berechnung des Deltas sind sämtliche vorkommenden stationären Entgelte neu zu berechnen, zu berücksichtigen und in der Oberfläche im Vergleich zwischen
eingereichten und ermittelten Entgelten übersichtlich auszugeben. Eine Simulation von
Fällen §115b -§120 SGB V ist optional.
Die Ergebnisse der Simulation müssen weiterverarbeitet werden können.
Simulationsergebnisse auf Grundlage einer Fallzusammenführung müssen ebenfalls
weiterverarbeitet werden können. Auf Basis dieser Ergebnisse müssen die Differenzen angezeigt werden und ggf. weiterverarbeitet werden können. Die
Simulationsergebnisse müssen dokumentiert und historisiert werden. Dies gilt sowohl
für das maschinelle Batchverfahren als auch für das manuelle Verfahren. Für den Fall, dass ein Gutachten vom MD maschinell übermittelt wurde, muss die
Möglichkeit bestehen, eine entsprechende Simulation aufgrund der Daten der MD-
Übermittlung automatisiert zu erstellen und zu speichern.
Seite 20 von 60
[Seite 21]
Es muss bei einer Verweildauerkürzung von vollstationären Fällen (Verweildauer
größer 2) auch die alternativ resultierende Hybrid-DRG anzeigt werden (obwohl Original Aufnahme- und Entlassdatum mehr als 2 Tage Abstand haben).
5.3.4 Besondere Fallkonstellationen
Die Software muss folgende Anforderungen abdecken:
• Eine Fallzusammenführung ist in einer Prüfregelsimulation abzubilden, indem die von
der Prüfung identifizierten Fälle systemseitig zusammengeführt werden. Die Software
muss für eine Fallzusammenführung mögliche Fälle anbieten. Diese Fälle sollen als
zusammengeführter Fall aufgebaut werden und zu den eingereichten Krankenhausrechnungen eine entsprechende Gegenrechnung erzeugen.
• Nichtverwendung von Fällen eines gesunden Neugeborenen und eines
Organspenders in fallübergreifenden Prüfungen, einer Fallzusammenführung sowie
zur Berechnung einer Verlegung.
• Verwendung von Krankenhaus-Fällen ohne Rechnung (nur Aufnahmeanzeige/nur
Aufnahmeanzeige und Entlassungsanzeige), um für Prüffälle eine Verlegung ermitteln
zu können.
• Es muss eine Möglichkeit fürs Grouping der Leistungsgruppen NRW geben
(Übergangsfrist bis zur verbindlichen Einführung der Leistungsgruppen Bund in NRW
bis 31.12.2030).
5.3.5 Prüf- und Regelwerk
Die Software des AN muss ein eigenes ausführliches medizinisches und formales
Prüfregelwerk zu allen Vergütungssystematiken (bspw. ambulant inkl. Vertragsärztlicher Abrechnung, stationär; SÜV, Hybrid) inklusive einer Dokumentation
(PDF oder Online) zur Verfügung stellen.
Der AN muss ein Team mit Expertinnen und Experten mit hoher Fachkompetenz zur
zeitnahen Regelpflege, für Anpassungen vorhalten.
Die hohe Fachkompetenz muss anhand der folgenden
Mindestkriterien nachgewiesen werden:
Seite 21 von 60
[Seite 22]
- der überwiegende Teil der Experten muss eine mindestens zweijährige Erfahrung im
Medizincontrolling und dem Regelwerk (inhaltlich medizinisch, formal, technisch) haben
- Mindestens einer der Mitarbeitenden muss zusätzlich ein abgeschlossenes
Medizinstudium haben und dieses mit entsprechenden Zertifikaten/Diplomen oder ähnlichem nachweisen.
Prinzipiell bietet der AN kurzfristig Schulungen für die AG an, in denen die Prüfregeln des AN inhaltlich – medizinisch erklärt werden. Der AN muss dazu ein Team mit
Expertinnen und Experten mit hoher Fachkompetenz bereitstellen.
Der AN liefert unterjährige Anpassungen, bspw. bei gesetzlichen Änderungen, neuen
Abrechnungsbestimmungen oder Entgeltschlüsseln,
Schlichtungsausschussentscheidungen, Urteilen zeitnah oder mindestens 1x pro Quartal.
Anpassungen zum Jahreswechsel bspw. OPS, ICD, Entgeltschlüssel, Simulation,
Grouping muss der AN zum Ende des ablaufenden Jahres, wenn entsprechende Informationen veröffentlicht sind, bereitstellen.
Kundenindividuelle Anpassungen des Regelwerks müssen möglich sein (Automatisierungen, eigene Regeltexte, Unterdrückungen, Anpassung von
Gewichtungen). Anpassungen weisen eine einfache Sichtbarkeit der Änderungen in
der Prüfregelübersicht auf. Diese Änderungen müssen selbstständig von der AG durchgeführt werden können,
ohne dass der AN hiervon Kenntnis erhält.
Die individuelle Ausgestaltung des Regelwerkes durch die AG unterliegt dem
Betriebsgeheimnis und ist für den AN nicht einsehbar.
Es muss die Möglichkeit einer rückwirkenden Rechnungsprüfung angeboten werden.
Z.B. ist es möglich für einen zurückliegenden Zeitraum für bestimmte Prüfregeln den Prüfbericht neu erzeugen zu lassen.
Der AN gewährt der AG uneingeschränkten Zugriff auf alle vom AN erstellten Prüfregeln. Die AG muss im Prüfregelwerk Prüfregeln ansehen, deaktivieren, kopieren
und anpassen können. Die Prüfregeltexte müssen individuell anpassbar sein, mit einer
Zeichenmenge von mindestens 5000 Zeichen und übersichtlicher Strukturierung/
Seite 22 von 60
[Seite 23]
Formatierung. Dabei hat die Software sicherzustellen, dass die AG ein nutzbares
Backup des Prüfregelwerks anfertigen kann.
Der AN muss eine vollständige digitale Detaildokumentation mit flexibler Filter-, Such-
und Sortierfunktion mitliefern, welche die Bedingungen, den Text und den logischen Aufbau jeder einzelnen Prüfregel beinhaltet. Auch müssen die Anwender der AG die
Möglichkeit haben, selbst zu entscheiden, ob er nur das eigene Prüfregelwerk nutzt
und das gesamte oder Teile des Prüfregelwerks des AN deaktiviert.
Der AN muss eine mindestens quartalsweise stattfindende Prüfung, Anpassung und
Ergänzung des Prüfregelwerks durchführen. Zusätzlich muss das gesamte
Prüfregelwerk zum Jahreswechsel aktualisiert werden.
Der AN muss die Überarbeitungen durch Release-Unterlagen detailliert darstellen. Die
Prüfregeln der AG dürfen bei einem Update des Prüfregelwerks durch den AN nicht überschrieben werden.
Für die Bearbeitung von Anfragen seitens der AG bei inhaltlichen Fragestellungen im Prüfregelwerk oder Anpassungsbedarfen bei Fehlern oder unvollständigen Angaben
muss ein Support mit einem ausreichend großen Team mit Expertinnen und Experten
mit hoher Fachkompetenz zur zeitnahen Bearbeitung zur Verfügung stehen.
Die hohe Fachkompetenz muss anhand der folgenden Mindestkriterien nachgewiesen
werden:
- der überwiegende Teil der Experten muss eine mindestens zweijährige Erfahrung im Medizincontrolling und dem Regelwerk (inhaltlich medizinisch, formal, technisch)
haben
- Mindestens einer der Mitarbeitenden muss zusätzlich ein Medizinstudium erfolgreich
abgeschlossen haben und dieses mit entsprechenden Zertifikaten/Diplomen auf Nachfrage nachweisen können.
5.3.6 Modul zur Prüfregelerstellung
Für die Erstellung, Einsichtnahme, Backup und Aktivierung bzw. Deaktivierung der
Regeln bzw. des Regelwerkes muss der AN ein Modul zur Prüfregelerstellung inklusive
eines Handbuches mit Erklärungen zur Verfügung stellen.
Seite 23 von 60
[Seite 24]
Im Modul zur Prüfregelerstellung sind unterschiedliche Filter-, Such-, und
Sortierfunktionen flexibel kombinierbar vorhanden.
Mit dem Modul zur Prüfregelerstellung müssen auch ohne spezielle
Datenbankkenntnisse komplexe Prüfregeln von der AG erstellt werden können. Änderungen am Prüfregelwerk sind zu dokumentieren und inklusive der Benutzerdaten
des ändernden Anwenders revisionssicher aufzuzeichnen und zu archivieren. Ein
Zugriff auf das Archiv muss gewährleistet sein. Es müssen formale Plausibilitätskontrollen im Modul zur Prüfregelerstellung existieren,
damit Logik-Fehler in den Regeln ausgeschlossen werden können (z.B. syntaktische,
logische, mathematische Prüfung der Regeln). Bei der Erstellung von Prüfregeln in
diesem Modul bestehen Toleranzen hinsichtlich Groß- und Kleinschreibung sowie bei der Leerzeichensetzung. Zudem muss die Möglichkeit bestehen, mit Platzhaltern und
Listen zu arbeiten. Bei der Erstellung von Prüfregeln müssen Parameter beliebig durch
„und/oder/nicht“ verknüpfbar sein.
Tabellen/Listen, die in Regeln verwendet werden, müssen über externe Quellen befüllt
und importiert werden können.
Es muss die Möglichkeit geben, über Prüfregeln verschiedene Automatisierungen
vorzunehmen. Dazu zählen unter anderem:
- automatisierte Bezahlung
- automatisierte Rechnungsabweisung, abhängig von der erwarteten Ersparnis (wird
Rechnung teurer oder günstiger)
-
Automatisierungsstopp
-
automatisierter Versand einer ANFM
-
Rechnung automatisch zu 0,00 € korrigiert freigeben
-
automatisierte Anfrage eines Falldialogs
-
automatisierte Erstellung von Wiedervorlagen
-
automatisierte Anlage der Falldokumentation (Notizen / Ergebnisse)
-
automatisierte Erstellung eines MD-Auftrages mit der Möglichkeit den MD-Auftrag
weiterzubearbeiten, versandfertig anzulegen bzw. direkt zu versenden
- automatisierter Versand einer Leistungsrechtlichen Entscheidung bei
Gutachteneingang (abhängig von gestellten Kranzfragen) o bei negativem Gutachten + Fallabschluss
Seite 24 von 60
[Seite 25]
o bei positivem Gutachten mit automatischem Grouping und Versand der
entsprechenden Leistungsrechtlichen Entscheidung (z.B. bei Prüfung uGVD, ambulantes Potential, Kodierung)
- Neuberechnung nach Ablehnung der initialen Rechnung ohne Regelanschlag und ohne Gutschrift soll bei Bedarf die automatische Zahlung unterbinden (z.B. wenn
Neuberechnung höher ist als Ursprungsrechnung)
Wechselwirkungen/Hierarchien von verschiedenen Automatisierungsmöglichkeiten
innerhalb eines Falles müssen sichtbar (z.B. Warnhinweis) gemacht werden bzw.
niedrigschwellig nachschlagbar und nachvollziehbar sein.
Das Modul zur Prüfregelerstellung ist auf Mehrnutzerbetrieb ausgerichtet. Zudem muss
sichergestellt sein, dass Änderungen eines Anwenders nicht durch die Änderungen
eines anderen Anwenders überschrieben werden.
Die Prüfregeln in diesem Modul müssen mit einem Bearbeitungsstand (z.B. in
Bearbeitung, geprüft, freigegeben) versehen werden.
Jede Regel, jede Bedingung, und jede Tabelle/Liste ist eindeutig klassifizierbar. Es
muss die Möglichkeit bestehen, Regeln und Tabellen je Jahrgang separat abzulegen.
Die Prüfregeln sind optional Organisationseinheiten zuzuordnen und somit nur auf die
Krankenhäuser der jeweiligen Organisationseinheit anzuwenden.
Das Modul zur Prüfregelerstellung muss einen Freigabemechanismus beinhalten, über
den die entwickelten Prüfregeln in das produktive Regelwerk gegeben werden. Der
Freigabemechanismus ist rollenbasiert (siehe 5.2.5).
Die Software kann eine Funktionalität anbieten, mit der die Änderungen bspw. zum
Jahreswechsel (wie ICD/OPS, andere Schlüssel wie Aufnahmegründe,
Entgeltschlüssel etc.) automatisiert in den Regelwerken angepasst werden und die Anpassungen als Protokoll ausgegeben werden. Die Funktionalität muss auch die
Möglichkeit bieten, Schlüssel durch die AG einpflegen zu lassen.
Die Software muss die Schnittstelle zu 21c bieten, um Prüfregeln mit Variablen zu
erstellen, die aus externen Quellen (bspw. externer Score; LEI-Fehler, externer
Vorprüfsoftware des vdek (VPS)) bezogen werden.
Seite 25 von 60
[Seite 26]
Es muss die Möglichkeit bestehen, (vdek-)Struktur- und Budgetdaten zu importieren. Struktur- und Budgetdaten müssen zur Rechnungsprüfung mit Prüfregeln verknüpft
werden können.
Die AG muss eine Gewichtung der Prüfregeln vornehmen können. Bei der
Implementierung stellt der AN die Gewichtung der softwareseitigen Prüfregeln
entsprechend seinen Erfahrungswerten ein. Die Gewichtung muss die Priorität der einzelnen Prüfregeln in Bezug auf die Beanstandungsnotwendigkeit darstellen. Die
Prüfregeln müssen individuell bzw. in Abhängigkeit von der Gewichtung einem
Schweregrad (z.B. Hinweis, Warnung, Fehler) zugeordnet werden können.
Anwender, welche nicht mit der Regelerstellung betraut und keinen schreibenden
Zugriff auf das Modul zur Prüfregelerstellung besitzen, müssen einen lesenden Zugriff
auf das Regelwerk und die in den Regeln abgebildeten Algorithmen, Texte, Funktionen etc. erhalten. Außerdem ist eine direkte Verzweigung aus einem Beanstandungsfall
anhand der in der Rechnungsprüfung angeschlagenen oder im Rahmen einer
Fallsimulation erzeugten Regeln ins Regelwerk bereitzustellen.
5.3.7 Durchführung der Rechnungsprüfung
Für ambulante bzw. stationäre Krankenhausfälle sowie Hybrid-DRG Fälle, für die eine
für die Rechnungsprüfung relevante Veränderung im Stammsystem BITMARCK_21c|ng erfolgte, muss die Rechnungsprüfung außerhalb der Online-Zeit
(1) maschinell gesteuert als Batchverarbeitung aufgerufen werden.
Des Weiteren muss sichergestellt werden, dass ein Fall manuell aus dem
Stammsystem (oder der Software selbst) an die Rechnungsprüfung übergeben wird.
Die Software stellt sicher, dass bei Vorliegen bestimmter Konstellationen ein Fall
erneut an die Rechnungsprüfung übergeben wird.
Bei jeder Übergabe eines Falles muss eine eigene Fallversion inkl. aller berechneten
Fallkriterien und der erzeugten Prüfergebnisse abgelegt werden. Dies gilt auch für den Fall, dass keine Prüfergebnisse erzeugt werden.
1 Online-Zeit ist von 6:30-20:30 Uhr. Seite 26 von 60
[Seite 27]
Außerdem muss das Ergebnis einer Simulation aus einer Prüfregel heraus
automatisiert als Fallversion innerhalb des Falles abzulegen, d.h. die entsprechend der Regelsimulation angepassten Falldaten und die damit erzeugten Entgelte sind zu
speichern.
Des Weiteren müssen die durch den Anwender manuell durchgeführten
Fallsimulationen mit den erzeugten Falldaten speicherbar sein und zum Wiederaufruf
zur Verfügung stehen. Dies gilt insbesondere bei Fallzusammenführungen und Falltrennungen.
Die Software muss eine Funktionalität bereitstellen, mit der Prüfergebnisse aus
vorgelagerten Prüfstufen (Vorprüfsoftware des vdek; Prüfungen des Stammsystems BITMARCK_21c|ng) in die Beanstandungsfälle zu übernehmen und zu klassifizieren
bzw. optional auszusteuern sind. Dazu werden FHL-Segmente (Fehlersegmente) im
Rahmen des §301 SGB V Datenaustausch verwendet und mit Verwertung der Informationen technisch entfernt.
Es sind Protokolle mit jedem Rechnungsprüfungsaufruf zu erzeugen, die darstellen, welche Fälle an die Prüfung gegangen sind, welche Prüfergebnisse erzeugt
und welche Fälle ausgesteuert wurden.
Es muss ein manuell befüllbares Freitextfeld für die Dokumentation zu Entscheidungen zum Fall vorgehalten werden. Die Software muss die Möglichkeit
bieten, Textbausteine für die Dokumentation zu hinterlegen.
5.3.8 Unauffällige Fälle
Für unauffällige Fälle (Definition wird von der AG über das Regelwerk vorgegeben)
muss die Software alle offenen Rechnungen maschinell in den Status „akzeptiert“
setzen. Für unauffällige Fälle muss die Software die Möglichkeit bieten, dass diese manuell
und/oder maschinell auffällig gestellt werden.
5.3.9 Auffällige Fälle
Seite 27 von 60
[Seite 28]
Wird ein Fall in der Rechnungsprüfung auffällig, muss er eine eindeutige
Kennzeichnung als Beanstandungsfall erhalten, welches selektierbar ist. Des Weiteren muss (bspw. über das Regelwerk) konfiguriert werden, ob für auffällige Fälle
automatisch oder manuell gezahlt und die Information an das Stammsystem
übermittelt wird.
Automatisierung
Für auffällige Fälle muss die Software die Möglichkeit bieten, dass alle offenen Rechnungen in den Status „akzeptiert“ gesetzt werden und dass gleichzeitig eine
Terminvorlage erstellt wird. Die Software muss die Möglichkeit bieten, dass ein
automatisierter Fallabschluss von unbearbeiteten Fällen auf Basis bestimmter
Kriterien mit Übermittlung der Zahlungsinformationen an das Stammsystem BITMARCK_21c|ng zur weiteren Bearbeitung durchgeführt wird.
5.3.10 Anzeige aller Fälle über Filter/Spezifikation
Der AN muss die Möglichkeit, Standardfilter zur grundsätzlichen Fallzuordnung
anzulegen, zur Verfügung stellen.
Es müssen alle Fälle inkl. der dunkelverarbeiteten Fälle angezeigt werden können. Es
muss bei automatisch verarbeiteten Fällen/Rechnungen möglich sein, alle Prüfhinweise über die Oberfläche anzeigen zu lassen, da diese ggf. für
Folgeprozesse relevant sind und eine manuelle Korrektur notwendig ist.
Es muss die Möglichkeit bestehen, für die unterschiedlichen Nutzer der
verschiedenen Software-Module Standardfilter über die Oberfläche mit separaten
Zugriffen und Rollen zu vergeben. Ein Austausch der Filter z.B. auf Berechtigungsebene (u.a. Sachbearbeiter, Teamleiter/Gruppenleiter,
Dienststellenleiter) muss möglich sein. Jeder Anwender muss die Möglichkeit haben,
individuelle Filter zu speichern.
Beanstandungsfälle müssen über definierte Kriterien (z.B. Kennzeichnung als
Beanstandungsfall, IK, Krankenhaus-Aufnahmenummer, Aufnahmedatum), auch als
Kombination von Kriterien, gefiltert und in der Anzeige sortiert werden können. Aus der Ergebnisliste muss es möglich sein, direkt in den beanstandeten Fall zu
verzweigen.
Seite 28 von 60
[Seite 29]
Beanstandungsfälle der Hybrid-DRG Prüfung müssen über definierte Kriterien (z.B.
Kennzeichnung als Beanstandungsfall, BSNR, IK, Krankenhaus-Aufnahmenummer, Aufnahmedatum, Behandlungsdatum, ICD und OPS), auch als Kombination von
Kriterien, gefiltert und in der Anzeige sortiert werden können. Aus der Ergebnisliste
muss es möglich sein, direkt in den beanstandeten Fall zu verzweigen.
Die Software muss für den Datenaustausch mit dem Medizinischen Dienst flexibel
kombinierbare Such- und Filtermöglichkeiten bereitstellen, sowohl für TP4a- als auch für §115f SGB V Datensätze.
Die Such- und Filterfunktionen müssen es ermöglichen, Datensätze anhand mehrerer
Kriterien gleichzeitig (z. B. Fallnummer, Zeitraum, Status, Prüfergebnis) zu selektieren.
Die Software muss zu jedem Fall eine zugehörige Anzeige von ambulanten
Behandlungen (bspw. TP1 / Hybrid-DRG), Arznei-, Heil-, Hilfsmittel- und Pflegedaten bei der Fallbearbeitung (Schlüssel, Volltexte, Kataloge) liefern. Es müssen alle
zahlungsrelevanten Informationen (Entgeltarten) angezeigt werden.
Die Software muss die Möglichkeit vorhalten, dass aus dem Leistungsfall im
Umsystem direkt in das Stammsystem gesprungen werden kann.
5.3.11 Dokumentation
Die Fälle müssen mit allen relevanten Informationen an die Software übergeben werden. Hierzu gehören insbesondere die TP4a-Informationen. Diese müssen über
die KHFM-Schnittstelle abgerufen werden können.
Die Software muss während der Fallbearbeitung inhaltlich vorgenommene Änderungen (maschinell oder manuell) anzeigen. Gleichzeitig müssen die Daten im
Stamm -und Umgebungssystem synchronisiert den Anwendenden zur Verfügung
gestellt werden.
Zu den Fällen muss eine Bearbeitungshistorie zur Verfügung stehen, in der alle
wesentlichen Bearbeitungsschritte nachvollziehbar dokumentiert sind.
Seite 29 von 60
[Seite 30]
Für den Fall, dass während der Fallbearbeitung eine Regel angeschlagen hat, muss
die Möglichkeit bestehen, dass der Sachbearbeiter die angeschlagene Regel einsehen kann (Inhalt, warum angeschlagen, Berechnungsgrundlage).
Zu jedem beanstandeten Krankenhausfall muss die AG die entsprechenden stationären Voraufenthalte und Nachaufenthalte einsehen können. Zusätzlich muss
die Information angezeigt werden, ob der jeweilige Vor-/Nachaufenthalt ebenfalls ein
Beanstandungsfall gewesen ist.
Zu jedem beanstandeten Hybrid-DRG-Fall muss die AG (stationäre) Voraufenthalte
und Nachaufenthalte sowie ambulante Leistungen einsehen können.
Die Software muss der AG alle patientenrelevanten Daten auch historisch (z.B. §301-
Nachrichten) zur Verfügung stellen können.
Die Software muss die Möglichkeit vorhalten, dass der Anwendende
leistungserbringerspezifische Informationen wie bspw. Strukturdaten, zeitbezogen
aus dem Fall heraus aufrufen kann. Zusätzlich muss die Möglichkeit bestehen, individuelle Informationen zu erfassen.
5.3.12 TP4a-Nachrichten
Die Software muss eine Möglichkeit bieten, TP4a-Nachrichten neu zuzuordnen und fehlerhafte Verarbeitungsreihenfolgen zu korrigieren.
Aufgetretene Fehler, Warnungen und Hinweise, die beim TP4a-Import auftreten, müssen in der Software angezeigt werden.
Die Software muss ermöglichen, dass auch AUFN-, VERL-, ENTL-, KHIN- und INKA
Meldungen über ein Regelwerk beurteilt und ggf. Meldungen maschinell bewilligt oder abgewiesen werden. Die AG muss die Möglichkeit erhalten, über
Konfigurationseinstellungen diese Funktionalität deaktivieren zu können, um
stattdessen die 21c-Intelligence-Batche zu benutzen.
Darüber hinaus muss die Software das Hinterlegen von Textbausteinen in die
Nachrichtentypen ermöglichen.
Seite 30 von 60
[Seite 31]
5.3.13 Schriftverkehr
Die Software muss die Erstellung von Briefen – automatisch als Workflow oder
manuell mit der Bearbeitung durch den Anwender ermöglichen.
Das automatische Befüllen von Textvariablen aus der Applikation heraus muss
möglich sein, z.B. Versicherten-, Krankenhaus-, Datensatz- und Rechnungsinformationen, Prüffeststellungen, Beanstandungen und interne Angaben
zur Organisationseinheit.
Der zur Verfügung gestellte Umfang der Textvariablen muss sich an den organisatorischen Bedürfnissen der AG orientieren und kann bei Bedarf erweitert
werden.
Die Textbausteine müssen über eine Administrationsoberfläche erstellt, bearbeitet
und gelöscht werden können.
Es muss die Möglichkeit bestehen, dass Informationen aus dem LDAP als
Adressdaten sowie persönliche Informationen in der Software übernommen werden.
5.3.14 Terminvorlage
Anwender müssen für definierte Vorgänge manuell Termine für Terminvorlagen
vergeben können. Es muss möglich sein, Terminvorlagen zu löschen und neue
Termine zu setzen, wenn die Bearbeitung vor Ablauf der ursprünglichen Frist erfolgt.
Terminvorlagen müssen zur Steuerung der Bearbeitung nach Fälligkeitsterminen
(z.B. Zahlungsfrist) sortiert werden können. Es muss sichergestellt werden, dass
definierte Vorgänge/Terminvorlagen zwingend bearbeitet werden müssen.
Zu bestimmten Vorgängen (z.B. PrüfvV-Fristen, Eingang MD-Gutachten, offene
Rechnungen, Eingang TP4a-Nachrichten) müssen sogenannte Terminvorlagen automatisch erzeugt werden. Die Konfiguration der Termine muss von der AG
administrierbar sein und muss je Dienststelle definiert und verwaltet werden können.
Definierte Terminvorlagen (z.B. Eingang eines MD-Gutachtens) müssen automatisch
auf erledigt gesetzt werden, wenn das Ereignis vor Terminfälligkeit eintritt.
Seite 31 von 60
[Seite 32]
Einzelne oder mehrere Aufgaben oder Terminvorlagen müssen mit wenig Aufwand an andere Anwender oder Teams weitergeleitet und abgeschlossen werden können.
Eine Übersicht der in der Prüfsoftware gefilterten Terminvorlagen muss nach MS
Excel exportiert werden können.
5.3.15 Export der Fälle über Filterkriterien
Einzelne Fälle müssen exportiert (Excel oder PDF) bzw. gedruckt werden können. Des Weiteren muss es möglich sein, Aufgabenlisten, Prüfergebnisse des Falles als
auch Prüfverfahrensdaten einzeln auszudrucken oder zu speichern. Der
Informationsinhalt der individuellen Speicherung muss manuell wählbar sein.
5.3.16 Übergabe von Zahlungsinformationen
Die mit der Simulation erzeugte Gegenrechnung zur eingereichten Rechnung muss
als Zahlungsvorschlag an BITMARCK_21c|ng übergeben werden können. Es müssen alle Funktionen innerhalb der Anwendung vorgehalten werden, die den
Zahlungsverkehr im 21c|ng-Stammsystem betreffen, bspw. die Rechnungskorrektur.
5.3.17 Anzeige / Einsichtnahme in Fremd- oder DAK- Dokumente
Die Software muss ermöglichen, Fremddokumente und DAK-Dokumente (z.B. DRG-
Katalog, Fallpauschalenkatalog, SPIK-Leitfaden usw.) direkt aufrufen zu können.
Dabei muss eine fachliche Suche als Volltextsuche möglich sein.
5.3.18 Ad-Hoc-Reporting
Der AN muss Ad-Hoc-Berichte zur Verfügung stellen, über die Fallmengen ermittelt
werden können und die eine Zuordnung auf Anwender ermöglichen.
5.3.19 Plausibilitätsprüfung
Seite 32 von 60
[Seite 33]
Die Eingaben der Anwender müssen durch Plausibilitätsprüfungen validiert werden
(z.B. Pflichtfelder müssen abgefragt werden, Entlassung darf nicht vor Aufnahme möglich sein, etc.) können.
Die Anwender haben die Möglichkeit, Pflichtfelder zu definieren und zu konfigurieren.
5.4 Analysetool (Regelentwicklung und Bewertung)
Es muss ein Modul inklusive eines Handbuchs bereitgestellt werden, in dem die im Modul zur Prüfregelerstellung entwickelten Prüfregeln hinsichtlich ihres
Anschlagsverhaltens monetär und quantitativ bewertet werden können. Die
Bewertung erfolgt auf Basis von Echtfällen, die in dem Modul bereitzustellen sind und auf denen die AG ihre entwickelte Prüfregel testen kann. Wird die Prüfregel im 4-
Augen-Prinzip für einsetzbar eingestuft, wird sie freigegeben und läuft in der
folgenden Verarbeitung der Rechnungsprüfung mit.
Hierfür ist ein Falldatenbestand der letzten vier Jahre (ca. 8 Mio. Krankenhausfälle)
bereitzustellen, aus dem sich der Anwender Subsets ziehen kann, die dann für die Regelbewertung genutzt werden. Je nach Anwendungsstruktur kann die Bearbeitung
im Analysetool in einer separaten Umgebung erfolgen.
Der Falldatenbestand wird durch die AG aktualisiert, der AN stellt ein entsprechendes Verfahren für die Aktualisierung bereit.
Die Echtfälle müssen in ihrem Ursprungszustand – wie vom Krankenhaus vor der Prüfung der Krankenkasse übermittelt – bereitgestellt werden können. Es muss
möglich sein, einzelne Aktivitäten in einem Fall zu definieren, um diese nachladen zu
können.
Mehrere Anwender müssen parallel im Analysetool Auswertungen durchführen
können.
Das Modul muss ganzjährig mit dem aktuellen Prüfregelbestand, den neuesten
Stammdaten bezüglich individuell vereinbarter Entgelte und Basisfallwerten zur
Verfügung stehen.
6 Maschinelles Erkennen von Prüfpotenzialen (KI)
Die Software unterstützt die Auswahl auffälliger Fälle (s. Punkt 5.3.9) durch einen statistischen und analytischen Lernprozess auf Basis künstlicher Intelligenz, der
Seite 33 von 60
[Seite 34]
automatisiert und/oder manuell initiiert in die Entscheidung zur Erzeugung einer
Beanstandung einfließt.
Die Basis für das KI-Modell bilden die bei der AG bereits vorhandenen
Beanstandungsdaten und MD-Informationen. Sofern die Daten der AG durch den AN genutzt werden, dürfen diese Daten nur innerhalb der Prüfsoftware der AG verwendet
werden. Eine darüberhinausgehende Verwendung dieser Daten bedarf der
ausdrücklichen schriftlichen Genehmigung durch die AG.
Sofern beim AN bereits trainierte Modelle zur Verfügung stehen, können diese
ebenfalls genutzt werden. Dieser Prozess muss vom AN für die AG transparent dargestellt werden.
Die Software muss die Möglichkeit sicherstellen, dass ein eigenes KI-Modell
angebunden und verwendet werden kann. Es müssen alle Automatisierungsfunktionen zur Verfügung stehen, die mit einem internen Modul
abgebildet werden.
6.1 Anbindung externer KI-Modelle
6.1.1 Allgemein
Die Anbindung externer KI-Modelle (zur Unterstützung sämtlicher Prozessschritte in
der KH-Rechnungsprüfung) muss gewährleistet werden. Dies gilt auch für die Prüfung der Hybrid-DRGs oder weiteren SÜVs.
Das System muss insbesondere folgende Funktionen bereitstellen:
• Bereitstellung offener, dokumentierter und standardisierter Schnittstellen die eine Anbindung externer Systeme ermöglichen
• Die Performance der Schnittstellen muss für die Mengen der AG (bis zu
20.000 Eingangsrechnungen pro Nachtverarbeitung) ausgelegt sein
• Übergabe von Daten an die KI zur Verarbeitung
• Entgegennahme, Validierung und Weiterverarbeitung der KI-Ergebnisse
• Protokollierung der KI-Anfragen und -Antworten
• Konfigurierbare Nutzung der KI (z.B. Aktivierung/Deaktivierung)
• Benutzeroberfläche zur Anzeige und ggf. Korrektur der KI-Ergebnisse
Seite 34 von 60
[Seite 35]
• Zukunftssichere Erweiterbarkeit der Schnittstellen (z.B. Erweiterung der KI)
Das System darf die hausinterne KI nicht ersetzen, sondern muss deren Ergebnisse integrieren, verarbeiten und in die fachlichen Prozesse der
Krankenhausrechnungsprüfung einbinden können. Dies gilt auch für die Prüfung der
Hybrid-DRGs oder weiteren SÜVs.
6.1.2 Verarbeitung von KI-Ergebnissen
Bereitstellung von Schnittstellen, um KI-Ergebnisse von einem DAK-KI-Service zu
erhalten und den Service über neue / veränderte KH-Abrechnungen zu informieren.
Die Software muss folgende Funktionalitäten zur Verarbeitung von KI-Ergebnissen vorhalten:
• Retry-Mechanismen für die Kommunikation mit dem DAK-KI-Service bei
temporärer Nicht-Verfügbarkeit desselben (oder je nach Schnittstellenart andere
Mechanismen, die Resilienz gegen temporäre Serviceausfälle sicherstellen – siehe auch „Fallback-Mechanismen bei der KI-Anbindung“)
• Konfigurierbare Zuordnung und Interpretation der gelieferten KI-Ergebnisse
innerhalb der fachlichen Workflows und des User-interfaces
• Speicherung der gelieferten Ergebnisse inkl. Zeitstempel, Modell-
/Versionskennzeichnung und Quelle zur vollständigen Nachvollziehbarkeit
Optional besteht die Möglichkeit, mehrere KI-Ergebnisse je Fall (z.B. unterschiedliche Modelle oder Score-Versionen) strukturiert verarbeiten, speichern
und anzeigen zu können.
6.1.3 Fehlerhandling und Resilienz
Die Software muss ein robustes Fehler- und Ausnahmehandling bei der
Kommunikation mit KI-Services bereitstellen:
Implementierung eines robusten Fehler- und Ausnahmehandlings bei der
Kommunikation mit der KI, insbesondere bei
• Zeitüberschreitungen (Timeouts)
• temporären Nichterreichbarkeiten
• fehlerhaften oder unvollständigen Antworten
Seite 35 von 60
[Seite 36]
6.1.4 Fallback-Mechanismen bei der KI-Anbindung
Das System muss ein differenziertes und konfigurierbares Fehlerhandling bei der
Abfrage und Verarbeitung von KI-Ergebnissen (z. B. Scores oder Priorisierungsinformationen) bereitstellen.
Insbesondere sind folgende Anforderungen zu erfüllen: • Wird bei der Abfrage der KI kein Score geliefert (z. B. aufgrund
technischer Fehler, Zeitüberschreitungen, unvollständiger Antworten
oder temporärer Nichterreichbarkeit), muss das System den
betreffenden Fall eindeutig kennzeichnen.
• Für gekennzeichnete Fälle muss es konfigurierbar möglich sein,
o die automatische Verarbeitung auszusetzen und den Fall bis
zur erfolgreichen Score-Ermittlung in einem definierten
Zwischenstatus zu halten oder
o den Fall zunächst ohne Termin weiterzuführen, jedoch für eine nachträgliche Score-Ermittlung vorzumerken.
• Das System muss die strukturierte Sammlung aller Fälle ohne KI-
Score ermöglichen und diese für eine erneute, gebündelte Abfrage
(Batch-Verarbeitung) der KI verfügbar machen.
• Die nachträgliche Abfrage und Übernahme der Scores müssen automatisiert, wiederholbar und nachvollziehbar durchführbar sein.
• Nach erfolgreicher Nachlieferung der Scores muss das System in der
Lage sein,
o die Verarbeitung nachzuholen und
o die Fälle entsprechend der gelieferten Priorisierung
automatisiert in die vorgesehenen fachlichen Workflows einzuordnen.
• Sämtliche Fehlersituationen, Fallback-Entscheidungen und
nachträglichen Score-Übernahmen sind vollständig zu protokollieren
(inkl. Zeitstempel, Ursache, Statusänderung).
Durch diese Mechanismen ist sicherzustellen, dass technische Störungen oder temporär fehlende KI-Ergebnisse nicht zu fachlich falschen oder irreversiblen
Seite 36 von 60
[Seite 37]
Prozessschritten führen und eine kontrollierte, nachholbare Verarbeitung jederzeit
möglich ist.
7 Schriftwechsel und Dokumentenmanagementsystem (DMS)
Die Bereitstellung der in diesem Abschnitt beschriebenen Funktionalitäten ist nicht Bestandteil der zum Leistungsbeginn gemäß Ziffer 2.2 bereitzustellenden Leistungen.
Die Umsetzung erfolgt ausschließlich als optional abrufbare Leistung auf Anforderung
der AG mit einer schriftlichen Vorankündigung von mindestens sechs Monaten.
Die Software kann die Erstellung von Dokumenten direkt aus der Anwendung heraus
ermöglichen. Die erzeugten Dokumente müssen innerhalb der Software gespeichert
und abgelegt werden können.
Darüber hinaus kann die Software eine Vorlagenfunktion bereitstellen, die die
Verwendung von Variablen bzw. Platzhaltern zur automatischen Übernahme von Daten aus dem System ermöglicht. Die Variablen müssen frei in
Dokumentenvorlagen eingebunden werden können, sodass Dokumente automatisiert
und konsistent mit den jeweils verfügbaren Stammdaten und Vorgangsdaten erstellt
werden können.
Optional kann die Möglichkeit bestehen, kundenindividuelle Variablen bereitzustellen
oder diese durch berechtigte Anwender selbstständig anzulegen und zu verwalten, sofern die Standardvariablen für den jeweiligen Anwendungsfall nicht ausreichen.
Die Software kann außerdem eine über die Oberfläche zu erreichende Schnittstelle
zum Dokumentenmanagementsystem zur Verfügung stellen, um Dokumente dort speichern und ablegen zu können.
8 Anbindung an HyperDoc der Firma IQDoQ GmbH und M/Text als Option
Die Bereitstellung der in diesem Abschnitt beschriebenen Funktionalitäten ist nicht
Bestandteil der zum Leistungsbeginn gemäß Ziffer 2.2 bereitzustellenden Leistungen. Die Umsetzung erfolgt ausschließlich als optional abrufbare Leistung auf Anforderung
der AG mit einer schriftlichen Vorankündigung von mindestens sechs Monaten.
Seite 37 von 60
[Seite 38]
Die Anbindung an HyperDoc der IQDoQ GmbH sowie die optionale Integration von
M/Text ermöglichen eine effiziente, medienbruchfreie Dokumentenverarbeitung und schaffen die Grundlage für durchgängig digitale Geschäftsprozesse.
8.1 Anbindung an HyperDoc der Firma IQDoQ GmbH
Bei der AG ist das Dokumentenmanagementsystem (DMS) HyperDoc der Firma IQDoQ GmbH im Einsatz. In diesem wird die eingehende und ausgehende
Kommunikation in elektronischen Akten (eAkte) verwaltet und gespeichert.
Für die zu beschaffende Software leiten sich im Wesentlichen zwei Anwendungsfälle für eine Integration von DMS ab:
- Übergabe von Dokumenten an das DMS aus der Software heraus
- Aufruf von Dokumenten im DMS aus der Software heraus
8.2 Übergabe von Dokumenten an das DMS aus der Software heraus
Der AN stellt sicher, dass die Software eine Schnittstelle für dokumentenbezogene
Fachdaten bereitstellt. Die zu übergebenden dokumentenbezogenen Fachdaten werden während der Projektierung detailliert. Zusätzlich zu den
dokumentenbezogenen Fachdaten und ggf. weiteren Meta-Daten besteht die
Möglichkeit, eine (eindeutige) Dokumenten-ID zu übergeben. Als Schnittstellentechnologie sind die Dokumente über eine synchrone Webservice-
Schnittstelle nach dem SOAP-Standard bereitzustellen. Der Rückgabewert muss
mindestens eine Quittung beinhalten, dass die Annahme der Daten erfolgreich durchgeführt wurde. Für die weitere Verarbeitung ist die Software selbst
verantwortlich.
8.3 Aufruf von Dokumenten im DMS aus der Software heraus
Über die o.g. Dokumenten-ID muss ein Dokument im DMS direkt aufgerufen und zur Anzeige gebracht (Viewer) werden können. Aus dem Dokument muss dann auch auf
die zugehörige Akte verzweigt werden können. Zum Aufruf von Dokumenten stellt der
Seite 38 von 60
[Seite 39]
DMS-Client, der auf dem Terminalserver (WTS) läuft, einen registrierten URI-Handler
zur Verfügung. Als Parameter des URI-Aufrufs wird die Dokumenten-ID verwendet. Der Aufruf erfolgt über folgendes Schema: dmsplus://dok?uuid=.
Der AN stellt sicher, dass ein Aufruf eines Dokuments aus der Software heraus
ermöglicht wird. Es ist nicht notwendig, dass das aus dem DMS aufgerufene Dokument in der Software zur Anzeige gebracht wird.
Die Software muss eine Ablage für alle relevanten Dokumente in der Fallbearbeitung
unterstützen.
Für den Schriftverkehr über M/TEXT (CCM-Lösung (Customer Communication
Management) von kwsoft zur Erstellung, Verwaltung und Ausgabe personalisierter
Kundenkommunikation) muss der AN eine Schnittstelle zur Verfügung stellen, mit der die in Punkt 5.3 genannten fachlichen Anforderungen abgebildet werden können.
Die Anbindung der Prüfsoftware zur Krankenhausrechnungsprüfung an M/TEXT
erfolgt über den BITMARCK 21c|ng Integration Server (I-Server) als zentrale
Integrationskomponente zwischen Fachanwendung und M/TEXT. Der I-Server stellt eine standardisierte Schnittstelle (à Übergabe der Daten erfolgt über den I-Server-
SOAP-Service DocumentServiceWS) bereit und übernimmt die vollständige
technische Orchestrierung der Dokumentenerstellung. Dadurch wird die Prüfsoftware
von der konkreten Implementierung der Dokumentenerzeugung entkoppelt und kann den Schriftverkehr (z.B. leistungsrechtliche Entscheidungen, MD-Korrespondenz)
einheitlich über zentrale M/TEXT-Services erzeugen und kanalspezifisch ausleiten.
Die Datenübergabe an den I-Server erfolgt über eine strukturierte
Service-Schnittstelle und umfasst alle zur Dokumentenerstellung erforderlichen Informationen. Hierzu gehören insbesondere
(1) Steuerinformationen zur Auswahl der Vorlage und des Ausgabekanals,
(2) fachliche Fall- und Abrechnungsdaten der Krankenhausrechnungsprüfung als
Variablen (z.B. Versicherte, Krankenhaus, Prüfergebnisse, Beanstandungen) sowie
(3) Empfänger- und Kontextinformationen zur Zuordnung des Dokuments im weiteren
Prozess.
Diese Struktur ermöglicht es, die Dokumentinhalte vollständig aus der
Fachanwendung zu speisen und gleichzeitig Layout und Textlogik zentral in M/TEXT zu verwalten
Seite 39 von 60
[Seite 40]
Der I-Server validiert und transformiert die übergebenen Daten und leitet sie an den
M/TEXT-DocumentServer weiter, der auf Basis der hinterlegten Templates die Dokumente erzeugt. Dadurch wird ein durchgängiger, revisionssicherer
Dokumentations- und Kommunikationsprozess im Kontext der
Krankenhausrechnungsprüfung gewährleistet.
Die zentrale Nutzung des I-Servers ist eine verbindliche Voraussetzung für eine skalierbare und standardisierte Integration der Prüfsoftware in die bestehende
Systemlandschaft der AG. Sie gewährleistet die Wiederverwendung bestehender
M/TEXT-Funktionen, eine konsistente Steuerung des Schriftverkehrs sowie eine einfache Erweiterbarkeit für zukünftige Anforderungen (z. B. neue Dokumenttypen
oder Ausgabekanäle) im Umfeld der Krankenhausrechnungsprüfung.
Der AN stellt sicher, dass die Prüfsoftware zur Krankenhausrechnungsprüfung die
Anbindung an M/TEXT über den BITMARCK 21c|ng Integration Server (I-Server)
unter Nutzung einer standardisierten Dokumentserver-Schnittstelle realisiert. Der Aufruf der Schnittstelle muss servicebasiert und synchron erfolgen und die Übergabe
aller zur Dokumentenerstellung erforderlichen Informationen ermöglichen.
Der AN gewährleistet, dass die Schnittstellenkommunikation eine strukturierte Übergabe von Steuerinformationen, fachlichen Nutzdaten sowie Empfänger- und
Kontextinformationen vorsieht. Der Aufruf der I-Server-Schnittstelle muss mindestens
folgende Inhalte umfassen:
• Auswahl der zu verwendenden Dokumentvorlage (Template-ID)
• Festlegung des Ausgabekanals (z.B. Druck, E-Mail, DMS)
• Übergabe fachlicher Daten aus der Krankenhausrechnungsprüfung
(insbesondere Versicherte, Fall- und Abrechnungsdaten, Prüfergebnisse und
Beanstandungen)
• Übergabe der Empfängerdaten sowie prozessbezogener
Kontextinformationen
Der AN stellt sicher, dass die Datenübergabe einer konsistenten und erweiterbaren Struktur folgt, die eine Trennung zwischen fachlichen Inhalten und Layoutdefinitionen
ermöglicht. Änderungen an Dokumentvorlagen dürfen keine Anpassung der
Fachanwendung erfordern, sofern die übergebenen Variablen unverändert bleiben.
Die Datenstruktur ist so auszugestalten, dass mehrere fachliche Teilbereiche (z.B. Fall, Prüfung, finanzielle Auswirkungen) logisch getrennt und strukturiert übertragen
werden können.
Beispielhaft muss der AN eine Datenstruktur unterstützen, die mindestens die folgenden logischen Komponenten enthält:
Seite 40 von 60
[Seite 41]
• Steuerkomponente („control“)
• Template-ID
• Ausgabekanal
• Priorität
• Fachliche Daten („data“)
• Versicherteninformationen
• Fall- und Krankenhausdaten
• Prüfergebnisse und ausgelöste Prüfregeln
• finanzielle Auswirkungen der Prüfung
• Empfängerdaten („recipient“)
• Adressat und Kommunikationsdaten
• Kontextinformationen („context“)
• Prozessart (z. B. Krankenhausrechnungsprüfung)
• Dokumenttyp (z. B. Leistungsentscheidung, MD-Korrespondenz)
• Referenzkennungen zur eindeutigen Zuordnung
Der AN stellt sicher, dass der Aufruf der Schnittstelle sowie die Übergabe und
Verarbeitung der Daten revisionssicher protokolliert werden.
Schnittstelle zum I-Server
Für die Integration der Schnittstelle erhält der AN, bei Bestehen eines Partner-
/Kooperationsvertrags mit der BITMARCK GmbH, die Schnittstellenbeschreibung
sowie die Beschreibung zu den verwendeten Web Services Description Language (WSDL) Attributen und Operationen.
9 Controlling Modul
9.1 Zielsetzung
Die AG muss in die Lage versetzt werden, alle Prozesse der
Krankenhausrechnungsprüfung sowie der Prüfung der Hybrid-DRG transparent,
steuerbar und analytisch auswertbar zu machen. Es dient der operativen und strategischen Steuerung von Prüftätigkeiten, Ressourcen und Wirtschaftlichkeit.
Trennscharfe Abgrenzung der Prüfstufen und der Prüfaktivitäten (z.B. formale
Abweisung, MD, EV) hinsichtlich Erfolges pro/gegen DAK.
Seite 41 von 60
[Seite 42]
Der AN stellt standardisierte Auswertungen und Berichte zur Verfügung. Für die AG
muss die Möglichkeit bestehen, eigene Auswertungen zu programmieren und
Berichte zu definieren.
Im Rahmen der Abnahme der Software durch die AG sind die vom AN definierten
Auswertungen durch die AG zu prüfen und ggf. kostenfreie Anpassungen durch diese
beim AN zu veranlassen. Die kostenfreien Anpassungen betreffen insbesondere neue Funktions- und Datenbankfelder sowie gesetzlich vorgegebene
Statistiklieferungen (GKV-SV).
Der AG werden die vollständigen Stamm- und Bewegungsdaten der Software
mindestens Tagesaktuell über ein geeignetes Replikationsverfahren auf
Datenbankebene zur Verfügung gestellt.
Das Controlling Modul bietet die Möglichkeit, zusätzliche Datenquellen (wie z.B. MS
Excel, MS Access) einzubinden.
9.2 Funktionale Anforderungen
9.2.1 Kennzahlen- und KPI-System
Die Software muss einen standardisierten und erweiterbaren KPI-Katalog
bereitstellen.
Dieser umfasst insbesondere Kennzahlen wie:
• Prüfquoten,
• Erfolgsquoten,
• Einsparvolumen,
• MD-Ausschöpfungsquoten.
Der KPI-Katalog muss durch berechtigte Anwender konfigurierbar und erweiterbar
sein.
9.2.2 Analyse- und Auswertungsfunktionen
Seite 42 von 60
[Seite 43]
Das System muss Analyse- und Auswertungsfunktionen bereitstellen, die es
ermöglichen, Daten strukturiert auszuwerten. Hierzu gehören insbesondere:
• Drill-down-Analysen zur Detailbetrachtung einzelner Kennzahlen,
• Trendanalysen zur Darstellung zeitlicher Entwicklungen,
• Forecasting-Funktionen zur Prognose zukünftiger Entwicklungen,
• Abweichungsanalysen zum Vergleich von Plan- und Ist-Werten,
• Benchmarking-Funktionen zum Vergleich von Einheiten oder Zeiträumen.
9.2.3 Reporting und Dashboards
Die Software kann rollenbasierte Dashboards bereitstellen, die folgende Funktionalitäten umfassen:
• individuelle Anpassbarkeit der dargestellten Inhalte je Rolle,
• Visualisierung relevanter Kennzahlen und Analysen,
• Exportfunktionen (z. B. nach Excel oder PDF),
• automatisierte Erstellung und Verteilung von Reports,
• frei konfigurierbare Darstellungen (z. B. Tabellen, Diagramme).
9.2.4 Budget- und Maßnahmensteuerung
Die Software kann Funktionen zur Planung und Überwachung von Budgets sowie zur Steuerung von Maßnahmen bereitstellen.
Dies umfasst insbesondere:
• die Erfassung und Verwaltung von Budgets,
• die Zuordnung von Maßnahmen zu Budgets,
• die Nachverfolgung des Umsetzungsstatus von Maßnahmen,
• sowie die Auswertung von Budgetverbräuchen und Maßnahmenwirkungen.
9.2.5 Schnittstellen
Die Software muss Import- und Export-Schnittstellen sowie Integrationsmöglichkeiten in bestehende Prüf- und BI-Systeme bereitstellen.
Hierzu gehören insbesondere:
• standardisierte Schnittstellen zur Datenübertragung,
• API-basierte Anbindungen zur Integration externer Systeme, Seite 43 von 60
[Seite 44]
• sowie die Möglichkeit zur Verarbeitung großer Datenmengen.
• Schnittstellen sind als REST-Schnittstellen oder für KI-Anbindung als MCP- Schnittstellen
auszulegen.
• Die Schnittstellenspezifikationen sollen maschinenlesbar dokumentiert sein (OpenAPI kompatibel) • API unterstützt Versionierung (mind. zwei Versionen) • API ist grundsätzlich abwärtskompatibel (mind. zwei Versionen)
Die besonderen Gegebenheiten der Auftraggeberin als Großkasse mit
Massendatenverarbeitung sind zu berücksichtigen. Die Schnittstellen müssen daher hinsichtlich Performance, Skalierbarkeit und
Aktualität so ausgelegt sein, dass auch große Datenvolumina effizient und zeitnah
verarbeitet werden können.
9.3 Anbindung externes DWH
Das System muss alle prüfungsrelevanten Daten, Zwischen- und Endergebnisse fallbezogen in einer einheitlichen Datenbasis bereitstellen. Insbesondere sind
manuelle und automatisierte Prüfaktivitäten aus der Fallbearbeitung einschließlich der
MD-Kommunikation zeitnah (mind. täglich) bereitzustellen. Aktivitäten auf
Einzelrechnungen sind rechnungsspezifisch darzustellen (z.B. Prüfregelanschläge oder Leistungsentscheidungen). Bei allen Daten ist ein aktivitätenbezogener
Zeitstempel zu liefern (z.B. Zeitpunkt Anschlag der Prüfregel oder gültiger KI-Score
zum Zeitpunkt MD-Versand).
Die für die Anwendung bereitgestellten Schnittstellen sind im Rahmen der
Weiterentwicklung (z.B. aufgrund gesetzlicher Änderungen) zu berücksichtigen und zu erweitern (z.B. neue Aufnahmegründe). Die Dokumentation der Schnittstelle ist
Release-abhängig zu aktualisieren und bereitzustellen.
9.4 Datenqualität und Revisionssicherheit
Seite 44 von 60
[Seite 45]
9.5 Es muss eine Historisierung und Dokumentation der Kennzahlen sowie die Durchführung von Plausibilitätsprüfungen gewährleistet werden. Performance- und Skalierbarkeit
Das System muss schnelle Ladezeiten und eine hohe Skalierbarkeit gewährleisten.
9.6 Abbildung der Prüfstufen und Auswertbarkeit der Teilergebnisse
Die Software muss den vollständigen Ablauf eines Prüffalls über alle vorgesehenen Prüfstufen hinweg abbilden und die jeweiligen Ergebnisse revisionssicher
dokumentieren. Jeder Prüffall kann eine oder mehrere Prüfstufen durchlaufen. Für jede
Prüfstufe müssen die Wirksamkeit und das Einzelergebnis unabhängig voneinander auswertbar sein. Zusätzlich muss das Gesamtergebnis des Prüffalls transparent aus
den Teilbeiträgen der einzelnen Prüfstufen ableitbar sein.
Abbildung der Prüfstufen
Die Software muss mindestens folgende Prüfstufen systemseitig strukturiert unterstützen:
Abweisung einer Rechnung aus formalen Gründen
Erkennung und Dokumentation formaler Abweisungsgründe, z. B.
• fehlende oder unvollständige Leistungsnachweise
• formale Fehler gemäß §301 SGB V sowie DTA §115f SGB V
• Fristversäumnisse des Krankenhauses und der Vertragsärzte
Die Entscheidung, der Zeitpunkt und die Begründung müssen dokumentiert und auswertbar sein. Erfolgsbewertung in Abhängigkeit von erzielter Einsparung muss
möglich sein.
Seite 45 von 60
[Seite 46]
Alternative Klärverfahren
Prüfung mit oder ohne Einleitung eines Vorverfahrens nach PrüfvV, aber ohne
Beauftragung des MD (z. B. Falldialog, Fallkonferenz, SFB, medizinische Begründung durch das Krankenhaus)
Die Software muss unterstützen: • Initiierung des Klärverfahrens
• Kommunikation und Dokumentation des Informationsaustauschs
• Erfassung der medizinischen Stellungnahmen • Ergebnisdokumentation mit klarer Zuordnung zur Prüfstufe und der erzielten
Einsparung
MD-Verfahren Die Software muss alle Schritte im MD-Verfahren vollständig abbilden, insbesondere:
• Prüfveranlassung und Begründung (Kranzfragen, Prüfgegenstände,
Auffälligkeiten, interne und externe Begründungen, Besonderheiten und beanstandeten Falldaten)
• MD-Anfrage, Gutachten, Stellungnahmen, Fristenführung
• Detaildaten der MD-Antwort in Bezug auf Kranzfragen und begutachtete
Falldaten • Leistungsentscheidung der Krankenkasse auf Basis des Gutachtens
• Ergebnisabschluss (z.B. Minderung, Streichung, Einigung, Bestätigung der
Krankenhausabrechnung)
Alle relevanten Metadaten müssen auswertbar sein.
Erörterungsverfahren
Die Software muss den sachlich chronologischen Ablauf eines Erörterungsverfahrens
(inkl. Bestreiten) nach MDK-Reformgesetz und PrüfvV abbilden, u. a.:
• Antrag und Zulässigkeit • Positionen von Krankenhaus und Krankenkasse
• Ergebnis (einvernehmlich, uneinig, Teilanerkennung etc.)
• finanzielles Teilergebnis
Seite 46 von 60
[Seite 47]
In dieser Prüfstufe werden auch die Abläufe und Ergebnisse aus den aktiven und
passiven Klageverfahren erfasst.
Rückwirkende Rechnungsprüfung
Die Software muss rückwirkende Rechnungsprüfung unterstützen. Die vorherigen Ergebnisse aus den regulären Prüfstufen müssen weiter sichtbar und auswertbar
sein.
9.7 Ergebnisse und Wirksamkeit je Prüfstufe
Für jede Prüfstufe müssen mindestens folgende Informationen strukturiert erfasst und
auswertbar gemacht werden: • Ausgang der Prüfstufe (z.B. erfolgreich, erfolglos, teilweise erfolgreich)
• finanzielle Wirkung (brutto/netto)
• Art der Fallkorrektur (z.B. DRG-Wechsel, Korrektur der Verweildauer, OPS- Anpassung)
• Erfolg/Misserfolg der verfolgten Prüfgründe
• Zeitpunkt, Dauer (Beginn und Ende der Prüfstufe), Fristenläufe • Status des Falls nach Abschluss der Prüfstufe
Zuordnung des jeweils erzielten Retax zu den Prüfstufen.
Beispiel:
Ein Fall erzielt in Prüfstufe formale Rückweisung (100 €), in Prüfstufe MD eine gestützte
Minderung (500 €), in Prüfstufe EV eine Teilanerkennung (-250 €). Alle Beträge müssen getrennt sowie in Summe ausweisbar sein.
Abschluss einer Prüfstufe „Für DAK“
➢ Der Rechnungsbetrag der letzten eingegangenen Rechnung vor der Prüfstufe ist höher als der Rechnungsbetrag der korrigierten Rechnung nach der
Prüfstufe (positiver Retax)
Gesamteinstufung des Falls „Für DAK“
➢ Der berechnete Gesamtbrutto-Betrag des Falls ist geringer als der Betrag der
„höchsten eingereichten Rechnung“ (positiver Retax)
Seite 47 von 60
[Seite 48]
➢ Berücksichtigung von Aufwandspauschalen (AWP), Strafzahlungen und
anderen Nachtragsrechnungen
• „Fallzusammenführung“ als Sonderfall
9.8 Gesamtfallbetrachtung stationär
Die Software muss die Ergebnisse aus den einzelnen Prüfstufen zu einem
Gesamtergebnis pro Fall zusammenführen:
• Gesamteinsparung • Gesamtergebnis (vollständig erfolgreich, teilweise erfolgreich, nicht
erfolgreich)
• Zeitliche Gesamtdauer • Anzahl durchlaufener Prüfstufen
• Anteil der Wirksamkeit je Prüfstufe am Gesamtergebnis (in € und in %)
Das Gesamtergebnis muss transparente Herleitungen aus den Teilergebnissen enthalten.
9.9 Gesamtfallbetrachtung vertragsärztliche Hybrid-DRG
Die Software muss die Ergebnisse aus den einzelnen Fällen zu verschiedenen
Parametern auswerten können: • Fallmengen je Hybrid-DRG
• Ausgaben je Hybrid-DRG
• Gesamteinsparung je Hybrid-DRG
• Fallmenge auf OPS und ICD-Ebene • Ausgaben auf OPS und ICD-Ebene
• Gesamteinsparung auf OPS und ICD-Ebene
• Anteil der Wirksamkeit je Prüfregel am Gesamtergebnis (in € und in %) Das Gesamtergebnis muss transparente Herleitungen aus den Teilergebnissen
enthalten.
9.10 Berichtswesen und Analyseanforderungen
Die Software muss Auswertungen ermöglichen:
Seite 48 von 60
[Seite 49]
Auf Fallebene
• Prozessverlauf über alle Prüfstufen (Timeline) • Teilbeträge je Prüfstufe
• Begründungen und Entscheidungen je Stufe
• Gesamtergebnis in Relation zu Teilergebnissen
Auf aggregierter Ebene (z. B. Krankenhaus, Zeitraum, Entgeltbereich)
• Erfolgsquoten je Prüfstufe • finanzieller Erfolg je Prüfstufe
• durchschnittliche Wirksamkeit pro Prüfstufe
• typische Fallverläufe (z. B. mit/ohne MD)
• Verteilungen der Prüfstufenketten (z. B. 1 → 2 → 3, 2 → 3, 3 → 4 etc.)
Je Fall wird ein „Zeitstrahl“ erstellt, in den die relevanten Ereignisse der
Rechnungsprüfung aus diversen Quellen eingetragen werden: • Eingang eines Falls (Aufnahme, Entlassung DA)
• Storno des Falls (FZL und Umwandlung)
• Fallstorno im DA • Abschluss des Falls
• Eingang einer Rechnung
• Abweisung (Löschung) einer Rechnung
• Gutschrift einer Rechnung = Datenkorrektur (ggf. mit Folge der automatischen Stornierung)
• Prüfungsvermerk einer Rechnung
• Freigabe einer Rechnung • Storno einer Rechnung
• Prüfungsrelevante Aktionen (inkl. Abschluss und Stornierungen)
• Eröffnung eines Prüfverfahrens
• Abschluss eines Prüfverfahrens • Versand/Eingang bestimmter KAIN und INKA-Meldungen im DA
• Versand MD Auftrag (auch Widerspruch)
• Eingang Gutachten • Ablauf und Ergebnis Erörterungsverfahren
• Klageverfahren und -ergebnisse
• Aktionen zu rückwirkender Rechnungsprüfung
Seite 49 von 60
[Seite 50]
9.11 Revisionssicherheit und Nachvollziehbarkeit
Die Software muss sicherstellen:
• Jede Entscheidung ist historisiert und auf Benutzer-, Zeit- und
Entscheidungsgrundlage zurückführbar. • Prüfstufen dürfen nicht überschrieben, sondern nur fortgeschrieben werden.
• Der Prüffallverlauf muss als revisionssichere Chronologie abbildbar sein.
• Berechnungslogiken für Wirksamkeit müssen dokumentiert und überprüfbar
sein.
10 Entwicklungsbegleitung und Test
Die AG benötigt eine Möglichkeit (über ein geeignetes Ticket-Tool), um dem AN im Bedarfsfall weitere Anforderungen für die Entwicklung neuer Software-Releases
melden zu können. Diese Anforderungen sind durch den AN in angemessener Zeit zu
bewerten und mit der AG bzgl. einer möglichen Umsetzung abzustimmen. Die
Gewichtung der Anforderung erfolgt im Idealfall unter Berücksichtigung der Kundengröße oder es werden alternative Bewertungsbemessungen vorgehalten.
Software-Anpassungen, die nicht auf Grund von AG Anforderungen umgesetzt werden, müssen ohne gesonderte Bezahlung vorgenommen werden. Dies betrifft
bspw. gesetzliche Änderungen beim TP4a-Verfahren, TP1-Verfahren, DTA Hybrid-
DRG §115f SGB V, Fehlerbehebungen, abrechnungsbedingte Jahreswechselanpassungen sowie neue Anbindungen von technischen oder
fachlichen Komponenten (bspw. MD-Portal / MiMa / KIM), Anpassungen der KHFM-
Schnittstelle oder gesetzliche Themen.
Die Inhalte der vom AN vorgenommenen Software-Anpassungen sind der AG
rechtzeitig vor Auslieferung bekannt zu geben. Um den Software- Entwicklungsprozess zu verbessern, hält die AG es für wünschenswert, wenn
regelmäßige Sprint-Reviews während der Entwicklungsphase durchgeführt werden.
Rechtzeitig vor der Einführung ist ein neues Release in das Testsystem der AG
einzuspielen. Anhand der mitgelieferten Release-Informationen bekommt die AG die
Möglichkeit, das neue Release ausreichend zu testen.
Seite 50 von 60
[Seite 51]
Der AN stellt ein Ticket-Tool bereit. Über das Ticket-Tool hat der AN die Möglichkeit,
Fehler zu melden, die beim Release-Test festgestellt werden.
10.1 Software-Anpassungen
Der Auftraggeber behält sich vor, während der Vertragslaufzeit Anpassungen und
Weiterentwicklungen der Software zu beauftragen, soweit diese nicht von den vertraglich geschuldeten Pflege- und Wartungsleistungen umfasst sind.
11 Datenschutz
Sämtliche Abrechnungsarten, die vorgehalten werden, bei denen Mitarbeiter der AG
Patienten sind, werden als geschützte bzw. besonders geschützte Versicherte in zwei
gesonderten Dienststellen geführt. Die Software muss die Möglichkeit bieten, diese Fälle getrennt von den anderen Krankenhausfällen und Hybrid-DRG Fällen zu prüfen
und zu bearbeiten. Hierbei sind die gesonderten Vereinbarungen zum Datenschutz
der AG zu beachten.
Die Software muss mit den in der AVV beschriebenen Datenschutzanforderungen
konform sein.
Die Software muss ein Löschkonzept sowie die technische Möglichkeit bereitstellen,
analog den gewählten Löschparametern die Leistungsdaten in der Stammanwendung
(Bitmarck 21c|ng) zu löschen.
12 Migration
Die Datenmigration aus der aktuell bei der AG verwendeten Prüfungssoftware muss
maschinell geschehen. Hierbei muss die vollständige und fachlich korrekte Übernahme der für die Rechnungsprüfung relevanten Datenbestände, einschließlich aller zur
Bearbeitung erforderlichen Informationen, Dokumente und Verfahrensstände gegeben
sein. Die Migration muss gewährleisten, dass sämtliche laufenden und abgeschlossenen
Fachprozesse ohne Verlust von Informationen, Bearbeitungsständen oder
Nachvollziehbarkeit im Zielsystem weitergeführt bzw. ausgewertet werden können.
Seite 51 von 60
[Seite 52]
Es muss sichergestellt sein, dass nach der Datenmigration / Umstellung kein
Lesezugriff auf die heutige Prüfungssoftware im Sinne eines Altdatenarchivs benötigt wird.
Im Rahmen der Einführung wird zwischen der AG und dem AN definiert, welche Datenfelder aus der bisherigen Prüfsoftware in die neue Software übernommen
werden müssen und wie dies vom AN sichergestellt wird. Hierzu gehört, dass der AG
das vollständige Datenmodell der neuen Software zur Verfügung gestellt wird.
Der AN muss durch Tests nachweisen, dass die Datenmigration korrekt erfolgt.
Parameter für die Tests sind vorab vom AN mit der AG abzustimmen. Anschließend stellt die AG durch einen Test zur Überprüfung auf funktionale Korrektheit der
migrierten Daten sicher, dass die migrierten Daten mit der neuen Prüfungssoftware
korrekt weiterbearbeitet werden können.
Rechtzeitig vor dem Umstellungszeitpunkt muss ein Performancetest durch den AN
erfolgen, um die benötigte Laufzeit für die Datenmigration zu ermitteln. Auf Basis
dieses Ergebnisses wird zwischen der AG und dem AN definiert, ob die Datenmigration ggfs. in mehreren Schritten zu erfolgen hat, falls die Dauer der
Datenmigration innerhalb eines Umstellungsfensters nicht ausreicht.
Das aktuell gültige Prüfregelwerk der AG muss in die Software des AN migriert
werden. Dies ist durch den AN sicherzustellen und die Vollständigkeit zu garantierten
/ nachzuweisen.
Für die Datenmigration muss der AN einen Plan zur Minimierung des
Migrationsrisikos vorhalten und der AG auf Anforderung vorlegen. Außerdem müssen
Rollback- und Notfallpläne vorab mit der AG abgestimmt werden. Des Weiteren muss eine Zeit- und Ressourcenplanung mit der AG abgestimmt werden.
Der AN ist verpflichtet auch nach Ablauf der Vertragslaufzeit, der AG bei der Datenmigration in ein Nachfolgesystem zu unterstützen.
13 Dokumentation der Software
Der AN stellt der AG detaillierte Benutzerhandbücher je Softwaremodul in elektronischer Form in deutscher Sprache zur Verfügung und pflegt diese laufend.
In den Benutzerhandbüchern werden auch Administrations- und Auswertungsmöglichkeiten beschrieben. Der AN stellt aktualisierte Versionen der
Benutzerhandbücher mit jedem Release zur Verfügung.
Seite 52 von 60
[Seite 53]
Der AN stellt der AG detaillierte System-, Installations- und Betriebshandbücher für alle Softwaremodule in elektronischer Form zur Verfügung und pflegt diese laufend.
Die Handbücher beinhalten außerdem einen Leitfaden der regelmäßig durchzuführenden Arbeiten (Monitoring) zur Sicherung der Funktionsfähigkeit der
Software, inklusive der zu überwachenden Datenströme. Die Handbücher sind auf die
Systeme der AG (Bitmarck 21c|ng) ausgerichtet.
14 Schulungen / Schulungssystem
Im Rahmen der Einführung einer neuen Rechnungsprüfungssoftware muss der AN
Schulungsunterlagen (ggf. unterteilt für die jeweiligen Module) in deutscher Sprache
bereitstellen und die Anwendenden der AG schulen. Dabei müssen folgende Nutzergruppen berücksichtigt werden:
• Mitarbeitende der Rechnungsprüfung
• Mitarbeitende des Medizincontrollings und der Regelersteller
• Key User / Systemadministratoren • Optional Projektverantwortliche und Führungskräfte
Der AN muss die Planung, Vorbereitung, Durchführung und Nachbereitung der Schulungsmaßnahmen übernehmen. Der AG bestimmt nach vorheriger Absprache
mit dem AN, ob die Schulungen jeweils in Präsenz oder Online durchgeführt werden.
Die Schulungsleitenden des AN müssen über praktische Erfahrungen in der Nutzung
der Software (mindestens ein Jahr) sowie über Schulungserfahrungen bei
Softwareeinführungen (mindestens bei drei Einführungen) verfügen. Die
Schulungsleitenden müssen ab Produktivsetzung drei Monate lang, als Ansprechpartnerinnen und Ansprechpartner bei Fragen zur Verfügung stehen.
Der AN muss sicherstellen, dass die Software vorab auf ein Schulungs- / Testsystem der AG installiert und für Schulungszwecke genutzt werden kann.
14.1 Anwenderschulung
Die Schulungen müssen bedarfs - und adressatengerecht vom AN konzipiert werden.
Seite 53 von 60
[Seite 54]
Ziel der Schulungen ist es, einen Überblick über die Bestandteile der Software, deren Struktur, Funktion und Handhabung zu vermitteln. Die Anwendenden der AG müssen
in die Lage versetzt werden, die fachliche Prüfung und Bearbeitung von Datensätzen
und Rechnungen der Krankenhäuser und die Hybrid-DRG Abrechnung vollumfänglich durchzuführen und alle Module der Software sicher handhaben zu können.
Bundesweit müssen insgesamt 600 Teilnehmende an acht verschiedenen Standorten der AG geschult werden. Es muss bei der Erstellung der Schulungsunterlagen durch
den AN sichergestellt sein, dass Multiplikatoren (bis zu 20 Personen) befähigt
werden, die Mitarbeitenden vor Produktionsaufnahme der Software an den
verschiedenen Standorten zu schulen.
Die Schulungsunterlagen, die die Softwareinhalte beschreiben, müssen anschaulich
gestaltet sein und Screenshots mit Erklärungen sowie Anwenderbeispielen (z.B. Prüfung der Rechnungen, Filterung und Bearbeitung von Aufgaben und
Terminvorlagen, Erstellung eines MD-Auftrags, Bearbeitung einer
Fallzusammenführung etc.) enthalten. Die Unterlagen sind als PDF-Datei zur Verfügung zu stellen. Der AN räumt der AG das uneingeschränkte Recht ein, die
Schulungsunterlagen zum weiteren internen Gebrauch zu duplizieren, zu verändern
und für interne Bedarfe zu ergänzen.
14.2 Schulung Prüfregelerstellung
Der AN muss eine spezielle Schulung zur Erstellung von Prüfregeln durchführen. Die
Schulung ist für insgesamt 35 Personen der AG durchzuführen. Inhalte dieser
Schulungen sind z.B. folgende Themen:
• Struktur der Software
• Oberflächen und Prozesse
• Theorie Regelwerk und Rechnungsprüfung • Erstellen unternehmenseigener Regeln
• Datenkränze, Algorithmen und Operanden, die bei der Erstellung von
Prüfregeln verwendet werden • Regelkonfigurationen, Parameter
• Erlösrelevante Aspekte
Seite 54 von 60
[Seite 55]
• Berechnung von Fallkriterien
• Automatisierungen • Zuladen von Stammdaten
• Praktische Übungen
• Entgeltprüftoleranzen • Administrative Aufgaben in Bezug auf das Prüfregelwerk
Ziel dieser Schulung ist es, die Teilnehmer der Schulungen zu befähigen, die Inhalte der Software zu verstehen und alles Wissen zu erlangen, um die Software anwenden
und sicher Prüfregeln erstellen zu können.
Die Schulungsunterlagen beschreiben die Inhalte des Moduls zur Prüfregelerstellung.
Sie müssen anschaulich sein und Beispiele zur Anlage und Änderung von Prüfregeln enthalten, die mit Screenshots und Erklärungen sowie Anwenderbeispielen gestaltet
sind. Die Unterlagen sind als PDF-Datei zur Verfügung zu stellen. Der AN räumt der
AG das uneingeschränkte Recht ein, die Schulungsunterlagen zum weiteren internen Gebrauch zu duplizieren, zu verändern und für interne Bedarfe zu ergänzen.
14.3 Schulung Administratoren
Der AN führt für bestimmte Anwender der AG (bis zu 5 Personen) spezielle Schulungen der technischen und administrativen Funktionen in der Software und der vorhandenen Schnittstellen durch. Dazu gehören insbesondere die im Abschnitt 5.1.1. genannten Module zur Softwareadministration.
15 Anforderungen an Service und Support
Zeit Prozess Zeit Menge z.B. Dauer Button -> < Produktionsähnliches Anzeigeprozesse Fensteranzeige 2s Umfeld < Produktionsähnliches Anmeldeprozesse 10s Umfeld < Produktionsähnliches Berechnungsprozesse Online- 2s Umfeld Zeit2 • MD-DA • MD-Portal < Produktionsähnliches Datenanreicherungsprozesse • TP4a-DA 2s Umfeld • Rechnungszahlung < Produktionsähnliches Analysetool3 Regelfreigabe 2s Umfeld
2 Online-Zeit ist von 6:30-20:30 Uhr. 3 Die Performance-Werte (Zeit, Menge) im Analysetool gelten bei parallelem Online-Betrieb. Seite 55 von 60
[Seite 56]
Falldatenbereitstellung für < 1.000 Fälle Regelsimulation 20s < Regelsimulation 1.000 Fälle 20s Batch in 120 30.000 Fälle Offline- min Zeit
Kann die Software in der Batchverarbeitung nicht die angegebene Menge von Fällen (35.000 Nachrichten) verarbeiten, muss eine Fallmengensteuerung existieren, mit der man eine bestimmte Anzahl an Fällen auswählen kann.
Der Bieter hat die Sicherstellung der technischen Lauffähigkeit der angebotenen Software in der vorgesehenen Betriebsumgebung zu gewährleisten. Hierzu gehören insbesondere die Analyse softwarebedingter Störungen, die Bereitstellung von Workarounds sowie die Lieferung und Pflege von Fehlerkorrekturen, Patches und Hotfixes.
16 Betrieb von Software auf der OpenShift-Containerplattform
16.1 Gegenstand der Leistung
Gegenstand ist die Bereitstellung, der Betrieb und die Wartung der gegenständlichen
Prüfsoftware auf der OpenShift-Containerplattform unter Einhaltung definierter technischer und sicherheitsrelevanter Anforderungen.
Abweichend von den Regelungen in Ziffer 2.2 sind die in diesem Abschnitt definierten
Anforderungen nicht zum Leistungsbeginn bereitzustellen. Die vollständige Umsetzung und Bereitstellung muss spätestens innerhalb von sechs Monaten nach definierten
Leistungsbeginn in 2.2 abgeschlossen sein.
16.2 Leistungsumfang Der Auftragnehmer erbringt Leistungen zur Bereitstellung containerisierter Anwendungen inkl.:
• Erstellung und Lieferung von Container-Images und Helm Charts
• Integration in bestehende OpenShift-/Kubernetes-Umgebungen
• Sicherstellung von Betreibbarkeit, Skalierbarkeit und Sicherheit
• Software erfordert nicht die Installation zusätzlicher Operatoren
Seite 56 von 60
[Seite 57]
• Berechtigungen von Serviceaccounts sind nach dem Least Privilege Design
angelegt und dokumentiert
• Als containerbasierte Datenbank wird ausschließlich PostgresSQL verwendet
• TLS 1.3 (statt 1.2) und einen Plan wie Post Quanten Kryptographie
(PQK/PQC) vom AN angegangen/eingeplant wird.
• Die Anwendung kann vollständig über einen Webbrowser bedient und administriert werden.
• Die Anwendung unterstützt die jeweils aktuellen Versionen der gängigen
Webbrowser: Chrome, Firefox, Edge
• Die Anwendung unterstützt GitOps Prozesse, .dh. sie ist vollständig
automatisiert installier- und konfigurierbar.
• Anwendungen lassen sich aus der Infrastruktur (Deployment, Monitoring,
etc.) über APIs ansprechen, steuern und konfigurieren.
• Die Anwendung unterstützt die Zero-Trust Architektur durch
(maschinenlesbare, automatisierte) Dokumentation ihrer
Kommunikationsbeziehungen. (in-/out-bound)
16.3 Technische und fachliche Anforderungen 16.3.1 Container-Images:
• OCI-konforme Container-Images sind verpflichtend.
• Für dauerhafte Services sind glibc-basierte Images zu verwenden
• Nicht glibc-basierte Images nur für One-Time-Container.
16.3.2 Kubernetes-Konfiguration: StatefulSets für zustandsbehaftete Anwendungen.
• Deployments für zustandslose Anwendungen.
• Nutzung von Affinity/Anti-Affinity und Topology Spread Constraints.
• Definition von Ressourcen (CPU/Memory Requests und Limits).
16.3.3 Persistente Datenhaltung:
• Mengengerüste vorab definieren.
• StorageClass muss konfigurierbar sein.
• RWX-Zugriffe vermeiden.
16.3.4 Security:
Seite 57 von 60
[Seite 58]
• CVEs sind durch den Hersteller eigenständig und fristgerecht zu beheben.
• Umsetzung gemäß BSI Patch- und Änderungsmanagement.
16.4 Lieferung und Bereitstellung • Bereitstellung von Container-Images und Helm Charts über OCI-kompatible
Registry
• Kein Push in interne Registries der Auftraggeberin.
• Versionierung nach etablierten Standards (z.B. SemVer).
16.5 Dokumentation • Vollständige technische Dokumentation ist bereitzustellen
• Architekturskizze mit Darstellung der Komponenten, Schnittstellen und
Abhängigkeiten ist verpflichtend.
16.6 Mitwirkungspflichten des Auftragnehmers Der AN stellt sicher, dass:
• alle Anforderungen eingehalten werden
• notwendige Abstimmungen (z.B. Datenhaltung) frühzeitig erfolgen
• Sicherheitsanforderungen kontinuierlich umgesetzt werden
16.7 Verbindlichkeit Die beschriebenen Anforderungen sind verbindlicher Bestandteil der Ausschreibung und im Angebot vollständig zu berücksichtigen.
Seite 58 von 60
[Seite 59]
17 Abkürzungsverzeichnis
Abkürzung Erläuterung
AD Active Directory
AG Auftraggeberin
AHHP Arznei-, Heil-, Hilfsmittel und Pflegedaten
AN Auftragnehmer
BITMARCK_21c|ng Krankenkassenmanagementsystem, Stammsystem
BPflV alt Bundespflegesatzverordnung
DA Datenaustausch
DMS Dokumentenmanagementsystem
DRG Diagnosis Related Group (diagnosebezogene Fallgruppierung)
eAkte elektronische Akte
EU-DSGVO EU-Datenschutzgrundverordnung
FZF Fallzusammenführung gem. Groupingregelung der FPV
Hybrid-DRG Hybrid-Diagnosis Related Group (§115f SGB V)
HyperDoc Software für digitales Dokumentenmanagement
ICD International Classification of Diseases and Related Problems
ID Identifikation
IK Institutskennzeichen der Krankenhäuser
INKA Information der Krankenhäuser
i.V.m. In Verbindung mit
KAIN Krankenkasseninformation
KH Krankenhaus
KHFM-Schnittstelle Krankenhausfallmanagement Schnittstelle
LDAP Lightweight Directory Access Protocol
Seite 59 von 60
[Seite 60]
MD Medizinischer Dienst der Krankenkassen
MVD Mittlere Verweildauer
OPS Operationen- und Prozedurenschlüssel
PEPP Pauschalierendes Entgeltsystem Psychiatrie und Psychosomatik
PrüfvV Prüfverfahrensvereinbarung
REST Representational State Transfer
SOAP Simple Object Access Protocol
SEG 4 Sozialmedizinische Expertengruppe der MD-Gemeinschaft „Vergütung und Abrechnung“
TP4a Datenaustauschverfahren mit den Krankenhäusern
vdek Verband der Ersatzkassen e.V.
WBB Weitere Begutachtungsbereiche
WSDL Web Services Description Language
WTS Windows Terminal Server
Seite 60 von 60