SAD - Loggtjänsten

Owned by Peter Leader
Last updated: mars 25, 2024
17 min read

Innehåll





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.


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.

Referenser

Kategori

Referens

Dokument inom kategori

Kategori

Referens

Dokument inom kategori

Plattformsbeskrivningar

P1

HSA-Katalogen - https://www.inera.se/tjanster/alla-tjanster-a-o/hsa-katalogtjanst/

HSA används i lösningen för att tillhanda kvalitetssäkrade uppgifter om personer och funktioner/system.

Grundläggande rättighetshetstilldelning utgår från HSA.

P2

Loggtjänsten - https://inera.atlassian.net/wiki/spaces/SAK/pages/3397195490/Logg

Används i lösningen för att logga uttag av loggrapporter för senare uppföljning enligt PDL.

P3

Personuppgiftstjänsten - https://inera.atlassian.net/wiki/spaces/PU/overview

Används i lösningen för att slå upp namn på patienter som loggrapporter ska beställas för när dessa görs med avseende på patient.

P4

Tjänsteplattform - https://inera.atlassian.net/wiki/spaces/NTJPP/overview

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

Tjänstekontraktsbeskrivningar

T1

HSA-Katalogen - Inera SE165565594230-1000

infrastructure:directory:organization

GetHealthCareUnitList:2
GetEmployeeIncludingProtectedPerson:3

T2

Loggtjänsten - Inera SE165565594230-1000

informationsecurity:auditing:log
StoreLog:2

T3

Personuppgiftstjänsten - Inera SE165565594230-1000

strategicresourcemanagement:persons:person
GetPersonsForProfile:3

T4

Samtyckestjänsten - Inera SE165565594230-1000

informationsecurity:authorization:consent

Bilagor

B1 (obligatorisk)

Arkitekturella beslut -  https://rivta.se/tkview/#/domain/informationsecurity:auditing:log

B2

Publik information - https://inera.atlassian.net/wiki/spaces/SAK/pages/3397195490/Logg

B3

Driftsdokumentation - https://inera.atlassian.net/l/c/vJ1F0Asj

B4

Bitbucket - https://bitbucket.org/rivta-domains/riv.informationsecurity.auditing.log

B5

Informationsspecifikation för loggtjänst

B6

Svarskoder och systemloggar för WS-kontrakt i Loggtjänsten

Styrande dokument

Ref

Dokument ID

Dokument/länk

Ref

Dokument ID

Dokument/länk

S1

T-boken

http://rivta.se/documents/ARK_0019/

S2

RIV Tekniska Anvisningar

http://rivta.se/documents

S3

Gemensam tjänsteplattform

https://inera.atlassian.net/wiki/spaces/NTJPP/overview

Stödjande dokument

Ref

Dokument ID

Dokument/länk

Ref

Dokument ID

Dokument/länk

R1

RIVTA

http://rivta.se

R2

Tjänsteplattform

https://www.inera.se/digitalisering/infrastruktur/nationella-tjansteplattformen-och-tjanstekontrakt/

Versionshistorik

Version

Datum

Kommentar

Utförare

Version

Datum

Kommentar

Utförare

0.1

Mar 30, 2022 

Första version för 3.0 med nya mallen från ARK_0013 på RIVTA.SE (Confluence-mall finns hos CGI)

 

1.0

Mar 25, 2024

Dokumentation uppdaterad och överflyttad från 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

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

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

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

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

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

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

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

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

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  

Icke-funktionella krav

Icke-funktionella krav från verksamheten

 Svarstider

Specificeras i Tjänstekontraktsbeskrivningen. 

Tillgänglighet

Specificeras i Tjänstekontraktsbeskrivningen. 

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.

 

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

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.

SystemName

Loggrapporttjänsten

ActivityType

Läsa

StartDate

Datum och tid för registreringen.

Purpose

Medarbetaruppdragets syfte (http://sambi.se/attributes/1/commissionPurpose)

UserId

HSA-id för Spärradministratören (http://sambi.se/attributes/1/employeeHsaId)

Name

Namn på Spärradministratören (http://sambi.se/attributes/1/givenName +  http://sambi.se/attributes/1/surname)

Title

Titel på användaren (http://sambi.se/attributes/1/healthcareProfessionalLicense)

Assignment

Medarbetaruppdragets namn (http://sambi.se/attributes/1/commissionName)

CareProviderId

Medarbetaruppdragets vårdgivare HSA-id (http://sambi.se/attributes/1/healthCareProviderHsaId)

CareProviderName

Medarbetaruppdragets vårdgivare Namn (http://sambi.se/attributes/1/healthCareProviderName)

CareUnitId

Medarbetaruppdragets vårdenhet HSA-id (http://sambi.se/attributes/1/healthCareUnitHsaId)

CareUnitName

Medarbetaruppdragets vårdenhet Namn (http://sambi.se/attributes/1/healthCareUnitName)

Resurser (en per loggförändring ifall flera påverkas samtidigt)

ResourceType

Loggrapport

PatientId.Root

PNR: 1.2.752.129.2.1.3.1 SNR: 1.2.752.129.2.1.3.3 NRID: 1.2.752.74.9.1

PatientId.Extension

Patientens Personnummer, Samordningsnummer eller Nationell reservidentitet.

CareProviderId

Vårdgivarens HSA-id där samtycket gäller.

CareProviderName

Vårdgivarens Namn där samtycket gäller.

CareUnitId

Vårdenhetens HSA-id där samtycket gäller.

CareUnitName

Vårdenhetens Namn där samtycket gäller.

Nyttjade tjänstekontrakt

loggtjänsten : informationsecurity:auditing:log

Konsument/Producent

Tjänstekontrakt

Version

Dokument

Producent

StoreLog

2

https://rivta.se/tkview/#/domain/informationsecurity:auditing:log

 

 

 

 

  • GetLogsByOrder och GetFilesForOrderId är nya kontrakt som realiseras i "

Nya loggtjänsten 3.0" 

Producent

GetLogs

2

Producent

GetInfoLogs

2

Producent

GetAccessLogsForPatient

2

Producent

GetLogsByOrder

1*

Producent

GetFilesForOrderId

1*

Personuppgiftstjänsten - strategicresourcemanagement:persons:person

Konsument

GetPersonsForProfile

3

https://rivta.se/tkview/#/domain/strategicresourcemanagement:persons:person

Loggtjänsten - informationsecurity:auditing:log

Konsument

StoreLog

2

https://rivta.se/tkview/#/domain/informationsecurity:auditing:log

HSA Katalogtjänst - infrastructure:directory:organization / infrastructure:directory:employee

Konsument

GetHealthCareUnitList

2

https://rivta.se/tkview/#/domain/infrastructure:directory:organization

Konsument

GetEmployeeIncludingProtectedPerson

3

https://rivta.se/tkview/#/domain/infrastructure:directory:employee

 

Nyttjade plattformsfunktioner

 

Ref

Syfte

Dokument

Ref

Syfte

Dokument

P1

HSA-Katalogen

HSA används i lösningen för att tillhanda kvalitetssäkrade uppgifter om personer och funktioner/system.

https://www.inera.se/tjanster/alla-tjanster-a-o/hsa-katalogtjanst/

 

P2

Loggtjänsten

Används i lösningen för att logga skapande av loggrapporter för senare uppföljning enligt PDL.

https://inera.atlassian.net/wiki/spaces/SAK/pages/3397195490/Logg

P3

Personuppgiftstjänsten

Används i lösningen för att slå upp namn på patienter som loggrapporter beställs för.

https://inera.atlassian.net/wiki/spaces/PU/overview?homepageId=3353215021

P4

Nationell tjänsteplattform

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

Tjänsteplattform - https://inera.atlassian.net/wiki/spaces/NTJPP/overview

 

Informationshantering

Domäninformationsmodell

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

 

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

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