Services de base de la plate-forme eHealth

• La plate-forme eHealth propose une série d'outils gratuits (services de base) qui peuvent être librement intégrés dans les logiciels des acteurs de soins^[1].
• Le Welcome Pack (version 08/09/2026) énumère dix services de base : la coordination de sous-processus électroniques, le portail, RN Consult, les certificats eHealth, I.AM, le métahub, le timestamping, le chiffrement de bout en bout, l'eHealthBox et la pseudonymisation et l'anonymisation^[2]. Id Support, la Directory et DAAS ne figurent pas sur cette liste ; cette page les traite comme des services apparentés.
• Le timestamping prouve l'existence et le contenu d'un document à une date déterminée et est surtout utilisé pour la prescription électronique dans les hôpitaux^[3][3].
• Service apparenté : Id Support permet à un prestataire de soins de vérifier la validité de la pièce d'identité d'un patient auprès de la source authentique^[4].
• Services apparentés : la Directory et DAAS déterminent le ou les destinataires d'un message, notamment pour les attestations d'incapacité de travail^[5][6][6].
• Selon une page d'architecture non datée, la plate-forme continue de maintenir et de prendre en charge SOAP, mais déconseille SOAP pour les projets destinés aux appareils mobiles et y donne la priorité à REST^[7]. Une politique générale qui préfère REST à SOAP n'a pas été trouvée.
• Un calendrier général de suppression progressive n'a pas été trouvé ; les release notes mentionnent notamment des services qui atteignent la fin de leur cycle de vie^[8][8], par exemple la mise hors service annoncée de Sadmi v2 dans la release R20262^[9].

Quels services communs la Plate-forme eHealth met-elle à la disposition des logiciels de soins, et comment évoluent-ils de SOAP vers REST ? La Plate-forme eHealth propose ces services gratuitement en vue de leur intégration dans les logiciels des acteurs de soins^[1]. La présente page donne l'aperçu et décrit les services qui n'ont pas de page propre : le service de base Timestamping et les services techniques apparentés Id Support, Directory et DAAS, qui ne figurent pas sur la liste du Welcome Pack. Pour ce dont un logiciel a besoin par service afin de se coupler, voir Intégration technique avec l'infrastructure eHealth ; pour l'aperçu complet du catalogue d'API, groupé par fonction, voir Services et API de la plate-forme eHealth.

Aperçu des services de base et des services apparentés. Le Welcome Pack (version 08/09/2026) énumère dans sa table des matières dix services de base : coordination de sous-processus électroniques, portal, RN Consult, certificats eHealth, I.AM, le répertoire des références (Metahub), timestamping, chiffrement de bout en bout, eHealthBox ainsi que pseudonymisation et anonymisation^[2]. Le SLA de CoBRHA qualifie CoBRHA de « Base Service »^[10]. La colonne « Officiel » indique si un service figure sur la liste du Welcome Pack ; « non » signifie uniquement qu'il n'y figure pas.

La colonne « interfaces » suit le registre d'API de l'Atlas (état du catalogue au 28/09/2026) ; là où une claim existe, celle-ci figure dans la colonne « fonction ». La colonne « Officiel » suit la liste du Welcome Pack^[2]. La question de savoir si la page de service « Services de base » donne une liste divergente n'a pas encore été traitée (voir les questions ouvertes).

Timestamping

Le Timestamping de la Plate-forme eHealth conserve une preuve de l'existence et du contenu d'un document à une date déterminée^[3]. Le service se compose du webservice TimeStampAuthority (certification et archivage facultatif) et du webservice TimeStampConsult (consultation et contrôle de documents datés)^[3].

Le timestamping est surtout utilisé pour la prescription électronique dans les hôpitaux, et en outre pour la prescription électronique ambulatoire (Recip-e), MyCareNet et RCT^[3][2]. Pour les prescriptions hospitalières, les codes de hachage sont regroupés toutes les 5 minutes dans un paquet, le « TimeStampBag »^[3]. La Plate-forme eHealth prouve ainsi le moment de la création sans connaître le contenu, parce que celui-ci est haché^[3]. L'utilisation du timestamping pour les prescriptions hospitalières est réglée par la loi (règlement du 5 décembre 2016 relatif à la prescription électronique au sein de l'hôpital)^[3]. La plate-forme fournit le TimeStamping Client comme implémentation de référence ; un hôpital peut aussi utiliser une solution propre ou celle d'un fournisseur de logiciels, pour autant que cette solution réponde aux mêmes spécifications^[3].

Selon les release notes de R2024.1.2 (datées du 23/07/2024), l'endpoint /TimestampAuthority/v1 devait être mis hors service dans cette release et les utilisateurs devaient migrer vers /TimestampAuthority/v2^[22]. Les release notes sont rédigées à l'avance (« will be undeploy ») ; aucune confirmation distincte de l'exécution n'a été trouvée.

Id Support (service apparenté)

Id Support ne figure pas sur la liste des services de base dans le Welcome Pack^[2]. Via eHealth Id Support, un prestataire de soins peut contrôler la validité de la pièce d'identité d'un patient auprès de la source authentique concernée^[4]. La Plate-forme eHealth n'est pas une source authentique pour les données d'identité : Id Support est un service relais vers le service de la Banque Carrefour de la Sécurité Sociale^[23]. Le service n'existe que comme webservice destiné à l'intégration dans les logiciels des prestataires de soins et requiert un token du service STS de la Plate-forme eHealth^[4][4]. Id Support n'est pour le moment disponible que pour les prestataires de soins individuels reconnus dans l'arrêté royal n° 78^[4]. Selon la délibération n° 07/2014 du Comité sectoriel du Registre national, les prestataires de soins et les institutions de soins peuvent utiliser Id Support via la Plate-forme eHealth^[4].

Directory et DAAS (services apparentés)

Le Directory et DAAS ne figurent pas non plus sur la liste des services de base dans le Welcome Pack^[2]. Le Directory est un registre d'acteurs liés entre eux pendant une période, consultable via la DAta Attribute Service (DAAS) ; via le Directory WS, des partenaires privilégiés y ajoutent des données^[5]. DAAS est un service générique de la Plate-forme eHealth permettant d'identifier le ou les destinataires d'un message dans le secteur de la santé, par exemple un service de prévention, un médecin-contrôleur ou un employeur^[6]. DAAS suit l'exemple de l'Attribute Authority (AA) de I.AM et consulte les sources authentiques ou le guide de routage résiduaire ; le résultat est transmis au fournisseur de logiciels du prestataire de soins^[6]. DAAS est notamment utilisé dans Mult-eMediatt, le projet d'informatisation des certificats d'incapacité de travail, et dans la plate-forme TRIO^[6]. DAAS a également été rendu pseudo-compatible^[24] (voir Pseudonymisation et anonymisation (plate-forme eHealth)). Dans la release R20252.1, le Directory a été adapté pour Mult-eMediatt afin d'affiner l'ensemble de données du certificat par type de destinataire^[25].

API dans le catalogue de la Plate-forme eHealth

État du catalogue au 28/09/2026 (registre de l'Atlas). Les API des autres services de base figurent sur leurs propres pages.

Politique. Selon la page de service « Architectures » (sans date de publication), la Plate-forme eHealth continue d'entretenir et de prendre en charge l'architecture SOAP, mais la déconseille pour les projets destinés aux appareils mobiles et y donne la priorité à REST^[7]. La plate-forme décrit SOAP comme l'architecture pour les applications sur un seul appareil et REST pour les applications sur plusieurs appareils ; pour les nouveaux projets mobiles, REST est préféré^[7]. Dans cette source, la priorité donnée à REST est donc limitée aux projets mobiles ; aucune politique générale préférant REST à SOAP n'a été trouvée dans les sources traitées (lacune). La question de savoir si la page reflète la politique actuelle n'est pas établie.

Pas de calendrier général. Aucune politique transversale aux services ni aucun calendrier de retrait des services SOAP n'a été trouvé dans les sources traitées (lacune). Les release notes paraissent le jour où une release entre en acceptation et mentionnent entre autres les services qui atteignent la fin de leur cycle de vie^[8][8]. Exemples de telles annonces :

• Timestamping : les release notes de R2024.1.2 (23/07/2024) ont annoncé la mise hors service de /TimestampAuthority/v1, avec migration vers v2^[22].
• Registre central de traçabilité (pas un service de base) : les release notes de R20262 annoncent la mise hors service de Sadmi v2, avec passage à /Sadmi/v3 ou /Sadmi/v4^[9] ; cette major release est planifiée du 13 au 20 octobre 2026^[9].

Toutes les modifications ne figurent pas dans les release notes : le gel fonctionnel d'Addressbook SOAP figure dans le cookbook REST v1.3^[26].

État par service (exemples) :

• Addressbook : SOAP et REST utilisent le même backend, mais seul REST reçoit encore des améliorations fonctionnelles ; SOAP subsiste pour la compatibilité^[26].
• Consentement : il existe trois versions du service Consent^[17] ; la gestion de l'opt-out n'est prise en charge que par Patient Data Access Consent WS REST et la plate-forme conseille aux utilisateurs de REST de migrer vers ce service^[17].
• Relation thérapeutique : dans le cadre de la release R20252.1, la plate-forme a annoncé une réécriture technique complète (refactoring) des services Therapeutic Link, tant SOAP que REST^[18] ; le fait qu'elle soit passée en production n'est pas confirmé séparément. Interprétation : SOAP est donc encore entretenu.
• Matrice d'accès : la WS Matrix (PADAC) est un service REST^[20].
• ETEE : ETKDepot et KGSS existent en SOAP et REST, KeyDepot uniquement en REST^[14].
• eHealthBox : SOAP et REST coexistent^[27] (dans le catalogue du 28/09/2026 : SOAP v3.0 et REST v1.2). En 2025, la grande majorité du trafic passait par SOAP (112.876.714 messages) contre 917.260 via REST^[28] ; en 2022, il s'agissait de 171.044.364 messages via SOAP et de 13.005 via REST^[28]. REST croît donc, mais reste une petite part.
• Services plus petits : Timestamping, Id Support, Directory et DAAS ne figurent dans le catalogue qu'en SOAP (voir le tableau ci-dessus).

Constatations : les services de base sont gratuits et destinés à l'intégration dans les logiciels des acteurs de soins^[1]. Selon une page d'architecture non datée, SOAP reste entretenu et pris en charge, et REST reçoit la priorité pour les projets destinés aux appareils mobiles^[7] ; aucune priorité générale pour REST n'a été trouvée. Pour certains services, seul REST évolue encore^[26] ou la nouvelle fonctionnalité ne se trouve que dans une variante REST^[17], tandis que pour d'autres services, une réécriture en SOAP et en REST a encore été annoncée^[18]. Interprétation : « SOAP retiré » n'est pas un résumé correct pour les services de base dans leur ensemble ; la migration se déroule service par service.

Recommandation (propre) : tenez à jour, par couplage, quel service, quelle interface et quelle version sont utilisés, suivez les release notes de la Plate-forme eHealth quant aux annonces de mise hors service, et choisissez pour les nouvelles intégrations la variante REST là où elle existe.

• Cadre légal (timestamping) : l'utilisation du timestamping pour les prescriptions hospitalières est réglée par la loi^[3] ; les hôpitaux peuvent utiliser à cette fin l'implémentation de référence ou une solution propre ou de fournisseur qui soit conforme^[3].
• Gestion des versions : les mises hors service annoncées, comme celle de TSA v1^[22], exigent des migrations en temps utile dans les logiciels hospitaliers ; les release notes en sont la première source^[8][8].
• Id Support : le service n'est pour le moment disponible que pour les prestataires de soins individuels^[4], même si la délibération mentionne aussi les institutions de soins^[4].
• Routage : DAAS et le Directory déterminent les destinataires des certificats d'incapacité de travail via Mult-eMediatt^[6][25].

Id Support requiert un token du service STS de la Plate-forme eHealth^[4][4]. L'utilisation de DAAS requiert, selon le projet, une approbation par le Comité de gestion de la Plate-forme eHealth et par le Comité de sécurité de l'information^[6]. Les conditions des autres services de base figurent sur leurs propres pages et sur Intégration technique avec l'infrastructure eHealth.

• Addressbook SOAP : le cookbook REST v1.3 (24/03/2026) indique que seul REST reçoit encore des améliorations fonctionnelles^[26], alors que les release notes de R20252.1 (09/12/2025) annonçaient encore de nouvelles options de recherche pour SOAP comme pour REST^[25]. Interprétation : le gel ne s'appliquait peut-être qu'après R20252.1.
• Id Support, cartes prises en charge : la page de service cite quatre pièces d'identité (eID, Kids-ID, Foreign ID, ISI+)^[4], le cookbook v1.5 (19/07/2022) en cite six : eID, KidsID, ForeignID, titre de séjour biométrique, carte SIS et carte ISI+^[23]. La question de savoir quelle liste est actuelle n'est pas établie.
• Timestamping v1 : le cookbook TSA V2 du 11/06/2024 indiquait que la première version de TSA était encore utilisée par de nombreux partenaires^[29], alors que les release notes de R2024.1.2 (23/07/2024) annonçaient la mise hors service de l'endpoint v1^[22]. La question de savoir si la mise hors service s'est déroulée ainsi à cette date n'est pas établie (voir les questions ouvertes).
• Release du refactoring TherLink : le message sur la réécriture cite en français « R20252.1 » et en néerlandais « R2023.1.2 » comme release du 2/12/2025, alors que les release notes R20252.1 datent cette minor release du 09/12/2025^[18].
• Portée de la priorité donnée à REST : la page d'architecture limite la priorité donnée à REST aux projets destinés aux appareils mobiles et ne porte pas de date^[7] ; des affirmations plus larges (« REST reçoit la priorité ») ne découlent pas de cette source.
• Calendrier général de retrait : non trouvé ; « non trouvé » ne signifie pas qu'il n'existe pas.