Ce que l'ordonnance électronique change pour le système de facturation médicale ── Lire le support de l'ordonnance électronique d'ORCA à travers son code source

L’ordonnance électronique, dont l’exploitation a débuté en janvier 2023, est souvent présentée comme le deuxième volet de la transformation numérique de la santé, après la vérification d’éligibilité en ligne. Mais concrètement, que signifie le support de l’ordonnance électronique pour un système de facturation médicale ? Dire simplement qu’il s’agit de « numériser le formulaire de l’ordonnance » ne suffit pas pour en faire la conception.

Le premier article a traité du rôle du système de facturation médicale, le deuxième de l’API 日レセ, le troisième de la vérification d’éligibilité en ligne, et le quatrième de la vérification des feuilles de soins. Ce cinquième article dissèque l’ordonnance électronique du point de vue du système de facturation médicale.

• Comment le flux de la prescription change-t-il avec l’ordonnance électronique (compréhension minimale du dispositif réglementaire) ?
• Le panorama complet du support d’ORCA (日レセ) ── la répartition des responsabilités entre le corps du logiciel et les programmes compatibles
• La conception de tbl_shoho_kanri, qui gère l’identifiant d’ordonnance, le numéro d’échange et le renouvellement
• La connexion entre dispositifs réglementaires : le mode de délivrance souhaité arrive depuis la vérification d’éligibilité en ligne

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 de l’ORCA Project officiel ; les éléments relatifs au code source reposent sur une lecture effective du code source public du 日レセ, branche 5.2 (instantané publié le 1er juillet 2026) (les modalités d’obtention du code source sont récapitulées au point 5 du chapitre 8).

Comment lire cet article

Le public visé est constitué des ingénieurs de fournisseurs qui développent des systèmes destinés aux établissements de santé (dossier médical électronique, aide à la prescription, accueil, systèmes de service, etc.), ainsi que des responsables informatiques qui, en interne, gèrent leur intégration. Aucune connaissance préalable de la tarification des soins ou de l’administration médicale n’est présupposée, mais une connaissance générale des bases de données relationnelles et de l’intégration par API l’est.

Ce qui se lit de façon autonome dans cet article : l’ossature du dispositif réglementaire de l’ordonnance électronique (chapitre 2), la répartition des responsabilités chez ORCA (chapitre 4), la conception de la table de gestion des prescriptions (chapitre 5), l’intégration CSV et les formulaires imprimés (chapitre 6), l’environnement de validation pour les fournisseurs (chapitre 8) se lisent tels quels sans avoir lu le reste de la série.

Environnement présupposé : les descriptions de définitions de table et de code source de cet article reposent sur le 日レセ, branche 5.2 (édition WebORCA sur site, instantané de code source publié le 1er juillet 2026). La base de données du 日レセ est PostgreSQL ; la mise en place de l’édition WebORCA sur site utilise l’utilisateur de base de données orca et l’encodage UTF-8 (la version de PostgreSQL suit l’OS ; pour Ubuntu 22.04 LTS, pour laquelle une procédure officielle est fournie, il s’agit de la version 14). Les noms commençant par tbl_ qui apparaissent dans le texte désignent des tables sur ce PostgreSQL.

Les articles à lire en premier pour aller plus vite : le texte s’appuie sur les 4 articles suivants comme prérequis. Il n’est pas nécessaire de tous les lire depuis le début ; il suffit d’y revenir quand une référence apparaît.

Correspondance des désignations et abréviations : fixons d’abord les termes dont l’appellation varie facilement entre les documents officiels et le texte.

Sommaire

1. La conclusion, d’abord ── l’ordonnance passe de « ce qu’on remet » à « ce qu’on va chercher »
2. Compréhension minimale du dispositif ── le service de gestion des ordonnances électroniques et le numéro d’échange
3. Préhistoire ── l’ordonnance portait un code QR dès 2001
4. Le panorama complet du support d’ORCA ── la répartition des responsabilités entre le corps du logiciel et les programmes compatibles
5. Lire tbl_shoho_kanri ── les attributs électroniques que porte une ordonnance
6. La sortie des données ── le CSV et les formulaires de l’ordonnance électronique
7. La connexion avec la vérification d’éligibilité ── le mode de délivrance arrive depuis la vérification d’éligibilité
8. Pour les fournisseurs ── comment préparer un environnement de validation
9. Points pratiques pour qui développe un système d’intégration
10. Conclusion
11. Références

1. La conclusion, d’abord ── l’ordonnance passe de « ce qu’on remet » à « ce qu’on va chercher »

L’ordonnance papier était une « intégration de données remise en main propre » : l’établissement l’imprimait, le patient l’apportait à la pharmacie. Avec l’ordonnance électronique, ce flux s’inverse.

flowchart LR
    subgraph clinic["Établissement de santé"]
        DR["Prescription du médecin"]
        RC["Système de facturation médicale / dossier médical électronique<br/>(chez ORCA, gère les données de prescription)"]
        SIGN["Programme compatible ordonnance électronique<br/>+ module de signature électronique distinct<br/>(signature électronique, envoi)"]
        DR --> RC --> SIGN
    end
    SIGN -->|"Enregistrement des données d'ordonnance"| EPS["Service de gestion des ordonnances électroniques<br/>(Fonds de paiement des soins, Fédération nationale des assurances maladie)"]
    EPS -->|"Numéro d'échange (pour le patient)"| PT["Patient<br/>(carte d'assurance maladie My Number ou numéro d'échange)"]
    PT --> PH["Pharmacie"]
    EPS -->|"Récupération des données d'ordonnance"| PH
    PH -->|"Enregistrement du résultat de délivrance"| EPS2["(vers le service de gestion)<br/>base pour la vérification des doubles prescriptions"]

• L’établissement de santé enregistre les données d’ordonnance auprès du service de gestion des ordonnances électroniques (géré, comme la vérification d’éligibilité en ligne, par le Fonds de paiement des soins et la Fédération nationale des assurances maladie).
• Au lieu de transporter du papier, le patient se fait accueillir en pharmacie avec sa carte d’assurance maladie My Number, ou communique son numéro d’échange (avec les informations de la carte d’assuré, etc.).
• La pharmacie va chercher les données d’ordonnance auprès du service de gestion, et y enregistre le résultat de la délivrance.

Du point de vue du système de facturation médicale, l’essentiel tient en deux points. Premièrement, l’ordonnance n’est plus un document imprimé qui se termine à l’intérieur de l’établissement, mais devient une donnée structurée enregistrée auprès d’un service externe. Deuxièmement, comme les résultats de prescription et de délivrance se centralisent auprès du service de gestion, la vérification des doubles prescriptions au-delà des établissements et des pharmacies devient possible. Le 4e article affirmait qu’« en principe, le rapprochement avec les données d’autres organismes est impossible en interne à l’établissement » ; on peut situer l’ordonnance électronique comme l’infrastructure nationale qui franchit ce mur dans le domaine de la prescription (non pas au moment de la vérification, mais au moment même de la prescription).

2. Compréhension minimale du dispositif ── le service de gestion des ordonnances électroniques et le numéro d’échange

Récapitulons uniquement les points essentiels du dispositif réglementaire.

• Depuis quand : exploitation débutée en janvier 2023. Le mécanisme repose sur le réseau et le socle de la vérification d’éligibilité en ligne, et les établissements compatibles s’étendent progressivement.
• Méthode d’identification de l’ordonnance : une ordonnance électronique émise se voit attribuer un identifiant d’ordonnance. Si le patient se fait accueillir en pharmacie avec sa carte d’assurance maladie My Number, il sélectionne et identifie l’ordonnance électronique concernée sur le lecteur de carte (une étape de sélection existe en cas de pluralité) ; s’il n’utilise pas la carte, il communique à la pharmacie le numéro d’échange et les informations de la carte d’assuré, etc. pour l’identifier (le numéro d’échange seul ne permet pas l’identification).
• Vérification des doubles prescriptions : comme les informations de prescription et de délivrance s’accumulent auprès du service de gestion, le médecin et le pharmacien peuvent, au moment même de la prescription, consulter un résultat de vérification rapproché des données récentes de prescription et de délivrance.
• Ordonnance à renouvellement : introduite par la révision tarifaire de l’exercice 2022, elle peut être utilisée de façon répétée dans une période donnée. L’ordonnance électronique s’accorde bien avec la gestion des utilisations répétées d’un renouvellement, et comme on le verra plus loin, des champs de renouvellement sont bien intégrés dans les tables d’ORCA.

Comment les identifiants circulent entre l’hôpital et la pharmacie

La structure de l’ordonnance électronique se comprend le mieux en suivant, dans l’ordre chronologique de l’émission à la délivrance, entre les mains de qui passent les trois identifiants : identifiant d’ordonnance, numéro d’échange et informations de l’assuré.

sequenceDiagram
    participant MED as Établissement de santé<br/>(ORCA + module d'ordonnance électronique/de signature)
    participant EPS as Service de gestion<br/>des ordonnances électroniques
    participant PT as Patient
    participant PH as Pharmacie
    Note over MED: Confirmation de la prescription, signature électronique
    MED->>EPS: Enregistrement des données d'ordonnance (informations de l'assuré incluses)
    EPS-->>MED: Émission de l'identifiant d'ordonnance + numéro d'échange
    Note over MED: Enregistrement dans tbl_shoho_kanri<br/>Impression du numéro d'échange sur le talon
    MED-->>PT: Remise du talon (numéro d'échange)
    alt Accueil avec carte d'assurance maladie My Number
        PT->>PH: Présente la carte My Number<br/>sélectionne l'ordonnance concernée sur le lecteur
        PH->>EPS: Interrogation avec les informations de l'assuré
    else Accueil avec numéro d'échange
        PT->>PH: Communique le numéro d'échange + les informations de la carte d'assuré, etc.
        PH->>EPS: Interrogation avec le numéro d'assuré, etc. + le numéro d'échange
    end
    EPS-->>PH: Retourne les données d'ordonnance (géré en interne par l'identifiant d'ordonnance)
    PH->>EPS: Enregistrement du résultat de délivrance

Ce schéma appelle deux observations.

Premièrement, les données d’intégration système ne passent jamais directement de l’hôpital à la pharmacie. La donnée originale de l’ordonnance transite toujours par le service de gestion. Ce que transporte le patient est une « clé » (carte d’assurance maladie My Number ou numéro d’échange) ; il peut aussi recevoir et transporter un papier récapitulant le contenu de la prescription (le talon), mais ce talon n’est qu’une information de référence : la donnée originale utilisée par la pharmacie pour la délivrance est récupérée auprès du service de gestion. Il n’est pas nécessaire de construire une intégration point à point entre l’hôpital et la pharmacie ; en contrepartie, la qualité de l’intégration de chacun avec le service de gestion devient déterminante.

Deuxièmement, les rôles des trois identifiants sont clairement distincts.

C’est dans la table de gestion des prescriptions, décrite plus loin, que subsiste, côté ORCA, la trace de cet aller-retour. L’identifiant d’ordonnance et le numéro d’échange retournés par le service de gestion au moment de l’émission y sont stockés tels quels (PRESCRIPTIONID · ACCESSCODE), et utilisés pour l’impression sur le talon comme pour le rapprochement lors d’une annulation ou d’une modification.

3. Préhistoire ── l’ordonnance portait un code QR dès 2001

La « numérisation des données de l’ordonnance » n’est en réalité pas un sujet nouveau. Le code source d’ORCA contient un programme cobol/common/ORCSQRCSV.CBL intitulé « Sortie des données QR de l’ordonnance », dont la date de création est septembre 2001. Le mode opératoire consistant à imprimer un code QR sur l’ordonnance papier, que le système côté pharmacie lit puis importe dans le système de délivrance, existait déjà il y a plus de vingt ans.

Autrement dit, ce que l’ordonnance électronique a apporté n’est pas la « numérisation », mais la standardisation du lieu de stockage et du canal de récupération des données. Le code QR était une « donnée valable pour ce seul exemplaire », imprimée sur le papier, tandis que l’ordonnance électronique est enregistrée auprès d’un service de gestion commun à l’échelle nationale, où n’importe qui (dans la limite de ses droits) peut la récupérer via l’identifiant d’ordonnance. C’est cette différence qui rend possible une fonction transversale comme la vérification des doubles prescriptions. La coexistence, dans le code source, de ces deux mécanismes, ancien et nouveau, est une image bien caractéristique d’un système de facturation médicale en période de transition.

4. Le panorama complet du support d’ORCA ── la répartition des responsabilités entre le corps du logiciel et les programmes compatibles

Selon la page officielle (« Ordonnance électronique du 日医標準レセプトソフト »), le support de l’ordonnance électronique d’ORCA se compose du 日レセ lui-même + des programmes compatibles avec l’ordonnance électronique (API d’ordonnance électronique). La lecture du code source public de la branche 5.2 permet de confirmer cette ligne de partage dans l’implémentation elle-même.

La dernière ligne est la plus intéressante. La signature électronique, pourtant le point technique saillant de l’ordonnance électronique, n’apparaît nulle part dans les 4 millions de lignes du 日レセ lui-même. Le corps du logiciel se consacre exclusivement à « rester la source de vérité des données de prescription », tandis que le domaine à évolution rapide de la signature et de la communication est isolé dans des programmes séparés ── c’est le même schéma de répartition que l’on a observé pour l’intégration de la vérification d’éligibilité en ligne au 3e article (le corps du logiciel porte l’API et les tables, l’échange de fichiers est confié à onshi-tools). On peut y voir une conception qui découple les évolutions de spécification côté infrastructure nationale du cycle de publication du corps du logiciel.

Alors, qu’y a-t-il du côté isolé ? Voici la composition des programmes compatibles listés sur la page officielle.

L’OS pris en charge varie selon le composant : le module d’ordonnance électronique et l’assistant étendu d’ordonnance électronique sont réservés à Windows 11 (x64), tandis que l’écran de saisie de prescription fonctionne sous Windows, Mac et Ubuntu (le support Ubuntu étant réservé à l’édition WebORCA sur site). Dans la planification des postes en établissement, prêtez attention au fait que les modules d’émission présupposent Windows. Et le partage de la signature est le point important : la page officielle précise explicitement que « pour introduire l’ordonnance électronique, un module de signature électronique séparé est nécessaire ». Le module de signature électronique vérifié (fourni par I-O DATA DEVICE, Mitsubishi Electric IT Solutions) prend en charge la signature locale via carte HPKI (HPKI = infrastructure à clé publique du secteur de la santé, du médical et du social ; une carte à puce contenant un certificat électronique qui peut attester une qualification nationale comme celle de médecin) ainsi que la signature à distance (authentification FIDO, authentification par carte HPKI, authentification par carte My Number). Autrement dit, la question la plus mouvante de l’ordonnance électronique ── « comment faire aboutir la signature électronique du médecin » ── est isolée à la fois du 日レセ lui-même et du module d’ordonnance électronique, absorbée dans une couche dédiée de module de signature. C’est la réponse à la raison pour laquelle HPKI n’apparaît pas dans le code source du corps du logiciel.

Quand un dossier médical électronique est présent, qui est le sujet de l’émission ?

Les schémas précédents réduisaient l’intérieur de l’établissement à un seul flux, mais dans la réalité, une configuration où le dossier médical électronique et le système de facturation médicale coexistent est fréquente. Dans ce cas, le chemin par lequel la prescription parvient jusqu’à la pharmacie (le service de gestion) se répartit essentiellement en deux motifs.

En schéma, la différence entre les deux motifs se résume à « de quel côté se trouve le bloc de signature et d’enregistrement ».

flowchart TB
    subgraph A["Motif A : ORCA comme sujet de l'émission"]
        direction LR
        EMRA["Dossier médical électronique<br/>(commande)"] -->|"API 日レセ"| ORCAA["ORCA<br/>tbl_shoho_kanri"]
        ORCAA --> MODA["Module d'ordonnance électronique<br/>+ module de signature électronique"]
        MODA -->|"Enregistrement"| EPSA["Service de gestion<br/>des ordonnances électroniques"]
    end
    subgraph B["Motif B : le dossier médical électronique comme sujet de l'émission"]
        direction LR
        EMRB["Dossier médical électronique<br/>(support propre d'ordonnance électronique + signature)"] -->|"Enregistrement"| EPSB["Service de gestion<br/>des ordonnances électroniques"]
        EMRB -->|"Transmission de la prescription pour facturation"| ORCAB["ORCA<br/>(création de la feuille de soins)"]
    end

La trace du motif A subsiste clairement dans le code source. Le champ de type d’origine de l’émission (HAKKOKBN) de la table de gestion des prescriptions vue au chapitre 5 comporte une valeur « Envoi de données intermédiaires par API » (confirmé dans le commentaire de la clause COPY CPSHOHO-KANRI.INC) : une prescription envoyée depuis le dossier médical électronique via l’API est gérée dans la même table qu’une prescription saisie à l’écran d’ORCA. La conception « l’API est la version API des écrans métier », vue au 2e article, reste bien vivante sur le chemin d’émission de l’ordonnance électronique.

Dans les deux motifs, il n’existe aucun traitement qui « envoie » vers la pharmacie. Côté pharmacie, c’est le système de facturation de la pharmacie ou le système de délivrance qui récupère les données d’ordonnance auprès du service de gestion (concernant l’intégration à l’intérieur du système de la pharmacie, le ministère de la Santé publie une documentation sur les données d’intégration entre le système de facturation de la pharmacie et le dossier de délivrance électronique). Le premier choix de conception que doit trancher le fournisseur côté établissement est de savoir où placer le point de départ de l’émission, de la signature et de l’annulation, côté dossier ou côté ORCA, puis, en fonction de cette décision, qui doit porter une gestion équivalente à tbl_shoho_kanri afin que l’identifiant d’ordonnance et le numéro d’échange puissent être rapprochés des données de facturation.

5. Lire tbl_shoho_kanri ── les attributs électroniques que porte une ordonnance

Le centre du côté 日レセ lui-même est la table de gestion des prescriptions tbl_shoho_kanri. Voici les principaux champs, extraits de la définition (record/tbl_shoho_kanri.db) et des commentaires japonais de la clause COPY.

tbl_shoho_kanri {
    TBL_UUID          varchar(36);  -- uuid d'identification
    RENNUM            number(1);    -- numéro de série (la clé primaire est HOSPNUM+TBL_UUID+RENNUM)
    SRYYMD / PTID / SRYKA / HKNCOMBI  -- date de soins, patient, service, combinaison d'assurance
    SHOHO_KEITAI      varchar(1);   -- type d'émission de l'ordonnance (électronique/papier)
    PRESCRIPTIONID    varchar(36);  -- identifiant d'ordonnance
    ACCESSCODE        varchar(16);  -- numéro d'échange
    REFILL_NUM        number(1);    -- nombre de renouvellements
    REFILL_ZAIKAISU   number(3);    -- durée en jours du renouvellement
    CANCEL_TIME / CANCEL_UNDO_TIME  -- date/heure d'annulation de l'ordonnance et d'annulation de l'annulation
    CHANGE_TIME / CHANGE_UNDO_TIME  -- date/heure de modification et d'annulation de la modification
};

Cette seule table laisse transparaître la réalité opérationnelle de l’ordonnance électronique.

• Elle possède une paire de zones pour l’identifiant d’ordonnance (36 chiffres) et le numéro d’échange (16 chiffres). Les clés correspondant aux deux modes de réception vus au chapitre 2 (carte My Number/numéro d’échange) figurent directement comme attributs de l’enregistrement (notez que le numéro d’échange, en exploitation actuelle, fait 6 chiffres, et que les 16 chiffres sont la capacité de la colonne ; il serait plus sûr de ne pas implémenter le nombre de chiffres comme une valeur figée).
• L’annulation et la modification ont chacune une date/heure d’UNDO. L’ordonnance électronique étant une donnée déjà enregistrée auprès du service de gestion, annuler une prescription en interne exige aussi d’en annuler l’enregistrement, et il peut même arriver qu’on annule cette annulation (opération de restauration). Ce qui, à l’époque du papier, consistait à « déchirer et réécrire » est devenu une gestion de transitions d’état.
• Le renouvellement est un attribut dès l’origine. Le nombre de renouvellements et le nombre de jours de prescription figurent parmi les champs de base de la gestion des prescriptions : une gestion de cycle de vie présupposant une utilisation répétée est intégrée dès la conception.

Notez que l’usage d’un uuid pour l’identification est un idiome commun avec la table liée à la vérification d’éligibilité en ligne (tbl_onshi_kaku) du 3e article. La clé primaire n’est cependant pas l’uuid seul, mais une clé composite numéro d’établissement + uuid + numéro de série (RENNUM), une conception où plusieurs lignes peuvent être rattachées au même uuid. Lorsqu’un système d’intégration manipule des données équivalentes à cette table, prenez garde : considérer l’uuid seul comme clé de ligne écraserait les lignes multiples.

6. La sortie des données ── le CSV et les formulaires de l’ordonnance électronique

Avant d’aborder la table du chapitre 5 et la connexion à la vérification d’éligibilité du chapitre 7, résumons d’abord en un schéma comment les données circulent à l’intérieur d’ORCA.

flowchart LR
    ONS["Vérification d'éligibilité en ligne<br/>(à l'accueil)"] -.->|"Mode de délivrance souhaité<br/>SHO_SHOHO_KEITAI"| TBL
    NYURYOKU["Saisie de la prescription<br/>(écran / API 日レセ)"] --> TBL["tbl_shoho_kanri<br/>Identifiant d'ordonnance, numéro d'échange,<br/>renouvellement, annulation/modification"]
    TBL -->|"Export CSV<br/>(ORCSEPRECSV)"| MOD["Module d'ordonnance électronique<br/>(construction et envoi de la demande d'enregistrement)"]
    SIGNM["Module de signature électronique<br/>(signature électronique)"] -.->|"Signature"| MOD
    MOD -->|"Enregistrement"| EPS["Service de gestion<br/>des ordonnances électroniques"]
    EPS -.-> RET["Identifiant d'ordonnance, numéro d'échange<br/>(enregistré dans tbl_shoho_kanri,<br/>vers le talon imprimé de la série ORCHC02)"]

La sortie par laquelle les données de prescription passent vers le programme compatible est ORCSEPRECSV.CBL (sortie des données CSV de l’ordonnance électronique). L’historique des modifications de l’en-tête constitue lui-même un enregistrement des évolutions réglementaires.

• Octobre 2022, création ── implémenté en amont du démarrage de l’exploitation en janvier 2023
• Juin 2023, prise en compte du référentiel de posologie ── l’ordonnance électronique codifie aussi la posologie (mode de prise), ce qui a nécessité une cohérence avec le référentiel de posologie
• 2024 : prise en charge du nombre de renouvellements (janvier), mention du numéro de délivrance dans les remarques (mars), prise en charge du souhait patient pour un médicament original (août), passage à 40 octets pour le nom en kanji (décembre) ── des évolutions réglementaires, comme le traitement particulier des médicaments à longue durée de référencement (enregistrement du souhait du patient), se traduisent directement par des ajouts de champs
• 2025 : prise en charge de l’avertissement sur code factice (janvier), prise en charge de la date de péremption d’utilisation (avril), prise en charge du nombre de chiffres pour le numéro de payeur/bénéficiaire (juillet) ── même deux ans et demi après le début de l’exploitation, les révisions continuent au rythme de plusieurs fois par an

Comme le montre cet historique, l’intégration CSV de l’ordonnance électronique n’a pas été « construite une fois pour toutes » : elle continue d’évoluer en temps réel. Côté formulaires, les programmes de formulaires d’ordonnance (série ORCHC02, série ORCHCM19) alignent des versions compatibles avec l’ordonnance électronique. Si les formulaires ne disparaissent pas avec l’ordonnance électronique, c’est en raison du talon remis au patient (incluant la notification du numéro d’échange) et de la coexistence continue avec l’exploitation papier. Ce n’est pas « numérisation = suppression des formulaires », mais les formulaires subsistent tandis que le lieu de stockage de la donnée originale change ── voilà la réalité de cette période de transition, que la structure des fichiers du code source reflète honnêtement.

7. La connexion avec la vérification d’éligibilité ── le mode de délivrance arrive depuis la vérification d’éligibilité

En observant l’ordonnance électronique comme un flux interne à l’établissement, la première bifurcation est : « ce patient reçoit-il son ordonnance sous forme électronique ou papier ? » D’où vient cette information ── la réponse est la vérification d’éligibilité en ligne.

Quand un patient se fait accueillir avec sa carte d’assurance maladie My Number, il peut choisir sur le lecteur de carte le mode de réception de l’ordonnance (électronique/papier). Ce choix parvient au système de facturation médicale en même temps que le résultat de la vérification d’éligibilité. La table des résultats de vérification d’éligibilité de la vérification d’éligibilité en ligne, tbl_onshi_kaku, lue au 3e article, comporte un champ de mode de délivrance de l’ordonnance (SHO_SHOHO_KEITAI), ajouté selon le commentaire de définition en juillet 2022. La définition XML de la vérification d’éligibilité comporte elle aussi un champ PrescriptionIssueSelect (mode de délivrance de l’ordonnance). Six mois avant le début de l’exploitation de l’ordonnance électronique (janvier 2023), le point d’entrée côté vérification d’éligibilité avait donc d’abord été étendu ── l’ordre dans lequel le dispositif réglementaire s’est empilé se lit jusque dans les dates du code source.

Et le mode de délivrance décidé à l’accueil se fixe, au moment de la prescription, comme tbl_shoho_kanri.SHOHO_KEITAI, ordonnance par ordonnance. La transmission de données entre dispositifs réglementaires ── vérification d’éligibilité (accueil) → prescription (soins) → service de gestion (émission) ── se trouve connectée jusqu’au niveau de la conception des tables. La vision du 3e article, qui décrivait la vérification d’éligibilité en ligne comme « l’axe principal par lequel l’information circule à partir de l’entrée que constitue l’éligibilité », se trouve confirmée aussi pour l’ordonnance électronique.

8. Pour les fournisseurs ── comment préparer un environnement de validation

Le premier écueil du développement d’une intégration à l’ordonnance électronique n’est pas le code, mais « la dispersion des canaux d’obtention de la spécification et de l’environnement de test ». Récapitulons l’information officielle, canal par canal.

1) Obtention de la spécification ── « ONS pour établissements médicaux »

La spécification de première main pour les fournisseurs de systèmes est centralisée sur « ONS pour établissements médicaux », le site d’information dédié aux fournisseurs fourni par le Fonds de paiement des soins (on y trouve aussi la spécification d’interface externe du système de vérification d’éligibilité en ligne et la spécification des conditions d’enregistrement du service de gestion des ordonnances électroniques). Ce site est distinct du portail global utilisé par les établissements de santé, et suppose une inscription en tant que fournisseur. Par ailleurs, la page « Ordonnance électronique (pour les fournisseurs de systèmes) » du ministère de la Santé publie un document technique explicatif à destination des fournisseurs de systèmes (version 2.04 au moment de la rédaction) ainsi que des documents d’intégration pour les systèmes de pharmacie. À noter que le « guide d’implémentation de l’ordonnance électronique » de JAHIS (association professionnelle des industriels de systèmes d’information sanitaire, médicale et sociale ; un groupement sectoriel des fournisseurs de systèmes d’information médicale, qui élabore diverses normes et guides d’implémentation) (version 1.2, 2021) est un document de réflexion antérieur au service de gestion des ordonnances électroniques actuel ; la source de première main pour la spécification actuelle reste bien la spécification et le document technique explicatif d’ONS. Ce guide ressort souvent en premier dans les résultats de recherche, soyez vigilant.

2) Obtention des certificats et cartes de test

L’émission d’une ordonnance électronique nécessite obligatoirement la signature électronique (HPKI) du médecin ou du dentiste, si bien que des certificats sont également nécessaires pour les tests. Le guichet d’obtention varie selon l’usage.

• Carte de test HPKI (signature, authentification) : le guichet varie selon la profession. Pour les médecins, l’obtention se fait par courrier via un formulaire de demande, sur la page « À l’attention des fournisseurs » du Centre d’authentification électronique de l’Association médicale japonaise (JMACA, l’autorité de certification HPKI gérée par l’Association médicale japonaise, qui délivre la carte de qualification de médecin = carte HPKI). Pour les dentistes et les pharmaciens, il faut suivre les instructions de leur autorité de certification respective (MEDIS = Fondation de développement des systèmes d’information médicale, autorité de certification de l’Association pharmaceutique japonaise).
• Utilisation en environnement de validation du second certificat électronique HPKI (signature sans carte) et carte My Number de test : demande par e-mail au guichet dédié de MEDIS.
• Point de vigilance : même en temps normal, une carte HPKI de production met 2 à 3 mois entre la demande et l’émission. De plus, au moment de la rédaction, les instructions de JMACA indiquent une suspension temporaire de l’émission de la carte physique (carte de qualification de médecin) faute de cartes à puce, avec une émission anticipée du second certificat électronique HPKI (sans carte). Avant de bâtir un plan reposant sur une carte physique, il est plus sûr de commencer par vérifier l’état d’émission le plus récent et la possibilité de substitution par une signature sans carte.

3) Validation de la connexion et vérification avant mise en production

La validation de la connexion avec le service de gestion se déroule selon les instructions fournies via ONS, mais un document que le développeur a intérêt à lire en amont est la « liste de contrôle d’autovérification concernant la publication d’un logiciel compatible avec l’ordonnance électronique (confirmation de fin de test) » (version 4.2 au moment de la rédaction), publiée par le ministère de la Santé. Le fournisseur est censé confirmer la fin des tests de cette liste avant la publication, ce qui signifie, à l’inverse, qu’une liste officielle de « ce qu’il faut tester » existe dès le départ. Partir de cette liste pour bâtir le plan de test est le chemin le plus rapide. Par ailleurs, comme alternative à une implémentation maison du traitement de signature, il existe un module commun de signature de l’ordonnance électronique, et une liste des prestataires de services d’accompagnement à l’introduction est également publiée sur la page du ministère de la Santé.

4) Environnement de validation côté ORCA

Pour valider avec la configuration 日レセ + programmes compatibles, montez une édition WebORCA sur site sur un serveur de test, et suivez le manuel d’installation du module d’ordonnance électronique et de l’assistant étendu d’ordonnance électronique officiel. Comme vu au chapitre 6, l’ordonnance électronique est liée au référentiel de posologie, donc sans mettre également ce référentiel à jour, ce n’est pas une validation des données de sortie. De plus, les codes de posologie standard ont une date de péremption. Au moment de la rédaction, la page officielle indique qu’à partir du 1er août 2026, une partie des codes de posologie standard deviendra inutilisable pour l’ordonnance électronique, et que si un mappage vers un code expiré subsiste, le 日レセ produira un code factice en sortie. N’actualisez pas uniquement le référentiel : incluez aussi dans vos critères de test la vérification du remappage des codes de posologie que votre propre système utilise (même si le test passe aujourd’hui, il peut basculer vers une sortie de code factice une fois la date de péremption dépassée). Comme pour le fichier de modèles de validation de la vérification d’éligibilité présenté au 3e article, la règle d’or est de vérifier les moyens de validation officiels avant de créer soi-même des données de test.

5) Lire soi-même le code source

Toutes les descriptions relatives à l’implémentation dans cet article ont été vérifiées en consultant directement le code source public réel. N’importe qui peut faire de même. Voici le fil conducteur.

• Obtention : le code source est publié depuis la page d’information technique de l’ORCA Project. Il est publié le 1er de chaque mois, sous forme d’archive tar (zip), avec le code source correspondant au 1er du mois précédent ; le corps du logiciel de la branche 5.2 se trouve à https://ftp.orca.med.or.jp/pub/src/jma-receipt.r_5_2_branch.zip (l’affichage de la liste du répertoire n’étant pas possible, obtenez-le via le lien de la page d’information technique). Les frais publics régionaux (jma-receipt-kk) et les formulaires (jma-receipt-forms) sont dans des archives séparées.
• Où regarder : les définitions de table se trouvent sous record/ (par exemple record/tbl_shoho_kanri.db), les commentaires japonais des champs dans les clauses COPY du COBOL (cobol/copy/CPSHOHO-KANRI.INC), et le traitement principal sous cobol/common/ (par exemple ORCSEPRECSV.CBL). Pour saisir le panorama global des tables, le « document de définition des tables de base de données du 日医標準レセプトソフト », disponible sur la même page d’information technique, sert d’index.
• Comment progresser dans la lecture : la recherche par commentaire japonais dépend de l’encodage du code source, il est donc plus sûr de commencer par suivre les identifiants alphanumériques.

# Définition de la table de gestion des prescriptions, et clause COPY portant les noms de champs + commentaires japonais
less record/tbl_shoho_kanri.db
less cobol/copy/CPSHOHO-KANRI.INC

# Repérer les programmes qui manipulent l'identifiant d'ordonnance
grep -rl "PRESCRIPTIONID" cobol/ | head

# Le commentaire d'en-tête d'un programme COBOL contient l'historique des modifications
# (qui constitue un enregistrement des évolutions réglementaires)
head -60 cobol/common/ORCSEPRECSV.CBL

• Suivre les changements : en conservant les archives mensuelles et en prenant un diff -r avec le mois précédent, on peut détecter les changements avant même l’annonce officielle (point 5 du chapitre 9).

9. Points pratiques pour qui développe un système d’intégration

Voici les points essentiels lorsqu’on aborde l’ordonnance électronique depuis un dossier médical électronique, une aide à la prescription ou un système d’accueil.

1. Tracer la ligne de partage des responsabilités en premier. La répartition standard chez ORCA est : gestion des données de prescription au 日レセ lui-même, signature et communication avec le service de gestion aux programmes compatibles avec l’ordonnance électronique. Découpez, fonctionnalité par fonctionnalité, avec quel côté votre système d’intégration doit dialoguer, avant de concevoir. Décider d’implémenter soi-même la partie signature signifie assumer aussi l’exploitation des cartes HPKI.
2. Traiter l’identifiant d’ordonnance et le numéro d’échange comme des entités. Avec un modèle de données où « ordonnance = document imprimé », la gestion d’état comme l’annulation, la modification, l’UNDO ou le renouvellement devient un ajout après coup. La composition des champs de tbl_shoho_kanri constitue une excellente référence pour la conception d’une entité de prescription à l’ère de l’ordonnance électronique (elle ne porte cependant que le nombre et le nombre de jours de renouvellement, et ne porte pas l’état du nombre d’utilisations déjà effectuées ou du nombre restant : concevez le nombre restant comme une donnée relevant du cycle de vie côté délivrance, à traiter séparément).
3. Le mode de délivrance arrive à partir de l’accueil ── mais uniquement pour un accueil My Number. Le souhait électronique/papier n’est inclus dans le résultat de vérification d’éligibilité que si le patient s’est fait accueillir avec sa carte d’assurance maladie My Number. Pour un patient qui n’utilise pas cette carte (attestation de droits, etc.), le personnel ou le médecin doit confirmer le souhait au guichet ou en salle de consultation : se fier uniquement à SHO_SHOHO_KEITAI laisse subsister un chemin où la prescription est atteinte sans que le souhait n’ait été confirmé. Prévoyez à la fois un flux qui fait remonter l’information de l’accueil jusqu’aux soins et à la prescription, et un flux de confirmation pour le cas où aucune valeur issue du lecteur de carte n’existe.
4. Présupposer qu’il existe deux sortes de « papier ». Tant que tous les patients et toutes les pharmacies ne seront pas passés à l’électronique, l’ordonnance papier subsistera, mais dans un établissement ayant déjà introduit l’ordonnance électronique, il existe une exploitation où même une ordonnance papier enregistre les informations de prescription et de délivrance auprès du service de gestion (ordonnance papier avec numéro d’échange), soumise elle aussi à la vérification des doubles prescriptions. Plutôt qu’une dichotomie « électronique/papier », un branchement à trois voies ── « électronique / papier avec enregistrement au service de gestion / papier selon l’ancienne exploitation par code QR » ── est plus réaliste dans la conception.
5. Se doter d’un moyen de suivre l’extension du dispositif réglementaire. La prise en charge du référentiel de posologie, du renouvellement, et le code source autour de l’ordonnance électronique en général sont mis à jour chaque année. Comme recommandé à plusieurs reprises dans cette série, la surveillance des diffs mensuels de record/ et cobol/ du code source public constitue, ici aussi, un moyen de détection des changements plus rapide que les annonces officielles.

10. Conclusion

• L’ordonnance électronique fait passer l’ordonnance d’un « papier que le patient transporte » à une « donnée structurée, enregistrée auprès d’un service de gestion, récupérable par identifiant d’ordonnance/numéro d’échange ». La centralisation des informations de prescription et de délivrance rend possible la vérification des doubles prescriptions au-delà des établissements et des pharmacies.
• Le support d’ORCA se compose du 日レセ lui-même (gestion des données, sortie CSV, formulaires) + de l’ensemble des programmes compatibles (module d’ordonnance électronique, assistant étendu d’ordonnance électronique, etc.) + d’un module de signature électronique nécessaire séparément (offre de fournisseur vérifiée). L’absence de signature électronique dans le code source du corps du logiciel constitue la preuve de cette répartition des responsabilités.
• Le centre côté corps du logiciel est tbl_shoho_kanri, qui gère l’identifiant d’ordonnance, le numéro d’échange, le nombre/la durée de renouvellement, l’annulation/la modification et leurs dates/heures d’UNDO par ordonnance. La coexistence avec la sortie du code QR de l’ordonnance (depuis 2001) subsiste dans le code source, illustrant l’essence de ce changement, qui va de la « numérisation » à la « standardisation du lieu de stockage ».
• Le mode de délivrance électronique/papier arrive, pour un accueil My Number, au moment de l’accueil, comme résultat de la vérification d’éligibilité en ligne (le point d’entrée côté vérification d’éligibilité ayant été ajouté par anticipation en juillet 2022 selon le code source). Pour les patients porteurs d’une attestation de droits, une confirmation du souhait est nécessaire séparément au guichet ou en salle de consultation. L’empilement réglementaire vérification d’éligibilité → ordonnance électronique est connecté jusqu’au niveau des tables et des définitions XML.

Le prochain article de la série portera soit sur une lecture complète du schéma de base de données d’ORCA (« édition base de données »), soit sur l’exploitation réelle de la surveillance des diffs du code source mensuel.

11. Références

• Ordonnance électronique - Ministère de la Santé, du Travail et des Affaires sociales
• Ordonnance électronique du 日医標準レセプトソフト - ORCA Project (programmes compatibles avec l’ordonnance électronique, formulaires concernés)
• À propos du support de l’ordonnance électronique du 日医標準レセプトソフト - ORCA Project
• Ordonnance électronique (pour les fournisseurs de systèmes) - Ministère de la Santé, du Travail et des Affaires sociales (document technique explicatif, spécification des conditions d’enregistrement, liste de contrôle d’autovérification avant publication)
• À l’attention des fournisseurs (carte de test HPKI) - Centre d’authentification électronique de l’Association médicale japonaise
• API d’impression d’ordonnance - ORCA Project
• Informations techniques - ORCA Project (publication mensuelle du code source, document de définition des tables de base de données)
• Réglages d’exploitation à deux postes (日レセ 5.2 et ultérieur) - ORCA Project (sur le fait que la base de données de l’édition WebORCA sur site est PostgreSQL)
• HPKI, infrastructure à clé publique du secteur de la santé, du médical et du social, présentation de l’autorité de certification électronique - MEDIS
• Code source du 日レセ, branche 5.2 (instantané publié en juillet 2026) record/tbl_shoho_kanri.db / cobol/copy/CPSHOHO-KANRI.INC / cobol/common/ORCSEPRECSV.CBL / cobol/common/ORCSQRCSV.CBL / record/tbl_onshi_kaku.db et autres ── toutes les descriptions relatives à l’implémentation dans le texte reposent 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.

En quoi l'ordonnance électronique diffère-t-elle de l'ordonnance papier ?

Au lieu que le patient apporte une ordonnance papier à la pharmacie, les données de l'ordonnance sont enregistrées dans le service de gestion des ordonnances électroniques (géré par le Fonds de paiement des soins et la Fédération nationale des assurances maladie) et la pharmacie les récupère en ligne. Le patient se fait accueillir avec sa carte d'assurance maladie My Number et sélectionne l'ordonnance concernée sur le lecteur de carte, ou bien communique à la pharmacie le numéro d'échange et les informations de la carte d'assuré pour l'identifier (l'identifiant d'ordonnance est un identifiant interne au système, pas un numéro que le patient manipule). Comme les informations de prescription et de délivrance se centralisent du côté du service de gestion, le changement majeur est de rendre possible la vérification des doubles prescriptions au-delà des établissements et des pharmacies.

Comment ORCA (日レセ) prend-il en charge l'ordonnance électronique ?

Le rôle se répartit en deux. Le 日レセ lui-même possède une table qui gère l'identifiant d'ordonnance, le numéro d'échange, le nombre de renouvellements et l'historique d'annulation/de modification (tbl_shoho_kanri), un mécanisme d'export du contenu de la prescription en CSV, ainsi que les formulaires imprimés d'ordonnance compatibles avec l'ordonnance électronique. En revanche, la signature électronique (signature locale via carte HPKI ou signature à distance) et la communication avec le service de gestion des ordonnances électroniques relèvent de l'ensemble de programmes compatibles comme le module d'ordonnance électronique et l'assistant étendu d'ordonnance électronique, ainsi que d'un module de signature électronique distinct, nécessaire séparément (des offres de fournisseurs vérifiées existent). Le fait que le traitement de signature électronique soit absent du code source public du 日レセ lui-même confirme cette répartition des responsabilités.

Qu'est-ce que le numéro d'échange ?

C'est le numéro utilisé quand un patient récupère une ordonnance électronique en pharmacie sans utiliser sa carte d'assurance maladie My Number. La pharmacie identifie l'ordonnance à partir de ce numéro et des informations de la carte d'assuré, puis la récupère auprès du service de gestion. Dans l'exploitation actuelle, le numéro d'échange comporte 6 chiffres ; dans le code source d'ORCA (日レセ), il est stocké dans la table de gestion de prescription sous le champ ACCESSCODE (une zone de 16 chiffres maximum), géré en paire avec l'identifiant d'ordonnance.

Quel est le rapport entre la vérification d'éligibilité en ligne et l'ordonnance électronique ?

Leurs points d'entrée sont connectés. Quand un patient se fait accueillir avec sa carte d'assurance maladie My Number, il peut choisir sur le lecteur de carte s'il souhaite recevoir son ordonnance sous forme électronique ou papier, et cette information (le mode de délivrance de l'ordonnance) parvient au système de facturation médicale en même temps que le résultat de la vérification d'éligibilité en ligne. Dans le code source d'ORCA également, un champ de mode de délivrance de l'ordonnance a été ajouté en juillet 2022 à la table des résultats de vérification d'éligibilité, ce qui montre que la vérification d'éligibilité en ligne et l'ordonnance électronique reposent sur le même socle.

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.