Où se produisent la minoration et le renvoi des relevés de soins — décomposer la logique du contrôle des relevés à partir du code source d'ORCA et de documents publics

Les recettes au guichet ne représentent qu’une fraction des revenus d’un établissement de santé : l’essentiel se décide lors de la facturation mensuelle des relevés de soins. C’est précisément pour cela que des expressions comme « on nous a minorés » ou « on a reçu un renvoi » pèsent lourd sur le terrain. Et pourtant, pour l’ingénieur qui travaille sur les systèmes, où et selon quelle logique se produisent la minoration et le renvoi reste un sujet étonnamment difficile à cerner.

Le premier volet de la série a traité du rôle du logiciel de facturation, le deuxième de l’API de Nichi-Rece, et le troisième de la vérification en ligne de l’éligibilité. Ce volet-ci s’attaque au cœur du métier des relevés de soins — la logique du contrôle et de l’examen — en alignant, dans l’ordre, les « postes de contrôle » que traverse un relevé.

• Le sens précis des termes renvoi, minoration et réexamen
• Les contrôles internes à l’établissement de santé — l’implémentation de la fonction de contrôle des données d’ORCA et du check master
• Le contrôle des données rece-den avant soumission
• Les contrôles côté organisme d’examen et de paiement — contrôles informatiques, contrôle de concordance, contrôle longitudinal
• Le fait que, structurellement, le logiciel de facturation et le côté examen partagent la même structure « table de règles + moteur »

Les descriptions relatives au dispositif réglementaire s’appuient sur des documents publics de la Caisse de paiement, des associations médicales, etc. ; les descriptions relatives à l’implémentation d’ORCA s’appuient sur une lecture effective du code source officiel de Nichi-Rece, série 5.2 (instantané publié le 1er juillet 2026).

Le strict minimum de vocabulaire — de quoi suivre l’article

Le secteur médical enchaîne les sigles ; fixons donc d’abord le strict minimum de vocabulaire. À partir d’ici, lisez ces termes avec le sens suivant.

En un seul schéma, voici comment circulent le relevé de soins et l’argent.

flowchart LR
    PT["Patient"] -->|"Consultation, ticket modérateur"| MED["Établissement de santé<br/>(établit le relevé via le logiciel de facturation)"]
    MED -->|"Relevé de soins (facturation)"| SSK["Organisme d'examen et de paiement<br/>(Caisse de paiement, Fédérations d'assurance maladie)"]
    SSK -->|"Facturation examinée"| HKN["Assureur"]
    HKN -->|"Paiement"| SSK
    SSK -->|"Paiement"| MED
    SSK -.->|"Notification de renvoi / minoration"| MED

Ce que traite cet article, c’est la partie centrale : où et quoi est contrôlé pendant que le relevé de soins passe de l’établissement de santé à l’organisme d’examen et de paiement.

Ce texte s’adresse aux ingénieurs travaillant sur des systèmes destinés aux établissements de santé (intégration avec le logiciel de facturation, dossier médical électronique, systèmes de service), ainsi qu’aux responsables informatiques internes. Aucune expérience pratique de la gestion administrative médicale n’est présupposée. La lecture des volets précédents de la série n’est pas non plus un prérequis, mais elle facilite la compréhension du contexte.

Table des matières

1. La conclusion d’abord — un relevé de soins traverse « quatre postes de contrôle »
2. Le vocabulaire en bref — renvoi, minoration, ajustement de points, réexamen
3. Poste de contrôle 1 — lire dans le source la fonction de contrôle des données d’ORCA
4. Le check master comme table de règles — la conception des tables de la famille tbl_chk
5. Contrôles à la saisie et API — le contrôle ne se limite pas à la fin de mois
6. Poste de contrôle 2 — le contrôle des données rece-den, l’inspection des données de facturation
7. Postes de contrôle 3 et 4 — les contrôles informatiques de l’organisme d’examen et de paiement, le contrôle de concordance et le contrôle longitudinal
8. Les deux côtés partagent la structure « table de règles + moteur » — la carte de l’ingénieur
9. Points pratiques — ce que le système peut faire pour améliorer la précision du contrôle
10. En résumé
11. Références

1. La conclusion d’abord — un relevé de soins traverse « quatre postes de contrôle »

En un seul schéma, voici les principaux points de contrôle que traverse un relevé de soins, depuis la saisie à l’établissement de santé jusqu’au paiement.

flowchart LR
    subgraph clinic["Au sein de l'établissement de santé"]
        NYU["Saisie quotidienne<br/>(contrôles à la saisie)"]
        DC["① Fonction de contrôle des données<br/>(ORCA : orca41)"]
        REC["② Contrôle des données rece-den<br/>(inspection des données de facturation)"]
        NYU --> DC --> REC
    end
    subgraph SHINSA["Organisme d'examen et de paiement (Caisse de paiement, Fédérations d'assurance maladie)"]
        CC["③ Contrôles informatiques<br/>+ contrôle de concordance et contrôle longitudinal"]
        JIN["④ Contrôle par le personnel<br/>+ commission d'examen"]
        CC --> JIN
    end
    REC -->|"Facturation en ligne"| CC
    JIN -->|"Facturation examinée"| HOKEN["Assureur"]
    HOKEN -.-> PAY["Paiement<br/>(vers l'établissement de santé via l'organisme d'examen et de paiement)"]
    JIN -.-> RET["Renvoi (retour) / minoration (réduction de points)<br/>(notifié à l'établissement de santé → correction et re-facturation)"]

• Poste de contrôle 1 (contrôle du contenu) : le logiciel de facturation vérifie la cohérence du contenu des soins — « le diagnostic et le médicament correspondent-ils ? », « y a-t-il des actes non facturés qui auraient dû l’être ? ». Chez ORCA, c’est la fonction de contrôle des données qui s’en charge.
• Poste de contrôle 2 (contrôle des données de facturation) : le relevé électronique à soumettre (le fichier rece-den) est vérifié en tant que données de facturation, du format d’enregistrement jusqu’aux exigences de saisie des commentaires. Chez ORCA, c’est le contrôle des données rece-den.
• Poste de contrôle 3 (examen automatisé) : les contrôles informatiques de l’organisme d’examen et de paiement passent mécaniquement le relevé au crible de règles fondées sur les avis, circulaires officiels et notices de médicaments, et signalent les éléments suspects. Le contrôle de concordance, qui rapproche les relevés médicaux et pharmaceutiques d’un même patient, et le contrôle longitudinal, qui compare avec les relevés des mois précédents, en font aussi partie.
• Poste de contrôle 4 (examen humain) : le personnel contrôle les éléments signalés par la machine, et c’est finalement la commission d’examen qui tranche. Le résultat est notifié à l’établissement de santé sous forme de renvoi ou de minoration.

L’essentiel à retenir, pour un ingénieur, c’est que les postes de contrôle 1 et 3 réalisent le même type de vérification, chacun de son côté. L’établissement de santé veut « repérer avant soumission les facturations susceptibles d’être retenues à l’examen » ; le côté examen veut « repérer les facturations non conformes aux règles ». Cette symétrie se traduit, comme on le verra, par une similitude de structure d’implémentation — dans les deux cas, une table de règles plus un moteur.

2. Le vocabulaire en bref — renvoi, minoration, ajustement de points, réexamen

Récapitulons le vocabulaire réglementaire, aussi brièvement que possible.

Ce qui compte, c’est que le renvoi signifie « à refaire » alors que la minoration signifie « une réduction définitive » — la gravité diffère. Et le contrôle de concordance comme le contrôle longitudinal détectent des erreurs impossibles à repérer en ne regardant qu’un seul relevé isolé (limite de fréquence à cheval sur plusieurs mois, incohérence entre le médical et le pharmaceutique). Leur nature diffère cependant : le rapprochement avec le relevé d’un autre organisme (concordance) est, par principe, impossible en interne dans l’établissement de santé, tandis que la comparaison avec ses propres mois passés (l’équivalent du contrôle longitudinal) est possible avec ses propres données. Comprendre cette ligne de partage, et « tout récupérer en interne ce qui peut l’être », voilà l’objectif du travail de contrôle.

3. Poste de contrôle 1 — lire dans le source la fonction de contrôle des données d’ORCA

Où trouver le source, et comment suivre cet article

À partir d’ici, nous lisons le source. N’importe qui peut faire de même chez soi ; indiquons donc d’abord le chemin à suivre.

• Comment l’obtenir : le source est publié sur la page d’information technique du projet ORCA. Chaque 1er du mois, le source tel qu’il était au 1er du mois précédent est publié sous forme d’archive tar (zip) ; pour la série 5.2, le fichier principal se trouve à https://ftp.orca.med.or.jp/pub/src/jma-receipt.r_5_2_branch.zip (le listing de répertoire n’étant pas disponible, récupérez-le via le lien de la page d’information technique).
• Fichiers ouverts à partir de ce chapitre : la structure de la fonction se trouve dans lddef/orca41.ld, les écrans dans screen/D0x.glade, le traitement de contrôle dans cobol/orca41/ et cobol/orcabt/, et la définition de la table de règles dans record/tbl_chk*.db et cobol/copy/CPCHK.INC.
• Comment s’y retrouver : une recherche en japonais dépend de l’encodage des caractères ; le plus sûr est donc de s’orienter d’abord à l’aide des identifiants alphanumériques.

# Structure de la fonction de contrôle des données (liste des écrans, batchs, API)
less lddef/orca41.ld

# Groupe de batchs contenant le corps de la logique de contrôle
ls cobol/orcabt/ORCDTCHK*.CBL

# Définition de la table de règles, et définition des champs avec commentaires en japonais
less record/tbl_chk.db
less cobol/copy/CPCHK.INC

Fixons aussi d’abord la terminologie des types de fichiers. Même sans connaître COBOL ou GTK, ces trois notions suffisent pour suivre.

La structure de la fonction

Le contrôle des données d’ORCA correspond au menu métier n° 41 ; dans le source, cela correspond au répertoire cobol/orca41/ et au fichier lddef/orca41.ld. La définition LD révèle directement la structure.

• Côté écrans : à partir de D01, « Instruction de contrôle du relevé de soins », on bifurque respectivement vers D02 « Instruction individuelle », D03 « Enregistrement des paramètres des postes de contrôle » et D04 « Confirmation du contenu des erreurs », tandis que D05 « Liste des paramètres d’exception » est appelé depuis D04 (les branchements se trouvent dans le traitement de transition d’ORCGD01.CBL et ORCGD04.CBL, et les noms d’écran peuvent être vérifiés dans le titre de chaque screen/D0x.glade).
• Côté moteur : le corps de la logique de contrôle ne se trouve pas côté écran, mais dans le groupe de programmes batch cobol/orcabt/ORCDTCHK000 à 011.CBL. Depuis l’écran, ORCGDSUB02.CBL lance ce batch comme job (identifiant shell ORCBSD1), ce qui sépare l’écran interactif du traitement de contrôle.
• Côté API : une API permettant de déclencher le contrôle des données depuis l’extérieur (ORCGDAPI01) est liée sous le nom bindapi "datacheckv3".

La définition de la requête de l’API (record/xml_data_checkv3req.db) est ce qui décrit le plus efficacement les spécifications d’entrée de cette fonction.

data_checkv3req {
    Request_Number             varchar(02);   -- 00=récupération d'informations / 01=exécution du contrôle / 02=vérification de l'état
    Karte_Uid                  varchar(36);   -- identifiant de l'appelant (obligatoire à l'exécution ; erreur si vide)
    Orca_Uid                   varchar(36);   -- identifiant de job (obligatoire pour la vérification d'état ; reçu dans la réponse d'exécution)
    Perform_Month              varchar(07);   -- année-mois de traitement ciblée
    Start_Day / End_Day        varchar(02);   -- plage de dates
    InOut                      varchar(01);   -- classification hospitalisation/ambulatoire
    Check_Insurance_Information { Id; }[6];   -- assurances ciblées (6 max)
    Check_Item_Information    { Id; }[22];    -- identifiants des postes de contrôle (22 max)
    Patient_Information { Patient_ID; }[100]; -- patients ciblés (100 max)
};

(La signification des valeurs de Request_Number se vérifie dans les définitions de constantes et les branchements d’ORCGDAPI01.CBL ; le contrôle d’obligation de Karte_Uid et Orca_Uid se vérifie dans ORCGDAPI01S01.CBL et ORCGDAPI01S02.CBL. L’exécution (01) tourne comme un job, et l’on suit sa progression avec la vérification d’état (02) en fournissant l’Orca_Uid reçu dans la réponse d’exécution — une conception asynchrone.)

Ce qui attire l’attention, c’est que Check_Item_Information est un tableau de 22 éléments. Le contrôle des données n’est pas une inspection unique, mais un ensemble d’inspections appelées « postes de contrôle », dont on choisit à l’exécution lesquelles lancer. L’écran de confirmation du contenu des erreurs (D04.glade) dispose aussi d’un mécanisme d’enregistrement d’exceptions, permettant de supprimer une erreur donnée en la marquant « ne pas contrôler (ce mois-ci) » ou « ne pas contrôler (toujours) » (les exceptions sont enregistrées dans la table tbl_chkreigai). C’est la forme d’un moteur de règles réellement exploitable, où les faux positifs peuvent être éliminés au fil de l’exploitation.

À titre indicatif, D04.glade contient comme données d’exemple « Pontal » (un antalgique antipyrétique) et « ulcère gastrique », avec la classification de check master « 1, médicament et diagnostic ». Même dans les données d’exemple d’une définition d’écran se trouve gravé le cas d’usage représentatif que nous verrons au chapitre suivant : le contrôle de correspondance entre médicament et diagnostic.

4. Le check master comme table de règles — la conception des tables de la famille tbl_chk

La connaissance de « ce qui est correct », telle que la détient le contrôle des données, se répartit en deux emplacements.

• Ce que porte la table de règles (le check master) : les correspondances entre médicaments et actes médicaux — indications approuvées, contre-indications, facturation combinée, etc. Ce n’est pas codé en dur dans COBOL, mais conservé comme données dans un ensemble de tables.
• Ce que porte le code du programme : les contrôles relatifs à la structure de base du dispositif, comme la cohérence de l’assurance, du numéro de symbole, ou du nombre réel de jours. Ils sont implémentés directement dans le groupe de batchs (ORCDTCHK*), et l’historique des modifications aligne d’ailleurs des ajouts côté code tels que « prise en charge du contrôle des données de numéro de branche » ou « prise en charge du contrôle des données de numéro d’assurance des accidents du travail ».

Autrement dit, croire que « maintenir le check master à jour suffit à modifier toutes les règles » est une erreur. La table de règles ne couvre que le premier domaine ; le second ne peut évoluer que par une modification du programme.

Sur cette base, voici les tables associées extraites de la liste des tables (lddef/orcadb.inc) :

La structure d’une règle se vérifie dans record/tbl_chk.db et dans la clause COPY cobol/copy/CPCHK.INC (dont les champs portent des commentaires en japonais). Réduite à l’essentiel, une ligne de règle a la forme suivante.

Classification de contrôle (CHKKBN) + code de soins (SRYCD) + période de validité (YUKOSTYMD à YUKOEDYMD)
  → ensemble de codes correspondants (CDKBN + CD), classification hospitalisation/ambulatoire, classification de traitement

Autrement dit, une règle déclarative du type « pour le code de soins X, durant la période Y, l’un des codes de l’ensemble Z doit lui correspondre (ou ne doit pas coexister avec lui) ». Les types de règles disponibles sont énumérés sur l’écran de sortie d’états du check master (screen/X91.glade).

• Médicament et diagnostic / diagnostic et médicament (correspondance des indications approuvées)
• Acte médical et diagnostic / diagnostic et acte médical
• Médicament et association contre-indiquée
• Médicament contre-indiqué et diagnostic
• Facturation combinée d’actes médicaux (même jour, même mois, même épisode de facturation)
• Actes non facturés entre eux
• Contrôle du nombre de facturations

Ce qui est intéressant, c’est que « médicament et diagnostic » et « diagnostic et médicament » forment une paire. Quand le sens s’inverse, ce que l’on cherche à détecter change aussi.

Attention toutefois : en implémentation, il ne s’agit pas d’une simple recherche inversée dans une seule table. La lecture du programme d’états (cobol/orca103/ORCHXLST.CBL) montre que, comme dans le tableau ci-dessus, ces règles sont gérées dans des tables et des clés distinctes : enregistrer un sens n’active pas automatiquement le sens inverse. Si les règles ont une période de validité, c’est pour que la table de règles suive les révisions bisannuelles de la rémunération des soins et les inscriptions/radiations du prix des médicaments — le principe vu au volet 1, « suivre le dispositif réglementaire est l’essence même d’un logiciel de facturation », traverse ainsi jusqu’à la conception de la table de règles.

Notez que toutes les règles ne rentrent pas dans cette forme unique. tbl_chksnd et tbl_chk005 ont une forme qui porte une chaîne de diagnostic (BYOMEI) et la gestion des diagnostics suspectés, tandis que tbl_chktrd a une forme qui porte une classification même jour / même mois (DAYMONTHKBN) : la table de règles elle-même est normalisée sous des formes différentes selon le type de contrôle. Le terme « table de règles » ne renvoie donc pas à un schéma unique — un point à garder en tête en lisant l’implémentation.

5. Contrôles à la saisie et API — le contrôle ne se limite pas à la fin de mois

Le contrôle des données est une inspection par batch mensuel, mais ce n’est pas la seule forme de contrôle. Le source révèle aussi des mécanismes qui fonctionnent plus en amont — au moment même de la saisie quotidienne.

• API de contrôle des associations contre-indiquées : /api01rv2/contraindicationcheckv2 (programme responsable ORAPI021R4V2, « restitution des informations sur les médicaments en association contre-indiquée » ; la date de création dans l’en-tête est 2016). En lui passant un patient et un médicament, elle renvoie les informations d’association contre-indiquée applicables — une API qui permet de construire une intégration où le dossier médical électronique interroge Nichi-Rece au moment même de la saisie de la prescription.
• API de contrôle des données : datacheckv3, vu au chapitre précédent. Comme le batch mensuel peut être lancé sans opération à l’écran, on peut mettre en place un fonctionnement du type « contrôler automatiquement chaque nuit les données du mois en cours, et produire une liste d’erreurs le lendemain matin ».

Il y a ici une leçon de conception universelle : plus une erreur est capturée près de sa source, moins coûteuse est sa correction. Une erreur trouvée par le contrôle des données en fin de mois doit être corrigée pour tout un mois d’un coup, alors qu’une association contre-indiquée repérée au moment de la saisie de la prescription se règle en quelques secondes (notez que cette API ne surveille que les associations contre-indiquées : les contrôles de correspondance, comme l’absence d’indication approuvée, restent du ressort du contrôle mensuel des données et ne sont pas pris en charge à la saisie). Le fait que le dispositif de contrôle d’ORCA soit multi-étages — « saisie (API) → mensuel (contrôle des données) → avant soumission (contrôle rece-den) » — est la mise en œuvre de ce principe.

6. Poste de contrôle 2 — le contrôle des données rece-den, l’inspection des données de facturation

Alors que le contrôle des données examine « la cohérence du contenu des soins », un autre contrôle attend juste avant la soumission : le contrôle des données rece-den. Il porte sur le fichier de relevé électronique (rece-den) et vérifie la validité en tant que données de facturation : format d’enregistrement, présence des enregistrements obligatoires, etc.

Les conditions de ce contrôle sont publiées en PDF sur le site officiel d’ORCA sous le titre « Spécification des conditions de contrôle des données rece-den » (en trois variantes : assurance maladie, accidents du travail, et suivi post-traitement). Autrement dit, ORCA ne se contente pas de publier le contrôle du contenu (dont le check master peut être vérifié via des états ou du CSV) : il publie aussi comme document la spécification des conditions du contrôle rece-den, ce qui permet de vérifier « ce qui est contrôlé » à partir d’une source primaire.

Il n’est toutefois pas exact de considérer le contrôle rece-den comme « une simple inspection de forme ». La lecture du source montre qu’un sous-programme vérifiant les exigences de saisie des commentaires du relevé (cobol/common/ORCSRECECOMCHK.CBL, ajouté en 2018) et un contrôle de l’historique de facturation des honoraires de gestion et de conseil liés notamment à la téléconsultation (ORCSRECESRCHK.CBL) sont implémentés côté traitement rece-den, et que le script Ruby du traitement mensuel (dans le dépôt, scripts/monthly/receden_check.rb.in — un modèle installé sous le nom receden_check.rb) va jusqu’à vérifier la cohérence avec le master des points et le master des diagnostics (la cohabitation de Ruby au sein d’un monde COBOL est d’ailleurs un des charmes de ce source). Grossièrement, la répartition est « contrôle des données = contenu des soins, contrôle rece-den = données de facturation », mais la frontière n’est pas stricte, et une partie du contrôle sémantique relève du contrôle rece-den — s’en tenir trop rigidement à cette répartition fait mal identifier l’origine d’une erreur. En pratique, l’essentiel est que ce n’est qu’après avoir passé les deux qu’un relevé devient « prêt à être soumis à l’examen ».

7. Postes de contrôle 3 et 4 — les contrôles informatiques de l’organisme d’examen et de paiement, le contrôle de concordance et le contrôle longitudinal

Le relevé soumis entre alors dans le circuit d’examen de l’organisme d’examen et de paiement (la Caisse de paiement pour l’assurance des salariés, les Fédérations d’assurance maladie pour l’assurance maladie nationale et les personnes âgées de fin de vie). Ce qui compte ici, c’est qu’une partie des règles de contrôle côté examen est elle aussi publiée.

Sur la page « Publication relative aux contrôles informatiques » de la Caisse de paiement, deux types de fichiers sont mis à disposition (tous deux au format CSV, avec un périmètre élargi progressivement).

Remarquez le nom : la Caisse de paiement utilise elle aussi le terme « check master ». Cette structure qui gère séparément les règles fondées sur les avis/circulaires et celles fondées sur les notices correspond, terme à terme, à celle d’ORCA, où les règles de calcul des points vivent dans le programme et les indications de médicaments dans le check master.

Il existe cependant des contrôles non publiés. La page de publication indique explicitement que la publication des cas nécessitant une vérification de la colonne des remarques, des cas nécessitant un jugement médical, et des cas relatifs aux indications de médicaments ou d’actes médicaux, sera examinée avec prudence. La Caisse de paiement explique aussi de manière répétée que le contrôle informatique se contente de signaler les éléments suspects : il ne minore pas mécaniquement, mais passe par le contrôle du personnel et la décision de la commission d’examen. « Contrôle informatique = minoration automatique » est faux, et c’est un point que les personnes côté système doivent comprendre précisément.

Et puis il y a le contrôle de concordance et le contrôle longitudinal évoqués au chapitre 2. Ces deux contrôles, montés en puissance à partir de 2012, ne sont pas des inspections d’un relevé isolé, mais des inspections des relations entre relevés. Traçons ici la frontière avec précision. Le contrôle de concordance (rapprochement du relevé médical et du relevé pharmaceutique d’un même patient) a pour contrepartie le relevé d’un autre organisme, la pharmacie d’officine : il ne peut donc, par principe, pas être remplacé par un contrôle interne à l’établissement de santé. En revanche, l’équivalent du contrôle longitudinal (comparaison du mois en cours et des mois passés pour un même patient) est possible en interne, dans la limite de l’historique de facturation de son propre établissement. Gérer rigoureusement, dans ses propres données, les facturations soumises à une limite de fréquence et les diagnostics correspondant aux prescriptions externes, constitue la mesure réaliste pour réduire les signalements issus du contrôle de concordance et du contrôle longitudinal.

8. Les deux côtés partagent la structure « table de règles + moteur » — la carte de l’ingénieur

En condensant tout ce qui précède sur une seule page, le monde du contrôle des relevés de soins se présente ainsi.

La structure est isomorphe ; ce qui diffère, c’est l’exhaustivité des règles et le périmètre d’inspection. On peut en tirer trois conclusions du point de vue de l’ingénieur.

1. La séparation les règles sont des données, le moteur est un programme a été une condition indispensable pour suivre les révisions réglementaires pendant plus de vingt ans. Si les règles avaient été noyées dans le code, chaque révision aurait exigé une refonte complète.
2. Dans le domaine piloté par le check master (indications approuvées, contre-indications, etc.), la précision du contrôle côté établissement dépend moins de l’intelligence du moteur que de la richesse de la table de règles (pour les contrôles implémentés dans le code, comme l’assurance ou le nombre réel de jours, le périmètre du programme lui-même détermine directement la capacité de détection). Le check master d’ORCA comporte deux filières, la partie fournie (tbl_chk_master) et la partie enregistrée par l’utilisateur (tbl_chk_user) : la conception permet donc à chaque établissement d’ajouter ses propres règles. La valeur des logiciels commerciaux de contrôle des relevés de soins tient elle aussi, au fond, à la richesse de leur table de règles propriétaire.
3. Maintenant qu’une partie des règles côté examen est publiée, « comment intégrer les règles publiées côté examen dans son propre contrôle » devient un nouveau sujet pratique. Le fait qu’elles soient fournies sous une forme lisible par machine, en CSV public, est une portée qu’un ingénieur ne saurait ignorer.

9. Points pratiques — ce que le système peut faire pour améliorer la précision du contrôle

Voici, du point de vue du responsable système d’un établissement de santé ou d’un prestataire d’intégration, les points à retenir.

1. Faire correspondre la structure multi-étages du contrôle avec l’exploitation. Les trois étages — saisie (API des associations contre-indiquées, etc.), mensuel (contrôle des données), avant soumission (contrôle rece-den) — ont des rôles différents. Si votre pratique se limite à « lancer le contrôle des données une fois en fin de mois », il reste de la marge pour exploiter les deux étages en amont.
2. Le contrôle des données peut être automatisé via l’API. Avec datacheckv3, on peut mettre en place une exécution périodique en spécifiant les postes de contrôle et les patients ciblés. En optant pour un batch nocturne suivi d’une liste d’erreurs le matin, la charge de contrôle de fin de mois se répartit au quotidien.
3. Traiter l’enregistrement d’exceptions comme un « réglage des règles ». Laisser des faux positifs sans les traiter finit par faire ignorer la liste d’erreurs. Maintenir méthodiquement les exceptions (tbl_chkreigai) et les règles propres à l’établissement (tbl_chk_user) pour préserver un bon rapport signal/bruit de la liste d’erreurs est la ligne de vie du travail de contrôle.
4. Reboucler les résultats de renvoi et de minoration dans une boucle d’analyse. Agréger les motifs des avis de rectification des points et refléter les schémas récurrents dans les règles propres à l’établissement du check master ou dans la pratique à la saisie — c’est cela, « faire grandir la table de règles », et c’est la seule façon de réduire l’écart de perception avec le côté examen.
5. Consulter régulièrement les documents publiés côté examen. La publication des contrôles informatiques de la Caisse de paiement continue d’être mise à jour. À une époque où le côté examen explique officiellement « ce qu’il regarde », explications du contrôle de concordance et du contrôle longitudinal comprises, il n’y a aucune raison de ne pas les lire.

10. En résumé

• Un relevé de soins traverse une série de postes de contrôle multi-étages : ① le contrôle du contenu par le logiciel de facturation → ② le contrôle des données rece-den → ③ les contrôles informatiques côté examen (+ contrôle de concordance et contrôle longitudinal) → ④ le personnel et la commission d’examen. Le renvoi est un retour, la minoration une réduction de points, et le contrôle de concordance, qui rapproche le relevé d’un autre organisme, ne peut pas être remplacé en interne à l’établissement de santé (la comparaison avec ses propres mois passés, elle, est possible en interne).
• Le contrôle des données d’ORCA est implémenté comme la fonction orca41, et les règles d’indications approuvées, de contre-indications, de facturation combinée, etc. sont conservées comme données dans le check master (la cohérence de base, comme l’assurance ou le nombre réel de jours, reste côté code). On sélectionne les postes de contrôle à exécuter, on supprime les faux positifs par enregistrement d’exceptions, et on peut le piloter depuis l’extérieur via l’API datacheckv3 — tout cela se vérifie dans le source public.
• Le côté examen publie lui aussi sa table de règles — conditions de contrôle du siège + check master — en CSV, si bien que l’établissement de santé et l’examen partagent la même structure « table de règles + moteur ». La différence réside dans l’exhaustivité des règles et le périmètre d’inspection (seul le côté examen peut voir tous les établissements et tous les mois).
• Ce qui détermine la précision du contrôle, ce n’est pas le moteur, mais la richesse de la table de règles et la façon dont elle est exploitée. L’enregistrement d’exceptions, les règles propres à l’établissement, une boucle d’analyse des résultats de minoration, et l’intégration des règles publiées côté examen, sont les points pratiques essentiels.

Les prochains volets de la série sont prévus pour aborder un « volet base de données » lisant directement le schéma d’ORCA, ainsi que la pratique d’une veille automatisée par diff pour suivre les publications mensuelles du source.

11. Références

• Publication relative aux contrôles informatiques — Caisse de paiement des honoraires médicaux de l’assurance sociale (publication en CSV des conditions de contrôle du siège et du check master)
• Contrôle de concordance et contrôle longitudinal — Caisse de paiement des honoraires médicaux de l’assurance sociale
• Contrôle, examen, renvoi, minoration, demande de réexamen des relevés de soins, etc. — Association médicale de Tokyo, « Points clés de la pratique médicale assurée à l’usage des praticiens libéraux »
• Manuel de l’édition ambulatoire du logiciel de facturation standard de l’Association médicale japonaise (rubriques relatives au contrôle des données) — ORCA Project
• Spécification des conditions de contrôle des données rece-den — ORCA Project
• Informations techniques — ORCA Project (publication mensuelle du code source, documents de définition des tables de la base de données)
• Code source du cœur de Nichi-Rece, série 5.2 (instantané publié en juillet 2026) : lddef/orca41.ld / cobol/orca41/ORCGD*.CBL / cobol/copy/CPCHK.INC / record/tbl_chk*.db / record/xml_data_checkv3req.db / screen/D01.glade / screen/D04.glade / screen/X91.glade / lddef/api01rv2.ld (contraindicationcheckv2) et autres — toutes les descriptions relatives à l’implémentation dans cet 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.

Quelle est la différence entre la minoration et le renvoi ?

Les deux termes concernent l'examen mené par les organismes d'examen et de paiement (la Caisse de paiement des honoraires médicaux pour l'assurance des salariés, les Fédérations d'assurance maladie nationale pour l'assurance maladie nationale), mais leur sens diffère. Le renvoi signifie que le relevé de soins est renvoyé à l'établissement de santé : après correction d'une erreur de saisie ou d'un problème d'éligibilité, il peut être re-soumis à partir du mois suivant. La minoration signifie que, à l'issue de l'examen, le nombre de points est ajusté à la hausse ou à la baisse (en pratique, presque toujours à la baisse), ce qui réduit d'autant le montant facturé. En cas de désaccord avec une minoration, il existe une procédure de demande de réexamen.

Combien de fois un relevé de soins est-il contrôlé avant sa soumission ?

Globalement, il traverse plusieurs étages de contrôle. À l'intérieur de l'établissement de santé : le contrôle du contenu par le logiciel de facturation (chez ORCA, la fonction de contrôle des données), puis le contrôle des données rece-den, qui vérifie le fichier de relevé électronique en tant que données de facturation. Après soumission : les contrôles informatiques de l'organisme d'examen et de paiement (conditions de contrôle fondées sur les avis et circulaires officiels, et check masters fondés sur les notices des médicaments), le contrôle de concordance qui rapproche les relevés médicaux et pharmaceutiques d'un même patient, et le contrôle longitudinal qui compare avec les mois de facturation passés, avant l'examen mené par le personnel et la commission d'examen.

Comment le contrôle des relevés de soins est-il implémenté dans ORCA (Nichi-Rece) ?

Elle est implémentée comme la fonction de contrôle des données (menu métier 41), et l'implémentation peut être vérifiée dans le code source public. Les règles de correspondance entre médicaments et actes médicaux (médicament et diagnostic, acte médical et diagnostic, associations médicamenteuses contre-indiquées, etc.) sont conservées comme données dans un ensemble de tables appelé « check master », qu'un programme COBOL interprète pour contrôler les données du patient — une structure « table de règles + moteur ». Les contrôles de base, comme la cohérence de l'assurance ou du nombre réel de jours de traitement, sont implémentés directement côté programme. Un enregistrement d'exceptions (« ne pas contrôler cette erreur ») et une API permettant de déclencher le contrôle des données depuis un système externe (datacheckv3) sont également disponibles.

Les règles de contrôle des organismes d'examen et de paiement sont-elles publiées ?

Une partie l'est. Sous le titre « Publication relative aux contrôles informatiques », la Caisse de paiement publie sous forme de fichiers CSV les conditions de contrôle du siège fondées sur les avis et circulaires officiels, ainsi que les check masters fondés sur les notices des médicaments, et elle élargit progressivement leur champ. Le fonctionnement du contrôle de concordance et du contrôle longitudinal est également expliqué sur le site officiel. Cela dit, certains contrôles ne sont pas publiés, comme les cas nécessitant une vérification de la colonne des remarques ou un jugement médical.

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.