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.
Figur: Loggtjänsten i Säkerhetstjänster
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.
Målgrupp
De huvudsakliga målgrupperna för detta dokument är beställare, arkitekturledning, systemarkitekter och utvecklingsteam.
Tjänsteplattform, lokalt såväl som nationellt, är en möjlig förmedlare av tjänsterna. Tillför möjlighet till internetanslutning samt förenkling av integrationspunkterna och vägval för att hitta viss producerande tjänst
Första version för 3.0 med nya mallen från ARK_0013 på RIVTA.SE (Confluence-mall finns hos CGI)
Arkitekturell översikt
Arkitekturella mål
Mål
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.
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).
Planerade avsteg
Inga planerade avsteg.
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.
Följsamhet till T-boken
Följsamhet mot T-bokens styrande principer
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.
Åtkomstloggar ska kunna konsumeras på vårdsystemets villkor. Det finns stöd för att hämta hem en vårdgivares loggar till ett eget system för analys. Konsumenter skall dock ha stöd för att köa upp åtkomstloggar på konsumentsidan ifall Loggtjänsten skulle vara tillfälligt otillgänglig.
Loggtjänsten är designad för att kunna installeras på flera noder för redundans.
För Loggrapport-verktyget är det ett grundläggande krav att användaren kan loggas in på ett säkert sätt med korrekta rättigheter från nationell katalogtjänst. Ifall IdP och/eller HSA är otillgänglig kan inte nya användare logga in i systemet. Dock finns en möjlighet att redan inloggade användare kan fortsätta att arbeta.
Tjänstekontrakten har inga beroenden till externa system.
Det grafiska användargränssnittet använder IdP, HSA, Loggtjänsten och Personuppgiftstjänsten.
IdP - Kritiskt för inloggning i systemet.
HSA - Kritiskt för IdP.
Loggtjänsten - PDL-loggar sparas i lokal databas innan dessa skickas till Loggtjänsten för att inte vara beroende av Loggtjänstens tillgänglighet.
Personuppgiftstjänsten - Namn på patienten är inte ett krav för hämtning av loggrapport vilket innebär att tjänsten fungerar utan fungerande koppling till Personuppgiftstjänsten .
Verksamhetskritiska gemensamma 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 gemensam master.
Möjlighet till att mellanlagra internt i konsumenten finns. Efter beslut från Inera så levereras dock inte Loggtjänsten för lokal installation.
Krav mellan integrerade parter måste regleras, informationsägaren ska godkänna att ett visst system får agera mot informationen genom ett visst tjänstekontrakt.
Exempelvis skall enligt integrationsprocessen för den gemensamma tjänsteplattformen ett överenskommelsesnummer för en integrationsöverenskommelse 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.
Tillämpas för
HSA-integrationen HSA-RIV
Säkerhetstjänster genom integrationsavtal
Tjänsteplattform genom integrationsavtal
Arkitekturen måste möjliggöra tillräcklig tillgänglighet vid flera samverkande system.
Uppfylls genom design för hög tillgänglighet enligt detta dokument.
En sammantagen tolkning av tillämpliga lagar och förordningars konsekvenser för teknisk realisering av informationsfångst, utbyte och lagring.
Utvecklingen följer RIV-specifikationen.
Förutsättningar för spårbarhet etableras i form av loggningsregler för komponenter som deltar i säkert informationsutbyte.
Uppfylls genom användande av nationell lösning för loggning för verksamhetens behov av uppföljning av aktiviteter.
Interoperabla, internationellt beprövade och för leverantörer tillgängliga standarder tillämpas för kommunikation mellan parter som har upprättat tillit.
Uppfylls för stödtjänsterna genom nyttjande av
Tekniska profilen RIV-TA BP 2.1
För webbklienter som ingår nyttjas för autentisering, SSO och auktorisation:
TLS
SAML 2.0 Web SSO Profile
OIDC Core
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.
Uppfyllt
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.
Hanteras inom ramen för tjänsteförvaltningen.
Integration ska ske över en integrationsinfrastruktur (t.ex. virtualiseringsplattform) som möjliggör uppföljning av tjänsteproducenters fullföljande av SLA.
Uppfylles genom nyttjande av nationell tjänsteplattform. Lokala tjänsteplattformar kan och bör också nyttjas.
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)
Uppfylles genom att
Tjänsterna kan delas mellan vårdgivare efter behov genom s.k logisk uppdelning.
Stöd för godtycklig vårdgivare i HSA.
IT:4 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.
Uppfylles genom användande av verksamhetsbaserad adressering (typiskt vårdgivare) enligt RIV TA.
En arkitektur som skapar lös koppling mellan konsumenter och producenter, avseende adressering och standarder för kommunikation.
Uppfylles, se Meddelandeutbyte och Interoperabla standards enligt ovan.
En nationell integrationspunkt ska kunna erbjudas för varje nationellt standardiserat tjänstekontrakt, som en fasad mot bakomliggande brokiga systemlandskap.
Tillämpas via Nationell tjänsteplattform.
Nationella tjänstekontrakt förvaltas i en nationellt koordinerad förvaltning.
Tillämpas för de nationella tjänstekontrakten.
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.
Se RIVTA.SE för de informations- och begreppsmodeller som utgör grund för lösningen.
Parter som samverkar i enlighet med arkitekturen integrerar med system hos parter som lyder under annan styrning (t.ex. myndigheter, kunder och leverantörer). Det kan leda till att vård- och omsorgsgivare antingen:
Nationellt bryggar informationen (semantisk översättning) eller
Nationellt införlivar externt förvaltat tjänstekontrakt som standard.
Observera att semantisk bryggning av information till vårdens referensmodell förutsätter en nationell förvaltning av bryggningstjänster.
För att införliva ett externt förvaltat tjänstekontrakt förutsätts en transparent, robust och uthållig tjänstekontraktsförvaltning hos den externa parten.
<Ej tillämpbar>
Befintliga system behöver anpassas till nationella tjänstekontrakt. Detta kan göras av leverantörer direkt i produkten, eller genom fristående integrationskomponenter (”anslutningar”). En anslutning bör ligga nära (logiskt vara en del av) det system som ansluts, oavsett om det är i rollen som konsument eller producent för anslutningen som genomförs.
Tillämpas vid implementation/anslutning av vårdsystem till Loggtjä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).
Tillämpas, se Meddelandeutbyte och Interoperabla standards enligt ovan. De interoperabla, web service-baserade gränssnitten, rekommenderas för integrationen för god förvaltningsbarhet.
IT5: Lokalt driven e-tjänsteförsörjning
Förutsättningar att uppfylla
Uppfyllnad
När utveckling av källkod är en del av en tjänsteleverans skall följande beaktas:
Alla leveranser tillgängliggörs under öppen källkodslicens. Valet av licensformer samordnas nationellt genom rekommendationer.
Utvecklingen bedrivs från start i en allmänt tillgänglig (över öppna nätverk) projektinfrastruktur där förvaltningsorganisation kan förändras över tiden inom ramen för en kontinuerligt tillgänglig projektinfrastruktur (analogi: ”Projektplatsen för e-tjänsteutveckling”).
Det innebär full insyn och åtkomst för utvecklare till källkod, versionshantering, ärendehantering, stödforum och andra element i en projektinfrastruktur under projektets och förvaltningens hela livscykel.
Upphandlade e-tjänster fungerar på de vanligaste plattformarna hos vårdgivarna och hos nationella driftspartners (Windows, Linux, Unix) t.ex. genom att vara byggda för att exekvera på en s.k. Java virtuell maskin.
Gemensam referensmodell för e-tjänsters interna uppbyggnad stimulerar och förenklar återanvändning och överföring av förvaltningsansvar mellan organisationer.
Lösningen bygger på öppen källkod.
I väntan på att infrastruktur byggs på Inera så hanteras källkod och projektdokument i CGI's system där Inera's förvaltningsgruppering har full insyn.
Efter beslut hos Inera så levereras inte tjänsten som lokal installation hos vårdgivarna. Tjänsten byggs i Java vilket gör den plattformsoberoende men konfigurationen som levereras är specifik för Inera's driftleverantör.
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.
Tjänsten stödjer Singel Sign On med tjänster som nyttjar Ineras IdP.
Tjänstekontraktens Soap-gränssnitt följer RIV 2.1
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.
Drivs av val av plattform hos Ineras drifleverantör.
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.
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.
IT6: Samverkan i federation
Förutsättningar att uppfylla
Uppfyllnad
Att gemensamma gränssnitt i alla federativa utbyten finns framtagna och beskrivna, vilket möjliggör kostnadseffektiva och leverantörsneutrala lösningar.
För tjänsteinteraktionerna med vårdsystem nyttjas tjänstekontrakt enligt RIV TA BP 2.1.
Det behövs organ och processer för att godkänna utgivare av elektroniska identitetsintyg och certifikat som är giltiga i federationen.
Aktörer i olika nät, inklusive öppna nät ska vara välkomna i elektronisk samverkan genom att samverkande komponenter är säkra.
Två-vägs TLS enligt RIV TA BP 2.1.
För webbapplikationer nyttjas TLS autentisering med stöd av certifikat samt OIDC-intyg.
Att Ingående parter i federationen är överens om ett antal gemensamma ståndpunkter:
att stark autentisering likställs med 2-faktors autentisering
att vid samverkan acceptera följande metoder för stark autentisering; eID, PKI med lagring av nyckelpar på SmartCard eller motsvarande och metoder baserade på engångslösenord, antingen genererade i en fysisk enhet eller säkert distribuerad till fysisk enhet
att tillämpa en gemensam certifikat- och utfärdarpolicy, likvärdig med SITHS, som ett minimikrav för egen eller annans PKI
att sträva mot en autentiseringslösning, framför flera olika, för att realisera stark autentisering i den egna organisationen och i federation
att enbart acceptera SAMLv2, eller senare version, vid identitetsfederering samt tydliggöra att det i förekommande fall är det enda sättet att logga in och säkerställa det inte finns någon bakväg in
att tillämpa ett gemensamt ramverk för att ingå i en federation
att tillämpa en gemensam katalogpolicy, med utgångspunkt från HSA policy, som ett minimikrav för egna kataloger
att sträva mot att all gränsöverskridande kommunikation skall vara möjlig både över Sjunet och Internet. Det är den egna organisationen som beslutar vilken tillgänglighet som är tillräcklig för anslutningen
att sträva efter att möjliggöra kontroll av trafik till och från den egna infrastrukturen i en eller få kontrollpunkter
att utgå från att kommunikation över Internet och Sjunet har ett likvärdigt skyddsbehov
Lösningen stödjer en sådan kommande federation genom användning av
Autentisering:
Nationell extern IdP med OIDC som teknik.
SITHS-kort/certifikat och tillhörande utfärdarpolicys
HSA: HSA som katalogtjänst; från HSA hämtas alla användaregenskaper såsom rättigheter.
Nät: Tjänster som kommer att vara åtkomliga både via Internet eller Sjunet. Oavsett vilket nät som används säkras tjänsterna enligt ovan, d v s i grunden utgår lösningen ifrån att samma skyddsbehov finns i båda fallen. För exponering mot Internet följs även Sjunets säkerhetsregler, vilket tillför ytterligare skyddsmekanismer.
Tjänster som exponeras via Tjänsteplattformen använder den nätverksexponering mot Internet som Tjänsteplattformen tillhandahåller.
Användningsfall
Användningsfall - Översikt
Ref
Dokument ID
Dokument
AF1
Lagra loggar
Aktör 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. Detta görs uteslutande genom tjänstekontraktet StoreLog (se Tjänstekontraktsbeskrivning)
AF2
Hämta loggar
Aktör hämtar loggar utifrån ett av flera perspektiv (Vårdgivare, patient, användare m.fl). Hämtning av loggar görs via ett antal GET-tjänstekontrakt (se Tjänstekontraktsbeskrivning)
AF3
Söka loggar
Aktören loggar in i loggrapportgränssnittet och fyller i ett formulär med sökkriterier. Ifall aktören är behörig returneras en lista med PDL loggar som matchar de sökkriterier som angivits.
AF4
Administrera tjänsten
Figur: Schematisk användningsfallsöversikt.
Aktörsinformation
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.
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.
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.
Vårdsystem
Vårdsystem som behöver registrera eller hämta loggar ansluter och autentiserar sig genom Nationella tjänsteplattformen.
Logisk realisering användningsfall
AF1 - Lagra loggar
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.
Realisering
AF2 - Hämta loggar
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.
Realisering
Image RemovedImage Added
AF3 - Söka loggar
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.
Realisering
Image RemovedImage Added
AF4 - Administrera tjänsten
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
Realisering
Realiserat genom ett webbgränssnitt med egen adress som endast kan nås genom driftleverantörens VPN. '
Icke-funktionella krav från Systemägaren/Förvaltaren
Test
TBD BY INERA
Konfigurationsstyrning
TBD BY INERA
SLA-övervakning
TBD BY INERA
Visning av driftsstatus
TBD BY INERA
Teknisk lösning
Ö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.
Figur: Systemberoenden till andra system och tjänster för Loggstjä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.
Image Removed
Image Added
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.
Beskrivning av arkitekturellt signifikanta delar av lösningen
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.
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.
Integration med Loggtjänsten
Tjänsten interagerar med Loggtjänstens tjänstekontrakt genom Nationella Tjänsteplattformen för att lagra aktivitetsloggar enligt PDL.
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.
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.
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.
Bakgrundsjobb för rensning av loggrapporter
Loggrapporter som inte tagits bort av användaren rensas automatisk bort efter konfigurerbar tid.
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.
Felhantering
Se dokumentet Svarskoder och systemloggar för WS-kontrakt i Loggtjänsten [B6].
Säkerhet
Klassificering av information
Se dokumentet Informationsspecifikation för Loggtjänst [B5] .
Riskområden
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
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.
Intrångsskydd
Systemet skyddas från intrång med hjälp av driftsorganisationens egen infrastruktur samt noggrant testad behörighetskontroll i systemet.
Insynsskydd (kryptering)
TLS används i all kommunikation med stödtjänsterna, Loggtjänsten samt HSA.
Riktighet
Riktigheten i systemets verksamhetsloggar och persistent data (databas) skyddas med hjälp av driftsorganisationens egen infrastruktur och är inte en del av systemet.
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.
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.
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å.
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.
Logg
LogId
Av loggtjänsten skapat UUID.
SystemId
HSA-id för det SITHS-certifikat som tjänsten använder vid kontakt med Loggtjänsten.
Tjänsteplattform, lokalt såväl som nationellt, är en möjlig förmedlare av tjänsterna. Tillför möjlighet till internetanslutning samt förenkling av integrationspunkterna och vägval för att hitta viss producerande tjänst
För information om datatyperna se Tjänstekontraktsbeskrivning för Loggtjänsten [T4].
Informationens ursprung
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.
Information som skapas
Patientdata - En logg innehåller patientdata i form av information om vilka vårdgivare och vårdenheter patienten har besökt.
Driftaspekter
Lösningsöversikt
Logisk anslutningsarkitektur
Image RemovedImage Added
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.
Programvaror
Java SE 17
MongoDB 5.0.13
Redis 6.2.7
Detaljerad information
Loggtjänstens driftshandbok innehåller detaljerad information om driften av tjänsten. Kräver behörighet och inloggning.
Produktionssättning och överlämning till förvaltning