Recip-e (prescription électronique dans le secteur ambulatoire)

• Recip-e est le système de prescriptions électroniques ambulatoires : la prescription est conservée sous forme codée jusqu'à l'exécution, avec un RID unique^[1].
• Qui prescrit un médicament à un patient non hospitalisé, y compris lors d'une consultation ambulatoire à l'hôpital, doit le faire par voie électronique, avec des exceptions^[2].
• Les messages sont du KMEHR-XML^[3] ; les spécifications publiques les plus récentes (20230224, paquet du 02/06/2023) désignent KMEHR 1.28 comme la version actuelle^[4].
• Dans le catalogue d'API eHealth, Recip-e ne figure au 29/09/2026 que comme services SOAP v4.0^[5] ; la version FHIR était en phase de test en août 2026^[6].
• Les prescriptions doivent être établies à partir de la source authentique des médicaments SAM^[2].
• La loi du 20 juillet 2026 laisse au Roi le soin de fixer par AR la date de l'obligation de prescription électronique de médicaments^[7].

Recip-e est le système de prescriptions électroniques dans le secteur ambulatoire. Les prescripteurs envoient une prescription à un serveur, où elle est conservée sous forme codée jusqu'à son exécution. Chaque prescription possède un RID unique^[1]. Un pharmacien exécute ensuite la prescription^[8]. Le nom Recip-e désigne également l'ASBL Recip-e. Celle-ci se compose de représentants des prestataires de soins siégeant au Comité de l'assurance de l'INAMI. Aujourd'hui, l'ASBL agit surtout comme point de contact multidisciplinaire pour les besoins des prestataires de soins en matière de numérisation^[9].

Quel problème résout-il ?

Recip-e remplace la prescription papier par une prescription électronique sécurisée, conservée jusqu'à sa délivrance^[1]. Un support papier peut toutefois subsister : le RID figure en haut de la preuve (papier) de prescription électronique^[1]. Cette preuve n'est qu'un moyen technique permettant au pharmacien de récupérer la prescription et n'a aucune valeur juridique^[2]. Le prescripteur n'est plus tenu de l'imprimer, sauf si le patient le demande^[2]. Quiconque prescrit un médicament à un patient non hospitalisé doit le faire électroniquement, à quelques exceptions près^[2].

Production. La Plate-forme eHealth décrit Recip-e comme un service^[1], avec un SLA et un rapportage de KPI (dernière période mentionnée : T2 2026)^[1]. La même page qualifie encore Recip-e de « nouveau système » issu du plan d'action e-Santé de 2014^[1] ; ce texte est périmé. Le service de timestamping de la Plate-forme eHealth est aussi utilisé pour Recip-e^[11]. Selon la roadmap Recip-e d'octobre 2024, le développement et le support technique de l'application Recip-e sont assurés par l'équipe applicative Recip-e, qui est passée le 14 octobre 2024 chez Smals asbl^[12]. Qui exploite techniquement le serveur ne figure pas explicitement dans les sources (voir questions ouvertes). L'obligation de prescription vaut aussi pendant une consultation ambulatoire à l'hôpital^[2]. Parmi les exceptions figurent les prescripteurs qui avaient au moins 64 ans le 1er janvier 2020, les prescriptions établies hors du cabinet et la force majeure^[2]. Pour la force majeure, un protocole d'urgence décrit quand on peut se replier sur la prescription papier^[2]. En cas de consultation à distance aussi, la prescription est créée électroniquement via Recip-e ; le patient la consulte via le Personal Health Viewer et peut recevoir le numéro RID^[10].

Services et interfaces techniques

• Format de message : Recip-e utilise KMEHR-XML comme format de message entre prescripteurs et dispensateurs^[3]. Selon les directives de contenu de 2019/2020, les prescriptions pouvaient se baser sur KMEHR 1.28 à partir du 01/05/2020, et KMEHR 1.28 est devenu obligatoire à partir du 01/06/2020^[3] (voir KMEHR). Ces directives de production 2019-2020 sont obsolètes depuis la mise à jour du 23/03/2021 et ont été intégrées dans les spécifications générales de dématérialisation^[13]. Les plus récentes d'entre elles (version de document 20230224, publiée dans le paquet du 02/06/2023) citent KMEHR 1.28 comme la version actuelle pour le champ PrescriptionVersion^[4]. Le SDK pour prescripteurs valide le KMEHR d'une nouvelle prescription contre kmehr-1.28.xsd et kmehr_elements-1.28.xsd^[4]. L'aperçu des modifications pour les maisons de logiciels a comme dernière mise à jour le 02/06/2023 et ne mentionne pas de mise à jour de paquet ultérieure^[13].
• Données médicamenteuses : les prescriptions ambulatoires doivent obligatoirement être établies à partir de la source authentique SAM^[2]. SAM est proposée comme open data via la Plate-forme eHealth et sert entre autres de source pour la prescription électronique^[14].
• API (29 septembre 2026) : dans le catalogue de production et d'acceptation de l'eHealth API Portal, Recip-e figure uniquement comme services SOAP v4.0 (Prescriber, Executor, Patient) ; une API FHIR Recip-e n'y figure pas. C'est une indication, pas une preuve qu'aucune API FHIR n'est en production^[5].
• Tests FHIR : en août 2026 est paru un projet de guide de test (v0.1, 13 août 2026) pour tester les prescriptions numériques de médicaments sur l'eHealth Digital Testing Environment (DTE)^[6]. Le guide distingue quatre acteurs : prescripteurs, exécutants, patients et hôpitaux, un hôpital étant une combinaison de prescripteurs et d'exécutants au sein de la même organisation^[6].
• Accès depuis l'hôpital : les médecins hospitaliers peuvent prescrire électroniquement via le logiciel DPI de l'hôpital. Le logiciel de prescription doit obligatoirement utiliser la source authentique SAM(v2)^[2]. L'application gratuite PARIS de l'INAMI est destinée aux prescripteurs qui n'ont temporairement pas accès à leur progiciel ou au système d'information hospitalier^[15].

• Implémentation FHIR (planning, non confirmé) : selon la roadmap Recip-e d'octobre 2024, la nouvelle implémentation FHIR devait être livrée en 2025 en quatre paquets, avec une homologation à partir de fin décembre 2025 et une utilisation sur le terrain attendue au premier semestre de 2026 ; des sources ultérieures ne confirment pas cette attente^[12]. Selon la même roadmap, l'implémentation KMEHR continuerait à être développée de manière limitée à côté de l'implémentation FHIR, sans date de fin^[12]. En août 2026, la version FHIR était encore en phase de test (projet de guide de test)^[6].
• Loi du 20 juillet 2026 : la loi conserve aussi la prescription électronique de médicaments dans la banque de données unifiée des prescriptions, jusqu'à son exécution et au maximum un an après son établissement^[7]. Le Roi détermine par AR à partir de quand la prescription électronique de médicaments est obligatoire, éventuellement par catégorie de prescripteurs^[7]. Voir Loi du 20 juillet 2026 portant des dispositions diverses en matière de santé (chapitre 6 Prescription électronique).
• Dans la phase 2 de VIDIS, on ne peut plus prescrire qu'avec une vue sur le Schéma de médication partagé, et on évolue vers la prescription de traitements au lieu de conditionnements^[15]. PARIS disparaîtra à terme avec la phase 2 de VIDIS^[15].
• Dans BIHR (Belgian Integrated Health Record), des sources authentiques peuvent être centrales. La page BIHR cite UHMEP en exemple pour les prescriptions (de renvoi)^[16]. Savoir si UHMEP remplace le serveur Recip-e n'est pas confirmé.
• Au niveau européen, l'e-prescription et l'e-délivrance relèvent des catégories EHDS prioritaires, qui s'appliquent à partir du 26 mars 2029^[17] (voir EHDS (Espace européen des données de santé)).

• Obligation légale : les prescriptions ambulatoires des médecins hospitaliers, y compris lors d'une consultation à l'hôpital, doivent être électroniques^[2] et être établies à partir de SAM^[2].
• Loi du 20 juillet 2026 : les dispositions relatives à la prescription électronique de médicaments ne s'appliquent pas aux prescriptions hospitalières électroniques exécutées par l'officine hospitalière ; le Roi peut toutefois les rendre applicables plus tard^[7].
• Délimitation intra-muros/ambulatoire : pour la prescription électronique intra-muros, les BMUC : financement du DPI intégré exigent que les prescriptions de médicaments soient saisies de manière structurée^[18]. Le timestamping est surtout utilisé pour la prescription électronique dans les hôpitaux^[11]. Cet usage est réglé par le règlement du 5 décembre 2016 relatif à la prescription électronique à l'hôpital^[11]. Le service de timestamping distingue lui-même « la prescription électronique dans les hôpitaux » de « la prescription électronique ambulatoire (Recip-e) »^[11]. Interprétation : Recip-e n'est donc pas le circuit de prescription intra-muros.
• Continuité : PARIS est une option de repli lorsque le système d'information hospitalier est temporairement inaccessible^[15]. En cas de force majeure, le prescripteur peut, selon le protocole d'urgence, se replier sur le papier^[2]. Du côté de la délivrance, une mesure transitoire s'applique : en cas d'indisponibilité persistante des services de base eHealth, le pharmacien peut exceptionnellement délivrer sur la base de la preuve de prescription électronique et indiquer cela comme force majeure^[2].
• Recommandation (propre) : intégrez PARIS et le protocole d'urgence dans la procédure de downtime pour les consultations ambulatoires, et demandez au fournisseur du DPI quelle version de KMEHR et quelle fréquence de mise à jour de SAM le module Recip-e utilise aujourd'hui.

Conditions de mise en œuvre et limites

Les médecins hospitaliers envoient leurs prescriptions via le logiciel DPI de l'hôpital^[2]. Comme le logiciel de prescription doit utiliser SAM(v2)^[2], la qualité de la prescription dépend aussi de l'intégration de SAM chez le fournisseur.

• Actualité de la page eHealth. La page du service publie des KPI jusqu'au T2 2026^[1], mais qualifie encore Recip-e de « nouveau »^[1]. Le texte introductif est donc plus ancien que le rapportage.
• Nom. « Recip-e » désigne à la fois le système de prescription^[1] et l'asbl qui est aujourd'hui surtout un point de contact^[9].
• Version de KMEHR. Les spécifications publiques les plus récentes (2023) citent KMEHR 1.28 comme la version actuelle^[4], la même version qui était obligatoire depuis le 01/06/2020^[3]. De la documentation de 2024-2026 n'a pas été trouvée (lacune, 30/09/2026) ; cela ne prouve pas qu'il n'existe pas d'exigence plus récente, non publique.
• UHMEP et Recip-e. Interprétation : la loi du 20 juillet 2026 impose une seule banque de données unifiée pour les prescriptions de médicaments et de renvoi ; avec le cookbook FHIR Recip-e sur UHMEP, cela indique qu'UHMEP devient la base technique de la version FHIR de Recip-e. Ce n'est pas encore un remplacement : dans le catalogue d'API eHealth, Recip-e figure uniquement comme SOAP v4.0, et une annonce du démarrage en production de Recip-e FHIR ou de la fin du flux KMEHR n'a pas été trouvée^[7][5].
• Planning FHIR. La roadmap attendait une utilisation sur le terrain au premier semestre de 2026^[12], mais en août 2026 il n'y avait encore qu'un projet de guide de test^[6]. Interprétation : le planning a glissé.
• VIDIS phase 2. Les pages de l'INAMI ne sont pas univoques sur le timing de la phase 2^[19][15]. Le moment où PARIS disparaîtra est donc incertain.