Remontées des RPU Max Bensadon - ATIH.

Présentation au sujet: "Remontées des RPU Max Bensadon - ATIH."— Transcription de la présentation:

1 Remontées des RPU Max Bensadon - ATIH

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

3 Circuit actuel

4 Cible

5 Solutions proposées Régions déjà en schéma cible Régions sans serveur
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

6 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

7 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é

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

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

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

11 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

12 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

13 Habilitations National : Lecteur Régional : Etablissement : Lecteur
Gestionnaire de fichier Etablissement : Lecteur