Interoperabilitet - med andra ord

 

Interoperabilitet - med andra ord



Version 1.0

ARK_0058

2020-05-13





 

Detta dokument är ett försök att översiktligt beskriva principerna bakom dagens kommunikation över tjänsteplattformar. Många termer kan vara obekanta för läsaren - sist i dokumentet finns en liten ordlista som kan vara till hjälp.

Vi inleder med ett historiskt scenario - hur fungerade informationsutbytet inom vården under det förra århundradet.

När vi använde brev i stället för digitala meddelanden

Här beskrivs ett hypotetiskt scenario.

Hypotetisk bakgrund

Under 1990-talet identifierades inom vården behovet av att kunna utbyta brev med information på ett enkelt, effektivt och säkert sätt. Många kloka personer slog sina huvuden ihop, och efter flera års tänkande och ritande på whiteboards så kom man fram med en plan. Den arkitektur planen byggde på hade följande egenskaper:

  • Det finns mallar som bestämde formatet och det tillåtna innehållet på de brev som ska skickas.

  • Både avsändare och mottagare av breven, liksom postkontoren, ska inneha ett sigill som gör att de säkert kan identifieras. Identiteten framgår av sigillet.

  • Alla parter får en adress så att breven kan hitta fram till rätt mottagare.

  • En kontrollmekanism som ser till att styra behörigheter, vem som har rätt att skicka ett brev till en viss adress.

  • Ett centralt, nationellt, postkontor. Här ska alla brev passera som skickas mellan vårdenheter i olika städer. På kontoret finns det nationella adress- och behörighetsförteckningar.

  • Regionala postkontor i varje stad. Det hanterar flödet av brev mellan enheter och personer inom staden, men också brev till och från staden, via det centrala postkontoret. På dessa kontor finns regionala adress- och behörighetsförteckningar.

  • Ett system för massutskick. Kopplat till detta system finns ett index där ett urval av adresser kan sökas fram.

  • Och så finns det naturligtvis läkare, sjuksköterskor, administrativ personal, vårdenheter mm, som agerar i rollerna avsändare och mottagare.

 

Administration

Det var en hel del som behövde förberedas innan breven kunde börja flöda.

  • Postkontoren måste byggas och utrustas med lämpliga sorteringsbord. Dessutom måste samtliga kontor sätta upp adress- och ett behörighetsförteckningar.

    • Adressförteckningen innehåller gatuadressen för alla adressater som skall kunna nås från aktuellt postkontor (sker per mall).

    • Behörighetsförteckningen berättar vilken avsändare som har rätt att adressera en viss adressat (per mall).

  • Mallarna för de olika brevtyperna designades. Dessa placerades i olika mallkategorier.

  • Samtliga parter som ska kunna skicka och ta emot brev är tvungna att skaffa ett sigill.

Meddelandeflödet

Själva utbytet av brev följer en bestämd sekvens. Det kan exempelvis vara:

  1. En läkare (avsändare) bestämmer sig för att skicka ett brev till en vårdcentral i en annan stad (mottagare) för att be om en journalkopia. En lämplig mall för journalinformation väljs.

  2. Frågan formuleras, och sedan skickas brevet till det närmaste postkontoret, adresserat till vårdcentralen. Det kan vara ett regionalt kontor eller så kan brevet, i vissa fall, skickas direkt till det nationella kontoret. Brevet skickas krypterat, och en kopia av avsändarens sigill skickas med.

  3. Mottagande postkontor tar emot sigill och brev. Därefter sker följande:

    1. Kontroll att sigillet är korrekt. Avsändarens identitet plockas fram.

    2. Kontroll i adressförteckningen att adressen (vårdcentralen) är känd och accepterad för den mall som används (dvs, mallen + adressen → mottagare).

    3. Kontroll i behörighetsförteckningen av att avsändaren har rätt att skicka brev baserat på aktuell mall till mottagaren.

  4. Om kontrollerna ovan går bra skickas brevet vidare till nästa part. Om denna part är ett postkontor upprepas kontrollerna.

  5. Om brevet lyckas passera de mellanliggande postkontoren når det till slut mottagande vårdcentral. En mottagare kan representera många enskilda parter.

  6. Ett svar formuleras, baserat på mallen. Svarsbrevet skickar sedan tillbaka enligt samma väg som det anlänt.

Massutskick

För viss information kunde det vara så att det är många mottagare som behövde tillfrågas för att få ett samlat svar. Avsändaren kunde då välja att adressera Massutskicksfunktionen. Den har ett index med adresser som för varje mall pekar ut de mottagare som behöver kontaktas. Funktionen genomför sedan utskicken, och samlar ihop svarsbreven i en kartong. Denna returneras sedan till avsändaren.

Digital integration

I vårt århundrade är det naturligtvis mycket ineffektivt att förlita sig på brev för att byta information mellan vårdens parter. I mitten på 00-talet identifierades sex insatsområden för digital samordning på nationell nivå:

  1. Harmonisera lagar och regelverk med en ökad IT-användning.

  2. Skapa en gemensam informationsstruktur.

  3. Skapa en gemensam teknisk infrastruktur.

  4. Skapa förutsättningar för samverkande och verksamhetsstödjande IT-system.

  5. Möjliggöra åtkomst till information över organisationsgränser.

  6. Göra information och tjänster lättillgängliga för medborgarna.

 

För att möjliggöra detta skapades en digital referensarkitektur (T-boken) samt ett Regelverk för Interoperabilitet inom Vård och omsorg (RIV). Det innehöll:

 

  • Tekniska anvisningar, RIV-TA.

  • Digitala tjänstekontrakt (mallar). Dessa bestämde formatet och det tillåtna innehållet på de meddelanden som skulle skickas. Tjänstekontrakten delades in i tjänstedomäner.

  • Alla parter som skall ingå i meddelandeutbytet ska inneha ett SITHS-certifikat (sigill) som gör att de säkert kan identifieras. Partens HSA-id (identitet) framgår av certifikatet.

  • En TjänsteAdresseringsKatalog, TAK. Den innehåller:

    • En tabell med logiska adresser så att meddelanden kunde hitta fram till rätt mottagare.

    • En kontrollmekanism som såg till att styra anropsbehörigheter, vem som hade rätt att skicka meddelande till en viss adress.

  • En central, nationell tjänsteplattform. Här skulle alla meddelanden passera som gick mellan olika regioner. I dess TAK finns det nationella adress- och behörighetsregisterna.

  • Regionala tjänsteplattformar i varje region. Det hanterar meddelandeflödet inom regionen, men också meddelanden till och från regionen, via den nationella tjänsteplattformen. I dessa plattformar finns en regional TAK.

  • Ett system för aggregerande tjänster (massutskick). Kopplat till detta system finns ett engagemangsindex som pekar ut vilka adresser som innehåller information för en viss individ.

  • Till detta kopplas tjänstekonsumenter (avsändare) och tjänsteproducenter (mottagare).

Administration i den digitala världen

Initialt

Det var en hel del som behövde sättas upp innan meddelandena kunde börja flöda.

  • Tjänsteplattformarna med sin TAK (adress- och behörighetsregister) behövde implementeras och driftsättas. De behövde också hämta ut SITHS-certifikat.

  • Engagemangsindex och en plattform för aggregerande tjänster sättas upp.

  • Tjänstekontrakt utvecklades. Dessa grupperades i sk tjänstedomäner (~mappar med tjänstekontrakt) för att förenkla den praktiska hanteringen.

  • De system som ska agera tjänsteproducenter måste bygga stöd för att kunna leverera information enligt tjänstekontrakten.

  • De system som ska agera tjänstekonsumenter måste bygga stöd för att kunna hämta information enligt tjänstekontrakten.

Efter hand

  • När en ny tjänsteproducent skall anslutas:

    • Hämta ut ett SITHS-certifikat.

    • Bestämma vilka logiska adresser som skall peka ut denna tjänsteproducent.

    • “TAK-a”: Beställ en producentanslutning hos “tjänsteplattformarna” (vilket innebär uppdatering av TAK-ens Adressregister). Tjänsteproducentens HSA-id i certifikatet används som nyckel i TAK-databasen.

  • När en ny tjänstekonsument skall anslutas:

    • Hämta ut ett SITHS-certifikat.

    • Erhåll godkännande att få ansluta mot tjänsteproducenternas logiska adresser. Detta kan ske på olika sätt. Ett exempel är att informationsägaren för det data som den logiska adressen pekar ut måste lämna sitt godkännande. Det kan i praktiken t ex innebära att en verksamhetschef på en vårdcentral bestämmer vilka tjänster som skall få tillhandahåll webbtidbokning för vårdcentralen i fråga.

    • “TAK-a”: Beställ en konsumentanslutning hos “tjänsteplattformarna” (vilket innebär uppdatering av TAK-ens Behörighetsregister). Tjänstekonsumentens HSA-id i certifikatet används som nyckel i TAK-databasen.

Det digitala meddelandeflödet

Själva utbytet av meddelandet följde en bestämd sekvens. Exempelvis:

  1. En läkare vill ta del av journalinformation via NPÖ. NPÖ agerar tjänstekonsument och skickar ett meddelande till en logisk adressat (i detta fall ett journalsystem) för att begära information, enligt specifikationen i ett tjänstekontrakt.

  2. Förfrågningsmeddelandet (“requesten”) populeras, och skickas till den närmaste tjänsteplattformen. Det kan vara en regional eller den nationella tjänsteplattformen. Det är adresserat med den logiska adressen till slutmottagaren. TLS används och information om tjänstekonsumentens certifikat, och HSA-id, medföljer anropet.

  3. Mottagande tjänsteplattform tar emot meddelandet och certifikatsinformationen. Därefter sker följande:

    1. Kontroll av att certifikatet är korrekt. Konsumentens HSA-id plockas fram.

    2. Kontroll i TAK-ens adressregistret av att den logiska adressen är känd för det kontrakt som används (dvs, kontraktet + adressen → mottagare).

    3. Kontroll i TAK-ens behörighetsregister av att konsumenten har rätt att skicka meddelanden baserat på aktuellt kontrakt till adressaten.

  4. Om kontrollerna ovan går bra skickas meddelandet vidare till nästa part. Om denna part är en tjänsteplattform upprepas kontrollerna.

  5. Om meddelandet lyckas passera de mellanliggande tjänsteplattformarna når det till slut tjänsteproducenten (journalsystemet). En producent kan representera många logiska adressater.

  6. Ett svar formuleras, baserat på tjänstekontraktet. Svaret skickar sedan tillbaka enligt samma väg som det anlänt.

Termer och begrepp

Vi använder en del termer och förkortningar vars betydelse inte alltid är helt uppenbar. Några av de vanligaste återfinns i tabellen nedan.

RIV-TA-baserad arkitektur

Kommentar

Brevbaserad arkitektur som jämförelse

RIV-TA-baserad arkitektur

Kommentar

Brevbaserad arkitektur som jämförelse

Aggregerande tjänst

En aggregerande tjänst anropas av en tjänstekonsument och hämtar logiska adresser i Engagemangsindex för en viss individ och informationstyp. Därefter används adresserna för att hämta informationen. Denna paketeras och returneras till tjänstekonsumenten.

Massutskick

Anropsbehörigheter i en TAK

Alla meddelanden som når tjänsteplattformen är skickade från en tjänstekonsument. Meddelandena är baserade på ett tjänstekontrakt och adresserade med en logisk adress. Behörighetstabellen i TAK är baserad på dessa två entiteter och för varje kombination av tjänstekontrakt och logisk adress finns en lista över vilka tjänstekonsumenter som har rätt att genomföra anropet. Kommer ett anrop från en tjänstekonsument som inte har behörighet kommer tjänsteplattformen att returnera ett felmeddelande.

Behörighetsförteckning

Engagemangsindex, EI

Engagemangsindex är ett nationellt index som pekar ut vilka logiska adresser som skall användas för att hämta information av en specifik typ för en enskild individ.

Engagemangsindex

HSA, HSA-id

HSA-katalogen (tidigare Hälso- och Sjukvårdens Adressregister) innehåller information om; individer, organisationer och system. Varje sådan informationsmängd identifieras av ett unikt id-begrepp; HSA-id. Detta HSA-id används som nyckelbegrepp i HSA-katalogen, men också i certifikat (individuella och för system) och som logisk adress.

Identitet

Logisk adress

Adresseringen i RIV-TA bygger på sk logiska adresser. Istället för att direkt adressera en dator med en IP-adress eller URL så används adresser som representerar en organisation (t ex en vårdenhet) eller källsystem (t ex ett journalsystem). De logiska adresserna utgörs ofta (men inte alltid) av HSA-idn. Översättning mellan logisk adress och fysisk adress (URL) sker baserat på vägvalsinformationen i TAK-en.

Adress

RIV-TA-meddelande

RIV-TA definierar standarden för hur meddelanden skall utformas. Detta detaljeras sedan av tjänstekontraktet, som exakt specificerar hur informationsinnehållet i ett fråge- (request) respektive svarsmeddelande (response) skall vara utformade.

Brev

Request

Ett meddelande som skickas från en tjänstekonsument.

Fråga, förfrågan

Response

Svaret från en tjänsteproducent som skickas (tillbaka) till tjänstekonsumenten.

Svar

SITHS-certifikat

Ett certifikat som ges ut av Ineras SITHS-förvaltning. Det innehåller bl a individens/systemets HSA-id. Alla tjänsteplattformar, tjänstekonsumenter och tjänsteproducenter måste inneha ett giltiga certifikat.

Sigill

TAK:a

Att “TAK” är ett Inera-uttryck som innebär att uppdatera tjänsteplattformens Tjänsteadresseringskatalog (TAK). Det innebär vanligen att man lägger till eller förändrar Anropsbehörigheter och/eller vägval.

Administrera adress- och behörighetsregister

Tjänsteadresseringskatalog, TAK

TAK är en databas som innehåller information om vägval (URL-er) och behörigheter. Dessa baseras i sin tur på logisk adress och vilket tjänstekontrakt som används.

Adress- och behörighetsförteckning

Tjänstedomän

En tjänstedomän är en gruppering av tjänstekontrakt. Grupperingen kan vara baserad på att kontrakten stödjer samma verksamhetsprocess (ex tidbokning, elektronisk remiss) eller hanterar relaterad information (ex resurssamordning).

Mallkategori

Tjänstekonsument

Tjänstekonsumenten är en rollbeteckning det system som initierar ett anrop (request). I normalfallet går anropet först till en tjänsteplattform och sedan vidare till en tjänsteproducent.

Rollerna säger inget om huruvida ett system konsumerar eller producerar information - en tjänstekonsument kan producera information som konsumeras av en tjänsteproducent (tyvärr).

Avsändare

Tjänstekontrakt

Tjänstekontraktet beskriver detaljerat informationsinnehållet i de request- och responsemeddelanden som utbyts mellan tjänstekonsumenter och tjänsteproducenter. Detta finns definierat i WSDL-filer och XML-scheman.

Mall

Tjänstekontraktsbeskrivning, TKB

Dokumentation för de tjänstekontrakt som ingår i en tjänstedomän. Det finns alltså en TKB per tjänstedomän.

Malldokumentation

Tjänsteplattform

En tjänsteplattform tar emot anrop från en tjänstekonsument, kontrollerar dess behörighet, översätter den logiska adressen till en URL och anropas sedan en tjänsteproducent. Svaret returneras sedan till tjänstekonsumenten. De två grundfunktionerna är alltså:

  • Kontroll av behörighet

  • Vägval

Postkontor

Tjänsteproducent

Tjänsteproducent är en rollbeteckning det system som tar emot ett anrop (requesten). I normalfallet går anropet från en tjänstekonsument först till en tjänsteplattform och sedan vidare till en tjänsteproducent.

Rollerna säger inget om huruvida ett system konsumerar eller producerar information - en tjänstekonsument kan producera information som konsumeras av en tjänsteproducent (tyvärr).

Mottagare

Transport Layer Security, TLS

Transport Layer Security (TLS), ’transportlagersäkerhet’, är ett kryptografiskt kommunikationsprotokoll som är en öppen standard för säkert utbyte av krypterad information mellan datorsystem. TLS är en vidareutveckling av version 3 av SSL-protokollet.

Rekommenderat brev

Vägval i en TAK

Alla meddelanden som når tjänsteplattformen är baserade på ett tjänstekontrakt och adresserade med en logisk adress. Vägvalstabellen i TAK är baserad på dessa två entiteter och för varje kombination finns en URL som pekar ut den tjänsteproducent som skall anropas.

Adressförteckning

Se https://inera.atlassian.net/wiki/spaces/RTA/pages/3632834 för mer formella definitioner av termer som används inom RIV-TA.