Serveur Télématique d'identifiant Communautaire. Interface STIC-SIH Dossier de Spécifications Générales. Interface STIC-SIHv1.0.

Transcription

1 Interface STIC - SIH Dossier de Spécifications Générales Interface STIC-SIHv1.0.doc Page 1 sur 25

2 1. Sommaire 1. SOMMAIRE OBJET DU DOCUMENT Présentation Terminologie Documents de référence NORME HPRIM XML Association Hprim Hprim XML INTERFACE STIC -SIH Le Serveur STIC du SIH Architecture Réseau Service d'envoi (FILE_LOADER_TO_MSMQ) Service de réception (MSMQ_LOADER_TO_FILE) TRAITEMENTS Les données patient Traitement des informations à envoyer Traitement des informations reçues INTERFACE CENTRE LÉON BÉRARD-STIC Choix organisationnels Choix de développement de l'interface Traitement des messages ANNEXES Table des erreurs retournées par STIC Notes d'usage de Hprim XML...25 Interface STIC-SIHv1.0.doc Page 2 sur 25

3 2. Objet du Document 2.1. Présentation Le Serveur Télématique d'identité Communautaire (STIC) est un projet permettant de gérer des Identifiants Permanent du Patient Régional (IPPR). Chaque établissement disposant d'un Système d'information gère ses patients de manière différente, et les identifie de manière unique au sein de l'établissement en leur attribuant un Identifiant Permanent du Patient Local (IPPL). L'objectif du STIC est de rapprocher ces différents IPPL en se basant sur la comparaison de certains critères (Nom, Prénom, date de naissance, ) et de les associer à un IPPR unique. Afin de pouvoir obtenir du serveur STIC principal cet IPPR, il est nécessaire de mettre en place au sein du système d'information de l'établissement une interface entre la base patient et le STIC. Ce document décrit les exigences de fonctionnement de l'interface STIC - SIH 2.2. Terminologie SIH STIC IPPR IPPL Fusion locale Fusion centrale Défusion locale Défusion centrale Système d'information Hospitaliser Serveur Télématique d'identifiant Communautaire Identifiant Permanent du Patient Régional Identifiant Permanent du Patient Local Opération de fusion de deux IPPL réalisée au sein d'un établissement lorsque un doublon est détecté Opération de fusion de deux IPPL réalisée sur la plate-forme centrale STIC (interface Web) lorsque un doublon est détecté Opération effectuée au sein d'un établissement lorsque deux patients distinct ont été identifié par le même IPPL Opération effectuée sur la plate-forme centrale STIC (interface Web) lorsque deux patients distinct ont été identifié par le même IPPR 2.3. Documents de référence Recommandations Hprim XML (en téléchargement sur Charte d'identification du patient pour le projet STIC Interface STIC-SIHv1.0.doc Page 3 sur 25

4 3. Norme Hprim XML 3.1. Association Hprim L'Association "HPRIM" édite les "Recommandations HPRIM", protocole de communication proposé par tous les Fournisseurs d Informatiques Médicales adhérents à l association. Créée en octobre 1990 de la nécessité d Harmoniser et de PRomouvoir les Informatiques Médicales, l'association "HPRIM" (juin 1997 plus de 150 adhérents) regroupe des Fournisseurs d Informatiques Médicales. Extrait du site Hprim XML La recommandation «H XML» décrit un langage XML d échange de messages entre acteurs de santé. Plus précisément, cette recommandation décrit le contenu et le format de ces messages XML. Elle ne décrit pas les mécanismes d échange et de transport mis en œuvre pour les acheminer, ces mécanismes faisant l objet d autres recommandation H.PR.I.M. tel que «H Net». Extrait de la documentation Hprim XML L'intégralité des informations transmises à l'interface par le STIC, ou envoyée au STIC par cette interface est au format Hprim XML. Cette norme à été choisie car elle est déjà en usage dans certains établissements. De plus elle a été élaborée par des professionnels de santé dans un souci de pragmatisme et d'adaptabilité. La documentation Hprim XML est disponible sur le site de l'association ( ) Interface STIC-SIHv1.0.doc Page 4 sur 25

5 4. Interface STIC -SIH L'interface STIC-SIH permet de : - recevoir des messages XML du STIC - traiter ces messages et les intégrer à la base de donnée patient SIH - envoyer des messages au STIC en fonction des informations du SIH SIH Serveur STIC du SIH STIC Adresse dédiée Traitement des informations à envoyer écriture XML Ecoute Service d'envoi DB patient Erreur Traité Traitement des informations reçues lecture XML Réception Service de réception Cette interface est divisée en deux parties. La première, générique, est le serveur STIC du SIH. Sur ce serveur, quatre répertoires sont accessibles : - le répertoire "Ecoute" : c'est dans ce répertoire que sont déposés les messages XML destinés au STIC - le répertoire "Réception", dans lequel sont déposés les messages XML envoyés par le STIC - le répertoire "Erreur" : les messages déposés dans "Ecoute", mais qui ne respectent pas les normes de saisies y sont copiés - le répertoire "Traité" : les messages qui ont été déposés dans "Ecoute" et qui ont effectivement été envoyés au STIC sont déplacés dans ce répertoire. La seconde partie concerne le traitement des messages à envoyer et reçus. Cette partie est spécifique à chaque SIH. Il s'agit : - de la création des messages XML selon la norme Hprim en extrayant les données de la base de données Patient du SIH, et de leur dépôt dans "Ecoute" - de la lecture des messages XML dans "Réception", et de l'intégration des informations dans la base de données Patient du SIH. Interface STIC-SIHv1.0.doc Page 5 sur 25

6 4.1. Le Serveur STIC du SIH C'est sur ce serveur que se trouvent les répertoires "Ecoute", "Réception", "Erreur" et "Traité", ainsi que les services d'envoi et de réception. Ces Services ont été développés par la société STERIA. Ils sont présentés sous la forme d'applications à installer sur le serveur STIC du SIH. (Machine dédiée, OS: Windows 2000 Server avec MSMQ) 4.2. Architecture Réseau Le serveur STIC du SIH est connecté au serveur STIC principal par une liaison VPN logicielle (gérée via Windows 2000 Server). STIC VPN SIH Serveur STIC Principal FIREWALL INTERNET FIREWALL Serveur STIC du SIH DMZ Publique DMZ Publique 4.3. Service d'envoi (FILE_LOADER_TO_MSMQ) Ce service attend l'arrivée de fichiers XML dans le répertoire "Ecoute". Chaque fichier est lu, et confronté au schéma XML défini dans la norme Hprim. On vérifie la conformité des informations avec la charte d'identification du patient, et la présence des champs obligatoires. En fonction du résultat de cette phase de vérification, le message peut être envoyé vers le STIC (le fichier sera déplacé dans le répertoire "Traité") ou déplacé dans le répertoire "Erreur" (un mail est également envoyé à une adresse dédiée du SIH pour avertir d'un problème de traitement) 4.4. Service de réception (MSMQ_LOADER_TO_FILE) Ce service est en attente de messages sur une messagequeue. Chaque message est lu, et transformé en fichier au format Hprim XML qui est déposé dans le répertoire "Réception" Interface STIC-SIHv1.0.doc Page 6 sur 25

7 5. Traitements Le traitement des informations reçues et à envoyer est spécifique à chaque SIH. Cette partie va donc établir la liste des messages qu'il est nécessaire de pouvoir traiter et créer Les données patient Les identifiants Les patients sont identifiés de deux manières : - par leur Identifiant Permanent du Patient Régional - par leur Identifiant Permanent du Patient Local, couplé au code attribué au SIH. (A l'heure actuelle, la valeur de ce code n'est pas fixée lors de l'envoi par le SIH -si sa valeur n'a aucune importance, le champ doit tout de même être rempli-, elle est cependant exacte lors des retours effectués par STIC au SIH) Si l'ippr est connu, ces deux identifiants doivent toujours être présents dans le message XML Les traits stricts Le rapprochement des patients inscrits au STIC est basé sur les traits stricts. Ils sont communs à tous les SIH. Ce sont : - le nom de naissance - le prénom - le sexe - la date de naissance - le pays de naissance - le code postal du lieu de naissance Attention! Les traits stricts sont soumis à la charte d'identification! Les traits étendus Les traits étendus sont spécifiques à chaque établissement. Ce sont : - Le nom usuel - L'adresse d'habitation (adresse, code postal, ville, pays) - Le numéro de téléphone Interface STIC-SIHv1.0.doc Page 7 sur 25

8 Tableau récapitulatif ID Traits Stricts Traits étendus Nom IPPR IPPL Code SI Nom Prénom Sexe Date de naissance Pays de Naissance Code postal de naissance Nom usuel Commune de naissance Adresse ligne 1 Adresse ligne 2 Adresse ligne 3 Code Postal Commune Pays Téléphone Description Identifiant Permanent du Patient Régional Identifiant Permanent du Patient Local Identifiant Permanent du Patient Régional Nom de naissance (25 caractères au maximum) Premier prénom uniquement (20 caractères au maximum) M ou F Date (format yyyy-mm-dd) Code pays INSEE sur 3 caractères Code postal de la commune de naissance (5 caractères) Nom d'usage pour les femmes mariées Commune de naissance Adresse d'habitation. Première ligne Adresse d'habitation. Deuxième ligne Adresse d'habitation. Troisième ligne Code Postal de l'adresse d'habitation Nom de la commune d'habitation Pays d'habitation (code pays INSEE) Numéro de téléphone du patient Note : se référer à la Charte d'identification pour plus de détails Interface STIC-SIHv1.0.doc Page 8 sur 25

9 5.2. Traitement des informations à envoyer Messages Hprim XML Les informations à envoyer sont extraites de la Base Patient du SIH, et mise au format Hprim XML avant d'être copiées dans le répertoire "Ecoute" Le type de message mgsevenementpatient est le seul utilisé pour transmettre des informations du SIH au STIC Evénement Patient (MsgEvenementPatient) Ce message est utilisé dans les cas suivants : - Inscription d'un patient à STIC - Modification des traits stricts ou étendus d'un patient - Fusion locale d'un patient - Défusion locale d un patient - Demande d informations asynchrone Note : Dans les schémas suivants, seuls les éléments entourés sont utilisés. Interface STIC-SIHv1.0.doc Page 9 sur 25

10 Inscription d'un patient au STIC Envoi d'un message de type msgevenementpatient avec action=création IMPORTANT : Dans le cas où l'erreur ERR010 est retournée (voir la table des erreurs renvoyée par STIC en annexe), le SIH peut forcer la création en mettant dans le champ "commentaire" du fichier envoyé la valeur "IGNORE_HOMONYME". Modification d'un patient Envoi d'un message de type msgevenementpatient avec action=modification Fusion locale Envoi d'un message de type msgevenementpatient avec action=fusion Message signifiant une fusion de deux IPPL au sein d'une structure. Ce message contient deux entités de type patient : la première "patient" correspond au patient dont l'ippl est conservé dans l'établissement. Le seconde, "patienteliminé" contient les informations relatives au patient dont l'ippl est supprimé. Interface STIC-SIHv1.0.doc Page 10 sur 25

11 Défusion locale Envoi d'un message de type msgevenementpatient avec action=défusion Lorsque deux patients distinct se sont vus attribuer un même IPPL de manière erronée, on utilise ce message pour signifier cette erreur au STIC, et le nouvel IPPL créé. Ce message contient deux entités de type patient : la première "patient" correspond au patient dont l'ippl est conservé tel quel dans l'établissement. Le seconde, "patienteliminé" contient les informations relatives au patient dont l'ippl est créé. Demande d informations Envoi d'un message de type msgevenementpatient avec action=information Ce message permet de demander au STIC l'envoi de l'intégralité des données d un patient : tous les traits stricts et tous les tous les traits étendus connus de chaque SIH. L'entité "Patient" doit contenir l'ippl et/ou l'ippr. Les autres éléments de l'entités "Patient" peuvent être complétés avec des valeurs fictives s'ils sont obligatoires, ou omis s'ils sont facultatifs Interface STIC-SIHv1.0.doc Page 11 sur 25

12 5.3. Traitement des informations reçues Messages Hprim XML Trois types de messages peuvent être envoyés par le STIC au SIH : - Messages de type msgretouridentifiantspatients : retour d'inscription d'un patient au STIC (envoi de l'ippr) - Messages de type msgretourmodificationspatients : retour de modification d'un patient - Messages de type msgretourinformationspatients : Envoi d'informations sur un patient Ces messages sont lus dans le répertoire "Réception" Les messages retour peuvent être envoyés quelques secondes après le traitement du message du SIH si tout se passe bien. Néanmoins, dans le cas de l'inscription d'un patient, de la fusion ou de la défusion locale, plusieurs jours peuvent être nécessaires s'il est fait appel au Service Qualité Retour d'inscription d'un patient (MsgRetourIdentifiantsPatients ) Ce message peut être envoyé en retour après l'inscription d'un patient au STIC, ou après une défusion locale (si le nouvel IPPL ne peut être rapproché d'aucun patient existant et est considéré comme nouvellement inscrit : dans ce cas, le SIH reçoit un message de type avertissement qui sera nécessairement suivi d un message OK après traitement) Il retourne l'ippr, ainsi que les couples IPPL/SI (s'il existent) au SI demandeur. Ce message peut avoir l'un des trois statuts suivants : entetemessageacquittement statut= OK La création a été effectuée. Le message contient l'ippr du patient inscrit entetemessageacquittement statut= Avertissement Ce message indique que la création n'a pas été effectuée. Interface STIC-SIHv1.0.doc Page 12 sur 25

13 Le message contient le numéro du message XML acquitté et un texte d'avertissement. (voir la table des messages d'information en annexe) Le SIH doit s attendre à recevoir par la suite un message de statut «OK» lorsque le traitement final aura été effectué. entetemessageacquittement statut= Erreur Une erreur a été rencontrée lors de la tentative de création de l'ippr. (voir la table des messages d'erreur en annexe) Retour d'une modification (MsgRetourModificationsPatients) Ce message est envoyé par le STIC dans les cas suivants : - Pour informer le SIH de l'état d'une demande de modification. L'entête de message utilisée est enteteacquittement. - Pour signifier une activation / désactivation d'un patient réalisée sur la plate-forme centrale L'entête de message utilisée est entetemessage. - Pour signifier modification d'un patient réalisée sur la plate-forme centrale, ou une modification des traits stricts demandée par un SIH. L'entête de message utilisée est entetemessage. - Pour signifier une fusion / défusion d'un patient réalisée sur la plate-forme centrale. L'entête de message utilisée est entetemessage. Dans ces trois derniers cas, le message est issu d'une action effectuée sur le serveur central, et est indépendant des envois du SIH. Il est envoyé à tous les SIH ayant connaissance du patient concerné. Le message msgretourmodificationpatient contient, en plus de l'entête, toutes les informations du patient (excepté en cas d'erreur) : IPPL du SIH, IPPR, traits stricts et étendus EnteteMessageAcquittement peut avoir trois statuts entetemessageacquittement statut= OK L'action a été effectuée. entetemessageacquittement statut= Avertissement Ce message indique que l'action n'a pas été effectuée, et que la demande a été mise en attente ou transformée par STIC. Le message contient le numéro du message acquitté et le message signifiant la mise en attente. (voir la table des messages d'information en annexe) entetemessageacquittement statut= Erreur Une erreur a été rencontrée lors de la réalisation de l'action demandée. (voir la table des messages d'erreur en annexe) Interface STIC-SIHv1.0.doc Page 13 sur 25

14 Retour modification Ce message est envoyé dans trois cas : - après l'envoi au STIC d'un message de type msgevenementpatient avec action=modification : entetemessageacquittement est utilisé - après une modification effectuée par un SIH sur les traits stricts (il est envoyé à tous les SIH ayant connaissance du patient sans demande préalable) : entetemessage est utilisé, - après une modification effectuée sur les traits stricts depuis la plate-forme STIC centrale (sans demande préalable) : entetemessage est utilisé. retourmodificationspatients actionavertissement= modification Retour activation Ce message est envoyé (sans demande préalable du SIH) après l'activation d'un patient. retourmodificationspatients actionavertissement= activation Retour désactivation Ce message est envoyé (sans demande préalable du SIH) après la désactivation d'un patient. retourmodificationspatients actionavertissement= désactivation Retour fusion locale / défusion locale Ce message est envoyé après la fusion ou défusion locale d'un patient. retourmodificationspatients actionavertissement= fusionlocale Fusion centrale Ce message permet d'avertir le SIH d'une fusion de deux IPPR réalisée sur le serveur STIC via l'interface d'administration. Interface STIC-SIHv1.0.doc Page 14 sur 25

15 Cas particulier : Ce cas est rare : il suppose que deux IPPL d'un même SIH (représentant le même patient) aient été enregistrés au STIC sous deux IPPR différents. Lorsqu'on fusionne un patient A vers un patient B, les IPPL du patient A sont rattachés au patient B. Si un IPPL du même SI est déjà présent, le nouvel IPPL est rattaché à l'ippr mais il doit être inaccessible et invisible. Le message renvoyé au SI contient l'ippr et ses traits stricts ainsi que l'ippl qui a disparu et ses traits étendus. Deux messages de ce même type sont envoyés. Le premier correspond au patient dont l'ippr est conservé. Le second, pour lequel l'entité "Alias" contient "OBSOLETE" correspond au patient dont l'ippr est supprimé. retourmodificationspatients actionavertissement= fusioncentrale Défusion centrale Ce message permet d'avertir le SIH d'une défusion réalisée sur le serveur STIC via l'interface d'administration. retourmodificationspatients actionavertissement= defusioncentrale Interface STIC-SIHv1.0.doc Page 15 sur 25

16 Informations Patient (MsgRetourInformationsPatients) Ce message contient toutes les informations connues du STIC pour un patient, c'est-à-dire, pour chaque SI, l'ensemble des traits stricts et étendus, ainsi que l'ippl couplé au code SI suite à une demande d informations du SIH (Envoi d'un message de type msgevenementpatient avec action=information du SIH à STIC) Interface STIC-SIHv1.0.doc Page 16 sur 25

17 6. Interface Centre Léon Bérard-STIC Le Centre Léon Bérard est le premier établissement a s'être connecté à STIC. Cette partie présente les choix organisationnels et techniques du service informatique du CLB pour la connexion au Serveur STIC 6.1. Choix organisationnels Au Centre Léon Bérard, c'est le personnel d'accueil qui est chargé de la saisie et de la mise à jour des informations dans la Base Patient (suivant le respect de la charte patient) Il a donc été créé une adresse mail dédiée, accessible à ce personnel. Tous les messages envoyés par l'interface STIC le sont à cette adresse. De cette manière, les corrections à apporter (lors de l'invalidation de données qui ne respectent pas la charte, par exemple) peuvent être effectuées immédiatement. Lors des premiers essais, le service informatique pourra être sollicité pour les messages relatifs aux bugs. En routine, tous les mails sont envoyés au personnel d accueil. L origine des mails pourra être : Erreurs d identité : corrigées par l accueil en interne Données manquantes : corrigées par l accueil en interne Puis d autres origines : Erreur de STIC : l accueil CLB fera appel à la cellule qualité STIC (téléphone) pour régler les éventuels litiges sur les traits du patient. En définitive, l accueil et la cellule qualité STIC seront autonomes pour résoudre les problèmes via leur applicatif respectif Choix de développement de l'interface Architecture des données Plutôt que d'apporter des changements massif à la base de données patient du SI, il a été décidé d'ajouter deux tables permettant de gérer l'ippr. Ces tables permettent de garder la trace des différents envois faits au STIC. De la même manière, les informations reçues du STIC sont stockées et non directement intégrées à la base patient. (L'évaluation de la pertinence de la mise à jour est laissée au personnel d'accueil) Interface STIC-SIHv1.0.doc Page 17 sur 25

18 La première, MAL100, contient les informations envoyées au STIC, et le statut de celles-ci (envoyée, acquittée, etc.) Nom IPPL IPPR STATUT_ENVOI DATE_ENVOI HEURE_ENVOI STATUT_RECEPTION DATE_RECEPTION HEURE_RECEPTION NOM_USUEL PRENOM NOM_NAISSANCE SEXE DATE_NAISSANCE PAYS_NAISSANCE CODE_POSTAL_NAISSANCE COMMUNE_NAISSANCE ADRESSE_LIGNE1 ADRESSE_LIGNE2 ADRESSE_LIGNE3 CODE_POSTAL_ADRESSE COMMUNE_ADRESSE PAYS_ADRESSE TELEPHONE ACCORD_PATIENT ACTIF ID_FUSION Description Identifiant du Patient Permanent Local Identifiant du Patient Permanent Régional (complété lors de la réception du message RetourIdentifiantPatient) Statut indiquant le type du dernier message envoyé Date d'envoi du message Heure d'envoi du message Statut indiquant le type du dernier message reçu Date de réception du message Heure de réception du message Oui/non Oui/non (mis à jour lors d'une activation / désactivation du patient) Permet de référencer l'ippl du patient conservé lorsque l'ippl en cours est supprimé par une fusion (permet le lien lors du retour fusionlocale qui ne contient que l IPPL gardé) La seconde, STI001, contient les modifications des traits stricts envoyés par la plate-forme centrale. Comme il a été mentionné plus haut, ces informations ne sont jamais introduites tel quel dans la base patient. A chaque fois que cette table est mise à jour, un message est adressé au personnel de l'accueil, qui va répercuter ces modifications après confrontation aux données existantes. Nom IPPL IPPR PRENOM NOM_NAISSANCE SEXE DATE_NAISSANCE PAYS_NAISSANCE CODE_POSTAL_NAISSANCE Description Interface STIC-SIHv1.0.doc Page 18 sur 25

19 Statuts d'envoi et de réception Les statuts d'envoi et de réception évoluent de la manière suivante : STATUT_ENVOI : - "010" lorsque un message de création est envoyé - "030" lorsque un message de modification est envoyé - "600" (pour l'ippl à supprimer ) lorsque un message de fusion est envoyé STATUT_RECEPTION Cas retouridentifiantpatient : - "400" si le statut est "OK" - "200" si le statut est "Avertissement" (exemple : mise en attente de création d'un IPPR) - "100" si le statut est "Erreur" Cas retourmodificationpatient : modification - "400" si le statut est "OK" fusionlocale - "400" pour l'ippl conservé si le statut est "OK" - "600" pour l'ippl supprimé si le statut est "OK" fusioncentrale - "500" si le statut est "OK"; "900" si le tag "Alias" contient "OBSOLETE" défusioncentrale - "510" si le statut est "OK" Interface STIC-SIHv1.0.doc Page 19 sur 25

20 6.3. Traitement des messages Traitement des messages à envoyer Note : Actuellement, le Centre Léon Bérard n'utilise pas le message de demande d'information au STIC Un déclencheur a été mis en place sur la base patient. Chaque mise à jour effectuée déclenche l'envoi d'un message MSMQ contenant l'ippl mis à jour à une file de message. Ce service lit cette file en permanence et crée les messages XML pour STIC Pour chaque message lu, si la mise à jour de la base patient ne porte pas sur les traits stricts ou étendus: Si cet IPPL n'existe pas dans la table des IPPL envoyés à STIC (MAL100) On effectue une mise à jour de la table, et on crée un message XML de type msgevenementpatient avec action=création qui est déposé dans le répertoire "Ecoute" du serveur STIC du Centre Léon Bérard Si cet IPPL existe dans la table des IPPL envoyés à STIC (MAL100), et n'existe pas dans la table des IPPL traités par STIC (STI001) On effectue une mise à jour de la table MAL100, et on crée un message XML de type msgevenementpatient avec action=modification qui est déposé dans le répertoire "Ecoute" du serveur STIC du Centre Léon Bérard. Cas particulier : si le statut pour cet IPPL dans MAL100 correspond à "message envoyé" ("010"), on crée un message de type msgevenementpatient avec action=création Si cet IPPL existe dans la table des IPPL envoyés à STIC (MAL100), et dans la table des IPPL traités par STIC (STI001) Si les données de la base patient, de la table des IPPL envoyés à STIC (MAL100), et de la table des IPPL traités par STIC (STI001) sont identiques, on supprime l'enregistrement correspondant dans STI001. (Il s'agit de l intégration d une modification signalée par le STIC qui n'affecte ni les traits stricts, ni les traits étendus) Si les données (traits stricts) de la base patient et de la table des IPPL envoyés à STIC (MAL100) sont différents, et que les données (traits stricts) de la base patient et de la table des IPPL traités par STIC (STI001) sont identiques, on crée un message de type msgevenementpatient avec action=modification si la différence porte sur les traits étendus. On met à jour MAL100, et on supprime l'enregistrement dans STI001. Si les données (traits stricts) de la base patient et de la table des IPPL envoyés à STIC (MAL100) sont différents, et que les données (traits stricts) de la base patient et de la table des IPPL traités par STIC (STI001) sont différent, on se trouve dans le cas d un litige, on envoie un mail à l accueil qui contacte la cellule qualité STIC pour solutionner le problème. Dans tous les cas, si ACTIF ou ACCORD_PATIENT valent "Non", on effectue aucun traitement. Interface STIC-SIHv1.0.doc Page 20 sur 25

21 File de messages MSMQ (IPPL) Ecoute Base Patient Déclencheur écriture lecture Application de création des messages Hprim XML à envoyer écriture Message XML mail mise à jour SERVEUR STIC DU CLB MAL100 STI Traitement des messages de fusion à envoyer Le choix a été fait de ne pas traiter la défusion locale. On considère en effet que la défusion locale correspond à la création, puis l'inscription d'un nouveau patient au STIC Le Centre Léon Bérard dispose d un service qui permet de gérer la fusion de doublons locaux. Cette application a été modifiée pour générer automatiquement un message XML contenant l'ippl à conserver et l'ippl à supprimer. Ce message est déposé dans un répertoire "Fusion", que lit en permanence l'application de création des messages de fusion à envoyer au STIC. Ce dernier vérifie l'existence des deux IPPL : Si l'ippl à conserver et l'ippl à supprimer existent dans la table des IPPL envoyés à STIC (MAL100) On effectue une mise à jour de la table MAL100, et on crée un message XML de type msgevenementpatient avec action=fusion qui est déposé dans le répertoire "Ecoute" du serveur STIC du Centre Léon Bérard. Si l'ippl à conserver existe dans la table des IPPL envoyés à STIC (MAL100) et non l'ippl à supprimer L'IPPL à supprimer n'a jamais été envoyé au STIC. Pas de traitement Si l'ippl à conserver n'existe pas dans la table des IPPL envoyés à STIC (MAL100) et que l'ippl à supprimer existe On effectue une mise à jour de la table MAL100, et on crée un message XML de type msgevenementpatient avec action=fusion qui est déposé dans le répertoire "Ecoute" du serveur STIC du Centre Léon Bérard. Mise à jour de la table des IPPL envoyés à STIC (MAL100) : création ("010") pour l'ippl à conserver et fusion ("600") pour l'ippl à supprimer. Si ni l'ippl à conserver ni l'ippl à supprimer n'existent dans la table des IPPL envoyés à STIC (MAL100) Interface STIC-SIHv1.0.doc Page 21 sur 25

22 On effectue une mise à jour de la table MAL100, et on crée un message XML de type msgevenementpatient avec action=création qui est déposé dans le répertoire "Ecoute" du serveur STIC du Centre Léon Bérard. Dans tous les cas, si ACTIF ou ACCORD_PATIENT valent "Non", on effectue aucun traitement. Application de locale de fusion d'ippl écriture Messages XML lecture Application de création des messages de fusion à envoyer écriture Ecoute Message XML mise à jour SERVEUR STIC DU CLB MAL Traitement des messages reçus L'application de lecture des messages XML reçus parcours en permanence le répertoire "Réception" Pour chaque message lu, on détermine le type : Message de type msgretouridentifiantpatient - si statut = "OK" On effectue une mise à jour de la table des IPPL envoyés à STIC MAL100 - si statut = "Avertissement" On effectue une mise à jour de la table des IPPL envoyés à STIC MAL100 Envoi d'un mail "Avertissement lors d'une demande de création" - si statut = "Erreur" On effectue une mise à jour de la table des IPPL envoyés à STIC MAL100 Envoi d'un mail "Erreur lors d'une demande de création" Message de type msgretourmodificationpatient - si actionavertissement="modification" Cas entetemessageacquittement statut= "OK" On effectue une mise à jour de la table des IPPL envoyés à STIC MAL100 Cas entetemessageacquittement statut = "avertissement" ou "erreur" Envoi d'un mail d'avertissement ou d'erreur Interface STIC-SIHv1.0.doc Page 22 sur 25

23 Cas entetemessage On effectue une mise à jour de la table des IPPL reçus de STIC STI001 Envoi d'un mail "Changement d'identité du patient" - si actionavertissement="fusionlocale" Cas entetemessageacquittement statut= "OK" On effectue une mise à jour de la table des IPPL envoyés à STIC MAL100 Cas entetemessageacquittement statut = "avertissement" ou "erreur" Envoi d'un mail d'avertissement ou d'erreur pour une demande de fusion - si actionavertissement="fusioncentrale" ou "défusioncentrale" On effectue une mise à jour de la table des IPPL envoyés à STIC MAL100 et reçus par STIC STI001. Envoi d'un mail "Changement d'identité d'un patient" (ou "Suppression du patient" si l'entité "Alias" contient "OBSOLETE") - si actionavertissement="activation" ou "désactivation" On effectue une mise à jour de la table des IPPL envoyés à STIC MAL100 Reception MAL100 STI001 mise à jour Application de lecture des messages Hprim XML reçus lecture Message XML mail SERVEUR STIC DU CLB Interface STIC-SIHv1.0.doc Page 23 sur 25

24 7. Annexes 7.1. Table des erreurs retournées par STIC CENTRALE Ces erreurs, avertissement et informations sont dans les messages renvoyés par le S - STIC ET dans la base de données STIC MESSAGES ERREUR ERR000 Erreur inattendue : <description> ERR002 Enregistrement impossible : Le patient <IPPL> existe déjà dans le STIC. ERR004 Modification impossible : Le patient <IPPR> est désactivé Défusion locale impossible : défusion de <IPPL1> en <IPPL2> impossible car <IPPL2> ERR007 existe déjà dans le STIC L'IPPL fourni (<IPPL>) ne correspond pas à l'ippr fourni (<IPPR>) mais à l'ippr ERR009 suivant : <IPPR>. Votre base n'est pas à jour Enregistrement impossible : Le rapprochement automatique à fournit un IPPR <IPPR> ERR010 qui contient déjà un IPPL <IPPL> appartenant à votre SI. Les IPPL sont certainement doublons locaux (<IPPL1> et <IPPL2>) ou Homonymes parfaits INT003 SI inconnue (cette erreur n'est évidemment pas renvoyée au SI car il est inconnu) INT004 L'utilisateur associé au SI est erroné (Erreur de configuration de la table SI) Défusion locale impossible : défusion de <IPPL1> en <IPPL2> impossible car <IPPL1> ERR011 n'existe pas dans le STIC AVERTISSEMENT (suivi, après un délai d'attente éventuel, d'un message dont le statut est OK) AVT001 Avertissement : <description> AVT002 Demande de modification : aucune modification n'a été trouvée AVT003 Le patient <IPPR> est désactivé INF002 L'enregistrement du patient <IPPL> est en attente de traitement par la cellule qualité INF016 La demande de modification du patient <IPPL> a été transformée en demande de création INF017 La demande de modification du patient <IPPL> porte sur un patient temporaire. Une demande d'enregistrement est en cours? INFORMATION INF001 L'enregistrement du patient <IPPL> est terminé INF003 Modification du patient <IPPL> terminée INF004 Fusion locale de <IPPL1> sur <IPPL2> traitée INF005 Fusion locale de <IPPL1> sur le patient temporaire <IPPL2> traitée INF006 Fusion locale de <IPPL1> sur le patient non enregistré <IPPL2> traitée - La patient <IPPL2> est maintenant en cours d'enregistrement INF007 Défusion locale de <IPPL1> en <IPPL2> traitée. L'enregistrement du patient <IPPL2> terminé INF008 Défusion locale de <IPPL1> en <IPPL2> traitée. L'enregistrement du patient <IPPL2> est en attente de traitement par la cellule qualité INF013 Début de traitement d'un message. INF014 Fin de traitement d'un message. INF015 Demande d'information traitée Interface STIC-SIHv1.0.doc Page 24 sur 25

25 7.2. Notes d'usage de Hprim XML Champs facultatifs Lorsqu'une entité est facultative dans un message Hprim XML, et qu'elle na pas de valeur, l'entité ne doit pas être présente dans le schéma. Exemple : Si le numéro de téléphone du patient est fourni, on a : <telephones> <telephone> </telephone> </telephones> Lorsque le numéro de téléphone n'existe pas, les entités <telephone> et <telephones> n'existent pas dans le message. Cas particulier : code postal de naissance Le code postal de naissance n'est pas obligatoire dans le schéma Hprim XML. Cependant, il est nécessaire de le fournir dans le cadre de STIC. Il existe certains cas, cependant, où il est inconnu au sein d'un établissement (notamment dans le cas d'un patient né à l'étranger). Dans ce cas, on utilise la valeur "00000" Interface STIC-SIHv1.0.doc Page 25 sur 25