4.9 Release Notes
Dokumenthistorik
Datum | Version | Namn | Förändring |
---|---|---|---|
Feb 27, 2023 | 0.1 | @Former user (Deleted) | Dokument upprättat |
Mar 7, 2023 | 0.2 | @Former user (Deleted) | Alla tre förändringar beskrivna |
Mar 28, 2023 | 1.0 | @Former user (Deleted) | Publicerad version |
Innehåll
Personuppgiftstjänsten 4.9 Release Notes
Release-datum:
Test/NTjP QA | Mar 10, 2023 |
---|---|
Produktion | Apr 13, 2023 |
Förändringar
Denna version innehåller:
Algoritmen för beräkning av huvudidentitet har uppdaterats för att möjliggöra att länkningar mellan identiteter alltid skapas när hänvisningar mellan identiteter finns i Navets grunddata, samt att i samtliga fall då länkade identiteter finns kunna utse en huvudidentitet.
Relationer i personposter filtreras nu så att personposter som returneras i svar inte längre kan innehålla en make/maka eller partner trots att personen är skild från sagda make/maka eller partner.
Födelsedatum är nu ett tillgängligt attribut i profil 1 och uppåt, vilket innebär att det alltid returneras i svar, även för tjänstekontrakt som inte är av typ Unrestricted.
Webbservice och Webbgränssnitt
Uppdaterad algoritm för huvudidentitet och länkningar
Att kunna utse en huvudidentitet bland flera länkade identiteter är en förutsättning för att vid sökningar kunna välja att som svar få eventuell huvudidentitet som sökt identitet är kopplad till. Den tidigare algoritmen för beräkning av huvudidentitet byggde på att det alltid måste finnas en entydigt aktuell identitet i en kedja med länkade identiteter. Om flera identiteter var aktuella eller om ingen av identiteterna var aktuell så har ingen huvudidentitet kunnat utses, vilket även inneburit att inga länkningar mellan identiteterna då har skapats. Med den nya algoritmen kommer en huvudidentitet alltid att utses, utifrån kompletterade kriterier om vad som skall ske i de tidigare ohanterade fallen.
Se algoritm för huvudidentitet och länkningar för komplett dokumentation om den nya algoritmen.
Filtrering av Relationer för skilda personer
Förändring: Som en användare av Personuppgiftstjänstens tjänstekontrakt får jag inte längre i svaren med relationer av typen make/maka eller partner för personidentiteter som har status skild respektive skild partner, så att jag inte kan misstolka dessa relationer som att de är aktiva.
Förändringen handlar om relationer från en personidentitet till andra personer, tex relationen make/maka, vilket lagras i klass RelationshipType i Inera PU-tjänst. Ett status-attribut för relationer (RelationshipType → status) finns men kommer alltid att vara tomt i Inera Personuppgiftstjänst, oavsett vilken information som finns i motsvarande fält i Skatteverkets Navet (Relation status, Termkod 02008). Detta på grund av att fältet ej aviseras via de totalposter från Navet som Inera Personuppgiftstjänst prenumererar på från Skatteverket. Normalt aviserar Skatteverket endast aktuella relationer, ej avslutade, vilket gör att de inte alls kommer att finnas i Inera PU-tjänst och att avsaknaden av data i status-fältet ej är av större vikt, men i vissa undantagsfall aviserar Skatteverket relationer även då de har status avslutad. I Inera PU-tjänst har det därmed kunnat förekomma Relationer som i Navet har status avslutad, men som i PU-tjänsten har tomt statusfält vilket normalt indikerar att relationen är aktiv/aktuell. Dessa undantagsfall har varit relationer av typ make/maka eller partner, som alltså har kunnat förekomma i Inera PU-tjänst med tomt status-värde även då de i Navet har status avslutad.
Risken som anslutna kunder till Inera Personuppgiftstjänst har identifierat är att de i verksamheten felaktigt kan få intrycket att till exempel en person fortfarande är gift med en annan person, och då delge den förmodade maken/makan information som den ej hade rätt att ta del av. Därför införs i denna Release nu en filtrering av svaren från alla relevanta tjänstekontrakt, så att dessa avslutade relationer inte inkluderas.
Vid skapande av svar på tjänstekontraktsanrop där en personidentitets Relationer (SKV: Termkod 02000, PU: Klass RelationshipType) kan förekomma så skall vid specifika fall aktuell Relation EJ inkluderas i svaret. Dessa undantagsfall då inkludering ej skall ske definieras av att alla följande kriterier ska vara uppfyllda:
Aktuell personidentitet har i SKV fält "CivilstandKod" (Termkod 01081) ett värde som antingen är "S" (för Skild) eller "SP" (för Skild partner).
Aktuell Relation (Termkod 02000) har i SKV fält "Relationstyp" (Termkod 02003) ett värde som antingen är "M" (för Make/maka) eller "P" (för Partner).
Födelsedatum tillgängligt i Profil 1
Regionkunder har identifierat att det faktum att födelsedatum inte alltid visas för sekretessmarkerade personer innebär en patientrisk, eftersom födelsedatumet i många fall krävs i verksamhetssystem för att upprätthålla patientsäkerheten, samtidigt som födelsedatum inte alltid motsvaras av datumdelen i ett personnummer. Följande förändring har därför införts: Attributet Födelsedatum (BirthType → dateOfBirth) har tidigare endast varit tillgängligt om en sökfråga ställs med Profil 4 eller högre, men kommer nu att ingå redan från Profil 1, det vill säga alltid vara tillgängligt oavsett vilken profil som väljs. Detta innebär också att Födelsedatum kommer att vara tillgängligt för personposter med sekretessmarkering oavsett vilken typ av tjänstekontrakt som används (-Unrestricted eller ej).
Dokumentation
Se menyutgång dokumentation
Användarhandbok
Se Användarhandbok Personuppgiftstjänsten
Tjänstekontrakt
Inga förändringar.
Systemdokumentation
Guide till Personuppgiftstjänsten
Se Guide till Personuppgiftstjänsten
Installation av Personuppgiftstjänsten
Installation och Administration
Hanteras av driftleverantör.
Uppgradering från tidigare release
Hanteras av driftleverantör.