ORCA (Nichi-Rece) non è un sistema di cartelle cliniche elettroniche — Sistemi di fatturazione medica e architettura IT sanitaria dal punto di vista di un ingegnere

Avete mai sentito l’espressione “la cartella clinica elettronica ORCA”? È un nome che compare inevitabilmente in ogni progetto che coinvolga sistemi per strutture sanitarie, ma la formulazione contiene un malinteso. ORCA (il JMA Standard Receipt Software) non è un sistema di cartelle cliniche elettroniche.

Questo articolo è rivolto agli ingegneri che incontrano per la prima volta il lavoro nell’IT sanitaria e cerca di rispondere alle seguenti domande.

• Cos’è ORCA e dove si colloca nell’architettura di sistema di una struttura sanitaria?
• Cosa fa concretamente, in termini di sistema, il “lavoro di ricevuta” gestito da un sistema di fatturazione medica?
• Con quali tecnologie è realizzato e cosa c’è nel codice sorgente pubblicato?
• Cosa cambia con il passaggio a WebORCA e a cosa deve fare attenzione chi integra?

Tutto ciò che segue è basato su fonti primarie pubblicate. Le affermazioni sul codice sorgente sono il risultato del download e dell’ispezione effettiva del codice sorgente ufficiale della serie 5.2 di Nichi-Rece (snapshot pubblicato il 1° luglio 2026, file VERSION che riporta 5.2.0).

Indice

1. La conclusione prima di tutto — ORCA è un “sistema di fatturazione medica”
2. Cos’è il lavoro di ricevuta — il percorso più breve per capirlo come sistema
3. L’architettura di sistema di una struttura sanitaria — dove si colloca ORCA
4. La storia e la licenza del progetto ORCA
5. Lo stack tecnologico — contando effettivamente i quattro milioni di righe di COBOL
6. Navigare nell’albero dei sorgenti — cosa si trova dove
7. Punti di ingresso per l’integrazione — Nichi-Rece API, PushAPI e CLAIM
8. Cosa cambia con il passaggio a WebORCA
9. Riassunto — i punti che gli ingegneri dovrebbero cogliere
10. Riferimenti

1. La conclusione prima di tutto — ORCA è un “sistema di fatturazione medica”

Il “JMA Standard Receipt Software” (Nichi-Rece in breve), che sta al centro del progetto ORCA, è un sistema di fatturazione medica (in giapponese receipt computer o rececon). Un sistema di fatturazione medica calcola l’importo delle spese mediche dovute per quanto eseguito clinicamente e produce la ricevuta (richiesta di rimborso delle spese mediche) inviata agli enti di revisione e pagamento.

I sistemi di cartelle cliniche elettroniche e i sistemi di fatturazione medica hanno ruoli chiaramente separati.

Il soprannome “la cartella clinica elettronica ORCA” è nato perché molti prodotti di cartelle cliniche elettroniche sono stati costruiti attorno a un’architettura “la parte di fatturazione si integra con ORCA”. Come ingegnere, una volta fissata la distinzione — ORCA = il backbone del lato richieste rimborso, cartella clinica elettronica = il lato referto clinico — tutto ciò che segue si colloca molto più facilmente.

2. Cos’è il lavoro di ricevuta — il percorso più breve per capirlo come sistema

Il modo più rapido per capire che tipo di sistema sia un sistema di fatturazione medica è capire come fluiscono i ricavi in una struttura sanitaria. Nell’ambito dell’assistenza sanitaria assicurata giapponese, il paziente paga tipicamente solo il 10-30% al banco, e il resto viene richiesto mensilmente dalla struttura sanitaria agli enti di revisione e pagamento (il Social Insurance Medical Fee Payment Fund e le organizzazioni dell’assicurazione sanitaria nazionale). Quel documento di richiesta è la ricevuta.

Visto come sistema, un sistema di fatturazione medica è una macchina che gestisce il seguente ciclo mensile.

1. Giornaliero: l’accettazione verifica l’idoneità assicurativa, le procedure mediche (visite, esami, prescrizioni, trattamenti e così via) vengono inserite, e al paziente viene addebitato l’importo al banco calcolato automaticamente dal listino tariffario.
2. Mensile: un mese di procedure viene aggregato per paziente × combinazione assicurativa e trasformato in ricevute. Prima dell’invio, viene eseguito un controllo dati (coerenza tra diagnosi e prescrizioni, e così via) e il risultato viene inviato come dati elettronici di ricevuta (dati rece-den).
3. Il mese successivo e oltre: gestire le ricevute restituite dal processo di revisione (henrei, richieste respinte) e le ricevute ridotte in valutazione (satei), correggerle e rinviarle.

La cosa importante qui è che le regole per il calcolo dei punti tariffari cambiano con la revisione biennale delle tariffe mediche. Se il software non riesce a tenere il passo con le revisioni del master delle tariffe, dei prezzi dei farmaci e delle regole di calcolo, la struttura sanitaria non può richiedere correttamente. La difficoltà essenziale di un sistema di fatturazione medica non è l’interfaccia utente né la scala — è mantenere quella conformità normativa per decenni. Le cronologie delle revisioni scolpite nel sorgente di ORCA, discusse di seguito, sono proprio quel record.

3. L’architettura di sistema di una struttura sanitaria — dove si colloca ORCA

Disegnata, l’architettura tipica di una clinica pone ORCA (Nichi-Rece) vicino al centro dei sistemi interni.

flowchart LR
    subgraph clinic["All'interno della struttura sanitaria"]
        EMR["Cartella clinica elettronica<br/>referti clinici e ordini"]
        RSV["Sistema di accettazione e appuntamenti"]
        ONS["Terminale di verifica idoneità online"]
        ORCA["ORCA/Nichi-Rece<br/>sistema di fatturazione medica (richieste rimborso)"]
        EMR -->|"Nichi-Rece API (HTTP)"| ORCA
        RSV -->|"integrazione accettazione e appuntamenti"| ORCA
        ONS -->|"informazioni idoneità assicurativa"| ORCA
    end
    ORCA -->|"ricevute (richieste mensili)"| PAY["Enti di revisione e pagamento<br/>Payment Fund e organizzazioni NHI"]

Ci sono tre punti da notare.

• Nella maggior parte delle architetture, i dati master di pazienti e assicurazioni risiedono sul lato ORCA. Il sistema di cartelle cliniche elettroniche li legge e li aggiorna tramite API. Quale lato detenga l’assegnazione dei numeri di paziente è il primo punto di contesa in qualsiasi progetto di integrazione.
• Le procedure mediche (ciò che è stato fatto) vengono inviate dal sistema di cartelle cliniche elettroniche a ORCA, e ORCA esegue il calcolo dei punti tariffari che alimenta la fatturazione e le richieste. Il sistema di cartelle cliniche elettroniche descrive l’assistenza nel “linguaggio degli ordini” e ORCA nel “linguaggio dei punti tariffari”, pertanto la traduzione tra i due (mappatura dei codici procedura) è il problema pratico centrale dell’integrazione.
• L’invio mensile della ricevuta è compito di ORCA. In altre parole, il ricavo di una struttura sanitaria viene richiesto attraverso ORCA. Gli errori di integrazione emergono non come referti clinici mancanti ma come importi di richiesta errati — quella tensione è caratteristica di questo dominio.

4. La storia e la licenza del progetto ORCA

ORCA è un progetto della Japan Medical Association (JMA). La “JMA IT Declaration” del novembre 2001 ha stabilito la politica secondo cui il software sviluppato dalla Japan Medical Association sarebbe stato rilasciato come open source, e Nichi-Rece è stato sviluppato come elemento centrale di quella politica. L’uso in ambienti clinici è iniziato nel 2002, e lo sviluppo è proseguito per oltre vent’anni.

Ciò che colpisce dal punto di vista di un ingegnere è che il codice sorgente di un sistema aziendale è stato pubblicato continuativamente per più di vent’anni.

• La licenza è la JMA OpenSource License version 1.0, inclusa nel sorgente. Non è GPL ma un accordo proprio della JMA: l’uso del programma (inclusa la riproduzione, l’adattamento, la distribuzione e la trasmissione al pubblico) è concesso in modo non esclusivo e gratuito, e la distribuzione di una versione modificata impone gli stessi termini — una struttura simile al copyleft. La legge applicabile è quella giapponese.
• Un tempo esisteva un repository CVS pubblico, ma è stato reso privato con il lancio dell’edizione commerciale. L’accordo attuale è che il primo di ogni mese viene pubblicato come tarball il sorgente relativo al primo del mese precedente. Vengono pubblicati tre componenti — il prodotto principale, il supporto alle spese pubbliche regionali e i moduli pubblici — e le serie 5.0, 5.1 e 5.2 sono pubblicate in parallelo.
• Anche la struttura di sviluppo e distribuzione è particolare. Leggendo le cronologie delle revisioni nel sorgente si trovano i nomi degli ingegneri di NACL (il contraente di sviluppo) nei primi anni, che a partire circa dal 2022 passano a commit a nome di ORCAMO (la Japan Medical Association ORCA Management Organization). I servizi periferici (supporto, packaging, manuali e così via) sono forniti dall’ORCA Management Organization come edizione commerciale, mentre il rollout e la manutenzione sono gestiti da fornitori di supporto certificati in tutto il paese — un modello di divisione del lavoro.

ORCA è quindi software “open source, ma non sviluppo comunitario alla GitHub”. Puoi leggere il sorgente, puoi farne un fork, ma il mainline è guidato da un unico ente in modo simile a un vendor. Considerato un dominio come quello sanitario, in cui gli errori sono inaccettabili e la conformità normativa è obbligatoria, ritengo che sia una posizione ragionevole.

5. Lo stack tecnologico — contando effettivamente i quattro milioni di righe di COBOL

INSTALL.ja nel sorgente pubblicato della serie 5.2 elenca MONTSUQI (panda), OpenCOBOL, PostgreSQL, MONPE e altri come software richiesti. Riassunto, l’architettura è la seguente.

Le parole da sole non trasmettono la scala, quindi ecco i risultati del conteggio effettivo dello snapshot della serie 5.2 (circa 8.200 file e 237 MB una volta estratto).

I nomi delle tabelle del database sono sorprendentemente semplici, e una volta presa confidenza con la lettura il business emerge direttamente. Ad esempio tbl_ptinf (dati master del paziente), tbl_ptbyomei (diagnosi del paziente), tbl_uketuke (accettazione), tbl_jyurrk (storia dei trattamenti), tbl_tensu (master dei punti tariffari), tbl_syskanri (gestione sistema). La divisione dei ruoli dalla Sezione 1 — paziente, assicurazione, diagnosi, procedura, punti tariffari — è implementata direttamente come struttura delle tabelle.

La pietra angolare dell’architettura è MONTSUQI. Internamente, Nichi-Rece è un sistema classico di elaborazione centralizzata: il client Java (monsiaj) riceve le definizioni di schermata dal server e le renderizza, l’input viene elaborato dai programmi COBOL sul server, e questi leggono e scrivono su PostgreSQL. Quale schermata corrisponda a quale programma COBOL è dichiarato nei file di definizione LD nella directory lddef/.

flowchart LR
    CL["monsiaj<br/>client Java"] -->|"interazione schermata"| MW["MONTSUQI<br/>application server"]
    API["Sistema integrato<br/>es. cartella clinica elettronica"] -->|"Nichi-Rece API (HTTP)"| MW
    MW -->|"instradato dalle definizioni in lddef/*.ld"| AP["Programmi di business<br/>circa 1.750 sorgenti COBOL"]
    AP --> DB[("PostgreSQL<br/>285 tabelle")]

Ciò che è interessante è che l’instradamento delle schermate e delle API vive nello stesso file di definizione LD. In altre parole, la Nichi-Rece API non è un server separato aggiunto in seguito; è implementata come “punto di ingresso che conversa in XML invece che tramite schermata”, aggiunto sopra la stessa piattaforma di programmi di business delle schermate interattive. I dettagli di questa progettazione sono trattati nell’articolo di approfondimento.

La combinazione “COBOL + middleware su misura + PostgreSQL” sembra molto lontana dalle sensibilità dello sviluppo web moderno. Eppure l’intestazione di un singolo programma COBOL riporta in commenti una cronologia delle revisioni che risale al 2002, fino a lavori normativi recenti come le prescrizioni elettroniche (2022) e la verifica dell’idoneità della scheda assicurativa My Number (2024) — si può leggere il fatto che lo stesso codebase ha tenuto il passo con le revisioni per oltre vent’anni. Questa architettura è anche il risultato dell’ottimizzazione per “essere matura e continuare a girare”.

6. Navigare nell’albero dei sorgenti — cosa si trova dove

Come mappa per leggere effettivamente il sorgente, ecco le principali directory di primo livello.

Un avvertimento pratico. Il sorgente è codificato in EUC-JP (il documento di licenza è ISO-2022-JP). Aprirlo in un editor moderno dà mojibake, quindi finisci per leggerlo tramite iconv -f EUC-JP -t UTF-8. È una sorta di capsula del tempo in cui lo standard dell’ambiente Linux del 2002 è stato conservato così com’era.

7. Punti di ingresso per l’integrazione — Nichi-Rece API, PushAPI e CLAIM

Per un ingegnere su un sistema esterno che tocca ORCA, ci sono stati effettivamente tre punti di ingresso.

1. La Nichi-Rece API — la raccomandazione attuale. Il sistema integrato invia richieste HTTP per recuperare informazioni sui pazienti, registrare l’accettazione, registrare procedure mediche e così via. Le operazioni di lettura sono fondamentalmente GET o POST + XML; le operazioni di scrittura sono POST + XML. La specifica API è pubblicata sul sito ufficiale.
2. PushAPI — un meccanismo per notificare al sistema integrato gli eventi che si verificano sul lato Nichi-Rece (istruzioni di stampa modulo, ad esempio). Consente di costruire una coordinazione a livello di schermata guidata da eventi anziché tramite polling.
3. CLAIM — a lungo usato come protocollo standard per lo scambio di informazioni mediche, ma il supporto è terminato nel marzo 2026. L’elaborazione CLAIM è ancora presente nel sorgente, ma le integrazioni CLAIM esistenti sono ormai basate sulla migrazione alle API.

In sintesi, se state progettando un’integrazione ORCA ora, la Nichi-Rece API è l’unica scelta. E come notato sopra, poiché l’API è implementata sulla stessa piattaforma di programmi di business COBOL delle schermate interattive, quando “il comportamento dell’API non è chiaro” si può scendere nel sorgente e verificare. La procedura concreta per cogliere l’intera superficie API dal sorgente (inclusi endpoint che non appaiono nell’elenco ufficiale) è spiegata nell’articolo di approfondimento.

8. Cosa cambia con il passaggio a WebORCA

ORCA è attualmente in un periodo di transizione verso “WebORCA”. In termini ampi esistono due forme di distribuzione.

• WebORCA cloud edition — utilizzo di Nichi-Rece come servizio cloud fornito dall’ORCA Management Organization. La struttura sanitaria è sollevata dall’amministrazione del server.
• WebORCA on-premises edition — installato su un server interno (Ubuntu).

La cosa importante è che entrambi contengono lo stesso Nichi-Rece. Il software in esecuzione non diventa un prodotto diverso a seconda della forma di distribuzione; l’insieme di API e il loro comportamento sono fondamentalmente comuni ad entrambi. Le differenze di cui un ingegnere integratore deve essere consapevole sono concentrate non nell’implementazione ma attorno alla connettività.

• Differenze di punto di ingresso come il cloud edition che prefissa i percorsi delle richieste API con /api, e le impostazioni di connessione e autenticazione differiscono per forma di distribuzione. La specifica API in sé è comune.
• Con la cloud edition, i sistemi integrati interni chiamano l’API attraverso internet, quindi il routing di rete e il comportamento in modalità degradata durante le interruzioni richiedono più attenzione progettuale rispetto a un’architettura on-premises.
• La pubblicazione mensile del sorgente include anche le definizioni WebORCA (ad esempio i file .db.weborca sotto record/). Questa è la prova che un unico albero di sorgente supporta entrambe le forme di distribuzione, e significa che le conoscenze acquisite leggendo il sorgente si applicano anche all’edizione cloud. Notare che alcune definizioni .weborca regolano limiti come quelli degli array di risposta, quindi quando si controllano i dettagli, verificare se esiste una definizione specifica per WebORCA.

9. Riassunto — i punti che gli ingegneri dovrebbero cogliere

• ORCA (Nichi-Rece) non è un sistema di cartelle cliniche elettroniche ma un sistema di fatturazione medica. Detiene il backbone dei dati del lato richieste rimborso — paziente, assicurazione, diagnosi, procedura, punti tariffari — e attraverso di esso viene richiesto il ricavo di una struttura sanitaria.
• La difficoltà essenziale di un sistema di fatturazione medica è mantenere la conformità con la revisione biennale delle tariffe mediche per decenni. Le cronologie delle revisioni nel sorgente di ORCA sono il documento storico di esattamente questo.
• È un sistema aziendale open source in esecuzione dalla JMA IT Declaration del 2001, con il sorgente pubblicato mensilmente come tarball. La licenza non è GPL ma la JMA OpenSource License.
• All’interno è 1.754 sorgenti COBOL per un totale di circa 4,06 milioni di righe, più MONTSUQI, più 285 tabelle PostgreSQL (misurato sulla serie 5.2). Schermate e API sono instradate attraverso le stesse definizioni LD in un’architettura di elaborazione centralizzata.
• La Nichi-Rece API è l’attuale punto di ingresso per l’integrazione esterna. CLAIM ha raggiunto la fine del supporto nel marzo 2026. La migrazione a WebORCA è in corso, ma sia l’edizione cloud che quella on-premises contengono lo stesso Nichi-Rece, quindi le conoscenze acquisite dal sorgente pubblicato si applicano a entrambe.

La prossima volta leggeremo effettivamente questo sorgente pubblicato e spiegheremo come cogliere l’intera immagine della Nichi-Rece API dal sorgente — quale URL è gestito da quale programma COBOL e quali endpoint mancano dall’elenco ufficiale — con una tabella di mappatura di tutti i 137 endpoint.

10. Riferimenti

• What Is ORCA - ORCA Project
• Technical Information - JMA Standard Receipt Software - ORCA Project (pubblicazioni del codice sorgente, specifiche API, documenti di definizione delle tabelle)
• JMA Standard Receipt Software API - ORCA Project
• JMA Standard Receipt Software “ORCA” - Japan Medical Association ORCA Management Organization
• About the Commercial Edition of the JMA Standard Receipt Software - Japan Medical Association ORCA Management Organization
• WebORCA Cloud Edition - ORCA Project
• Codice sorgente della serie 5.2 di Nichi-Receive (snapshot pubblicato luglio 2026) INSTALL.ja / doc/license.html / lddef/orcadb.inc e altri — tutte le cifre misurate in questo articolo si basano su questo snapshot

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

ORCA è un sistema di cartelle cliniche elettroniche?

No. Il JMA Standard Receipt Software (Nichi-Rece), che sta al centro del progetto ORCA, è un sistema di fatturazione medica responsabile delle richieste di rimborso delle spese mediche (ricevute). Il sistema di cartelle cliniche elettroniche in cui vengono scritti i referti clinici è un software separato, e la maggior parte delle strutture sanitarie utilizza un sistema di cartelle cliniche elettroniche integrato con ORCA tramite API. L'espressione "la cartella clinica elettronica ORCA" è meglio intesa come un soprannome nato dal fatto che ORCA viene spesso usato insieme a uno di questi sistemi.

Chiunque può leggere il codice sorgente di ORCA (Nichi-Rece)?

Sì. Il codice sorgente del JMA Standard Receipt Software è pubblicato sotto la JMA OpenSource License, e il primo di ogni mese viene reso disponibile uno snapshot relativo al primo del mese precedente sotto forma di tarball. Il vecchio repository CVS è stato reso privato con il lancio dell'edizione commerciale, ma la pubblicazione del sorgente è proseguita.

Con quali tecnologie è realizzato ORCA?

Il server gira su Linux, e la maggior parte della logica di business è scritta in COBOL. Il database è PostgreSQL, la piattaforma di esecuzione dei programmi di business è un middleware open source chiamato MONTSUQI (panda), e il client è tipicamente monsiaj, scritto in Java. Contando il sorgente della serie 5.2, il COBOL da solo conta circa 1.750 programmi e oltre quattro milioni di righe, con più di 280 tabelle di database.

Come si integra un sistema di cartelle cliniche elettroniche con ORCA?

La raccomandazione attuale è la Nichi-Rece API. Il sistema integrato — ad esempio la cartella clinica elettronica — invia richieste HTTP per recuperare informazioni sui pazienti, registrare procedure mediche e così via. Esiste anche una PushAPI attraverso cui Nichi-Rece notifica eventi all'esterno. L'integrazione tramite CLAIM (lo standard di scambio di informazioni mediche), usata per molti anni, ha raggiunto la fine del supporto nel marzo 2026, pertanto qualsiasi nuova integrazione dovrebbe essere progettata assumendo l'uso delle API.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.