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.

Tjänster som idag använder tjänstekontrakten för att där hantera PDLs krav på att logga åtkomst av patientinformation är bland andra Nationell Patientöversikt, Intygstjänster/Rehabstödet, Infektionsverktyget och Webcert.

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 på hanteringen av loggar från de nationella tjänsterna (ex Nationell patientöversikt och Pascal) 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, arkitekturledning, systemarkitekter och utvecklingsteam.

1.3. Referenser

1.3.1. Styrande dokument

1.3.2. Stödjande dokument

1.3.3. Versionshistorik

2. Arkitekturell översikt

2.1.  Arkitekturella mål

2.1.1.  Mål

2.1.2. 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.

2.1.3. 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].
• 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å nationell tjänsteplattform (virtualiseringsplattform).

2.1.4. Planerade avsteg

Inga planerade avsteg.

2.2. 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.

3. Följsamhet till T-boken

3.1. Följsamhet mot T-bokens styrande principer

3.1.1. IT2: Informationssäkerhet

3.1.2. IT3: Nationell funktionell skalbarhet

3.1.3. IT:4 Lös koppling

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

3.1.5. IT6: Samverkan i federation

4. Användningsfall

4.1. Användningsfall - Översikt

4.2. Aktörsinformation

4.2.1. Vårdpersonal

Användare som loggar in i vårdsystem och får åtkomst till patientdata varvid vårdsystemet registrerar accessen som en logg i Loggtjänsten.

4.2.2. Loggadministratör

Användare som loggar in i loggrapportgränssnittet för att söka efter loggar och gör detta med ett medarbetaruppdrag som har syftet Administration alternativt Tillsyn och utvärdering samt har den personliga systemrolls-egenskapen BIF;Loggadministratör.

4.2.3. Systemadministratör

Användare som loggar in i systemet med ett medarbetaruppdrag med syftet Administration samt har den personliga systemrolls-egenskapen BIF;Administratör.

I praktiken ska användarens HSA-id även finnas med i en lista med "vitlistade" användare.

4.2.4. Vårdsystem

Vårdsystem som behöver registrera eller hämta loggar ansluter och autentiserar sig genom Nationella tjänsteplattformen.

4.3.  Logisk realisering användningsfall

4.3.1. AF1 - Lagra loggar

4.3.1.1.  Textuell beskrivning

Ett vårdsystem lagrar logg(ar) över en användares access till patientuppgifter m.h.a tjänstekontraktet StoreLog.

Aktörer: Vårdpersonal/Vårdsystem

Förutsättningar: Vårdpersonal inloggad i vårdsystemet och vårdsystemet ansluten till tjänstekontraktet StoreLog. 

4.3.1.2.  Realisering

4.3.2. AF2 - Hämta loggar

4.3.2.1.  Textuell beskrivning

Ett system hämtar loggar för visning/behandling i det egna systemet för vårdpersonal eller patient.

Aktörer: Vårdsystem

Förutsättningar: Vårdsystemet ansluten till något av tjänstekontrakten för hämtning av loggar. 

4.3.2.2.  Realisering

4.3.3. AF3 - Söka loggar

4.3.3.1.  Textuell beskrivning

Loggadministratörer, som enligt patientdatalagen (PDL) måste göra uppföljningar av journalåtkomster, hämtar loggrapporter via loggtjänstens loggrapport-GUI. 

Aktörer: Loggadministratör

Förutsättningar: Loggadministratören inloggad i med rätt behörighet i loggrapportgränssnittet.

4.3.3.2.  Realisering

4.3.4. AF4 - Administrera tjänsten

4.3.4.1.  Textuell beskrivning

En systemadministratör från Inera, drift- eller applikationsförvaltaren skall kunna administrera viss konfiguration via ett webbgränssnitt.

Aktörer: Systemadministratör 

4.3.4.2. Realisering

Realiserat genom ett webbgränssnitt med egen adress som endast kan nås genom driftleverantörens VPN. '

Här hanteras:

• Truststore
• Certifikatsnycklar
• Behörighet webbgränssnitt för loggrapporter
• Behörighet webbgränssnitt för systemaministration
• Behörighet för webbserviceanrop.
• Viss övervakning
• Viss statistik  

5. Icke-funktionella krav

5.1. Icke-funktionella krav från verksamheten

5.1.1.  Svarstider

Specificeras i Tjänstekontraktsbeskrivningen. 

5.1.2. Tillgänglighet

Specificeras i Tjänstekontraktsbeskrivningen. 

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

5.2.1. Test

TBD BY INERA

5.2.2. Konfigurationsstyrning

TBD BY INERA

5.2.3. SLA-övervakning

TBD BY INERA

5.2.4. Visning av driftsstatus

TBD BY INERA

6. Teknisk lösning

6.1. Översikt

Tjänsten är realiserad i tre applikationer som är installerade i OpenShift. En applikation som hanterar alla WS-anrop för att lagra och hämta åtkomstloggar. En annan applikation som presenterar en användargränssnitt (webbsida) för att beställa loggrapporter i PDF eller XML-format samt en tredje applikation för ett administrationsgränssnitt där allt från behörigheter och certifikatsnycklar kan hanteras.

WS-applikationens endpoints skyddas med dubbelriktad TLS och de båda webbgränssnitten kräver inloggning via Ineras IdP.

Databasen MongoDB används för persistens och Redis för att hantera nod/clustergemensamma cacher.

Figur: Lösningsöversikt - fysisk vy.

Applikationerna är skrivna i Java 17 med ramverket Spring/Spring Boot samt Angular för webbgränssnitten.

Applikationerna nyttjar ett common-bibliotek för funktionalitet gemensamma för flera projekt inom förvaltningen som Spärr, Samtycke, IdP och Personuppgiftstjänsten. Exempel på sådan funktionalitet är integration med tjänster som HSA, IdP och Personuppgiftstjänsten.

• Ineras IdP används för att autentisera användare av systemet.
• Loggtjänsten används för att logga aktiviteter enligt PDL och möjliggöra uppföljning av händelser.
• HSA är en katalogtjänst som håller användarinformation där användare som vill få åtkomst till tjänsterna måste finnas upplagda.
• Personuppgiftstjänsten (PU i bilden ovan) tillhandahåller ett antal tjänstekontrakt som nyttjas för att hämta personuppgifter för patienter. Personuppgiftstjänsten nyttjar b.l.a. Navet som är Skatteverkets personadressregister för myndigheter som omfattar alla personer som finns folkbokförda i Sverige.

Figur: Intern vy av realiserade tjänster

Följande skiktning gäller för systemet: 

• Persistenslagret:
  • Hanterar persistens mot databasen.
• Tjänstelagret:
  • Certifikat-autentisering på web service anrop sker via Autentiseringen.
  • Loggning sker via gränssnitt för Loggning och utförs vid alla typer av registreringar, makulering, återkallande och uttag av rapporter. HSA katalogen nyttjas för att hämta information om aktör.
  • Validering utförs på inkommande data. Tjänstekontraktet Personuppgifter nyttjas vid registrering för att validera angiven personidentitet (PNR, SNR, NRID) och hämta personuppgifter.
  • Uttag av rapport för logguppföljning. Loggdata returneras efter åtkomstkontroll på vårdgivarenivå.
• Webbtjänstelagret:
  • Transformerar XML-data till tjänsteobjekt och vice versa.
• GUI-lagret:
  • Hanterar OIDC-autentisering och webbsidor för slutanvändare genom att nyttja Ineras IdP.

6.2. Beskrivning av arkitekturellt signifikanta delar av lösningen

6.2.1. Säker persistens med Merkle tree -blockkejdor

För att säkerställa att loggarna är riktiga och oförvanskade under lagringstiden lagras dessa i databasen som ett Merkle Tree där varje nod får en kryptografisk hash från ett block av data/loggar och varje block kedjas m.h.a en hash från undernoder.

Bakgrundsjobb för validering av hashträden/kedjor exekveras regelbundet.

6.2.2. Integration med HSA

Tjänsten interagerar med HSA's tjänstekontrakt genom Nationella Tjänsteplattformen för att hämta information om användaren som loggat in samt när loggrapporter skall hämtas med anseende på personal.

6.2.3. Integration med Loggtjänsten

Tjänsten interagerar med Loggtjänstens tjänstekontrakt genom Nationella Tjänsteplattformen för att lagra aktivitetsloggar enligt PDL.

6.2.4. Integration med Personuppgiftstjänsten

Tjänsten interagerar med Personuppgiftstjänstens tjänstekontrakt genom Nationella Tjänsteplattformen för att hämta namn på patienten när loggrapport tas ut med avseende på patient.

6.2.5. Autentisering

Tjänsten nyttjar Ineras IdP för säker inloggning till användargränssnittet. Tillitsnivån skall vara LoA3 och användaren behöver ett antal attribut från inloggningen för att få access till de olika funktionerna. Sen användarhandboken för specifikation på vilka attribut som krävs för vilka funktioner.

6.2.6.  Bakgrundjobb för att skicka loggar till Loggtjänsten

För att inte vara beroende av att loggtjänsten är tillgänglig skrivs loggarna till lokal databas innan ett bakrundsjobb kontinuerligt hanterar kön med loggar som då skickar loggarna till Loggtjänsten när det är möjligt.

6.2.7. Bakgrundsjobb för rensning av loggrapporter

Loggrapporter som inte tagits bort av användaren rensas automatisk bort efter konfigurerbar tid.

6.3. Realisering av användargränssnitt

Ingående användargränssnitt nyttjar Angular. Ett ramverk som är kompatibelt med alla de större webbläsarna på marknaden idag.

6.4. Felhantering

Se dokumentet Svarskoder och systemloggar för WS-kontrakt i Loggtjänsten [B6].

7. Säkerhet

7.1. Klassificering av information

Se dokumentet Informationsspecifikation för Loggtjänst [B5] .

7.2. Riskområden

7.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å Angular som bl.a förhindrar cross-site-scripting och POSTning av felaktiga formulärer m.m.
• att använda väl beprövade verktyg för kodgenerering

7.4. Principer för utveckling av säker programkod

Följande principer har följts för att åstadkomma så säker programkod som möjligt:

• Följande av väl etablerade och nertecknade standarder för säkerhet.
• Välkända och uppdaterade bibliotek och ramverk.
• Välkända och uppdaterade kryptografiska bibliotek.
• Verktyg för statisk kodanalys.
• Löpande manuell kodgranskning.
• Väl etablerade rutiner för verifiering samt system- och acceptanstest.

7.5. Intrångsskydd

Systemet skyddas från intrång med hjälp av driftsorganisationens egen infrastruktur samt noggrant testad behörighetskontroll i systemet.

7.6. Insynsskydd (kryptering)

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

7.7. Riktighet

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

7.8. Autentisering

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.

7.9. Lagkrav

Loggtjänsten syftar till att stödja processen att logga direktåtkomst inom sammanhållen journalföring enligt Patientdatalagen (PDL) genom att lagra åtkomstloggar åt anslutna system och möjliggöra uppföljning av dessa. 

7.10. Spårbarhet

Samtliga användarstyrda aktiviteter ska loggas enligt PDL vilket även innefattar uppföljning genom rapportuttag.

Ifall aktiviteten utförs av konsumerande vårdsystem ansvarar det vårdsystemet för den loggning som krävs. 

Loggningen ska motsvara lagkraven på spårbarhet enligt PDL och Socialstyrelsens riktlinjer.

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 loggtjänstens användargränssnitt. 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årdgivarnivå. 

7.10.1. Logginformation som sparas vid uttag av loggrapporter

Nedan följer en lista med information som loggas vid uttag av loggrapporter i Loggtjänstens användargränssnitt för loggrapporter.

8. Nyttjade tjänstekontrakt

9. Nyttjade plattformsfunktioner

10. Informationshantering

10.1. Domäninformationsmodell

För information om datatyperna se Tjänstekontraktsbeskrivning för Loggtjänsten [T4].

10.2. Informationens ursprung

10.2.1. Information som konsumeras

• Personuppgifter - namn på patienter genom uppgifter från Personuppgiftstjänsten.
• Användarinformation - Namn och organisatorisk tillhörighet genom uppgifter från HSA-katalogen.

10.2.2. Information som skapas

• Patientdata - En logg innehåller patientdata i form av information om vilka vårdgivare och vårdenheter patienten har besökt.

11. Driftaspekter

11.1. Lösningsöversikt

11.2.  Logisk anslutningsarkitektur

11.3. Fysisk miljö

Systemet byggs och konfigureras för att installeras i OpenShift och har stöd för att ingå i ett kluster av sådana noder. Beskrivning av sådan "fysisk miljö" står driftleverantören för. 

11.4. Programvaror

• Java SE 17
• MongoDB 5.0.13
• Redis 6.2.7

11.5. Detaljerad information

Loggtjänstens driftshandbok  innehåller detaljerad information om driften av tjänsten. Kräver behörighet och inloggning.

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

Se Loggtjänstens driftshandbok. Kräver behörighet och inloggning.