Malgré les explications données dans la documentation et sur ce forum, je ne suis pas certain d’avoir bien compris quelles préconisations suivre concernant les bénéficiaires BEN_IDT_ANO partageant un même BEN_NIR_PSA avec d’autres bénéficiaires BEN_IDT_ANO. Je crois comprendre qu’il soit indispensable de les exclure systématiquement dès lors qu’on exploite à la fois des données DCIR et PMSI, afin de ne garder que les bénéficiaires BEN_IDT_ANO pour qui on sache sans ambiguïté à qui rattacher le NIR_ANO_17 de chaque séjour.
Ce problème est nouveau pour moi car jusqu’il y a peu je ne travaillais que sur des extractions sur projets réalisées par la DEMEX. Cela ne fait que quelque mois que j’exploite les données via l’accès permanent CHU.
Sauf que je constate qu’on perd de l’ordre de 10% de la population en procédant ainsi, avec une sur-représentation chez ces exclusions des femmes et des bénéficiaires nés dans la première moitié des années 1990. S’agirait-il des jeunes adultes commençant à s’assurer eux même et d’épouses devenues leur propre ouvreuse de droit avec PUMA ?
En procédant à un appariement probabiliste sur le sexe, l’année de naissance et le département de résidence au sein des BEN_IDT_ANO d’un même NIR_ANO_17, je ne récupère qu’un nombre très négligeable d’exclus.
Le rang de naissance non plus, par manque de fiabilité dans le PMSI. Dans un autre projet, j’avais constaté plus de discordance que de concordance entre PMSI et DCIR sur la commune de résidence (même en utilisant rfcommun.T_FIN_GEO_LOC_FRANCE), donc la commune de résidence ne peut pas servir à améliorer l’appariement probabiliste.
Me confirmez-vous, malgré le biais induis, que les bonnes pratiques préconisées soient d’exclure les environ 10% de BEN_IDT_ANO qui partagent un ou des BEN_NIR_PSA avec d’autres bénéficiaires BEN_IDT_ANO ?
L’identifiant SNDS, appelé pseudo-NIR, est composé de 3 éléments : NIR de l’assuré ouvreur de droit + date de naissance du bénéficiaire + code sexe du bénéficiaire. Il est crypté avant d’être restitué dans les bases du SNDS à travers les variables BEN_NIR_PSA (dans le DCIR) et NIR_ANO_17 (dans le PMSI). Dans le cadre des demandes d’extractions des données du SNDS (accès sur projet), cette variable est également cryptée et restituée aux utilisateurs dans la variable NUM_ENQ.
Le NIR est également disponible de manière pseudonymisée dans le référentiel des bénéficiaires sous la variable BEN_NIR_ANO. Celui-ci ne dépend pas de l’ouvreur de droit, mais uniquement de l’individu. Il est unique pour un individu durant toute sa vie. Cette variable est également cryptée et restituée aux utilisateurs dans la variable NUM_ENQ_ANO
Depuis 2016, la variable BEN_IDT_ANO (NUM_ENQ_IDT) alimente également la table référentielle IR_BEN_R. Elle prend la valeur de la variable BEN_NIR_ANO lorsque celle-ci existe, et celle de la concaténation de la variable BEN_NIR_PSA et BEN_RNG_GEM (rang gémellaire) sinon.
Du fait de cette construction, comme vous le soulevez, un même NIR_ANO_17 (ou un même BEN_NIR_PSA) peut correspondre à plusieurs BEN_IDT_ANO, par exemple dans les cas suivants :
Lorsque BEN_NIR_ANO n’est pas remontée pour un patient (et donc BEN_IDT_ANO = BEN_NIR_PSA + BEN_RNG_GEM) et que le rang gémellaire change à cause d’un changement de régime. En effet, dans le régime général (y compris SLM), ce rang gémellaire permet de distinguer les naissances gémellaires de même sexe ; alors que les autres régimes, comme la MSA, ne gèrent pas le rang gémellaire, mais un rang de bénéficiaire (déterminé lors de l’ouverture des droits et correspondant donc à un numéro d’ordre au sein d’une même famille) ;
Lorsque plusieurs lignes sont renseignées dans IR_BEN_R pour un même couple BEN_NIR_PSA/BEN_RNG_GEM, le BEN_NIR_ANO étant parfois renseigné et d’autres fois non (se référer au max de la date de mise à jour dans ce cas : BEN_DTE_MAJ).
Avant d’exclure les BEN_IDT_ANO qui partagent un même BEN_NIR_PSA, des actions peuvent être mises en place pour repérer et conserver les BEN_IDT_ANO correspondant à un même patient. Il est possible de créer une variable concaténant BEN_NIR_PSA (ou NUM_ENQ en identifiant cryptée) et rang gémellaire BEN_RNG_GEM, que l’on trouve dans la table IR_BEN_R et IR_BEN_ARC. Pour cela, il suffit de joindre les données du DCIR (table PRS) et les données du référentiel des bénéficiaires (table IR_BEN_R et IR_BEN_R_ARC) à partir de cette variable concaténée, et on conserve aussi le Numéro d’Inscription au Répertoire du bénéficiaire BEN_NIR_ANO (ou NUM_ENQ ANO en identifiant crypté).
On peut alors obtenir une description de toutes les combinaisons possibles d’identifiants, et des règles peuvent être définies au cas par cas selon les combinaisons observées. Le point important est d’avoir suffisamment confiance au choix retenu pour qu’il corresponde à un unique bénéficiaire.
Par exemple, il peut être décidé de conserver des patients qui ont un BEN_NIR_PSA/ NUM_ENQ différents mais le même BEN_NIR_ANO/NUM_ENQ_ANO, et des BEN_NIR_PSA/NUM_ENQ+BEN_RNG_GEM différents :
BEN_NIR_PSA/NUM_ENQ
BEN_NIR_ANO/NUM_ENQ_ANO
BEN_NIR_PSA/NUM_ENQ+ BEN_RNG_GEM
BEN_IDT_ANO
XXX-1000152915
XXX-ANO1000000006
XXX-10001529151
XXX-ANO1000000006
XXX-1000397380
XXX-ANO1000000006
XXX-10003973801
XXX-ANO1000000006
Bien cordialement,
L’équipe du Health Data Hub
Cette réponse a été rédigée en collaboration avec la société HORIANA.