Översikt

För att samverkan via digitala tjänster och informationsutbyte ska vara möjlig behöver samverkande parter vara överens om hur tjänster ska utformas, samt hur informationen ska representeras, paketeras och tolkas. Man behöver också vara överens om vilken information som får överföras och hur den får behandlas.

Utöver dessa överenskommelser behöver det finnas infrastrukturtjänster som möjliggör en effektiv, säker och robust teknisk samverkan med rättssäker åtkomsthantering. Ett urval av dessa kan med fördel nyttjas gemensamt för att på så vis uppnå olika skalfördelar.

Samverkan mellan parter beskrivs av interoperabilitetsspecifikationer som omfattar de legala, organisatoriska, semantiska och tekniska perspektiven av samverkan.

Open

Bilden visar hur API:er och klienter förhåller sig till interoperabilitetsspecifikation, centralt realiserade digitala stödtjänster samt centralt definierade byggblock. API och API-klient realiseras enligt en interoperabilitetsspecifikation. API och API-klient nyttjar centralt realiserade digitala stödtjänster. Centralt definierade byggblock beskriver en delmängd av realisering för API och eller API-klient

Centralt realiserade digitala stödtjänster

Med centralt realiserade digitala stödtjänster avses här de infrastrukturtjänster där det finns stora operationella fördelar med central realisering eller där samverkan över organisationsgränser underlättas av viss gemensam funktionalitet. Syftet med den typ av tjänster som beskrivs i det här kapitlet är huvudsakligen att underlätta teknisk samverkan mellan två parter.

Nedan beskrivs kandidaterna lämpliga för central realisering inom svensk vård och omsorg.

Tjänstekatalog

Inom svensk vård och omsorg finns behov av informationsutbyte mellan många olika aktörer inom flera verksamhetsområden och dessa behöver hitta varandras utbud av API:er till digitala tjänster och API:ernas tekniska anropsadresser. Tjänstekatalogen realiserar de två byggblocken Tjänsteregistrering och Tjänstesökning från T2 - välfärden.

En tjänstekatalog bör hantera tjänster för en specifik standard, detta på grund av att man för olika standarder kan vilja ha olika utformning av API för tjänstesökning. Till exempel kan sökning efter digitala tjänster baserade på FHIRs REST-API:er behöva ske annorlunda än för digitala tjänster baserade på tjänstekontrakt utformade enligt RIV TA Basic Profile 2.1. Detta för att underlätta för API-klienten att kunna tolka svaret från tjänstesökningen.

Inom varje område där samverkan ska ske behöver det finnas gemensamt överenskomna regler för hur den digitala tjänsten fungerar ur ett konsument- och producentperspektiv. Identifierare för digitala tjänster behöver vara unika inom den kontext som de exponeras.

Registrera lokalt och konsolidera centralt

T2 rekommenderar att tjänstekatalogen realiseras som en federativ lösning med central konsolidering. Respektive part kan i en sådan lösning välja att ha en lokal tjänstekatalog för att administrera sina digitala tjänster. Informationen om digitala tjänster som ska exponeras utanför den egna organisationen konsolideras centralt.

För varje registrering behövs information om:

• Organisationsidentifierare

• Teknisk anropsadress

• Identifierare för integrationsprofil

Utöver detta kan även ytterligare information behövas för att berika katalogen.

Open

Exempel på hur tjänsteregistrering kan konsolideras via lokala kataloger men även registreras direkt mot en centralkatalog.

Sök lokalt och centralt

Tjänstesökning tillhandahåller förmågan att utforska vilka digitala tjänster som organisationer erbjuder.

Lokala tjänster kan med fördel nyttja en lokal katalog för lokala tjänster och på så vis endast bli beroende av en central katalog för uppslag av tjänster utanför den egna organisationen. Gränssnittet för sökning i lokal katalog kan, för att förenkla realisering av lokala tjänster, vara utformat på samma sätt som för en central katalog men det är upp till respektive organisation att bedöma utifrån påverkan på lokal katalog kontra antal tjänster som behöver söka centralt.

Sökning efter tjänster sker med organisationsidentifierare och den inom sammanhanget överenskomna identifieraren för integrationsprofil.

Tjänstesökning möjliggör uppslag av digitala tjänster baserat på organisationsidentifierare i syfte att undvika behovet av statisk teknisk konfiguration över organisationsgränser.

För ökad robusthet rekommenderas API-klienter hålla en cache av anropsadresser. Vid tjänstesökning i syfte adressering kan man söka med strategin först lokal cache, sedan lokal tjänstekatalog, till sist central tjänstekatalog. Detta för att minimera operativt beroende till externa parter och öka robustheten.

Informationsaggregering

Beroenden finns till följande arkitekturbyggblock från T2 - välfärden:

• Informationslokalisering

• Tjänstesökning

Dessutom kan det finnas beroende till informationsindex. Se avsnittet Informationslokalisering genom index nedan för mer detaljer kring index.

I många situationer finns behov av att samla in information från många dataägare och skapa en aggregerad bild. Detta kan göras på tre olika sätt beroende av hur man väljer att hitta informationskällor och var informationen aggregeras.

1. Hämta information från källor givna av informationsindex, aggregera själv

Detta mönster för informationsaggregering innebär att API-klienten via informationsindex söker fram de organisationer som har information för det sökbegrepp man är intresserad av. API-klienten söker sedan via tjänstesökning de digitala tjänster hos dessa organisationer som stödjer utlämnande av den typ av information som ska aggregeras och den digitala tjänsten aggregerar därefter svaren för vidare användning.

För att detta mönster ska fungera rättsligt krävs att API-klientens åtkomst till informationen i index antingen inte i sig självt medför en personuppgiftsincident, eller att själva åtkomstbeslutet för indexposten utförs av dataägaren eller av denne via avtal utsett biträde. Aspekter kring utformning av index berörs i avsnittet “informationslokalisering genom index” nedan.

Till exempel skulle detta mönster kunna användas för sammanställa journalinformation till enskild och där API-klienten vill ha kontroll över presentation och felhantering av informationen från de enskilda källorna.

2. Hämta information från alla möjliga källor, aggregera själv

Detta mönster för informationsaggregering innebär att digitala tjänster, via en API-klient för tjänstesökning, hämtar alla producenter med digitala tjänster vilka stödjer utlämnande av den typ av information som ska aggregeras. Sedan anropar den digitala tjänsten, via en annan API-klient, dessa producenter med det sökbegrepp som man är intresserad av och aggregerar själv de svar som ges för vidare användning.

Då det i varje digital tjänst tas ett åtkomstbeslut och information endast lämnas ut om det finns behörighet så finns inte problematiken med åtkomstkontroll kring indexposter som beskrivs ovan. Mönstret lämpar sig då antalet digitala tjänster är få, där en majoritet av dem har information, eller där konsekvenserna av onödiga anrop är små.

3. Hämta aggregerad information från aggregerande tjänst, vilken i sin tur frågar källor givna av informationsindex

Detta mönster för informationsaggregering innebär att den digitala tjänstens API-klient begär information för ett visst sökbegrepp från en aggregerande tjänst. Den aggregerande tjänsten söker sedan via informationslokalisering fram de organisationer som har information för det sökbegrepp man är intresserad av. Den aggregerande tjänsten hämtar därefter via tjänstesökning de digitala tjänster hos dessa organisationer som stödjer utlämnande av den typ av information som ska aggregeras. Den aggregerande tjänsten frågar dessa digitala tjänster efter information för det sökbegrepp som efterfrågats, aggregerar svaren och returnerar det aggregerade svaret till API-klienten.

Till exempel skulle detta mönster kunna användas för att presentera bokade tider för en patient eller andra typer av patientöversikter där API-klienten vill ha ett enkelt gränssnitt där komplexiteten göms i den aggregerande tjänsten.

Informationslokalisering genom index

Beroenden finns till följande arkitekturbyggblock från T2 - välfärden:

• Informationslokalisering

Informationslokalisering handlar om att aktörer ska kunna identifiera var det finns befintlig information som behövs vid ett visst tillfälle. Förutsättningar kring att lokalisera information är beroende av informationstyp och lagrum. I detta kapitel fokuserar vi på informationslokalisering genom att använda index.

Förmågor

Returnera information om informationsbärande aktörer.

Aktörsmönster

Aktörsmönster är beskrivna i T2 - välfärden https://inera.atlassian.net/wiki/spaces/OITIFV/pages/2643985049/Samverkan+och+interaktioner#Akt%C3%B6rsm%C3%B6nster

En Tjänstekonsument - ett fåtal Tjänsteproducenter

Beroende på det faktiska antalet tjänsteproducenter i kombination med anrops- och svarsmönster kan utformningen göras antingen med eller utan index.

Sökning baserat på informationsindex är tillämpligt vid hög anropsfrekvens och då det inte är sannolikt att alla eller flertalet tjänsteproducenter faktiskt innehar information av den aktuella typen.

En Tjänstekonsument - många Tjänsteproducenter

När antalet tjänsteproducenter är betydande, och det inte kan antas att samtliga eller flertalet bär den sökta informationen, så kan sökning med någon form av informationsindex användas för att minimera antalet anrop att till tjänsteproducenter som inte har relevant information.

Om det i normalfallet är så att alla tjänsteproducenter kan förväntas ha information som matchar sökningen så tillför inte index något nämnvärt värde då de flesta tjänsteproducenter ändå kommer att bli anropade.

Nyttan av index

För att reducera antalet frågor kan man identifiera informationsbärande aktörer genom att dessa registrerar informationsförekomsten i ett index som sedan används för att styra vilka aktörer man ska fråga i syftet är att begränsa totala antalet frågor.

Båda exemplen genererar en substantiell mängd frågor men skillnaden är påtaglig och skulle kunna påverka hur informationslokaliseringen kan utformas i synnerhet om man skulle betrakta dem separat.

Om man i exemplet patientens direktåtkomst använder index och antar att en individ i genomsnitt har information i 10 stycken system så skulle antalet frågor begränsas till 1984 frågor per sekund för API-klient. Motsvarande siffror för vårdens direktåtkomst skulle innebära en reducering till 111 anrop per sekund för API-klient.

Utfallet per producent är något mer svårprognostiserat givet att vi inte vet hur informationen fördelas över system men det går att anta att system med stor användarbas (befolkningsmängd) får fler frågor och att vinsten för dessa kanske kan vara marginell. Men för system med färre antal användare bör vinsten vara stor.

Utformning av index

Vid utformning av index är det viktigt att överväga med vilken granularitet som indexet ska bära information. Viktiga aspekter är hur man balanserar integritet och informationssäkerhet kontra tekniska effektivitetsvinster.

Exempel 1: Tjänstekonsumenten behöver fråga alla tjänsteproducenter, som har ett tillämpligt API, efter den information som är intressant (tex observation av typen längd)

Exempel 2: Tjänstekonsumenten kan avgränsa frågan till de tjänsteproducenter som har information av rätt typ på en övergripande nivå (observation)

Exempel 3: Tjänstekonsumenten kan avgränsa frågan till de tjänsteproducenter som har information av rätt typ (observation av typen vitalparametrar)

Det finns två tydliga motsatsförhållanden i detta i och med att ju mer granulärt indexet är desto mer stöd ger det till konsumenten men samtidigt så ökar det integritetsrisken och insatsen för producenterna att hålla indexet uppdaterat. Så utformningen behöver ta hänsyn till aktörernas förmågor, fördelning samt integritetsfrågan.

Informationslokalisering med lokala index

Fördelen med lokala index/informationslokaliseringstjänster är att dessa kan realiseras närmare tjänsteproducentens övriga tjänster och därmed lättare kan utformas att ta beslut om vilka indexposter som ska returneras baserat på vem som efterfråga situationen och i vilket syfte för att på så sätt undvika risken för att en viss aktör får tillgång till en indexpost men inte har accessrätt till den faktiska informationen.

Sökning mot lokala index lämpar sig för situationer där:

• Antalet index är hanterbart

• Det är relativt få aktörer

• Dataägaren vill/behöver kunna styra åtkomsten till index-informationen baserat på den som frågar.

• Det finns lagkrav på formerna kring hur informationsutlämning ska se.

I exemplet ovan skulle varje sjukhus då kunna ha sin egen informationslokaliseringstjänst/index som respektive verksamhetssystem i de olika regionerna använder för att hitta var det finns radiologisvar. Eftersom den verksamhetsmässiga samverkan är avgränsad till så få parter så anses det inte motiverat att uppdatera någon form av mer centraliserat index.

Orkestrering

Beroenden finns till följande arkitekturbyggblock från T2 - välfärden:

• Orkestrering

Orkestrering kan användas för att utforma digitala tjänster som hanterar flera olika typer av information, hantering kan vara både att läsa och skriva, i syfte att stödja ett komplext applikationsflöde

Exempel på orkestering är en tjänst som inhämtar information av olika typ och från olika källor och sen använder den för att, enligt givna affärsregler, skapa en ny sammansatt informationstyp. Att utforma detta som en gemensam digital tjänst kan vara lämpligt då man inte vill att varje tjänstekonsuments digitala tjänst ska behöva hålla reda på vilka som är relevanta källor, tolka affärsreglerna samt göra sammanslagningen.

Varje producents digitala tjänst tar egna åtkomstbeslut för informationstillgången, beslutet kan behöva tas med kunskap om informationsbehandlingen som sker i den orkestrerade tjänsten samt vem som är ursprunglig frågeställare.

Informationsbehörighet

Enligt T2 - välfärden kan tjänster ha behov av mekanismer för att filtrera svarsinformationen utifrån egenskaper knutet till informationen eller användaren. Nedan ges exempel på sådana behörighetsgrundande egenskaper som är av organisationsöverskridande karaktär, vilket kan motivera central realisering av informationsförsörjningen.

Spärr

Vid informationsutbyte av journalinformation enligt sammanhållen journalföring krävs det att spärrad information filtreras bort och ibland även information om att det finns spärrad information.

De system som ska tillgängliggöra journalinformation enligt sammanhållen journalföring måste således ha tillgång till information om vilka spärrar som finns.

Då spärrar kan sättas både nationellt och lokalt har man inom svensk vård och omsorg beslutat använda nationell samordning av spärrhantering i en gemensam spärrtjänst, vilken system som tillgängliggör informationen konsulterar.

Försegling

Försegling kan begäras både hos en viss vårdgivare och hos 1177 Journalen.

Idag är 1177 Journalen det enda nationella systemet för invånares direktåtkomst till journalinformation över huvudmannagränser och total försegling av direktåtkomst kan hanteras där.

Om invånares direktåtkomst till journalinformation bereds via andra/flera kanaler kan det behövas nationell samordning av invånares vilja till att helt försegla all journalinformation via en förseglingstjänst.

Lokal försegling av information hos en viss vårdgivare/enhet i ett specifikt vårdinformationssystem kan idag förekomma och är då en helt lokal hantering som fyller sitt syfte oavsett kanal.

Patientrelation

Enligt PDL kan vårdgivare endast ta del av andra vårdgivares journalinformation under lagrummet sammanhållen journalföring då det finns en patientrelation.

Samtycke

Invånarens samtycke krävs idag i många fall där personinformation ska behandlas eller åtkomst till personinformation ska ges.

Det är därför av stor vikt för åtkomsthantering för många av befintliga och framtida digitala tjänster att samtycken kan hanteras effektivt av såväl invånare som vårdens medarbetare.

Företrädare

För direktåtkomst till patientuppgifter kan det finnas behov att bereda åtkomst till digitala tjänster för olika typer av företrädare för en invånare.

Centralt definierade digitala tjänster

Identitetshantering och Åtkomsthantering är två byggblock som det är nödvändigt att alla aktörer är överens om realiseringen av. En sådan överenskommelse lägger grunden för ett gemensamt ramverk för att ett rättssäkert informationsutbyte ska kunna ske.

Identitetshantering

Gällande identitetshantering används idag uteslutande SITHS som identitetsutgivare för medarbetare. För invånare ska alla enligt svensk e-legitimation godkända identitetsutfärdare stödjas. Dessutom ska digitala identiteter godkända enligt eIDAS-förordningen kunna användas för att styrka sin identitet.

Åtkomsthantering

För åtkomsthantering ska T2 - vård och omsorg linjera med Referensarkitektur för identitet och åtkomst.