ORCA (Nichirese) n'est pas un dossier médical électronique — Le logiciel de facturation médicale et l'architecture des systèmes de santé, vus par un ingénieur

Avez-vous déjà entendu l’expression « l’ORCA du dossier médical électronique » ? C’est un nom qui revient immanquablement dès qu’on touche à un projet de système pour établissement de santé, mais cette façon de le présenter recèle en réalité un malentendu. ORCA (abrégé Nichirese, du japonais 日医標準レセプトソフト, littéralement « logiciel standard de facturation des soins de l’Association médicale japonaise ») n’est pas un dossier médical électronique.

Cet article s’adresse aux ingénieurs qui abordent pour la première fois un projet d’IT médicale, et vise à répondre aux questions suivantes.

• Qu’est-ce qu’ORCA, et où se situe-t-il dans l’architecture système d’un établissement de santé ?
• Que fait concrètement, du point de vue système, le « traitement des factures de soins » dont s’occupe un logiciel de facturation médicale ?
• Avec quelles technologies est-il construit, et que contient le code source publié ?
• Qu’est-ce qui change avec la migration vers WebORCA, et que doit retenir la partie qui s’y connecte ?

Toute la description s’appuie sur des sources primaires publiques. Ce qui concerne le code source provient d’un téléchargement et d’une vérification réelle du code source 5.2 de Nichirese (instantané publié le 1er juillet 2026, version 5.2.0 selon le fichier VERSION), publié officiellement.

Sommaire

1. La conclusion, d’abord — ORCA est un « logiciel de facturation médicale »
2. Qu’est-ce que le traitement des factures de soins ? — Comprendre vite, du point de vue système
3. Le schéma du système d’un établissement de santé — où se situe ORCA ?
4. Histoire et licence du projet ORCA
5. La pile technique — compter réellement le contenu des 4 millions de lignes de COBOL
6. Parcourir l’arborescence des sources — ce qui se trouve où
7. Les portes d’entrée de l’intégration — l’API Nichirese, PushAPI et CLAIM
8. Ce qui change avec la migration vers WebORCA
9. Conclusion — les points à retenir pour un ingénieur
10. Références

1. La conclusion, d’abord — ORCA est un « logiciel de facturation médicale »

Au cœur du projet ORCA se trouve le « 日医標準レセプトソフト » (abrégé Nichirese), qui est un logiciel de facturation médicale (littéralement, une machine à établir les factures de soins). Un tel logiciel calcule la rémunération des soins à partir du contenu des actes médicaux et établit la facture de soins (relevé détaillé de rémunération des actes médicaux) soumise aux organismes de contrôle et de paiement.

Le dossier médical électronique et le logiciel de facturation médicale ont des rôles clairement distincts.

Le surnom « l’ORCA du dossier médical électronique » est né du fait que de nombreux logiciels de dossier médical électronique adoptent une architecture où « la partie facturation est confiée à ORCA en connexion ». Pour un ingénieur, retenir dès le départ la distinction ORCA = socle du système de facturation, dossier médical électronique = système des dossiers de soins permet ensuite de clarifier tout le reste du propos.

2. Qu’est-ce que le traitement des factures de soins ? — Comprendre vite, du point de vue système

Pour comprendre à quoi sert un logiciel de facturation médicale, le plus rapide est de connaître le flux de revenus d’un établissement de santé. Dans le système d’assurance maladie japonais, le patient ne règle en principe au guichet qu’une part de 10 à 30 % du coût ; le reste est facturé chaque mois par l’établissement de santé aux organismes de contrôle et de paiement (le Fonds de paiement des honoraires de l’assurance sociale et les fédérations d’assurance maladie nationale). Cette facture, c’est la reseputo.

D’un point de vue système, un logiciel de facturation médicale fait tourner le cycle de traitement par lots mensuel suivant.

1. Au quotidien : à l’accueil, on vérifie les droits d’assurance, on saisit les actes médicaux (consultation, examens, prescriptions, soins…), et on encaisse le montant à la charge du patient, calculé automatiquement d’après le barème de points.
2. Chaque mois : les actes médicaux du mois sont agrégés par couple patient × assurance pour établir la facture de soins. Avant soumission, un contrôle des données est effectué (cohérence entre diagnostics et prescriptions, etc.), puis la facture est soumise sous forme électronique (données de télétransmission).
3. Le mois suivant et après : on traite les dossiers « renvoyés » lors du contrôle ou ceux ayant subi une « réduction tarifaire », on les corrige, et on refacture.

Ce qui compte ici, c’est que les règles de calcul des points changent tous les deux ans, à chaque révision du barème de rémunération des soins. Si le logiciel ne parvient pas à suivre les révisions du référentiel de points, du prix des médicaments et des règles de calcul, l’établissement de santé ne peut plus facturer correctement. La difficulté fondamentale d’un logiciel de facturation médicale ne tient ni à l’interface ni à la montée en charge, mais au fait de poursuivre ce suivi réglementaire pendant des décennies. L’historique des modifications gravé dans le code source d’ORCA, évoqué plus loin, en est précisément la trace.

3. Le schéma du système d’un établissement de santé — où se situe ORCA ?

Si l’on schématise l’architecture typique d’une clinique, ORCA (Nichirese) occupe une position proche du hub du système interne.

flowchart LR
    subgraph clinic["Au sein de l'établissement de santé"]
        EMR["Dossier médical électronique<br/>Dossiers de soins, prescriptions"]
        RSV["Système d'accueil et de rendez-vous"]
        ONS["Terminal de vérification des droits en ligne"]
        ORCA["ORCA/Nichirese<br/>Logiciel de facturation (facturation des soins)"]
        EMR -->|"API Nichirese (HTTP)"| ORCA
        RSV -->|"Intégration accueil/rendez-vous"| ORCA
        ONS -->|"Informations sur les droits d'assurance"| ORCA
    end
    ORCA -->|"Facture de soins (facturation mensuelle)"| PAY["Organismes de contrôle et de paiement<br/>Fonds de paiement, fédérations d'assurance maladie"]

Trois points sont à retenir.

• Dans de nombreuses configurations, c’est ORCA qui détient le référentiel des informations patient et d’assurance. Le dossier médical électronique les consulte et les met à jour via l’API. Savoir qui détient la numérotation des patients devient le premier point à trancher dans la conception de l’intégration.
• Les actes médicaux (ce qui a été fait) sont envoyés du dossier médical électronique vers ORCA, qui effectue le calcul des points et l’achemine vers l’encaissement et la facturation. Le dossier médical électronique décrit les soins dans le « langage des prescriptions », ORCA dans le « langage des points » : cette conversion (la correspondance des codes d’actes médicaux) constitue le principal défi pratique de l’intégration.
• La soumission mensuelle des factures de soins relève d’ORCA. Autrement dit, le chiffre d’affaires de l’établissement de santé est facturé en passant par ORCA. Une erreur d’intégration ne se traduit pas par un dossier de soins manquant mais par une erreur de montant facturé — c’est la tension propre à ce domaine.

4. Histoire et licence du projet ORCA

ORCA est un projet de l’Association médicale japonaise (日本医師会, le Nichii). En novembre 2001, la « déclaration d’informatisation du Nichii » a posé le principe de publier en open source les logiciels développés par l’Association médicale japonaise, et Nichirese en a été le développement central. Son utilisation sur le terrain médical a commencé en 2002, et le développement se poursuit depuis plus de vingt ans.

Ce qui mérite d’être souligné du point de vue d’un ingénieur, c’est que le code source d’un système métier reste publié depuis plus de vingt ans.

• La licence est le contrat de licence open source du Nichii (日医オープンソース使用許諾契約, JMA OpenSource License version 1.0), inclus avec les sources. Ce n’est pas une GPL, mais un contrat propre au Nichii : l’utilisation du programme (y compris la reproduction, l’adaptation, la distribution et la communication au public) est accordée à titre non exclusif et gratuit, avec l’obligation d’imposer les mêmes conditions lors de la distribution d’une version modifiée — une structure de type copyleft. Le droit applicable est le droit japonais.
• Un dépôt CVS était autrefois publié, mais il est devenu privé avec le lancement de la version commerciale ; désormais, les sources sont publiées sous forme de tarball le 1er de chaque mois, correspondant à l’état du 1er du mois précédent. Trois composants sont publiés — le logiciel principal, les subventions régionales et les formulaires publics —, avec les branches 5.0, 5.1 et 5.2 publiées en parallèle.
• L’organisation du développement et de la diffusion est elle aussi particulière. En lisant l’historique des modifications du code source, on voit qu’au départ apparaissent les noms d’ingénieurs de NACL (le sous-traitant du développement), puis qu’à partir de 2022 environ, les commits passent au nom d’ORCAMO (l’Organisation de gestion ORCA de l’Association médicale japonaise). Les services annexes (support, packaging, manuels, etc.) sont fournis en version commerciale par l’Organisation de gestion ORCA, tandis que l’installation et la maintenance sont assurées par des prestataires de support agréés répartis dans tout le pays — un modèle de répartition des rôles.

Autrement dit, ORCA est un logiciel « open source, mais pas développé par une communauté à la GitHub ». On peut lire les sources, on peut même les forker, mais le développement principal est mené par un acteur unique, à la manière d’un éditeur — et compte tenu du domaine médical, où l’erreur n’est pas permise et le suivi réglementaire est obligatoire, c’est, je pense, un compromis raisonnable.

5. La pile technique — compter réellement le contenu des 4 millions de lignes de COBOL

À partir de ce chapitre, les noms propres se multiplient d’un coup ; voici donc d’abord un tableau de vocabulaire. Gardez-le sous les yeux pour la lecture des chapitres suivants.

Le fichier INSTALL.ja des sources 5.2 publiées liste, parmi les logiciels requis, MONTSUQI (panda), OpenCOBOL, PostgreSQL, MONPE, entre autres. Pour résumer l’architecture :

Les mots seuls ne donnent pas une idée de l’échelle réelle ; voici donc les résultats d’un comptage effectué sur l’instantané 5.2 (environ 8 200 fichiers, 237 Mo une fois décompressé).

Les noms des tables de la base de données sont directs, et une fois qu’on s’y est habitué, le métier devient lisible tel quel. La nomenclature mélange abréviations anglaises et romanisation du japonais ; en repassant mentalement la partie japonaise en kanjis, le sens devient clair. En voici les principales :

La répartition des rôles vue au chapitre 1 — patient, assurance, diagnostic, acte médical, points — se retrouve donc telle quelle dans la structure des tables. Le document de définition des tables est publié sur le site officiel ; en cas de doute sur la lecture d’un nom, on peut y vérifier la dénomination exacte.

MONTSUQI est la clé de voûte de l’architecture. À l’intérieur de Nichirese, le client Java (monsiaj) reçoit du serveur les définitions d’écran et les affiche, tandis que la saisie est traitée côté serveur par des programmes COBOL qui lisent et écrivent dans PostgreSQL — une architecture centralisée classique. La correspondance entre chaque écran et le programme COBOL qui le traite est déclarée dans les fichiers de définition LD du répertoire lddef/.

flowchart LR
    CL["monsiaj<br/>Client Java"] -->|"Opérations à l'écran"| MW["MONTSUQI<br/>Serveur d'applications"]
    API["Système intégré<br/>Dossier médical électronique, etc."] -->|"API Nichirese (HTTP)"| MW
    MW -->|"Répartition selon les définitions lddef/*.ld"| AP["Programmes métier<br/>Environ 1 750 programmes COBOL"]
    AP --> DB[("PostgreSQL<br/>285 tables")]

Ce qui est intéressant, c’est que le dispatching des écrans et celui de l’API cohabitent dans le même fichier de définition LD. Autrement dit, l’API Nichirese n’est pas un serveur séparé ajouté après coup : elle est implémentée comme « une porte d’entrée qui dialogue en XML à la place de l’écran », posée sur la même plateforme de programmes métier que les écrans interactifs. Les détails de cette conception seront traités dans un article de suite.

Une architecture « COBOL + middleware dédié + PostgreSQL » paraît bien éloignée de la sensibilité du développement web moderne. Pourtant, l’en-tête d’un seul programme COBOL porte, en commentaire, un historique de modifications remontant à 2002, jusqu’aux adaptations réglementaires les plus récentes comme l’ordonnance électronique (2022) ou la vérification des droits via la carte d’assurance maladie numérique (2024) : on y lit que la même base de code suit les révisions depuis plus de vingt ans. Cette architecture est aussi le résultat d’une optimisation vers « continuer à fonctionner en restant éprouvée ».

6. Parcourir l’arborescence des sources — ce qui se trouve où

Voici, comme carte pour la lecture réelle des sources, un aperçu des principaux répertoires de premier niveau.

Une remarque pratique : le code source est encodé en EUC-JP (le document de licence, en ISO-2022-JP). L’ouvrir avec un éditeur moderne produit des caractères illisibles ; il faut donc le lire en passant par iconv -f EUC-JP -t UTF-8. C’est une sorte de capsule temporelle qui a conservé tel quel le standard des environnements Linux de 2002.

7. Les portes d’entrée de l’intégration — l’API Nichirese, PushAPI et CLAIM

Pour un ingénieur d’un système externe qui touche à ORCA, il existe concrètement trois portes d’entrée.

1. L’API Nichirese — la recommandation actuelle. Le système intégré envoie des requêtes HTTP pour récupérer les informations patient, gérer l’accueil, enregistrer des actes médicaux, etc. Les opérations de lecture utilisent généralement GET ou POST + XML, les opérations de mise à jour POST + XML. La spécification de l’API est publiée sur le site officiel.
2. PushAPI — un mécanisme qui notifie au système intégré les événements survenus côté Nichirese (une instruction d’impression de formulaire, par exemple). Il permet de construire une synchronisation d’écran pilotée par événements plutôt que par sondage (polling).
3. CLAIM — longtemps utilisé comme protocole standard d’échange d’informations médicales, mais son support a pris fin en mars 2026. Le traitement lié à CLAIM subsiste encore dans les sources, mais les intégrations CLAIM existantes doivent désormais migrer vers l’API.

Autrement dit, pour concevoir dès maintenant une intégration avec ORCA, l’API Nichirese s’impose comme seul choix. Et comme évoqué plus haut, l’API étant implémentée sur la même plateforme de programmes métier COBOL que les écrans interactifs, il est possible, quand « le comportement de l’API reste incompris », de descendre jusqu’aux sources pour vérifier. La démarche concrète pour appréhender, à partir des sources, la vue d’ensemble de l’API (y compris les points de terminaison absents de la liste officielle) sera présentée dans l’article de suite.

8. Ce qui change avec la migration vers WebORCA

ORCA traverse actuellement une période de migration vers « WebORCA ». Il existe globalement deux formes de mise à disposition.

• WebORCA version cloud — une forme où Nichirese est utilisé comme service cloud fourni par l’Organisation de gestion ORCA. L’établissement de santé est déchargé de la gestion des serveurs. L’inscription passe par un prestataire de support agréé, et les instructions officielles estiment à environ trois semaines le délai entre l’inscription et le démarrage du service. L’établissement de santé n’héberge aucun serveur sur place, utilise l’application depuis un navigateur, et les mises à jour de programme liées aux révisions tarifaires sont effectuées côté cloud, de façon groupée. La tarification est un abonnement mensuel par établissement.
• WebORCA version sur site (on-premise) — une forme installée sur un serveur interne (Ubuntu). L’environnement actuellement fourni est Nichirese Ver5.2.0 sur Ubuntu 22.04 (jammy).

Concernant le calendrier de la migration, deux points sont à retenir.

Le premier, c’est qu’une voie de migration officielle est prévue. Le projet ORCA publie un « guide de migration de l’environnement d’exploitation de Nichirese », qui précise explicitement la procédure de migration depuis Nichirese 5.1.0 / 5.2.0 en configuration classique (version MONTSUQI), fonctionnant sous Ubuntu 16.04 / 18.04 / 20.04, vers WebORCA en version sur site (Ubuntu 22.04 + 5.2.0). Le sens inverse — migrer vers un OS ou une version de Nichirese inférieurs — n’est pas possible.

Le second, c’est qu’il n’existe pas de date limite uniforme publiée du type « tous les établissements de santé doivent passer à WebORCA avant telle date ». Ce qui joue réellement le rôle de délai en pratique, ce sont les dates de fin de support, fixées pour chaque combinaison d’OS et de paquet Nichirese ; elles sont publiées sous forme de « calendrier de support des paquets Nichirese et des OS », et les versions dont la fin approche sont annoncées individuellement. Pour qui développe un système d’intégration, la façon pratique d’appréhender ce calendrier n’est pas de se demander « quand aura lieu la migration vers WebORCA », mais de vérifier la version d’Ubuntu et de Nichirese utilisée par l’établissement de santé partenaire, ainsi que sa date de fin de support.

Ce qui compte, c’est que dans les deux cas, le contenu est le même Nichirese. Le logiciel qui tourne ne devient pas un produit différent selon la forme de mise à disposition, et les types d’API comme leur comportement restent fondamentalement communs. Les différences que l’ingénieur qui intègre doit retenir se concentrent non pas sur l’implémentation, mais sur la connexion.

• Le chemin de requête de l’API porte un préfixe /api en version cloud ; les informations de connexion et la configuration d’authentification diffèrent selon la forme de mise à disposition — ce sont des différences à l’entrée. La spécification de l’API elle-même reste commune.
• En version cloud, comme le système intégré interne appelle l’API à travers Internet, la conception du chemin réseau et du comportement dégradé en cas de panne demande davantage de réflexion qu’en configuration sur site.
• Les sources publiées chaque mois contiennent telles quelles les définitions propres à WebORCA (par exemple les fichiers .db.weborca sous record/). C’est la preuve que la même arborescence de sources alimente les deux formes, et que les connaissances tirées de la lecture des sources valent aussi pour la version cloud. Notez que dans la version .weborca, certaines définitions — comme la limite de taille des tableaux dans les réponses — sont ajustées : en vérifiant les détails, pensez aussi à regarder si une définition spécifique à WebORCA existe.

9. Conclusion — les points à retenir pour un ingénieur

• ORCA (Nichirese) n’est pas un dossier médical électronique mais un logiciel de facturation médicale. Il détient le socle des données de facturation — patient, assurance, diagnostic, acte médical, points — et le chiffre d’affaires de l’établissement de santé est facturé en passant par lui.
• La difficulté fondamentale d’un logiciel de facturation médicale est de poursuivre pendant des décennies le suivi des révisions tarifaires biennales. L’historique des modifications du code source d’ORCA en constitue la trace authentique.
• C’est un système métier open source qui perdure depuis la déclaration d’informatisation du Nichii de 2001, dont les sources sont publiées chaque mois sous forme de tarball. La licence n’est pas une GPL mais le contrat de licence open source du Nichii.
• Le contenu se compose de 1 754 fichiers COBOL, environ 4,06 millions de lignes, plus MONTSUQI et 285 tables PostgreSQL (mesures sur la branche 5.2). C’est une architecture centralisée où écrans et API sont tous deux dispatchés par les mêmes définitions LD.
• Pour l’intégration externe, l’API Nichirese est aujourd’hui la porte d’entrée. Le support de CLAIM a pris fin en mars 2026. La migration vers WebORCA est en cours, mais la version cloud comme la version sur site contiennent le même Nichirese, et les connaissances tirées des sources publiques valent pour les deux.

La prochaine fois, nous lirons réellement ce code source publié pour présenter, avec un tableau de correspondance pour les 137 points de terminaison, la méthode permettant d’appréhender depuis les sources la vue d’ensemble de l’API Nichirese (quelle URL est traitée par quel programme COBOL, et quels points de terminaison sont absents de la liste officielle).

10. Références

• Qu’est-ce qu’ORCA - ORCA Project
• Informations techniques - Nichirese - ORCA Project (publication du code source, spécification de l’API, document de définition des tables)
• API du logiciel standard de facturation des soins de l’Association médicale japonaise - ORCA Project
• Le logiciel standard de facturation des soins « ORCA » - Organisation de gestion ORCA de l’Association médicale japonaise
• À propos de la version commerciale du logiciel standard de facturation des soins - Organisation de gestion ORCA de l’Association médicale japonaise
• WebORCA version cloud - ORCA Project
• Logiciel standard de facturation des soins [WebORCA version cloud] - Organisation de gestion ORCA de l’Association médicale japonaise (parcours d’inscription, formes de mise à disposition, tarifs)
• Guide de migration de l’environnement d’exploitation de Nichirese - ORCA Project (cible et procédure de migration vers WebORCA version sur site)
• Aux utilisateurs actuels du logiciel standard de facturation des soins - ORCA Project (source de publication du « calendrier de support des paquets Nichirese et des OS »)
• Code source 5.2 de Nichirese (instantané publié en juillet 2026) INSTALL.ja / doc/license.html / lddef/orcadb.inc, entre autres — toutes les valeurs mesurées dans le corps de l’article s’appuient sur cet instantané

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

ORCA est-il un dossier médical électronique ?

Non. Le logiciel standard de facturation des soins de l'Association médicale japonaise (Nichirese), au cœur du projet ORCA, est un logiciel de facturation médicale qui s'occupe de la facturation des soins (la reseputo). Le dossier médical électronique, qui sert à rédiger les dossiers de soins, est un logiciel distinct ; dans de nombreux établissements de santé, le dossier médical électronique et ORCA sont utilisés en les connectant via une API. L'expression « l'ORCA du dossier médical électronique » est plus justement comprise comme un surnom né du fait qu'ORCA est souvent utilisé en connexion avec un dossier médical électronique.

Le code source d'ORCA (Nichirese) est-il accessible à tout le monde ?

Oui. Le code source du logiciel standard de facturation des soins de l'Association médicale japonaise est publié sous le contrat de licence open source du Nichii (JMA OpenSource License), et un instantané de l'état du 1er du mois précédent peut être téléchargé sous forme de tarball le 1er de chaque mois. L'ancien dépôt CVS est devenu privé avec le lancement de la version commerciale, mais la publication des sources elle-même se poursuit.

Avec quelles technologies ORCA est-il construit ?

Le serveur fonctionne sous Linux, et l'essentiel de la logique métier est écrit en COBOL. La base de données est PostgreSQL, la plateforme d'exécution des programmes métier utilise le middleware open source MONTSUQI (panda), et le client s'appuie notamment sur monsiaj, écrit en Java. En comptant les sources de la branche 5.2, on trouve, rien que pour le COBOL, environ 1 750 fichiers et plus de 4 millions de lignes, et une base de données de plus de 280 tables.

Comment le dossier médical électronique et ORCA s'intègrent-ils ?

La recommandation actuelle est l'API Nichirese. Un système intégré comme un dossier médical électronique envoie des requêtes HTTP pour récupérer les informations patient, enregistrer des actes médicaux, etc. Il existe aussi PushAPI, qui notifie des événements depuis Nichirese. L'intégration via CLAIM (le protocole d'échange d'informations médicales), utilisée de longue date, a vu son support prendre fin en mars 2026 ; il est donc raisonnable de concevoir toute nouvelle intégration en partant du principe de l'API.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.