Numéro d'assuré AVS13 comme identificateur de personnes

Transcription

1 Patrick Kummer, Jérôme Magnin, août 2008 Numéro d'assuré AVS13 comme identificateur de personnes 1 e attribution du NAVS13 Description du processus et des tests

2 Données concernant ce document Nom du projet: Numéro d assuré AVS Code PPA: Nom du document: 1 e attribution du NAVS13, description du processus et des tests Auteur: Date: P. Kummer, J. Magnin Phase du projet: Conception détaillée Enregistrement électronique: N de reg.: Y:\_A_Projekte\Projekt_PURE\45-06_Versichertennummer\4_Konzepte\03_ConceptionDetail\RapportTests1eAttibution.doc Version: Date: But: Début, Kummer Input, Magnin / CdC Input, Ghisio / CdC Dernières adaptations, Kummer Version publiée Destinataires: Les membres du comité de coordination du projet (CC) Les services cantonaux compétents de l harmonisation des registres (Art. 9 LHR) Les membres du team projet OFS «Numéro d assuré AVS» Les membres du projet CdC «BlastIN» Les membres du projet CdC «UPI09» Les membres du projet CdC «COMIN» 2/27

3 1 Préambule 5 2 Introduction 5 3 Objectif du document 5 4 Processus de 1 e attribution La vue d ensemble Le processus général Le planning de la 1 e attribution L exportation de données La conversion La livraison des données L assurance qualité Le monitoring Le rappel Le traitement des données Le retour de données L importation des données Le service clearing La deuxième itération Le contrôle final de l attribution La description des tests Objectifs des tests Planification des tests Description des tests Le niveau T1 (Divers outils de soutien) Le niveau T2 (Livraison à l OFS) Le niveau T3 (Tests de 1 e attribution) Le niveau T4 (Tests des procédures du Service Clearing) Le niveau T5 (Tests de la mise à jour continuelle (uniquement UPI)) Conclusion des tests /27

4 Glossaire : Notion Signification NAVS11 Numéro AVS significatif à 11 positions, actuellement utilisé (1971 à 2008) NAVS13 OFS RF RdH Infostar CA CM Ordipro RF UPI VERA CdC SYMIC Nouveau Numéro AVS anonyme à 13 positions (à partir de 2008). Désigné en partie avec les raccourcis suivants : NNSS, NN, VN, NIP Office fédéral de la statistique Registre fédéral (p.ex. Infostar, SYMIC) Registre des habitants (Informatisiertes Standesregister) Registre d état civil du département fédéral de justice et police Caisses de compensation AVS/AI Caisses maladie Système d'information du département fédéral des affaires étrangères qui traite les données du personnel diplomatique et des représentations consulaires en Suisse (et autres). Cf. Ordonnance relative au système d information Ordipro du Département fédéral des affaires étrangères, RS Registre fédéral (ex. InfoStar, SYMIC) Universal Personal Identification Database. Registre national de référence pour le NAVS13, géré par la CdC Système d'information pour l'administration des Suisses de l'étranger (VERA) du département des affaires étrangères. Cf. Ordonnance relative à l administration en réseau des Suisses de l étranger, RS Centrale de compensation AVS/AI, qui dispose du monopole pour l'attribution et l'administration du NAVS13 Système d'information central sur la migration (SYMIC). Système d'information de l'office fédéral des migrations (ODM). Cf. Ordonnance du 12 avril 2006 sur le système d information central sur la migration RS /27

5 1 Préambule Ce document est une publication conjointe de l Office fédéral de la statistique (OFS) et de la Centrale de compensation (CdC). Les auteurs y décrivent de manière indépendante de leur organisation la phase du projet 1 e attribution du NAVS13. Les rôles respectifs de l OFS et de la CdC sont : - responsables de la coordination et du rassemblement des données ; - responsables de l attribution cohérente du NAVS13. 2 Introduction L OFS et la CdC ont élaboré conjointement la procédure de 1 e attribution aux registres des habitants, aux registres de personnes de la Confédération selon la LHR et aux registres des caisses maladie selon l OCA. La procédure établie prévoit un traitement global et simultané de tous les registres concernés, afin d optimiser la procédure et de maximiser le niveau de fiabilité de l attribution d un NAVS13 à une personne. Les délais auxquels cette procédure doit se conformer imposent de fortes contraintes sur la «qualité» des données fournies par les acteurs. Par «qualité», on entend d une part la qualité de gestion des attributs d identification des personnes, mais également l adéquation entre la population attendue et celle transmise par les registres impliqués. Certaines plausibilités sont établies et vérifiées afin d obtenir une attribution cohérente du NAVS13 à une personne. Une des plausibilités est que toute personne qui réside en Suisse dispose d une couverture d assurance maladie, ce qui signifie que toutes les personnes livrées par les registres des habitants vont se retrouver dans les données fournies par les caisses maladie. Ce recouvrement attendu entre les données des registres des habitants et celles des caisses maladie illustre l importance primordiale de disposer, en janvier 2009, de l ensemble des données de tous les partenaires, et cela dans un format défini. Afin d optimiser le processus de traitement, il est également prévu de grouper par lots cantonaux la livraison des données des registres des habitants et des caisses maladie. Dans le but de pouvoir assurer la procédure de 1 e attribution au mois de janvier 2009, l OFS et la CdC souhaitent faire un exercice de 1 e attribution sous la forme de grande répétition générale en automne Tous les acteurs impliqués sont conviés à participer à ces tests de 1 e attribution. Ce document décrit dans le détail le processus de 1 e attribution ainsi que les éléments qui seront testés. Il existe différents niveaux de tests qui sont mis à disposition et décrits ci-après. Leur mise à disposition se fera en relation avec l avancement des travaux. 3 Objectif du document Ce document sert de base à l élaboration et à la mise en œuvre des activités liées à la 1 e attribution et aux tests y relatifs. Il décrit de manière thématique, et non technique, les différentes étapes de cette phase du projet 1 e attribution. Ce document est destiné aux personnes directement impliquées dans le projet et va servir de référence pour cette phase. Pour mémoire, les trois grandes phases du projet sont : Projet NAVS13 Management de projet 1 La phase préparatoire La conception (générale et détaillée) 2 La phase de 1 e attribution La construction (réalisation 1) 3 La phase de mise à jour continuelle L exploitation (réalisation 2) 5/27

6 Pour les phases, il sera établi 3 types de documents : A Technique B Thématique C Générale Spécifications pour les fournisseurs Description de la phase Guidelines de logiciel En résumé les documents : Projet NAVS13 A Technique B Thématique C Générale 1 La phase préparatoire - Rapports Conception + Tests2007 Guidelines Phase préparatoire 2 La phase de 1 e attribution Spécifications Ce document Fin août e attribution 3 La phase de mise à jour continuelle Spécifications UPI + RFtoRdH Novembre 2008 Novembre 2008 Les documents déjà établis sont disponibles sur Internet sous : Parallèlement à ces documents, il existe encore d autres documents publiés sous la forme de recommandations, d exemples et d outils disponibles sur les sites internet de la CdC ou de l OFS. 6/27

7 4 Processus de 1 e attribution 4.1 La vue d ensemble Pour attribuer le nouveau numéro d'assuré (NAVS13) aux personnes enregistrées dans les différents registres des personnes (CdC, RF, CM, RdH), il est prévu que les registres des personnes exportent de leurs systèmes, du 15 au 30 janvier 2009 et conformément aux directives, l ensemble de leur population à numéroter. Les données exportées seront ensuite transmises par un canal prévu à cet effet à la CdC. Les données livrées sont traitées par la CdC, permettant ainsi la première attribution du NAVS13. Le résultat du processus est un jeu de données retournées par la CdC aux systèmes livrants. Ces derniers importent les données dans leur base en stockant correctement le NAVS13 assigné, conjointement avec les éventuelles corrections proposées. CdC RF CM RdH CdC RF CM RdH Export UPI Import Matching Clearing 4.2 Le processus général Le schéma ci-dessous présente le processus de 1 e attribution et la répartition des responsabilités entre l OFS et la CdC. De manière générale, l OFS est responsable du rassemblement complet des données et de leurs transmissions à la CdC selon un format défini. La CdC est responsable du traitement des données afin de faire l attribution du NAVS13 à la population. La CdC est également responsable de traiter les cas de non-attribution automatique du NAVS13 à une personne et de mettre en place des outils de gestion pour la mise à jour continuelle. 7/27

8 Schéma du processus général : Zuständigkeit: Datenfluss: BFS Normal ZAS Ausnahme 1 Export P 2 Konverter 3 Lieferung 4 QS 6 Monitoring P T XML T EWR CSV Sedex XML SFT 7 Transfert BFS2ZAS Sedex P T 8 Normalisierung > aller 5 Manungsdienst P T 9 Matching Import Aufbau (Erstverg.) EWR Anfragen EWR Betrieb Sedex SFT P T XML 11 Exception Handling (WEB-GUI) P ( ) T retour < Hans Muster? Hannes Musther 10 Clearing?? P ( ) T Betrieb EWR 12 Rückgabe SC / Abfragen (WS/WEB-GUI) XML P T Hans Muster Hannes Musther UPI Self Clearing Hans Muster? Hannes Musther Les différentes étapes du processus liés à la 1 e attribution sont décrites dans le détail ci-après. 4.3 Le planning de la 1 e attribution Octobre 2008 Tests 15 janvier 2009 Date de référence Printemps er retour des données Fin 2009 ~98% NAVS13 attribués Phase préparatoire Phase 1 e attribution Transition Phase mise à jour continuelle Traitement de masse Traitement au cas par cas 1 Tests 1 e attribution 3 Départ du clearing avec RdH 2 Date de référence de 1 e attribution 4 Départ mise à jour continuelle 8/27

9 4.4 L exportation de données Les registres doivent exporter les données nécessaires à l attribution du NAVS13. Il s agit de la population résidente dans la commune à la date de référence, c est-à-dire toutes les personnes inscrites dans la commune ayant soit une résidence principale ou de séjour dans celle-ci. Les données relatives aux personnes doivent être exportées selon un format autorisé mais surtout contenir les attributs nécessaires à la 1 e attribution. Les attributs et les formats sont décrits dans le document technique suivant : Première attribution du numéro d assuré AVS. Processus technique. Version 1.1, Ce document est disponible sous : En résumé: Les formats : Excel selon template CSV selon template XML selon schémas ech-0083 ou ech-0099 Attributs obligatoires : Identificateur local Nom Prénom(s) Date de naissance Sexe Nationalité Population: Les registres cantonaux et/ou communaux des habitants (RdH): - Les personnes résidant pour une période de plus de 3 mois dans une commune suisse ; - Les personnes annoncées comme résidant* de manière principale ou secondaire dans la commune. *Si le séjour n'est pas systématiquement enregistré ou ne peut être distingué de l'établissement, l'ofs, respectivement la CdC, doivent être informés avant la livraison des données du type de population contenue dans la livraison. Le registre des migrations (SYMIC): - Les personnes en statut «actif» dans le système SYMIC ; - Les individus au bénéfice d un permis de séjour allant au-delà de 4 mois. Le registre de l état civil (Infostar): - Les personnes de nationalité suisse ; - Les personnes étrangères ayant eu un événement d état civil et résidant en Suisse. Le registre des diplomates et des employés d organisations internationales (Ordipro): - Les internationaux étrangers ou diplomates possédant une carte de légitimation suisse et établis en Suisse (et leurs proches). Le registre des Suisses de l étranger (VERA): - Les personnes de nationalité suisse domiciliées hors de la Suisse ; - Les personnes de l étranger cotisant (facultativement) à l AVS/AI. Les caisses maladie (CM): - La population soumise à l assurance obligatoire de soins en Suisse (selon LAMal). Le registre des assurés AVS/AI (NRA/AVS) - La population déjà en possession d un numéro AVS à 11 et/ou à 13 positions. 4.5 La conversion Le format défini pour la transmission définitive à la CdC pour le traitement des données est le format ech Afin d offrir un maximum de souplesse, l OFS propose différentes alternatives pour livrer les données et propose un outil de conversion qui permet de convertir les données au final dans le format désiré. Ces outils de conversion peuvent être utilisés à différents niveaux du processus selon les connaissances techniques des utilisateurs et du modèle de transmission de données choisi. Ces outils sont à disposition sur le site de l OFS. 9/27

10 Conversion aller possible : Excel selon le Template > CSV-0083 CVS-0083 > XML ech-0083 XML-eCH-0099* > XML ech-0083 *attention : 1 Un filtre est intégré dans la conversion afin d extraire la population non-désirée pour le traitement : Personnes ayant déménagé ou décédées dans l année. 2 Pour le traitement, les données doivent contenir les informations concernant la relation d annonce («ResidenceType»). Le contrôle de couverture de population RdH et CM se fait sur la base de la population qui est annoncée comme étant résident principal dans la commune. Conversion retour possible : XML ech-0083 > CSV La livraison des données Les registres tiers peuvent utiliser à choix deux moyens différents pour assurer la transmission de manière électronique et sécurisée de leurs données via l OFS à la CdC. Toutes les données sont transmises en premier lieu à l OFS qui assure un contrôle de certains éléments. Une fois le contrôle passé avec succès, les données sont transmises par paquet cantonaux à la CdC pour le traitement. Les registres tiers peuvent utiliser à choix deux moyens différents pour assurer la transmission de manière électronique et sécurisée de leurs données via l OFS à la CdC. Il est conseillé d utiliser la plate-forme sedex pour transférer les données à l OFS. Variante 1- sedex «secure data exchange» Entre le et le , les registres tiers peuvent seulement transmettre leurs données pour la première attribution du NAVS13. Le service de validation ne sera pas disponible d une part afin de ne pas surcharger les systèmes et, d autre part, pour ne pas semer la confusion (livraison pour le service de validation ou pour la première attribution?). Les registres tiers qui sont connectés à la plate-forme sedex peuvent transmettre leurs données à l OFS via deux types de message. 1 envoi des données pour la validation* (type de message 94, adressage 3-CH-1) Avec ce type de message, les données doivent être transmises au format ech-0099 : *Attention : Le nom du type de message est déconcertant. Il s agit du type de message, qui est normalement utilisé pour la validation des données. Cependant à ce moment ( ) la livraison sert uniquement à la première attribution du NAVS13. 2 envoi des données pour la 1 e attribution (type de message 83, adressage 3-CH-21) : Avec ce type de message, les données doivent être transmises au format ech-0083 ou ech /27

11 Le schéma ci-dessous illustre le flux : Message type 94 RdH Sedex- ID 1-BFSNr-1 1 Original 2 Data ech-0099 OFS G-SOA Sedex- ID 3-CH-1 RdH (entre 15 et 30 janvier 09 ) 1- Envoie un message pour la validation > l original est router au système21 qui peut utiliser ces données pour la 1 e attribution. Une quittance est faite dans ce sens. 2- Envoie ces données directement pour la 1 e attribution. Une quittance est faite dans ce sens. Original Si les deux sont disponibles le type 83 est utilisé de manière prioritaire Message type 83 Data ech-0083 or ech-0099 OFS 1 e att. Sedex- ID 3-CH-21 Le monitoring affichera toutes les données entrée sur le système21 Le service de validation est indisponible entre le A partir du , uniquement livraison des cas particuliers. Doit être défini de manière bilatérale. Variante 2- SFT «secure file transfer» Une application web permet de transmettre de manière sécurisée des fichiers électroniques. SFT permet de télécharger un fichier et de le transmettre à un destinataire. Ce système ne demande aucune infrastructure ou logiciel au niveau du client. L utilisateur (RdH) doit, via l application web, retirer un ticket et ensuite télécharger son fichier compressé (Zip). Le destinataire (OFS) est averti via qu il a reçu un message. Le destinataire, après authentification, peut aller retirer le message qui lui est destiné. Par ce canal, on peut transmettre tous les types (XML, CSV) de fichiers. Nous partons cependant du principe que ce canal sera principalement utilisé pour transmettre des fichiers sous forme Excel ou CSV par les petites communes. La procédure : Taper la commune et sélectionner celle-ci sur la base de la liste proposée. 11/27

12 Lire le mail envoyé par le système SFT et cliquer sur le lien pour télécharger le fichier. Vérifier dans le mail que vous êtes bien le bon destinataire. Parcourir les dossiers sur le disque local de votre ordinateur et sélectionner le fichier à transmettre. Information sur le succès du transfer et transmission du mot de passe pour la réception des données après attribution du NAVS13 en avril Lien pour l utilisation du SFT : 12/27

13 La matrice suivante présente les différentes constellations possibles entre le canal et les formats pour la transmission des données. Livraison sedex SFT CD / DVD ech-0083 ech-0099 CSV Excel ech-0083 ech-0099 CSV Excel ech-0083 ech-0099 CSV Excel Résultat sedex STF CD / DVD ech-0083 ech-0083 CSV ech-0083 CSV Le mode de livraison des données a été défini avec chaque canton et formalisé dans une convention. Dans de multiples cantons, les solutions seront combinées. 4.7 L assurance qualité Dans cette étape du processus, différents éléments sont prévus pour permettre de faire un contrôle de qualité relativement basique des données fournies par les tiers. La première chose qui est faite est d éventuellement convertir les fichiers entrant dans le format ech Ensuite les clauses de plausibilité suivantes sont appliquées sur le fichier au format XML : - identificateur unique sur le jeu de données ; - population attendue ~= population livrée. Ce contrôle se fait avec les données issues de la statistique de la population (ESPOP) ; - attributs obligatoires livrés (id, nom, prénom(s), date de naissance, sexe, nationalité) ; - conformité au schéma ech-0083 ; - si un code nationalité est fourni -> validation avec la nomenclature OFS. 13/27

14 4.8 Le monitoring Il s agit, dans cette étape, de garantir le suivi des données qui sont transmises pour la 1 e attribution. Numéro OFS de commune N d historisation de la commune Abréviation du canton Nom officiel de la commune Canal utilisé Date de livraison FR Alterswil sedex FR Arconciel sedex FR Attalens sedex FR Auboranges sedex FR Autafond sedex FR Autigny SFT FR Avry SFT FR Barberęche SFT FR Bas-Intyamon SFT FR Bas-Vully SFT En gris, l état de prévision. Chaque livraison des données à l OFS sera suivie et affichée presque en temps réel afin de garantir le flux de cette livraison. Il est prévu de faire un monitoring à deux niveaux. - 1 er niveau : affichage du flux des données rentrantes issues des communes. - 2 ème niveau : affichage des données transmises à la CdC pour le traitement. Au moment où le canton est affiché en vert sur la carte, le travail de livraison des données est terminé pour le canton. 14/27

15 1 er niveau commune Numéro OFS de commune N d historisation de la commune Abréviation du canton Nom officiel de la commune Canal utilisé Etat de livraison FR Alterswil sedex FR Arconciel sedex FR Attalens sedex FR Auboranges sedex FR Autafond sedex FR Autigny SFT FR Avry SFT FR Barberęche SFT FR Bas-Intyamon sedex FR Bas-Vully SFT Lors de la livraison, l affichage de commune peut avoir trois états : 1 Rouge : Aucune livraison de la commune n a été effectuée. Une livraison est attendue. 2 Orange : Au moins une livraison non valide de données a été faite par la commune. Une nouvelle livraison est attendue dans les 24 heures. 3 Vert : Une livraison valide de données a été faite par la commune. Une fois que toutes les communes d un canton sont vertes (complet et valide), elles sont transmises à la CdC pour le traitement. La transmission se fait aussitôt que le canton est complet et valide. 2 ème niveau canton 15/27

16 4.9 Le rappel Le canton doit en principe s assurer que ses communes livrent les données dans les délais pour le traitement. Pour l heure, nous envisageons les actions suivantes : - 20 janvier : les cantons font un premier rappel aux communes pour qu elles fassent la livraison des données ; - 26 janvier : les communes qui n auraient pas livré leurs données sont contactées personnellement par le canton (ou l OFS) pour faire un 2 ème rappel et clarifier le problème ; - 28 janvier : les cantons (ou l OFS) vont sur place pour récolter les données ; - 2 février : toutes les données sont prêtes pour le traitement à la CdC ; - 9 février : les données seront traitées. Les données manquantes seront traitées ultérieurement Le traitement des données. Le principe général du traitement intégratif est de comparer entrer eux tous les enregistrements destinés à recevoir le NAVS13. Une telle comparaison a pour but de détecter les paires d enregistrements ayant un degré de similarité élevé. Ces paires sont ensuite regroupées en petits lots («clusters»), de telle façon que chacun d entre eux ait toutes les chances de regrouper tous les enregistrements désignant une seule et même personne physique au sein de tous les registres participant à l opération. Des règles de plausibilité sont ensuite appliquées sur chaque lot pour déterminer s il peut donner lieu de façon «sûre» à l attribution automatique d un NAVS13. Si la réponse s avère positive (lot dit «régulier»), le NAVS13 pourra être rapidement communiqué en retour à tous les registres dont provient l un des enregistrements formant le lot. Dans le cas contraire (lot dit «irrégulier»), le lot est transmis au service de traitement manuel («clearing»). Charge alors à celui-ci d entreprendre les actions jugées adéquates afin que les enregistrements composant le cluster irrégulier se voient attribuer, de façon ultime, le NAVS13 correct. 16/27

17 4.11 Le retour de données Suite au 1 er traitement des données, une majorité des NAVS13 pourra être attribuée de manière automatique aux données transmises. Ces données seront retournées aux registres tiers dès que possible. Il est planifié de retourner le 1 er grand lot de données à mi-avril Les données retournées comprendront: 1 Tous les enregistrements des personnes qui ont été transmis à la CdC en janvier ; 2 Les NAVS13 attribués de manière cohérente sur la base du traitement automatique et ceux issus du clearing d ici avril ; 3 Les données d identification issues d un registre hiérarchiquement plus élevé, soit «Infostar» ou «SYMIC» ou encore dans des cas exceptionnels «Ordipro». Les données retournées par la CdC via l OFS aux registres tiers seront, de manière générale, transmises par le même canal que lors de la livraison. Les registres tiers n étant pas prêts pour l importation des données ou disposant d un autre canal pour le retour que pour l aller doivent l annoncer à l OFS. L OFS mettra également à disposition le monitoring pour le retour. Celui-ci comprendra : - Les indications pour la livraison du retour des données ( ) Le % de NAVS13 attribué (dès le retour) - L état de la livraison pour le retour des données Etat du monitoring entre le : Numéro OFS de commune N d historisation de la commune Abréviation du canton Nom officiel de la commune Canal utilisé Date de retour FR Alterswil sedex FR Arconciel sedex FR Attalens sedex FR Auboranges sedex FR Autafond sedex FR Autigny SFT FR Avry SFT FR Barberęche SFT FR Bas-Intyamon SFT FR Bas-Vully SFT /27

18 Etat du monitoring à partir du : (exemple au ) Numéro OFS de commune N d historisation de la commune Abréviation du canton Nom officiel de la commune Canal utilisé % NAVS13 Date de retour FR Alterswil sedex FR Arconciel sedex FR Attalens sedex FR Auboranges sedex FR Autafond sedex FR Autigny SFT FR Avry SFT FR Barberęche SFT FR Bas-Intyamon SFT FR Bas-Vully SFT L importation des données Les données retournées par la CdC doivent être traitées par les registres tiers comme décrit dans les recommandations faites par la CdC. Gestion du NAVS13 dans les registres tiers : La principale règle est que le NAVS13 doit être géré conjointement aux attributs qui sont retournés par la CdC (UPI). Les applications de registres tiers doivent tenir compte de cet élément lors de l importation des données. Les données peuvent ensuite être importées avec le logiciel de la commune. Remarque concernant les données retournées et à importer: Les caractères officiels supplémentaires provenant de registres hiérarchiques supérieurs sont livrés d Infostar ou de SYMIC, lorsqu un enregistrement pour cette personne est disponible et est issu d un de ces deux registres. Les registres des habitants doivent utiliser ces indications, afin d adapter leurs données à celles de l UPI (provenant des registres officiels mentionnés). Exemple : Données livrées Données retournées = Livrées + UPI ~ ID-Source Nom Prénom 1 Kummer Patrik 2 Alabor Thomas 3 Schwyn Hans-Peter ID-Source Nom Prénom 1 Kummer Patrik 2 Alabor Thomas 3 Schwyn Hans-Peter Légende: RdH UPI ID-S NAVS13 Nom Nom Prénom Kummer Patrick Alabor Thomas Schwyn Jean-Pierre 18/27

19 L état après l importation sera le suivant: Données livrées Données Attribution NAVS13 Actions pour la 1e attribution? Oui Personne avec NAVS13 Attribution réussie Ne rien entreprendre avec les mêmes caractères que ceux officiels Oui Personne avec NAVS13 avec des caractères différents de ceux officiels Attribution réussie mais caractères non identiques Apurer les données à l interne avec le soutien si nécessaire de l office des migrations ou de l office de l état-civil Oui Personne sans NAVS13 Echec de l attribution automatique Non Personne sans NAVS13 Pas d attribution étant donné que rien n a encore été livré Ne rien entreprendre au début. Redemander un numéro plus tard (dès mi-2009) Ne rien entreprendre au début. Redemander un numéro plus tard (dès mi- 2009) Ultérieurement, les registres des habitants peuvent demander les NAVS13 manquants à la CdC, via internet par le biais d une application web ou directement par l intermédiaire du logiciel RdH. Les demandes des informations manquantes peuvent être faites à partir du mi Il n est cependant pas sûr qu au mois de juin tous les cas soient déjà disponibles. Il n est pour l heure encore pas défini, si une procédure d annonce «active» des cas résolus issus du clearing pourrait être proposée par la CdC. Exemple : Population envoyée le 15 janvier 2009 Etat de la population en mai 2009 ID-S NAVS13 Nom Nom Prénom 1 Kummer Patrick 2 Alabor Thomas 3 Schwyn Jean-Pierre RdH ID-S NAVS13 Nom Prénom Prénom 1 Clearing Kummer Patrick Alabor Thomas Schwyn Hans-Peter 4 Müller Peter Problématique pour les RdH Les NAVS13 des cas 1 et 4 doivent être recherchés ultérieurement. Le prénom de 3 a été adapté selon les données retournées par l UPI Le service clearing Le service clearing est la structure responsable du traitement des données n ayant pu faire l objet d une attribution automatique du NAVS13. Ce service de la CdC se compose de 50 collaborateurs et a pour responsabilité la résolution des problèmes d identification : personne potentiellement enregistrée plusieurs fois dans un même registre ou absente d un registre où elle devrait être. Le service pourra résoudre une partie des cas de manière totalement autonome sur la base de données fournies par les tiers, et dans d autres cas plus complexes, il devra avoir recours à des deman- 19/27

20 des d informations complémentaires directement auprès des divers services responsables des données. Les principales sollicitations seront des demandes : - de confirmation que deux enregistrements du registre sollicité et ayant des attributs très proches, représentent bien la même personne ; - de répartition des données du registre sollicité lorsque deux personnes proches mais différentes ont été identifiées ; - de confirmation de validité d enregistrement extraite à partir du dossier sollicité (date de mise à jour de l information) ; - libres d informations complémentaires. Le détail des processus et sollicitations aux registres seront décrits d ici novembre 2008 par la CdC dans le cadre du projet «COMIN». Dans cette description sera également contenu le détail relatif aux retours des cas résolus par le service clearing. Les demandes issues du service clearing pourraient se présenter de la manière suivante : Est-ce que la personne 1 est la même que la personne 2? Namen Vornamen Geschlecht Geburtsdatum Nationalität 1 UPI Berchtold Alfred Josef EWR Berchtold Fredy > oui, car le prénom et la date de naissance n étaient pas saisis correctement dans 2 Namen Vornamen Geschlecht Geburtsdatum Nationalität 1 UPI Berchtold Alfred Josef EWR Berchtold Fredy Alfred Josef > non, car le prénom et la date de naissance sont différents Namen Vornamen Geschlecht Geburtsdatum Nationalität 1 UPI Berchtold Alfred Josef EWR Berchtold Fredy Alfred Josef La deuxième itération Entre le moment de la livraison des données du registre de personnes à la CdC et l'importation de la réponse de la CdC dans le registre de personnes, environ 2 mois vont s écouler, ceci à cause de la 20/27

21 durée du processus. Pendant cette période, les registres de personnes subiront des changements car de nouveaux enregistrements (p. ex. immigration) et des départs devront être enregistrés. Si le nombre de mutations durant cette période dépasse 200, une deuxième livraison du registre de personnes à la CdC est possible. La procédure sera faite de manière similaire à la 1 e attribution. Le registre de personnes peut attendre un mois entre la réception de la réponse à la première attribution et la demande d un envoi pour une deuxième livraison de la seconde itération. À l'échéance de ce délai, le registre de personnes doit utiliser les interfaces fournies par l UPI pour la mise à jour continuelle. La deuxième livraison ne contient plus l'ensemble des enregistrements de personnes, mais seulement "le delta": les données des nouveaux enregistrements depuis la première livraison. Le traitement de la deuxième livraison s'effectuera relativement rapidement (quelques jours). Par conséquent, une seule itération de deuxième livraison est attendue par registre de personnes. Le planning actuel prévoit le traitement de la 2 ème itération dès le 1 e juillet Le contrôle final de l attribution La grande majorité des numéros sera attribuée à la population durant l années Il est prévu que 98% de la population à numéroter dans le cadre de cette action de 1 e attribution dispose d un NAVS13 à la fin de l année Il est prévu de faire un contrôle de l état de l attribution par le biais du service de validation. Celui-ci pourra, dès la mi-2009, détecter le pourcentage de NAVS13 attribué dans les registres des habitants. Il n est pour l heure pas prévu de faire d autres contrôles intermédiaires. 21/27

22 5 La description des tests Comme indiqué en introduction, l OFS et la CdC vont mettre en place des procédures de tests qui seront évolutives en fonction de l avancement de travaux. Les niveaux de tests T1 et T2 sont d une importance moindre. Par contre, les niveaux T3, T4 et T5 sont indispensables. 5.1 Objectifs des tests Les tests ont comme objectif de préparer au mieux tous les acteurs impliqués dans le processus de 1 e attribution. Certains éléments sont prévus comme outils de soutien à la préparation des données, d autres servent effectivement au traitement de données. Les objectifs des tests peuvent être résumés de la manière suivante : - Soutien pour les travaux préparatoires des tiers (convertisseurs, simulateurs) ; - Proof of concept «rassemblement et livraison des données» par les acteurs ; - Tests de charges des systèmes d exploitation (systèmes de transmission et de traitement des données) ; - Préparation optimale de la normalisation des données avant traitement ; - Calibrage des outils de matching pour le traitement ; - Dans la mesure du possible, en fonction du volume des données à disposition de la CdC pour les tests: estimations quantitatives des lots d enregistrements réguliers et irréguliers, et des types d anomalies rencontrées dans les lots irréguliers ; - Validation des procédures de clearing fonctionnelles et des procédures de résolution de cas problématiques avec les acteurs ; - Retour des données aux livreurs, et importation des NAVS13 attribués. 5.2 Planification des tests Zuständigkeit: BFS ZAS T T T Reg. Lieferung Rücknahme QC/Monitoring Erstvergabe Verarbeitung (Matching) T end2end Reg. Exception handling Service clearing Self clearing T Reg Betrieb UPI -services 22/27

23 T1 dès Divers outils de soutien (simulation de livraison) - Générateur de schéma - Validateur de schéma - Convertisseurs - Simulateur sedex T Reg. Lieferung Rücknahme QC/Monitoring Erstvergabe Verarbeitung (Matching) T2 dès Livraison à l OFS - Réception effective de données transmises via sedex à l OFS (type 83) - Réception de données transmises via SFT à l OFS - Premiers essais du monitoring T Reg. Lieferung Rücknahme QC/Monitoring Erstvergabe Verarbeitung (Matching) T3 dès Tests de 1 e attribution - Tests de 1 e attribution complets intégrant : La livraison des données par les tiers, le contrôle et le monitoring des données par l OFS, le transfer de données à la CdC pour le traitement, un premier traitement des données et un retour avec NAVS13 fictif issu d un traitement automatique simplifié des données à disposition (seul le Matching sera mis en œuvre sur ce niveau) T Reg. Lieferung Rücknahme QC/Monitoring Erstvergabe Verarbeitung (Matching) T4 dès Tests des procédures du Service Clearing - Tests des procédures de clearing en interne - Tests des procédures de traitement des cas résiduels avec les tiers ( , EndToEnd) T end2end Reg. Exception handling Service clearing Self clearing T5 dès Tests de la mise à jour continuelle (uniquement UPI) 23/27

24 - Tests des services-upi T Reg. Betrieb UPI -services 5.3 Description des tests Le niveau T1 (Divers outils de soutien) Les tests du niveau T1 sont disponibles et publiés sur Internet. Ces outils restent à disposition jusqu au printemps Les outils de soutien ci-dessous ont été élaborés pour servir d aide à la préparation de la livraison des données pour le 15 janvier Ils ont été élaborés par l'ofs et la CdC. Nom de la ressource Format Description succincte Version Ressource Générateur ech-0083 Java Le générateur produit.un fichier conforme au format ech-0083 avec des données aléatoires Generator ech Converter ech-0083 Programme Java Utilitaire permettant de convertir un fichier XML 1.01 converter echconforme à la syntaxe ech-0083 en un fichier plat de 0083 type CSV et réciproquement. Validator Programme Java Utilitaire permettant de contrôler la conformité de la BIP (format XML) à la syntaxe du Schema XSD ech Validator.zip ech-0083 Schémas XML sedex Le fichier zip contient tous les schémas XML relatifs à sedex, y compris ceux de l association ech dont dépendent les schémas sedex. Schémas sedex XML Simulateursedex Java Le simulateur propose une simulation des applications de sedex pour les messages de type 83 et Simulator-sedex Le niveau T2 (Livraison à l OFS) Le niveau de test T2 permettra aux registres tiers de faire une livraison de leurs données effectives pour le traitement dans un des formats autorisés par un des canaux autorisés [voir 4.5 et 4.6]. Une analyse des données sera faite et une réponse sera donnée à la livraison en fonction du résultat de l analyse [voir 4.7]. Dans un premier temps, seuls les messages destinés explicitement à la 1 e attribution (type de message 83) via sedex seront autorisés pour les tests de livraison. Les éléments seront ensuite transmis au monitoring. Celui-ci affichera l état des données transmises par les communes. Le service de validation (type de message 94) pourra être sollicité de manière standard comme habituellement et indépendant à ces tests. L utilisation du service de validation est vivement recommandée pour assurer la qualité des données de manière générale. 24/27

25 5.3.3 Le niveau T3 (Tests de 1 e attribution) Les tests du niveau T3 permettront de tester la boucle complète de la 1 e attribution. La boucle se limitera par contre uniquement à la partie traitement automatique des données. Le service clearing ne pourra pas, pour des raisons de planning, être opérationnel à ce moment. Les registres tiers pourront livrer leurs données depuis le 1 er jusqu au 30 octobre 2008 pour participer à cette grande action. A. La livraison de données pour les tests Variante 1-sedex «secure data exchange» Cette livraison pourra se faire par l intermédiaire d un message destiné à la 1 e attribution (type de message 83) ou d un message destiné à la validation (type de message 94) [voir 4.3]. Lors des tests de 1 e attribution, le traitement de message adressé à la validation sera traité en interne de manière différente que lors de la 1 e attribution en janvier. Dans ce cas, le message qui est envoyé pour la validation est transmis normalement à la validation et une copie de ce message sera transmise au système 21 de la 1 e attribution. Si ce fichier est complet et valide pour la 1 e attribution, il pourra être utilisé pour la suite du traitement des tests. Parallèlement, la validation se fera de manière indépendante. Le schéma ci-dessous illustre le flux : Message type 94 RdH Sedex- ID 1-BFSNr-1 1 Original 2 Message type 83 Original Data ech-0099 OFS G-SOA Sedex- ID 3-CH-1 1 Copie Message type 94 Data ech-0099 RdH (entre 1 e et 30 octobre) 1- Envoie un message pour la validation. Une copie est transmise au système21 qui peut utiliser ces données pour les tests. Si possible une quittance est faite dans ce sens. 2- Envoie ces données directement pour les tests de 1 e attribution. Une quittance est faite dans ce sens. Si les deux sont disponibles le type 83 est utilisé de manière prioritaire Le monitoring affichera toutes les données entrées sur le système21 Data ech-0083 or ech-0099 OFS 1 e att. Sedex- ID 3-CH-21 Variante 2- SFT «secure file transfer» La livraison des données par ce canal se fait exactement de la même manière pendant les tests que lors de la 1 e attribution [voir 4.6]. B. Le traitement des données lors des tests Les données seront traitées de manière simplifiée lors de ces tests. Situation A : Présupposé : au moins les 3 registres fédéraux suivants sont disponibles à la CdC au 10 octobre 2008: Infostar (état civil) ; SYMIC (étrangers) ; VERA (Suisses à l étranger). Pour les cantons dont l effectif aura été livré au complet et selon les directives, aussi bien par les registres des habitants que par les caisses maladie, un traitement selon la méthode intégrée sera effectué. Le résultat donnera lieu aux estimations suivantes : 25/27

26 - Fraction de la population à laquelle le NAVS13 pourra vraisemblablement être attribué de façon automatique en 2009, - Nature des éventuels problèmes rencontrés avec le traitement du lot cantonal (relatifs aux données, à leur mise en forme ou à la population livrée). Dans la mesure où ces problèmes sont aisément attribuables à une source de données en particulier : feed-back auprès de la source (via l OFS). Situation B : Si les conditions caractérisant la situation A ne sont pas réunies (absence d un des 3 registres fédéraux majeurs ou population cantonale incomplète), les opérations suivantes seront effectuées : - Chaque registre livré subira une comparaison avec le registre central des assurés de l AVS (NRA) et un pseudo-navs13 retourné pour tous les enregistrements ayant rencontré un correspondant «sûr» dans le NRA. - Dans la mesure où des anomalies auront pu être constatées dans les données livrées (attributs et leur mise en forme) : feed-back auprès de la source (via l OFS). Nota Bene : dans tous les cas de figure, les enregistrements retournés avec un numéro fictif ne s accompagnent pas de la garantie que ces enregistrements ne seront pas impliqués dans une opération de clearing lors de la phase productive en 2009! Le numéro fictif sera identique pour toutes les personnes : [ ] C. Le retour des données lors des tests Le retour des données après le traitement se fait de manière identique que lors de la 1 e attribution. Les données fictives ne devront pas être importées de manière définitive. D. La plus-value potentielle générée par les tests T3 Elle est soumise aux deux facteurs limitants suivants : a) durée prévue relativement courte, contraignant à un traitement simplifié ; b) incertitude sur le degré de participation (couverture) des registres concernés. Un bénéfice majeur pour l ensemble des acteurs du processus ne peut être espéré que dans la mesure où une très forte majorité d entre-eux livre les données à temps et selon les critères prévus pour la livraison productive de janvier Proportionnellement au degré de réalisation de cette attente, il sera possible de faire des estimations de certains ordres de grandeur, permettant à leur tour de réaliser des optimisations à tous les niveaux du processus. - estimations réelles des difficultés du rassemblement des données ; - analyse de la qualité des attributs et de leurs cohérences [identification] ; - estimation grossière du volume d assignation automatique possible ; - estimation du temps de traitement automatique ; - estimation des populations problématiques ; - estimation de la cohérence des attributs [livré, retourné]. 26/27

27 5.3.4 Le niveau T4 (Tests des procédures du Service Clearing) Les tests du niveau T4 sont scindés en deux parties. 1 Dans un premier temps, la CdC teste en interne, sans solliciter les registres tiers, les procédures de clearing. Le but de ces tests est de vérifier les procédures de résolution sur la base des informations disponibles. Un élément central de ces tests est le contrôle des flux du service clearing : import des données et intégration avec l UPI. 2 Dans un deuxième temps, les registres tiers seront intégrés à la démarche de test afin de valider de bout en bout les procédures dans les cas complexes résiduels. Les sollicitations se feront dans la majorité des cas au travers d échanges d . Ces procédures seront définies et décrites par la CdC dans le projet COMIN d ici novembre Le niveau T5 (Tests de la mise à jour continuelle (uniquement UPI)) Les tests de ce dernier niveau permettront de contrôler les procédures de la mise à jour continuelle. Les services de l UPI permettront de pouvoir utiliser les services proposés pour écrire dans l UPI, mais surtout pour consulter l UPI. Les droits en écriture sont limités. Les spécifications techniques des accès aux services sont disponibles et publiées sur Internet [voir 3]. Ces procédures seront définies et décrites par la CdC dans le projet UPI09 d ici novembre Conclusion des tests La mise en place de tests est indispensable pour pouvoir garantir la mise en œuvre de la 1 e attribution du NAVS13 à la population. Les tests ne sont en principe pas obligatoires. Cependant, l OFS et la CdC recommandent vivement à tous les registres tiers impliqués dans ce processus de participer à ces tests. Comme nous l avons vu, les tests les plus importants sont les T3, T4 et T5. Les diverses conventions (avec les cantons et santésuisse) établies montrent que la plupart des acteurs vont s efforcer, dans la mesure du possible, à participer à l exercice T3 de 1 e attribution. Si l ensemble des acteurs participent, les résultats seront très représentatifs et utiles pour tous. 27/27