SAD - Lösningsarkitektur

Innehåll



Dokumentinformation

Syfte

Syftet med detta dokument är att beskriva systemarkitektur och teknisk realisering för den nationella personuppgiftstjänsten, samt vilka styrande behov och krav som legat bakom denna realisering.

Målgrupp

De huvudsakliga målgrupperna för detta dokument är beställare, arkitekturledningen, systemarkitekter och utvecklingsteam.

Revisionsinformation



Version

Författare

Datum

Kommentar

Version

Författare

Datum

Kommentar

0.1

@Former user (Deleted)

Mar 22, 2016 

Första utkastet

0.2

@Former user (Deleted)

Apr 28, 2016 

Ändringar i samband med korrekturläsning

1.0

@Former user (Deleted)

Aug 30, 2016 

Fastställd

1.1

@Former user (Deleted)

Nov 26, 2016 

Tillägg och revidering för PU 2.1

1.2

@Former user (Deleted)

Jun 12, 2017 

Tillägg och revidering för PU 3.0

1.3

@Former user (Deleted)

Feb 15, 2018 

Uppdaterad med beräkning av kön

1.4

@Former user (Deleted)

Mar 28, 2018 

Justeringar för release 3.0.3 Apr 28, 2018

Lagt till information om sekretessmarkering 

1.5

@Former user (Deleted)

Apr 3, 2019 

Uppdaterat för PU 4

1.6

@Former user (Deleted)

Sep 20, 2019 

Uppdaterat med antalsbegränsning för synkront avancerat personsök

1.7

@Former user (Deleted)

Oct 27, 2019 

Lagt till info om Skyddad Folkbokföring och gränssnitt för att tvinga en SKV-uppdatering av personpost

1.8

@Former user (Deleted)

Jun 23, 2020 
 

Tjänstekontrakt v1 och v2, referens

1.9

@Former user (Deleted)

Oct 2, 2020 

Aktualitet för invånare i Region Stockholm

2.0

@Former user (Deleted) 

Sep 29, 2021 

Kopierad från version 4.3 och anpassad för version 4.6

3.0

@Former user (Deleted) 

Apr 6, 2022 

Anpassad för version 4.7

4.0

@Former user (Deleted) 

Aug 9, 2023 

Anpassad för extern publicering





Begreppslista

Begrepp

Beskrivning

Begrepp

Beskrivning

PU-tjänst

Förkortning för personuppgiftstjänst

Navet

Skatteverkets tjänst som används som informationskälla för personuppgifter för svenska medborgare. Tjänsten riktas till myndigheter

SKV

Skatteverket

SOAP

Protokoll för datakommunikation

REST

Protokoll för datakommunikation

NTjP

Nationell Tjänsteplattform

PNR

Personnummer

SNR

Samordningsnummer

LRID

Lokal reservidentitet

NRID

Nationell reservidentitet



Översiktlig beskrivning

Inledning

Syftet med en nationell PU-tjänst är att erbjuda en gemensam tjänst för regioner, kommuner och system inom vården, där de personuppgifter som behövs inom verksamheten finns att tillgå. Främsta anledningen till detta är att kostnaden för att hämta folkbokföringsuppgifter från Skatteverket annars är hög, då varje region/kommun var och en måste hämta dessa från Skatteverket.

Det finns även andra anledningar till en nationell PU-tjänst:

  • Kunna tillgodose hög tillgänglighet - Skatteverket lämnar inga SLA:er på Navet.

  • Svarstider - Skatteverket lämnar inga garantier på svarstider.

  • Aktualitet - Nationell PU-tjänst kan ha hög aktualitet på personuppgifter.

  • Möjliggöra personsök och uttag av data givet olika parametrar.

  • Stöd för nationella och lokal reservidentiteter.

  • Stöd för individens kontaktuppgifter.

Det har gjorts en förstudie kring behovet av en gemensam PU-tjänst av Inera, där det genomförts intervjuer med bl.a. SLL, Skåne, VGR, Skatteverket och Datainspektionen. Utöver förstudien har regelbundna referensgruppsmöten genomförts där landstingen inkommit med krav och verksamhetsspecifika behov. Denna PU-tjänst är resultatet av detta förarbete. Fortsatt utveckling av tjänsten sker genom samarbete mellan Inera och landstingen.

Sammanfattning

En nationell personuppgiftstjänst som alla regioner och landsting ska kunna nyttja behöver en arkitektur som kan hantera personuppgifter för samtliga folkbokförda personer i landet. Den måste vara redundant för att kunna hålla hög tillgänglighet, skalbar för att kunna hålla bra svarstider och kunna nyttja navets aviseringsfiler samt hämta enskilda personposter för att ha hög aktualitet på personuppgifterna. Gällande regelverk kräver att den nationella PU-tjänsten behöver ett avtal per region/landsting, vilket innebär att nationella PU-tjänsten får hämta en aviseringsfil per region/landsting.





Konsument

Konsumenter för PU-tjänsten kan vara vård- och omsorgssystem som hanterar patienter/invånare, men kan även vara system som hanterar medarbetare, katalogsystem, identitetshanteringssystem etc. Dessa finns både som Nationella och lokala/regionala e-tjänster.

Regional PU-tjänst

Arkitekturen tillåter lokala/regionala PU-tjänster, även om det kostnadsmässigt vore optimalt med enbart den nationella PU-tjänsten. Dock vore det önskvärt att dessa PU-tjänster fyller sina mellanlager med data från den nationella PU-tjänsten istället för via Navet för att minska kostnader. Nationell PU-tjänst tillhandahåller en aviseringsstrategi för att hålla Regional PU-tjänst uppdaterad. Detta för att kunna genomföra en gradvis övergång från nuläge till önskad målbild.

Nationell PU-tjänst

Den gemensamma PU-tjänsten kan nyttjas av både nationella samt regionala konsumenter. Arkitekturen på nationella PU-tjänsten är sådan att den klarar en redundant och skalbar miljö med minst två databasservrar.

Målbild och principer

Verksamhetsmässiga mål

  • Minska kostnad för personuppgifter hos regioner och landsting.

  • Öka den tekniska tillgängligheten på personuppgifter.

  • Säkerställa god aktualitet på personuppgifter.

  • Personuppgifter ska kunna hämtas via ett webbaserat användargränssnitt eller via integration mot webbtjänstegränssnitt.

  • Inloggade användare ska vara starkt autentiserade med hjälp av SITHS-kort.

  • Tillhandahålla aviseringsstrategi för att kunna hålla lokal PU-tjänst uppdaterad

  • Tillhandahålla stöd för reservidentiteter på både nationellt och lokala format

  • Tillhandahålla stöd individens egna kontaktuppgifter

  • Tillhandahålla stöd för koppling av identiteter

  • Tillhandahålla stöd för identitetsstyrkning via bilagor

Arkitekturella mål

Övergripande mål

  • Följsamhet mot Nationella IT-strategin.

  • Följsamhet mot RRR:er från Arkitekturledningen.

  • Samverkan med externa system ska så långt som möjligt utformas i enlighet med gällande versioner av tekniska anvisningar såsom T-bokens referensarkitektur, tekniska målbilder för nationella tjänster och RIV tekniska anvisningar.

  • Återanvändning av nationellt framtagen och driftsatt infrastruktur maximeras.

  • Samverka mellan flera datakällor med olika informationsägare

Specifika mål

  • Nationella PU-tjänsten ska klara en hög belastning och kunna leverera bra svarstider, och skalas upp vid behov.

  • Tjänstegränssnitt (tjänstekontrakt) för all extern funktionalitet utan krav på specifik lokalt installerad programvara (Software Development Kit, SDK).

  • RIVTA2.1 Säkerhetsmodell ska gälla för tjänstegränssnitten.

  • Tillhandahålla personuppgifter till konsumenter genom RIV tjänstekontrakt.

Planerade avsteg

Inga planerade avsteg.

Prioriterade områden

Den nationella PU-tjänsten ska klara en hög belastning, leverera data med bra svarstider och ha hög teknisk tillgänglighet. Det ska även vara möjligt att skala upp driftsmiljö om belastningen påverkar svarstider. Därför skall systemet utvecklas med tekniker som kan klara en hög belastning samt vara skalbara.

PU-tjänsten skall logisk särskilja personuppgifter utifrån vilken region/landsting som är PuA för den aktuella uppgiften. Detta då SKV ej tillhandahåller personuppgifter till Inera som kund, utan enbart till Landsting (PuA) där Inera får agera biträde (PuB).

Avgränsningar

Inga planerade avgränsningar.

Teknisk lösning

Översikt

Nationella PU-tjänsten driftas i Ineras Kubernetes-miljö.

I plattformen ingår grundläggande teknik såsom autentisering, webbtjänstestack, loggning och persistenshantering. På plattformen läggs sedan den den nationella verksamhetsmodulen för PU-tjänsten. Följande skiktning gäller: 

  • Persistenslagret: Hanterar hämtning av data från databaser.

  • Tjänstelagret: Hanterar autentisering, behörighetskontroll, validering, loggning, transaktionshantering, verksamhetslogik samt kommunikation mot Navet.

  • Webbtjänstelagret:

    • SOAP: Transformerar XML-data till tjänsteobjekt och vice versa.

    • REST: Hanterar GET/POST/PUT/DELETE för tillgängliga REST-tjänster.

  • GUI-lagret: Hanterar OIDC-autentisering mot Ineras IdP och webbsidor för slutanvändare.





Arkitekturellt signifikanta delar av lösningen

Autentisering via SITHS-certifikat och Ineras IdP

PU-tjänstens webbapplikation använder Ineras IdP för OIDC-autentisering och SITHS-certifikat som autentiseringsteknik. I användarens token/biljett lagras certifikatsuppgifter och egenskaper från HSA-katalogen som användaren fått vid autentiseringen. Dessa uppgifter följer användaren under dennes HTTP-session. 
Då slutanvändare skall autentisera sig mot webbapplikation samt då en systemkonsument skall anropa webbtjänstegränssnittet måste dessa klienter presentera sitt certifikat. Certifikaten som används måste vara utfärdade av SITHS. Mjuka funktionscertifikat för systemkonsumenter och ett SITHS-kort för slutanvändare av PU-tjänstens webbapplikation.

Auktorisation

Åtkomst från systemkonsument via tjänstekontrakt styrs genom att man i tjänsten konfigurerar vilka certifikat som är behöriga. Auktorisation kan även hanteras i Tjänsteplattform om tjänster konsumeras via sådan.

HSA Webbtjänst (HSA-WS)

PU-tjänstens webbapplikation kräver att användare finns upplagda i den HSA-katalog som den använda autentiseringstjänsten är kopplad till. Användarens HSA-id från dennes SITHS-kort måste vara åtkomligt i HSA-katalogen och finnas upplagd med rätt systemroll för att användaren skall ges åtkomst till användargränssnittet. Det förutsätts att användaren arbetar inom ett medarbetaruppdrag då uppgifter om aktuell vårdgivare är en del av uppföljningsdata.

Webbtjänster

Integrerande systemkonsument kan anropa personuppgiftstjänsten med SOAP-WS. Denna teknik följer RIV 2.1-standarden, se referens R2.

Hantering av bilagor

PU-tjänsten hanterar uppladdning samt nerladdning av binära filer genom en kombination av SOAP-WS och REST API i enlighet med ARK_0038, se referens R3. Hantering av bilagor dokumenteras under egen avdelning, se Filhantering.

Huvudidentitet och koppling av identiteter

Då flera personidentiteter kan identifiera samma identitet (reservidentitet, samordningsnummer, personnummer o.s.v.) har PU-tjänsten stöd för koppling av personidentitet. När identiteter kopplas så kommer alltid en identitet vara den som anses vara den nu gällande, och denna identitet får då begreppet Huvudidentitet.

Se vidare under Användningsfall Koppla personidentiteter.

Logisk arkitektur

Se sammanfattning

Användargränssnitt

Användargränssnitt för hälso- och sjukvårdspersonal

Användargränssnittet är framtaget med ramverket Angular och är kompatibelt med alla de större webbläsarna på marknaden idag.

Utformning av användargränssnitt (UX)

Användargränsnittet innehåller tre huvudområden enligt figuren nedan. 1 är menyn för funktionsval, 2 är toppmenyn med allmän information och 3 är vyn som visar information beroende på funktionsval. 



Kravbild för tillgänglighetskrav

PU-tjänsten har som mål att följa de riktlinjer för webbläsarstöd som tas fram inom e-klient.

För inloggning i användargränssnittet är PU-tjänsten beroende av tekniken i autentiseringstjänsten där NetId nyttjas tillsammans med en kortläsare med SITHS-kort alternativt mobilt SITHS för de organisationer som nyttjar det.

Känd problembild vid autentisering

Den nationella autentiseringstjänsten hanterar läsning av användarens SITHS certifikat via NetId's plugin till webbläsaren. I dagsläget minskar stöd för sådan plugins, och nuvarande status är att Chrome och Microsoft Edge kan användas för inloggning medan Firefox inte har stöd för NetId-inoggning. Däremot skall mobil autentisering fungera även med Firefox.

Användningsfall

PU-tjänstens användningsfall finns realiserad som webbtjänster och som en del i tjänstens webbapplikation. Den finns även tillgänglig i användargränssnittet.

Hämta personuppgifter för person utifrån personidentitet

  1. Användare jobbar med en eller flera personer i e-tjänst. E-tjänsten behöver personuppgifter på dessa.



    1. E-tjänsten begär personuppgifter via webbtjänstegränssnitt. 0 till 500 personidentiteter kan efterfrågas i samma fråga.

    2. Användaren loggar in i PU-tjänstens webbapplikation för att manuellt hämta personuppgifterna till e-tjänsten.

  2. PU-tjänsten söker fram och returnerar matchande identiteter. Beroende på sökvillkor returneras antingen efterfrågad identitet eller dess matchande huvudidentitet.

Sök personuppgifter utifrån parametrar

Synkront

Används då en aktör är i behov av att söka rätt på en persons identitet utifrån givna parametrar. Exempelvis namn och adress. Resultatet begränsas i antal (500) och det efterfrågade uppgifterna returneras direkt i tjänstens svar till aktören.

  1. Användaren jobbar med en person i en e-tjänst, men saknar korrekt personidentitet på denne. Övrig information om personen finns.

  2. Antingen söker e-tjänsten personuppgifter via webbtjänstegränssnitt (2a) eller så får användaren logga in i PU-tjänstens webbapplikation (2b) för att söka personuppgifterna till e-tjänsten.

    1. Via PU-tjänstens webbapplikation sker sökning genom att fylla i 1..n fördefinierade textfält.

    2. Via WS-gränssnitt sker sökning i enlighet med tjänstens tjänstekontrakt. Inparameter för fråga sker enligt syntax definierad i SimpleQL.

Asynkront

Via tjänstekontrakt

Används främst för att göra urval där ett större sökresultat förväntas. Exempelvis "alla män mellan 40 och 50 år inom Region Östergötland". Resultat returneras i form av ett orderid som används vidare i flöde för hämtning av filer.

  1. Användaren jobbar i en e-tjänst, och behöver identitetsdata för ett urval av parametrar.

  2. Via WS-gränssnitt sker sökning i enlighet med tjänstens tjänstekontrakt. Inparameter för fråga sker enligt syntax definierad i SimpleQL.

  3. PU-tjänsten skapar ett orderId för beställningen och returnerar till frågande part.

  4. PU-tjänsten söker ut data och skapar en XML-fil.

  5. E-tjänsten frågar efter färdiga filer för tidigare erhållet orderId

  6. PU-tjänsten returnerar uppgifter om var färdig fil kan hämtas.

  7. E-tjänst hämtar beställd fil

Via uppladdad fil

Från och med version 4.6 finns möjlighet att ladda upp en fil med personidentiteter och tillhörande identifierare för identitetstyp (OID). Denna funktion kan t.ex användas för att hämta hem uppdateringar för regions "utomläningar".

  1. Anropande system iordningställer en radbruten CSV-fil med identitet och OID för de identiteter man vill ha hem. Ex. 191212121212;1.2.752.129.2.1.3.1

  2. Via REST-gränssnitt laddas filen upp till personuppgiftstjänsten. Inparametrar anges för profile (mandatory), fromDate (optional), maxResultsPerFile (optional) och primaryidentity (optional)

  3. PU-tjänsten skapar ett orderId för beställningen och returnerar till frågande part.

  4. PU-tjänsten söker ut data och skapar en XML-fil.

  5. E-tjänsten frågar efter färdiga filer för tidigare erhållet orderId

  6. PU-tjänsten returnerar uppgifter om var färdig fil kan hämtas.

  7. E-tjänst hämtar beställd fil

Aviseringar

Personuppgiftstjänsten erbjuder inte någon ren aviseringsfunktionalitet som liknar den man kan få från Skatteverket. Istället kan man använda sig av frågespråket SimpleQL för att t.ex uppdatera en lokal cache med personuppgifter.

Bilagor

PU-tjänsten hanterar uppladdning, hämtning, samt borttag av bilagor till en given identitet. Bilagor hanteras via REST-tjänst och kräver direktanslutning gentemot PU-tjänsten (dvs NTjP kan ej användas).

För vidare information om hantering av bilagor, se Filhantering.

Hämta kontaktuppgifter för person utifrån personidentitet

En identitets kontaktuppgifter går att erhålla via tjänst för att hämta personuppgifter, men detta användningsfall finns till för att tillgodose behov där en konsument har rätt att hämta kontaktuppgifter, men ej personuppgifter.

  1. Användare jobbar med en eller flera personer i e-tjänst. E-tjänsten behöver kontaktuppgifter på dessa.


    1. E-tjänsten begär kontaktuppgifter via webbtjänstegränssnitt.

    2. Användaren loggar in i PU-tjänstens webbapplikation för att manuellt hämta kontaktuppgifter till e-tjänsten.


  2. PU-tjänsten söker fram och returnerar matchande kontaktuppgifter.

Som alternativ till ovan flöde kan det vara individen själv som vill hämta sina lagrade kontaktuppgifter. Detta kan erbjudas via en vårdportal (såsom 1177) där individen själv har möjlighet att se sina lagrade kontaktuppgifter.

Uppdatera reservidentitet

Uppdatering av personuppgifter för en given reservidentitet kan ske både via WS-tjänst, samt via PU-tjänstens tillhandahållna GUI. Indata till den uppdaterande tjänstens är alltid totalen av hur de nya uppgifterna skall se. Dvs det är inte förändringarna som skickas in, utan hur man vill att det nya resultatet skall se ut. Att inte skicka in en uppgift innebär att den uppgiften skall raderas. Samma tjänst används för att följande flöden:

Skapa ny Nationell reservidentitet

  1. Aktör loggar in PU-tjänsten eller ansluten e-tjänst.

  2. Aktör anger optionellt födelsedatum samt optionellt kön

  3. PU-tjänsten skapar ett ny nationellt reservidentitet som returneras.

Lägg till befintligt Lokal reservidentitet

  1. Aktör loggar in PU-tjänsten eller ansluten e-tjänst.

  2. Aktör anger lokal reservidentitet samt OID för dess domän.

  3. PU-tjänsten sparar befintlig lokal reservidentitet och returnerar resultatet.

Uppdatera reservidentitet

  1. Aktör loggar in PU-tjänsten eller ansluten e-tjänst.

  2. Aktören söker fram uppgifter för den identitet som man vill uppdatera.

  3. PU-tjänsten returnerar tidigare sparade uppgifter

  4. Aktören ändrar/tar bort/lägger till uppgifter och skickar in den totala personuppgiftsposten till PU-tjänsten

  5. PU-tjänsten sparar uppgifterna.

Uppdatera kontaktuppgifter

En identitets kontaktuppgifter skall uppdateras. Detta kan ske av personal som nyttjar e-tjänst, eller av individen själv via en vårdportal (såsom 1177).

  1. Aktören loggar in i en tjänst för att uppdatera kontaktuppgifter. Detta kan vara e-tjänst för vård och omsorg eller en vårdportal för individen själv.

  2. Tidigare lagrade kontaktuppgifter söks fram och presenteras.

  3. Uppgifterna förändras, och den totala datamängden för kontaktuppgifter skickas till PU-tjänsten.

  4. PU-tjänsten sparar uppgifterna och returnerar resultat från operationen.

Koppla personidentiteter

Användningsfallet består av 2 delar. Koppling av personidentiteter samt isärkoppling av personidentiteter.

Koppling av personidentiteter kan ske enligt följande:

PNR → PNR. SKV

SNR → SNR: SKV

SNR → PNR: SKV

NRID → NRID: Vården

NRID → SNR: Vården

NRID → PNR: Vården

LRID → NRID: Vården

Förenklat gäller alltså följande kedja för kopplingar: LRID → NRID → SNR → PNR

Kopplingar sparar ingen hierarkisk information, utan enbart enligt en platt struktur. Nedan bild symboliserar hur ett resultatet av ett flöde av kopplingar ser ut.



Koppla identitet

  1. Aktör loggar in PU-tjänsten eller ansluten e-tjänst.

  2. Aktören söker fram uppgifter för den identitet som man vill koppla annan identitet till.

  3. Aktören söker fram uppgifter för den identitet som man vill koppla till tidigare sökta identitet.

  4. Aktör begär koppling

  5. PU-tjänsten utför koppling

Koppla isär identitet

  1. Aktör loggar in PU-tjänsten eller ansluten e-tjänst.

  2. Aktören söker fram uppgifter för den identitet som man vill koppla isär en identitet ifrån.

  3. Aktören anger den kopplade identitet som man vill koppla ifrån.

  4. Aktör begär isärkoppling

  5. PU-tjänsten utför isärkoppling

Upprätthålla lokalt mellanlager av SKV-data

PU-tjänsten skall upprätthålla ett lokalt mellanlager av personuppgiftsdata från SKV. Ett lokalt mellanlager krävs för att PU-tjänsten skall kunna tillgodose de krav som ställs gällande tillgänglighet och svarstider. Ett lokalt mellanlager är även ett krav för att kunna tillhandahålla funktionalitet såsom personsök och urval.

Nyttja Navetavisering (SKV)

För att kunna upprätthålla ett internt och så när till komplett mellanlager av SKV data skall PU-tjänsten hämta och läsa in navet-aviseringar med högsta tillgängliga frekvens. Detta kräver att PU-tjänsten har tillgång till navet-aviseringar för hela landets befolkning. Dagens avtalsmässiga lösning bygger på ett avtal med varje landsting/region. PU-tjänsten bör alltså hämta 21st grunddataladdningar primärt, och sedan 21st aviseringsfiler "dagligen". Aviseringsfiler från SKV är s.k. "totalfiler" och vid förändring av en post tillhandahålls hela den nya posten, istället för alternativet med Δ-poster.

SKV tillhandahåller aviseringsfiler via ett "fråga-hämta" flöde. PU-tjänsten försöker hämta tillgängliga filer utifrån ett konfigurerbart intervall. När filer finns att tillgå laddar PU-tjänsten ner dessa och läser in datat till lokalt mellanlager. Vid felaktig inläsning markeras status för aviseringar som FAILED. Notera att avsaknad av filer ej räknas som ett fel då detta kan ske från SKV's håll. Innan status sätts till FAILED gör PU-tjänsten upprepade försök (konfigurerbart antal) att läsa in filen/filerna. PU-tjänstens förvaltning blir notifierade om felaktiga inläsningar och hanterar dessa manuellt för att återställa aviseringsstatus till SUCCESSFUL.

När en personpost inkommit via navet-avisering märks posten med orderID för den PuA som posten inkom för. Enbart poster som inkommit via navet-avisering har detta fält satt.

Direktuppslag

Om en efterfrågad personpost saknas vid fråga utför PU-tjänsten ett direktuppslag mot Navet för att söka och vid träff lagras den posten lokalt.  Om en post som hämtats via direktuppslag senare inkommer via Navet-avisering, skrivs den befintliga posten över med det data som kommer via aviseringen.

Exempel:

  • Samordningsnummer. Dessa kommer aldrig via Navet-avisering, och kommer således alltid leda till direktuppslag vid första sökningen.

  • Nyfödda. Dessa kommer saknas i lokalt mellanlager innan de inkommit via Navet-avisering. Söker man på en nyfödd person innan den aviserats kommer en direktslagning göras mot Navet och tillgängliga uppgifter hämtas och sparas lokalt. När aviseringar börjar inkomma för den aktuella posten skrivs tidigare data över med det som nu kommer i de kontinuerliga aviseringarna.

Flöde för aktualitet

När en sökning (lookup) görs på en personpost kontrollerar PU-tjänsten om posten inkommit via avisering.

  • Via avisering: Den lokalt sparade posten returneras, då poster som ingår i aviseringar uppdateras kontinuerligt.

  • Ej via avisering: Ifall posten aldrig inkommit via avisering, exempelvis samordningsnummer, kontrolleras när posten senast uppdaterades mot Navet direktslagning. Om denna uppdatering är äldre än ett i PU-tjänsten konfigurerbart antal dagar sker en ny direktslagning mot Navet. Om senaste uppdatering däremot inte är äldre är värdet returneras den lokalt mellanlagrade kopian.

  • Då navet är otillgängligt returneras alltid den lokalt lagrade kopian, oavsett när senaste uppdateringen skedde.

Kön

Det schema som Personuppgiftstjänsten använder, och tillhandahåller sitt data enligt, har sin grund i det schema som SKV/NAVET använder. Detta schema har modifierats med tillämpningar och utökningar som ger dess konsumenter det verksamhetsstöd som de behöver, samtidigt som det skall följa RIV-TA.

En av dessa utökningar berör kön på personposten. Personuppgiftstjänsten tillhandahåller uppgift om kön som ett eget element i sitt schema. Uppgift om kön är dock inget som SKV tillhandahåller explicit i det data som kommer från NAVET. Personuppgiftstjänsten måste således beräkna detta utifrån en individs person- eller samordningsnummer.

För definitionen av personnummer (och samordningsnummer) se [R4].

Följande regelverk gäller för de olika identitetstyperna.

  • Personnummer (PNR)

    • När data för en person inkommer från NAVET till Personuppgiftstjänsten utför personuppgiftstjänsten en beräkning för att avgöra kön. Detta sker utifrån den definition av personnummer som refererats tidigare. Värde för kön sparas som ett eget element (i enlighet med gällande kodverk) och tillhandahålls till personuppgiftstjänstens konsumenter utifrån dess egna schema. Uppgift om kön kan inte uppdateras manuellt, utan är helt beroende av det personnummer som låg till grund för beräkningen.

  • Samordningsnummer (SNR)

    • Samma som för PNR

  • Nationell reservidentitet (NRID)

    • När en ny NRID begärs av en aktör så skapas denna utifrån angivet födelsedata och kön. Dessa värden sparas explicit som egna element, men kodas även in i den NRID som skapas. Uppgifter som kön och födelsedata kan ändras vid ett senare tillfälle, men detta kommer inte påverka den NRID som skapats. Pga detta är rekommendationen att kön och födelsedata för NRID alltid skall utläsas ur dess egna element.

  • Lokal reservidentitet (LRID)

    • Dessa skapas inte av Personuppgiftstjänsten, men kan matas in för att koppla tidigare lokala identiteter gentemot nationella. Kön anges som ett eget element, vilket kan ändras vid senare tillfälle. Formatet på LRID har Personuppgiftstjänsten inget ansvar för.

Sekretessmarkering

Uppgifter hos SKV kan ha skyddsbehov och kan ha tillförts en markering för sekretess. När denna markering är satt hanterar personuppgiftstjänsten data kopplat till individen på ett skyddat sätt. Data filtreras innan utlämning till tjänstekonsument. Se detaljerad information i TKB V3 [T1].

Markering för Skyddad folkbokföring

Uppgifter hos SKV kan ha starkare skyddsbehov än den som Sekretessmarkering ger. Flaggan för Skyddad folkbokföring ersätter begreppet kvarskrivning. Personuppgiftstjänsten filtrerar uppgifter på samma sätt som den gör för poster som är Sekretessmarkerade.

Testmarkering

Personuppgiftstjänsten har funktion för att tillföra en datamängd för testidentiteter. Dessa är baserade på en lista med identiteter som SKV tillhandahåller och där Inera testorganisation kan lägga till data kopplat till identiteten. Dessa identiter markeras med testflagga. Enbart identiteter som finns i lista från SKV kan tillföras som testidentitet.

Om undantagsfallet med att en tidigare testidentitet kommer som en riktig identitet från SKV så ersätts data i personuppgiftstjänsten med det riktig SKV-data och identiteten upphör vara testidentitet.

Testidentiteter är i tjänstens databas separerade från riktiga SKV-identiteter.

Tvinga uppdatering av personpost

Aktualitet i Personuppgiftstjänsten bygger på de ändringsaviseringar som tjänsten hämtar per region. Som ett komplement till detta finns en möjlighet att via Personuppgiftstjänstens webbgränssnitt göra en manuell hämtning av en personpost från Skatteverkets Navet. För detta finns en särskild menyutgång som kan användas för att hämta aktuellt data från Navet för angiven personidentitet. Särskild behörighet krävs.

Uppfyllande av icke-funktionella krav

Icke-funktionella krav från verksamheten

Svarstider

95% av svaren ska tillhandahållas på under 50ms vid fråga på en personpost. Undantag kan tex vara att personposten inte finns i mellanlager och måste hämtas från Navet eller att personposten inte uppdaterats i mellanlagret på ett tag så att den måste hämtas på nytt från Navet.

Svarstider tar inte hänsyn till latency i näverk (transporttider till och från klient), eller overhead som uppstår vid nyttjande av 1..n tjänsteväxlar (exempelvis NTjP)

Tillgänglighet

Nationella PU-tjänsten ska ha en tillgänglighet på 99,9% i snitt över året.

Volymskrav

Nationella PU-tjänsten ska kunna hantera alla regioner eller landstings behov av personuppgifter. I Stockholms läns landsting handlar det om ca 2 miljoner slagningar per dygn.

Icke-funktionella krav från Systemägaren/Förvaltaren

Test

Specifika krav överenskommes i avtal om drift av tjänst.

Konfigurationsstyrning

Specifika krav överenskommes i avtal om drift av tjänst.

SLA-övervakning

Specifika krav överenskommes i avtal om drift av tjänst.

Säkerhet

Infrastruktursäkerhet

Infrastrukturen för personuppgiftstjänsten kräver att full tillgång till applikationsserver och databasserver begränsas. Om tillgång ges till någon av dessa kan användaren komma åt systemloggar samt personuppgifter och förvanska dessa. Att begränsa åtkomsten löses normalt sett med en brandvägg samt att servrarna skyddas med användarnamn och ett starkt lösenord.

Riskanalys

Genomförd och tillhandahålls efter begäran.

Riskminimering i den tekniska lösningen

Framtagna konstruktionsriktlinjer för Java används för all konstruktion, i dessa ingår bland annat förhindrande av "SQL injection", cross-site-scripting och postning av felaktiga formulär, m.m.

Givna riktlinjer i enlighet med RIV standard uppfylls.

Intrångsskydd

Fysiskt och logiskt intrångsskydd hanteras av driftleverantör.

Insynsskydd (kryptering)

All transport från/till PU-tjänsten är skyddad med kryptering (TLS).

Transportförvanskning

Alla klienter som ansluter till PU-tjänsten måste presentera ett signerat X509-certifikat för legitimering. Dessa certifikat ingår i den krypterade TLS-kommunikationen till och från personuppgiftstjänsten. Förvanskning av TLS-trafiken resulterar i ogiltigt data som i så fall avbryter kommunikationen.

Dataintegritet (Oförvanskat över tid), riktighet

Data i PU-tjänsten är indelat i 3 olika informationsägarkategorier.

  • SKV

    • Äger allt data som inkommer från Navet. Detta kan inte förändras av aktör i tjänsten utan enbart via uppdateringar från SKV (Navet)

  • Vården

    • Äger allt data rörande reservidentiteter. Detta data kan förändras av vårdaktör i tjänsten.

  • Individen

    • Äger allt data rörande egna kontaktuppgifter. Detta data kan förändras av vård- samt individ-aktör i tjänsten.

Autentisering ("stark" vid behov enligt informationsklassning)

Alla klienter som ansluter till personuppgiftstjänsten måste presentera ett signerat X509-certifikat för legitimering. Vilka certifikatsutfärdare som tillåts i PU-tjänsten kan konfigureras av PU-tjänstens förvaltningsorganisation.

Implementerad Signering

Ej aktuellt.

Spårbarhet (loggning)

Felmeddelanden loggas och möjlighet till att slå på ökad trace-loggning finns. Dvs att default loggas inte all aktivitet utan man man kan slå på extra loggning för felsökning. Loggarna sparas av driftleverantören.

Datamodell

För information om datatyperna, se tjänstekontrakt [T1].

Driftaspekter

Tjänsten är skalbar vertikalt och horisontellt för att möjliggöra kapacitetsökning vid behov.

Tjänsten kan installeras och driftas med RedHat version 6 eller senare.

Fysisk miljö

Driftsmiljön för Nationella PU-tjänsten ska sättas upp så den är redundant och skalbar med databasen MongoDB för persistens och Redis för sessionsdata.







Följsamhet mot T-bokens styrande principer



IT2: Informationssäkerhet



IT2: Informationssäkerhet



Förutsättningar att uppfylla

Uppfyllnad

Verksamhetskritiskt IT-stöd designas för att möta verksamhetens krav på tillgänglighet vid frånfall av ett externt beroende. Ju fler beroenden till andra komponenters tillgänglighet, desto lägre egen tillgänglighet.

Personuppgiftstjänsten är designad att kunna nyttja Navets aviseringsfunktion för att inte vara beroende av deras tillgänglighet.

Verksamhetskritiska nationella stödtjänster (t.ex. tillgång till behörighetsstyrande information) erbjuder möjlighet till lokala instanser som med tillräcklig aktualitet hålls uppdaterade med nationell master.

Arkitekturen tillåter lokala/regionala instanser.

Krav mellan integrerande parter regleras genom integrationsavtal. Integrationsavtal är det avtal där informationsägaren godkänner att en ett visst system får agera mot information genom ett visst tjänstekontrakt. Exempelvis skall enligt integrationsprocessen för den nationella tjänsteplattformen ett avtalsnummer för ett integrationsavtal registreras i samband med att man "öppnar dörren" för en viss tjänstekonsument mot en viss kombination av informationsägare och tjänstekontrakt.

Integrationsavtal krävs för att ansluta mot personuppgiftstjänsten.

Arkitekturen måste möjliggöra tillräcklig tillgänglighet vid flera samverkande system.

Uppfylls genom design för hög tillgänglighet enligt ovan.

En sammantagen tolkning av tillämpliga lagar och förordningars konsekvenser för teknisk realisering av informationsfångst, utbyte och lagring.

Följt lösningsförslag från förstudien om gemensam personuppgiftstjänst.

Förutsättningar för spårbarhet etableras i form av loggningsregler för komponenter som deltar i säkert informationsutbyte.

Systemloggning för felhantering samt traceloggning implementeras.

Interoperabla, internationellt beprövade och för leverantörer tillgängliga standarder tillämpas för kommunikation mellan parter som har upprättat tillit.

Uppfylls för stödtjänsterna genom nyttjande av

  • tekniska profilen RIV-TA BP 2.1 

    För webbklienter som ingår nyttjas för autentisering, SSO och auktorisation: 

    • SSL/TLS*

    • OIDC*



IT3: Nationell funktionell skalbarhet



IT3: Nationell funktionell skalbarhet



Förutsättningar att uppfylla

Uppfyllnad

Nationella tjänstekontrakt definieras med nationell täckning som funktionell omfattning. Det är möjligt för ett centraliserat verksamhetssystem som användas av alla verksamheter i Sverige att realisera varje standardiserat tjänstekontrakt. Det får inte finnas underförstådda funktionella avgränsningar till regioner, kommuner, landsting eller andra organisatoriska avgränsningar i nationella tjänstekontrakt.

Personuppgiftstjänstens kontrakt är nationellt gångbara och innehåller inga lokala/organisationsspecifika begränsningar.

SLA ska definieras för varje tjänstekontrakt. Detta SLA ska ta hänsyn till framtida kapacitet för tjänstekontraktet med avseende på transaktionsvolym, variationer i användningsmönster och krav på tillgänglighet, i kombination med förmåga till kontinuerlig förändring.

Se tjänstebeskrivning för Personuppgiftstjänst.

Integration ska ske över en integrationsinfrastruktur (t.ex. virtualiseringsplattform) som möjliggör uppföljning av tjänsteproducenters fullföljande av SLA.

Tjänstekontrakten är möjliga att nyttja via en virtualiseringsplattform (tjänsteplattform).

System och e-tjänster som upphandlas kan utökas med fler organisationer som kunder utan krav på infrastrukturella ingrepp (jämför s.k. SaaS)

Personuppgiftstjänsten kan hantera flera samtidiga organisationer/huvudmän i samma delade instans.



IT4: Lös koppling



IT4: Lös koppling



Förutsättningar att uppfylla

Uppfyllnad

Meddelandeutbyte baseras på att kommunikation etableras utgående från vem som äger informationen som ska konsumeras eller berikas, inte vilket system, plattform, datalager eller tekniskt gränssnitt som informationsägaren för stunden använder för att hantera informationen. Genom centralt administrerad förmedlingstjänst skapas lös koppling mellan informationskonsument och informationsägarens tekniska lösning.

Följer RIV TA 2 för samverkan.

En arkitektur som skapar lös koppling mellan konsumenter och producenter, avseende adressering och standarder för kommunikation.

Följer RIV TA 2 för samverkan.

En nationell integrationspunkt ska kunna erbjudas för varje nationellt standardiserat tjänstekontrakt, som en fasad mot bakomliggande brokiga systemlandskap.

Tjänstekontrakten för nationell integrationspunkt och kan erbjudas via Tjänsteplattform.

Nationella tjänstekontrakt förvaltas i en nationellt koordinerad förvaltning.

Enligt RIV TA.

För en process inom vård och omsorg kan flera tjänstekontrakt ingå. Därför är det viktigt att alla tjänstekontrakt baseras på en gemensam referensmodell för informationsstruktur.

Informationen inom domänen har mappats till Navets informationsstruktur (Skatteverket) samt till Nationell informationsstruktur 2016:1 (Socialstyrelsen).

Parter som samverkar i enlighet med arkitekturen integrerar med system hos parter som lyder under annan styrning (t.ex. myndigheter, kunder och leverantörer). Det kan leda till att vård- och omsorgsgivare antingen:

  • Nationellt bryggar informationen (semantisk översättning) eller 

  • Nationellt införlivar externt förvaltat tjänstekontrakt som standard.

Observera att semantisk bryggning av information till vårdens referensmodell förutsätter en nationell förvaltning av bryggningstjänster.
För att införliva ett externt förvaltat tjänstekontrakt förutsätts en transparent, robust och uthållig tjänstekontraktsförvaltning hos den externa parten.

<Ej tillämpbar>

Befintliga system behöver anpassas till nationella tjänstekontrakt. Detta kan göras av leverantörer direkt i produkten, eller genom fristående integrationskomponenter ("anslutningar"). En anslutning bör ligga nära (logiskt vara en del av) det system som ansluts, oavsett om det är i rollen som konsument eller producent för anslutningen som genomförs.

Tillämpas vid implementation / anslutning av konsumenter till PU-tjänsten

Interoperabla standarder för meddelandeutbyte tillämpas, så att integration med till exempel en Web Service kan utföras utan att anropande system behöver tillföras en för tjänsteproducenten specialskriven integrationsmodul (s.k. agent).

Personuppgiftstjänsten följer RIV-TA 2.1.



IT5: Lokalt driven e-tjänsteförsörjning



IT5: Lokalt driven e-tjänsteförsörjning



Förutsättningar att uppfylla

Uppfyllnad

När utveckling av källkod är en del av en tjänsteleverans skall följande beaktas:

  • Alla leveranser tillgängliggörs under öppen källkodslicens. Valet av licensformer samordnas nationellt genom rekommendationer. 

  • Utvecklingen bedrivs från start i en allmänt tillgänglig (över öppna nätverk) projektinfrastruktur där förvaltningsorganisation kan förändras över tiden inom ramen för en kontinuerligt tillgänglig projektinfrastruktur (analogi: "Projektplatsen för e-tjänsteutveckling").

  • Det innebär full insyn och åtkomst för utvecklare till källkod, versionshantering, ärendehantering, stödforum och andra element i en projektinfrastruktur under projektets och förvaltningens hela livscykel.

  • Upphandlade e-tjänster fungerar på de vanligaste plattformarna hos vårdgivarna och hos nationella driftspartners (Windows, Linux, Unix) t.ex. genom att vara byggda för att exekvera på en s.k. Java virtuell maskin.

  • Gemensam referensmodell för e-tjänsters interna uppbyggnad stimulerar och förenklar återanvändning och överföring av förvaltningsansvar mellan organisationer.

Ej uppfyllt. Realiseringen av personuppgiftstjänst lämnas ej ut som öppen källkod.

Minsta möjliga – men tillräcklig – mängd standarder och stödjande gemensamma grundbultar för nationella e-tjänstekanaler säkerställer att även utvecklingsenheter i mindre organisationer kan bidra med e-tjänster för en integrerad användarupplevelse och att en gemensam back-office för anslutning av huvudmän till e-tjänster finns etablerad. I den mån etablerade standarder med bred tillämpning i kommersiella e-tjänster finns (t.ex. för single-sign-on), bör de användas i syfte att möjliggöra upphandling av hyllprodukter.

<Ej tillämpbar>

Utveckling sker mot globalt dominerande portabilitetsstandarder i de fall mellanvara (applikationsservrar) tillämpas. Det är möjliggöraren för nyttjande av free-ware och lågkostnadsverktyg i organisationer som inte orkar bära tunga licenskostnader för komplexa utvecklingsverktyg och driftsplattformar.

Uppfyllt. Personuppgiftstjänsten är en fristående produkt som endast kräver java samt databasen MongoDB som tillägg - vilken kan nyttjas utan kostnad.

Nationell (eller regional – beroende på sammanhang vård/omsorg) förvaltning är etablerad (t.ex. s.k. Portal Governance), med effektiva processer för att införliva lokalt utvecklade e-tjänster i nationella e-tjänstekanaler. Systematisk och effektiv allokering av resurser för drift är en viktig grundförutsättning.

<Ej tillämpbar>

Genom lokal governance och tillämpning av det nationella regelverket får lokala projekt den stöttning som behövs för att från början bygga in förutsättningar för integration i samordnade (t.ex. nationella) e-tjänstekanaler.

<Ej tillämpbar>



IT6: Samverkan i federation



IT6: Samverkan i federation



Förutsättningar

Uppfyllnad

Att gemensamma gränssnitt i alla federativa utbyten finns framtagna och beskrivna, vilket möjliggör kostnadseffektiva och leverantörsneutrala lösningar.

Alla integrationspunkter består av nationella tjänstekontrakt.

Det behövs organ och processer för att godkänna utgivare av elektroniska identitetsintyg och certifikat som är giltiga i federationen.

Enligt SITHS policy för certifikat för personal och system.

Aktörer i olika nät, inklusive öppna nät ska vara välkomna i elektronisk samverkan genom att samverkande komponenter är säkra.

Realiseringen av personuppgiftstjänsten nyttjar säker kommunikation i form av SSL/TLS med dubbelriktad autentisering.

Att Ingående parter i federationen är överens om ett antal gemensamma ståndpunkter:

  • att stark autentisering likställs med 2-faktors autentisering 

  • att vid samverkan acceptera följande metoder för stark autentisering; eID, PKI med lagring av nyckelpar på SmartCard eller motsvarande och metoder baserade på engångslösenord, antingen genererade i en fysisk enhet eller säkert distribuerad till fysisk enhet

  • att tillämpa en gemensam certifikat- och utfärdarpolicy, likvärdig med SITHS, som ett minimikrav för egen eller annans PKI

  • att sträva mot en autentiseringslösning, framför flera olika, för att realisera stark autentisering i den egna organisationen och i federation

  • att enbart acceptera SAMLv2 eller OIDC vid identitetsfederering samt tydliggöra att det i förekommande fall är det enda sättet att logga in och säkerställa det inte finns någon bakväg in

  • att tillämpa ett gemensamt ramverk för att ingå i en federation

  • att tillämpa en gemensam katalogpolicy, med utgångspunkt från HSA policy, som ett minimikrav för egna kataloger

  • att stäva mot att all gränsöverskridande kommunikation skall vara möjlig både över Sjunet och Internet. Det är den egna organisationen som beslutar vilken tillgänglighet som är tillräcklig för anslutningen

  • att sträva efter att möjliggöra kontroll av trafik till och från den egna infrastrukturen i en eller få kontrollpunkter

  • att utgå från att kommunikation över Internet och Sjunet har ett likvärdigt skyddsbehov

Lösningen stödjer en sådan kommande federation genom användning av

Autentisering:

  • Nationell extern IdP/Autentiseringstjänst med OIDC som bas

  • SITHS-kort / certifikat och tillhörande utfärdarpolicys

    HSA (Indirekt):
    HSA som katalogtjänst; från HSA hämtas alla användaregenskaper såsom rättigheter.

    Nät:
    Oavsett vilket nät som används säkras tjänsterna enligt ovan, d v s i grunden utgår lösningen ifrån att samma skyddsbehov finns i båda fallen.
    För exponering mot Internet följs även Sjunets säkerhetsregler, vilket tillför ytterligare skyddsmekanismer (ytterligare separat DMZ).
    Tjänster som exponeras via Tjänsteplattformen använder den nätverksexponering mot Internet som Tjänsteplattformen tillhandahåller.

    Exponering av tjänster på Internet hanteras separat och dokumenteras i för det avsedd SAD.




Referenser

Styrande dokument

S1

RIV Tekniska Anvisningar

http://rivta.se/

Stödjande dokument

R1

 SAD-mall

Arkitekturledningens mall för SAD

http://rivta.se/documents/ARK_0013/

R2

RIVTA BP2.1

RIV Tekniska Anvisningar Basic Profile 2.1

http://rivta.se/documents/ARK_0002/

R3

RIV Tekniska Anvisningar - Binära bilagor

http://rivta.se/documents/ARK_0038/

R4

Definition av PNR samt SNR

https://www.skatteverket.se/privat/folkbokforing/personnummerochsamordningsnummer.4.3810a01c150939e893f18c29.html



Nyttjade integrationstjänster



T1

Personuppgiftstjänst

Tjänstekontrakt för Personuppgiftstjänst återfinns på

https://bitbucket.org/rivta-domains/riv.strategicresourcemanagement.persons.person/src

Nyttjade plattformsfunktioner



P1

Autentisering

Autentiseringstjänsten används för interoperabel hantering av identitetsintyg (OIDC) med rättighetsstyrande attribut för användare.
Den nationellt driftade Autentiseringstjänsten nyttjas i den nationella driftnoden.

P2

SITHS

SITHS-kort används för säker inloggning, ger stöd för stark autentisering av användare.

P3

Tjänsteplattform

Nationell tjänsteplattform, lokalt såväl som nationellt, är en möjlig förmedlare av tjänsterna. Tillför möjlighet till internetanslutning samt förenkling av integrationspunkterna och vägval för att hitta viss producerande tjänst.
https://www.inera.se/kundservice/dokument-och-lankar/digitalisering/tjansteplattformen/