| Innehållsförteckning | ||||
|---|---|---|---|---|
|
Ö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.
...
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.
...
| Info |
|---|
Exempel: Tidbokning som digital verksamhetsförmåga kan delas upp i flera olika digitala tjänster:
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.
...
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.
...
Exempel 2
Den digitala tjänsten skicka remiss i organisation 1 behöver hitta adressen till en tjänst hos organisation 2 som kan ta emot remisser
Remisstjänsten i organisation 1 behöver kunna hitta den digitala tjänsten med stöd för integrationsprofil Skicka remiss i organisationsenheten SE2301 som finns inom organisation 2. För detta används en API-klient för tjänstesökning som hittar adresser på följande sätt:
API-klienten söker först i sin cache men har i exemplet inte någon cachad adressinformation att utgå ifrån så den behöver göra adressuppslag.
API-klienten söker sedan i den lokala katalogen men får där ingen träff.
Därefter söker API-klienten i den centrala katalogen och hittar adressen till
SE2301i organisation 2, vilken ärhost1.x.y.Remisstjänsten använder därefter en annan API-klient för att anropa tjänsten
skicka remisshosSE2301genom att anropahost1.x.y
...
Informationsaggregering
Beroenden finns till följande arkitekturbyggblock från T2 - välfärden:
...
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.
...
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.
...
Exempel
Detta mönster skulle kunna användas vid bokning av tid för att hämta in lediga tider och där antalet parter är begränsat genom tidigare urval, baserat på attribut som geografisk plats, verksamhetsutbud och liknande.
Tjänstekonsumenten har som ingångsvärde (från en här odefinierad process) ett antal organisationsidentifierare till vilka man vill ställa frågan om lediga tider för att kunna boka tid för besök. För ändamålet vill man använda tjänsten “Hämta lediga tider”
Ett anrop till tjänstesökning med dessa organisationsidentifierare (A, B, C, D) returnerar anslutningsadresser till de organisationer som har stöd för “Hämta lediga tider (A, B, C)
Därefter anropas respektive organisations tjänst och svaren sammanställs och presenteras varefter en tid väljs och används tex vid bokning av en viss tid hos B.
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 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.
...
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.
...
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.
...
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:
...
| Info |
|---|
Exempel på en orkestrerande tjänst är försäkringskassans SSBTEK (sammansatt bastjänst ekonomisk bistånd) som sammanställer information från:
|
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.
...
| Info |
|---|
Spärrtjänsten finns som del av Ineras tjänsteutbud (Säkerhetstjänster - Inera). Denna används av den förvaltningsgemensamma applikationen Nationell patientöversikt. |
Försegling
Försegling kan begäras både hos en viss vårdgivare och hos 1177 Journalen.
...
| Info |
|---|
Med försegling avses att spärra informationen för åtkomst av individen själv eller olika typer av ombud utanför vården men har ingen påverkan på vårdpersonals åtkomst under sammanhållen journalföring. |
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.
| Info |
|---|
Om det är aktuellt med åtkomst till information via flera kanaler så behöver alla, som ska stödja företrädarens åtkomst, ha tillgång till denna information som styrker rätten för en person att företräda en annan. För att undvika att uppgifter om denna rätt behöver kontrolleras och registreras flera gånger så är det lämpligt med centrala informationskällor för detta. |
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.
...