UREGRetour d’Expérience

Fabrice MARTINELLO Chef de Projets ICT

fabrice.martinello@chc.be

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

Contexte général (1/2)

5 Services d’Urgences Sur tous les sites sauf à la clinique Saint-Vincent Clinique de l’Espérance service scindé en 2

Urgences AdultesUrgences Pédiatriques

Chiffres ? Sur les 5 sites / an : environ 100.000 patients

Contexte général (2/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).

Contexte informatique (1/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.

Contexte informatique (2/2)

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).

Liste des développements informatiques effectués dans le cadre de notre projet UREG

• 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).

Changements au niveau Base de données (1/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.

Changements au niveau Base de données (2/2)

Omnipro – Nouvel événement des Urgences (1/3)

Volet administratif de l’admission

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

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

Création de 2 nouvelles définitions

• ‘CONFIG.UREG’ (configuration adresse IP du serveur RswConnect dans le réseau du CHC).

Autres Développements et Paramétrages au niveau d’Omnipro (1/5)

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

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.

Autres Développements et Paramétrages au niveau d’Omnipro (2/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.

Autres Développement et Paramétrages au niveau d’Omnipro (3/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.

Autres Développement et Paramétrages au niveau d’Omnipro (4/5)

• 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)

WebService et Serveur (1/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.

WebService et Serveur (2/2)

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.

Difficultés rencontrées

D’un point de vue informatique, le projet UREG n’a pas été trop difficile à mettre en place au 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.

Conclusions

FIN

Merci pour votre attention …