Open	Introduktion till samverkansarkitektur   Revision A ARK_0074 2024-11-01

1. Inledning

“Samverkansarkitekturen” är Ineras samlingsbegrepp för alla de referensarkitekturer och anvisningar som tagits fram för att möjliggöra interoperabel samverkan mellan aktörer inom svensk vård och omsorg. Samverkan kan gälla både informationsutbyte och att stödja verksamhetsprocesser över organisationsgränser.

Idag baseras många av välfärdens interoperabla lösningar på informationsförsörjning via den gemensamma samverkansarkitekturens Nationella tjänsteplattform. Samverkansarkitekturen har sedan 2010 erbjudit integrationer enligt integrationsprofilen Basic Profile 2.1 (SOAP och XML) där meddelanden förmedlats via Nationella tjänsteplattformen med en logiskt adresserad mottagare. Sedan 2023, när de kompletterande T2-referensarkitekturerna publicerades, öppnades det upp för att använda andra integrationsstandarder och -mönster.

Det händer otroligt mycket i den Svenska landskapet för interoperabilitet och digital infrastruktur idag så det känns viktigt att notera att denna vägledning är skriven i kontexten av regionalt självbestämmande, förvaltningsgemensam infrastruktur inom regional och kommunal sektor levereras via Inera, samt att det finns en stor framtidstro på standarden HL7 FHIR inom e-hälsoområdet.

2. Samverkansarkitekturen i sitt sammanhang

Samverkansarkitekturen består i sig själv av olika typer av arkitekturdokument. Samverkansarkitekturens mönster för samverkan ställer krav på viss gemensam digital infrastruktur, samt möjliggör kostnadseffektiv etablering av interoperabla lösningar som möter behov ute hos aktörer i välfärden.

Samverkansarkitekturens innehåll kan delas in i ett antal kategorier eller lager ur vilka man kan använda tillämpliga delar beroende på förutsättningar för, och krav på, den lösning som ska tas fram.

Pilen i bilden beskriver att designbeslut för interoperabla lösningar utgår från principerna och sen “arbetar sig upp” genom de olika lagren och använder tillämpliga referensarkitekturer och anvisningar vid utformning av lösningar.

Open

Schematisk bild över hur samverkansarkitekturen relaterar till andra delar av det digitala ekosystemet för interoperabel samverkan.

Samverkansarkitekturen ägs av Sveriges regioner och kommuner och förvaltas av Inera.

2.1 Svenskt ramverk för digital samverkan

I Europa finns ett stort fokus på digitalisering via Interoperable Europe, där man strävar emot interoperabla lösningar inom offentlig förvaltning. En av grundstenarna för detta arbete är European Interoperability Framework (EIF), utifrån vilket Myndighetssveriges samverkansprogram eSamverka (eSam) tagit fram en svensk anpassning, Svenskt ramverk för digital samverkan. Idag förvaltas detta ramverk av myndigheten för digital förvaltning, Digg.

Ramverket ger ett antal principer för digital samverkan, samt ett antal rekommendationer för hur man ska tolka och tillämpa principerna.

Samverkansarkitekturen siktar på att följa Svenskt ramverk för digital samverkan, även om många delar av samverkansarkitekturen skrevs långt innan ramverket fanns på plats. Till exempel definierar T-boken sina egna principer, medan T2 utgår ifrån svenskt ramverk för digital samverkan. De olika uppsättningar principer mappar dock förhållandevis väl emot varandra.

2.2 Gemensam digital infrastruktur

Infrastruktur som används för interoperabla lösningar idag är främst Inera-tjänsterna Nationella tjänsteplattformen, Sjunet, HSA och SITHS. Det finns även gemensamt realiserade tjänster för hantering av loggning, spärrhantering, samt hantering av identiteter och åtkomststyrning.

• Nationella tjänsteplattformen tar bort beroendet mellan olika aktörers tekniska realiseringar genom att stödja förmedling av logiskt adresserade anrop. Nationell tjänsteplattform fungerar också som ett tillitsankare för att säkra en obruten tillitskedja mellan samverkande parter. Regionerna har realiserat sina regionala tjänsteplattformar för att enklare kunna ansluta till de nationella interoperabla lösningarna, samt för att kunna hantera regionala samverkansbehov.

• Sjunet är ett skyddat nätverk som är säkrare än Internet genom att endast Sjunet-kunder har åtkomst till nätet.

• HSA är en elektronisk katalogtjänst som innehåller kvalitetsgranskade uppgifter om organisationer, anställda och system inom vård och omsorg i Sverige.

• SITHS är en elektronisk identitetshandling som erbjuds för såväl anställda som system inom kommuner, regioner och privata aktörer inom välfärden.

För att stödja tjänsteutformning av nya tjänster enligt T2-mönster planerar Inera att ta fram stödtjänster för detta.

1. Tjänstekatalog för teknisk adressering av anrop.

2. Federationsmedlemskatalog för att informationsförsörja information om aktörers deltagande i federationer för informationsutbyten.

3. IAM Metadata-katalog kommer användas för att dela tillitsgrundande information och digitala identiteter. Här planeras en framtida nationell infrastruktur under ledning av Digg, men tidplanen är oklar idag.

2.3 Interoperabla lösningar

En interoperabel lösning är en samling digitala tjänster som via API och/eller användargränssnitt realiserar ett verksamhetsbehov. Varje interoperabel lösning beskrivs av en interoperabilitetsspecifikation innehållande överenskommelser som beskriver förutsättningar och krav för hur lösningen kan och får användas.

De interoperabla lösningarna ska förhålla sig till Svenskt ramverk för digital samverkan, bör utgå ifrån en fastställd övergripande referensarkitektur, samt tillämpa de anvisningar som passar lösningens kontext.

3. Samverkansarkitekturens nyttor

3.1 Att fungera som inlaga i nationellt interoperabilitetsarbete

Inom svensk offentlig förvaltning pågår många utredningar och många projekt för gemensam digital infrastruktur och digitalisering av svensk offentlig förvaltning. I detta arbete ingår standardisering av grunddata, kodverk, semantik, samt realisering av diverse stödtjänster.

Då Sveriges regioner och kommuner kommer behöva anpassa sig till dessa arbeten för sina integrationer med Myndighetssverige blir det mest kostnadseffektivt om man deltar i standardiseringen och tillser att den från start möter behoven från regional och kommunal verksamhet. Om det uppnås behöver man inte ta fram egna standarder utan kan använda de nationella.

Med anledning av vad som sagts i tidigare stycken kan man se samverkansarkitekturen som en inlaga i de standardiseringsarbeten som sker inom Myndighetssverige genom att förtydliga regional och kommunal sektors behov och visa på faktiskt realiserade lösningar.

3.2 Att främja innovation, lokalt och centralt

Mycket av innovationen inom Svensk välfärd sker ute i regioner, kommuner, inom industrin och i diverse forskningsprojekt. Att underlätta för den innovativa utvecklingen att ske i linje med samverkansarkitekturens anvisningar skapar nytta i flera steg.

Om det ges möjlighet att använda samverkansarkitekturens stödtjänster redan när man sätter upp en utvecklingsmiljö ges större utrymme för innovativt arbete. Dessutom blir det enklare att skala upp lyckosamma innovationer att kunna användas i en nationell kontext med drift och förvaltning hos en federationsoperatör som till exempel Inera.

3.3 Att minska etableringskostnad för interoperabla tjänster

Om man använder standarder som verksamhetsssystemen stödjer i sitt grundutförande (t.ex. FHIR), bör man kunna minska kostnaden för införande av stöd för nya interoperabla lösningar. Även genom att kunna nyttja antingen redan etablerade interoperabilitetsstandarder för en lösning, alternativt nyttja nationell eller sektorgemensam profilering av en sådan standard, kan stora effektivitetsfördelar uppnås i etableringsfasen för en lösning.

3.4 Att öka välfärdens digitaliseringstakt totalt sett

Med samma resonemang som för etableringskostnader ovan bör även den tid som krävs för att designa och utveckla tillämpningsspecifika adaptrar mot systemen förkortas avsevärt. Genom att använda befintliga interoperabilitetsstandarder och redan stödd teknik bör många av de potentiella fallgroparna kunna undvikas - man bygger vidare på tidigare innovatörers erfarenheter.

4. Samverkansarkitekturen

Samverkansarkitekturen består i sig av tre huvudsakliga delar:

1. Övergripande referensarkitekturer - ger mönster och terminologi för när man bygger interoperabla lösningar inom svensk välfärd.

2. Specialiserade arkitekturer - för specifika tillämpningsområden som till exempel telemedicin eller en specifik förmåga som kan vara del av en interoperabel lösning

3. RIV-TA - anvisningar, vägledningar och tjänstekontrakt som tagits fram för att stödja realisering av digital infrastruktur för samverkan och utforma interoperabla lösningar.

Open

Schematisk bild över samverkansarkitekturens delar

4.1 Övergripande referensarkitekturer

Referensarkitekturer ger stöd för när man utformar lösningsarkitekturer inom ett eller flera verksamhetsområden . En referensarkitektur innehåller i regel en terminologi med vilken man kan beskriva både behov och lösningar inom området, olika lösningsmönster som kan beaktas, samt vägledning för hur man designar sina lösningar, bland annat avseende standarder.

Inom svensk vård och omsorg tillämpas idag främst referensarkitekturen T-boken. 2023 fastställdes T2-arkitekturerna, vilka ger möjlighet att beskriva interoperabilitetsbehov och -lösningar med större flexibilitet.

4.1.1 T-boken

T-boken, eller “Referensarkitektur för vård och omsorg - T-boken” som den heter egentligen heter, kartlägger behov och ger mönster för interoperabla lösningar för svensk vård och omsorg. Mönstren bygger på integrationer via så kallade tjänsteplattformar. Tjänsteplattformarna säkerställer en obruten tillitskedja mellan samverkande parter, samt möjliggör logiskt adresserade anrop.

T-boken tillämpar en tjänstebaserad paradigm (SOA) med tjänster realiserade med standarderna SOAP och XML.

T-boken togs fram innan svenskt ramverk för digital samverkan fanns och har en egen uppsättning principer och rekommendationer.

Aktörsmönster

T-boken har tillämpats inom svensk vård och omsorg idag enligt ett mönster där all interoperabel samverkan sker via Inera i rollen som distributör av den information som ska delas. Med denna modell delegeras stort ansvar för hantering av tillit och säkerhet till distributören.

Open

Arkitekturellt mönster

T-bokens tillämpning inom svensk vård och omsorg bygger på att anrop förmedlas via en nationell tjänsteplattform. Tjänsteplattformen vidarebefordrar API-klientens logiskt adresserade anrop till API:ets tekniska anslutningsadress efter att ha säkerställt att API-klienten har behörighet.

Open

4.1.2 T2

T2 är samlingslingsnamn för arkitekturerna T2 - referensarkitektur för interoperabilitet inom svensk välfärd (T2 - välfärden) och T2 - referensarkitektur för interoperabilitet inom svensk vård och omsorg (T2 - vård och omsorg). T2 - vård och omsorg är en specialisering av T2 - välfärden som beskriver mer detaljerat hur interoperabla lösningar bör utformas inom svensk vård och omsorg. T2 - välfärden är tänkt kunna tillämpas inom andra välfärdsområden än vård och omsorg.

T2-arkitekturerna innehåller principer, terminologi och modeller för utformning av interoperabla lösningar. T2 har utgått ifrån svenskt ramverk för digital samverkan samt EU-standarder som EIF och EIRA. T2 möjliggör ökad flexibilitet i utformning av lösningar genom möjlighet till direkt kommunikation mellan samverkande parter med stöd för integrationer med stöd för logisk adressering och åtkomststyrning via stödtjänster. Information från stödtjänster kan med fördel mellanlagras nära konsumenten.

T2 Har ingen direkt koppling till någon enskild standard för API utformning.

Aktörsmönster

T2 beskriver en ökad flexibilitet i aktörsmönstret där interoperabel samverkan bör ske direkt mellan tjänstekonsument och tjänsteproducent, men om behov finns av en central värdeskapande tjänst (mer än att underlätta distributionen) så är det inget som hindrar det.

Med direkt kommunikation möjliggörs ökad transparens och därmed större tillit och säkerhet.

Open

Arkitekturellt mönster

Anrop sker enligt T2 direkt från API-klient till API. Uppslag av teknisk anslutningsadress görs av API-klient mot en stödtjänst. Inhämtandet av behörighetsgrundande information och för API-klienten inhämta

Open

4.2 Specialiserade referensarkitekturer

4.3 RIV-TA

Akronymen RIV-TA står för Regelverk för Interoperabilitet inom Vård och omsorg - Tekniska Anvisningar. Inom svensk välfärd finns det idag bred samsyn på hur interoperabla lösningar ska utformas och denna samsyn befästs genom att man fastställt sina överenskommelser i form av anvisningar för olika aspekter av utformandet. Det finns bland annat en mängd anvisningar som reglerar utformandet av lösningar baserat på SOAP och XML. Anvisningar för utformandet av lösningar baserade på T2s mönster med direkt kommunikation är under framtagande.

RIV-TA omfattar även nationellt överenskomna tjänstekontrakt för överföring av information inom specifika domäner. Gränsen mellan nationella tjänstekontrakt och tillämpningsspecifika tjänstekontrakt är idag inte tydlig då Inera förvaltar såväl nationella som de flesta tillämpningsspecifika tjänstekontrakten, och publicerar dem på samma sätt.

Anvisningar och tjänstekontrakt finns publicerade på rivta.se, där även de tidigare nämnda arkitekturerna finns.

5. Vägledning för design av interoperabla lösningar

Under och efter fastställandet av T2-arkitekturerna har det framkommit att T2 skulle vara en ersättare till T-boken och att alla nuvarande interoperabla tjänster ska behöva göra ett teknikskifte för att “anpassas till T2”. Detta är helt fel och vi vill förtydliga att T2 kompletterar T-boken på det sätt att man ges ökad flexibilitet i val av interoperabilitetsstandard och integrationsmönster, när detta behövs för att lösa uppkomna behov.

5.1 Ta fram en interoperabilitetsspecifikation

I T2 - välfärden finns det en generell metodik för tillämpning som kan användas när man tar fram en interoperabel lösning. I denna ingår stegen som behöver utredas inför att en interoperabilitetsspecifikation tas fram. Interoperabilitetsspecifikationen ska belysa samverkan ur legalt, organisatoriskt, semantiskt och tekniskt perspektiv.

Dagens tjänstekontraktsbeskrivningar är en form av interoperabilitetsspecifikation men enligt T2 är interoperabilitetsspecifikationer tänkta att avse ett visst lagrum och syfte.

5.2 Val av integrationsmönster

Nedan visas ett vägledande beslutsträd för hur en interoperabel lösning kan påverkas när man behöver möta nya behov som uppkommit. Beslutsträdet utgår ifrån följande premisser:

1. Utveckling sker utifrån kundbehov och ökad kostnadseffektivitet

2. Man maximerar kostnadseffektivitet genom att skjuta på fördyrande beslut

3. Beslut fattas logiskt

Open

Beslutsträd för val av integrationsmönster för nyutveckling / vidareutveckling av interoperabel lösning

5.2.1 Proprietär interoperabilitetsstandard och direkt integration

Här avses att man använder anslutnings mönster från T2 och utvecklar API:er enligt en proprietär modell.

Om man kommer fram till att detta mönster lämpar sig för de behov som ska mötas så behöver man dels klarlägga om det behövs stödtjänster enligt T2 samt att tillhandahålla API specifikationer för de proprietära API:erna.

Det proprietära API som tas fram ska vara följsamt mot RIV-TA T2 REST (ännu ej publicerad).

5.2.2 Etablerad interoperabilitetsstandard och direkt integration

Här avses att man använder anslutnings mönster från T2 och utvecklar API:er enligt någon vedertagen standard som till exempel HL7 FHIR, DICOM eller liknande.

Om man kommer fram till att detta mönster lämpar sig för de behov som ska mötas så behöver man dels klarlägga om det behövs stödtjänster enligt T2. Dessutom kan man behöva hantera anpassning av standarden vid behov. Exempelvis så behöver ofta HL7 FHIR profileras (anpassas) för svenska behov och detta arbete kan med fördel hanteras tillsammans med HL7 Sverige.

5.2.3 Basic Profile 2.1 och direkt integration

Här avses anrop som inte skickas via Nationell tjänsteplattform utan från tjänstekonsumerande system till tjänsteproducerande system, möjligtvis via en eller flera tjänsteproducerande organisations regionala tjänsteplattform.

Detta mönster rekommenderas om det finns behov av att överföra större datamängder än vad som tillåts via Nationell tjänsteplattform och där producenter och konsumenter har förmågan att hantera detta.

Om man kommer fram till att detta mönster lämpar sig för de behov som ska mötas så måste information om tjänsteproducentens anslutningsadress göras tillgänglig. Detta kan ske till exempel via en referens i svaret på ett tidigare anropsförmedlat anrop, eller genom att man tillgängliggör anslutningsadresser i tjänsteplattformars tjänsteadresseringskataloger eller någon annan form av tjänstekatalog som konsumenterna har tillgång till. Notera att även om adressering sker direkt mot vad som upplevs som en tjänsteproducent så kan det ändå finnas behov av att ange en logiskt adress för att möjliggöra för producenten att använda logisk adressering internt.

Om man tillgängliggör NTjP:s tjänsteadresseringskatalogs data till tjänstekonsumenter via ett separat API kan man anropa de tjänster direkt mot deras anslutningspunkt i regional tjänsteplattform. Regional tjänsteplattform behöver acceptera anrop direkt från dessa tjänstekonsumenter nätverksmässigt och via TAKad behörighet.

5.2.4 Basic Profile 2.1 via Nationell tjänsteplattform

I dagens infrastruktur för anropsförmedling av anrop utformade enligt Basic Profil 2.1 vidarebefordras anropen via en kedja av tjänsteplattformar. Varje tjänsteplattform vidarebefordrar anropet enligt en intern adresskatalog.

Detta mönster rekommenderas idag för överföring av mindre datamängder (mindre än 5MB) där det inte finns redan etablerade integrationsprofiler för verksamhetsbehovet.

Om man kommer fram till att detta mönster lämpar sig för de behov som ska mötas så finns det en färdig infrastruktur på plats, processer för att utveckla tillämpningsspecifika tjänstekontrakt, samt etablerade verksamheter med lång erfarenhet att etablera denna typ av samverkan, både hos Inera och regionerna.

Detta mönster har störst förutsägbarhet avseende tids- och budgetestimat.

5.3 Centralt realiserade tjänster

Olika tillämpningar kan kräva realisering av värdeskapande centrala tjänster. Exempel på detta är aggregerande tjänster inom vård och omsorg, och sammansatta bastjänster inom kommunal sektor (t.ex. SSBTEK).

Behovet av centralt realiserade tjänster är helt oberoende av val av interoperabilitetsstandard. Gällande integrationsmönster inför den centrala tjänsten naturligtvis ytterligare en part i den interoperabla lösningen, men i övrigt påverkas inte val av integrationsmönster mellan parterna.

Specifikt för aggregerande tjänster kan nämnas att om källan för informationslokalisering som ligger som grund för aggregeringen består av ett personbundet index så anses indexet innehålla skyddsvärd information som tjänstekonsumerande system inte får ges tillgång till. Detta påverkar utformning av lösningen. I dagsläget får endast aggregerande tjänster realiserade som del av Nationell tjänsteplattform ta del av dagens källa för informationslokalisering, Engagemangsindex.