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

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

R1

RIVTA

http://rivta.se

R2

Tjänsteplattform

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

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

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

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.

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.

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.

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.

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