FR2850477A1

FR2850477A1 - Outils logiciels consultables a distance a l'aide d'un logiciel de navigation pour la creation, modification, consultation et diffusion de documents medicaux

Info

Publication number: FR2850477A1
Application number: FR0300907A
Authority: FR
Original assignee: Lincoln
Current assignee: Lincoln
Priority date: 2003-01-28
Filing date: 2003-01-28
Publication date: 2004-07-30

Abstract

L'outil logiciel est consultable à distance à l'aide d'un logiciel de navigation et apte à traiter des pages destinées à supporter des données médicales relatives à au moins une application médicale (AM) d'un groupe de patients. L'outil logiciel (SIT) comprend un module de création de pages (M-S) adapté pour permettre à un utilisateur distant autorisé de créer via une interface intuitive, souple, dynamique, et conviviale, des pages comportant des blocs contenant des champs paramétrables, correspondant à un formulaire médical personnalisé et structuré en relation avec ladite application médicale (AM). L'outil logiciel comprend d'autres modules (M-A, M-B, M-S, M-D) permettant la consultation, la modification, la composition et la diffusion de pages supportant des données relatives à des documents médicaux créés à partir d'outils métier médicaux, notamment des dossiers médicaux de spécialité, des documents bureautiques et des documents d'imagerie médicale.

Description

La présente invention se rapporte à la création, consultation, composition, modification et/ou diffusion de pages supportant des données médicales relatives à une ou plusieurs applications médicales d'un groupe de patients.

Elle trouve une application générale dans le traitement de données médicales et plus particulièrement les données médicales consultables à distance à l'aide d'un logiciel de navigation.

On connaît déjà des outils logiciels permettant l'archivage de données médicales, par exemple des images radiographiques et des compte rendus d'interventions, et leur numérisation.

On connaît aussi des outils logiciels permettant aux spécialistes d'une application médicale d'échanger de manière sécurisée des données médicales à travers un réseau de communication spécialisé. En pratique, de tels outils logiciels sont consultables à distance à l'aide d'un logiciel de navigation, et traitent des pages supportant des données médicales relatives à une application médicale d'un groupe de patients.

De tels outils logiciels consultables à distance sont limités actuellement à une seule application ou discipline médicale.

De plus, les utilisateurs de ce genre d'outils logiciels ne peuvent pas, sauf en ayant des connaissances poussées en informatique, créer eux mêmes, des formulaires médicaux correspondant à leurs besoins spécifiques.

La présente invention remédie à ces inconvénients.

Elle porte sur un outil logiciel consultable à distance à l'aide d'un logiciel de navigation, et apte à traiter des pages destinées à supporter des données médicales relatives à au moins une application médicale d'un groupe de patients.

Selon une définition générale de l'invention, l'outil logiciel comprend un module de création de formulaires médicaux adapté pour permettre à un utilisateur distant de créer via une interface intuitive, souple, dynamique, et conviviale, des pages correspondant à un formulaire médical structuré en relation avec ladite application médicale.

Ainsi, grâce au module de création selon l'invention, un utilisateur distant peut créer, via une interface intuitive et conformément à ses besoins spécifiques, un formulaire médical sans aucune connaissance spécifique et préalable en informatique. De plus le module de création est utilisable pour une ou plusieurs disciplines ou applications médicales.

Selon une réalisation, le module de création comprend un moteur de génération de formulaires médicaux sous la forme de pages consultables à l'aide d'un logiciel de navigation, ledit moteur étant relié à une base de données relationnelle possédant une pluralité de tables aptes à décrire les caractéristiques de chacune des pages d'un formulaire médical choisi.

En pratique, le moteur de génération est adapté pour permettre à un utilisateur distant de créer un formulaire médical ayant une structure comprenant plusieurs chapitres découpés chacun en plusieurs blocs contenant chacun des champs et items, les éléments du formulaire étant paramétrables au moyen d'une interface intuitive du type logiciel de navigation par des utilisateurs sans connaissance préalable des outils informatiques.

Selon une autre réalisation, l'outil logiciel comprend en outre un module de composition automatique d'un compte rendu à partir des différentes pages d'un formulaire médical. Ledit module de composition est consultable à distance à l'aide d'un logiciel de navigation, et comprend un dictionnaire contenant des champs de formulaire prédéfinis associés chacun à un texte paramétrable. Le module de composition automatique est apte, en réponse à une sélection d'un champ de formulaire par un utilisateur distant, à aller chercher dans le dictionnaire le texte correspondant, à proposer à l'utilisateur de modifier ce

texte, et à transformer ledit champ sélectionné par le texte associé, ce qui permet à l'utilisateur distant de composer automatiquement un compte rendu personnalisé à partir d'un formulaire médical qu'il a lui-même paramétré, le tout à partir d'une interface conviviale de son navigateur Internet.

Selon une autre réalisation, l'outil logiciel comprend en outre un module de consultation à distance à l'aide d'un logiciel de navigation, apte en réponse à une demande de consultation d'un utilisateur à permettre audit utilisateur de consulter les documents médicaux d'un patient choisi.

Par exemple, le module de composition de compte rendu est accessible à partir du module de consultation afin de permettre à un utilisateur distant de composer un compte rendu sur au moins un document médical ainsi consulté.

Selon encore une autre réalisation, l'outil logiciel comprend en outre un module d'agrégation des documents médicaux d'un patient, ledit module d'agrégation étant consultable à distance à l'aide d'un logiciel de navigation, et apte en réponse à une requête d'un utilisateur distant à regrouper dans un dossier unique lié à l'identité du patient plusieurs documents médicaux de ce même patient.

Dans le cas où l'application médicale est du type imagerie médicale, l'outil logiciel comprend en outre un module d'imagerie médicale consultable à distance à l'aide d'un logiciel de navigation et permettant à un utilisateur distant de traiter des documents d'imagerie issus de l'application d'imagerie.

L'outil logiciel comprend en outre un module d'indexation consultable à distance à l'aide d'un logiciel de navigation et comprenant une première entrée recevant des données nominatives relatives à un patient, en particulier en les important à partir du serveur d'identité d'une institution hospitalière ou d'une clinique médicale, et une seconde entrée recevant un document médical contenant notamment des formulaires médicaux, et une sortie délivrant un document médical indexé à partir des données nominatives dudit patient.

De préférence, l'outil logiciel comprend des moyens de contrôle d'accès à chacun des modules de traitement de pages supportant des données médicales et aux documents médicaux associés, selon une loi de distribution de droits d'accès choisie.

La présente invention a également pour objet un procédé de traitement de données médicales relatives à au moins une application médicale d'un groupe de patients.

Le procédé de traitement de données médicales comprend des étapes de création, consultation, composition, modification et/ou diffusion de pages supportant des données médicales à l'aide d'outils logiciels de création, consultation, composition, modification et/ou diffusion de pages, visés ci-avant.

La présente invention a également pour objet un dispositif de traitement de données médicales relatives à au moins une application médicale d'un groupe de patients.

Le dispositif de traitement de données médicales comprend un serveur de données accessible à distance à l'aide d'un logiciel de navigation de type Internet et comprenant des outils logiciels de création, consultation, composition, modification, et/ou diffusion de pages, visés ci-avant.

D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description détaillée ci-après et des dessins dans lesquels : - la figure 1 représente schématiquement un système informatique d'une institution hospitalière utilisant des outils logiciels conformes à l'invention ; - la figure 2 représente schématiquement la structure et le fonctionnement du module d'application bureautique conforme à l'invention ; - la figure 3 illustre schématiquement la structure et le fonctionnement du module de gestion de document de spécialité conforme à l'invention ;

- la figure 4 représente schématiquement l'organisation de la base de données associée aux pages supportant les données médicales selon l'invention ; - la figure 5 est un exemple d'une structure d'un chapitre à quatre blocs conforme à l'invention ; - les figures 6a et 6b sont des exemples détaillés de chapitres conformes à l'invention ; - la figure 7 est un autre exemple d'un chapitre conforme à l'invention ; et - la figure 8 illustre schématiquement la structure et le fonctionnement du module de gestion d'imagerie selon l'invention.

En référence à la figure 1, le système informatique SYS décrit est par exemple celui d'une institution hospitalière tel qu'un hôpital. Bien évidemment, l'invention s'applique à tout autre système informatique dans lequel l'information est généralement distribuée dans des serveurs de données médicales à travers des réseaux de communications.

Le système informatique SYS fournit ici une pluralité de services médicaux et administratifs accessibles à des médecins ou autres utilisateurs autorisés à l'aide d'interfaces utilisateurs IHM.

Les interfaces utilisateurs IHM, individualisées en référence à la figure 1, en IHM-1, IHM-2, IHM-3, IHM-4, IHM-5 sont par exemple des ordinateurs connectés par des réseaux de communication appropriés RES à des serveurs utilisateurs SUT. Les interfaces utilisateurs IHM sont équipées d'un logiciel de navigation, de type navigateur Internet permettant d'accéder à des pages écrites en langage informatique à balises, du type HTML ou XML. Les réseaux de communication sont du type intranet ou extranet.

Les serveurs utilisateurs SUT, individualisés en SUT-1, SUT-2, SUT-3, assurent notamment des fonctions administratives, de communication et d'annuaire. Par exemple, l'un des serveurs utilisateurs SUT-1 est le serveur d'identité de l'institution hospitalière SIH et le serveur SUT-2 est l'annuaire d'entreprise ANN.

Le système informatique SYS comprend en outre une pluralité de serveurs d'applications médicales SAM, individualisés en SAM-1, SAM-2, SAM-3, et relatifs chacun à au moins une application médicale choisie AM, du type par exemple : cardiologie, explorations fonctionnelles, imagerie, électrophysiologie AM1, analyse ambulatoire de la pression artérielle AM2, scanner AM3.

Un serveur formant intergiciel SIT est intercalé entre les serveurs utilisateurs SUT et les serveurs SAM et applications médicales AM.

Le serveur intergiciel SIT, appelé middleware en anglo saxon, est un ensemble de logiciels permettant à des utilisateurs distants, à l'aide d'un logiciel de navigation du type navigateur Internet, de traiter des pages destinées à supporter des données médicales concernant l'hospitalisation ou le suivi clinique des patients.

Le serveur intergiciel SIT s'appuie sur des boîtes à outils logicielles permettant à des utilisateurs distants de créer des documents tels que des formulaires médicaux ou des dossiers de spécialités, conformément à leurs besoins, sans aucune connaissance informatique, et de diffuser les documents correspondants sur un réseau de communication RES de type Intranet ou Extranet institutionnel garantissant la sécurité des transactions.

Par exemple, le serveur intergiciel SIT comprend quatre modules principaux MA, M-B, M-D, et M-S.

En bref, le module M-B est un outil du genre bureautique, consultable à distance par exemple via un réseau de communication RES, et qui permet aux utilisateurs distants de traiter les données médicales à l'aide d'outils de traitement de données de type traitement de texte ou analogue.

De son côté, le module M-S est un outil de gestion de dossier de spécialité offrant de nombreuses possibilités de création, modification et/ou consultation

de pages susceptibles de supportées des documents, formulaires, registres médicaux.

Concernant le module M-D, il forme un outil de gestion des dossiers d'imagerie, gérant à la fois les images et les données associées aux images.

Enfin, le module M-A est un outil d'agrégation des documents médicaux provenant des modules M-B, M-S et M-D.

En référence à la figure 2, le module M-B forme un outil d'application bureautique polyvalent offrant de nombreuses possibilités aussi bien pour le secrétariat médical que pour les médecins.

Au lancement du module ou application M-B sur un poste de type microordinateur équipé d'un logiciel de navigation, l'utilisateur en connexion s'identifie au cours d'une session d'identification dans laquelle l'utilisateur indique son profil et les droits d'accès attachés. Les profils des utilisateurs et les droits d'accès attachés peuvent être du type : pas de droit, mode consultation restreinte, consultation élargie, secrétaire, modification restreinte, modification élargie, ou administrateur.

En se connectant au module M-B, l'administrateur de l'application, qui peut être une secrétaire SEC disposant de droits d'administration sur le module M-B, bénéficie des fonctions logicielles lui permettant : - la création de modèles MOD correspondant aux différents types de courriers ou de rapports à produire, à partir d'un traitement de texte classique, qui sera copié dans la boite appropriée de l'interface de son navigateur, - la création des utilisateurs de l'application ou des correspondants du service, avec attribution ATT d'un profil de connexion à chaque utilisateur, ces utilisateurs pouvant être directement importés de l'annuaire ANN d'entreprise, - la création des différents postes du service clinique concerné où sont dictés les différents rapports ou documents bureautiques,

- l'indexation des modèles, de manière à faire correspondre automatiquement chaque modèle à un ou plusieurs postes et/ou à un ou plusieurs utilisateurs, et - la création d'une ou plusieurs pages de formulaires associés aux documents, par des méthodes qui seront détaillées plus loin à propos du module M-S, permettant notamment le codage de diagnostics ou d'actes médicaux.

Le module M-B dispose par ailleurs d'une interface d'indexation IND qui permet à chaque secrétaire SEC d'attribuer un document transmis par l'auteur AUT du document sous la forme d'une cassette K7 dictée (dictée analogique) ou sous la forme d'un fichier vocal enregistré sur le réseau (dictée numérique) à un certain nombre d'attributs ATT.

Ces attributs comprennent notamment : - l'identité du patient concerné par le document, qui peut être importé du serveur d'identité SIH de l'institution dans la base de données relationnelle du module M-B, - le ou les médecins AUT ayant dicté le document, - le poste où le document a été dicté dans le service clinique, notamment la salle d'hospitalisation s'il s'agit d'un compte rendu d'hospitalisation, - le ou les correspondants à qui doivent être adressés les documents, la secrétaire SEC pouvant inclure de nouveaux correspondants grâce à un formulaire dédié du module d'indexation, ou pouvant importer des correspondants répertoriés dans l'annuaire ANN de l'entreprise, et - d'autres attributs sous la forme de champs ou de pages de formulaires créés par l'administrateur de l'application.

La secrétaire, une fois le modèle MOD et les attributs ATT du document définis selon les étapes précédentes, va retranscrire le texte dicté, soit directement dans une boite de texte de l'interface IND permettant toutes les mises en forme de type RTF (Rich Text Format), soit directement sur un logiciel de traitement de texte, puis en copiant le texte ainsi saisi et mis en forme dans la boite de

texte de l'interface IND. A la fin de la saisie, le secrétaire valide le document, et l'imprime si elle le souhaite.

Le module M-B propose une interface utilisateur UTIL de communication et de visualisation intuitive de type Internet permettant des recherches rapides multicritères et une localisation rapide des patients et documents recherchés.

L'auteur du document AUT s'identifie au module M-B et trouve dans l'interface UTIL les patients retranscris par la secrétaire selon les modalités précitées, et non encore signés. La liste des documents non signés est en effet proposée au médecin, avec accès au document sélectionné et possibilité de le signer. Le médecin peut ainsi ouvrir le document, le modifier et le signer. La signature Sig du document REV1 entraîne son archivage dans une zone définie du serveur SIT sous une forme non modifiable, en format PDF par exemple. Pour modifier un document DOC (en pratique seul les signataires et l'administrateur peuvent modifier un document), le médecin sélectionne le document concerné par le nom du patient, par le numéro d'identification et par le critère de signature des documents. Une signature ultérieure effectuée par l'auteur du document ou par un autre utilisateur COS disposant des droits de modification sur ce dossier entraînera la publication d'un second document REV2, dont la traçabilité sera assurée par les attributs de la signature (auteur, date).

En pratique, un document médical est ainsi caractérisé par un numéro d'identification, un type de document, une date de création, les différents attributs associés au document, le modèle de document et le texte retranscrit.

Le document porte ainsi un numéro unique d'identification.

Pour le médecin auteur AUT du ou des document (s), pour les médecins disposant de droits de modification sur ce document, l'outil M-B permet de visualiser automatiquement tous les documents tapés et non signés, de les corriger et de les signer électroniquement Sig. Le système permet la gestion des différentes mises à jour et garantit la traçabilité des différentes signatures Sig et des documents correspondants DOC.

Les documents ainsi signés DOC sont susceptibles d'être diffusés sur le réseau de communication interne de l'institution (Intranet par exemple).

Pour les différents utilisateurs distants (Consultation) ayant accès à l'Intranet qu'ils soient internes ou externes à l'institution, l'outil logiciel M-B permet d'ouvrir et de consulter (en fonction des droits d'accès à l'Intranet institutionnel) les différents documents DOC sous un format non modifiable. La consultation d'un document DOC par un utilisateur distant appelé aussi correspondant, dépend des droits de consultation attribués par l'équipe médicale responsable.

Une table versiondoc (non représentée) permet d'afficher l'historique des différentes versions des documents en indiquant le numéro, l'auteur et la date de la révision du document.

Des fonctions d'administration permettent à l'administrateur de changer certains paramètres tels que les mots de passe ou définir le profil des utilisateurs en groupes (personnel médical, plein temps, service). Pour ouvrir un droit de consultation sur un patient, il est possible de sélectionner directement un groupe (selon le profil, la catégorie ou le service) ou de façon plus restreinte additionner les groupes (tel profil et telle catégorie) sans avoir à choisir les utilisateurs un à un.

En référence à la figure 3, le module M-S est un applicatif de spécialité paramétrable permettant, au moyen d'une interface de communication et de visualisation de type Internet hautement conviviale et consultable à distance, de créer des dossiers de spécialité DSP, et de les agréger dans le module M-A que l'on décrira plus en détail ci-après.

Une application médicale AM qui implique l'impression d'un rapport sous un système d'exploitation approprié, peut publier (diffuser) un document dans le module M-S en un format standard du type par exemple format PDF avec l'ensemble de ses illustrations.

Pour cela, une imprimante virtuelle VIR est installée dans le poste utilisateur de l'application médicale. Cette imprimante virtuelle permet d'exporter tout document imprimé sous la forme d'un fichier EXP au format PDF.

Une méthode d'indexation simple IND similaire à celle décrite en référence à la figure 2 est également prévue pour indexer un document EXP au format RTF avec des attributs ATT issus du serveur d'identité SIH ou d'un annuaire ANN.

L'outil logiciel M-S permet le paramétrage complet du document DSP en vue de la publication sur le réseau de communication (Intranet par exemple ou Internet) des documents correspondants.

Par exemple, l'auteur AUT d'un document de spécialité DSP dicte un compte rendu classique et l'indexe au moyen du module M-B décrit en référence à la figure 2.

Le compte rendu dicté CRPRF et le document généré par l'applicatif médical sont alors associés sous la forme de deux documents au format PDF.

En variante, l'auteur AUT d'un document de spécialité peut créer son propre formulaire médical ou dossier de spécialité.

Pour cela, le module M-S met à la disposition de l'auteur un module de création qui va lui permettre de créer, via une interface intuitive, dynamique, souple et conviviale, un formulaire médical structuré comprenant plusieurs chapitres constitués chacun de plusieurs champs et items destinés à contenir des données médicales d'une application médicale de son choix.

Le module de création comprend un moteur de génération de formulaire médical sous la forme de pages consultables à l'aide d'un logiciel navigateur.

En pratique, le moteur est relié à une base de données relationnelle possédant une pluralité de tables aptes à décrire les caractéristiques de chacune des pages d'un formulaire médical correspondant.

Le moteur de génération est adapté pour permettre à un utilisateur de créer un formulaire médical ayant une structure comprenant plusieurs chapitres découpés chacun en plusieurs blocs contenant chacun des champs et items.

Un chapitre est un ensemble d'informations associées à une procédure et regroupées dans un formulaire.

L'outil M-S offre la possibilité de définir entièrement le nom des chapitres et les champs présents à l'intérieur desdits chapitres.

Par exemple, un formulaire comprend plusieurs chapitres.

Un chapitre, appelé données d'inclusions est prévu de préférence de façon systématique. En pratique, il n'est pas possible de le modifier dans la mesure où il reprend les informations relatives à l'inclusion de la procédure.

Un chapitre signature permet aux opérateurs de signer les procédures. Il est systématiquement proposé aux profils habilités.

Un chapitre lettre aux référents est disponible dès lors qu'un référent a été défini pour la procédure.

Les autres chapitres (par exemple, indication de l'examen et résultat de la procédure ) sont créés par l'utilisateur selon ses besoins spécifiques.

Le moteur de création comprend un assistant de création permettant à l'utilisateur de définir les champs de chaque chapitre à la suite d'un échange de questions et de réponses visualisées sur un écran de visualisation de l'interface homme machine de l'utilisateur.

Par exemple, le module de création est accessible aux utilisateurs ayant un certain profil et des droits d'accès spécifiques. Par exemple ce profil correspond à celui d'un super-administrateur .

Par exemple, après vérification des droits autorisant la création de formulaires, l'assistant de création affiche un écran invitant l'utilisateur à créer un chapitre en lui proposant plusieurs questions. Ainsi, l'utilisateur créé un nouveau chapitre en répondant à la question nom du chapitre ainsi qu'à la question nombre de blocs . Le cas échéant , une zone de commentaire est insérable dans le chapitre.

En pratique, le nombre de blocs doit être compris entre 1 et 4. Le nombre de chapitres que l'on peut créer est illimité. Le nom du chapitre est par exemple limité à 30 caractères.

Ensuite, il convient de renseigner le nom (libellé) des blocs pour chaque nouveau chapitre conformément à un écran dans lequel l'utilisateur sélectionne un chapitre et remplit le libellé de chaque bloc du chapitre ainsi sélectionné.

Par défaut, le bloc sélectionné est celui que l'on veut créer. Les autres items de la liste correspondent à tous les chapitres déjà présents dans l'application. Cet écran permet donc de créer des blocs ou de modifier des blocs.

En mode création : # Le libellé du bloc est par exemple limité à 30 caractères.

# Il faut saisir le nom de chaque bloc avant de pouvoir accéder à l'écran de définition du bloc.

En mode modification : # Les libellés existants sont affichés et ils peuvent être modifiés.

Ensuite, il convient de renseigner un écran dans lequel il est proposé de décrire les champs de chaque bloc de chaque chapitre.

En pratique, l'utilisateur commence par décrire les champs du premier bloc du chapitre concerné. Tant qu'au moins un champ n'est pas défini, l'utilisateur ne peut pas passer au bloc suivant.

Le type d'objet proposé par défaut est la case à cocher.

Une flèche permet de se déplacer de bloc en bloc Les champs s'ajoutent les uns en dessous des autres.

Conformément à un écran d'organisation, Il est ensuite possible de réorganiser les champs au sein du bloc en cliquant sur le bouton correspondant (si au moins deux champs ont été définis dans le bloc).

Avant de valider la création du chapitre, il est possible de visualiser le résultat (dès qu'au moins un champ par bloc est créé).

Le module M-S permet aussi d'administrer les chapitres afin de modifier ou de supprimer des chapitres et de les organiser au sein de l'application conformément à un écran approprié.

Il est possible dans cet écran de définir l'ordre d'apparition des chapitres dans le menu déroulant des chapitres. Ces chapitres s'intégreront dans l'ordre défini ci-dessous en s'intercalant nécessairement entre Données d'inclusion (en premier) et Conclusions .

Des boutons représentant une poubelle et un oeil permettent à l'utilisateur de supprimer ou d'accéder à des données de façon intuitive et conviviale.

Le bouton oeil permet d'accéder à l'écran de définition des libellés de blocs.

Une aide est proposée au passage de la souris sur l'image représentant l'oeil ( modifier les blocs du chapitre ).

De même, le bouton oeil permet d'accéder à l'écran de définition des champs du bloc en validant les éventuelles modifications sur le libellé des blocs (# bouton Valider+ lien vers les champs). Une aide est proposée au passage de la souris sur l'image oeil ( modifier les champs du bloc ) En pratique, l'utilisateur ne peut changer le type des champs déjà enregistrés (une case à cocher ne peut pas devenir une liste Oui/Non/ ? ) mais l'utilisateur peut modifier les libellés des champs, les valeurs par défaut.

La suppression d'un champ entraîne sa disparition des formulaires mais les données déjà saisies ne sont pas physiquement supprimées.

L'écran de modification des champs d'un bloc est le même que celui de création. Les champs sont pré-remplis et il est possible d'ajouter de nouveaux champs.

L'avantage d'un tel moteur de génération de formulaire réside en pratique dans son aptitude à permettre de créer des formulaires médicaux relativement complexes (c'est-à-dire répondant à des besoins spécifiques d'une ou plusieurs applications médicales) tout en utilisant un langage commun accessible à tout utilisateur, non connaisseur en informatique.

En référence à la figure 4, la base de données relationnelle comprend par exemple quatre tables : la table T1 page , la table T2 bloc , la table T3 liste et la table T4 détail .

La table T1 page décrit les caractéristiques de chacun des écrans de la base de données.

Par exemple, la table T1 page a la structure suivante.

<tb>
<tb> Variable <SEP> Description <SEP> Type <SEP> Exemple
<tb> CD~PGE <SEP> Code <SEP> de <SEP> la <SEP> page <SEP> CHAR <SEP> 3
<tb> NM~PGE <SEP> Nom <SEP> HTML <SEP> de <SEP> la <SEP> page <SEP> CHAR <SEP> Inclusion
<tb> LB~PGE <SEP> Libellé <SEP> de <SEP> la <SEP> page <SEP> CHAR <SEP> Inclusion
<tb> d'un
<tb> nouveau
<tb> patient
<tb> TP~PGE <SEP> Page <SEP> de <SEP> type <SEP> chapitre <SEP> (O/N) <SEP> CHAR <SEP> O
<tb> NB~BLC <SEP> Nombre <SEP> de <SEP> blocs <SEP> de <SEP> la <SEP> page <SEP> (maximum <SEP> 4) <SEP> NUM <SEP> 2
<tb> TXT <SEP> Existence <SEP> d'une <SEP> zone <SEP> de <SEP> texte <SEP> associée <SEP> à <SEP> la <SEP> NUM <SEP> 0
<tb> page <SEP> (0/1)
<tb>
La table T2 bloc détaille la structure des blocs en précisant le contenu des champs du formulaire.

En référence à la figure 5, un chapitre CHA est découpé en blocs BLO (4 au maximum). Par exemple, le chapitre CHA comprend un champ titre du chapitre et les blocs BL01, BL02 et BL03.

En référence à la figure 6a, le chapitre CHA décrit ci dessus comporte à l'intérieur du bloc BL01 plusieurs types de champ de formulaire : un titre de section Titre , une case à cocher CC, une liste déroulante à choix unique LDU, une liste déroulante à choix multiple LDM, un champ de texte TXT, un champ de valeur numérique NUM , un champ de date DAT , un champ de durée DUR etc En référence à la figure 6b, l'utilisateur peut à chaque instant visualiser le document, ou réorganiser les champs à l'intérieur d'un bloc, en supprimant, modifiant ou déplaçant tout champ à l'intérieur d'un bloc, en ajoutant des titres de section ou des lignes de séparation entre les sections d'un même bloc.

A l'intérieur de chaque bloc BLO, des champs sont insérés les uns en dessous des autres (le numéro du champ est alors incrémenté de 1 ).

La structure de la table T2 bloc est par exemple la suivante.

Variable <SEP> Description <SEP> Type <SEP> Exemple
<tb> CD~PGE <SEP> Code <SEP> de <SEP> la <SEP> page <SEP> CHAR <SEP> 3 <SEP>
<tb> NO~BLC <SEP> Numéro <SEP> du <SEP> bloc <SEP> (max. <SEP> 4) <SEP> NUM <SEP> 1
<tb> NM~BLC <SEP> Nom <SEP> du <SEP> bloc <SEP> CHAR <SEP> Description
<tb> SS~BLC <SEP> Numéro <SEP> du <SEP> sous <SEP> bloc <SEP> NUM <SEP> 1
<tb> LIGNE <SEP> Numéro <SEP> de <SEP> ligne <SEP> du <SEP> bloc <SEP> NUM <SEP> 1
<tb> TP~OBJ <SEP> Code <SEP> type <SEP> d'objet <SEP> CHAR <SEP> LD
<tb> BAC <SEP> = <SEP> Boite <SEP> à <SEP> cocher
<tb> LD <SEP> = <SEP> Liste <SEP> déroulante
<tb> TXT <SEP> = <SEP> Texte <SEP>
<tb> SEC <SEP> = <SEP> Section <SEP>
<tb> CG~OBJ <SEP> Catégorie <SEP> de <SEP> l'objet <SEP> CHAR <SEP> 11
<tb> 11 <SEP> = <SEP> Invariant <SEP> de <SEP> niveau <SEP> 1
<tb> 12 <SEP> = <SEP> Invariant <SEP> de <SEP> niveau <SEP> 2
<tb> CP <SEP> = <SEP> Champ <SEP> Personnel
<tb> NM~OBJ <SEP> Nom <SEP> de <SEP> l'objet <SEP> CHAR <SEP> Ventri
<tb> Nom <SEP> de <SEP> la <SEP> variable <SEP> dans <SEP> la <SEP> base <SEP> de
<tb> données
<tb> LB~OBJ <SEP> Description <SEP> de <SEP> l'objet <SEP> CHAR <SEP> Ventriculogr
<tb> aphie
<tb> LD~NOM <SEP> Nom <SEP> de <SEP> la <SEP> Liste <SEP> Déroulante <SEP> CHAR <SEP> VENTRI
<tb> TYPE <SEP> Champ <SEP> de <SEP> type <SEP> : <SEP> D <SEP> : <SEP> Date <SEP> CHAR <SEP> A
<tb> N <SEP> : <SEP> Numérique
<tb> A <SEP> : <SEP> Alphanumérique
<tb> DETAIL <SEP> Fiche <SEP> de <SEP> détail <SEP> associée <SEP> au <SEP> champ <SEP> : <SEP> 8
<tb> OUI/NON
<tb> LONGUEUR <SEP> Longueur <SEP> des <SEP> champs <SEP> texte <SEP> : <SEP> définit <SEP> la <SEP> taille <SEP> NUM <SEP> 8 <SEP>
<tb> de <SEP> l'objet <SEP> INPUT
<tb> DEFAUT <SEP> Valeur <SEP> par <SEP> défaut <SEP> des <SEP> objets <SEP> de <SEP> type <SEP> TXT <SEP> ou <SEP> CHAR <SEP> DATE~DU~
<tb> BAC <SEP> JOUR
<tb> Pour <SEP> les <SEP> BAC, <SEP> 1 <SEP> si <SEP> le <SEP> champ <SEP> est <SEP> coché <SEP> et <SEP> 0
<tb> sinon
<tb>

<tb>
<tb> CTRL <SEP> Saisie <SEP> obligatoire <SEP> (0/1) <SEP> CHAR <SEP> 1
<tb> CROISE <SEP> Contrôles <SEP> croisés <SEP> - <SEP> associations <SEP> des <SEP> CHAR
<tb> variables <SEP> (1 <SEP> ,1a) <SEP> (2 <SEP> ,2a)... <SEP>
<tb>

TYP~CTRL <SEP> Quelques <SEP> contrôles <SEP> prédéfinis <SEP> : <SEP>
<tb> 1. <SEP> CLE <SEP> : <SEP> les <SEP> caractères <SEP> spéciaux <SEP> et <SEP> les
<tb> espaces <SEP> sont <SEP> interdits
<tb> 2. <SEP> CROISE1 <SEP> - <SEP> CROISE2... <SEP> : <SEP> contrôles
<tb> croisés <SEP> prédéfinis
<tb> 3. <SEP> DEC <SEP> : <SEP> champ <SEP> décimal
<tb> TP~ACC <SEP> Lecture <SEP> (L)ou <SEP> écriture <SEP> (W) <SEP> CHAR <SEP> W
<tb> CR~TXT <SEP> Compte <SEP> Rendu <SEP> : <SEP> Texte <SEP> associé <SEP> CHAR <SEP>
<tb> CR~TXT~NE <SEP> Compte <SEP> Rendu <SEP> : <SEP> Texte <SEP> à <SEP> afficher <SEP> si <SEP> champ <SEP> CHAR
<tb> G <SEP> négatif
<tb> (BAC <SEP> non <SEP> coché <SEP> ou <SEP> item <SEP> de <SEP> LD <SEP> ='Non'
<tb> CR~CHP~NE <SEP> Compte <SEP> Rendu <SEP> : <SEP> Affichage <SEP> des <SEP> champs <SEP> NUM
<tb> G <SEP> négatifs
<tb> CRJJGNE <SEP> Compte <SEP> Rendu <SEP> : <SEP> Retour <SEP> à <SEP> la <SEP> ligne <SEP> pour <SEP> NUM
<tb> écrire <SEP> ce <SEP> champ
<tb> CR~INHIBE <SEP> 1 <SEP> si <SEP> le <SEP> champ <SEP> est <SEP> inhibé <SEP> du <SEP> compte <SEP> rendu <SEP> NUM
<tb> PRESENCE~ <SEP> Flag <SEP> affichage <SEP> image <SEP> infobulle <SEP> CHAR <SEP>
<tb> INFOBULLE
<tb> INFOBULLE <SEP> Texte <SEP> d'aide <SEP> associée <SEP> au <SEP> champ <SEP> CHAR
<tb> RAPPEL <SEP> Dernière <SEP> saisie <SEP> du <SEP> champ <SEP> automatiquement <SEP> CHAR
<tb> récupérée
<tb>
A certains champs CHP est associé une fiche de détail telle que la fiche cardiomyopathie (figure 7), pour permettre de saisir des informations complémentaires.

La table détail T4 permet la définition des formulaires des fiches de détails associés à certains champs. La structure de cette table est identique à celle de la table T2 BLOC.

La table liste T3 détaille pour chaque objet de type Liste Déroulante, les items présents et spécifie les items choisis par défaut.

Par exemple, la table liste T3 comprend certaines variables identiques à celles des tables T2 et T4 et des variables spécifiques du type suivant.

Variable <SEP> Description <SEP> Type <SEP> Exemple
<tb> NM~LD <SEP> Nom <SEP> de <SEP> l'objet <SEP> - <SEP> Nom <SEP> de <SEP> la <SEP> variable <SEP> CHAR8 <SEP> Ventri <SEP>
<tb> dans <SEP> la <SEP> base <SEP> de <SEP> données
<tb> NO~ITM <SEP> Numéro <SEP> de <SEP> l'item <SEP> de <SEP> la <SEP> liste. <SEP> NUM <SEP>
<tb> LB~ITM <SEP> Label <SEP> de <SEP> l'item <SEP> de <SEP> la <SEP> liste <SEP> CHAR20 <SEP> Non <SEP> faite
<tb> DEFAUT <SEP> Item <SEP> sélectionné <SEP> par <SEP> défaut <SEP> (0/1) <SEP> CHAR1 <SEP> 1
<tb>
La liste peut être à choix unique ou à choix multiple. La notion de liste à choix unique ou multiple n'est pas définie dans la table T3 LISTE mais directement associée au champ concerné dans la table T2 BLOC (type d'objet LD ou LDM). En effet une liste peut être utilisée plusieurs fois, sur des champs différents.

Le dictionnaire de l'application comprend d'autres tables, telles que celles relatives à l'utilisateur qui sert à gérer les droits des utilisateurs selon leur profil.

Par exemple, la table utilisateur user est la suivante.

Nom <SEP> du <SEP> champ <SEP> Type <SEP> de <SEP> donnees
<tb> ; <SEP> USER <SEP> ' <SEP> Texte <SEP> Nom <SEP> de <SEP> user <SEP> de <SEP> l'utilisateur
<tb> PWD <SEP> : <SEP> Texte <SEP> Mot <SEP> de <SEP> passe <SEP> de <SEP> l'utlsateur
<tb> PROFIL <SEP> Texte <SEP> Type <SEP> de <SEP> profil
<tb> TITRE <SEP> Texte <SEP> Préfixe <SEP> de <SEP> sexe <SEP> ou <SEP> fonction
<tb> U <SEP> NOM <SEP> 1 <SEP> Texte <SEP> Nom <SEP> de <SEP> l'utilisateur
<tb> ] <SEP> U <SEP> PNOM <SEP> Texte <SEP> Prénom <SEP> de <SEP> l'utilisateur <SEP>
<tb> OPERATEUR <SEP> Texte <SEP> renseigné <SEP> si <SEP> c'est <SEP> un <SEP> docteur <SEP>
<tb> NUMERO <SEP> NuméroAuto <SEP> Compteur
<tb> GROUPE~~ <SEP> Texte <SEP> Appartenance <SEP> un <SEP> group
<tb> MAIL <SEP> Texte <SEP> Adresse <SEP> Mail
<tb> ADRESSE <SEP> Texte <SEP> Adresse <SEP> postale
<tb> CPOSTAL <SEP> Texte <SEP> Code <SEP> Postal <SEP>
<tb> VILLE <SEP> Texte <SEP> Ville
<tb> PAYS <SEP> Texte <SEP> Pays
<tb>

Une table chapitre permet d'associer la liste des chapitres présents par type de procédure.

Par exemple, la table chapitre a la structure suivante.

<tb>
<tb> Variable <SEP> Description <SEP> Type
<tb> PROCEDU <SEP> Type <SEP> d'examen <SEP> CHAR
<tb> RE
<tb> CHAPITRE <SEP> Nom <SEP> du <SEP> chapitre <SEP> CHAR
<tb> URL <SEP> Nom <SEP> de <SEP> l'URL <SEP> CHAR
<tb> Ordre <SEP> liste <SEP> Ordre <SEP> d'apparition <SEP> dans <SEP> NUM
<tb> le <SEP> menu
<tb> Présence <SEP> Présence <SEP> de <SEP> détail <SEP> CHAR
<tb> détail
<tb> CD~PGE <SEP> Code <SEP> de <SEP> la <SEP> page <SEP> NUM
<tb>

"1""proèeilure ." c~apWe ; ,~ lf4orHreJisf' , çfpfè'SênceJliiin"--' ^ "', ! KT/Coro ~ Contexte Clinique contexte clinique ~2 oui~ ----- 3 1 BICQ.ro., - -- lnglOgra2bi~aIY-?,"!9.lo ~~ ~ 3 oui ~~~~~~~~~ ~~ ~

<tb>
<tb> KT/Coro <SEP> Evènements <SEP> complications <SEP> dilat <SEP> 4 <SEP> oul <SEP> 7
<tb> KT/Corp <SEP> Données <SEP> d'inclusion <SEP> Inclusion <SEP> menu <SEP> 1 <SEP> non <SEP> 4 <SEP> 4
<tb> Coro <SEP> suivie <SEP> ATL <SEP> Contexte <SEP> Clinique <SEP> contexte~clinique <SEP> 2 <SEP> oui <SEP> 3
<tb> Coro <SEP> suivie <SEP> ATL <SEP> Evènements <SEP> complications <SEP> dilat <SEP> 5 <SEP> oul <SEP> 7
<tb> Coro <SEP> suivie <SEP> ATL <SEP> Angiographie~ <SEP> analyse <SEP> angio <SEP> 3 <SEP> oul <SEP> 9
<tb> Coro <SEP> suivie <SEP> ATL <SEP> Données <SEP> d'inclusion <SEP> inclusion- <SEP> menu <SEP> 1 <SEP> 1 <SEP> non <SEP> 4
<tb> Coro <SEP> suivie <SEP> ATL <SEP> Angroplastie <SEP> angioplastie <SEP> 4 <SEP> non <SEP> 8
<tb> ATL <SEP> programmée <SEP> Contexte <SEP> Clinique <SEP> contexte~clinique <SEP> 2 <SEP> oui <SEP> 3 <SEP> 3
<tb>

ATL programmée - E\Inl11en --- c(Jm!Ons~dllat 4 oui ~~~ ~

<tb>
<tb> ATL <SEP> programmée <SEP> Données <SEP> d'inclusion <SEP> inclusion <SEP> menu <SEP> 1 <SEP> non <SEP> 4
<tb> , <SEP> ATL <SEP> programmée <SEP> Angioplastie <SEP> angioplastie <SEP> ~~~~~~3 <SEP> non~~~~~~~~~~ <SEP> 8
<tb> Autre <SEP> Contexte <SEP> Clinique <SEP> contexte~clinique <SEP> 2 <SEP> oui <SEP> 3
<tb> Autre <SEP> Evènements <SEP> complications <SEP> dilat <SEP> 3 <SEP> oui <SEP> bzz <SEP> - <SEP>
<tb> Autre <SEP> Données <SEP> d'inclusion <SEP> inclusion <SEP> menu <SEP> 1, <SEP> non <SEP> ~~~ <SEP> 4
<tb>
A l'intérieur d'un formulaire, des contrôles de cohérence sur les données saisies peuvent être mis en place.

Les données saisies peuvent être interprétées selon trois niveaux. Les invariants de premier niveau sont des champs communs à tous les centres qui

peuvent être exportés de façon anonymisée vers un serveur central afin de pouvoir réaliser des travaux en commun. Les invariants de deuxième niveau sont des champs maintenus en local et identiques pour tous les centres (par exemple, toutes les données d'identification du patient). Les champs personnalisés du troisième niveau offrent une souplesse d'utilisation qui permet de répondre aux besoins de chaque utilisateur.

La base de données registre est constituée par l'ensemble des informations saisies dans les formulaires. A chacun des formulaires est associé une table qui contient les données.

Le module M-S comprend également un module de composition automatique de compte rendu à partir d'un formulaire médical.

En pratique, le module de composition comprend un dictionnaire contenant des champs de formulaire prédéfinis de type case à cocher, liste déroulante à choix unique ou multiple, champ de texte ou de valeur numérique associés chacun à un texte paramétrable.

Le module de composition automatique est consultable à distance à l'aide d'un navigateur pour tout utilisateur autorisé.

En réponse à une sélection d'un champ de formulaire par un utilisateur autorisé, le module de composition va chercher dans le dictionnaire le texte correspondant et transforme ledit champ sélectionné par le texte associé.

L'utilisateur autorisé compose ainsi automatiquement un compte rendu à partir d'un formulaire médical.

Le module de composition permet de paramétrer un ou plusieurs formulaires (1 à 3 chapitres par formulaire, et un nombre indéterminé de champs par chapitre comportant cases à cocher, listes déroulantes à choix unique ou multiple, champs de texte ou de valeurs numériques).

Une fois définis par exemple par l'administrateur de l'application médicale qui distribue également les droits de consultation, ces formulaires ainsi paramétrés permettent de générer automatiquement un compte rendu, en utilisant le module de composition automatique qui associe un texte choisi par l'utilisateur à tout champ de formulaire.

Un module d'extraction de requêtes permet d'effectuer tout type de traitement ou d'analyse statistique sur le contenu des différents formulaires. Le rapport ainsi généré automatiquement en cochant sur les champs des formulaires est enfin associé à différentes boites de textes paramétrables, dans lesquelles l'utilisateur peut introduire du texte libre.

Ce mode de composition structuré présente l'avantage, par rapport à la dictée classique d'un compte rendu sous traitement de texte, de générer automatiquement un texte en cliquant sur des champs paramétrables de formulaires, tout en constituant une base de données personnalisée, d'exploitation statistique facile.

Ce mode de composition est particulièrement adapté à la tenue de documents DSP, dont l'exploitation statistique représente un besoin constant.

Pour citer un exemple, l'outil M-S est applicable à un service d'explorations fonctionnelles, par exemple pour informatiser la mesure ambulatoire de la pression artérielle (application médicale MAPA), en créant un Dossier de Spécialité (DSP) selon les méthodes exposées ci dessus.

Ainsi, le laborantin exporte dans l'applicatif médical MAPA les documents générés par l'appareil ambulatoire déposé sur le patient. Le médecin responsable consulte sur le réseau de communication (Intranet) ces documents, et génère son rapport en cliquant sur des champs de formulaires préalablement définis (et éventuellement en ajoutant du texte libre). Tout poste utilisateur relié à l'Intranet peut consulter ces documents au moyen d'un simple

navigateur, en fonction de l'habilitation du consultant, distribuée soit de manière globale (droit de consultation de l'ensemble des dossiers du DSP), soit de manière ponctuelle (droit pour le référent de consulter uniquement les documents correspondant à ses propres patients).

D'autres documents de spécialités DSP peuvent être consultables avec les outils logiciels tels, dans un service de Cardiologie par exemple, que la tenue de pochettes d'ECG dans le dossier patient, l'électrocardiographie ambulatoire, l'électrocardiographie d'effort, les épreuves de stimulation endocavitaires , des registres médicaux notamment du syndrome coronaire aigu etc...

En référence à la figure 8, le module de gestion d'imagerie M-D est apte à gérer de l'imagerie médicale de type radiologie, échographie, médecine nucléaire, imagerie cardiaque...

Le module M-D combine un module de routage ROU de l'imagerie au standard général DICOM utilisé pour l'imagerie médicale, une interface avec le système d'information radiologique RIS, un registre paramétrable permettant la tenue de registres de spécialité REG selon les méthodes M-S exposées ci dessus et la publication de compte rendus illustrés CIR consultables par des utilisateurs distants COS1, COS2, COS3, combinant un compte rendu structuré tel qu'exposé pour le module M-S aux images statiques ou dynamiques routées par le module ROU.

Le module M-D permet de mettre en place en parallèle avec la couche de stockage d'imagerie, une couche de communication sécurisée de l'imagerie et des données qui lui sont associées (images statiques et dynamiques, rapports, registres de spécialité).

Tous ces éléments sont consultables à partir d'un interface de communication accessible avec un simple navigateur, selon une procédure sécurisée garantissant l'habilitation des consultants à accéder aux différents documents,

et agrégés au dossier du patient par l'intermédiaire du module M-A que l'on décrira plus en détail ci-après.

Une interface entre le module M-D et le serveur RIS permet d'importer dans le module M-D les éléments d'identification du patient et les différents attributs de chaque procédure comme décrit en référence aux figures 2 et 3.

Le Radiologue ou le Spécialiste AUT chargé de faire le compte rendu se connecte avec son mot de passe approprié au module M-D de l'Intranet Institutionnel. Sur ce module, il dispose des éléments qui lui permettront de visualiser les images et/ou les séquences d'images, et d'introduire ou de dicter son compte rendu.

L'outil M-D dispose en outre, comme l'outil M-S décrit ci dessus, d'une interface d'administration qui permet au gestionnaire de l'application de définir, pour chaque modalité d'imagerie, un ou plusieurs formulaires personnalisés.

En remplissant les champs de ces formulaires, le radiologue enrichit automatiquement son rapport, avec une syntaxe institutionnelle personnalisée et sa base de données, qui peut être exploitée grâce au module statistique incorporé dans l'outil M-D.

Ces statistiques peuvent être automatisées en fonction de requêtes préétablies, et exportées vers un centre de recueil sous la forme de fichiers de tableurs.

Cette facilité permet d'organiser des statistiques communes à partir de plusieurs centres disposant de l'outil M-D.

Les différents postes connectés à l'Intranet Institutionnel (ou à l'Internet, lorsque des passerelles entre l'Intranet et l'Internet sont établies, avec les niveaux de sécurité adéquats) peuvent accéder à l'interface du module M-D.

Le module M-D demande l'identification de l'utilisateur (par mot de passe, par CPS ou par empreinte biométrique).

Si le consultant a été déclaré dans la base des utilisateurs, il accède par une interface conviviale aux compte rendus et à l'imagerie des dossiers qui lui sont accessibles, les autres comptes rendus n'étant pas vus.

L'outil M-D est relié à l'annuaire du personnel de l'entreprise ANN. Ainsi, l'outil M-D permet à l'administrateur de l'application de délivrer des droits de consultations globaux à des individus ou à des groupes d'individus (exemple : Personnel médical catégorie Temps Plein du Service de Neurologie ).

En dehors de ces droits globaux de consultation, le radiologue ayant dicté ou introduit son compte rendu peut donner des droits ponctuels de consultation de ce compte rendu (et en conséquence de tous les compte rendus de la même modalité concernant le même patient) à un ou plusieurs utilisateurs et/ou à un ou plusieurs groupes d'utilisateurs, que ces utilisateurs soient introduits par l'interface de l'application M-D ou importés à partir de l'annuaire d'entreprise.

L'outil logiciel M-D comporte des modules de base qui permettent de paramétrer le routage des images, les formulaires éventuels et le compte rendu résultant.

Pour le majorité des modalités, ces fonctionnalités de base sont suffisantes pour établir les formulaires et les rapports souhaités.

Pour certaines modalités de routine , l'outil M-D peut se résumer aux fonctions les plus simples : associer l'imagerie sélectionnée à un compte rendu dicté.

A l'autre extrémité, pour des spécialités très pointues , une prestation complémentaire spécifique peut être nécessaire avec des formulaires spécifiques créés avec le module de création décrit ci-avant.

Le serveur intergiciel SIT comprend également un outil transversal M-A permettant l'agrégation autour de l'identité unique du patient des documents issus des progiciels spécialisés M-B, M-S et M-D. Tous les documents produits à travers les différents dossiers de spécialité gérés par l'outil M-S ou par l'outil M-D sont ainsi agrégés aux documents bureautiques produits par l'outil M-B, autour de l'identité unique du patient.

L'interface du module M-A permet le regroupement des données. Ce regroupement est rendu possible par une structuration des tables des différentes bases, permettant de remonter en amont des outils M-B, M-S et M-D les données qui intéressent l'établissement (la table d'identification des patients ou la table des utilisateurs de l'institution) et les données qui intéressent chaque service (la table des correspondants du service).

En premier lieu, on sélectionne un patient (en introduisant par exemple les deux premiers caractères de son nom. Le cas échéant on affine la sélection avec des critères de sélection telle que la date de naissance.

On affiche ensuite l'historique du patient et les différents icônes qui permettent (dans le cas d'un utilisateur ayant des droits de consultation et de modification sur les dossiers) d'accéder au rapport (pour modification et signature), au document publié PDF ou aux images, à l'envoi du document par messagerie nominative ou anonyme, et à la lettre associée au document destinée au correspondant.

D'une manière générale, le serveur intergiciel SIT a l'avantage de traiter les données médicales à partir de pages consultables à distance à l'aide d'un navigateur de type INTERNET. Par exemple, les pages sont écrites en un langage de programmation de type à balises, par exemple du type HTML, XML, ou analogue.

Claims

REVENDICATIONS 1. Dispositif de traitement de données médicales relatives à au moins une application médicale d'un groupe de patients, caractérisé en ce qu'il comprend un serveur de données (SIT) accessible à distance à l'aide d'un logiciel de navigation de type Internet et comprenant des outils logiciels (M-A, M-B, M-S, M-D) de création, consultation, composition, modification, et/ou diffusion de pages supportant des données médicales, consultables à distance à l'aide d'un logiciel de navigation, et aptes à traiter des pages destinées à supporter des données médicales relatives à au moins ladite application médicale, lesdits outils logiciels comprenant un module de création (M-S) de formulaire adapté pour permettre à un utilisateur distant de créer via une interface intuitive, souple, dynamique, et conviviale, des pages correspondant à un formulaire médical structuré en relation avec ladite application médicale.
2. Dispositif selon la revendication 1, caractérisé en ce que le module de création (M-S) < omprend un moteur de génération de formulaires médicaux sous la forme de pages consultables à l'aide d'un logiciel de navigation, ledit moteur étant relié à une base de données relationnelle possédant une pluralité de tables aptes à décrire les caractéristiques de chacune des pages d'un formulaire médical choisi.
3. Dispositif selon la revendication 2, caractérisé en ce que le moteur de génération (M-S) est adapté pour permettre à un utilisateur de créer des formulaires médicaux comportant un nombre choisi de chapitres, eux mêmes divisés en blocs comportant chacun un nombre choisi de champs de formulaire, les chapitres et blocs étant paramétrables au moyen d'une interface intuitive d'un navigateur de type Internet, par des utilisateurs sans connaissance préalable des outils informatiques.
4. Dispositif selon l'une des revendications précédentes, caractérisé en ce que lesdits outils logiciels comprennent en outre un module de composition automatique (M-S) d'un compte rendu à partir d'un formulaire médical, ledit

<Desc/Clms Page number 28>

module de composition (M-S) étant consultable à distance à l'aide d'un logiciel de navigation et comprenant un dictionnaire contenant des champs de formulaire prédéfinis associés chacun à un texte paramétrable et en ce que le module de composition automatique est apte en réponse à une sélection d'un champ de formulaire par un utilisateur distant à aller chercher dans le dictionnaire le texte correspondant, à modifier éventuellement le texte importé du dictionnaire et à transformer ledit champ sélectionné par le texte associé, ce qui permet à l'utilisateur distant de composer automatiquement un compte rendu personnalisé à partir d'un formulaire médical paramétrable.
5. Dispositif selon l'une des revendications 1 à 4, caractérisé en ce que lesdits outils logiciels comprennent en outre un module de consultation (M-A, M-B, MS, M-D) consultable à distance à l'aide d'un logiciel de navigation, apte en réponse à une demande de consultation d'un utilisateur distant à permettre audit utilisateur de consulter des documents médicaux d'un patient choisi, pour autant que son profil l'habilite à consulter ledit document.
6. Dispositif selon la revendication 4 et la revendication 5, caractérisé en ce que le module de composition de compte rendu (M-S) est accessible à partir du module de consultation (M-A, M-D, M-S, M-B) afin de permettre à un utilisateur distant autorisé de composer un compte rendu sur au moins un document médical ainsi consulté.
7. Dispositif selon l'une des revendications précédentes, caractérisé en ce que lesdits outils logiciels comprennent en outre un module d'agrégation (M-A) des documents médicaux d'un patient, ledit module d'agrégation (M-A) étant consultable à distance à l'aide d'un logiciel de navigation, et apte en réponse à une requête d'un utilisateur autorisé à regrouper dans un dossier plusieurs documents médicaux d'un patient.
8. Dispositif selon l'une quelconque des revendications précédentes, dans lequel l'application médicale (AM) est du type imagerie médicale, caractérisé en ce que lesdits outils logociels comprennent en outre une module d'imagerie

<Desc/Clms Page number 29>

médicale (M-D) consultable à distance à l'aide d'un logiciel de navigation et permettant à un utilisateur distant de traiter des documents d'imagerie issus de l'application d'imagerie, et à associer à l'imagerie statique ou dynamique un compte rendu structuré selon les revendications précédentes.
9. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits outils logiciels comprennent en outre un module d'indexation consultable à distance à l'aide d'un logiciel de navigation et comprenant une première entrée recevant des données nominatives relatives à un patient, en particulier en important la totalité ou une partie de ces données d'un ou de plusieurs serveurs médicaux institutionnels, et une seconde entrée recevant un document médical contenant des données médicales selon un format structuré par utilisation de formulaires paramétrables selon les revendications précédentes, et une sortie délivrant un document médical indexé à partir des données nominatives dudit patient.
10. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits outils logiciels comprennent des moyens de contrôle d'accès à chacun des modules de traitement de pages supportant des données médicales (M-A, M-B, M-S, M-D) et aux documents médicaux associés, selon une loi de distribution de droits d'accès choisie et une librairie des utilisateurs pouvant être importée à partir d'un annuaire d'entreprise.