1 / 13

Modernisation des registres BCSS

Modernisation des registres BCSS. But de la modernisation. C’est également à la demande des institutions de sécurité sociale que la Banque-carrefour s’occupe du développement d’un important projet concernant la modernisation des registres.

Download Presentation

Modernisation des registres BCSS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Modernisation des registres BCSS

  2. But de la modernisation • C’est également à la demande des institutions de sécurité sociale que la Banque-carrefour s’occupe du développement d’un important projet concernant la modernisation des registres. • Le but de cette modernisation est principalement un alignement sur les données disponibles dans le Registre national. • La modernisation implique surtout une augmentation de la qualité des données personnelles disponibles, avec entre autres l’utilisation de caractères et signes spéciaux, de petites lettres et de lettres capitales, de nouvelles fonctionnalités, de nouveaux champs et l’extension des longueurs maximales dans les champs existants. • Au cours d’une période de transition, les formulaires existants seront supportés, mais on incitera les institutions à passer à l’utilisation de nouvelles technologies via les services Web.

  3. Augmentation de la qualité • Utilisation des tableaux code • But: • Utilisation de codes actuels dans les données lieu de naissance, nationalité, adresse • Contrôle de la structure des codes postaux à l’étranger • Tableaux code: • Codes du Registre national portant sur la nationalité, les codes pays d’adresse, les codes communaux de lieux de naissance belges, les rues belges et la structure des codes postaux étrangers. • La BCSS prévoit l’interprétation de certains codes pour une utilisation plus stricte dans le registre BCSS, surtout en ce qui concerne l’utilisation de codes pays et de nationalité dans les registres BCSS. • Les tableaux code (CTMS) seront consultables et téléchargeables par la BCSS, plus uniquement via le portail de la Sécurité sociale, mais également via service Web. • La BCSS prévoit la communication de modifications aux tableaux code et éventuellement la transmission de mutations • Pour des données d’adresse en Belgique, la possibilité sera prévue d’utiliser des codes rue, mais également la description de la rue à condition toutefois que l’orthographe soit correcte. • Stockage interne de codes à la BCSS • Par ce stockage, il sera également possible à terme d’effectuer des recherches sur adresse dans les registres BCSS. • La description exacte/la plus récente est remise aux OSS. • Effets: • Utilisation supplémentaire du nouveau tableau code pour les rues belges, la structure des codes postaux étrangers • Flux existants (A1 + SSDN) • Orthographe exacte de la rue belge • Contrôle de la structure du code postal étranger • Stockage interne de codes auprès de la BCSS

  4. Date de modification versus date d’entrée en vigueur • Par groupe de données sont prévus deux dates type, à savoir la date de modification et la date d’entrée en vigueur d’un certain événement. Ceci implique qu’une correction d’une donnée relèvera du dénominateur ‘modification’ et ne créera par conséquent pas de nouvel historique. Un nouvel historique sera uniquement inséré lors d’un événement avec une nouvelle date d’entrée en vigueur. • La cellule Identification de la BCSS aura la possibilité d’effectuer des insertions dans des données historiques. • Effets (A1 + SSDN): • Aucune distinction entre correction et modification. Les modifications apportées sont toujours considérées comme une correction.

  5. Nouvelles fonctionnalités • Dans le groupe ‘état civil’, un lien sera prévu vers le partenaire • Création d’un nouveau groupe de données ‘composition de ménage’, avec mention du ‘code-situation du ménage’ ’ • Outre la ‘date du décès’, le ‘lieu du décès’ pourra également être introduit • On pourra introduire plusieurs occurences pour ‘l’état civil’ et la ‘nationalité’ • Des recherches phonétiques sont prévues sur la combinaison du nom et de trois prénoms • Recherche sur adresse dans les registres BCSS; cette recherche peut être combinée avec les recherches phonétiques précitées sur le nom et trois prénoms • La cellule Identification de la BCSS aura la possibilité d’annuler des remplacements erronés • Effets ( A1+SSDN) • On ne prévoit pas de nouvelles fonctionnalités • De nouveaux groupes de données/nouvelles données dans un groupe de données existant peuvent • Ne pas être enregistrés • Ne pas être consultés • Pas de mutations.

  6. Nouveaux champs et adaption des longueurs • Nouveaux champs : partenaire, membres du ménage, troisième prénom et lieu du décès • Adaptation des longueurs maximales • Groupe de noms et prénoms • Les trois prénoms reçoivent chacun une longueur de 24 • Le nom reçoit une longueur de 48 • Groupe adresses • Dans les adresses belges, le numéro de maison et l’habitation d’index sont chacun prévus sur 10 • Dans les adresses étrangères • Le code postal est prévu sur 15 • Numéro de maison et index maison chacun prévus sur 10 • Le nom de rue et le nom de la localité sont chacun prévus sur 48 • Effets • A1: • Le message ne change pas • Les groupes de données où les données ne sont pas conformes,  « ancienne structure » ne sont plus consultables ou modifiables • SSDN • L’extension des longueurs n’a pas d’effets sur le message lui-même.

  7. Utilisation de caractères et signes spéciaux • La BCSS s’alignera sur le format universel UTF-8 où l’on fera une sélection des signes autorisés et non autorisés. • Effets (A1 +SSDN): • Les groupes de données avec des caractères et signes spéciaux ne peuvent plus être modifiés. • Les caractères et signes spéciaux sont transformés en lettres capitales pour les messages A1

  8. La nouvelle base de données auprès de la BCSS La modernisation des registres BCSS avec de nouvelles fonctionnalités, des champs nouveaux et plus étendus implique la création d’une nouvelle base de données auprès de la BCSS. Il en résulte que les données provenant de l’ancienne banque de données doivent être transférées à la nouvelle. La BCSS a déjà entamé les préparatifs nécessaires à cet effet. Lors du transfert de données, l’on tiendra compte, dans la mesure du possible, de l’amélioration de la qualité. Pour maintenir cette amélioration de la qualité, il est toutefois nécessaire que les flux existants avec le préfixe A1 passent les mêmes contrôles que les nouveaux services Web. A cet effet, la BCSS procèdera dès lors à l’adaptation des formulaires concernés (voir slide suivant).

  9. Amélioration de la qualité via les flux existants Les formulaires concernés sont le 601R pour la création de nouveaux numéros Bis et le L204 pour la mise à jour de numéros Bis existants. Pour toute clarté, il n’y aura pas d’adaptations aux lay-outs existants, mais on contrôlera uniquement plus rigoureusement la qualité fournie des données. Les contrôles supplémentaires reproduiront un certain nombre de nouveaux et probablement davantage de codes d’erreur (codes retour). L’objectif est cependant de réutiliser les codes existants durant le processus de validation, même avec une plus large définition.

  10. Démarrage de la nouvelle banque de données • Les flux A1 et les services Web SSDN Push restent soutenus, mais • On n’offre pas de nouvelles fonctionnalités • Il n’y a pas d’extension de longueurs de champs • On ne reproduit pas de nouveaux champs • Effets de mises à jour ou création avec des formulaires A1 • Les champs de données qui répondent aux nouvelles règles de la modernisation ne pourront plus être mises à jour que sur la base de ces mêmes règles. Ceci signifie que par ex. un nom écrit sous la forme de lettres majuscules, de lettres minuscules (Demol) ne pourra plus être modifié vers l’ancien format avec exclusivement des lettres majuscules (DEMOL). Les champs qui répondent aux nouvelles règles seront pour ainsi dire ‘gelés’. • Autres effets possibles avec le préfixe A1 + SSDN • Toutes les données ne pourront pas être modifiées. • Les données ‘gelées’ d’un NISS ne pourront plus être consultées sauf l’info Name; le cas échéant, cette info sera reproduite sur ses longueurs maximales moins 3 positions qui seront complétées par des petits points. • Toutes les données d’un groupe ne pourront pas être transmises comme mutation • La cellule Identification de la BCSS assistera si nécessaire les institutions dans leurs activités

  11. Passage à de nouveaux flux • Les nouveaux flux sont basés sur des services publics standard du type Web (via SOA platform) pour la création de nouveaux numéros Bis, des recherches phonétiques, des consultations actuelles et historiques et des mutations. • Dans le même cadre, des institutions peuvent prendre contact avec la BCSS pour conclure des accords concrets en vue de compléter et de mettre à jour de nouveaux groupes de données (par ex un chargement initial de données relatives à la composition de ménage).

  12. Planning • Le support des formulaires A1 est prévu jusque 3 ans au maximum à partir du 01 janvier 2011, donc au plus tard jusqu’au 31 décembre 2013. • Un planning plus court peut toujours être conclu bilatéralement entre l’institution concernée et la BCSS. • On prévoit la possibilité de supprimer progressivement les formulaires, si nécessaire, de sorte qu’il ne faille pas nécessairement effectuer une opération bigbang. • Documentation: • Disponible au 1er trimestre 2010: • Effets sur avis A1 • Effets sur avis SSDN • Nouveaux flux au 2ème trimestre 2010

  13. Modification MID? • Il est demandé/envisagé à partir de certaines institutions de Sécurité sociale de faire de la donnée ‘sexe’ une donnée obligatoire, de sorte qu’elle fera partie à part entière des différents types MID’s • OSS d’accord?

More Related