1. Dokumentinformation

1.1. Syfte

Syftet med detta dokument är att beskriva arkitekturen för på Samtyckstjänst. Den övergripande arkitekturen, och tillhörande nationella tjänstekontrakt, applicerar på alla implementationer av stödtjänst för samtycke som ska kunna samverka i en federation. Vidare beskrivs lösningsarkitekturen för de implementationer som tas fram under ledning av Inera AB på uppdrag av "Inera - landsting och regioner i samverkan för e-hälsa".

1.2. Målgrupp

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

1.3. Revisionsinformation

2. Översiktlig beskrivning

2.1. Sammanfattning

Säkerhetstjänsterna Samtycke syftar till att stödja processen att hantera relationen patient till vårdpersonal samt samtycke till direktåtkomst inom sammanhållen journalföring enligt Patientdatalagen (PDL). Modellen för detta baserar sig på PDLiP-arbetet (Patientdatalagen i Praktiken) som CeHis initierat och som resulterat i RIV-specifikation PDLiP [S8].Tjänster med motsvarande funktionalitet är idag i drift som stöd till Nationell Patientöversikt för att där hantera PDLs krav på samtycke.

Figur 1: Säkerhetstjänster översikt. 

Den vidareutvecklingen av tjänsterna som här kravställs syftar till dels till att anpassa tjänsterna till den nationella referensarkitekturen (T-boken) och dels att skapa en arkitektur där tjänsterna kan konsumeras på ett enklare och mer flexibelt sätt både på det lokala och nationella planet.
Mer specifikt innebär vidareutvecklingen att

• tjänstegränssnitt (tjänstekontrakt) enligt RIV TA 2.1 [R2] tas fram [T6]
• tjänsterna anpassas till säkerhetsmodellen för RIV TA, vilket bidrar till enklare anslutning och ökad teknisk interoperabilitet
• tjänster på lokalt och nationellt plan kan samverka genom tydliga kontrakt
• vårdsystem som ansluts binds till tjänstekontrakt – inte en specifik lösning. Det gör att huvudmän som använder samma vårdsystemsleverantör inte är bundna till samma val av stödtjänst
• tjänsteplattformar kan nyttjas för att konsolidera tjänsteutbudet och förenkla anslutningar

Se vidare "Arkitekturella mål" för specifika krav på utvecklingen. 
Nedan figur visar principiellt hur stödtjänsterna kan konsumeras från vårdsystem eller andra fristående e-tjänster.

Figur 2: Nyttjande av stödtjänster för hantering av samtycke.

Genom nyttjande av stödtjänster kan samma registrerade samtycke för åtkomst till andra vårdgivares uppgifter återanvändas i flera vårdsystem och e-tjänster, såväl lokala som nationella. Detta för att vårdpersonalen ska slippa multipla registreringar av samma sak. Allt efter regelverket tillåter kan samtycken anges att gälla för viss utsträckning i tid och för den personal det omfattar, t ex samtycke för alla medarbetare på vårdenheten under en vecka.
Vårdsystem får möjlighet att läsa/kontrollera samtyckesuppgifterna i stödtjänsterna, och användare kan göra registreringar, antingen genom dennes ordinarie vårdsystem (typiskt journalsystemet) eller via ett fristående gränssnitt, t ex i en portal eller i samband med att nationell e-tjänst nyttjas.

3. Målbild och principer

3.1. Verksamhetsmässig målbild

Följande verksamhetskopplade mål och krav finns för tjänsterna:

• Processer som hanterar sammanhållen journalföring där vårdinformationen finns i en eller flera system/e-tjänster, lokalt eller nationellt, ska kunna använda en konsoliderad hantering av samtycke för direktåtkomst enligt PDL.
• Tjänsten ska även stödja begreppet nödöppning att använda när inte samtycke är möjligt att få från patienten och det råder fara för patientens liv och hälsa.
• Hälso- och sjukvårdpersonalen ska få stöd att på ett enkelt sätt registrera patientens samtycke, dess varaktighet och för vem/vilka registreringen gäller.
• Samtycken ska kunna få genomslag i anslutna e-tjänster, såväl lokala som nationella, t ex både i det egna vårdsystemet och i nationell patientöversikt, så att dubbelregistreringar undvikes.
• Det ska finnas historik att tillgå för att se vad som lagts in för patienten bakåt i tiden.
• Inloggad personal ska vara starkt autentiserade, med SITHS eID eller motsvarande godkänd lösning. Notera att detta krav gäller inloggning i de applikationer som interagerar med de bakomliggande tjänsterna.
• All hantering ska loggas och loggen ska kunna tillgängliggöras vid den uppföljning av personalens aktiviteter (via loggar) som verksamheten är lagstadgade att utföra. De verktyg som används för övrig liknande uppföljning för åtkomst till nationella e-tjänster ska kunna användas. Se vidare under 11.11 Spårbarhet.
• Patient skall kunna anges med olika format på personidentitet såsom: Personnummer (PNR), Samordningsnummer (SNR), Nationell Reservidentitet (NRID).

3.2. Arkitekturella mål

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

3.2.2. 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]. Transportsäkerhet ersätter meddelandesäkerhet.
• 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å tjänsteplattform (virtualiseringsplattform), nationellt och/eller lokalt.
• Stöd för en distribuerad arkitektur, där det är möjligt för en region/landsting/kommun att upprätthålla egna instanser av tjänsterna alternativt gemensamma molnbaserade tjänster, och samtidigt kunna samverka nationellt med samtycke i nationella e-tjänster (Ersätter befintlig replikeringsmekanism).

3.2.3. Planerade avsteg

Inga planerade avsteg.

3.3. Prioriterade områden

I denna utveckling är prioriterat att anpassa tjänsterna till den nationella referensarkitekturen. 
Tjänsten Samtycke hanterar idag samtycke till direktåtkomst till sammanhållen journalföring enligt PDL. Utvecklingen ska möjliggöra att andra samtycketjänster (t ex för LF-samtycke hos Apotekens Service AB) parallellt kan existera och fungera tillsammans i arkitekturen. Det möjliggörs genom att använda referensarkitekturen och skapa fristående SOA-tjänster som kan samverka hos konsumerande system.
Andra typer av samtycken ska också kunna implementeras i konceptet, vilket tas höjd för, men i övrigt ligger utanför den vidareutveckling som beskrivs i detta dokument. Vid förfrågningar angående vidareutveckling av Inera Säkerhetstjänster, vänd er till Säkerhetstjänsters förvaltning, se http://inera.se/Infrastrukturtjanster/Sakerhetstjanster/ 

4. Teknisk lösning

4.1. Översikt

Bilden nedan visar översiktligt beroenden till andra system och tjänster som Samtyckestjänsten har. Se [T1-4]

Autentiseringstjänsten används för att autentisera användare av systemet.
Åtkomstkontrolltjänsten används för att kontrollera åtkomst för användare av systemet. (Intern)
Loggtjänsten används för att logga aktiviteter och möjliggöra uppföljning av händelser. 
Rapporttjänsten används för att generera rapporter för logguppföljning. Formatet på rapporter som genereras kan vara XML eller PDF.
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. 
Personuppgifter (PU) är ett tjänstekontrakt som nyttjas för att hämta personuppgifter för patienter. Personuppgifter nyttjar b.l.a. Navet som är Statens personadressregister för myndigheter som omfattar alla personer som finns folkbokförda i Sverige, både svenska och utländska medborgare.
Bilden nedan visar övergripande hur samtyckestjänsten är realiserade. 

Figur 4: Intern vy av realiserade tjänster.

Samtyckestjänsten har implementerats med en gemensam Java-plattform. I plattformen ingår grundläggande teknik såsom autentisering, loggning, åtkomstkontroll, webbtjänstestack o databashantering. På plattformen läggs sedan 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
• Certifikat-autentisering på web service anrop sker via Autentiseringen.
• Kontroll av behörighet sker via Åtkomstkontrollen. Behörighetskontroll sker på vårdgivarenivå.
• Loggning sker via gränsnitt för Loggning och utförs vid alla typer av registreringar, makulering, återkallan 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 SAML-autentisering och webbsidor för slutanvändare genom att nyttja Autentisering.

Det är möjligt att konfigurera tjänsterna på olika sätt när ett system ska installeras. Vid installation kan man välja att ha ett system som är helt fristående eller om man vill nyttja en eller flera av säkerhetstjänstens tjänster.
När en lokal installation av Samtyckestjänsten installeras kan man välja att nyttja säkerhetstjänsten. Om man väljer det alternativet installeras proxys mot Autentisering, Åtkomstkontroll, Loggning och Rapport och lokala anropen skickas vidare till säkerhetstjänsten. Loggning sker mot loggkategori 'bifverksamhetslogg' och befintliga logganalyser i Logganalystjänsten används för att generera rapport för logguppföljning. 
Det är även möjligt att bara konfigurera någon av dessa att gå mot säkerhetstjänsterna. Loggtjänst och Rapporttjänst måste däremot konfigureras lika. 
När en lokal installation av Samtyckestjänst installeras och man inte vill ha beroenden till säkerhetstjänsten installeras lokala implementationer av Autentisering, Åtkomstkontroll, Loggning och Rapporttjänsten. 
Säkerhetstjänsten har en lokal installation av Samtyckestjänsten installerad. Det är fullt möjligt att nyttja dessa av andra system som av någon anledning ej vill installera och använda egen lokal Samtyckes. 

Arkitekturen för tjänsterna och dess externa gränsytor byggs för att passa in i Ineras nationella referensarkitektur för interoperabla lösningar för hälso- och sjukvården. Referensarkitekturen är inriktad på en tjänsteorienterad arkitektur där funktionalitet utförs av en SOA-tjänst som antingen är nationell eller lokal och som i regel rör information som ägs av en vårdgivare. 
RIV Tekniska Anvisningar 2.1 används som standard för hur SOA-gränssnitten ("tjänstekontrakten") realiseras. 

Figur 5: Principer för samverkande tjänster för hantering av samtycke (i figur exemplifieras med samtycke)

Notera att en viss instans av stödtjänst för samtycke typiskt hanterar flera vårdgivares information. För att visa på principerna ges exempel utifrån två fiktiva vårdgivare A och B. 
Bilden ovan visar en systemöversikt där vårdsystem och användare interagerar med stödtjänster för samtycke. Tjänsterna kan delas upp i huvudtyperna Registrera-tjänster och Läsa-tjänster.
Det är valfritt var användargränssnittet för att registrera samtycket realiseras, i ett separat gränssnitt mot samtyckestjänsten (som i fallet NPÖ) eller i respektive vårdsystem/e-tjänst. Oavsett var sparas samtycket i samtyckestjänsten för aktuell vårdgivare.
Samtyckestjänst kan installeras och nyttjas fristående eller i kombination med andra tjänster. Tjänstekontrakten kan realiseras oberoende av var delsystemen realiseras. Man kan således välja att nyttja en mellan huvudmän delad molntjänst ("hotelltjänst") för funktionen Samtycketjänst, alternativt en "egen" lokal installation.
Nationella e-tjänster, t ex NPÖ, får genom tjänstekontrakten ett gränssnitt till de samtycken som behövs för dess hantering av direktåtkomst inom den sammanhållna journalföringen. 
Viktigt att notera är att lösningen inte inkluderar en replikering av den samlade bilden av alla samtycken i riket till en central nod. Tjänster som behöver samlad bild, t ex Patientens samlade samtycken, blir nationella aggregerande tjänster i integrationslagret som samlar ihop resultat från de samtyckestjänster som ingår.
Befintliga tjänster inom Inera Säkerhetstjänster återanvänds och anpassas till den nya arkitekturen. Sammanfattningsvis görs följande arkitekturmässiga anpassningar för tjänsterna:

• Tjänsterna friläggs så att de blir möjliga att instansiera som fristående tjänster
• Tjänsternas gränssnitt anpassas till RIV TA Basic Profile 2.1.
• Tjänsterna tillgängliggörs genom publicering via nationell Tjänsteplattform
• Applikationsdelar som anropar tjänst för Samtycke styrs om till de nya tjänstekontrakten.

4.2. Signifikanta delar av lösningen

4.2.1. Tjänsteinteraktioner - princip för tekniska gränssnitt

Alla integrationsmönster som ingår i denna arkitekturbeskrivning baseras på nyttjande av löst kopplade tjänstegränssnitt mot tjänsterna (tjänstekontrakt), utan beroende till specifika agenter eller programmeringsbibliotek (SDK:er). 
Det är självklart möjligt att använda och alternativt tillverka ett programmeringsbibliotek för en specifik plattform, men integrationspunkterna (kontrakten) mellan systemen är de bakomliggande tjänstekontrakten.
Nedan figur visar principen för de tjänsteinteraktioner som ingår i tjänstekontrakten. Kontraktet reglerar hela samspelet mellan konsument och producent. 

Figur 6: Tjänsteinteraktion, Typfall "fråga - svar" 

Integrerande vårdsystem anropar tjänsterna med webbtjänsteteknik enligt profilen RIV TA 2.1 [R2]. Det innebär i korthet att

• att tjänstekonsumenten har ett servercertifikat och kan hantera TLS/SSL med klientautentisering för säker kommunikation med tjänsteproducenten.
• att tjänstekonsumenten kan skicka och ta emot XML över HTTPS

4.2.2. Tjänsteplattform

Tjänstekontrakten är så utformade att anropet kan ställas mot en virtuell tjänst på en tjänsteplattform som sedan kan routas till korrekt tjänsteproducent. 
Se vidare [S7] för mer information om tjänsteplattform och dess förvaltning.
Detta är en vital del av lösningen för de nationella tjänstekontrakten; t ex kontraktet för läsning av aktuella samtycken för en viss patient och vårdgivare förutsätter att anropet kan routas till den samtyckestjänst som håller informationen för den vårdgivaren. 

Figur 7: Tjänsteinteraktion, Typfall "fråga - svar". Anrop via tjänsteplattform. 

4.2.3. Autentisering och auktorisation av slutanvändare i webbklienter

I lösningen ingår fristående användargränssnitt i form av webbklienter:

• Webbklient för vårdpersonal att registrera samtycke och nödsituation
• Webbklient för administration av tjänsterna

Den förra kan användas i samverkan med en webbapplikation för att utföra registreringarna (exempel på det är NPÖs lösning). Alternativt implementeras användarfunktionerna, t ex registrera samtycket, inom applikationen självt. Är det en patientingång, t ex MVK, hanteras funktioner och autentisering inom ramen för denna ingång. 
För autentisering av personal som användare enligt ovan används:

• Stark autentisering via eTjänstelegitimation. Lösningen är konfigurerad för SITHS eTjänstekort, men är i övrigt inte bunden till just SITHS som utgivare av kort/certifikat.
• Nationell katalogtjänst för uthämtande av egenskaper kopplade till användaren.
• Stöd för val av aktivt medarbetaruppdrag enligt HSA Befintlig integration med HSA nyttjas i webbapplikation, se [T1] samt arktekturellt beslut i [B1].
• SAML2.0 för utställande av intyg med identitets- och auktorisationsunderlag.

Används hotelltjänsten för samtyckeshanteringen, nyttjas även den nationella noden för autentisering. Installeras en egen lokal instans av webbklient/tjänst, kan alternativt en fristående autentiseringsfunktion användas.

4.2.4. Ramverk för realisering av ingående tjänsteproducenter

Tjänsteproducenterna är internt uppbyggda med hjälp av följande tekniska ramverk:

Java
Java används för att realisera tjänsterna och möjliggöra exekvering på olika miljöer. 

OSGi ramverk
Den Java-plattform som tjänsteproducenterna bygger på är i botten en OSGi-lösning som medger löst kopplade komponenter, så kallade bundlar, som kan uppgraderas individuellt. Det är också möjligt att på ett smidigt sätt växla mellan olika implementationer av samma gränssnitt. Detta skapar en mycket flexibel och pluggbar plattform. OSGi är en komponentmodell med stöd för att hantera olika versioner/implementationer av samma komponent samtidigt samt att dynamiskt kunna byta ut komponenter under drift. 
Ramverket tillhandahåller en standardiserad miljö för applikationer (bundlar) och består av fyra lager.

L0: Execution Environment – Exekverande miljö L1: Modules – Moduler/Komponenter L2: Life Cycle – Livscykel hantering  L3: Service Registry - Tjänsteregister

Figur 8: OSGi uppbyggnad

	L0: Execution environment – Specificerar Java miljön. Java 2 konfigurationer och profiler som J2SE, CDC, CLDC, MIDP o.s.v. är alla möjliga att använda som exekveringsmiljöer.
	L1: Modules – Definierar policies för klass laddning. OSGi ramverket är en kraftfull och strikt modell för class loading som bygger på Javas mekanismer för att ladda klasser men är utbyggt för att bättre hantera moduler/komponenter. I Java finns det normalt bara en classpath som innehåller alla klasser och resurser men med OSGi Modules får varje modul en egen privat classpath och allt som ska exponeras utanför en modul måste specificeras explicit.
	L2: Life Cycle – Hanterar dynamisk installation, start, stopp, uppdatering och avinstallation av bundlar. Life Cycle använder sig av Modules för att utföra klassladdning men tillhandahåller ett API för hantering av moduler under drift.
	L3: Service Registry – Tillhandahåller en dynamisk samarbetsmodell för bundlar. Bundlar kan samarbeta via traditionell klassdelning vilket inte är så kompatibelt med dynamisk installtion och avinstallation av kod, därför tillhandahåller Service Registry en modell för att kunna dela objekt mellan olika bundlar. Ett antal händelser är specificerade för att hantera att tjänster kommer och går, tjänster i detta fall är vanliga Java objekt. Många tjänster motsvarar server funktionalitet t.ex. en HTTP server medan andra kan vara vilket verksamhetsobjekt som helst.

En applikation i OSGi plattformen kallas för en bundle och kan beskrivas som ett vanlig Java ARchive (JAR) med ett utökat Manifest. Manifestet i en bundle specificerar vad den exporterar och vilka beroenden den har för att kunna exekvera i OSGi miljön.
En OSGi bundel innehåller vanliga Java klasser (POJO) som inte behöver vara beroende av OGSi API:t eller känna till att de exekveras som en OSGi bundle. 

Figur 9 Schematisk överblick över en OSGi bundle.

Varje komponent/bundle specificerar vad den tillhandahåller och vad den använder.
Om Servicekontraktet överensstämmer kopplar OSGi miljön ihop den komponent som tillhandahåller tjänsten med den som nyttjar tjänsten. 
Metro
Metro är den webbtjänstestack som används inom tjänsteproducenterna. Den inkluderar bl.a. JAX-WS, WSIT, JAXB och implementation för många av de WS-* standarder som nyttjas av tjänsteproducenterna. Tjänsteproducenterna realisering följer RIV TA 2.1. 

Figur 10 Metro webbtjänstestack

JAX-WS är grundstommen för utveckling av SOAP baserade webbtjänster inom Java och är en standardteknologi i Java.
JAX-WS version 2.1.7 nyttjas av samtycke. 
JAXB binder XML schemat till Java klasser vilket gör det enkelt att hantera XML data. JAXB är en standardteknologi i Java
JAXB version 2.1.11 nyttjas av samtycke. 


Figur 11 JAXB - Bindning av schema till Java klasser

WSIT (Web Services Interoperability Technologies) är en implementation komponent som utökar JAX-WS med implementationer av mekanismer för att kommunicera med andra webbtjänstestackar på ett interoperabelt sätt, i synnerhet för Windows Communication Foundation (WCF). 
WSIT innehåller stöd för meddelande optimering, säker meddelande transport, säkerhet osv. Det finns även stöd för bootstrapping och konfiguration.
WSIT ramverket är en implementation som utökar bygger på JAX-WS och JAXB. Bilden nedan visar vilka underliggande tjänster som är implementerade för varje område. De inringade tjänsterna är de som nyttjas av Samtyckesstänsten.
WSIT version 1.5 nyttjas av samtycke.

Figur 12 WSIT Web Service Features (inringade tjänsterna nyttjas av Samtyckestjänsten)

Tjänstepaketering
Tjänsteproducenterna följer internt samma mönster för paketstruktur för att möjliggöra olika deployment scenarier, för att t ex möjliggöra skalbarhet för att öka prestanda.

Figur 13 Tjänstepaketering

Pakteringen ger även möjligheten att nyttja deltjänster såsom loggning och loggutdrag från andra logg implementationer.

4.2.5. Ramverk för realisering av ingående användargränssnitt/webbklienter

Ingående användargränssnitt nyttjar Google Web Toolkit (GWT) teknik som är kompatibelt med alla de större webbläsarna på marknaden idag..

5. Användargränssnitt

5.1. Användargränssnitt slutanvändare

Flera av säkerhetsfunktionerna sker "bakom scenen" utan att användarens ser något gränssnitt. Några användargränssnitt (webbklienter) finns dock med i lösningen. Lösningen stödjer att efter behov bygga andra GUI mot tjänsten.

5.1.1. Användargränssnitt inloggning

 
Figur 14: Dialog för att ange PIN till SITHS-kortet.

PIN-dialogen genereras av programvara på arbetsstationen (Net iD) i samband med att en webbklient kräver klientautentisering med TLS/SSL (kortinloggning). 

Figur 15: Dialog för val av uppdrag (om flera finns)

Dialogen för uppdragsval för användare kan implementeras på olika sätt. Ovan visas exempel från nationella säkerhetstjänsten. Om användare har flera kopplade uppdrag (även kallat medarbetaruppdrag) i Nationell katalogtjänst (HSA), ska ett av uppdragen aktiveras genom ett val. Egenskaper kopplade till valt uppdrag som nyttjas i lösningen för auktorisation i webbklienter, se kap 4.2.3.

5.1.2. Användargränssnitt samtycke

Applikationen kan implementera eget användargränssnitt för att registrera samtycke, visa status för samtycke etc.
Som alternativ erbjuds ett användargränssnitt som kan samverka med applikationen. 

Figur 16: Dialog (webbsida) för registrering av samtycke och nödsituation. 

5.1.3. Användargränssnitt för administration

För den administration som behövs för samtycken, finns ett särskilt användargränssnitt mot tjänsten. Se För vidare information se användarhandbok för Samtyckestjänst. 

5.2. Utformning av användargränssnitt

Utformning av nya användargränssnitt (t ex samtyckesdialog) samordnas med look-and-feel i övriga användargränssnitt mot Inera Säkerhetstjänster, där befintliga dialoger för registrera samtycke och spärradministration utgör mall.
Användargränssnitt för administratörer innehåller tre huvudområden enligt figuren nedan. 1 är menyn för funktionsval, 2 är toppmenyn med allmän information och 3 är vyn som visar information beroende på funktionsval. 

Figur 17: Utformning av användargränssnitt. 

Användargränssnittet för slutanvändare (extern webbsidan) är utformat efter principerna

• Enkelhet och avskalat men informativt
• Så få knapptryckningar som möjligt

5.3. Systemkrav för ingående användargränssnitt (webbklienter)

Genom användande av Google Web Toolkit (GWT) teknik görs användargränssnitt kompatibla med dagens vanliga webbläsare. 
Som minimum kommer följande webbläsare att verifieras i tester:
Internet Explorer 11
SITHS-programvara som testats är Net iD 6.1.x på Windows 7.
Framtida versioner av programvara för eTjänstekort/eID, webbläsare och operativsystem måste kvalitetssäkras löpande.

6. Användningsfallsöversikt

6.1. Aktörsinformation

Nedan sammanställs de aktörer som behöver agera i de olika användningsfallen.

6.1.1. Aktörstyper

1. Hälso -och sjukvårdspersonal (HoS personal)För att kunna registrera, återkalla, makulera samtycke samt kontrollera om samtycke finns.
2. Administratör (hos verksamheten)För att administrera samtycken för vårdgivaren.
3. Vårdsystem För att göra kontroller online eller offline.
4. Patient För åtkomst till sina samtycken.

6.1.2. Aktörer i integrationsscenarier

Figur 19: Aktörerna Vårdsystem, HoS Personal och Administratör i ett typiskt integrationsscenario 

Figur 20: Aktören Patient via Invånarportal 

Se vidare under 10.1 för mer information om integrationsscenarier. 

6.2. Användningsfall - Översikt

Figur 21: Schematisk användningsfallsöversikt för samtyckestjänsten 

6.3. Signifikanta användningsfall

Följande är en, icke uttömmande, förteckning över användningsfall som driver arkitekturen. 

• Vårdpersonal registrerar
  • samtycke
  • nödöppning
• Administratör, på uppdrag av vårdverksamheten
  • makulerar samtycke resp. nödöppning, vid en felregistrering
  • återkallar samtycke, på patientens begäran (med vårdpersonal som ombud)
• Vårdsystem
  • Läser ut underlag från stödtjänsterna för intern kontroll mot samtycke.
  • Utför kontroll mot samtycke, genom anrop till stödtjänsterna
  • Registrerar samtycke i stödtjänst.
• Vårdpersonal - åtkomst till vårdinformation i flera steg i olika delsystem
  1. Användaren utgår från information denne har kring patienten inom sin egen vårdgivare i eget system.
  2. Användare väljer informationsvy, ev. i annat delsystem. som omfattar uppgifter även från andra vårdgivare (direktåtkomst).
  3. Kontroll sker av samtycke/nödöppning.
  4. Om saknas, visas dialog för registrering, och ny kontroll att kraven är uppfyllda utförs.
  5. Användaren kommer vidare till önskad informationsvy.

7. Tjänstekontrakt

Nedan lista är en översikt av de tjänster som ingår för att stödja hanteringen av samtycke/nödöppningari vårdsystemen. 
Tjänstekontraktet Personuppgifter nyttjas av stödtjänsterna för att hämta personuppgifter för patienter. 
För en mer utförlig information se beskrivningar i [T6] och [T2]. 

Registrera-tjänster, med utökad information

• Registrera, med utökad information
  • samtycke
  • nödöppning
• Återkalla, med utökad information
  • samtycke
  • nödöppning
• Makulera (ta bort), med utökad information [vid felregistrering]
  • samtycke
  • nödöppning

Lista-tjänster, med grundinformation [för att utföra intern kontroll av åtkomst]

• Lista för angiven patient och specificerad vårdgivare
  • samtycke
  • nödöppning
• Lista för alla patienter för specificerad vårdgivare
  • samtycke
  • nödöppning

Kontrollera-tjänster, kräver endast grundinformation

• Kontrollera baserat på fråga med aktörsinformation och patient
  • samtycke
  • nödöppning

Lista-tjänster, med utökad information [för att visa och administrera]

• Lista för angiven patient (för specificerade vårdgivare)
  • samtycke
  • nödöppning

Hämta personuppgifter [T2].

• Hämtar information för en viss patient. 

8. Sekvenser

Nedan följer exempel på typiska sekvenser, i nedan fall används samtycke för att åskådliggöra principerna. 

Figur 20: Flöde - Samtyckesregistrering 

Notera att användargränssnittet för registreringen kan implementeras på olika sätt. I ovan fall byggs det in i vårdsystemet. 

Figur 21: Flöde - Åtkomstkontroll - intern 


Figur 22: Flöde - Kontrollera samtycke - integrationsmönster 

Ovan figur visar olika tänkbara mönster för integration. Dessa kan användas var och en för sig eller i kombination. T ex är det tänkbart att använda förladdning i batch som en backup-metod till att kontrollera samtycket direkt mot tjänsten. Om tjänsten är otillgänglig kan det förladdade datat användas.

9. Uppfyllande av icke-funktionella krav

9.1. Icke-funktionella krav från verksamheten

9.1.1. Svarstider Svarstidercentrala instansen (Säkerhetstjänsten)

Den centrala instansen (Säkerhetstjänsten) är skalbar genom att lägga till ytterligare maskiner för att förbättra prestanda.

9.1.2. Svarstider lokala instanser

På de lokalt installerade tjänsterna hänger svarstiderna på aktuella miljöer såsom processorkraft, internminne och prestandan på nätverket som nyttjas. 

9.1.3. Tillgänglighet

Tillgängligheten på den centrala instansen (Säkerhetstjänsten) är specificerad till 99,8 %, vilket är ett kortare stopp innan den måste vara tillgänglig igen. 
De lokala tjänsterna har egen drift av dessa och måste ha egna krav på tillgänglighet för just den tjänsten.

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

9.2.1. Test

För att underlätta för test finns systemloggning som kan justeras att logga på olika nivåer. Kan konfigureras att logga på nivåerna Trace, Debug, Info, Warning och Error.

9.2.2. Konfigurationsstyrning

Tjänsterna kan konfigureras vid installation men även under drift via det administration GUI som finns.

9.2.3. SLA-övervakning

Tjänsterna övervakas via ett inbyggt övervakningsgränssnitt i java (JMX). Det används till att monitorera tjänsterna för att kunna se status på dessa. Till detta kan larmfunktioner kopplas på specificerade parametrar för att få snabb information vid eventuella fel och hitta värden som inte visar önskat värde.

Miman är ett internt program byggt för att testa tillgängligheten på den centrala instansen (Säkerhetstjänsten). Den utför ett antal operationen var 5 minut där resultatet sparas i en databas. Ett GUI finns för att kontrollera status på instansen. Operationer som utförs är:

• Hämta samtycke för patient (Skapar ett första gången som kan hämtas)
• Kontrollerar åtkomstkontroll
• Kontrollerar autentisering
• Skapar loggpost

10. Logisk arkitektur

Figur 23: Logisk vy: Konsumenter och producenttjänster - samtycke. 

I ovan sammanfattande bild representerar "Läs"-tjänster alla läsande tjänster (inklusive kontroll) och "Registrera"-tjänster alla tjänster som skriver till tjänsterna.
Arkitekturen följer T-bokens tekniska arkitektur [S2]. Konsumerande system kan vara lokala/regionala/nationella vårdsystem. Stödtjänsterna (producenttjänsterna) nås via virtualiseringsplattformar eller motsvarande.

 
Figur 24: Principer för integration och samverkan, lokalt/regionalt och nationellt. Här exempel med Samtycke.

Figuren ovan tar Samtycke som exempel.
Notera att en viss instans av stödtjänst för samtycke typiskt hanterar flera vårdgivares information. För att visa på principerna ges exempel utifrån två fiktiva vårdgivare A och B. 
Ovan bild tar upp tre typiska mönster som arkitekturen hanterar:

• Nationell e-tjänst. Har behov av hantering av samtycke. Nyttjar centrala stödtjänster (hotelltjänster).
• Lokalt vårdsystem. Har behov av hantering av samtycke lokalt. Nyttjar centrala stödtjänster (hotelltjänster).Personalen använder även nationella tillämpningar (e-tjänster).
• Lokalt vårdsystem. Har behov av hantering av samtycke lokalt. Nyttjar egna lokala stödtjänster och ska kunna vara "självförsörjande".Personalen använder även nationella tillämpningar (e-tjänster).

Alla tjänster är RIVTA21-anpassade och är möjliga att routas via en virtualiseringsplattform (Tjänsteplattform). För full funktionalitet förutsätts att vägval (routing) kan göras i ett integrationsskikt. På detta sätt kan nationell läsning och skrivning implementeras, utan att dessa anrop behöver påverkas om någon huvudman väljer en lokal implementation av tjänsten.Tjänsterna är designade att fungera lika väl på ett lokalt plan. Med fördel används en lokal tjänsteplattform, vilket dock inte är nödvändigt om syftet är endast att nå data i den egna installationen.
En anslutning av en lokal tjänst till den federativa nationella arkitekturen innebär att tillhandahålla den lokala tjänsten som tjänsteproducent för samtycke och registrera den i den nationella tjänsteplattformen.

10.1. Mappning mot signifikanta användningsfall

I nedan fall används samtyckeregistreringar för att exemplifiera principerna.

10.1.1. Lokala registreringar - åtkomst till nationell e-tjänst

Figur 25: Fall 1 

Figur 26: Fall 1 - tjänsteanrop. Steg 1 

Figur 27: Fall 1 - tjänsteanrop. Steg 2 

Ovan styrs anropen till rätt tjänsteproducent genom den logiska adresseringen som bygger på vilken huvudman/vårdgivare som användaren är inloggad på via dennes medarbetaruppdrag.
Det finns en viktig tillgänglighetsaspekt att tänka på här. Den nationella e-tjänsten blir beroende av en lokal tjänst hos den huvudman vars användare nyttjar den nationella e-tjänsten. Om den lokala tjänsten är nere, får det dock bara påverkan på användare som har uppdrag hos huvudmannen/vårdgivaren. Samtycken som lagras i vårdgivarens tjänst berör endast personal hos vårdgivare, eller mer korrekt: har uppdrag hos vårdgivaren, och det är endast för dem som anropet routas till den lokala tjänsten.
Detta är en viktig princip i arkitekturen. Tillgängligheten för den nationella etjänsten bör inte påverkas generellt (för alla) av en huvudmans beslut att hantera en lokal installation för t ex sin samtyckeshantering. 

10.1.2. Åtkomst till nationell e-tjänst, nationell registrering

Figur 28: Fall 2 

Figur 29: Fall 2 - tjänsteanrop. Steg 1 


Figur 30: Fall 2 - tjänsteanrop. Steg 2 

10.1.3. Nationell Läsning "Patientens samtycken"

Figur 31: Fall 3 

Figur 32: Fall 3 - tjänsteanrop. 

10.2. Beskrivning av arkitekturellt signifikanta delar av lösningen

Nedan används samtyckestjänst som exempel för att beskriva typiska integrationsscenarier.

10.2.1. Integrationsscenarier

Figur 33: Integrationsmönster för samtyckeshantering 

I Samtyckestjänsten kan samtycken registreras för senare återanvändning i process och IT-stöd. För att kontrollera existens av samtycke kan olika integrationsmönster användas:

1. Kontrollera om samtycke finns för viss patient visavi den användare som är inloggad på viss vårdenhet. Tjänsten svarar "ja/nej".Se vidare tjänsten CheckConsent [T6].
2. Hämta samtycken avseende viss patient och vårdgivare och utför intern kontroll. Se vidare tjänsten GetConsentsForPatient [T6].
3. Hämta samtycken avseende specificerade vårdgivare (bulkhämta) och utför intern kontroll. Se vidare tjänsten GetConsentsForCareProvider [T6].

En samtyckescache kan upprätthållas som kan användas ifall extern tjänst blir otillgänglig.
Användargränssnitt för samtyckesdialog kan antingen implementeras inom vårdsystemet, alternativt så nyttjas ett fristående GUI för samtyckesregistrering.
I alternativ 3 (bulkhämta) kan om så önskas även avregistreringar returneras (t ex återkallat samtycke). Det kan användas ifall vårdsystemet endast hämtar förändrade data så att avregistrerade kan tas bort.

10.2.2. Åtkomstkontroll

Med stöd av tjänsterna kan ett vårdsystem implementera en kontroll om åtkomst ska ges till viss patientinformation. Beslutet kan baseras på om samtycke och spärr (kompletterande tjänst) finns, samt vilka egenskaper användaren och patientinformationen har.

Figur 34: Interaktionsmönster för åtkomstkontroll där flera underlag vägs samman i beslutet. Vårdsystemet är här både PEP och PDP. 

Antingen implementerar vårdsystemet alla beslutsregler som behövs; vårdsystemet agerar då PDP (Policy Decision Point) och stödtjänsterna PIP (Policy Information Point) genom att tillhandahålla underlagen till besluten: samtycken och användares rättigheter/egenskaper, hämtas från de gemensamma stödtjänsterna.
Alternativt kan vårdsystemet delegera delbeslut till stödtjänsterna; stödtjänsten agerar då PDP och vårdsystemet PEP (Policy Enforcement Point) för det delbeslut stödtjänsten kan bidraga med. 

Figur 35: Principiella interaktionsmönster mot stödtjänst, där var ansvaret för PDP kan flyttas beroende på vilket tjänstekontrakt som nyttjas.

11. Säkerhet

11.1. Infrastruktursäkerhet

Infrastrukturen för samtyckestjänsten kräver att full tillgång till applikationsserver och databasserver begränsas. Om tillgång ges till någon av dessa kan användaren komma åt systemloggar samt spärrdata och förvanska dessa. Att begränsa åtkomsten löses normalt sett med en brandvägg samt att servrarna skyddas med användarnamn och ett starkt lösenord.

11.2. Riskanalys

11.2.1. Centrala instansen (Säkerhetstjänsten)

Riskanalys för den centrala instansen. 

Åtgärder för ovanstående risker: 
V1:

• Redundanta nätverk.
• Duplicerade in- och utgående kommunikationslinjer till både sjunet och internet.

V2:

• Använder GWT som förhindrar cross-site scripting.
• Kommunicerar via SSL för att förhindra avlyssning.
• Inloggning sker med SITHS-kort samt via OTP engångslösen.
• Tillgång till interna sjunet servrar styrs via brandväggar.
• Övergången från internet till sjunet via proxyservrar styrs genom att både näten är separerade och att all tillgång styrs via brandväggar förutom det vanliga inloggningsförfarandet.

V3:

• Redundanta tjänstservrar med duplicerade system med fail-over lösning.
• Klustrad lösning där fler servrar kan startas för att öka prestanda samt för att öka redundansen.
• Last balanseras för att uppnå optimal utnyttjande grad samt säkerställa och öka tillgänglighetsgraden på tjänsterna.
• Aktivt data delas mellan tjänsteservrar m.h.a Infinispan. Infinispan används för att få en klustrad miljö och kunna dela vissa objekt mellan servrar, bla konfiguration och HTTP sessioner.

V4:

• Redundant databasserver med fail-over lösning.
• Ingående data verifieras och valideras innan data sparas internt.
• Storage – backup på databasen sker löpande.

V5:

• Behörighet till information styrs via användarens rättigheter som hämtas från HSA katalogen.
• Behörighet för andra tjänster styrs via dessa tjänstecertifikat som kopplas till de vårdgivare som tjänsten skall ha tillgång till.

11.2.2. Lokala instanser

Riskerna hanteras av respektive huvudmans egen infrastruktur och är inte en del av systemet.

11.3. 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å GWT som bl.a förhindrar cross-site-scripting och POSTning av felaktiga formulärer m.m.
• Kodgenerering

11.4. Intrångsskydd

Intrångsskydd finns för de nationella driftnoderna för säkerhetstjänsterna [P1]. 
Intrångsskyddet för de lokala installationerna beror på respektive huvudmans egen infrastruktur.

11.5. Insynsskydd (kryptering)

SSL/TLS används i all kommunikation med stödtjänsterna, säkerhetstjänsterna samt HSA.

11.6. Transportoförvanskning.

SSL/TLS används i all kommunikation med stödtjänsterna, säkerhetstjänsterna samt HSA.

11.7. Presentationskorrekt

Validering sker vid all registrering av data enligt de principer som gäller för respektive data vilket säkerställer att data är korrekt.
Tillgång till användargränssnitt kräver att användaren är inloggad med SITHS-kort.
Appliceras t ex på framtagande av anpassat användargränssnitt för samtyckesregistrering. 

11.8. Dataintegritet (Oförvanskat över tid), riktighet

Riktigheten i systemets verksamhetsloggarloggar och persistent data (databas) skyddas med hjälp av respektive huvudmans egen infrastruktur och är inte en del av systemet.

11.9. Autentisering ("stark" vid behov enligt infoklassning)

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.

11.10. Lagkrav

Se sammanställning i [S8].

11.11. Spårbarhet (loggning)

Alla De användarstyrda aktiviteter som ska loggas, t ex är all typ av registrering, återkallan och makulering. Även uppföljning genom rapportuttag loggas.trande av samtycke.
Om aktiviteten utförs i vårdsystemet, ansvarar vårdsystemet för den loggning som behövs. Utförs aktiviteten i applikation (användargränssnitt) mot stödtjänsterna, ansvarar den applikationen för nödvändig loggning.
Loggningen ska motsvara lagkraven på spårbarhet enligt PDL och Socialstyrelsens riktlinjer. Se även DI:s checklista för logguppföljning i vården.
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 administrationsgränssnittet. 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årdgivare nivå. 

11.11.1. Logginformation som sparas vid aktiviteter för samtycken

Nedan följer en lista med information som loggas vid de olika aktiviteterna för hantering av samtycken.
Vid registrering:

• Aktör som utför aktivitet. 
• Aktör som begärt samtycke.
• Den medarbetare eller vårdenhet som samtycket gäller för.
• Aktuell patient. 
• Övrig information som anges vid registrering. 

Vid makulering:

• Aktör som utför aktivitet.
• Aktör som begärt makulering av samtycke.
• Information om det samtycke som makuleras.
• Orsak till makulering.

Vid återkallan:

• Aktör som utför aktivitet.
• Aktör som begärt återkallan av samtycke.
• Information om det samtycke som återkallas.
• Orsak till återkallan.

11.11.2. Logginformation som sparas vid rapportuttag

Vid uppföljning som sker via rapportuttag loggas den information som rapporten baseras på samt information om den användare som tar ut rapporten. 

12. Informationsmodell

Se vidare [S8] som är styrande för informationsmodellen.
Förenklade vyer av informationsmodellerna visas i nedan figurer:

Figur 38: Informationsmodell Samtycke (något förenklad) 

Figur 39: Informationsmodell Nödsituation (något förenklad) 

Figur 40: Informationsmodell Nödsituation (något förenklad) 

13. Datamodell

För information om datatyperna, se tjänstekontrakt [T6]. 

14. Driftaspekter

(Skalbarhet, Versionshantering, Uppdatering utan avbrott)(Deployment vy)

14.1. Översikt nätverksåtkomst

Figur 36 Översikt nätverksåtkomst 

Det finns krav på att tjänsterna finns tillgängliga för anslutning både via Sjunet och Internet, eftersom alla huvudmän inte har Sjunet-anslutning. Detta kommer att hanteras enligt ovan principskiss.
De frontsidor som behövs för Internetexponering finns på en proxy i internet-dmz. Kommunikation går därmed aldrig direkt från internet till servrar som frontar mot Sjunet (Sjunets säkerhetskrav).
Tjänstekontrakt på Internet nyttjar nationella Tjänsteplattformens kommande miljö med tjänsteproxy för Internet.
Webbapplikationer på Internet nyttjar Säkerhetstjänsters proxy för Internet. 
Kommunikation går säkrat via separata brandväggar mellan proxy-del och bakomliggande servrar. Kommunikation med stödtjänster som HSA-WS går över Sjunet och passerar aldrig internet-sidan.

14.2. Fysisk miljö

Den fysiska miljön för spärrtjänstenerna beror på huvudmannens val av systemkonfiguration. Se nedan samt föregående översiktsbild Figur 36 visar en lokal installation av Samtyckestjänsten. Den består av en maskin med applikationen samt en maskin med databasen. Ingen automatisk failover hantering. 


Figur 37 Exempel fysik miljö för en lokal installation av Samtyckestjänst 

Figur nedan visar installation av Samtyckestjänsten på Säkerhetstjänsten. Det är en klustrad miljö med failover hantering för en driftsäker miljö. 

Figur 38 Fysisk miljö för Säkerhetstjänsten inklusive Samyckestjänst 

14.3. Programvaror

Tjänsteproducenterna kräver följande programvaror: 

• Java SE 8 – 64-bit
• MySQL Server version 5.6.x – 64-bit
• MongoDB 3.4

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

För mer information se dokumentation för installation och administration. 

15. Följsamhet mot T-bokens styrande principer

15.1.1. IT2: Informationssäkerhet

15.1.2. IT3: Nationell funktionell skalbarhet

15.1.3. IT4: Lös koppling

15.1.4. IT5: Lokalt driven e-tjänsteförsörjning

15.1.5. IT6: Samverkan i federation

16. Referenser

16.1. Bilagor

16.2. Styrande dokument

16.3. Stödjande dokument

16.4. Integrationstjänster

I tabellen kan referenser förekomma som inte direkt är nyttjade i tjänsten. Enbart rader refererade i denna SAD nyttjas.

16.5. Plattformsfunktioner

I tabellen kan referenser förekomma som inte direkt är nyttjade i tjänsten. Enbart rader refererade i denna SAD nyttjas.