Wo entstehen Abrechnungskürzungen und Rücksendungen tatsächlich? — Die Logik der Rezeptprüfung anhand von ORCAs Quellcode und öffentlichen Dokumenten zerlegt

Die Einnahmen am Empfangstresen machen bei einer medizinischen Einrichtung nur einen Bruchteil des Umsatzes aus; der Großteil wird über die einmal im Monat eingereichte Abrechnung (Rezept) beglichen. Deshalb haben Formulierungen wie „wir wurden gekürzt“ oder „eine Abrechnung kam zurück“ in der Praxis ein erhebliches Gewicht — und doch ist es für Systementwickler überraschend schwer zu erkennen, wo und nach welcher Logik Abrechnungskürzungen und Rücksendungen tatsächlich entstehen.

Teil 1 dieser Serie behandelte die Rolle des Abrechnungssystems, Teil 2 die Nichi-Rece-API und Teil 3 die Online-Berechtigungsprüfung. Diesmal widmen wir uns dem Kern der Abrechnungsarbeit — der Logik von Prüfung und Bewertung — indem wir die Prüfpunkte, die ein Rezept durchlaufen muss, der Reihe nach auflisten.

• Die genaue Bedeutung der Begriffe Rücksendung, Abrechnungskürzung und erneute Prüfung
• Prüfungen innerhalb der medizinischen Einrichtung — die Implementierung von ORCAs Datenprüfungsfunktion und ihren Prüf-Mastertabellen
• Die vor der Einreichung durchgeführte rece-den-Datenprüfung
• Prüfungen auf Seiten der Abrechnungsstellen — maschinelle Prüfungen, Abgleichprüfung und Verlaufsprüfung
• Die Tatsache, dass die Seite des Abrechnungssystems und die Bewertungsseite strukturell dieselbe „Regeltabelle plus Engine“ sind

Aussagen zur regulatorischen Seite stützen sich auf öffentliche Dokumente der Zahlungsstelle, ärztlicher Standesorganisationen und ähnlicher Quellen; Aussagen zur Implementierung von ORCA beruhen auf der tatsächlichen Lektüre des offiziell veröffentlichten Nichi-Rece-Kern-Quellcodes der 5.2er-Serie (Snapshot veröffentlicht am 1. Juli 2026).

Inhaltsverzeichnis

1. Das Fazit zuerst — ein Rezept durchläuft „vier Prüfpunkte“
2. Die Begriffe in kürzester Form — Rücksendung, Abrechnungskürzung, Punktanpassung, erneute Prüfung
3. Prüfpunkt 1: ORCAs Datenprüfungsfunktion im Quellcode gelesen
4. Die Prüf-Mastertabelle als Regeltabelle — das Design der tbl_chk-Tabellenfamilie
5. Prüfungen bei der Eingabe und APIs — Prüfung findet nicht nur zum Monatsende statt
6. Prüfpunkt 2: die rece-den-Datenprüfung — Prüfung der Abrechnungsdaten
7. Prüfpunkte 3 und 4: maschinelle Prüfungen, Abgleichprüfung und Verlaufsprüfung bei den Abrechnungsstellen
8. Beide Seiten sind „Regeltabelle plus Engine“ — die Landkarte für Entwickler
9. Praxispunkte — was die Systemseite zur Verbesserung der Prüfgenauigkeit tun kann
10. Zusammenfassung
11. Referenzlinks

1. Das Fazit zuerst — ein Rezept durchläuft „vier Prüfpunkte“

Auf einer Seite zusammengefasst sehen die wichtigsten Prüfpunkte, die ein Rezept von der Dateneingabe in der medizinischen Einrichtung bis zur Zahlung durchläuft, so aus.

flowchart LR
    subgraph clinic["Innerhalb der medizinischen Einrichtung"]
        NYU["Tägliche Dateneingabe<br/>(Prüfung bei Eingabe)"]
        DC["1. Datenprüfungsfunktion<br/>(ORCA: orca41)"]
        REC["2. Rece-den-Datenprüfung<br/>(Prüfung der Abrechnungsdaten)"]
        NYU --> DC --> REC
    end
    subgraph SHINSA["Abrechnungsstellen (Zahlungsstelle / Verbände der Krankenversicherung)"]
        CC["3. Maschinelle Prüfungen<br/>+ Abgleich- und Verlaufsprüfung"]
        JIN["4. Prüfung durch Mitarbeitende<br/>+ Prüfausschuss"]
        CC --> JIN
    end
    REC -->|"Online-Einreichung"| CC
    JIN -->|"Geprüfte Abrechnung"| HOKEN["Versicherer"]
    HOKEN -.-> PAY["Zahlung<br/>(über die Abrechnungsstelle an die Einrichtung)"]
    JIN -.-> RET["Rücksendung / Abrechnungskürzung<br/>(Benachrichtigung der Einrichtung → Korrektur und erneute Einreichung)"]

• Prüfpunkt 1 (Prüfung des klinischen Inhalts): Das Abrechnungssystem prüft die interne Konsistenz des klinischen Inhalts — „Stimmen Diagnose und Arzneimittel überein?“, „Wurde etwas Abrechenbares übersehen?“. In ORCA übernimmt dies die Datenprüfungsfunktion.
• Prüfpunkt 2 (Prüfung der Abrechnungsdaten): Die einzureichende elektronische Abrechnung (die rece-den-Datei) wird als Abrechnungsdaten geprüft, vom Datensatzformat bis zu den Anforderungen an Bemerkungseinträge. In ORCA ist dies die rece-den-Datenprüfung.
• Prüfpunkt 3 (maschinelle Bewertung): Die maschinellen Prüfungen der Abrechnungsstelle durchsuchen das Rezept mechanisch anhand von Regeln, die aus amtlichen Bekanntmachungen, Rundschreiben und Arzneimittel-Packungsbeilagen abgeleitet sind, und markieren verdächtige Positionen. Dazu gehören auch die Abgleichprüfung, die die medizinischen und die Abgabe-Rezepte eines Patienten einander gegenüberstellt, sowie die Verlaufsprüfung, die das Rezept mit den Vormonaten vergleicht.
• Prüfpunkt 4 (menschliche Bewertung): Mitarbeitende prüfen die von der Maschine markierten Positionen, und letztlich entscheidet der Prüfausschuss. Das Ergebnis wird der medizinischen Einrichtung als Rücksendung oder als Abrechnungskürzung mitgeteilt.

Der wesentliche Punkt, den ein Entwickler verstehen sollte, ist, dass Prüfpunkt 1 und Prüfpunkt 3 von entgegengesetzten Seiten „dieselbe Art von Prüfung“ durchführen. Die Einrichtung möchte vor der Einreichung jede Abrechnung finden, die bei der Bewertung wahrscheinlich auffallen würde; die Bewertungsseite möchte Abrechnungen finden, die nicht den Regeln entsprechen. Wie wir sehen werden, zeigt sich diese Symmetrie als Ähnlichkeit in der Implementierungsstruktur — beide bestehen aus Regeltabelle plus Engine.

2. Die Begriffe in kürzester Form — Rücksendung, Abrechnungskürzung, Punktanpassung, erneute Prüfung

Die denkbar kürzeste Zusammenfassung des regulatorischen Vokabulars.

Wichtig ist die Unterscheidung, dass eine Rücksendung „noch einmal machen“ bedeutet, während eine Abrechnungskürzung „die Reduzierung ist endgültig“ bedeutet — die Schwere ist unterschiedlich. Und die Abgleich- und Verlaufsprüfung erkennen Fehler, die sich nicht durch die Betrachtung eines einzelnen Rezepts allein finden lassen (monatsübergreifende Häufigkeitsgrenzen, Diskrepanzen zwischen medizinischer und Abgabe-Abrechnung). Ihr Charakter unterscheidet sich jedoch: Der Abgleich mit dem Rezept einer anderen Organisation (Abgleichprüfung) ist innerhalb einer medizinischen Einrichtung grundsätzlich nicht möglich, während der Vergleich mit den eigenen Vormonaten (das Äquivalent zur Verlaufsprüfung) innerhalb der eigenen Daten möglich ist. Versteht man, wo diese Grenze verläuft, wird das Ziel der Prüfarbeit klar: „Alles, was intern erfassbar ist, auch intern erfassen“.

3. Prüfpunkt 1: ORCAs Datenprüfungsfunktion im Quellcode gelesen

Ab hier lesen wir den Quellcode. ORCAs Datenprüfung ist Geschäftsmenü 41 und entspricht im Quellcode dem Verzeichnis cobol/orca41/ sowie lddef/orca41.ld. Die LD-Definition zeigt die Struktur unmittelbar.

• Bildschirme: Ausgehend von D01 „Rezeptprüfungsanweisung“ verzweigt es zu D02 „Einzelanweisung“, D03 „Registrierung der Prüfelement-Einstellungen“ und D04 „Bestätigung des Fehlerinhalts“, während D05 „Liste der Ausnahmeeinstellungen“ von D04 aus aufgerufen wird (die Verzweigung findet sich in der Übergangsverarbeitung von ORCGD01.CBL und ORCGD04.CBL, und die Bildschirmnamen lassen sich anhand der Titel der jeweiligen screen/D0x.glade bestätigen).
• Engine: Der Kern der Prüflogik liegt nicht auf der Bildschirmseite, sondern in den Batch-Programmen cobol/orcabt/ORCDTCHK000 bis 011.CBL. Vom Bildschirm aus startet ORCGDSUB02.CBL diesen Batch als Job (Shell-ID ORCBSD1), sodass die interaktiven Bildschirme und die Prüfverarbeitung getrennt sind.
• API: Eine API zum externen Auslösen der Datenprüfung (ORCGDAPI01) ist als bindapi "datacheckv3" gebunden.

Die Request-Definition der API (record/xml_data_checkv3req.db) beschreibt die Eingabespezifikation dieser Funktion am kompaktesten.

data_checkv3req {
    Request_Number             varchar(02);   -- 00=Informationsabruf / 01=Prüfung ausführen / 02=Statusabfrage
    Karte_Uid                  varchar(36);   -- Kennung des Aufrufers (bei Ausführung erforderlich; Fehler bei leerem Wert)
    Orca_Uid                   varchar(36);   -- Job-Kennung (bei Statusabfrage erforderlich; wird in der Ausführungsantwort zurückgegeben)
    Perform_Month              varchar(07);   -- Ziel-Behandlungsjahr und -monat
    Start_Day / End_Day        varchar(02);   -- Datumsbereich
    InOut                      varchar(01);   -- Klassifikation stationär/ambulant
    Check_Insurance_Information { Id; }[6];   -- Zielversicherung (bis zu 6)
    Check_Item_Information    { Id; }[22];    -- IDs der Prüfelemente (bis zu 22)
    Patient_Information { Patient_ID; }[100]; -- Zielpatienten (bis zu 100)
};

(Die Bedeutung der Request_Number-Werte lässt sich anhand der Konstantendefinitionen und Verzweigungen in ORCGDAPI01.CBL bestätigen, die Pflichtprüfungen zu Karte_Uid und Orca_Uid anhand von ORCGDAPI01S01.CBL und ORCGDAPI01S02.CBL. Eine Ausführung (01) läuft als Job, und den Fortschritt verfolgt man über eine Statusabfrage (02) unter Angabe der in der Ausführungsantwort zurückgegebenen Orca_Uid — ein asynchrones Design.)

Bemerkenswert ist, dass Check_Item_Information ein Array mit 22 Elementen ist. Die Datenprüfung ist keine einzelne Prüfung, sondern eine Sammlung von Prüfungen, die als „Prüfelemente“ (check items) bezeichnet werden, und zur Ausführungszeit wird ausgewählt, welche davon laufen. Der Bildschirm zur Bestätigung des Fehlerinhalts (D04.glade) verfügt außerdem über eine Ausnahmeregistrierung, sodass einzelne Fehler als „nicht prüfen (diesen Monat)“ oder „nicht prüfen (dauerhaft)“ unterdrückt werden können (die Ausnahmen werden in der Tabelle tbl_chkreigai gespeichert). Das ist die Form einer praxistauglichen Regel-Engine, bei der sich Fehlalarme im laufenden Betrieb ausräumen lassen.

Nebenbei bemerkt enthält D04.glade Beispieldaten mit „Pontal“ (einem fiebersenkenden Schmerzmittel) und „Magengeschwür“, mit der Prüf-Master-Klassifikation „1 Arzneimittel und Diagnose“. Selbst in den Beispieldaten einer Bildschirmdefinition ist damit der repräsentative Anwendungsfall verankert, den wir im nächsten Abschnitt betrachten — die Prüfung, ob ein Arzneimittel zu einer Diagnose passt.

4. Die Prüf-Mastertabelle als Regeltabelle — das Design der tbl_chk-Tabellenfamilie

Von dem Wissen darüber, „was korrekt ist“, auf das sich die Datenprüfung stützt, ist der Teil, der die Beziehung zwischen Arzneimitteln und Maßnahmen betrifft, nicht in COBOL fest codiert, sondern wird als Daten in einer Tabellenfamilie namens Prüf-Mastertabellen (Check-Master) gehalten. Prüfungen, die die grundlegende Struktur des Systems betreffen — Konsistenz von Versicherung, Symbol und Nummer sowie die tatsächliche Anzahl der Behandlungstage —, sind dagegen direkt im Code der Batch-Programme (ORCDTCHK*) implementiert, und in den Revisionshistorien finden sich entsprechend Ergänzungen auf Code-Seite wie „Unterstützung der Datenprüfung für Unternummern“ oder „Unterstützung der Datenprüfung für Arbeitsunfallversicherungsnummern“. Es wäre ein Irrtum anzunehmen, dass die Pflege der Prüf-Mastertabellen jede Regel verändert: Was die Regeltabelle abdeckt, ist das Gebiet der zugelassenen Indikationen, Kontraindikationen, Kombinationsabrechnungen und Ähnliches. Mit diesem Vorbehalt ergibt die Extraktion der zugehörigen Tabellen aus der Tabellenliste (lddef/orcadb.inc) Folgendes:

Die Struktur einer Regel lässt sich in record/tbl_chk.db sowie im COPY-Member cobol/copy/CPCHK.INC (dessen Felder japanische Kommentare tragen) nachvollziehen. Auf das Wesentliche reduziert hat eine einzelne Regelzeile diese Form.

Prüfklassifikation (CHKKBN) + Behandlungscode (SRYCD) + Gültigkeitszeitraum (YUKOSTYMD bis YUKOEDYMD)
  -> die Menge der zugehörigen Codes (CDKBN + CD), Klassifikation stationär/ambulant, Verarbeitungsklassifikation

Mit anderen Worten eine deklarative Regel, die besagt: „Für Behandlungscode X muss innerhalb von Zeitraum Y einer der Codes aus Menge Z zugeordnet sein (oder darf nicht gleichzeitig vorkommen)“. Welche Regelarten es gibt, ist auf dem Berichtsausgabebildschirm der Prüf-Mastertabelle (screen/X91.glade) aufgeführt.

• Arzneimittel und Diagnose / Diagnose und Arzneimittel (Abgleich der zugelassenen Indikationen)
• Maßnahme und Diagnose / Diagnose und Maßnahme
• Arzneimittel und kontraindizierte Kombination
• Kontraindiziertes Arzneimittel und Diagnose
• Kombinationsabrechnung von Maßnahmen (gleicher Tag / gleicher Monat / gleicher Abrechnungsfall)
• Übersehene Abrechnungen zwischen Maßnahmen
• Prüfung der Abrechnungshäufigkeit

Interessant ist, dass „Arzneimittel und Diagnose“ sowie „Diagnose und Arzneimittel“ ein Paar bilden: Ersteres behandelt „wenn dieses Arzneimittel verordnet wird, muss diese Diagnose vorliegen“ (Erkennung einer fehlenden zugelassenen Indikation), Letzteres „wenn diese Diagnose vorliegt, sollten dieses Arzneimittel oder diese Untersuchung vorhanden sein“ (Erkennung übersehener Abrechnungen). In der Implementierung sind sie jedoch nicht zwei Richtungen ein und derselben Tabelle. Liest man das Berichtsprogramm (cobol/orca103/ORCHXLST.CBL), wird Ersteres in tbl_chksnd und Letzteres in tbl_chk005 verwaltet, in getrennten Tabellen mit getrennten Schlüsseln — registriert man nur eine Richtung, funktioniert die umgekehrte Richtung also nicht automatisch mit, was man beachten sollte. Der Gültigkeitszeitraum existiert, damit die Regeln den zweijährlichen Revisionen der Gebührenordnung sowie der Aufnahme und Streichung von Arzneimitteln folgen können; der Grundsatz „mit regulatorischen Änderungen Schritt zu halten ist das Wesen eines Abrechnungssystems“, den wir in Teil 1 gesehen haben, zieht sich damit auch durch das Design der Regeltabelle.

Zu beachten ist, dass nicht jede Regel in die oben gezeigte einzelne Form passt. tbl_chksnd und tbl_chk005 haben Formen, die Diagnosenamen als Zeichenketten (BYOMEI) und die Behandlung von Verdachtsdiagnosen enthalten, während tbl_chktrd eine Form mit einer Klassifikation für „gleicher Tag“/„gleicher Monat“ (DAYMONTHKBN) besitzt: Die Regeltabellen selbst sind je nach Prüfungsart in unterschiedliche Formen normalisiert. „Regeltabelle“ bedeutet also kein einheitliches Schema — ein Punkt, den man beim Lesen der Implementierung im Blick behalten sollte.

5. Prüfungen bei der Eingabe und APIs — Prüfung findet nicht nur zum Monatsende statt

Die Datenprüfung ist eine monatliche Batch-Prüfung, aber sie ist nicht die einzige stattfindende Prüfung. Der Quellcode zeigt auch Mechanismen, die weiter vorgelagert laufen — am Punkt der täglichen Dateneingabe.

• API zur Prüfung kontraindizierter Kombinationen: /api01rv2/contraindicationcheckv2 (bearbeitet vom Programm ORAPI021R4V2, „Rückgabe von Informationen zu kontraindizierten Arzneimittelkombinationen“; das Erstellungsdatum im Header ist 2016). Übergibt man ihr einen Patienten und ein Arzneimittel, liefert sie alle zutreffenden kontraindizierten Kombinationen zurück, sodass sich eine Integration bauen lässt, bei der die elektronische Patientenakte Nichi-Rece im Moment der Verordnungseingabe abfragt.
• Datenprüfungs-API: datacheckv3 aus dem vorigen Abschnitt. Da sich der monatliche Batch ohne Bildschirmbedienung starten lässt, kann man einen Ablauf einrichten wie „jede Nacht automatisch den laufenden Monat prüfen und am nächsten Morgen eine Fehlerliste erzeugen“.

Hier steckt eine universelle Design-Lektion. Je näher am Ursprung ein Fehler abgefangen wird, desto billiger ist seine Behebung. Ein Fehler, den die Datenprüfung zum Monatsende findet, bedeutet, dass gleich ein ganzer Monat auf einmal korrigiert werden muss, während man eine kontraindizierte Kombination im Moment der Verordnungseingabe in Sekunden beheben kann. (Zu beachten ist, dass diese API kontraindizierte Kombinationen betrachtet. Prüfungen von Zuordnungsbeziehungen, etwa einer fehlenden zugelassenen Indikation, bleiben das Gebiet der monatlichen Datenprüfung und werden bei der Eingabe nicht übernommen.) Dass ORCAs Prüfmechanismus mehrstufig ist — „Eingabezeitpunkt (API) → monatlich (Datenprüfung) → vor Einreichung (rece-den-Prüfung)“ —, ist eine Umsetzung dieses Prinzips.

6. Prüfpunkt 2: die rece-den-Datenprüfung — Prüfung der Abrechnungsdaten

Während die Datenprüfung die interne Konsistenz des klinischen Inhalts betrachtet, wartet unmittelbar vor der Einreichung eine andere Prüfung: die rece-den-Datenprüfung. Ihr Gegenstand ist die elektronische Rezeptdatei (rece-den), und sie prüft die Korrektheit als Abrechnungsdaten — Datensatzformat, Vorhandensein von Pflichtdatensätzen und Ähnliches.

Die Bedingungen für diese Prüfung werden von der offiziellen ORCA-Website als PDF unter dem Titel „Rece-den-Datenprüfung: Spezifikation der Prüfbedingungen“ veröffentlicht (in drei Varianten: Krankenversicherung, Arbeitsunfallversicherung und Nachsorge). Mit anderen Worten veröffentlicht ORCA nicht nur die Inhaltsprüfungen (deren Prüf-Mastertabellen über Berichte oder CSV einsehbar sind), sondern auch die Bedingungsspezifikation der rece-den-Prüfung als Dokument, sodass sich „was geprüft wird“ anhand einer Primärquelle bestätigen lässt.

Es wäre allerdings nicht zutreffend, die rece-den-Prüfung als reine Formatprüfung zu betrachten. Betrachtet man den Quellcode, sind auf der Seite der rece-den-Verarbeitung ein Unterprogramm, das die Eintragsanforderungen für Rezeptbemerkungen prüft (cobol/common/ORCSRECECOMCHK.CBL, neu ab 2018), sowie eine Prüfung der Abrechnungshistorie von Verwaltungs- und Beratungsgebühren im Zusammenhang mit Online-Konsultationsgebühren (ORCSRECESRCHK.CBL) implementiert, und das Ruby-Skript für die monatliche Verarbeitung (im Repository scripts/monthly/receden_check.rb.in — eine Vorlage, die als receden_check.rb installiert wird) prüft sogar die Konsistenz mit der Punktzahl-Mastertabelle und der Diagnose-Mastertabelle. (Dass Ruby neben COBOL existiert, gehört zu den Reizen dieses Quellcode-Baums.) Grob gesagt lautet die Aufteilung „Datenprüfung = klinischer Inhalt, rece-den-Prüfung = Abrechnungsdaten“, aber die Grenze ist nicht strikt, und ein Teil der inhaltlichen Prüfung wird von der rece-den-Prüfung übernommen — nimmt man diese Aufteilung zu wörtlich, verkennt man, woher ein Fehler stammt. In der Praxis ist der Punkt entscheidend, dass ein Rezept erst nach Bestehen beider Prüfungen „bereit zur Einreichung zur Bewertung“ ist.

7. Prüfpunkte 3 und 4: maschinelle Prüfungen, Abgleichprüfung und Verlaufsprüfung bei den Abrechnungsstellen

Das eingereichte Rezept geht dann in die Bewertung bei der Abrechnungsstelle (für die Arbeitnehmerversicherung die Zahlungsstelle; für die gesetzliche Krankenversicherung und die medizinische Versorgung älterer Menschen die Verbände der Krankenversicherung) ein. Wichtig ist hier, dass auch ein Teil der Prüfregeln der Bewertungsseite veröffentlicht wird.

Auf der Seite „Offenlegung zu maschinellen Prüfungen“ der Zahlungsstelle werden zwei Arten von Dateien bereitgestellt (beide im CSV-Format, mit schrittweise erweitertem Umfang).

Beachten Sie den Namen. Auch auf Seiten der Zahlungsstelle wird der Begriff „Prüf-Mastertabelle“ (Check-Master) verwendet. Eine Struktur, die Regeln aus amtlichen Bekanntmachungen und Rundschreiben getrennt von Regeln aus Packungsbeilagen verwaltet, entspricht genau der Struktur von ORCA, bei der die Gebührenberechnungsregeln im Programm und die Arzneimittelindikationen in den Prüf-Mastertabellen liegen.

Es gibt jedoch Prüfungen, die nicht veröffentlicht werden. Auf der Offenlegungsseite wird ausdrücklich festgehalten, dass Fälle, die eine Bestätigung der im Bemerkungsfeld eingetragenen Angaben erfordern, Fälle, die eine klinische Beurteilung erfordern, sowie Fälle im Zusammenhang mit den Indikationen von Arzneimitteln und Maßnahmen vor einer Veröffentlichung sorgfältig geprüft werden. Die Zahlungsstelle erklärt außerdem wiederholt, dass eine maschinelle Prüfung lediglich verdächtige Positionen markiert: Sie kürzt nicht mechanisch, sondern durchläuft eine Prüfung durch Mitarbeitende und eine Entscheidung des Prüfausschusses. „Maschinelle Prüfung = automatische Kürzung“ trifft nicht zu, und das sollten auch Personen auf der Systemseite genau verstehen.

Dann sind da noch die in Abschnitt 2 erwähnten Abgleich- und Verlaufsprüfungen. Diese beiden, die 2012 richtig in Gang kamen, sind keine Prüfungen eines einzelnen Rezepts, sondern Prüfungen der Beziehungen zwischen Rezepten. Ziehen wir die Grenze hier genau. Die Abgleichprüfung (Gegenüberstellung der medizinischen Abrechnung eines Patienten mit seiner Abgabe-Abrechnung) hat als Gegenstück ein Rezept einer anderen Organisation, der Abgabe-Apotheke, sodass sie grundsätzlich nicht durch eine Prüfung innerhalb der medizinischen Einrichtung ersetzt werden kann. Das Äquivalent zur Verlaufsprüfung (Vergleich des laufenden Monats eines Patienten mit den Vormonaten) hingegen ist innerhalb der eigenen Abrechnungshistorie im Haus möglich. Abrechnungen mit Häufigkeitsgrenzen konsequent zu verwalten und die zu ambulanten Verordnungen gehörenden Diagnosen innerhalb der eigenen Daten zu pflegen, ist die realistische Gegenmaßnahme, um Beanstandungen aus Abgleich- und Verlaufsprüfung zu verringern.

8. Beide Seiten sind „Regeltabelle plus Engine“ — die Landkarte für Entwickler

Auf einer Seite zusammengefasst sieht die Welt der Rezeptprüfung so aus.

Die Struktur ist isomorph; die Unterschiede liegen in der Vollständigkeit der Regeln und dem Umfang der Prüfung. Daraus lassen sich für einen Entwickler drei Schlussfolgerungen ziehen.

1. Die Trennung „Regeln sind Daten, die Engine ist ein Programm“ war die Voraussetzung dafür, über mehr als zwanzig Jahre mit regulatorischen Änderungen Schritt zu halten. Wären die Regeln im Code vergraben gewesen, hätte jede Revision eine vollständige Neubearbeitung bedeutet.
2. Im Bereich, der von den Prüf-Mastertabellen getrieben wird (zugelassene Indikationen, Kontraindikationen und Ähnliches), wird die Prüfgenauigkeit auf Seiten der Einrichtung weniger von der Cleverness der Engine bestimmt als von der Vollständigkeit der Regeltabelle (bei im Code implementierten Prüfungen wie Versicherung und tatsächlichen Behandlungstagen ist die eigene Abdeckung des Programms unmittelbar seine Erkennungsleistung). ORCAs Prüf-Mastertabellen bestehen aus zwei Linien, dem mitgelieferten Inhalt (tbl_chk_master) und dem vom Benutzer registrierten Inhalt (tbl_chk_user), sodass das Design es der Einrichtung erlaubt, eigene Regeln hinzuzufügen. Der Wert kommerzieller Rezeptprüfsoftware liegt, konsequent zu Ende gedacht, ebenfalls in der Vollständigkeit ihrer proprietären Regeltabelle.
3. Da nun ein Teil der Regeln der Bewertungsseite veröffentlicht ist, ist „wie man die veröffentlichten Regeln der Bewertungsseite in die eigene Prüfung übernimmt“ zu einem neuen praktischen Thema geworden. Die Bedeutung ihrer Bereitstellung als maschinenlesbares, veröffentlichtes CSV sollte einem Entwickler nicht entgehen.

9. Praxispunkte — was die Systemseite zur Verbesserung der Prüfgenauigkeit tun kann

Eine Zusammenfassung der Punkte, die man kennen sollte, wenn man im IT-Team einer medizinischen Einrichtung oder für einen Integrationsanbieter arbeitet.

1. Die mehrstufige Prüfstruktur auf den eigenen Betrieb übertragen. Die drei Stufen — Eingabezeitpunkt (die Kontraindikations-API und Ähnliches), monatlich (die Datenprüfung), vor Einreichung (die rece-den-Prüfung) — haben unterschiedliche Rollen. Lautet die eigene Praxis „nur einmal zum Monatsende die Datenprüfung laufen lassen“, besteht Spielraum, die beiden vorgelagerten Stufen zu nutzen.
2. Die Datenprüfung lässt sich über die API automatisieren. Mit datacheckv3 lassen sich geplante Läufe mit Angabe von Prüfelementen und Zielpatienten einrichten. Macht man daraus einen Nacht-Batch plus eine morgendliche Fehlerliste, verteilt sich die Prüflast des Monatsendes auf die einzelnen Tage.
3. Die Ausnahmeregistrierung als „Feinabstimmung der Regeln“ behandeln. Lässt man Fehlalarme bestehen, liest niemand mehr die Fehlerliste. Ausnahmen (tbl_chkreigai) und die eigenen Regeln (tbl_chk_user) gezielt zu pflegen, um das Signal-Rausch-Verhältnis der Fehlerliste hoch zu halten, ist die Lebensader der Prüfarbeit.
4. Die Ergebnisse von Rücksendungen und Abrechnungskürzungen in eine Analyseschleife zurückführen. Die Gründe auf den Punktanpassungsmitteilungen auszuwerten und häufige Muster in die eigenen Regeln der Prüf-Mastertabelle sowie in die Praxis bei der Eingabe einfließen zu lassen — das bedeutet „die Regeltabelle wachsen zu lassen“, und es ist der einzige Weg, die Wahrnehmungslücke zur Bewertungsseite zu verringern.
5. Die veröffentlichten Materialien der Bewertungsseite regelmäßig lesen. Die Offenlegung der maschinellen Prüfungen der Zahlungsstelle wird ständig aktualisiert. In einer Zeit, in der die Bewertungsseite offiziell erklärt, worauf sie achtet — einschließlich ihrer Erläuterungen zu Abgleich- und Verlaufsprüfung —, gibt es keine Entschuldigung, das nicht zu lesen.

10. Zusammenfassung

• Ein Rezept durchläuft eine mehrstufige Reihe von Prüfpunkten: 1. die Inhaltsprüfung des Abrechnungssystems → 2. die rece-den-Datenprüfung → 3. die maschinellen Prüfungen der Bewertungsseite (plus Abgleich- und Verlaufsprüfung) → 4. Mitarbeitende und der Prüfausschuss. Eine Rücksendung bedeutet, dass es zurückkommt; eine Abrechnungskürzung bedeutet, dass Punkte gestrichen werden; und die Abgleichprüfung, die Rezepte anderer Organisationen gegenüberstellt, kann innerhalb einer medizinischen Einrichtung nicht ersetzt werden (der Vergleich mit den eigenen Vormonaten ist im Haus möglich).
• ORCAs Datenprüfung ist als orca41-Funktion implementiert, und Regeln für zugelassene Indikationen, Kontraindikationen, Kombinationsabrechnungen und Ähnliches werden als Daten in den Prüf-Mastertabellen gehalten (grundlegende Konsistenzprüfungen wie Versicherung und tatsächliche Behandlungstage liegen im Code). Man wählt aus, welche Prüfelemente ausgeführt werden, unterdrückt Fehlalarme durch Ausnahmeregistrierung und kann die Prüfung über die datacheckv3-API auch von außen steuern — all das lässt sich im veröffentlichten Quellcode nachvollziehen.
• Auch die Bewertungsseite veröffentlicht ihre Regeltabellen — zentrale Prüfbedingungen plus Prüf-Mastertabellen — als CSV, sodass die Seite der Einrichtung und die Bewertungsseite die gleiche Struktur aus „Regeltabelle plus Engine“ aufweisen. Die Unterschiede liegen in der Vollständigkeit der Regeln und dem Prüfumfang (nur die Bewertungsseite kann alle Einrichtungen und alle Monate einsehen).
• Was die Prüfgenauigkeit bestimmt, ist nicht die Engine, sondern die Vollständigkeit der Regeltabelle und ihr Betrieb. Ausnahmeregistrierung, eigene Regeln, eine Analyseschleife über die Ergebnisse von Kürzungen und die Übernahme der veröffentlichten Regeln der Bewertungsseite sind die praktischen Kernpunkte.

Für kommende Folgen dieser Serie sind eine „Datenbank-Ausgabe“ geplant, die ORCAs Datenbankschema direkt liest, sowie die Praxis eines Diff-Monitorings, das die monatlichen Quellcode-Veröffentlichungen automatisch verfolgt.

11. Referenzlinks

• Offenlegung zu maschinellen Prüfungen — Sozialversicherungsträger für ärztliche Honorare (Social Insurance Medical Fee Payment Fund) (CSV-Veröffentlichung der zentralen Prüfbedingungen und Prüf-Mastertabellen)
• Abgleichprüfung und Verlaufsprüfung — Sozialversicherungsträger für ärztliche Honorare
• Rezeptprüfung, Bewertung, Rücksendungen, Abrechnungskürzungen, Anträge auf erneute Prüfung und mehr — Ärztekammer Tokio, „Kernpunkte der Versicherungsmedizin für niedergelassene Ärzte“
• Nichi-Rece Ambulanz-Edition Handbuch (Themen zur Datenprüfung) — ORCA Project
• Rece-den-Datenprüfung: Spezifikation der Prüfbedingungen — ORCA Project
• Nichi-Rece-Kern-Quellcode der 5.2er-Serie (Snapshot veröffentlicht Juli 2026): lddef/orca41.ld / cobol/orca41/ORCGD*.CBL / cobol/copy/CPCHK.INC / record/tbl_chk*.db / record/xml_data_checkv3req.db / screen/D01.glade / screen/D04.glade / screen/X91.glade / lddef/api01rv2.ld (contraindicationcheckv2) und andere — alle Aussagen zur Implementierung in diesem Artikel basieren auf diesem Snapshot

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Worin unterscheiden sich Abrechnungskürzung und Rücksendung?

Beide Begriffe betreffen die Prüfung durch die Abrechnungsstellen (den Sozialversicherungsträger für ärztliche Honorare und die Verbände der gesetzlichen Krankenversicherung), bedeuten aber Unterschiedliches. Eine Rücksendung (henrei) ist ein an die medizinische Einrichtung zurückgeschicktes Rezept; die Einrichtung kann den Eingabefehler oder den Berechtigungsfehler korrigieren und es in einem späteren Monat erneut einreichen. Eine Abrechnungskürzung (satei) bedeutet, dass die Punkte auf dem Rezept infolge der Prüfung nach oben oder unten angepasst werden (in der Praxis so gut wie immer nach unten), sodass sich der abgerechnete Betrag entsprechend verringert. Wenn Sie mit einer Kürzungsentscheidung nicht einverstanden sind, gibt es ein Verfahren zur Beantragung einer erneuten Prüfung.

Wie oft wird ein Rezept vor der Einreichung geprüft?

Grob gesagt durchläuft es mehrere Prüfstufen. Innerhalb der medizinischen Einrichtung gibt es die inhaltliche Prüfung durch das Abrechnungssystem (bei ORCA die Datenprüfungsfunktion) sowie die rece-den-Datenprüfung, die die elektronische Rezeptdatei als Abrechnungsdaten untersucht. Nach der Einreichung folgen die maschinellen Prüfungen der Abrechnungsstellen (Prüfbedingungen auf Basis amtlicher Bekanntmachungen und Rundschreiben sowie Prüf-Mastertabellen auf Basis von Packungsbeilagen), die Abgleichprüfung, die die medizinischen und die Abgabe-Rezepte eines Patienten einander gegenüberstellt, und die Verlaufsprüfung, die die Abrechnung mit den Vormonaten vergleicht — gefolgt von der Bewertung durch Mitarbeitende und den Prüfausschuss.

Wie ist die Rezeptprüfung in ORCA (Nichi-Rece) implementiert?

Sie ist als Datenprüfungsfunktion (Geschäftsmenü 41) implementiert, und die Implementierung lässt sich im veröffentlichten Quellcode nachvollziehen. Die Regeln zum Verhältnis zwischen Arzneimitteln und Maßnahmen (Arzneimittel versus Diagnose, Maßnahme versus Diagnose, kontraindizierte Arzneimittelkombinationen und Ähnliches) werden als Daten in einer Tabellenfamilie namens Prüf-Mastertabellen (Check-Master) gehalten, die von COBOL-Programmen interpretiert werden, um Patientendaten zu prüfen — eine klassische Struktur aus „Regeltabelle plus Engine“. Grundlegende Prüfungen wie die Konsistenz der Versicherung und die tatsächliche Anzahl der Behandlungstage sind direkt im Programmcode implementiert. Außerdem gibt es Funktionen zur Registrierung von Ausnahmen (diesen Fehler nicht prüfen) und eine API (datacheckv3) zum Starten der Datenprüfung aus einem externen System.

Werden die von den Abrechnungsstellen verwendeten Prüfregeln veröffentlicht?

Teilweise. Unter der Überschrift „Offenlegung zu maschinellen Prüfungen“ veröffentlicht die Zahlungsstelle sowohl ihre zentralen Prüfbedingungen, die sich aus amtlichen Bekanntmachungen und Rundschreiben ableiten, als auch ihre Prüf-Mastertabellen, die sich aus Arzneimittel-Packungsbeilagen ableiten, als CSV-Dateien — und weitet den Umfang schrittweise aus. Auch die Mechanismen der Abgleichprüfung und der Verlaufsprüfung werden auf der offiziellen Website erläutert. Allerdings werden manche Prüfungen nicht veröffentlicht, darunter Fälle, die eine Prüfung des Bemerkungsfelds erfordern, oder solche, die eine klinische Beurteilung verlangen.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.