FR2793913A1

FR2793913A1 - Systeme informatique muni d'un systeme expert

Info

Publication number: FR2793913A1
Application number: FR9815337A
Authority: FR
Inventors: Bruno Ringo; Cyrille Barnerias; Philippe Presles; Alain Trebucq; Thierry Andro
Original assignee: Individual
Current assignee: Individual
Priority date: 1998-12-04
Filing date: 1998-12-04
Publication date: 2000-11-24

Abstract

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.Un système informatique selon la présente invention comporte un système de gestion de règles notamment un système expert comprenant des outils de sélection (25, 26) 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.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 la base et échanges des données).

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 le 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. Il 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 reconnaît 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 la 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 à Internet 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 la 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 contexte 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 le 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 reçu, alerte, ou nouveaux 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 le 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.

Il 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, il 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. Il 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. Il 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 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 replication 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 le 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 la description ci-après et des figures annexées données comme des exemples non limitatifs, et sur lesquelles : - la 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 la 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 5 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 ;

- la figure 10 est un masque (terminologie Lotus Notes) d'un générateur de règles en mode conception ; - la figure 11est un masque (terminologie Lotus Notes) de saisie d'un générateur de règles en mode création ; - la figure 12 est un exemple de l'affichage d'un exemple de document (terminologie Lotus Notes) règles ; - la figure 13 est un masque d'une règle d'affichage au niveau de l'interface hommemachine, le lien vers l'action et les comportements d'historisation éventuellement associés.

Sur les figures 1 à 13 et sur les listings incorporés au texte de la description, on a utilisé les mêmes références pour désigner les mêmes éléments.

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émente 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 la 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.

Il est bien entendu que la présente invention n'est pas limitée à une exécution séquentielle illustrée sur la 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 la 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 à la 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, l'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 le 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 Vue Règles actives d'une Base Fichier.nsf 29 comportant d'autre part une partie 31 intitulée Vue

Règles historisées et une partie 33 intitulée Vue Règles Déclenchées. 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 à la Vue des Règles actives 27 qui peuvent stocker d'autres règles qui ont été sélectionnées antérieurement et non encore purgées.

Sur la figure 3, l'Agent EVENEMENT assure un balayage, symbolisé par la flèche 35, de la Vue Règles actives 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 21 assure l'activation des règles historisées, c'est-à-dire les transferts de règles de la partie 31 de la Base Fichier.nsf, contenant des règles susceptibles de devenir actives après leur déclenchement vers la partie 27 Vue Règles actives. Le critère d'analyse des règles historisées symbolisée par la flèche 37 correspond par exemple à un événement et à la date système. Une règle histonsé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 la 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 actives 27 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 EVENEMENT 21 assure le déclenchement des Règles actives, c'est- à-dire l'analyse de règles de la Vue des Règles actives 27 symbolisée par la flèche 41 et leur transfert, symbolisé par la flèche 43, dans la Vue Règle Déclenchées 33. Les actions prévues dans les règles de la Vue Règles Déclenchées 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 le 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 Base Actions.nsf de documents et de formulaires. La règle

déclenchée est reliée sur la 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 la 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 Règles Déclenchées 33.

Le système sur la 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, comme il sera expliqué ci-après en référence aux figures 10 à 13, 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 la 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 connu est illustré sur la 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. Il est bien entendu que le poste client 55 selon la 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 Santé 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 la 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 à 100 % 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 le 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, le 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.

La mise en oeuvre d'un logiciel 71 réalisée à l'aide du logiciel Lotus Notes est expliqué en référence aux figures 10 à 13, étant bien entendue que des applications développées en tout langage, ou mettant en oeuvre tout générateur d'application, système de gestion de base de données, système expert et analogues ne sortent pas du cadre de la présente invention. Sur ces figures, on met en oeuvre la version française de ce logiciel étant bien entendu que la mise en oeuvre des versions anglaise, allemande ou autres ne sortent pas du cadre de la présente invention.

Le logiciel Lotus Notes utilise différentes entités. L'entité "formulaire" correspond à un masque de saisie vide. L'entité "document" correspond à une instantiation du formulaire, c'est-à-dire à un formulaire rempli. Une "règle" est un document contenant des paramètres d'activation d'un autre élément (document ou formulaire de la base action).

Bien que, sans sortir du cadre de la présente invention, les règles utilisées par les systèmes selon la présente invention puissent être écrites avec un simple éditeur de texte, on utilise avantageusement un générateur de règles dont un exemple est illustré sur la figure 10 en mode conception. La règle créée à la figure 10 correspond à un générateur de règles illustré sur la figure 11. Sur cette figure, on peut voir un générateur de règles parfaitement adapté aux processus 93 de la figure 9. Les règles correspondent à un niveau de sélection de critères de règles jmax égal 1, (référence 17, figure 1). Il s'agit d'élément déclencheur du contrôle de cette règle. L'action liée à la règle est définie dans le document règle par son type (cas d'un document dans la figure 12, référence 100) et par son identifiant ("ALD1 accident vasculaire cérébral invalidant" dans la figure 12, référence 101). Cette action sera activable si elle se retrouve dans les règles déclenchées, c'est-à-dire que l'événement déclencheur du contrôle a eu lieu et que les conditions (figure 12, référence 103) ont été satisfaites (d'où passage en règle activées) et que l'événement déclencheur du déclenchement a lieu avant l'événement déclencheur de péremption de la règle. Lors de son activation (bouton "exécuter" de la figure 13), cette règle peut être historisée si elle a une fréquence de redéclenchement (figure 12, référence 104). Une règle historisée peut être directement activée si son événement de déclenchement a lieu après sa date de réactivation (le contrôle des conditions n'est plus réalisé). Sur la figure 12, on peut voir une règle exécutable réalisée par remplissage du masque vide de la figure 11créée à l'aide du masque de conception de la figure 10. Cette règle est associée à document de la base action ci-après.

OK/FERMER
ALD1: ACCIDENT VASCULAIRE CEREBRAL INVALIDANT
Le terme d'accident vasculaire cérébral désigne :
1 Les accidents ischémiques cérébraux avec ou sans nécrose cérébrale quels qu'en soient la cause ou le mécanisme,
2 Les thrombophlébites cérébrales,
3 Les accidents hémorragiques cérébraux, cérébro-méningés ou méningés.

Dans ces trois types d'accidents d'étiologie vasculaire relativement facile à confirmer, l'exonération s'impose dès la phase aiguë en présence de troubles neurologiques importants nécessitant une prise en charge lourde, des examens coûteux, des soins de maintenance puis de rééducation active. Cette période peut être très prolongée et le caractère invalidant de l'accident ne se discute pas.

L'évolution, variable, conduit à distinguer : - les cas où persiste un important déficit neurologique entraînant une invalidité évidente justifiant l'exonération du ticket modérateur, - les cas où persistent des séquelles moins importantes mais justifiant une rééducation prolongée. Ces situations semblent devoir entraîner l'exonération du ticket modérateur pour une période limitée.

En dehors de ces cas les patients peuvent, le cas échéant, être exonérés du ticket modérateur au titre d'une autre affection de longue durée (artériopathie chronique, insuffisance cardiaque, diabète, hypertension artérielle).

Sur la figure 13, on peut voir un masque règle 2 de la base fichier.nsf permettant d'affecter des actions à des règles comportant notamment des boutons de déclenchement susceptible d'être associés à des actions suggérées à un médecin tel que exécuter cette règle, exécuter, OK, ignorer/effacer ou fermer/conserver.

Ci-après, on a reproduit le code source d'un script en langage Lotus Script, d'un exemple de logiciel 71 de la figure 9. Les éléments soulignés ne font pas parties du code source mais sont des références aux figures.

Définition de constantes permettant d'accéder aux autres bases notes (ce script fait partie de la base fichier.nsf dans le cas de Médical Plus.) Option Public Const BASEGDP = "siamuc/Gestion.nsf' Const BASEREGLES = "siamuc/Regles.nsf' Const BASEFPA = "siamuc/Fichier.nsf'
La fonction fBalaieRegle est la fonction d'activation des règles :son rôle est de balayer les règles présentes sur le poste et de contrôler celles ' qui ont l'événement courant (passé en paramètre: sEven) comme événement déclencheur de contrôle.

C'est pour effectuer ces contrôles que ' la routine qui l'appelle doit lui passer des données liées à l'événement (passées par le paramètre Liste).

' De plus, une règle peut avoir un comportement "d'historisation " (suivi de cas sur un patient). La fonction fBalaieRegle ne doit donc pas activer ' une règle qui est déjà historisée pour le patient. Pour cela, pour toute règle ayant l'événement courant comme déclencheur de contrôle .la fonction , commence par vérifier que cette règle (identifiée par son numéro) est absente de la liste des règles historisées pour ce patient. Cette fonction à donc besoins de .connaître le patient courant (passé en paramètre :clePatient).

Function fBalaieRegle( Liste List As String, sEven As String, db As NotesDatabase, clePatient As String) As Integer
On Error Goto PB
On Error ErrNotAListTag Goto PBDONNEE 'cette fonction balaie les règles correspondant à l'événement sEven et les copies dans la base fichier patient seulement 'si les données de la liste passée en paramètres répondent aux conditions et que cette règle n'a pas été historisée pour le patient
Dim reglesDb As New NotesDatabase( "" , BASEREGLES ) 'nouvel objet base lié à la base des règles
Dim reglesView As NotesView
Set reglesView = reglesDb.GetView("ReglesView") 'nouvel objet vue lié à la vue ReglesView de la baseRègles.nsf
Dim reglesDocs As NotesDocumentCollection

Set reglesDocs = reglesView.GetAIiDocumentsByKey(sEven) 'collection de documents récupérant les règles ayant l'événement courant comme déclencheur de contrôle.

Dim reglesDoc As NotesDocument 'variable qui contiendra les documents successifs de la collection
Dim ok As Integer 'mis à zéro si la règle ne doit pas s'appliquer
If reglesDocs.Count > 0 Then 25
Dim iCtr As Integer iCtr = 0 "********* boucle sur toutes les règles potentiellement applicables**************************

Fori%=1 To reglesDocs.Count
Set reglesDoc=reglesDocs.GetNthDocument(i%) 'initialisation du document
Dim vFrequenceRegle As Variant 'contiendra la fréquence de renouvellement d'une règle historique

vFrequenceRegle = reglesDoc.GetltemValueffrequenceMAJRegles") 'récupération de la clé de la règle pour vérifier qu'elle n'est pas déjà présente dans l'historique du patient.

Dim sNumeroRegle As String sNumeroRegle = Cstr ( reglesDoc.numeroMAJRegles(O) ) 31

If Not Strcompare(vFrequenceRegle(0),"")=0 Then 'si la règle est une règle historique 'récupération des règles historiques de ce patient dans la base fichier patient Dim historiqueView As NotesView Set historiqueView = db.GetView("ReglesHistoriquesView") Dim historiquesDocs As NotesDocumentCollection Dim tCleHisto (1 ) As String 'clé de recherche à deux dunension clé patient et clé règle tCleHisto (0)=clePatient tCleHisto (1)=sNumeroRegle

Set historiquesDocs = historiqueView.GetAlIDocumentsByKey(tCleHisto) 'si la règle a été historisée, la collection n'est pas vide
If Not historiquesDocs,Count = 0 Then
Call sMajLog( ERREUR, Now + " fBalaieRegle: Regle déjà présente dans l'historique de ce patient") ok=0
Goto DOCSUIVANT 'branchement direct au doc suivant et pas de contrôle des conditions de déclenchement
End If
End If 's'il s'agissait d'une regle historique , analyse des conditions de déclenchement de la règle récupérées sous forme d'un tableau de string car le champ est un texte multivalué For j%=1 To 3 3
Dim sOu As String sOu = "listeMAJRegles"+Cstr(j%)
Dim vChaine As Variant vChaine = reglesDoc.GetltemValue(sOu)
If Strcompare( vChaine(O), "") = 0 Then Goto OUSUIVANT
Dim sTemp As String sTemp=""
Forall element In vChaine sTemp=sTemp+" / " + element
End Forall

Call sMajLog( NORMAL, Now + " fBalaieRegle: controle de"+ sOu +" : "+ sTemp) ok%=1
Dim iLen As Integer 'taille d'une ligne
Dim iSeparateur As Integer 'position du "="
Dim sValeur As String 'valeur test
Dim sParametre As String 'paramètre à comparer
Dim sComp As String 'code comparaison
Dim Regles(2) As String 'tableau' type de comparaison (=, 2 <>, 3 >, 4<, nom du paramètre, valeur '******* boucle sur les éléments successifs du tableau de string (conditions de déclenchement) ******
Forall sLigne In vChaine iSeparateur% = Instr(1.sLigne,"=",0) iLen%=Len(sLigne)
If iSeparateur% Then 'ne s'exécute pas si la ligne ne contient pas le signe "=" sValeur$ = Right$ (sLigne, iLen% - iSeparateur%) 'valeur récupère ce qu'il yaà droite du séparateur sParametre$ = Left$( sLigne , iSeparateur% - 1 ) sComp$=Left$( sParametre$,1) 'comparateur récupère le premier caractère sParametre=Right$(sParametre$,iSeparateur%-2) 'paramètre récupère ce qu'il y a à gauche du séparateur,a droute du =
Regles (0) = sComp$ 'stockage du type de comparaison dans le tableau Règles
Regles (1 ) = sParametre$ 'stockage du paramètre dans le tableau Règles
Regles (2) = sValeur$ 'stockage de la valeur dans le tableau Règles 25 'quand la ligne est décodée, comparaison des valeurs en fonction du code comparaison
Select Case Cint( Regles(O) )
Case 1 'contrôle à l'égalité
If Not Strcompare ( Regles(2),Liste( Regles(1)))=0 Then ok =
Goto OUSUIVANT
End If
Case 2 'contrôle à l'inégalité
If Strcompare ( Regles(2),Liste( Regles(1 )))=0 Then ok =
Goto OUSUIVANT
EndIf
Case 3 'contrôle à l'infériorité

If Not Cint(Liste( Regles(1))) < Cint(Regles(2)) Then ok =
Goto OUSUIVANT
End If Case 4 'contrôle à la supériorité
If Not Cint(Liste( Regles(1))) > Cint(Regles(2)) Then ok =
Goto OUSUIVANT
End If
Case 5 'contrôle que la valeur du paramètre FPA fait partie de la liste de valeurs de la règle If flsElement ( Liste( Regles(1) ), Regles (2) , = 1 Then
Goto LIGNESUIVANTE
Else ok=0
Goto OUSUIVANT End If Case 6
If flsElement (Regles(2), Liste( Regles(1) ), 44) = 1 Then
Goto LIGNESUIVANTE
Else ok=0
Goto OUSUIVANT
End If
Case 7 'contrôle que la liste de valeur du paramètre FPA a un élément commun avec la liste de valeurs de la règle
If flntersection ( Liste( Regles(1) ), Regles(2) , Asc (";"), Asc("/")) = 1 Then
Goto LIGNESUIVANTE
Else ok=0
Goto OUSUIVANT End If Case 8 ok=1
Call sMajLog( NORMAL, Now + " Attention: régie systématiquement appliquées sur "+ sEven + "!!!!!" )
Goto EXECUTION
Case Else
Call sMajLog(ERREUR, Now + " fBalaieRegle: mauvaise régie détectée, pas de code comparateur valide" )
End Select
End If 'la ligne contenait le séparateur "="

LIGNESUIVANTE:
End Forall '******************* passage à la ligne suivante ****************** 'après analyse, si les coti(litions sont vérifiées, ou s'il n'y avait aucune condition 'création d'un nouveau document copiant le document règle dans la base fichier patient If ok=1 Then EXECUTION:
Dim newDoc As NotesDocument
Set newDoc = reglesDoc.CopyToDatabase(db) newDoc.devenirMAJRegles="Active" 'marquage de la copie de règle comme active newDoc.numeroMAJRegles=sNumeroRegle
26
If Not Strcompare (clePatient,"") = 0 Then 26

newDoc.cle MAJ Reg les=clePatient Dim adminDoc As NotesDocument Set adminDoc = db.GetDocumentByID( fGetAdmin(clePatient) ) 27 newDoc.nomMAJRegles = adminDoc.nomFPAAdministratif(O)

newDoc.prenomMAJRegles = adminDoc.prenomFPAAdministratif(0)
Else
Dim logDoc As NotesDocument
Set logDoc = db.GetDocumentByID( fGetLog() )
Dim sUtilisateur As String sUtilisateur = logDoc.utilisateurFPALog(O)
Dim iSeparateur1 As Integer iSeparateur1 = Instr(1, sUtilisateur, "/", 1)
Dim iSeparateur2 As Integer iSeparateur2 = Instr(iSeparateur1+1, sUtilisateur, "/", 1) newDoc.nomMAJRegles = Mid( sUtilisateur, 1 , iSeparatuer1-1) newDoc.prenomMAJRegles = Mid( sUtilisateur, iSeparateur1 + 1 , iSeparateur2 - iSeparateur1-1 ) newDoc.cleMAJRegles=Mid( sUtilisateur, iSeparateur2 + 1 , Len(sUtilisateur) iSeparateur2 )
End If
Call newDoc.Save(True,True) iCtr=iCtr+1
Goto DOCSUIVANT
End If OUSUIVANT:
Next DOCSUIVANT:
Next

********************** passage au doc règle suivant **********************
End If 's'il n 'y avait pas de règle
Call sMajLog( NORMAL, Now + " fBalaieRegle: " + Cstr(reglesDocs.Count) + " régies sont controlées") fBalaieRegle = iCtr
Call sMajLog( NORMAL , Now + "fBalaieRegles terminé, "+ Cstr(iCtr) +" régies appliquées sur "+ sEven )
Exit Function PB :
Call sMajLog( ERREUR, Now + " fBalaieRegle: problème " + Error() + Cstr(Erl()) ) fBalaieRegle=iCtr
Exit Function PBDONNEE :
Call sMajLog( ERREUR, Now + " fBalaieRegle: problème de donnée "+ Error() )
Resume Next End Function

Function fAction (sEven As String, db As NotesDatabase, clePatient As String) As Integer
On Error Goto PB 'premièrement. ce script balaie les règles historiques précédemment stockées dans le fichier patient pour éventuellement les transférer vers 'les règles actuelles
Dim histoDocs As NotesDocumentCollection
Dim histoView As NotesView
Dim histoDoc As NotesDocument

Set histoView = db.GetView("RegIesHistariquesView") Set histoDocs = histoView.GetAlIDocumentsByKey(clePatient) 37 If histoDocs.Count > 0 Then
Dim sDate As String 39
Dim dNow As New NotesDateTime (Now)
For i%=1To histoDocs.Count Set histoDoc=histoDocs.GetNthDocument(i%) sDate =histoDoc.dateMAJRegles(0)
Dim dDate As New NotesDateTime(sDate)
Dim IDiff As Long IDiff = dNow.TimeDifference(dDate)
If IDiff > 0 Then histoDoc.devenirMAJRegle = "Activée"
Call histoDoc.Save(True,True)
End If
Next End If 'trois vues permettent de visualiser les mêmes règles activées, mais elles les classes différemment ..

Dim ActivesDepartView As NotesView

Set ActivesDepartView = db.GetViewÇ'ReglesActivesDepartView") Dim ActivesDestructeurView As NotesView Set ActivesDestructeurView = db.GetView("ReglesActivesDestructeurview") Dim ActivesDeclencheurView As NotesView Set ActivesDeclencheurView = db.GetView("RegIesActivesDeclencheurView")

'Purge de.\ document.\ ayant l'événement courant comme destructeur et présent dans la vue Active Destructeur 'cette vue regroupe les r-ègles actives marquées purgeables triés par destructeurs
Dim ReglesPurgables As NotesDocumentCollection
Call ActivesDestructeurView.Refresh 35

Set ReglesPurgables = ActivesDestructeurView.GetAlIDocumentsByKey(sEven) Call RegIesPurgables.RemoveAll(True) 'Marquage des documents ayant l'événement courant comme départ et présent dans la vite ActiveDepart 'cette vue regroupe les règles actives non marquées purgeables triés par événement de contrôle ' cela permet d'exécuter une fois une règle ayant le même événement de contrôle et de purge
Dim ReglesNouvelles As NotesDocumentCollection
Call ActivesDepartView.Refresh
Set ReglesNouvelles = ActivesDepartView.GetAlIDocumentsByKey(sEven)
If ReglesNouvelles.Count > 0 Then

Call Reg lesno uvelles. Sta mpal 1 ("evenementMAJ Reg les"," Pu rg able") End If 'Copie des règles déclenchables et marquage déclenchée de la copie Dim ReglesDeclenchees As NotesDocumentCollection Call ActivesDeclencheurView.Refresh Set ReglesDeclenchees = ActivesDeclencheurView.GetAlIDocumentsByKey(sEven) 41 Dim Action As Integer iAction = PAS ACTION If ReglesDeclenchees.Count > 0 Then
For i%=1 To ReglesDeclenchees.Count
Dim regleDoc As NotesDocument
Set regleDoc = ReglesDeclenchees.GetNthDocument(i%)
Dim newDoc As New NotesDocument(db) 4
Call regleDoc.CopyAllltems(newDoc) newDoc.devenirMAJRegles = "Déclenchée"
Call newDoc.Save(True,True)
If Strcompare (regleDoc.caractereMAJRegles(O), "O") = 0 Then iAction=ACTION~O
Else
If Strcompare (regleDoc.caractereMAJRegles(O), "F") = 0 And iAction = PAS~ACTION Then iAction=ACTION~F End If

End If
Next End If 'Analyse de la liste des règles déclenchées pour retour vers processus de présentation.

Dim DeclencheesView As NotesView

Set DeclencheesView = db.GetView("RegIesDeclencheesView") Call DeclencheesView.Refresh Dim sPresentation As String Dim iCtr As Integer iCtr = 0 Dim regleSpeDoc As NotesDocument Set regleDoc=DeclencheesView.GetFirstDocument Do While ( Not regleDoc Is Nothing And iCtr<10 ) sPresentation = sPresentation + Chr(13) + Left$(regleDoc.prenomMAJRegles(0), 1) + "." + regleDoc.nomMAJRegles(O) + " " + regleDoc.resumeMAJRegles(0) iCtr = iCtr + 1
Set regleDoc = DeclencheesView.GetNextDocument(regleDoc) Loop 'Retour vers processus par fichier texte nonnahsé.

Dim iNumeroFichier As Integer iNumeroFichier = Freefile sNom = iniVal("CheminCom") + "\" + iniVal("RetourFile") Open sNom For Output As iNumeroFichier Select Case (iAction) Case ACTION~O
Write # iNumeroFichier, "0" Case ACTION
Write # iNumeroFichier, "F" Case Else
Write # iNumeroFichier, "R" End Select Print # iNumeroFichier, sPresentation$ Close(iNumeroFichier) fAction = iAction

Call sMajLog( NORMAL, Now + " fAction: retour "+ sPresentation ) 'purge de la vue règles qui contient les règles dépassées Dim view As NotesView

Set view = db.GetView("RegIesPerimeesView")
Dim perimeDoc As NotesDocument
Dim nextPerimeDoc As NotesDocument
Set perimeDoc = view.GetFirstDocument
Do While Not perimeDoc Is Nothing
Set nextPerimeDoc = view.GetNextDocument(perimeDoc)
Call perimeDoc.Remove(True)
Set perimeDoc = nextPerimeDoc
Loop
Exit Function PB :
Call sMajLog( ERREUR, Now + " fAction: problème "+ Error() ) iNumeroFichier = Freefile sNom = iniVal("CheminCom") + "temp/retour.txt"
Open sNom For Output As iNumeroFichier
Wnte # iNumeroFichier, "R"
Close(iNumeroFichier)
Exit Function End Function

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 le 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 le 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 notamment à l'informatique et aux télécommunications.

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, ULR, etc.) mobilisées de façon contextuelle par ordinateur et partagée en réseau (mise à jour de la base et échanges des données).

Claims

REVENDICATIONS 1. 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 (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.
2. Système informatique selon la revendication 1, 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.
3. Système informatique selon la revendication 1 ou 2, caractérisé en ce qu'il comporte des moyens de replication (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.
4. Système informatique selon l'une quelconque des revendications précédentes, caractérisé en ce que les règles comportent un critère de péremption limitant leur activation dans le temps.
5. Système informatique selon l'une quelconque des revendications précédentes, 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).
6. Système informatique selon la revendication 5, 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.
7. Système informatique selon l'une quelconque des revendications précédentes, 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).
8. Système informatique selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une base de codification (69) d'événements susceptible d'être traitée par des règles.
9. Système informatique selon l'une quelconque des revendications précédentes, caractérisé en ce que les règles mises en oeuvre sont gérées par le logiciel Lotus Notes.

<Desc/Clms Page number 28>
10. Système informatique selon l'une quelconque des revendications 5 à 9, caractérisé en ce que le logiciel vertical (61,65) est un logiciel d'assistance à la consultation médicale pour médecin.
11. Système informatique selon l'une quelconque des revendications précédentes, 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.