PROCEDE ET SYSTEME POUR COLLECTER ET DIFFUSER LES DONNEES PROVENANT DES APPAREILS MÉDICAUX, NOTAMMENT UTILISÉS DANS LES
UNITÉS DE SOINS INTENSIFS
La présente invention concerne un nouveau procédé et un nouveau système pour collecter les données provenant d'appareils émetteurs produisant lesdites données et pour les diffuser vers des utilisateurs. Chaque utilisateur dispose au moins d'un équipement informatique, notamment un microordinateur personnel, connecté à un écran de visualisation et/ou à une imprimante et/ou à un haut parleur. Chaque équipement informatique est associé à un logiciel d'analyse de données.
Plus particulièrement, l'invention concerne un nouveau procédé et un nouveau système pour collecter les données provenant des appareils médicaux, notamment provenant des appareils médicaux utilisés dans les unités de soins intensifs, et pour diffuser lesdites données vers les praticiens de la santé. Chaque praticien de la santé dispose au moins d'un équipement informatique, notamment un micro ordinateur personnel, connecté à un écran de visualisation et/ou à une imprimante et/ou à un haut parleur. Ledit équipement informatique est associé à un logiciel d'analyse clinique.
Les appareils médicaux sont couramment utilisés dans les unités de soins intensifs : moniteurs cardiaques,
ventilateurs, pompes d'infusion, etc. La plupart des appareils disponibles sur le marché aujourd'hui disposent d'un port de communication, généralement rs232. Ils permettent donc de diffuser tout ou partie des données collectées à des logiciels d'analyse clinique. Ces logiciels utilisent les données collectées par les appareils médicaux pour de multiples applications, par exemple pour l'étude de la réaction du patient à un traitement, ou pour un changement de prescription. Il s'agit clairement d'informations précieuses pour toute la communauté médicale, du médecin et des infirmiers en passant par l'administration hospitalière, les sociétés pharmaceutiques et les responsables de la santé au plan national.
Or, un problème fondamental doit être résolu si l'on veut récupérer les données collectées par les appareils médi- eaux. En effet, il n'existe pas de protocole de communication commun entre les appareils et les ordinateurs. En utilisant une analogie simple, chaque appareil médical parle un langage qui lui est spécifique. Chaque logiciel doit donc parler et comprendre une multitude de langages. II existe essentiellement deux solutions pour résoudre ce problème.
La première solution consiste à connecter chaque appareil médical à une boite noire qui lui est spécifique et qui est conçue pour traduire les messages reçus dans un langage commun susceptible d'être compris par les logiciels cliniques. A titre d'exemple, on peut citer, Device Link de la société HP ou Octanet de la société Marquette-Hellige.
La seconde solution consiste à développer pour chaque logiciel d'analyse clinique un programme spécifique à chaque appareil médical. A titre d'exemple, on peut citer la solution clink n link de la société Picis et CareVue de la société HP.
Dans un cas comme dans l'autre, la diversité des appareils et des logiciels développés oblige les concepteurs de boites noires et/ou les développeurs de logiciels cliniques à modifier sans cesse leurs produits sans pour autant satisfaire
les besoins des utilisateurs déjà équipés. Les solutions décrites dans les documents EASTMAN KODAK (WO 99 41691 A) du 19 août 1999, WOOD ET AL (US 5 715 823) du 10 février 1998, KLEINHOLZ ET AL (XP002083080) de juin 1996, HASKIN MARVIN E (US 4 764 870 A) du 16 août 1998 et PINSKY ET AL (US 5 513 101 A) du 30 avril 1996 présentent les mêmes inconvénients.
Certes, il y a bien eu des tentatives de standardisation des messages en sortie des appareils. A ce jour ces tentatives n'ont pas abouti. Ainsi par exemple, il a fallu plusieurs années pour produire une première esquisse de standardisation des informations issues de pompes d'infusion, un des appareils les plus simples du marché.
Le procédé selon 1 ' invention pour résoudre ce problème est un procédé pour collecter les données provenant d'appareils émetteurs, notamment provenant d'appareils médicaux tels que ceux utilisés dans les unités de soins intensifs. Ce procédé est également conçu pour diffuser lesdites données vers des utilisateurs, notamment vers des praticiens de la santé. Chaque utilisateur dispose au moins d'un équipement informatique, notamment un micro ordinateur personnel, connecté à un écran de visualisation et/ou à une imprimante et/ou à un haut parleur. Cet équipement informatique est associé à un logiciel d'analyse de données, notamment un logiciel d'analyse clinique. Les données sont fournies par les équipements émetteurs selon des formats spécifiques différents selon les types d'équipements émetteurs .
Le procédé selon 1 ' invention comprend les étapes suivantes :
- l'étape de collecter les données provenant des équipements émetteurs,
- l'étape de traduire les données selon un format commun,
- l'étape de diffuser les données selon le format commun vers les équipements informatiques des utilisateurs concernés .
- l'étape de convertir, avant ou après diffusion, les données selon le format commun en des données formatées compatibles avec chaque équipement informatique et/ou son logiciel d'analyse de données. Ainsi, l'utilisateur peut disposer des données émises par un appareil émetteur, même si elles sont formatées selon d'autres standards que ceux de son équipement informatique et du logiciel d'analyse de données associé.
Avantageusement, le procédé selon l'invention comporte en outre les étapes suivantes :
- l'étape de configurer la collecte des données, au moyen de données de configuration-collecte, en fonction du format des données provenant des appareils émetteurs,
- l'étape d'enregistrer lesdites données de configu- ration-collecte.
Avantageusement, le procédé selon l'invention comporte en outre 1 'étape de stocker les données traduites sous un format commun.
Avantageusement, on configure l'émission ou la réception des données traduites sous un format commun au moyen de données de configuration-équipement-informatique, en fonction des spécificités des équipements informatiques et/ou des logiciels d'analyse de données. Avantageusement également, on enregistre lesdites données de configuration-équipement- informatique .
La présente invention concerne aussi un système pour résoudre le problème posé. Ce système est conçu pour collecter des données produites par des appareils émetteurs, notamment des données médicales provenant d'appareils médicaux par exemple situés dans des unités de soins intensifs. Ce système est également conçu pour diffuser lesdites données vers des utilisateurs, notamment vers des praticiens de la santé.
Le système selon 1 ' invention comprend au moins un dispositif de traitement de données. Le dispositif de traitement de données comporte des moyens de réception, notamment un module
logiciel de réception, pour recevoir les données provenant des appareils émetteurs. Le dispositif de traitement de données comporte aussi des moyens de traitement de données, notamment un module logiciel de traitement de données, pour traduire les données reçues sous un format commun. Le dispositif de traitement de données comporte aussi des moyens d'émission de données, notamment un module logiciel d'émission de données, pour diffuser les données selon le format commun vers les utilisateurs . Le système selon l'invention est tel que l'utilisateur dispose d'un équipement informatique. Cet équipement informatique peut être notamment constitué par un micro ordinateur personnel, connecté à un écran de visualisation et/ou à une imprimante et/ou à un haut parleur. Chaque équipement informatique comporte : o des moyens de réception des données émises par ledit dispositif de traitement de données, o un logiciel d'analyse de données.
Pour convertir les données selon le format commun en des données formatées compatibles avec l'équipement informatique et/ou les autres modules dudit logiciel d'analyse de données : o selon une première variante de réalisation, le logiciel d'analyse de données de l'équipement informatique comporte un module de conversion, o selon une autre variante de réalisation, le dispositif de traitement de données comporte en outre des moyens de conversion, notamment un module logiciel de conversion.
Ces moyens de conversion permettent de convertir les données selon le format commun en des données formatées compatibles avec l'équipement informatique et/ou son logiciel d'analyse de données.
De préférence, selon une première variante de réalisation, ledit dispositif de traitement de données est intégré dans ledit équipement informatique. Il s'applique à tous
les logiciels d'analyse clinique susceptibles d'être utilisés en combinaison avec lui.
De préférence, selon une autre variante de réalisation, les moyens de réception dudit équipement informatique sont interconnectés aux moyens d'émission dudit dispositif de traitement de données via un réseau de communication informatique, notamment de type Internet.
Avantageusement, le dispositif de traitement de données comporte une interface de configuration-réception, notamment un module de configuration-réception, permettant d'entrer les données de configuration des moyens de réception en fonction du format des données provenant des appareils émetteurs. Le dispositif de traitement de données comporte en outre un registre contenant lesdites données de configuration des moyens de réception.
Avantageusement également, le dispositif de traitement de données comporte des moyens de stockage pour stocker les données traduites sous un format commun.
Avantageusement, le logiciel d'analyse de données de l'équipement informatique comporte un module de configurâtion- réception permettant d'entrer les données de configuration des moyens de réception en fonction des spécificités des équipements informatiques et/ou des autres modules du logiciel d'analyse de données. Le logiciel d'analyse de données comporte également un module d'enregistrement contenant lesdites données de configuration-réception des moyens de réception. Ainsi, les utilisateurs peuvent disposer des données émises par un appareil émetteur distant, même si elles sont formatées selon d'autres standards que ceux de leur équipement informatique et du logiciel d'analyse de données qu'ils utilisent.
Avantageusement, dans une autre variante de réalisation, le dispositif de traitement de données comporte une interface de configuration-émission, notamment un module de configuration-émission. Cette interface permet d'entrer les données de configuration des moyens d'émission en fonction des
spécificités des équipements informatiques et du logiciel d'analyse de données auxquels elles sont destinées. Le dispositif de traitement de données comporte également un registre contenant lesdites données de configuration des moyens d'émission. Ainsi également, dans le cas de cette variante de réalisation, les utilisateurs peuvent disposer des données émises par un appareil émetteur distant, même si elles sont formatées selon d'autres standards que ceux de leur équipement informatique et du logiciel d'analyse de données qu'ils utilisent.
D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description de variantes de réalisation de l'invention, données à titre d'exemple indicatif et non limitatif, et de : - la figure 1 qui représente de manière schématique une variante de réalisation du système selon l'invention,
- la figure 2 qui représente de manière schématique sous forme de blocs diagrammes les six modules composant une variante de réalisation du logiciel permettant de mettre en oeuvre l'invention.
On va maintenant décrire de manière schématique une variante de réalisation du système selon 1 ' invention dans le cas où les appareils émetteurs sont des appareils médicaux.
Le système est conçu pour collecter des données médicales provenant d'appareils médicaux 1. Ces appareils médicaux sont par exemple situés dans des unités de soins intensifs 2. Le système est également conçu pour diffuser lesdites données vers des praticiens de la santé 3.
Le système comprend au moins un dispositif de traitement de données 4. Ce dispositif de traitement de données 4 comporte des moyens de réception 4a, notamment un module logiciel de réception 4a ' , pour recevoir les données provenant 7 des appareils émetteurs 1. Ce dispositif de traitement de données 4 comporte des moyens de traitement de données 4b, notamment un module logiciel de traitement de données 4b', pour
traduire les données reçues sous un format commun. Le dispositif de traitement de données 4 comporte également des moyens d'émission de données 4c, notamment un module logiciel d'émission de données 4c', pour diffuser les données selon le format commun vers les utilisateurs 3. Les modules logiciels 4a', 4b' et 4c' sont symbolisés sur la figure 1 par des lignes d'instruction machine. L'utilisateur 3 dispose d'un équipement informatique 5, notamment un micro ordinateur personnel, connecté à un écran de visualisation 5a. Il peut comporter aussi une imprimante 5b et/ou un haut parleur 5c. Chaque équipement informatique 5 comporte des moyens de réception 5d des données émises par ledit dispositif de traitement de données 4, un logiciel d'analyse de données 5e, symbolisé sur la figure 1 par des lignes d'instruction machine. Dans le cas de certaines variantes de réalisation, non représentées sur la figure 1, ledit dispositif de traitement de données 4 peut être intégré dans l'équipement informatique 5.
Dans le cas de la variante de réalisation représentée sur la figure 1, les moyens de réception 5d dudit équipement informatique 5 sont interconnectés au moyen d'émission 4c dudit dispositif de traitement de données 4 via un réseau de communication informatique 6, notamment de type Internet.
Le logiciel d'analyse de données 5e de l'équipement informatique 5 comporte un module de conversion 5f pour convertir les données selon le format commun en des données formatées compatibles avec l'équipement informatique 5 et/ou les autres modules 5g dudit logiciel d'analyse de données.
Dans d'autres variantes de réalisation, le dispositif de traitement de données 4 peut comporter en outre des moyens de conversion 4d, notamment un module logiciel de conversion 4d' , pour convertir les données selon le format commun en des données formatées compatibles avec 1 ' équipement informatique 5 et/ou son logiciel d'analyse de données 5e.
Le dispositif de traitement de données 4 comporte une interface de configurâtion-réception 4e, notamment un module
logiciel de configur tion-réception 4e', permettant d'entrer les données de configuration des moyens de réception 4a en fonction du format des données provenant des appareils émetteurs 1. Le dispositif de traitement de données 4 comporte un registre 4f contenant lesdites données de configuration des moyens de réception 4a.
Le dispositif de traitement de données 4 comporte des moyens de stockage 4g pour stocker les données traduites sous un format commun. Le logiciel d'analyse de données 5e dudit équipement informatique 5 comporte un module logiciel de configuration- réception 5h permettant d'entrer les données de configuration des moyens de réception 5d en fonction des spécificités des équipements informatiques 5 et/ou des autres modules 5g du logiciel d'analyse de données 5e.
Le logiciel d'analyse de données 5e comporte également un module d'enregistrement 5i contenant lesdites données de configuration-réception des moyens de réception 5d.
Grâce à cette combinaison de moyens, les utilisateurs peuvent disposer des données émises par un appareil émetteur distant, même si elles sont formatées selon d'autres standards que ceux, de leur équipement informatique et du logiciel d'analyse de données qu'ils utilisent. De plus les mises à jour sont réalisées une seule fois pour tous les appareils et tous les logiciels mis en service.
Dans une autre variante de réalisation, le dispositif de traitement de données 4 comporte une interface de configuration-émission 4e, notamment un module de configuration- émission 4e', permettant d'entrer les données de configuration des moyens d'émission 4c en fonction des spécificités des équipements informatiques 5 et du logiciel d'analyse de données 5e auxquels elles sont destinées. Dans ce cas, le registre 4f contient lesdites données de configuration des moyens d'émission 4c.
Ainsi dans le cas de cette variante de réalisation, grâce à cette combinaison de moyens, les utilisateurs peuvent également disposer des données émises par un appareil émetteur distant, même si elles sont formatées selon d'autres standards que ceux de leur équipement informatique et du logiciel d'analyse de données qu'ils utilisent.
On va maintenant décrire la figure 2 qui représente de manière schématique sous forme de blocs diagrammes les six modules composant une variante de réalisation du logiciel permettant de mettre en oeuvre l'invention. Le logiciel, ci- après dénommé le logiciel "DataCaptor" , est constitué des 7 modules suivants :
(1) Le DataCaptor Service (DS) 21, autrement appelé en langue française le Service DataCaptor, est le coeur du logiciel. Il démarre et contrôle les autres modules. Il assure un fonctionnement correct de l'ensemble du système. Il détecte les dysfonctionnements et restaure un fonctionnement nominal en corrigeant les éventuels problèmes. Il vérifie que chaque module DataCaptor Communication Interface (DCI) 22 (4a, figure 1) , autrement appelé en langue française l'Interface de Communication de DataCaptor, est activé et fonctionne correctement. Il maintient l'intégrité et la sécurité du système à tout moment. Il contrôle les modules DataCaptor Device Interface (DDI) 23 (4a, figure 1) , autrement appelés en langue française l'Interface d'Appareil de DataCaptor, via des interfaces (marche/arrêt : M/A, commandes : C) . Il met à disposition des interfaces destinées à être utilisées par les autres modules.
(2) Le DataCaptor Data Store (DDS) 24, autrement appelé en langue française le Dispositif de Stockage de Données DataCaptor, est un module de stockage des données D, à la fois pour le long terme et pour le court terme. Ce module reçoit les données acquises par chaque DDI 23, les stocke sur le disque 25
(4g, figure 1) et assure la transmission des données aux
DataCaptor ActiveX Controls (DAC) 26, autrement appelés en langue française les Contrôles ActiveX DataCaptor. Le DDS 24
exécute des fonctions en soi connues pour gérer le stockage des données. Il est optimisé pour traiter à la fois, sans baisse de performance, les requêtes en temps réel et les requêtes de données historiques. Il met à disposition des interfaces permettant une exploitation des données D et des commandes C par les autres modules. Toutes les données collectées sont stockées localement dans des fichiers binaires.
(3) Chaque DataCaptor ActiveX Control (DAC) 26 est accessible de tous les points du réseau de communication informatique 6, qu'il s'agisse d'un petit réseau NetBEUI ou de l'Internet. Chaque DataCaptor ActiveX Control (DAC) 26 permet la diffusion des données D.
Le DataCaptor ActiveX Control (DAC) 26 trouve le DataCaptor Data Store (DDS) 24 associé dont il connaît l'adresse, puis il s'enregistre auprès de celui-ci comme récepteur de données. Le DataCaptor ActiveX Control (DAC) 26 peut ensuite recevoir les données D provenant du DataCaptor Data Store (DDS) 24 associé. Ce dernier peut être situé à proximité ou bien être distant. Les données D sont transmises, par le DataCaptor ActiveX Control (DAC) 26 à l'équipement informatique 5 (figure 1) du praticien de la santé, via le module DataCaptor Data Portai (DDP) 40, autrement appelé en langue française le Portail de Données DataCaptor. Le logiciel clinique utilisé par un praticien de la santé, accède ainsi à toutes les données relatives à un patient collectées par n'importe quel appareil médical d'une unité de soins, d'un hôpital, etc.
Le DataCaptor ActiveX Control (DAC) 26 peut adresser des commandes C au DataCaptor Data Store (DDS) 24 et/ou au DataCaptor Service (DS) 21 ainsi qu'à tout module. Le programmeur du logiciel applicatif d'analyse clinique 5e peut, dans le cas de certaines variantes de réalisation, intégrer dans celui-ci un module DataCaptor ActiveX Control (DAC) 26. Le module DataCaptor ActiveX Control (DAC) 26 est l'interface d'utilisation du système pour le programmeur. Dans le cas de cette variante, les commandes C, adressées par le
DataCaptor ActiveX Control (DAC) 26 au DataCaptor Data Store (DDS) 24 et/ou au DataCaptor Service (DS) 21 ainsi qu'à tout module, peuvent être préprogrammées dans le logiciel applicatif et actionnées par le praticien de la santé. En encapsulant un ou plusieurs modules DataCaptor ActiveX Control (DAC) 26 dans le logiciel clinique utilisé par un praticien de la santé, on permet à celui-ci d'accéder à toutes les données relatives à un patient collectées par n'importe quel appareil médical d'une unité de soins, d'un hôpital, etc. (4) Les DataCaptor Device Interfaces (DDI) 23 permettent d'accéder aux appareils médicaux via les DataCaptor Communication Interface (DCI) 22. Ils sont configurés en fonction des spécificités de 1 ' appareil médical connecté à partir des paramètres contenus dans le registre 27 (4f, figure 1) du système d'exploitation et introduits dans le registre par le DataCaptor Control Panel (DCP) 28 (4e figure 1) , autrement appelés en langue française le Panneau de Contrôle DataCaptor. Ils sont démarrés par le DataCaptor Service (DS) 21. Ensuite, chaque DataCaptor Device Interface (DDI) 23 se connecte au module DataCaptor Communication Interface (DCI) 22 approprié. Les DataCaptor Device Interfaces (DDI) 23 assurent le maintien de la connexion avec 1 ' appareil connecté et gèrent les erreurs de communication détectées. Chaque DataCaptor Device Interface (DDI) 23 assure à la fois la communication bas-niveau par l'intermédiaire du module DataCaptor Communication Interface (DCI) 22 et l'interface haut-niveau : les protocoles de communication des données émises par 1 ' appareil médical concerné . Les DataCaptor Device Interfaces (DDI) 23 lisent et traduisent les protocoles des appareils médicaux auxquels ils sont connectés. Les DataCaptor Device Interfaces (DDI) 23 peuvent lire et traduire les paramètres sporadiques, les courbes de données en temps réel et toute autre donnée digitale en sortie des appareils médicaux.
Chaque DataCaptor Device Interface (DDI) 23 transmet les données collectées au DataCaptor Data Store (DDS) 24.
(5) Les DataCaptor Communication Interfaces (DCI) 22 permettent de démarrer et de contrôler les ports de communication physiques 29 avec les réseaux de communication informatique auxquels sont connectés les appareils médicaux 1. II existe un DataCaptor Communication Interface (DCI) 22 par type de port de communication (série, réseau, etc.). Chaque DataCaptor Communication Interface (DCI) 22 est démarré par le premier DataCaptor Device Interface (DDI) 23 qui nécessite ce type de port de communication. Ils surveillent également les éventuelles erreurs de communication.
(6) Le module DataCaptor Control Panel (DCP) 28 (4e, figure 1) est l'interface permettant de configurer le système. C'est par l'intermédiaire du DataCaptor Control Panel (DCP) 28 que l'utilisateur spécifie (i) les branchements physiques entre les appareils médicaux et les ports de communication physique, (ii) les paramètres de communication et (iii) le type d'appareil médical concerné.
Le module DataCaptor Control Panel (DCP) 28 permet de mettre à jour le registre 27 (4f, figure 1) . Le module DataCaptor Control Panel (DCP) 28 fournit aux DataCaptor Device Interfaces (DDI) 23, via le registre 27, les informations relatives à la configuration des sources de données du système et aux DataCaptor Communication Interfaces (DCI) 22 concernés.
(7) Le module DataCaptor Data Portai (DDP) 40 est le module de conversion des données D, provenant des DataCaptor
ActiveX Control (DAC) 26, au format de communication du logiciel d'analyse clinique 5e (figure 1) . Le DataCaptor Data Portai (DDP) 40 transmet les données, ainsi converties, au logiciel applicatif d'analyse clinique 5e de l'équipement informatique 5 (figure 1) . Le module DataCaptor Data Portai (DDP) 40 reçoit des commandes C du logiciel applicatif d'analyse clinique 5e (figure 1) et les transmet au DataCaptor ActiveX Control (DAC) 26.
Un DataCaptor Data Portai (DDP) 40 est destiné à recevoir des données D de un ou plusieurs DataCaptor ActiveX Control (DAC) 26.
Lorsque le programmeur du logiciel applicatif d'analyse clinique 5e (figure 1) intègre dans celui-ci un module DataCaptor ActiveX Control (DAC) 26, il n'est pas nécessaire de prévoir un DataCaptor Data Portai (DDP) 40. Dans ce cas, également, le programmeur du logiciel applicatif d'analyse clinique 5e adapte le langage propriétaire du logiciel d'analyse clinique au format commun.
Synthèse L'analyse du problème et de la solution selon l'invention montre qu'il est possible de scinder le problème général en plusieurs problèmes plus simples à solutionner :
Acquérir les données. Gestion de la communication avec 1 ' appareil par 1 ' intermédiaire de son protocole de communication.
Traduire les données entrantes en un format interne. Archivage des données.
Distribution des données aux utilisateurs. Rendre accessible les données par les logiciels d'application (notamment les logiciels d'analyse clinique) . Traduction du format interne au format général . Gestion de la globalité du système. Assurer les fonctions commandes, l'historique et le contrôle.
La solution selon 1 ' invention fournit toutes les données, quel que soit le format de la source, en un format de sortie unique et facilement exploitable.
La plate-forme de base ayant servi au développement d'une variante de réalisation du logiciel DataCaptor est Microsoft Distributed Component Object Model ( [D] COM) . Cette variante de réalisation du logiciel DataCaptor est écrit en Microsoft C++ et Visual Basic. Elle implémente une architecture à base de ( [D] COM) et fonctionne sur WNT, W98 et W95. Le choix de ( [D] COM) permet de régler toutes les questions de communication inter-modules , inter-PCs, et Internet et permet d'assurer une compatibilité avec les futures versions de système
d'exploitation de Microsoft, tout en permettant une compatibilité binaire avec d'autres systèmes d'exploitation. En effet, [D]COM est un standard binaire.
La possibilité existe d'écrire d'autres variantes de réalisation du logiciel DataCaptor en CORBA, en utilisant Java. 90% des plates-formes peuvent donc utiliser DataCaptor.