Que se passe-t-il quand on présente sa carte Mynumber-assurance maladie ? Lire, depuis le code source d'ORCA, l'articulation entre la confirmation d'éligibilité en ligne et le système de facturation des soins

Quand on présente la carte Mynumber-assurance maladie au lecteur à l’accueil d’une clinique, la vérification d’identité et la confirmation des droits d’assurance se terminent en quelques secondes. Mais derrière ces quelques secondes, quels systèmes s’activent, et dans quel ordre ? En particulier, peu d’ingénieurs, sans doute, sauraient expliquer comment les informations d’éligibilité parviennent jusqu’au système de facturation qui porte in fine la responsabilité de la demande de remboursement.

Deux articles plus tôt, nous avions expliqué qu’ORCA (le logiciel de facturation standard de l’Association médicale japonaise) est un système de facturation des soins ; la fois précédente, nous avions montré comment saisir depuis le code source la vue d’ensemble de l’API de Nichi-Rece. Cette fois, en guise d’application, nous disséquons la confirmation d’éligibilité en ligne (couramment abrégée « Onshi ») du point de vue du système de facturation.

• Le flux complet, depuis la présentation de la carte Mynumber-assurance maladie jusqu’à l’enregistrement des informations d’éligibilité dans le système de facturation
• Le contenu de la « liaison par fichiers » qui relie le terminal de confirmation d’éligibilité au système de facturation
• Le point d’entrée côté ORCA — les 20 API liées à la confirmation d’éligibilité et le groupe de tables tbl_onshi_*
• La chronologie des évolutions réglementaires de 2020 à 2026, gravée dans l’historique des modifications COBOL

Les éléments relatifs au dispositif réglementaire s’appuient sur les documents publics du ministère de la Santé, du Travail et des Affaires sociales et sur ceux publiés officiellement par ORCA ; les éléments relatifs au code source s’appuient sur une lecture effective du code source de Nichi-Rece de la série 5.2 (instantané publié le 1er juillet 2026), publié officiellement.

Les prérequis de cet article

Le public visé est constitué des ingénieurs qui développent des systèmes s’interfaçant avec le système de facturation des soins — systèmes d’accueil, dossiers médicaux électroniques, systèmes de rendez-vous, etc. Il n’est pas nécessaire de savoir lire le COBOL (chaque extrait cité sera expliqué). Aucune expérience pratique de la gestion administrative médicale n’est présupposée non plus.

Comme il s’agit du troisième article de la série, les termes expliqués dans les deux précédents reviennent tels quels. Pour que cet article puisse se lire de façon autonome, en voici ci-dessous le vocabulaire minimal.

Table des matières

1. La conclusion, d’abord — la confirmation d’éligibilité est un relais entre « quatre acteurs »
2. Comprendre le dispositif en un minimum de temps — qu’est-ce que la confirmation d’éligibilité en ligne ?
3. Entre le terminal et le système de facturation — le point de contact de la liaison par fichiers OQS
4. Le point d’entrée côté ORCA — compter depuis le code source les 20 API liées à la confirmation d’éligibilité
5. La destination des données — les 13 tables tbl_onshi_*
6. Lire tbl_onshi_kaku — ce qu’une confirmation d’éligibilité laisse comme trace
7. L’historique des modifications comme chronologie du dispositif — 2020-2026
8. La répercussion vers l’enregistrement des patients — le résultat ne devient pas « tel quel » l’information d’assurance
9. Points pratiques pour qui développe un système de liaison
10. Conclusion
11. Références

1. La conclusion, d’abord — la confirmation d’éligibilité est un relais entre « quatre acteurs »

Si l’on résume en un schéma le trajet allant de la présentation de la carte Mynumber-assurance maladie jusqu’à l’inscription des informations d’éligibilité dans le système de facturation, on compte quatre acteurs.

flowchart LR
    subgraph clinic["Au sein de l'établissement médical"]
        CR["Lecteur de carte<br/>à reconnaissance faciale"]
        TERM["Terminal de confirmation<br/>d'éligibilité"]
        REN["Programme de liaison<br/>(onshi-tools pour Nichi-Rece)"]
        ORCA["ORCA/Nichi-Rece<br/>accumulation dans tbl_onshi_*"]
        UKE["Accueil / enregistrement<br/>des patients"]
        CR --> TERM
        TERM <-->|"Dossier partagé<br/>OQS〜.xml"| REN
        REN -->|"API liées à la confirmation<br/>d'éligibilité (enregistrement)"| ORCA
        ORCA --> UKE
    end
    TERM <-->|"IP-VPN /<br/>IPsec+IKE"| OQS["Système de confirmation<br/>d'éligibilité en ligne<br/>(Fonds de paiement, Assoc. centrale d'assurance nationale)"]

1. Le lecteur de carte à reconnaissance faciale lit la carte Mynumber et effectue la vérification d’identité (reconnaissance faciale ou code confidentiel).
2. Le terminal de confirmation d’éligibilité interroge, via le réseau du système de confirmation d’éligibilité en ligne (IP-VPN d’un opérateur de lignes dédiées, ou connexion IPsec+IKE via Internet), le système de confirmation d’éligibilité en ligne (exploité par le Fonds de paiement des honoraires médicaux de l’assurance sociale et l’Association centrale d’assurance maladie nationale), et reçoit les informations d’éligibilité en XML.
3. Entre le terminal et le système de facturation, la base est la liaison par fichiers. Le XML de résultat est déposé dans un dossier partagé, puis le programme de liaison l’importe dans le système de facturation. Pour Nichi-Rece, le programme officiel qui assure ce rôle est onshi-tools.
4. Le résultat importé s’accumule d’abord dans le groupe de tables dédiées à la confirmation d’éligibilité au sein d’ORCA (tbl_onshi_*), avant que les processus d’accueil et d’enregistrement des patients ne le répercutent vers les informations patient et d’assurance.

Le point essentiel, c’est que le résultat de la confirmation d’éligibilité n’est pas écrit directement dans la table maîtresse des patients, mais s’accumule d’abord dans une table dédiée. Cette architecture en deux temps, où « l’enregistrement de l’interrogation » et « la répercussion vers la table maîtresse des patients » sont séparés, est la clé pour comprendre l’intégration de la confirmation d’éligibilité dans ORCA (chapitres 6 et 8).

2. Comprendre le dispositif en un minimum de temps — qu’est-ce que la confirmation d’éligibilité en ligne ?

Avant d’entrer dans les détails techniques, résumons d’abord brièvement le dispositif réglementaire.

• De quoi s’agit-il ? : un mécanisme qui vérifie immédiatement en ligne les droits d’assurance d’un patient, en utilisant comme clé la carte Mynumber (carte Mynumber-assurance maladie) ou le symbole et le numéro de la carte d’assurance. Comme un changement de droits d’un assureur à l’autre (changement d’emploi, déménagement, etc.) est répercuté au moment même de l’interrogation, l’intérêt principal du point de vue de la facturation est de réduire les rejets de relevés de soins dus à des erreurs d’éligibilité.
• Depuis quand ? : l’exploitation à grande échelle a commencé en octobre 2021, et depuis avril 2023 l’installation du système est en principe devenue obligatoire pour les établissements médicaux et pharmacies conventionnés. En décembre 2024, l’émission de nouvelles cartes d’assurance maladie classiques a pris fin, la carte Mynumber-assurance maladie étant devenue la base du dispositif.
• Que reçoit-on en dehors de l’éligibilité ? : lorsque le patient donne son consentement via le lecteur de carte, l’établissement médical peut consulter les informations sur les médicaments, les bilans de santé spécifiques et les informations de soins. Le périmètre s’étend en outre à la confirmation d’éligibilité pour l’aide médicale (assistance sociale) et à l’intégration des informations d’aide aux frais médicaux des collectivités locales (PMH : Public Medical Hub).

Bien qu’on l’appelle « confirmation d’éligibilité », la situation actuelle est plutôt qu’elle devient une artère principale de l’intégration des informations médicales, où l’éligibilité n’est que le point d’entrée par lequel finissent par transiter jusqu’aux informations de soins. La façon dont cet « élargissement du périmètre » se manifeste dans le code du système de facturation sera examinée au chapitre 7 sous forme de chronologie.

3. Entre le terminal et le système de facturation — le point de contact de la liaison par fichiers OQS

Comment se connecte le point de contact interne à l’établissement médical, c’est-à-dire entre le terminal de confirmation d’éligibilité et le système de facturation (ou le dossier médical électronique) ?

Dans les documents publics destinés aux éditeurs de systèmes, l’État présente, comme méthodes d’intégration entre les systèmes existants et le système de confirmation d’éligibilité en ligne, la liaison par fichiers via une application de liaison, ainsi que l’intégration par application web, l’intégration par reconnaissance faciale ou l’intégration par API web. La méthode centrale, la liaison par fichiers, repose, pour le dire simplement, sur un mécanisme classique mais fiable : « déposer un fichier XML au nom déterminé dans un dossier déterminé fait revenir un fichier XML de réponse ».

Nichi-Rece adopte lui aussi cette méthode. La page officielle d’ORCA « Confirmation d’éligibilité en ligne de Nichi-Rece » indique, comme fichiers échangés avec le terminal de confirmation d’éligibilité,

• Demande : OQSsiquc01req_Oxxxxxxxxxxxx.xml
• Résultat : OQSsiquc01res_Oxxxxxxxxxxxx.xml

cette nomenclature, et ces fichiers s’échangent via un dossier partagé. C’est onshi-tools, fourni officiellement, qui assure cet échange de fichiers et leur importation dans Nichi-Rece ; il existe une version Ubuntu et une version Windows (un outil de surveillance du service d’importation et un outil de vérification de l’environnement sont également publiés).

Le préfixe OQS en tête est commun à tous les fichiers échangés avec le système de confirmation d’éligibilité en ligne (le développement de cette abréviation n’est pas explicité dans les documents publics). Le nom du fichier se compose du préfixe OQS, d’une partie indiquant le type de demande (siquc01, etc.), de req (demande) ou res (résultat), puis d’un identifiant attribué par l’établissement médical. Selon le même système, les fichiers de demande pour les informations sur les médicaments portent le préfixe YZK, et ceux pour les bilans de santé spécifiques le préfixe TKK (chapitre 4).

Ce vocabulaire « OQS » apparaît aussi dans le code source public d’ORCA. Par exemple, la définition de réponse record/xml_onlinequares1.db de l’API qui assemble et renvoie les données de demande d’interrogation pour le programme de liaison (onlinequa1, vu au chapitre 4) contient des champs tels que InsurerNumber (numéro d’assureur), InsuredCardSymbol (symbole de la carte d’assuré), QualificationConfirmationDate (date de confirmation d’éligibilité) ou LimitApplicationCertificateRelatedConsFlg (drapeau de consentement relatif au certificat d’application du plafond). Le même fichier de définition contient, en commentaire, le nom du fichier de demande d’annulation du consentement de consultation pour les soins à domicile, OQSsihvd01req_xxxxxxxxxxxx.xml (avec une note datée de 2024-11) : la nomenclature OQS apparaît donc telle quelle dans le code source. Les noms des champs XML côté système de confirmation d’éligibilité en ligne se retrouvent ainsi tels quels jusque dans l’API du système de facturation. C’est une conception bienvenue pour qui développe un système de liaison, car elle permet de confronter le cahier des charges de l’État et le code source d’ORCA avec le même vocabulaire.

4. Le point d’entrée côté ORCA — compter depuis le code source les 20 API liées à la confirmation d’éligibilité

Comptons maintenant le point d’entrée côté ORCA. Avec la même méthode que la fois précédente, en relevant les déclarations bindapi dans les définitions LD (lddef/*.ld) du code source de la série 5.2, on trouve 20 points de terminaison liés à la confirmation d’éligibilité, répartis dans 3 fichiers LD. Les noms de fonction sont, dans tous les cas, recopiés tels quels depuis le « nom de composant » indiqué dans l’en-tête du programme COBOL responsable.

(Les dates de création sont extraites du champ de date de création de l’en-tête de chaque programme, mises en forme uniformément en AAAA/MM. Seul onlinequa4 indique « 2021 » car sa date de création est notée 21/xx/xx dans l’en-tête, mois et jour masqués. La précision entre parenthèses pour onlinequa1 est un ajout basé sur le contenu de l’implémentation.)

Cette liste se répartit en trois groupes selon le rôle.

1. API d’enregistrement (terminal → Nichi-Rece) : à commencer par onlinequa2 (reconnaissance faciale) et onlinequa3 (carte d’assurance), ce sont les processus d’« enregistrement/mise à jour » pour les médicaments, les bilans de santé spécifiques, les informations de soins, l’image OCR, l’aide médicale et l’aide aux frais médicaux. C’est le point d’entrée par lequel le résultat parvenu depuis le terminal de confirmation d’éligibilité est injecté dans Nichi-Rece.
2. API de constitution de la demande (programme de liaison → Nichi-Rece) : à en juger par son nom, onlinequa1 ressemble à une « API d’interrogation de résultat », mais la lecture de l’implémentation montre le contraire. Elle lit, par un uuid (obligatoire), le dernier enregistrement de tbl_onshi_kaku, puis assemble et renvoie à partir de là le contenu de la demande d’interrogation (requête OQS) à envoyer au terminal de confirmation d’éligibilité — le numéro d’assureur, le symbole et le drapeau de consentement utilisés pour la confirmation d’éligibilité, ainsi que les noms des fichiers de demande pour les informations sur les médicaments et les bilans de santé spécifiques (YZKsiquc01req_～.xml, TKKsiquc01req_～.xml ; le « ～ » désigne une chaîne où la fin du numéro de patient est complétée par des X pour atteindre 20 caractères). C’est une API par laquelle le programme de liaison, ayant reçu une instruction d’interrogation du PushAPI, vient chercher « ce qu’il faut demander au terminal » ; ce n’est pas une API qui recherche et renvoie un résultat accumulé.
3. API de récupération (dossier médical électronique, etc. → Nichi-Rece) : les 3 API sous /api01rv2/ permettent à un système de liaison de récupérer les informations accumulées sur les médicaments, les bilans de santé spécifiques et les soins. Le fait qu’elles se trouvent sous api01rv2, où se regroupent les API de lecture, est aussi conforme à la règle de placement des API Nichi-Rece observée la fois précédente.

Le code source contient en outre une définition record/push_onlinequa.db, qui montre que des événements PushAPI liés à la confirmation d’éligibilité (Bulk_Qualification, patient_qualification) sont prévus. La lecture des points d’émission montre que l’écran de l’opération d’interrogation, le sous-programme de confirmation d’éligibilité appelé depuis l’accueil et l’enregistrement des patients (ORCSONSHI001.CBL), l’écran d’interrogation groupée des patients avec rendez-vous (ORCGY06.CBL) et le traitement par lots (ORCBONSHIPUSH.CBL) émettent chacun un événement d’instruction d’interrogation. Autrement dit, cet événement sert principalement de canal permettant à Nichi-Rece d’envoyer au programme de liaison l’instruction « va faire la confirmation d’éligibilité ». Le contenu diffère toutefois selon l’émetteur. La classe contient soit Rreq (demande d’interrogation), soit, dans certains cas, directement la valeur du drapeau de nécessité de confirmation (Yes) ; le sens de l’uuid n’est pas non plus constant : uuid de l’enregistrement de tbl_onshi_kaku pour un événement individuel, uuid de gestion de tâche pour l’interrogation groupée des patients avec rendez-vous, absence d’uuid pour l’instruction groupée du traitement par lots. Le côté récepteur doit donc choisir entre onlinequa1 (constitution d’une demande individuelle), onlinequaapp1 (groupé pour patients avec rendez-vous) et onlinerefall1 (enregistrement groupé des numéros d’interrogation), selon le nom de l’événement, la classe et le sens de l’uuid. Le commentaire en tête de record/xml_onlinequareq1.db décrit le flux par lequel le programme récepteur (onshi_receiver), ayant reçu la notification Push, récupère les données de demande via onlinequa1 ; en se limitant à l’événement individuel, on peut ainsi lire un cycle complet : Push (instruction d’interrogation) → onlinequa1 (constitution de la demande) → fichier de demande envoyé au terminal → onlinequa2/onlinequa3 (enregistrement du résultat). À l’inverse, les API d’enregistrement du résultat par reconnaissance faciale ou carte d’assurance (onlinequa2/onlinequa3) n’émettent pas cet événement. Attention donc : si vous construisez un écran d’accueil en attendant du PushAPI une « notification à l’instant où le résultat est enregistré », vous resterez en attente sans jamais recevoir cette notification (chapitre 9).

5. La destination des données — les 13 tables tbl_onshi_*

Où vont les données reçues par les API d’enregistrement ? En extrayant de la liste des tables de la base de données (lddef/orcadb.inc) celles dont le nom contient onshi, on en trouve 13. Rien qu’en regardant leurs noms, on voit que les types d’informations transmis par la confirmation d’éligibilité s’y reflètent directement.

L’architecture en deux temps évoquée au chapitre 1 apparaît ici clairement. Les données issues de la confirmation d’éligibilité ne sont pas écrites directement dans la table maîtresse des patients (tbl_ptinf) ou dans les tables d’assurance : elles atterrissent d’abord dans des tables tbl_onshi_*, qui conservent tel quel le vocabulaire de la confirmation d’éligibilité. C’est une conception qui met en place une zone tampon entre le vocabulaire du dispositif réglementaire national (éligibilité, médicaments, bilan de santé spécifique, informations de soins…) et le vocabulaire interne du système de facturation (patient, assurance, aide publique…) ; on y lit qu’elle a su absorber les extensions du dispositif réglementaire (le fait même que le nombre de tables ait atteint 13 en est la preuve) sans briser le schéma du système de facturation lui-même.

6. Lire tbl_onshi_kaku — ce qu’une confirmation d’éligibilité laisse comme trace

La lecture de la table centrale tbl_onshi_kaku (définie dans record/tbl_onshi_kaku.db) montre concrètement ce qu’enregistre une confirmation d’éligibilité. Le fichier de définition est un simple texte alignant noms de champs et types, qui se présente comme suit (sur un total de 668 lignes, seuls les passages utilisés dans l’explication qui suit sont extraits ici).

tbl_onshi_kaku {
	HOSPNUM				number(2,0);
	TBL_UUID     			varchar(36);
	AITE_UUID     			varchar(36);
	OYA_UUID     			varchar(36);
	KOUHI_UUID     			varchar(36);
	FUJYO_UUID     			varchar(36);
#---> UUID PMH (2025-11)
	PMH_UUID     			varchar(36);
#---> identification de consentement groupé (2024/12)
	PROCESS_CLASS			varchar(01);
	(omis)
#---> nom du fichier image (2022/7)
	HKNOCR_FILENAME  		varchar(100);
	(omis)
	SHO_HKNJANUM			varchar(8);
	SHO_KIGO     			varchar(80);
	SHO_NUM     			varchar(80);
	SHO_EDABAN    			varchar(2);
	SHO_BIRTHDAY    		varchar(8);
	(omis)
	RES_HKNJANUM			varchar(8);
	RES_KIGO     			varchar(80);
	RES_NUM     			varchar(80);
	RES_EDABAN    			varchar(2);
	RES_HONKZKKBN	    		varchar(1);
	RES_HIHKNJANAME    		varchar(100);
	(omis)
	KENSHIN_DOUIFLG  	  	varchar(1);
	KENSHIN_TIME  		  	varchar(14);
	KENSHIN_KIGENYMD   	  	varchar(14);
	YAKUZAI_DOUIFLG   	  	varchar(1);
	YAKUZAI_TIME  		  	varchar(14);
	YAKUZAI_KIGEN  		  	varchar(14);
#---> informations de consentement aux soins (2022/7)
	SHINRYO_DOUIFLG   	  	varchar(1);

Rien qu’en relevant les préfixes des noms de champs (SHO_/RES_/〜_DOUIFLG) et les commentaires de date d’ajout commençant par #--->, on peut déjà lire à peu près la structure et l’historique de cette table. Voici, ci-dessous, une explication des principaux groupes de champs.

• Le faisceau d’uuid : outre TBL_UUID (cet enregistrement lui-même), on trouve des uuid pointant vers des enregistrements associés — AITE_UUID, OYA_UUID, KOUHI_UUID (aide publique), FUJYO_UUID (aide médicale), PMH_UUID (aide aux frais médicaux). La confirmation d’éligibilité, la confirmation d’aide publique, la confirmation d’assistance et les informations d’aide sont enregistrées comme des enregistrements distincts, et reliées en un seul événement d’accueil par une chaîne d’uuid. C’est pour cela que l’API de constitution de la demande du chapitre 4 (onlinequa1) rend obligatoire la spécification de l’uuid.
• Les critères de recherche utilisés pour l’interrogation (SHO_*) : numéro d’assureur, symbole, numéro, numéro de branche, date de naissance, etc. spécifiés lors de l’interrogation. Leur origine dans la définition est l’« information de recherche pour la confirmation d’éligibilité » (QualificationConfirmSearchInfo) côté requête ; c’est l’enregistrement de « sur quels critères l’interrogation a été faite » (le numéro d’assureur et le symbole ne figurant pas sur la carte Mynumber elle-même, ce n’est donc pas une « copie de la carte »).
• Les informations d’éligibilité renvoyées (RES_*) : numéro d’assureur, symbole, numéro, numéro de branche, distinction assuré/famille, nom de l’assuré, etc. C’est l’enregistrement de « ce que le système de confirmation d’éligibilité a répondu ». Comme les critères d’interrogation (SHO) et le résultat (RES) sont conservés dans des champs distincts, on peut suivre sur l’enregistrement l’écart entre le symbole et le numéro connus jusque-là et l’éligibilité la plus récente (changement de droits dû à un changement d’emploi, un déménagement, etc.).
• Résultat et état : résultat du traitement (RESULT_*), code/message d’erreur (ERR_*), validité de l’éligibilité (SIKAKU_YUKO), catégorie de carte d’assuré (CARD_CLASS — dont l’origine dans la définition est InsuredCardClassification, la catégorie de l’enregistrement d’éligibilité renvoyé, et non le type de carte physique), date et heure de confirmation, lien avec le numéro de patient (PTID), drapeau de correspondances multiples (FUKUSU_GAITO), etc.
• Autour du consentement : le drapeau de consentement n’est pas unique ; il se décline séparément selon le type d’information. Outre les médicaments (YAKUZAI_DOUIFLG), le bilan de santé spécifique (KENSHIN_DOUIFLG) et les informations de soins (SHINRYO_DOUIFLG), on trouve le certificat d’application du plafond (GENDO_DOUIFLG), le certificat de maladie spécifique (SIKKAN_DOUIFLG), et même une granularité poussée jusqu’aux opérations, aux noms de blessures/maladies, aux maladies infectieuses, aux allergies, aux examens et aux prescriptions. La « consultation d’informations basée sur le consentement » évoquée au chapitre 2 est ainsi implémentée sous forme de champs de table qui distinguent, type par type, à quoi porte le consentement.

Les commentaires du fichier de définition conservent aussi la date d’ajout de chaque champ : une note de juillet 2022 pour le champ du nom de fichier OCR de la carte d’assurance, et de novembre 2025 pour PMH_UUID. La définition de la table elle-même fait partie de l’histoire de l’adaptation réglementaire que nous verrons au chapitre suivant.

7. L’historique des modifications comme chronologie du dispositif — 2020-2026

Deux articles plus tôt, nous avions écrit que « l’historique des modifications de l’en-tête COBOL constitue une chronologie des réformes réglementaires ». Le groupe de programmes liés à la confirmation d’éligibilité en est l’exemple le plus éclatant. Mettons en regard les dates de création du tableau du chapitre 4 et l’historique des modifications avec les évolutions du dispositif réglementaire.

Deux articles plus tôt, nous avions écrit que « la difficulté fondamentale d’un système de facturation est de suivre les réformes réglementaires pendant des décennies » ; la confirmation d’éligibilité en est le présent continu. Depuis sa création en 2020 jusqu’à 2026, une API ou une table s’est ajoutée presque chaque année — ce fait constitue aussi un avertissement pratique : il ne faut pas considérer l’intégration de la confirmation d’éligibilité comme une intégration qu’on « construit une fois pour toutes » (chapitre 9).

Notez que si l’on effectue un diff mensuel du code source public, ce type d’extension peut être détecté comme une différence dans lddef et record, autour de l’annonce officielle. La surveillance des diffs entre instantanés mensuels, proposée la fois précédente, s’avère donc particulièrement efficace dans le domaine de la confirmation d’éligibilité.

8. La répercussion vers l’enregistrement des patients — le résultat ne devient pas « tel quel » l’information d’assurance

Comment le résultat accumulé dans tbl_onshi_kaku est-il finalement répercuté vers la table maîtresse des patients ?

En comptant les programmes qui référencent la table de résultats de confirmation d’éligibilité, les plus nombreux sont les 16 programmes du processus d’enregistrement des patients (cobol/orca12/) ; elle est aussi référencée depuis le processus d’accueil (orca11) et le processus d’interrogation. Rien qu’en relevant les commentaires de section du programme central de l’enregistrement des patients, ORCGP02.CBL, on voit déjà le déroulement du traitement.

* Traitement de recherche d'UID de confirmation d'éligibilité en ligne
* Données de confirmation d'éligibilité en ligne — traitement de nouveau patient
* Informations de confirmation d'éligibilité en ligne — traitement des informations de base
* Informations de confirmation d'éligibilité en ligne — traitement de mise à jour de l'adresse
* Informations de confirmation d'éligibilité en ligne — traitement des informations d'assurance
* Informations de confirmation d'éligibilité en ligne — traitement d'ajout du plafond et de l'aide publique, etc.
* Informations de confirmation d'éligibilité en ligne — traitement de vérification de la date de début de l'aide publique

Autrement dit, Nichi-Rece ne se contente pas d’écraser mécaniquement le résultat de la confirmation d’éligibilité : il le répercute en le décomposant en décisions individuelles dans le contexte du processus d’enregistrement des patients — « création d’un nouveau patient », « mise à jour du nom et de l’adresse », « rapprochement et mise à jour des informations d’assurance », « ajout de la reconnaissance du plafond ou de l’aide publique », « vérification de la validité de la date de début ». Le résultat de la confirmation d’éligibilité n’est qu’un élément de décision ; c’est bien le processus d’enregistrement des patients qui détient, en dernier ressort, l’autorité sur la table maîtresse des patients et de l’assurance. L’architecture en deux temps du chapitre 1 peut s’interpréter comme une conception au service de cette séparation des responsabilités.

L’implication pour qui développe un dossier médical électronique ou un système d’accueil est claire : créer un raccourci qui répercute directement le résultat de la confirmation d’éligibilité dans sa propre table maîtresse des patients revient à contourner cette logique de rapprochement. La bonne pratique est de faire passer la répercussion par les processus d’ORCA (ou une API équivalente).

9. Points pratiques pour qui développe un système de liaison

Voici un résumé des points essentiels lorsqu’un système d’accueil, un dossier médical électronique ou un système de rendez-vous interagit avec la confirmation d’éligibilité.

1. Il y a deux points de contact. Le point de contact avec le terminal de confirmation d’éligibilité (liaison par fichiers OQS) et le point de contact avec le système de facturation (API Nichi-Rece) sont deux choses distinctes. Dans la configuration Nichi-Rece, c’est onshi-tools qui assure la liaison et l’importation de fichiers ; déterminez donc d’abord si votre système de liaison doit lui-même manipuler les fichiers OQS, ou s’il lui suffit d’utiliser les données déjà importées dans Nichi-Rece (les API de récupération pour les médicaments, le bilan de santé spécifique et les soins ; les API habituelles d’informations patient pour le résultat répercuté vers le patient et l’assurance). Dans la plupart des cas, la seconde option suffit.
2. Intégrer la chaîne d’uuid dans la conception. La confirmation d’éligibilité, la confirmation d’aide publique, l’aide médicale et l’aide aux frais médicaux s’enchaînent par uuid en tant qu’enregistrements distincts (chapitre 6). Vérifier dès le départ, dans les définitions record/ du code source, la conception de la clé qui permet de reconstituer « un accueil » sera payant par la suite.
3. Vérifier dans le code source la « signification » d’un événement PushAPI avant de l’utiliser. L’événement push_onlinequa existe bel et bien, mais à en juger par ses points d’émission, son usage principal est l’instruction de demande d’interrogation (Rreq) ; les API d’enregistrement de résultat (onlinequa2/onlinequa3) ne l’émettent pas. onlinequa1 non plus n’est pas une API qui renvoie un résultat, mais une API de constitution de la demande (chapitre 4). Si vous voulez créer un affichage synchronisé du type « confirmation d’éligibilité effectuée » sur un écran d’accueil, vous ne pouvez pas partir du principe qu’une notification d’arrivée du résultat viendra de Nichi-Rece. Celui qui apprend en premier l’arrivée du résultat est le côté qui l’enregistre (le programme de liaison) ; si une synchronisation est nécessaire, faites émettre une notification vers votre propre système au même endroit que le chemin d’importation (au moment où l’enregistrement se termine), ou bien concevez l’écran en partant du principe de la répercussion via l’accueil et l’enregistrement des patients de Nichi-Rece.
4. Respecter l’état du consentement, type par type. Les informations sur les médicaments, le bilan de santé spécifique et les soins circulent sur la base du consentement du patient, et tbl_onshi_kaku prévoit des drapeaux de consentement par type d’information, tels que YAKUZAI_DOUIFLG, KENSHIN_DOUIFLG ou SHINRYO_DOUIFLG. Le fait qu’une API de récupération renvoie une donnée ne doit pas conduire à l’utiliser sans avoir vérifié l’état de consentement pour le type concerné.
5. Concevoir la maintenance en partant du principe d’un « ajout annuel ». Comme le montre le chapitre 7, les API et les tables liées à la confirmation d’éligibilité sont étendues quasiment chaque année. Nous recommandons d’intégrer dans l’exploitation une surveillance des diffs de lddef/record du code source publié mensuellement, et de prendre l’habitude de les lire comme des notes de version des évolutions réglementaires.
6. Partir de l’outillage officiel pour la validation. Outre le programme de liaison, ORCA publie officiellement des fichiers de motifs de validation, un outil de vérification de l’environnement, ainsi que des outils de récupération groupée pour l’aide médicale, les soins à domicile et les soins en ligne. Vérifiez ces moyens de validation officiels avant de créer vos propres données de test.

10. Conclusion

• L’accueil avec la carte Mynumber-assurance maladie est traité par un relais lecteur de carte → terminal de confirmation d’éligibilité → (liaison par fichiers) → programme de liaison → système de facturation. Entre le terminal et le système de facturation, la base est l’échange de fichiers XML nommés selon la convention OQS ; pour Nichi-Rece, c’est onshi-tools, l’outil officiel, qui assure ce pont.
• Le point d’entrée côté ORCA compte 20 API liées à la confirmation d’éligibilité (enregistrement, constitution de la demande, récupération). Le résultat de la confirmation d’éligibilité n’est pas écrit directement dans la table maîtresse des patients : il s’accumule d’abord dans les 13 tables tbl_onshi_*, dans une architecture en deux temps où le processus d’enregistrement des patients détient la décision de rapprochement et de mise à jour.
• tbl_onshi_kaku conserve séparément les critères de recherche utilisés pour l’interrogation (SHO_*) et les informations d’éligibilité renvoyées (RES_*), ce qui permet de suivre sur l’enregistrement l’écart entre les critères d’interrogation et l’éligibilité la plus récente. Les enregistrements associés sont regroupés par une chaîne d’uuid.
• L’historique des modifications COBOL liées à la confirmation d’éligibilité, depuis sa création en 2020 jusqu’à la reconnaissance faciale, l’OCR, les informations de soins, l’aide médicale, le PMH et les soins en ligne, constitue littéralement une chronologie de l’extension du dispositif réglementaire. L’intégration de la confirmation d’éligibilité n’est pas un domaine qu’on « construit une fois pour toutes » : c’est un domaine à concevoir en partant du principe d’une maintenance qui suit des extensions annuelles.
• Comme d’habitude, tout ceci peut être vérifié comme information de première main à partir du code source public. Le vocabulaire du cahier des charges national (les noms de champs XML OQS) se retrouvant tel quel jusque dans l’API du système de facturation, on peut confronter les documents réglementaires et le code source avec le même langage.

Le prochain article de la série portera sur la logique de vérification et d’évaluation des relevés de soins. Nous y décomposerons, toujours à partir du code source et des documents publics, ce que vérifient respectivement le contrôle des données au sein de l’établissement médical (le processus orca41 d’ORCA) et le contrôle informatique côté organisme de vérification et de paiement.

11. Références

• À propos de la confirmation d’éligibilité en ligne (destiné aux établissements médicaux, cliniques de soins, éditeurs de systèmes, etc.) — ministère de la Santé, du Travail et des Affaires sociales
• Portail intégré destiné aux établissements médicaux (documentation technique de l’application de liaison, etc.)
• Confirmation d’éligibilité en ligne de Nichi-Rece — logiciel de facturation standard de l’Association médicale japonaise — ORCA Project (onshi-tools, liaison par fichiers OQS, documents de validation)
• Outil de récupération groupée pour la confirmation d’éligibilité en ligne — logiciel de facturation standard de l’Association médicale japonaise — ORCA Project
• À propos de la prise en charge de la confirmation d’éligibilité en ligne par le logiciel de facturation standard de l’Association médicale japonaise — Organisme de gestion ORCA de l’Association médicale japonaise
• Code source de Nichi-Rece, série 5.2 (instantané publié en juillet 2026) : lddef/orca14.ld / lddef/orca71.ld / lddef/api01rv2.ld / cobol/orca14/ORAPION*.CBL / cobol/orca71/ORAPION*.CBL / record/tbl_onshi_*.db / record/xml_onlinequares1.db / record/push_onlinequa.db / cobol/orca12/ORCGP02.CBL et autres — toutes les descriptions de la liste des API, des champs de table et de l’historique des modifications dans cet article se fondent 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.

Quand l'accueil se fait avec la carte Mynumber-assurance maladie, comment les informations sur les droits d'assurance entrent-elles dans le système de facturation ?

Une fois l'identité vérifiée par le lecteur de carte à reconnaissance faciale, le terminal de confirmation d'éligibilité interroge le système de confirmation d'éligibilité en ligne du Fonds de paiement des soins et de l'Association centrale d'assurance maladie nationale, puis reçoit les informations d'éligibilité sous forme de fichier XML. L'échange avec le système de facturation se fait fondamentalement par liaison de fichiers via un dossier partagé ; pour ORCA (Nichi-Rece), c'est le programme de liaison officiel (onshi-tools) qui importe le fichier de résultat. Les résultats importés s'accumulent dans les tables liées à la confirmation d'éligibilité de Nichi-Rece (comme tbl_onshi_kaku), puis sont répercutés vers les informations patient et d'assurance depuis les processus d'accueil et d'enregistrement des patients.

La confirmation d'éligibilité en ligne ne transmet-elle que les informations sur les droits d'assurance ?

Non, pas seulement les informations d'éligibilité. Avec le consentement du patient, l'établissement médical peut aussi consulter les informations sur les médicaments, les bilans de santé spécifiques et les informations de soins. Dans le code source d'ORCA également, indépendamment du résultat de la confirmation d'éligibilité, des API d'enregistrement et des tables dédiées sont prévues séparément pour les informations sur les médicaments, les bilans de santé spécifiques et les informations de soins (médecine générale et dentaire). Le périmètre s'élargit d'ailleurs chaque année, avec par exemple la confirmation d'éligibilité pour l'aide médicale (assistance sociale) ou l'intégration des informations d'aide aux frais médicaux (PMH).

Combien d'API liées à la confirmation d'éligibilité en ligne compte ORCA (Nichi-Rece) ?

En comptant les définitions LD du code source de la série 5.2 publié (instantané de juillet 2026), on trouve 20 points de terminaison liés à la confirmation d'éligibilité en ligne. Ils se répartissent en trois catégories : les API d'enregistrement, qui inscrivent dans Nichi-Rece le résultat de la confirmation d'éligibilité ainsi que les informations sur les médicaments, les bilans de santé spécifiques et les soins ; les API de constitution de la demande, qui assemblent et renvoient les données de demande d'interrogation que le programme de liaison envoie au terminal de confirmation d'éligibilité ; et les API de récupération, par lesquelles le dossier médical électronique et d'autres systèmes récupèrent les données accumulées. Les trois premières ont été créées en novembre 2020, et de nouvelles API ont été ajoutées à chaque extension du dispositif réglementaire depuis lors.

À quoi faut-il faire attention lorsqu'on développe un système de liaison autour de la confirmation d'éligibilité en ligne ?

Il faut d'abord bien saisir que l'échange entre le terminal de confirmation d'éligibilité et le système de facturation repose fondamentalement sur l'envoi et la réception de fichiers XML (méthode par application de liaison). Ensuite, il faut prêter attention au fait que l'intégration ORCA est conçue pour suivre les enregistrements liés via un uuid, à la différence de rôle entre les API d'enregistrement et les API de récupération, et au fait que la consultation des informations sur les médicaments, les bilans de santé spécifiques et les soins dépend de l'état du consentement du patient. Comme les API et les tables sont étendues quasiment chaque année pour suivre les évolutions réglementaires, nous recommandons aussi d'intégrer dans l'exploitation une surveillance des diffs du code source publié mensuellement.

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.