FR 2878105 A1 20060519 FR 0452604 A 20041112 PROCÉDÉ D'AGRÉGATION DE DOCUMENTS PUBLIÉS PAR LES APPLICATIONS MÉDICALES La présente invention concerne une plateforme technique pour la circulation d'informations médicales entre différents groupes d'utilisateurs, avec des restrictions d'accès à certaines informations par certains groupes d'utilisateurs et des possibilités d'enrichissements incrémentaux des informations par un ou plusieurs utilisateurs, d'une manière traçable. La circulation rapide de l'information médicale au sein de l'hôpital devient un élément déterminant pour la qualité de la pratique médicale. Ces informations sont pour la plupart produites au sein des services spécialisés qui disposent de logiciels "métier". Tout ou partie de ces informations doit être rendue accessible au sein de l'établissement aux professionnels habilités qui sont amenés à prendre en charge le patient auquel ces informations sont associées. La problématique principale réside dans la mise en place d'une chaîne cohérente "d'alimentation" de ce dossier patient "partagé", basé sur un ensemble de "documents applicatifs", issus d'outils métiers ou d'outils de publication spécialisés: il s'agit d'un environnent hautement spécialisé, hétérogène, variable selon les métiers et dans un même métier selon les approches culturelles de tel ou tel centre hospitalier. Par contre, le portail de consultation doit permettre une vision homogène du dossier agrégé du patient, quel que soit l'outil métier ou de publication producteur, sécurisée pour préserver les droits des patients et garantir la confidentialité de l'information, obéissant aux grandes normes médicales internationales, et robuste pour permettre de maintenir un fonctionnement cohérent du portail quels que soient les dysfonctionnements du système d'information. L'objet de la présente invention est de présenter un procédé industrialisable permettant d'utiliser des outils métier et de publication hétérogènes du marché - présents dans les Etablissements de Santé (hôpitaux ou cliniques, ES dans la suite du texte) - pour permettre la mise en place normalisée, sécurisée et robuste d'un portail de consultation intranet et ville hôpital On connaît dans l'état de la technique différentes solutions de plateformes visant à faciliter la gestion de documents numériques dans un environnement de santé publique. Les brevets ci-après présentent une partie de l'état de la technique, auquel la présente invention vise à apporter une amélioration technique en terme de sécurité de l'agrégation de documents numériques et de gestion de ces documents numériques par différentes catégories d'utilisateurs. La demande de brevet internationale WO02067177 concerne un système informatisé permettant de produire et de tenir à jour un dossier médical électronique. Ce système comprend un ordinateur présentant une unité centrale de traitement, des instructions pouvant être exécutées par un ordinateur et destinées à être exécutées sur l'unité centrale de traitement, ainsi qu'un dispositif de saisie permettant de saisir des données de dossier médical dans une base de données de dossiers médicaux électroniques. Cette base de données de dossiers médicaux électroniques est en communication électronique avec l'unité centrale de traitement et stocke et organise des données concernant un participant. Le système informatisé est également en communication électronique avec un dispositif de sortie qui permet d'accéder à la base de données de dossiers médicaux électroniques et aux données qui y sont stockées. Le brevet anglais GB2385971 concerne l'utilisation de fichiers de soins de santé intégrés consacrés à des patients spécifiques, y compris les informations qui concernent l'administration de soins de santé aux patients et les informations qui concernent la gestion de l'administration des soins. On peut utiliser ce type de fichier dans le cadre d'un système de soins de santé pour faciliter la gestion et assurer les soins proprement dits. Il est possible d'enregistrer les deux catégories d'informations susmentionnées dans un fichier de patient universel, à raison d'un fichier par patient, sous les formes suivantes: données formatées, liens avec des données formatées, ou sélections à partir d'une liste. On distingue les trois variantes suivantes: fonction d'audit, par enregistrement de tout contact avec les fichiers en guise de piste d'audit; fonction de sécurité, avec contrôle de l'accès au système de fichier intégré; gestion de verrouillage, pour contrôler l'accès en écriture à ce système. Selon un autre aspect, l'invention concerne un système électronique d'informations sur les soins de santé, qui comprend un cadre modulaire et une fonction d'affichage liée à ce cadre, pour l'établissement d'une interface utilisateur graphique destinée aux utilisateurs du système. Le cadre en question englobe plusieurs activités, chacune portant sur tel ou tel domaine des soins de santé, et le cadre peut être adapté à des activités supplémentaires pour la mise en place d'un système unique intégré. L'interface utilisateur graphique peut être adaptée à l'affichage d'informations qui correspondent à une ou plusieurs activités, avec format de menu commun pour la présentation des opérations disponibles dans l'interface et composantes visuelles communes pour la présentation des informations aux utilisateurs du système. Le brevet australien AU018696OA5 concerne un système permettant de fournir de l'information en relation avec la santé publique et privée via un réseau ouvert. Le système comporte un serveur capable de communiquer avec les équipements clients via le réseau. Au moins une base de données, accessible par le serveur, conserve de l'information en relation avec la santé publique, et notamment des comptes rendus de presse qui se rapportent à la santé et sont prévus pour une diffusion grand public. La base de données conserve également en mémoire des définitions de différents groupes d'utilisateurs, et de l'information en relation avec la santé privée, et notamment des bulletins d'information ou des formulaires spécifiques d'organisations, prévus pour une diffusion uniquement aux membres des groupes d'utilisateurs. Le serveur fournit l'information se rapportant à la santé publique à n'importe quel appareil client, mais l'information se rapportant à la santé privée n'est fournie qu'aux membres d'un groupe auquel cette information privée s'applique. Les utilisateurs, et plus particulièrement ceux du monde médical et paramédical sont incités à utiliser le système dans la mesure où il fournit à l'utilisateur aussi bien des comptes rendus de presse grand public d'intérêt général que de l'information spécifique d'une organisation. Cela rend le système plus attrayant aux parrains qui souhaitent mettre des annonces en ligne, soit à destination de tous les utilisateurs, soit à destination de groupes d'utilisateurs spécifiques. Le brevet anglais GB0229681 concerne un système intégré qui fournit au patient un accès en temps réel, sécurisé, à un système d'informations relatives à la santé du personnel d'une entreprise et aux dossiers de santé personnels. Cet accès peut être fourni par Internet et via une page Web de portail traitant la santé personnelle. À partir de la page Web de portail sécurisée concernant la santé personnelle, les patients peuvent visualiser des informations créées et mises à jour par leur praticien. Les patients peuvent également demander des informations et des services à leur praticiens, avoir directement accès au système d'informations relatives à la santé du personnel d'une entreprise, comme la planification d'un rendez-vous, le paiement d'une facture, l'inscription à un cours, le remplissage de formulaires d'assurances et autre, et la visualisation d'informations et la fournitures d'autres prestations qui concernent leur état de santé particulier. La demande de brevet internationale WO0124038 concerne des procédés, un appareil et un support lisible sur ordinateur, qui permettent de rassembler des informations sanitaires, médicales et liées à l'état complet de bien-être destinées à établir un profil sanitaire de client. On rassemble les informations médicales et sanitaires relatives à un client en se fondant sur un profil sanitaire de ce client. Un fournisseur de service permet d'accéder à un profil sanitaire associé à ce client et de conserver ce profil. Ce profil sanitaire possède de nombreux événements qui reflètent des caractéristiques médicales, sanitaire ou liées au bien-être du client. On retrouve des informations relatives au client fondées sur ce profil sanitaire dans de nombreuses sources extérieures, telles que des serveurs Web et des bibliothèques de fichiers, à intervalle de temps prédéfinis ou à la demande du client. Les informations pertinentes sont affichées sur une interface utilisateur de façon à permettre au client d'évaluer efficacement ces informations. Le profil sanitaire et médical du client peut, par ailleurs, être modifié par l'interface utilisateur. La demande de brevet internationale W004051415 concerne un procédé informatisé destiné à l'intégration de données dans un processus de flux médical. Ce procédé consiste à recevoir des données liées à un patient, à initier une recherche informatisée de données sur la base des données liées au patient reçues, à recevoir les résultats de la recherche informatisée de données et à intégrer ces résultats de recherche au procédé de flux médical. La demande de brevet internationale W00195158 concerne un procédé et un appareil permettant de gérer et d'accéder à des informations relatives à un système informatisé. Ce procédé consiste à collecter des informations concernant l'état du système informatisé surveillant les informations, à traduire ces informations dans un format convivial, à poster ces informations conviviales sur un support accessible par le client et à permettre à un ou plusieurs clients d'accéder audit support. L'invention consiste également à générer une fiche de dérangement pour les problèmes liés au système informatisé, à poster ladite fiche de dérangement au support, à mettre à jour l'état des réparations en temps réel ou en temps quasi réel, enfin à enregistrer dans une base de données ladite fiche et chaque état supplémentaire de la réparation. La demande de brevet internationale W004038560 concerne, dans des modes de réalisation, des systèmes et des procédés de gestion d'essais cliniques. Un système de gestion d'essais cliniques comporte un client Web, un client, un serveur et une base de données d'enregistrement de patients. Le serveur offre plusieurs applications différentes qu'un utilisateur peut exécuter, en fonction de leur rôle dans le processus des essais cliniques. Ces applications sont divisées en composants principaux et secondaires. Dans un mode de réalisation exemplaire, il y a vingt-neuf composants principaux et secondaires. Les informations émanant de la base de données d'enregistrement de patients sont rapportées en fonction du rôle de l'utilisateur y accédant dans le processus d'essais cliniques. Les utilisateurs ayant des rôles différents sont des protagonistes, à savoir le promoteur, le régulateur, l'investigateur, le site, le patient et le surveillant. L'invention concerne également des procédés permettant de rapporter des informations relatives à des essais cliniques, de surveiller des événements en matière d'essais cliniques, de programmer et de suivre des rendez-vous, de fournir de bonnes informations cliniques, de conclure un essai et d'afficher des informations destinées aux protagonistes. Ces différentes solutions ne sont pas totalement satisfaisantes car elles ne permettent pas de sécuriser l'accès et les modifications des informations contenues dans le système d'information, ni de gérer de manière spécifique les modes d'accès à ces informations. L'invention vise à résoudre les problèmes techniques que posent ces solutions de l'art antérieur, par une solution constituée par une plateforme comprenant des moyens permettant de dissocier l'acquisition et les modifications de manière traçable des documents numériques, et l'accès par un groupe d'utilisateur à des documents agrégés sans risque de modification des documents originaux, à partir de réseaux informatiques distincts ou identiques mais dans ce dernier cas avec des modes d'accès différenciés. L'invention concerne à cet effet, dans son acception la plus générale, une plateforme informatique comprenant une pluralité de modules métiers constitués par des moyens techniques d'acquisition de données numériques, une pluralité de moyens techniques de publication permettant de produire des documents numériques enregistrés sur un premier serveur sécurisé accessible sur un premier reseau informatique muni de moyens de normalisation et de publication des documents et d'enregistrement dans une base de donnée relationnelle, ainsi qu'un second serveur sécurisé accessible par un second réseau informatique, lesdits serveurs étant isolés physiquement, le second serveur comportant une réplication d'une partie paramétrable du contenu du premier serveur, avec une actualisation périodique. Avantageusement, cette plateforme comprend une architecture matérielle et logicielle comportant lesdits moyens de normalisation et de publication des documents, un portail d'accès, un coffre-fort électronique, un serveur Web d'imagerie au standard DICOM, une base de données relationnelles et un langage de programmation permettant le déploiement d'applications Web autour de la base de données relationnelle. Selon une variante préférée, les documents sont définis par une liste minimale d'attributs associés aux documents et/ou aux procédures d'imagerie, et une syntaxe (conforme aux standards XML, HL7 et IHE) permettant de bâtir des enveloppes d'échange normalisées. L'invention concerne également un procédé électronique de gestion et de circulation de documents numériques comprenant des étapes d'acquisition d'information par l'intermédiaire d'une pluralité de modules métiers , des étapes de production de documents numériques enregistrés sur un premier serveur sécurisé accessible sur un premier réseau informatique par l'intermédiaire d'une pluralité de moyens techniques de publication munis de moyens de normalisation et de publication des documents et d'enregistrement dans une base de donnée relationnelle, et des étapes de publication de documents agrégés auprès d'utilisateurs à partir d'un second serveur sécurisé accessible par un second réseau informatique, lesdits serveurs étant isolés physiquement, le second serveur comportant une réplication du contenu du premier serveur, avec une actualisation périodique. De préférence, ce procédé comporte des étapes de notification de publication d'un document consistant à générer une enveloppe XML-HL7-IHE à partir des attributs associés à tout document et à acheminer au portail lesdits attributs, et à convertir le document en un format numérique prédéfini (notamment PDF ou XML) préalablement à l'acheminement vers le coffre-fort électronique. Selon des variantes, le procédé selon l'invention comprend des caractéristiques additionnelles suivantes: - un traitement: É de compression des images statiques ou des images dynamiques; d'archivage d'images sélectionnées sur un serveur Web au standard d'imagerie DICOM; É de transmission des attributs minimaux associés à la procédure aux moyens (7) de normalisation et de publication des documents selon un format informatique prédéfini, comportant notamment les adresses URL permettant de visualiser conjointement à partir d'un explorateur Internet la procédure d'imagerie sur le serveur Web d'imagerie, et les documents associés à l'imagerie. lors de la notification de publication d'une procédure d'imagerie statique ou dynamique, une étape de génération et d'acheminement vers le serveur d'une enveloppe XML-HL7-IHE à partir des attributs transmis par le serveur d'imagerie; 20 le portail intègre dans sa base de données relationnelle l'ensemble des éléments contenus dans les enveloppes normalisées transmises par les moyens de normalisation et de publication, comportant notamment les URL permettant de pointer vers le document correspondant (archivé dans le coffre-fort électronique) et vers la procédure d'imagerie correspondante (archivée dans le serveur Web d'imagerie) ; - tout document est accessible à partir des éléments archivés dans la base de donnée relationnelle du portail - provenant des enveloppes HL7 et des données transmises de manière asynchrone par le GIP (Gestionnaire d'identité patient de l'établissement) et l'annuaire d'entreprise; une partie au moins des données du coffre fort électronique et du serveur Web d'imagerie est externalisé, c'est-à-dire copié dans une configuration de même architecture située à l'extérieur, pour autant que les enveloppes normalisées associées aux documents concernés soient également mises à disposition d'un hébergeur agréé extérieur. Le procédé selon l'invention comporte additionnellement: - une étape d'export des images destinées à être imprimées et/ou des comptes-rendus associés aux images à partir d'un plateau technique d'imagerie, qu'il soit ou non pourvu d'un système d'archivage local au format DICOM; - une étape d'intégration de ces documents et images à l'ensemble du dossier patient contenu dans le portail d'agrégation; - des étapes de saisie, modification et signature des documents d'imagerie et d'intégration automatique des documents et des images correspondantes à l'ensemble des documents du dossier agrégé du patient; - une étape d'identification conditionnant l'accès à l'annuaire d'entreprise et déterminant l'identité et le statut de l'intervenant, ainsi que l'identité et le statut de l'ensemble des patients présents. L'invention sera mieux comprise dans la description qui suit, concernant un exemple non limitatif de mise en oeuvre se référant aux figures 1 à 4 et des fiches 1 à 3. La figure 1 est un descriptif du procédé selon l'invention dans une configuration INTRANET destinée à la consultation du portail pour les seuls intervenants autorisés de l'Etablissement de Santé (dénommé ES cidessous). Les modules 1, 2 et 3 représentent les outils métier de l'ES. Ces outils métiers comprennent des outils d'imagerie (1) constitués par les installations fournissant de l'imagerie statique ou dynamique aux radiologues (angiographie, scanner, résonance magnétique...), à la médecine nucléaire, aux cardiologues (angiographie, échographie), aux ophtalmologues, etc. La plupart de ces appareils répondent à la norme DICOM d'acquisition et de transfert des images. Ces outils d'imagerie (1) comprennent donc l'appareillage (de scanner par exemple), les consoles avancées qui permettent de travailler l'image, et le système d'archivage local qui permet aux spécialistes d'archiver pour une durée plus ou moins longue les images et de les analyser au moyen des consoles avancées, en utilisant le standard DICOM pour l'analyse et la communication des images. Ces outils métiers comprennent également des outils de biologie (2) qui permettent toutes les analyses notamment du sang ou des urines: ces outils comprennent des automates et des systèmes informatiques reliés aux automates permettant de produire sous forme chiffrée le résultat des analyses et de les publier sous forme de documents, imprimés ou transmis. Ces outils métiers comprennent aussi les outils de soin (3) qui permettent aux médecins de prescrire les traitements et aux infirmières d'appliquer le plan thérapeutique, ou les secrétariats médicaux (comportant des traitements de texte permettant de faire la saisie des comptes-rendus et des courriers, directement ou par utilisation d'outils de transcription numérique). Les modules 4, 8 et 6 représentent les outils de publication spécialisés de l'ES. Ces outils de publication spécialisés comprennent le module de communication (4) du serveur Web d'imagerie: ce module (4) met à disposition - dans un format comprimé - les images au format DICOM non comprimées sélectionnées dans le module 1, et les exporte vers la baie de stockage N 9 du serveur d'images, d'où elles sont consultables à partir d'un navigateur Internet. Il existe un lien entre le module 4 et le module 6, comme cela sera explicité plus loin. Le module de communication (4) exporte vers le module 7 en format DICOM les attributs DICOM de l'étude (appelés DICOM Worklist'). Ces outils de publication spécialisés comprennent aussi un serveur (5) de diffusion des résultats biologiques, qui permet la diffusion des résultats du module 1 sous la forme de documents, le plus souvent consultables à travers un navigateur, sinon sous la forme de documents physiques'. Ces outils de publication spécialisés comprennent encore un serveur de bureautique (6) et de formulaires médicaux qui permet: - aux secrétariats de produire des documents, par transcription de courriers dictés; - aux médecins de produire directement des comptes-rendus d'examen soit sous forme textuelle (en saisissant au clavier les comptes-rendus ou en les dictant à un outil de transcription vocale), soit sous forme structurée (dans ce cas le médecin dispose de formulaires médicaux, et le compte-rendu est généré automatiquement lorsque le formulaire est rempli dans sa totalité, au moment de la signature électronique) ; - aux outils de soin de communiquer avec des dossiers de spécialité, par l'intermédiaire de formulaires médicaux spécialisés (dans ce cas le document correspondant est produit de la même manière que pour le point ci-dessus). Il convient de remarquer qu'il doit exister une liaison entre les modules 6 et 4, de manière à mettre éventuellement en correspondance les comptesrendus avec les images correspondantes. D'une manière générale, il convient de remarquer que plusieurs systèmes sont disponibles commercialement qui permettent de remplir les fonctions des modules 1 à 6 tels qu'exposés ci-dessus. Le compte rendu est dans tous les cas rendu disponible à la consultation lors de la signature électronique par le professionnel de santé habilité. Le procédé faisant l'objet de la présente invention a pour but d'organiser le flux de données entre ces différents modules, en mettant en place une architecture matérielle et logicielle de manière à permettre la mise en place normalisée, sécurisée et robuste d'un portail de consultation intranet permettant une vision agrégée de l'ensemble des documents concernant un patient, quel qu'en soient les outils métier ou de publication d'origine. La solution comprend également un module de normalisation et de publication (7) des attributs des documents produits par les modules 1 à 6, qui comporte deux fonctions. - la normalisation des documents physiques et leur transfert vers le module 8: on entend par documents physiques les documents produits par les modules 5 ou 6 sous une forme matérielle (par exemple sous la forme d'un document Word, ou PDF, ou d'un fichier Excel ou PowerPoint notamment, mais non exclusivement). Le module 7 a pour fonction de convertir ces documents hétérogènes en un format normalisé retenu par l'ES, notamment les formats PDF ou XML. Dans le cas où le document serait produit par l'outil de publication sous la forme d'un lien vers les modules 5 ou 6 permettant d'ouvrir le document sur un navigateur, le module 7 convertit ce document en document physique normalisé et le transfère au module 8; la production d'une enveloppe normalisée d'attributs au standard XML-HL7-IHE. Toute publication de document par les modules 4 à 6 correspond à un certain nombre d'attributs associés au document. Ces attributs sont par exemple le nom du patient, son numéro d'identification dans l'ES, le type de document produit, le signataire du document, le service de l'ES auquel appartient le signataire etc. Ils comportent également des attributs destinés à l'externalisation des documents, attributs qui seront décrits plus loin. La fiche N 1 synthétise les attributs minimaux que les modules 4 à 6 doivent fournir au module 7. Ces attributs peuvent être fournis sous un format quelconque au module 7 (pour autant que le format soit précisé formellement, par exemple un fichier Txt, ou Excel, etc.). Doit être également précisé au module 7 s'il s'agit: 1/ d'un document principal (par exemple un compte-rendu d'hospitalisation) 2/ d'un documents associé au document principal (c'est par exemple un compte- rendu opératoire associé au compte-rendu d'hospitalisation, ou la lettre du praticien qui adresse le patient etc.) 3/ d'une Imagerie associée au document principal (ce sont les images associées au document principal, consultables au niveau du module 4 en activant l'URL de localisation précisé dans la fiche N 1) Ces attributs seront transférés par le module 7 dans un répertoire adéquat du portail d'Agrégation des Documents publiés par les Applications Médicales, ADAM dans la suite du document, après conversion en enveloppe normalisée le module 7 assurera la conversion des attributs transmis par les modules 4 à 6 lors d'une publication de document en langage XML et selon le standard normalisé médical international HL7, compliant avec le standard des normes médicales internationales IHE (Information Hospital Enterprise). La fiche N 2 donne un exemple non limitatif d'une enveloppe normalisée XML-HL7- IHE correspondant aux attributs IHE de la fiche N 1 transmis par le module 7 au portail ADAM. Ce fichier normalisé d'attributs sera nommé ci- dessous enveloppe normalisée . En résumé, le module 7, dès réception de la notification d'une publication de document par les modules 4 à 6, transmet le document correspondant sous un format normalisé (notamment PDF ou HL7) au module 8, et l'enveloppe normalisée correspondante au portail ADAM après conversion adéquate des attributs fournis par les modules 4 à 6 au format d'échange XML-HL7-IHE. S'agissant des images, transférées en format DICOM sous forme comprimée du module 4 vers le module 9, le module 7 construit l'enveloppe HL7 correspondante à partir des attributs de la DICOM worklist transmis par le module 4 et également des attributs pour l'étude considérée qui lui parviennent du module 6: en effet, le module 4 et le module 6 participent à la définition complète des attributs de l'enveloppe HL7 d'attributs de l'imagerie, de manière à lier le document principal (compte-rendu d'imagerie) aux images correspondantes., et achemine cette enveloppe vers le portail ADAM, comme précisé dans les fiches N 1 et N 2. Ce lien est effectué au niveau du module 6 par l'opérateur d'imagerie qui associe les images d'une étude DICOM au compte- rendu correspondant qu'il saisit ou qu'il dicte au niveau du module 6. La plateforme comprend un coffre-fort électronique (8) où sont déposés les documents physiques par le module 7, comme exposé ci-dessus. Il s'agit d'un serveur de stockage sécurisé, comportant les dispositifs de backup et de redondance adéquats nécessaires pour garantir une sécurité maximale des documents archivés. Une baie de stockage (9) du serveur Web d'imagerie, contient l'enregistrement des images sélectionnées et comprimées, comme cela a été précisé ci-dessus. Ces images sont accessibles à travers un explorateur Internet à partir d'une URL pointant sur l'étude précisée dans l'enveloppe HL7 d'attributs, comme cela a été précisé ci-dessus. L'invention comprend une couche logicielle construite autour des technologies de l'Internet permettant d'organiser, pour chaque typed'examen caractérisé par un code d'examen (pouvant être un code normalisé IHE) et un libellé d'examen, la consultation du document principal, du ou des documents éventuellement associés et de l'imagerie éventuellement associée au document principal. Le portail ADAM est connecté à 3 modules et obéit à des règles de consultation établies par l'ES: premier module: le Gestionnaire d'Identité Patient ou GIP: il s'agit du serveur d'identité de l'ES, qui comporte d'une part des renseignements sur le patient (notamment un numéro unique d'identification au sein de l'ES), d'autre part des renseignements sur le statut et les mouvements du patient: a tout instant il est ainsi notamment possible de connaître le statut du patient (hospitalisé ou consultant ou venant réaliser un acte externe) ou ses mouvements au sein des différentes unités de soin de l'ES. Ces renseignements sont transmis de manière très rapprochée au portail ADAM (par exemple toutes les 5 minutes) au moyen par exemple d'une messagerie, ou par tout moyen de communication asynchrone adopté par l'ES. - deuxième module: l'Annuaire d'Entreprise. Il s'agit d'un annuaire, pouvant notamment mais non exclusivement obéir au standard LDAP, qui renseigne périodiquement - de manière également asynchrone, notamment au moyen d'une messagerie ou par tout autre moyen asynchrone de communication défini par l'ES - le portail ADAM (par exemple de manière hebdomadaire) sur l'identité et le statut des différents intervenants médicaux et non médicaux de l'ES, ainsi que sur leur affectation dans les différentes unités administratives ou de soin définies dans l'ES. troisième module: il s'agit du module 7 qui transmet au portail ADAM les enveloppes normalisées, comme cela a été décrit ci-dessus dans le détail. Le portail ADAM est bâti autour d'une base de données relationnelle, par exemple mais non limitativement Oracle. Cette base de données effectue la relation entre les patients (définis par leur numéro unique d'identification), les différents attributs transmis par les enveloppes HL7 et les différentes données d'identification et de statut importées du GIP et de l'annuaire d'entreprise. Lorsqu'un acteur de l'ES se connecte au portail au moyen d'un identifiant et d'un mot de passe ou tout autre type d'identification (notamment une carte professionnelle de santé ou une identification biométrique), il est identifié dans sa fonction au niveau de l'ES et - en relation avec cette fonction - des règles peuvent être appliquées définissant quels patients - au moment de la connexion peuvent être consultés en fonction notamment de la provenance des documents (selon qu'ils proviennent ou non de l'unité médicale à laquelle appartient le consultant) et selon le statut du patient. Pour donner un exemple concret, la fiche N 3 illustre - non limitativement - un type de règles qu'un ES peut mettre en place pour la consultation des documents d'un patient par le corps médical. On y remarquera que, dans cet exemple, l'ES choisit de permettre au médecin qui demande à consulter un patient dont il n'a pas le libre accès de forcer les droits en attestant des raisons qui justifient cette demande: on comprend l'importance pour la couche logicielle du portail ADAM de fournir aux administrateurs une traçabilité complète des accès des différents intervenants et consultants, ainsi que des boites à outil paramétrables permettant de mettre facilement en place de telles règles d'accès. Les enveloppes normalisées, l'annuaire d'entreprise et le GIP permettent donc de construire en temps réel la base de données relationnelle permettant de pointer vers les documents et vers les images archivés au niveau des modules 8 et 9. La transmission des données de l'annuaire d'entreprise et du GIP se faisant de manière asynchrone, le fonctionnement du portail est assuré indépendamment des dysfonctionnements éventuels du système d'information hospitalier: par exemple si le GIP ou un des modules 1 à 6 tombaient en panne, il resterait possible de consulter tous les documents et toutes les images transmis aux modules 8 et 9 jusqu'au moment de la panne, pour autant que la base de données relationnelle du portail ADAM et les modules 8 et 9 fonctionnent normalement. La figure 2 est un descriptif du procédé selon l'invention dans une configuration EXTRANET destinée à la consultation du portail à partir de l'extérieur de l'ES, notamment dans le cadre d'une consultation du Dossier Patient Partagé au niveau régional, ou national, voire international. Il implique la présence d'un opérateur agréé et de règles d'accès aux documents définis par les autorités sanitaires et politiques. Le procédé objet de la présente invention permet justement à l'ES de s'adapter très facilement aux obligations et aux contraintes imposées par ces autorités. On reconnaît la partie gauche de la figure, des modules 1 à 8, qui correspond à la description faite ci-dessus de la figure 1. On se souvient lors de la description des attributs de l'enveloppe HL7 construite par le module 7, que nous avons indiqué que des attributs d'externalisation seraient associés aux documents dans le cadre d'un projet de Dossier Patient Partagé externalisé. Ces attributs sont notamment: 1/ la notion de document exporté ou non exporté pour chaque document, le praticien qui signe ce documents décide si ce document est destiné à rester à l'intérieur de l'ES ou doit être externalisé. Des règles peuvent par ailleurs être appliquées selon les disposition juridiques imposées et le type de document concerné (par exemple les comptes-rendus d'hospitalisation peuvent être systématiquement externalisés alors que certains documents concernant le patient peuvent rester en interne, notamment s'ils concernent des problèmes d'enseignement ou de recherche). 2/ Pour les documents exportés, la notion de document non accompagné ou de document accompagné qui sera explicitée plus loin. Le module 10 est une copie d'une partie paramétrable du contenu des modules 7 et 8, faite au niveau d'un coffre fort électronique externalisé, au moyen d'une liaison d'un débit adéquat entre l'ES et L'hébergeur agréé. Le module 9 est un répertoire adéquat du système d'information mis en place par l'hébergeur agréé. Ce répertoire est alimenté régulièrement par les enveloppes HL7 provenant du portail ADAM correspondant à l'attribut document exporté . Le système d'information de l'hébergeur agréé reçoit donc les enveloppes d'attributs des documents du portail ADAM destinés à être externalisés, et peut donc pointer sur ces documents (et éventuellement les images associées) déposés dans le module 10. L'hébergeur agréé peut établir une relation entre l'identité du patient exporté par le portail ADAM d'un ES et une identité globale (par exemple une identité nationale) au moyen d'une technologie appropriée de serveur d'identification, qui reste sous la responsabilité de l'hébergeur en fonction notamment des disposition juridiques correspondantes. Si les règles d'export de documents viennent à changer (par exemple si on décide d'externaliser certains documents qui étaient restés à l'intérieur de l'ES), il suffit de modifier au niveau des modules 5 ou 6 l'attribut document non exporté de ces documents en document exporté pour que de nouvelles enveloppes normalisées soient émises au module 7, et que ces documents deviennent consultables - éventuellement associés à des documents associés et à de l'imagerie - sans que le contenu du module 10 ne doive être modifié, par une opération très légère portant seulement sur l'échange de fichiers XML. Dans une variante du même procédé, seuls les documents et/ou les images correspondant à l'attribut document exporté sont externalisés au niveau du module 10. Dans cette configuration, si un document contenu dans les modules 8 ou 9 doit être externalisé, les données correspondantes (document ou image) seront transférées secondairement au module 10 en même temps que les enveloppes HL7 correspondantes seront émises vers le module 7. La figure 3 (les numéros de la figure 3 déjà attribués correspondent à ceux déjà cités et définis dans les figures 1 et 2) est un descriptif du procédé selon l'invention dans une configuration plus particulièrement destinée à illustrer le fonctionnement d'un système d'imagerie en relation avec le portail ADAM. L'imagerie, de par le volume considérable qu'elle représente en termes de capacités de stockage, est en effet un des points clés pour apprécier le caractère opérationnel d'un portail d'accès au dossier patient partagé. Trois scénarios sont décrits - permettant d'optimiser le travail d'un service d'imagerie en relation avec le procédé ADAM et selon les niveaux d'équipement de ce service - selon que le service d'imagerie est ou non équipé d'un système d'archivage local (module 1) et/ou d'un système d'information évolué dédié à l'imagerie (ou RIS Radiology Information System, module 11), prenant notamment en charge de manière adéquate la production de comptes- rendus d'imagerie au sein même de l'outil métier centres ne disposant pas de la solution Archivage local et travaillant avec un RIS peu évolué, ne prenant pas en charge la gestion des comptes-rendus: le RIS (module 11) transfère aux modalités la DICOM Worklist, qui contient en format DICOM un certain nombre d'attributs de l'examen. Les modalités transfèrent automatiquement au module 4 par le protocole DICOM les images destinées à être archivées par le serveur Web d'imagerie (module 8). Le module 4 communique au module 6 les attributs de la DICOM Worklist et des images, le module 7 produisant l'enveloppe normalisée correspondante, comme explicité ci- dessus. L'opérateur dispose sur le module 6 d'outils logiciels: 1/ une joblist de transcription lui permettant: a/ de consulter par ordre alphabétique ou par modalité la liste des examens en attente de compte- rendu; b/ de visualiser les images correspondantes, c/ de transcrire vocalement numériquement le compte-rendu, de l'indexer et de le signer électroniquement. 2/ une joblist de mise à jour lui permettant de consulter les dossier d'imagerie et les comptes-rendus associés, de les modifier et de les re-signer électroniquement Tout compte-rendu signé est publié sur ADAM sous la forme d'un document PDF transféré par le module 7 au module 8, et d'une enveloppe HL7 transmise par le module 7 au portail ADAM, permettant notamment la visualisation des images à partir de tout poste du réseau équipé d'un navigateur Internet. Les dossiers d'imagerie sont ainsi automatiquement agrégés autour de l'identité unique du patient par le portail ADAM; centres disposant de la solution Archivage local et travaillant avec un RIS peu évolué, ne prenant pas en charge la gestion des comptes-rendus: le scénario précédent reste inchangé, mais le flux des images est optimisé à la production par le module 1 (système d'archivage local ) , qui: 1/ assure l'archivage exhaustif et définitif des images en format DICOM selon des modalités propres à chaque centre 2/ optimise les flux d'imagerie entre les modalités et les stations de visualisation et de traitement avancé, notamment pour les séquences comportant un grand nombre d'images; 3/ permet de transférer au module 4 des images sélectionnées ou reconstruites selon le choix des opérateurs (flèche N 14 de la figure) ; centres disposant de la solution Archivage local et travaillant avec un RIS évolué, prenant en charge la gestion des comptes-rendus et obéissant au standard HL7-IHE: Le scénario précédent est rendu encore plus fluide. Dans ce cas le compte rendu ainsi que les attributs qui lui sont associés peuvent être transférés par le module 1 au module 6 au format HL7- IHE (trait N 15 du schéma), au sein même de l'outil métier . L'avantage de cette organisation est non seulement que la création et la signature du compte rendu peut être totalement intégrée au lieu de production, mais que la disponibilité en parallèle de la plateforme ADAM permet de plus créer ou de modifier ultérieurement et de re-signer si nécessaire- un compte rendu à partir de tout poste de l'établissement relié au module 6, distant de l'outil métier . La figure 4 est un descriptif du procédé selon l'invention permettant une représentation schématique de l'accès au portail ADAM par un intervenant interne à l'ES Tout intervenant interne à l'ES dispose d'un identifiant et d'un mot de passe permettant de le relier: 1/ à l'annuaire d'entreprise, ce qui permet de l'identifier (l'identification comportant tous les renseignements sur l'identité et sur le statut au sein de l'ES) ; 2/ au Gestionnaire d'Identité Patients (GIP) de l'ES (ce qui permet de connaître l'identité, le statut et les mouvements de l'ensemble des patients ayant eu au moins une venue dans l'ES) Le statut de l'intervenant comporte notamment le caractère médical ou non médical de l'activité exercée, le ou les services dans lequel l'intervenant travaille, son rang et l'activité au sein de ce service Le statut du patient comporte notamment le type de venue au moment de la connexion (hospitalisation, consultation ou acte externe) sa localisation dans une unité de soin au moment de la connexion, les mouvements au cours d'une venue Dans une deuxième configuration du même procédé, l'identification de l'intervenant peut se faire par un autre moyen, notamment par carte CPS ou identification biométrique De la connaissance simultanée de l'identité et du statut de l'intervenant se connectant et des patients présents dans le GIP au moment de la connexion peuvent découler des règles d'accès aux documents. L'architecture logicielle du portail doit permettre un paramétrage simple de ces règles par l'administrateur du système. La fiche N 3 donne un exemple de telles règles, pouvant être appliquées à un ES pour servir de base à la consultation des documents: ces règles doivent en effet pouvoir être décidées par les instantes décisionnaires de l'ES en accord avec les dispositions légales et avec les règles adoptées par la CNIL pour garantir la sécurité et la confidentialité des informations. Une fois identifié, l'intervenant peut accéder au patient de son choix, par une interface représentée 10 schématiquement dans la figure 3, permettant: - d'accéder directement aux documents autorisés; - de n'accéder aux documents du patient d'accès restreint qu'après avoir justifié des raisons de la demande d'accès (voir notamment la fiche N 3, où l'exemple fourni permet l'accès aux documents restreints dans le cas où il s'agit d'une urgence médicale ou si la consultation des documents est nécessaire dans le cadre de la dispensation de soins au patient par le médecin demandant l'accès au dossier) - de disposer d'une vue synthétique permettant l'accès direct au document principal et - le cas échéant - au ou aux documents associés au document principal et à l'imagerie associée, tels que définis ci-dessus. S'agissant de l'accès aux documents à travers un hébergeur agréé externe tel que défini au niveau de la figure 2, les modalités d'accès aux documents seront définis par l'hébergeur en fonction des dispositions qui lui auront été confiées par les autorités lui ayant confié son mandat. ANNEXES Fiche N 1 Interface avec ADAM Fichier d'échange XML Objectif Fournir les données nécessaires à la publication de documents dans ADAM au travers d'un fichier XML Description des données à transmettre On peut définir 4 familles de données à transmettre: É Les informations Patient ^ Le document principal É Les documents associés (document indexé Imagerie Son) INFORMATIONS PATIENT Variable Description Exemple 1 NIP* N identification 1230456789 Patient NOM* Nom DUPONT PNOM* Prénom Charles DATNAI* Date de naissance 1965-12-15 00:00:00 SEXE* Sexe (M/F) M NOMPAT Nom patronymique FRION (*) variables obligatoires DOCUMENT PRINCIPAL Variable Description Exemple 1 Exemple 2 TP_EXM* Libellé examen MAPA Scanner cérébral en urgence CD_EXM Code examen TêteCraneUrgence STATUTNENUE Statut de l'examen (3 items Hospitalisation Consultation possibles) ^ Hospitalisation É Consultation ^ Acte Externe DT_EXM* Date examen ou 2003-12-15 2003-12-15 00:00:00 Date de transcription du document 00:00:00 CD_SIGN* Code signataire SIGNATAIRE Auteur de la signature Dr Dumont Pr Fabre DT_SIGN* Date de signature 2003-12-15 2003-12-28 00:00:00 00:00:00 CD_HOP* Code hôpital LRB LRB SERV_PROD** Codes des services producteurs 22 CARDIO SERV_DEST** Codes des services destinataires 24 RADIO ID_DOC* Identifiant du document LRB22031027161 LRB53031027161483 VERSION* Version du document 1 CONFIDENTIALIT 0 Non accompagné 1 0 E* 1 - Accompagné URL* Localisation du document (*) variables obligatoires (**) 1 ou plusieurs services DOCUMENTS ASSOCIES Variable Description Exemple 1 TITRE Commentaire de l'infobulle du Courrier du Dr Tardy du 12/12/2002 document indexé ID_DOC* Identifiant du document LRB2203102716142_FILS1 URL* Localisation du document 1SERVICE1ldocumentslpublication12565238009\ LRB2203102716142_FI LS 1.pdf IMAGERIE ASSOCIEE Variable Description Exemple 1 MODALITE* Modalité d'imagerie XA ID_DICOM* Identifiant DICOM examen 1. 25335.2214.2225786 URL* Localisation de l'imagerie http://164.1.103.158/ 28 Correspondance balise HL7 Balise HL7 Description Remarques id Identifiant unique du document principal version_nb Version du document path Localisation du document mod_code Code Examen txt Libellé Examen effective_time Date + heure de réalisation d'examen ou de transcription du document availability_time Date+ heure de signature confidentiality Niveau de confidentialité : 0-Non accompagné 1-Accompagné id root NIP family Nom du patient given Prénom du patient gender Sexe (F/M) birthdate Date de naissance du patient (aaaa-mm-dd) br_family Nom patronymique du patient type_evt Statut de l'examen (3 items possibles) : Hospitalisation Consultation Acte Externe id root Code Signataire supervisor Nom du signataire id root Code Auteur author Nom de l'auteur organization Code hôpital tracker Code service destinataire Quelques précisions ^ Un fichier.ini du même nom est systématiquement créé après la création du fichier XML (afin de confirmer la fin de génération du fichier XML) ^ Les fichiers sont déposés dans un répertoire EXPORT FICHE N 2 EXEMPLE DE FICHIER NORMALISE XML AU STANDARD HL7 CORRESPONDANT AUX ATTRIBUTS DE LA FICHE N 1 040907164752 2 http://164.1.99. 100/pdfmiddlecare/bmiddlecare/SERVICE4/documents/publication /2600041983/pdf/040907164752_2. pdf CR Hospitalisation 2004-09-07 00:00:00 2004-09-22 12:00:10 1 RHUMATOLOGIE A 01 RHUMATOLOGIE B 05 Document principal CR Hospitalisation 040907164752 http://164.1.99. 100/pdfmiddlecare/bmiddlecare/SERVICE4/documents/publi cation/260004 1983/pdf/040907164752_2. pdf Document indexé Imagerie indexée Son indexé 2600041983 STEFANINI Lucette F 1935-04-23 Hospitalisation APH3197889 Dr HYNAUX APH0501201 Dr DIEUDE LRB 01 05 Fiche 3 Exemple de règles médicales d'accès aux documents à travers le portail ADAM Accès par le corps médical identifié de l'hôpital aux documents publiés sur ADAM, à partir de l'Intranet du groupe Lariboisière- FW Niveau de sécurité des accès: code des enveloppes XML d'attributs 1: accès restreint aux documents pour les urgences 2: accès aux documents pour les intervenants médicaux du même service (documents produits parle service ou adressés au service) ou pour les patients hospitalisés 3: accès aux documents pour les intervenants médicaux de tous les services ADM: accès déclaré autorisé pour besoins médicaux. L'intervenant médical s'identifie et déclare nécessiter l'accès aux documents pour des raisons médicales ADR: accès déclaré autorisé pour besoins de recherche ou d'enseignement. L'intervenant médical s'identifie et déclare nécessiter l'accès aux documents pour des raisons de recherche ou d'enseignement. Il s'engage à anonymiser les documents diffusés. AAC: accès accompagné : le document ne pourra être consulté parle patient qu'en présence d'un professionnel de santé. Exemple de règles d'accès 1. Tous les médecins identifiés d'un service peuvent consulter tous les documents de tous les patients du service, publiés par le service ou adressés au service par un autre service (Niveau 2 par défaut). 2. Tous les médecins identifiés d'un service peuvent consulter tous les documents (quel que soit le service éditeur) de tous les patients hospitalisés dans le service (Niveau 2 par défaut) 3. Tous les médecins identifiés de l'hôpital peuvent consulter tous les documents des patients ayant au moins un document publié sur ADAM à condition d'attester (traçabilité des demandes assurée par ADAM) : É Que cette consultation entre dans le cadre d'une urgence médicale concernant le patient (niveau 1 ou supérieur) É Ou que cette consultation est nécessaire dans le cadre de la dispensation de soins au patient par le médecin demandant l'accès au dossier (ADM=oui) REVENDICATIONS 1 - Plateforme informatique comprenant une pluralité de modules métiers (1, 2, 3) constitués par des moyens techniques d'acquisition de données numeriques, une pluralité de moyens techniques de publication (4, 5, 6) permettant de produire des documents numériques enregistrés sur un premier serveur sécurisé accessible sur un premier réseau informatique muni de moyens (7) de normalisation et de publication des documents et d'enregistrement dans une base de donnée relationnelle, ainsi qu'un second serveur sécurisé accessible par un second réseau informatique, lesdits serveurs étant isolés physiquement, le second serveur comportant une réplication d'une partie paramétrable du contenu du premier serveur, avec une actualisation périodique. 2 - Plateforme informatique selon la revendication 1, caractérisée en ce qu'elle comprend une architecture matérielle et logicielle comportant lesdits moyens (7) de normalisation et de publication des documents, un portail d'accès, un coffre-fort électronique, un serveur Web d'imagerie au standard DICOM, une base de données relationnelles et un langage de programmation permettant le déploiement d'applications Web autour de la base de données relationnelle. 3 - Plateforme informatique selon la revendication 1, caractérisée en ce que les documents sont définis par une liste minimale d'attributs associés aux documents et/ou aux procédures d'imagerie, et une syntaxe (conforme aux standards XML, HL7 et IHE) permettant de bâtir des enveloppes d'échange normalisées. 4 - Procédé électronique de gestion et de circulation de documents numériques comprenant des étapes d'acquisition d'information par l'intermédiaire d'une pluralité de modules métiers (1, 2, 3), des étapes de production de documents numériques enregistrés sur un premier serveur sécurisé accessible sur un premier réseau informatique par l'intermédiaire d'une pluralité de moyens techniques de publication (4, 5, 6) munis de moyens (7) de normalisation et de publication des documents et d'enregistrement dans une base de donnée relationnelle, et des étapes de publication de documents agrégés auprès d'utilisateurs à partir d'un second serveur sécurisé accessible par un second réseau informatique, lesdits serveurs étant isolés physiquement, le second serveur comportant une réplication d'une partie paramétrable du contenu du premier serveur, avec une actualisation périodique. - Procédé électronique de gestion et de circulation de documents numériques selon la revendication précédente, caractérisé en ce qu'il comporte des étapes de notification de publication d'un document consistant à générer une enveloppe XML-HL7-IHE à partir des attributs associés à tout document et à acheminer au portail lesdits attributs, et à convertir le document en un format numérique prédéfini (notamment PDF ou XML) préalablement à l'acheminement vers le coffre-fort électronique. 6 - Procédé électronique de gestion et de circulation de documents numériques selon la revendication 4 ou 5, caractérisé en ce qu'il comprend un traitement: de compression des images statiques ou des images dynamiques; d'archivage d'images sélectionnées sur un serveur Web au standard d'imagerie DICOM; de transmission des attributs minimaux associés à la procédure aux moyens (7) de normalisation et de publication des documents selon un format informatique prédéfini, comportant notamment les adresses URL permettant de visualiser conjointement à partir d'un explorateur Internet la procédure d'imagerie sur le serveur Web d'imagerie, et les documents associés à l'imagerie. 7 - Procédé électronique de gestion et de circulation de documents numériques selon la revendication 4, 5 ou 6, caractérisé en ce qu'il comprend lors de la notification de publication d'une procédure d'imagerie statique ou dynamique une étape de génération et d'acheminement vers le serveur d'une enveloppe XML-HL7-IHE à partir des attributs transmis par le serveur d'imagerie. 8 - Procédé électronique de gestion et de circulation de documents numériques selon l'une au moins des revendications 4 à 7, caractérisé en ce que le portail intègre dans sa base de données relationnelle l'ensemble des éléments contenus dans les enveloppes normalisées transmises par les moyens (7) de normalisation et de publication, comportant notamment les URL permettant de pointer vers un document principal, vers des documents éventuellement indexés au document principal (archivés dans le coffre-fort électronique) et éventuellement vers la procédure d'imagerie correspondante (archivée dans le serveur Web d'imagerie). 9 - Procédé électronique de gestion et de circulation de documents numériques selon l'une au moins des revendications 4 à 8, caractérisé en ce que tout document est accessible à partir des éléments archivés dans la base de donnée relationnelle du portail - provenant des enveloppes HL7 et des données transmises de manière asynchrone par le GIP (Gestionnaire d'identité patient de l'établissement) et l'annuaire d'entreprise. - Procédé électronique de gestion et de circulation de documents numériques selon l'une au moins des revendications 4 à 9, caractérisé en ce qu'une partie au moins des données du coffre-fort électronique et du serveur Web d'imagerie est externalisé, c'est-à-dire copié dans une configuration de même architecture située à l'extérieur, pour autant que les enveloppes normalisées associées aux documents concernés soient également mises à disposition d'un hébergeur agréé extérieur. 11 - Procédé électronique de gestion et de circulation de documents numériques selon l'une au moins des revendications 4 à 10, caractérisé en ce qu'il comporte une étape d'export à partir d'un plateau technique d'imagerie pouvant être ou non pourvu d'un système d'archivage local au format DICOM, des images destinées à être imprimées et/ou des comptesrendus associés aux images, et d'intégration de ces documents et images à l'ensemble du dossier patient contenu dans le portail d'agrégation. 12 - Procédé électronique de gestion et de circulation de documents numériques selon l'une au moins des revendications 4 à 11, caractérisé en ce qu'il comporte des étapes de saisie, modification et signature des documents d'imagerie et d'intégration automatique des documents et des images correspondantes à l'ensemble des documents du dossier agrégé du patient. 13 - Procédé électronique de gestion et de circulation de documents numériques selon l'une au moins des revendications 4 à 11, caractérisé en ce qu'il comporte une étape d'identification conditionnant l'accès à l'annuaire d'entreprise et déterminant l'identité et le statut de l'intervenant, ainsi que l'identité et le statut de l'ensemble des patients présents.