IHE SDPi (Service-oriented Device Point-of-care Interoperability)

• Quoi : SDPi est une norme « Gemini » que HL7 International et IHE développent conjointement, avec quatre profils : Plug-and-trust (SDPi-P), Reporting (SDPi-R), Alerting (SDPi-A) et external Control (SDPi-xC).^[1][1]

• Comment : les profils fixent l'utilisation d'IEEE 11073 SDC au chevet du patient en soins aigus, et des acteurs passerelles assurent la traduction vers les systèmes extérieurs, notamment vers les profils HL7 v2 DEC et ACM.^[1][1]

• État : la révision 2.4.1 a été publiée le 7 mai 2026 pour Trial Implementation ; après des tests concluants, elle sera intégrée au Devices Technical Framework.^[1]

• FHIR : les premiers mappings de SDC vers FHIR existent, mais ne sont pas encore prêts pour une implémentation dans des produits, et la HL7 Point-of-Care Device FHIR IG n'a pas encore de publication officielle.^[1][3]

• Tests : IHE Allemagne a organisé 21 Plug-a-thons SDC/SDPi entre octobre 2020 et octobre 2025, mais le groupe de travail SDPi considère les Plugathons OR.NET comme des smoke tests sans tests de conformité ; à Bruxelles, une première approche des tests formels a été arrêtée en mars 2026, avec le Connectathon IHE North America d'octobre 2026 comme étape suivante.^[4][5][5][5]

• Pour qui : pour un hôpital, SDPi décrit comment les données des dispositifs au chevet du patient parviennent, via une passerelle, au DPI, à l'aide à la décision ou à un entrepôt de données cliniques.^[6][1]

• Principale incertitude : SDPi 2.4.1 ne règle pas encore la gestion des certificats et n'utilise pas de manière normative les projets de normes pour les alarmes et la commande externe.^[1][1]

IHE SDPi (Service-oriented Device Point-of-care Interoperability) est une norme « Gemini » : un développement commun des groupes de travail consacrés aux dispositifs de HL7 International et d'IHE, publié selon les processus de consensus des deux organisations.^[1] Là où IEEE 11073 SDC fournit les normes (modèle de données, protocole, normes de rôle), SDPi fixe, en tant que profil, la manière dont elles sont utilisées dans des cas d'usage concrets.^[1][1]

SDPi vise en premier lieu les lieux de soins aigus (quartier opératoire, lits de soins intensifs et d'urgence) et l'interaction directe entre dispositifs au chevet du patient (device-to-device, D2D).^[1] Il se démarque de la pratique actuelle, dans laquelle les dispositifs communiquent par des protocoles propriétaires avec le serveur passerelle de leur fabricant, ce qui entraîne une intégration de serveur à serveur, avec les limites qui en découlent en matière de performances, de qualité et de possibilités.^[1] Un autre objectif est de produire des rapports de test directement utilisables dans un dossier réglementaire, comme une demande 510(k) auprès de la FDA américaine ; il s'agit d'un objectif, non d'un résultat atteint.^[1]

Historique : les profils IHE PCD

Avant SDPi, le profil IHE Device Enterprise Communication (DEC) acheminait les données des dispositifs liés au patient vers les applications hospitalières, indépendamment du fournisseur et avec une sémantique cohérente.^[6] Ces profils PCD (Patient Care Devices) reposent sur HL7 v2.6 comme base, avec des éléments des versions 2.7 à 2.9.^[4] Parmi les destinataires des données DEC figurent des applications d'aide à la décision clinique, des entrepôts de données cliniques et des DPI.^[6] Le nouveau IHE Devices (DEV) Technical Framework couvre, outre ces dispositifs orientés vers l'intégration hospitalière, également les dispositifs personnels (Personal Connected Health).^[1]

Quatre profils et les passerelles

Des acteurs passerelles relient SDPi à des systèmes extérieurs au contexte du chevet en soins aigus, le plus souvent via d'autres protocoles.^[1] Ils prévoient des mappings vers des profils IHE existants tels que DEC et ACM et peuvent fonctionner de manière bidirectionnelle, par exemple pour recevoir des données démographiques du patient depuis un DPI.^[1]

Pour le codage, MDC, la nomenclature ISO/IEEE 11073, est le système de codes standard de SDC ; SDPi déconseille autant que possible les codes privés des fabricants, parce qu'ils compromettent l'interopérabilité.^[1][1] Du côté HL7 v2, DEC et ACM utilisent pour les paramètres et les termes d'alarme la table Rosetta d'IHE RTM.^[7][8]

Versions et statut

La révision 2.4.1 a été publiée le 7 mai 2026 pour Trial Implementation et peut être testée lors de Connectathons IHE ultérieurs ; après des tests concluants, elle sera intégrée au Devices Technical Framework.^[1] IHE invite les organisations à développer sur la base de tels suppléments Trial Implementation.^[9] Le Devices Technical Framework lui-même en est à la révision 10.0, dont le volume 1, contenant les profils en tant que texte final normatif, est paru le 4 novembre 2024.^[9]

SDPi 2.4.1 utilise de manière non normative trois projets non publiés : la HL7 FHIR Point-of-Care Device IG, IEEE 11073-10702 (alarmes) et IEEE 11073-10703 (commande externe).^[1] L'option d'alarme de la release 2.4 est donc une intégration précoce de la norme d'alarme non encore publiée.^[1]

Un groupe de travail OR.NET contribue à l'extension du SDPi Technical Framework, avec une attention particulière pour la connexion aux systèmes informatiques et la résolution rapide des problèmes dans les normes existantes.^[10]

Sécurité

SDPi rattache ses exigences de sécurité, d'efficacité et de sûreté informatique (SES) aux normes de l'ISO/IEC JWG7, notamment ISO/IEC 81001-1:2021 et IEC 80001-1:2021, la norme de gestion des risques des réseaux informatiques comportant des dispositifs médicaux.^[1] IEEE 11073-20701 exige des canaux sécurisés entre participants via TLS avec authentification mutuelle.^[1] SDPi 2.4.1 ne règle pas la gestion des certificats ; celle-ci est reportée à des révisions ultérieures.^[1]

Mapping vers FHIR

La HL7 Point-of-Care Device (PoCD) FHIR IG décrit comment les mesures des dispositifs au chevet du patient en soins aigus sont transmises sous forme de ressources FHIR aux DPI, à l'aide à la décision et aux archives.^[3] Elle porte sur la représentation des données des dispositifs, non sur la connectivité, le transport ou la commande.^[3] Le guide contient un mapping de la plupart des classes d'objets SDC vers des ressources FHIR telles que Device, DeviceMetric et Observation.^[11] Il entend compléter les interfaces HL7 v2 via IHE PCD-01, non les remplacer.^[3] Il n'existe pas encore de publication officielle : la version la plus récente est 1.0.0-ballot3, basée sur FHIR R4, une version de ballot qui vise le trial use et n'est pas encore prête pour un usage en production.^[3][12] Dans SDPi 2.4, les premiers mappings de SDC vers FHIR ont été réalisés, mais la passerelle FHIR ne sera entièrement spécifiée que dans une version ultérieure.^[1]

Comme défi, le track a relevé que les tests IHE n'ont jamais été formellement fondés sur des cas d'usage, alors que SDPi définit des cas d'usage transversaux aux profils, comme une « Silent ICU » comportant des exigences supplémentaires.^[5] Le fait que le Plugathon se soit tenu à Bruxelles ne dit rien d'un usage belge : les participants sont des développeurs, avec des dispositifs simulés et des prototypes.^[13] Aucun environnement de production, aucun marché public belge ni aucun DPI ou plate-forme d'intégration belge mentionnant SDPi n'a été trouvé lors de la consultation du 9 novembre 2026 ; pour SDC lui-même, voir IEEE 11073 SDC (connectivité des dispositifs orientée services).

• Tests de Connectathon : le Plugathon de mars 2026 préparait des tests formels plus tard en 2026^[13] ; le track SDPi prévoyait le Connectathon IHE North America d'octobre 2026 comme prochain événement de test.^[5]

• Intégration au Technical Framework : après des tests concluants, la révision Trial Implementation sera intégrée au Devices Technical Framework.^[1]

• Passerelle FHIR : entièrement spécifiée dans une version ultérieure, en fonction de la PoCD FHIR IG.^[1][3]

• Gestion des certificats : reportée à des révisions ultérieures.^[1]

Dans le modèle SDPi, le DPI d'un hôpital ne reçoit pas les données des dispositifs directement via SDC, mais via une passerelle qui traduit vers HL7 v2 et DEC ; les DPI, l'aide à la décision et les entrepôts de données cliniques sont les destinataires visés.^[1][6] Voir Moteur d'intégration (interface engine) pour le logiciel qui reçoit et transmet les flux HL7 v2 dans un hôpital. FHIR n'est pas encore une alternative pour ce flux, parce que les mappings ne sont pas prêts pour une implémentation dans des produits.^[1] Comme SDPi se rattache à IEC 80001-1, il touche aussi à la gestion des risques du réseau sur lequel fonctionnent les dispositifs.^[1]

Recommandation (propre) : qui planifie une intégration de dispositifs peut, dans un cahier des charges, renvoyer aux profils SDPi et aux acteurs passerelles plutôt qu'à des interfaces propres à un fabricant, et vérifier à cette occasion si son DPI ou son moteur d'intégration prend en charge DEC (PCD-01) et ACM comme destinataire.

• Le statut de publication HL7 (édition STU) de SDPi n'a pas été vérifié dans une source HL7 distincte ; la publication IHE en Trial Implementation est en revanche confirmée.^[1]

• Les profils d'alarme et de commande reposent sur des projets de normes IEEE qui ne sont pas utilisés de manière normative ; leur contenu peut encore changer.^[1][1]

• La gestion des certificats n'est pas réglée, alors que l'authentification TLS mutuelle est exigée.^[1][1]

• La voie FHIR n'est pas encore utilisable en production.^[1][12]