Remontées des RPU

Max Bensadon - ATIH

Enjeu

• Mettre en place un deuxième circuit de remontée des RPUs sans détériorer l’existant

Circuit actuel

Cible

Solutions proposées• Régions déjà en schéma cible

– ORUsa avec serveur déjà opérationnel et opérant sur l’ensemble des établissements de la région transmettant déjà à l’INVS

=> Mettre en place la connexion avec l’ATIH

• Régions sans serveur– Avec ou sans ORUsa mais établissements transmettent à l’INVS

Mettre en place l’organisation du projet Proposition transitoire faite par la FEDORU intégrant la possibilité de

connexion avec l’ATIH Demande aux établissements transmettant à l’INVS de dupliquer le

flux vers la solution transitoire

• Régions avec serveur mais tous les établissements non connectés– Toutes les autres situations (avec ORUsa) en général le

processus de généralisation est en cours. Mettre en place la connexion avec l’ATIH

Plateforme Syrius• Réception des fichiers en provenance des

serveurs régionaux

• Transmis de manière automatique

• Tous les mois

• Contenant l’ensemble des RPUs produits entre le 1er janvier et la fin du mois par établissement

• Le 15 du mois suivant

• RPU anonymisés

Transmission par établissement• Seuls les serveurs régionaux sont autorisés à transmettre les

fichiers• Le format est quasiment le même que celui utilisé par l’INVS

dans le cadre du réseau OSCOUR.• Les fichiers ne doivent pas être modifié par les contrôles

qualités des ORUs.• Le serveur régional transmet les fichiers des établissements

accompagné de variables permettant de valider le fichier (ex: nb de RPU).

• Le système accuse réception du fichier et transmet le résultat de validation.

• En cas de problème une retransmission est à prévoir par le serveur régional

• Sinon le fichier est réputé validé

Fichiers cumulatifs

• Intérêt : – Autocorrectif: chaque mois les données

antérieures sont transmises et donc les corrections sont automatiquement intégrées.

– Pour le mois 12, prévision d’une transmission sur une période plus longue (par exemple jusqu’à fin Avril n+1).

Anonymisation

• Suppression du nom de la commune de résidence ;

• Code postal remplacé par un code géographique de résidence (dans les conditions habituelles du PMSI) ;

• Date de naissance remplacée par l'âge exprimé en années et calculé à la date de passage aux urgences.

Contrôle qualité

• Ils sont variables d’une région à une autre• Dépendent de l’utilisation qui va être fait des

données.• Conséquences variables :

– Retour vers l’établissement pour correction– Suppression du séjour

• Décision de ne pas intégrer les contrôles de manière avoir des données homogènes.

• Signifie l’intégration de contrôle dans la chaîne de traitement nationale (Syrius)

Accès aux données• Nécessite une habilitation dans le domaine

Syrius• Chaque fichier transmis fait l’objet d’un

traitement• Elaboration d’un certain nombre de

tableaux (comme ePMSI)– Exhaustivité et contrôle des données– Fréquence observée des variables– Indicateurs …

• Elaboration d’une base nationale de RPUs

Gestion des utilisateurs

• Utilisation de la plateforme PLAGE pour la gestion des utilisateurs.

• Ils existent aux 3 niveaux définis par le modèle :– National – Régional– Etablissement

• Notion de domaine : applications (ePMSI par ex.)• Notion de rôles : habilitation dans les applications• Création des utilisateurs et attribution des rôles se fait par le

biais d’utilisateurs ayant le rôle d’administrateur dans le niveau– National : ATIH– Régional : ARS– Etablissement

Habilitations

• National : Lecteur

• Régional : – Lecteur– Gestionnaire de fichier

• Etablissement : Lecteur