Was passiert, wenn Sie die My-Number-Versichertenkarte auflegen? ── Die Online-Berechtigungsprüfung und ihre Anbindung an das Abrechnungssystem aus dem Quellcode von ORCA gelesen

Legt man an der Anmeldung einer Arztpraxis die My-Number-Versichertenkarte auf das Kartenlesegerät, sind Identitätsprüfung und Berechtigungsprüfung binnen weniger Sekunden erledigt. Welche Systeme in dieser Zeitspanne in welcher Reihenfolge arbeiten – und insbesondere, wie die Berechtigungsinformation in das Abrechnungssystem gelangt, das letztlich die Abrechnung übernimmt –, können überraschend wenige Entwicklerinnen und Entwickler erklären.

Vor zwei Artikeln haben wir festgehalten, dass ORCA (die JMA-Standard-Abrechnungssoftware) ein Abrechnungssystem ist, und zuletzt haben wir gezeigt, wie sich die gesamte Nichi-Rece-API aus dem Quellcode erschließen lässt. Diesmal wenden wir beides an und sezieren die Online-Berechtigungsprüfung (im japanischen Kurzjargon on-shi) aus der Perspektive des Abrechnungssystems.

• Den vollständigen Ablauf vom Auflegen der My-Number-Versichertenkarte bis zur Registrierung der Berechtigungsinformation im Abrechnungssystem
• Woraus die „dateibasierte Anbindung“ tatsächlich besteht, die das Berechtigungsprüfungsterminal mit dem Abrechnungssystem verbindet
• Die Empfängerseite in ORCA — die 20 Berechtigungsprüfungs-APIs und die tbl_onshi_*-Tabellen
• Die Chronik der gesetzlichen Anpassungen von 2020 bis 2026, eingemeißelt in die COBOL-Änderungshistorien

Aussagen zum System selbst stützen sich auf veröffentlichte Materialien des japanischen Gesundheitsministeriums (MHLW) und von ORCA offiziell; Aussagen zum Quellcode sind das Ergebnis des tatsächlichen Lesens der offiziell veröffentlichten Nichi-Rece-5.2er-Serie (Snapshot vom 1. Juli 2026).

Inhaltsverzeichnis

1. Das Wichtigste zuerst — Die Berechtigungsprüfung als Staffelübergabe zwischen „vier Akteuren“
2. Das System in Kürze — Was die Online-Berechtigungsprüfung ist
3. Zwischen Terminal und Abrechnungssystem — Die OQS-Dateianbindung
4. Die Empfängerseite in ORCA — Die 20 Berechtigungsprüfungs-APIs im Quellcode gezählt
5. Wohin die Daten fließen — Die 13 tbl_onshi_*-Tabellen
6. tbl_onshi_kaku gelesen — Was eine einzelne Berechtigungsprüfung hinterlässt
7. Die Änderungshistorie als Chronik des Systems — 2020 bis 2026
8. Übernahme in die Patientenregistrierung — Das Ergebnis wird nicht „eins zu eins“ zur Versicherungsinformation
9. Praktische Hinweise für den Bau anbindender Systeme
10. Zusammenfassung
11. Quellen

1. Das Wichtigste zuerst — Die Berechtigungsprüfung als Staffelübergabe zwischen „vier Akteuren“

Zeichnet man den Weg vom Auflegen der My-Number-Versichertenkarte bis zur Ankunft der Berechtigungsinformation im Abrechnungssystem auf einer einzigen Seite nach, treten vier Akteure auf.

flowchart LR
    subgraph clinic["Innerhalb der medizinischen Einrichtung"]
        CR["Kartenlesegerät mit<br/>Gesichtserkennung"]
        TERM["Berechtigungsprüfungsterminal"]
        REN["Anbindungsprogramm<br/>(onshi-tools auf Nichi-Rece)"]
        ORCA["ORCA/Nichi-Rece<br/>sammelt in tbl_onshi_*"]
        UKE["Anmeldung & Patientenregistrierung"]
        CR --> TERM
        TERM <-->|"gemeinsamer Ordner<br/>OQS~.xml"| REN
        REN -->|"Berechtigungsprüfungs-APIs<br/>(Registrierung)"| ORCA
        ORCA --> UKE
    end
    TERM <-->|"IP-VPN /<br/>IPsec+IKE"| OQS["Online-Berechtigungsprüfungssystem<br/>(Payment Fund & Nationaler Verband der Krankenkassenorganisationen)"]

1. Das Kartenlesegerät mit Gesichtserkennung liest die My-Number-Karte und bestätigt die Identität (per Gesichtserkennung oder PIN).
2. Das Berechtigungsprüfungsterminal fragt über das Netzwerk des Systems (ein Carrier-IP-VPN oder eine IPsec+IKE-Verbindung über das Internet) beim Online-Berechtigungsprüfungssystem an (betrieben vom Sozialversicherungs-Honorarabrechnungsfonds sowie dem Nationalen Verband der Krankenkassenorganisationen) und erhält die Berechtigungsinformation als XML.
3. Zwischen Terminal und Abrechnungssystem ist die dateibasierte Anbindung die Norm. Die Ergebnis-XML wird in einen gemeinsamen Ordner gelegt, und ein Anbindungsprogramm übernimmt sie in das Abrechnungssystem. Bei Nichi-Rece übernimmt diese Rolle das offizielle Programm onshi-tools.
4. Die übernommenen Ergebnisse sammeln sich zunächst in einem eigenen Satz von Berechtigungsprüfungstabellen innerhalb von ORCA (tbl_onshi_*), aus denen die Anmelde- und Patientenregistrierungsprozesse sie in die Patienten- und Versicherungsinformationen übernehmen.

Der entscheidende Punkt ist, dass das Ergebnis der Berechtigungsprüfung nicht direkt in den Patientenstamm geschrieben wird, sondern zunächst in eigenen Tabellen gesammelt wird. Diese zweistufige Anordnung – die Trennung von „dem Nachweis der Anfrage“ und „der Übernahme in den Patientenstamm“ – ist der Schlüssel zum Verständnis der Berechtigungsprüfungsanbindung von ORCA (Abschnitte 6 und 8).

2. Das System in Kürze — Was die Online-Berechtigungsprüfung ist

Bevor wir in die Systeme einsteigen, hier die kürzestmögliche Zusammenfassung des Systems selbst.

• Was es tut: ein Mechanismus zur sofortigen, online durchgeführten Bestätigung der Versicherungsberechtigung einer Patientin oder eines Patienten, verankert an der My-Number-Karte (der My-Number-Versichertenkarte) oder an Kennzeichen und Nummer der Versichertenkarte. Da Änderungen der Berechtigung über Versicherer hinweg (Arbeitsplatzwechsel, Umzug und Ähnliches) zum Zeitpunkt der Anfrage widergespiegelt werden, liegt die größte Bedeutung auf der Abrechnungsseite darin, dass zurückgewiesene Abrechnungsbelege durch fehlerhafte Berechtigungsangaben reduziert werden.
• Seit wann: Der Vollbetrieb begann im Oktober 2021, und ab April 2023 wurde die Einführung des Systems für krankenversicherte medizinische Einrichtungen und Apotheken grundsätzlich verpflichtend. Im Dezember 2024 endete die Ausgabe neuer Krankenversicherungskarten, sodass nun eine auf der My-Number-Versichertenkarte basierende Regelung gilt.
• Was neben der Berechtigung noch durchkommt: Stimmt die Patientin oder der Patient am Kartenlesegerät zu, kann die medizinische Einrichtung außerdem Arzneimittelinformationen, Informationen zur spezifischen Gesundheitsuntersuchung und Behandlungsinformationen einsehen. Der Umfang wurde seither auf die Berechtigungsprüfung für Krankenhilfe (Sozialhilfe) sowie die Anbindung von Informationen kommunaler Zuschüsse zu Behandlungskosten (PMH: Public Medical Hub) ausgeweitet.

Auch wenn es „Berechtigungsprüfung“ heißt, lässt sich der heutige Stand am ehesten so einordnen, dass daraus eine Hauptleitung für den Austausch medizinischer Informationen wird, bei der die Berechtigung lediglich den Einstiegspunkt bildet und auch Behandlungsinformationen mitfließen. Wie sich diese „Ausweitung des Umfangs“ im Code des Abrechnungssystems niederschlägt, wird in Abschnitt 7 als Chronik dargestellt.

3. Zwischen Terminal und Abrechnungssystem — Die OQS-Dateianbindung

Wie ist die Schnittstelle innerhalb der medizinischen Einrichtung – zwischen Berechtigungsprüfungsterminal und Abrechnungssystem (bzw. dem System der elektronischen Patientenakte) – tatsächlich verbunden?

Die von der Regierung veröffentlichten Materialien für Systemanbieter legen mehrere Ansätze fest, um Bestandssysteme an das Online-Berechtigungsprüfungssystem anzubinden: dateibasierte Anbindung über eine Anbindungsanwendung, dazu Webanwendungsanbindung, Gesichtserkennungsanbindung und Web-API-Anbindung. Die zentrale davon, die dateibasierte Anbindung, ist grob gesagt die klassische, aber verlässliche Anordnung, bei der „eine XML-Datei mit vereinbartem Namen in einen vereinbarten Ordner gelegt wird und eine Antwort-XML-Datei zurückkommt“.

Nichi-Rece folgt diesem Ansatz. Die offizielle Seite „Nichi-Rece Online-Berechtigungsprüfung“ von ORCA nennt folgende Benennung für die mit dem Berechtigungsprüfungsterminal ausgetauschten Dateien:

• Anfrage: OQSsiquc01req_Oxxxxxxxxxxxx.xml
• Ergebnis: OQSsiquc01res_Oxxxxxxxxxxxx.xml

Diese werden über einen gemeinsamen Ordner hin- und hergereicht. Für die Abwicklung dieses Dateiaustauschs sowie die Übernahme in Nichi-Rece sorgt das offiziell bereitgestellte onshi-tools, verfügbar in einer Ubuntu- und einer Windows-Edition (begleitend werden Werkzeuge zur Überwachung des Übernahmedienstes und zur Umgebungsprüfung veröffentlicht).

Dieses „OQS“-Vokabular taucht auch im veröffentlichten Quellcode von ORCA auf. So enthält beispielsweise die Antwortdefinition record/xml_onlinequares1.db der API, die Anfragedaten für das Anbindungsprogramm zusammenstellt und zurückgibt (onlinequa1, das wir in Abschnitt 4 betrachten), Felder wie InsurerNumber, InsuredCardSymbol, QualificationConfirmationDate und LimitApplicationCertificateRelatedConsFlg (das Einwilligungsflag im Zusammenhang mit der Bescheinigung über die Zuzahlungshöchstgrenze). Die XML-Feldnamen auf Seiten des Online-Berechtigungsprüfungssystems ziehen sich unverändert bis in die API des Abrechnungssystems durch. Für alle, die ein Anbindungssystem bauen, ist das ein willkommenes Design: Sie können die Spezifikationen der Regierung und den Quellcode von ORCA im selben Vokabular gegeneinander abgleichen.

4. Die Empfängerseite in ORCA — Die 20 Berechtigungsprüfungs-APIs im Quellcode gezählt

Zählen wir nun die Empfängerseite in ORCA. Mit derselben Methode wie zuletzt – dem Herausgreifen der bindapi-Deklarationen aus den LD-Definitionen (lddef/*.ld) der 5.2er-Quellcode-Serie – ergeben sich 20 Berechtigungsprüfungs-Endpunkte, verteilt auf drei LD-Dateien. Die Funktionsnamen sind Abschriften des im Kopf des zuständigen COBOL-Programms notierten „Komponentennamens“.

(Die Erstellungsdaten stammen aus dem Erstellungsdatumsfeld im jeweiligen Programmkopf. Die Anmerkung in Klammern zu onlinequa1 ist unsere eigene, aus dem Implementierungsverhalten abgeleitete Einordnung.)

Diese Liste gliedert sich nach Rolle in drei Gruppen.

1. Registrierung (Terminalseite → Nichi-Rece): onlinequa2 (Gesichtserkennung) und onlinequa3 (Versichertenkarte) sowie die „Registrierung/Aktualisierung“-APIs für Arzneimittelinformation, spezifische Gesundheitsuntersuchung, Behandlungsinformation, OCR-Bilder, Krankenhilfe und Zuschüsse zu Behandlungskosten. Das sind die Eingangspunkte, über die vom Berechtigungsprüfungsterminal eintreffende Ergebnisse in Nichi-Rece eingespielt werden.
2. Anfrage-Zusammenstellung (Anbindungsprogramm → Nichi-Rece): Vom Namen her wirkt onlinequa1 wie eine „Ergebnisabfrage-API“, doch beim Lesen der Implementierung zeigt sich etwas anderes. Bei Angabe einer uuid (Pflichtfeld) liest die API den neuesten Datensatz in tbl_onshi_kaku und stellt daraus den Inhalt der an das Berechtigungsprüfungsterminal zu sendenden Anfrage (der OQS-Anfrage) zusammen und gibt ihn zurück – die für die Berechtigungsprüfung zu verwendende Versicherernummer, Kennzeichen und Nummer sowie Einwilligungsflags, dazu die Anfragedateinamen für Arzneimittelinformation und spezifische Gesundheitsuntersuchung (YZKsiquc01req_~.xml, TKKsiquc01req_~.xml, wobei „~“ für das mit X auf fest 20 Zeichen aufgefüllte Ende der Patientennummer steht). Es ist die API, über die ein Anbindungsprogramm, das eine PushAPI-Anfrageanweisung erhalten hat, ermittelt, „was das Terminal fragen soll“ – keine API, die angesammelte Ergebnisse durchsucht und zurückgibt.
3. Abruf (elektronische Patientenakte und Ähnliches → Nichi-Rece): Die drei unter /api01rv2/ sind APIs, über die ein Anbindungssystem auf die angesammelte Arzneimittel-, Gesundheitsuntersuchungs- und Behandlungsinformation zugreift. Dass sie sich in api01rv2 befinden, wo sich die lesenden APIs sammeln, entspricht genau den Nichi-Rece-API-Platzierungsregeln, die wir zuletzt gesehen haben.

Der Quellcode enthält außerdem eine Definition namens record/push_onlinequa.db, die zeigt, dass PushAPI-Ereignisse für die Berechtigungsprüfung (Bulk_Qualification und patient_qualification) existieren. Verfolgt man, wo sie ausgelöst werden, zeigt sich, dass Anfrageanweisungsereignisse von den Anfragebildschirmen ausgehen, von der aus Anmeldung und Patientenregistrierung aufgerufenen Berechtigungsprüfungs-Subroutine (ORCSONSHI001.CBL), vom Massenabfragebildschirm für Terminpatienten (ORCGY06.CBL) sowie von einem Batch-Job (ORCBONSHIPUSH.CBL). Mit anderen Worten ist dieses Ereignis primär ein Kanal, über den Nichi-Rece das Anbindungsprogramm anweist, „eine Berechtigungsprüfung durchzuführen“. Der Inhalt unterscheidet sich jedoch je nach Auslöser. Die Klasse kann Rreq (Anfrageanweisung) enthalten, trägt aber in manchen Fällen direkt den Wert eines Prüfpflicht-Flags (Yes), und auch die Bedeutung der uuid ist nicht einheitlich: Bei einzelnen Ereignissen ist es die uuid eines tbl_onshi_kaku-Datensatzes, bei Massenabfragen für Terminpatienten eine Job-Verwaltungs-uuid, und bei der Batch-Massenanweisung gibt es überhaupt keine uuid. Die Empfängerseite muss anhand von Ereignisname, Klasse und Bedeutung der uuid zwischen onlinequa1 (Zusammenstellung einer einzelnen Anfrage), onlinequaapp1 (Massenabfrage für Terminpatienten) und onlinerefall1 (Massenregistrierung von Anfragenummern) unterscheiden. Der Kommentar am Anfang von record/xml_onlinequareq1.db beschreibt den Ablauf, bei dem das empfangende Programm für die Push-Benachrichtigung (onshi_receiver) die Anfragedaten über onlinequa1 abruft, und zumindest für einzelne Ereignisse lässt sich der vollständige Kreislauf ablesen: Push (Anfrageanweisung) → onlinequa1 (Zusammenstellung der Anfrage) → Anfragedatei an das Terminal → onlinequa2/onlinequa3 (Registrierung des Ergebnisses). Umgekehrt lösen die Ergebnisregistrierungs-APIs für Gesichtserkennung und Versichertenkarte (onlinequa2/onlinequa3) dieses Ereignis nicht aus. Wer einen Anmeldebildschirm baut und dabei erwartet, dass PushAPI „eine Benachrichtigung in dem Moment liefert, in dem ein Ergebnis registriert wird“, wird auf eine Benachrichtigung warten, die nie eintrifft – Vorsicht ist hier geboten (Abschnitt 9).

5. Wohin die Daten fließen — Die 13 tbl_onshi_*-Tabellen

Wohin fließen die von den Registrierungs-APIs empfangenen Daten? Zieht man die onshi enthaltenden Tabellen aus der DB-Tabellenliste (lddef/orcadb.inc) heraus, ergeben sich 13. Schon das Lesen der Namen zeigt, dass sich die Arten der durch die Berechtigungsprüfung fließenden Informationen darin unmittelbar abbilden.

Die in Abschnitt 1 beschriebene zweistufige Anordnung wird hier deutlich sichtbar. Daten aus der Berechtigungsprüfung werden nicht direkt in den Patientenstamm (tbl_ptinf) oder die Versicherungstabellen geschrieben; sie landen zunächst in tbl_onshi_* — Tabellen, die im Vokabular der Berechtigungsprüfung selbst geführt werden. Das ist ein Design, das eine Pufferzone zwischen dem Vokabular des landesweiten Systems (Berechtigung, Arzneimittel, spezifische Gesundheitsuntersuchung, Behandlungsinformation und Ähnliches) und dem internen Vokabular des Abrechnungssystems (Patient, Versicherung, öffentliche Kostenübernahme und Ähnliches) legt – und man kann daran ablesen, wie es die Ausweitung des Systems (allein die Tatsache, dass die Tabellen auf dreizehn angewachsen sind, ist der Beleg dafür) aufgefangen hat, ohne das Schema des eigentlichen Abrechnungssystems zu brechen.

6. tbl_onshi_kaku gelesen — Was eine einzelne Berechtigungsprüfung hinterlässt

Liest man die zentrale Tabelle tbl_onshi_kaku (definiert in record/tbl_onshi_kaku.db), erschließt sich konkret, was eine einzelne Berechtigungsprüfung protokolliert. Hier die wichtigsten Feldgruppen.

• Ein Bündel von UUIDs: Neben TBL_UUID (der Datensatz selbst) stehen AITE_UUID, OYA_UUID, KOUHI_UUID (öffentliche Kostenübernahme), FUJYO_UUID (Krankenhilfe) und PMH_UUID (Zuschuss zu Behandlungskosten) – uuids, die auf verwandte Datensätze verweisen. Berechtigungsprüfung, Prüfung öffentlicher Kostenübernahme, Prüfung der Krankenhilfe und Zuschussinformation werden als getrennte Datensätze registriert und über eine Kette von uuids zu einem einzigen Anmeldevorgang verbunden. Das ist der Grund, weshalb die in Abschnitt 4 behandelte Anfrage-Zusammenstellungs-API (onlinequa1) die uuid zur Pflichtangabe macht.
• Die bei der Anfrage verwendeten Suchbedingungen (SHO_*): die zum Zeitpunkt der Anfrage angegebene Versicherernummer, Kennzeichen, Nummer, Filialnummer, Geburtsdatum und Ähnliches. Diese leiten sich von den bei der Anfrage übermittelten „Suchinformationen zur Berechtigungsbestätigung“ (QualificationConfirmSearchInfo) ab und sind ein Nachweis dessen, „wonach wir gefragt haben“ (Versicherernummer sowie Kennzeichen/Nummer sind nicht auf der Vorderseite einer My-Number-Karte aufgedruckt, daher handelt es sich hierbei nicht um „eine Kopie der Kartenvorderseite“).
• Die zurückgegebene Berechtigungsinformation (RES_*): Versicherernummer, Kennzeichen, Nummer, Filialnummer, Kategorie Hauptversicherter/Angehöriger, Name der versicherten Person und Ähnliches. Das ist der Nachweis dessen, „was das Berechtigungsprüfungssystem geantwortet hat“. Da Anfragebedingungen (SHO) und Ergebnisse (RES) in getrennten Feldern gehalten werden, lässt sich jede Abweichung zwischen dem lokal gehaltenen Kennzeichen/Nummer und der aktuellen Berechtigung (etwa eine Berechtigungsänderung durch Arbeitsplatzwechsel oder Umzug) am Datensatz nachvollziehen.
• Ergebnis und Status: Verarbeitungsergebnis (RESULT_*), Fehlercode und -meldung (ERR_*), Gültigkeit der Berechtigung (SIKAKU_YUKO), Klassifikation der Versichertenkarte (CARD_CLASS – abgeleitet von InsuredCardClassification, der Klassifikation des zurückgegebenen Berechtigungsdatensatzes, nicht des physischen Kartentyps), Zeitstempel der Prüfung, Verknüpfung mit der Patientennummer (PTID), ein Flag für mehrfache Treffer (FUKUSU_GAITO) und Ähnliches.
• Einwilligungsbezogene Felder: Es gibt nicht ein einzelnes Einwilligungsflag, sondern ein eigenes Flag pro Informationstyp. Arzneimittel (YAKUZAI_DOUIFLG), spezifische Gesundheitsuntersuchung (KENSHIN_DOUIFLG) und Behandlungsinformation (SHINRYO_DOUIFLG), dazu die Bescheinigung über die Zuzahlungshöchstgrenze (GENDO_DOUIFLG) und die Bescheinigung für die Behandlung bestimmter Erkrankungen (SIKKAN_DOUIFLG), weiter untergliedert bis auf Einheiten wie Operationen, Diagnosen, Infektionskrankheiten, Allergien, Untersuchungen und Verordnungen. Die in Abschnitt 2 angesprochene „Einsicht auf Grundlage der Einwilligung“ ist als Tabellenfelder implementiert, in einer Form, die genau unterscheidet, wofür im Einzelnen eingewilligt wird, aufgeschlüsselt nach Typ.

Die Kommentare in der Definitionsdatei vermerken auch, wann Felder hinzugefügt wurden: Das Dateinamensfeld für das OCR-Bild der Versichertenkarte ist mit Juli 2022 vermerkt, PMH_UUID mit November 2025. Die Tabellendefinition selbst ist Teil der im nächsten Abschnitt betrachteten Historie gesetzlicher Anpassungen.

7. Die Änderungshistorie als Chronik des Systems — 2020 bis 2026

Vor zwei Artikeln schrieb ich, dass „die Änderungshistorien in den COBOL-Köpfen eine Chronik gesetzlicher Revisionen bilden“. Die Berechtigungsprüfungsprogramme sind das anschaulichste Beispiel dafür. Hier die Erstellungsdaten und Änderungshistorien aus der Tabelle in Abschnitt 4, neben die Entwicklungen auf Seiten des Systems gestellt.

Vor zwei Artikeln schrieb ich, dass „die eigentliche Schwierigkeit eines Abrechnungssystems darin besteht, über Jahrzehnte hinweg die gesetzliche Konformität aufrechtzuerhalten“ – und die Berechtigungsprüfung ist genau diese Schwierigkeit im Präsens verlaufend. Von ihrer Entstehung 2020 bis 2026 ist nahezu jedes Jahr eine API oder eine Tabelle hinzugekommen. Das ist zugleich eine praktische Warnung, dass die Anbindung der Berechtigungsprüfung nicht als einmalig zu bauende und dann abgeschlossene Anbindung behandelt werden darf (Abschnitt 9).

Beachten Sie auch: Diffen Sie den veröffentlichten Quellcode monatlich, lassen sich Erweiterungen dieser Art als Unterschiede in lddef und record rund um die offiziellen Ankündigungstermine erkennen. Die zuletzt vorgeschlagene monatliche Diff-Überwachung der Snapshots ist gerade im Bereich der Berechtigungsprüfung besonders wirksam.

8. Übernahme in die Patientenregistrierung — Das Ergebnis wird nicht „eins zu eins“ zur Versicherungsinformation

Wie werden die in tbl_onshi_kaku angesammelten Ergebnisse letztlich in den Patientenstamm übernommen?

Zählt man die Programme, die auf die Ergebnistabelle der Berechtigungsprüfung zugreifen, liegt die mit Abstand größte Gruppe bei der Patientenregistrierung (cobol/orca12/) mit 16 Programmen, dazu weitere Zugriffe aus der Anmeldung (orca11) und den Abfrageprozessen. Greift man einfach die Abschnittskommentare in ORCGP02.CBL, dem zentralen Programm der Patientenregistrierung, heraus, offenbart sich der Ablauf der Verarbeitung.

* Online-Berechtigungsprüfung UID-Suche
* Online-Berechtigungsprüfungsdaten: Behandlung neuer Patienten
* Online-Berechtigungsprüfungsinformation: Verarbeitung der Grundinformation
* Online-Berechtigungsprüfungsinformation: Verarbeitung der Adressaktualisierung
* Online-Berechtigungsprüfungsinformation: Verarbeitung der Versicherungsinformation
* Online-Berechtigungsprüfungsinformation: Hinzufügen von Zuzahlungshöchstgrenze und weiterer öffentlicher Kostenübernahme
* Online-Berechtigungsprüfungsinformation: Prüfung des Startdatums der öffentlichen Kostenübernahme

Mit anderen Worten überschreibt Nichi-Rece nicht mechanisch mit dem Ergebnis der Berechtigungsprüfung. Es zerlegt die Übernahme in einzelne Entscheidungen im Kontext der Patientenregistrierung – „einen neuen Patienten anlegen“, „Name und Adresse aktualisieren“, „Versicherungsinformation abgleichen und aktualisieren“, „Zuzahlungshöchstgrenzenbescheinigung und öffentliche Kostenübernahme hinzufügen“, „die Gültigkeit von Startdaten prüfen“. Das Ergebnis der Berechtigungsprüfung ist Eingabe für eine Entscheidung; die maßgebliche Quelle für Patienten- und Versicherungsstamm bleibt fest bei der Patientenregistrierung. Die zweistufige Anordnung aus Abschnitt 1 lässt sich als Design genau für diese Aufgabenteilung lesen.

Die Implikation für alle, die eine elektronische Patientenakte oder ein Anmeldesystem bauen, liegt auf der Hand. Wer eine Abkürzung baut, die Berechtigungsprüfungsergebnisse direkt auf der eigenen Seite in einen Patientenstamm übernimmt, umgeht diese Abgleichlogik. Die Übernahme sollte über die eigenen Arbeitsabläufe von ORCA laufen (oder über die dazu äquivalenten APIs).

9. Praktische Hinweise für den Bau anbindender Systeme

Hier die wichtigsten Punkte, wenn ein Anmeldesystem, eine elektronische Patientenakte, ein Terminsystem oder Ähnliches mit der Berechtigungsprüfung in Berührung kommt.

1. Es gibt zwei Schnittstellen. Die Schnittstelle zum Berechtigungsprüfungsterminal (OQS-Dateianbindung) und die Schnittstelle zum Abrechnungssystem (die Nichi-Rece-API) sind zwei verschiedene Dinge. In einer Nichi-Rece-Konfiguration übernimmt onshi-tools die Dateianbindung und die Übernahme, entscheiden Sie also zuerst, ob Ihr Anbindungssystem OQS-Dateien wirklich selbst verarbeiten muss oder ob die nach der Übernahme in Nichi-Rece vorliegenden Daten genügen (Abruf-APIs für Arzneimittel-, Gesundheitsuntersuchungs- und Behandlungsinformation; die gewöhnlichen Patienteninformations-APIs für die übernommenen Patienten- und Versicherungsergebnisse). In den meisten Fällen genügt Letzteres.
2. Integrieren Sie die uuid-Kette in Ihr Design. Berechtigungsprüfung, Prüfung öffentlicher Kostenübernahme, Krankenhilfe und Zuschüsse zu Behandlungskosten sind getrennte, per uuid verkettete Datensätze (Abschnitt 6). Das Schlüsseldesign, mit dem sich „ein einzelner Anmeldevorgang“ rekonstruieren lässt, vorab aus den record/-Definitionen im Quellcode zu erarbeiten, zahlt sich später aus.
3. Prüfen Sie die „Bedeutung“ von PushAPI-Ereignissen im Quellcode, bevor Sie sie verwenden. Die push_onlinequa-Ereignisse existieren, doch soweit es um ihre Auslösestellen geht, dienen sie hauptsächlich der Anweisung einer Anfrage (Rreq); die Ergebnisregistrierungs-APIs (onlinequa2/onlinequa3) lösen sie nicht aus. Auch onlinequa1 ist keine API, die Ergebnisse zurückgibt, sondern eine, die Anfragen zusammenstellt (Abschnitt 4). Wenn Sie eine Koordination wie einen Indikator „Berechtigung geprüft“ auf einem Anmeldebildschirm möchten, können Sie nicht davon ausgehen, dass eine Benachrichtigung über den Eingang eines Ergebnisses von Nichi-Rece kommt. Die erste Partei, die weiß, dass ein Ergebnis eingetroffen ist, ist diejenige, die es registriert (das Anbindungsprogramm). Benötigen Sie diese Koordination, senden Sie entweder eine Benachrichtigung an Ihr eigenes System an derselben Stelle wie den Übernahmepfad (an dem Punkt, an dem die Registrierung abgeschlossen wird), oder gestalten Sie den Bildschirm unter der Annahme, dass die Übernahme über die Anmelde- und Patientenregistrierungsprozesse von Nichi-Rece erfolgt.
4. Respektieren Sie den Einwilligungsstatus je Informationstyp. Arzneimittel-, Gesundheitsuntersuchungs- und Behandlungsinformation fließen auf Grundlage der Einwilligung der Patientin oder des Patienten, und tbl_onshi_kaku stellt ein Einwilligungsflag pro Informationstyp bereit: YAKUZAI_DOUIFLG, KENSHIN_DOUIFLG, SHINRYO_DOUIFLG und weitere. Gestalten Sie es nicht so, dass „wenn der Aufruf der Abruf-API etwas zurückgibt, es verwendet werden darf“, ohne den Einwilligungsstatus für den jeweiligen Typ zu prüfen.
5. Planen Sie die Wartung unter der Annahme, dass jedes Jahr etwas hinzukommt. Wie Abschnitt 7 zeigt, werden sowohl APIs als auch Tabellen im Bereich der Berechtigungsprüfung nahezu jährlich erweitert. Wir empfehlen, eine Diff-Überwachung von lddef/record in der monatlichen Quellcode-Veröffentlichung fest in den Betrieb zu integrieren und sich anzugewöhnen, sie wie Release Notes für gesetzliche Anpassungen zu lesen.
6. Beginnen Sie die Verifikation mit den offiziellen Werkzeugen. Über das Anbindungsprogramm hinaus veröffentlicht ORCA offiziell Prüfmuster-Dateien, Umgebungsprüfwerkzeuge sowie Massenabrufwerkzeuge für Krankenhilfe, häusliche Pflege und Online-Versorgung. Prüfen Sie, welche offiziellen Verifikationsmittel es gibt, bevor Sie eigene Testdaten erfinden.

10. Zusammenfassung

• Die Anmeldung mit der My-Number-Versichertenkarte wird als Staffelübergabe verarbeitet: Kartenlesegerät → Berechtigungsprüfungsterminal → (Dateianbindung) → Anbindungsprogramm → Abrechnungssystem. Zwischen Terminal und Abrechnungssystem ist der Austausch von XML-Dateien nach OQS-Benennung die Norm, und bei Nichi-Rece überbrückt das offizielle onshi-tools die beiden.
• Die Empfängerseite in ORCA besteht aus 20 Berechtigungsprüfungs-APIs (Registrierung, Anfrage-Zusammenstellung und Abruf). Berechtigungsprüfungsergebnisse werden nicht direkt in den Patientenstamm geschrieben; sie sammeln sich zunächst in den 13 tbl_onshi_*-Tabellen, in einer zweistufigen Anordnung, bei der die Patientenregistrierung die Entscheidung über Abgleich und Aktualisierung trifft.
• tbl_onshi_kaku hält die bei der Anfrage verwendeten Suchbedingungen (SHO_*) und die zurückgegebene Berechtigungsinformation (RES_*) getrennt, sodass sich jede Abweichung zwischen Anfragebedingungen und aktueller Berechtigung am Datensatz nachvollziehen lässt. Verwandte Datensätze werden durch eine Kette von uuids gebündelt.
• Die COBOL-Änderungshistorien der Berechtigungsprüfungsprogramme sind eine Chronik der Ausweitung des Systems selbst, von ihrer Entstehung 2020 über Gesichtserkennung, OCR, Behandlungsinformation, Krankenhilfe, PMH bis zur Online-Versorgung. Die Anbindung der Berechtigungsprüfung ist kein „einmal bauen und fertig“; es ist ein Bereich, der unter der Annahme jährlich mitwachsender Wartung gestaltet werden sollte.
• Wie immer lässt sich all das als Primärinformation aus dem veröffentlichten Quellcode bestätigen. Da sich das Vokabular der Regierungsspezifikationen (die OQS-XML-Feldnamen) unverändert bis in die API des Abrechnungssystems durchzieht, können Sie die gesetzlichen Materialien und den Quellcode in derselben Sprache gegeneinander abgleichen.

Der nächste Artikel dieser Reihe soll die Logik der Rechnungsprüfung und -bewertung behandeln. Wir werden aufschlüsseln, worauf die interne Datenprüfung (der orca41-Ablauf von ORCA) und die computergestützten Prüfungen auf Seiten der Abrechnungsprüfungs- und Zahlstellen jeweils achten – wieder anhand des Quellcodes und veröffentlichter Materialien.

11. Quellen

• Über die Online-Berechtigungsprüfung (für medizinische Einrichtungen, Behandlungsstätten und Systemanbieter) - Ministerium für Gesundheit, Arbeit und Soziales
• Umfassendes Portal für medizinische Einrichtungen (technische Materialien zu Anbindungsanwendungen und Ähnlichem)
• Nichi-Rece Online-Berechtigungsprüfung - JMA-Standard-Abrechnungssoftware - ORCA-Projekt (onshi-tools, OQS-Dateianbindung, Verifikationsmaterialien)
• Massenabrufwerkzeug für die Online-Berechtigungsprüfung - JMA-Standard-Abrechnungssoftware - ORCA-Projekt
• Über die Unterstützung der Online-Berechtigungsprüfung durch die JMA-Standard-Abrechnungssoftware - Japan Medical Association ORCA Management Organization
• Nichi-Rece 5.2er-Quellcode-Serie (Snapshot veröffentlicht Juli 2026) lddef/orca14.ld / lddef/orca71.ld / lddef/api01rv2.ld / cobol/orca14/ORAPION*.CBL / cobol/orca71/ORAPION*.CBL / record/tbl_onshi_*.db / record/xml_onlinequares1.db / record/push_onlinequa.db / cobol/orca12/ORCGP02.CBL und weitere — die API-Liste, Tabellenfelder und Aussagen zur Änderungshistorie in diesem Artikel beruhen sämtlich 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.

Wenn eine Patientin oder ein Patient sich mit der My-Number-Versichertenkarte anmeldet, wie gelangt die Versicherungsberechtigung in das Abrechnungssystem?

Sobald die Identität an einem Kartenlesegerät mit Gesichtserkennung bestätigt wurde, fragt das Berechtigungsprüfungsterminal beim Online-Berechtigungsprüfungssystem an, das vom Payment Fund und den Krankenkassenorganisationen betrieben wird, und erhält die Berechtigungsinformationen als XML-Datei. Die Anbindung an das Abrechnungssystem erfolgt grundsätzlich dateibasiert über einen gemeinsamen Ordner; im Fall von ORCA (Nichi-Rece) nimmt das offiziell bereitgestellte Anbindungsprogramm (onshi-tools) die Ergebnisdateien entgegen. Die übernommenen Ergebnisse sammeln sich zunächst in den Berechtigungsprüfungstabellen innerhalb von Nichi-Rece (tbl_onshi_kaku und weitere) und werden von den Anmelde- und Patientenregistrierungsprozessen in die Patienten- und Versicherungsinformationen übernommen.

Liefert die Online-Berechtigungsprüfung ausschließlich Informationen zur Versicherungsberechtigung?

Nein, nicht nur Berechtigungsinformationen. Mit Einwilligung der Patientin oder des Patienten kann die medizinische Einrichtung außerdem Arzneimittelinformationen, Informationen zur spezifischen Gesundheitsuntersuchung und Behandlungsinformationen einsehen. Auch der Quellcode von ORCA stellt getrennt von den Berechtigungsprüfungsergebnissen eigene Registrierungs-APIs und Tabellen für Arzneimittelinformationen, Informationen zur spezifischen Gesundheitsuntersuchung sowie Behandlungsinformationen (Human- und Zahnmedizin) bereit. Der Umfang wird von Jahr zu Jahr erweitert und reicht inzwischen bis zur Berechtigungsprüfung für die Krankenhilfe (im Rahmen der Sozialhilfe) und zur Anbindung von Informationen zu Zuschüssen für Behandlungskosten (PMH).

Wie viele APIs zur Online-Berechtigungsprüfung besitzt ORCA (Nichi-Rece)?

Zählt man die LD-Definitionen in der veröffentlichten 5.2er-Quellcode-Serie (Snapshot vom Juli 2026), ergeben sich 20 Endpunkte im Zusammenhang mit der Online-Berechtigungsprüfung. Sie gliedern sich in Registrierungs-APIs, die Berechtigungsergebnisse sowie Arzneimittel-, Gesundheitsuntersuchungs- und Behandlungsinformationen in Nichi-Rece einspielen; Anfrage-Zusammenstellungs-APIs, die die Anfragedaten aufbauen und zurückgeben, welche das Anbindungsprogramm an das Berechtigungsprüfungsterminal sendet; sowie Abruf-APIs, über die Systeme wie die elektronische Patientenakte auf die angesammelten Daten zugreifen. Die ersten drei entstanden im November 2020, und mit jeder weiteren Ausweitung des Systems kamen neue APIs hinzu.

Worauf sollte ich beim Aufbau eines Anbindungssystems rund um die Online-Berechtigungsprüfung achten?

Zunächst sollten Sie verinnerlichen, dass die Verbindung zwischen Berechtigungsprüfungsterminal und Abrechnungssystem grundsätzlich ein Austausch von XML-Dateien ist (das Anbindungsanwendungsverfahren). Darüber hinaus müssen Sie bei einer ORCA-Anbindung berücksichtigen, dass verwandte Datensätze konzeptionell über uuids verfolgt werden, dass Registrierungs- und Abruf-APIs unterschiedliche Rollen erfüllen und dass der Einwilligungsstatus der Patientin oder des Patienten die Einsicht in Arzneimittel-, Gesundheitsuntersuchungs- und Behandlungsinformationen steuert. Und da APIs und Tabellen durch gesetzliche Anpassungen nahezu jedes Jahr erweitert werden, empfehlen wir, eine Diff-Überwachung der monatlichen Quellcode-Veröffentlichungen fest in den Betrieb zu integrieren.

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.