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

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

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