Open	RIV Tekniska Anvisningar Översikt   Version 3.0 ARK_0001 2024-09-18

1. Inledning

RIV står för Regelverk för Interoperabilitet inom Vård och omsorg och utgår från fastställda referensarkitekturer för interoperabel samverkan. RIV kompletteras med Tekniska Anvisningar (RIV-TA) som beskriver hur aktörer ska tillämpa referensarkitekturerna för att etablera interoperabel verksamhetsstödjande samverkan med hög säkerhet, god kvalitet och robusthet.

Detta dokument är en övergripande beskrivning för RIV Tekniska Anvisningar som koncept samt dess ingående delar.

RIV Tekniska Anvisningar publiceras på hemsidan http://www.rivta.se.

1.1 Målgrupp

Dokumentet riktar sig till aktörer som vill få en grundlig förståelse av RIV Tekniska anvisningar samt för motiven bakom dessa.

1.2 Syfte

Översikten syftar till att beskriva konceptuellt hur man realiserar utbytet av information mellan två parter och visar hur anvisningarna samverkar. Dessutom tydliggörs vad som kan förväntas av de tekniska profiler som utarbetas.

1.3 Tillgänglighet

Detta dokument är publicerat under licensen Creative Commons CC-BY-SA (http://creativecommons.org/licenses/by-sa/2.5/se/ ).

Det betyder att du fritt får kopiera, distribuera och skapa bearbetningar av anvisningarna under förutsättning att upphovsmannen Sveriges Kommuner och Regioner anges, men inte på ett sätt som antyder att de godkänt eller rekommenderar din användning av verket.

1.4 Förvaltning

Utveckling och förvaltning av RIV-TA och dess delar/dokument sker genom att förändringsbehov och/eller förslag skickas in till Inera via e-post till kundservice@inera.se. Ange "RIVTA: Anvisningens namn"" i ämnesraden.

2. Anvisningarna i sitt sammanhang

RIV Tekniska Anvisningar (RIV-TA) är en samling dokument med regler, instruktioner och vägledning. Det är uppdelade för att beskriva en viss aspekt eller ett visst område av interoperabel samverkan.

RIV-TA beskriver hur nationell samverkan inom svensk kommunal och regional sektor realiseras enligt fastställda referensarkitekturer som till exempel Referensarkitektur för vård och omsorg - T-boken och Referensarkitektur för identitet och åtkomst.

RIV-TA bygger i stor utsträckning på etablerade öppna standarder.

Sveriges kommuners och regioners förvaltningsgemensamma och lokala realiseringar av infrastrukturella komponenter som möjliggör nationell samverkan enligt T-bokens mönster ska vara följsamma mot tillämpliga delar av RIV-TA.

Open

Anvisningarna i sitt sammanhang

3. Terminologi

Detta avsnitt beskriver termer som används genomgående i RIV Tekniska Anvisningar.

3.1 Termer för tjänsteinteraktioner

Följande uppställning beskriver de olika tjänsteinteraktionstyperna och hur de visualiseras i anvisningarna:

3.2 Termer för samverkansmönster

Figurerna nedan visar de mest centrala termerna för några olika samverkansmönster.

Direktsamverkan

Samverkan via tjänsteplattform

Samverkan via aggregerande tjänst

Aggregerande tjänster exekveras inom ramen för någon form av aggregeringsplattform. De använder sig av någon form av informationslokalisering, till exempel via ett engagemangsindex för att få information om vilka tjänsteproducenter som skall anropas. Anropen kan sedan ske via en tjänsteplattform eller direkt till tjänsteproducenten.

4. Övergripande krav på informationsutbyte

Här redovisas de övergripande kraven som gäller oavsett vilken teknisk standard som en viss realisering bygger på.

4.1 Logisk adressering

T-boken beskriver en abstrakt modell för adressering där tjänstekonsumenten i ett meddelandeutbyte ska adressera en tjänsteproducent med en logisk adress. Logiska adresser översätts alltid till tekniska anslutningsadresser genom uppslag i en adresskälla.

Detta gäller i alla led - alltså även vid federerade arkitekturer där en virtuell tjänst i en tjänsteplattform dirigerar ett anrop till en tjänsteproducent som i själva verket visar sig vara en virtuell tjänst i en annan tjänsteplattform. Adresseringen i en tjänsteplattform riktas alltid till ”nästa” system nedströms, dvs tjänsteproducenten ur tjänsteplattformens perspektiv. Den logiska adressen vidarebefordras alltid för potentiell användning hos mottagande system.

Interoperabilitesspecifikationerna detaljerar reglerna för hur den logiska adressen ska deklareras i en tjänsteinteraktion. Antingen direkt eller genom att peka ut en basprofil.

• I RIVTA Basic Profile 2.1 deklareras logisk adress i tjänsteinteraktionens WSDL i form av SOAP-header. Se separat anvisning för detaljer

• Andra interoperabilitesspecifikationer eller basprofiler kan peka på annan användning.

T-bokens adresseringsmodell är kärnan i den nationella referensarkitekturen. Det är därför viktigt att ha grundlig förståelse för dess ändamål. Den är designad med utgångspunkt i att systemstrukturen inom vård och omsorg är distribuerad, med federativt ägarskap. Det betyder att många organisationer länkas samman med varandra, men var och en ansvarar för sin del.

Inom vård och omsorg finns en uppsättning typfall för hur man adresserar digitala tjänster. I samtliga fall är adresseringsmodellens syfte att bidra till lös koppling mellan tjänstekonsument och tjänsteproducent. Logisk adressering kan realiseras på olika sätt, till exempel inbyggt i en tjänsteplattform eller som en fristående tjänst för adressuppslag.

Adresseringsmodellen säkerställer tillsammans med tjänsteadresseringskatalogen att alla parter i arkitekturen kan uttrycka vem som är mottagare av ett meddelande utan att behöva ha kunskap om mottagarens realisering. Detta görs genom att man med hjälp av den logiska adressen hämtar tjänsteproducentens tekniska anslutningsadress via ett adressuppslag i tjänsteadresseringskatalogen. En verksamhet kan därmed förändra sin realisering utan att detta påverkar logiska adresser och därmed tjänstekonsumenter. Det enda som behöver uppdateras är den tekniska anslutningsadressen i tjänsteadresseringskatalogen.

Den logiska adressen kan representeras av en textsträng, OID eller liknande. Hur en logisk adress ska uttryckas bestäms i en interoperabilitetsspecifikation och kan därmed variera mellan olika standarder.

I praktisk tillämpning finns det fördelar med att använda identifierare från en gemensam källa, som till exempel HSA-katalogen, som logisk adress både för att säkerställa unicitet men också för att göra det enklare att spåra organisatorisk tillhörighet för den logiska adressen. Vid verksamhetsadressering så kan användning av organisationsidentifierare på rätt nivå också underlätta samverkan med utbudskataloger och dylikt. Därför används HSA-id i nedanstående exempel.

Observera att användningen av HSA-id som logisk adress inte i sig ställer krav på att det finns ett funktionscertifikat enligt SITHS-modellen för att styrka producentens serveridentitet under adressering och anrop. System och organisationsenheter kan registreras i HSA-katalogen utan att det finns krav på att det skapas SITHS certifikat.

Den logiska adressen representerar normalt ett av dessa koncept:

• Verksamhet/organisation

• Ett källsystem

4.1.1 Verksamhetsbaserad adressering

Vid verksamhetsbaserad adressering representerar den logiska adressen en organisation eller verksamhet. Det är vanligen en vårdgivare eller vårdenhet men även andra, som t ex myndigheter, förekommer. Vilka värden som används som logiska adresser definieras av en interoperabilitetsspecifikation. Den logiska adressen utgörs i denna modell av en organisatorisk identifierare. Typiskt används organisationens HSA-id som adress men även organisationsnummer kan användas då båda dessa uppfyller kraven på unicitet och spårbarhet.

Exempel på logisk adressering i en interaktion utformad enligt Basic Profile 2.1:

En tjänstekonsument vill boka en tid hos en viss vårdenhet och använder dess organisatoriska adress (SE1112) som logisk adress. Den logiska adressen används för att slå upp den tekniska anslutningsadressen (URL:en) för det källsystem (p1.region1.se) som betjänar den logiska adressen. Därefter anropas källsystemet med den tekniska adressen som URL. Den logiska adressen (SE1112) skickas med som en del i anropet via SOAP-headern LogicalAddress så att källsystemet vet vilken logisk adress som anropet avser.

Som framgår ovan så är p1.region1.se ett källsystem men adresseringen av anropet sker med den logiska adressen (HSA-id) för verksamheten eftersom det är denna som är känd utifrån ett verksamhetsperspektiv.

4.1.2 Källsystemsbaserad adressering

Den logiska adressen representerar ett källsystem. I exemplet nedan används det HSA-id som adresserar systemet som logisk adress. Att HSA-id används är dels för spårbarhet, dels för att underlätta att skapa unika adresser.

Observera att det alltså är källsystemet som pekas ut i den logiska adressen, inte nödvändigtvis tjänsteproducenten (även om det kan vara samma system). På detta sätt uppnås en högre grad av lös koppling än om systemet skulle adresseras direkt med en URL eller IP-adress.

Ett källsystem innehåller i normalfallet information som härrör från många verksamheter. Denna adresseringsmodell ger därför möjlighet att hämta information som härrör från flera verksamheter i en interaktion och utan att behöva ange verksamheternas identiteter explicit. Adresseringsmodellen har införts främst som ett sätt att avlasta källsystem och integrationsinfrastrukturen vid aggregering.

Tabellen nedan visar när källsystembaserad adressering kan användas, samt hur tjänstekonsumenten erhåller den logiska adressen.

Tabell 2 Exempel på användande av källsystemsbaserad adressering

4.1.3 Val av adresseringsmetod

Den som ansvarar för utvecklingen av en interoperabilitetsspecifikation behöver fundera över vad som är den mest lämpade adresseringsmetoden vid olika situationer.

Det är tillämpningen och datalandskapet som är mest avgörande för valet så det kan inte uteslutas att olika tillämpningar kan behöva använda olika adresseringsmetoder även inom samma domän. Val av adresseringsmetod(er) framgår av interoperabilitetsspecifikationen.

Observera att samma tjänsteproducent kan adresseras på olika sätt vid olika tillfällen. En aggregerande tjänst som adresseras via en verksamhetsbaserad logisk adress kan i nästa steg adressera tjänsteproducenter via källsystemsadresser.

Rekommendation källsystemsadressering

Källsystemsadressering kan vara lämpligt i situationer där man behöver lokalisera och hämta information utan att man har kännedom på förhand om inom vilken/vilka organisationer som informationen existerar. I dessa situationer används ofta aggregerande tjänster som baserar sig på index för lokaliseringen och då kan källsystemsadressering underlätta både hanteringen av indexinformationen och anropsmönstret till källsystemen.

Motiv

1. Administrationen i TAK minskar eftersom adresseringsinformation enbart registreras per källsystem och tjänstekontrakt i stället för att registreras per vårdenhet (om vårdenhet är verksamhetsbegreppet) och tjänstekontrakt.

2. Belastningen på tjänsteproducenten minskar eftersom aggregerande tjänster bara behöver göra ett anrop per källsystem istället för ett anrop per vårdenhet. För en kroniker kan det över en tioårsperiod finnas information på 20-30 olika vårdenheter, varav många kan hanteras i samma system. Det blir då 1-2 anrop per informationsmängd istället för 20-30.

3. Om man skulle ha verksamhetsbaserad adressering för journalinformation innebär det att varje index-post i Engagemangsindex är märkt med vårdenhet. Kopplingen mellan vårdenhet och organisatorisk enhet ändras löpande i journalsystemen. Vid varje sådan ändring påverkas ett stort antal befintliga patienter, i det att deras journaluppgifter byter vårdenhet. En konsekvens av det är att alla indexposter i Engagemangsindex som refererar patienter/informationsmängder som mappats om behöver uppdateras i en stor batch. Det är komplext och prestandamässigt svårt att hantera för journalsystemens Engagemangsindexanslutningar.

4. Antalet poster i Engagemangsindex blir mindre eftersom det endast blir en post per källsystem, patient och informationstyp i stället för en post per enhet, patient och informationstyp.

Konsekvenser för tjänsteproducenter

Om ett källsystem adresseras direkt, med källsystemsbaserad adressering, ska det kontrollera om det behöver avgränsa/filtrera svaret utifrån parametrar i begäran. Exempel på avgränsning är vårdenhet eller vårdgivare.

Om systemet stödjer flera logiska adresser så ska det alltid kontrollera vilken logiska adress som används vid anropet och anpassa svaret utifrån den logiska adressen.

Rekommendation verksamhetsadressering

Verksamhetsadressering lämpar sig väl för informationshantering där kontexten för anropet huvudsakligen utgörs av en viss verksamhet.

Motiv

Styrande princip IT4: Lös koppling i T-boken (Referensarkitektur för vård och omsorg - T-boken). Verksamhetsbaserade logiska adresser innebär en lösare koppling mellan tjänstekomponenterna. Tjänstekonsumenten får inget beroende till systemstrukturen hos anropad verksamhet.

Konsekvenser för tjänsteproducenter

Om den logiska adressen är en verksamhetsadress ska filtrering av returnerad information göras på information tillhörande den adresserade verksamheten. Filtrering ska alltid ske både baserat på den logiska adressen och på eventuella parametrar i anropets meddelande.

4.2 Anropsbehörighet

En tjänstekonsuments behörighet att anropa en tjänsteproducent kan regleras på flera nivåer, och på flera platser i infrastrukturen. Grunden är att en tjänstekonsuments möjlighet att använda en viss tjänst kräver att en grundläggande tillit etablerats till organisationen som ansvarar för tjänstekonsumenten.

4.2.1 Organisationstillit

Organisationstillit innebär att lita på att den samverkande parten är en relevant aktör samt har förmåga att hantera den information som delas enligt gällande lagar och informationsklassificering. Kraven på organisatoriska tillitsskapande förmågor regleras av lagar, avtal eller andra överenskommelser och regelverk. Detta benäms ofta som tillramverk.

1. Affärsmässiga - finns offentligt finansierat uppdrag? Är man registrerad vårdgivare hos IVO? Har man relevanta försäkringar (exempelvis patientförsäkring och ansvarsförsäkring)

2. Informationssäkerhetsmässiga - besitter organisationen adekvat nivå av tillitsskapande förmågor genom certifiering gentemot ISO27001 eller motsvarande?

3. Kvalitetsmässiga - Besitter organisationen förmågor inom kvalitetssäkringsområdet för att kunna uppfylla gemensamt överenskomna kvalitetskrav?

För ytterligare resonemang kring tillit mellan organisationer se T-Boken, IT6: Samverkan i federation. (kapitel 4.6 i revision D)

4.2.2 Delegerad åtkomsthantering baserad på organisationstillit

Organisationstillit innebär att man har tillit till andra parter och därför delegerar ansvar för behörighetsbeslut och spårbarhetsloggning för informationsbehandlingen till den part informationen delas med. Varje organisation ansvarar för att de egna systemen är korrekta i sin funktion och har adekvata skyddsmekanismer. Vid samverkan som baseras på organisationstillit förutsätter man att respektive part säkerställer att:

• Överförd information är korrekt.

• Information hanteras på ett säkert sätt och att obehöriga parter vare sig kan ta del av eller manipulera information.

• Information endast behandlas i överenskommet syfte och följsamt mot gällande lagstiftning, ingångna avtal och policyer.

4.2.3 Etablerade tillitskedjor

Ett digitalt informationsutbyte kan involvera en kedja av aktörer och tillit till informationsutbytet i sin helhet kräver förtroende för varje enskild aktörs tillitsskapande förmågor. Tillit uppnås genom att tillitsramverket stipulerar regelverk för varje aktörstyp samt adekvata mekanismer för att säkerställa följsamhet och att dessa upprätthålls över tid.

Tilliten i samverkan är transitiv. Transitiv innebär i den här kontexten att beslutet om att vidarebefordra ett visst anrop från ett tjänstekonsumerande system till en viss logisk adressat inte tar hänsyn till vad som döljer sig bakom det tjänstekonsumerande systemet eller hur den logiska adressatens tjänsteproducerande system är realiserat.

Varje tjänstekonsumerande part i kedjan ansvarar för att säkerställa:

1. Att behörighetsgrundande information tillgängliggörs i anropet

2. Att kommunikation skyddas av TLS.

3. Att tjänsteproducerande är en part som man har tillit till.

Varje tjänsteproducerande part i kedjan ansvarar för att säkerställa:

1. Att tjänstekonsumentens identitet är giltig och utgiven av en betrodd identitetsutgivare.

2. Att tjänstekonsumerande part är en part som man har tillit till.

3. Att behörighetsgrundande information finns att tillgå.

4. Att beslut om åtkomst kan fattas följsamt mot gällande lag och ingångna avtal.

4.2.4 Realisering av åtkomsthantering

Tjänsteproducenten kan fastställa tjänstekonsumentens rätt att anropa baserat på ett flertal olika typer av åtkomststyrande information

• Information i klientcertifikat.

• Information i kuverteringens headrar enligt proprietärt format.

• Åtkomstintyg, exempelvis enligt OAuth 2

• http headrar

Olika standarder kan använda olika metoder och att det är interoperabilitetsspecifikationen som definierar vad som ska användas, antingen direkt, eller genom att peka ut en RIV-profil eller liknade.

Åtkomsthanteringen utförs för att kontrollera att tjänstekonsument har rätt att använda tjänsten samt vilka behörigheter som konsumenten har. Detta realiseras i regel genom att utvärdera tjänstekonsumentens behörighetsgrundande information mot tjänstens åtkomstpolicy.

Se Referensarkitektur - Identitet och åtkomst för detaljer.

4.2.5 Informationsbehörighet

Även om en tjänstekonsument har åtkomst till en tjänsteproducent betyder inte det att man är behörig att ta del av all information som matchar en förfrågan. Det kan finnas lokalt implementerade regelverk och policyer som begränsar vad som delas. Denna typ av filtrering som sker vid behandlingen av en förfrågan ska resultera i exkludering av informationsposter och avgör vilken information som returneras.