FR2848314A1 - Procede de synchronisation au sein d'un systeme de type client serveur destine a la gestion d'un systeme qualite, de management, d'evaluation ou de coordination - Google Patents

Abstract

L'invention concerne un procédé de synchronisation de données entre au moins un poste client (1) et un poste serveur (2), connecté l'un à l'autre par l'intermédiaire d'un réseau de télécommunications (3), le procédé étant déclenché par l'émission d'une requête de synchronisation, caractérisé en ce que le procédé comporte des étapes de :- création par le poste serveur d'un fichier de description d'un ensemble de données destiné au poste client sur la base des enregistrements contenus dans le poste serveur,- transmission du fichier de description au poste client à travers le réseau de télécommunications,- établissement par le poste client d'une liste de données à échanger entre les deux postes client et serveur,- échange à travers le réseau de télécommunication entre le poste client et le poste serveur des données désignées par la liste précédemment établie.

Description

<Desc/Clms Page number 1>

L'invention concerne les procédés de synchronisation des données au sein d'un système de type client/serveur destiné à la gestion des systèmes qualité, d'organisation, de management, d'évaluation et de coordination, notamment dans tous les secteurs médicaux (professions de santé libérales, établissements de santé, réseaux de santé), mais également dans les entreprises multisites ou multi services et les administrations.

Actuellement, dans un système comprenant au moins un poste serveur et au moins un poste client relié l'un à l'autre par un réseau de télécommunication, la liaison entre les deux postes doit toujours être établie dès qu'une information centralisée sur le poste serveur est nécessaire pour le poste client, ou dès que le client modif-ie une information centralisable pour que le poste serveur enregistre cette modification. Ce type de synchronisation entre le poste client et le poste serveur nécessite des connexions permanentes très fiables entre les deux.

Toutefois, la disponibilité de telles connexions n'est pas toujours acquise : en effet, le serveur peut être indisponible, le réseau encombré ou inaccessible, le poste client nécessite une liaison téléphonique pour se connecter,... Ceci est préjudiciable à la bonne marche du système et à l'intégrité des données échangées entre le poste client et le poste serveur, surtout dans le cadre du

<Desc/Clms Page number 2>

fonctionnement d'un système de gestion d'assurance qualité.

Un but de l'invention est de fournir un procédé de synchronisation de données dans un système client/serveur de gestion d'un système d'assurance qualité résolvant les problèmes précédents.

A cet effet, on prévoit, selon l'invention, un procédé de synchronisation de données entre au moins un poste client comportant des moyens de stockage d'un ensemble de données et un poste serveur comportant des moyens des stockage d'au moins une base d'enregistrement de données, connectés l'un à l'autre par l'intermédiaire d'un réseau de télécommunications, le procédé étant déclenché par l'émission d'une requête de synchronisation, caractérisé en ce que le procédé comporte des étapes de : - suite à la réception de la requête, création par le poste serveur d'un fichier de description comportant une description complète d'un ensemble de données associées au poste client contenu dans la base des enregistrements, transmission du fichier de description au poste client à travers le réseau de télécommunications, - suite à la réception du fichier système, établissement par le poste client d'une liste de données à échanger entre les deux postes client et serveur, en comparant chaque donnée décrite dans le fichier de description à la donnée correspondante

<Desc/Clms Page number 3>

enregistrée dans les moyens de stockage du poste client, - échange à travers le réseau de télécommunication entre le poste client et le poste serveur des données désignées par la liste précédemment établie.

Ainsi, la synchronisation s'effectue en une seule fois et ne nécessite l'établissement que d'une connexion entre le poste serveur et le poste client le temps de le transmission des données de la synchronisation, le poste client pouvant travailler hors ligne jusqu'à la prochaine requête en synchronisation émise, une connexion permanente n'étant pas nécessaire (ce qui est idéal pour une connexion via une ligne téléphonique) ou bien pouvant être établi alors que le serveur est disponible, le réseau optimal.

Avantageusement mais facultativement, le procédé de synchronisation présente au moins l'une des caractéristiques suivantes : - suite à la réception du fichier système par le poste client, comparaison par ce dernier des informations de version et/ou de révision des différentes données, informations contenues dans le fichier de description, avec des informations de version et/ou de révision des données correspondantes enregistrées dans les moyens de stockage du poste client.

<Desc/Clms Page number 4>

- la liste de données à échanger comporte une première liste de données destinées à être transmises par le poste serveur au poste client et une deuxième liste de données destinées à être transmises par le poste client au poste serveur.

- la deuxième liste est élaborée alors que le poste client est hors ligne dès qu'une donnée est modifiée ou créée en local dans les moyens de stockage du poste client.

- le procédé comporte une étape supplémentaire d'envoi sélectif par le poste client au poste serveur d'un ensemble d'informations de mises à jour depuis la précédente synchronisation concernant un utilisateur du poste client et enregistrées dans les moyens de stockage du poste client.

- le procédé comporte une étape supplémentaire d'échange sélectif de messages de l'utilisateur entre les postes client et le poste serveur, une première partie des messages étant enregistrée dans les moyens de stockage du poste serveur et une deuxième partie des messages étant enregistrée dans les moyens de stockage du poste client.

- l'échange de messages comprend des étapes de : - réception de la première partie des messages pour l'utilisateur par le poste client, et - envoi au poste serveur de la deuxième partie des messages de l'utilisateur.

<Desc/Clms Page number 5>

- le procédé comporte en outre une étape supplémentaire de mise à jour sélective du logiciel enregistré dans les moyens de stockage du poste client.

- la requête en synchronisation est envoyée automatiquement par le poste client au poste serveur.

- la requête en synchronisation est envoyée sur ordre de l'utilisateur par le poste client au poste serveur.

On prévoit, aussi selon l'invention, un support informatique de stockage, caractérisé en ce qu'il comporte un logiciel apte à mettre en #uvre le procédé de synchronisation de données présentant au moins l'une des caractéristiques précitées.

En plus, on prévoit, selon l'invention, un procédé de synchronisation de données entre au moins un poste client comportant des moyens de stockage d'un ensemble de données et un poste serveur comportant des moyens de stockage d'au moins une base d'enregistrement de données, connectés l'un à l'autre par l'intermédiaire d'un réseau de télécommunications, le procédé étant apte à être mise en #uvre sur le poste client, caractérisé en ce que le procédé comporte des étapes de : - émission d'une requête de synchronisation vers le poste serveur, - réception à travers le réseau de télécommunications d'un fichier de description du poste serveur en réponse à la requête, comportant une description

<Desc/Clms Page number 6>

complète d'un ensemble de données associées au poste client contenu dans la base des enregistrements, suite à la réception du fichier de description, établissement d'une liste de données à envoyer vers et/ou à télécharger du poste serveur, en comparant chaque donnée décrite dans le fichier de description à la donnée correspondante enregistrée dans les moyens de stockage du poste client, - envoi vers et/ou téléchargement du poste serveur, à travers le réseau de télécommunications, des données désignées par la liste précédemment établie.

Avantageusement mais facultativement, le procédé de synchronisation présente au moins l'une des caractéristiques suivantes : - suite à la réception du fichier de description, le poste client compare des informations de version et/ou de révision des différentes données, informations contenues dans le fichier de description, avec des informations de version et/ou de révision des données correspondantes enregistrées dans les moyens de stockage du poste client.

- la liste de données à envoyer vers et/ou à télécharger du poste serveur comporte une première liste de données destinées à être téléchargées du poste serveur et une deuxième liste de données destinées à être envoyées au poste serveur.

<Desc/Clms Page number 7>

- la deuxième liste est élaborée alors que le poste client est hors ligne, dès qu'une donnée est modifiée ou créée en local dans les moyens de stockage du poste client.

- le procédé comporte une étape supplémentaire d'envoi sélectif au poste serveur d'un ensemble d'informations mises à jour depuis la précédente synchronisation concernant un utilisateur du poste client et enregistrées dans les moyens de stockage du poste client.

- le procédé comporte une étape supplémentaire d'envoi sélectif vers et/ou de téléchargement sélectif du poste serveur de messages de l'utilisateur, une première partie des messages étant enregistrée dans les moyens de stockage du poste serveur et une deuxième partie des messages étant enregistrée dans les moyens de stockage du poste client.

- le procédé comporte en outre une étape supplémentaire de mise à jour sélective du logiciel enregistré dans les moyens de stockage du poste client.

- la requête en synchronisation est envoyée automatiquement par le poste client au poste serveur.

- la requête en synchronisation est envoyée sur ordre de l'utilisateur par le poste client au poste serveur.

De plus, on prévoit, selon l'invention, un support informatique de stockage, caractérisé en ce qu'il comporte un logiciel apte à mettre en #uvre le procédé de

<Desc/Clms Page number 8>

synchronisation de données présentant au moins l'une des caractéristiques précitées.

En outre, on prévoit aussi, selon l'invention, un procédé de synchronisation de données entre au moins un poste client (1) comprenant des moyens de stockage d'un ensemble de données et un poste serveur (2) comprenant des moyens de stockage d'au moins une base d'enregistrements de données, connectés l'un à l'autre par l'intermédiaire d'un réseau de télécommunications (3), le procédé étant apte à être mise en #uvre sur le poste serveur, caractérisé en ce que le procédé comporte des étapes de : - Réception à travers le réseau de télécommunication d'une requête de synchronisation du poste client, - suite à la réception de la requête, création d'un fichier de description comportant la description complète d'un ensemble de données associées au poste client contenu dans la base des enregistrements, - transmission du fichier de description au poste client à travers le réseau de télécommunications, - réception du et/ou envoi vers le poste client à travers le réseau de télécommunications d'un deuxième ensemble de données sur requête du poste client.

Avantageusement mais facultativement, le procédé de synchronisation présente au moins l'une des caractéristiques suivantes :

<Desc/Clms Page number 9>

- le poste serveur envoie vers le poste client un premier ensemble de données sur requête du poste client, puis réceptionne du poste client un deuxième ensemble de données.

- suite à la réception du deuxième ensemble de données du poste client, le poste serveur acquitte la réception et met à jour, dans les moyens de stockage du poste serveur, les enregistrements la base des enregistrements de données associés au poste client.

- le procédé comporte une étape supplémentaire de réception sélective du poste client d'un ensemble d'informations de mises à jour depuis la précédente synchronisation concernant un utilisateur du poste client et enregistrement de ces information sur les moyens de stockage du poste serveur.

- le procédé comporte une étape supplémentaire d'envoi sélectif vers et/ou de réception sélective du poste client de messages de l'utilisateur, une première partie des messages étant enregistrée dans les moyens de stockage du poste serveur et une deuxième partie des messages étant enregistrée dans les moyens de stockage du poste client.

- le procédé comporte en outre une étape supplémentaire d'envoi sélectif vers le poste client d'une mise à jour éventuelle du logiciel enregistré dans les moyens de stockage du poste client.

On prévoit aussi, selon l'invention,- un support informatique de stockage, caractérisé en ce qu'il comporte

<Desc/Clms Page number 10>

un logiciel apte à mettre en #uvre le procédé de synchronisation de données présentant au moins l'une des caractéristiques précitées.

D'autres caractéristiques et avantage de l'invention apparaîtront lors de la description ci-après d'un mode de réalisation de celle-ci, aux dessins annexés : - la figure 1 est un schéma représentant un réseau où le procédé selon l'invention est mis en #uvre, - les figures 2a et 2b sont un organigramme d'établissement d'un fichier système par le procédé selon l'invention, - la figure 3 est un organigramme illustrant un mode de réalisation du procédé selon l'invention, - la figure 4 est un extrait d'une base de données de la partie commune d'un système d'assurance qualité, - les figures 5 et 6 sont des extraits d'une base de données de la partie propre à un utilisateur du système d'assurance qualité, - la figure 7 est une partie d'une représentation visuelle d'un système d'assurance qualité, et la - la figure 8 est une exemple d'une fichier system.xml obtenu par le procédé selon l'invention.

<Desc/Clms Page number 11>

Le mode de réalisation du procédé selon l'invention est décrit ci-après dans le cadre d'un cabinet médical. Il peut être adapté à tout autre secteur d'activité pour lequel il existe un système d'assurance qualité.

De manière globale, un système d'assurance qualité comprend un ensemble de documents (PR, MO et DO définis ci-après) définis par un administrateur sur un poste serveur et constituant la base du système d'assurance qualité, commune à tous les utilisateurs dans un secteur d'activité donné (ici un cabinet médical).

Un logiciel à installer sur un poste client est fourni à chaque utilisateur de manière à ce que le poste client puisse s'interfacer avec le poste serveur. Chaque utilisateur peut installer l'application sur un ou plusieurs ordinateurs lui appartenant et qui constituent le poste client.

Le logiciel installé sur le poste client récupère alors l'ensemble des éléments (PR, MO et DO) du système d'assurance qualité, en exécutant une première fois le principe de synchronisation selon l'invention décrit ultérieurement de manière à effectuer une initialisation du poste client.

De plus, le logiciel installé sur le poste client permet à chaque utilisateur d'ajouter ses propres éléments au système d'assurance qualité, de réécrire certains éléments (MO par exemple) et de renseigner les informations relatives à son activité (liste des pièces, des appareils, des personnes...). Ceci permet de faire vivre

<Desc/Clms Page number 12>

le système d'assurance qualité due l'utilisateur. L'ensemble de ces opérations est effectué alors que le poste client n'est pas en ligne ou connecté au poste serveur via un réseau de télécommunication.

Les informations sont ensuite transmises vers le serveur, soit automatiquement en fin de journée soit sur demande, par le déclenchement du procédé de synchronisation selon l'invention, ceci afin de : - conserver toutes les informations de l'utilisateur (archivage). contrôler le respect des diverses échéances (rappel des vaccins, des tests de dépistage, des contrôles d'étalonnage pour les appareils... dans le cas d'un cabinet médical). réaliser des statistiques afin de suivre l'évolution d'un utilisateur et d'établir des comparaisons entre utilisateur (dans un souci d'optimisation de la base du système d'assurance qualité lié à un secteur d'activité).

- permettre à un utilisateur ayant installé l'application sur plusieurs ordinateurs du poste client, de synchroniser chacun des ordinateurs avec le poste serveur, et ainsi de garantir que chaque ordinateur possède les mêmes informations.

<Desc/Clms Page number 13>

I. Présentation du système
I.1. Eléments constitutifs du système
Les éléments du système d'assurance qualité s'organisent autour de différents types.

I.1.1. Procédures (PR)
Les procédures (PR) ont pour but de décrire les règles d'organisation régissant un service, une activité, une fonction, une tâche ou un processus de traitement. Les procédures décrivent les pratiques ou procédés, c'est-àdire : qui réalise les diverses activités décrites, comment, quand, pourquoi. Quand cela est nécessaire, une procédure peut faire référence à un ou plusieurs modes opératoires plus spécifiques.

1.1.2. Modes opératoires (MO)
Les modes opératoires (MO) ont pour but de décrire dans le détail les actions à réaliser et les consignes à appliquer dans l'ordre logique des phases de déroulement d'une tâche ou d'un processus du système d'assurance qualité. Deux types de MO ont été définis : - elab . c'est un document texte, dont chaque modification entraîne une nouvelle version.

- table . c'est un document texte organisé sous forme de tableau, archivé selon les mêmes principes que pour les MO de type elab .

Tous les modes opératoires sont définis par défaut par l'administrateur sur le poste serveur de manière à constituer une partie de la base commune, mais l'utilisateur peut modifier, en utilisation, certains

<Desc/Clms Page number 14>

modes opératoires indiqués comme modifiables par l'administrateur.

1.1.3. Actes de soins (ADS)
Les actes de soins (ADS) sont propres à l'activité d'un cabinet médical par exemple. Ils ont pour but de décrire, dans le détail, les actions à réaliser et/ou les consignes à appliquer dans l'ordre logique des phases de déroulement d'un soin. Leur présentation est très similaire à celle des MO de type Table.

1.1.4. Documents (DO)
Les documents (DO) sont des formulaires (mis à part les DO de type Mod ) permettant de saisir toutes les informations qualité de l'abonné. Plusieurs types de DO sont définis : - Mod . ce document est un modèle type proposé par l'administrateur du poste serveur, non modifiable par l'utilisateur et fourni au format PDF (Portable Document Format ou format de document portable). Un seul paramètre version est nécessaire pour ce type de document. La balise XML (extensible Markup Language ou langage de balisage extensible) qui représente, de manière préférentielle, ce type de document est de la forme : <DO id="2" ref="1.2.2" type="Mod" title="Modèle type d'un MO" version="2"/>
Cet exemple indique que le DO numéro 2 de type Mod a pour référence 1.2.2 et pour titre Modèle type d'un MO dans sa version 2.

- Arc : c'est un DO rempli par l'utilisateur, avec un archivage de toutes les versions, la dernière

<Desc/Clms Page number 15>

étant la version active pour l'utilisateur, les autres étant considérées comme désuètes. La version représente le nombre de modifications apportées au document par l'administrateur du poste serveur, et la revision , le nombre de modifications apportées par l'utilisateur.

Un document de ce type peut être de la forme suivante:
Do n l D01.1.1 Référentiels et engagements
1. Textes référentiels
Texte...texte...texte...texte...texte...texte...texte...t exte...texte...texte...texte...texte...texte...texte...te xte...texte...

2. Engagements
Texte...texte...texte...texte...texte...texte...texte...t exte...texte...texte...texte...texte...texte...texte...te xte...texte...

Le document DO numéro un de chaque utilisateur est ainsi formé en assemblant : les informations données par l'administrateur du poste serveur, que sont la référence (1. 1.1), le titre (Référentiels et engagements) et le premier paragraphe (1.
Textes référentiels ; Partie définie par l'administrateur et commune à tous les utilisateurs. Toute modification génère une nouvelle version),

<Desc/Clms Page number 16>

les informations données par l'utilisateur, qui constituent le deuxième paragraphe (2.

Engagements ; Partie propre à chaque utilisateur. Toute modification génère une nouvelle révision).

En supposant que le DO ci-dessus soit dans sa première version, il est possible que dans sa version 2 il ait comme référence 6. 5.7 , ainsi qu'un titre et des textes référentiels différents.

Le DO n 1 est représenté de manière préférentielle par le fichier XML suivant : <?xml version="1.0" encoding="iso-8859-1"?> <DO id="l" ref="l.l.l" type="Arc" title="Référentiels et engagements" version="4" revision="l" /> <referentiel>< [CDATA Partie cabinet conseil ] ] ></referentiel> <engagement>< ! [CDATA[..~.....Partie abonné........]]></engagement> </DO>
Dans cet exemple, le DO n 1 de type Arc est dans sa version 4 et dans sa révision 1. La révision étant égale à un, nous en déduisons que l'utilisateur a rempli une fois ses engagements, et ne les a pas modifiés depuis.

- Lst est un type de document ne possédant qu'une seule version, car il représente une liste qui s'incrémente automatiquement. Par exemple, le planning des formations est un document de ce type car il est constitué d'une liste de formations. Par exemple :

<Desc/Clms Page number 17>

Do n 10 D03.1.3Planning des formations

<tb>
<tb> Personne <SEP> Tâche <SEP> Formateur <SEP> Date <SEP> Validation
<tb> à <SEP> former <SEP> nécessitant <SEP> Ou <SEP> Début <SEP> - <SEP> de <SEP> la
<tb> une <SEP> organisme <SEP> fin <SEP> formation
<tb> formation
<tb> Marc <SEP> M05.1.2 <SEP> 01/06/02 <SEP> Oui
<tb> >30/07/02
<tb> Sophie <SEP> M06.3.3 <SEP> 01/07/02 <SEP> Non
<tb> >31/07/02
<tb> Pierre <SEP> ADS1 <SEP> 01/07/02
<tb> >31/08/02
<tb>

Chaque fois qu'une formation est ajoutée, la liste des formations déjà existante est incrémentée, sans occasionner une nouvelle version du DO n 10.

De manière préférentielle, la représentation XML de ce DO de type Lst est la suivante : <?xml version="1.0" encoding="iso-8859-1"?> <DO id="10" type="Lst" count="3" mod~date="2002-07-30 17:49:49"> <entry id="l" personne~id="l" task~type="MO" task~id="ll" formation~type="interne" formateur~id="l" begin="2002-06-01" end="2002-07-30" mod~date="2002-07-31 12:48:00"/> <entry id="2" personne~id="2" task~type="MO" task~id="14" formation~type="interne" formateur~id="l" begin="2002-07-01" end="2002-07-31" mod~date="2002-07-31 17:49:38"/> <entry id="3" personne~id="3" task~type="ADS" task~id="l" formation~type="interne" formateur~id="l" begin="2002-07-01" end="2002-08-31" mod~date="2002-07-31 18:49:38"/> </DO>
Chaque formation est représentée par une balise entry associée à différents attributs indiquant l'identifiant de la formation et de la personne à former,

<Desc/Clms Page number 18>

le type de la tâche (MO ou ADS) et son identifiant, le type de formation (interne ou externe) et l'identifiant du formateur, ainsi que les dates de début et de fin de la formation. L'attribut mod~date de la balise entry renseigne sur la date de saisie de cette entrée.

Les attributs count et mod~date de la balise DO renseignent respectivement sur le nombre total d'entrées qui ont été effectuées et sur la date de dernière modification de ce registre (le plus grand mod~date trouvé).

- Reg est un type de document à registre, comme un formulaire complété par l'utilisateur et classé dans un registre.

Par exemple, chaque fois qu'un rapport d'audit qualité interne est renseigné, une nouvelle entrée est faite dans le registre.

Do n 13
D03.2.1 Rapport d'audit qualité interne
Rapport n l

<tb>
<tb> Document <SEP> Ecart <SEP> Description <SEP> et <SEP> N <SEP> du
<tb> Qualité <SEP> Ou <SEP> proposition <SEP> Rapport
<tb> concerné <SEP> Non- <SEP> d'alerte
<tb> conformité
<tb> D04.2.2 <SEP> NC <SEP> Description <SEP> de <SEP> 5
<tb> la <SEP> nonconformité
<tb> D05.3.1
<tb>
Bilan de l'audit : Conclusion du rapport d'audit qualité interne numéro

<Desc/Clms Page number 19>

La saisie d'un rapport d'audit par le biais du formulaire du DO 3. 2.1 génère une nouvelle entrée dans le registre des rapports d'audit qualité interne. Le registre est en quelque sorte un classeur, dans lequel tous les rapports sont stockés, chacun étant identifié par un numéro unique (rapport n 1, n 2, n 3...).

De manière préférentielle, le fichier XML représentant le DO n 13 est structuré comme suit : <?xml version="1.0" encoding="iso-8859-1"?> <RE id="5" ref="3.2.1" type="Reg" title="Registre des rapports d'audit qualité interne" count="3"> <entry id="l" task~type="MO" task~id="23" personne~id="2" auditeur~id="l" date="2001-12-19"mod~date="2001-12-20 11:30:00"> <DO id="20" alerte="1" alerte~id="5">Description de la non- conformité</DO> <DO id="39" alerte="0"/> <bilan>Conclusion du rapport d'audit qualité interne numéro </bilan> </entry> </RE>
La syntaxe utilisée est similaire à celle des DO de type Lst , un rapport d'audit qualité interne étant représenté par une balise entry complétée de différents attributs : - id représente l'identifiant unique de l'entrée dans le registre des rapports d'audit.

- task~type et task~id informent sur le mode opératoire ou l'acte de soins audité.

- personne-id est l'identifiant de la personne auditée.

- auditeur-id ou auditeur~name représentent l'identifiant de l'auditeur ou son nom.

<Desc/Clms Page number 20>

- date est la date effective de l'audit.

- mod~date est la date de validation de cette entrée dans le logiciel client.

La différence entre les DO de type Lst et Reg réside dans le fait que les entrées de DO de type Reg sont en général plus complexes mais dont la nature fait qu' elles ne sont transmises qu'une fois pour archivage et jamais modifiées. Il s'agit par exemple de comptes-rendus de réunion qui se tiennent à intervalle régulier, alors que le type Lst est plutôt utilisé pour des plannings qui peuvent éventuellement être modifiés.

- RAr est un type de document à registre, tout comme le type Reg , mis à part que chaque entrée est un document de type archive Arc . Un numéro d'entrée dans le registre peut être présent plusieurs fois avec un indice de révision indiquant de quelle révision il s'agit.

Chaque fois qu'un élément est modifié, on archive la version précédente. Il peut se présenter sous la forme suivante :

<tb>
<tb> Do <SEP> n 6
<tb> D02.1.1 <SEP> Moyens <SEP> en <SEP> infrastructure
<tb> Pièce <SEP> 1 <SEP> : <SEP> Revision <SEP> n 1
<tb> Ouverture <SEP> : <SEP> Description <SEP> des
<tb> ouvertures
<tb> Dimension <SEP> : <SEP> Dimensions <SEP> de <SEP> la <SEP> pièce
<tb> Eclairage <SEP> : <SEP> Eclairages
<tb> Equipement <SEP> : <SEP>
<tb>

<Desc/Clms Page number 21>

Toute pièce est présente dans le registre des fiches descriptives des lieux sous la forme d'une entrée présente autant de fois qu'il y a de révisions de la pièce. Cette entrée est apte à transiter entre le poste serveur et le poste client, de manière préférentielle, sous la forme XML suivante : <?xml version="1.0" encoding="iso-8859-1"?> <RE id="2" ref="2. 1.1" type="RAr" title="Registre des fiches descriptives des lieux" count="1"> <entry id="l" piece~id="2" name="Pièce 1" revision="l" mod~date="2002-08-28
11:30:00"> <ouverture>Description des ouvertures</ouverture> <dimension>Dimensions de la pièce</dimension> <eclairage>Eclairages</eclairage> </entry> </RE>
La syntaxe utilisée repose sur les mêmes principes que précédemment, chaque pièce étant représentée par une balise entry .

Différents attributs complètent la définition de la pièce : - id : identificateur unique de la pièce.

- piece~id : identificateur unique d'un type de pièce (0 est le type indéfini, 1 est le type salle de prévention , par exemple,...) .

- name : nom de la pièce.

- revision : numéro de révision de cette pièce.

- mod~date : date de saisie de cette entré.

Différentes balises permettent de décrire la pièce correspondante :

<Desc/Clms Page number 22>

- ouverture : correspond au descriptif des ouvertures de la pièce.

- dimension : indique les dimensions de la pièce.

- éclairage : décrit le système d'éclairage.

- RLs est un type de document à registre, tout comme le type Reg , hormis le fait que chaque entrée est un document de type Lst . Par exemple, le registre des fiches de vie des appareils contient pour chaque appareil une entrée dans le registre, avec un certain numéro pour cette entrée, ce numéro pouvant être présent plusieurs fois dans la base avec un attribut mod~date indiquant la date de l'entrée. Chaque entrée est une liste des opérations de contrôle et d'étalonnage effectuées sur cet appareil.

Ce type de document peut se présenter sous la forme suivante :
Do n 7
D02.2.1 Fiche de vie des appareils

<tb>
<tb> Marque <SEP> marque <SEP> de <SEP> l'appareil
<tb> Type <SEP> . <SEP> modèle <SEP> de <SEP> l'appareil
<tb> Numéro <SEP> de <SEP> série: <SEP> numéro <SEP> de <SEP> série <SEP> de <SEP> l'appareil
<tb> Date <SEP> de <SEP> fabrication <SEP> : <SEP> 12/09/2001
<tb> Date <SEP> de <SEP> mise <SEP> en <SEP> service <SEP> 20/09/2001
<tb> Fréquence <SEP> de <SEP> la <SEP> maintenance <SEP> 2
<tb> Fréquence <SEP> de <SEP> l'étalonnage <SEP> 24
<tb> Lieu <SEP> . <SEP> Identificateur <SEP> de <SEP> la <SEP> pièce
<tb> Date <SEP> Entreprise <SEP> Référence <SEP> du <SEP> Observations
<tb> d'intervention <SEP> rapport
<tb> Contrôle <SEP> Etalonnage <SEP> Contrôle <SEP> Etalonnage
<tb>

<Desc/Clms Page number 23>

Pour un appareil donné, la liste des opérations de contrôle et d'étalonnage vient s'incrémenter automatiquement au fur et à mesure des interventions.

La différence avec un document de type Lst est que ce dernier ne représente qu'un unique élément, alors qu'un document de type RLs est complété autant de fois qu'il y a d'éléments (le formulaire du D02.2.1 : Fiche de vie des appareils est complété autant de fois qu'il y a d'appareils) .

De manière préférentielle, la structure XML d'un tel document est similaire aux précédentes : <?xml version="1.0" encoding="iso-8859-1"?> <RE id="3" ref="2.2.1" type="RLs" title="Registre des fiches de vie des appareils" count="1" mod~date="2002-08-28 11:30:00"> <entry id="1" name="nom de l'équipement" marque="marque de l'appareil" modele="modèle de l'appareil" num~scric="numéro de série de l'appareil" fab~date="2001-09-12" serv~date="2001-09-20" control~periode="2" etalon~periode="24" lieu~id="l" mod~date="2001-12-20 11:30:00"> <intervention type="etalon" name="entreprise ayant effectué le controle" rapport="référence du rapport d'étalonnage" date="2001-09-
20">observation sur l'intervention d'etalonnage</intervention> <intervention type="control" name="entreprise ayant effectué le controle" rapport="référence du rapport de contrôle" date="2001-12-
23">observation sur l'intervention de contrôle</intervention> <intervention type="control" name="entreprise ayant effectué le controle" rapport="référence du rapport de contrôle" date="2002-02-
25">observation sur l'intervention de contrôle</intervention> </entry> </RE>
Un appareil est représenté par une balise entry , associée à différents attributs : - id : unique de l'appareil.

<Desc/Clms Page number 24>

- name : nom de l'appareil.

- marque : marque de l'appareil.

- modèle : modèle de l'appareil.

- num~serie : numéro de série de l'appareil.

- fab~date serv~date : dates de fabrication et de mise en service.

- control~periode : nombre de mois entre deux visites de contrôle.

- etalon~periode : nombre de mois entre 2 visites d'étalonnage.

- lieu~id : identifiant de la pièce où est affecté cet équipement.

- mod~date : date de saisie de cette entrée dans le logiciel client.

Afin de représenter les interventions de contrôle et d'étalonnage, chaque balise entry encapsule une liste de balises intervention , dont les attributs précisent les détails de l'intervention : - type : type d'intervention (Contrôle/ Etalonnage).

- name : nom de l'entreprise qui est intervenue.

- rapport : référence du rapport de control ou d'étalonnage.

- date : date de l'intervention.

Le contenu de chaque balise intervention représente les observations qui ont pu être faites au cours de l'intervention.

<Desc/Clms Page number 25>

1.1.5. Registres (RE)
Les registres (RE) permettent la sauvegarde de tous les documents implémentés par l'utilisateur. Les registres contiennent les informations des documents de type Reg , Rar et RLs .

Il est à noter que les numéros identificateurs de DO ne correspondent pas aux numéros identificateurs des registres RE, car ces derniers ont été choisis en fonction de l'ordre d'apparition des formulaires dans la liste de tous les documents.

Une exception a été faite pour le DO n 1 (DO1.1.1) qui est attaché au registre n 1 (RE1.1.1) bien qu'étant de type Arc . Le DO n 6 (D02.1.1) de type Rar est quant à lui attaché au registre n 2 (RE2.1.1), le DO n 7 (D02.2.1) est lié au registre n 3 (RE2. 2.1) et ainsi de suite pour le reste des documents.

1.2. Organisation de la base de données du système d'assurance qualité
Différents types de table ont été mis en place dans une base de données afin de stocker les données.

1.2.1. Informations communes à tous les utilisateurs:
Les informations communes mises à disposition de tous les utilisateurs sur le poste serveur, sont stockées selon les mêmes principes que pour les DO de type Arc , à savoir que chaque modification génère une nouvelle version

<Desc/Clms Page number 26>

du document, toutes les versions précédentes ayant été archivées dans la base de données. L'ensemble des procédures, des modes opératoires et des documents de type Mod et Arc , ainsi qu'une partie (la référence et le titre) des autres types de document, respectent ce mode de fonctionnement.

La figure 4 représente les enregistrements de la table Procédures concernant la PR n 15.

Les diverses champs de la table Procédures permettent de retracer l'historique d'une procédure donnée - Id~proc : ce champ est la clé primaire de la table, et permet d'identifier un enregistrement de manière unique.

- Id ce champ contient l'identifiant des procédures. Dans l'exemple précédent, seule la procédure PR n 15 a été représentée.

- Ref : est la référence de la procédure.

- Libelle : est le titre qui est donné à la procédure dans le système d'assurance qualité.

- Version : ce champ permet de retracer l'historique d'une procédure pour un id donné.

- Docxml : ce champ contient le fichier xml utilisé lors des diverses échanges entre le poste serveur et le poste client. Il contient toutes les informations relatives à une version de la procédure, telles que son id, sa référence, son libelle, son numéro de-version et le contenu de la procédure. Le fait de stocker les

<Desc/Clms Page number 27>

informations directement au format XML évite d'avoir à recomposer le fichier XML à chaque demande d'un utilisateur : le fichier est déjà prêt pour l'envoi.

- Date~deb : date de début de la version.

- Date~fin : date de fin de la version courante, qui constitue la date de début de la version suivante, car à partir de cette date, la procédure est passée dans la version suivante. Seule la dernière version d'une procédure ne possède pas de date de fin, car elle représente la version active.

1.2.2. Informations utilisateur :
Les informations propres à chaque utilisateur sont stockées dans des tables distinctes, dont la structure dépend du type de document associé.

Par exemple, Les actes de soins (ADS) sont stockés dans des tables similaires à celles étudiées précédemment, comme l'illustre la figure 5
L'organisation des champs de la table Gq~cd~ads est conforme aux règles énoncées précédemment : - Id~gqcdads : représente la clé primaire.

- Id~denta : Identifiant unique de l'utilisateur, fourni à ce dernier lors de l'initialisation de son système, et utilisé lors des échanges entre le poste serveur et le poste client.

- Id : Identifiant de l'acte de soins (ADS).

- Pr : Ce champ contient l'identifiant de la procédure (PR) à laquelle l'acte de soins (ADS) est

<Desc/Clms Page number 28>

associé. Par exemple, si la valeur de ce champ est égale à 10 , cela signifie que l'acte de soins considéré est associé à la procédure d'identifiant 10 , quelle que soit la référence de la procédure.

- Ref : Référence de l'acte de soins.

- Libelle : Libellé de l'acte de soins.

- Revision : Indice de révision permettant de suivre l'évolution de l'ADS.

- Docxml : contenu des actes de soins, crées uniquement par l'utilisateur, est envoyé par celui-ci au format XML pour être stockés tels quels en vue d'un archivage.

- Date~deb : date de début de la révision.

- Date~fin : date de fin de la révision.

La table Gq~cd~mo , contenant les modes opératoires du chapitre cinq qui ont été modifiés par l'utilisateur, est similaire à celle des actes de soins hormis le fait que le champ Pr n'existe pas pour les modes opératoires.

Dans un autre exemple, la structure de la table contenant les informations du DO n 10 de type Lst est illustrée en figure 6.

Nous constatons, dans cet exemple, que l'utilisateur numéro dix a défini deux formations internes (entrée numéro un et deux) pour la personne numéro deux, concernant les modes opératoires d'identifiant onze et quatorze. Les divers champs de la table renseignent sur

<Desc/Clms Page number 29>

les dates de début et de fin de la formation et sur l'éventuelle validation de cette formation. Lors de la validation de la formation numéro un, une nouvelle entrée est faite dans le registre, contenant les mêmes informations, mis à part que la date de validation est renseignée et que le champ Date~mod contient une date supérieure à 2002-07-30 17:48:00 permettant de retracer l'évolution de la formation.

L'ensemble des tables contenant les informations des abonnés relatives à des documents de type Reg , RAr et RLs est organisé de manière similaire, à savoir qu'un même numéro Entry~id (pour un utilisateur donné), peut être présent plusieurs fois dans la table, la valeur du champ Date~mod permettant de retracer l'évolution d'une même entrée dans le temps.

1.3. Architecture du système d'assurance qualité
Comme nous l'avons indiqué précédemment, le système d'assurance qualité comprend un ensemble de documents ou d'éléments commun à tous les utilisateurs.

Chaque éléemnt possède une référence, un titre et un contenu.

La référence permet de positionner un élément dans la représentation visuelle qui est faite du système d'assurance qualité dont une illustration est faite à la figure 7.

<Desc/Clms Page number 30>

Ainsi, le chapitre 1 est constitué de toutes les procédures dont la référence est de la forme l.i , i étant un entier naturel positif (i - -*) permettant d'ordonner les procédures au sein d'un même chapitre. La pr1.1 sera donc suivie de la prl.2 si celle-ci existe, puis de la prl.3 et ainsi de suite.

Il est ensuite possible d'associer des modes opératoires et des documents à une procédure, l'association étant réalisée à l'aide des références selon le même principe que celui des procédures.

Ainsi, la prl.2 est associée à tous les modes opératoires et à tous les documents dont la référence est du type 1.2.i , i satisfaisant les mêmes conditions que précédemment (i - -*).

Dans le cas ou une procédure possède des modes opératoires et des documents associés, il est nécessaire de définir une relation d'association (dépendance) entre ceux-ci. Cette association n'est pas basée sur les références, mais est réalisée à l'aide d'un module indépendant, chaque MO du type 1.2.i pouvant être associé à zéro ou plusieurs DO du type 1.2.i . Dans l'exemple précédent, il sera possible d'associer le mol.2.1 aux documents dol.2.2 , do1.2.3 et dol.2.4 . Une association identique est possible avec les mo1.2.2 , mo1.2.3 , mo1.2.4 et mo1.2.5 . (Il est à noter que cette association n'est pas apparente dans la représentation visuelle du système qui est donnée à la figure 7).

<Desc/Clms Page number 31>

Une fois implémenté, le système d'assurance qualité est validé par l'administrateur du poste serveur, cette opération consistant à définir les dépendances (relation d'association entre les diverses MO et DO associés à une même procédure). Ainsi, en combinant d'une part la structure donnée par les références et d'autre part les relations de dépendances entre modes opératoires et documents, il est possible de représenter l'ensemble du système à un instant t en un seul fichier system.xml (illustré en figure 8) .

Le fichier system.xml présenté constitue la représentation informatique du schéma de la figure 7. Nous y retrouvons le détail de l'arborescence du système.

Nous constatons par exemple que l'élément : <PR id="l" ref="1.1" title="REFERENTIELS ET ENGAGEMENTS" version=' ' 10' ' >...</PR> symbolisant la procédure n 1 de référence 1.1 dans sa version 10 contient un élément : <DO id="1" ref="1.1.1" type="Arc" title="Référentiels et engagements" version="4"/> qui représente le document n 1 de référence 1.1.1 dans sa version 4 . L'association est faite ici en fonction des références.

De même, la procédure n 2 de référence 1. 2 , représentée par l'élément : <PR id="2" ref="1.2">..</PR> est associée à plusieurs modes opératoires : <MO id="l" ref="1.2.1"/> <MO id="2" ref="1.2.2">..</MO>, qui est associé au document <DO id="2" ref="1.2.2">

<Desc/Clms Page number 32>

<MO id="3" ref="1.2.3">..</MO>,qui est associé aux documents <DO id="3" ref="1.2.3"> et <DO id="4" ref="1.2.4">.

<MO id=''4'' ref="1.2.4''/> <MO id="S" ref="1.2.5"/>
Il est à noter que chaque élément est défini par un numéro d'identification unique id , ce qui permet de modifier sa référence et son titre en toute liberté.

II. Fonctionnement du logiciel client
La syntaxe des fonctions d'échange entre le poste serveur et le poste client repose sur l'utilisation des préfixes get et set selon le principe suivant : - Get concerne toutes les fonctions de récupération d'informations à partir du poste serveur. Par exemple, le poste client appelle getglossaire.php afin que le poste serveur lui retourne l'ensemble des définitions du glossaire.

- Set concerne toutes les fonctions d'envoi d'informations au poste serveur. L'application client appelle setmessage.php afin d'envoyer au poste serveur un message de l'utilisateur.

II.1. Création d'un compte utilisateur
La création d'un utilisateur est réalisée par le biais d'un formulaire. Une fois cette étape effectuée, l'utilisateur dispose d'un numéro de contrat et d'un mot de passe, qui lui sont demandés au démarrage du logiciel

<Desc/Clms Page number 33>

client, et passés en paramètres de requête à l'appel de la fonction getabonne sur le poste serveur.

Le poste serveur retourne alors un numéro d'identification id au logiciel client du poste client, qui correspond à un numéro utilisé en interne dans la base de données et qui est utilisé dans les échanges suivants d'informations afin d'identifier de manière unique chaque utilisateur par un numéro.

L'étape suivante permet à l'utilisateur de définir un mot de passe utilisateur d'accès au système de gestion du système d'assurance qualité dont le logiciel client fait partie, ainsi qu'un mot de passe d'administration.

Une fois le processus d'initialisation terminé, un appel à la fonction getsystem?id~denta=id, avec comme paramètre id~denta la valeur de l'identificateur id énoncé précédemment, permet de lancé le procédé de synchronisation selon l'invention, pour synchroniser les informations locales du poste client avec celles du poste serveur.

II.2. Le cache ou miroir local des données de l'utilisateur
Pour permettre à l'utilisateur de travailler hors connexion , c'est-à-dire sans être connecté en permanence au poste serveur, le logiciel client gère un cache local (mémoire tampon sur le poste client de l'utilisateur) qui est un miroir des informations archivées sur le poste serveur concernant l'utilisateur et son système d'assurance qualité. Ce principe de fonctionnement permet

<Desc/Clms Page number 34>

aussi de garantir l'intégrité des données de ceux qui disposent d'une connexion permanente, même si le réseau devenait temporairement indisponible, tout en permettant à ceux qui ne disposent pas d'une telle connexion de pouvoir utilisé le logiciel.

Ce principe de cache local suppose de mettre en place un procédé de synchronisation des données entre le poste serveur et le logiciel client du poste client, afin de transmettre les données modifiées de part et d'autre, dans les deux sens.

Les données du système qualité de l'utilisateur sont séparées en deux parties : une première partie est, comme nous l'avons déjà vu, commune à tous les utilisateurs et une deuxième partie est propre à l'utilisateur. Ces données sont stockées localement dans un dossier principal déterminé qu'il est proposé de désigner après l'installation du logiciel client sur un ordinateur du poste client. Ce dossier peut au besoin être créé n'importe où sur le réseau du poste client afin de pouvoir travailler sur n'importe quel ordinateur dudit réseau.

Les données sont en général stockées sous forme de fichiers présentant une extension, comme par exemple .lst , qui ont une structure calquée sur les documents XML utilisés pour l'échange d'informations entre le poste client et le poste serveur et décrite en précédemment.

Cette structure des données reste relativement légère.

Seuls les documents modèles nécessitant une mise en page particulière sont stockés sous forme de documents PDF.

<Desc/Clms Page number 35>

Il.2.1. Données communes à tous les utilisateurs
Elles sont placées dans un sous-dossier système du dossier principal, ce qui permet d'éviter de télécharger plusieurs fois les données communes à plusieurs utilisateurs (documents mis en place par l'administrateur du poste serveur). Ce sous dossier système contient les éléments suivants : - pour chaque procédure du système d'assurance qualité, un fichier nommé pr~ID.lst où ID correspond à l'identifiant unique de la procédure dans la base de données du poste serveur. Ce fichier décrit toutes les versions connues de la procédure n ID; - pour chaque MO Elab et Table , un fichier nommé mo-ID.lst qui décrit toutes les versions connues et définies par l'administrateur du poste serveur de ce Mode Opératoire ; - pour chaque DO de type Arc , un fichier nommé do ID.lst donnant les différentes versions successives du modèle-type de documents fourni par l'administrateur du poste serveur ; - un fichier glossaire.lst donnant la dernière version du glossaire du logiciel, c'est-à-dire l'ensemble des définitions et abréviations utiles à l'utilisation du système d'assurance qualité ; - un fichier param.lst qui contient les informations essentielles concernant les différents comptes utilisateur utilisant un sous dossier Datas (id~denta, RAQ, mots de passe) décrit ci-après.

<Desc/Clms Page number 36>

II.2.2. Données propres à l'utilisateur
Elles sont placées dans un sous-dossier d'un sous dossier Datas du dossier principal, nommé avec le numéro de contrat de l'utilisateur. Ce dossier est créé après validation de la création de l'utilisateur par le poste serveur précédemment décrite. Ce dossier contient les éléments suivants : - un fichier abonne.lst contenant les informations de l'utilisateur qui sont échangées sous forme xml avec les fonctions getAbonne et setAbonne.

- pour chaque ADS listé par l'utilisateur dans un élément DO~4, un fichier nommé ads~ID.lst décrivant toutes les révisions de cet ADS tel que défini par l'utilisateur ; - pour chaque MO modifiable par l'utilisateur, un fichier nommé mo~ID.lst , décrivant toutes les révisions faites par l'utilisateur de ce Mode Opératoire ; - pour chaque DO de type Arc (archive), un fichier nommé do ID.lst décrivant toutes les révisions de ce document effectuées par l'utilisateur ; - pour chaque DO de type Lst (liste, planning), un fichier nommé do ID.lst décrivant toutes les entrées de ce document ajoutées par l'utilisateur ; - pour chaque DO de type Mod (modèle), un fichier nommé do ID.lst et un sous-dossier nommé DO ID . Le fichier décrit le numéro de version courante et le fichier PDF correspondant. Le sous-dossier contient toutes les versions successives du DO Mod au format PDF. Chaque document PDF est nommé DO~ID~V.pdf où V correspond au

<Desc/Clms Page number 37>

numéro de version du document. Ces documents PDF ne sont pas placés dans le dossier système des données communes à tous les utilisateurs car ils ont une entête et un pied de page personnalisés pour l'utilisateur sur chaque page du document ; - pour chaque DO à Registre (type Reg , RAr , RLs ) , un fichier nommé re~ID.lst où ID correspond au numéro d'identifiant du registre (et non du DO). Il contient toutes les entrées de registre ajoutées par l'utilisateur ; - un fichier message.lst contenant l'intégralité des messages échangés entre l'utilisateur et le poste serveur via une interface de messages intégrée au logiciel client ; - un fichier system.lst qui contient la description du système d'assurance qualité de l'utilisateur ainsi que la liste des éléments à synchroniser. Ce fichier est basé en grande partie sur le system.xml décrit précédemment, le procédé de synchonisation est expliqué ci-après. En cas de problème, ce fichier peut être supprimé après avoir quitté le logiciel, il sera régénéré automatiquement lors de la synchronisation suivante. Seule est alors perdue la liste des documents modifiés par l'utilisateur sur le poste client et restant à transmettre au poste serveur.

Il.3. Principe de la synchronisation
Afin de synchroniser les informations entre le poste serveur et le poste client, il est nécessaire de combiner

<Desc/Clms Page number 38>

les informations communes à tous les utilisateurs (telles que les procédures, les modes opératoires et les différents documents) et les informations propres de l'utilisateur. Pour ce faire, le poste serveur réagit à une requête getsystem de synchronisation en allant chercher, dans la base de données, le dernier fichier system.xml validé (e général le plus récent). Ce fichier représente donc l'ensemble des informations communes, avec les références, les titres et les numéros de version de chaque élément.

Il reste par conséquent à ajouter les informations de propre à l'utilisateur.

Pour ce faire, le poste serveur parcourt tout en analysant le fichier system.xml étudié précédemment selon les principes de l'organigramme des figures 2a et 2b.

Le fichier system.xml validé est analysé, et, suivant le type de balise rencontré, différentes actions vont se succéder : - Les balises <SYSTEM> (étape 10) et <CH> (étape 20) sont recopiées telles quelles dans le nouveau fichier system.xml .

- Les balises <PR> (étape 30) sont recopiées telles quelles dans le nouveau fichier system.xml , puis, le procédé de synchronisation analyse la liste des ADS afin de déterminer ceux associés à cette procédure (étape 35) .

Pour un id~denta donné, il récupère dans la table

<Desc/Clms Page number 39>

Gq~cd~ads l'ensemble des actes de soins dans leur dernière version, et vérifie que le champ Pr est égal à la valeur de l'attribut id de la balise <PR> concernée. Puis il copie les ADS dans le nouveau fichier system.xml .

- En ce qui concerne les modes opératoires (balise <MO>, étape 40), tous sont recopiés tels quels dans le nouveau fichier system.xml sauf ceux modifiables par l'abonné.

Par exemple (cf annexe), une balise du type <MO id="l" ref="1.2.1" title="ELABORATION D'UNE PROCEDURE (PR)" type="elab" version="12"> est recopiée sans modification car le référence de 1. 2.1 indique qu'il s'agit du premier chapitre et définie comme non modifiable par l'administrateur du poste serveur.

Par contre une balise du type <MO id="34" ref="5.1.1" title="PLANNIFICATION DES JOURS D'OUVERTURE DU CABINET" type="elab" VERSION="9"> (indiqué comme modifiable par l'utilisateur par l'administrateur du poste serveur) est recopiée avec un attribut de révision ajouté indiquant l'indice de révision de ce document pour l'utilisateur concerné. Par exemple, si l'utilisateur a modifié cinq fois le mode opératoire initial, la balise retournée sera <MO id="34" ref="5.1.1" title="PLANNIFICATION DES JOURS D'OUVERTURE DU CABINET" type="elab" version="9" revision="5"> .

<Desc/Clms Page number 40>

- Les traitements opérés lorsque le procédé de synchronisation rencontre une balise <DO> (étape 50) dépendent du type de document concerné : * Si le document est de type Arc (étape 51), le procédé de synchronisation récupère l'indice de révision associé et le recopie tel quel dans le nouveau fichier system. xml , de la même manière que pour les modes opératoires modifiables précédents.

* Sinon, si le document est de type Lst (étape 52), le procédé de synchronisation récupère la date de dernière modification par l'utilisateur du document concerné et l'ajoute à la balise correspondante dans le nouveau fichier system. xml .

* Sinon, la balise <DO> est recopiée tel quel dans le nouveau fichier system. xml , puis, s'il s'agit du document d'identificateur id égal à six, par exemple, (étape 501), le procédé de synchronisation récupère la date de dernière modification et le nombre d'éléments associés à l'utilisateur dans le registre numéro deux et les recopie dans le nouveau fichier system. xml . Le fonctionnement est le même pour les autres documents à registre (étapes 502 à 513).

- la balise <UPDATE> (étape 60) permet d'ajouter des informations de mise à jour. Le procédé de synchronisation récupère la date de dernière modification du glossaire, de

<Desc/Clms Page number 41>

la messagerie et de la mise à jour du logiciel client, et retourne les balises suivantes, par exemple : <UPDATE> <glossaire mod~date="2002-07-25 11:25:09'' /> <messages mod~date="2002-07-07 17 :01:55 /> <history mod~date="2002-08-13 00:50:39'' />
Lorsque le procédé de synchronisation récupère ces balises sur le poste client, il compare alors la date de dernière modification du glossaire avec celle dont il dispose en local dans le poste client. Si cette dernière est plus ancienne, il.récupère le dernier glossaire sur le poste serveur et met à jour la date interne du poste client avec la valeur 2002-07-25 11 :25:09 .

Ainsi, tant que le glossaire n'est plus modifié, lors des prochains appels à getsystem , les dates étant identiques, le glossaire ne sera pas récupéré sur le serveur.

Le fonctionnement est similaire avec la messagerie et la mise à jour du logiciel.

- Les balises de fermeture (étape 70) sont recopiées sans traitement dans le nouveau fichier system.xml .

Le system.xml contient par exemple les balises suivantes <UPDATE>< /UPDATE> . Les traitements effectués lors de l'analyse de la balise <UPDATE> ont été expliqués précédemment. Puis, lorsque la balise de fermeture </UPDATE> est rencontrée, elle est recopiée afin de fermer le balise <UPDATE> .

<Desc/Clms Page number 42>

L'annexe A donne un exemple du fichier XML résultant d'un appel à getsystem . Ce fichier contient la représentation du système d'assurance qualité d'un utilisateur, à partir des informations contenues sur le poste serveur.

Ensuite, le fichier system.xml est transmis via le réseau de télécommunication par le poste serveur au poste client.

Une fois que le poste client a récupéré ce fichier, ce dernier sert de base à trois types d'opérations effectuer par le poste client : - le procédé de synchronisation selon l'invention compare, dans un premier temps, les informations contenu dans le fichier system.xml communes à tous les utilisateurs (attribut version dans le fichier XML), ainsi que celles propres à l'utilisateur (attribut revision ), avec les informations déjà disponibles sur le poste client dans son propre fichier system.xml local.

Il va par exemple comparer, pour une procédure (PR) donnée, le numéro de version donné par le poste serveur via le fichier transmis et le numéro de la version locale disponible sur le poste client. Si le procédé de synchronisation selon l'invention que la version située sur le poste serveur est égale à 5 et que la version locale maximale sur le poste client est 3, le procédé de synchronisation détermine que la procédure dans ses versions 4 et 5 est à télécharger sur le poste serveur par

<Desc/Clms Page number 43>

un appel à un fonction du type getpr?version=4 et getpr ?version=5 .

Le téléchargement n'est pas fait immédiatement. La comparaison entre la version du fichier system.xml reçu et la version locale de ce fichier sur le poste client est d'abord évaluée intégralement. Au cours de cette comparaison, le procédé de synchronisation selon l'invention complète une liste de téléchargement d'éléments du poste serveur, liste comprenant toutes les informations nécessaires au téléchargement du ou des éléments en question. Cette liste est immédiatement enregistrée dans un fichier nommé, par exemple system.lst , de l'utilisateur. Le procédé de synchronisation enregistre également, en même temps qu'il effectue la comparaison, la version du fichier system.xml en local sur le poste client. De cette manière, si l'application mettant en #uvre le procédé de synchronisation causait une erreur ou si la connexion via le réseau de télécommunication devenait inopérante, la liste des éléments à récupérer reste disponible pour une synchronisation future.

- le procédé de synchronisation selon l'invention utilise la structure du fichier system.xml pour construire ou reconstruire le plan du système d'assurance qualité de l'utilisateur. L'imbrication des balises dans le fichier system.xml fournit la logique de dépendances des différents éléments constitutifs. Les attributs des balises fournissent les références logiques

<Desc/Clms Page number 44>

et libellés de chacun des éléments. Le plan du système d'assurance qualité est alors mis à jour si nécessaire.

- la balise spéciale intitulée update , décrite précédemment, en fin du fichier system.xml reçu permet d'indiquer procédé de synchronisation selon l'invention les dates de dernière modification de différents éléments comme la liste des postes ou des pièces, les messages, le glossaire ou la mise-à-jour du logiciel client. Lorsque cette balise précise cette date pour un élément, le procédé de synchronisation selon l'invention peut alors sauter certaines étapes facultatives de la synchronisation s'il n'y a pas eu de changement entre la version de l'élément considéré du poste serveur et celle du même élément sur le poste client. Cela permet d'éviter quelques requêtes supplémentaires auprès du poste serveur par le poste client. Ceci permet de raccourcir la durée de la connexion nécessaire pour réaliser complètement la synchronisation.

Lorsque le fichier system.xml reçu a été complètement analysé et exploité, le procédé de synchronisation selon l'invention poursuit la synchronisation en passant par les différentes étapes illustrées par le digramme de la figure 3.

En référence à cette figure, nous avons décrit précédemment en détails les étapes 100 et 105. Le procédé

<Desc/Clms Page number 45>

de synchronisation selon l'invention présente les étapes suivantes : une nouvelle liste des intitulés de postes et de pièces est téléchargée si nécessaire (étapes 110 et 115) depuis le poste serveur.

Le nom d'un poste ou d'une pièce peut être modifié par l'administrateur du poste serveur.

Toutefois, il faut veiller d'une part à ne pas supprimer un poste ou un type de pièces qui aurait pu être utilisé par un utilisateur et, d'autre part, à ne pas modifier l'identifiant d'un poste ou d'une pièce. en exploitant la liste des éléments à télécharger depuis le poste serveur déterminé lors de l'étape 105, le procédé de synchronisation selon l'invention effectue successivement et un par un le téléchargement des différents éléments de la liste à l'aide, par exemple, d'une fonction getElement où Elément est remplacé par le nom de l'élément à télécharger (étape 120) en exploitant la liste des éléments à envoyer au poste serveur, le procédé de synchronisation selon l'invention effectue successivement et un par un l'envoi au poste serveur des éléments modifiés par l'utilisateur, et jamais envoyés, à l'aide, par exemple d'une fonction setElement où

<Desc/Clms Page number 46>

Element est remplacé par le nom de l'élément à envoyer (étape 125)
Il est à noter que la liste des éléments à envoyés au poste serveur peut être créée lors de l'étape 105, durant la comparaison. Mais, de manière avantageuse, cette liste est créée et complétée à chaque fois que l'utilisateur modifie ou ajoute un élément et sauvegarde ces modifications. Si, à ce moment, l'élément en question n'est pas encore dans cette liste, il y est ajouté avec toutes les informations nécessaires et les paramètres pour la fonction setElement .

Le système d'assurance qualité de l'utilisateur n'est mis à jour avec le nouvel indice de révision de l'élément ainsi envoyé qu'après que cet élément ait été effectivement envoyé au poste serveur et acquitté par ce dernier. De cette manière, le système d'assurance qualité contenu dans le poste client reflète toujours l'état du système d'assurance qualité de l'utilisateur archivé sur le poste serveur. C'est pourquoi certains éléments comme la liste des ADS de l'utilisateur nécessitent une transmission au poste serveur avant d'être pris en compte dans le plan du système d'assurance qualité. dans une étape 130, le procédé de synchronisation selon l'invention envoie au poste serveur les informations de l'utilisateur si elles ne l'ont pas encore été (mot de passe d'ouverture de compte,...)

<Desc/Clms Page number 47>

si le dernier message sur le poste serveur est plus récent que le dernier message disponible localement sur le poste client, le procédé de synchronisation télécharge tous les messages plus récents depuis le poste serveur (étape 135). Puis, il envoie les nouveaux messages de l'utilisateur et ne met à jour la date de dernier message disponible que lorsque le poste serveur a acquitté la réception des messages de l'utilisateur ainsi envoyés. dans une étape 140, le procédé de synchronisation télécharge depuis le poste serveur une liste des anomalies du système d'assurance qualité dans le nouvel état actuel et synchronisé par les étapes précédentes.

Cette liste est déterminée alors par le poste serveur avant envoi au poste client. dans une étape 145, une dernière version du glossaire est téléchargée depuis le poste serveur si celle-ci est plus récente que la version disponible localement sur le poste client. dans une étapes 150, si la dernière mise à jour du logiciel client est plus récente que celle du logiciel utilisé par l'utilisateur, alors le procédé de synchronisation interroge le poste serveur pour télécharger une liste de toutes les versions ultérieures à celle utilisée et des fichiers qui les composent. Le

<Desc/Clms Page number 48>

procédé de synchronisation télécharge alors depuis le poste serveur, successivement et un par un, la dernière version de chaque fichier mis à jour ou ajouté ainsi listé (étape 155).

L'historique des mises à jour et la liste des fichiers à télécharger sont stockés dans un fichier de type logicielclient.lst . Si les téléchargements sont interrompus par une rupture de la connexion via le réseau de télécommunication, ils reprendront lors de la synchronisation suivante. Ces fichiers sont placés dans un dossier temporaire nommé Download (téléchargement).

Une fois tous les fichiers nécessaires téléchargés dans le dossier Download , la synchronisation est terminée. dans une dernière étape 160, si une mise à jour du logiciel client a été téléchargée, le procédé de synchronisation selon l'invention propose alors de réaliser effectivement cette mise à jour immédiatement. Pour cela, il est éventuellement nécessaire de quitter le logiciel client. Si l'utilisateur choisit d'installer la mise à jour de suite, le procédé de synchronisation quitte et lance un logiciel de mise à jour du logiciel client. Si la mise à jour est faite immédiatement, ce logiciel de mise à jour relance alors le logiciel client après la mise à -jour. Dans le cas contraire, la mise à jour du logiciel

<Desc/Clms Page number 49>

client a lieu lorsque l'utilisateur le quitte (il n'est bien sûr pas relancé dans ce cas après la mise à jour).

Pour mettre à jour le logiciel client, le logiciel de mise à jour effectue une sauvegarde des fichiers qui doivent être mis à jour (donc remplacés) qu' il place dans un sous-dossier d'un dossier Versions précédentes (ce dossier est créé si nécessaire). Le sous-dossier porte le nom de l'identifiant unique de la version utilisée jusque là dans l'historique des mises à jour qui est échangé lors de l'étape 150. Ensuite, les fichier de mise à jour téléchargés sont placés au bon endroit selon leur type dans l'arborescence des fichiers constituant le logiciel client.

Ainsi, il est donc possible de revenir à une version précédente en reprenant les fichiers sauvegardés dans le dossier Versions précédentes et en les replaçant au bon endroit selon leur type dans l'arborescence des fichiers constituant le logiciel client (manuellement ou automatiquement). Toutefois, si cette manipulation est effectué manuellement, la version du logiciel client indiquée dans la boîte de dialogue A propos de... ne correspond plus aux fichiers remplacés manuellement.

Bien qu'illustré dans le cadre d'un cabinet médical et d'un système d'assurance qualité associé à ce dernier, le système de gestion présenté précédemment peut s'appliquer à des systèmes qualité, d'organisation, de

<Desc/Clms Page number 50>

management, d'évaluation et de coordination, notamment dans tous les secteurs médicaux (professions de santé libérales, établissements de santé, réseaux de santé), mais également dans les entreprises multisites ou multi services et les administrations.

De plus, le système développé peut intégrer les différents référentiels Qualité et métier et permettre une modification à tous les niveaux des documents.

Bien entendu, on peut apporter à l'invention de nombreuses modifications sans pour autant sortir du cadre de celle-ci.

<Desc/Clms Page number 51>

<?xml version=*1.0" encoding=*iso-8859-1" ?> <SYSTEM version="1.0" update="2002-08-01 16:23:18" )anguage='FR"> <CH id="1" ref="1" title= Organisation du Système Quafité"> <PR id="1" ref="1.1" t'rtle="REFERENTIELS ET ENGAGEMENTS" version="10"> <DO id="1" ref="1.1.1" type="Arc" title="Référentiels et engagements" version="4" revision="1" /> </PR> <PR id="2" ref="1.2" title="ELABORATION ET MAITRISE DES DOCUMENTS" version="17"> <MO id="1" ref="1 .2.1" title="ELABORA TION D'UNE PROCEDURE (PR)" type="elab" version="12" l> <MO id="2" ref="1.2.2" fitle= ELABOPATION D'UN MODE OPERATOfRE (MO)" type="elab" version="13"> <DO id="2" ref="1.2.2" type="Mod" title="Modèle type d'un MO" version="2" /> </MO> <MO id="3" ref="1.2.3" title="ELABORATION ET MAITRISE D'UN ACTE DE SOIN (ADS)" type="elab" version="10"> <DO id="3" rez="1.2.3" type="Mod" title="Modèle type d'un ADS" version="2" /> <DO id="4" rez= 1.2.4 type=^Arc^ title="Liste des ADS" version="3" revision="1" 1> </MO> <MO id="4" ref="1.2.4" tide= ELABORATION ET MAITRISE D'UN DOCUMENT (DO)" type="elab" version="8" /> <MO id--"5" ref=^1.2.5" title="ELABORATION ET MAITRISE D'UN REGISTRE (RE)" type="elab" verslOn="8"1> </PR> <PR id="3" ref="1.3" title="ORGANISATION ET DEFINITION DES POSTES" version="12"> <DO id= 5" ref="1.3.1" type="Arc" title="Organigramme de définition des postes" version="11" " revision=''2" /> </PR> </CH> <CH id="2" ref="2" title="Plateau technique"> <PR id="4" rez="2.1" title="MOYENS EN INFRASTRUCTURE" version="4"> <DO id="6" rez="2.1.1 type="RAr" title="Moyens en infrastructure" version="1"> <RE id="2" ref--"2.1.1^ type="RAr" title="Registre des fiches descriptives des lieuo" count="9" mod~date="2002-06-1711:48:10" 1> </DO> </PR> <PR id="5" rez='2.2" title="MAITRISE DES EQUIPEMENTS" version="7"> <DO id="71 ref="2.2.1" type="RLs" title="Fiches de vie des appareils" version="1"> <RE id="3" ref="2.Z.1" type="RLs" title="Registre des fiches de vie des appareils" count="1" mod~date="2002-06-17 11:12:14" /> </DO> </PR> </CH> <CH id="3" ref="3" title="Management du personnel"> <PR id="6" ref='3.1" title="VIE DES PERSONNES" version="8"> <DO id="8" ref="3.1.1" type="Arc" title="Organigramme hiérarchique et fonctionner version="2" revision="2" /> <DO id="9" ref="3.1.2" type="RLs" title="Fiche de vie des personnes" version="1"> <RE id="4" ref="3.1.2" type="RLs" title="Registre des fiches de vie des personnes" oount=*5 mod date="2002-06-2010:51:25" !> </DO> <DO id="10" ref="3.1.3" type="Lst" title="Planning des formations" version="1" ^ mod~date="0000-00-00 00:00:00" 1> <DO in="11" ref="3.1.4" type="Mod" tibe='Convention collective" version="2" /> <DO id="12" ref="3.1.5" type="Mod" title="Modèle type d'un contrat de travail" version="3" /> <DO id="65" ref="3.1.6" type="RLs" title="Fiche de vie du praticien" version="1" /> </PR> <PR id="7" ref="3.2" title="AUDITS QUALITE INTERNE^ version="6"> <DO id="13" ref="3.2.1" type="Reg" title='Rapport d'audit qualité interne" version="1"> <RE id="5" ref="3.2.1" type="Reg" title="Registre des rapports d'audit qualité inteme" count="0" mod-date= 0000-00-00 00:00:00" 1> </DO> <DO id="14" ref="3.2.2" type=^Lst" title="Programme d'audit qualité interne" version="1" mod-date=*0000-00-00 00:00:00" 1> </PR> <PR id= 8" ref="3.3" title="REUNION D'EQUIPE HEBDOMADAIRE^ version="6"> <DO id="15" ref="3.3.1" type=''Reg* title=*Compte rendu de réunion d'équipe" version="1"> <RE id="6" ref="3.3.1" type="Reg" title="Registre des comptes rendus de réunion d'équipe^ count="2" mod~date="2002-07 -30 10:51:33"1> </DO> </PR> </CH> <CH id="4" ref="4" title="Organisation des activités spécifiques"> <PR id="15" ref="4.1" title="MAITRISE DE L'ENVIRONNEMENT" version="5"> <MO id="6" ref="4.1.1" title="RAMASSAGE DES INSTRUMENTS SOUILLES" type="table" version="7" /> <MO id="7" ref="4.1.2" title--"NETTOYAGE ET DECONTAMINATION DES SURFACES EN SALLE DE SOINS ENTRE 2 PATIENTS SOINS NON STERILES" type="table" version="9"> <DO id="23^ ref="4.1.2" type="Mod" title="Liste des matériels et produits à utiliser entre 2 patients soins non stériles" version='*4'' /> </MO> <MO id="8" ref="4.1.3" title="NETTOYAGE ET DECONTAMINITION DES SURFACES EN SALLE DE SOINS ENTRE 2 PATIENTS" type="table" version="6"> <DO id="24" ref="4.1.3" type="Mod" title="Liste des matériels et produits à utiliser pour des soins stériles" version="4"1> </MO> <MO id="9" ref="4.1.4" title="NETTOYAGE ET DECONTAMINATION DES SURFACES EN SALLE DE SOINS EN FIN DE JOURNEE"

<Desc/Clms Page number 52>

type="table" version="7"> <DO id="25" ref="4.1.4" type="Mod" title="Liste des matériels et produits à utiliser en salle de soins en fin de journée" version="5" /> </MO> <MO id="10" rez="4.1.5" title="INSTALLATION D'UN PATIENT EN SALLE DE SOINS" type="table" version="7"> <DO id="26" ref="4.1.5" type="Mod" title="Rapport de soins" version="4" /> </MO> <MO id="11" ref="4.1.6" title="NETTOYAGE DU CABINET (surfaces autres que les salles de soins)" type="table" version="12"> <DO id="27" ref="4.1.6" type="Mod" title="Liste des matériels et produits à utiliser pour les surfaces autres que les salles de soins et stérilisation" version="4" /> </MO> <MO id="12" ref="4.1.7" title="NETTOYAGE HEBDOMADAIRE DES SALLES DE SOINS ET DE LA STERILISATION" type="table" version="5"> <DO id="28" ref="4.1.7" type="Mod" title="Liste des matériels et produits à utiliser en salles de soins et stérilisation en fin de semaine" version="4" /> </MO> <MO id="13" ref="4.1.8" title="RAMASSAGE, TRI, ET STOCKAGE DES DECHETS ISSUS DES SOINS" type="table" version="4"> <DO id="29" ref="4.1.8" type="Mod" title="Liste des matériels et produits à utiliser en fin de mois" version="4" /> </MO> <MO id="14" ref="4.1.9" title="RAMASSAGE, DECONTAMINATION DES TENUES SOUILLEES" type="table" version="4" /> <MO id="15" ref="4.1.10" title="STOCKAGE DES TENUES DECONTAMINEES^ type="table" version="3"/> <MO id="16" ref="4.1.11" title="LAVAGE DES MAINS" type="table" version="3" /> </PR> <PR id="16" ref="4.2" title="DECONTAMINATION, STERILISATION DES INSTRUMENTS ET TRACABILITE" version="6"> <MO id="17" ref="4.2.1" title="NETTOYAGE ET DECONTAMINATION DES INSTRUMENTS SOUILLES" type="table" version="4"> <DO id="30" ref="4.2.1" type="Mod" title="affiche bain de pré-désinfection" version="4" /> </MO> <MO id="18" ref="4.2.2" title="STOCKAGE ET PRESERVATION DES INSTRUMENTS DECONTAMINES NON STERILISABLES" type="table" version="3"> <DO id="31" rez=^4.2.2" type="Mod" title="nomenclature des cassettes de soin" version="4" /> </MO> <MO id="19" ref="4.2.3" title="CONDITIONNEMENT DES INSTRUMENTS DECONTAMINES STERILISABLES" type="table" version="3"> <DO id="32" ref="4.2.3" type="Mod" title=^Nomenclature des cassettes de chirurgie" version="4" /> </MO> <MO id="20" ref="4.2.4" title="IDENTIFICATION DES PRODUITS A STERILISER" type="table" version="3"> <DO id="33" ref="4.2.4" type="Mod" title="Nomenclature des sets d'examen" version="4" /> </MO> <MO id="21" ref="4.2.5" title="CONSIGNES DE STERILISATION" type="table" version="3"> <DO id="34" ref="4.2.5" type="Mod" title="Etiquette d'identification des produits à stériliser" version="4" /> </MO> <MO id="22" ref="4.2.6" title="CONTRÔLE DES PRODUITS EN FIN DE CYCLE DE STERILISATION" type="table" version="3" /> <MO id="23" ref="4.2.7" title="CONTROLE DE LA BANDE TEMOIN DU CYCLE DE STERILISATION D'UN LOT DE PRODUITS" type="table" version="3"> <DO id="35" ref="4.2.7" type="Mod" title="Bande témoin du cycle de stérilisation d'un lot de produit" version="5" /> </MO> <MO id="24" ref="4.2.8" title="DETECTION DES PRODUITS DE STERILISATION NON CONFORMES" type="table" version="4"> <DO id="36" ref="4.2.8" type="Mod" title="Etiquette d'identification des produits non conformes en fin de stérilisation" version="4" /> </MO> <MO id="25" ref="4.2.9" title="STOCKAGE ET PRESERVATION DES INSTRUMENTS STERILISES" type="table" version="3" /> </PR> <PR id="17" ref="4.3" title="MATERIOVIGILANCE, TRACABILITE ET GESTION DES STOCKS DES CONSOMMABLES ET DES DISPOSITIFS MEDICAUX" version="6"> <MO id="26" ref="4.3.1" title="ACHAT DES PRODUITS" type="table" version="3"> <DO id="37" ref="4.3.1" type="Mod" title="Bon de commande des produits à acheter" version="4" /> </MO> <MO id="27" ref="4.3.2" title="RÉCEPTION, CONTRÔLE ET STOCKAGE DES PRODUITS ACHETES" type="table" version="4" /> <MO id="28" ref="4.3.3" title="MATERIOVIGILANCE ET TRACABILITE DES SOINS" type="elab" version="5" /> <MO id="29" ref="4.3.4" title="RÈGLEMENT DES FOURNISSEURS" type="table" version="3"> <DO id="38" ref="4.3.2" type="Mod" title="Fiche de signalement d'un incident ou d'un risque d'incident" version="4" /> </MO> </PR> <PR id="18" ref="4.4" title="CONCEPTION DES DISPOSITIFS MEDICAUX SUR MESURE" version="6"> <MO id="30" ref="4.4.1" title="MATERIOVIGILANCE ET DECLARATION DE FABRICANT DE DMSM" type="elab" version="7"> <DO id="39" ref="4.4.1" type="Mod" title="Fiche de déclarationde fabricant" version="4" 1> <DO id="40" ref="4.4.2" type="Mod" title="Modèle de courrier accompagnant la déclaration de fabricant de DMSM" version="4" /> </MO> <MO id="31" ref="4.4.2" title="PRESCRIPTION DES DISPOSITIFS MEDICAUX SURMESURE" type="elab" version="5"> <DO id="41" ref="4.4.3" type="Mod" title="Fiche de prescription et traçabilité des DMSM" version="4" /> ' </MO> <MO id="32" ref="4.4.3" title="DECLARATION DE CONFORMITE AUX EXIGENCES ESSENTIELLES DE SANTE ET DE SECURITE" type="elab" version="4"> <DO id="43" ref="4.4.5" type="Mod" title="Déclaration de conformité aux exigences essentielles de santé et de sécurité" version="4"/> </MO> <MO id="33" ref="4.4.4" title="RECEPTION DES DISPOSITIFS MEDICAUX SUR MESURE ET TRACABILITE DES SOINS" type="elab" version="5"> ~~~~~~~

<Desc/Clms Page number 53>

<DO id="42" ref="4.4.4" type=^Mod^ title="Modèle type d'un bon de livraison^ version="4" /> </MO> </PR> <PR id="19" ref="4.5" title="TRAITEMENT DES BLESSURES EXPOSANT A UN RISQUE DE CONTAMINATION" version="7"> <DO id="44" ref="4.5.1" type="Reg" title="Formulaire de déclaration des blessures exposant à un risque de contamination" version="2"> <RE id="14" ref="4.5.1" type="Reg" title="Registre des rapports d'accidents" count="1" mod~date="2002-07-09 16:43:21" /> </DO> </PR> </CH> <CH id="5" ref="5" title="Service prise en charge des patients"> <PR id="20" ref="5.1" title="ACCUEIL DES PATIENTS" version="6"> <MO id="34" ref="5.1.1" title="PLANNIFICATION DES JOURS D'OUVERTURE DU CABINET" type="elab" version="9" revision="O"> <DO id="45" ref="5.1.1" type="Arc" title= Calendrier des fermetures hebdomadaires" version="5" revision="0" /> <DO id="46" bref="5.1.2" type="Lst" title="Calendrier des fermetures annuelles" version-= 2^ mod-date="0000-00-00 00:00:00" 1> </MO> <MO id="35" ref="5.1.2" title="PRISE DE RENDEZ-VOUS (Confirmation et relance) (proposition type)" type="table" version="4" revision="0"> <DO id="47" ref="5.1.3" type="Mod" title="Fiche contact" version="4" /> </MO> <MO id="36" ref="5.1.3" title="ACCUEIL DES NOUVEAUX PATIENTS (proposition type)" type="tab!e" version="3" revision="O"> <DO id="48" ref="5.1.4" type="Mod" title="Questionnaire médical" version="4" /> <DO id="49" ref="5.1.5" type="Mod" title="Fiche de renseignements personnels" version="4" /> </MO> <MO id="37" ref="5.1.4" title="RENDEZ-VOUS DE SUIVI (proposition type)" type="table" version="4" revision="O"> <DO id="50" ref="5.1.6" type="Mod" title="Fiche de vie patient" version="4" /> </MO> <MO id="38" ref="5.1.5" title=^CONSULTATION POST-TRAITEMENT (proposition type)" type="table" version="4" revision="O"> <DO id="51" rez="5.1.7" type="Mod" title="Questionnaire de satisfaction" version="4" /> 4M0> </PR> <PR ld="21" ref="5.2" title="EXAMENS" version="6"> <MO id="40" ref="5.2.2" title="RADIO PANORAMIQUE" type="table" version="1" revision="0" /> <MO id="41" ref="5.2.3" title="RADIOGARPHIES INTRA-BUCCALES" type="table" version="2" revision--"0" /> </PR> <PR id="22" ref="5.3" title="COMMUNICATION ET INFORMATION EN PREVENTION" version="5"> <MO id="42" ref="5.3.1" title="COMPTE RENDU DE BILAN^ type--"table" version="2" revision="0"> <DO id="52" ref="5.3.1" type="Mod" title="Compte rendu de bilan^ version="4" /> </MO> <MO id="43" ref="5.3.2" title="PROPOSITION DE PLAN DE TRAITEMENT ET DEVIS" type="table" version="2" revision="0"> <DO id="53" rez=*5.3.2" type="Mod" title="Proposition de plan de traitement et devis" version="4" /> </MO> <MO id="44" ref="5.3.3" title="SIGNATURE DEVIS" type="table" version="1" revision="0" /> <MO id="45" rez="5.3.4' title="ENTENTE PREALABLE" type="table" version="2" revision="0"> <DO id="54" ref="5.3.3" type="Mod" title="Entente financière" version="4" /> <DO id="55" ref="5.3.4" type="Mod" title="Consentement à la pose d'implants" version="4" 1> </MO> <MO id="46" ref="5.3.5" title="SEANCE DE PREVENTION" type="table" version="2'' revision="0" I> </PR> <PR id="23" ref=''5.4" title="SOINS NON STERILES" version="7"> <ADS id="1" ref="1" title="IMPLANT 1" pr~id="23" revision="1" /> <DO id="56" ref="5.4.1" type="Mod" title="Documents d'examen parodontal" version="4" /> <DO id="57" rez"5.4.7* type=*Mod'' title="Conduite à tenir après une chirurgie" version="4" /> </PR> <PR id="24" ref="5.5" title="SOINS STERILES" version=^6^ 1> <PR id="25" ref="5.6" title="SECRETARIAT ADMINISTRATIF" version="5"> <MO id="47" rez="5.6.1" title="REGLEMENT PAR LE PATIENT" type="table" version="3" revision="0"> <DO id="58" ref="5.6.1" type="Mod" titie-= Facture" version="4" /> </MO> <MO id="48" ref="5.6.2" title="RELANCE D'HONORAIRE" type="table" version="3" revision="0"> <DO id="59" ref="5.6.2" type="Mod" title="Courrier de relance n* 1 version="4" /> <DO id="60" ref="5.6.3" type="Mod" title="Courrier de relance n 2" version="4" /> <DO id="61" bref="5.6.4" type="Mod" title="Counier de relance n 3" version="4" 1> <DO id="62" ref="5.6.5" type="Mod" title="Courrier de relance n 4" version="4" /> <DO id="63" ref="5.6.6" type="Mod" title="Courrier de relance n 5" version="4" /> <DO id="64" ref="5.6.7" type="Mod" title="Suivi de relance" version="4" 1> </MO> </PR> </CH> <CH id="6" ref="6" title="Analyse du Système Qualité"> <PR id="9" ref="6.1" title="ALERTE anomalies, non-confonnités, réclamations" version="10"> <DO id="16" ref="6.1.1" type="Reg" title="Rapport d'alerte et d'action corrective' version="3"> <RE id="7" ref="6. 1. 1" type="Reg" title="Registre des rapports d'alertes et d'actions correctives" count="0" mod date="0000-00-00 00:00:00" />

<Desc/Clms Page number 54>

</DO> </PR> <PR id="10" ref="6.2" title="ACTIONS CORRECTIVES ET PROCEDURE DE VERIFICATION" version="9"> <DO id="17" ref="6.2.1" type="Reg" title="Bilan de vérification trimestrielle des actions correctives" version="3"> <RE id="8" ref="6.2.1" type="Reg" title="Registre de vérification des actions correctives" count="0" mod~date="0000-00-00 00:00:00" 1> </DO> </PR> <PR id="11" ref="6.3" title="ACTIONS PREVENTIVES ET PROCEDURE DE VERIFICATION" version="9"> <DO id="18" ref="6.3.1" type="Reg" title="Rapport d'action préventive" version="3"> <RE id="9" ref="6.3.1" type="Reg" title="Registre des actions préventives" count="0" mod date--"0000-00-00 00:00:00" /> </DO> <DO id="19" ref="6.3.2" type="Reg" title="Bilan de vérification trimestrielle des actions préventives" version="3"> <RE id="10" ref="6.3.2" type="Reg" title="Registre de vérification des actions préventives" count="0' mod~date="0000-00-00 00:00:00" /> </DO> </PR> <PR id="12" ref="6.4" title="BILAN JOURNALIER" version="7"> <DO id="20" ref="6.4.1" type="Reg" title="Tableau de bord joumalier" version="3"> <RE id="11" ref="6.4.1" type="Reg" title="Registre des tableaux de bord journaliers des patients" count="13" mod~date="2002-07-30 15:30:50" /> </DO> </PR> <PR id="13" ref="6.5" title="REVUE MENSUELLE DES CONTRATS PATIENTS" version="9"> <DO id="21" ref="6.5.1" type="Reg" title="Rapport de revue de contrats" version="3"> <RE id="12" ref="6.5.1" type="Reg" title="Registre des rapports de revue de contrat" count="0" mod~date="0000-00-00 00:00:00" 1> </DO> </PR> <PR id="14" ref="6.6" title="REVUE DE DIRECTION TRIMESTRIELLE" version="7"> <DO id="22" ref="6.6.1" type="Reg" title="Rapport de revue de direction" version="3"> <RE id="13" ref="6.6.1" type="Reg" title="Registre des rapports de revue de direction" count="0" mod-date="0000-00-00 00:00:00" 1> </DO> </PR> </CH> <UPDATE> <glossaire mod~date="2002-07-25 11:25:09" /> <messages mod~date="2002-07-07 17:01:55" /> <history mod~date="2002-08-13 00:50:39" /> </UPDATE> <ISYSTEM>

Claims (28)

1. REVENDICATIONS 1. Procédé de synchronisation de données entre au moins un poste client (1) comportant des moyens de stockage d'un ensemble de données et un poste serveur (2) comportant des moyens des stockage d'au moins une base d'enregistrement de données, connectés l'un à l'autre par l'intermédiaire d'un réseau de télécommunications (3), le procédé étant déclenché par l'émission d'une requête de synchronisation, caractérisé en ce que le procédé comporte des étapes de : - suite à la réception de la requête, création par le poste serveur d'un fichier de description comportant une description complète d'un ensemble de données associées au poste client contenu dans la base des enregistrements, - transmission du fichier de description au poste client à travers le réseau de télécommunications, - suite à la réception du fichier système, établissement par le poste client d'une liste de données à échanger entre les deux postes client et serveur, en comparant chaque donnée décrite dans le fichier de description à la donnée correspondante enregistrée dans les moyens de stockage du poste client, échange à travers le réseau de télécommunication entre le poste client et le postë serveur des

   <Desc/Clms Page number 56>

   données désignées par la liste précédemment établie.
2. 2. Procédé selon la revendication 1, caractérisé en ce que suite à la réception du fichier système par le poste client, comparaison par ce dernier des informations de version et/ou de révision des différentes données, informations contenues dans le fichier de description, avec des informations de version et/ou de révision des données correspondantes enregistrées dans les moyens de stockage du poste client.
3. 3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que la liste de données à échanger comporte une première liste de données destinées à être transmises par le poste serveur au poste client et une deuxième liste de données destinées à être transmises par le poste client au poste serveur.
4. 4. Procédé selon la revendication 3, caractérisé en ce que la deuxième liste est élaborée alors que le poste client est hors ligne dès qu'une donnée est modifiée ou créée en local dans les moyens de stockage du poste client.
5. 5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que le procédé comporte une étape supplémentaire d'envoi sélectif par le poste client au poste serveur d'un ensemble d'informations de mises à jour depuis la précédente synchronisation concernant un

   <Desc/Clms Page number 57>

   utilisateur du poste client et enregistrées dans les moyens de stockage du poste client.
6. 6. Procédé selon l'une des revendication 1 à 5, caractérisé en ce que le procédé comporte une étape supplémentaire d'échange sélectif de messages de l'utilisateur entre les postes client et le poste serveur, une première partie des messages étant enregistrée dans les moyens de stockage du poste serveur et une deuxième partie des messages étant enregistrée dans les moyens de stockage du poste client.
7. 7. Procédé selon la revendication 6, caractérisé en ce que l'échange de messages comprend des étapes de : - réception de la première partie des messages pour l'utilisateur par le poste client, et - envoi au poste serveur de la deuxième partie des messages de l'utilisateur.
8. 8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce que le procédé comporte en outre une étape supplémentaire de mise à jour sélective du logiciel enregistré dans les moyens de stockage du poste client.
9. 9. Procédé selon l'une des revendications 1 à 8, caractérisé en ce que la requête en synchronisation est envoyée automatiquement par le poste client au poste serveur.

   <Desc/Clms Page number 58>
10. 10. Procédé selon l'une des revendications 1 à 8, caractérisé en ce que la' requête en synchronisation est envoyée sur ordre de l'utilisateur par le poste client au poste serveur.
11. 11. Support informatique de stockage, caractérisé en ce qu'il comporte un logiciel apte à mettre en #uvre le procédé de synchronisation de données selon l'une des revendications 1 à 10.
12. 12. Procédé de synchronisation de données entre au moins un poste client (1) comportant des moyens de stockage d'un ensemble de données et un poste serveur (2) comportant des moyens de stockage d'au moins une base d'enregistrement de données, connectés l'un à l'autre par l'intermédiaire d'un réseau de télécommunications (3) , le procédé étant apte à être mise en #uvre sur le poste client, caractérisé en ce que le procédé comporte des étapes de : - émission d'une requête de synchronisation vers le poste serveur, réception à travers le réseau de télécommunications d'un fichier de description du poste serveur en réponse à la requête, comportant une description complète d'un ensemble de données associées au poste client contenu dans la base des enregistrements,

    <Desc/Clms Page number 59>

    - suite à la réception du fichier de description, établissement d'une liste de données à envoyer vers et/ou à télécharger du poste serveur, en comparant chaque donnée décrite dans le fichier de description à la donnée correspondante enregistrée dans les moyens de stockage du poste client, - envoi vers et/ou téléchargement du poste serveur, à travers le réseau de télécommunications, des données désignées par la liste précédemment établie.
13. 13. Procédé selon la revendication 12, caractérisé en ce que, suite à la réception du fichier de description, le poste client compare des informations de version et/ou de révision des différentes données, informations contenues dans le fichier de description, avec des informations de version et/ou de révision des données correspondantes enregistrées dans les moyens de stockage du poste client.
14. 14. Procédé selon l'une des revendications 12 ou 13, caractérisé en ce que la liste de données à envoyer vers et/ou à télécharger du poste serveur comporte une première liste de données destinées à être téléchargées du poste serveur et une deuxième liste de données destinées à être envoyées au poste serveur.
15. 15. Procédé selon la revendication 14, caractérisé en ce que la deuxième liste est élaborée alors que le poste

    <Desc/Clms Page number 60>

    client est hors ligne, dès qu'une donnée est modifiée ou créée en local dans les moyens de stockage du poste client.
16. 16. Procédé selon l'une des revendications 12 à 15, caractérisé en ce que le procédé comporte une étape supplémentaire d'envoi sélectif au poste serveur d'un ensemble d'informations mises à jour depuis la précédente synchronisation concernant un utilisateur du poste client et enregistrées dans les moyens de stockage du poste client.
17. 17. Procédé selon l'une des revendication 12 à 16, caractérisé en ce que le procédé comporte une étape supplémentaire d'envoi sélectif vers et/ou de téléchargement sélectif du poste serveur de messages de l'utilisateur, une première partie des messages étant enregistrée dans les moyens de stockage du poste serveur et une deuxième partie des messages étant enregistrée dans les moyens de stockage du poste client.
18. 18. Procédé selon l'une des revendications 12 à 17, caractérisé en ce que le procédé comporte en outre une étape supplémentaire de mise à jour sélective du logiciel enregistré dans les moyens de stockage du poste client.
19. 19. Procédé selon l'une des revendications 12 à 18, caractérisé en ce que la requête en synchronisation est

    <Desc/Clms Page number 61>

    envoyée automatiquement par le poste client au poste serveur.
20. 20. Procédé selon l'une des revendications 12 à 18, caractérisé en ce que la requête en synchronisation est envoyée sur ordre de l'utilisateur par le poste client au poste serveur.
21. 21. Support informatique de stockage, caractérisé en ce qu'il comporte un logiciel apte à mettre en #uvre le procédé de synchronisation de données selon l'une des revendications 12 à 20.
22. 22. Procédé de synchronisation de données entre au moins un poste client (1) comprenant des moyens de stockage d'un ensemble de données et un poste serveur (2) comprenant des moyens de stockage d'au moins une base d'enregistrements de données, connectés l'un à l'autre par l'intermédiaire d'un réseau de télécommunications (3) , le procédé étant apte à être mise en #uvre sur le poste serveur, caractérisé en ce que le procédé comporte des étapes de : - Réception à travers le réseau de télécommunication d'une requête de synchronisation du poste client, - suite à la réception de la requête, création d'un fichier de description comportant la description complète d'un ensemble de données associées au poste client contenu dans la base des enregistrements,

    <Desc/Clms Page number 62>

    - transmission du fichier de description au poste client à travers le réseau de télécommunications, - réception du et/ou envoi vers le poste client à travers le réseau de télécommunications d'un deuxième ensemble de données sur requête du poste client.
23. 23. Procédé selon la revendication 22, caractérisé en ce que le poste serveur envoie vers le poste client un premier ensemble de données sur requête du poste client, puis réceptionne du poste client un deuxième ensemble de données.
24. 24. Procédé selon la revendication 23, caractérisé en ce que, suite à la réception du deuxième ensemble de données du poste client, le poste serveur acquitte la réception et met à jour, dans les moyens de stockage du poste serveur, les enregistrements la base des enregistrements de données associés au poste client.
25. 25. Procédé selon l'une des revendications 22 à 24, caractérisé en ce que le procédé comporte une étape supplémentaire de réception sélective du poste client d'un ensemble d'informations de mises à jour depuis la précédente synchronisation concernant un utilisateur du poste client et enregistrement de ces information sur les moyens de stockage du poste serveur.

    <Desc/Clms Page number 63>
26. 26. Procédé selon l'une des revendication 22 à 25, caractérisé en ce que le procédé comporte une étape supplémentaire d'envoi sélectif vers et/ou de réception sélective du poste client de messages de l'utilisateur, une première partie des messages étant enregistrée dans les moyens de stockage du poste serveur et une deuxième partie des messages étant enregistrée dans les moyens de stockage du poste client.
27. 27. Procédé selon l'une des revendications 22 à 26, caractérisé en ce que le procédé comporte en outre une étape supplémentaire d'envoi sélectif vers le poste client d'une mise à jour éventuelle du logiciel enregistré dans les moyens de stockage du poste client.
28. 28. Support informatique de stockage, caractérisé en ce qu'il comporte un logiciel apte à mettre en #uvre le procédé de synchronisation de données selon l'une des revendications 22 à 27.