Was verändert das elektronische Rezept im Abrechnungssystem? — ORCAs Unterstützung für elektronische Rezepte im Quellcode gelesen

Das elektronische Rezept, das im Januar 2023 in Betrieb ging, wird oft als zweite Welle der medizinischen Digitalisierung (DX) nach der Online-Berechtigungsprüfung bezeichnet. Doch was bedeutet die Unterstützung elektronischer Rezepte konkret für ein Abrechnungssystem? „Das Rezeptformular digitalisieren“ ist keine Aussage, aus der sich ein Design ableiten lässt.

Teil 1 behandelte die Rolle des Abrechnungssystems, Teil 2 die Nichi-Rece-API, Teil 3 die Online-Berechtigungsprüfung und Teil 4 die Rezeptprüfung. In diesem fünften Teil sezieren wir das elektronische Rezept aus der Perspektive des Abrechnungssystems.

• Wie elektronische Rezepte den Verordnungsablauf verändern (das denkbar kürzeste Verständnis der regulatorischen Seite)
• Die Gesamtform der Unterstützung durch ORCA (Nichi-Rece) — die Verantwortungsteilung zwischen dem Kern und den begleitenden Programmen
• Das Design von tbl_shoho_kanri, das Rezept-IDs, Austauschnummern und Refills verwaltet
• Die Verbindung zwischen den Systemen, über die das vom Patienten bevorzugte Ausstellungsformat aus der Online-Berechtigungsprüfung eintrifft

Aussagen zur regulatorischen Seite stützen sich auf öffentliches Material des Ministeriums für Gesundheit, Arbeit und Soziales (MHLW) sowie der offiziellen ORCA-Website; Aussagen zum Quellcode 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 — das Rezept wird vom „Übergebenen“ zum „Abzuholenden“
2. Das kürzeste Verständnis der Regularien — der Verwaltungsdienst für elektronische Rezepte und die Austauschnummer
3. Vorgeschichte — Rezepte tragen schon seit 2001 QR-Codes
4. Die Gesamtform von ORCAs Unterstützung — die Verantwortungsteilung zwischen Kern und begleitenden Programmen
5. tbl_shoho_kanri gelesen — die elektronischen Attribute eines einzelnen Rezepts
6. Der Ausgang der Daten — die CSV für elektronische Rezepte und die Berichtsformulare
7. Die Verbindung zur Online-Berechtigungsprüfung — das Ausstellungsformat kommt von der Berechtigungsprüfung
8. Für Anbieter — wie eine Testumgebung eingerichtet wird
9. Praxispunkte für alle, die Integrationen bauen
10. Zusammenfassung
11. Referenzlinks

1. Das Fazit zuerst — das Rezept wird vom „Übergebenen“ zum „Abzuholenden“

Ein Papierrezept war „von Hand getragene Datenintegration“: Die medizinische Einrichtung druckte es aus, und der Patient trug es zur Apotheke. Bei elektronischen Rezepten kehrt sich der Ablauf um.

flowchart LR
    subgraph clinic["Medizinische Einrichtung"]
        DR["Verordnung des Arztes"]
        RC["Abrechnungssystem / EPA<br/>(bei ORCA: verwaltet die Rezeptdaten)"]
        SIGN["Programm zur Unterstützung elektronischer Rezepte<br/>+ separates Modul für elektronische Signatur<br/>(Signatur und Übermittlung)"]
        DR --> RC --> SIGN
    end
    SIGN -->|"Rezeptdaten registrieren"| EPS["Verwaltungsdienst für<br/>elektronische Rezepte<br/>(Zahlungsstelle / Nationaler NHI-Verband)"]
    EPS -->|"Austauschnummer (für den Patienten)"| PT["Patient<br/>(My-Number-Karte oder Austauschnummer)"]
    PT --> PH["Apotheke"]
    EPS -->|"Rezeptdaten abrufen"| PH
    PH -->|"Abgabeergebnis registrieren"| EPS2["(zurück an den Verwaltungsdienst)<br/>Grundlage für Prüfungen auf Mehrfachverordnung"]

• Die medizinische Einrichtung registriert die Rezeptdaten beim Verwaltungsdienst für elektronische Rezepte (betrieben, wie auch die Online-Berechtigungsprüfung, von der Zahlungsstelle und dem Nationalen Verband der Krankenversicherungsvereinigungen).
• Statt Papier zu tragen, wird der Patient in der Apotheke entweder mit seiner My-Number-Versichertenkarte angenommen oder gibt die Austauschnummer an (zusammen mit den Versicherungsdaten).
• Die Apotheke ruft die Rezeptdaten beim Verwaltungsdienst ab und registriert das Abgabeergebnis.

Aus Sicht des Abrechnungssystems gibt es zwei wesentliche Veränderungen. Erstens ist ein Rezept nicht mehr ein innerhalb der Praxis fertiggestelltes Formular, sondern strukturierte Daten, die bei einem externen Dienst registriert werden. Zweitens werden, weil sich Verordnungs- und Abgabedaten im Verwaltungsdienst ansammeln, Prüfungen wie Mehrfachverordnungen einrichtungs- und apothekenübergreifend möglich. In Teil 4 haben wir geschrieben, dass ein Abgleich mit den Daten einer anderen Organisation innerhalb einer Einrichtung grundsätzlich nicht möglich ist; das elektronische Rezept lässt sich als nationale Infrastruktur verstehen, um diese Mauer im Bereich der Verordnung zu überwinden (zum Zeitpunkt der Verordnung statt zum Zeitpunkt der Bewertung).

2. Das kürzeste Verständnis der Regularien — der Verwaltungsdienst für elektronische Rezepte und die Austauschnummer

Nur die wichtigsten Punkte der regulatorischen Seite.

• Seit wann: Der Betrieb begann im Januar 2023. Es handelt sich um einen Mechanismus, der auf dem Netzwerk und dem Fundament der Online-Berechtigungsprüfung aufbaut, und die Zahl der teilnehmenden Einrichtungen wird schrittweise ausgeweitet.
• Wie ein Rezept identifiziert wird: Jedem ausgestellten elektronischen Rezept wird eine Rezept-ID zugewiesen. Wird der Patient in der Apotheke mit einer My-Number-Versichertenkarte angenommen, wird das Rezept durch Auswahl am Kartenlesegerät identifiziert (bei mehreren vorhandenen Rezepten gibt es einen Auswahlschritt); verwendet er keine My-Number-Karte, wird es identifiziert, indem der Apotheke die Austauschnummer zusammen mit den Versicherungsdaten mitgeteilt wird (die Austauschnummer allein genügt nicht).
• Prüfungen auf Mehrfachverordnung: Weil sich Verordnungs- und Abgabeinformationen im Verwaltungsdienst ansammeln, können Ärzte und Apotheker zum Zeitpunkt der Verordnung die Ergebnisse von Prüfungen gegen aktuelle Verordnungs- und Abgabedaten einsehen.
• Refill-Rezepte: In der Gebührenordnungsrevision des Geschäftsjahres 2022 eingeführt, sind dies Rezepte, die innerhalb eines bestimmten Zeitraums wiederholt verwendet werden können. Elektronische Rezepte eignen sich gut für die Verwaltung wiederholter Refill-Nutzung, und wie wir sehen werden, sind Refill-Felder auch in ORCAs Tabellen eingebaut.

Wie die Kennungen zwischen Krankenhaus und Apotheke wandern

Die Struktur des elektronischen Rezepts wird am deutlichsten, wenn man in chronologischer Reihenfolge von der Ausstellung bis zur Abgabe verfolgt, durch wessen Hände die drei Kennungen — Rezept-ID, Austauschnummer und Versicherungsdaten — wandern.

sequenceDiagram
    participant MED as Medizinische Einrichtung<br/>(ORCA + E-Rezept-/Signaturmodul)
    participant EPS as Verwaltungsdienst für<br/>elektronische Rezepte
    participant PT as Patient
    participant PH as Apotheke
    Note over MED: Rezept bestätigt, elektronisch signiert
    MED->>EPS: Rezeptdaten registrieren (inkl. Versicherungsdaten)
    EPS-->>MED: Rezept-ID + Austauschnummer ausstellen
    Note over MED: In tbl_shoho_kanri erfasst<br/>Austauschnummer auf der Patientenkopie gedruckt
    MED-->>PT: Kopie übergeben (mit Austauschnummer)
    alt Annahme mit My-Number-Versichertenkarte
        PT->>PH: My-Number-Karte vorlegen und<br/>Rezept am Kartenlesegerät auswählen
        PH->>EPS: Abfrage anhand der Versicherungsdaten
    else Annahme mit Austauschnummer
        PT->>PH: Austauschnummer + Versicherungsdaten mitteilen
        PH->>EPS: Abfrage anhand der Versichertennummer etc. + Austauschnummer
    end
    EPS-->>PH: Rezeptdaten zurückgeben (intern nach Rezept-ID verwaltet)
    PH->>EPS: Abgabeergebnis registrieren

Aus diesem Diagramm lassen sich zwei Dinge ableiten.

Erstens: Es fließen keine Systemintegrationsdaten direkt vom Krankenhaus zur Apotheke. Die maßgeblichen Rezeptdaten laufen immer über den Verwaltungsdienst. Was der Patient mit sich trägt, ist ein „Schlüssel“ (eine My-Number-Versichertenkarte oder eine Austauschnummer); er kann auch eine Papierkopie des Rezeptinhalts mit sich tragen, doch diese Kopie ist nur eine Referenzinformation — die maßgeblichen Daten, aus denen die Apotheke abgibt, werden vom Verwaltungsdienst abgerufen. Man erspart sich den Aufbau einer Punkt-zu-Punkt-Integration zwischen Krankenhaus und Apotheke, doch im Gegenzug ist für beide Seiten die Qualität der Integration mit dem Verwaltungsdienst alles.

Zweitens: Die drei Kennungen haben klar unterschiedene Rollen.

Die Spuren dieses Hin- und Rücklaufs zeigen sich auf ORCA-Seite in der weiter unten besprochenen Rezeptverwaltungstabelle. Die vom Verwaltungsdienst bei Ausstellung zurückgegebene Rezept-ID und Austauschnummer werden unverändert gespeichert (PRESCRIPTIONID und ACCESSCODE) und für den Druck der Patientenkopie sowie den Abgleich bei Stornierung oder Änderung verwendet.

3. Vorgeschichte — Rezepte tragen schon seit 2001 QR-Codes

„Rezepte in Daten verwandeln“ ist tatsächlich keine neue Geschichte. ORCAs Quellcode enthält ein Programm cobol/common/ORCSQRCSV.CBL, „QR-Datenausgabe für Rezepte“, mit Erstellungsdatum September 2001. Einen QR-Code auf ein Papierrezept zu drucken, damit ihn das System der Apotheke einliest und in das Abgabesystem übernimmt, gibt es seit über zwanzig Jahren.

Die Veränderung, die das elektronische Rezept mit sich brachte, war also nicht „Digitalisierung“, sondern die Standardisierung, wo die Daten liegen und wie sie abgerufen werden. Ein QR-Code war „die Daten für dieses eine Blatt“, auf Papier gedruckt; ein elektronisches Rezept wird bei einem landesweit gemeinsam genutzten Verwaltungsdienst registriert und kann von jedem (im Rahmen seiner Berechtigungen) über die Rezept-ID abgerufen werden. Dieser Unterschied ist es, der übergreifende Funktionen wie Prüfungen auf Mehrfachverordnung ermöglicht hat. Dass alter und neuer Mechanismus im selben Quellcode-Baum koexistieren, ist ein sehr charakteristisches Bild eines Abrechnungssystems mitten im Übergang.

4. Die Gesamtform von ORCAs Unterstützung — die Verantwortungsteilung zwischen Kern und begleitenden Programmen

Laut der offiziellen Seite („Nichi-Rece Elektronische Rezepte“) besteht ORCAs Unterstützung für elektronische Rezepte aus dem Nichi-Rece-Kern plus den Programmen zur Unterstützung elektronischer Rezepte (der API für elektronische Rezepte). Liest man den veröffentlichten Quellcode der 5.2er-Serie, lässt sich diese Trennlinie auch anhand der Implementierung bestätigen.

Interessant ist die letzte Zeile. Der Mechanismus der elektronischen Signatur — das technische Highlight der elektronischen Rezepte — taucht in den vier Millionen Zeilen des Nichi-Rece-Kerns überhaupt nicht auf. Der Kern bleibt konsequent der maßgebliche Datensatz der Rezeptdaten, während die sich schnell verändernden Bereiche Signatur und Kommunikation in separate Programme ausgelagert werden — dasselbe Trennungsmuster wie bei der Integration der Online-Berechtigungsprüfung, die wir in Teil 3 gesehen haben (der Kern stellt APIs und Tabellen bereit, der Dateiaustausch läuft über onshi-tools). Man kann dies als ein Design lesen, das Spezifikationsänderungen auf Seiten der nationalen Infrastruktur vom Release-Zyklus des Kerns entkoppelt.

Was also befindet sich auf der ausgelagerten Seite? Die Aufstellung der begleitenden Programme auf der offiziellen Seite sieht so aus.

Die unterstützten Betriebssysteme unterscheiden sich je nach Komponente: Das Modul für elektronische Rezepte und der erweiterte E-Rezept-Helfer sind ausschließlich für Windows 11 (x64), während der Bildschirm für die Rezepteingabe unter Windows, Mac und Ubuntu läuft (Ubuntu-Unterstützung nur in der WebORCA-On-Premises-Edition). Bei der Planung der Arbeitsplätze in der Praxis sollte man beachten, dass die Module rund um die Ausstellung Windows voraussetzen. Auch die Aufteilung der Signaturverantwortung ist wichtig: Die offizielle Seite hält ausdrücklich fest, dass „zur Einführung elektronischer Rezepte ein separates Modul für elektronische Signatur erforderlich ist“. Die verifizierten Module für elektronische Signatur (bereitgestellt von I-O Data Device und Mitsubishi Electric IT Solutions) übernehmen die lokale Signatur mit einer HPKI-Karte sowie die Fernsignatur (FIDO-Authentifizierung, HPKI-Kartenauthentifizierung und My-Number-Kartenauthentifizierung). Mit anderen Worten: Die volatilste Frage beim elektronischen Verordnen — wie die elektronische Signatur des Arztes zustande kommt — wurde sowohl aus dem Nichi-Rece-Kern als auch aus dem E-Rezept-Modul ausgelagert und in eine eigene Signaturschicht überführt. Das ist die Antwort darauf, warum HPKI im Kern-Quellcode nie auftaucht.

Ist eine elektronische Patientenakte vorhanden, welche Seite stellt das Rezept aus?

Die bisherigen Diagramme haben alles innerhalb der medizinischen Einrichtung zu einem einzigen Ablauf zusammengefasst, doch in realen Praxen koexistieren häufig eine elektronische Patientenakte (EPA) und ein Abrechnungssystem. In diesem Fall lässt sich der Weg, auf dem ein Rezept die Apotheke (den Verwaltungsdienst) erreicht, grob in zwei Muster unterteilen.

Als Diagramm dargestellt läuft der Unterschied zwischen den beiden Mustern darauf hinaus, auf welcher Seite der Kasten „Signatur und Registrierung“ liegt.

flowchart TB
    subgraph A["Muster A: ORCA als Aussteller"]
        direction LR
        EMRA["EPA<br/>(Order-Eingabe)"] -->|"Nichi-Rece-API"| ORCAA["ORCA<br/>tbl_shoho_kanri"]
        ORCAA --> MODA["E-Rezept-Modul<br/>+ Modul für elektronische Signatur"]
        MODA -->|"Registrieren"| EPSA["Verwaltungsdienst für<br/>elektronische Rezepte"]
    end
    subgraph B["Muster B: EPA als Aussteller"]
        direction LR
        EMRB["EPA<br/>(eigene E-Rezept-Unterstützung + Signatur)"] -->|"Registrieren"| EPSB["Verwaltungsdienst für<br/>elektronische Rezepte"]
        EMRB -->|"Rezept zur Abrechnung übergeben"| ORCAB["ORCA<br/>(Rezepterstellung)"]
    end

Die Spuren von Muster A sind im Quellcode deutlich vorhanden. Die Ausstellungsquellen-Klassifikation (HAKKOKBN) in der Rezeptverwaltungstabelle, die wir in Abschnitt 5 betrachten, hat einen Wert mit der Bedeutung „API-Zwischendatenübermittlung“ (bestätigbar anhand der Kommentare im COPY-Member CPSHOHO-KANRI.INC), sodass Rezepte, die über die API aus einer EPA eingespielt werden, in derselben Tabelle verwaltet werden wie Rezepte, die auf ORCAs Bildschirmen eingegeben wurden. Das Design, das wir in Teil 2 gesehen haben — „die API ist die API-Version der Bildschirmfunktionen“ — lebt auch im Ausstellungsweg elektronischer Rezepte weiter.

In keinem der beiden Muster gibt es eine Verarbeitung, die etwas an die Apotheke „sendet“. Die Apothekenseite — das eigene Abrechnungssystem und Abgabesystem der Apotheke — ruft die Rezeptdaten vom Verwaltungsdienst ab (für die Integration innerhalb der Apothekensysteme veröffentlicht das MHLW Material zu den Integrationsdaten zwischen Abrechnungssystem und elektronischer Abgabeakte). Das Erste, was ein Anbieter auf der Einrichtungsseite entscheiden muss, ist, ob der Ausgangspunkt für Ausstellung, Signatur und Stornierung auf Seiten der EPA oder auf Seiten von ORCA liegt, und dann, im Einklang mit dieser Entscheidung, welche Seite das Äquivalent zu tbl_shoho_kanri führt, damit Rezept-IDs und Austauschnummern mit den Abrechnungsdaten abgeglichen werden können.

5. tbl_shoho_kanri gelesen — die elektronischen Attribute eines einzelnen Rezepts

Im Zentrum der Nichi-Rece-Kernseite steht die Rezeptverwaltungstabelle tbl_shoho_kanri. Aus der Definition (record/tbl_shoho_kanri.db) und den japanischen Kommentaren im COPY-Member ergeben sich die wichtigsten Felder:

tbl_shoho_kanri {
    TBL_UUID          varchar(36);  -- Identifikations-UUID
    RENNUM            number(1);    -- Laufende Nummer (Primärschlüssel ist HOSPNUM+TBL_UUID+RENNUM)
    SRYYMD / PTID / SRYKA / HKNCOMBI  -- Behandlungsdatum, Patient, Abteilung, Versicherungskombination
    SHOHO_KEITAI      varchar(1);   -- Klassifikation der Rezeptausstellung (elektronisch/Papier)
    PRESCRIPTIONID    varchar(36);  -- Rezept-ID
    ACCESSCODE        varchar(16);  -- Austauschnummer
    REFILL_NUM        number(1);    -- Refill-Anzahl
    REFILL_ZAIKAISU   number(3);    -- Refill-Rezepttage
    CANCEL_TIME / CANCEL_UNDO_TIME  -- Zeitpunkt der Rezeptstornierung und Zeitpunkt der Stornierungs-Rücknahme
    CHANGE_TIME / CHANGE_UNDO_TIME  -- Zeitpunkt der Änderung und Zeitpunkt der Änderungs-Rücknahme
};

Allein anhand dieser einen Tabelle lässt sich die Praxis des elektronischen Verordnens durchschauen.

• Sie enthält Felder für die Rezept-ID (36 Stellen) und die Austauschnummer (16 Stellen) als Paar. Die Schlüssel, die den beiden in Abschnitt 2 gezeigten Abholwegen entsprechen (My-Number-Karte / Austauschnummer), liegen dort unmittelbar als Attribute des Datensatzes vor. (Zu beachten: Die Austauschnummer ist im aktuellen Betrieb sechsstellig; die 16 ist die Spaltenkapazität. Es wäre sicherer, die Stellenzahl nicht als festen Wert zu implementieren.)
• Sowohl Stornierung als auch Änderung haben jeweils eigene UNDO-Zeitstempel. Da ein elektronisches Rezept bereits beim Verwaltungsdienst registrierte Daten sind, muss beim Stornieren eines Rezepts in der Praxis auch die Registrierung storniert werden — und selbst das Zurücknehmen dieser Stornierung (die Wiederherstellung) kann vorkommen. Was in der Papierzeit „zerreißen und neu schreiben“ war, ist zur Verwaltung von Zustandsübergängen geworden.
• Refills sind von Anfang an ein Attribut. Die Refill-Anzahl und die Rezepttage gehören zu den Grundfeldern der Rezeptverwaltung, sodass eine auf wiederholter Nutzung basierende Lebenszyklusverwaltung ins Design eingewoben ist.

Die Verwendung einer uuid zur Identifikation ist ein Idiom, das sich mit den Online-Berechtigungstabellen aus Teil 3 (tbl_onshi_kaku) teilt. Der Primärschlüssel ist jedoch nicht die uuid allein, sondern ein zusammengesetzter Schlüssel aus Einrichtungsnummer + uuid + laufender Nummer (RENNUM) — ein Design, bei dem mehrere Zeilen an derselben uuid hängen können. Wenn Ihr Integrationssystem Daten verarbeitet, die dieser Tabelle entsprechen, seien Sie vorsichtig: Behandeln Sie die uuid allein als Zeilenschlüssel, werden mehrere Zeilen zu einer zusammenfallen.

6. Der Ausgang der Daten — die CSV für elektronische Rezepte und die Berichtsformulare

Bevor wir fortfahren, hier ein zusammenfassendes Bild, wie sich Daten innerhalb von ORCA bewegen, unter Einbeziehung sowohl der Tabelle aus Abschnitt 5 als auch der Verbindung zur Online-Berechtigungsprüfung aus Abschnitt 7.

flowchart LR
    ONS["Online-Berechtigungsprüfung<br/>(bei Anmeldung)"] -.->|"Bevorzugtes Ausstellungsformat<br/>SHO_SHOHO_KEITAI"| TBL
    NYURYOKU["Rezepteingabe<br/>(Bildschirm / Nichi-Rece-API)"] --> TBL["tbl_shoho_kanri<br/>Rezept-ID, Austauschnummer,<br/>Refills, Stornierung/Änderung"]
    TBL -->|"CSV-Export<br/>(ORCSEPRECSV)"| MOD["E-Rezept-Modul<br/>(stellt Registrierungsanfrage zusammen und sendet sie)"]
    SIGNM["Modul für elektronische Signatur<br/>(elektronische Signatur)"] -.->|"Signatur"| MOD
    MOD -->|"Registrieren"| EPS["Verwaltungsdienst für<br/>elektronische Rezepte"]
    EPS -.-> RET["Rezept-ID und Austauschnummer<br/>(in tbl_shoho_kanri erfasst und<br/>an die ORCHC02-Kopieberichte übergeben)"]

Der Ausgang, durch den Rezeptdaten an die begleitenden Programme übergeben werden, ist ORCSEPRECSV.CBL (CSV-Datenausgabe für elektronische Rezepte). Die Revisionshistorie in seinem Header ist selbst ein Protokoll des Schritthaltens mit regulatorischen Änderungen.

• Oktober 2022, neu erstellt — noch vor dem Produktivstart im Januar 2023 implementiert
• Juni 2023, Unterstützung für die Übernahme aus der Dosierungsanweisungs-Mastertabelle — da elektronische Rezepte auch die Dosierungsanweisung (wie das Arzneimittel eingenommen wird) codiert behandeln, wurde die Konsistenz mit der Dosierungsanweisungs-Mastertabelle notwendig
• 2024: Unterstützung der Refill-Anzahl (Januar), Unterstützung für Bemerkungen zur Ausgabenummer (März), Unterstützung für den vom Patienten gewünschten Originalpräparat-Wunsch (August), Kanji-Namen mit 40 Byte (Dezember) — Bewegungen auf regulatorischer Seite, etwa Selbstbeteiligungen bei Auswahlbehandlung für lang gelistete Markenpräparate (Erfassung des Patientenwunsches), übersetzen sich unmittelbar in neue Felder
• 2025: Unterstützung der Dummy-Code-Warnung (Januar), Unterstützung des Ablaufdatums (April), Unterstützung der Stellenanzahl von Kostenträger-/Empfängernummer (Juli) — selbst zweieinhalb Jahre nach dem Produktivstart gehen die Anpassungen im Takt von mehreren pro Jahr weiter

Wie diese Historie zeigt, ist die CSV-Integration für elektronische Rezepte kein „einmal gebaut und fertig“, sondern etwas, das sich fortlaufend weiterentwickelt. Auf der Berichtsseite stehen Versionen mit Unterstützung für elektronische Rezepte neben den Berichtsprogrammen für das Rezeptformular (den Familien ORCHC02 und ORCHCM19). Berichte verschwinden nicht, wenn Rezepte elektronisch werden, weil sowohl die an den Patienten übergebene Kopie (einschließlich der Mitteilung der Austauschnummer) als auch das fortgesetzte Nebeneinander mit dem Papierbetrieb bestehen bleiben. „Digitalisierung = Ende der Papierformulare“ entspricht nicht der Realität der Übergangszeit; die Formulare bleiben bestehen, während sich der Ort der maßgeblichen Daten ändert — und die Dateistruktur des Quellcodes spiegelt das ehrlich wider.

7. Die Verbindung zur Online-Berechtigungsprüfung — das Ausstellungsformat kommt von der Berechtigungsprüfung

Betrachtet man es als Praxis-Workflow, ist die erste Verzweigung beim elektronischen Verordnen: „Erhält dieser Patient das Rezept elektronisch oder auf Papier?“. Woher kommt diese Information? Die Antwort lautet: Online-Berechtigungsprüfung.

Wenn ein Patient mit einer My-Number-Versichertenkarte angenommen wird, kann er am Kartenlesegerät auswählen, wie er das Rezept erhalten möchte (elektronisch oder Papier). Diese Auswahl erreicht das Abrechnungssystem zusammen mit dem Ergebnis der Berechtigungsprüfung. Die Ergebnistabelle der Berechtigungsprüfung tbl_onshi_kaku, die wir in Teil 3 gelesen haben, besitzt ein Feld für das Ausstellungsformat des Rezepts (SHO_SHOHO_KEITAI), das laut Definitionskommentar im Juli 2022 hinzugefügt wurde. Auch die XML-Definitionen der Online-Berechtigungsprüfung enthalten ein Element PrescriptionIssueSelect (Ausstellungsformat des Rezepts). Ein halbes Jahr vor dem Produktivstart der elektronischen Rezepte (Januar 2023) war die Empfangsseite auf Seiten der Online-Berechtigungsprüfung bereits erweitert worden — die Reihenfolge, in der sich die Regularien aufgebaut haben, lässt sich anhand der Daten im Quellcode nachvollziehen.

Das bei der Anmeldung festgelegte Ausstellungsformat wird dann zum Zeitpunkt der Verordnung pro Rezept als tbl_shoho_kanri.SHOHO_KEITAI fixiert. Die Übergabe von Daten zwischen den Systemen — Online-Berechtigungsprüfung (Anmeldung) → Verordnung (Konsultation) → Verwaltungsdienst (Ausstellung) — ist auf der Ebene des Tabellendesigns verbunden. Die Sichtweise aus Teil 3, die Online-Berechtigungsprüfung als „die Hauptleitung, über die Informationen vom Berechtigungseingang aus fließen“ zu bezeichnen, wird auch durch die elektronischen Rezepte bestätigt.

8. Für Anbieter — wie eine Testumgebung eingerichtet wird

Das Erste, worüber man bei der Integrationsentwicklung für elektronische Rezepte stolpert, ist nicht der Code, sondern die Tatsache, dass die Wege zur Beschaffung von Spezifikationen und Testumgebungen verstreut sind. Hier die offiziellen Informationen, nach Einstiegspunkt geordnet.

1) Beschaffung der Spezifikationen — „Medical Institution ONS“

Die primären Spezifikationen für Systemanbieter sind auf „Medical Institution ONS“ (Iryō Kikan tō ONS) gebündelt, der von der Zahlungsstelle bereitgestellten Informationsseite für Anbieter (dort finden sich sowohl das Spezifikationsdokument für die externe Schnittstelle des Online-Berechtigungsprüfungssystems als auch die Spezifikation der Aufzeichnungsbedingungen des Verwaltungsdienstes für elektronische Rezepte). Es handelt sich um eine von dem allgemeinen Portal, das medizinische Einrichtungen nutzen, getrennte Website, und eine Registrierung als Anbieter ist Voraussetzung. Ergänzend veröffentlicht die Seite „Elektronische Rezepte (für Systemanbieter)“ des MHLW ein technisches Erläuterungsdokument für Systemanbieter (zum Zeitpunkt der Abfassung Version 2.04) sowie Integrationsmaterial für Apothekensysteme. Zu beachten ist, dass der „Implementierungsleitfaden für elektronische Rezepte“ von JAHIS (Ver. 1.2, 2021) ein Vorstudiendokument aus der Zeit vor dem aktuellen Verwaltungsdienst für elektronische Rezepte ist; die Primärquellen für die aktuelle Spezifikation sind die ONS-Spezifikationen und das technische Erläuterungsdokument. Da dieses Dokument bei der Suche tendenziell zuerst erscheint, ist Vorsicht geboten.

2) Beschaffung von Testzertifikaten und -karten

Da die Ausstellung eines elektronischen Rezepts eine elektronische Signatur (HPKI) eines Arztes oder Zahnarztes erfordert, braucht man auch für Tests Zertifikate. Die Antragswege unterscheiden sich je nach Zweck.

• HPKI-Testkarten (für Signatur und für Authentifizierung): Die Anlaufstelle unterscheidet sich je nach Beruf. Für Ärzte erhält man sie, indem man ein Antragsformular von der Seite „Für Anbieter“ der Zertifizierungsstelle der Japanischen Ärztekammer (JMACA) postalisch einsendet. Für Zahnärzte und Apotheker gilt die Anleitung der jeweiligen Zertifizierungsstellen (MEDIS bzw. die Zertifizierungsstelle des Japanischen Apothekerverbands).
• Nutzung der Testumgebung für HPKI-Zweit-Zertifikate (kartenlose Signatur) und Test-My-Number-Karten: Beantragung per E-Mail bei der zuständigen Stelle von MEDIS (dem Entwicklungszentrum für medizinische Informationssysteme).
• Eine Warnung: Selbst in normalen Zeiten dauert es zwei bis drei Monate vom Antrag bis zur Ausstellung einer produktiven HPKI-Karte. Darüber hinaus besagt die Anleitung der JMACA zum Zeitpunkt der Abfassung, dass die Ausstellung physischer Karten (ärztlicher Qualifikationsnachweise) wegen eines IC-Kartenmangels vorübergehend ausgesetzt ist und dass HPKI-Zweit-Zertifikate (kartenlos) vorgezogen ausgestellt werden. Bevor man einen auf Karten basierenden Plan aufstellt, ist es sicherer, den aktuellen Ausstellungsstand zu prüfen und ob die kartenlose Signatur als Ersatz taugt.

3) Verbindungsverifikation und Prüfungen vor der Veröffentlichung

Die Verbindungsverifikation gegen den Verwaltungsdienst erfolgt gemäß der über ONS bereitgestellten Anleitung, doch was ein Entwickler zuerst lesen sollte, ist die vom MHLW veröffentlichte „Selbstprüfliste für die Veröffentlichung von Software mit Unterstützung für elektronische Rezepte (Bestätigung des Testabschlusses)“ (zum Zeitpunkt der Abfassung Version 4.2). Die Regelung sieht vor, dass Anbieter vor der Veröffentlichung den Testabschluss anhand dieser Checkliste bestätigen — was, umgekehrt betrachtet, bedeutet, dass von Anfang an eine offizielle Liste dessen existiert, „was getestet werden sollte“. Von dort rückwärts zu arbeiten ist der schnellste Weg, einen Testplan zu erstellen. Es gibt außerdem ein gemeinsames Signaturmodul für elektronische Rezepte als Option, falls man die Signatur nicht selbst implementieren möchte, und die Seiten des MHLW führen eine Liste von Anbietern, die Einführungsunterstützungsdienste anbieten.

4) Die Testumgebung auf ORCA-Seite

Wenn Sie eine Konfiguration aus Nichi-Rece plus begleitenden Programmen verifizieren, richten Sie die WebORCA-On-Premises-Edition auf einem Testserver ein und konfigurieren Sie sie gemäß dem offiziellen Installationshandbuch für E-Rezept-Modul & erweiterten E-Rezept-Helfer. Wie wir in Abschnitt 6 gesehen haben, greifen elektronische Rezepte mit der Dosierungsanweisungs-Mastertabelle ineinander, sodass Sie ohne abgeschlossene Master-Aktualisierungen die Ausgabedaten nicht wirklich verifizieren. Darüber hinaus haben Standard-Dosierungsanweisungscodes ein Ablaufdatum. Die offizielle Seite kündigt zum Zeitpunkt der Abfassung an, dass ab dem 1. August 2026 einige Standard-Dosierungsanweisungscodes in elektronischen Rezepten nicht mehr verwendbar sein werden und dass Nichi-Rece Dummy-Codes ausgibt, wenn Zuordnungen zu abgelaufenen Codes bestehen bleiben. Bringen Sie die Mastertabellen also nicht nur auf den neuesten Stand, sondern nehmen Sie auch die erneute Prüfung der Zuordnung der von Ihrem eigenen System verwendeten Dosierungsanweisungscodes in Ihre Testpunkte auf (Tests, die heute bestehen, können sich zum Ablaufdatum in eine Dummy-Code-Ausgabe verwandeln). Wie schon bei den in Teil 3 vorgestellten Musterdateien der Online-Berechtigungsprüfung gilt die eiserne Regel: Prüfen Sie, welche offiziellen Verifikationsmittel existieren, bevor Sie eigene Testdaten erfinden.

9. Praxispunkte für alle, die Integrationen bauen

Die wichtigsten Punkte, wenn eine EPA, ein Verordnungsunterstützungs- oder Anmeldesystem mit elektronischen Rezepten in Berührung kommt.

1. Ziehen Sie zuerst die Verantwortungsteilung. ORCAs Standardkonfiguration teilt die Dinge so auf: Verwaltung der Rezeptdaten im Nichi-Rece-Kern, Signatur und Kommunikation mit dem Verwaltungsdienst in den Programmen zur Unterstützung elektronischer Rezepte. Klären Sie funktionsweise, mit welcher Seite Ihre eigene Integration sprechen soll, bevor Sie sie entwerfen. Die Entscheidung, die Signatur selbst zu implementieren, bedeutet, auch den Betrieb der HPKI-Karten zu übernehmen.
2. Behandeln Sie Rezept-ID und Austauschnummer als Entitäten. Bleiben Sie beim Datenmodell „Rezept = Druckdokument“, wird die Zustandsverwaltung für Stornierung, Änderung, UNDO und Refills nachträglich zum Anhängsel. Die Feldstruktur von tbl_shoho_kanri ist ein hervorragendes Lehrbuch für den Entwurf der Rezept-Entität im Zeitalter elektronischer Rezepte. (Zu beachten ist jedoch, dass sie nur Refill-Anzahl und -Tage enthält — der Zustand, wie viele Nutzungen verbraucht und wie viele noch übrig sind, ist dort nicht abgebildet. Entwerfen Sie unter der Annahme, dass die verbleibende Anzahl Daten sind, die zum Lebenszyklus der Abgabeseite gehören und separat behandelt werden müssen.)
3. Das Ausstellungsformat fließt von der Anmeldung herunter — aber nur bei Anmeldung per My-Number. Die Präferenz des Patienten für elektronisch/Papier ist nur dann im Ergebnis der Online-Berechtigungsprüfung enthalten, wenn er mit einer My-Number-Versichertenkarte angenommen wird. Bei Patienten, die keine solche verwenden — etwa mit Berechtigungsbescheinigung —, muss die Absicht von Mitarbeitenden oder dem Arzt am Empfang oder im Sprechzimmer bestätigt werden, sodass, wenn man sich allein auf SHO_SHOHO_KEITAI verlässt, ein Weg bestehen bleibt, auf dem ein Rezept erreicht wird, ohne dass die Präferenz bestätigt wurde. Bauen Sie sowohl den Weg ein, der die Informationen vom Anmeldezeitpunkt bis zu Konsultation und Verordnung weiterträgt, als auch einen Bestätigungsablauf für den Fall, dass vom Kartenlesegerät kein Wert vorliegt.
4. Gehen Sie davon aus, dass es zwei Arten von „Papier“ gibt. Papierrezepte bleiben bestehen, bis alle Patienten und alle Apotheken auf elektronisch umgestellt haben, doch in Einrichtungen, die elektronische Rezepte eingeführt haben, gibt es die Praxis, Verordnungs- und Abgabeinformationen auch für Papierrezepte beim Verwaltungsdienst zu registrieren (ein Papierrezept mit Austauschnummer), das dann in den Geltungsbereich der Prüfungen auf Mehrfachverordnung fällt. Statt einer binären Aufteilung elektronisch/Papier ist es realistisch, die Verzweigung auf drei Fälle auszulegen: elektronisch, Papier mit Registrierung beim Verwaltungsdienst und Papier nach der traditionellen QR-Code-Regelung.
5. Verfügen Sie über einen Mechanismus zur Verfolgung regulatorischer Erweiterungen. Unterstützung der Dosierungsanweisungs-Mastertabelle, Refill-Unterstützung — der Quellcode rund um elektronische Rezepte wird jedes Jahr aktualisiert. Wie diese Serie immer wieder empfiehlt, erkennt ein Diff-Monitoring von record/ und cobol/ im monatlich veröffentlichten Quellcode auch hier Änderungen schneller als offizielle Ankündigungen.

10. Zusammenfassung

• Das elektronische Rezept verwandelt ein Rezept von „Papier, das der Patient trägt“ in „strukturierte Daten, die bei einem Verwaltungsdienst registriert und über Rezept-ID / Austauschnummer abgerufen werden“. Die Bündelung von Verordnungs- und Abgabeinformationen hat Prüfungen auf Mehrfachverordnung einrichtungs- und apothekenübergreifend möglich gemacht.
• ORCAs Unterstützung besteht aus dem Nichi-Rece-Kern (Datenverwaltung, CSV-Export, Berichte) + der begleitenden Programmfamilie (E-Rezept-Modul, erweiterter E-Rezept-Helfer und Ähnliches) + einem separat erforderlichen Modul für elektronische Signatur (verifizierte, von Anbietern bereitgestellte Produkte). Das Fehlen der elektronischen Signatur im Kern-Quellcode ist der Beleg für diese Verantwortungsteilung.
• Im Zentrum der Kernseite steht tbl_shoho_kanri, das Rezept-ID, Austauschnummer, Refill-Anzahl und -Tage sowie Stornierung/Änderung mit ihren UNDO-Zeitstempeln pro Rezept verwaltet. Die Koexistenz der Rezept-QR-Code-Ausgabe (seit 2001) im selben Quellcode spiegelt das wahre Wesen der Veränderung wider: von „Digitalisierung“ zu „Standardisierung, wo die Daten liegen“.
• Das elektronische/Papier-Ausstellungsformat kommt bei der Anmeldung als Teil des Ergebnisses der Online-Berechtigungsprüfung an — bei Anmeldung per My-Number (die Empfangsseite auf Seiten der Online-Berechtigungsprüfung wurde laut Quellcode bereits im Juli 2022 vorab hinzugefügt). Bei Patienten mit Berechtigungsbescheinigung und Ähnlichem muss die Präferenz separat am Empfang oder im Sprechzimmer bestätigt werden. Die Art, wie sich die Regularien aufbauen — zuerst Online-Berechtigungsprüfung, dann elektronische Rezepte —, ist auf der Ebene von Tabellen und XML-Definitionen verbunden.

Die nächste Folge dieser Serie ist entweder als „Datenbank-Ausgabe“ geplant, die ORCAs gesamtes Datenbankschema liest, oder als Praxis eines monatlichen Quellcode-Diff-Monitorings.

11. Referenzlinks

• Elektronische Rezepte — Ministerium für Gesundheit, Arbeit und Soziales
• Nichi-Rece Elektronische Rezepte — ORCA Project (Programme zur Unterstützung elektronischer Rezepte und Zielberichte)
• Über die Unterstützung elektronischer Rezepte in Nichi-Rece — ORCA Project
• Elektronische Rezepte (für Systemanbieter) — Ministerium für Gesundheit, Arbeit und Soziales (technisches Erläuterungsdokument, Spezifikation der Aufzeichnungsbedingungen, Selbstprüfliste vor Veröffentlichung)
• Für Anbieter (HPKI-Testkarten) — Zertifizierungsstelle der Japanischen Ärztekammer
• Rezeptdruck-API — ORCA Project
• Nichi-Rece-Kern-Quellcode der 5.2er-Serie (Snapshot veröffentlicht Juli 2026): record/tbl_shoho_kanri.db / cobol/copy/CPSHOHO-KANRI.INC / cobol/common/ORCSEPRECSV.CBL / cobol/common/ORCSQRCSV.CBL / record/tbl_onshi_kaku.db 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 unterscheidet sich ein elektronisches Rezept von einem Papierrezept?

Statt dass der Patient ein Papierrezept zur Apotheke trägt, werden die Rezeptdaten beim Verwaltungsdienst für elektronische Rezepte (betrieben von der Zahlungsstelle und dem Nationalen Verband der Krankenversicherungsvereinigungen) registriert, und die Apotheke ruft sie online ab. Der Patient wird mit seiner My-Number-Versichertenkarte angenommen und wählt das betreffende Rezept am Kartenlesegerät aus, oder er identifiziert es, indem er der Apotheke die Austauschnummer zusammen mit seinen Versicherungsdaten mitteilt (die Rezept-ID ist eine interne Systemkennung, keine Nummer, mit der der Patient hantiert). Die größte Veränderung besteht darin, dass, weil sich Verordnungs- und Abgabeinformationen im Verwaltungsdienst ansammeln, Prüfungen wie Mehrfachverordnungen einrichtungs- und apothekenübergreifend durchgeführt werden können.

Wie unterstützt ORCA (Nichi-Rece) elektronische Rezepte?

Die Rolle ist zweigeteilt. Der Nichi-Rece-Kern hält eine Tabelle (tbl_shoho_kanri), die Rezept-IDs, Austauschnummern, Refill-Anzahlen sowie die Historie von Stornierungen/Änderungen verwaltet, einen Mechanismus zum Export des Rezeptinhalts als CSV sowie Formularprogramme für Rezepte, die elektronische Rezepte unterstützen. Die elektronische Signatur (lokale Signatur mit einer HPKI-Karte oder Fernsignatur) und die Kommunikation mit dem Verwaltungsdienst für elektronische Rezepte sind dagegen Aufgabe der begleitenden Programmfamilie — des Moduls für elektronische Rezepte, des erweiterten Helferprogramms für elektronische Rezepte und Ähnlichem — sowie des separat erforderlichen Moduls für die elektronische Signatur (es gibt verifizierte, von Anbietern bereitgestellte Produkte). Dass im veröffentlichten Nichi-Rece-Kern-Quellcode keine Verarbeitung für elektronische Signaturen auftaucht, ist selbst ein Beleg für diese Verantwortungsteilung.

Was ist eine Austauschnummer?

Es ist die Nummer, die ein Patient verwendet, um ein elektronisches Rezept in einer Apotheke ohne My-Number-Versichertenkarte abzuholen. Die Apotheke identifiziert das Rezept anhand dieser Nummer zusammen mit den Versicherungsdaten und ruft es vom Verwaltungsdienst ab. Im aktuellen Betrieb ist die Austauschnummer sechsstellig; im Quellcode von ORCA (Nichi-Rece) wird sie in der Rezeptverwaltungstabelle als ACCESSCODE (ein Feld mit bis zu 16 Stellen) gespeichert und zusammen mit der Rezept-ID verwaltet.

Wie hängen Online-Berechtigungsprüfung und elektronische Rezepte zusammen?

Sie sind am Eingang miteinander verbunden. Wenn ein Patient mit einer My-Number-Versichertenkarte angenommen wird, kann er am Kartenlesegerät angeben, ob er das Rezept elektronisch oder auf Papier erhalten möchte, und diese Information (das Ausstellungsformat des Rezepts) fließt zusammen mit dem Ergebnis der Berechtigungsprüfung an das Abrechnungssystem. Auch im ORCA-Quellcode wurde der Tabelle für das Ergebnis der Berechtigungsprüfung im Juli 2022 ein Feld für das Ausstellungsformat des Rezepts hinzugefügt, was zeigt, dass Online-Berechtigungsprüfung und elektronische Rezepte auf demselben Fundament aufbauen.

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.