1. Dokumentinformation
1.1. 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.
1.2. Målgrupp
De huvudsakliga målgrupperna för detta dokument är beställare, arkitekturledningen, systemarkitekter och utvecklingsteam.
1.3. Revisionsinformation
Version | Författare | Datum | Kommentar |
|---|---|---|---|
0.1 |
| Första utkastet | |
0.2 | Ändringar i samband med korrekturläsning | ||
| 1.0 |
| Fastställd | |
| 1.1 |
| Tillägg och revidering för PU 2.1 |
1.4. Begreppslista
| 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 |
2. Översiktlig beskrivning
2.1. Inledning
Syftet med en nationell PU-tjänst är att skapa en gemensam tjänst för landsting, regioner 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 personuppgifter från skatteverket idag är hög för regionerna, då var och en måste hämta dessa från skatteverket. En gemensam personuppgiftstjänst ämnar minska dessa kostnader då man kan minska antalet lokala PU-tjänster i landet. 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.
- Samverkan med framtida reservnummertjänst.
- Samverkan med framtida tjänst för en individs 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.
2.2. Sammanfattning
En nationell personuppgiftstjänst som alla regioner och landsting ska kunna nyttja behöver en arkitektur som kan hantera personuppgifter för alla personer i hela 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. P.g.a. lagar/regelverk behöver den nationella PU-tjänsten ett avtal per region/landsting, vilket innebär att nationella PU-tjänsten får hämta en aviseringsfil per region/landsting (totalt 21 beställningar gentemot SKV).
2.2.1. 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.
2.2.2. Regional PU-tjänst
Arkitekturen tillåter fortfarande 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 navet för att minska kostnader. Nationell PU-tjänst tillhandahåller aviseringsfiler till Regional PU-tjänst enligt SKV's aviseringsschema. Detta för att kunna genomföra en gradvis övergång från nuläge till önskad målbild.
2.2.3. 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 uppsättning, dvs minst 2 applikationsservrar och 2 databasservrar. Arkitekturen på tjänsten stödjer även att skala upp antalet servrar på applikation och databasnivå.
3. Målbild och principer
3.1. 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 aviseringsfiler för fortsatt nyttjande av regionala tjänster
- Möjliggöra för framtida samverkan med reservnummertjänst
- Möjliggöra för framtida samverkan med kontaktuppgiftstjänst
3.2. Arkitekturella mål
3.2.1. Ö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
3.2.2. 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 och aviseringsfiler enligt SKV-format.
3.2.3. Planerade avsteg
Inga planerade avsteg.
3.3. 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).
3.4. Avgränsningar
Inga planerade avgränsningar.
4. Teknisk lösning
4.1. Översikt
Nationella PU-tjänsten implementeras i samma plattform som Säkerhetstjänster, detta för att återanvända funktionalitet för redundans och skalbarhet. På så vis får man billigare utveckling och en billigare förvaltning. Notera att detta INTE innebär att PU-tjänsten är hårt kopplad till Säkerhetstjänsten. Deployment kan ske som en del av säkerhetstjänstens driftmiljö, eller som en separat installation.
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 personuppgifter från mellanlager.
- Tjänstelagret: Hanterar autentisering, behörighetskontroll, validering, loggning, transaktionshantering, verksamhetslogik samt kommunikation mot Navet.
- Webbtjänstelagret: Transformerar XML-data till tjänsteobjekt och vice versa.
- GUI-lagret: Hanterar SAML-autentisering och webbsidor för slutanvändare.
4.2. Arkitekturellt signifikanta delar av lösningen
4.2.1. Autentisering via SAML 2.0 och SITHS certifikat
PU-tjänstens webbapplikation använder SAML 2.0 och SITHS certifikat som autentiseringsteknik. Autentisering utförs gentemot Ineras nationella autentiseringstjänst (med mål att framtida federation av autentiseringstjänster skall kunna nyttjas). I användarens SAML-intyg 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. Ett mjukt funktionscertifikat för systemkonsumenter och ett SITHS-kort för slutanvändare av PU-tjänstens webbapplikation.
4.2.2. 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.
4.2.3. 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.
4.2.4. Webbtjänster
Integrerande systemkonsument kan anropa personuppgiftstjänsten med webbtjänsteteknik. Denna teknik följer RIV 2.1-standarden, se referens B2.
4.2.5. OSGi
Den Java-plattform som personuppgiftstjänsten bygger på är i botten en OSGi-lösning som medger löst kopplade komponenter, så kallade bundlar, som kan uppgraderas individuellt. Det är också möjligt att på ett smidigt sätt växla mellan olika implementationer av samma gränssnitt. Detta skapar en mycket flexibel och pluggbar plattform. För vidare information om de ingående delarna i denna plattform hänvisas till Säkerhetstjänsternas gemensamma SAD [R3].
5. Logisk arkitektur
6. Användargränssnitt
6.1. Användargränssnitt för hälso- och sjukvårdspersonal
Användargränsnittet är framtaget med ramverket Google Web Toolkit 2.6 (GWT) och är kompatibelt med alla de större webbläsarna på marknaden idag.
6.2. 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.
6.3. Kravbild för tillgänglighetskrav
Tack vare användandet av GWT-tekniken så är användargränssnittet kompatibelt med alla dagens webbläsare. Följande kombination av klient-programvara har använts i nuvarande tester:
Internet Explorer 11
SITHS-programvara som testats är Net iD 6.1.x på Windows 7.
Framtida versioner av SITHS-programvara, webbläsare och operativsystem måste kvalitetssäkras löpande.
6.3.1. Känd problembild vid autentisering
Den nationella autentiseringstjänster hanterar läsning av användarens SITHS certifikat via plugin (NetId) till browsern. I dagsläget minskar stöd för sådan plugins, och nuvarande status är att Chrome och Internet Explorer kan användas för inloggning, men inte nyare versioner av Firefox, eller Microsoft Edge.
7. 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.
7.1. Lookup. Hämta personuppgifter för person utifrån personnummer.
- Användare jobbar med en eller flera personer i e-tjänst. E-tjänsten behöver personuppgifter på dessa.
- Antingen hämtar 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 hämta personuppgifterna till e-tjänsten.
7.2. Search, Synkront. Sök personuppgifter utifrån kända parametrar
Beskrivningen syftar på samma bild som i avsnitt 7.1.
- Användaren jobbar med en person i en e-tjänst, men saknar korrekt personidentitet på denne. Övrig information om personen finns.
- 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.
- Via PU-tjänstens webbapplikation sker sökning genom att fylla i 1..n fördefinierade textfält.
- Via WS-gränssnitt sker sökning i enlighet med tjänstens tjänstekontrakt. Inparameter för fråga sker enligt syntax definierad i 2.1 SimpleQL.
7.3. GetFiles. Hämta aviseringsfiler
- En konsument (med rättighet att avisera på data) vill ta del av "sina" personuppgifter och gör en begäran om att läggas upp som aviseringskund i PU-tjänsten. Som aviseringkund kan man få grunddata och aviseringsfiler för urvalet 0..n landsting samt 0..n kommuner.
- Efter beställning skapa PU-tjänstens filer med bestämt intervall som konsumenten kan hämta enligt beskrivning Hämta filer 2.1.
7.4. Upprätthålla lokalt mellanlager av data
PU-tjänsten skall upprätthålla ett lokalt mellanlager av personuppgiftsdata. 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.
7.4.1. 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å 21st avtal, ett med varje landsting/region. PU-tjänsten hämtar således 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.
7.4.2. Direktuppslag
Om en efterfrågad personpost (lookup) saknas, utför PU-tjänsten ett direktuppslag mot Navet för att söka, och vid träff, lagra posten lokalt. Om direktuppslag returnerar en post sparas denna 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.
7.4.3. 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.
8. Uppfyllande av icke-funktionella krav
8.1. Icke-funktionella krav från verksamheten
8.1.1. 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)
8.1.2. Tillgänglighet
Nationella PU-tjänsten ska ha en tillgänglighet på 99,9% i snitt över året.
8.1.3. 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.
8.2. Icke-funktionella krav från Systemägaren/Förvaltaren
8.2.1. Test
Specifika krav överenskommes i avtal om drift av tjänst.
8.2.2. Konfigurationsstyrning
Specifika krav överenskommes i avtal om drift av tjänst.
8.2.3. SLA-övervakning
Specifika krav överenskommes i avtal om drift av tjänst. PU-tjänsten skall, i enlighet med RIVTA 2.1 tillhandahålla tjänsten "PingForConfiguration", som kan nyttjas för övervakning.
9. Säkerhet
9.1. 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.
9.2. Riskanalys
Genomförd och tillhandahålls efter begäran.
9.3. 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". I användargränssnittet används webbteknik (GWT) som förhindrar bland annat cross-site-scripting och postning av felaktiga formulär, m.m.
Givna riktlinjer i enlighet med RIV standard uppfylls.
9.4. Intrångsskydd
Fysiskt och logiskt intrångsskydd hanteras av driftleverantör.
9.5. Insynsskydd (kryptering)
All transport från/till PU-tjänsten är skyddad med kryptering (SSL/TLS).
9.6. 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 SSL-kommunikationen till/från personuppgiftstjänsten. Förvanskning av SSL-trafiken resulterar i ogiltigt data som i så fall avbryter kommunikationen.
9.7. Dataintegritet (Oförvanskat över tid), riktighet
För data i PU-tjänsten ses SKV som informationsägare. Inga tjänster som förändrar data förekommer.
9.8. Autentisering ("stark" vid behov enligt infoklassning)
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.
9.9. Implementerad Signering
Ej aktuellt.
9.10. 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. Systemloggar sparas i 90 dagar.
10. Datamodell
För information om datatyperna, se tjänstekontrakt [T1].
11. 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.
11.1. Fysisk miljö
Driftsmiljön för Nationella PU-tjänsten ska sättas upp så den är redundant, dvs minst 2 applikationsservrar och 2 databasservrar.
Applikationsservrarna behöver även en delad diskarea för konfiguration. Plattformen som PU-tjänsten nyttjar använder sig av Infinispan för att dela bl.a. sessionsdata, som ligger i minnet.
PU-tjänsten ska finnas tillgänglig både på SJUNET och på INTERNET. Webbtjänstekontraktet tillgängliggörs på båda genom NTjP som finns på både SJUNET och INTERNET. GUI instans behövs dock installeras på både SJUNET och INTERNET.
11.2. Programvaror
Personuppgiftstjänsten kräver följande programvara:
- Java SE 8 – 64 bit
- MongoDB 3.0
- MySQL 5.6
11.3. Detaljerad information
Ej specificerat
11.4. Produktionssättning och överlämning till förvaltning
Driftsättning sker i samarbete mellan objektansvarig, driftleverantör samt förvaltningsorganisation.
12. Följsamhet mot T-bokens styrande principer
12.1.1. 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
|
12.1.2. 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. |
12.1.3. 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:
Observera att semantisk bryggning av information till vårdens referensmodell förutsätter en nationell förvaltning av bryggningstjänster. | <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. |
12.1.4. 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:
| 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> |
12.1.5. 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:
| Lösningen stödjer en sådan kommande federation genom användning av
|
13. Referenser
13.1. Styrande dokument
S1 | RIV Tekniska Anvisningar |
13.2. Stödjande dokument
| R1 | SAD-mall | Arkitekturledningens mall för SAD |
| R2 | RIVTA BP2.1 | RIV Tekniska Anvisningar Basic Profile 2.1 |
| R3 | Säkerhetstjänster SAD | SAD för gemensam arkitektur för Säkerhetstjänster |
13.3. Nyttjade integrationstjänster
| T1 | Personuppgiftstjänst | Tjänstekontrakt för Personuppgiftstjänst återfinns på V1: https://bitbucket.org/rivta-domains/riv.population.residentmaster/src V2: https://bitbucket.org/rivta-domains/riv.masterdata.citizen.citizen/src |
13.4. Nyttjade plattformsfunktioner
| P1 | Autentisering | Autentiseringstjänsten används för interoperabel hantering av identitetsintyg (SAML2) med rättighetsstyrande attribut för användare. |
| P2 | SITHS | SITHS-kort används för säker inloggning, ger stöd för stark autentisering av användare. |
| P3 | Tjänsteplattform | http://www.inera.se/TJANSTER--PROJEKT/ICC-Integration-Competence-Center/ |