Dokumentinformation

Syfte

Syftet med detta dokument är att beskriva systemarkitektur och teknisk realisering för Ineras spärrlösning. Spärrlösningen beskrivs utifrån hur den samverkar med andra system.

Målgrupp

De huvudsakliga målgrupperna för detta dokument är beställare, arkitekturledningen, systemarkitekter och utvecklingsteam.

Översiktlig beskrivning

Inledning

Stödtjänsten Spärr syftar till att stödja registrering och hantering av patientens önskan att spärra sina uppgifter i vårdens system enligt Patientdatalagen och Socialstyrelsens föreskrifter (HSLF-FS 2016:40 med handbok).
Tjänsten medger att spärren registreras och sedan tillgängliggörs för alla de vårdsystem som behöver utföra kontroll mot spärr. Spärren applicerar på informationshanteringen både inom det inre sekretessområdet (inom vårdgivarens verksamhet) och vid sammanhållen journalföring.
Såväl lokala/regionala vårdsystem såväl som nationella e-hälsotjänster kan nyttja Spärrtjänst. 
Utformningen av Spärrtjänst tas sin grund i uppdraget Patientdatalagen i Praktiken (PDLiP), som syftat till att skapa förutsättningar för en nationell samsyn av tolkning och tillämpning av Patientdatalagen.

Sammanfattning

Arkitekturen för Spärrtjänst medger att vårdgivare, kommuner och regioner kan hantera sina "egna" spärrar i en spärradministrationstjänst där en kopia på spärren replikeras till den nationell tjänsten så att de blir tillgängliga för nationella tjänster som t.ex Nationell Patientöversikt.
Spärrar hanteras därför på två nivåer:

• Spärradministration en tjänst för spärradministration där spärren hanteras (registreras, hävs etc). 
• Nationell spärrtjänst samlar kopior med grundläggande data om alla spärrar genom replikering från vårdgivarnas spärrtjänster.

Registrerad spärrinformation utbyts genom RIV tjänstekontrakt. Bilden nedan illustrerar hur vårdsystem kan integrera sig med spärrtjänsten samt hur spärrtjänsterna samverkar med varandra. 

Figur: Stödtjänster för hantering av spärr av patientuppgifter enligt PDL. 

Vårdgivarens spärrtjänst 
Vårdgivarens spärrtjänst håller originalen för de spärrar som vårdgivaren registrerar för patientens räkning. 
Spärrar administreras antingen direkt via ett webbaserat användargränssnitt eller via integration mot webbtjänstegränssnittet.
Vårdgivarens spärrtjänst hanterar ett utökat format för spärrar som  inkluderar information om vem som registrerat spärren och när spärren registrerades.
Vårdgivarens spärrtjänst kan implementeras på olika sätt förutsatt att den uppfyller de standardiserade tjänstekontrakt som krävs för att samverkan ska fungera med andra system.
Lokal spärrtjänst levereras från och med denna version inte som nedladdningsbar produkt. Lokala Säkerhetstjänster 2.17 är den sista version som kan laddas ner men Inera rekommenderar att vårdgivaren använder Ineras tjänst för Spärradministration.
Ineras tjänst för Spärradministration driftas av Inera för anslutna vårdgivare. Flera vårdgivare/huvudmän kan därmed dela på en gemensam installation. 

Nationell spärrtjänst
Den nationella spärrtjänsten är en centraliserad tjänst som har till uppgift att tillhandahålla ett samlat spärrunderlag för de e-hälsotjänster som opererar på det nationella planet som t ex Nationell Patientöversikt där patientinformation samlas från många olika vårdgivare över regiongränser. Dessa tjänster behöver göra kontroll mot patientens samlade spärrar oavsett var dessa har registrerats.
Det sker ingen direkt administration av spärrar i den nationella spärrtjänsten då enbart kopior av spärrarna tas emot från den lokala spärradministrationstjänsten. Den nationella spärrtjänsten lagrar endast den grundläggande kärna av spärrinformation som behövs för att kunna utföra spärrkontroll i vårdsystemen. 

Vårdsystem
En spärr "nyttjas" genom webbtjänsteintegration från ett vårdsystem som utför spärrkontroll och kontrollerar om angiven vårdinformationen är spärrad eller inte. Vårdsystemet kan välja att hämta ett spärrunderlag för intern kontroll eller att fråga tjänsten om spärr föreligger för viss informationsåtkomst. 

Realiserade tjänster
Nedan bild visar översiktligt hur framtagna tjänster är realiserade. Se vidare under Teknisk lösning för mer information. 

Figur: Översiktlig intern realisering spärrtjänst.

Tillgänglighet på tjänstekontrakt

Spärrtjänsten realiserar version 4 av de tjänstekontrakt som specificeras i dess tjänstekontraktsbeskrivningar inom RIV-TA domänerna (se [T4]). Nedan anges vilka kontrakt som är tillgängliga inom Vårdgivarens (lokalt) respektive Nationell spärrtjänst.

Version 2

Inte tillgänglig i denna version.

Version 3

Inte tillgänglig i denna version.

Version 4

* Ej installerade i NTjP

Målbild och principer

Verksamhetsmässiga mål

• Vårdgivare ska kunna nyttja stödtjänst för Spärr för att på ett rationellt och sammanhållet sätt hantera kravet på patientens spärr i sina vårdinformationssystem.
• En registrerad spärr ska kunna tillgängliggöras för alla vårdsystem som behöver ta hänsyn till spärren. Dubbelregistrering av patientens spärr ska undvikas.
• Spärrar ska kunna administreras antingen direkt via ett webbaserat användargränssnitt eller via integration mot webbtjänstegränssnitt.
• Det ska finnas historik att tillgå för att se vad som lagts in för patienten bakåt i tiden.
• Inloggade användare ska vara starkt autentiserade med hjälp av SITHS-kort.
• Alla användarrelaterade aktiviteter avseende spärrar (sätta, häva, ta bort, tillfälligt häva, lista spärrar etc) skall loggas.
• Det ska vara möjligt att ta ut rapporter över loggen och/eller exportera loggdata ur perspektiven:
  • spärrhantering för en enskild patient, respektive
  • en enskild medarbetares spärrhantering
• Patient skall kunna anges med identitet av typ Personnummer (PNR), Samordningsnummer (SNR), eller Nationellt Reservidentitet (NRID).
• Det skall vara möjligt att kopiera spärrar mellan vårdgivarens egna vårdenheter vid t ex omorganisation.
• Det skall vara möjligt att kopiera spärrar mellan en patients olika identiteter ifall patienten har flera som i fallet där en reservidentitet kopplas till ett personnummer.

Arkitekturella mål

Övergripande mål

• Följsamhet mot Nationella IT-strategin.
• Följsamhet mot RIV TA.
• Samverkan med externa system ska så långt som möjligt utformas i enlighet med gällande versioner av tekniska anvisningar så som T-bokens referensarkitektur, tekniska målbilder för nationella tjänster och RIV tekniska anvisningar.
• Återanvändning av nationellt framtagen och driftsatt infrastruktur maximeras.

Specifika mål

• RIVTA2.1 Säkerhetsmodell ska gälla för tjänstegränssnitten.
• Vårdsystem ska kunna välja att hämta ett spärrunderlag för intern kontroll eller att fråga tjänsten om spärr föreligger för viss informationsåtkomst.

Planerade avsteg

• Inga planer finns att leverera Spärradministrationstjänsten för lokal installation.

Prioriterade områden

Avgränsningar

I projektet har inte ingått att realisera tjänstekontrakt för patientingång. Syftet med patientingången är att patienten själv på sikt ska erbjudas möjlighet att via mina vårdkontakter se de spärrar som lagts in för dennes räkning. 

Denna version av Spärrtjänsten planeras inte att göras tillgänglig för lokal installation då det av Inera rekommenderade sättet att administrera spärrar numer är att använda molntjänsten. 

Teknisk lösning

Översikt

Nedan bild visar övergripande hur tjänsterna nationell och lokal spärrtjänst är realiserade: 


Figur: Intern vy av realiserad tjänst .

De båda tjänsterna har implementerats med en gemensam Java-plattform. I plattformen ingår grundläggande teknik såsom autentisering, webbtjänstestack, loggning, databashantering. På plattformen läggs sedan den lokala eller den nationella verksamhetsmodulen och dessa paketeras till två olika system. Följande skiktning gäller för de båda systemen: 

• Persistenslagret: Hanterar persistens mot databasen.
• Tjänstelagret: Hanterar autentisering, åtkomstkontroll, validering, loggning samt transaktionshantering.
• Webbtjänstelagret: Transformerar XML-data till tjänsteobjekt och vice versa.
• GUI-lagret: Hanterar autentisering och webbsidor för slutanvändare.

Beroenden

Bilden nedan visar översiktligt beroenden till andra system och tjänster som Spärradministration har. Se [T1-6]

Figur: Beroenden i Spärradministration

Arkitekturellt signifikanta delar av lösningen

Autentisering via OIDC och SITHS certifikat

Användargränssnittet för vårdgivarens spärrtjänst använder OIDC och SITHS certifikat som autentiseringsteknik. I användarens biljett lagras certifikatsuppgifter och egenskaper från HSA-katalogen som användaren fått vid autentiseringen. Dessa uppgifter följer användaren under dennes HTTP-session. 
Då slutanvändare skall autentisera sig mot användargränssnittet samt då ett vårdsystem skall anropa webbtjänstegränssnittet måste dessa klienter presentera sitt certifikat. Certifikaten som används är SITHS, för vårdsystem ett mjukt funktionscertifikat och för användare ett SITHS-kort.

Auktorisation

För åtkomst från vårdsystem via tjänstekontrakt styrs åtkomst genom att man i tjänsten konfigurerar vilka certifikat som ges åtkomst till systemet och på vilka vårdgivare dessa tillåts operera. Auktorisation kan även hanteras i Tjänsteplattform om tjänster konsumeras via sådan.
En spärr registreras antingen på vårdenhetsnivå (inre) eller vårdgivarenivå (yttre). I både fallen så lagras alltid ett vårdgivar-id, t.ex. "ABC". Gällande åtkomst i så gäller detta på vårdgivarnivå enligt följande:

• En spärradministratör med uppdrag på vårdgivar-id "ABC" får endast möjlig åtkomst (titta/editera/radera, etc...) till spärrar vars vårdgivar-id är "ABC"
• Ett anslutet journalsystem (konfigurerat med access till vårdgivar-id "XYZ") får endast möjlig åtkomst (titta/editera/radera, etc...) till spärrar vars vårdgivar-id är "XYZ". Dock kommer samtliga spärrar i systemet att få genomslag vid en spärrkontroll.
• Ett anslutet journalsystem (konfigurerat med access till vårdgivar-id "XYZ") får endast registrera spärrar/tillfälliga hävningar på vårdgivare vars vårdgivar-id är "XYZ".

HSA Webbtjänst (HSA-RIV)

Spärradministrationstjänstens gränssnitt kräver att användare finns upplagda i den HSA-katalog som tjänsten kopplas till. Användarens HSA-id från dennes SITHS-kort måste vara åtkomligt i HSA-katalogen och finnas upplagd med rätt egenskaper och medarbetaruppdrag för att användaren skall ges åtkomst till användargränssnittet.

Webbtjänster

Integrerande vårdsystem kan anropa spärrtjänsterna med webbtjänsteteknik. Denna teknik följer RIV 2.0-standarden, se referens S6.

Replikering till nationell tjänst

En implementation av en lokal Spärrtjänst ska ansluta mot det nationella tjänstekontraktet, så att bilden av patientens spärrar blir komplett i nationella tjänsten.
Vårdgivarens spärrtjänst (lokal eller i delad molntjänst) replikerar enkelriktat mot den nationella tjänsten för att samla spärrdata nationellt. Den nationella spärrtjänstens enda uppgift är att lagra kopior av alla de lokala instansernas data. Så fort en förändring av spärrdata sker i vårdgivarens tjänst så skickas detta upp till den nationella.

Unikt nationellt spärr-id

Spärr-id måste vara nationellt unikt då det samlade spärrunderlaget behöver hanteras i nationell tjänst. För att garantera detta behöver ett format väljas som garanterar att id:et blir unikt vid sammanställning i den nationella spärrtjänsten. För detta rekommenderas att välja GUID-format. 

Logisk arkitektur

Figur: Logisk systemöversikt och gränsytor i samverkan.

Användargränssnitt

Användargränssnitt för hälso- och sjukvårdspersonal

Användargränssnittet är framtaget med ramverket Angular och är kompatibelt med alla de större webbläsarna på marknaden idag.

Figur: Registrering av spärr.

Kravbild för tillgänglighetskrav

Följande webbläsare har testats:

• Chrome
• Internet Explorer 11
• Microsoft Edge som baseras på Chromium

SITHS-programvara som testats är Net iD 6.8.x på Windows 10.

Framtida versioner av Net iD, webbläsare och operativsystem måste kvalitetssäkras löpande. 

Användningsfall

Alla spärrtjänstens användningsfall är realiserade som webbtjänster. Dessa är också tillgängliga i användargränssnittet med undantag för "Kontrollera spärrar" (CheckBlocks) som är en ren integrationsfunktion.

Användningsfall - Översikt

1. Lista spärrar
2. Lista spärrar för patient
3. Registrera spärr
4. Avregistrera spärr
5. Registrera tillfällig hävning
6. Avregistrera tillfällig hävning
7. Kontrollera spärrar
8. Lista utökade spärrar för patient
9. Registrera utökad spärr
10. Häv spärr permanent
11. Häv spärr tillfälligt
12. Återkalla tillfällig hävning
13. Ta bort spärr

Figur: Schematisk (förenklad) användningsfallsöversikt.

Aktörsinformation

Vårdsystem

I det fall tjänstegränssnitten nyttjas i den lokala spärrtjänsten så kan vårdsystem hantera spärrar. Sett ur spärrtjänstens perspektiv så är aktören inte slutanvändaren av vårdsystemet, utan vårdsystemet självt. Vårdsystemet agerar å användarens vägnar. Vårdsystemet har ett unikt HSA-id.

HoS

I det fall användargränssnittet nyttjas i den lokala spärrtjänsten så är aktören en Hälso- och Sjukvårdsperson (HoS) som hanterar spärrar. I första hand en spärradministratör. Vårdsystemet har ett unikt HSA-id samt övriga uppgifter såsom vårdgivartillhörighet.

Klockan

Den lokala spärrtjänstens klocka startar ett tätt återkommande jobb för att synkronisera/hämta nationellt spärrdata från den nationella spärrtjänsten. Detta sker i bakgrunden utan någon mänsklig interaktion.  

Logisk realisering

Begreppet "utökad" förekommer i denna SAD för att förtydliga att objektet avser en lokal, utökad dataform. Det nationella formatet för spärrar är mindre och innehåller endast den datamängd som verkligen krävs för att utföra spärrkontroll.

Flöde AF - Lista spärrar

Returnerar en lista med grundläggande spärrar för alla patienter som har minst en aktiv spärr samt därtill hörande aktiva tillfälliga hävningar. Syftet är dels att kunna åstadkomma import av spärrar i de vårdsystem som saknar möjlighet till on-line slagning, dels att anropande vårdsystem enkelt ska kunna undanta patienter utan spärr från spärrkontroll (dvs. förenkla i normalfallet).

Flöde AF - Lista spärrar för patient

Operationen har samma funktion som Lista spärrar för alla, men är begränsat till en specifik patient. Syftet är att användas on-line av vårdsystem som ska kontrollera spärrar för aktuell patient i samband med att vårdinformation ska visas.

Flöde AF – Registrera spärr

Registrerar en kopia på ett grundläggande spärrobjekt.

Flöde AF – Avregistrera spärr

Operationen tar bort en tidigare registrerad kopia på ett grundläggande spärrobjekt. Används i alla former där en spärr inte längre skall gälla.

Flöde AF – Registrera tillfällig hävning

Operationen registrerar en tillfällig hävning av en spärr. Till skillnad från permanent hävning, som gäller hela spärren, är en tillfällig hävning begränsad till att gälla en viss HoS-person eller en viss vårdenhet. Av det skälet kan flera tillfälliga hävningar existera samtidigt för samma spärr.

Flöde AF – Avregistrera tillfällig hävning

Operationen tar bort en tidigare registrerad tillfällig hävning. Används då den tillfälliga hävningen inte längre är tillämplig vid kontroll av åtkomst till vårdinformation.

Flöde AF – Kontrollera spärrar

Utför spärrkontroll genom att jämföra metadata om vårdinformation med patientens spärrar. Som svar erhålles vilken vårdinformation som är spärrad utifrån frågeunderlaget. Vårdsystemet kan därmed undanta denna från att visas för användaren.

Flöde AF – Lista utökade spärrar för patient

Returnerar alla utökade spärrobjekt och utökade tillfälliga hävningar för en viss patient. Notera att denna operation, till skillnad från Lista spärrar för patient, syftar till att administrera spärrar, inte kontrollera tillgång till vårdinformation. Urvalet är därför inte begränsat till enbart aktuella spärrar utan även ogiltiga.

Flöde AF – Registrera utökad spärr

Lagrar ett nytt utökat spärrobjekt.

Flöde AF – Häv spärr permanent

Häver en sedan tidigare registrerad spärr och gör spärren permanent ogiltig.

Flöde AF – Häv spärr tillfälligt

Operationen registrerar en tillfällig hävning av en spärr. Till skillnad från permanent hävning, som gäller hela spärren, är en tillfällig hävning begränsad till att gälla en viss HoS-person eller en viss vårdenhet. Av det skälet kan flera tillfälliga hävningar existera samtidigt för samma spärr.

Flöde AF – Återkalla tillfällig hävning

Operationen återkallar/makulerar en sedan tidigare registrerad tillfällig hävning av spärr. Spärren blir således aktiv igen för den/de aktör(er) som den tillfälliga hävningen avsåg.

Flöde AF – Ta bort spärr

Tar bort (makulerar) en sedan tidigare registrerad spärr. Spärren raderas inte fysiskt utan markeras som makulerad. Spärrar tas endast bort till följd av felregistrering. Detta skall inte förväxlas med permanent hävning.

Flöde AF – Vårdsystem

Figuren nedan visar ett exempel på systemintegration där "Vårdsystem X" inhämtar spärrar och kontrollerar huruvida vårdinformation är spärrad eller inte. Figuren visar också på kopplingen mellan lokal och nationell spärrtjänst. 
 
Figur: Sekvensdiagram – Lista spärrar och utföra spärrkontroll.

Uppfyllande av icke-funktionella krav

Icke-funktionella krav från verksamheten

Svarstider

I implementerad spärrtjänst håller funktioner avsedda för slutanvändare, såsom Registrera spärr, Lista spärrar för patient generellt sätt svarstider under en sekund.
Synkroniseringsmetoder såsom "Lista alla spärrar" håller svarstider på mellan en och 30 sekunder beroende på antalet spärrar.

Tillgänglighet

Kontroll av spärrar är en kritisk funktion i vårdsystem vilket gör att tillgänglighet på spärrdata är av stor vikt. 
Principer för hög tillgänglighet:
Vårdgivarens spärrtjänst skall inte bli otillgänglig då den nationella spärrtjänsten ej kan nås. Det ska alltså fortfarande gå att hämta och registrera spärrar på vårdgivarens nivå. Replikering som inte kan utföras köas upp tills den nationella noden åter är tillgänglig. 
Detsamma rekommenderas för anslutna vårdsystem, som ej bör bli otillgängliga då spärrtjänst inte kan nås. För att öka tillgängligheten på dessa vårdsystem så kan dessa, om möjligt, lagra de senast hämtade spärruppgifterna från spärrtjänst. Eftersom verksamhetens process för att registrera en spärr som begärts av en patient kan ta timmar, snarare än minuter, så kan normalt också vårdsystemen fungera utan senaste spärrstatus vid tillfällen då spärrtjänsten är otillgänglig. 
Specifika krav överenskommes i avtal om drift av tjänst. Eftersom lokal spärrtjänst är en produkt så bestämmer brukaren delvis själv vilken infrastruktur som skall stödja hög tillgänglighet såsom redundans, backup, m.m.

Volymskrav

Hänsyn har tagits till den mängd användare och spärrar som förväntas existera på nationell nivå. Arkitekturen har utformats så att spärrtjänsten hanterar storleksordningen "tusentals" spärrar och förväntar sig inte "miljontals".

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

Test

Specifika krav överenskommes i avtal om drift av tjänst.

Konfigurationsstyrning

Specifika krav överenskommes i avtal om drift av tjänst.

SLA-övervakning

Specifika krav överenskommes i avtal om drift av tjänst. 

Informationsmodell

Allmänt

Använda definitioner bygger på [S8] RIV-specifikation PDLiP (Patientdatalagen i Praktiken) med vissa tillägg. 
Övergripande modell 

Figur 8: Till varje spärr kan kopplas 0 eller fler tillfälliga hävningar. 

För mer information om datatyperna, se tjänstekontrakt som informationsspecifikation för spärrtjänsten [T4].

Driftaspekter

Till skillnad från tidigare version av spärrtjänsten som ingick i installationen av Säkerhetstjänster så paketeras inte denna version för traditionell installation i Linux eller Windows. 

Inera driftar numera sina applikationer i containerbaserade miljöer som OpenShift. Leveransen av de olika delarna av Ineras spärrlösning byggs nu därför endast till jar-filer som sedan byggs in i image-filer för deploy i specifik OpenShift-miljö.

Lösningsöversikt

Nedanstående figur visar det infrastruktursförslag som ges vid drift av lokal och/eller nationell spärrtjänst. I detta fall visar bilden en lokal spärrtjänst på Sjunet som anslutits till nationell spärrtjänst.

Fysisk miljö

Den fysiska miljön för spärrtjänsten beror på huvudmannens val av systemkonfiguration. Se föregående översiktsbild.

Programvaror

Spärrtjänsten kräver följande programvara:

• Java OpenJDK 11 – 64 bit
• MySQL Server 8.0 (eller högre) – 64 bit
• Redis 

Detaljerad information

Ej specificerat

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

Ej specificerat
 

Följsamhet mot T-bokens styrande principer

Referenser