Introduction
Terminal Urgences (ou toute appli basée sur le framework gts) est un applicatif web qui, une fois en production, ne se gêre plus que via son interface web.
Les seuls services éventuels à relancer en cas de problème système sont: apache et mysql (et selon votre configuration hl7d et/ou proftpd).
Il convient également de vérifier qu’une crontab est bien en place et exécute toutes les minutes le script « crontab.sh » à la racine de TU.
Les différentes taches exécutées à intervalles régulier par TU ( intégration, sorties de patient, exports des données RPU.. ) sont gêrées par un moteur de planification de taches interne à TU. (dans l’applicatif: gestion -> taches planifiées )
Le serveur du terminal ne répond plus, que faire ?
Lorsque vous désirez accéder au terminal (depuis votre navigateur), une erreur est affichée. En fonction de l’erreur, il y a plusieurs possibilités :
- Si vous n’avez aucune réponse du serveur, il est possible que le serveur apache ne soit plus en fonctionnement. Vous devez donc vous connecter en SSH pour le relancer avec (habituellement) la commande suivante :
- /etc/init.d/apache2 restart
- Dans le cas précédent, la connexion SSH est peut-être impossible également, il vous faudra donc vérifier que le serveur est toujours en état de marche (connexion en local par exemple). Si ce n’est pas le cas, vous devrez soit l’allumer soit forcer un redémarrage (dans le cas extrème où votre distribution linux serait plantée…).
- Si le serveur web semble bien répondre mais que certains éléments sont absents (menu ou carrément une page blanche signalant qu’une erreur est survenue), il est possible que le serveur MySQL ne soit plus en étant de marche et dans ce cas, vous devrez le relancer avec (habituellement) la commande suivante :
- /etc/init.d/mysql restart
Ces problèmes systèmes sont très rares et ne peuvent être couverts de façon exhaustive par une documentation. Dans certains cas, les commandes données plus haut ne seront pas suffisantes pour résoudre le problème (espace disque saturé, table mysql corrompue…) et il faudra dans ce cas faire appel à vos connaissances d’administration linux ou faire appel à notre support.
Les identités ne sont plus intégrées automatiquement, que faire ?
Généralités
Vous pouvez déjà vérifier dans l’interface du terminal que les messages sont toujours intégrés en allant dans « Gestion » -> « Rechercher messages ». Les horaires de traitements des messages et d’éventuels messages d’erreurs pourront vous aiguiller pour comprendre pourquoi les nouveaux patients n’apparaissent plus dans le terminal.
Si aucun message n’est traité depuis un certain temps, vous pouvez également vérifier que les exécutions de la tâche planifiée sont toujours actives en allant dans « Gestion » -> « Tâches planifiées » et en regardant plus précisément celle se nommant « Importation des fichiers HL7 et Hprim 2.1 » en cliquant sur le lien « Logs ». Si aucune exécution n’a eu lieu depuis plusieurs minutes, il y a effectivement un problème : le service « cron » est-il toujours fonctionnel sur le serveur ? Si ce n’est pas le cas, un redémarrage du serveur pourrait résoudre le problème.
Il se peut également qu’il y ait un problème applicatif au niveau de l’intégration des messages HL7. Pour vérifier ce point, il vous suffit d’effectuer les actions suivantes :
- connexion en SSH sur le serveur
- cd /var/www/var/log/
- tail -f php.log
- exécution manuelle de la tâche planifiée en erreur
- s’il y a une erreur « applicative », elle devrait apparaître dans la console
- NOTE : pensez à ce moment à vérifier la présence d’une mise à jour en exécutant index.test.php dans votre navigateur, le problème est peut-être déjà résolu. Si ce n’est pas le cas, vous devez faire appel à votre support.
Sinon, si le traitement est toujours actif, il y a peut-être un problème sur le dépôts des fichiers. En allant dans « var/importation/ », vous pouvez vérifier si des fichiers sont bien déposés (et à quelle date les derniers ont été traités dans « var/importation/ok »). Si vous constatez que les fichiers déposés sont tous vides, il y a certainement un problème d’espace disque (à vérifier avec la commande « df »).
Si aucun fichier n’a été déposé depuis trop longtemps (ce temps est à déterminer en fonction du dernier patient admis aux urgences par exemple), il y a deux possibilités : soit le connecteur (ftp ou socket) côté terminal est en panne, soit les messages en provenance du logiciel d’admission n’arrivent plus.
Cas d’un flux déposé par FTP
Le serveur FTP ne répond peut-être plus (vous pouvez vérifier en essayant de vous connecter sur le port 21). Si c’est le cas, vous devez le relancer via (habituellement) la commande suivante :
/etc/init.d/proftpd restart
Si le serveur FTP répond toujours, il faudrait vérifier du côté de votre logiciel qui gère les admissions afin d’être certain que les messages sont bien envoyés vers le terminal.
Cas d’un flux « socket »
Le serveur HL7d ne répond peut-être plus (vous pouvez vérifier en essayant de vous connecter sur le port 21110). Si c’est le cas, vous devez le relancer via la commande suivante :
/etc/init.d/hl7d restart
Si le serveur HL7 répond toujours, il faudrait vérifier du côté de votre logiciel qui gère les admissions afin d’être certain que les messages sont bien envoyés vers le terminal.
Pour vous aider dans la résolution du problème, vous avez également la possibilité de consulter les logs du connecteur hl7 en direct avec la commande suivante :
tail -f /usr/local/hl7d/var/log/hl7d.log
Effet d’une partition remplie à 100%
Différents effets sont visibles lorsqu’une partition atteint 100% dans le terminal :
- les fichiers du flux d’admission déposés dans le répertoire var/importation sont tous vides. Après avoir libéré de l’espace disque, il faudra rejouer les messages manquants depuis votre EAI (ou depuis votre logiciel qui gère les admissions).
- le serveur MySQL ne répond plus (ou mal) et ne peut plus démarrer. Après avoir libéré de l’espace disque et une fois le serveur MySQL redémarré, vous devrez vous assurer que les tables ne sont pas corrompues (un outil comme phpMyAdmin, généralement installé avec le terminal, vous permettra de le voir).
Les messages de mouvements générés par le terminal ne sont plus envoyés, que faire ?
- Vous pouvez vérifier que la sémaphore ne soit pas bloquée en vous connectant en administrateur (dans l’environnement Administration, petite clé en haut à gauche de l’application) puis en allant dans « Gestion -> Taches planifiées ». Si la sémaphore est bloquée, vous pouvez déjà tenter une exécution manuelle (si ça échoue et que l’erreur n’est pas parlante, il peut s’agit d’un bug applicatif et vous devrez faire appel à la hotline du terminal). Une fois l’exécution manuel réussie, vous pouvez cliquer sur « Débloquer la sémaphore » pour que le flux reparte à nouveau.
- S’il n’y a pas de blocage côté terminal, vous pouvez vérifier également que le destinataire des flux (généralement un EAI) n’a pas de soucis. Pour ça, il vous suffit de faire un telnet sur le port concerné, exemple :
telnet eai.votrech.fr 21105
- A noter que vous pouvez également vérifier que la configuration des envois HL7 est toujours correcte en allant dans « Gestion -> Configuration destinataires » (vous devez être connecté dans l’environnement « Administration » pour ça).
L’historique de passage ne s’affiche plus
Pour certains établissements, l’historique de passage est affiché depuis une base externe (voir ici pour la configuration :https://code.google.com/p/gteserv/wiki/HistoriquesExternes). Si cette base de données ne répond plus cela peut ralentir fortement l’utilisation de TU lors de la consultation d’une fiche patient.
Il suffit alors de vérifier la connexion à cette base en suivant ces étapes :
Pour Oracle :
- lancer le script /home/oracle/bin/sqlplusO
- renseigner les paramètres de connexion comme indiqués dans le fichier var/define.xml.php du terminal urgences