FR2794548A1 - Systeme informatique muni d'un systeme expert - Google Patents

Abstract

Système informatique pour la mise en oeuvre du procédé tel que défini par l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend notamment un réseau (R) constitué d'un ensemble de terminaux informatiques (T1, T2,... Tn) et d'au moins un serveur (S), chaque terminal informatique étant au moins équipé d'un interface d'entrée/ sortie (I/ O) pour assurer la connexion au réseau, d'une unité centrale de traitement (UC), d'une unité d'affichage ou de visualisation (A), d'une unité de saisie (US), d'une imprimante (I), et d'un ensemble mémoire (M), en ce que l'ensemble mémoire (M) de chaque terminal est partagé en plusieurs blocs (M1, M2, M3) où sont notamment enregistrés le fichier professionnel local (F1) des données sur les patients, le fichier local (F2) de règles applicables aux données du fichier professionnel local, et le fichier local (F3) de documents associé au fichier local (F2) de règles, et en ce que le serveur (S) comprend des bases de données (FG2, FG3) où sont notamment enregistrées toutes les règles applicables au métier considéré et tous les documents associés à ces règles.

Description

SYSTEME INFORMATIQUE MUNI D'UN SYSTEME EXPERT La présente invention se rapporte principalement à un système informatique sur lequel a été implanté un mécanisme de gestion de règles applicables en fonction d'un contexte, notamment un système expert perfectionné susceptible de travailler avec une grande rapidité et à un système d'appel contextuel d'information utilisant un système expert.

Les systèmes expert des types connus comportent un moteur d'inférence et une base de connaissance incorporant les connaissances d'un expert dans le domaine considéré comprenant une base de fait et une base de règle. La base de règle comprend un grand nombre de règles dont 1e moteur d'inférence vérifie en permanence les conditions d'application pour exécuter les actions découlant des règles devant ëtre appliquées. I1 en résulte que les systèmes expert des types connus, pour pouvoir former des réponses ou pour commander des actions en temps réel monopolisent une unité centrale d'un système informatique dédié.

De plus, la formulation de règles de la base des règles de système expert de type connu n'est pas simple et nécessite pour leur formulation, non seulement la présence d'un expert du domaine considéré, mais également l'implication d'un cogniticien.

D'autre part, on reconnait des logiciels de navigation sur Internet et de visualisation des pages décrites dans le langage HTML (browser en terminologie anglo-saxon) notamment le logiciel Internet Explorer de la Société Microsoft et le logiciel Navigator de 1a Société Nestcape. Ces logiciels permettent de télécharger des données à partir de serveurs de données répartis sur Internet. Toutefois, les données rapatriées ne sont pas automatiquement organisées dans la mémoire de masse de l'ordinateur ni interfacées avec les logiciels présents sur cet ordinateur. Les données ne sont pas mises à jour sur l'ordinateur dans le cas de leur mise à jour sur le serveur.

On connaît également des outils de travail orientés vers le réseau au sein des entreprises. Les solutions mises en oeuvre associent habituellement une messagerie électronique, un outil de travail collaboratif sur un des documents partagés, notamment des outils dits de Groupware tels que le logiciel Lotus Notes commercialisé par la Société IBM, des applications bureautiques, des accès à Inter net et, éventuellement, des applications professionnelles orientées métier. Ces solutions sont utilisées par les membres d'une entreprise via des procédures de travail contraignantes autant en terme d'utilisation qu'en terme d'apprentissage. La rentabilité de la mise en oeuvre de tels outils logiciels et de leurs matériels associés n'est rendue possible que par des économies d'échelle offerts par la standardisation. Les procédures de travail ne sont suivies strictement que gràce à l'autorité hiérarchique régnant à l'intérieur des entreprises.

On connaït aussi le système de gestion de base de données relationnelles ORACLE, version 7 assurant la gestion de replication de base de données sur plusieurs postes.

On connaït également le fonctionnement client- serveur sur un réseau local permettant à un client d'assurer l'extraction d'une partie d'une base de données et d'assurer le traitement de 1a partie extraite sur le poste client.

Aucun outil informatique de type connu n'assure une interaction pertinente entre les informations reçues des serveurs et les logiciels verticaux, notamment les logiciels métiers. Cela est particulièrement vrai dans les cas d'une pluralité d'utilisateurs exerçant un même métier et utilisant des logiciels métiers différents. De plus, les systèmes experts des types connus monopolisent les machines sur lesquels ils s'exécutent et ne permettent donc pas une exécution en arrière plan de manière à fournir à un utilisateur, en temps réel, des informations pertinentes en fonction du contêxte ou de proposer à l'utilisateur d'exécuter des actions pertinentes en fonction de ce contexte.

C'est par conséquent un but de la présente invention d'offrir un système informatique de gestion de règles applicables en fonction d'un contexte, notamment à l'aide d'un système expert d'exécution particulièrement rapide.

C'est également un but de la présente invention d'offrir un tel système expert susceptible de s'exécuter en arrière plan de manière à pouvoir coopérer avec d'autres programmes s'exécutant en avant plan, tels que des logiciels verticaux, par exemple des logiciels métiers du type logiciel médical pour un médecin.

C'est aussi un but de la présente invention d'offrir un système expert permettant une saisie et une édition facile des règles du métier concerné.

C'est également un but de la présente invention d'offrir un système informatique intégrant des procédures métiers au niveau de l'interface homme-machine.

C'est également un but de la présente invention d'offrir un système informatique permettant de télécharger des informations à partir des serveurs disponibles sur un réseau, et d'interfacer de manière automatique les informations téléchargées avec les logiciels verticaux, notamment avec les logiciels métiers.

C'est aussi un but de la présente invention d'offrir un tel système assurant le téléchargement automatique de mise à jour des informations précédemment téléchargées. C'est également un but de la présente invention d'offrir un système informatique permettant un travail synchrone hors connexion notamment du type - chargement en ligne d'un formulaire à remplir ; - remplissage hors ligne du formulaire ; - renvoi en ligne du formulaire rempli ; - téléchargement d'une mise à jour du formulaire lorsque le formulaire précédemment traité est périmé.

Ces buts sont atteints par un système informatique selon la présente invention comportant un système de gestion de règles notamment un système expert comprenant des outils de sélection des règles applicables selon des pluralités de critères différents. Avantageusement, les critères des sélections sont hiérarchisés. Ainsi, le système selon la présente invention ne traite en permanence qu'un nombre réduit des règles sélectionnées selon un ou plusieurs critères de la sélection de règles. Le traitement d'un nombre réduit de règles peut s'effectuer en tâche de fond sans accaparer des ressources exagérées et permet l'exécution simultanée, en avant plan, d'un logiciel métier et l'interaction entre le système expert et ce logiciel.

Avantageusement, les règles sélectionnées sont copiées dans une base restreinte de règles actives, ce qui permet d'en accélérer 1e traitement. En variante, les règles sélectionnées portent un drapeau de sélection permettant de les tester sans extraction de la base de règles ou par extraction successive de règles individuelles sélectionnées.

Avantageusement, le système selon la présente invention utilise une interface unifiée et centralisée. D'une part, il est avantageux de codifier les informations présentes sur divers serveurs susceptibles d'être accédés. Par exemple, pour un médecin, on codifiera les médicaments, les actes médicaux, les maladies et analogues. Pour un garagiste, on codifiera les pièces détachées, les divers modèles de véhicules et de moteurs, les pannes et/ou les interventions du garagiste. Pour un ingénieur de bureau d'études, on codifiera les catalogues de pièces détachées susceptible d'être mises en oeuvre ainsi que les divers comportements de produits ou sous- ensembles susceptibles d'être conçus.

Au niveau du poste client, le logiciel comporte avantageusement une page d'accueil comprenant des liens vers les divers outils logiciels susceptibles d'être mis en oeuvre tout en affichant leur état comme par exemple nouveau message <I>reçu, alerte,</I> ou<I>nouveaux</I> documents disponibles sur les réseaux avec correspondance forte avec les profils de l'utilisateur. Le poste client de l'utilisateur assure une gestion des connexions vers les serveurs et d'émission de requête de téléchargement des documents à charger sur 1e poste. En variante pour des clients disposant d'une liaison permanente avec les serveurs, ces fonctions sont exécutées dans un espace privé réservé au client sur le serveur.

Avantageusement, l'automatisation des mises à jour, notamment des bases de contenues et des messages s'effectuent de manière paramétrable, notamment par la saisie d'un profil d'utilisateur définissant ses centres d'intérêts, ses priorités et analogues.

Avantageusement, la réception des messages d'urgence pertinents pour ses métiers ou des traitements obligatoires ne peut pas être supprimée du profil.

Avantageusement, les automatismes de mise à jour et de connexion mettent en oeuvre des mécanismes de sécurité de type connu, notamment une carte d'identification de l'utilisateur à base de microcircuits, dite carte à puce, par exemple, des cartes CPS d'un domaine médical. Toujours dans le domaine médical, le serveur peut être muni d'une carte de contrôle de type CSA. Quel que soit le domaine, le serveur assure avantageusement la création d'un journal des échanges.

I1 peut s'avérer avantageux de permettre l'export ou l'accès à tout ou partie des données du poste client à partir d'un autre poste, fixe ou nomade. Dans ce dernier cas, ii peut s'agir d'une liaison non filaire associée à un poste léger du type assistant personnel.

Avantageusement, l'intégration du poste client est assuré par une automatisation de procédures métiers, avec une activation contextuelle des divers outils ou services. De manière préférée, un mécanisme de règles et une communication événementielle assurera l'activation pertinente de certains outils au regard des besoins de l'utilisateur. Par exemple, en médecine, le mécanisme de règles active les outils de saisie d'un formulaire de déclaration obligatoire d'une maladie suite à un diagnostic positif ou propose l'activation des dits outils de saisie.

Avantageusement, les règles elles-mêmes, peuvent également être mises à jour automatiquement par importation de données par le réseau. I1 s'agit, de préférence, du critère de sélection du niveau le plus élevé assurant le chargement ou la mise à jour uniquement des règles correspondantes au profil de l'utilisateur de manière à limiter le nombre de règles à traiter.

En variante, le système selon la présente invention fonctionne en local avec une possibilité de sauvegarde distante sur le serveur. I1 peut s'agir d'une sauvegarde partielle, par exemple du fichier d'adresses, ou d'une sauvegarde totale incorporant les fichiers professionnels susceptibles d'être restitués après un sinistre sur le poste client de l'utilisateur.

En variante, des personnes ayant le droit d'accès à ces informations, par exemple un confrère en cas d'urgence médicale, peuvent consulter ces informations concernant le patient traité. Le réseau permet d'autoriser l'accès direct d'un premier médecin aux données stockées sur le poste d'un confrère (deuxième médecin) ou sur une sauvegarde privée sur le serveur des données de ce poste du deuxième médecin. De même, l'envoi, notamment par courrier électronique, du résultat d'un examen ou des tests réalisés par un spécialiste, par un exemple par un radiologue ou par un laboratoire médical au médecin traitant.

L'invention a principalement pour objet un procédé pour harmoniser le fonctionnement de terminaux informatiques dans chacun desquels est au moins implanté un logiciel métier correspondant au métier de l'utilisateur ou client du terminal, chaque terminal comportant au moins un fichier professionnel local où sont mémorisées des données propres à l'utilisateur dans l'exercice de son métier, au moins un fichier local de règles où sont mémorisées les règles applicables aux données du fichier professionnel local de l'utilisateur, et au moins un fichier local de documents qui peuvent être sélectionnés et activés en tant que résultat de l'application de règles du fichier local de règles à des données du fichier professionnel local de données, ce procédé étant caractérisé en ce qu'il consiste - à regrouper en réseau les terminaux d'un ensemble d'utilisateurs exerçant le même métier et devenant membres du réseau, - à inclure dans le réseau au moins un serveur dans lequel sont au moins enregistrées un fichier général des règles applicables dans le métier commun à cet ensemble d'utilisateurs, et un fichier général des documents qui peuvent être sélectionnés et activés en tant que résultat de l'application de l'ensemble des règles du fichier général, - à mettre régulièrement à jour les fichiers généraux de règles et de documents du serveur, puis les fichiers locaux correspondants de chaque terminal du réseau, de manière à ce que des mêmes données entrées dans un terminal quelconque du réseau soient traitées de la même manière par tous les terminaux du réseau.

L'invention a également pour objet un système informatique pour la mise en oeuvre du procédé précité, système qui est caractérisé en ce qu'il comprend notamment un réseau constitué d'un ensemble de terminaux informatiques et d'au moins un serveur, chaque terminal informatique étant au moins équipé d'un interface d'entrée/sortie pour assurer la connexion au réseau, d'une unité centrale de traitement, d'une unité d'affichage ou de visualisation, d'une unité de saisie, d'une imprimante, et d'un ensemble mémoire, en ce que l'ensemble mémoire de chaque terminal est partagé en plusieurs blocs où sont notamment enregistrés le fichier professionnel local des données sur les patients, le fichier local de règles applicables aux données du fichier professionnel local, et le fichier local de documents associé au fichier local de règles, et en ce que le serveur comprend des bases de données où sont notamment enregistrées toutes 'Les règles applicables au métier considéré et tous les documents associés à ces règles.

L'invention a également pour objet un système informatique comportant un mécanisme de gestion de règles à exécuter de manière conditionnelle en fonction d'un contexte caractérisé en ce qu'il comporte des moyens de sélection selon une pluralité des critères différents des règles susceptible d'être exécutées dans un contexte particulier ou un ensemble de contexte particulier, parmi les règles d'un ensemble de toutes les règles susceptible d'être exécutées.

L'invention a également pour objet un système informatique caractérisé en ce que les critères de sélection sont hiérarchisés, de manière à tester les règles à sélectionner selon un critère uniquement parmi les règles déjà sélectionnées selon les critères ayant un niveau hiérarchique supérieur.

L'invention a aussi pour objet un système informatique caractérisé en ce qu'il comporte des moyens de réplication des règles sélectionnées vers des moyens de mémorisation et en ce qu'il assure le balayage selon le contexte de l'ensemble répliquées des règles sélectionnées.

L'invention a aussi pour objet un système informatique caractérisé en ce que les règles comportent un critère de péremption limitant leur activation dans le temps.

L'invention a aussi pour objet un système informatique caractérisé en ce qu'il comporte en outre un logiciel vertical et des moyens d'interfaçage du système de gestion de règles avec le logiciel vertical.

L'invention a également pour objet un système informatique caractérisé en ce qu'il comporte un interface homme-machine graphique et en ce que l'intégration entre le système de gestion des règles et le logiciel vertical s'effectue au niveau de l'interface homme-machine.

L'invention a aussi pour objet un système informatique caractérisé en ce qu'il comporte des moyens de connexion à des serveurs et une base de données organisant dans un format prédéterminé les informations reçues des serveurs.

L'invention a également pour objet un système informatique caractérisé en ce qu'il comporte une base de codification d'événements susceptible d'être traitée par des règles.

L'invention a aussi pour objet un système informatique caractérisé en ce que les règles mises en oeuvre sont gérées par le logiciel Lotus Notes. L'invention a aussi pour objet un système informatique caractérisé en ce que 1e logiciel vertical est un logiciel d'assistance à la consultation médicale pour médecin.

L'invention a également pour objet un système informatique caractérisé en ce qu'il comporte des moyens de stockage locals et/ou distants d'informations organisées et en ce que le système de gestion de règles assure un accès à un élément pertinent d'informations organisées stockées en fonction d'un contexte résultant de l'exécution d'un programme par ledit système informatique.

L'invention sera mieux comprise au moyen de 1a description ci-après et des figures annexées données comme des exemples non 'Limitatifs, et sur lesquelles - 1a figure 1 est un diagramme de flux d'un processus de sélection des règles mises en oeuvre par l'exemple préféré de réalisation d'un système de gestion de règles mis en oeuvre par le système information selon 1a présente invention ; - la figure 2 est un schéma illustrant une première étape de fonctionnement de l'exemple préféré de réalisation d'un système expert implanté sur un système informatique selon la présente invention ; - la figure 3 est un schéma illustrant une deuxième étape de fonctionnement de l'exemple préféré de réalisation d'un système expert implanté sur un système informatique selon la présente invention ; - la figure 4 est un schéma illustrant une troisième étape de fonctionnement de l'exemple préféré de réalisation d'un système expert implanté sur un système informatique selon la présente invention ; - la figure S est un schéma illustrant une quatrième étape de fonctionnement de l'exemple préféré de réalisation d'un système expert implanté sur un système informatique selon la présente invention ; - la figure 6 est un schéma illustrant une cinquième étape de fonctionnement de l'exemple préféré de réalisation d'un système expert implanté sur un système informatique selon la présente invention ; - la figure 7 est un schéma d'une architecture du type connu ; - la figure 8 est un schéma de l'architecture selon la présente invention ; - la figure 9 est un schéma de l'architecture de 'L'exemple préféré de réalisation d'un poste client sur la présente invention ; et - 1a figure 10 illustre schématiquement un système informatique pour mettre en oeuvre l'invention dans 1e cas d'une assistance à 1a consultation médicale.

La figure 1 illustre un principe de fonctionnement à un système de gestion de règles notamment d'un système expert susceptible d'àtre implanté dans un système informatique sur la présente invention. Le système de gestion des règles, notamment le moteur d'inférence ou le mécanisme de gestion de règles du logiciel Lotus Notes de la Société IBM sélectionne les règles à exécuter selon une pluralité de critères avantageusement hiérarchisés. On évite de balayer constamment des règles dont on est sür qu'elles n'ont pas à s'appliquer dans le cas considéré, pour permettre une exécution rapide du système expert et notamment, dans la mesure où le système expert n'accapare qu'une faible partie de la puissance de calcul disponible, sa coopération avec d'autres logiciels.

En 1, on initialise le compteur de niveau de critères de sélection.

On va en 3.

En 3, on incrémente le compteur de niveau de critères de sélection.

On va en 5. En 5, on charge le critère de sélection de règles dont le niveau correspond à la valeur du compteur incrémenté en 3.

On va en 7.

En 7, on initialise le compteur de règles sélectionnables, c'est-à-dire de règles qui n'ont pas été éliminées par un critère de niveau de sélection supérieur. Par exemple, si j égal 1, on va balayer l'ensemble des règles disponibles de 0 à imax. Si j est supérieur à 1, on analyse uniquement l'ensemble des règles sélectionnées au niveau supérieur.

On va en 9.

En 9, on incrémente le compteur de règles à analyser.

On va en 11.

En 11, on vérifie si la règle analysée (règle i) remplit les critères en cours d'analyse (critères de sélection de niveau j).

Si la règle analysée correspond au critère, on va en 13.

Sinon, on va en 15.

En 13, on assure la sélection de la règle i. Cette sélection peut correspondre au marquage de 1a règle, par exemple par un drapeau dans la base des règles, soit, avantageusement, par une copie de la règle dans une base réduite de règles actives.

En 15, on vérifie s'il reste des règles à analyser.

S'il reste des règles à analyser, on va en 9. Si la règle analysée était la dernière règle à analyser, on va en 17.

En 17, on vérifie si on se trouve au dernier niveau de critères de sélection.

Sinon, on va en 3.

Si oui, on va en 19 où la routine de sélection de règles se termine. Elle sera automatiquement redéclenchée si une condition correspondant au critère de sélection change. Ainsi, le système informatique selon la présente invention est particulièrement performant si les critères de sélection testés correspondent à de conditions relativement stables dans le temps, les critères changeant rapidement en temps réel, étant analysé par le mécanisme de manipulation de règles, notamment le moteur d'inférence, parmi les règles sélectionnées.

I1 est bien. entendu que la présente invention n'est pas limitée à une exécution séquentielle illustrée sur 1a figure 1, une répartition du balayage sur plusieurs taches exécutées sur un même processeur, ou exécutées en parallèle sur une pluralité de processeurs, ne sort pas du cadre de la présente invention.

Sur les figures 2 à 6, on peut voir les étapes successives de 1a gestion des règles de l'exemple préféré de réalisation du système informatique selon la présente invention. Sans que cela présente un quelconque caractère limitatif, le système expert est basé sur les logiciels Lotus Notes et installé sur un poste informatique d'assistance à 1a consultation médicale autonome susceptible d'être connecté, par exemple, par ligne téléphonique au réseau Internet.

Lors d'une lecture des données, comme par exemple une mise à jour du fichier patient, !'Agent EVENEMENT effectue un contrôle de règles. Les règles 23.1 à 23.n sont stockées dans une base de règle 23 portant, sur 1e logiciel Lotus Notes, l'extension .nsf. Dans l'exemple illustré, où j est égal 1, les règles sont sélectionnées selon un critère unique lors de leur balayage symbolisé par la flèche 25. Les règles sélectionnées sont copiées, par exemple, dans une partie 27 intitulée<I>Vue</I> Règles<I>actives</I> d'une<I>Base</I> Fichier.nsf 29 comportant d'autre part une partie 31 intitulée Vue Règles historisées et une partie 33 intitulée<I>Vue</I> Règles<I>Déclenchées.</I> Toutefois, il est bien. entendu que le stockage des règles dans une pluralité de bases différentes ne sort pas du cadre de la présente invention. Les règles actives sont rajoutées à 1a<I>Vue des</I> Règles <I>actives 27</I> qui peuvent stocker d'autres règles qui ont été sélectionnées antérieurement et non encore purgées.

Sur la figure 3,<I>l'Agent</I> EVENEMENT assure un balayage, symbolisé par la flèche 35, de la<I>Vue Règles</I> <I>actives</I> pour en éliminer les règles périmées. De plus, il peut être intéressant d'automatiser une purge complète pour ne pas risquer de noyer l'utilisateur sous des règles qui ne l'intéressent pas.

Sur la figure 4, l'Agent EVENEMENT <I>21</I> assure l'activation des règles historisées, c'est-à-dire les transferts de règles de la partie 31 de 1a<I>Base</I> F.zchier.nsf, contenant des règles susceptibles de devenir actives après leur déclenchement vers la partie 27 Vue <I>Règles actives.</I> Le critère d'analyse des règles historisées symbolisée par la flèche 37 correspond par exemple à un événement et à 1a date système. Une règle historisée peut, par exemple, correspondre à une règle devant être exécutée périodiquement ou devant être exécutée plusieurs fois à intervalles réguliers ou non. L'historisation permet des déclenchements périodiques de certains examens en fonction de la date du dernier examen contenue dans le fichier patient de 1a date actuelle (date système).

De même, certaines analyses ou procédures médicales peuvent n'être déclenchées grâce aux règles adéquates uniquement dans des cas où elles sont utiles en fonction du profil du patient et notamment de ses antécédents médicaux et familiaux, de son environnement, d'un diagnostic, ou d'une hypothèse diagnostic. Le transfert de règles historisées vers la Vue Règles <I>actives 27</I> est symbolisée par la flèche 39. Les règles transférées sont avantageusement effacées de la Vue Règles historisées 31. Sur la figure 5, l'Agent EVENENIENT 21 assure 1e déclenchement des Règles actives, c'est-à- dire l'analyse de règles de la<I>Vue des Règles actives 27</I> symbolisée par la flèche 41 et leur transfert, symbolisé par la flèche 43, dans la<I>Vue</I> Règle<I>Déclenchées</I> 33. Les actions prévues dans les règles de la Vue Règles <I>Déclenchées</I> 33 individuellement ou en combinaison sont exécutées avantageusement en interaction avec un logiciel métier s'exécutant sur le système informatique selon la présente invention. Un exemple avantageux est illustré sur la figure 6 sur laquelle on exécute les scripts du masque règle déclenchés par le bouton d'action de règles générées dans 1e logiciel Lotus Notes par exemple le déclenchement d'une règle provoque la proposition, l'affichage, l'édition ou l'envoi d'un document et/ou d'un formulaire correspondant à la règle stockée dans une <I>Base</I> Actions.nsf de documents et de formulaires. La règle déclenchée est reliée sur 1a figure 6 au document ou formulaire de la base 45 par la flèche 47. Si la règle prévoit son exécution ultérieure, elle est transférée dans 1a Vue Règles historisées 31 comme symbolisée par la flèche 49. Les règles déclenchées sont effacées de la Vue <I>Règles Déclenchées</I> 33.

Le système sur 1a présente invention est basé sur un déclenchement événementiel et dispose de capacité de redéclenchement programmée. Cette logique événementielle est avantageusement basée sur une liste d'événements spécifiques au métier du logiciel métier associé ainsi que sur des propriétés des règles. Par exemple, chaque règle est associée à trois propriétés, son événement de contrôle, correspondant au critère de sélection 5, de la figure 1, son événement de déclenchement et son événement de péremption. Ainsi, on automatise des protocoles répétitifs et complexes non liés à une date comme par exemple le remplissage d'un formulaire au début de chaque consultation par un médecin (événement de déclenchement) suite au choix de l'utilisateur (événement de contrôle). Cette procédure professionnelle est automatisable si le choix de l'utilisateur (le praticien) active la règle qui se déclenche à chaque choix de patient jusqu'à ce que l'utilisateur change. La capacité de redéclenchement programmée (Règles historisées) permet de gérer la procédure de suivi de cas. Ce service est avantageusement basé sur une communication simple entre processus permettant de déclencher un événement (flèche 43, figure 5) par le mécanisme de gestion de règle, ou en passant les données associées définissant son contexte pour contrôler les paramètres de déclenchement. Avantageusement, le mécanisme de gestion des règles est associé à un programme tampon paramétrable qui permet de paramétrer les interactions dans l'interface homme-machine d'une nouvelle règle déclenchée. Cela permet à l'utilisateur de déclencher l'action liée à une règle au moment qu'il juge opportun sans brutalement couper son travail. Ce service permet également de gérer l'interaction avec les outils réseau, notamment l'interaction entre les outils réseau et le logiciel métier. En effet, d'une part, les règles peuvent être pilotées, c'est-à-dire sélectionnées et activées par les services réseau, par exemple par réception d'un courrier électronique. De même, les règles peuvent activer des outils réseau comme par exemple aller chercher une information sur un serveur d'information Internet ou sur un serveur du réseau local ou émettre un message sur un tel réseau. Les règles peuvent également assurer le transfert d'un contexte. Ainsi, le logiciel métier du système informatique selon la présente invention permet à l'utilisateur d'accéder au service réseau sans devoir apprendre leur mécanisme, ni leur interface homme-machine spécifique. Par exemple un logiciel de consultation médicale peut déclencher des règles en associant des données du fichier patient à un diagnostic établi dans un format compatible. Il est à noter que la réalisation d'outil d'activation contextuel de règles pertinentes pour une profession est facilitée par une normalisation des données utilisées par cette profession, aussi bien au niveau de l'organisation que de la représentation de ces données, pour 1a définition des critères de déclenchement de règles. En médecine, on peut utiliser des codes CIP pour rédiger une prescription. L'accès au réseau de type cornu est illustré sur ia figure 7. Un poste client 51 est relié par un réseau à un premier serveur 53.1 de données stockées selon une norme A à un deuxième serveur 53.2 des données stockées selon une norme B et à un troisième serveur 53.3 stockant des informations selon une norme C. Le poste client 51 doit donc intégrer la gestion des normes A, B et C. Au contraire, le poste client 55 selon la présente invention intègre une norme unique. Les serveurs 57.1, 57.2 et 57.3 devront intégrer une norme unique D de stockage et de présentation d'information. Ainsi, le poste client peut accéder à tous ces serveurs de manière unifié avec possibilité d'interaction des données des serveurs 57.1 à 57.3 avec les logiciels métier du poste client 55. I1 est bien entendu que le poste client 55 selon 1a présente invention peut également accéder à des serveurs classiques comme le serveur 59 sans bénéficier d'avantages spécifiques de la présente invention.

Sur la figure 9, on peut voir les fonctionnalités du système informatique sur la présente invention d'assistance à la consultation médicale. Ce système comporte un poste fonctionnant par exemple sous le système d'exploitation WINDOWS 95, WINDOWS 98 ou WINDOWS NT4, commercialisé par la société Microsoft ou sur un Macintosh commercialisé par la société APPLE. Le poste comporte de manière connue des logiciels métier comme un logiciel de consultation médicale 61, des moyens 63 de gestion de sécurité, par exemple, à base de cartes à micro circuits, un logiciel de comptabilité 65 et des modules de Formation Médicale Continue 67. Avantageusement, le poste comporte en outre une base de codification 69 assurant une codification d'actes médicaux et/ou des médicaments. Ces logiciels sont interfacés par un ensemble logiciel 71 apportant au niveau de l'interface homme-machine des services supplémentaires tels que la gestion du poste informatique 73, le courrier électronique 75, un logiciel d'agenda 77, un accès télématique au minitel':" 79, un fichier des patients 81, des logiciels de communication 83 avec un réseau local et/ou distant, un logiciel de statistiques 85, un module de mise à jour automatique de formulaires et de la documentation 87 assurant la replication à partir des serveurs des versions à jour des informations déjà disponibles sur le poste, un service d'acquisition par téléchargement et d'affichage des actualités documentaires 89, un accès 91 à des services externes, comme par exemple les services Villages<I>Santé</I> et analogues. Des processus 93, par exemple à base de règles du logiciel Lotus Notes assure l'intégration des divers éléments 73 à 91 à l'interface machine et leur interfaçage avec les logiciels 61 à 69. De même, le système informatique de la figure 9 peut accéder de manière transparente et unifiée à tous les serveurs locaux ou distants utilisant une architecture des données compatibles. Le logiciel assure le rapatriement de toutes les informations sous forme d'une base de données organisée par le logiciel 71 facilitant l'accès à ces données par les logiciels 61 à 69 ainsi que les mises à jour 87 à partir du réseau. Ces mises à jour s'effectuent de manière préférée automatiquement par exemple à l'allumage du poste le matin et/ou avant son extinction le soir. La périodicité de connexion au réseau, par exemple quotidienne, biquotidienne ou hebdomadaire est nettement supérieure à la fréquence des mises à jour des informations documentaires et surtout des formulaires administratifs liés au domaine médical. Ainsi, lors d'une consultation médicale assistée par le logiciel de consultation 61 utilisant 1a fiche d'un patient stockée dans le fichier patient 81, le logiciel 71 propose au médecin de remplir un formulaire de prise en charge à i00 ô par la Sécurité Sociale des prestations de son patient (déclaration d'une pathologie en Affection Longue Durée). Ce formulaire est à jour et peut être partiellement pré- rempli avec les données concernant 1e médecin ainsi que le patient. Le formulaire est rempli hors ligne. Lors de la connexion, tous les formulaires remplis sont retransmis au serveur de l'organisme compétent, par exemple de la Sécurité Sociale.

De même, 1e logiciel 71 permet de faciliter les échanges, entre professionnels, des données utilisables par des logiciels de consultation 61 différents. L'intégration du logiciel 61 permet également d'échanger des données métier avec les serveurs, ce qui permet de mettre en place des services de sauvegarde distants, si cela est désiré, dans une zone privée du serveur pour un fichier d'adresse ou même pour les fichiers professionnels. Le médecin peut autoriser le traitement automatisé des données comme par exemple des statistiques médicales. Enfin l'accès aux données métier sur le serveur permet de mettre en place des outils d'accès distants. Ainsi, un médecin en déplacement pourrait consulter son fichier patient sur un serveur sécurisé. En variante, un autre professionnel accrédité peut, en cas d'urgence, accéder à des données, comme par exemple des données concernant la dernière glycémie d'un patient. De même, des messages urgents pourraient être transmis par réseau à un ensemble de praticiens concernés. Dans le cas où le système informatique serait éteint, on pourrait prévoir le réveil à distance par modem. Le système informatique tel que décrit précédemment peut ainsi être avantageusement utilisé pour harmoniser 1e fonctionnement d'un ensemble de terminaux informatiques.

D'une manière générale, ces terminaux informatia_ues fonctionnent sous un système d'exploitation qui permet l'exécution de logiciels parmi lesquels ont peut trouver un logiciel métier Lo qui est spécifique à une profession, par exemple un logiciel d'assistance à la consultation médicale pour un médecin, comme cela a déjà été évoqué précédemment.

Ce logiciel métier Lo va prendre en compte des données qui peuvent être réparties en au moins trois fichiers mémorisés, à savoir - un fichier local patient F1 où sort enregistrées des données propres à chaque patient et qui constituent son dossier médical, - un fichier local règle F2 où sont enregistrées des règles qui sont susceptibles d'être appliquées aux données du fichier patent F?, et - un fichier local document F3 où sont enregistrées des données sous la forme de documents, d'imprimés ou autres, et qui sont susceptibles d'apporter une réponse et/ou de définir un type d'action à effectuer, en tant que résultat de règles locales appliquées à des données du fichier local patient F1.

Dans le domaine médical, la masse des informations susceptibles d'être prises en compte par les médecins dans l'exercice de leurs fonctions, est sans cesse croissante compte tenu d'une meilleure connaissance des maladies, de leurs diagnostics, des traitements thérapeutiques et de leurs effets secondaires,..., de la découverte de nouvelles maladies, de nouveaux médicaments,...

Face à cette prolifération d'informations, les médecins ont la possibilité d'équiper leurs terminaux informatiques avec un logiciel L1 leur permettant de consulter des bases de données enregistrées dans un serveur pour parfaire leurs connaissances sur des sujets donnés, ces bases de données étant régulièrement mises à jour.

Concrètement, faute d'une solution adaptée, i1 n'y a pas d'interaction de manière contextuelle entre les deux logiciels Lo et L1, car le médecin ne fait que consulter les bases de données sans pouvoir enregistrer certaines des informations consultées pour qu'elles puissent être prises en compte par le logiciel métier Lo.

Ainsi, dans l'exercice de ses fonctions, le médecin va utiliser son logiciel métier d'une part et ses propres connaissances d'autre part, pour mener à bien la consultation avec ses patients.

En pratique, les médecins ont à leur disposition des logiciels métiers différents fonctionnant sous des systèmes d'exploitation différents, et il en résulte une grande diversité.

Selon l'invention, on va créer cette interaction en liant les logiciels Lo et L1 de manière contextuelle, et on va harmoniser le fonctionnement d'un ensemble de terminaux en les regroupant en réseau, avec notamment la possibilité de partager au moins des règles communes applicables à leurs patients et de pouvoir échanger des informations.

L'interaction entre les logiciels Lo et L1 est telle que les fichiers Fz et F3 des règles et des documents sont automatiquement mis à jour à partir d'au moins un serveur du réseau sans aucune intervention du médecin, et plusieurs médecins qui auront décidé de se grouper en réseau pourront partager des règles et des documents communs.

Ainsi, dans 1e domaine médical, il va être possible d'harmoniser les ordonnances prescrites par les différents médecins du réseau et ce, quel que soit 1e médecin consulté par le patient.

Un tel réseau R tel que schématiquement illustré sur la figure 14, regroupe un ensemble de terminaux informatiques T1, T2,...,Tn et au moins un serveur S.

Chaque terminal, en l'occurrence le terminal T1, comprend notamment à titre d'exemple une interface I/0 d'entrée-sortie pour assurer la connexion au réseau R, une unité centrale de traitement UC, une unité d'affichage A, une unité de saisie US, une imprimante I, et un ensemble mémoire M, tous ces éléments étant reliés entre eux par un bus B de données, d'adresses et de commande.

L'ensemble mémoire M est partagé en plusieurs blocs M1, M2, M3 et M4 où sont notamment enregistrés les fichiers évoqués précédemment, à savoir le fichier professionnel local F1 sur les données des patients, le fichier local F2 des règles applicables et le fichier local F3 des documents, ainsi qu'un bloc M4 où sont enregistrés un logiciel métier Lo et un logiciel de consultation L1 qui permet de dialoguer avec le serveur S, et un logiciel L2 d'interaction qui permet d'étendre les fonctionnalités du logiciel métier Lo.

Un tel réseau R peut fonctionner de la manière décrite ci-après et donnée à titre d'exemple.

D'une manière générale, le médecin équipé du terminal informatique T1 peut être amené à mettre à jour son fichier professionnel local F1 au cours d'une consultation avec son patient, à afficher sur l'unité A le traitement en cours du patient,..., mais sans que cela implique nécessairement une réaction particulière du système. Autrement dit, ces données peuvent constituer des faits qui ne sont pas susceptibles de créer un évènement auquel le système va réagir, comme par exemple un changement d'adresse.

Par contre, des données représentatives d'un fait peuvent créer un évènement qui va être automatiquement pris en compte par le système et 1e forcer à réagir.

Suite à une analyse de sang prescrite à son patient par exemple, le médecin va examiner les résultats et entrer les données correspondantes pour mettre à jour le dossier médical de son patient, mais surtout dans le but de faire réagir le logiciel métier Lo de son terminal à ces données.

Ces données prises en compte par le logiciel métier Lo vont alors créer un ou plusieurs avènements qui vont être analysés par des règles enregistrées dans le fichier local F2 et dûment sélectionnées par le logiciel métier Lo à partir des données entrées.

Dans le cas d'un patient diabétique par exemple dont les résultats de l'analyse font apparaître un taux sanguin en sucre qui dépasse une valeur de seuil, les règles applicables au diabète vont être sélectionnées dans le fichier local F2 de règles, et les règles ainsi appliquées vont permettre au logiciel métier Lo de consulter le fichier F3 de documents pour activer les documents concernant le diabète, et les éditer par exemple ainsi qu'une ordonnance prédisant le traitement approprié que devra suivre le patient.

Dans 1e cas où 1e patient est une femme qui a plus de cinquante ans, l'entrée de cette donnée va également créer un évènement qui va être analysé par les règles du fichier local F2. Cette analyse va se traduire par la consultation du dossier médical de la patiente enregistré dans le fichier F1 pour savoir si elle a déjà effectué une mammographie. Dans la négative, le logiciel métier Lo va consulter le fichier F3 de documents pour prescrire une mammographie en éditant une ordonnance à cet effet, ainsi que des documents d'information à destination de la patiente. Dans l'affirmative, les règles appliquées contrôlent la date à laquelle la dernière mammographie a été faite avant de décider d'en prescrire une autre.

D'une manière générale, les règles applicables enregistrées dans le fichier local F2 sont régulièrement mises à jour à partir du serveur S où sont enregistrées toutes les règles applicables, enregistrées dans un fichier général FG2 et, dûment contrôlées par des personnes ou organismes habilitées. Cette mise à jour peut consister à supprimer des règles pour les remplacer par d'autres ou à les compléter,... D'une manière similaire, 'Le serveur S contient également un fichier général FG3 de documents qui est aussi régulièrement mis à jour, ainsi que ceux enregistrés dans 1e fichier 'Local F3.

Cependant, si un tel système permet au médecin de travailler en local, l'intérêt d'une organisation en réseau R va permettre à plusieurs médecins de travailler et de partager un ensemble de règles et de documents en commun, ce qui se traduira par des résultats de même nature pour tous les patients et ce quel que soit le médecin consulté appartenant au réseau.

L'invention propose donc un procédé pour harmoniser le fonctionnement de terminaux informatiques T1, T2,...,Tn dans chacun desquels est au moins implanté un logiciel métier Lo correspondant au métier de l'utilisateur ou client du terminal, chaque terminal Ti, T2,...,Tn comportant au moins un fichier professionnel -Local F1 où sont mémorisées des données propres à l'utilisateur dans l'exercice de son métier, au moins un fichier local F2 de règles où sont mémorisées les règles applicables aux données du fichier professionnel local F1 de l'utilisateur, et au moins un fichier local F3 de documents qui peuvent être sélectionnés et édités en tant que résultat de l'application de règles du fichier local F2 de règles à des données du fichier professionnel local F1 de données, ce procédé étant caractérisé en ce qu'il consiste - à regrouper en un réseau R les terminaux Ti,T2,...,Tn d'un ensemble d'utilisateurs exerçant le même métier et devenant membres du réseau, - à inclure dans le réseau R au moins un serveur S dans lequel sont au moins enregistrées un fichier général FG2 des règles applicables dans le métier commun à cet ensemble d'utilisateurs, et un fichier général FG3 des documents qui peuvent être sélectionnés et activés en tant que résultat de l'application de l'ensemble des règles du fichier général, - à mettre à jour les fichiers généraux de règles et de documents du serveur S, puis les fichiers locaux correspondants F2, F3 de chaque terminal du réseau, de manière à ce que des mêmes données entrées dans un terminal quelconque du réseau soient traitées de la même manière par tous les terminaux du réseau.

Avantageusement, le procédé peut consister également à n'enregistrer dans le fichier local F2 de règles de chaque terminal que les règles susceptibles d'être appliquées sur les données enregistrées dans le fichier professionnel F1 local de l'utilisateur, à mettre à jour ces règles locales lorsqu'elles sont modifiées ou remplacées par d'autres, et à introduire dans le fichier local F2 les règles applicables à de nouvelles données entrées dans le fichier professionnel local Fi par l'utilisateur.

D'une manière similaire, 1e procédé consiste également à n'enregistrer dans le fichier local F3 de documents de chaque terminal que les documents susceptibles d'être sélectionnés et activés en tant que résultat de l'application de règles du fichier local F2 de règles à des données du fichier professionnel local Fi, à mettre à jour ces documents locaux lorsqu'ils sont modifiés ou remplacés, et à introduire dans le fichier local F3 les nouveaux documents qui seront sélectionnés et activés après application de nouvelles règles locales à de nouvelles données entrées dans 1e fichier professionnel local F1 par l'utilisateur.

Dans le cas d'une application médicale, les médecins qui auront leurs terminaux informatiques connectés en réseau pourront travailler sur des mêmes règles et des mêmes documents qu'ils partageront en commun.

Le procédé peut consister également à enregistrer dans le serveur S au moins un extrait du fichier local patient F1 de chaque utilisateur connecté au réseau R, de façon à permettre la constitution de fichiers communs aux utilisateurs ou membres d'un réseau professionnel, en particulier de donner 1a possibilité à un utilisateur d'interroger depuis sont terminal l'extrait du fichier local patient F1 des autres terminaux du réseau, et à permettre également l'établissement de statistiques sur l'activité des utilisateurs ou membres d'un réseau professionnel, par exemple.

La présente invention n'est pas limitée à l'assistance à la consultation médicale, mais s'applique à des domaines où les données peuvent être stockées sous forme d'une base de données organisées. Par exemple, un système informatique selon la présente invention de documentation assistée par ordinateur en mécanique appellera par des règles les divers documents de la mécanique ainsi que les propriétés physiques des divers matériaux.

Un système pour architecte intégrera outre des données techniques, une base de connaissances juridiques sur 1e droit de la construction ainsi que des catalogues des pièces disponibles pour réaliser des bâtiments. Le programme scolaire peut être mis sous forme de ràgles avec plusieurs niveaux de critères de sélection. Le premier niveau de critères peut correspondre à la classe. Le deuxième niveau de critères peut correspondre à la matière. Les règles peuvent correspondre à des éléments de cours à enseigner.

La hiérarchisation des critères d'application des règles permet d'accélérer le fonctionnement du système informatique sur la présente invention par traitement d'un nombre réduit des règles susceptibles d'être pertinentes.

Toutefois, la mise en oeuvre de système informatique puissant permet, sans sortir du cadre de la présente invention, d'utiliser des règles sans sélection préalable selon une pluralité de critères, en assurant chaque fois 1e balayage de la base de règles complètes.

De même, la présente invention n'est pas limitée à des règles reproduisant les connaissances d'un expert dans un domaine. Toute ou partie des règles d'un système selon la présente invention peuvent concerner des actions à exécuter de manière conditionnelle en fonction d'un contexte.

La présente invention s'applique principalement à une documentation contextuelle assistée par ordinateur et partagée en réseau et à une gestion d'une base d'information et de services (documents, formulaires, utilitaires, fichiers, URL, etc.) mobilisées de façon contextuelle par ordinateur et partagée en réseau (mise à jour de 1a base et échanges des données).

Claims (4)

<U>REVENDICATIONS</U>

1. Procédé pour harmoniser le fonctionnement de terminaux informatiques (T1,T2,...Tn) dans chacun desquels est au moins implanté un logiciel métier Lo correspondant au métier de l'utilisateur ou client du terminal, chaque terminal (T1,T2,...Tn) comportant au moins un fichier professionnel local (F1) où sont mémorisées des données propres à l'utilisateur dans l'exercice de son métier, au moins un fichier 'Local (F2) de règles où sont mémorisées les règles applicables aux données du fichier professionnel local (F1) de l'utilisateur, et au moins un fichier local (F3) de documents qui peuvent être sélectionnés et activés en tant que résultat de l'application de règles du fichier local (F2) de règles à des données du fichier professionnel local (F1) de données, ce procédé étant caractérisé en ce qu'il consiste . - à regrouper en un réseau (R) les terminaux (T1,T2,...Tn) d'un ensemble d'utilisateurs exerçant le même métier et devenant membres du réseau, - à inclure dans le réseau (R) au-moins un serveur (S) dans lequel sont au moins enregistrées un fichier général (FG2) des règles applicables dans le métier commun à cet ensemble d'utilisateurs, et un fichier général (FG3) des documents qui peuvent être sélectionnés et activés en tant que résultat de l'application de l'ensemble des règles du fichier général, - à mettre régulièrement à jour les fichiers généraux de règles et de documents du serveur (S), puis les fichiers locaux correspondants (F2,F3) de chaque terminal du réseau, de manière à ce que des mêmes données entrées dans un terminal quelconque du réseau soient traitées de la même manière par tous les terminaux du réseau.

2. Procédé selon la revendication 1, caractérisé en ce qu'il consiste également à n'enregistrer dans le fichier local (F2) de règles de chaque terminal que les règles susceptibles d'être appliquées sur les données enregistrées dans le fichier professionnel local de l'utilisateur, à mettre à jour ces règles locales (Fi.) lorsqu'elles sont modifiées ou remplacées par d'autres, et à introduire dans le fichier local (F2) les règles applicables à de nouvelles données entrées dans 1e fichier professionnel local (F1) par l'utilisateur.

3. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il consiste également à n'enregistrer dans le fichier local (F3) de documents de chaque terminal que les documents susceptibles d'être sélectionnés et activés en tant que résultat de l'application de règles du fichier local (F2) de règles à des données du fichier professionnel local (F1), à mettre à jour ces documents locaux lorsqu'ils sont modifiés ou remplacés, et à introduire dans le fichier local (F3) les nouveaux documents qui seront sélectionnés et activés après application de nouvelles règles locales à de nouvelles données entres dans le fichier professionnel local (F1) par l'utilisateur.

4. Procédé selon la revendication 2 ou 3, caractérisé en ce qu'il consiste à enregistrer dans le serveur (S) un extrait du fichier professionnel local (F1) de chaque utilisateur. S. Procédé selon la revendication 4, caractérisé en ce qu'il consiste à permettre à tout utilisateur d'interroger depuis son terminal l'extrait du fichier professionnel local (F1) des autres utilisateurs. 6. Système informatique pour la mise en oeuvre du procédé tel que défini par l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend notamment un réseau (R) constitué d'un ensemble de terminaux informatiques (T1,T2,...Tn) et d'au moins un serveur (S), chaque terminal informatique étant au moins équipé d'un interface d'entrée/sortie (I/0) pour assurer la connexion au réseau, d'une unité centrale de traitement (UC), d'une unité d'affichage ou de visualisation (A), d'une unité de saisie (US), d'une imprimante (I), et d'un ensemble mémoire (M), en ce que l'ensemble mémoire (M) de chaque terminal est partagé en plusieurs blocs (Ml,M2,M3) où sont notamment enregistrés 1e fichier professionnel local (F1) des données sur les patients, 1e fichier local (F2) de règles applicables aux données du fichier professionnel local, et le fichier local (F3) de documents associé au fichier local (F2) de règles, et en ce que le serveur (S) comprend des bases de données (FG2,FG3) où sont notamment enregistrées toutes les règles applicables au métier considéré et tous les documents associés à ces règles. 7. Système informatique selon 1a revendication 6, caractérisé en ce qu'il comporte un mécanisme de gestion de règles à exécuter de manière conditionnelle en fonction d'un contexte caractérisé en ce qu'il comporte des moyens (11) de sélection selon une pluralité des critères différents (5) des règles (27) susceptible d'être exécutées dans un contexte particulier ou un ensemble de contexte particulier, parmi les règles d'un ensemble (23) de toutes les règles susceptible d'être exécutées. 8. Système informatique selon la revendication 7, caractérisé en ce que les critères de sélection sont hiérarchisés, de manière à tester les règles (23.1 à 23n) à sélectionner selon un critère uniquement parmi les règles déjà sélectionnées selon les critères ayant un niveau hiérarchique supérieur. 9. Système informatique selon 1a revendication 7 ou 8, caractérisé en ce qu'il comporte des moyens de réplication (26) des règles sélectionnées (27) vers des moyens de mémorisation et en ce qu'il assure le balayage (35) selon le contexte de l'ensemble répliquées des règles sélectionnées. 10. Système informatique selon l'une quelconque des revendications 6 à 9, caractérisé en ce que les règles comportent un critère de péremption limitant leur activation dans le temps. 11. Système informatique selon l'une quelconque des revendications 6 à 10, caractérisé en ce qu'il comporte en outre un logiciel vertical (61, 65) et des moyens (71) d'interfaçage du système de gestion de règles avec le logiciel vertical (61,65). 12. Système informatique selon la revendication 11, caractérisé en ce qu'il comporte un interface homme-machine graphique et en ce que l'intégration entre le système de gestion des règles (71, 93) et le logiciel vertical (61, 65) s'effectue au niveau de l'interface homme-machine. 13. Système informatique selon l'une quelconque des revendications 6 à 12, caractérisé en ce qu'il comporte des moyens de connexion à des serveurs (57.1, 57.2, 57.3) et une base de données organisant dans un format prédéterminé les informations reçues des serveurs (57.1, 57.2, 57.3). 14. Système informatique selon l'une quelconque des revendications 6 à 13, caractérisé en ce qu'il comporte une base de codification (69) d'événements susceptible d'être traitée par des règles. 15. Système informatique selon l'une quelconque des revendications 6 à 14, caractérisé en ce que les règles mises en oeuvre sont gérées par le logiciel Lotus Notes. 16. Système informatique selon l'une quelconque des revendications 11 à 15, caractérisé en ce que le logiciel vertical (61, 65) est un logiciel d'assistance à la consultation médicale pour médecin. 17. Système informatique selon l'une quelconque des revendications 6 à 16, caractérisé en ce qu'il comporte des moyens de stockage locaux et/ou distants d'informations organisées et en ce que le système de gestion de règles assure un accès à un élément pertinent d'informations organisées stockées en fonction d'un contexte résultant de l'exécution d'un programme par ledit système informatique.