FAQ

Informationssystem där aktörens agerande leder till automatiskt informationsutbyte med andra system (tjänsteproducenter).

Tjänstekonsumenten är alltså ett IT-system som initierar ett specifikt informationsutbyte.

Tjänsteproducenter uppvisar ett tekniskt gränssnitt som möjliggör för tjänstekonsumenter att genom frågemeddelanden förändra eller begära information.
Det tekniska gränssnittet följer fastställda standarder för säker meddelandebaserad kommunikation (teknisk interoperabilitet). 
De hanterar frågemeddelanden och producerar svarsmeddelanden enligt för funktionen fastställt nationellt tjänstekontrakt (semantisk interoperabilitet).

Systemoberoende tekniska kontrakt som reglerar samspelet mellan olika komponenter i systemlandskapet, med utgångspunkt i 
process- och informationsmodeller. 
Dessa är upprättade enligt anvisningar för teknisk interoperabilitet i den tekniska arkitekturen vilket innebär 
att tjänstekontraktet säkerställer teknisk interoperabilitet genom att följa anvisning vid upprättandet. 
Ett enskilt tjänstekontrakt består av ett innehåll (nyttolast), kuvert och regler vilket är grunden för semantisk interoperabilitet. 
Semantisk interoperabilitet i sin tur förutsätter en gemensam referensmodell för informationsstruktur.

När ett tjänstekontrakt installeras i en tjänsteplattform skapas en virtuell tjänst.

Integrationstjänst i en tjänsteplattform som är baserad på ett tjänstekontrakt. Den är en nationell ställföreträdare för alla lokala 
tjänsteproducenter som uppfyller ett tjänstekontraktet. Den uppträder som om det 
fanns en nationell tjänsteproducent, men dirigerar vidare frågemeddelanden till 
respektive informationsägares tjänsteproducent och förmedlar 
svarsmeddelandet i retur.

I samband med vidareförmedling verifieras att tjänstekonsumenten är behörig 
att integrera med adresserad informationsägare.

Exempel:

• Den virtuella tjänsten ”Hämta individens tidbokningar” förmedlar frågemeddelanden vidare till respektive vårdenhets tidbokningssystem (tjänsteproducent). 
• Den virtuella tjänsten ”Hämta individens listningar” (kundval/valfrihetssystem/vårdval) förmedlar frågemeddelanden vidare till respektive läns eller kommuns listningssystem (tjänsteproducent).

För att kunna tolkas, administreras och versionshanteras behöver de tjänstekontrakt som stödjer en viss process 
eller informationsbehov grupperas. En sådan gruppering benämns Tjänstedomän.

Tjänsteplattform är ett samlingsnamn för de komponenter som utgör plattform för tjänstebaserad integration över huvudmannagränser. 
Varje samverkansdomän i en federation kan ha en egen instans eller ingå i den överordnade domänens plattform. 
Den nationella samverkansdomänen har en instans som publicerar virtuella tjänster och aggregerande tjänster för 
alla nationella tjänstekontrakt. 
All samverkan mellan samverkansdomäner och inom den nationella domänen sker via tjänster i den nationella tjänsteplattformen.

Virtualiseringsplattformen är en central komponent i TP. 
Den erbjuder infrastruktur för virtuella tjänster. 
Dess primära syfte är systematisk realisering av virtuella tjänster. 
Som en effekt kan generella aspekter av virtualisering förändras i plattformen i stället för att alla 
enskilda tjänster behöver förändras. Det ger gemensam hantering av gemensamma behov, så som felhantering, 
åtkomstkontroll, övervakning, vägval. loggning, uppdatering av engagemangsindex, SLA-uppföljning mot tjänsteproducenter m.m.

En anropande tjänstekonsument behöver inte hålla reda på den tekniska adressen (IP-adress, FQHN) till alla de 
producenter som den anropar. Istället skickar konsumenten med en sk logisk adress till TP. TP översätter den 
logiska adressen och skickar meddelandet vidare till rätt mottagare. 
På detta sätt uppnås sk "lös koppling" mellan de system som är integrerade via TP. 
Ett adressbyte kan genomföras en gång i TP, inte i potentiellt hundratals konsumentsystem.

En tjänstekonsument har inte automatiskt rätt att anropa producentsystem via TP. 
Informationsägaren/systemägaren måste explicit ge tillstånd för varje anropande system. 
Dessa godkännanden lagras i TP och är en förutsättning för att ett anrop skall skickas vidare.

Adressering sker i normalfallet baserat på IP-adress. Som exempel, IP-adressen till Ineras hemsida är 79.136.112.108. 
I normallet används dock host- och domännamn som representerar de tekniska adresserna. 
Tillsammans utgår det ett sk "fully-qualified host name" (FQHN). I Ineras fall är det namnet "www.inera.se".

En viktig effekt av konceptet med tjänsteplattformen är att frikoppla konsumenter och producenter så långt det är möjligt. 
Vi vill inte tvinga alla konsumenter att direkt administrera den tekniska adressen till samtliga producentsystem som 
den vill koppla sig till, och i praktiken känner konsumenten över huvud taget inte till producentsystemet. 
I stället används virtuella tjänster och logiska adresser som representerar en verksamhet (verksamhetsadressering) eller ett system (systemadressering). 
I båda dessa fall används HSA-id som logisk adress (med något undantag).

Tjänstekontrakt som är verksamhetsadrsserade använder ett HSA-id som representerar en organisatorisk enhet som logisk adress.

Vid systemadressering används ett HSA-id som representerar ett källsystem som logisk adress. 
Ett källsystem kan t ex vara ett journalsystem. I normalfallet är källsystemet inte samma sak som tjänsteproducenten.

Tjänsteplattformen måste mappa en logisk adress till den teknisak adressen för ett producentsystem, 
och skicka ett anrop vidare till producenten. Det är alltså inte producentsystemet som adresseras, 
istället en bakomliggande verksamhet eller ett bakomliggande källsystem. 
Producentsystemet kan sägas representera verksamheten eller källsystemet. 
Mappningen mellan logisk adress och adress till tjänsteproducent lagras i Tjänsteadresseringskatalogen (TAK) i Tjänsteplattformen.

Nej, i normalfallet måste verksamheten eller systemägare för källsystemet explicit godkänna varje tjänstekonsument innan anrop tillåts.

Denna information lagras i Tjänsteadresseringskatalaogen i Tjänsteplattformen.

Tjänsteadresseringskatalogen är en databas med nio tabeller som innehåller den grundinformation som 
Tjänsteplattformen behöver för att hantera virtuella tjänster (tjänstekontrakt), 
anslutningar av konsumenter och producenter, logiska adresser samt behörigheter.

Namnet på tjänstekontraktet (hela namnrymden), version samt vilken version av RIVTA det bygger på.

HSA-id (från SITHS-funktionscertifikat) som konsumenten har. Dessutom IP-adressen till konsumenten.

HSA-id (från SITHS-funktionscertifikat) som producenten har. Dessutom IP-adressen till producenten.

Logiska adresser lagras i en tabell tillsammans med uppgifter om adressens gilitighetsperiod. 
De logiska adresserna kopplas samman med tjänstekontrakt och producentsystem på ett sådan sätt att 
Tjänsteplattformen utifrån ett anrop mot ett specifikt tjänstekontrakt och logisk adress kan se vilken 
producent som skall adresseras.

Anropsbehörigheter lagras i en tabell tillsammans med uppgifter om gilitighetsperiod. 
En uppgift om behörighet kopplas samman med logisk adress, tjänstekontrakt och konsumentsystem. 
Tjänsteplattformen kan utifrån denna information avgöra huruvida en viss tjänstekonsument får anropa en 
specifik tjänst (tjänstekontrakt) på en specifik logisk adress.

Det är naturligtvis av yttersta vikt att information i Tjänsteadresseringskatalogen är korrekt, 
samt att det finns en spårbarhet på vem som tillhandahållit vilken information. 
Inom förvaltningen för den gemensamma Tjänsteplattformen använder man för närvarande ett system med 
fyra olika Word-blanketter (A, B, C och D) för att inhämta informationen. 
Dessa ligger till grund för uppdateringar av databasen, och arkiveras. 
Det finns planer på att ta fram ett administrativt gränssnitt för att delegera ut administrationen av TAK närmare 
verksamheterna.

Den nationella arkitekturen som den är beskriven i T-boken och detaljerad i RIV TA utgår ifrån att flera 
tjänsteplattformar kan seriekopplas. Typfallet är att en region/landsting har en regional instans (en sk RTjP) som används för regional trafik, men också utgör gateway för alla integrationer till tjänster utanför regionen. Praktiskt kan man i normalfallet tänka sig en kedja på upp till tre plattformar, RTjP-NTjP-RTjP, för kommunikation ut ur en region, 
via den gemensamma plattformen (NTjP) och in till en tjänst i en annan region. Teoretisk skall dock kedjan kunna vara längre

När plattformar kopplas i serie måste de samspela vad gäller vägval (adressering) och behörighetskontroll. 
Det innebär att det kommer att vara ett visst överlapp av information mellan regionala och den gemensamma TAKen. 
Dock måste även adresser till angränsande plattformar finnas med.

Låt oss anta att en tjänstekonsument kopplas samman med en tjänsteproducent (som representerar en verksamhet) via tre plattformar; 

K1 - RTjP1 - NTjP - RTjP2 - P1 - V1.

Ett exempel på en sådan integration skulle kunna gälla NPÖ2 som tjänstekonsument och tjänsten !GetCareDocumentation. 
En tjänstekonsument på VGR, K1, är ansluten till VGRs regionala plattform, 
RTjP1. 
När en journal skall hämtas från Hjärtkliniken på Karolinska sjukhuset inom SLL kommer anropet att routas via den gemensamma plattformen (NTjP),
och sedan vidare till SLLs regionala plattform (RTjP2). 
Därefter går det till den producent, Take Care (P1), som representerar Hjärtkliniken. Den slutgiltiga adressaten, logiska adressen, är alltså Hjärtkliniken (V1).

RTjP1-TAK
För att detta exempel skall fungera så måste RTjP1-TAK (dvs den TAK som används av RTjP1) innehålla förljande information:

Det är i den första tjänsteplattformen i kedjan som det sker en behörighetskontroll av att den ursprungliga tjänstekonsumenten har behörighet att anropa verksamheten i fråga. RTjP1 har ingen information om RTjP2 och P1.

NTjP-TAK

NTjP-TAK kommer att ha information om:

Behörighetskontrollen begränsas här till att verifiera att den regionala tjänsteplattformen RTjP1 har rättighet att andressera V1 för !GetCareDocumentation. 
NTjP känner inte till K1 eller P1.

RTjP2-TAK

RTjP2-TAK innehåller:

Behörighetskontrollen begränsas här till att verifiera att den gemensamma tjänsteplattformen NTjP har rättighet att andressera V1 för !GetCareDocumentation. 
RTjP2 känner inte till K1 eller RTjP1.

För installation i SIT- eller QA-miljön ska domänen vara tekniskt granskad och godkänd, dvs. det finns ett tekniskt granskningsprotokoll publicerat på RIVTA. 

Domäner som ägs av eHälsomyndigheten är undantag och kvalitetssäkras inte enligt våra rutiner.  

För installation i produktionsmiljön ska domänen vara granskad och godkänd utifrån perspektiven informatik, säkerhet och teknik. 

Domänversionen måste vara en released version som inte kommer att ändras. Ingen released candidate (RC) är tillåten i produktionsmiljön. 

Domäner som ägs av eHälsomyndigheten är undantag och kvalitetssäkras inte enligt våra rutiner.