Connecteurs eHealth (eHealth platform services connectors)

Les « eHealth platform services connectors » sont des bibliothèques locales et légères qui aident les développeurs de logiciels à intégrer les services de base de la plate-forme eHealth, surtout en matière de sécurité (authentification, chiffrement), au moyen d'une couche de connecteur technique et d'une couche de connecteurs business par public cible^[1]. Selon la plate-forme eHealth, elles visent en premier lieu les développeurs de logiciels pour prestataires de soins individuels et pharmacies^[1] ; les connecteurs business sont proposés par catégorie professionnelle (notamment Physician, Physiotherapist, Nurse, Pharmacy, Dentist, Midwife), à côté du connecteur technique^[1]. Plus généralement, les bibliothèques prennent aussi en charge les connexions avec des services qui utilisent les standards mis en place par la plate-forme, comme les hubs (Hubs & Metahub (répertoire des références))^[1]. La plate-forme eHealth les distribue sous licence libre et elles sont disponibles pour tous^[2] ; pour bénéficier d'un support, il faut avoir introduit au préalable une demande auprès de la plate-forme eHealth^[1].

Le connecteur technique offre une API générique pour les services de base techniques, surtout la sécurité avec l'authentification et le chiffrement.^[1] Selon le « Connector v4 : Manuel d'utilisation » (version 1.10), une session de la plate-forme eHealth est créée, maintenue et partagée au sein du connecteur^[3]. La configuration STS (endpoint.sts) se trouve dans la configuration du connecteur^[1]. Voir I.AM et I.AM Connect (Identity & Access Management) et Certificats eHealth et chiffrement (ETEE) ; le chiffrement sert notamment à l'eHealthBox (voir la page qui lui est consacrée).

Gestion et public cible

Statut : en production, géré par la plate-forme eHealth^[1]. Dans l'environnement d'acceptation, l'accès aux services web exige, outre un certificat d'acceptation, l'intégration du connecteur^[4].

Outre les connecteurs gérés par la plate-forme eHealth, l'organisation GitHub smals-belgium contient des bibliothèques open source distinctes, telles que des helpers de pseudonymisation pour Java et .NET et un composant web (shared-referral-prescription-webcomponent)^[5]. La bibliothèque Smals de pseudonymisation convertit un numéro d'identification de patient en un point de courbe elliptique et l'aveugle avant chaque appel au service de pseudonymisation, de sorte que ce service ne voit jamais lui-même d'identifiant de patient^[6][6].

Interfaces techniques

• Langage : les connecteurs sont disponibles en Java et .NET, mais sont uniquement développés en Java^[1] ; la variante .NET n'est pas un code natif mais est générée à partir du code source Java au moyen de l'outil IKVM (adapté)^[1].
• Couches et dépendance : selon le « Connector v4 : Manuel d'utilisation » 1.10, un connecteur business contient aussi la version requise du connecteur technique^[3] ; quiconque intègre un connecteur business reçoit donc un connecteur technique adapté (déduction).
• Versions : selon la page (consultée le 26/09/2026), il existe actuellement deux versions ; la 5.1.x n'est disponible qu'en Java et nécessite au minimum Java 21^[1]. La page ne date pas l'apparition de ces lignes de versions.^[1] En mai 2026, des modifications ont été apportées à toutes les versions, notamment au connecteur business (VSB-Net, MyCareNet Chapitre IV)^[1] ; ainsi, le connecteur business pour MyCareNet Chapitre IV a reçu un service de consultation pour les pharmacies^[1].
• Endpoint STS : l'ancien service STS Saml11TokenService n'est plus utilisé depuis octobre 2023^[1]. Selon la FAQ, une cause possible de l'erreur « SOA-03005 WSDL compliance failure » est une propriété de configuration endpoint.sts qui renvoie encore à cet ancien service^[1].

Depuis octobre 2023, SHA256 est obligatoire et la version minimale supportée du connecteur est la 4.1.2 ; la plate-forme eHealth recommande fortement de toujours utiliser la dernière version^[1]. Selon la page consultée le 26/09/2026, il existe actuellement deux versions ; la 5.1.x nécessite au minimum Java 21 et n'est disponible qu'en Java^[1]. La page ne donne pas de date de fin pour l'autre version.

• Public cible : selon la plate-forme eHealth, les connecteurs visent en premier lieu les logiciels pour prestataires de soins individuels et pharmacies^[1], et les connecteurs business existent par catégorie professionnelle, sans variante hospitalière distincte dans la liste^[1]. C'est pourquoi, pour les logiciels hospitaliers, c'est surtout le connecteur technique qui est pertinent.^[1][1]
• Dépend du fournisseur : le fait qu'un DPI ou un middleware utilise le connecteur ou implémente lui-même les protocoles est un choix du fournisseur ; le connecteur est un outil, pas une obligation (déduction à partir de la description comme bibliothèque d'aide^[1]).
• Exigence de plateforme : la 5.1.x nécessite au minimum Java 21 et n'est disponible qu'en Java^[1]. Les connecteurs sont uniquement développés en Java ; la variante .NET est générée à partir du code source Java^[1].
• Recommandation (propre) : demandez aux fournisseurs quelle version du connecteur (et quel runtime) leurs connexions utilisent, et s'ils prévoient d'adopter la ligne 5.x. Vérifiez aussi que la configuration ne renvoie plus à l'ancien endpoint STS, une cause possible de l'erreur « SOA-03005 »^[1].

Conditions de mise en œuvre et limites

Le connecteur fonctionne avec un certificat eHealth^[4]. Pour les services REST, l'authentification et l'autorisation des clients passent par I.AM Connect (OIDC)^[7] ; les sources consultées ne décrivent pas quel support REST offrent les connecteurs. Voir Intégration technique avec l'infrastructure eHealth.

• La page en ligne indiquait le 26/09/2026 deux versions et identifiait la 5.1.x comme la ligne qui n'est disponible qu'en Java et nécessite au minimum Java 21.^[1] Recommandation : vérifiez toujours les artefacts de version actuels.
• La description de la gestion de session et des couches de connecteur provient du « Connector v4 : Manuel d'utilisation » 1.10 ; la question de savoir si elle s'applique inchangée à la ligne 5.1.x n'a pas été examinée.^[3]
• La question de savoir si les bibliothèques de smals-belgium sont officiellement prises en charge par Smals elle-même ne ressort pas de la source consultée.^[5]
• Note méthodologique : « non trouvé » n'est pas une preuve d'absence.