INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
butyle, t-butyle, heptyle, octyle, éthylhexyle, cyclohexyle, hydroxyéthyle et benzyle), le N-aryl- (méth)acrylamide (le groupe aryle comprend, par exemple, phényle, tolyle, nitrophényle, naphtyle et hydroxy- phényle), le N,N-dialkyl(méth)acrylamide (le groupe alkyle comprend, par exemple, méthyle, éthyle, butyl, isobutyle, éthylhexyle et cyclohexyle), le N,N- diaryl(méth)acrylamide (le groupe aryle comprend, par exemple, phényle), le N-méthyl-N-phényl(méth)acrylamide, le N-hydroxyéthyl-N-méthyl(méth)acrylamide, le N-2-acéto- amidoéthyl-N-acétyl(méth)acrylamide, le N-(phényl- sulfonyl)-(méth)acrylamide et le N-(p-méthylphényl- sulfonyl)(méth)acrylamide ; un composé d'alylle tel que des esters d'allyle (par exemple, l'acétate d'allyle, le caproate d'allyle, le caprylate d'allyle, le laurate d'allyle, le palmitate d'allyle, le stéarate d'allyle, le benzoate d'allyle, l'acétoacétate d'allyle et le lactate d'allyle) et l'allyloxyéthanol ; des éthers vinyliques, tels que l'éther alkylvinylique (le groupe alkyle comprend, par exemple, hexyle, octyle, décyle, éthylhexyle, méthoxyéthyle, éthoxyéthyle, chloroéthyle, 1-méthyl-2,2-diméthylpropyle, 2-éthylbutyle, hydroxyéthyle, hydroxyéthoxyéthyle, diméthylaminoéthyle, diéthylaminoéthyle, butylamino- éthyle, benzyle et tétrahydrofurfuryle) et des éthers arylvinyliques (le groupe aryle comprend, par exemple, phényle, tolyle, chlorophényle, 2,4-dichlorophényle, naphtyle et anthranyle) ; des esters vinyliques tels que le butylate de vinyle, l'isobutylate de vinyle, le triméthylacétate de vinyle, le diéthylacétate de vinyle, le barate de vinyle, le caproate de vinyle, le chloracétate de vinyle, le dichloracétate de vinyle, le méthoxyacétate de vinyle, le butoxyacétate de vinyle, le phénylacétate de vinyle, l'acétoacétate de vinyle, le lactate de vinyle, le ss- phénylbutylate de vinyle, le cyclohexylcarboxylate de
Comme indiqué dans l'étape 208 en figure 4, les deman des de services ou de données peuvent être générées direc tement au niveau du système de commande de communication de données 40. Ces demandes peuvent être formulées par l'intermédiaire des composants de l'interface d'opérateur du système de commande de communication de données, de préférence par l'intermédiaire d'une interface interac tive, telle qu'un programme de recherche sur Internet ou une autre interface d'utilisateur graphique. On notera que la capacité à générer des demandes de données et de servi ces directement au niveau du système de commande de commu nication de données offre des avantages significatifs par rapport aux techniques -existantes pour le service interac tif aux systèmes de-diagnostic. Par exemple, lorsque la base d'équipement installée dans un établissement médical n'est pas ou ne peut pas être équipée pour la communica tion directe par l'intermédiaire d'un réseau externe, l'équipement peut néanmoins être couplé au système de com mande de communication de données par l'intermédiaire du réseau interne. De plus, de nombreux dispositifs et systè mes de diagnostic médical ne sont pas équipés pour que l'interface d'opérateur puisse autoriser la formulation de demandes de services et de données. Toutefois, la capacité à générer ces demandes directement au niveau du système de commande de communication de données permet à ces systèmes d'être inclus dans une configuration de fourniture de ser vices globale. Après la génération de la demande lors de l'étape 208, les fonctions de tri et de vérification d'au torisations de l'étape 206 peuvent être effectuées comme indiqué en figure 4.
Lors de l'étape 210 de la figure 4, les données com prises dans la demande sont analysées, de façon à identi fier le système de diagnostic désigné ou demandeur, les problèmes ou les questions spécifiques devant être trai tés, un opérateur ou un médecin formulant la demande, etc. Lors de l'étape 212, cette information est enregistrée dans les circuits de mémoire du système de commande de communication de données. Lors de l'étape 214, la demande est placée dans une file d'attente pour la transmission au fournisseur de services à distance. Lorsqu'une session de connexion est en train de se faire, la demande peut être transmise à la fenêtre de communication disponible la plus précoce, comme indiqué dans l'étape 216. Si nécessaire, la transmission lors de l'étape 216 peut nécessiter le dé clenchement d'une session de connexion. Dans la réalisa tion actuellement préférée, ces connexions peuvent être déclenchées soit par le système de commande de communica tion de données, soit par le fournisseur de services à distance. Lorsqu'on le désire, la réception et la trans mission de la demande est reconfirmée au système de diag- nostic désigné comme indiqué dans l'étape 218. De plus, lorsque des données de client additionnelles sont néces saires pour traiter la demande, ces données peuvent être extraites comme indiqué dans l'étape 220. Ces données peu vent comprendre des configurations ou des déterminations de paramètres particulières qui peuvent avoir été présen tes lors d'une séquence d'imagerie, par exemple des chaî nes de données produites par un écran ou un système d'ima gerie, des données d'historique de services, etc.
Les demandes formulées selon la logique de la figure 4 sont transmises par l'intermédiaire du réseau externe au fournisseur de services à distance. La figure 5 illustre des exemples d'étapes logiques pour traiter de telles de mandes. La procédure de traitement, indiquée globalement par le numéro de référence 250, commence par la réception de la demande lors de l'étape 252. Lors de l'étape 254, un message d'accusé de réception peut être formulé par le fournisseur de services à distance, par exemple par l'in termédiaire d'un programme de messagerie de retour automa tique, et renvoyé au système de commande de communication de données pour informer l'établissement du fait que la demande a été reçue et qu'elle est traitée. Cet accusé de réception peut comprendre des détails additionnels concer nant le traitement, par exemple des numéros de référence, des numéros de répartition, des programmes horaires de traitement, etc. Lors de l'étape 256, les données de la demande sont analysées pour l'enregistrement par le four nisseur de services à distance. L'analyse effectuée lors de l'étape 256 peut comprendre une analyse pour des don nées similaires à celles examinées lors de l'étape 210 de la figure 4, par exemple pour une identification du sys tème demandeur ou désigné, une identification de l'éta blissement, des données d'abonnement à un service, et des données de paramètres ou opérationnelles nécessaires pour examiner et traiter la demande. Lors de l'étape 254, on accède à des enregistrements d'autorisation ou de compta bilité mémorisés à l'intérieur d'une base de données du fournisseur de services à distance, et ceux-ci sont remis à jour pour prendre note de la demande. Selon la structure de comptabilité désirée, la demande peut être traitée dans le cadre d'un contrat ou d'un abonnement existant, sur la base d'une garantie, sur une base de paiement lors de l'utilisation, ou d'une autre façon.
Comme indiqué ci-dessus, en fonction du type de de mande transmise à partir de l'établissement de diagnostic médical, son traitement par le fournisseur de services à distance peut se faire selon différents modes. Comme indi qué dans l'étape 260 en figure 5, la demande est traitée chez le fournisseur de services pour le traitement, par exemple pour un traitement automatique, ou pour l'inter vention d'un ingénieur de service. Dans tous les cas, il peut être nécessaire d'obtenir des données additionnelles depuis le système afin de traiter correctement la demande de service. Dans le cas d'un équipement d'imagerie de diagnostic médical, cette information additionnelle peut comprendre des fichiers de données d'image bruts ou trai tés, des déterminations et des paramètres de configuration de système, etc. Comme indiqué dans l'étape 262, ces don nées peuvent être récupérées par l'intermédiaire du réseau externe, du système de commande de communication de don nées, et du réseau interne de l'établissement. Une fois que l'on a accédé à une information suffisante pour trai ter la demande, les données demandées, les rapports, les analyses, etc., peuvent alors être retransmis à partir du fournisseur de services à distance vers le système de diagnostic médical désigné par l'intermédiaire du système de commande de communication de données, ou directement vers le système de commande de communication de données d'où est venue la demande. Les transmissions lors de l'étape 264 peuvent comprendre une large gamme de données. Par exemple, les données peuvent comprendre des paramètres de configuration, des étapes de recherche de panne suggé rées, des messages électroniques, une documentation élec tronique, des remises à jour de logiciel, des protocoles, etc. Lorsque c'est nécessaire, un ingénieur de maintenance peut être détaché, comme indiqué dans l'étape 266 de la figure 5, pour un suivi additionnel. L'ingénieur de main tenance détaché lors de l'étape 266 peut traiter la de mande soit en personne soit à distance, par exemple par téléphone ou par d'autres connexions à partir du fournis seur de services à distance.
Comme indiqué ci-dessus, les réponses aux demandes de l'établissement de diagnostic médical peuvent être trans mises par l'intermédiaire d'autres supports, tels qu'un grand réseau et une liaison satellite. La logique de la figure 5 illustre une réalisation pour traiter ces trans missions en réponse à des demandes. Bien que différents supports puissent être employés dans ce but, dans une réa lisation actuellement préférée, les supports ont des dé bits ou des largeurs de bande de transmission significati- vement différents, permettant de réaliser certains types de transmissions par l'intermédiaire d'un premier type de connexion, tel que le grand réseau, des transmissions plus exigeantes ou spécifiques étant réalisées par l'intermé diaire d'un support à plus grande largeur de bande. Diffé rentes approches peuvent être adoptées pour décider lequel des supports sera employé pour la transmission. Par exem ple, le fournisseur de services à distance peut sélection ner manuellement ou automatiquement un support en fonction des exigences ou des préférences de l'établissement de diagnostic médical. De plus, des types spécifiques de transmissions peuvent être effectuées sur un support ou sur l'autre, par exemple des transmissions par supports à débit continu, qui peuvent nécessiter une largeur de bande substantielle, qui peuvent occuper une liaison pendant des périodes de temps substantielles, ou qui peuvent être par ticulièrement sujettes à des interruptions ou des retards de réseau.
Dans la réalisation actuellement préférée, la sélec tion du grand réseau ou de la liaison satellite est faite en fonction d'une catégorie de données ou de transmission. Par conséquent, lors de l'étape 268 de la figure 5, la ca tégorie est examinée, et l'un des supports disponibles est sélectionné. A titre d'exemple, des présentations multimé- dias, des sessions de formation, et des catégories de don nées similaires, sont transmises par l'intermédiaire de la liaison satellite, tandis que les transmissions de données plus classiques sont faites par l'intermédiaire du grand réseau. En fonction de la catégorie de transmission, en suite, le support est sélectionné comme indiqué soit dans l'étape 270 soit dans l'étape 276. La transmission est en suite programmée comme indiqué dans l'étape 272 ou dans l'étape 278. Dans le cas de sessions de formation, par exemple, la transmission peut être programmée à une date et une heure ultérieures, lorsque le système de diagnostic désigné doit se trouver dans un emplacement spécifique, dans une pièce de formation ou chez un autre client de l'établissement de diagnostic. Finalement, comme indiqué dans l'étape 274 ou dans l'étape 280, la transmission pro grammée est effectuée par l'intermédiaire du support sé lectionné.
La figure 6 indique un exemple de logique de commande pour recevoir et traiter des transmissions revenant du fournisseur de services à distance à l'établissement de diagnostic. Cette logique de commande, désignée globale ment par le numéro de référence 300, commence avec la ré ception de la transmission de données lors de l'étape 302. Cette réception se fait par l'intermédiaire du système de commande de communication de données, par exemple lors d'une session de transmission de données en cours. Lors de l'étape 304, les données reçues sont analysées pour iden tifier au moins le système de diagnostic désigné ou adres sé. Lors de l'étape 306, les données sont délivrées du système de commande de communication de données au système désigné par l'intermédiaire du réseau interne de l'éta blissement. On notera que l'étape 306 peut comprendre la mémorisation de tout ou partie des données, ou de l'infor mation dérivée ou analysée depuis les données dans les circuits de mémoire du système de commande de communica tion de données, ou dans une autre base de données de l'établissement. Lors de l'étape 308, la réception et l'échange de communications sont enregistrés par le sys tème de commande de communication de données.
Lorsque c'est nécessaire, d'autres procédures pour la réception et le traitement de données peuvent être réali sées, comme indiqué en figure 7. Les autres étapes de ré ception globalement indiquées par le numéro de référence 350 peuvent être souhaitables, par exemple, lors de la ré ception de données numériques par l'intermédiaire de liai sons satellites, les données étant acheminées par l'inter médiaire du système de commande de communication de don nées pour la distribution. En particulier, ces systèmes de communication par satellite, ou d'autres supports alterna tifs, peuvent ne pas nécessiter une communication dans les deux sens. Par conséquent, une partie de l'information destinée à adresser les données peut être transmise en pa rallèle par l'intermédiaire de l'autre support, en parti culier par l'intermédiaire d'un grand réseau. Ainsi, lors de l'étape 352, un programme d'établissement de liaison est exécuté entre le système de commande de communication de données et le fournisseur de services à distance pour assurer une connectivité appropriée et la capacité à échanger l'information nécessaire. Lors de l'étape 354, une procédure d'authentification peut être exécutée pour assurer que la session de transmission avec le support pa- rallèle se conforme à la demande et au programme de trans mission. Lors de l'étape 356, l'adresse du destinataire est identifiée et confirmée, de façon à assurer que le ca nal de transmission soit accordé ou sélectionné de façon appropriée, et que le client ou le système de diagnostic soit identifié à l'intérieur de l'établissement. Lors de l'étape 358, la transmission est reçue et démodulée, fil trée ou traitée d'une autre façon. Comme indiqué lors de l'étape 360, les données reçues par l'intermédiaire du support parallèle peuvent nécessiter un traitement addi tionnel, de façon à mettre en paquets les données pour la transmission sur le réseau interne. Après ce traitement, les données sont distribuées au système désigné. La sé quence de communication et la transmission sont enregis trées comme indiqué lors de l'étape 362.
En plus de l'échange interactif de services et d'au tres données, la présente technique permet l'acquisition de données opérationnelles et de paramètres à partir des systèmes de diagnostic médical qui sont des clients du ré seau interne de l'établissement par l'intermédiaire d'une procédure simplifiée. La figure 8 illustre des exemples d'étapes dans cette procédure, par l'intermédiaire d'une logique de commande désignée globalement par le numéro de référence 400. En général, la procédure permet aux données d'être acquises ou collectées à partir des systèmes de diagnostic mis en réseau par l'intermédiaire du système de commande de communication de données, et d'être transmises du système de commande de communication de données au fournisseur de services à distance. Dans les approches connues jusqu'à présent pour fournir des services à des systèmes de diagnostic médical, ces données étaient acqui ses, de façon caractéristique, par une connexion directe avec un système de diagnostic désiré, ce qui nécessitait la réalisation indépendante d'un grand nombre de con nexions et ce qui imposait des exigences substantielles sur l'infrastructure, aussi bien à l'intérieur de l'éta blissement que chez le fournisseur de services à distance. De plus, lorsque des systèmes de diagnostic n'étaient pas équipés pour une connectivité directe avec le fournisseur de services à distance, on ne pouvait obtenir que peu d'informations, voire aucune information, en particulier directement à partir du système.
Dans la présente approche, l'information peut être ob tenue par l'intermédiaire de plusieurs processus diffé rents, déclenchés aussi bien automatiquement que manuelle ment. Dans l'exemple de logique de la figure 8, le proces sus d'acquisition de données peut commencer avec le dé clenchement d'un programme d'interrogation automatique lors de l'étape 402. Ce programme sera exécuté par le sys tème de commande de communication de données qui rentre en contact avec chaque système mis en réseau, ou avec des systèmes désignés à partir desquels des données sont dési rées, selon un programme horaire préétabli. A titre d'exemple, le programme horaire peut comprendre des acqui sitions de données périodiques au cours d'une période de 24 heures, ou une acquisition moins fréquente. En fonction du programme et du programme horaire, les clients sont contactés lors de l'étape 404 de la figure 8. Lors de l'étape 406, on accède aux données, par exemple par ex traction à partir des circuits de mémoire des systèmes de diagnostic du client. Lors de l'étape 408, les données peuvent être filtrées, par exemple de façon à déterminer si une information complète ou incomplète est acquise, afin d'analyser des données qui ne sont pas désirées, tel les que des données spécifiques au patient, etc. Lors de l'étape 410, les données sont enregistrées, par exemple dans les circuits de mémoire du système de commande de communication de données.
A titre d'alternative au processus d'interrogation dé crit ci-dessus, certaines données peuvent être collectées lors de l'apparition d'un événement spécifique dans le système de diagnostic ou à l'intérieur de l'établissement. Par exemple, lorsque certains des systèmes de l'établisse ment sont mobiles, la connexion du système mobile au ré seau interne peut provoquer l'exécution, par le système de commande de communication de données, du programme d'ac quisition de données pour le système nouvellement connec té. Par conséquent, comme indiqué dans l'étape 412 de la figure 8, le système ou l'appareil spécifique peut changer d'état, par exemple en établissant ou en renouvelant une connexion avec le réseau interne. Lors de l'étape 414, en suite, on accède au système, et l'information désirée est transférée du système au système de commande de communica tion de données. A titre d'exemple, pour permettre le sui vi des appareils, la gestion des appareils, l'analyse de la productivité, et d'autres fonctions, l'emplacement des appareils mobiles peut être identifié et enregistré pour une utilisation ultérieure, ou pour permettre au personnel de l'établissement de suivre les appareils.
Les séquences d'acquisition de données peuvent égale ment être déclenchées par une demande manuelle, comme in diqué dans l'étape 416 en figure 8. La demande manuelle peut être entrée par l'intermédiaire des composants d'in terface d'opérateur du système de commande de communica tion de données, de façon, par exemple, à accéder aux per formances, à l'utilisation, et à d'autres caractéristiques ou paramètres des systèmes mis en réseau et à les affi cher. En réponse à la demande manuelle, on accède au sys tème désigné, comme indiqué dans l'étape 418, et les don nées désirées sont localisées et transmises à partir de la mémoire du dispositif, comme indiqué dans l'é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 dans l'établisse ment de diagnostic, et transmises au fournisseur de servi- ces à distance au cours d'une ou plusieurs sessions de communication de données. Ces sessions peuvent être pro grammées à des heures appropriées, par exemple durant les heures creuses, les heures de nuit, les week-ends, etc. La figure 9 illustre des étapes dans un exemple de logique de commande, désignée globalement par le numéro de référence 450, pour transmettre les données une fois qu'elles sont acquises dans l'établissement.
Si l'on se réfère à la figure 9, le transfert de don nées est tout d'abord programmé, comme indiqué dans l'étape 452. Comme indiqué, cette programmation peut être établie à des heures appropriées, aussi bien pour l'éta blissement de diagnostic que pour le fournisseur de servi ces à distance. Cependant, on notera que ces transferts de données peuvent être déclenchés par une intervention de l'opérateur, comme on le désire. Comme indiqué dans l'étape 454, une connexion est ensuite établie entre l'établissement de diagnostic et le fournisseur de servi ces à distance. La connexion peut être déclenchée soit par l'établissement soit par le fournisseur de services à dis tance, le fournisseur de services à distance étant le dé clencheur préféré dans la présente réalisation. Egalement, lors de l'étape 454, le fournisseur de services à distance provoque le transfert des données, par exemple par l'in termédiaire d'un programme de communication mémorisé tout à la fois dans le système de commande de communication de données et chez le fournisseur de services à distance. En réponse au déclenchement, on accède aux données à partir de la mémoire de l'établissement médical ou du référentiel de données, et elles sont transférées au fournisseur de services à distance comme indiqué dans l'étape 456. Durant ou après le transfert, toute analyse, tout filtrage, et tous autres traitements désirés sont effectués comme indi qué dans l'étape 458. En particulier, les données transfé rées sont de préférence analysées afin d'identifier les systèmes de diagnostic individuels d'où viennent les don nées, et afin de séparer les unes des autres les données opérationnelles et de paramètres pour les systèmes indivi duels. Les données sont ensuite mémorisées, de préférence dans des bases de données relationnelles, pour une extrac tion et une analyse ultérieures. Finalement, lors de l'étape 460, la session de transfert de données est enre gistrée, de préférence tout à la fois dans l'établissement de diagnostic et chez le fournisseur de services à dis tance.
Bien que l'invention puisse être susceptible de subir différentes modifications et d'avoir d'autres formes, des réalisations spécifiques ont été montrées à titre d'exem ple dans les dessins et ont été décrites en détail ici. Toutefois, on comprendra que l'invention ne vise pas à être limitée aux formes particulières représentées. Au contraire, l'invention vise à couvrir toutes les modifica tions, tous les équivalents et toutes les alternatives rentrant à l'intérieur de l'esprit et de l'étendue de l'applicabilité de l'invention telle qu'elle est définie par les revendications jointes qui suivent. REVENDICATIONS 1. Procédé pour acquérir des données de paramètres à partir d'une pluralité de systèmes de diagnostic médical (24 à 38) d'une institution médicale (12), le procédé étant caractérisé en ce qu'il comprend les étapes suivan tes (a) l'exécution d'un programme d'accès aux données (400) pour acquérir des données de paramètres à partir d'une pluralité de systèmes de diagnostic médical (24 à 38) couplés à un réseau interne (20, 22) d'une institution médicale ; (b) la mémorisation des données de paramètres (410) dans un référentiel de données (92) de l'institution médi cale ; (c) l'établissement d'une liaison de données (454) en tre l'institution médicale (12) et un fournisseur de ser vices à distance (14) par l'intermédiaire d'un réseau ex terne (50) ; et (d) la transmission des données de paramètres (456) au fournisseur de services à distance.