130 likes | 201 Vues
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
E N D
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
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