Borgeres stamdata (navn, adresse m.v.) flyder fra CPR registrer og ind til STAR city systemerne efter nedenstående flow

Flow beskrivelse

Data fra CPR register

1. CPR registret leverer dagligt (om natten) en delta til BI STAR City

2. BI foretager

   1. En load af disse rådata i deres egen system

   2. Sender en kopi af rådata til STARs kontor 'Data og Analyse' (DOA)

Distribution i STAR City systemer

1. BI forbereder distribution ved

   1. At udvælge de borger i rådata, hvor data skal sendes videre
      Ikke alle borgere sendes videre til de øvrige STAR City systemer (af GDPR hensyn)
      Kun borgere, der er mellem 15 og xx år, medtages, dog kan borger under 15 år være på en positivliste (på bestilling tilføjes løbende borgere til positivlisten) og i givet fald medtages de også

   2. Borgere, der fra CPR modtages med kommunenr. < 100 eller mellem 900 og 998, får i det videre flow til DFDG omsat kommunenr. til 101. Øvrige kommunenr. fra CPR, fx 9999, omsættes ikke til 101.

   3. Udvælge hvilke data i rådata, der medtages
      Ikke alle oplysninger, som BI modtager, sendes videre til de øvrige STAR City systemer (af GDPR hensyn)

2. CPR stamdata loades ind i Vitas
   BI? har vi lidt flere info

3. BI publicerer følgende eventtyper på event broker

   1. På ændringer til CPR stamdata publicerer BI event Star.EksterneData.Events.Borgerstamdata.V2.BorgerstamdataOpdateretEvent fra forretningsdomæne (siloen) EksterneData

   2. På ændringer til adresse og adressehistorik publicerer BI event Star.EksterneData.Borgerstamdata.Events.Borgerstamdata.V1.AdresseOpdateretEvent fra forretningsdomæne (siloen) EksterneData

   3. På ændringer til forsørgelsesforhold (cpr relation til børn under 18 år) publicerer BI event Star.EksterneData.Events.Borgerstamdata.V1.ForsoergelsepligtOpdateretEvent fra forretningsdomæne (siloen) EksterneData

4. Borgerkommunikation modtager Borgerstamdata-eventet og laver et nyt borgerstamdatatevent som distribueres til de øvrige forretningsdomæner. Dette primært for at sikre imod problemer med race conditions ift. jobcentertilknytning (som ikke er en del af tegningen, da det regnes for at høre til flytteflow, se https://starwiki.atlassian.net/wiki/spaces/LOG/pages/7307502 ). Da visse borgere optræder med en teknisk kommunekode (mindre end 101), oversætter Borgerkommunikation disse til 101 inden eventet behandles og sendes til andre forretningsdomæner.

5. Hver enkelt forretningsdomæne (silo), der anvender CPR data, abonnerer på de relevante events og

   1. Gemmer for forretningsdomænet (siloen) de relevante borgere og datafelter. Der gemmes kun de data, der er nødvendige i forhold til forretningsbehov

   2. Udfører afledte forretningsmæssige opgaver som f.eks. behandling af CPR statusskift herunder død, CPR nummer skift, flytteflow, sætte jobcentertilknytning for nye borgere og WSRM afsendelse til eksterne.

6. Hver enkelt forretningsdomæne (silo) udfører eventuelle batch processer på baggrund af de modtagne data. I DFDG Classic sørger batchjobbet DFDG-TASS-ProcessCprAliassesChanges for udsendelse af WSRM GetCprChanged når der er tale om personnummerskift.