Brevet FR2975556A1 — publié le 20121123

Système de restitution à distance de données médicales traitées 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui du domaine médical. Plus précisément, l'invention concerne une technique permettant de restituer des données médicales traitées (le traitement étant réalisé sur une plate-forme informatique) sur un dispositif client situé à distance de ladite plate-forme informatique. 2. ARRIÈRE-PLAN TECHNOLOGIQUE Le partage de données médicales entre des entités éloignées, de manière rapide, est une problématique de plus en plus récurrente. Un premier exemple illustrant cette problématique est celui de l'échange de données médicales entre des hôpitaux. Généralement, les hôpitaux comprennent des serveurs de type PACS (acronyme anglais de « Picture Archiving and Communication System » en anglais) permettant de gérer des données médicales au format DICOM (acronyme anglais de « Digital Imaging and Communications in Medicine »), et ce, grâce notamment à des fonctions d'archivage. Une première technique de transfert de données médicales au format DICOM est utilisée entre ces structures hospitalières via l'utilisation de réseaux dédiés, par exemple de type RNIS (acronyme de « Réseau Numérique à Intégration de Services »). Ainsi, grâce au débit élevé d'une connexion de type RNIS, le téléchargement des données médicales au format DICOM est relativement rapide. Cependant, dans le cas de figure où une liaison reliant des hôpitaux n'est pas une connexion de type RNIS, les délais de transfert peuvent être conséquents, et ce, même si on utilise, en substitut, une deuxième technique de transfert via une connexion de type SDSL (acronyme anglais de « Symmetric Digital Subscriber Line »). Un deuxième exemple illustrant l'importance du partage de données médicales, est celui du télédiagnostic, où un professionnel de la santé (radiologue, cardiologue, etc...), depuis son cabinet, en fonction de données médicales (par exemple des images médicales) obtenues par un dispositif géré par des manipulateurs auprès d'un patient, doit établir un diagnostic à partir de celles-ci, d'où la nécessité d'obtenir rapidement ces données médicales avec la plus grande qualité, pour ne pas éluder des éléments qui potentiellement peuvent avoir une grande incidence sur le diagnostic réalisé. Lorsqu'une donnée médicale est une image médicale (sous forme numérique), celle-ci ayant généralement une résolution (mesurée en nombre de pixels par unité de surface) élevée (i.e avec des images ayant une forte densité en pixels), elle possède une taille importante (de l'ordre de plusieurs dizaines ou centaines de Megaoctets). Ainsi, il est difficile d'obtenir rapidement l'image voulue, et ce, même en utilisant une troisième technique consistant à utiliser une connexion de type ADSL (acronyme anglais de « Asymmetric Digital Subscriber Line »). Une autre contrainte inhérente au partage de données médicales réside dans le fait que recevoir et traiter des données médicales au format DICOM (format très répandu pour stocker des données médicales) implique des exigences au niveau des dispositifs client (généralement des ordinateurs), en particulier sur le système d'affichage desdits dispositifs clients (par exemple des écrans et des cartes graphiques) utilisés (que ce soit dans le premier ou le deuxième exemple). Par exemple, l'utilisation des techniques de visualiations dite MPR (acronyme anglais de « Multi-Planar Reformatting », ou « Multi-Planar Reconstruction ») et MIP (acronyme anglais de « Maximum Intensity Projection ») nécessite d'importantes ressources matérielles informatiques. Plus précisément, les performances du processeur du dispositif client (récepteur) ainsi que la quantité de mémoire vive disponible sur celui-ci doivent être importantes. De plus, la carte graphique de ce dispositif client doit avoir des performances en adéquation avec celles de l'écran utilisé. En outre, un logiciel particulier d'interprétation permettant de réaliser un certain nombre de fonctions (zoom, rotation, mesure de distance et de densité, etc...) et qui est généralement un logiciel propriétaire non compatible avec tout type de systèmes d'exploitations (Linux, Mac, etc...), doit être installé sur le dispositif client pour réaliser les actions désirées. Une autre contrainte réside dans le fait que les dispositifs clients ainsi que les logiciels d'interprétation doivent être certifiés conforme vis-à-vis des critères d'exigence de la directive 93/42/CEE, annexe II point 3 ainsi que vis-à-vis des critères d'exigence de la réglementation américaine approuvés par un tiers 510(k) de la FDA (acronyme anglais de « Food and Drug Administration ») des Etats-Unis. Cette contrainte oblige un éditeur de logiciels à effectuer une certification pour chaque logiciel, ce qui peut s'avérer contraignant (en temps, en moyens financiers, etc...). Enfin, une dernière contrainte d'une telle solution (dispositif client associé à un logiciel d'interprétation) réside dans la difficulté d'adapter celle-ci par rapport à des politiques de sécurité mises en oeuvre notamment dans des hôpitaux. Ainsi, l'utilisation d'un pare-feu, pour filtrer certains ports, peut engendrer des problèmes lors de l'installation et de l'utilisation d'un logiciel d'interprétation. Remarquons que, dans les cas de figures mentionnés précédemment, on duplique les éléments entre les deux entités pour restituer des données médicales (mêmes logiciels installés, etc...) car ce sont les mêmes données médicales qui sont traitées. On connaît, dans l'état de la technique, différents types de solutions permettant d'accélérer la prise de connaissance de ces données médicales, en ne modifiant pas le débit d'une connexion comme mentionné précédemment avec les première, deuxième et troisième techniques (RNIS, SDSL, ADSL). En effet, une quatrième technique, divulguée dans les documents Dl (JP 2000116606), D2 (CN 101350923) et D3 (EP 2237179) consiste à appliquer des techniques de compression sur des données médicales, permettant ainsi un transfert de ces données médicales de manière plus rapide. En effet, la réduction du nombre de pixels transmis, par exemple d'un serveur PACS vers un dispositif client, n'affecte pas toujours la qualité d'affichage d'une image médicale si les caractéristiques d'affichage de l'écran du dispositif client sont prises en considération. Les paragraphes §0091 à §0093 du document D3 mettent en exergue cette caractéristique: une image ayant à l'origine une résolution de 2560 x 1960 pixels peut être redimensionnée en une autre image ayant une résolution de 640 x 480 pixels, et ce, sans perte de qualité si elle est affichée sur l'écran d'un dispositif client qui a une capacité d'affichage maximale de 640 x 480 pixels. Cependant, un inconvénient des techniques divulguées dans les documents Dl et D2 réside dans le fait que la compression doit être sans perte sous peine de supprimer un élément important pour le spécialiste qui consulte par exemple des images médicales. Un inconvénient de la technique divulguée dans le document D3 réside dans le fait que le dispositif client et le serveur PACS doivent, dans une étape préalable, échanger des informations de configuration pour la mise en oeuvre de cette technique. De plus, à chaque fois que la configuration d'un écran d'un dispositif client est modifiée, il est nécessaire de transmettre cette information au serveur PACS pour qu'il puisse reconfigurer ses paramètres avant d'émettre de nouvelles données médicales compressées. Enfin, un inconvénient commun des techniques mentionnées précédemment réside dans le fait que celles-ci nécessitent l'installation de logiciels propriétaires qui utilisent beaucoup de ressources mémoires lorsqu'ils sont exécutés. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique qui fonctionne de manière rapide, même avec une bande passante relativement faible. Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique qui ne nécessite pas d'importantes ressources (en termes de mémoire vive, des caractéristiques de la carte graphique, etc....) au sein d'un dispositif client. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui ne nécessite pas de compresser ou d'appliquer tout autre traitement sur les données médicales susceptibles de dégrader la qualité des données médicales et donc, potentiellement, d'induire un mauvais diagnostic de la part d'un praticien. Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui ne nécessite pas l'installation de logiciels propriétaires de traitement de données médicale, au niveau d'un dispositif client. Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui soit interopérable quel que soit le système d'exploitation et le navigateur web exécutés sur le dispositif client. Un autre objectif d'au moins un mode de réalisation de l'invention est de permettre l'obtention de données médicales lors du changement du matériel client, sans avoir à en informer une plate-forme informatique pouvant être un serveur PACS. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui ne nécessite qu'une seule procédure de certification, selon la directive 93/42/CEE, annexe II point 3. Enfin, un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui ne nécessite que peu, voire aucune adaptation vis-à-vis des politiques de sécurité mises en oeuvre au sein des réseaux utilisés. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un système de restitution de données médicales traitées, ledit système comprenant un dispositif client connecté, via un canal de communication, à une plate-forme informatique obtenant des données médicales initiales, les données médicales traitées étant obtenues par traitement des données médicales initiales. Ce système est remarquable en ce que la plate-forme informatique comprend : - un bloc de réception de commandes provenant du dispositif client ; - un bloc de traitement, permettant de générer les données médicales traitées à partir des données médicales initiales, en fonction des commandes reçues ; - un bloc d'émission des données médicales traitées vers le dispositif client; et en ce que le dispositif client comprend : - un bloc de contrôle à distance du bloc de traitement compris dans la plate-forme informatique, via la transmission desdites commandes ; - un bloc de réception des données médicales traitées, générées par le bloc de traitement compris dans la plate-forme informatique ; - un bloc de restitution des données médicales traitées reçues. Le principe général de l'invention consiste donc à permettre à un utilisateur d'un dispositif client de restituer (c'est-à-dire visionner, interpréter, et/ou entendre) des données médicales traitées via un bloc de contrôle qui est interopérable sur tous les systèmes d'exploitations. Il n'y a donc aucune contrainte sur le système d'exploitation utilisé par le dispositif client. Cette technique permet donc une totale liberté de choix du système d'exploitation exécuté par le dispositif client, contrairement aux techniques de l'art antérieur. Ainsi, ce mode de réalisation particulier de l'invention ne nécessite pas l'installation de logiciels propriétaires utilisant d'importantes ressources matérielles sur le dispositif client. De plus, dans un autre mode de réalisation de l'invention, aucune contrainte (sur les performances) sur le dispositif client n'est imposée : n'importe quel dispositif (par exemple un PC du marché, un iphone, etc...) peut être utilisé pour restituer des donnés médicales traitées contrairement aux solutions de l'état de la technique. De plus, dans un autre mode de réalisation de l'invention, quand bien même la bande passante de la connexion reliant le dispositif client à la plate-forme informatique est relativement faible, un utilisateur du dispositif client peut visualiser et traiter des données médicales, chose qu'il n'aurait pas pu réaliser avec les techniques de l'art antérieur. Enfin, cette technique ne nécessite pas d'utiliser des techniques de compression susceptibles d'altérer la qualité des données médicales. Selon un aspect particulier de l'invention, un tel système de restitution de données médicales traitées est remarquable en ce que le bloc de contrôle à distance comprend un module logiciel qui s'exécute dans la fenêtre d'un navigateur web. Ainsi, grâce à la combinaison du bloc de contrôle et du navigateur web, on peut appliquer cette technique sur chacun des systèmes d'exploitation compris dans la liste, non exhaustive, suivante (et ce quelque soit la version utilisée, y compris des versions antérieures à celles disponibles sur le marché) : - Microsoft Windows ; - Linux ; - Mac OS ; -Android. Selon une caractéristique particulière, un tel système de restitution de données médicales traitées est remarquable en ce que le module logiciel comprend une applet Java ou un module Active X. Ainsi, lorsqu'une machine virtuelle Java est présente sur le dispositif client, ou que des moyens d'exécution de contrôles ActiveX, ou plus généralement une technologie d'exécution de composants, sont présents sur le dispositif client, il est alors possible d'exécuter, via un navigateur web, un module logiciel compatible avec les technologies susmentionnées. Selon une caractéristique particulière, un tel système de restitution de données médicales traitées est remarquable en ce que les données médicales initiales comprennent des données d'imagerie médicale. Selon une caractéristique particulière, un tel système de restitution de données médicales traitées est remarquable en ce que lesdites données médicales initiales sont conformes au standard DICOM. Selon une caractéristique particulière, un tel système de restitution de données médicales traitées est remarquable en ce que les données médicales initiales appartiennent au groupe comprenant : - des données de suivi de radiothérapie ; - des données radiologiques ; - des données obtenues via un examen de médecine nucléaire ; - des données anatomopathologiques ; -des données électrophysiologiques (ECG, EEG, MEG,...) et - des données textuelles relatives à un patient. Par exemple, les données textuelles relatives à un patient peuvent être des comptes-rendus médicaux, des quantités de médicaments utilisés pour un traitement, ou tout autre type d'informations liées au suivi médical d'un patient. Selon une caractéristique particulière, un tel système de restitution de données médicales traitées est remarquable en ce que la plate-forme informatique est de type PACS. Selon une caractéristique particulière, un tel système de restitution de données médicales traitées est remarquable en ce que le bloc de contrôle à distance comprend un client selon le protocole RDP et en ce que le bloc de traitement comprend un serveur selon le protocole RDP. Selon une caractéristique particulière, un tel système de restitution de données médicales traitées est remarquable en ce que la plate-forme informatique et le dispositif client comprennent chacun un bloc de chiffrement et un bloc de déchiffrement pour sécuriser le canal de communication. Dans un autre mode de réalisation de l'invention, il est proposé un procédé de restitution de données médicales traitées, sur un dispositif client connecté, via un canal de communication, à une plate-forme informatique obtenant des données médicales initiales, les données médicales traitées étant obtenues par traitement des données médicales initiales. Ce procédé est remarquable en ce qu'il comprend les étapes suivantes : - émission de commandes via un bloc de contrôle à distance compris dans le dispositif client ; - réception des commandes par un bloc de réception de commandes compris dans la plate-forme informatique ; - traitement des commandes reçues et génération de données médicales traitées à partir des données médicales initiales en fonction des commandes reçues; - émission des données médicales traitées vers le dispositif client par un bloc d'émission; - restitution des données médicales traitées reçues au niveau du dispositif client via le bloc de contrôle à distance et un bloc de restitution. Selon une caractéristique particulière, le procédé est remarquable en ce qu'il comprend une étape préalable d'obtention d'un module logiciel par le dispositif client. Selon une caractéristique particulière, le procédé est remarquable en ce qu'il comprend, suite à l'étape d'obtention et avant l'étape d'émission, une étape d'exécution du module logiciel dans la fenêtre d'un navigateur web, compris dans le bloc de contrôle. Selon une caractéristique particulière, le procédé est remarquable en ce qu'il comprend en outre une étape d'exécution d'un client RDP au niveau du dispositif client et une étape d'exécution d'un serveur RDP au niveau de la plate-forme informatique. Dans un autre mode de réalisation de l'invention, il est proposé un produit programme d'ordinateur qui comprend des instructions de code de programme pour la mise en oeuvre du procédé précité (dans l'un quelconque de ses différents modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation de l'invention, il est proposé un médium de stockage lisible par ordinateur, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé précité (dans l'un quelconque de ses différents modes de réalisation). Dans un autre mode de réalisation, l'invention concerne un dispositif client compris dans un système de restitution de données médicales traitées, connecté, via un canal de communication, à une plate-forme informatique obtenant des données médicales initiales, les données médicales traitées étant obtenues par traitement des données médicales initiales. Un tel dispositif est remarquable en ce qu'il comprend : - des moyens de contrôle à distance de moyens de traitement compris dans la plate-forme informatique, via la transmission des commandes ; - des moyens de réception des données médicales traitées, générées par les moyens de traitement compris dans la plate-forme informatique ; - des moyens de restitution des données médicales traitées reçues. Dans un autre mode de réalisation, l'invention concerne une plate-forme informatique comprise dans un système de restitution de données médicales traitées, le système comprenant un dispositif client connecté, via un canal de communication, à la plate-forme informatique obtenant des données médicales initiales, les données médicales traitées étant obtenues par traitement des données médicales initiales. Une telle plate-forme informatique est remarquable en ce qu'elle comprend : - des moyens de réception de commandes provenant du dispositif client; - des moyens de traitement, permettant de générer les données médicales traitées à partir des données médicales initiales, en fonction des commandes reçues ; - des moyens d'émission des données médicales traitées vers le dispositif client. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : - la figure 1 présente un synoptique d'un mode de réalisation particulier du système selon un mode de réalisation de l'invention ; - la figure 2 présente la structure d'un dispositif client selon un mode de réalisation particulier de l'invention ; - la figure 3 présente la structure d'une plate-forme informatique selon un mode de réalisation particulier de l'invention ; - la figure 4 présente un organigramme d'un mode de réalisation particulier du procédé de restitution de données médicales traitées sur un dispositif client ; - la figure 5 présente la structure simplifiée d'un dispositif client selon l'invention. 6. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence numérique. Dans un mode de réalisation particulier de l'invention, il est proposé une technique permettant de s'affranchir des problèmes liés à la non-interopérabilité des techniques de l'art antérieur. La figure 1 présente un synoptique d'un mode de réalisation particulier du système selon un mode de réalisation de l'invention. Le système 100 de restitution de données médicales traitées comprend une plate-forme informatique 101 comprenant un bloc de traitement 102 via l'intermédiaire duquel des traitements (zoom, rotation, application des techniques MPR et/ou MIP, etc...) sur des données médicales initiales 105, qui sont stockées dans une mémoire 107 de la plate-forme informatique 101 et/ou dans un dispositif 106 de stockage particulier de type base de données (« datawarehouse » en anglais), à partir de commandes de contrôle en provenance d'un dispositif client 109 via l'utilisation d'un canal de communication 108. Ces commandes de contrôle sont réceptionnées par la plate-forme informatique 101 grâce à un bloc de réception 103, et les données médicales traitées sont émises vers le dispositif client grâce à l'emploi d'un bloc d'émission 104 de données médicales traitées. Les données médicales traitées sont réceptionnées au niveau du dispositif client 109 par un bloc de réception 111 qui redirige celles-ci vers le bloc de contrôle à distance 110. Dans un mode de réalisation particulier, les données médicales initiales sont des images médicales stockées au format DICOM, ou encore des données graphiques ou textuelles (relatives par exemple à des comptes-rendus médicaux), et les données médicales traitées peuvent par exemple consister en des données graphiques prêtes à être affichées sur un écran. Remarquons que c'est le bloc de contrôle à distance 110 qui génère les commandes de contrôle qui sont envoyées à la plateforme informatique 101. Enfin, la combinaison du bloc de contrôle à distance 110 et du bloc de restitution 112 permet de restituer à l'identique des images ou sons qu'un utilisateur pourrait voir via un écran connecté à la plate-forme informatique 101. Ainsi, ce sont par exemple des données graphiques exploitables par un périphérique d'affichage, et non la transmission des images au format DICOM qui transitent via le canal de communication 108. Dans un mode de réalisation préférentiel, le canal de communication est sécurisé via l'établissement d'un tunnel SSL (acronyme anglais de « Secure Socket Layer »). Dans un mode de réalisation préférentiel, le canal de communication permet de réaliser une connexion de type RDP (acronyme anglais de « Remote Desktop Protocol ») entre la plate-forme informatique 101 et le dispositif client 109. Dans un mode de réalisation préférentiel, le bloc de contrôle à distance 110 comprend un module (ou composant) ActiveX ou une applet Java permettant, via l'utilisation d'un navigateur web et d'un bloc de restitution 112, de restituer (dans ce mode, afficher) les données graphiques reçues. Ainsi, la combinaison du système SSL avec le protocole HTTP, permet une compatibilité avec les politiques sécuritaires mises en oeuvre dans les réseaux locaux dans lesquels se trouvent la plate-forme informatique 101 et le dispositif client 109, du fait de l'utilisation du port 443, qui n'est généralement pas bloqué par un pare-feu dans le contexte d'application de la présente invention. Remarquons enfin que le bloc de contrôle à distance 110 ne nécessite que peu de ressources mémoires et est interopérable sur tous les systèmes d'exploitations. La figure 2 présente la structure d'un dispositif client selon un mode de réalisation particulier de l'invention. Dans un mode de réalisation particulier, le bloc de contrôle à distance 110 comprend un module logiciel (qui est par exemple un module ActiveX ou une applet Java) 202, et lorsque celui-ci activé (i.e exécuté), il peut lancer l'exécution d'un client RDP 203 intégré, dans un mode de réalisation, au système d'exploitation en cours d'exécution sur le dispositif client 109. Ainsi, dans un mode de réalisation, le bloc de contrôle à distance 110 comprend le module logiciel 202 et un client RDP 203. Si aucun client RDP n'est présent au sein du dispositif, le module logiciel 202 lance le téléchargement d'un tel client. Généralement, le système d'exploitation Microsoft Windows comprend, par défaut, un tel client RDP. Lorsque le système d'exploitation est du type Linux, Mac OS ou autre, un tel téléchargement est généralement réalisé. Lorsque aucun client RDP lié à un système d'exploitation ne peut être obtenu, un client RDP Java peut être exécuté (cependant, les performances sont alors dégradées). Un tel client RDP Java peut-être intégré par défaut dans le module logiciel 202. Dans un mode de réalisation particulier, lorsque le client RDP est lancé, le module logiciel 202 transmet les paramètres suivants au client RDP qui sont nécessaires pour établir la connexion avec la plate-forme informatique 101 : - adresse IP ou nom de la plate-forme informatique 101 ; - nom du domaine, nom d'utilisateur et mot de passe pour la connexion avec la plate-forme informatique 101 ; - Application à exécuter au démarrage ; - Paramètres à transmettre à l'application à exécuter au démarrage ; - Taille de la fenêtre ; - Affichage en plein écran ; - Nombre de couleurs affichées ; - Redirection des imprimantes, lecteurs locaux, presse papier, redirection audio, périphériques USB ou autres ; - Cache des images. Le module logiciel 202 constitue l'équivalent d'une passerelle pour le client RDP 203. Le module logiciel 202 est obtenu suite à l'exécution d'une étape d'obtention consistant à se connecter à une plate-forme informatique (pouvant être différent de la plate-forme informatique 101) via un navigateur web 201 et à transmettre des paramètres liés au dispositif client. Ainsi, le choix de la transmission et de l'exécution du module ActiveX ou de l'applet Java (i.e le module logiciel 202) est effectué en fonction du résultat d'une étape de vérification des paramètres liés au dispositif client. Le module logiciel 202, une fois obtenu, peut être mis en cache par le navigateur web 201 afin d'accélérer les consultations futures. Remarquons que le module 202 est considéré comme étant sûr (i.e en étant signée numériquement par une autorité de confiance), et de fait aucun mécanisme de 30 type « sandbox » n'est utilisé dans le mode de réalisation préférentiel. Ainsi, la plate-forme informatique par lequel le dispositif client 109 obtient le module logiciel 202 et la plate-forme informatique 101 comprenant le bloc de traitement 102 peuvent être distincts. Dans un mode de réalisation préférentiel, dans lequel le bloc de restitution 112 est un écran ou un dispositif d'affichage, le navigateur web 201 constitue l'interface avec le bloc de contrôle à distance 110 permettant à un utilisateur de visualiser des données médicales traitées, et de choisir des commandes de contrôle à envoyer à destination du bloc de traitement 102 compris dans la plate-forme informatique 101. Dans un autre mode de réalisation, le bloc de contrôle comprend des interfaces permettant à un utilisateur d'interagir directement, via le bloc de restitution, avec les autres éléments compris dans le bloc de contrôle. Dans un autre mode de réalisation, les données (commandes et/ou données médicales traitées) entrantes et sortantes du bloc de contrôle à distance 110 sont respectivement déchiffrées et chiffrées par un bloc de chiffrement et un bloc de déchiffrement compris dans le dispositif client. Dans un mode de réalisation, La figure 3 présente la structure d'une plate-forme informatique selon un mode de réalisation particulier de l'invention. Dans un mode de réalisation préférentiel, le bloc de traitement 102 compris dans la plate-forme informatique 101 comprend un bloc de déchiffrement et de chiffrement 301 appelé module « Tunnel » permettant de traiter des données chiffrées (de par l'utilisation du protocole SSL), véhiculant des commandes de contrôle de restitution et/ou de traitement à effectuer sur les données médicales initiales 105, en provenance d'un dispositif client via le canal de communication 108. Le bloc de déchiffrement et de chiffrement 301 permet de déchiffrer les données chiffrées, puis, redirige les données déchiffrées vers un bloc de répartition 302. Le bloc de répartition 302 permet de rediriger les données déchiffrées vers au moins un module dit module « Terminal Server» 303 compris dans le bloc de traitement 102. Dans un mode de réalisation, lorsqu'une technique de virtualisation est mise en oeuvre dans la plate-forme informatique 101, le bloc de répartition 302 peut rediriger les commandes en provenance du module de déchiffrement et de chiffrement 301, parmi une pluralité de modules du type « Terminal Server» 303, en fonction de la charge de ces différents modules. Ainsi, il est effectué un équilibrage des charges au niveau de ces modules. Le module « Terminal Server» 303 est un composant de Microsoft Windows permettant l'accès et l'utilisation d'applications présentes sur la plate-forme informatique 101. Notamment dans un mode de réalisation particulier, le module « Terminal Server» 303 permet l'accès ainsi que l'utilisation des modules 304 qui sont des applications permettant de traiter des données médicales initiales 105 en fonction des commandes reçues. Les données médicales traitées qui sont obtenues via l'un des modules 304 sont ensuite transmises à un des modules « Terminal Server» 303 avec lequel il est en interaction. Le module « Terminal Server» 303 redirige les données médicales traitées vers le bloc de déchiffrement et de chiffrement 301 qui chiffre celles-ci. Les données médicales traitées chiffrées sont ensuite transmises vers un bloc d'émission 104 qui redirige celles-ci vers le dispositif client 109, via le canal de communication 108. La figure 4 présente un organigramme d'un mode de réalisation particulier du procédé de restitution de données médicales traitées sur un dispositif client. Dans ce mode de réalisation, on considère que le dispositif client 109 et la plate-forme informatique 101 n'ont jamais effectué de communication entre eux. Dans l'étape 401, un utilisateur d'un dispositif client 109 lance un navigateur web 201 quelconque installé sur le dispositif 109, et se connecte à une première plate-forme informatique via une connexion HTTP classique sur lequel un site web propose un service de restitution d'images médicales. Dans l'étape 402, suite à une inscription sur ce site et à une validation, par la plate-forme informatique des informations transmises, un module logiciel (un module ActiveX ou une applet Java) 202 est téléchargé puis exécuté par le navigateur web 201. Le module logiciel 202 télécharge ensuite, si nécessaire, un client RDP. Ainsi, à la fin de cette étape, le dispositif client dispose d'un module logiciel 202 et d'un client RDP 203. Dans l'étape 403, le module logiciel 202 initie une connexion de type SSL entre le dispositif client 109 et une plate-forme informatique 101. Dans l'étape 404, le module logiciel 202 initie une connexion de type RDP via le client RDP 203 avec la plate-forme informatique 101. Dans l'étape 405, le module logiciel 202 restitue (ou affiche) via le navigateur 201 et le bloc de restitution 112, les données médicales traitées obtenues grâce au bloc de traitement 102. La figure 5 présente la structure simplifiée d'un dispositif client 109 selon l'invention (par exemple le mode de réalisation particulier décrit ci-dessus en relation avec la figure 1). Ce dispositif comprend une mémoire RAM 503, une unité de traitement 501, équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur stocké dans une mémoire ROM 502. À l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire RAM 503 avant d'être exécutées par le processeur de l'unité de traitement 501. Cette figure 5 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser les différentes étapes détaillés ci-dessus, en relation avec la figure 4. En effet, la technique de l'invention se réalise indifféremment : - sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou - sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). Dans le cas où l'invention est implantée sur une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. REVENDICATIONS1. Système de restitution de données médicales traitées, ledit système comprenant un dispositif client (109) connecté, via un canal de communication (108), à une plate-forme informatique (101) obtenant des données médicales initiales (105), les données médicales traitées étant obtenues par traitement des données médicales initiales, caractérisé en ce que ladite plate-forme informatique (101) comprend : - un bloc de réception de commandes (103) provenant dudit dispositif client (109); - un bloc de traitement (102), permettant de générer les données médicales traitées à partir des données médicales initiales (105), en fonction des commandes reçues ; - un bloc d'émission (104) des données médicales traitées vers le dispositif client (109) ; et en ce que le dispositif client (109) comprend : - un bloc de contrôle à distance (110) du bloc de traitement (102) compris dans la plate-forme informatique, via la transmission desdites commandes ; - un bloc de réception (111) des données médicales traitées, générées par le bloc de traitement (102) compris dans la plate-forme informatique ; - un bloc de restitution (112) des données médicales traitées reçues. 2. Système de restitution de données médicales traitées selon la revendication 1, 20 caractérisé en ce que ledit bloc de contrôle à distance (110) comprend un module logiciel (202) qui s'exécute dans la fenêtre d'un navigateur web (201). 3. Système de restitution de données médicales traitées selon la revendication 2, caractérisé en ce que ledit module logiciel (202) comprend une applet Java ou un module Active X. 25 4. Système de restitution de données médicales traitées selon l'une quelconque des revendications 1 à 3, caractérisé en ce que lesdites données médicales initiales (105) comprennent des données d'imagerie médicale. 5. Système de restitution de données médicales traitées selon l'une quelconque des revendications 1 à 4, caractérisé en ce que lesdites données médicales initiales (105) sont 30 conformes au standard DICOM. 15 6. Système de restitution de données médicales traitées selon l'une quelconque des revendications 1 à 5, caractérisé en ce que lesdites données médicales initiales (105) appartiennent au groupe comprenant : - des données de suivi de radiothérapie ; - des données radiologiques ; - des données obtenues via un examen de médecine nucléaire ; - des données anatomopathologiques ; -des données électrophysiologiques (ECG, EEG, MEG,...) et - des données textuelles relatives à un patient. 7. Système de restitution de données médicales traitées selon l'une quelconque des revendications 1 à 6, caractérisé en ce que la plate-forme informatique (101) est de type PACS. 8. Système de restitution de données médicales traitées selon l'une quelconque des revendications 1 à 7, caractérisé en ce que ledit bloc de contrôle à distance (110) comprend un client selon le protocole RDP (203) et en ce que ledit bloc de traitement (102) comprend un serveur selon le protocole RDP (303). 9. Système de restitution de données médicales traitées selon l'une quelconque des revendications 1 à 8, caractérisé en ce que ladite plate-forme informatique (101) et ledit dispositif client (109) comprennent chacun un bloc de chiffrement et un bloc de déchiffrement (301) pour sécuriser ledit canal de communication. 10. Procédé de restitution de données médicales traitées, sur un dispositif client connecté, via un canal de communication, à une plate-forme informatique obtenant des données médicales initiales, les données médicales traitées étant obtenues par traitement des données médicales initiales, caractérisé en ce qu'il comprend les étapes suivantes : - émission de commandes via un bloc de contrôle à distance (110) compris dans ledit dispositif client; - réception desdites commandes par un bloc de réception (103) de commandes compris dans ladite plate-forme informatique (101) ; - traitement (302) desdites commandes reçues et génération (303, 304) desdites données médicales traitées à partir des données médicales initiales (105) en fonction desdites commandes reçues; - émission (104) desdites données médicales traitées vers le dispositif client par un bloc d'émission;- restitution desdites données médicales traitées reçues au niveau du dispositif client via le bloc de contrôle à distance et un bloc de restitution. 11. Procédé selon la revendication 10 caractérisé en ce qu'il comprend une étape préalable d'obtention d'un module logiciel par le dispositif client. 12. Procédé selon la revendication 11 caractérisé en ce qu'il comprend, suite à l'étape d'obtention et avant l'étape d'émission, une étape d'exécution dudit module logiciel (202) dans la fenêtre d'un navigateur web (201), compris dans ledit bloc de contrôle (110). 13. Procédé selon la revendication 12 caractérisé en ce qu'il comprend en outre une étape d'exécution d'un client RDP au niveau du dispositif client et une étape d'exécution d'un serveur RDP au niveau de ladite plate-forme informatique (101). 14. Produit programme d'ordinateur, comprenant des instructions de code de programme pour la mise en oeuvre du procédé selon l'une quelconque des revendications 10 à 13, lorsque ledit programme est exécuté sur un ordinateur. 15. Médium de stockage lisible par ordinateur, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur ou un processeur pour mettre en oeuvre le procédé selon l'une quelconque des revendications 10 à 13. 16. Dispositif client compris dans un système de restitution de données médicales traitées, connecté, via un canal de communication (108), à une plate-forme informatique (101) obtenant des données médicales initiales (105), les données médicales traitées étant obtenues par traitement des données médicales initiales, caractérisé en ce que le dispositif client (109) comprend : - des moyens de contrôle à distance (110) de moyens de traitement (102) compris dans la plate-forme informatique , via la transmission desdites commandes ; - des moyens de réception (111) des données médicales traitées, générées par les moyens de traitement (102) compris dans la plate-forme informatique ; - des moyens de restitution (112) des données médicales traitées reçues. 17. Plate-forme informatique comprise dans un système de restitution de données médicales traitées, ledit système comprenant un dispositif client (109) connecté, via un canal de communication (108), à ladite plate-forme informatique (101) obtenant des 5 10données médicales initiales (105), les données médicales traitées étant obtenues par traitement des données médicales initiales, caractérisé en ce que ladite plate-forme informatique (101) comprend : - des moyens de réception (103) de commandes provenant dudit dispositif client (109); - des moyens de traitement (102), permettant de générer les données médicales traitées à partir des données médicales initiales, en fonction des commandes reçues ; - des moyens d'émission (104) des données médicales traitées vers le dispositif client.