ORIGAMI, le logiciel métier que je développe et maintiens en production pour la régulation médicale, propose désormais l’ordonnance numérique à ses prescripteurs. Le branchement n’a pas été fait en direct contre les téléservices de l’Assurance Maladie, mais via Ordoclic, qui expose ses services e-santé par API à des éditeurs intégrateurs. La certification CNDA Ordonnance numérique a été obtenue côté ORIGAMI, en passant les pré-séries en notre nom, avec Ordoclic comme socle technique et fonctionnel.
Je voulais documenter ce chemin parce qu’il est mal connu, et qu’il change radicalement le rapport coût/bénéfice pour un éditeur de taille modeste qui hésite à ajouter l’e-prescription à son catalogue fonctionnel.
Le contexte : un logiciel métier qui doit prescrire
ORIGAMI est une application Rails utilisée par des praticiens en activité. À un moment, la prescription électronique cesse d’être une option : les flux papier deviennent un irritant à la fois pour le médecin (qui veut transmettre directement au pharmacien) et pour le patient (qui ne veut pas balader une feuille). Il faut donc générer des prescriptions structurées, signées, déposées dans la base sécurisée hébergée par la CNAM, et interrogeables par le pharmacien à partir d’un identifiant.
Une fois ce besoin posé, deux chemins existent pour un éditeur.
Les deux chemins possibles
Le chemin direct. L’éditeur s’enregistre lui-même auprès de l’ANS, monte sa chaîne PKI, gère ses certificats serveur et ses certificats logiciel, intègre Pro Santé Connect ou des cartes CPS pour l’authentification des professionnels, dialogue avec le téléservice de l’ordonnance numérique, développe et certifie son propre LAP (Logiciel d’Aide à la Prescription) auprès de la HAS (avec base médicamenteuse agréée, contrôles d’interactions, contre-indications, posologies), et passe le dossier CNDA pour son propre compte. C’est le chemin des gros éditeurs historiques. Il a sa cohérence : on contrôle la chaîne de bout en bout, on ne dépend de personne. Il a un coût d’entrée et de maintenance qui n’est pas absorbable par une structure d’un ou deux développeurs sans déformer le reste du produit.
Le chemin de l’API intégrateur. L’éditeur s’appuie sur un partenaire déjà raccordé aux téléservices et déjà certifié LAP, qui expose une API plus simple côté éditeur, et qui factorise la plomberie réglementaire. C’est ce que propose Ordoclic via son API intégrateur. Le logiciel métier consomme les services, l’éditeur passe sa propre certification CNDA Ordonnance numérique en s’appuyant sur le socle Ordoclic. Pour l’utilisateur final (le médecin), l’expérience est la même qu’avec un éditeur en raccordement direct : il prescrit, ça part, le pharmacien interroge la base, le circuit est sécurisé.
Le choix entre les deux n’est pas une question de fierté technique. C’est une question de surface réglementaire que l’on est prêt à porter en interne.
Ce qu’Ordoclic prend en charge
Le partenaire gère l’essentiel des frictions qui rendent le chemin direct lourd :
- Le raccordement aux téléservices CNAM et à l’écosystème ANS, avec les certificats serveur et la chaîne IGC-Santé associés.
- L’authentification du professionnel de santé via Pro Santé Connect / e-CPS et la lecture carte CPS, sans que l’éditeur ait à manipuler directement ces flux bas niveau.
- La signature électronique de la prescription et son dépôt dans la base sécurisée, dans le format attendu par les pharmaciens, avec QR code unique.
- L’interrogation côté dispensateur via l’identifiant d’ordonnance.
- Le LAP en lui-même : moteur d’ordonnance numérique certifié HAS V2 (LAP ambulatoire), marqué CE (dispositif médical), agréé CNDA pour l’ordonnance numérique. Ordoclic se décrit comme « multibase » et expose, via son LAP, une base médicamenteuse actualisée avec alertes (interactions, contre-indications) et posologies, c’est-à-dire précisément le périmètre que la HAS exige d’un LAP en médecine ambulatoire. C’est ce qui rend la certification HAS « infâme » à porter en solo : référentiel exigeant, base médicamenteuse agréée à intégrer (Vidal côté Ordoclic), revalidation à chaque évolution. Côté ORIGAMI, on consomme.
- L’accompagnement aux pré-séries CNDA, étape obligatoire pour que l’éditeur intégrateur obtienne sa propre certification Ordonnance numérique.
L’éditeur reste responsable de ce qui est métier : la modélisation de la prescription dans son domaine, l’ergonomie côté médecin, la traçabilité applicative, la gestion des cas où le médecin doit annuler ou rééditer, et la cohérence avec le reste du dossier patient.
Ce qu’Ordoclic ne remplace pas
La responsabilité clinique du prescripteur, et plus largement la responsabilité du logiciel métier, ne disparaissent pas. Les alertes de la base médicamenteuse remontent côté ORIGAMI via l’API, et le médecin prescripteur tranche en dernier ressort. Le logiciel métier doit afficher ces alertes correctement, tracer la décision, et gérer les cas dégradés propres à son domaine. Le mode dégradé doit être pensé côté éditeur : que se passe-t-il quand l’API ne répond pas pendant l’acte de soin ? Le prescripteur doit pouvoir continuer son acte, et la prescription se consolide quand le service redevient disponible.
L’intégration côté Rails
Le branchement côté code n’a rien d’exotique. Ce sont des appels HTTP authentifiés contre l’API Ordoclic intégrateur, depuis une couche service dédiée. Les patterns que j’utilise sur le reste du logiciel s’appliquent sans changement : objets Result en sortie de chaque appel, ViewComponent pour les écrans de prescription, ActionPolicy pour vérifier qui peut prescrire, Sentry pour la traçabilité. Côté UI, Ordoclic propose aussi un mode widget / iframe, utile quand on veut intégrer plus vite sans réimplémenter l’interface de saisie. ORIGAMI a fait le choix d’un branchement API pur, pour garder le contrôle total sur l’ergonomie côté médecin.
Les sujets de fond, c’est ailleurs qu’ils se jouent.
D’abord, l’authentification du prescripteur. Côté Rails, on doit savoir avec certitude quel utilisateur agit, dans quel contexte d’exercice, et associer ça à un identifiant exploitable côté API (notamment via le RPPS). Ce n’est pas une cinématique qui se reconstruit en trois lignes : elle se cale au moment de la configuration du compte du médecin, et elle doit être à jour à chaque prescription.
Ensuite, la signature et le format. Une ordonnance numérique au sens du téléservice n’est pas un PDF signé envoyé par mail. Ce sont des données structurées, signées, déposées dans la base CNAM, et qui seront interrogées par le pharmacien à partir d’un identifiant. Ordoclic gère le format technique ; côté éditeur, on doit fournir des données propres, complètes et tracées.
Enfin, l’ergonomie côté médecin. C’est l’enjeu invisible qui sépare une intégration utilisable d’une intégration installée mais évitée. L’écran de prescription doit s’inscrire naturellement dans le flux de consultation, afficher proprement les alertes interactions/contre-indications remontées par l’API, ne pas ajouter d’étapes inutiles, et bien se comporter quand le réseau est instable ou quand le service est lent. Ces sujets-là restent intégralement à la charge de l’éditeur, et c’est là que se gagne ou se perd l’adoption.
Ce que la certification CNDA via Ordoclic est
Pour clarifier un point souvent ambigu : la certification CNDA Ordonnance numérique obtenue dans ce cadre est bien une certification portée par l’éditeur intégrateur lui-même (ORIGAMI dans notre cas), pour une version donnée du logiciel. Elle est obtenue en passant les pré-séries CNDA en s’appuyant sur le LAP et le moteur Ordonnance numérique d’Ordoclic comme socle technique conforme. Elle autorise la diffusion de cette version auprès des professionnels de santé pour la fonctionnalité d’ordonnance numérique. Elle est tracée, attachée à une version précise, et rejouée à chaque évolution significative.
Ce n’est ni un agrément solo obtenu en raccordement direct, ni un agrément hérité passivement du partenaire. C’est une certification en propre, obtenue par un chemin que beaucoup d’éditeurs métier sous-utilisent par méconnaissance.
Le pattern, pour d’autres éditeurs métier
Pour un éditeur Rails qui maintient un logiciel métier en santé et qui veut ajouter l’ordonnance numérique sans absorber l’ensemble des démarches ANS et le développement d’un LAP certifié HAS en interne, le pattern est viable et tient en quelques points :
- S’appuyer sur un partenaire intégrateur (Ordoclic en est un) plutôt que de viser un raccordement direct et un LAP maison si la structure n’a pas vocation à devenir éditeur PKI + LAP à plein temps.
- Garder l’éditeur responsable du métier (modélisation, ergonomie, mode dégradé, traçabilité applicative, affichage des alertes cliniques) et déléguer au partenaire ce qui relève de la plomberie réglementaire et de la base médicamenteuse.
- Penser la certification CNDA comme un état attaché à une version, pas comme un événement ponctuel : à chaque évolution significative, on rejoue la conformité.
C’est le même esprit que celui que j’ai décrit pour INSi : prendre le temps de brancher proprement les briques e-santé, en s’appuyant sur ce qui existe déjà côté ANS et partenaires certifiés, plutôt que de tout reconstruire en interne.
Si vous avez ça dans votre boîte
Si vous éditez un logiciel métier de santé et que l’ordonnance numérique est sur votre roadmap, vous n’avez pas à choisir entre tout absorber en interne et renoncer. La voie de l’API intégrateur existe et fonctionne. C’est le genre de sujet que je traite chez SXN Labs : cadrer le besoin, intégrer proprement le partenaire dans une application Rails, accompagner les pré-séries CNDA, et laisser derrière un système exploitable et agréable à maintenir.