Application de rédaction des courriers médicaux

Développement d’une plateforme visant à dématérialiser les processus de création, d’échange et d’envoi des courriers médicaux d’un établissement hospitalier dans le cadre d’un système d’information en mode WEB.

Contexte : 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étaire et médecins.

A travers le portail le médecin peut visualiser la liste de ses consultations et créer des dictées numériques via Winscribe.
Une fois la dictée enregistrée, un pool de secrétaires se partage la rédaction des dictées grâce à une interface de saisie en mode web. La rédaction comprend la gestion du contenu, des pièces jointes en GED, des fichiers et des PJ physique. La gestion des destinataires internes et externes est également disponible
Une fois le courrier rédigé, la secrétaire demande la validation au médecin. Le courrier est disponible en visualisation PDF par le médecin au travers du portail. Il peut alors valider ou demander des corrections, il peut également corriger à la volée ses propres courriers.
Une fois le courrier validé, un processus d’envoi est lancé. Pour les destinataires internes, les PDF sont stockés sur le réseau pour le vaguemestre.

Pour les destinataires externes, le choix d’un prestataire doit être fait pour Septembre

Technologies utilisées : J2EE, JSP, JPA, Servlets, EJB, Pojo, Javascript/Ajax, Oracle, Design Patterns MVC, Singleton, Delegate, Facade, librairie PDF iText

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 à 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 modifs 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ée. 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 complexes des classés 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 s’y besoin changera les données dans la base.

Pour plus d’informations sur nos services et nos expertises, n’hésitez pas à nous contacter !

 

<<< Article précédent / Article suivant >>>
Separateur
© 2010 VersusMind, expertise & architecture numérique
VersusMind Tel : +33 (0)3 83 27 22 03 - Fax : +33 (0)9 55 17 39 15 - courriel : info@versusmind.eu
Les produits, logos et marques cités appartiennent à leurs propriétaires respectifs.