1. Dokumentinformation

1.1. Syfte

Syftet med detta dokument är att beskriva arkitekturen för loggtjänsten. Den övergripande arkitekturen och tillhörande nationella tjänstekontrakt, applicerar dels på hanteringen av loggar från de nationella tjänsterna (ex Nationell patientöversikt, Pascal) dels ev logghantering på lokal nivå (lokala vårdsystem) för tillgängliggörande av dessa loggposter för patienten.

1.2. Målgrupp

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

1.3. Revisionsinformation

2. Översiktlig beskrivning

2.1. Inledning

Med loggtjänster avses verktyg för vårdgivarna inom svensk hälso- och sjukvård för att uppfylla Patientdatalagen och Socialstyrelsens föreskrifter (HSLF-FS 2016:40 med handbok) gällande krav på uppföljning av åtkomst till patientinformation. Genom att nationellt standardisera tjänstekontrakt för samverkan mellan vårdsystem och loggtjänst skapas kompatibilitet mellan alla journalsystem och alla loggtjänster. Därigenom undviks huvudmanna-specifika anpassningar av vårdsystem som behöver integration med loggtjänster samt att åtkomst till åtkomstloggar sker på ett enhetligt sätt i ett standardiserat format. Tjänstekontrakten standardiserar även patienttjänsters åtkomst till logginformation.

Det typiska behovet av loggtjänsten är att ansluta en tillämpning som erbjuder direktåtkomst till sammanhållen journalföring och som därmed har behov av åtkomstloggning enligt PDL och HSLF-FS 2016:40.

 Figur 1: Säkerhetstjänster översikt.

2.2. Sammanfattning

Den nationella arkitekturen för hantering av åtkomstloggar är utformad till att

• Dels stödja vårdgivarens krav att följa upp vilken tillgång vårdgivarens personal har haft till patientinformation, dels kravet att den vårdgivare som bereder tillgång till information skall få veta vilka vårdgivare som har haft tillgång till vårdgivarens information.
• Dels möjliggöra att patienten kan ta del av åtkomstloggar som rör patienten.Arkitekturen medger att vårdgivare, landsting/kommuner och regioner flexibelt kan välja var uppföljningen av åtkomstloggar kan ske. Antingen via nationella tjänster/rapporter för uppföljning eller lokala/regionala system där uppföljningen kan ske med de system som vårdgivaren lokalt har valt att använda.

Tjänstekontrakten syftar till att ge följande verksamhetsmässiga effekter

• Säkerställa uppföljning av åtkomst till journaluppgifter som sker i de nationella tillämpningarna/tjänsterna
• Valfrihet för vårdgivaren hur uppföljning av åtkomstloggar ska ske
• Tillgängliggörande av åtkomstinformation till patienten innebär mindre administrativ belastning bland vårdgivarna genom att patienten själv bereds åtkomst till åtkomstloggar.

Figur 2: Principer för samverkande tjänster.

I figuren ovan visas som exempel en tjänst för sammanhållen patientöversikt (NPÖ) där en aktörs aktiviteter i NPÖ loggas till den nationella loggtjänsten. Uppföljning av åtkomstloggar kan sen ske antingen via den nationella loggrapporttillämpningen eller för de vårdgivare som har etablerade system för lokal logguppföljning i deras logguppföljningssystem. Dessa system kan via hämtningstjänsten hämta de loggar som tillhör dem.

Logguppföljning sker i respektive logguppföljningssystem.

Figuren visar även ett exempel där patienten via en tillämpning i ex. 1177 kan få se vilka vårdgivare och vilken vårdenhet som har haft tillgång till patientens information. Som källor för detta så kan dels den nationella loggtjänsten leverera information, men även information hos åtkomstloggar i lokal logghantering hos de vårdgivare som via de nationella tjänstekontrakten kan publicera denna information. Detta sker då via en aggregerade tjänst som via Tjänsteplattformen har åtkomst till producenter av åtkomstloggar.

2.3. Information hanterad i loggtjänsten

Loggtjänsten hanterar loggposter som ska ge tillräckligt underlag för att beskriva vilken typ av åtkomst som har skett till vårdinformationen, inom vilket syfte, av vem och i vilket uppdrag, rörande vilken resurs, där resursen oftast är en patient och ägs av någon vårdgivare.

Informationen skall kunna tjäna som underlag för att bedöma om åtkomsten till vårdinformationen har varit berättigad eller ej.

Tjänstekontrakten hanterar registrering av åtkomstloggar samt läsning av densamma.

3. Målbild och principer

3.1. Verksamhetsmässig målbild

Följande verksamhetskopplade mål och krav finns för tjänsterna:

• Stödtjänsterna för logghantering ska stödja de verksamhetskrav som utgår från PDL samt HSLF-FS 2016:40, paragraferna som rör uppföljning av access till vårdinformation i de nationella tjänsterna.
• Tjänsten ska möjliggöra för patienten att själv kunna få uppgifter om vilka vårdgivare som har haft access till patientens vårdinformation
• Inloggad personal ska vara starkt autentiserade, med SITHS eID eller motsvarande godkänd lösning.
  Notera att detta krav gäller inloggning i de applikationer som interagerar med de bakomliggande tjänsterna. 
• All hantering ska loggas
• Tjänsten skall kunna användas såsom en lokal tjänst.
• Patient skall kunna anges med identitet av typ Personnummer (PNR), Samordningsnummer (SNR), eller Nationellt Reservidentitet (NRID).
  

Se dokumentet Tillämpningsanvisning PDL-loggning på Ineras hemsida för vägledning.

3.2. Arkitekturella mål

3.2.1. Generella mål

• Följsamhet mot Nationella IT-strategin.
• Lösningen utformas i enlighet med gällande versioner av tekniska anvisningar så som T-bokens referensarkitektur [S2], tekniska målbilder för nationella tjänster och RIV tekniska anvisningar.
• Återanvändning av nationellt framtagna säkerhetslösningar och nationell katalogtjänst
• 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.

3.2.2. Specifika mål

• Tjänstegränssnitt (tjänstekontrakt) för all extern funktionalitet utan krav på specifik lokalt installerad programvara (Software Development Kit, SDK).
• RIVTA2.1 Basic Profile Säkerhetsmodell för tjänstegränssnitten [R2]. Transportsäkerhet ersätter meddelandesäkerhet.
• Kan nyttja tjänst genom att tjänsten litar på anropande system utan att systemet måste ha en säkerhetsbiljett för slutanvändaren (trust mellan system).
• Möjligt att nyttja tjänsterna var och en för sig efter behov (fristående tjänster).
• Tjänsterna kan publiceras på tjänsteplattform (virtualiseringsplattform), nationellt och/eller lokalt.
  • Undantaget är hämtningstjänsten som realiseras som en REST-tjänst eftersom det är en mycket lättviktig lösning för att hämta filer på jämfört med SOAP som RIVTA2.1 Basic Profile använder sig av.
• Stöd för en distribuerad arkitektur, där det är möjligt för en region/landsting/kommun att upprätthålla egna instanser av tjänsterna alternativt gemensamma molnbaserade tjänster, och samtidigt kunna samverka nationellt med loggtjänsten i nationella e-tjänster.

3.2.3. Planerade avsteg

För de vårdgivare som önskar följa upp åtkomsloggar som genereras i de nationella tjänsterna i sina egna, lokala logguppföljningssystem kommer detta kunna ske genom att de till sitt lokala system hämtar ”sina” loggposter från den nationella loggtjänsten via en specifik ”hämtningstjänst”. Dessa hämtningar kan innebära att stora mängder data ska överföras från den nationella loggtjänsten till det lokala logguppföljningssystemet. T.ex kan användningsfallet vara: Hämta alla mina loggposter mellan 2013-01-01 – 2013-01-31

Denna datamängd är ej lämplig att överföra via ett nationellt tjänstekontrakt och Tjänsteplattformen. Hämtningstjänsten använder ett överföringssätt (REST) som är mer optimalt för denna typ av användningsfall.

3.3. Prioriterade områden

I denna utveckling är prioriterat att anpassa tjänsterna till den nationella referensarkitekturen och vara oberoende av andra system.

Loggtjänstens syfte är i första hand för uppfyllande av krav enligt PDL och HSLF-FS 2016:40, paragraferna som rör åtkomstloggning.

4. Teknisk lösning

4.1. Översikt

Nedan bild visar övergripande hur tjänsterna nationell och lokal loggtjänst är realiserade:

Figur 3: Översiktlig intern vy av realiserad tjänst

De både tjänsterna har implementerats med en gemensam Java-plattform. I plattformen ingår grundläggande teknik såsom autentisering, webbtjänstestack, loggning, databashantering. På plattformen läggs sedan den lokala eller den nationella verksamhetsmodulen och dessa paketeras till två olika system.

Följande skiktning gäller för de båda systemen:

• Persistenslagret: Hanterar persistens mot databas och filarea.
• Tjänstelagret: Hanterar autentisering, åtkomstkontroll, validering, loggning samt transaktionshantering.
• Webbtjänstelagret: Transformerar XML-data till tjänsteobjekt och vice versa.
• GUI-lagret: Hanterar SAML-autentisering och webbsidor för slutanvändare.

4.1.1. Beroenden

Bilden nedan visar översiktligt beroenden till andra system och tjänster som loggtjänsten använder. Se [T1], [T2], [T3]

4.2. Signifikanta delar av lösningen

4.2.1. Webbtjänster

Eftersom loggtjänsten förväntas hantera stora mängder åtkomstloggar, har stor vikt lagts åt att i alla led att kunna skala skala systemet horisontellt vid behov.

4.2.1.1. Lagringstjänst

Bilden nedan visar en översiktlig bild hur lagringstjänsten är uppdelad i två delar:

Figur 4: Intern realisation av lagringstjänsten.

Den första delen ska så snabbt som möjligt kunna bearbeta av inkommande åtkomstloggar. Detta åstadkoms genom att enbart behörighetskontroll på den anropande tjänsten och att åtkomstloggen följer schemat. Därefter läggs åtkomstloggen i binärformat i en utav de behållare(mysql-databas) som finns tillgängliga och loggtjänsten returnerar att den tagit emot åtkomstloggen till den anropande tjänsten.

Den andra delen hämtar åtkomstloggarna kontinuerligt ifrån behållarna, samt delar upp dessa per vårdgivare. Åtkomstloggar tillhörande samma vårdgivare läggs i en lokal arkivfil för respektive vårdgivare. Dessutom signeras och kedjas åtkomstloggarna löpande med tjänstens certifikat för att man i efterhand ska kunna upptäcka om någon åtkomstlogg förvanskats eller tagits bort. Var sjätte timme alternativt när den lokala arkivfilen blivit 50Mb stor (konfigurerbara värden) zippas den ihop tillsammans med en metadatafil (som används av hämtningstjänsten bl.a.) och läggs på den gemensamma arkivarean. Skapandet av arkivfilerna, signeringen,kedjningen samt zippningen sker hela tiden strömmande varpå man undviker att behöva läsa upp stora mängder data i tjänstens minne vilket annars kan kräva stora mängder ram och riskera att sänka systemet vid hög last. Metadata lagras även i MySQL för att användas som ett index av den lokala tjänsten Söktjänst mot arkiv.

Genom att göra på detta sättet fås hög kapacitet för att ta emot stora mängder åtkomstloggar. Minnesanvändningen blir låg för att skapa arkivfilerna, dessutom får man mindre data på arkivarean (då ju dessa är filer zippade), jämfört med om man direkt hade läst in de i en databas då dessa ofta är optimerade för att snabbt söka fram data till förmån för att ta liten plats. Det är även enkelt att koppla in en arkivtjänst för långtidsförvaring då det är "vanliga" filer som kan kopieras. Arkivfilerna blir även signerade/kedjade vilket gör det svårt att i efterhand förvanska informationen. Nackdelen med lösningen är att det kan ta upp till 7 timmar (default) beroende på systemets konfiguration innan åtkomstloggarna blir sökbara.

4.2.1.2. Hämtningstjänst

Bilden nedan visar en översiktlig bild hur hämtningstjänsten fungerar.

Figur 5: Intern realisation av hämtningstjänst.

Hämtningstjänsten är en relativt enkel REST-tjänst som levererar den eller de arkivfiler (som redan finns skapade) och som matchar sökintervallet, Den anropande tjänsten behörighetskontrollas utifrån vårdgivare.

4.2.1.3. Söktjänst

Bilden nedan visar på hur söktjänsten är realiserad i två delar.

Figur 6: Intern realisation av söktjänsten.

Söktjänsten består av ett antal olika tjänster för att kunna leverera data i olika skärningar. T.ex. ur ett patientperspektiv eller personalperspektiv. Söktjänsten kan användas direkt av externa system men används också i loggadministrationsgui:t för att skapa de fördefinierade rapporterna där.

Söktjänsten består av två delar, där den ena delen ansvarar för att läsa in innehållet i de arkivfiler som finns på arkivarean till databasen (MongoDB). Denna del ansvarar även för att ta bort åtkomstloggar äldre än 18 månader. Inläsning till MongoDB sker kontinuerligt eftersom arkiven skapas så att en rapport kan genereras från befintliga loggposter i MongoDB.

Den andra delen i söktjänsten ställer frågorna mot databasen (MongoDB) och transformerar det till xml-data som levereras i tjänstekontrakten. För att ytterligare få upp hastigheten styrs alla skrivningar mot MongoDB:s Master-server och frågorna mot dess slav.

Som databasmotor för söktjänsten används MongoDB som är en snabb och skalbar lösning som vid behov kan dela upp databasen i ytterligare Replica Sets för att på så vis skala både läs och skrivprestanda men även storlek på databasen.

Söktjänstens kontrakt är konstruerade att vara "halv-asynkrona" för att vid onormala toppar kunna bibehålla funktionen utan att systemet ska gå ner. Detta åstadkoms genom att i normalfallet uppträder tjänsten synkront och man får ett resultat vid varje fråga, vid hög belastning köas istället anropen upp och istället returneras ett "kö-id" till den anropande tjänsten som denna använder i kommande anrop till söktjänsten för att så småningom få ett resultat tillbaka. På så vis startas inte nya körningar/trådar/minnesallokering för varje nytt anrop vilket i ett högt belastat system snabbt kan sänka det,

4.2.2. Tjänster i administrationsgränsnitt (GUI)

4.2.2.1. Söktjänst mot arkiv (endast lokalt installerad)

Söktjänst mot arkiv består av två tjänster som ska leverera data för en viss patient eller medarbetare längre tillbaka i tiden än 18 månader. Söktjänst mot arkiv kan bara användas i loggadministrationsgui:t för att hämta åtkomstloggar i XML format. 
Tjänsten använder loggarkiven som utgångspunkt och dessa måste ligga kvar i den gemensamma arkivarean för att kunna hanteras av tjänsten (upp till 10 år).

Kravet på denna tjänst är att kunna leverera ett resultat inom 72 timmar då upp till 10 år av loggposter ska hanteras. Tjänsten bör även vara konfigurerad att köras nattetid då den kan använda mycket resurser av systemet. Default är den konfigurerad att köras kl 22-06.

Söktjänsten mot arkiv består av flera delar.

• När en sökning initieras sker först en slagning mot MySQL (utifrån loggarkivens metadata) för att hitta vilka arkiv som håller uppgifter om aktuell patient eller medarbetare och vårdgivare samt inom vilket tidsspann som sökningen gäller,
• Arkiven som innehåller data med en viss patient eller medarbetare läses in i en temporär MongoDB, men bara de loggposter som är relevanta. Jobbet med att läsa in arkiven i en temporär MongoDB sker parallellt på alla noder i klustret för att minska belastningen per nod och snabba upp jobbet.
• När arkiven är inlästa sker en slagning mot MongoDB för att hämta ut loggposter sorterade och utifrån sökbehoven, samt sparar resultat i en XML fil.
• Sista steget komprimerar XML-filen till en .zip fil.

Alla stegen strömmar data för att säkerställa att minneshanteringen inte belastas för mycket då det kan handla om relativt stora datamängder.

Bilden nedan visar hur Söktjänst mot arkiv är realiserad i de olika delarna.

Figur 7: Intern realisation av Söktjänst mot arkiv

4.2.3. Tjänsteinteraktioner - princip för tekniska gränssnitt

Alla integrationsmönster som ingår i denna arkitekturbeskrivning baseras på nyttjande av löst kopplade tjänstegränssnitt mot tjänsterna (tjänstekontrakt), utan beroende till specifika agenter eller programmeringsbibliotek (SDK:er).

Det är självklart möjligt att använda och alternativt tillverka ett programmeringsbibliotek för en specifik plattform, men integrationspunkterna (kontrakten) mellan systemen är de bakomliggande tjänstekontrakten.

Nedan figur visar principen för de tjänsteinteraktioner som ingår i tjänstekontrakten. Kontraktet reglerar hela samspelet mellan konsument och producent.

Figur 8: Tjänsteinteraktion, Typfall "fråga - svar"

Integrerande vårdsystem anropar tjänsterna med webbtjänsteteknik enligt profilen RIV TA 2.1 [R2]. Det innebär i korthet att

• att tjänstekonsumenten har ett servercertifikat och kan hantera TLS med klientautentisering för säker kommunikation med tjänsteproducenten.
• att tjänstekonsumenten kan skicka och ta emot XML över HTTPS

4.2.4. Tjänsteplattform

Tjänstekontrakten är så utformade att anropet kan ställas mot en virtuell tjänst på en tjänsteplattform som sedan kan routas till korrekt tjänsteproducent.

Se vidare [S7] för mer information om tjänsteplattform och dess förvaltning.

Detta är en vital del av lösningen för de nationella tjänstekontrakten; t ex kontraktet för läsning av aktuella loggposter för en viss patient och vårdgivare förutsätter att anropet kan routas till den loggtjänst som håller informationen för den vårdgivaren.

Figur 9: Tjänsteinteraktion, Typfall "fråga - svar". Anrop via tjänsteplattform.

4.2.5. Autentisering och auktorisation av slutanvändare i webbklienter

I lösningen ingår fristående användargränssnitt i form av webbklient:

• Webbklient för personal inom verksamhet som har som uppgift att ta fram loggrapporter

Är det en patientingång, t ex 1177, hanteras funktioner och autentisering inom ramen för denna ingång.

För autentisering av personal som användare enligt ovan används:

• Stark autentisering sker med SAML-inloggning via IdP.
• Nationell katalogtjänst för uthämtande av egenskaper kopplade till användaren.
• Stöd för val av aktivt medarbetaruppdrag enligt HSA[1].

4.2.6. Ramverk för realisering av ingående tjänsteproducenter

Tjänsteproducenterna är internt uppbyggda med hjälp av följande tekniska ramverk:

Java

Java används för att realisera tjänsterna och möjliggöra exekvering på olika miljöer.

OSGi ramverk

Den Java-plattform som tjänsteproducenterna 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. OSGi är en komponentmodell med stöd för att hantera olika versioner/implementationer av samma komponent samtidigt samt att dynamiskt kunna byta ut komponenter under drift.

Ramverket tillhandahåller en standardiserad miljö för applikationer (bundlar) och består av fyra lager.

L0: Execution Environment – Exekverande miljö
L1: Modules – Moduler/Komponenter
L2: Life Cycle – Livscykel hantering
L3: Service Registry - Tjänsteregister

Figur 10: OSGI uppbyggnad

L0: Execution environment – Specificerar Java miljön. Java 2 konfigurationer och profiler som J2SE, CDC, CLDC, MIDP o.s.v. är alla möjliga att använda som exekveringsmiljöer.

L1: Modules – Definierar policies för klass laddning. OSGi ramverket är en kraftfull och strikt modell för class loading som bygger på Javas mekanismer för att ladda klasser men är utbyggt för att bättre hantera moduler/komponenter. I Java finns det normalt bara en classpath som innehåller alla klasser och resurser men med OSGi Modules får varje modul en egen privat classpath och allt som ska exponeras utanför en modul måste specificeras explicit.

L2: Life Cycle – Hanterar dynamisk installation, start, stopp, uppdatering och avinstallation av bundlar. Life Cycle använder sig av Modules för att utföra klassladdning men tillhandahåller ett API för hantering av moduler under drift.

L3: Service Registry – Tillhandahåller en dynamisk samarbetsmodell för bundlar. Bundlar kan samarbeta via traditionell klassdelning vilket inte är så kompatibelt med dynamisk installtion och avinstallation av kod, därför tillhandahåller Service Registry en modell för att kunna dela objekt mellan olika bundlar. Ett antal händelser är specificerade för att hantera att tjänster kommer och går, tjänster i detta fall är vanliga Java objekt. Många tjänster motsvarar server funktionalitet t.ex. en HTTP server medan andra kan vara vilket verksamhetsobjekt som helst.

En applikation i OSGi plattformen kallas för en bundle och kan beskrivas som ett vanlig Java ARchive (JAR) med ett utökat Manifest. Manifestet i en bundle specificerar vad den exporterar och vilka beroenden den har för att kunna exekvera i OSGi miljön.

En OSGi bundel innehåller vanliga Java klasser (POJO) som inte behöver vara beroende av OGSi API:t eller känna till att de exekveras som en OSGi bundle.

Figur 11. Schematisk överblick över en OSGi bundle

Varje komponent/bundle specificerar vad den tillhandahåller och vad den använder.

Om Servicekontraktet överensstämmer kopplar OSGi miljön ihop den komponent som tillhandahåller tjänsten med den som nyttjar tjänsten.

Metro

Metro är den webbtjänstestack som används inom tjänsteproducenterna. Den inkluderar bl.a. JAX-WS, WSIT, JAXB och implementation för många av de WS-* standarder som nyttjas av tjänsteproducenterna.
Tjänsteproducenterna realisering följer RIV TA 2.1.

Figur 12. Metro webbtjänstestack

JAX-WS är grundstommen för utveckling av SOAP baserade webbtjänster inom Java och är en standardteknologi i Java.

JAX-WS version 2.1.7 nyttjas loggtjänsten. JAXB binder XML schemat till Java klasser vilket gör det enkelt att hantera XML data. JAXB är en standardteknologi i Java

JAXB version 2.1.11 nyttjas av loggtjänsten.

Figur 13. JAXB - Bindning av schema till Java klasser

WSIT (Web Services Interoperability Technologies) är en implementation som utökar JAX-WS med mekanismer för att kommunicera med andra webbtjänstestackar på ett interoperabelt sätt, i synnerhet för Windows Communication Foundation (WCF).

WSIT innehåller stöd för meddelande optimering, säker meddelande transport, säkerhet osv. Det finns även stöd för bootstrapping och konfiguration.

WSIT ramverket är en implementation som utökar JAX-WS och JAXB. Bilden nedan visar vilka underliggande tjänster som är implementerade för varje område. De inringade tjänsterna är de som nyttjas av loggtjänsten.

WSIT version 1.5 nyttjas av loggtjänsten.

Figur 14. WSIT Web Service Features (inringade tjänsterna nyttjas av Loggtjänsten)

Tjänstepaketering

Tjänsteproducenterna följer internt samma mönster för paketstruktur för att möjliggöra olika driftsättningsscenarier, för att t ex möjliggöra skalbarhet för att öka prestanda.

Figur 15. Tjänstepaketering

Pakteringen ger även möjligheten att nyttja deltjänster såsom loggning och loggutdrag från andra logg implementationer.

4.2.7. Ramverk för realisering av ingående användargränssnitt/webbklienter

Ingående användargränssnitt nyttjar Google Web Toolkit (GWT) teknik som är kompatibelt med alla de större webbläsarna på marknaden idag.

5. Användargränssnitt

De administrativa användargränssittet tillgängliggörs som tjänst (enligt service provider), som använder normalt autentiseringförfarande (se ”SAMBI SAML Profil” [S9]) för att säkert autentisera aktörer. Detta innebär att SSO/SLO erhålls för administration av loggtjänsten.

5.1. Behörighetskontroll

För att få behörighet till de administrativa delarna, kan man vid installation konfigurera de egenskaper och värden som behövs för att få tillgång till de administrativa funktioner systemet tillhandahåller.

5.2. Användargränssnitt slutanvändare

Flera av säkerhetsfunktionerna sker "bakom scenen" utan att användaren ser något gränssnitt. Några användargränssnitt (webbklienter) finns dock med i lösningen. Lösningen stödjer att efter behov bygga andra GUI mot tjänsten.

5.2.1. Användargränssnitt inloggning

Användning av de nationella loggrapporterna kräver stark autentisering. Genom inloggning via Säkerhetstjänsternas autentiseringstjänst medför följande dialoger:

Figur 16: Dialog för att ange PIN till SITHS-kortet.

Notera att denna dialog är ett standardgränssnitt genereras av programvara på arbetsstationen (Net iD) i samband med att en webbklient kräver klientautentisering med TLS (kortinloggning).

Figur 17. Dialog för val av uppdrag (om flera finns)

Dialogen för uppdragsval för användare kan implementeras på olika sätt. Ovan visas exempel från nationella säkerhetstjänsten.
Om användare har flera kopplade uppdrag (även kallat medarbetaruppdrag) i Nationell katalogtjänst (HSA), ska ett av uppdragen aktiveras genom ett val. Egenskaper kopplade till valt uppdrag som nyttjas i lösningen för auktorisation i webbklienter, se kap 4.2.3.

5.2.2. Utformning av användargränssnitt

Användargränssnitt för administratörer 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.

Figur 7: Utformning av användargränssnitt.

Användargränssnittet är utformat efter principerna

• Enkelhet och avskalat men informativt
• Intuitiv navigering genom dialogerna.

5.2.3. Användargränssnitt loggadministration och uttag av loggrapporter

För att skapa rapporter samt se status på logg och rapporttjänsten. Se vidare användarhandbok [S11] .

5.3. Systemkrav för ingående användargränssnitt (webbklienter)

Följande webbläsare har testats:
Internet Explorer 11
Edge (kräver särskild paketering av Net iD)
Chrome
SITHS-programvara som testats är Net iD 6.5.x på Windows. 
Framtida versioner av Net iD, webbläsare och operativsystem måste kvalitetssäkras löpande.

6. Användningsfallsöversikt

6.1. Aktörsinformation

Nedan sammanställs de aktörer som behöver agera i de olika användningsfallen.

6.1.1. Aktörstyper

1)      Hälso -och sjukvårdspersonal (HoS verksamhetsansvariga)
Personer som har ansvar för verksamhetsuppföljning, uppföljning av vilka åtgärder som har vidtagits med patientuppgifterna.

2)      Lokala logguppföljningssystem
För att läsa/hämta loggposter från den nationella loggtjänsten.

3)      Patient
För åtkomst av information kring vilka vårdgivare som har tagit del av patientens vårdinformation.

4)      Nationella tjänster (NPÖ, Pascal), Lokala vårdsystem och Lokala Säkerhetstjänster utan loggtjänst
För lagring av loggposter på nationell loggtjänst.

5)      Lokala loggtjänster

6.1.2. Aktörer i integrationsscenarier

Figur 18: Aktörer HoS-personal med ansvar för logguppföljning, utan lokalt loggsystem.

Figur 19: Aktörer HoS-personal med ansvar för logguppföljning, med lokalt loggsystem

Figur 20: Aktören Patient 1177

Figur 21: Aktör nationell e-tjänst

Figur 22: Aktör via lokal logghantering

6.2. Primära användningsfall

Se Tjänstekontrakt Loggtjänsten [T3] för fler användningsfall

Figur 23: Schematisk översikt av primära användningsfall för Loggtjänst

6.2.1. Lagra loggar

Aktörstyp 4 och 5 skickar en lista med loggposter som valideras och lagras i loggtjänst. Om validering misslyckas lagras inga loggposter och anropet returnerar med en felkod och felmeddelande.

6.2.2. Sök loggar

Aktörstyp 1, 2 och 3 begär att får tillgång till PDL loggar inom sin vårdgivare som är upp till 18 månader gamla. Om aktören är behörig returneras en lista med PDL loggar som matchar de sökkriterier som angivits.

6.2.3. Sök loggar från loggarkiv

Aktörstyp 1 för en lokalt installerad loggtjänst begär att får tillgång till PDL loggar inom sin vårdgivare som kan vara upp till 10 år gamla. Om aktören är behörig returneras en lista med PDL loggar som matchar de sökkriterier som angivits.

6.2.4. Lista arkiv

Aktörstyp 2 och 5 begär en lista med befintliga arkiv inom ett datumintervall. Om aktören är behörig returneras en lista med arkiv. Tjänsten är en REST-tjänst och ingår inte i rivta.

6.2.5. Hämta arkiv

Aktörstyp 2 och 5 begär att få hämta ett arkiv inom sin vårdgivare. Om aktören är behörig returneras arkivet. Tjänsten är en REST-tjänst och ingår inte i rivta.

6.3. Sekundära användningsfall

Figur 23: Schematisk översikt av sekundära användningsfall för Loggtjänst

6.3.1. Kontrollera status

Möjlighet att se status på loggrapporttjänsten, tex om det finns arkiv som inte är inlästa i online databasen eller om arkiv ej kunnat läsas in i online databasen p.g.a. fel. Möjlighet finns då att försöka läsa in dessa igen genom osgi kommando.

6.3.2. 5.2.2. Generell administration

Administratör kan ändra den generella konkonfiguration för loggtjänsten.

7. Tjänstekontrakt

Nedan lista är en översikt av de tjänster som ingår för att stödja hanteringen av loggtjänstinformation.

Tjänstekontraktet Personuppgifter nyttjas av stödtjänsterna för att hämta personuppgifter för patienter.

Tjänstekontrakt för HSA används för att hämta organisationsinformation.

För en mer utförlig information se beskrivningar i [T1], [T2] och [T3].

Nedanstående tabell finns definierade i loggtjänsten

8. Sekvenser

Nedan följer exempel på typiska sekvenser, i nedan fall används loggtjänsten för att åskådliggöra principerna.

Figur 24: Flöde – Loggpostgenerering

Ovanstående diagram visar samspelet mellan det loggskapande systemet, vårdsystemet och loggtjänsten. Vårdsystemet skriver loggposter till loggklienten som ”paketerar” och ansvarar för översändandet av loggposter till loggtjänsten.

Figur 25: Flöde – Läsa loggposter

Figur 26: Flöde – Hämta loggposter

Ovanstående diagram visar hur man i en verksamhet med lokalt system för logguppföljning kan (batchvis/schemavis) hämta loggposter från den nationella loggtjänsten till sitt lokala system där uppföljning av loggarna sker. Loggposter som hämtas från loggtjänsten markeras som hämtade i loggtjänsten. Hämtning av loggposter kan ske antingen inom ett datumintervall alternativt hämta ej tidigare hämtade loggposter.

9. Uppfyllande av icke-funktionella krav

9.1. Icke-funktionella krav från verksamheten

9.1.1. Svarstider centrala instansen (Säkerhetstjänsten)

• Tjänsten ska kunna skala vertikalt och horisontellt för att kunna ge hög tillgänglighet,kapacitet och låga svarstider.
• Krav på låga svarstider för att ta ut loggrapporter. Absoluta merparten av loggrapporterna ska tillhandahållas inom ett tjänsteanrop.
• Kravet på att generera en loggrapport på data äldre än 18 månader är 72 timmar.

9.1.2. Svarstider lokala instanser

På de lokalt installerade tjänsterna hänger svarstiderna på aktuella miljöer såsom processorkraft, internminne och prestandan på nätverket som nyttjas.

9.1.3. Tillgänglighet

Systemet går att köra i s.k. klustrad miljö, där 1..n noder (server-instanser) körs parallellt med en lastbalanserare som delar lasten dem emellan.

Teknik för detta är Infinispan.

9.1.3.1. Nationell Säkerhetstjänst

Tillgängligheten på den centrala instansen (Säkerhetstjänsten) är specificerad till 99,8 %, vilket är ett kortare stopp (max 17,5h/år) innan den måste vara tillgänglig igen.

9.1.3.2. Lokal Säkerhetstjänst

Ansvaras av respektive huvudmans driftorganisation och är inte en del av systemet.

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

9.2.1. Test

För att underlätta för test finns systemloggning som kan justeras att logga på olika nivåer. Kan konfigureras att logga på nivåerna Trace, Debug, Info, Warning och Error.

9.2.2. Konfigurationsstyrning

Tjänsterna kan konfigureras vid installation men även under drift via Generell konfiguration (GUI).

9.2.3. SLA-övervakning

Tjänsterna övervakas via ett inbyggt övervakningsgränssnitt i java (JMX). Det används till att monitorera tjänsterna för att kunna se status på dessa. Till detta kan larmfunktioner kopplas på specificerade parametrar för att få snabb information vid eventuella fel och hitta värden som inte visar önskat värde.

9.2.4. Ping

Endast avsedd att användas av tjänsteplattformen (TP) för test att Loggtjänsten är tillgänglig.

10. Säkerhet

10.1. Infrastruktursäkerhet

Infrastrukturen för Loggtjä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 loggpostdata och förvanska dessa. Att begränsa åtkomsten löses normalt sett med en brandvägg samt att servrarna och databaser skyddas med användarnamn och ett starkt lösenord. Vilka som har åtkomst till servrar och databas skall vara dokumenterat.

10.2. Riskanalys

10.2.1. Centrala instansen (Säkerhetstjänsten)

Riskanalys för den centrala instansen (1=min, 3=max).

Åtgärder för ovanstående risker:

V1:

• Redundanta nätverk.
• Duplicerade in- och utgående kommunikationslinjer till både sjunet och internet.

V2:

• Använder GWT som förhindrar cross-site scripting.
• Kommunicerar via TLS för att förhindra avlyssning.
• Inloggning sker med SITHS-kort samt via OTP engångslösen.
• Tillgång till interna sjunetservrar styrs via brandväggar.
• Övergången från internet till sjunet via proxyservrar styrs genom att både näten är separerade och att all tillgång styrs via brandväggar förutom det vanliga inloggningsförfarandet.

V3:

• Redundanta tjänstservrar med duplicerade system med fail-over lösning.
• Klustrad lösning där fler servrar kan startas för att öka prestanda samt för att öka redundansen.
• Last balanseras för att uppnå optimal utnyttjande grad samt säkerställa och öka tillgänglighetsgraden på tjänsterna.
• Aktivt data delas mellan tjänsteservrar m.h.a Terracotta för att uppnå en kort fail-over tid. Terracotta används för att få en klustrad miljö och kunna dela vissa objekt mellan servrar, bla konfiguration och HTTP sessioner.

V4:

• Redundant databasserver med fail-over lösning.
• Ingående data verifieras och valideras innan data sparas internt.
• Storage – backup på databasen sker löpande.

V5:

• Behörighet till information styrs via användarens rättigheter som hämtas från HSA katalogen.
• Behörighet för andra tjänster styrs via dessa tjänstecertifikat som kopplas till de vårdgivare som tjänsten skall ha tillgång till.

10.2.2. Lokala instanser

Riskerna hanteras av respektive huvudmans egen infrastruktur och är inte en del av systemet.

10.3. Riskminimering i den tekniska lösningen

Riskerna med den tekniska lösningen motverkas genom

• att använda beprövade integrationsmönster och standardiserade tekniker
• att erbjuda alternativa integrationsmönster för att möta olika förutsättningar hos systemleverantörerna
• att integrationspunkterna är löst kopplade tjänstekontrakt, vilket minskar risk för förvaltningsproblematik
• att arkitekturen medför skalbarhet genom att fler noder kan kopplas in efter behov
• att användagränssnitten baseras på GWT som bl.a förhindrar cross-site-scripting och POSTning av felaktiga formulärer m.m.
• Kodgenerering

10.4. Intrångsskydd

Intrångsskydd finns för de nationella driftnoderna för säkerhetstjänsterna [P1].

Intrångsskyddet för de lokala installationerna beror på respektive huvudmans egen infrastruktur.

10.5. Insynsskydd (kryptering)

TLS används i all kommunikation med stödtjänsterna, säkerhetstjänsterna samt HSA.

10.6. Transportoförvanskning.

TLS används i all kommunikation med stödtjänsterna, säkerhetstjänsterna samt HSA.

10.7. Presentationskorrekt

Validering sker vid all registrering av data enligt de principer som gäller för respektive data vilket säkerställer att data är korrekt.

Tillgång till användargränssnitt kräver stark autentisering.

Appliceras t ex på framtagande av anpassat användargränssnitt för loggrapporter.

10.8. Dataintegritet (Oförvanskat över tid), riktighet

Riktigheten i systemets verksamhetsloggar och persistent data (databas) skyddas med hjälp av respektive huvudmans egen infrastruktur och är inte en del av systemet.

10.9. Autentisering (”stark” vid behov enligt infoklassning)

Kopplar till krav vid åtkomst av vårdinformation enligt PDL. Samtliga inloggade användare ska vara starkt autentiserade.
I vården innebär det ofta inloggning med SITHS-kort.

10.10. Lagkrav

Se sammanställning i [S8].

10.11. Krav på historiska data och gallring

10.11.1. Nationell instans

Åtkomstloggar som är maximalt 18 månader finns tillgängligt via de läsande tjänsterna. 
Behöver man göra uppföljning på äldre loggar måste man beställa dessa separat via förvaltningsorganisationen. Dessa ska då normalt levereras inom 2 veckor från dess att beställningen är gjord.

10.11.2. Lokala instanser

Åtkomstloggar som är maximalt 18 månader finns tillgängligt via de läsande tjänsterna.

Uppföljning på loggar äldre än 18 månader kan tas fram på de lokala instanserna av en loggadministratör via administrations GUI (Söktjänst mot arkiv). Loggarkiven måste då ligga kvar under den gemensamma arkivarean. Rapporten (Söktjänst mot arkiv) har krav på sig att färdigställas inom 72 timmar.

10.12. Spårbarhet (loggning)

Åtkomst till loggposter skall loggas. Loggposter som hämtas via hämtningstjänsten skall markeras såsom ”hämtade”.  Om aktiviteten utförs i vårdsystemet, ansvarar vårdsystemet för den loggning som behövs.
Utförs aktiviteten i applikation (användargränssnitt) mot stödtjänsterna, ansvarar den applikationen för nödvändig loggning.

Loggningen ska motsvara lagkraven på spårbarhet enligt PDL och Socialstyrelsens riktlinjer. Se även Datainspektionens checklista för logguppföljning i vården.

Lösningen ska möjliggöra att hantera uppföljning av åtgärderna på ett sammanhållet sätt i verksamheten. Rapportuttag är möjligt genom administrationsgränssnittet. Rapport kan genereras baserad på händelser för en patient eller händelser för en användare. Åtkomst till loggposter kontrolleras på vårdgivare nivå.

10.12.1. Logginformation som sparas vid aktiviteter för loggpostläsning

Se Tjänstekontrakt Loggtjänsten [T3].

11. Informationsmodell

Se vidare [S8] som är styrande för informationsmodellen.

Förenklade vyer av informationsmodellerna visas i nedan figurer:

Figur 33: Informationsmodell Loggpost (något förenklad) Datamodell

För mer information se [T1], [T2] och [T3] .

12. Driftaspekter

(Skalbarhet, Versionshantering, Uppdatering utan avbrott)(Deployment vy)

<tillhör implementering, se dock översikt>

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

Produkten kommer att kunna installeras och driftas under Windows Server 2008 R2, samt RedHat version 5 eller senare.

12.1. Programvaror

Tjänsteproducenterna kräver följande programvaror:                                                                                                                

• Java SE 8 – 64-bit
• MySQL Server version 5.6.x (eller 5.7) – 64-bit
• Mongo Db version 3.4.x - 64bit

12.2. Produktionssättning och överlämning till förvaltning

För mer information se dokumentation för installation och administration.

13. Följsamhet mot T-bokens styrande principer

13.1. IT2: Informationssäkerhet

13.2. IT3: Nationell funktionell skalbarhet

13.3. IT4: Lös koppling

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

14. Referenser

14.1. Bilagor

14.2. Styrande dokument

14.3. Stödjande dokument

14.4. Integrationstjänster

I tabellen kan referenser förekomma som inte direkt är nyttjade i tjänsten. Enbart rader refererade i denna SAD nyttjas.

14.5. Plattformsfunktioner

I tabellen kan referenser förekomma som inte direkt är nyttjade i tjänsten. Enbart rader refererade i denna SAD nyttjas.