Brevet FR2803148A1 — publié le 20010629

SERVICE INTERACTIF INTEGRE POUR UNE PLURALITE DE SYSTEMES DE DIAGNOSTIC MEDICAL DOMAINE DE L'INVENTION La présente invention concerne globalement le domaine des systèmes de diagnostic médical, et l'assistance à ces systèmes par un fournisseur de services à distance. Plus particulièrement, l'invention porte sur une technique destinée à faciliter l'assistance fournie à un certain nombre de systèmes de diagnostic médical d'une manière interactive via des connexions par réseau entre ces systèmes et un fournisseur de services à distance. CONTEXTE DE L'INVENTION Des installations de diagnostic médical, incluant des cliniques, des hôpitaux, des établissements de consultations externes, et des services à l'intérieur de ces organisations disposent souvent d'un ensemble de systèmes de diagnostic. A titre d'exemple, une clinique ou un hôpital peut inclure divers systèmes d'imagerie diagnostique médicale dans un département de radiologie, ou dans plusieurs départements de radiologie. Des cliniques et des cabinets annexes ou satellites peuvent inclure des équipements supplémentaires, fixes et mobiles. Ces systèmes d'imagerie peuvent typiquement inclure des systèmes d'imagerie par résonance magnétique (IRM), des tomodensitomètres (TDM), des appareils de radiographie, des appareils d'échographie, des caméras tomographiques à positons (PET), etc. Des systèmes de diagnostic supplémentaires peuvent inclure divers types d'appareils de surveillance, d'outils d'examen électronique ou de diagnostic, etc. A cause des horaires extrêmement exigeants et de la relative complexité de ces systèmes et équipements, ces installations traitent typiquement avec des fournisseurs de services extérieurs pour leur surveillance et leur maintenance. Dans une approche traditionnelle de l'assistance, un technicien d'assistance à la clientèle visite physiquement une installation et examine l'état de fonctionnement des systèmes, en notant tous les problèmes potentiels et en ordonnant toute assistance nécessaire au maintien de l'équipement en bon état de fonctionnement. Ces visites du technicien d'assistance à la clientèle sont aussi utiles pour mettre l'équipement à niveau, ce qui inclut des mises à niveau physiques et logicielles. Le technicien d'assistance à la clientèle, ou tout autre personnel spécialisé, peut aussi visiter les installations pour proposer une formation ou pour répondre à des questions concernant la configuration et le fonctionnement corrects de l'équipement. Bien que les visites conventionnelles du technicien d'assistance à la clientèle soient très utiles pour répondre à des besoins spécifiques lorsqu'ils apparaissent, l'assistance à distance aux systèmes de diagnostic médical a été modernisée par connexion en réseau des systèmes à un fournisseur de services à distance. Dans une approche connue, par exemple, des systèmes de diagnostic individuels peuvent être connectés via un réseau ouvert ou privé à un fournisseur de services à distance. La connexion peut être établie au lancement du système de diagnostic, ou par le fournisseur de services, en utilisant des techniques conventionnelles d'exploitation de réseau. Des données requises pour fournir le service, analyser des problèmes potentiels ou existants, etc., sont transmises via la connexion au réseau. En outre, des demandes de services, et une réponse à ces demandes, peuvent être transmises de façon similaire via le réseau. L'assistance à distance par réseau aux systèmes de diagnostic médical a fait preuve d'une grande efficacité et recevra un accueil de plus en plus favorable dans le futur. Ces techniques ne sont toutefois pas dépourvues d'inconvénients. Par exemple, il existe une base très substantielle d'utilisateurs de systèmes qui ne sont pas équipés en vue d'une connexion à un réseau externe. En général, les techniques actuelles incluent l'utilisation de divers types de modems pour une communication bidirectionnelle de données. Cependant, quand ce modem ou un circuit similaire n'est pas installé, un système peut être simplement incapable d'envoyer ou de recevoir des données pour une assistance à distance. En outre, quand des systèmes abonnés n'incluent pas de modems ou d'autres interfaces de télécommunications, des connexions et des sessions de transmission de données séparées sont typiquement requises pour chacun des systèmes, à cause de leur gestion indépendante et de la topologie globale de l'échange de données d'assistance à distance. Un autre inconvénient des techniques existantes d'assistance à distance aux systèmes de diagnostic médical est la coordination relativement limitée entre l'assistance et les fonctions internes ou externes de compte rendu et de comptabilité. Quand des systèmes de diagnostic individuels contactent ou sont contactés par un fournisseur de services à distance, par exemple, le fournisseur de services à distance conserve typiquement des journaux de données et des registres comptables qu'il présente à l'établissement ou l'installation pour résumer les activités d'assistance ou de maintenance. L'établissement peut toutefois être lui-même incapable de conserver ces registres, ou de les conserver efficacement, du fait des contacts indépendants établis entre les systèmes de diagnostic médical et le fournisseur de services à distance. Il existe donc un besoin d'une meilleure technique pour fournir des services à des systèmes de diagnostic médical via une connexion de service à distance. Il existe un besoin particulier d'une technique qui proposerait un échange interactif de données, de demandes, de comptes rendus, etc., tout en réduisant le nombre de connexions séparées requises, ainsi que les frais généraux de l'infrastructure nécessaire pour formuler et transmettre les données. RESUME DE L'INVENTION La présente invention fournit une technique d'assistance à distance à des systèmes de diagnostic médical conçue pour répondre à ces besoins. La technique est particulièrement bien adaptée à des installations incluant un grand nombre de systèmes de diagnostic, mobiles et fixes. La technique peut être appliquée à des installations et établissements comprenant un seul lieu ou département, ou à des installations dispersées ou intégrées comprenant des cabinets satellites, des départements disparates, etc. En outre, la technique est bien adaptée à des établissements ou départements dans lesquels de multiples systèmes sont ou peuvent être connectés à un réseau interne, tel qu'un réseau Ethernet, pour un échange rapide de données à l'intérieur de l'établissement. Selon une forme de réalisation présentement préférée, des demandes de données de service, des échanges de données et autres peuvent être formulés soit directement au niveau des systèmes de diagnostic individuels, soit au niveau d'un système de commande relié aux systèmes via un réseau interne. Les demandes de données, au sens global, peuvent inclure à la fois des demandes de maintenance ou d'assistance des systèmes, des demandes d'informations, des demandes de documentation, des demandes d'examen de protocoles, des demandes de mise à niveau de logiciels, etc. Une fois que la demande est formulée, un système de commande de transmission de données transmet la demande à un fournisseur de service à distance via un réseau externe. BREVE DESCRIPTION DES DESSINS La figure 1 est une vue d'ensemble schématique d'un système de transmission de données pour transmettre des données provenant d'une série de systèmes de diagnostic médical à un fournisseur de services ou de données à distance; la figure 2 est une vue schématique d'un exemple de système de commande de transmission de données selon certains aspects de la présente technique, à usage avec le système représenté sur la figure 1; la figure 3 est un schéma de flux de données illustrant les trajets suivis par les données dans les communications entre les divers composants du système de la figure 1; la figure 4 est un organigramme représentant un exemple de logique de commande de lancement d'une demande de service ou d'un autre transfert de données entre un système de diagnostic médical et un fournisseur de services à distance; la figure 5 est un organigramme représentant un exemple de logique de commande de gestion des demandes de services ou de données par un fournisseur de services à distance, et de renvoi de données en réponse à cette demande; la figure 6 est un organigramme représentant un exemple de logique de commande de réception d'une transmission provenant d'un fournisseur de services à distance au niveau de l'installation de diagnostic médical; la figure 7 est un organigramme représentant un exemple de logique de commande de réception de données via un moyen auxiliaire de transmission de données; la figure 8 est un organigramme représentant un exemple de logique de commande d'interrogation des systèmes d'une installation de diagnostic médical ou de recueil de données à renvoyer à un fournisseur de services à distance; et la figure 9 est un organigramme représentant un exemple de logique de commande d'accès aux données collectées dans l'opération de la figure 8 en vue d'un traitement et d'une mémorisation par un fournisseur de services à distance. DESCRIPTION DETAILLEE DE L'INVENTION A propos maintenant des figures, la figure 1 représente un système de transmission de données, repéré globalement 10, servant à transmettre des données d'exploitation ou paramètres d'une série de systèmes de diagnostic médical à un fournisseur de services ou de données à distance. Le système permet aussi des échanges interactifs de données, de demandes de services, de logiciels, etc., entre les systèmes et le fournisseur de services à distance de façon décrite plus en détail plus bas. Tel que représenté sur la figure 1, le système 10 inclut globalement une installation de diagnostic médical 12 qui est reliée à un fournisseur de services ou de données à distance 14. L'installation 12 peut inclure un seul lieu ou site 16, ou des sites supplémentaires 18, qui peuvent être géographiquement proches ou éloignés du site 16. Dans ce cas, les sites supplémentaires peuvent généralement être interconnectés au site 16 via un réseau interne de l'installation. A l'intérieur de l'installation 12, un réseau interne 20 fournit un moyen de transmission de données entre une série de systèmes de diagnostic médical, qui au besoin peuvent constituer des groupes ou départements 22, tels que des étages, des salles, des zones de traitement ou de diagnostic spécialisés, etc. Une série de systèmes de diagnostic médical, qui seront appelés généralement clients 24 dans la présente, est couplée au réseau 20 soit par des connexions permanentes au réseau, soit par des connexions temporaires au réseau. Par conséquent, bien que certains ou la plupart des clients 24 puissent être fixes, certains des clients peuvent être mobiles, ce qui permet d'utiliser le client ou l'équipement en tout lieu souhaité, et de le coupler au réseau interne une fois placé en un lieu souhaité. L'expression "système de diagnostic médical", telle qu'on l'utilise dans la présente, doit être comprise comme englobant une grande diversité d'équipements, de systèmes et de sous-systèmes. A titre d'exemple, des systèmes de diagnostic médical peuvent inclure des systèmes d'imagerie diagnostique conçus pour produire des images utiles de structures anatomiques d'un patient selon une nature ou une modalité particulière. D'autres systèmes de diagnostic médical peuvent inclure des appareils de surveillance de patient, des capteurs, des transducteurs et autres dispositifs de génération de signal ou de régulation. En outre, les systèmes de diagnostic médical communiquant selon la présente technique peuvent inclure des systèmes de gestion informatique, des postes de travail, des postes de visualisation d'images ou de données, etc. A titre d'exemple, sur la figure 1, une série de systèmes d'imagerie diagnostique médicale est représentée dans un seul groupe. En pratique, ce groupe peut être associé physiquement ou logiquement à un département de radiologie ou une clinique. Dans la forme de réalisation représentée sur la figure 1, ces systèmes incluent un système d'imagerie par résonance magnétique (IRM) 26, un tomodensitomètre (TDM) 28, un appareil de radiographie 30 et un appareil d'échographie 32. Ces systèmes sont tous de préférence des systèmes de diagnostic clients de la présente technique. Comme le comprendront les personnes compétentes dans l'art, chacun de ces systèmes imageurs est configuré pour produire des données d'image utiles selon la nature particulière de leur modalité respective. De façon déjà indiquée, certains de ces systèmes peuvent être mobiles, tels que des appareils d'échographie qui peuvent être relogés dans une salle ou une zone d'examen souhaitée et connectés au réseau 20 au niveau de cette zone ou une fois ramenés à une station de base. A titre d'autre exemple, dans la forme de réalisation de la figure 1, les systèmes de diagnostic clients incluent aussi une série de postes de gestion informatique. Les clients peuvent alors inclure un système informatique de département de radiologie (SIR), repéré 34, conçu pour gérer la production et le flux de données d'image conjointement aux systèmes imageurs 26, 28, 30 et 32. Un système informatique d'hôpital (SIH) 36 fournit des données supplémentaires de patients, financières, et autre assistance technique pour l'exploitation de l'installation 12 selon des techniques globalement connues. Enfin, un système d'archivage et de transmission d'images (SATI) 38 permet une mémorisation, un traitement, un accès et un archivage des fichiers de données produits par les systèmes d'imagerie diagnostique. Chacun des systèmes de diagnostic clients est couplé au réseau 20 pour échanger des données avec un fournisseur de services ou de données à distance, de façon décrite plus bas. Dans des techniques d'échange de données précédemment connues, certains des systèmes clients peuvent être équipés en vue d'un échange indépendant de données d'exploitation ou de paramètres requis pour une assistance, une maintenance, une analyse, une comptabilité et besoins similaires. Selon ces techniques, une connexion indépendante peut être établie entre les équipements et un fournisseur de services à distance, par exemple une connexion par un modem indépendant telle que représentée pour l'appareil d'échographie 32 de la figure 1. Selon la présente technique, bien que certains des systèmes puissent continuer à utiliser cette connexion directe, les systèmes de diagnostic clients n'ont pas besoin de cette connectabilité individuelle. Au contraire, des données peuvent être échangées entre les systèmes et un fournisseur de services ou de données à distance via le réseau 20. Dans la forme de réalisation présentement préférée, le réseau 20 comprend un réseau interne à grand débit, tel qu'un réseau Ethernet. Dans des formes de réalisation courantes, le réseau peut être un réseau à 10 Mb ou 100 Mb échangeant des données selon un protocole standard d'échange de données, tel que TCP/IP. On peut naturellement employer une autre architecture et d'autres normes de réseau interne. Le système de télécommunications inclut en outre un système de commande de transmission de données (SCTD) 40 qui est couplé au réseau 20 en vue de recevoir ou d'accéder à des données du client, et d'échanger des données avec un ou plusieurs fournisseurs de services ou de données à distance. Le SCTD 40 est donc couplé à un circuit de télécommunications externe, tel qu'un modem 42 et un décodeur de télécommunications par satellite 44. Le modem 42, et tous les modems supplémentaires souhaités, peuvent être de n'importe quel type approprié, tel qu'un modem à 56 kb/s selon la présente technique, un modem câble, ou n'importe quelle interface de télécommunications par réseau externe. Le décodeur 44 peut de même être n'importe quelle interface de télécommunications par satellite ou hertziennes, tel qu'un récepteur-décodeur intégré (IRD) du type disponible chez Scientific Atlanta aux Etats-Unis. De façon décrite plus en détail plus bas, l'utilisation de moyens d'émission et de réception en parallèle de données permet au SCTD 40 d'optimiser l'utilisation de la largeur de bande disponible dans les échanges de données entre l'installation et le fournisseur de services à distance. A titre d'exemple, le modem 42 peut offrir une largeur de bande de 56 kb/s, tandis que le décodeur 44 offre une largeur de bande nettement plus grande, telle que de 500 kb/s. Les transmissions de données vers et depuis l'installation 12 passent par une liaison 46 au réseau externe menant au modem 42, et par une liaison 48 de télécommunications par satellite menant au décodeur 44. La liaison 46 au réseau externe est couplée, par exemple par câbles téléphoniques conventionnels, par fibres optiques, ou autrement, à un réseau 50 tel qu'un grand réseau de télécommunications. Le réseau 50 peut toutefois être n'importe quel type de réseau approprié, incluant les réseaux privés virtuels ou l'Internet. L'isolation et la protection de l'intégrité du système informatique de l'installation 12 peuvent être assurées par une ou plusieurs barrières de sécurité 52. La liaison par satellite 48, qui fait aussi globalement partie du réseau externe assurant la transmission de données vers et depuis l'installation, sert à recevoir des données relayées par un satellite 54, ou par des répéteurs, émetteurs, etc., au sol. Les données provenant de l'installation 12 sont échangées avec un fournisseur de services 14 par les connexions au réseau externe décrites plus haut. Globalement, un fournisseur de services à distance 14 peut inclure un site principal 56, et des sites supplémentaires 58, interconnectés par des réseaux ouverts ou privés. Un fournisseur de services à distance 14, à titre d'exemple, peut inclure une ou des installations destinées à recevoir des demandes de données et de services provenant de l'installation de diagnostic médical sur la base d'un abonnement ou d'un contrat. Des services, des données, une formation, une assistance technique et autres informations peuvent alors être fournies aux installations abonnées par l'intermédiaire des connexions au réseau et selon les techniques décrites plus bas. Dans l'exemple illustré, le fournisseur de services à distance 14 inclut son propre réseau interne, tel qu'un réseau local Ethernet. Une série de clients ou systèmes est interconnectée par le réseau pour échanger des données de façon interne et avec l'installation de diagnostic médical. A titre d'exemple, un système de service, repéré globalement 62, est prévu pour recevoir et traiter des données de service, telles que des demandes de services, des demandes de protocole, des questions, etc. Le système de service 62 peut aussi être équipé pour programmer des communications de service normales ou spéciales, fournir des comptes rendus et des analyses de données d'exploitation ou de paramètres, etc. Dans l'exemple illustré, le fournisseur de services à distance 14 inclut aussi un centre d'assistance technique automatisée (CATA) repéré globalement 64. Le centre peut remplir diverses fonctions automatisées, incluant l'acquisition ou le recueil de données d'exploitation et de paramètres de l'installation, de façon décrite plus bas. En général, plusieurs ou toutes les fonctions remplies par le CATA peuvent être entièrement automatisées, ne nécessitant que peu ou pas l'intervention d'un opérateur. Les données collectées conformément aux programmes exécutés par le CATA sont mémorisées et rendues disponibles à la demande. Le fournisseur de services à distance 14 peut aussi inclure divers systèmes de commerce électronique 66 conçus pour fournir des données, recevoir des commandes, traiter les commandes et réaliser des transactions comptables et financières à la demande de l'installation de diagnostic médical. Un module ou système éducatif 68 peut en outre être prévu pour proposer des programmes d'enseignement ou de formation, fournir des manuels ou de la documentation, etc. Bien que certains des systèmes du fournisseur de services à distance puissent être configurés en vue d'une liaison directe à une ou plusieurs installations de diagnostic médical ou à un ou plusieurs systèmes de diagnostic, dans l'exemple illustré ils sont configurés en vue d'une communication avec les systèmes de diagnostic via le réseau interne 60 et une interface de télécommunications 70. L'interface de télécommunications 70 va typiquement inclure un routeur de données, et d'autres matériels et logiciels destinés à adresser correctement des données reçues de l'installation de diagnostic médical vers un ou plusieurs des systèmes internes du fournisseur de services à distance, et à diriger des communications de ces systèmes vers l'installation de diagnostic médical. L'interface 70 transmet les données via un ou plusieurs modems 72, et via un émetteur 74 de télécommunications par satellite. Si cela est souhaité, d'autres liaisons réseau ou liaisons par satellite peuvent être prévues pour des systèmes spécifiques du fournisseur de services à distance, par exemple un émetteur 76 prévu pour le module éducatif 68. Chacun des dispositifs de télécommunications est couplé à une liaison de transmission de données, incluant une nouvelle liaison 78 de transmission de données pour le modem 72 et des liaisons par satellite 80 et 82 pour les émetteurs 74 et 76, respectivement. La liaison 78 de transmission de données protège de préférence l'intégrité du réseau et des données du fournisseur de services à distance 14 par une ou plusieurs barrières de sécurité 84 ou des dispositifs de protection similaires. La topologie du système représenté sur la figure 1 permet un échange interactif de données entre l'installation médicale et le fournisseur de services à distance. De façon déjà indiquée, les données peuvent être échangées au lancement de l'installation de diagnostic médical, ou de systèmes à l'intérieur de l'installation, par l'intermédiaire du SCTD 40. Selon une variante, des communications peuvent être lancées par le fournisseur de services à distance, par exemple pour répondre à des demandes de données ou de services, pour acquérir ou accéder à des données des systèmes de diagnostic par l'intermédiaire du SCTD, ou pour fournir divers services, incluant des matériels didactiques, des séances de formation, etc., via les liaisons au réseau externe. La figure 2 représente un exemple de configuration du SCTD 40, incluant ses périphériques associés et son cortège de logiciels. Dans la forme de réalisation représentée, le SCTD 40 inclut une unité centrale 86, qui peut se composer d'un microprocesseur disponible dans le commerce à l'intérieur d'un ordinateur polyvalent ou spécialisé. L'unité centrale est couplée à divers circuits matériels et fonctionnels pour réaliser les fonctions décrites dans la présente. Par exemple, tel que représenté sur la figure 2, l'unité centrale est couplée à une interface de télécommunications 88 pour envoyer et recevoir des données via le réseau externe tel que décrit plus haut, et pour échanger de façon similaire des données avec les systèmes de diagnostic via le réseau interne. L'interface de télécommunications 88 peut donc coordonner des communications par un ou plusieurs modems 42 couplés à la liaison 46 de transmission de données. Le décodeur 44 de télécommunications par satellite achemine de façon similaire des données par l'intermédiaire du SCTD via la liaison par satellite 48. Une interface réseau 90 supplémentaire, telle qu'une interface Ethernet, permet l'échange de données via le réseau interne 20 de l'installation. En plus de ces composants de communication, le SCTD 40 inclut un circuit de mémoire 92 et des composants de soutien logistique supplémentaires. Le circuit de mémoire 92 peut inclure n'importe quelle mémoire appropriée, telle que des lecteurs de disques, une mémoire vive (RAM), une mémoire morte (ROM), une mémoire vive dynamique, une mémoire optique, etc. Le circuit de mémoire 92 mémorise des programmes logiciels exécutés par le SCTD, ainsi que des données collectées par le SCTD pour les transmettre au fournisseur de services à distance, et des données reçues en provenance du fournisseur de services à distance pour les envoyer à des systèmes de diagnostic désignés ou destinataires de l'installation. Un système de sauvegarde 94 est de préférence prévu pour créer périodiquement des versions archivées de fichiers, programmes, données collectées, etc., choisis. Une ou plusieurs interfaces périphériques, repérées globalement 96, sont prévues pour recevoir des signaux d'entrée provenant d'une interface opérateur, et pour afficher des données et fournir en sortie des données à la demande. Dans la forme de réalisation représentée, ces périphériques incluent un écran 98 et une imprimante 100 d'ordinateur en tant que périphériques de sortie. Les périphériques d'entrée peuvent inclure un clavier 102 et une souris 104 conventionnels, et n'importe quel autre périphérique d'entrée approprié. Bien que certains logiciels d'application et programmes utilitaires puissent être mémorisés et exécutés sur divers clients de l'installation, en particulier à l'intérieur des systèmes d'imagerie, du SIR, du SIH et du SATI, le SCTD 40 exécute de préférence de façon indépendante diverses applications pour remplir les fonctions de transmission de données qui lui sont affectées. Ces applications, repérées globalement 106 sur la figure 2, sont de préférence mémorisées dans le circuit de mémoire 92, et exécutées par l'unité centrale 86. Selon une variante, certaines des applications peuvent être résidentes ailleurs, et être entièrement ou partiellement exécutées par un autre circuit de traitement de données. Les applications 106 vont généralement inclure divers programmes d'application disponibles dans le commerce, et peuvent en outre inclure des programmes personnalisés exécutés par l'unité centrale. Un cortège de logiciels 108 est donc disponible en vue d'une exécution par l'unité centrale, que ce soit de façon automatique, sur la base d'horaires réguliers, ou en réponse à des invites de l'opérateur ou des invites du fournisseur de services à distance. Des programmes d'application, globalement repérés 110 sur la figure 2, peuvent inclure des logiciels destinés à collecter des données des systèmes de diagnostic, à mémoriser ces données, à transmettre des données au fournisseur de services à distance, et à acheminer des données du fournisseur de services aux systèmes désignés. Dans la forme de réalisation représentée sur la figure 2, le cortège de logiciels 108 inclut un logiciel de base de données pour associer d'une manière relationnelle des données collectées depuis les systèmes de diagnostic. Ces données incluent de préférence l'identification des systèmes, leurs emplacements, des données d'utilisation, ainsi que divers paramètres utilisés pour déterminer l'état de fonctionnement du système et le besoin éventuel de dépannage. Comme l'apprécieront les personnes compétentes dans l'art, dans le cas de systèmes d'imagerie diagnostique, des données d'exploitation ou des paramètres très divers peuvent être mémorisés directement au niveau des systèmes de diagnostic individuels et peuvent fournir des indications extrêmement utiles des performances des systèmes, et d'éventuels besoins de futurs services. Le cortège de logiciels 108 inclut aussi de préférence un logiciel de serveur, tel que le logiciel de serveur Windows NT de Microsoft Corporation, Redmond, Washington, ainsi qu'un logiciel de serveur Web. Le logiciel de serveur permet au SCTD de fonctionner comme un serveur, à la fois pour les clients internes et pour des clients ou utilisateurs externes. Un logiciel de navigation est aussi de préférence inclus pour permettre à un opérateur, à l'aide des dispositifs d'interface opérateur du SCTD, de se connecter à des sites, tels que sur l'Internet pour demander des informations et des données, envoyer des demandes de services et de données, etc. Dans la forme de réalisation préférée, le logiciel de navigation peut aussi fonctionner sur le SCTD pour servir d'interface interactive directement au niveau d'un ou plusieurs des systèmes de diagnostic, en particulier les systèmes d'imagerie diagnostique. Un logiciel de routage fonctionne aussi sur le SCTD pour permettre une transmission correcte de paquets de données du fournisseur de services à distance à des systèmes de diagnostic désignés à l'intérieur de l'installation via le réseau interne. D'autres programmes ou logiciels d'application sont aussi de préférence inclus dans le SCTD, incluant des programmes de diagnostic et de service, et des programmes de service interactif. Ces programmes, qui peuvent inclure une plate- forme de service interactif, permettent de générer des demandes de services, de préférence à l'aide d'une interface de navigation Web en vue d'une transmission immédiate ou retardée au fournisseur de services à distance. Ces applications permettent aussi de préférence la réception de comptes rendus et de données de service renvoyés par le fournisseur de services à distance d'une manière interactive. Un logiciel de compte rendu sur le SCTD permet de générer des comptes rendus, en particulier des comptes rendus concernant des activités de télécommunications inscrites au journal tel que décrit plus bas. Des programmes de sécurité peuvent être exécutés en tant que partie du cortège de logiciels, de préférence pour vérifier l'intégrité des données envoyées et reçues par le SCTD, et pour restreindre à la fois l'accès au réseau interne par des utilisateurs extérieurs, incluant le fournisseur de services à distance, et l'accès aux sites Web ou fournisseurs de services à distance par les clients couplés au réseau interne. Des applications de gestion de parc informatique tournent aussi de préférence sur le SCTD pour permettre la réalisation de diverses fonctions commerciales, financières et administratives, de préférence en coordination avec des fonctions similaires réalisées par le SIR et le SIH. Dans la forme de réalisation représentée, par exemple, des programmes transactionnels et comptables peuvent être opérationnels, par exemple pour conserver une comptabilité des services à distance utilisés par l'installation, tous les frais ou honoraires associés à ces services, une comptabilité similaire pour toutes les transactions de commerce électronique effectuées, etc. Un programme de suivi des équipements peut fournir une analyse des emplacements et de la disponibilité de clients ou équipements spécifiques, en particulier les clients mobiles dont on peut suivre la trace via le réseau interne jusqu'à des emplacements spécifiques. Les composants du cortège de logiciels représenté sur la figure 2 et décrit plus haut peuvent inclure divers logiciels d'application disponibles dans le commerce, ou un logiciel créé spécifiquement pour l'installation ou pour une application. En général, des personnes compétentes dans l'art pourront facilement développer n'importe quel logiciel spécialisé, sans expérimentation excessive. Dans la forme de réalisation présentement préférée, des logiciels d'application disponibles dans le commerce inclus dans le système et exécutés par le SCTD incluent un logiciel de base de données disponible chez Oracle Corporation, Redwood City, Californie, un logiciel multimédia disponible chez Eloquent Systems, Inc., North Vancouver, Colombie-Britannique, un logiciel de serveur Web tel que le logiciel Netscape Entreprise disponible chez Netscape Communications, Mountain View, Californie, et un logiciel de navigation tel qu'un logiciel disponible chez Microsoft Corporation, Redmond, Washington, ou chez Netscape Communications. La figure 3 illustre un flux global de données à l'intérieur de la topologie d'ensemble du système représenté sur la figure 1. Tel que représenté sur la figure 3, un flux bidirectionnel de données est prévu entre le SCTD 40 et les divers clients 24, et d'autres systèmes connectés au réseau, tels que le SIR 34, le SIH 36 et le SATI 38. De façon déjà indiquée, les clients 24 incluent de préférence des systèmes d'imagerie diagnostique médicale qui sont reliés au fournisseur de services à distance par l'intermédiaire du SCTD pour des besoins interactifs de données et de services. Le SCTD 40 échange aussi des données avec le circuit de mémoire 92, qui sur le schéma de la figure 3 peut inclure des bases de données, à la fois locales au SCTD et situées en divers noeuds du réseau de l'installation. A l'intérieur du fournisseur de services à distance 14, des données peuvent être échangées entre l'interface 70 et les divers systèmes et sous-systèmes, tels que ceux décrits plus haut, comme le système de service 62, le CATA 64, les systèmes de commerce électronique 66, et les modules ou systèmes éducatifs 68. Chacun de ces systèmes peut inclure d'autres systèmes ou postes connectés en réseau, tels que des postes de travail 112 qui permettent à des ingénieurs d'application. par l'intermédiaire du système de service 62, d'accéder à des données des systèmes de diagnostic, de répondre à des besoins et demandes de services spécifiques, etc. Une ou plusieurs bases de données (BDD) 114 et 116 sont de préférence reliées aux systèmes du fournisseur de services à distance pour permettre une mémorisation relationnelle des paramètres et données d'exploitation, et leur extraction à la demande en vue d'une analyse, d'un compte rendu, d'une facturation, etc. On remarquera que les composants du fournisseur de services à distance, incluant les systèmes représentés sur la figure 3, peuvent échanger des données soit localement soit par des réseaux de configurations très diverses, incluant des configurations permettant à un ou plusieurs des systèmes et bases de données de se trouver en des lieux géographiquement éloignés les uns des autres. Les données échangées de façon interne à l'intérieur de l'installation de diagnostic médical et du fournisseur de services à distance sont ensuite échangées via les liaisons au réseau externe entre ces installations. Dans la forme de réalisation représentée, ces liaisons réseau incluent les liaisons 48 et 80 de télécommunications par satellite qui acheminent des données via un satellite 54 ou un circuit au sol, ainsi que les liaisons 46 et 78 et le réseau 50 qui constituent un grand réseau de télécommunications. La technique et les composants de transmission de données décrits plus haut permettent un accès à des données et un échange de données conformément à divers programmes. Des étapes logiques de certains de ces programmes sont représentées sur les figures 4-9. A propos de la figure 4, un premier programme permet de formuler des demandes de services et de données au niveau de l'installation de diagnostic en vue d'une transmission au fournisseur de services à distance. Le programme de demande de service, repéré globalement 200, commence à une étape 202 à laquelle un client de l'installation génère une demande de données. Dans le présent contexte, ces demandes de données peuvent inclure une large gamme de demandes de services, de données, de logiciels et autres. Spécifiquement, pour des systèmes d'imagerie diagnostique médicale, ces demandes peuvent inclure des descriptions de problèmes spécifiques apparaissant au niveau du système, des demandes de protocoles d'imagerie ou de logiciels, des demandes de renseignements opérationnels, etc. Des demandes similaires peuvent toutefois provenir de clients connectés en réseau, tels que les services de formation interne de l'installation, par exemple pour de la documentation de formation multimédia qui peut être transmise par le SCTD de façon décrite plus haut. On remarquera aussi que la demande de données peut être formulée au niveau de systèmes de diagnostic qui incluent un logiciel tournant localement pour la formulation des demandes, ou à l'aide d'applications tournant sur le SCTD et accessibles par l'intermédiaire du système de diagnostic. A une étape 204, ces demandes sont transmises au SCTD. A une étape 206, les demandes sont filtrées et toute vérification de licence peut être effectuée, par exemple pour déterminer si le système de diagnostic demandeur détient une licence en cours pour le type de demande formulée. De façon indiquée à une étape 208 sur la figure 4, des demandes de services ou de données peuvent être générées directement au niveau du SCTD 40. Ces demandes peuvent être formulées à l'aide des composants d'interface opérateur du SCTD, de préférence à l'aide d'une interface interactive, telle qu'un navigateur Web ou une autre interface utilisateur graphique. On remarquera que la capacité à générer des demandes de données et de services directement au niveau du SCTD offre des avantages significatifs par rapport aux techniques existantes d'assistance interactive aux systèmes de diagnostic. Par exemple, lorsque la base d'équipement installée dans une installation médicale n'est pas ou ne peut pas être équipée en vue d'une télécommunication directe via un réseau externe, l'équipement peut toutefois être couplé au SCTD via le réseau interne. En outre, de nombreux systèmes et appareils de diagnostic médical ne sont pas équipés d'une interface opérateur permettant une formulation de demandes de services et de données. La capacité à générer ces demandes directement au niveau du SCTD permet donc d'inclure ces systèmes dans une structure globale de fourniture de services. Après la génération de la demande à l'étape 208, les fonctions de filtrage et de vérification de licence de l'étape 206 peuvent être exécutées, de façon indiquée sur la figure 4. A une étape 210 sur la figure 4, les données incluses dans la demande subissent une analyse grammaticale afin d'identifier le système de diagnostic demandeur ou désigné, des problèmes ou questions à résoudre, l'opérateur ou le clinicien formulant la demande, etc. A une étape 212, ces informations sont inscrites au journal dans le circuit de mémoire du SCTD. A une étape 214, la demande est placée dans une file d'attente de transmission au fournisseur de services à distance. Lorsqu'une session de connexion est en cours, la demande peut être transmise dès la première fenêtre de communication disponible, de façon indiquée à une étape 216. Si nécessaire, la transmission à l'étape 216 peut requérir le lancement d'une session de connexion. Dans la forme de réalisation présentement préférée, ces connexions peuvent être lancées soit par le SCTD, soit par le fournisseur de services à distance. Si cela est souhaité, l'envoi et la réception de la demande sont confirmés au système de diagnostic désigné, de façon indiquée à une étape 218. En outre, si des données supplémentaires du client sont requises pour répondre à la demande, ces données peuvent être extraites de façon indiquée à une étape 220. Ces données peuvent inclure des configurations particulières ou des réglages de paramètres pouvant avoir été établis durant une séquence d'imagerie, par exemple des flux de données produits par un système d'imagerie ou un appareil de surveillance, des données d'historique de service, etc. Les demandes formulées conformément à la logique de la figure 4 sont transmises via le réseau externe au fournisseur de services à distance. La figure 5 représente un exemple d'étapes logiques de traitement de ces demandes. La procédure de traitement, repérée globalement 250, commence à la réception de la demande à une étape 252. A une étape 254, un message d'accusé de réception peut être formulé par le fournisseur de services à distance, par exemple par un programme de renvoi automatique de message, et renvoyé au SCTD pour informer l'installation que la demande a été reçue et est en cours de traitement. Cet accusé de réception peut inclure des détails supplémentaires concernant le traitement, tels que des numéros de référence, des numéros d'expédition, des délais de traitement, etc. A une étape 256, des données de la demande subissent une analyse grammaticale en vue d'une inscription au journal par le fournisseur de services à distance. L'analyse grammaticale effectuée à l'étape 256 peut inclure une analyse de données similaires à celles examinées à l'étape 210 de la figure 4, par exemple pour identifier le système demandeur ou désigné, identifier l'installation, les données d'abonnement au service, et des paramètres ou données d'exploitation requis pour examiner et répondre à la demande. A une étape 258, des registres de licence ou comptables mémorisés dans une base de données du fournisseur de services à distance sont extraits et mis à jour pour y indiquer la demande. Selon la structure comptable désirée, la demande peut être traitée sous un contrat ou un abonnement existant, sur la base d'une garantie, sur la base d'une facturation à l'utilisation, ou autrement. De façon déjà indiquée, selon le type de la demande transmise par l'installation de diagnostic médical, son traitement par le fournisseur de services à distance peut prendre divers modes. De façon indiquée â une étape 260 de la figure 5, la demande est adressée à l'intérieur du fournisseur de services en vue d'un traitement, tel qu'un traitement automatique, ou de l'intervention d'un technicien d'assistance à la clientèle. Dans chaque cas, il peut être nécessaire d'obtenir des données supplémentaires du système afin de répondre correctement à la demande de service. Dans le cas d'un appareil d'imagerie diagnostique médicale, ces informations supplémentaires peuvent inclure des fichiers de données d'image brute ou traitée, des paramètres de configuration et des réglages du système, etc. De façon indiquée à une étape 262, ces données peuvent être extraites via le réseau externe, le SCTD et le réseau interne de l'installation. Une fois qu'on dispose d'informations suffisantes pour répondre à la demande, les données, comptes rendus, analyses, etc., demandés peuvent être transmis du fournisseur de services à distance au système de diagnostic médical désigné via le SCTD, ou directement au SCTD s'il était à l'origine de la demande. Les transmissions effectuées à une étape 264 peuvent inclure une large gamme de données. Par exemple, les données peuvent inclure des paramètres de configuration, des suggestions d'étapes de dépannage, des messages électroniques, de la documentation électronique, des mises à niveau de logiciels, des protocoles, etc. Si nécessaire, un technicien d'assistance à la clientèle peut être envoyé, de façon indiquée à une étape 266 de la figure 5, pour un travail complémentaire. Le technicien d'assistance à la clientèle envoyé à l'étape 266 peut répondre à la demande soit en personne soit à distance, par exemple par téléphone ou autres connexions depuis le fournisseur de services â distance. De façon déjà indiquée, des réponses à des demandes provenant de l'installation de diagnostic médical peuvent être transmises par des moyens auxiliaires, tels qu'un grand réseau et une liaison par satellite. La logique de la figure 5 illustre une forme de réalisation destinée à effectuer ces transmissions en réponse à des demandes. Bien qu'on puisse employer divers moyens dans ce but, dans une forme de réalisation présentement préférée les moyens ont des débits de transmission ou bandes passantes nettement différents, ce qui permet d'effectuer certains types de transmissions par un premier type de connexion, tel que le grand réseau, et d'effectuer des transmissions plus exigeantes ou spécifiques par un moyen à plus grande largeur de bande. On peut adopter diverses approches pour décider lequel des moyens sera employé pour la transmission. Par exemple, le fournisseur de services à distance peut sélectionner manuellement ou automatiquement un moyen en fonction des spécifications ou préférences de l'installation de diagnostic médical. En outre, des transmissions de types spécifiques peuvent être effectuées sur un moyen ou l'autre, telles que des transmissions multimédia en continu qui peuvent requérir une grande largeur de bande, peuvent occuper une liaison pendant de longues périodes de temps, ou peuvent être particulièrement sensibles aux interruptions ou retards du réseau. Dans la forme de réalisation présentement préférée, la sélection du grand réseau ou de la liaison par satellite est effectuée d'après une catégorie de données ou de transmission. Par conséquent, à une étape 268 de la figure 5, la catégorie est examinée et l'un des moyens disponibles est sélectionné. A titre d'exemple, des présentations multimédia, des séances de formation et des catégories de données similaires sont transmises via la liaison par satellite, tandis que des transmissions de données plus conventionnelles sont effectuées via le grand réseau. Selon la catégorie de transmission, le moyen est ensuite sélectionné de façon indiquée à une étape 270 ou 276. La transmission est ensuite programmée de façon indiquée à une étape 272 ou 278. Dans le cas de séances de formation, par exemple, la transmission peut être programmée à une date et une heure ultérieures, le système de diagnostic désigné étant un lieu spécifique, une salle d'étude, ou un autre client de l'installation de diagnostic. Enfin, de façon indiquée à une étape 274 ou 280, la transmission programmée est effectuée via le moyen sélectionné. La figure 6 représente un exemple de logique de commande de réception et de traitement des transmissions renvoyées du fournisseur de services à distance à l'installation de diagnostic. Cette logique de commande, globalement repérée 300, commence à la réception de l'envoi de données à une étape 302. Cette réception s'effectue par l'intermédiaire du SCTD, comme dans une session de transmission de données en cours. A une étape 304, les données reçues subissent une analyse grammaticale pour identifier au moins le système de diagnostic désigné ou destinataire. A une étape 306, les données sont transférées du SCTD au système désigné via le réseau interne de l'installation. On remarquera que l'étape 306 peut inclure une mémorisation d'une partie ou de l'ensemble des données, ou d'informations déduites ou provenant de l'analyse des données, dans le circuit de mémoire du SCTD, ou dans une autre base de données de l'installation. A une étape 308, le SCTD inscrit au journal la réception et l'échange de télécommunications. Si nécessaire, des procédures auxiliaires de réception et de traitement des données peuvent être mises en oeuvre de façon indiquée sur la figure 7. Les étapes auxiliaires de réception repérées globalement 350 peuvent être souhaitables, par exemple, dans la réception de données numériques via des liaisons par satellite, les données étant acheminées par l'intermédiaire du SCTD pour être distribuées. En particulier, ces systèmes de télécommunications par satellite ou autres moyens auxiliaires peuvent ne pas utiliser une communication bidirectionnelle. En conséquence, certaines informations d'adressage des données peuvent être transmises en parallèle via l'autre moyen, en particulier par un grand réseau. A une étape 352, un programme de mise en liaison est donc exécuté entre le SCTD et le fournisseur de services à distance pour s'assurer d'une connectabilité appropriée et de la capacité à échanger les informations nécessaires. A une étape 354, une procédure d'authentification peut être exécutée pour s'assurer que la session de transmission via le moyen parallèle est conforme à la demande et à l'horaire de transmission. A une étape 356, l'adresse du destinataire est identifiée et confirmée, par exemple pour s'assurer que la voie de transmission est correctement accordée en fréquence ou choisie, et que le client ou système de diagnostic est identifié à l'intérieur de l'installation. A une étape 358, la transmission est reçue et démodulée, filtrée, ou traitée autrement. De façon indiquée à une étape 360, les données reçues via le moyen parallèle peuvent requérir un traitement supplémentaire, tel qu'un formatage des données en paquets pour leur transmission sur le réseau interne. Après ce traitement, les données sont envoyées au système désigné. La séquence de communication et la transmission sont inscrites au journal de façon indiquée â une étape 362. En plus de l'échange interactif de services et d'autres données, la présente technique permet l'acquisition de données d'exploitation et de paramètres des systèmes de diagnostic médical qui sont clients du réseau interne de l'installation selon une procédure modernisée. La figure 8 représente un exemple d'étapes de cette procédure, par une logique de commande repérée globalement 400. La procédure permet globalement une acquisition ou un recueil par le SCTD de données des systèmes de diagnostic médical connectés au réseau, et leur transmission du SCTD au fournisseur de services à distance. Dans des approches précédemment connues de la fourniture de services à des systèmes de diagnostic médical, ces données étaient typiquement acquises par une connexion directe à un système de diagnostic désiré, ce qui nécessitait d'effectuer indépendamment un grand nombre de connexions et introduisait des exigences substantielles sur l'infrastructure, à la fois à l'intérieur de l'installation et au niveau du fournisseur de services à distance. En outre, quand les systèmes de diagnostic n'étaient pas équipés en vue d'une connexion directe au fournisseur de services à distance, on ne pouvait obtenir que peu ou pas d'information, en particulier directement concernant le système. Dans la présente approche, les informations peuvent être obtenues par plusieurs opérations différentes, lancées automatiquement ou manuellement. Dans l'exemple de logique de la figure 8, l'opération d'acquisition de données peut commencer au lancement d'un programme d'interrogation automatique à une étape 402. Ce programme serait exécuté par le SCTD qui contacte chaque système connecté en réseau, ou des systèmes désignés dont on désire obtenir des données, selon un horaire préétabli. A titre d'exemple, l'horaire peut inclure une acquisition périodique de données toutes les 24 heures, ou une acquisition moins fréquente. En fonction du programme et de l'horaire, les clients sont contactés à une étape 404 de la figure 8. A une étape 406, un accès aux données est effectué, par exemple par extraction du circuit de mémoire des systèmes de diagnostic clients. A une étape 408, les données peuvent être filtrées, par exemple pour déterminer si les informations acquises sont complètes ou incomplètes, pour filtrer des données non souhaitées, telles que des données spécifiques des patients, etc. A une étape 410, les données sont enregistrées, par exemple dans le circuit de mémoire du SCTD. Comme variante de l'opération d'interrogation décrite plus haut, certaines données peuvent être collectées lorsqu'un événement spécifique se produit dans le système de diagnostic ou à l'intérieur de l'installation. Par exemple, quand certains des systèmes de l'installation sont mobiles, une connexion du système mobile au réseau interne peut provoquer une exécution par le SCTD du programme d'acquisition de données pour le système nouvellement connecté. De façon indiquée à une étape 412 de la figure 8, le système ou équipement spécifique peut donc changer d'état, par exemple établir ou renouveler une connexion au réseau interne. A une étape 414, un accès au système est ensuite effectué et les informations désirées sont transférées du système au SCTD. A titre d'exemple, pour permettre un suivi des équipements, une gestion de parc informatique, une analyse de productivité et autres fonctions, l'emplacement des équipements mobiles peut être identifié et enregistré en vue d'une utilisation ultérieure, ou pour permettre au personnel de l'installation de localiser les équipements. Les séquences d'acquisition de données peuvent aussi être lancées par une demande manuelle, de façon indiquée à une étape 416 sur la figure 8. La demande manuelle peut être saisie à l'aide des composants d'interface opérateur du SCTD, par exemple pour accéder à des caractéristiques ou paramètres de performances, d'utilisation et autres des systèmes connectés au réseau et les afficher. En réponse à la demande manuelle, un accès au système désigné est effectué, de façon indiquée à une étape 418, et les données désirées sont localisées et extraites de la mémoire du dispositif, de façon indiquée à une étape 420. Pour faciliter la transmission des données acquises au fournisseur de services à distance, les données acquises sont de préférence mémorisées localement au niveau de l'installation de diagnostic, et transmises au fournisseur de services à distance en une ou plusieurs sessions de transmission de données. Ces sessions peuvent être programmées à des horaires pratiques, comme durant des heures creuses, la nuit, le week-end, etc. La figure 9 illustre des étapes d'un exemple de logique de commande, repérée globalement 450, de transmission des données une fois qu'elles ont été acquises au niveau de l'installation. A propos de la figure 9, le transfert de données est d'abord programmé de façon indiquée à une étape 452. De façon déjà indiquée, cette programmation peut correspondre à des horaires pratiques, à la fois pour l'installation de diagnostic et pour le fournisseur de services à distance. On remarquera toutefois que ces transferts de données peuvent être lancés par intervention d'un opérateur, si cela est souhaité. De façon indiquée à une étape 454, une connexion est alors établie entre l'installation de diagnostic et le fournisseur de services à distance. La connexion peut être lancée par l'un ou l'autre de l'installation et du fournisseur de services à distance, le fournisseur de services à distance étant le lanceur préféré dans la présente forme de réalisation. Aussi, à l'étape 454, le fournisseur de services à distance invite au transfert de données, par exemple par un programme de télécommunications mémorisé à la fois au niveau du SCTD et du fournisseur de services à distance. En réponse à l'invite, les données sont extraites de la mémoire de l'installation médicale ou du répertoire de données et transférées au fournisseur de services à distance, de façon indiquée à une étape 456. Durant ou après le transfert, tous les traitements souhaités d'analyse grammaticale, de filtrage et autre sont exécutés de façon indiquée à une étape 458. En particulier, les données transférées subissent de préférence une analyse grammaticale pour identifier les systèmes de diagnostic individuels desquels proviennent les données, et pour séparer les unes des autres les données d'exploitation et paramètres des systèmes individuels. Les données sont ensuite mémorisées, de préférence dans des bases de données relationnelles, en vue d'une extraction et d'une analyse ultérieures. Enfin, à une étape 460, la session de transfert de données est inscrite au journal, de préférence à la fois au niveau de l'installation de diagnostic et du fournisseur de services à distance. Bien que l'invention soit susceptible d'accepter diverses modifications et variantes, des formes de réalisation spécifiques ont été représentées à titre d'exemple sur les dessins et décrites en détail dans la présente. On comprendra toutefois que l'invention n'est pas limitée aux formes particulières décrites. L'invention englobe plutôt toutes les modifications, équivalents et variantes inclus dans l'esprit et la portée de l'invention telle qu'elle est définie dans les revendications annexées qui suivent. REVENDICATIONS 1. Procédé de fourniture de données de service à des systèmes de diagnostic médical (24-38), caractérisé par le fait qu'il comprend les étapes de: (a) génération d'une demande (202) de service des systèmes de diagnostic pour un système de diagnostic désigné couplé à un réseau interne (20) d'une installation de diagnostic médical (12); (b) transmission de la demande à un fournisseur de services à distance (204) via un réseau externe (50) par un système de commande (40) de transmission de données couplé à une pluralité de systèmes de diagnostic par le réseau interne; (c) réception et traitement de la demande (252) au niveau du fournisseur (14) de services à distance; (d) transmission d'une réponse (254) du fournisseur de services à distance en réponse à la demande. 2. Procédé selon la revendication 1, dans lequel la réponse est transmise au système de commande (40) de transmission de données. 3. Procédé selon la revendication 1, comprenant en outre l'étape de transmission de la réponse (306, 360) au système de diagnostic désigné via le réseau interne (20). 4. Procédé selon la revendication 1, dans lequel la demande de service des systèmes de diagnostic est générée au niveau du système de diagnostic (24-38) désigné. 5. Procédé selon la revendication 4, dans lequel la demande de service des systèmes de diagnostic est générée par un programme d'interface (106, 108) prévu dans le système de commande (40) de transmission de données. 6. Procédé selon la revendication 5, dans lequel le programme i d'interface (106, 108) inclut une application de navigateur Web. 7. Procédé selon la revendication 1, dans lequel la demande de service est générée au niveau du système de commande (40) de transmission de données. 8. Procédé selon la revendication 1, dans lequel la demande de service inclut au moins des données identifiant le système de diagnostic (40) désigné. 9. Procédé selon la revendication 8, comprenant en outre l'étape d'accès à des données d'exploitation (406, 420) du système de diagnostic (24-38) désigné en réponse à la demande de service. 10. Procédé selon la revendication 1, dans lequel la demande de service est transmise au fournisseur de services à distance via un premier moyen de transmission (46, 50, 78) de données et la réponse est transmise à l'installation de diagnostic médical via un second moyen de transmission (48, 54, 80) de données différent du premier moyen. 11. Procédé selon la revendication 10, dans lequel le premier moyen inclut une liaison (50) de grand réseau de télécommunications. 12. Procédé selon la revendication 10, dans lequel le second moyen inclut une liaison par satellite (54). 13. Procédé selon la revendication 10, dans lequel la réponse est transmise directement à un système de diagnostic (24-38). 14. Procédé selon la revendication 1, comprenant les étapes supplémentaires de placement de la demande de service dans une file d'attente (214), et de transmission de la demande de service selon un horaire établi (216). 15. Procédé selon la revendication 1, dans lequel la réponse inclut des données de service destinées à résoudre un problème de fonctionnement du système de diagnostic désigné, et dans lequel le procédé inclut une mémorisation des données de service en vue d'un téléchargement vers le système de diagnostic désigné. 16. Système fournissant un service à distance à une pluralité de systèmes de diagnostic médical connectés en réseau, le système comprenant une pluralité de systèmes de diagnostic médical (24-38) cou plés à un réseau interne (20) d'une installation de diagnostic médical (12), incluant un système de diagnostic désigné; un circuit (86) de génération de demande de service pour formuler une demande de service concernant un fonctionnement du système de diagnostic désigné; et un système de commande (40) de transmission de données couplé au réseau interne et à un réseau externe (46) pour transmettre la demande de service à un fournisseur de services à distance et pour recevoir du fournisseur (14) de services à distance une réponse à la demande. 17. Système selon la revendication 16, incluant un fournisseur (14) de services à distance, le fournisseur de services à distance recevant la demande de service, générant la réponse et transmettant la réponse au système de commande (40) de transmission de données. 18. Système selon la revendication 17, dans lequel le système de commande inclut une interface réseau externe (42, 44) pour recevoir la réponse via au moins deux moyens de transmission de données différents. 19. Système selon la revendication 16, dans lequel la demande de service est générée au niveau du système de diagnostic (24-38) désigné. 20. Système selon la revendication 16, dans lequel les systèmes de diagnostic (24, 38) incluent au moins deux systèmes imageurs (26, 28, 30, 32) de modalités différentes, et dans lequel le système de diagnostic désigné est sélectionné parmi les au moins deux systèmes imageurs. 21. Système selon la revendication 16, dans lequel les données d'exploitation utiles pour répondre à la demande de service sont mémorisées au niveau du système de diagnostic (24-38) désigné. 22. Système selon la revendication 21, dans lequel le système de commande (40) de transmission de données accède (262, 206, 418) aux données d'exploitation du système de diagnostic désigné via le réseau interne. 23. Système selon la revendication 16, dans lequel le système de commande de transmission de données inclut une interface opéra teur (98, 100, 102, 104), et dans lequel la demande de service est générée à l'aide de l'interface opérateur.