...
...
Innehåll
Innehållsförteckning | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Sektion | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
InledningDokumentet beskriver hur en Lokal PU (LPU) kan nyttja kontrakten SearchPersonsForProfileByOrder(Unrestricted), SearchPersonsForProfileByOrder samt REST-tjänsten SearchPersonByFile för att hålla en lokal databas uppdaterad med de senaste ändringarna i Ineras Nationella Personuppgiftstjänst (NPU). Antal förändringar per dygn varierar en hel del. Vid ett stickprov för april 2021 så låg antalet förändrade personposter i hela databasen på mellan 20.000 och 120.000 per dygn. Orsaken till de stora mängderna förändringar per dygn är främst uppdateringar av kontaktuppgifter via 1177. Strategier för att få mindre svar kan vara att hämta förändringar flera gånger per dygn eller att dela upp frågan per region.
För att en LPU ska få söka med kontraktet SearchPersonsForProfileByOrderUnrestricted så krävs det att en region äger den lokala tjänsten och därmed är personuppgiftsansvarig (PuA) eller att den som äger LPU har avtal som gör den till personuppgiftsbiträde (PuB). Följande fyra användningsfall beskrivs.
Det krävs att LPU kan ta emot och behandla svaren från NPU som anges i exemplen nedan. Se Tjänstekontraktsbeskrivningen (TKB:n) för fullständig information och strukturen för de anrop och typer som returneras. Relaterad dokumentation
KonnektivitetSOAP-tjänst för att generera filer med sökta personposter och lista tillgängliga filer är tillgängliga via Nationell Tjänsteplattform (NTjP). NTjP saknar dock stöd för REST-baserade tjänster vilket medför att REST-tjänst för att hämta filer (ladda upp/ta bort) enbart är tillgänglig genom direktaccess mot tjänsteproducent. Anrop mot tjänsterna sker med HTTPS (Mutual-TLS) och validering av certifikatet från tjänstekonsument utförs för att endast tillåta att tjänsten levererar data till tillåtna mottagare. Det är endast beställaren (den som anropat ovan nämnda kontrakt) som kan hämta filerna. Certifikat för upprättande av mTLS-sessionen måste vara ett funtionscertifikat utgivet av SITHS. Samtliga system som går via NTjP måste kontakta Ineras kundtjänst på kundservice@inera.se för att kunna få direktaccess till filhämtning.
Förändringar av personposterTidpunkten för en förändring av en personpost anges i personpostens fält Version. Det finns flera händelser i Personuppgiftstjänsten som orsakar en ny tidsstämpel i detta fält.
TestpersonerVid anslutning mot pu.ineratest.org ska frågorna starta med uttrycket includetestidentities = 'true' för att få med de personer som specifikt är markerade som testpersoner, exempelvis: FROM PersonRecord WHERE includetestidentities = 'true' AND PopulationRegistrationLocality.CountyCode = '3'; Se dokumentationen för SimpleQL för mer information om uppbyggnad av frågor. GrunddataladdningGrundladda från geografiskt områdeGrundladda det lokala PU-systemet med personer från geografiska områden. Det kan vara allt från en länskod till en blandning av flera läns och kommunkoder. Vid hämtning av personer som LPU är PuA eller PuB för så får kontraktet med postfix Unrestricted användas. Detta kontrakt returnerar fullständiga personposter på de som matchar frågan oavsett om de är identitetsskyddade eller inte.
Exempelanrop
Grundladda med utomläningar och reservidentiterI vissa fall vill man hämta personuppgifter på personer som inte är folkbokförda inom sin egen region även kallade "utomläningar" eller så har man en lista på reservidentiteter som man vill hämta hem. I dessa fall är inte den egna regionen PuA eller PuB för dessa uppgifter och då är det inte tillåtet att nyttja kontraktet med postfix Unrestricted. Data som returneras då kan vara filtrerad p.g.a. identitetsskydd. Identitetsskydd kan vara i form av sekretessmarkeringsekretessmarkering eller skyddad folkbokföring. Ifall en personpost är skyddsmarkerad på detta sätt filtreras vanligtvis en stor del av personinformationen bort och leveransen sker enligt Profil 1 (se TKB för mer information om profiler).
Har er LPU behov av att hämta persondata om reservnummer så kan ni i denna query även skicka in dessa nummer. Då reservidentiteter inte kan identitetsskyddas så vet vi säkert att fullständig data returneras fast än vi inte använder oss av metoden med postfix Unrestricted.
Exempelanrop |
title | Exempelsvar |
Exemplet ovan där SearchPersonsForProfileByOrder anropas returneras ett id på max 36 tecken. Detta Order-Id används som inparameter till tjänsten GetFilesForOrderId som returnerar ett svar om var den resulterande filen kan hämtas. Ifall ordern inte är redo för nedladdning än så returneras inget svar vilket betyder att anropande tjänst får försöka igen senare. GetFilesForOrderId returnerar en url som ska användas för att hämta svarsfilen.
title | Exempelanrop
title | Exempelsvar |
Filens innehåll ser ut på samma vis som ett svar från ett vanligt anrop mot SearchPersonsForProfile, specifikationer finns som vanligt i TKB:n. Kodblock | | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
language | xml |
Kodblock | |||
---|---|---|---|
| |||
<?xml version='1.0' encoding='UTF-8'?> <ns2:SearchPersonsForProfileResponse xmlns:ns2="urn:riv:strategicresourcemanagement:persons:person:SearchPersonsForProfileResponder:3" xmlns:ns3="urn:riv:strategicresourcemanagement:persons:person:3" xmlns:ns4="urn:riv:itintegration:registry:1"> <ns2:personRecord> <ns3:personalIdentity> <ns3:root>1.2.752.129.2.1.3.1</ns3:root> <ns3:extension>198602212394</ns3:extension> </ns3:personalIdentity> <ns3:gender>1</ns3:gender> <ns3:protectedPersonIndicator>false</ns3:protectedPersonIndicator> <ns3:testIndicator>false</ns3:testIndicator> <ns3:primaryIdentity>true</ns3:primaryIdentity> <ns3:version>20190117180851</ns3:version> <ns3:name> <ns3:givenNameIndicator>10</ns3:givenNameIndicator> <ns3:givenName> <ns3:name>Moltas</ns3:name> </ns3:givenName> <ns3:surname> <ns3:name>Lundgren</ns3:name> </ns3:surname> </ns3:name> <ns3:birth> <ns3:dateOfBirth> <ns3:format>YYYY-MM-DD</ns3:format> <ns3:value>1986-02-21</ns3:value> </ns3:dateOfBirth> <ns3:birthAbroad> <ns3:placeOfBirthAbroad> <ns3:placeOfBirthAbroad>QUEBEC</ns3:placeOfBirthAbroad> </ns3:placeOfBirthAbroad> <ns3:countryOfBirth>KANADA</ns3:countryOfBirth> </ns3:birthAbroad> </ns3:birth> <ns3:populationRegistrationLocality> <ns3:populationRegistrationDate> <ns3:format>YYYY-MM-DD</ns3:format> <ns3:value>2007-08-10</ns3:value> </ns3:populationRegistrationDate> <ns3:countyCode>01</ns3:countyCode> <ns3:municipalityCode>80</ns3:municipalityCode> <ns3:propertyDesignation>BLÅKLINTEN 3</ns3:propertyDesignation> <ns3:fictitiousPropertyNumber>0</ns3:fictitiousPropertyNumber> </ns3:populationRegistrationLocality> <ns3:populationRegistrationRecord> <ns3:syncronizationTime>2019-01-17T18:08:51.000+01:00</ns3:syncronizationTime> <ns3:notificationCase> <ns3:modificationTime>2007-09-04T01:21:11.000+02:00</ns3:modificationTime> </ns3:notificationCase> <ns3:historicalRecords> <ns3:populationRegistrationLocality> <ns3:populationRegistrationDate> <ns3:format>YYYY-MM-DD</ns3:format> <ns3:value>2007-08-10</ns3:value> </ns3:populationRegistrationDate> <ns3:countyCode>01</ns3:countyCode> <ns3:municipalityCode>80</ns3:municipalityCode> <ns3:propertyDesignation>BLÅKLINTEN 3</ns3:propertyDesignation> <ns3:populationRegistrationType>FB</ns3:populationRegistrationType> </ns3:populationRegistrationLocality> </ns3:historicalRecords> </ns3:populationRegistrationRecord> <ns3:addressInformation> <ns3:residentialAddress> <ns3:postalAddress2>KAMMAKARGATAN 3</ns3:postalAddress2> <ns3:postalCode>11140</ns3:postalCode> <ns3:city>STOCKHOLM</ns3:city> </ns3:residentialAddress> <ns3:nationalKeys> <ns3:propertyId>100014022</ns3:propertyId> <ns3:addressPlaceId>491</ns3:addressPlaceId> <ns3:apartmentId>25605931</ns3:apartmentId> </ns3:nationalKeys> </ns3:addressInformation> <ns3:maritalStatus> <ns3:maritalStatusCode>OG</ns3:maritalStatusCode> </ns3:maritalStatus> <ns3:immigration> <ns3:immigrationDate> <ns3:format>YYYY-MM-DD</ns3:format> <ns3:value>2007-08-10</ns3:value> </ns3:immigrationDate> </ns3:immigration> <ns3:citizenship> <ns3:citizenshipCountryCode> <ns3:countryCode>SE</ns3:countryCode> </ns3:citizenshipCountryCode> </ns3:citizenship> </ns2:personRecord> <ns2:personRecord> <ns3:personalIdentity> <ns3:root>1.2.752.129.2.1.3.1</ns3:root> <ns3:extension>198602072392</ns3:extension> </ns3:personalIdentity> <ns3:gender>1</ns3:gender> <ns3:protectedPersonIndicator>false</ns3:protectedPersonIndicator> <ns3:testIndicator>false</ns3:testIndicator> <ns3:primaryIdentity>true</ns3:primaryIdentity> <ns3:version>20190108110923</ns3:version> <ns3:name> <ns3:givenNameIndicator>10</ns3:givenNameIndicator> <ns3:givenName> <ns3:name>Jens</ns3:name> </ns3:givenName> <ns3:surname> <ns3:name>Lööf</ns3:name> </ns3:surname> </ns3:name> <ns3:birth> <ns3:dateOfBirth> <ns3:format>YYYY-MM-DD</ns3:format> <ns3:value>1986-02-07</ns3:value> </ns3:dateOfBirth> <ns3:birthAbroad> <ns3:placeOfBirthAbroad> <ns3:placeOfBirthAbroad>GDANSK</ns3:placeOfBirthAbroad> </ns3:placeOfBirthAbroad> <ns3:countryOfBirth>POLEN</ns3:countryOfBirth> </ns3:birthAbroad> </ns3:birth> <ns3:populationRegistrationLocality> <ns3:populationRegistrationDate> <ns3:format>YYYY-MM-DD</ns3:format> <ns3:value>2007-08-22</ns3:value> </ns3:populationRegistrationDate> <ns3:countyCode>01</ns3:countyCode> <ns3:municipalityCode>82</ns3:municipalityCode> <ns3:propertyDesignation>SLUT 1:10</ns3:propertyDesignation> <ns3:fictitiousPropertyNumber>0</ns3:fictitiousPropertyNumber> </ns3:populationRegistrationLocality> <ns3:populationRegistrationRecord> <ns3:syncronizationTime>2019-01-08T11:09:23.000+01:00</ns3:syncronizationTime> <ns3:notificationCase> <ns3:modificationTime>2007-09-11T10:53:18.000+02:00</ns3:modificationTime> </ns3:notificationCase> <ns3:historicalRecords> <ns3:populationRegistrationLocality> <ns3:populationRegistrationDate> <ns3:format>YYYY-MM-DD</ns3:format> <ns3:value>2007-08-22</ns3:value> </ns3:populationRegistrationDate> <ns3:countyCode>01</ns3:countyCode> <ns3:municipalityCode>82</ns3:municipalityCode> <ns3:propertyDesignation>SLUT 1:10</ns3:propertyDesignation> <ns3:populationRegistrationType>FB</ns3:populationRegistrationType> </ns3:populationRegistrationLocality> </ns3:historicalRecords> </ns3:populationRegistrationRecord> <ns3:addressInformation> <ns3:residentialAddress> <ns3:postalAddress2>FINNBODAVÄGEN 2</ns3:postalAddress2> <ns3:postalCode>13131</ns3:postalCode> <ns3:city>NACKA</ns3:city> </ns3:residentialAddress> <ns3:nationalKeys> <ns3:propertyId>100294037</ns3:propertyId> <ns3:addressPlaceId>1259</ns3:addressPlaceId> <ns3:apartmentId>25717466</ns3:apartmentId> </ns3:nationalKeys> <ns3:district> <ns3:districtCode>101259</ns3:districtCode> </ns3:district> </ns3:addressInformation> <ns3:maritalStatus> <ns3:maritalStatusCode>OG</ns3:maritalStatusCode> </ns3:maritalStatus> <ns3:immigration> <ns3:immigrationDate> <ns3:format>YYYY-MM-DD</ns3:format> <ns3:value>2007-08-22</ns3:value> </ns3:immigrationDate> </ns3:immigration> <ns3:citizenship> <ns3:citizenshipCountryCode> <ns3:countryCode>SE</ns3:countryCode> </ns3:citizenshipCountryCode> </ns3:citizenship> </ns2:personRecord> </ns2:SearchPersonsForProfileResponse> |
Hämta uppdateringar
Uppdatera personer från ett geografiskt område
Grundladdningsfrågan kan utökas med att endast hämta uppgifter som blivit uppdaterade sedan en viss tidpunkt. Tidpunkten för när en personpost uppdaterades hittar man i fältet Version. Se exempel-frågan nedan.
En personpost får ny version inte bara när Skatteverket gör förändringar utan även när andra förändringar sker som t.ex. förändring av kontaktuppgifter via 1177.
Exempelanrop
Kodblock | ||||
---|---|---|---|---|
| ||||
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:riv:itintegration:registry:1" xmlns:urn1="urn:riv:strategicresourcemanagement:persons:person:SearchPersonsForProfileByOrderUnrestrictedResponder:3"> <soapenv:Header> <urn:LogicalAddress>SE165565594230-1000</urn:LogicalAddress> </soapenv:Header> <soapenv:Body> <urn1:SearchPersonsForProfileByOrderUnrestricted> <urn1:query>FROM PersonRecord WHERE (PopulationRegistrationLocality.CountyCode IN ("05","06","07") OR (PopulationRegistrationLocality.CountyCode = "12" AND PopulationRegistrationLocality.MunicipalityCode = "87")) AND Version >= "20190220095204";</urn1:query> <urn1:queryLanguage>SimpleQL</urn1:queryLanguage> <urn1:profile>P5</urn1:profile> </urn1:SearchPersonsForProfileByOrderUnrestricted> </soapenv:Body> </soapenv:Envelope> |
Uppdateringar på utomläningar och reservidentiteter
Från och med version 4.6 av Personuppgiftstjänsten rekommenderar Inera att man använder filsökningstjänsten för att hämta hem specifika identiteter. Dessa identiteter läggs helt enkelt i en textfil och laddas upp till REST-tjänsten SearchPersonByFile. Läs mer om denna funktion i
stycketstycket Söka personuppgifter via fil i dokumentet Filhantering.
Detektera utflyttade från angivna regioner
Personuppgiftstjänsten håller endast totalposter av folkbokföringsregistret och håller inte själv någon förändringshistorik. Det gör det omöjligt att likt Skatteverket leverera aviseringsfiler med enskilda förändringar och orsakskoder för förändringarna.
Det som finns från Skatteverket är deras lista med historiska poster. Problemet med en historisk post från Skatteverket är att de endast innehåller ett start-datum för när en sådan post började gälla och inte något datum för när den slutade gälla. Därför har det tidigare inte gått att ställa frågan för att detektera vilka som har flyttat från de län som LPU håller personposter för: "-Ge mig alla personposter som har en historisk post i mina län med slutdatum senare än sist jag frågade."
Från och med version 4.6 av Personuppgiftstjänsten försöker dock tjänsten själv att detektera förändringar i Skatteverkets historiska poster och själv skriva ett slutdatum för en historisk post. När en personpost har ett slutdatum på en historikpost finns möjligheten att ställa SimpleQL-frågan "ge mig alla personposter som har en historisk post i mitt län och där den historiska posten har ett slutdatum senare än sist jag frågade men som också har en nuvarande länskod som skiljer sig från mitt läns".
Denna fråga kan ställas som separat fråga för att rensa bort utflyttade eller kombineras med en fråga som de i exemplen ovan.
Exempel på frågan "ge mig alla personposter av typen personnummer som inte bor i län 23 och som är förändrade sedan sist jag frågade 2022-01-26 kl. 00:00:00 men som också har en historisk post i län 23 som är avslutad sedan sist jag frågade 2022-01-26 kl. 00:00:00".
Exempelanrop
Kodblock | ||||
---|---|---|---|---|
| ||||
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:riv:itintegration:registry:1" xmlns:urn1="urn:riv:strategicresourcemanagement:persons:person:SearchPersonsForProfileByOrderResponder:3"> <soapenv:Header> <urn:LogicalAddress>SE165565594230-1000</urn:LogicalAddress> </soapenv:Header> <soapenv:Body> <urn1:SearchPersonsForProfileByOrder> <urn1:query>FROM PersonRecord WHERE (PopulationRegistrationLocality.CountyCode NOT IN ("23") AND personalidentity.root = "PNR" AND Version > "20220126000000") AND (PopulationRegistrationRecord.HistoricalRecords.HistoricalRegistrations.CountyCode = "23" AND personalidentity.root = "PNR" AND PopulationRegistrationRecord.HistoricalRecords.HistoricalRegistrations.LocalRegistrationEndTime > "20220126000000");</urn1:query> <urn1:queryLanguage>SimpleQL</urn1:queryLanguage> <urn1:profile>P5</urn1:profile> </urn1:SearchPersonsForProfileByOrder> </soapenv:Body> </soapenv:Envelope> |
Nedan följer ett exempel på den enda historik som som kommer från Skatteverket.
Exempel på Historical Records från Skatteverket
Kodblock | ||
---|---|---|
| ||
<historicalRecords> <populationRegistrationLocality> <populationRegistrationDate> <format>YYYY-MM-DD</format> <value>2016-05-31</value> </populationRegistrationDate> <countyCode>23</countyCode> <municipalityCode>80</municipalityCode> <propertyDesignation>SPRÄNGAREN 6</propertyDesignation> <populationRegistrationType>FB</populationRegistrationType> </populationRegistrationLocality> <populationRegistrationLocality> <populationRegistrationDate> <format>YYYY-MM-DD</format> <value>2005-11-25</value> </populationRegistrationDate> <countyCode>23</countyCode> <municipalityCode>09</municipalityCode> <propertyDesignation>HÖGSTALÄGDEN 7:1</propertyDesignation> <populationRegistrationType>FB</populationRegistrationType> </populationRegistrationLocality> </historicalRecords> |
Persistering vid användandet av både restricted och unrestricted-kontrakten.
Då det finns två kontrakt som returnerar olika mängder data så är det viktigt att anropen mot SearchPersonsForProfileByOrderUnrestricted sker sist i grundladdningen och uppdateringsflödet.
Ett exempel där det annars kan ge oönskade effekter är:
Avisering på länskod 12 med kontrakt SearchPersonsForProfileByOrderUnrestricted resulterar i att en fullständig personpost hämtas för t.ex 191212121212.
Resulterar i att LPU sparar en fullständig personpost för 191212121212 till sin databas.Avisering på personer som flyttat från län 12 med kontrakt SearchPersonsForProfileByOrder, 191212121212 har flyttat från län 12 till en ny adress inom län 12. Vi får träff på 191212121212.
Resulterar i att LPU skriver över den fullständiga posten som LPU hade hämtat hem tidigare, 191212121212 riskerar nu att endast innehålla en del av personposten på grund av filtreringen som sker då personen har ett identitetsskydd.