Teknisk vy PA5.01
Ö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.
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.
Exempel: Tidbokning som digital verksamhetsförmåga kan delas upp i flera olika digitala tjänster:
Visa bokade tider
Nybokning
Avbokning
Ombokning
Olika aktörer kan välja att realisera en eller flera av dessa digitala tjänster. Därför behöver detta beskrivas på en mer detaljerad nivå så att en applikation som vill avboka en tid kan avgöra om aktören stöder just den åtgärden.
Tidbokning beskrivs i de interoperabilitetsspecifikationer som används av tjänstekonsumenter och tjänsteproducenter vid implementation för att förstå regelverken kopplat till de ingående digitala tjänsterna.
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.
Den konsoliderade modellen medger alltså att lokala kataloger inte direkt behöver exponeras mot externa tjänster och heller inte nödvändigtvis behöver ha samma gränssnitt för sökning eftersom externa sökningar sker mot den centrala katalogen. Om konsolideringen sker maskinellt från lokal till central katalog så behöver konsolideringsgränssnittet vara standardiserat.
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.
Exempel
Organisation 1 (vars vårdsystem har anropsadress host1.a.b) registrerar att enheten SE1611 stödjer integrationsprofilen lediga tider samt att enheten SE1612 stödjer integrationsprofilen skicka remiss. De ska exponeras utanför den egna organisationen och konsolideras därför upp till central adresskatalog.
Organisation 2 (vars vårdsystem har anropsadress host1.x.y) registrerar att enheten SE2301 stödjer integrationsprofilen skicka remiss samt att enheten SE2302 stödjer integrationsprofilen lediga tider. De ska exponeras utanför den egna organisationen och konsolideras därför upp till central adresskatalog.
En administratör på någon nivå, i bilden inom organisation 3, registrerar direkt i central adresskatalog via ett webbgränssnitt att enhet SE3399 stödjer integrationsprofilen remiss via vårdsystem med anropsadress host1.d.e.
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/3020325205/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.