ORCA (Nichi-Rece) ist keine elektronische Patientenakte ── Abrechnungssysteme und die Architektur von Healthcare-IT aus Sicht eines Ingenieurs

Haben Sie schon einmal den Ausdruck „die ORCA-Patientenakte“ gehört? Es ist ein Name, der bei jedem Projekt rund um Systeme für medizinische Einrichtungen unweigerlich fällt – doch die Formulierung enthält einen Irrtum. ORCA (die JMA Standard Receipt Software) ist keine elektronische Patientenakte.

Dieser Artikel richtet sich an Ingenieurinnen und Ingenieure, die zum ersten Mal mit Healthcare-IT zu tun haben, und will die folgenden Fragen beantworten.

• Was ist ORCA, und wo steht es in der Systemarchitektur einer medizinischen Einrichtung?
• Was genau macht die „Abrechnungsarbeit“, für die ein medizinisches Abrechnungssystem zuständig ist, aus Systemsicht eigentlich?
• Mit welchen Technologien ist es gebaut, und was steckt im veröffentlichten Quellcode?
• Was ändert sich mit dem Wechsel zu WebORCA, und worauf muss eine integrierende Partei achten?

Alles hier Beschriebene beruht auf veröffentlichten Primärquellen. Aussagen zum Quellcode sind das Ergebnis des tatsächlichen Herunterladens und Untersuchens des offiziell veröffentlichten Nichi-Rece-Quellcodes der 5.2er-Serie (Snapshot vom 1. Juli 2026, VERSION-Datei mit Eintrag 5.2.0).

Inhaltsverzeichnis

1. Zunächst das Fazit ── ORCA ist ein „medizinisches Abrechnungssystem“
2. Was Abrechnungsarbeit ist ── der kürzeste Weg zum Systemverständnis
3. Die Systemarchitektur einer medizinischen Einrichtung ── wo ORCA steht
4. Geschichte und Lizenz des ORCA-Projekts
5. Der Technologie-Stack ── die vier Millionen Zeilen COBOL tatsächlich ausgezählt
6. Sich im Quellbaum zurechtfinden ── was wo liegt
7. Integrationspunkte ── die Nichi-Rece-API, PushAPI und CLAIM
8. Was sich mit dem Wechsel zu WebORCA ändert
9. Zusammenfassung ── die Punkte, die Ingenieurinnen und Ingenieure kennen sollten
10. Quellen

1. Zunächst das Fazit ── ORCA ist ein „medizinisches Abrechnungssystem“

Die „JMA Standard Receipt Software“ (kurz Nichi-Rece), die im Zentrum des ORCA-Projekts steht, ist ein medizinisches Abrechnungssystem (auf Japanisch ein Receipt Computer oder Rececon). Ein medizinisches Abrechnungssystem berechnet aus den erbrachten Leistungen die fällige ärztliche Vergütung und erstellt das Rezept (die Leistungsabrechnung), das bei den Prüf- und Zahlungsstellen eingereicht wird.

Elektronische Patientenakte und medizinisches Abrechnungssystem haben klar getrennte Rollen.

Der Spitzname „die ORCA-Patientenakte“ entstand, weil viele Produkte für elektronische Patientenakten mit einer Architektur „der Abrechnungsteil wird über ORCA integriert“ aufgebaut wurden. Fixieren Sie als Ingenieurin oder Ingenieur einmal die Unterscheidung – ORCA = das Rückgrat der Abrechnungsseite, elektronische Patientenakte = die klinische Seite –, fügt sich alles Weitere deutlich leichter zusammen.

2. Was Abrechnungsarbeit ist ── der kürzeste Weg zum Systemverständnis

Der schnellste Weg zu verstehen, um was für ein System es sich bei einem medizinischen Abrechnungssystem handelt, führt über den Umsatzfluss einer medizinischen Einrichtung. Im japanischen Krankenversicherungssystem zahlt die Patientin oder der Patient in der Regel nur 10 bis 30 Prozent am Schalter, und den Rest rechnet die medizinische Einrichtung monatlich gegenüber den Prüf- und Zahlungsstellen ab (dem Sozialversicherungsfonds für ärztliche Vergütungen und den Verbänden der gesetzlichen Krankenversicherung). Dieses Abrechnungsdokument ist das Rezept.

Systemisch betrachtet ist ein medizinisches Abrechnungssystem eine Maschine, die den folgenden monatlichen Batch-Zyklus durchläuft.

1. Täglich: Der Empfang prüft die Versicherungsberechtigung, medizinische Leistungen (Konsultation, Untersuchungen, Verschreibungen, Behandlungen und so weiter) werden erfasst, und der Patient wird mit dem automatisch aus der Gebührenordnung berechneten Eigenanteil belastet.
2. Monatlich: Die Leistungen eines Monats werden je Kombination aus Patient und Versicherung aggregiert und zu Abrechnungen verarbeitet. Vor der Einreichung läuft eine Datenprüfung (Konsistenz zwischen Diagnosen und Verschreibungen und so weiter), und das Ergebnis wird als elektronische Abrechnungsdaten (Rece-Den-Daten) übermittelt.
3. Ab dem Folgemonat: Von der Prüfung zurückgewiesene Abrechnungen (Henrei, zurückgesandte Abrechnungen) und in der Bewertung gekürzte Abrechnungen (Satei) werden bearbeitet, korrigiert und erneut eingereicht.

Wichtig ist dabei, dass sich die Regeln zur Berechnung der Punktzahlen mit der zweijährlich stattfindenden Reform der ärztlichen Vergütungen ändern. Kann die Software mit Änderungen an der Leistungsstammdaten, den Arzneimittelpreisen und den Berechnungsregeln nicht Schritt halten, kann die medizinische Einrichtung nicht korrekt abrechnen. Die eigentliche Schwierigkeit eines medizinischen Abrechnungssystems liegt nicht in der Benutzeroberfläche und nicht in der Skalierung – sie liegt darin, diese regulatorische Konformität über Jahrzehnte aufrechtzuerhalten. Die weiter unten behandelten Änderungsprotokolle im Quellcode von ORCA sind genau diese Aufzeichnung.

3. Die Systemarchitektur einer medizinischen Einrichtung ── wo ORCA steht

Zeichnet man sie auf, platziert die typische Architektur einer Klinik ORCA (Nichi-Rece) nahe am Knotenpunkt der internen Systeme.

flowchart LR
    subgraph clinic["Innerhalb der medizinischen Einrichtung"]
        EMR["Elektronische Patientenakte<br/>klinische Unterlagen & Anordnungen"]
        RSV["Empfangs- und Terminsystem"]
        ONS["Terminal zur Online-Anspruchsprüfung"]
        ORCA["ORCA/Nichi-Rece<br/>medizinisches Abrechnungssystem (Leistungsabrechnung)"]
        EMR -->|"Nichi-Rece-API (HTTP)"| ORCA
        RSV -->|"Empfangs- und Terminintegration"| ORCA
        ONS -->|"Informationen zur Versicherungsberechtigung"| ORCA
    end
    ORCA -->|"Abrechnungen (monatliche Forderungen)"| PAY["Prüf- und Zahlungsstellen<br/>Zahlungsfonds & Krankenversicherungsverbände"]

Es gibt drei Punkte zu beachten.

• In den meisten Architekturen liegen die Stammdaten für Patienten und Versicherungen auf der ORCA-Seite. Die elektronische Patientenakte liest und aktualisiert sie über die API. Welche Seite die Vergabe der Patientennummern übernimmt, ist der erste Streitpunkt bei jedem Integrationsentwurf.
• Medizinische Leistungen (was getan wurde) werden von der elektronischen Patientenakte an ORCA gesendet, und ORCA führt die Punktzahlberechnung durch, die in Abrechnung und Forderung mündet. Die elektronische Patientenakte beschreibt die Behandlung in der „Sprache der Anordnungen“, ORCA in der „Sprache der Punktzahlen“; die Übersetzung dazwischen (das Mapping der Leistungscodes) ist der eigentliche Knackpunkt der Integration.
• Die monatliche Abrechnungseinreichung ist Aufgabe von ORCA. Anders gesagt: Der Umsatz einer medizinischen Einrichtung wird über ORCA abgerechnet. Integrationsfehler zeigen sich nicht als fehlende klinische Unterlagen, sondern als falsche Abrechnungsbeträge – diese Spannung ist charakteristisch für diesen Bereich.

4. Geschichte und Lizenz des ORCA-Projekts

ORCA ist ein Projekt der Japan Medical Association (JMA). Mit der „JMA-IT-Erklärung“ vom November 2001 wurde die Leitlinie festgelegt, von der Japan Medical Association entwickelte Software als Open Source zu veröffentlichen, und Nichi-Rece wurde als Herzstück dieser Leitlinie entwickelt. Der klinische Einsatz begann 2002, und die Entwicklung wird seither seit über zwanzig Jahren fortgeführt.

Aus Sicht eines Ingenieurs bemerkenswert ist, dass der Quellcode eines Fachanwendungssystems seit über zwanzig Jahren fortlaufend veröffentlicht wird.

• Die Lizenz ist die dem Quellcode beiliegende JMA-OpenSource-Lizenz Version 1.0. Sie ist keine GPL, sondern eine eigene Vereinbarung der JMA: Die Nutzung des Programms (einschließlich Vervielfältigung, Bearbeitung, Verbreitung und öffentlicher Zugänglichmachung) wird nicht-exklusiv und unentgeltlich gewährt, und für die Verbreitung geänderter Versionen gelten dieselben Bedingungen – eine copyleft-ähnliche Struktur. Anwendbares Recht ist japanisches Recht.
• Früher war ein CVS-Repository öffentlich zugänglich, doch mit dem Start der kommerziellen Ausgabe wurde CVS geschlossen. Die aktuelle Regelung sieht vor, dass am Ersten jedes Monats der Quellcode zum Stand des Ersten des Vormonats als Tarball veröffentlicht wird. Veröffentlicht werden drei Komponenten – das Hauptprodukt, die regionale Unterstützung öffentlicher Aufwendungen und öffentliche Formulare –, und die Serien 5.0, 5.1 und 5.2 werden parallel veröffentlicht.
• Auch die Entwicklungs- und Bereitstellungsstruktur ist bemerkenswert. Liest man die Änderungsprotokolle im Quellcode, findet man in den frühen Jahren Namen von Ingenieurinnen und Ingenieuren von NACL (dem Entwicklungsauftragnehmer), die ab etwa 2022 zu Commits unter dem Namen der ORCAMO (der ORCA Management Organization der Japan Medical Association) übergehen. Begleitende Dienstleistungen (Support, Paketierung, Handbücher und so weiter) stellt die ORCA Management Organization als kommerzielle Ausgabe bereit, während Rollout und Wartung von landesweit zertifizierten Support-Anbietern übernommen werden – ein Modell der Arbeitsteilung.

ORCA ist also Software, die „Open Source, aber keine GitHub-artige Community-Entwicklung“ ist. Man kann den Quellcode lesen, man kann forken, doch der Hauptzweig wird von einer einzelnen Stelle vendorähnlich vorangetrieben. Bedenkt man einen Bereich wie das Gesundheitswesen, in dem Fehler nicht toleriert werden und regulatorische Konformität zwingend ist, halte ich das für eine vernünftige Lösung.

5. Der Technologie-Stack ── die vier Millionen Zeilen COBOL tatsächlich ausgezählt

INSTALL.ja im veröffentlichten Quellcode der 5.2er-Serie listet MONTSUQI (panda), OpenCOBOL, PostgreSQL, MONPE und weitere als benötigte Software auf. Zusammengefasst sieht die Architektur so aus:

Worte allein vermitteln nicht das Ausmaß, daher hier die Ergebnisse des tatsächlichen Auszählens des 5.2er-Serien-Snapshots (rund 8.200 Dateien und 237 MB nach Entpacken).

Die Namen der Datenbanktabellen sind angenehm schlicht, und hat man sich einmal eingelesen, wird das Geschäft direkt sichtbar. Zum Beispiel tbl_ptinf (Patientenstammdaten), tbl_ptbyomei (Patientendiagnosen), tbl_uketuke (Empfang), tbl_jyurrk (Behandlungshistorie), tbl_tensu (Punktzahl-Stammdaten), tbl_syskanri (Systemverwaltung). Die Rollenverteilung aus Kapitel 1 – Patient, Versicherung, Diagnose, Leistung, Punktzahl – ist direkt als Tabellenstruktur umgesetzt.

Der Grundpfeiler der Architektur ist MONTSUQI. Intern ist Nichi-Rece ein klassisches zentralistisches System: Der Java-Client (monsiaj) empfängt Bildschirmdefinitionen vom Server und stellt sie dar, Eingaben werden von COBOL-Programmen auf dem Server verarbeitet, die wiederum PostgreSQL lesen und schreiben. Welcher Bildschirm zu welchem COBOL-Programm gehört, wird in den LD-Definitionsdateien im Verzeichnis lddef/ deklariert.

flowchart LR
    CL["monsiaj<br/>Java-Client"] -->|"Bildschirminteraktion"| MW["MONTSUQI<br/>Anwendungsserver"]
    API["Integrierendes System<br/>z. B. elektronische Patientenakte"] -->|"Nichi-Rece-API (HTTP)"| MW
    MW -->|"Weiterleitung anhand der Definitionen in lddef/*.ld"| AP["Fachprogramme<br/>ca. 1.750 COBOL-Quellen"]
    AP --> DB[("PostgreSQL<br/>285 Tabellen")]

Interessant ist, dass die Weiterleitung von Bildschirmen und die Weiterleitung von APIs in derselben LD-Definitionsdatei liegen. Anders gesagt: Die Nichi-Rece-API ist kein nachträglich angebauter separater Server; sie ist als „Eingangspunkt, der statt über einen Bildschirm per XML kommuniziert“ implementiert, der modulweise auf derselben Fachprogrammplattform aufsetzt wie die interaktiven Bildschirme. Die Details dieses Entwurfs behandelt der Folgeartikel.

Die Kombination „COBOL + eigens entwickelte Middleware + PostgreSQL“ wirkt weit entfernt vom Gefühl moderner Webentwicklung. Und doch trägt der Kopf eines einzelnen COBOL-Programms ein Änderungsprotokoll in Kommentaren, das bis 2002 zurückreicht, bis hin zu jüngster regulatorischer Arbeit wie elektronischen Verschreibungen (2022) und der Anspruchsprüfung per My-Number-Versichertenkarte (2024) – man liest daraus ab, dass dieselbe Codebasis seit über zwanzig Jahren mit Reformen Schritt hält. Diese Architektur ist auch das Ergebnis einer Optimierung auf „ausgereift sein und weiterlaufen“.

6. Sich im Quellbaum zurechtfinden ── was wo liegt

Als Landkarte zum tatsächlichen Lesen des Quellcodes hier die wichtigsten Verzeichnisse der obersten Ebene.

Eine praktische Warnung. Der Quellcode ist in EUC-JP kodiert (das Lizenzdokument in ISO-2022-JP). Öffnet man ihn in einem modernen Editor, erhält man Mojibake, sodass man ihn letztlich über iconv -f EUC-JP -t UTF-8 lesen muss. Es ist eine Art Zeitkapsel, in der der Standard der Linux-Umgebung von 2002 unverändert erhalten geblieben ist.

7. Integrationspunkte ── die Nichi-Rece-API, PushAPI und CLAIM

Für eine Ingenieurin oder einen Ingenieur auf einem externen System, die oder der ORCA berührt, gab es effektiv drei Einstiegspunkte.

1. Die Nichi-Rece-API ── die aktuelle Empfehlung. Das integrierende System sendet HTTP-Anfragen, um Patientendaten abzurufen, den Empfang zu registrieren, medizinische Leistungen zu registrieren und Ähnliches. Lesende Operationen sind im Grunde GET oder POST + XML, schreibende Operationen POST + XML. Die API-Spezifikation ist auf der offiziellen Website veröffentlicht.
2. PushAPI ── ein Mechanismus, um das integrierende System über auf Nichi-Rece-Seite eintretende Ereignisse zu benachrichtigen (etwa Druckanweisungen für Formulare). Damit lässt sich eine Bildschirmkoordination ereignisgesteuert statt per Polling aufbauen.
3. CLAIM ── lange als Standardprotokoll für den medizinischen Informationsaustausch genutzt, doch der Support endete im März 2026. CLAIM-bezogene Verarbeitung ist im Quellcode noch vorhanden, doch für bestehende CLAIM-Integrationen wird nun die Migration zur API vorausgesetzt.

Kurz gesagt: Wer heute eine ORCA-Integration entwirft, hat nur die Wahl der Nichi-Rece-API. Und wie oben angemerkt, lässt sich, weil die API auf derselben COBOL-Fachprogrammplattform implementiert ist wie die interaktiven Bildschirme, bei „das Verhalten der API ist unklar“ bis in den Quellcode hinabsteigen und nachprüfen. Das konkrete Vorgehen, sich anhand des Quellcodes ein Gesamtbild der API zu verschaffen (einschließlich Endpunkten, die in der offiziellen Liste fehlen), erläutert der Folgeartikel.

8. Was sich mit dem Wechsel zu WebORCA ändert

ORCA befindet sich derzeit in der Übergangsphase zu „WebORCA“. Es gibt grob zwei Bereitstellungsformen.

• WebORCA Cloud-Edition ── die Nutzung von Nichi-Rece als von der ORCA Management Organization bereitgestellter Cloud-Dienst. Die medizinische Einrichtung ist von der Serververwaltung befreit.
• WebORCA On-Premises-Edition ── Installation auf einem internen Server (Ubuntu).

Wichtig ist, dass beide innen dasselbe Nichi-Rece sind. Die laufende Software wird je nach Bereitstellungsform nicht zu einem anderen Produkt; die API-Palette und ihr Verhalten sind für beide grundsätzlich identisch. Die Unterschiede, auf die eine integrierende Ingenieurin oder ein integrierender Ingenieur achten muss, konzentrieren sich nicht auf die Implementierung, sondern auf die Konnektivität.

• Unterschiede am Eingangspunkt wie das /api-Präfix der API-Anfragepfade in der Cloud-Edition und je nach Bereitstellungsform unterschiedliche Verbindungs- und Authentifizierungseinstellungen. Die API-Spezifikation selbst ist gemeinsam.
• Bei der Cloud-Edition rufen interne integrierende Systeme die API über das Internet auf, sodass Netzwerkführung und degradiertes Verhalten bei Ausfällen mehr Entwurfsaufwand erfordern als bei einer On-Premises-Architektur.
• Die monatliche Quellcode-Veröffentlichung enthält auch die WebORCA-Definitionen (etwa die .db.weborca-Dateien unter record/). Das ist der Beweis, dass ein einziger Quellbaum beide Bereitstellungsformen trägt, und es bedeutet, dass aus dem Quellcode gewonnenes Wissen auch für die Cloud-Edition gilt. Beachten Sie, dass manche .weborca-Definitionen Dinge wie Array-Obergrenzen anpassen; prüfen Sie beim Entwurf einer WebORCA-Integration daher, ob eine WebORCA-spezifische Definition existiert.

9. Zusammenfassung ── die Punkte, die Ingenieurinnen und Ingenieure kennen sollten

• ORCA (Nichi-Rece) ist keine elektronische Patientenakte, sondern ein medizinisches Abrechnungssystem. Es hält das Rückgrat der abrechnungsseitigen Daten – Patient, Versicherung, Diagnose, Leistung, Punktzahl –, und der Umsatz einer medizinischen Einrichtung wird darüber abgerechnet.
• Die eigentliche Schwierigkeit eines medizinischen Abrechnungssystems liegt darin, die Konformität mit der zweijährlichen Reform der ärztlichen Vergütungen über Jahrzehnte aufrechtzuerhalten. Die Änderungsprotokolle im Quellcode von ORCA sind genau diese dokumentierte Aufzeichnung.
• Es ist ein Open-Source-Fachanwendungssystem, das seit der JMA-IT-Erklärung von 2001 läuft, mit monatlich als Tarball veröffentlichtem Quellcode. Die Lizenz ist nicht GPL, sondern die JMA-OpenSource-Lizenz.
• Im Inneren stecken 1.754 COBOL-Quellen mit insgesamt rund 4,06 Millionen Zeilen, dazu MONTSUQI und 285 PostgreSQL-Tabellen (gemessen an der 5.2er-Serie). Bildschirme und APIs werden über dieselben LD-Definitionen in einer zentralistischen Architektur weitergeleitet.
• Die Nichi-Rece-API ist der aktuelle Einstiegspunkt für externe Integration. CLAIM erreichte im März 2026 das Ende des Supports. Die WebORCA-Migration läuft, doch sowohl Cloud- als auch On-Premises-Edition sind innen dasselbe Nichi-Rece, sodass aus dem veröffentlichten Quellcode gewonnenes Wissen für beide gilt.

Im nächsten Teil lesen wir diesen veröffentlichten Quellcode tatsächlich und erklären, wie sich aus dem Quellcode das Gesamtbild der Nichi-Rece-API erschließen lässt – welche URL von welchem COBOL-Programm verarbeitet wird und welche Endpunkte in der offiziellen Liste fehlen – komplett mit einer Zuordnungstabelle aller 137 Endpunkte.

10. Quellen

• Was ist ORCA - ORCA Project
• Technische Informationen - JMA Standard Receipt Software - ORCA Project (Quellcode-Veröffentlichungen, API-Spezifikationen, Tabellendefinitionsdokumente)
• JMA Standard Receipt Software API - ORCA Project
• JMA Standard Receipt Software „ORCA“ - Japan Medical Association ORCA Management Organization
• Über die kommerzielle Ausgabe der JMA Standard Receipt Software - Japan Medical Association ORCA Management Organization
• WebORCA Cloud-Edition - ORCA Project
• Quellcode der Nichi-Rece-5.2er-Serie (Snapshot veröffentlicht im Juli 2026) INSTALL.ja / doc/license.html / lddef/orcadb.inc und weitere ── alle im Artikel genannten Messwerte beruhen 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.

Ist ORCA eine elektronische Patientenakte?

Nein. Die JMA Standard Receipt Software (Nichi-Rece), die im Zentrum des ORCA-Projekts steht, ist ein medizinisches Abrechnungssystem, das für die Abrechnung ärztlicher Leistungen (Rezepte/Claims) zuständig ist. Die elektronische Patientenakte, in die klinische Notizen geschrieben werden, ist eine separate Software, und die meisten medizinischen Einrichtungen nutzen eine elektronische Patientenakte, die über eine API mit ORCA verbunden ist. Die Bezeichnung „die ORCA-Patientenakte“ versteht man am besten als Spitznamen, der entstanden ist, weil ORCA so häufig zusammen mit einer solchen eingesetzt wird.

Kann jeder den Quellcode von ORCA (Nichi-Rece) lesen?

Ja. Der Quellcode der JMA Standard Receipt Software selbst wird unter der JMA-OpenSource-Lizenz veröffentlicht, und am Ersten eines jeden Monats lässt sich ein Snapshot zum Stand des Ersten des Vormonats als Tarball herunterladen. Das frühere CVS-Repository wurde beim Start der kommerziellen Ausgabe geschlossen, doch die Veröffentlichung des Quellcodes selbst wird fortgesetzt.

Mit welchen Technologien ist ORCA gebaut?

Der Server läuft unter Linux, und der Großteil der Geschäftslogik ist in COBOL geschrieben. Als Datenbank kommt PostgreSQL zum Einsatz, als Ausführungsplattform für die Fachprogramme eine Open-Source-Middleware namens MONTSUQI (panda), und als Client dient typischerweise das in Java geschriebene monsiaj. Zählt man den Quellcode der 5.2er-Serie, entfallen auf COBOL allein rund 1.750 Programme mit über vier Millionen Zeilen, bei mehr als 280 Datenbanktabellen.

Wie integriert sich eine elektronische Patientenakte mit ORCA?

Die aktuelle Empfehlung ist die Nichi-Rece-API. Das integrierende System – etwa die elektronische Patientenakte – sendet HTTP-Anfragen, um Patientendaten abzurufen, medizinische Leistungen zu registrieren und Ähnliches. Es gibt außerdem eine PushAPI, über die Nichi-Rece Ereignisse nach außen meldet. Die Integration über CLAIM (den Standard für den medizinischen Informationsaustausch), die viele Jahre lang genutzt wurde, erreichte im März 2026 das Ende des Supports, sodass jede neue Integration auf Grundlage der API konzipiert werden sollte.

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.