IEEE 11073 SDC est une famille de normes internationales qui permet à des dispositifs médicaux de fabricants différents, au chevet du patient, par exemple au quartier opératoire ou aux soins intensifs, d'échanger des données via le réseau et de se commander mutuellement de manière sûre. Elle se compose d'un modèle de données (BICEPS), d'un protocole de services web (MDPWS) et d'une norme d'architecture qui relie les deux, complétés par des normes par rôle de participant. Les normes centrales sont publiées ; les normes pour les alarmes et la commande externe sont encore en développement. Pour les hôpitaux, l'enjeu est de raccorder des dispositifs sans protocole propre à chaque fabricant ; dans un marché public belge, le « protocole SDC » figurait comme critère d'attribution.
", "last_verified": "2026-11-09", "verification_outdated": false, "sections": [ { "id": "en-bref", "title": "En bref", "kind": "tekst", "html": "IEEE 11073 SDC (connectivité des dispositifs orientée services) définit, au sein de la famille ISO/IEEE 11073 pour la communication des dispositifs médicaux au chevet du patient, une architecture pour des dispositifs et des systèmes informatiques médicaux distribués et orientés services.[2] « Point-of-care » désigne ici le lieu où le patient est soigné : le profil IHE SDPi, qui s'appuie sur SDC, vise les quartiers opératoires, les lits de soins intensifs et les lits d'urgence, ainsi que l'interaction directe entre dispositifs au chevet du patient.[12]
\nAttention à l'abréviation. HL7 FHIR Structured Data Capture s'appelle aussi « SDC » (version 4.0.0, STU 4), mais il s'agit d'un guide d'implémentation FHIR pour les formulaires et les questionnaires, sans lien avec IEEE 11073 SDC pour la connectivité des dispositifs.[13] Cette page porte exclusivement sur la norme relative aux dispositifs.
\nLa famille se compose de trois normes centrales, qui règlent chacune une couche :
\nS'y ajoutent les participant key purposes (PKP) : des ensembles d'exigences par rôle, grâce auxquels un fabricant peut avoir certaines attentes à l'égard des participants d'autres fabricants.[5] IEEE 11073-10700 répartit les responsabilités pour les participants de base.[5] IEEE 11073-10701 impose des exigences aux participants qui fournissent ou utilisent des valeurs de mesure, afin qu'ils contribuent de manière sûre aux fonctions système fondées sur ces informations de mesure.[6] Les projets de normes P11073-10702 et P11073-10703 font de même pour les participants qui échangent des données d'alarme et des commandes externes.[16][3]
\nLa nomenclature IEEE 11073-10101 est partagée avec les normes pour les dispositifs de santé personnels (PHD) : elle sert à la fois aux dispositifs au chevet du patient et aux dispositifs personnels au sein de la famille ISO/IEEE 11073.[17] En tant que norme à double logo ISO/IEEE 11073-10101:2020, elle figure dans le catalogue de l'ISO/TC 215, où elle est confirmée (stade 90.93).[18]
\nSDC est issu du projet de recherche allemand OR.NET : le nom de travail Open Surgical Communication Protocol (OSCP) est devenu la famille IEEE 11073 SDC, composée de IEEE 11073-20702, -10207 et -20701.[7] Le développement a été financé par des fonds de recherche publics allemands et européens, notamment du ministère fédéral allemand de la Recherche (BMBF), du ministère de l'Économie (BMWi) et du Fonds européen de développement régional (FEDER).[7] En 2016, l'association OR.NET e.V. a été fondée pour poursuivre le travail du projet ainsi que maintenir et élargir le consortium.[7] Au salon Medica 2018, des fabricants ont présenté, selon OR.NET, les premiers dispositifs médicaux compatibles OR.NET.[7]
" }, { "id": "comment-est-ce-structure", "title": "Comment est-ce structuré ?", "kind": "tekst", "html": "État selon les fiches de statut de l'IEEE SA, consultées le 9 novembre 2026. L'approbation par l'IEEE SA Board et la publication sont des dates distinctes.
\n| Norme | \nTitre ou rôle | \nStatut | \nDates | \nAffirmations | \n
|---|---|---|---|---|
| IEEE 11073-20702-2016 | \nMDPWS : protocole de services web | \npubliée ; projet de révision en cours | \napprouvée 2016-09-22, publiée 2017-05-26 ; PAR de révision 2026-03-26 | \n[1][1][15] | \n
| IEEE 11073-10207-2017 | \nBICEPS : modèle de domaine et de services | \npubliée, corrigendum Cor 1-2025 ; projet de révision en cours | \napprouvée 2017-12-06, publiée 2018-02-21 ; PAR de révision 2026-03-26 | \n[4][4][14] | \n
| IEEE 11073-20701-2018 | \narchitecture et liaison de BICEPS à MDPWS | \nnorme active | \napprouvée 2018-09-27, publiée 2019-01-15 | \n[2][2] | \n
| IEEE 11073-10700-2022 | \nPKP participants de base | \npubliée ; reprise ISO IEEE/ISO 11073-10700-2024 | \napprouvée 2022-11-08, publiée 2023-09-15 ; version ISO 2024-09-16 | \n[5][19] | \n
| IEEE 11073-10701-2022 | \nPKP valeurs de mesure (metric) | \npubliée | \napprouvée 2022-12-03, publiée 2023-09-22 | \n[6][6] | \n
| IEEE P11073-10702 | \nPKP alarmes | \nprojet (Active PAR) | \nPAR 2019-03-21 | \n[16][3] | \n
| IEEE P11073-10703 | \nPKP commande externe | \nprojet (Active PAR) | \nPAR 2019-03-21 | \n[3][3] | \n
| IEEE P11073-10720 | \ncomposants modulaires de participants | \nen développement (Active PAR) | \nabsentes des sources | \n[20] | \n
| IEEE P11073-10107 | \nextension de la nomenclature avec des commandes pour la commande externe | \nen développement (Active PAR) | \nabsentes des sources | \n[21] | \n
| IEEE 11073-10101 | \nnomenclature partagée pour les dispositifs au chevet du patient et les PHD | \nédition active 2019, amendement 10101b-2023 | \npubliée 2019-10-09 | \n[17][22] | \n
| IEEE P11073-70000 | \nrapport des tests de conformité (TRISC) | \nprojet | \nabsentes des sources | \n[23] | \n
Les normes sont développées par l'IEEE 11073 Point-of-Care Devices (PoCD) Working Group, qui développe et promeut des normes IEEE pour l'interopérabilité des dispositifs médicaux.[8] L'IEEE SA Board approuve les normes, comme IEEE 11073-20701-2018 le 27 septembre 2018.[2] La PKP de base IEEE 11073-10700 a aussi été reprise comme norme ISO ; cette version est parue le 16 septembre 2024.[19] Les conditions auxquelles les textes des normes peuvent être obtenus n'ont pas été examinées lors de ce cycle.
\nL'association OR.NET e.V. réunit l'industrie, des cliniques et la recherche autour du raccordement ouvert et indépendant des fabricants de la technologie médicale dans les quartiers opératoires, les soins intensifs et d'autres soins aigus.[9] La diffusion de SDC est son objectif explicite.[9] Son adresse est « c/o SurgiTAIX AG » à Herzogenrath (Allemagne).[24]
\nL'outil de test open source SDCcc vérifie la conformité d'un dispositif aux trois normes centrales et n'évalue délibérément pas les normes PKP non encore publiées.[11] L'outil se comporte comme SDC Service Consumer, se connecte au dispositif testé et interagit avec lui pendant le déroulement du test.[25] TLS est obligatoire pour l'utiliser.[25] Un groupe de travail d'OR.NET organise régulièrement des Plug-a-thons, hybrides et virtuels, au cours desquels des implémentations sont testées les unes contre les autres à l'aide d'outils de test.[26] Le projet IEEE P11073-70000 doit fixer la manière de rapporter les tests de conformité pour la famille 11073.[23] Aucun schéma de conformité ou de certification assorti d'un label reconnu n'a été trouvé dans les sources traitées.
\nUn autre groupe de travail d'OR.NET travaille à un processus de délivrance ou de signature de certificats cryptographiques pour les dispositifs, une PKI pour SDC ; il s'agit d'un objectif de travail, pas d'un service opérationnel.[27]
\n| Implémentation | \nQuoi | \nStatut ou limite | \nAffirmation | \n
|---|---|---|---|
| sdc11073 | \nbibliothèque Python dans l'organisation GitHub de Dräger | \nselon le README, non destinée à des produits médicaux ni à la routine clinique | \n[28] | \n
| SDCLib/C | \nbibliothèque C++ | \nplus maintenue : ni développement, ni corrections de bogues, ni mises à jour de sécurité | \n[29] | \n
| sdcX | \npile SDC fermée de l'éditeur de SDCLib, présentée pour des produits commerciaux et des dossiers réglementaires | \naffirmation du fournisseur | \n[29] | \n
SDC règle le trafic entre dispositifs ; le chemin vers le DME passe par des passerelles que décrit IHE SDPi. La SOMDS DEC Gateway de SDPi est requise pour le mapping de SDC et de BICEPS vers HL7 v2 et vers les transactions du profil IHE DEC.[12] La HL7 Point-of-Care Device FHIR IG contient un mapping de la plupart des classes d'objets SDC vers des ressources FHIR telles que Device, DeviceMetric et Observation.[30] Ce guide est encore une version de ballot, pas prête pour un usage en production.[31]
" }, { "id": "ou-est-ce-utilise", "title": "Où est-ce utilisé ?", "kind": "tekst", "html": "| Partie | \nCe qu'elle dit | \nDate | \nNature | \nAffirmation | \n
|---|---|---|---|---|
| Ascom | \nfait partie des premières entreprises à avoir implémenté ISO/IEEE 11073 SDC et est membre d'OR.NET | \npage produit, consultée le 2026-11-09 | \naffirmation du fournisseur | \n[32] | \n
| GE HealthCare | \na annoncé son adhésion à OR.NET e.V. et qualifie SDC de protocole « émergent » | \n1er avril 2025 | \naffirmation du fournisseur | \n[33][33] | \n
| Fabricants au salon Medica | \npremiers dispositifs médicaux compatibles OR.NET présentés | \n2018 | \ncommuniqué d'OR.NET | \n[7] | \n
| Prestataires de services à la DMEA | \nservices pour l'implémentation de SDC présentés ; « réseau en croissance », sans chiffres de production ou d'utilisation | \navril 2026 | \ncommuniqué d'OR.NET | \n[34] | \n
En Allemagne, le VDE plaide en juillet 2026 pour que HL7 FHIR et ISO/IEEE 11073 valent comme exigence minimale lors des futurs achats de technologie médicale ; il s'agit d'une proposition politique, pas d'une obligation en vigueur.[35] Aucun pays qui impose légalement ou finance SDC n'a été trouvé.
\n| Source | \nQuoi | \nCe qu'elle ne dit pas | \nAffirmation | \n
|---|---|---|---|
| Marché public d'un hôpital belge pour des respirateurs aux soins intensifs (TED 748528-2026, 28 octobre 2026) | \n« protocole SDC » comme critère d'attribution de qualité avec 5 points | \nquelle norme ou version SDC est visée | \n[10] | \n
| Marché public d'un hôpital belge pour un logiciel CIED (TED 674691-2026, 1er octobre 2026) | \navec nexuzhealth (fournisseur du DPI CWS), un mapping des champs souhaités vers IEEE 11073-10103, la nomenclature pour les dispositifs cardiaques implantables, a été réalisé | \nil s'agit de la nomenclature 11073, pas de SDC lui-même | \n[36] | \n
| Le même marché CIED | \nune étude préalable a montré que les fabricants n'appliquent pas encore cette norme de manière uniforme | \n\n | [36] | \n
| Semaine du Connectathon IHE-Europe, Bruxelles, 23-27 mars 2026 | \nun Plugathon pour dispositifs, consacré à l'intégration SDC/SDPi | \npas de test formel du Connectathon | \n[37] | \n
Aucune mention de SDC n'a été trouvée dans les critères BMUC ou les critères relatifs au DME, dans des DME ou plateformes d'intégration belges, ni dans des sessions d'eHealth.
" }, { "id": "planification", "title": "Planification", "kind": "tekst", "html": "SDC relie les dispositifs entre eux et à une passerelle ; aujourd'hui, le DME reçoit les données via une passerelle qui les traduit vers HL7 v2 et le profil IHE DEC, avec les DME et l'aide à la décision comme destinataires possibles.[12][38] Le profil SDPi se démarque de la pratique actuelle, dans laquelle les dispositifs communiquent avec le serveur passerelle de leur fabricant via des protocoles propriétaires.[12] Voir Moteur d'intégration (interface engine) pour les moteurs qui traitent ces flux HL7 v2 à l'hôpital.
\nSécurité et réglementation. Implémenter le protocole SDC ne suffit pas pour démontrer la sécurité, l'efficacité et la sécurité informatique des fonctions système qui naissent de la combinaison de dispositifs.[5] Le MDR définit l'interopérabilité comme la capacité de dispositifs du même fabricant ou de fabricants différents à échanger des informations et à utiliser les informations qui ont été échangées.[39] L'annexe I exige que les dispositifs destinés à être mis en œuvre avec d'autres dispositifs aient une interopérabilité fiable et sûre, et que l'ensemble d'une combinaison, y compris le système de raccordement, soit sûr.[39][39] Les fabricants de dispositifs logiciels doivent énoncer les exigences minimales concernant le matériel informatique, les réseaux informatiques et la sécurité informatique.[39] Ces dispositions du MDR ne mentionnent pas SDC ; elles font peser l'obligation sur le fabricant. Selon l'EHDS, les exigences d'interopérabilité ne s'appliquent à un dispositif médical que dans la mesure où le fabricant allègue l'interopérabilité avec un système de DME.[40]
\nRecommandation (propre) : lors de l'achat de moniteurs, de respirateurs ou de pompes à perfusion, ne demandez pas seulement « SDC », mais les normes et versions concrètes (normes centrales, PKP), les profils SDPi et les acteurs de passerelle, la preuve de test (p. ex. SDCcc ou Plug-a-thon) et les exigences de réseau et de certificats que le fabricant impose ; fixez qui porte la responsabilité de la sécurité des combinaisons de dispositifs.
" }, { "id": "incertitudes-et-informations-contradictoires", "title": "Incertitudes et informations contradictoires", "kind": "tekst", "html": "