UREG

1. UREG Retour d’Expérience Fabrice MARTINELLO Chef de Projets ICT fabrice.martinello@chc.be

2. Contexte général (1/2) • Le CHC regroupe 6 cliniques • Clinique Saint-Joseph à Liège • Clinique de l’Espérance à Montégnée • Clinique Notre-Dame à Waremme • Clinique Notre-Dame à Hermalle sur Argenteau • Clinique Saint-Vincent à Rocourt • Clinique Sainte-Elisabeth à Heusy

3. Contexte général (2/2) • 5 Services d’Urgences • Sur tous les sites sauf à la clinique Saint-Vincent • Clinique de l’Espérance  service scindé en 2 • Urgences Adultes • Urgences Pédiatriques • Chiffres ? • Sur les 5 sites / an : environ 100.000 patients

4. Contexte informatique (1/2) • Utilisation d’Omnipro (v4.5.1.h) de la société Mims (dossier médical informatisé, dossier infirmier informatisé, gestion des lits, agenda, salle d’attente, etc …) • Utilisation d’Omnipro pour l’événement des urgences (fenêtre et paramétrages effectués en interne par le service informatique du CHC).

5. Contexte informatique (2/2) • Dans le cadre du projet UREG notre événement des Urgences devait être modifié pour ajouter les champs manquants demandés par le SPF. • On a décidé de faire un nouvel événement des Urgences car pour diverses raisons l’ancien événement des urgences ne correspondait plus aux attentes des Urgentistes.

6. Liste des développements informatiques effectués dans le cadre de notre projet UREG • Création de 2 nouvelles tables dans la base de données. • Développements et paramétrages au niveau d’Omnipro. • Développement d’un Web Service et installation d’un nouveau serveur virtuel (RswConnect).

7. Changements au niveau Base de données (1/2) • Création de la table DATA_TOEXPORT • Cette table sert a sauvegarder la liste des événements des Urgences qui doivent faire l’objet d’un envoi vers le SPF via un Web Service. Cette table est alimentée par un script Omnipro. La colonne ‘Status’ est mise à jour par le Web Service en fonction du résultat de l’envoi vers le SPF (OK / ERREUR).

8. Changements au niveau Base de données (2/2) • Création de la table DATA_TOEXPORT_ERROR • Cette table sert a ‘logger’ les erreurs rencontrées par le Web Service lorsque ce dernier essaie de faire les envois vers le SPF.

9. Omnipro – Nouvel événement des Urgences (1/3) Volet administratif de l’admission

10. Omnipro – Nouvel événement des Urgences (2/3) Volet administratif de sortie

11. Omnipro – Nouvel événement des Urgences (3/3) Résumé HRM

12. Autres Développements et Paramétrages au niveau d’Omnipro (1/5) • Création de 2 nouvelles définitions • ‘CONFIG.UREG’ (configuration adresse IP du serveur RswConnect dans le réseau du CHC).

13. Autres Développements et Paramétrages au niveau d’Omnipro (2/5) • Une définition ‘UREG.ADMMED8’ qui reprend les différentes variables UREG à envoyer

14. Autres Développements et Paramétrages au niveau d’Omnipro (2/5) • Modification d’un script Omnipro • Ajouter au script existant pour le RHM la partie liée à l’envoi UREG. • Script qui se déclenche à chaque fois que l’on sort de l’événement des urgences.

15. Autres Développement et Paramétrages au niveau d’Omnipro (3/5) • Que fait le script spécifiquement pour UREG ? • Récupère les informations encodées dans l’événement des urgences. • Insert une nouvelle ligne dans la table OBJ_DATA de type ‘UREG’ en sauvegardant l’ID de l’événement des urgences correspondant (Table OBJETS). • Insert une nouvelle ligne dans la table OBJ_DATA_CONTENU avec les infos récupérées de l’événement et formatée suivant le questionnaire ADMMED8.

16. Autres Développement et Paramétrages au niveau d’Omnipro (4/5) • La script fait aussi … • Lorsque l’on sort pour la première fois de l’événement des urgences: • Insert une nouvelle ligne dans la nouvelle table DATA_TOEXPORT (crée spécifiquement pour UREG) avec une colonne reprenant l’ID correspondant de la ligne crée dans OBJ_DATA et une colonne ‘STATUS’ égal à 0. • Lorsque l’on sort les fois suivantes de l’événement des urgences: • Fait une mise à jour de la colonne ‘STATUS’ ( 0) de la ligne insérée lors de la première sortie de l’événement en fonction du numéro d’objet (événement) récupéré de la table OBJ_DATA.

17. WebService et Serveur (1/2) • Installation d’un nouveau serveur virtuel pour pouvoir déployer le service RswConnect et installation du certificat eHealth. • Développement du Web Service ‘RSW-WS-EHEALTH’ (effectué par Mims). • Installation du WebService ‘RSW-WS-EHEALTH’ sur un Tomcat (le même Tomcat ou les autres Web Services Mims sont déjà déployés (ex: ceux liés au RSW) (effectué par MIMS)

18. WebService et Serveur (2/2) • Que fait ce Web Service ? • Il lit constamment la table DATA_TOEXPORT et vérifie s’il existe des lignes avec une colonne ‘Status’ égal à 0. • Si c’est le cas, il récupère dans la table OBJ_DATA_CONTENU les données UREG enregistrées par le script Omnipro à la sortie de l’événement. • Le Web Service formate le message à envoyer. • Le Web Service envoie le message à travers RswConnect. • Le Web Service fait la mise à jour de la colonne ‘Status’ de la table DATA_TOEXPORT pour l’objet en question. • Le Web Service insert les erreurs éventuelles dans la table DATA_TOEXPORT_ERROR.

19. Difficultés rencontrées • La demande d’un nouveau certificat auprès de eHeath pour notre projet UREG a pris beaucoup plus de temps que prévu et cela a occasionné du retard dans notre planning. • L’utilisation de l’ICD9 pour le champs Diagnostic est remis en question par nos Urgentistes. Certains termes courant qu’ils utilisent ne se retrouvent pas dans l’ICD9  Décision a été prise de passer au glossaire Français SFMU qui répond plus aux attentes de nos Urgentistes.

20. Conclusions • D’un point de vue informatique, le projet UREG n’a pas été trop difficile à mettre en placeau CHC ; malgré certaines petites difficultés liées au fait que nous étions pilotes pour ce projet. • En ce qui concerne spécifiquement l’envoi des données UREG vers le SPF, c’est totalement transparent pour l’utilisateur; ce qui est apprécié par ces derniers.

21. FIN Merci pour votre attention …