bêta L'eHealth Atlas est en construction : nous collectons et vérifions encore des données, le contenu peut donc être incomplet.Contenu encore incomplet. Plus d'informations

Base de référence belge sur la santé numérique

Ouvrage de référence indépendant · source non officielle bêta

Recherche avancée Aide

Fiche de concept · Norme ou spécification

IEEE 11073 SDC (connectivité des dispositifs orientée services)

Identifiant Atlas ieee-11073-sdc · 69 affirmations · 40 sources · Dernière vérification09-11-2026 · Version 2026.11.13-2

Type
Norme ou spécification
Juridiction
International
Cycle de vie
normatif — Les trois normes centrales ont été publiées (2017-2019), les deux premières normes de rôle en 2023 ; les normes pour les alarmes et la commande externe sont encore des projets (état selon l'IEEE SA au 9 novembre 2026).[1][2][3]
Version
normes centrales : 11073-20702-2016, 11073-10207-2017, 11073-20701-2018 ; normes de rôle : 11073-10700-2022, 11073-10701-2022
Alias
IEEE 11073 SDC; ISO/IEEE 11073 SDC; Service-oriented Device Connectivity; SDC (toestelconnectiviteit); OR.NET-protocol; OSCP; BICEPS; MDPWS
FR / EN / DE
IEEE 11073 SDC (connectivité des dispositifs orientée services) / IEEE 11073 Service-oriented Device Connectivity (SDC) / IEEE 11073 SDC (Service-oriented Device Connectivity)

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.

Relations 3 Sources 40 Graphe

En bref

✎ Commenter
  • Quoi : SDC est la famille de normes IEEE 11073 pour les dispositifs médicaux et systèmes informatiques médicaux distribués et orientés services au chevet du patient (point-of-care).[2]
  • Comment : le modèle de données BICEPS (IEEE 11073-10207) décrit les mesures, les réglages, les alarmes, le contexte et la commande à distance, le protocole MDPWS (IEEE 11073-20702) les transporte sous forme de services web, et IEEE 11073-20701 relie les deux.[4][1][2]
  • État : les trois normes centrales ont été publiées entre 2017 et 2019 et les normes de rôle pour les participants de base et les valeurs de mesure en 2023, tandis que les normes de rôle pour les alarmes et la commande externe sont en cours en tant que projets depuis 2019.[1][2][5][6][3]
  • Origine et gestion : SDC est issu du projet de recherche allemand OR.NET et est développé par le groupe de travail IEEE 11073 Point-of-Care Devices ; l'association OR.NET e.V. veut diffuser la norme.[7][8][9]
  • Pour qui : un marché public belge pour des respirateurs aux soins intensifs (octobre 2026) a attribué 5 points au « protocole SDC » comme critère de qualité, sans préciser quelle norme SDC est visée.[10]
  • Principale incertitude : selon la norme de base, le protocole SDC ne suffit pas à démontrer la sécurité d'une fonction système composée de plusieurs dispositifs, et les normes de rôle ne sont pas encore vérifiées par l'outil de test ouvert.[5][11]

Qu'est-ce que c'est ?

✎ Commenter

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]

Attention à 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.

Trois couches et les normes de rôle

La famille se compose de trois normes centrales, qui règlent chacune une couche :

  • Modèle de données (BICEPS, IEEE 11073-10207). Le Participant Model fixe la structure des objets d'information médicale ; un Communication Model abstrait décrit la manière dont ils sont échangés.[4] Le modèle couvre les mesures et les réglages, les systèmes d'alarme, les informations de contexte telles que les données démographiques du patient et la localisation, la commande à distance et les informations d'archive.[4] Pour la signification des données, il utilise la nomenclature IEEE 11073-10101 et prend en charge d'autres systèmes de codes ; le transport réseau sort du champ de cette norme.[14]
  • Protocole (MDPWS, IEEE 11073-20702). MDPWS est le protocole de communication de SDC : il profile des spécifications de services web pour des systèmes qui échangent des données ou commandent de manière sûre des dispositifs en réseau.[1] Le Devices Profile for Web Services (DPWS) en constitue le fondement, adapté à un système distribué de dispositifs au chevet du patient.[15]
  • Architecture et liaison (IEEE 11073-20701). Cette norme relie le modèle de participant, le modèle de découverte et le modèle de communication de BICEPS au transport par services web de MDPWS.[2] Elle fixe aussi une liaison vers NTP pour la synchronisation de l'heure et vers DiffServ pour la qualité de service lors du transport.[2] Elle exige des canaux sécurisés entre participants via TLS avec authentification mutuelle.[12]

S'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]

La 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]

Historique

SDC 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]

Comment est-ce structuré ?

✎ Commenter

Normes, statut et dates

É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.

Norme Titre ou rôle Statut Dates Affirmations
IEEE 11073-20702-2016 MDPWS : protocole de services web publiée ; projet de révision en cours approuvée 2016-09-22, publiée 2017-05-26 ; PAR de révision 2026-03-26 [1][1][15]
IEEE 11073-10207-2017 BICEPS : modèle de domaine et de services publiée, corrigendum Cor 1-2025 ; projet de révision en cours approuvée 2017-12-06, publiée 2018-02-21 ; PAR de révision 2026-03-26 [4][4][14]
IEEE 11073-20701-2018 architecture et liaison de BICEPS à MDPWS norme active approuvée 2018-09-27, publiée 2019-01-15 [2][2]
IEEE 11073-10700-2022 PKP participants de base publiée ; reprise ISO IEEE/ISO 11073-10700-2024 approuvée 2022-11-08, publiée 2023-09-15 ; version ISO 2024-09-16 [5][19]
IEEE 11073-10701-2022 PKP valeurs de mesure (metric) publiée approuvée 2022-12-03, publiée 2023-09-22 [6][6]
IEEE P11073-10702 PKP alarmes projet (Active PAR) PAR 2019-03-21 [16][3]
IEEE P11073-10703 PKP commande externe projet (Active PAR) PAR 2019-03-21 [3][3]
IEEE P11073-10720 composants modulaires de participants en développement (Active PAR) absentes des sources [20]
IEEE P11073-10107 extension de la nomenclature avec des commandes pour la commande externe en développement (Active PAR) absentes des sources [21]
IEEE 11073-10101 nomenclature partagée pour les dispositifs au chevet du patient et les PHD édition active 2019, amendement 10101b-2023 publiée 2019-10-09 [17][22]
IEEE P11073-70000 rapport des tests de conformité (TRISC) projet absentes des sources [23]

Gestion

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.

L'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]

Tests et conformité

L'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.

Un 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]

Bibliothèques open source

Implémentation Quoi Statut ou limite Affirmation
sdc11073 bibliothèque Python dans l'organisation GitHub de Dräger selon le README, non destinée à des produits médicaux ni à la routine clinique [28]
SDCLib/C bibliothèque C++ plus maintenue : ni développement, ni corrections de bogues, ni mises à jour de sécurité [29]
sdcX pile SDC fermée de l'éditeur de SDCLib, présentée pour des produits commerciaux et des dossiers réglementaires affirmation du fournisseur [29]

Mappings vers HL7 v2 et FHIR

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]

Où est-ce utilisé ?

✎ Commenter

Fabricants et marché (affirmations des fournisseurs)

Partie Ce qu'elle dit Date Nature Affirmation
Ascom fait partie des premières entreprises à avoir implémenté ISO/IEEE 11073 SDC et est membre d'OR.NET page produit, consultée le 2026-11-09 affirmation du fournisseur [32]
GE HealthCare a annoncé son adhésion à OR.NET e.V. et qualifie SDC de protocole « émergent » 1er avril 2025 affirmation du fournisseur [33][33]
Fabricants au salon Medica premiers dispositifs médicaux compatibles OR.NET présentés 2018 communiqué d'OR.NET [7]
Prestataires de services à la DMEA services pour l'implémentation de SDC présentés ; « réseau en croissance », sans chiffres de production ou d'utilisation avril 2026 communiqué d'OR.NET [34]

Pays

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é.

Belgique (consulté le 9 novembre 2026)

Source Quoi Ce qu'elle ne dit pas Affirmation
Marché public d'un hôpital belge pour des respirateurs aux soins intensifs (TED 748528-2026, 28 octobre 2026) « protocole SDC » comme critère d'attribution de qualité avec 5 points quelle norme ou version SDC est visée [10]
Marché public d'un hôpital belge pour un logiciel CIED (TED 674691-2026, 1er octobre 2026) avec 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é il s'agit de la nomenclature 11073, pas de SDC lui-même [36]
Le même marché CIED une étude préalable a montré que les fabricants n'appliquent pas encore cette norme de manière uniforme [36]
Semaine du Connectathon IHE-Europe, Bruxelles, 23-27 mars 2026 un Plugathon pour dispositifs, consacré à l'intégration SDC/SDPi pas de test formel du Connectathon [37]

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.

Planification

✎ Commenter
  • Révision des normes centrales. Pour IEEE 11073-20702 et IEEE 11073-10207, des projets de révision ont été approuvés le 26 mars 2026 ; ils doivent remplacer les versions de 2016 et 2017.[15][14]
  • Alarmes et commande externe. Depuis l'approbation de leur proposition de projet le 21 mars 2019, P11073-10702 et P11073-10703 figurent comme projets en cours, et non comme normes publiées.[3] SDPi 2.4 intègre déjà la norme sur les alarmes à titre d'intégration anticipée, sous la forme de l'option « Distributed Alarm System ».[12] P11073-10107 doit étendre la nomenclature avec des commandes pour la commande externe.[21]
  • Participants modulaires. P11073-10720 doit définir des composants modulaires de participants en limitant l'optionnalité de BICEPS, en prescrivant des codes de nomenclature spécifiques et en spécifiant le comportement de communication.[20]
  • Rapport des tests. P11073-70000 (TRISC) doit régler le rapport des tests de conformité.[23]

Qu'est-ce que cela signifie pour un hôpital ?

✎ Commenter

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.

Sé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]

Recommandation (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.

Incertitudes et informations contradictoires

✎ Commenter
  • Le marché public belge pour des respirateurs mentionne le « protocole SDC » sans norme ni version ; les cahiers des charges eux-mêmes n'ont pas été lus.[10]
  • Les normes pour les alarmes et la commande externe figurent comme projets depuis 2019 ; aucune date de publication n'a été trouvée.[3]
  • L'outil de test ouvert vérifie uniquement les trois normes centrales, pas les normes de rôle ; selon cette source, aucun test de conformité pour les PKP n'est donc disponible publiquement.[11]
  • Une bibliothèque open source largement utilisée n'est plus maintenue et une autre n'est pas destinée à des produits médicaux ; les implémentations dans des produits reposent donc sur d'autres piles, en partie fermées.[29][28][29]
  • Les chiffres d'adoption manquent : les sources sur les fabricants sont des affirmations de fournisseurs ou des communiqués d'OR.NET sans chiffres de production ou d'utilisation.[34][32]
  • La PKI pour les certificats de dispositifs est un objectif de travail, pas un service opérationnel.[27]

Diagramme

Van toestel aan het bed naar het EPD (IEEE 11073 SDC en IHE SDPi) Stand 9 november 2026. Vereenvoudigd procesmodel op basis van de normen en het SDPi-supplement; geen weergave van een specifieke ziekenhuisimplementatie.
Van toestel aan het bed naar het EPD (IEEE 11073 SDC en IHE SDPi) Toestellen aan het bed operatiekwartier,intensieve zorg, spoed Gateway Ziekenhuistoepassingen 1. SDC: BICEPS-gegevens via MDPWS, TLS met wederzijdse authenticatie2. Toestelgegevens via SDC naar de gateway3. HL7 v2 volgens IHE DEC (en ACM voor alarmen)4. Patiëntdemografie uit het EPD (bidirectionele gateway)5. FHIR (PoCD IG): gepland, nog niet klaar voor productie Toestel (SDC-provider) (monitor, beademing, infuuspomp) Toestel (SDC-provider) monitor, beademing, infuuspomp Ander toestel of systeem (SDC-consumer) Ander toestel of systeem (SDC-consumer) SDPi-gateway (SOMDS DEC Gateway (SDPi-R)) SDPi-gateway SOMDS DEC Gateway (SDPi-R) EPD (ook beslissingsondersteuning, datarepository) EPD ook beslissingsondersteuning, datarepository 1 2 3 4 5

avec source hypothèse, projet ou position Conception propre, simplifiée · CC BY 4.0 · affirmations

  1. 1 Toestel (SDC-provider) → Ander toestel of systeem (SDC-consumer): SDC: BICEPS-gegevens via MDPWS, TLS met wederzijdse authenticatie[2][12]
  2. 2 Toestel (SDC-provider) → SDPi-gateway: Toestelgegevens via SDC naar de gateway[12]
  3. 3 SDPi-gateway → EPD: HL7 v2 volgens IHE DEC (en ACM voor alarmen)[12][38]
  4. 4 EPD → SDPi-gateway: Patiëntdemografie uit het EPD (bidirectionele gateway)[12]
  5. 5 SDPi-gateway → EPD: FHIR (PoCD IG): gepland, nog niet klaar voor productie (hypothèse)[12]

Relations 3 relations · 0 hypothèses

RelationConcept cibleTypeStatutPrécision
relève de org:ieee (pas de page) établi IEEE publiceert de normen; de IEEE 11073 Point-of-Care Devices-werkgroep ontwikkelt ze ook. [8][2]
utilise la terminologie Nomenclature ISO/IEEE 11073 des dispositifs médicaux (MDC) Terminologie ou classification établi Via het datamodel BICEPS (IEEE 11073-10207), dat daarnaast andere codesystemen ondersteunt. [14]
profile (entrant) IHE SDPi (Service-oriented Device Point-of-care Interoperability) Norme ou spécification établi [12]

Questions ouvertes 7

  1. Welke Belgische ziekenhuizen of netwerken vragen SDC of IHE SDPi in hun bestekken (monitoring, beademing, anesthesie, infuus), en met welk gewicht? Eén aanbesteding gevonden; de bestekken zelf zijn niet gelezen. Aidez-nous à répondre à cette question
  2. Wanneer worden IEEE 11073-10702 (alarmen) en -10703 (externe bediening) gepubliceerd, en wat wijzigt de lopende revisie van -10207 en -20702? Aidez-nous à répondre à cette question
  3. Welke toestellen op de Belgische markt dragen een gecertificeerde of zelfverklaarde SDC-interface (fabrikantdocumentatie, CE-documentatie)? Aidez-nous à répondre à cette question
  4. Draagt OR.NET e.V. formeel bij aan de normtekst in de IEEE-werkgroep, of beperkt zijn rol zich tot verspreiding, testen en profilering? De bronnen noemen enkel de oorsprong in het OR.NET-project. Aidez-nous à répondre à cette question
  5. Wie zal in Europa de PKI voor apparaatcertificaten beheren waar OR.NET aan werkt, en hoe verhoudt dat zich tot het certificaatbeheer van een ziekenhuis? Aidez-nous à répondre à cette question
  6. Ondersteunen de in België gebruikte ziekenhuis-EPD's (KWS, HiX, Epic, ...) of integratieplatformen een SDC- of SDPi-gateway, of enkel HL7 v2 via een fabrikantgateway? Aidez-nous à répondre à cette question
  7. Onder welke voorwaarden zijn de normteksten verkrijgbaar (aankoop, abonnement, vrije toegang)? Aidez-nous à répondre à cette question

Sources 40 sources · toutes les sources

  1. IEEE 11073-20702-2016 - Medical Devices Communication Profile for Web Services. IEEE Standards Association; 26-05-2017. SRC-4fbb21172e Lien cassé ?
  2. IEEE 11073-20701-2018 - Service-Oriented Medical Device Exchange Architecture and Protocol Binding. IEEE Standards Association; 15-01-2019. SRC-9b8cc5d0d2 Lien cassé ?
  3. IEEE P11073-10703 - External Control by Participants in an SDC System (project). IEEE Standards Association. SRC-79552a00e8 Lien cassé ?
  4. IEEE 11073-10207-2017 - Domain Information and Service Model for Service-Oriented Point-of-Care Medical Device Communication. IEEE Standards Association; 21-02-2018. SRC-1000718e83 Lien cassé ?
  5. IEEE 11073-10700-2022 - Base Requirements for Participants in a Service-Oriented Device Connectivity (SDC) System. IEEE Standards Association; 15-09-2023. SRC-aafeddba03 Lien cassé ?
  6. IEEE 11073-10701-2022 - Metric Provisioning by Participants in a Service-Oriented Device Connectivity (SDC) System. IEEE Standards Association; 22-09-2023. SRC-7448e5decd Lien cassé ?
  7. SDC Historie. OR.NET e.V.. SRC-dbf5a4f97d Lien cassé ?
  8. Point-of-Care Devices (PoCD) Working Group. IEEE Standards Association. SRC-1db5a4c6fb Lien cassé ?
  9. Was ist OR.NET e.V.?. OR.NET e.V.. SRC-a53c67b2b4 Lien cassé ?
  10. TED 748528-2026 - Accord cadre pour la fourniture et installation de respirateurs pour l'unité des soins intensifs. Publicatiebureau van de Europese Unie (TED); 28-10-2026. SRC-dd62ba946e Lien cassé ?
  11. SDC Testing. OR.NET e.V.. SRC-d83092ade3 Lien cassé ?
  12. IHE Devices Technical Framework Supplement - Service-oriented Device Point-of-care Interoperability (SDPi), Revision 2.4.1. IHE International / HL7 International (Gemini); 07-05-2026. SRC-9c5596d356 Lien cassé ?
  13. Structured Data Capture FHIR IG v4.0.0. HL7 International. SRC-73555c4cba Lien cassé ?
  14. IEEE P11073-10207 (revisieproject). IEEE Standards Association. SRC-1e84a880cf Lien cassé ?
  15. IEEE P11073-20702 (revisieproject). IEEE Standards Association. SRC-2879b5a4a3 Lien cassé ?
  16. IEEE P11073-10702 - Alert Provisioning by Participants in an SDC System (project). IEEE Standards Association. SRC-c6062132d1 Lien cassé ?
  17. IEEE/ISO 11073-10101-2020 - Nomenclature. IEEE Standards Association; 28-08-2020. SRC-8e040d9d00 Lien cassé ?
  18. ISO/TC 215 - catalogue des normes. ISO. SRC-33ebbf242d Lien cassé ?
  19. IEEE/ISO 11073-10700-2024. IEEE Standards Association; 16-09-2024. SRC-be810f8f66 Lien cassé ?
  20. IEEE P11073-10720 - Module Specifications (project). IEEE Standards Association. SRC-5aa1960048 Lien cassé ?
  21. IEEE P11073-10107 - Nomenclature for External Control of Medical Devices (project). IEEE Standards Association. SRC-e831668f31 Lien cassé ?
  22. IEEE 11073-10101-2019 - Health informatics--Point-of-care medical device communication - Part 10101: Nomenclature. IEEE Standards Association; 09-10-2019. SRC-e8042c9010 Lien cassé ?
  23. IEEE P11073-70000 - Test Reporting for Interoperability Standards Conformance (project). IEEE Standards Association. SRC-bb6567bad5 Lien cassé ?
  24. Impressum und Datenschutz. OR.NET e.V.. SRC-be0e0dfcd5 Lien cassé ?
  25. SDCcc - SDC conformance test tool (README). Drägerwerk (GitHub). SRC-4415f14912 Lien cassé ?
  26. Arbeitsgruppe (Stack-)Entwicklung, Tests, Tools und Plug-a-thons. OR.NET e.V.. SRC-01e2c384e5 Lien cassé ?
  27. Arbeitsgruppe Zertifikatsinfrastruktur und Security. OR.NET e.V.. SRC-771c504e08 Lien cassé ?
  28. sdc11073 - Python implementation of IEEE 11073 SDC (README). Drägerwerk (GitHub). SRC-029c224d20 Lien cassé ?
  29. SDCLib/C (README). SurgiTAIX AG (GitHub). SRC-b38cd813e8 Lien cassé ?
  30. Point-of-care Device FHIR IG - Mapping from IEEE 11073-10207 SDC to FHIR. HL7 International / Devices. SRC-a21f1eba87 Lien cassé ?
  31. Point-of-care Device FHIR IG - package-list (publicatiegeschiedenis). HL7 International / Devices. SRC-a56ab39973 Lien cassé ?
  32. SDC - Service-oriented Device Connectivity. Ascom. SRC-31bafec0d4 Lien cassé ?
  33. GE HealthCare joins OR.NET e.V. to support SDC protocol. GE HealthCare; 01-04-2025. SRC-4554c9de76 Lien cassé ?
  34. SDC - Wir sind viele (OR.NET e.V. auf der DMEA 2026). OR.NET e.V.; 24-04-2026. SRC-5ddb3122ae Lien cassé ?
  35. Vernetzte Medizintechnik - Motor der Digitalisierung. VDE; 07-07-2026. SRC-579fb4f63b Lien cassé ?
  36. TED 674691-2026 - Gebruik en onderhoud van CIED software. Publicatiebureau van de Europese Unie (TED); 01-10-2026. SRC-f1e50b9e9d Lien cassé ?
  37. IHE Plugathon 2026. IHE-Europe. SRC-37bb7cb6dc Lien cassé ?
  38. PCD Profile DEC Overview. IHE International. SRC-0dc4ccbb28 Lien cassé ?
  39. Regulation (EU) 2017/745 — Medical Device Regulation. Europese Unie; 05-05-2017. SRC-4f1876b9f1 Lien cassé ?
  40. Regulation (EU) 2025/327 of the European Parliament and of the Council of 11 February 2025 on the European Health Data Space and amending Directive 2011/24/EU and Regulation (EU) 2024/2847. Europees Parlement en Raad van de EU (EUR-Lex); 05-03-2025. SRC-af26b6d770 Lien cassé ?
Fiche ieee-11073-sdc · dernière vérification le 09-11-2026 · version 2026.11.13-2 · texte sous CC BY 4.0, sources uniquement liées
Améliorer cette page
Réutilisation : Cette page en Markdown · JSON