Inera Personuppgiftstjänst (PU-tjänsten) har en egen datastruktur för länkningar mellan personidentiteter, som visar vilka personidentiteter som hör till en och samma person. För varje person med länkade personidentiteter kommer även en huvudidentitet att utses. Denna sida beskriver hur dessa länkningar och huvudidentiteter fungerar.
Länkningarna byggs upp utifrån två datakällor:
För varje kedja med länkningar, det vill säga att en person har flera länkade personidentiteter, så kommer PU-tjänsten att utse en huvudidentitet bland dessa. Definitionen av huvudidentitet görs tydligast på följande verksamhetscentrerade sätt:
"Om jag i min verksamhetsutövning ska registrera ny information på en person, vilken av dennes personidentiteter skall jag då i normala fall registrera informationen på?"
Inera Personuppgiftstjänst försöker via en algoritm att så nära som möjligt uppnå definitionen genom i förväg bestämda regler för hur huvudidentiteten utses i olika fall. Varje verksamhetsutövare behöver dock göra en egen bedömning om huruvida det skulle finnas anledning att registrera information på en annan personidentitet än huvudidentiteten som anges av PU-tjänsten.
Följande definitioner används för att beskriva algoritmen som vid skapandet av länkningar utser huvudidentitet. I definitionerna hänvisas till attribut som beskrivs i Personuppgiftstjänstens Tjänstekontraktbeskrivning (TKB).
Personposter kommer att klassificeras som antingen aktuella eller inaktuella enligt tabell nedan.
Identitetstyp | Aktuellt om | Inaktuellt om |
---|---|---|
PNR | Attributet deregistration:deregistrationReasonCode saknar värde/är null | Attributet deregistration:deregistrationReasonCode har ett värde/är ej null (värdet kan vara AV, UV, GN, AN, TA, OB, FI) |
SNR | Attributet personalIdentityStatus:identityStatus har värdet "AKTIVT" | Attributet personalIdentityStatus:identityStatus har annat värde än "AKTIVT" (kan istället vara VILANDEFORKLARAT, VILANDEFORKLARAT_STANGT, AVREGISTRERAT) |
NRID | Attributet deregistration:deregistrationReasonCode saknar värde/är null | Attributet deregistration:deregistrationReasonCode har ett värde/är ej null (värdet kan vara AV, UV, GN, AN, TA, OB, FI) |
LRID | Attributet deregistration:deregistrationReasonCode saknar värde/är null | Attributet deregistration:deregistrationReasonCode har ett värde/är ej null (värdet kan vara AV, UV, GN, AN, TA, OB, FI) |
Aktuella personposter kan jämföras med varandra utifrån deras "aktualitetsdatum", för att avgöra vilken av identiteterna som är mest aktuell. Den personpost som har det senaste aktualitetsdatumet är mest aktuell. Vilket attribut som skall anses vara aktualitetsdatum beror på identitetstypen, enligt tabell nedan.
Identitetstyp | Aktualitetsdatum |
---|---|
PNR | Folkbokföringsdatum (attribut populationRegistrationLocality:populationRegistrationDate) |
SNR | Det senaste datumet av allokeringsdatum eller förnyelsedatum (attribut coOrdinationNumberData:allocationDate eller renewalDate) |
NRID | Versionsdatum (attribut version) |
LRID | Versionsdatum (attribut version) |
En inaktuell personpost kommer att ha ett "avregistreringsdatum". Vilket attribut som räknas som avregistreringsdatum beror på identitetstypen, enligt tabell nedan.
Identitetstyp | Avregistreringsdatum (attribut) |
---|---|
PNR | deregistration:deregistrationDate |
SNR | personalIdentityStatus:identityStatusDate |
NRID | deregistration:deregistrationDate |
LRID | deregistration:deregistrationDate |
En inaktuell personpost kommer att ha en "avregistreringskod". Vilket attribut som räknas som avregistreringskod beror på identitetstypen, enligt tabell nedan.
Identitetstyp | Avregistreringskod (attribut) |
---|---|
PNR | deregistration:deregistrationReasonCode |
SNR | personalIdentityStatus:identityStatus |
NRID | deregistration:deregistrationReasonCode |
LRID | deregistration:deregistrationReasonCode |
Tre huvudsakliga fall finns när länkningar skapas och en huvudidentitet skall utses:
I följande delavsnitt beskrivs hur huvudidentiteten utses vid vart och ett av dessa tre fall.
Om endast en av de länkade personposterna är aktuell så utses den som huvudidentitet.
Om fler än en av de länkade personposterna är aktuell så utses huvudidentiteten enligt följande hierarki och hantering.
Hierarki:
Personidentiteten som är först i hierarkin (lägst siffra) blir huvudidentitet. Finns flera på samma nivå så utses den med senaste aktualitetsdatum.
Hantering av specialfall:
Om ingen av de länkade personposterna är aktuell så utses huvudidentiteten enligt följande hierarki och hantering.
Hierarki:
Personidentiteten som är först i hierarkin (lägst siffra) blir huvudidentitet. Finns flera på samma nivå så utses den med senaste avregistreringsdatum.
Hantering av specialfall:
Här listas undantagsfall som kan förekomma då huvudidentiteten utses.
En personidentitet A har en länkning till sig från en annan personidentitet B, men personidentitet A visar sig saknas i Navet trots att den är av typ PNR eller SNR. Länkningen till personidentitet A kommer då att bibehållas i PU-tjänsten, men personidentitet A kan aldrig utses till huvudidentitet. En huvudidentitet utses istället bland övriga länkade personidentiteter, utifrån ovan angivna länknings-fall.
Vid specifika händelser som sker när tjänsten försöker skapa länkningar så kommer information skrivas till tjänstens logg.
Följande information skrivs ut till logg vid respektive loggningshändelse:
Händelse | Logginnehåll |
---|---|
Flera personposter är aktuella eller Inga personposter är aktuella | Timestamp; Händelsetyp (beskriver varför loggning skett); Länkens Databas-id; OID-nr personidentiet A + Avregkod personidentitet A; OID-nr personidentiet B + Avregkod personidentitet B; OID-nr personidentiet C + Avregkod personidentitet C; ... |
Personposten hittas ej i Navet | Timestamp; Händelsetyp (beskriver varför loggning skett); Länkens Databas-id; OID-nr personidentiet A; OID-nr personidentiet B; |