Contexte
Le client :
Centre Hospitalier
La demande :
Un établissement hospitalier souhaite numériser le processus de saisie et d’envoi des courriers de consultations tout en respectant un workflow précis d’échanges entre secrétaires et médecins.
Notre intervention
Résultats : Le développement s’intègre dans le portail déjà existant via l’utilisation d’une servlet principale. Selon la personne identifiée (secrétaire ou médecin), on va afficher du contenu différent via des requête à l’EJB.
Chaque action sur une dictée donne lieu à un enregistrement dans une table Oracle. Cela permet d’effectuer du traçage et de mettre en place des verrous pour éviter notamment que les secrétaires modifient trop rapidement une dictée appartenant à une collègue.
Chaque édition/correction de dictée donne lieu à une sauvegarde automatisée via une requête AJAX.
Côté médecin, à chaque connexion au portail, une première requête Ajax est réalisée pour connaître le nombre de courriers à valider. Le médecin a la possibilité de visualiser en PDF les différents courriers saisis par la secrétaire. Le PDF est généré à la volée via la librairie iText (via une servlet).
La correction d’une dictée peut se faire de différentes façons. La plus intéressante pour les médecins est le clic PDF. En cliquant sur une phrase du PDF, une page d’édition s’ouvre contenant le texte complet de la dictée et le paragraphe sur lequel il a cliqué est automatiquement surligné en jaune. Cela lui permet de corriger à la volée son document. Le PDF est automatiquement regénéré avec les modifications et celles-ci sont sauvegardées dans la BDD.
Il a également la possiblité de renvoyer la dictée vers la secrétaire pour une correction majeure en dictant un commentaire lié à la dictée.
La validation de la dictée (et donc du courrier) est un processus très verrouillé. Il existe deux niveaux de verrouillage, le niveau 1 a lieu au clic de “validation” et le courrier passe au niveau 2 lorsque tous les flux de sortie ont été correctement générés. Chaque flux de sortie peut générer une ou plusieurs exceptions. Toutes les actions des flux de sortie sont logguées et si une exception est détectée, la dictée reste verrouillée à l’état 1 permettant ainsi au support informatique d’effectuer des tests pour trouver la source du problème.
Chaque flux de sortie est indépendant et peut donc être ré-généré s’il y a eu un problème.
L’utilisation du système EJB/Pojo/Facade/delegate permet de requêter la base via des méthodes spécifiques. On peut facilement changer de fournisseur de données tant que celui-ci implémente les mêmes méthodes que les autres fournisseurs (facilement réalisable via une interface). L’utilisation des POJO en tant que copie plus ou moins complexe des classes métiers permet également de laisser le coeur du système gérer l’accès à la base. En effet côté interface, on ne manipule que ces POJO pour gérer l’affichage ou la modification de données. Dans ce cas de figure, les POJOs sont remontées au coeur du système qui copiera alors les données dans les classes métiers et au besoin changera les données dans la base.
Pour plus d’informations sur nos services et nos expertises, n’hésitez pas à nous contacter !