Innehållsförteckning |
---|
Sektion | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
DokumentinformationSyfteSyftet med detta dokument är att beskriva systemarkitektur och teknisk realisering för den nationella personuppgiftstjänsten, samt vilka styrande behov och krav. MålgruppDe huvudsakliga målgrupperna för detta dokument är beställare, arkitekturledningen, systemarkitekter och utvecklingsteam. Revisionsinformation
Begreppslista
Översiktlig beskrivningInledningSyftet 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.
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.
SammanfattningEn 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. 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 (totalt 21 beställningar gentemot SKV). KonsumentKonsumenter 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änstArkitekturen 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 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. Nationell PU-tjänstDen 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å. Målbild och principerVerksamhetsmässiga mål
Arkitekturella målÖvergripande mål
Specifika mål
Planerade avstegInga planerade avsteg. Prioriterade områdenDen 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änsningarInga planerade avgränsningar. Teknisk lösningÖversiktNationella PU-tjänsten implementeras i samma plattform som Säkerhetstjänster, detta för att återanvända funktionalitet för redundans och skalbarhet. 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:
Arkitekturellt signifikanta delar av lösningenAutentisering via SAML 2.0 och SITHS/EFOS certifikatPU-tjänstens webbapplikation använder SAML 2.0 och SITHS/EFOS 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. 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/EFOS-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änsterIntegrerande systemkonsument kan anropa personuppgiftstjänsten med SOAP-WS. Denna teknik följer RIV 2.1-standarden, se referens B2. Hantering av bilagorPU-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 R4. Hantering av bilagor dokumenteras under egen avdelning, se 3.0 Filhantering. Huvudidentitet och koppling av identiteterDå flera personidentiteter kan identifiera samma identitet (reservidentitet, sammordningsnummer, 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. OSGiDen 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 /wiki/spaces/SAK/pages/3397194054 [R3]. Logisk arkitekturAnvändargränssnittAnvändargränssnitt för hälso- och sjukvårdspersonalAnvä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. 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änglighetskravTack 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: PU-tjänsten har som mål att följa de riktlinjer som tas fram inom e-klient. Känd problembild vid autentiseringDen nationella autentiseringstjänster hanterar läsning av användarens SITHS/EFOS 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. Då PU-tjänsten nyttjar nationell Autentiseringstjänst så kommer den få ta del av den utveckling som sker inom denna och när ny funktionalitet som tillkommer i denna, har PU-tjänsten direkt möjlighet att nyttja densamma. AnvändningsfallPU-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
Sök personuppgifter utifrån parametrarSynkrontAnvä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 och det efterfrågade uppgifterna returneras direkt i tjänstens svar till aktören.
AsynkrontAnvä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.
Aviseringar
BilagorPU-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 3.0 Filhantering. Hämta kontaktuppgifter för person utifrån personidentitetEn 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.
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 reservidentitetUppdatering 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
Lägg till befintligt Lokal reservidentitet
Uppdatera reservidentitet
Uppdatera kontaktuppgifterEn 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).
Koppla personidentiteterAnvä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
Koppla isär identitet
Upprätthålla lokalt mellanlager av SKV-dataPU-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å 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. DirektuppslagOm 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:
Flöde för aktualitetNär en sökning (lookup) görs på en personpost kontrollerar PU-tjänsten om posten inkommit via avisering.
KönDet 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 modfierats 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. 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 [R5]. Följande regelverk gäller för de olika identitetstyperna.
Sekretessmarkering / Skyddad FolkbokföringUppgifter hos SKV kan ha skyddsbehov och kan ha tillförts en markering för sekretess alternativt markering för Skyddad Folkbokföring. När någon av dessa markeringar är satt hanterar personuppgiftstjänsten datat kopplat till individen på ett skyddat sätt. Data filtreras innan utlämning till tjänstekonsument. Se detaljerad information i TKB V3 [T1]. TestmarkeringPersonuppgiftstjä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 datat i personuppgiftstjänsten med det riktiga SKV datat, och identiteten upphör vara testidentitet. Testidentiter är logiskt separerade från riktiga SKV-identiteter i en egen databaskollektion. Uppfyllande av icke-funktionella kravIcke-funktionella krav från verksamhetenSvarstider95% 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änglighetNationella PU-tjänsten ska ha en tillgänglighet på 99,9% i snitt över året. VolymskravNationella 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örvaltarenTestSpecifika krav överenskommes i avtal om drift av tjänst. KonfigurationsstyrningSpecifika krav överenskommes i avtal om drift av tjänst. SLA-övervakningSpecifika 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. SäkerhetInfrastruktursäkerhetInfrastrukturen 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. RiskanalysGenomförd och tillhandahålls efter begäran. Riskminimering i den tekniska lösningenFramtagna 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. IntrångsskyddFysiskt och logiskt intrångsskydd hanteras av driftleverantör. Insynsskydd (kryptering)All transport från/till PU-tjänsten är skyddad med kryptering (SSL/TLS). TransportförvanskningAlla 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/från personuppgiftstjänsten. Förvanskning av TLS-trafiken resulterar i ogiltigt data som i så fall avbryter kommunikationen. Dataintegritet (Oförvanskat över tid), riktighetData i PU-tjänsten är indelat i 3 olika informationsägarkategorier.
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. Implementerad SigneringEj 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. Systemloggar sparas i 90 dagar. DatamodellFör information om datatyperna, se tjänstekontrakt [T1]. DriftaspekterTjä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, 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. PU-tjänsten exponerar REST-tjänster både på SJUNET och INTERNET för hantering av filer. ProgramvarorPersonuppgiftstjänsten kräver följande programvara:
Detaljerad informationEj specificerat Produktionssättning och överlämning till förvaltningDriftsättning sker i samarbete mellan objektansvarig, driftleverantör samt förvaltningsorganisation. |
...
Följsamhet mot T-bokens styrande principer
ReferenserStyrande dokument
Stödjande dokument
Nyttjade integrationstjänster
Nyttjade plattformsfunktioner
|