FR2803066A1 - Procede et dispositif pour la gestion des communications entre les structures medicales - Google Patents

Abstract

Technique servant à gérer l'échange de données entre des équipements et des systèmes (24-38) servant à exécuter des diagnostics médicaux et des prestataires de services ou de données distants (14). Système (40) de gestion de communications de données comportant un circuit (86) de traitement de données et des interfaces (42, 44, 90) pour un réseau interne (20, 22) d'un établissement médical (12) et pour un réseau externe (50). Des données sont échangées dans l'établissement entre le système de gestion et les équipements de diagnostics en réseau par l'intermédiaire du réseau interne (20, 22). Des données sont émises et reçues par le système de gestion (40) en communication avec le prestataire de services distant (14). Le système de commande peut assumer les fonctions d'un serveur et d'un routeur et peut stocker des données provenant des systèmes de diagnostics et du prestataire de services.

Description

Procédé et dispositif pour la gestion des communications entre les structures médicales La présente invention est relative d'une manière générale au domaine des établissements et systèmes conçus pour établir des diagnostics médicaux, ainsi qu'à la gestion des échanges de données entre de tels établissements et systèmes, et des prestataires de services extérieurs.

Les établissements et structures médicaux offrent une gamme toujours plus large de services et de procédures permettant de répondre aux besoins de leurs patients et de leur personnel. Les hôpitaux, les cliniques et autres établissements médicaux peuvent être constitués par de simples cliniques<B>à</B> un seul bureau, ou par de grands établissements intégrés comprenant un large éventail de services et de structures coopérant les uns avec les autres. En outre, même les cliniques les plus petites peuvent être partiellement ou entièrement intégrées un même lieu dans un établissement plus grand, ou être isolées géographiquement les unes des autres. Dans tous ces cas, les technologies de l'information deviennent un élément clé dans les échanges de données et de services nécessaires pour mener<B>à</B> bien la mission des structures.

Par exemple, dans une clinique ou un hôpital typique, un service de radiologie peut disposer de divers types de systèmes d'imagerie, notamment des systèmes d'imagerie par résonance magnétique (IRM), des systèmes de tomographie assistée par ordinateur<B>(CT),</B> des systèmes<B>à</B> ultrasons, des systèmes de radiographie, et autres. Certains de ces systèmes peuvent être<B>f</B>ixes, tandis- que d'autres peuvent etre déplacés d'un service<B>à</B> l'autre. Un système d'information pour service de radiologie (RIS) peut être interconnecté avec ces divers systèmes d'imagerie afin de coordonner leur fonctionnement, ainsi que pour faciliter l'examen de leurs images -par radiologues et des médecins établissant un diagnostic. Dans certains établissements ces diverses structures peuvent être reliées entre elles en réseau, d'une manière typique dans une architecture de réseau local (LAN).

Outre les équipements de radiologie, divers autres équipements d'une structure médicale peuvent être contrôlés ou mis en réseau au niveau services ou d'établissements. Des écrans de contrôle de patients, par exemple, peuvent présenter dans une certaine mesure une possibilité de mise en réseau, ce qui permet d'effectuer un suivi des patients et de contrôler<B>à</B> distance leur état physiologique. Les dossiers des patients, les documents comptables et autres peuvent de même être associés dans les différents systèmes individuels, certaines des informations faisant l'objet de doubles renvois dans un système d'information hospitalier (HIS).

Bien que certains des équipements présents dans un hôpital ou autre établissement médical puissent être conçus pour fonctionner d'une manière totalement indépendante d'autres équipements ou prestataires de services, de nombreux systèmes ou sous-systèmes individuels sont actuellement conçus pour communiquer d'une façon interactive des informations avec des éléments extérieurs.

exemple, dans le domaine de l'imagerie diagnostique, des systèmes individuels sont désormais équipés d'un modem par lequel ils peuvent émettre et recevoir des données d'images, des informations de services, des rapports, etc. Dans certains cas, personnel peut se connecter sur un réseau, par exemple Intemet, ou un réseau prive virtuel, pour émettre et recevoir des données directement vers et depuis le système d'imagerie. D'autres équipements d'un établissement peuvent de même être équipés la communication de données, soit de manière individuelle soit l'intermédiaire d'un poste de travail pour tout un service ou d'une liaison similaire, Bien que les réseaux individuels existant dans une structure médicale puissent fonctionner convenablement en ce qui concerne la plupart des buts recherchés, ils posent certains problèmes concernant la coordination et l'acheminement des données, et ils risquent de fatiguer l'infrastructure de l'établissement. En fonction du type de connexions réalisées, par exemple, des systèmes d'imagerie servant<B>à</B> établir des diagnostics médicaux peuvent nécessiter chacun une ligne de communication séparée pour assurer la' connectivité si cela est nécessaire. Dans une installation typique, ces lignes de communication sont constituées par des câbles téléphoniques classiques qu'il faut installer et entretenir pour les différents systèmes, même si les systèmes ne sont pas connectés<B>à</B> un réseau ou ne sont pas en train de transmettre des données.

Lorsque des données sont transmises vers ou depuis des équipements individuels ou des LAN individuels d'un établissement, une comptabilité séparée peut être requise, et des composants de liaison doivent acheminer séparément les données vers et depuis chaque système ou équipement connecté<B>'</B> un LAN. Là encore, cette procédure peut nécessiter des procédures de connexion séparées par l'intermédiaire de lignes spécialisées, ce qui non seulement accroît le coût global du système et de l'infrastructure, mais encore accroît fortement le temps pris et les opérations nécessaires au processus d'échange de données.

On a donc besoin d'une technique perfectionnée pour échanger des données entre des structures établissant des diagnostics médicaux et des ressources extérieures, telles que des prestataires de services, des sociétés assurant l'entretien des équipements, etc.

L'invention propose une technique d'échange de données conçue pour répondre<B>à</B> ces besoins. La technique peut être employée dans systèmes d'information nouvellement conçus ou aussi bien être adaptée dans des établissements pour améliorer leur infrastructure existante.

La technique présente un contrôleur de communications peut être connecté toutes sortes de réseaux et de systèmes internes existant dans un établissement afin d'acheminer des données d'arrivée et de départ entre éléments et des ressources extérieures. Le contrôleur peut être couplé<B>à</B> divers types de supports pour envoyer et recevoir des données, dont des réseaux ouverts ou -homogènes, des réseaux privés virtuels, etc. Les supports physiques permettant la transmission des données peuvent comporter des lignes téléphoniques, câbles, des liaisons par satellite et autres. Les protocoles exécutés par le contrôleur peuvent permettre l'échange simultané d'un grand volume de données. Le système peut être intégré avec divers systèmes de suivi et de gestion de déroulement travail de l'établissement afin de faciliter les échanges de données. Ainsi, les fonctions de comptabilité, de suivi, de surveillance, de planification et autres peuvent être intégrées par l'interrnédiaire du système de gestion.

La Figure<B>1</B> est une vue générale schématique d'un système de transmission de données permettant d'échanger des données entre une Mrie de systèmes établissant des diagnostics médicaux un prestataire de services ou un fournisseur de données distant; la Figure 2 est une vue schématique d'un exemple de système de gestion de transmissions de données selon certains aspects de la présente technique, utilisable dans le système représenté sur la Figure<B>,</B> la Figure<B>3</B> est un organigramme illustrant les chemins empruntés par les données lors des communications par l'interrnédiaire des divers éléments constituant le système de la Figure<B>1;</B> la Figure 4 est un organigramme illustrant un exemple de logique de commande lors de l'émission d'une demande de service ou autre transfert de données entre un système établissant des diagnostics médicaux et un prestataire de services distant; la Figure<B>5</B> est un organigramme illustrant un exemple de logique de commande utilisée pour gérer des demandes de services ou de données émises par un prestataire de services distant, et pour renvoyer des données en réponse<B>à</B> cette demande; la Figure<B>6</B> est un organigramme illustrant un exemple de logique de commande pour recevoir une transmission d'un prestataire de services distant dans la structure établissant des diagnostics médicaux; la Figure<B>7</B> est un organigramme illustrant un exemple de logique de commande pour recevoir des données par l'intermédiaire d'un autre moyen de transmission de données; la Figure<B>8</B> est un organigramme illustrant un exemple de logique de commande dans des systèmes d'interrogation de balayage d'une structure établissant des diagnostics médicaux ou de données a réémettre vers un prestataire de services distant-, et la Figure<B>9</B> est un organigramme illustrant un exemple de logique de commande pour accéder aux données recueillies lors de la procédure de la Figure<B>8,</B> en vue de leur gestion et de leur stockage par un prestataire de services distant.

Considérant maintenant les dessins, et tout d'abord en référence<B>à</B> la Figure<B>1,</B> il<B>y</B> est représenté un système de transmission de données, désigné globalement par le repère<B>10,</B> servant<B>à</B> transmettre<B>à</B> un prestataire de services ou un fournisseur de données distant des données ou des paramètres d'exploitation fournis par une série de systèmes établissant des diagnostics médicaux. Le systèmè permet également des échanges interactifs de données, de demandes de services, de logiciels, et autres entre les systèmes et le prestataire de services distant, comme décrit plus en détail ci-après. Comme représenté sur la Figure<B>1,</B> le système<B>10</B> comprend globalement une structure 12 établissant des diagnostics médicaux, en liaison avec un prestataire de services ou un fournisseur de données distant 14. La structure 12 peut comporter un seul lieu ou site<B>16,</B> ou des sites supplémentaires<B>1</B> qui peuvent être géographiquement situés au même endroit que le site<B>16</B> ou<B>à</B> distance de celui-ci. Dans de tels cas, les sites supplémentaires peuvent globalement être reliés au site<B>16</B> l'intermédiaire d'un réseau de structures.

Dans la structure 12, un réseau interne 20 présente un mécanisme pour effectuer des transmissions de données entre une série de systèmes établissant diagnostics médicaux qui, si on le souhaite, peuvent être disposés dans des groupes ou des services 22, par exemple des étages, des services, des zones spécialisées pour certains traitements ou diagnostics, etc. Une série de systèmes établissant des diagnostics médicaux, globalement appelés ici clients 24, sont couplés au réseau 20 soit par des connexions permanentes<B>à</B> un réseau, soit par des connexions temporaires<B>à</B> un réseau. Ainsi, alors que certains ou plupart des clients 24 peuvent être fixes, certains des clients peuvent être mobiles qui permet au client ou<B>à</B> l'équipement d'être utilisé<B>à</B> un endroit voulu, et d'être couplé au réseau interne une fois qu'il est placé<B>à</B> l'emplacement voulu.

Au terme de la présente description, l'expression<B> </B> système établissant des diagnostics médicaux<B> </B> doit être entendue comme couvrant toutes sortes d'équipements, de systèmes et de sous-systèmes. Par exemple, les systèmes établissant des diagnostics médicaux peuvent comprendre des systemes d'imagerie diagnostique conçus pour produire des images utiles de l'anatomie de patients en fonction de conditions physiques ou de modalités particulières. D'autres systèmes établissant des diagnostics médicaux peuvent comporter des écrans de contrôle de patients, des détecteurs, des transducteurs et autres dispositifs générant ou réinjectant des signaux. De plus, les systèmes établissant des diagnostics médicaux, communicant selon la présente technique, peuvent comprendre systèmes de gestion d'informations, des postes de travail, des postes d'examen d'images et de données, etc.

Par exemple, sur la Figure<B>1,</B> une série de systèmes d'imagerie établissant des diagnostics médicaux sont illustrés en un groupe. Dans la pratique, ce groupe peut être associé d'une manière physique ou logique<B>à</B> service ou une clinique radiologie. Dans la forme de réalisation illustrée sur la Figure<B>1,</B> ces systèmes comprennent un système d'imagerie par résonance magnétique (IRM) <B>26,</B> un système de tomographie assistée par ordinateur<B>(CT) 28,</B> un système de radiographie<B>30</B> et un système<B>à</B> ultrasons<B>32.</B> Tous ces systèmes comportent de préférence systèmes diagnostiques<B>de</B> clients pour la présente technique. Comme le comprendront les spécialistes de la technique, chacun de systèmes d'imagerie est configuré pour produire des données utiles sous forme d'images reposant sur des conditions physiques particulières ou leurs modalités respectives. Comme indiqué plus haut, certains de ces systèmes peuvent être mobiles, comme les systèmes<B>à</B> ultrasons peuvent être transférés dans une chambre ou zone d'examens voulue et connectés dans cette zone au réseau 20, ou encore au moment de leur retour dans une station de base.

Selon un autre exemple, dans la forme de réalisation illustrée sur la Figure<B>1,</B> système diagnostique de clients comprend également série de postes de gestion de données, Comme indiqué par le repère 34, les clients peuvent donc comprendre un système d'information (RIS) de service de radiologie conçu pour gérer la production et l'écoulement de données d'images conjointement avec des systèmes d'imagerie<B>26, 28, 30</B> et<B>32.</B> Un système d'information hospitalier (HIS) <B>36</B> fournit aide supplémentaire pour les données, le patient, considérations financières et autres servant au fonctionnement de la structure 12, selon des techniques globalement connues. Enfin, un système (PACS) <B>38</B> d'archivage et de transmission d'images permet des opérations de stockage, de traitement, d'accès et d'archi-v de fichiers de données produits par les systèmes d'imagerie diagnostique.

Chacun des systèmes diagnostiques de clients est couplé au réseau 20 pour échanger des données de la manière décrite ci-après avec un prestataire de services ou de données distant. Dans les techniques d'échange de données connues jusqu'à présent, certains des systèmes de clients peuvent être équipés pour un échange indépendant de données d'exploitation ou de paramètres nécessités par des besoins tels que réparations, l'entretien, les analyses, la comptabilité et autres. Selon ces techniques, une liaison indépendante pourrait être établie entre les équipements et un prestataire de services distant, par exemple par l'intermédiaire d'une connexion indépendante par modem comme illustré pour le système à-ultrasons <B>32</B> de la Figure <B>1.</B> Selon présente technique, bien que certains des systèmes puissent continuer<B>à</B> permettre cette liaison directe, les systèmes diagnostiques de clients n'ont pas besoin de permettre cette connectivité séparée. En revanche, les données peuknt être échangées entre les systèmes et un prestataire de services ou de données distant par l'intermédiaire du réseau 20.

Dans la forme de réalisation actuellement préférée, le réseau 20 est constitué par un réseau interne<B>à</B> grande vitesse tel qu'un réseau Ethemet. Dans les formes de réalisation actuelle, le réseau peut être un réseau d'une capacité de<B>10</B> Mb ou<B>100</B> Mb échangeant des données selon un protocole d'échange de données classique tel que TCP/IP. Evidemment, on peut utiliser une autre architecture interne réseau et d'autres normes.

Le système de transmission comprend en outre un système 40 de gestion de transmission de données (DCCS) couplé au réseau 20 pour recevoir des données ou accéder<B>à</B> des données provenant du client, et pour échanger des données avec un ou plusieurs prestataires de services ou fournisseurs de données distants. Le DCCS 40 est donc couplé<B>à</B> des circuits de transmission externes, par exemple un modem 42 et un décodeur 44 de données transmises par satellite. Le modem 42, et d'éventuels modems supplémentaires souhaités, peut être de n'importe quel type approprié, par exemple un modem de<B>56</B> kb/s selon la technologie actuelle d'un modem câble ou de n'importe quelle interface de communication appropriée avec un réseau externe. De même, le décodeur 44 peut être constitué par n'importe quelle interface appropriée<B>à</B> fonctionnement radioélectrique ou par satellite, par exemple un décodeur<B>à</B> infrarouge IRD du type proposé par Scientific Atlanta of the United States. Comme décrit plus en détail ci-après, l'utilisation de moyens en parallèle pour émettre et recevoir des données permet au DCCS 40 d'utiliser de la meilleure manière possible la largeur de bande disponible lors des échanges de données entre la structure et le prestataire de services distant. Par exemple, le modem 42 peut assurer largeur de bande de<B>56</B> kb/s tandis que le décodeur permet une largeur de bande considérablement plus grande, telle que<B>500</B> kb/s.

Les transmissions de données vers et depuis la structure 12 sont assurées par une liaison extérieure 46 en réseau acheminée jusqu'au modem 42 et par une liaison 48 par satellite acheminée jusqu'au décodeur 44. liaison extérieure 46 en réseau est couplée, par exemple par des câbles téléphoniques classiques, des fibres optiques ou autres,<B>à</B> un réseau<B>50</B> tel qu'un réseau étendu. Cependant, le réseau<B>50</B> peut être n'importe quel type de réseau adéquat, dont des réseaux privés virtuels ou l'Internet. L'isolation et la protection de l'intégrité du système de transmission de la structure 12 peuvent être assurées par un ou plusieurs pare-feu, La liaison 48 par satellite qui fait globalement partie du réseau externe pour la transmission de données vers depuis la structure, sert<B>à</B> recevoir des dormées relayées par l'intermédiaire d'un satellite 54, ou par l'intermédiaire de répéteurs au soi, d'émetteurs et autres.

Les données de la structure 12 sont échangées avec un prestataire 14 de services par l'intermédiaire des liaisons externes en réseau décrites plus haut. D'une manière générale, le prestataire de services distant 14 peut comporter un site principal<B>56</B> et des sites supplémentaires<B>58</B> reliés entre eux par l'intermédiaire de réseaux ouverts ou homogènes. Par exemple, le prestataire de services distant peut comporter une ou plusieurs structures servant<B>à</B> recevoir des demandes de données et de services émanant de la structure de diagnostic médical, sur la base d'un abonnement ou d'un contrat. Les services, les données, la formation, l'assistance technique et autres informations peuvent alors être fournis aux structures abonnées par l'interrnédiaire des liaisons en réseau et suivant les techniques décrites ci-après. Dans l'exemple illustré, le prestataire de services distant 14 comporte son propre réseau interne, par exemple un réseau local de type Ethernet.

Une série de clients ou de systèmes sont interconnectés par l'intermédiaire du réseau pour échanger des données<B>à</B> la fois de manière interne et avec structure de diagnostic médical. Par exemple, un système de services désigné globalement par le repère<B>62,</B> est prévu pour recevoir et traiter données de services telles que des demandes de services, des demandes de protocoles, des questions et autres. Le système de services<B>62</B> peut également être équipé pour planifier des appels de services réguliers ou spéciaux, fournir des rapports et des analyses établis<B>à</B> partir de données d'exploitation ou de parametres, etc. Dans l'exemple illustré, le prestataire de services distant 14 comporte également un centre d'assistance automatisé, désigné globalement par le repère 64. Le centre peut exécuter -diverses fonctions automatisées dont la saisie ou la collecte de paramètres et de données d'exploitation provenant de la structure, de la manière décrite plus loin. D'une manière générale, un grand nombre ou la totalité des fonctions exécutées par FASC peuvent être entièrement automatisées, ce qui ne nécessite pratiquement pas d'intervention de la part d'un opérateur. Les données collectées conformément aux programmes exécutés par l'ASC sont stockées et accessibles<B>à</B> demande. Le prestataire de services distant 14 peut également comporter divers systèmes de commerce électronique<B>66</B> conçus pour fournir des données recevoir des commandes, traiter des commandes et effectuer des transactions comptables et financières<B>à</B> la demande de la structure de diagnostic médical. unité ou un système d'apprentissage<B>68</B> peut en outre être prévu pour proposer des programmes d'apprentissage ou de formation, réaliser des notices ou une documentation, etc.

Bien que certains des systèmes du prestataire de services distant puissent être configurés pour une liaison directe avec une ou plusieurs structures établissant des diagnostics médicaux ou un ou plusieurs systèmes diagnostiques, dans l'exemple illustré ils sont configurés pour une communication avec les systèmes diagnostiques le réseau interne<B>60</B> et par l'intermédiaire d'une interface de transmission D'une manière typique, l'interface de transmission<B>70</B> comporte un routeur de données, et d'autres matériels et logiciels permettant un adressage approprié des données reçues de la structure de diagnostic médical vers un ou plusieurs des systèmes internes du prestataire de services distant, et pour diriger les transmissions depuis ces systèmes vers la structure de diagnostic médical. L'interface <B>70</B> transmet les données par l'intermédiaire d'un ou plusieurs modems<B>72</B> et par l'intermédiaire d'un émetteur 74 de satellite. Si on le souhaite d'autres liaisons en réseau ou par satellite peuvent être établies avec des systèmes spécifiques du prestataire de services distant, par exemple un émetteur<B>76</B> prévu pour l'unité d'apprentissage<B>68.</B> Chacun des dispositifs de transmission est couplé<B>à</B> une liaison de données, comportant une liaison de données nouvelle<B>78</B> pour le modem<B>72,</B> et des liaisons<B>80</B> et<B>82</B> par satellite pour les émetteurs respectifs 74 et<B>76.</B> De préférence, la liaison<B>78</B> de données protège l'intégrité du réseau et les données du prestataire de services distant 14<B>à</B> l'aide d'un ou plusieurs pare-feu 84 ou autres dispositifs de protection similaires.

L'architecture du système, illustrée sur la Figure<B>1,</B> permet un échange interactif de données entre la structure médicale et le prestataire de services distant. Comme examiné plus loin, les données peuvent être échangées au moment de la mise en marche de la structure de diagnostic médical, ou de systèmes présents dans la structure, par l'intermédiaire du DCCS 40. Selon une autre possibilité, des transmissions peuvent être déclenchées par le prestataire de services distant, par exemple pour répondre<B>à</B> des demandes de données ou de services, pour accéder des données des systèmes diagnostiques ou pour saisir de telles données l'intermédiaire du DCCS, ou pour assurer divers servic es, dont des documents d'utilisation, des séances de formation, et autres, par l'intermédiaire des liaisons externes en réseau.

La Figure 2 illustre un exemple de configuration pour le DCCS comprenant ses périphériques et sa suite logicielle correspondants. Dans la forme de réalisation illustrée, le DCCS 40 comprend une unité centrale<B>86,</B> qui peut comporter un microprocesseur existant dans le commerce, dans un ordinateur polyvalent ou un ordinateur conçu pour une application spécifique. L'unité centrale est couplée<B>à</B> divers ensembles fonctionnels et logiciels pour exécuter les fonctions décrites ici. Par exemple, comme représenté sur la Figure 2, l'unité centrale est couplée<B>à</B> une interface de transmission<B>88</B> pour émettre et recevoir des données comme décrit plus haut par l'intermédiaire du réseau externe, et pour émettre recevoir de la même façon des données avec les systèmes diagnostiques par l'intermédiaire du réseau interne. Ainsi l'interface de transmission<B>88</B> peut coordonner des communications par l'intermédiaire d'un ou plusieurs modems 42 couplés<B>à</B> liaison de données 46. De même, le décodeur 44 de signaux provenant d'un satellite fait passer les données dans le DCCS par l'intermédiaire de la liaison par satellite 48. Une interface réseau supplémentaire<B>90,</B> par exemple une interface Ethernet, permet d'échanger des données par l'intermédiaire du réseau interne 20 de la structure.

Outre ces composants servant aux transmissions, le DCCS 40 comprend circuits<B>92</B> de mémoire et des composants d'assistance supplémentaires. Les circuits<B>92</B> de mémoire peuvent comporter n'importe quelle mémoire appropriée, telle que des lecteurs de disque, une mémoire vive, une mémoire morte, une mémoire vive dynamique, une mémoire optique, etc. Les circuits<B>92</B> de mémoire stockent<B>à</B> la fois des sous-programmes de logiciels exécutés par le DCCS, ainsi que des données collectées par le DCCS pour être transmises au prestataire de services distant, et des données reçues du prestataire de services distant pour les distribuer<B>à</B> des systèmes diagnostiques spécifiés ou adressés de la structure. De préférence, un système de sauvegarde 94 est prévu pour créer périodiquement des -versions d'archives de certains fichiers, sous-programmes, données collectées et autres. Une ou plusieurs interfaces de périphériques, désignées globalement par le repère<B>96,</B> sont prévues pour recevoir des signaux d'entrée d'une interface d'opérateur, et pour afficher des données et restituer des données en fonction des besoins. Dans la forme de réalisation illustrée, ces périphériques comprennent comme périphériques de sortie un écran<B>98</B> et un ordinateur et une imprimante 100., Les périphériques d'entrée peuvent comprendre un clavier 102, une souris 104 classiques et n'importe quel autre périphérique d'entrée adéquat.

Bien que certaines applications et certains programmes utilitaires des logiciels puissent être stockés et exécutés sur divers clients de la structure, en particulier dans les systèmes d'imagerie, le RIS, le HIS et le PACS, il est préférable que le DCCS 40 exécute d'une manière indépendante diverses applications afin de remplir les fonctions de transmission de données qui lui sont attribuées. Ces applications, désignées globalement par le repère<B>106</B> de la Figure 2, sont de préférence stockées dans les circuits<B>92</B> de mémoire et sont exécutées par l'unité centrale<B>86.</B> Selon une autre possibilité, certaines des applications peuvent être résidantes ailleurs et peuvent être entièrement ou partiellement exécutées par d'autres circuits de traitement. Les applications<B>106</B> comprennent d'une façon générale divers sous-programmes d'applications existant dans le commerce et peuvent en outre comporter des sous-programmes personnalisés exécutés par l'unité centrale. conséquent, on dispose d'une suite logicielle<B>108</B> que l'unité centrale peut exécuter aussi bien de manière automatique, avec une périodicité régulière, qu'en réponse des sollicitations par un opérateur ou des sollicitations du prestataire de services distant.

Les sous-programmes d'applications, désignés globalement par repère<B>110</B> de la Figure 2, peuvent comporter un logiciel servant<B>à</B> collecter des données des systèmes diagnostiques,<B>à</B> stocker ces données,<B>à</B> transmettre des données au prestataire de services distant et<B>à</B> acheminer des données depuis le prestataire de services vers des systèmes spécifiés. Dans la forme de réalisation illustrée sur la Figure 2, la suite logicielle<B>108</B> comporte un logiciel de base de données pour associer d'une manière relationnelle des données collectées provenant des systèmes diagnostiques. De préférence, ces données comprennent l'identification des systèmes, leur localisation, des données d'exploitation ainsi que diverses données de paramètres utiles pour déterminer l'état de fonctionnement du système et la nécessite éventuelle d'une intervention. Comme le comprendront les spécialistes de la -technique, dans le cas de systèmes d'imagerie diagnostique, toutes sortes de données d'exploitation ou de paramètres peuvent être directement stockés dans les différents systèmes diagnostiques et peuvent fournir des indications extrêmement utiles quant au fonctionnement des systèmes, et<B>à</B> d'éventuels futurs besoins d'interventions.

La suite logicielle<B>108</B> comprend aussi de préférence un logiciel de serveur que le logiciel de serveur Windows <B>NT</B> de Microsoft Corporation, Redmond Washington, ainsi qu'un logiciel de serveur Web. Le logiciel de serveur permet DCCS de fonctionner comme un serveur,<B>à</B> la fois pour les clients internes et pour les clients ou utilisateurs externes. De préférence, un logiciel de navigateur est également inclus, ce qui permet<B>à</B> un opérateur, par l'intermédiaire des interfaces d'opérateur du DCCS, de se connecter sur des sites, par exemple sur l'Initernet pour demander des informations et des données, transmettre des demandes de services et de données, etc. Dans la forme de réalisation préférée, le navigateur peut également fonctionner sur le DCCS pour permettre un interfaçage interactif directement dans un ou plusieurs des systèmes diagnostiques, en particuliers les systèmes d'imagerie diagnostique. Le logiciel d'acheminement est également en fonction sur le DCCS pour permettre une transmission adéquate des paquets de données reçus du prestataire de services distant vers des systèmes diagnostiques spécifiés présents dans la structure par l'intermédiaire du réseau interne.

De préférence, des applications supplémentaires de sous- programmes de logiciels sont également inclus dans le DCCS, dont des sous programmes de diagnostic et de services, et des sous-programmes interactifs services. sous-programmes, qui peuvent comporter une plate-forme interactive de services permet de générer des demandes de services, de préférence l'intermédiaire d'une interface avec un navigateur Web pour une transmission immédiate ou temporisée vers le prestataire de senîces distant. De préférence, applications permettent aussi de recevoir d'une manière interactive du prestataire de services distant des rapports et des données de senices. Un logiciel d'élaboration de rapport installé dans le DCCS pennet d'établir des rapports, en particulier des rapports concernant des activités de transmission enregistrées de la manière décrite plus loin, Des sous-programmes de sécurité peuvent être exécutés dans le cadre de la suite logicielle, de préférence pour vérifier l'intégrité des données émises et reçues par l'intermédiaire du DCCS, et pour limiter l'accès d'utilisateurs extérieurs, dont le prestataire de services distant, au réseau interne, ainsi que l'accès des clients connectés au réseau interne<B>à</B> des sites Web ou des prestataires distants.

De préférence, des applications de gestion d'équipements fonctionnent également dans le DCCS pour permettre l'exécution de diverses fonctions commerciales, financières et de gestion, de préférence en coordination avec des fonctions similaires exécutées par le RIS et le HIS. Par exemple, dans la forme de réalisation illustrée, des sous-programmes de transactions et de comptabilité peuvent être opérationnels, notamment pour gérer une comptabilité pour des services distants utilisés par la structure, les dépenses ou honoraires éventue Is liés<B>à</B> ces services, une comptabilité similaire pour les éventuelles transactions de commerce électronique réalisées, etc. Un sous-programme de suivi des équipements peut permettre une analyse de la situation géographique et de la disponibilité de clients ou équipements spécifiques, en particulier de clients mobiles qu'il est possible de suivre jusqu'à des lieux spécifiques<B>à</B> l'aide du réseau interne.

Les éléments de la suite logicielle illustrés sur la Figure 2 et examinés ci-dessus peuvent comprendre divers progiciels d'applications commercialisés, ou des logiciels créés spécialement pour la structure ou l'application. Cependant, d'une manière générale, n'importe quel logiciel spécifique d'une application peut facilement être élaboré par les spécialistes de la technique, sans nécessiter une expérimentation excessive. Dans la forme de réalisation actuellement préférée, des applications de logiciels du commerce, incluses dans le système et exécutées par le DCCS, comprennent un logiciel de base de données disponible auprès de Oracle Corporation, Redwood City, Californie, un logiciel multimédia disponible auprès de Eloquent Systems, Inc., North Vancouver, Colombie Britannique, un logiciel de serveur Web tel que le logiciel Netscape Enterprise disponible auprès de Netscape Communications, Mountain View, Californie, et un logiciel de navigation tel que le logiciel disponible auprès de Microsoft Corporation, Redmond, Washington, ou Netscape Communications.

La Figure<B>3</B> illustre globalement la circulation des données dans l'ensemble de l'architecture de système illustrée sur la Figure<B>1.</B> Comme représenté sur la Figure<B>3,</B> une circulation de données dans les deux sens est établie entre le DCCS 40 et les divers clients 24, et d'autres systèmes en réseau tels que le RIS 34, le HIS <B>36</B> et le PACS <B>38,</B> Comme indiqué plus haut, les clients 24 comprennent de préférence des systèmes d'imagerie médicale diagnostique reliés au prestataire de services distant par l'intermédiaire du DCCS pour répondre<B>à</B> des besoins de données et de services interactifs.

Le DCCS 40 transmet également des données vers et depuis le circuit<B>92</B> de mémoire, lequel, sur le schéma de la Figure<B>3,</B> peut comprendre des bases de données,<B>à</B> la fois localement dans le DCCS et<B>à</B> divers n#uds en réseau de la structure.

<B>A</B> l'intérieur du prestataire de services distant 14, des données peuvent être échangées entre l'interface<B>70</B> et les divers systèmes et sous-systèmes, tels que ceux décrits plus haut, comme le système<B>62</B> de sen, ices, PACS 64, les systèmes de commerce électronique<B>66</B> et les unités ou sysièmes d'apprentissage<B>68.</B> Chacun de ces systèmes peut comporter d'autres systèmes ou postes en réseau, par exemple les postes de travail 112 qui, par l'intermédiaire du système de services<B>62,</B> permettent<B>à</B> des ingénieurs d'applications d'accéder<B>à</B> des données du sy!#tème de diagnostique, d'adresser des besoins et demandes de services spécifiques, et autres. De préférence, une ou plusieurs bases de données 114 et<B>116</B> sont reliées aux systèmes du prestataire de services distant afin de permettre un stockage relationnel de données opérationnelles et de paramètres, et de les restituer<B>à</B> volonté pour réaliser une analyse, rapport, une facturation, etc. <B>Il</B> faut souligner que les éléments du prestataire services distant, dont les systèmes illustrés sur la Figure<B>3,</B> peuvent échanger des données soit de manière locale soit par l'intermédiaire de toutes sortes de configurations en réseau, dont des configurations permettant qu'un ou plusieurs des systèmes et des bases de données soient géographiquement situés<B>à</B> des emplacements éloignés les uns des autres.

Les données échangées de manière interne au sein de la structure de diagnostic médical et du prestataire de services distant sont ensuite échangées par l'intermédiaire des liaisons en réseau entre ces structures. Dans la forme de réalisation illustrée, ces liaisons en réseau comprennent les liaisons par satellite 48 et <B>80,</B> qui acheminent des données par l'intermédiaire d'un satellite 54 ou d'un circuit au sol, ainsi réseau étendu défini par les liaisons 46 et<B>78,</B> et le réseau<B>50.</B>

Les techniques et composants de transmission de données décrits ci- dessus permettent d'accéder<B>à</B> des données et d'échanger des données selon divers sous-programmes. Des étapes logiques de certains de ces sous-programmes sont illustrées sur figures 4<B>à 9.</B>

En référence<B>à</B> la Figure 4, un premier sous-programme permet de formuler des demandes de services et de données dans la structure de diagnostics en vue d'une transmission au prestataire de services distant. Le sous-programme de demande de services, désigné globalement par le repère 200, commence<B>à</B> l'étape 202 où un client de la structure génère une demande de données. Dans le présent contexte, ces demandes de données peuvent comporter toutes sortes de demandes de services, de données, de logiciels et autres. En particulier, pour les systèmes d'imagerie médicale diagnostique, ces demandes peuvent comporter des descriptions de problèmes spécifiques survenant dans le système, des demandes de protocoles d'imagerie pour logiciels, des questions relatives au fonctionnement, etc. Cependant, des demandes similaires peuvent avoir pour origine des clients réseau, par exemple des services de formation interne de la structure, notamment pour des documents multimédia de formation qui peuvent être transmis par le DCCS comme décrit plus loin.<B>Il</B> faut également souligner que la demande de données peut être formulée dans des systèmes diagnostiques qui comportent<B≥</B> Io-giciel <B>à</B> fonctionnement local pour la formulation des demandes, ou par l'intermédiaire d'applications fonctionnant sur le DCCS et accessibles par l'intermédiaire du système diagnostique. Lors de l'étape 204, ces demandes sont transmises au DCCS. Lors de l'étape<B>206,</B> les demandes sont triées et il est possible d'effectuer une vérification éventuelle de licence, afin de déterminer si le système de diagnostique effectuant la demande est alors autorisé pour le type de demande faite.

Comme indiqué au niveau de l'étape<B>208</B> de la Figure 4, des demandes de services ou de données peuvent être générées directement dans le DCCS40. De telles demandes peuvent être formulées par l'intermédiaire des composants d'interface d'opérateur du DCCS, de préférence par l'intermédiaire d'une interface interactive telle qu'un navigateur Web ou autre interface utilisateur graphique.<B>Il</B> faut souligner que l'aptitude<B>à</B> générer directement des demandes de données et de services dans le DCCS offre de grands avantages par rapport techniques existantes pour l'utilisation interactive de systèmes diagnostiques. exemple,<B>'</B> le parc d'équipements installés d'une structure médicale n'est pas ou ne peut pas etre équipé pour des transmissions directes par l'intermédiaire d'un réseau externe, les équipements peuvent néanmoins être couplés au DCCS par l'intermédiaire du réseau interne. De plus, de nombreux systèmes et dispositifs de diagnostic médical ne sont pas équipés pour une interface opérateur afin de permettre la formulation de demandes de services et de données. Cependant, la possibilité de générer de telles demandes directement dans le DCCS permet que ces systèmes soient inclus dans un plan général de prestation de services. Suite<B>à</B> la génération de la demande lors de l'étape<B>208,</B> les fonctions de tri et de vérification de licence de l'étape peuvent être exécutées comme indiqué sur la Figure 4.

Lors de l'étape 210 de la Figure 4, les données incluses dans la demande font l'objet d'une analyse, notamment pour identifier le système diagnostique demandeur ou désigné, des problèmes ou questions spécifiques résoudre, opérateur ou un clinicien formulant la demande, etc. Lors de l'étape 21 ces informations sont enregistrées dans les circuits de mémoire du DCCS. Lors de l'étape 214, la demande est placée dans une invitation pour transmission prestataire de services distant. Si une session de connexion est en cours, la demande peut être émise dans la fenêtre de transmission disponible le plus tôt, comme indiqué au niveau de l'étape<B>216.</B> Si nécessaire, l'émission lors de l'étape<B>216</B> peut nécessiter l'ouverture d'une session de connexion. Dans la forme de réalisation actuellement préférée, de telles connexions peuvent être entreprises soit par le DCCS, soit par prestataire de services distant. Si on le souhaite, la réception et l'émission de la demande sont reconfirmées au système de diagnostique désigné, comme indiqué au niveau de l'étape<B>218.</B> De plus, si des données clients supplémentaires sont nécessaires pour adresser la demande, ces données peuvent être extraites comme indiqué au niveau de l'étape 220. Ces données peuvent comporter des configurations particulières ou des réglages de paramètres particuliers qui ont pu avoir été créés pendant une séquence d'imagerie, par exemple des trains de données produits un système ou un écran d'imagerie, des données d'historiques de services, etc.

Les demandes formulées conformément<B>à</B> la logique de la Figure 4 sont transmises par l'intermédiaire du réseau externe au prestataire de services distant. Figure<B>5</B> illustre un exemple d'étapes logiques pour faire face<B>'</B> ces demandes. La procédure de gestion, désignée globalement par le repère<B>250,</B> commence par la réception de la demande lors de l'étape<B>252.</B> Lors de l'étape 254, un message d'accusé de réception peut être formulé par le prestataire de services distant, par exemple par l'intermédiaire d'un programme d'émission automatique de message de retour, et être renvoyé au DCCS pour informer la structure de ce que la demande a été reçue et est en cours de gestion. Cet accusé de réception peut comporter des détails supplémentaires concernant la gestion, par exemple des références chiffrées, des numéros d'envois, des plans de gestion, etc. Lors de l'étape<B>256,</B> les données de la demande sont analysées en vue d'un enregistrement par le prestataire de senices distant. L'analyse effectuée lors de l'étape<B>256</B> peut comporter une analyse pour des données semblables<B>à</B> celles examinées lors de l'étape 210 de la Figure 4, par exemple pour une identification du système demandeur ou désigné, une identification de la structure, des données d'abonnement<B>à</B> un service, et des données de fonctionnement ou des paramètres nécessaires pour étudier et satisfaire la demande. Lors de l'étape 254, des archives de licence ou de comptabilité stockées dans une base de données du prestataire de services distant font l'objet d'un accès et d'une actualisation pour prendre note de la demande. Selon la structure comptable voulue, la demande peut être gérée dans le cadre d'un contrat ou d'un abonnement en cours, d'une garantie, ou selon un principe de paiement par utilisation, ou autrement.

Comme indiqué plus haut, selon le type de demande émise par la structure diagnostic médical, sa gestion par le prestatair e de services distant peut prendre diverses modalités. Comme indiqué<B>à</B> propos de l'étape<B>260</B> de la Figure<B>5,</B> la demande est considérée dans le prestataire de services pour une gestion telle qu'une gestion automatique, ou pour une intervention d'un technicien d'entretien. 'Dans les deux cas, il peut être nécessaire d'obtenir des données supplémentaires du système pour répondre correctement<B>à</B> la demande de services. Dans le cas d'un équipement d'imagerie pour diagnostic médical, ces informations supplémentaires peuvent comporter des fichiers données d'image brutes ou traitées, des paramètres de configuration et des réglages du système, et autres. Comme indiqué au niveau de l'étape<B>262,</B> ces données peuvent être récupérées par l'intermédiaire du réseau externe, du DCCS et réseau interne de la structure. Une fois qu'on a accédé<B>à</B> suffisamment d'informations pour répondre<B>à</B> la demande, les données, rapports, analyses et autres qui ont<B>'</B> demandés peuvent alors être renvoyés par le prestataire de services distant au système désigné de diagnostic médical par l'intermédiaire du DCCS, ou directement DCCS duquel est venue la demande. Les transmissions effectuées lors de l'étape peuvent comporter toutes sortes de données. Par exemple, les données peuvent comporter des paramètres de configuration, des propositions de mesures de dépannage, des messages électroniques, de la documentation électronique, des mises<B>à</B> niveau de logiciels, des protocoles, etc. Si nécessaire, un technicien inter-venant sur site peut être envoyé, comme indiqué lors de l'étape<B>266</B> de la Figure pour compléter le suivi. Le technicien envoyé sur place lors de l'étape<B>266</B> peut satisfaire la demande soit lui-même soit<B>à</B> distance, par exemple par téléphone autres moyens de communication avec le prestataire de ser-vices distant.

Comme indiqué ci-dessus, des réponses<B>à</B> des demandes émanant de la structure de diagnostic 'dical peuvent être transmises par l'intermédiaire d'autres moyens tels qu'un réseau étendu et une liaison par satellite. La logique de la Figure<B>5</B> illustre une fon-ne de réalisation permettant de traiter de telles émissions en réponse<B>à</B> des demandes. Bien que divers moyens puissent être employés<B>à</B> cette fin, dans une forme de réalisation actuellement préférée les moyens de transmission ont des vitesses ou largeurs de bande d'émission nettement différentes, ce qui permet de procéder<B>à</B> certains types transmissions<B>à</B> l'aide d'un premier type de connexion, par exemple le réseau étendu, des transmissions plus exigeantes ou spécifiques étant faites<B>à</B> l'aide d'un moyen<B>à</B> largeur de bande plus grande. Diverses solutions peuvent être adoptées pour décider celui des moyens qui sera employé pour la transmission. Par exemple, le prestataire de services<B>à</B> distance peut sélectionner manuellement ou automatiquement un moyen en fonction des besoins ou des préférences de la structure de diagnostic médical. De plus, des types spécifiques de transmissions peuvent être mis en #uvre sur un moyen ou l'autre, par exemple des transmissions multimédia en temps réel qui peuvent nécessiter une grande largeur de bande, peuvent occuper une liaison pendant grands laps de temps, ou peuvent être particulièrement sujets<B>à</B> des retards dus<B>à</B> des interruptions ou au réseau.

Dans la forme de réalisation actuellement préférée, le choix entre le réseau étendu ou la liaison par satellite est fait sur la base d'une catégorie de données ou d'émission. Ainsi, lors de l'étape<B>268</B> de la Figure<B>5,</B> la catégorie est examinée et l'un des moyens disponibles est choisi. titre d'exemple, des présentations par multimédia, des sessions de formation et autres catégories de données similaires sont transmises par la liaison par satellite, tandis que des émissions de données plus classiques se font par l'intermédiaire réseau étendu. Selon la catégorie de transmission, le moyen est donc choisi comme indiqué<B>à</B> l'étape<B>270</B> ou<B>276.</B> La transmission est ensuite planifiée comme indiqué lors de l'étape<B>272</B> ou de l'étape <B>278.</B> Dans le cas de sessions de formation. par exemple, la transmission peut être planifiée pour une date et une heure plus lointaine, le système de diagnostique désigné étant un lieu spécifique, une salle de formation ou un autre client de la structure de diagnostic. Enfin, comme indiqué au niveau de l'étape 274 ou<B>280,</B> la transmission planifiée est effectuée<B>à</B> l'aide du moyen choisi.

La Figure<B>6</B> illustre un exemple de logique de commande pour recevoir et traiter des réémissions du prestataire de services distant vers la structure de diagnostic. Cette logique de commande, désignée globalement par le repère<B>300,</B> cormnence lors de l'étape<B>302</B> par la réception des données émises. Cette réception s'effectue par l'intermédiaire du DCCS, comme lors d'une session d'émission de données en cours. Lors de l'étape 304, les données reçues sont analysées pour identifier au moins le système diagnostique désigné ou adressé. Lors de l'étape<B>306,</B> les données sont envoyées depuis le DCCS vers le système désigné par l'intermédiaire du réseau interne de la structure. Il faut souligner que l'étape<B>306</B> peut comporter le stockage de la totalité ou d'une partie des données, ou des informations obtenues ou analysées<B>à</B> partir des données présentes dans le circuit de mémoire du DCCS, ou dans une autre base de données de la structure. Lors de l'étape<B>308,</B> la réception et l'échange de communications sont enregistrés par le DCCS.

Si nécessaire, on peut, comme indiqué sur la Figure<B>7,</B> mettre en #uvre d'autres procédures possibles pour la réception et le traitement de données. Les autres étapes de réception indiquées globalement'par le repère<B>350</B> peuvent être souhaitables par exemple lors de la réception de données numériques par l'intermédiaire de liaisons par satellite, les données étant ache#minées par l'intermédiaire du DCCS pour être distribuées. En particulier, de tels systèmes de transmission par satellite, ou d'autres moyens possibles, peuvent ne pas demander communication dans les deux sens. Ainsi, certaines des informations permettant gérer les données peuvent être transmises en parallèle par l'intermédiaire de l'autre moyen, en particulier par un réseau étendu. Ainsi, lors de l'étape<B>352,</B> un sous- programme de mise en communication est exécuté entre le DCCS et le prestataire services distant pour assurer une connectivité appropriée et la possibilité d'échange infon-nations nécessaires. Lors de l'étape 354, une procédure d'authentification peut être menée pour assurer que la session d'émission par l'intermédiaire du moy en parallèle correspond<B>à</B> la demande et au plan d'émission. Lors de l'étape<B>' ,</B> l'adresse du destinataire est identifiée et confirmée de façon<B>à</B> s'assurer que le canal d'émission est convenablement accordé ou sélectionné, et que le client ou le système diagnostique est identifié dans la structure. Lors de l'étape<B>358,</B> l'émission est reçue et démodulée, filtrée ou soumise<B>à</B> un autre traitement. Comme indiqué au niveau de l'étape<B>360,</B> les données reçues par l'intermédiaire du moyen en parallèle peuvent nécessiter un traitement supplémentaire, par exemple pour mettre sous forme de paquets les données<B>à</B> émettre sur le réseau interne.<B>A</B> la suite de ce traitement, les données sont distribuées au système désigné. La séquence de communication et l'émission sont enregistrées comme indiqué lors de l'étape<B>362.</B>

En plus de l'échange interactif de données de services et autres, la présente technique permet la saisie de données d'exploitation et de paramètres provenant des systèmes de diagnostic médical qui constituent des clients du réseau interne de la structure, par l'intermédiaire d'une procédure simplifiée. La Figure<B>8</B> illustre des exemples d'étapes de cette procédure,<B>à</B> l'aide d'une logique de commande désignée globalement par le repère 400. Globalement, la procédure permet la saisie ou la collecte des données des systèmes de diagnostiques en réseau par l'intermédiaire du DCCS, et émises depuis le DCCS vers le prestataire de services distant. Dans des solutions antérieures permettant une prestation de service pour systèmes diagnostiques médicaux, ces données étaient saisies d'une manière typique par connexion directe sur un système de diagnostique voulu, nécessitant qu'un grand nombre de connexions soit réalisé d'une manière indépendante et imposant de fortes exigences concernant l'infrastructure,<B>à</B> la fois au sein de la structure et au niveau prestataire de services distant. De plus, si les systèmes de diagnostiques n'étaient pas équipés pour être directement connectables au prestataire de services distant, on ne pouvait pratiquement pas obtenir d'informations, en particulier directement du système.

Selon la présente solution, des informations peuvent être obtenues par plusieurs procédés différents, lancés de manière aussi bien automatique manuelle. Dans l'exemple de logique de la Figure<B>8,</B> le processus de saisie de données peut commencer par le lancement d'un sous-programme d'interrogation automatique lors de l'étape 402. Ce sous-programme devrait être exécuté par le DCCS qui entre contact selon un plan préétabli avec chaque système en réseau ou avec des systèmes désignés dont souhaite obtenir des données.<B>A</B> titre d'exemple, le plan peut comporter une saisie périodique de données pendant toute une période de 24 heures, ou une saisie moins fréquente. Conformément au sous-programme et au plan, les clients sont contactés lors de l'étape 404 de la Figure<B>8.</B> Lors de l'étape 406, on accède aux données, exemple par récupération<B>à</B> partir des circuits de mémoire des systèmes diagnostiques des clients. Lors de l'étape 408, les données peuvent être filtrées, notamment pour déterminer si des informations complètes ou incomplètes sont saisies, pour analyser des données non souhaitées telles que des données spécifiques patient, etc. Lors de l'étape 410, les données sont enregistrées, notamment dans les circuits de mémoire du DCCS.

Une alternative au processus d'interrogation décrit ci-dessus peut consister en ce que certaines données soient collectées lorsque survient un événement spécifique dans le système diagnostique ou dans la structure. Par exemple, si certains des systèmes de la structure sont mobiles, la connexion du système mobile au réseau interne peut amener le DCCS <B>à</B> exécuter le sous-programme de saisie de données pour le système nouvellement connecté. Ainsi, comme indiqué pour l'étape 412 de la Figure<B>8,</B> le système ou l'équipement spécifique peut changer d'état, notamment établissant ou en renouvelant une connexion au réseau interne. Lors de l'étape 4 on accède ensuite au système et les inforrnations voulues sont transférées du système vers le DCCS. <B>A</B> titre d'exemple, pour permettre le suivi d'équipements, la gestion d'équipements, l'analyse de productivité et pour d'autres fonctions, la localisation d'équipements mobiles peut être obtenue et enregistrée pour servir ultérieurement ou pour permettre au personnel de la structure de suivre les équipements.

Les séquences de saisie de donnée peuve nt également être lancées par une demande manuelle, comme indiqué par l'étape 416 de la Figure<B>8.</B> La demande manuelle peut être entrée par l'intermédiaire des composants de l'interface d'opérateur du DCCS, notamment pour accéder<B>à</B> des caractéristiques ou paramètres des systemes en réseau, ou pour afficher des caractéristiques de performance, d'utilisation et autres. En réponse<B>à</B> la demande manuelle, l'accès au système désigné se fait, comme indiqué par l'étape 418, et les données voulues sont localisées et transmises depuis la mémoire du dispositif, comme indiqué au niveau de l'étape 420.

Pour faciliter la transmission des données saisies vers le prestataire de services distant, il est préférable que les données saisies soient stockées place dans la structure de diagnostics et soient transmises au prestataire de services distant en une plusieurs sessions de transmission de données. Ces sessions peuvent être planifiées pour des moments commodes, notamment pendant les heures creuses, les heures de nuit, les fins de semaine, et autres. La Figure<B>9</B> illustre des étapes d'un exemple de logique de commande, désignée globalement par le repère<B>- ,</B> pour la transmission de données une fois que celles-ci ont été saisies dans la structure.

En référence<B>à</B> la Figure<B>9,</B> le transfert de données est tout d'abord planifié comme indiqué au niveau de l'étape 452. Comme on l'a signalé, plan peut être établi pour des moments commodes,<B>à</B> la fois pour la structure de diagnostic et pour le prestataire de services distant. Cependant, il faut souligner que ces transferts de données peuvent être lancés, si on le souhaite, par une intervention d'un opérateur.

Comme indiqué au niveau de l'étape 454, une connexion est alors établie entre la structure de diagnostics et le prestataire de services distant. La connexion peut être lancée soit par la structure soit par le prestataire de services distant, le prestataire de services distant étant préférable dans la présente forme de réalisation. Par ailleurs, au niveau de l'étape 454, le prestataire de services distant sollicite le transfert des données, par exemple par l'intermédiaire d'un sous-programme de transmission stocké<B>à</B> fois dans le DCCS et le prestataire de services distant. En réponse<B>à</B> la sollicitation, l'accès aux données se fait depuis la mémoire ou le référentiel de la structure médicale et les données sont transférées vers le prestataire de services distant, comme indiqué au niveau de l'étape 456. Pendant ou après le transfert, l'analyse, filtrage et autres traitements éventuels souhaités sont effectués comme indiqué au niveau de l'étape 458. En particulier, les données transférées sont de préférence analysées pour identifier les différents systèmes diagnostiques produisant les données, et pour séparer les unes des autres les données de fonctionnement et de paramètres pour les différents systèmes. Ensuite, les données sont stockées, de préférence dans des bases de données relationnelles, en vue de leur récupération et de leur analyse ultérieures. Enfin lors de l'étape 460, la session de transfert de données est enregistrée, de préférence<B>à</B> la fois dans la structure de diagnostics et le prestataire de services distant.

Claims (1)

1. REVENDICATIONS <B>1 ,</B> Système (40) de gestion de transmissions de données pour une structure<B>(1</B>2) exécutant des diagnostics médicaux, l'interface comprenant: une interface<B>(90)</B> de réseau de la structure servant<B>'</B> transmettre des données<B>à</B> des clients (24-36) dans une structure (12) établissant des diagnostics médicaux et pour recevoir des données des clients; une interface (42, 44) de réseau externe servant a transmettre des données<B>à</B> une structure de services distante (14) et<B>à</B> recevoir des données de la structure de services distante; et un circuit<B>(86)</B> de traitement de données agencé pour acheminer des données depuis la structure de services distante (14) vers des clients (24-38) dans la structure (12) établissant des diagnostics médicaux et pour transmettre des données depuis les clients vers la structure de services distante. 2. Système selon la revendication<B>1,</B> dans lequel l'interface<B>(90)</B> de réseau de la structure comporte une interface de réseau étendu (20). <B>3.</B> Système selon la revendication<B>1,</B> dans lequel l'interface (42, 44) de réseau externe comporte un circuit de transmission (42) pour un réseau étendu. 4. Système selon la revendication<B>1 ,</B> dans lequel l'interface(42, 44) de réseau externe comporte au moins deux circuits différents de transmission par des moyens de transmission. <B>5.</B> Système selon la revendication 4, dans lequel les circuits de transmission par moyens de transmission sont configurés pour recevoir des données par l'intermédiaire d'un réseau étendu<B>(50)</B> et d'une liaison radioélectrique (54) de données. <B>6.</B> Système selon la revendication<B>5,</B> dans lequel le réseau étendu <B>(50)</B> comprend l'Internet. <B>7.</B> Système selon la revendication<B>5,</B> dans lequel la liaison radioélectrique comporte une liaison de transmission (54) par satellite et circuits de transmission par moyens de transmission comprennent un circuit de décodage (44) servant<B>à</B> convertir les données reçues en données sous forme de paquets<B>'</B> fournir<B>à</B> un client (24-38). <B>8.</B> Système selon la revendication<B>1,</B> dans lequel le circuit de traitement de données est configuré pour exécuter des sous-programmes (200) d'interfaçage en réponse<B>à</B> des demandes de données émanant des clients<B>-38).</B> <B>9.</B> Système selon la revendication<B>1,</B> comprenant outre un circuit<B>(92)</B> de mémoire servant<B>à</B> stocker des données des clients (24 pour les transmettre<B>'</B> la structure de services distante (14). <B>10.</B> Système selon la revendication<B>1,</B> comprenant en outre une interface operateur <B>(98, 100,</B> 102, 104) pour accéder aux données des clients (24-M) <B>à</B> la demande. <B>11.</B> Système selon la revendication<B>1,</B> dans lequel le circuit de traitement<B>(86)</B> est configuré pour se comporter comme un serveur afin d'exécuter des sous-programmes<B>(l 10)</B> d'une manière interactive avec des clients. 12. Procédé pour gérer des transmissions de données entre une pluralité de clients (24-3<B>8)</B> en réseau d'une structure<B>(l</B> 2) établissant des diagnostics médicaux et un prestataire de services distant (14), le procédé comprenant les étapes consistant<B>à:</B> (a) prévoir un système (40) de traitement de données se comportant comme un serveur et un routeur pour recevoir des données des clients et transmettre données des clients<B>à</B> un prestataire de services distant (14), et pour recevoir des données adressées en provenance du prestataire de services distant et distribuer les données adressées aux clients (24-338); <B>(b)</B> interfacer le système de traitement de données avec un réseau interne (20, 22), de la structure (12) exécutant des diagnostics médic aux en vue d'un échange de données entre système (40) de traitement de données et les clients (24 <B>38).</B> (c) interfacer le système de traitement de données avec un réseau externe (46,<B>50, 78,</B> 48, en vue d'un échange de données entre le système (40) de traitement de données et le prestataire de services distant<B>(1</B>4); et <B>(d)</B> échanger des données entre les clients (24-38) et le prestataire de services distant (14) l'intermédiaire du système (40) de traitement de données, du réseau interne et du réseau externe. <B>13.</B> Procédé selon la revendication 12, dans lequel sensiblement toutes les transmissions de données entre les clients (24-38) et le prestataire de services distant (14) sont acheminées par l'intermédiaire du système (40) de traitement de données. 14. Procédé selon la revendication 12, comprenant l'étape supplémentaire consistant entreprendre l'accès (402, 404, 406) aux données des clients par le système (40) de traitement de données conformément<B>à</B> un sous- programme prédéterminé (400) de saisie de données. <B>15.</B> Proce selon la revendication 12, comprenant l'étape supplémentaire consistant entreprendre l'accès (418, 420) aux données des clients par le système (40) de traitement de données en réponse<B>à</B> une demande (416) d'opérateur appliquée au le système de traitement de données. <B>16.</B> Procédé selon la revendication 12, comprenant l'étape supplémentaire consistant<B>à</B> enregistrer les transmissions (212,<B>308, 362)</B> entre les clients (24-38) et le prestataire de services distant (14). <B>17.</B> Procédé selon la revendication 12, dans lequel le réseau externe (46,<B>50, 78,</B> 48, 54,<B>80)</B> comprend au moins deux moyens de transmission de données différents. <B>18.</B> Procédé selon la revendication<B>17,</B> dans lequel lesdits au moins deux moyens de transmission de données différents comprennent une liaison câblée <B>(50)</B> et une liaison (54) par satellite.