RIV Tekniska Anvisningar Tjänsteplattform





RIV Tekniska Anvisningar Tjänsteplattform



Version 1.8.1

ARK_0034

2022-02-23






Versionshistorik

Version

Revision

Datum

Författare

Kommentar

PA1



Mattias Nordvall

Första utkast

PA2



Mattias Nordvall

Uppdaterat efter intern remiss

PA3



Lars Erik Röjerås

Justeringar efter genomläsning

1.0



Mattias Nordvall

Dokumentets underrubrik är nu ”Tekniska krav” istället för ”Regler för interoperabilitet”.

Lagt till kapitel med definition av termer.

Tagit bort texter om reverse proxy (betraktas som implementationsdetalj).

Lagt till felkoder för virtualiseringsplattform.

Tagit bort regel om loggning av förändringar av TAK-information (inte ett tekniskt krav).

Tagit bort skrivning om godkännande av tjänstekontrakt i 3.1.1 (inte ett tekniskt krav).

Ändrat regel om uppbyggnad av URL:er till att enbart beskriva slutet på adresserna (det enda som är reglerat i RIV TA).

Förtydligat att anropsbehörighet i TAK avser närmast anropande tjänstekonsument.

Kapitlet om TAK använde begreppet ”logisk adress” om två olika saker.

Lagt till översiktligt kapitel om Tjänsteväxel.

Korrigerat ordval och stavfel.

Uppdaterade illustrationer.

1.0.1



Mattias Nordvall

Korrigerat vissa formuleringar och illustrationer.

Nytt stycke om förhållandet mellan nationella och regionala tjänsteplattformar.

1.1



Mattias Nordvall

Kapitlet om anpassningsplattform och tjänsteväxel omskrivet och felaktigheter korrigerade.

Regel ”Exponering av URL:er” i kapitel 4 korrigerad för att överensstämma med underliggande regelverk.

Exempel från den senaste versionen av RIV-TA Basic Profile, t.ex. SOAP Headers, är ändrade till mer generella begrepp

1.2



Mattias Nordvall

Lagt till regler i kapitel 4 från RIV TA Basic Profile 2.0. Dessa regler behöver följas av tjänsteplattformar.

Lagt till Regel #6 under kapitlet Aggregeringsplattform.

1.3



Mattias Nordvall

Uppdaterat Regel #6 under kapitlet Aggregeringsplattform.

1.4

2017-12-07

Björn Hedman

Lagt till information om adressering baserat på TAK och organisationsdata "HSA klättring"

Under rubrik 4.2.6 har görs hänvisning till Basic Profile istället för att beskriva och exemplifiera i detta dokument

Rättat numrering av regler under kapitel 5.1 (Virtualiseringsplattform) felet uppstod mellan version 1.0 och 1.1 (några regler utgick i 1.1)

Tagit bort hänvisning till fallstudie för "Regional tjänsteplattform, Landstinget Dalarna" eftersom länken var bruten.

1.5

2018-08-27

Lars Erik Röjerås

Reglerna 2 och 4 har utökats med beskrivning av HSA-baserat vägval och anropsbehörighet samt användning av "*".

1.6

2021-03-12

Anders Malmros

Tagit bort Mule-referens i 1.4 Fallstudier.

Uppdateringar och tillägg under kapitel 5 Virtualiseringsplattform:

  1. Regel #8, Felkoder, uppdaterad.

  2. Reglerna #9 och #10 flyttade hit från RIVTA Basic Profile Valfria tillägg 2.1.

  3. Regel #11, Vidarebefordran av anropskedja, tillagd.

  4. Regel #12, Skydd mot rundgång, tillagd.

  5. Regel #13, Vidarebefordran av RIV-headrar, tillagd.

1.7

2021-06-28

Anders Malmros

Rättat fel i regel #12. Felkod VP014 skall användas vid rundgång, inte VP013

1.8

2022-01-25

Anders Malmros

Lagt till ny felkod VP015 i regel #8, Felkoder

1.8.1

2022-02-23

Anders Malmros

Rättat felaktiga referenser till RIVTA Basic Profile Valfria tillägg 2.1 i kapitel 4.2.3 och 4.2.4

1. Inledning

Hälso- och sjukvårdssektorn i Sverige har på uppdrag av Sveriges Kommuner och Landsting och under ledning av CeHis, nuvarande Inera, gemensamt tagit fram en nationell teknisk arkitektur i syfte att stödja samarbete över organisationsgränserna.

Enligt det övergripande arkitekturdokumentet, T-boken, är en tjänsteplattform en samling komponenter som används för tjänstebaserad kommunikation över huvudmannagränser. En tjänsteplattform agerar kontaktpunkt för anslutningar till och från andra organisationer.

Inera AB har utvecklat en tjänsteplattform kallad SKLTP, som är baserad på öppna programvaror. SKLTP används av den nationella tjänsteplattformen, och är även fritt tillgänglig att användas regionalt.

Tjänsteplattformar kan dock realiseras med valfri programvara såvida reglerna i detta dokument kan uppfyllas.


Tjänsteplattform med ingående komponenter. Vissa komponenter är valfria.

1.1 Syfte

Syftet med dokumentet är att underlätta utvecklings- och valideringsinsatser genom att samla de krav och regler som ställs på en tjänsteplattform.

1.2 Målgrupp

Målgruppen för detta dokument är tekniska arkitekter och utvecklare som ska realisera en tjänsteplattform enligt T-boken och RIV Tekniska Anvisningar.

1.3 Avgränsningar

Denna anvisning beskriver enbart tekniska regler. Därmed utelämnas ämnen som t.ex. godkännandeprocess kring tjänstekontrakt och krav på loggning.

1.4 Fallstudier

Det har gjorts ett antal implementationer av tjänsteplattformar av den typ som beskrivs i detta dokument. Genom att studera dessa kan kompletterande information fås kring hur reglerna i detta dokument har tolkats och realiserats.

Det finns en referensimplementation SKL TP (http://skltp.se/).

1.5   Referenser

Ref

Dokument

Beskrivning

[R1]     

T-boken

Referensarkitektur för vård och omsorg

http://rivta.se/documents/ARK_0019

[R2]     

RIV Tekniska Anvisningar – Översikt

http://rivta.se/documents/ARK_0001

[R3]     

RIV Tekniska Anvisningar – Basic Profile

RIV-TA:s tillägg till WS-I Basic Profile

http://rivta.se/documents/ARK_0002

[R4]     

RIV Tekniska Anvisningar – Basic Profile – Valfria Tillägg 2.1

http://rivta.se/documents/ARK_0028

[R5]     

RIV Tekniska Anvisningar – Tjänsteschema

Beskrivning av schema-filer för tjänstekontrakt.

http://rivta.se/documents/ARK_0005

[R6]     

Tjänstekontrakts-beskrivning Engagemangsindex

Beskrivning av tjänstekontrakt i domänen itintegration:engegementindex.

http://rivta.se/domains/itintegration_engagementindex.html

[R7]     

WS-I Basic Profile 1.1

En specifikation på protokollanvändning i syfte att kunna implementera interoperabla webbtjänster.

http://www.ws-i.org/Profiles/BasicProfile-1.1.html

[R8]     

Tjänstekontrakts-beskrivning Tjänsteadressering

Beskrivning av tjänstekontrakt i domänen infrastructure:itintegration:registry.

http://rivta.se/domains/infrastructure_itintegration_registry.html

[R9]

Användarhandledning adressering med HSA information

Beskrivning av hur organisationsdata (från HSA) kan användas för logisk adressering

http://rivta.se/documents/ARK_0043

2. Terminologi

Följande termer förekommer i dokumentet.

Term

Definition

Tjänstekonsument

En tjänstekonsument är en tjänstekomponent (informationssystem) där agerandet leder till ett automatiskt informationsutbyte med andra tjänstekomponenter (exempelvis tjänsteproducenter).

En tjänstekonsument kan t ex vara en eTjänst, ett verksamhetssystem, en partneringång eller en tjänsteplattform. Tjänstekonsumenten agerar som initiativtagare i ett informationsutbyte.

Tjänsteproducent

En tjänsteproducent är en tjänstekomponent som har ett tekniskt gränssnitt som möjliggör för tjänstekonsumenter att genom meddelanden förändra eller begära information.

Tjänstekomponent

Avgränsad mängd programvara som kan utvecklas, integreras, testas, driftsättas och förvaltas fristående.

Tjänstekontrakt

Specifikation som beskriver ett nationellt standardiserat gränssnitt som förekommer mellan tjänstekomponenter i en tjänsteorienterad arkitektur.

Tjänstedomän

En enligt VIFO-kartan övergripande, verksamhetsbaserad indelningsgrund för nationellt standardiserade tjänsteinteraktioner.

Tjänsteinteraktion

Informationsutbyte mellan tjänstekomponenter baserat på tjänstekontrakt.

3. Allmänt

3.1 Regelverk

Följande regelverk ställer krav på tjänsteplattformar:

3.1.1 T-boken

T-boken beskriver en referensarkitektur samt definierar styrande principer. Dessa syftar till att all utveckling av e-tjänster ska sträva mot samma mål och uppfylla de långsiktiga behoven. T-boken ger också motiv till de arkitekturella mönster som har valts. Se [R1].

3.1.2     RIV Tekniska Anvisningar

RIV Tekniska Anvisningar är den tekniska realiseringen av de koncept som beskrivs i T-boken. Här definieras t.ex. RIV TA Basic Profile (förkortat RIV TA BP), som anger hur den tekniska kommunikationen mellan tjänstekomponenter ska gå till. RIV TA BP baseras på WS-I Basic Profile, som i sin tur bygger på SOAP. Se [R7].

3.2 Nationella och regionala och tjänsteplattformar

Tjänsteplattformar förekommer dels i en nationell instans, men även hos regionala aktörer inom hälso- och sjukvårdssektorn. Oavsett vilket, skall tjänsteplattformarna tillämpa de regler som beskrivs i detta dokument.

Tjänstekomponenter ansluts till någon av dessa tjänsteplattformar. Därefter styr tjänsteplattformarnas vägvalsinformation och anropsbehörigheter åtkomsten mellan tjänstekomponenterna.


Tjänstekonsumenter skickar alltid sina meddelanden till den tjänsteplattform tjänstekonsumenten är ansluten till. Meddelandena är adresserade med mottagarens logiska adress.

Såvida den adresserade tjänsteproducenten förekommer i den anropade tjänsteplattformens tjänsteadresseringskatalog, vidarebefordrar tjänsteplattformen meddelandet, antingen direkt till tjänsteproducenten, eller till den tjänsteplattform som tjänsteproducenten är ansluten till.

Observera att anrop direkt mellan regionala tjänsteplattformar inte får förekomma. Anrop mellan tjänstekomponenter anslutna till olika tjänsteplattformar skall alltid ske via den nationella tjänsteplattformen.

4. RIV Tekniska Anvisningar

RIV Tekniska Anvisningar (RIV TA) är en samling specifikationer på hur elektronisk information ska utbytas för att kunna tolkas av tjänstekomponenter byggda på olika mjukvaruplattformar.

Syftet med detta kapitel är att ge en sammanfattning av de regler från RIV TA som berör tjänsteplattformar, samt att hänvisa till de dokument där reglerna har sina gällande formuleringar. En tjänsteplattform behöver i dagsläget stödja RIV TA Basic Profile version 2.0 och 2.1.

Då RIVTA Basic Profile 2.0 är en äldre version finns dess dokumentation inte publicerad på rivta.se. Kontakta arkitektur@inera.se vid behov av denna dokumentation.

4.1 Information

4.1.1 Användning av tjänstekontrakt

Allt meddelandeutbyte ska baseras på tjänstekontrakt, som utformats enligt gällande versioner av RIV TA.

4.2 Kommunikation

Följande regler gäller för all kommunikation mellan tjänstekomponenter, inklusive tjänsteplattformars delkomponenter, om inte annat nämns.

4.2.1 Transportprotokoll

Tjänstekomponenter skall skicka och ta emot anrop över HTTPS, om inte annat anges i regelverk för specifika tjänstekomponenter.

Källa: RIVTA Basic Profile 2.0 och 2.1 [R3] Regel #6

4.2.2 Autentisering

HTTPS-sessioner skall autentiseras med hjälp av HTTPS Mutual Authentication. Det innebär att båda parter autentiserar varandra med hjälp av certifikat.

Tjänstekonsumentens identitet fastställs utifrån attributet SerialNumber i dess certifikat. Certifikat utgivna av SITHS är utformade på detta sätt.

Källa: RIVTA Basic Profile 2.0 och 2.1 [R3] Regel #6

4.2.3 Bevara ursprunglig avsändares identitet i http header

Efter att autentisering skett enligt ovan, och aktuell förfrågan INTE innehåller http header x-rivta-original-serviceconsumer-hsaid, skall tjänsteplattformen infoga denna http header i utgående anrop och sätta värdet till anropande tjänstekonsuments identitet.

Detta görs för att nästa komponent i kedjan inte kommer att kunna läsa ursprungsavsändarens certifikat.

Källa: RIVTA Basic Profile 2.1 [R3] Regel #23

Detta regleras inte i RIVTA Basic Profile 2.0.

4.2.4 Vidarebefordran av http header

Om ett inkommande anrop kommer från en tjänsteplattform och innehåller http header x-rivta-original-serviceconsumer-hsaid så ska denna http header skickas vidare oförändrad, förutsatt att anropet kommer från en tjänsteplattform som betraktas som känd. Detta kan fastställas t.ex. genom att hålla en lista på betrodda tjänsteplattformars ip-adresser eller funktionscertifikat.

Källa: RIVTA Basic Profile 2.1 [R3] Regel #23

Detta regleras inte i RIVTA Basic Profile 2.0.

4.2.5 Logisk adressering

Alla tjänstekomponenter skall förutsätta att inkommande meddelanden har en specificerad mottagare i form av en logisk adress. Den logiska adressen återfinns i en SOAP Header med följande namn:

Källa: RIVTA Basic Profile 2.0 och 2.1 [R3] Regel #8

4.2.6 Exponering av URL:er

Tjänsteproducenter och tjänsteplattformar skall exponera URL:er enligt reglerna i RIVTA Basic Profile 2.1 [R3] Regel #19.

Detta regleras inte i RIVTA Basic Profile 2.0.

4.2.7 Tekniska fel

I de fall där en tjänstekomponent behöver generera ett felmeddelande som beskriver ett tekniskt fel, skall detta göras med hjälp av SOAP Faults. Detta till skillnad från logiska fel, som ska kommuniceras med vanliga svarsmeddelanden och definieras i respektive tjänstekontraktsbeskrivning.

Källa: RIVTA Tjänsteschema 2.1 [R5] Regel #11

Detta regleras inte i RIVTA Tjänsteschema 2.0.

5. Virtualiseringsplattform

Virtualiseringsplattformen agerar som en ställföreträdare för alla tjänsteproducenter som implementerat ett tjänstekontrakt och anslutit till aktuell tjänsteplattform. Den uppträder som om det enbart fanns en tjänsteproducent, men dirigerar frågemeddelanden vidare till de faktiska tjänsteproducenterna och förmedlar svarsmeddelandet i retur.

En virtualiseringsplattform behöver kunna stödja flera olika RIV TA-profiler. Dessa profiler kan ha olika regler för hur t.ex. meddelandens logiska adress förmedlas (se kap. 4 för information om den senaste versionen).

Virtualiseringsplattformen har tillkommit för att uppfylla T-bokens arkitekturella princip om lös koppling mellan tjänstekonsumenter och -producenter.

Regel #1: Datakommunikation

Virtualiseringsplattformen skall följa alla kommunikationsregler i aktuella RIV TA-profiler.

Regel #2: Åtkomstkontroll

Virtualiseringsplattformen skall ha möjlighet att vid inkommande anrop kontrollera åtkomstbehörigheten för kombinationen av följande:

  • Anslutande tjänstekonsument (kan vara en annan tjänsteplattform)

  • meddelandets logiska mottagaradress

  • anropat tjänstekontrakt

Åtkomstbesluten skall baseras på information som lagras i tjänsteadresseringskatalogen. Om åtkomst inte tillåts skall den inkommande förfrågan inte vidarebefordras. Istället skall ett felmeddelande returneras, enligt aktuell RIV TA-profil.

Källa: [R2] Kapitel 8.5

Deaktiverad åtkomstkontroll. Om den logiska adressen "*" ingår i definitionen av en åtkomstbehörighet för tjänstekonsument i en tjänsteplattforms tjänsteadresseringskatalog innebär det att kontrollen skall deaktiveras för aktuellt tjänstekontrakt och tjänstekonsument, och att tjänstekonsumenten ska ha behörighet att anropa oberoende av den logiska adressen i själva meddelandet. 

Åtkomstkontroll via hierarkisk organisationsinformation. De logiska adresserna består i de flesta fall av ett HSA-id som representerar en verksamhet eller organisation (källsystemsbaserade logiska adresser berörs inte av denna metod för åtkomstkontroll). Genom att tillföra information till VP om det hierarkiska sambanden mellan logiska adresser (ex via en fil över organisationsträdet i HSA) skapas möjligheten att utföra åtkomstkontroll via en överliggande adress i hierarkin. I de fall där kontrollen av åtkomstkontroll för explicit angiven logisk adress misslyckas så hämtar VP närmast överliggande logiska adress i hierarkin och prövar om den har åtkomstbehörighet. Denna klättring och försök fortsätter tills endera:

  1. En åtkomstbehörighet hittas - vilket innebär att anropet får åtkomstbehörighet

  2. Toppen nås i organisationsträdet (utan att åtkomstbehörighet har tilldelats)

Roten i organisationshierarkin består definitionsmässigt av den logiska adressen "SE". Se mer information i separat dokumentation kring modellen  [R9].

Källa: [R2] Kapitel 8.7 

Regel #3: Utgått

Regel #4: Vägval för anrop

För att kunna vidarebefordra inkommande meddelanden till rätt tjänsteproducent, behöver virtualiseringsplattformen kunna slå upp den tekniska adress som meddelandet ska vidarebefordras till. Denna information tas fram ur den information som är registrerad i tjänsteadresseringskatalogen utifrån följande kriterier:

  • meddelandets logiska mottagaradress

  • anropat tjänstekontrakt, inkl. tjänstedomän och kontraktets huvudversion

  • anropad RIVTA-profilversion

Vägval via hierarkisk organisationsinformation.  De logiska adresserna består i de flesta fall av ett HSA-id som representerar en verksamhet eller organisation (källsystemsbaserade logiska adresser berörs inte av denna metod för åtkomstkontroll). Genom att tillföra information till VP om det hierarkiska sambanden mellan logiska adresser (ex via en fil över organisationsträdet i HSA) skapas möjligheten att definiera vägval via en överliggande adress i hierarkin. I de fall där inget explicit vägval hittas så hämtar VP närmast överliggande logiska adress i hierarkin och prövar om den har vägval definierat. Denna klättring och försök fortsätter till endera:

  1. Ett vägval hittas - vilket innebär att detta vägval används för aktuellt meddelande

  2. Toppen i hierarkin nås utan att ett vägval hittats - kontroll ska då ske om ett standardval är definierat, se nedan.

Roten i organisationshierarkin består definitionsmässigt av den logiska adressen "SE". Se mer information i separat dokumentation kring modellen  [R9].

Standardval. Om den logiska adressen asterisk ("*") ingår i definition av ett vägval så innebär det att detta vägval är standardval (default) för tjänstekontraktet. Om den logiska adressen i en begäran inte återfinns i något vägval enligt metoderna ovan skall vägvalet med logisk adress "*" användas (om ett sådant finns). 

Källa: [R2] Kapitel 8.6

Regel #5: Vidarebefordran av anrop

Virtualiseringsplattformen skall, såvida autentisering, åtkomstkontroll, vägval och övrig validering lyckats, skicka tjänstekonsumentens meddelande vidare till tjänsteproducenten. Svarsmeddelandet från tjänsteproducenten, oavsett om det är ett ordinarie svar eller ett felmeddelande, skall därefter returneras till tjänstekonsumenten.

Regel #6: Översättning mellan RIV-TA versioner

Virtualiseringsplattformen skall kunna översätta inkommande anrop från en version av RIV-TA till en annan. Skillnader mellan RIV TA-versioner kan t.ex. gälla utformning av SOAP-meddelanden eller säkerhetsmekanismer och kan utläsas i dokumentationen för respektive version.

Regel #7 Utgått

Regel #8: Felkoder

Virtualiseringsplattformen skall returnera felmeddelanden enligt respektive RIV TA-profil som HTTP 500 med SOAP Fault, med felkoder och felsträng enligt tabellen nedan. SOAP Fault-elementet detail används för att inkludera ytterligare felinformation så som spårningsinformation eller ytterligare detaljer kring det inträffade felet.

Fault code *

Fault string *

Fault code *

Fault string *

soap:Client

VP001 [namn tjänsteplattform] Rivta-version saknas i anrop eller stöds ej av tjänsteplattformen.

soap:Client

VP002 [namn tjänsteplattform] Fel i klientcertifikat. Saknas, är av felaktig typ, eller är felaktigt utformad.

soap:Client

VP003 [namn tjänsteplattform] Logisk adressat (ReceiverId) saknas i RivHeadern i inkommande meddelande.

soap:Client

VP004 [namn tjänsteplattform] Det finns inget vägval i tjänsteadresseringskatalogen som matchar anropets logiska adressat (ReceiverId) och tjänstekontrakt. Kontrollera uppgifterna i anropet och vid behov, beställ konfigurering i aktuell tjänsteplattform.

soap:Client

VP005 [namn tjänsteplattform] Tjänsteproducenten stödjer inte anropets angivna rivta-version. Kontrollera uppgifterna.

soap:Server

VP006 [namn tjänsteplattform] Internt fel i tjänsteplattformen. Det finns fler än en tjänsteproducent definierad i tjänsteadresseringskatalogen som matchar logisk adressat (ReceiverId), tjänstekontrakt och dagens datum. Tyder på felkonfiguration. Rapportera felet till tjänsteplattformsförvaltningen.

soap:Client

VP007 [namn tjänsteplattform] Tjänstekonsumenten saknar behörighet att anropa den logiska adressaten via detta tjänstekontrakt. Kontrollera uppgifterna och vid behov, tillse att det beställs konfiguration i aktuell tjänsteplattform.

soap:Server

VP008 [namn tjänsteplattform] Internt fel i tjänsteplattformen. Ingen kontakt med tjänsteadresseringskatalogen. Informera tjänsteplattformsförvaltningen.

soap:Server

VP009 [namn tjänsteplattform] Fel vid kontakt med tjänsteproducenten.

soap:Server

VP010 [namn tjänsteplattform] Internt fel i tjänsteplattformen. URL saknas för tjänsteproducenten i tjänsteplattformens tjänsteadresseringskatalog.

soap:Client

VP011 [namn tjänsteplattform] Anrop har gjorts utanför TLS vilket ej är tillåtet. Tjänstekonsumenten ska alltid använda TLS för säker kommunikation.

soap:Server

VP012 [namn tjänsteplattform] Internt fel i tjänsteplattformen. Nödvändiga resurser saknas för att VP skall fungera.

soap:Client

VP013 [namn tjänsteplattform] Enligt tjänsteplattformens konfiguration saknar tjänstekonsumenten rätt att använda headern x-rivta-original-serviceconsumer-hsaid. Kontakta tjänsteplattformsförvaltningen.

soap:Server

VP014 [namn tjänsteplattform] Anropsförmedlingen för den logiska adressaten har givit upphov till rundgång mellan tjänsteplattformar. Rapportera felet till tjänsteplattformsförvaltningen.

soap:Client

VP015 [namn tjänsteplattform] Anrop ej korrekt utformat och kan därför inte behandlas.

* Terminologi från SOAP 1.1

Texten [namn tjänsteplattform] ska vara en textuell beskrivning av den tjänsteplattformsinstans (t.ex. ‘NTJP-PROD’ eller ‘SLL-QA’) där felet upptäcktes. Dessa namn ägs av vardera tjänsteplattforms ansvariga förvaltningsorganisation som måste tillse att namnen är unika.

Regel #9: Propagering av ursprunglig sändares identitet i http header

En tjänsteplattform skall propagera ursprunglig avsändares identitet i http headern ”x-rivta-original-serviceconsumer-hsaid”. Det innebär att:

  1. Om http headern inte är satt i ett inkommande anrop så skall avsändaren betraktas som ursprunglig avsändare och dess identitet (HSA-ID) skall hämtas från inkommande klient certifikat och sättas i http headern i utgående anrop till tjänsteproducenten alternativt till nästa tjänsteplattform.

  2. Om http headern är satt i ett inkommande anrop så skall tjänsteplattformen föra vidare http headern i anropet till tjänsteproducenten alternativt till nästa tjänsteplattform.

Motiv: Detta ger möjlighet att föra vidare information om ursprunglig avsändares identitet även om anropet passerar en eller flera mellanliggande tjänsteplattformar.

Regel #10: Säkerställ att anropande tjänsteplattform är känd

För att säkerställa en pålitlig propagering av ursprunglig avsändares identitet skall en tjänsteplattform säkerställa att den endast för vidare ursprunglig avsändares identitet från andra tjänsteplattformar som den litar på, t ex genom att upprätthålla en lista på IP adresser eller HSA-ID för de tjänsteplattformar den litar på och som den kontrollerar mot innan den accepterar en inkommande http header för ursprunglig avsändare. För anrop där denna kontroll misslyckas skall ett felmeddelanden skickas tillbaka till avsändaren och felet skall loggas som ett potentiellt försök till intrång.

Motiv: Om inte denna kontroll utförs så riskerar en tjänsteplattform att bli utsatt för angrepp från av avsändare som skickar med en annan tjänstekonsuments identitet (HSA-ID) i http headern och därmed otillåtet kan uppträda med dess identitet.

Regel #11: Vidarebefordran av anropskedja i RIV-header

En tjänsteplattform skall propagera meddelandets anropskedja i http headern ”x-rivta-routing-history”. Det innebär att:

  • Om http headern inte är satt i ett inkommande anrop så skall avsändaren betraktas som ursprunglig avsändare och dess identitet (HSA-ID) skall hämtas från inkommande klient certifikat och sättas först i http headern. Därefter skall tjänsteplattformens eget HSA-id adderas, där tecknet "#" används som avskiljare. Headern skickas i utgående anrop till nästa tjänstekomponent (vilket kan vara den slutgiltiga tjänsteproducenten).

  • Om http headern är satt i ett inkommande anrop så skall tjänsteplattformens eget HSA-id adderas, där tecknet "#" används som avskiljare. Headern skickas i utgående anrop till nästa tjänstekomponent (vilket kan vara den slutgiltiga tjänsteproducenten).

Motiv: Detta ger möjlighet att föra vidare information om den väg ett meddelande tagit mellan ursprunglig tjänstekonsument och slutgiltig tjänsteproducent. Informationen används även för att implementera skydd för rundgång. Den är också viktig vid felsökning.

Regel #12: Skydd mot rundgång

Två tjänsteplattformar kan konfigureras i sina respektive tjänsteadresseringskataloger så att de ömsesidigt pekar ut varandra för samma tjänstekontrakt och logiska adress. Risken för detta ökar i och med att mekanismen standardvägval används. Detta skulle leda till rundgång, att de oupphörligen skulle skicka samma meddelande mellan varandra till dess att en eller båda plattformarna slås ut. För att förhindra detta skall en tjänsteplattform implementera skydd mot rundgång.

  • En tjänsteplattform skall analysera headern ”x-rivta-routing-history” för alla inkommande meddelanden.

  • Om dess egen identitet finns registrerad så innebär det att samma meddelande når plattformen en andra gång, och rundgång har identifierats.

  • Vid rundgång skall meddelandet inte skickas vidare. Istället ska felmeddelandet VP014 returneras.

Regel #13: Vidarebefordran av RIV-headrar

Hanteringen av headrar i en tjänsteplattform skiljer sig åt beroende på om den anropande parten är en ursprunglig tjänstekonsument eller en godkänd tjänsteplattform.En tjänsteplattform skall alltid skicka vidare http headrar vars namn börjar med "x-rivta-". Dessa headrar benämns gemensamt "RIV-headrar". Informationen i dessa headrar får inte manipuleras eller ändras på annat sätt än vad som beskrivs i regel #9 och #11 ovan.

Motiv: Detta ger möjlighet att föra vidare information även om anropet passerar en eller flera mellanliggande tjänsteplattformar.

6. Tjänsteadresseringskatalog

Tjänsteadresseringskatalogen (TAK) har till uppgift att översätta logiska adresser till tekniska adresser, i praktiken URL:er.

Den primära konsumenten av informationen i tjänsteadresseringskatalogen är Virtualiseringsplattformen (VP). Kommunikationen mellan VP och TAK regleras inte av några nationella tjänstekontrakt.

Tjänsteadresseringskatalogen kan kombineras med organisationsdata se också "Regel #4: Vägval för anrop"

Regel #1: Lagring av vägvalsinformation

Tjänsteadresseringskatalogen skall lagra vägvalsinformation. Denna information består av följande delar:

  • Tjänstekontrakt inklusive tjänstedomän, i formatet URN, plus kontraktets major-version. Exempel: urn:riv:clinicalprocess:activityprescription:prescribe:ChangePrescription:1

  • Logisk adress till en organisationsenhet eller ett IT-system

  • Version av RIV-TA i kortformat, t.ex. ”rivtabp21”

  • Associerad teknisk adress, i form av en http URL.

Regel #2: Exponering av vägvalsinformation

Tjänsteadresseringskatalogen skall exponera sin registrerade vägvalsinformation till virtualiseringsplattformen över valfritt gränssnitt.

Regel #3: Lagring av anropsbehörigheter

Tjänsteadresseringskatalogen skall kunna lagra anropsbehörigheter. Dessa anropsbehörigheter består av följande delar:

  • Tjänstekontrakt inklusive tjänstedomän, i formatet URN, plus kontraktets major-version. Exempel: urn:riv:clinicalprocess:activityprescription:prescribe:ChangePrescription:1

  • logisk adress

  • tjänstekonsumentens identitet

Regel #4: Exponering av anropsbehörigheter

Tjänsteadresseringskatalogen skall exponera sina registrerade anropsbehörigheter till virtualiseringsplattformen över valfritt gränssnitt.

Regel #5: Tjänstekontrakt

Tjänsteadresseringskatalogen skall implementera den nationella tjänstedomänen infrastructure:itintegration:registry. Kontrakten i denna domän används av vissa avancerade tjänstekonsumenter och -producenter och kan komma att utökas med ytterligare funktionalitet. Se [R8].

7. Aggregeringsplattform

Aggregeringsplattformen har till uppgift att ge en tjänstekonsument ett svar som sammanställts genom att kontakta flera tjänsteproducenter, baserat på information i Engagemangsindex (se kap 8). Detta är en frivillig komponent i en tjänsteplattform.

Aggregeringsplattformen exponerar aggregerande tjänster baserade på RIV TA tjänstekontrakt. Varje aggregerande tjänst exponerar ett specifikt tjänstekontrakt. Villkoret för att kunna använda ett tjänstekontrakt i en aggregerande tjänst är att kontraktets svarsmeddelande är utformat i form av en lista och därigenom stöder att flera svar sammanfogas.



7.1 Relationer till andra tjänster

7.1.1 Virtualiseringsplattform

Anrop både till och från en aggregerande tjänst sker genom motsvarande virtuell tjänst. Detta för att tillgodose kravet på lös koppling.

Detta innebär att varje aggregerande tjänst exponerar samma tjänstekontrakt som motsvarande virtuell tjänst.

7.1.2 Tjänsteadresseringskatalog

Varje aggregerande tjänst i aggregeringsplattformen uppträder som en tjänsteproducent, och behöver således registreras i tjänsteadresseringskatalogen (TAK). Som logisk mottagaradress i TAK används adressen till den organisation som ansvarar för den aggregerande tjänsten.

Detta gör att aggregerande tjänster kan anropas via virtualiseringsplattformen, förutsatt att tjänstekonsumenter anger rätt logisk mottagaradress.

7.1.3 Engagemangsindex

Enligt mönstret i T-boken använder sig aggregeringsplattformen av tjänsten engagemangsindex för att få information om vilka tjänsteproducenter som innehåller information som behövs i aggregeringen. Detta leder till att aggregeringsplattformen även behöver en lokal instans av tjänsten engagemangsindex.

Regel #1: Datakommunikation

Aggregeringsplattformen skall följa alla kommunikationsregler i RIV TA.

Regel #2: Generera tjänst med utgångspunkt från WSDL-filer

Godkända tjänstekontrakt levereras i formaten WSDL och XSD, enligt RIV-TA Basic Profile. Utifrån dessa artefakter skall en aggregerande tjänst kunna skapas och installeras i aggregeringsplattformen.

Källa: [R3] Regel #18

Regel #3: Utgående anrop till tjänsteproducenter

Aggregeringsplattformen skall vidarebefordra den inkommande förfrågan till de tjänsteproducenter som enligt tjänsten engagemangsindex innehåller information för att kunna sammanställa ett komplett svar.

I de utgående frågemeddelandena ändras den logiska mottagaradressen till respektive tjänsteproducents logiska adress. Den ursprungliga tjänstekonsumentens identitet vidarebefordras med hjälp av http header x-rivta-original-serviceconsumer-hsaid, se kapitel 4.

Regel #4: Sammanställning av information

Aggregeringsplattformen skall sammanställa de svar som tas emot från enskilda tjänsteproducenter och skapa ett aggregerat svar. Detta svar skall sedan returneras till den ursprungliga tjänstekonsumenten.

Eventuella felmeddelanden från tjänsteproducenter skall inte infogas i det sammanställda svaret.

Regel #5: ProcessingStatus i svar till konsument

En aggregerande tjänst skall infoga en header, enligt aktuell RIV TA-profil, i sitt svar till en tjänstekonsument. Headern har namnet ProcessingStatus och innehåller en lista över de tjänsteproducenter som bidragit till svaret, samt uppgift om huruvida respektive delsvar kommer direkt från källsystemets primärdatabas eller från en cache.

I förekommande fall innehåller headern även information om tjänsteproducenter som svarat med felmeddelande, eller inte svarat alls.

För mer information, se [R4]: Basic Profile med status för anrop till aggregerande tjänster 2.1: Regel #2.

Regel #6: Filtrering av ej åtkomliga och ej kompatibla källsystem

Engagemangsindex tillhandahåller information om vilka källsystem som innehåller information av ett specifikt slag om en specifik person. Information från alla dessa källsystem är dock ibland inte möjliga att aggregera av följande skäl:

  • Den aktuella tjänstekonsumenten har inte anropsbehörighet till alla dessa källsystem.

  • Vissa källsystem stöder inte den aktuella huvudversionen av tjänstekontraktet.

Innan utgående anrop initieras skall Aggregeringsplattformen via Tjänsteadresseringskatalogen undersöka tjänstekonsumentens anropsbehörighet till källsystemen, samt källsystemens stöd för den aktuella huvudversionen av tjänstekontraktet. Källsystem som inte uppfyller dessa villkor skall inte anropas. Detta för att undvika att överflödiga felmeddelanden genereras i de olika plattformskomponenterna.

Då detta utelämnande inte beror på något tekniskt fel, skall Aggregeringsplattformen inte returnera information om utelämnade källsystem i ProcessingStatus (se Regel #5).

8. Engagemangsindex

Den gemensamma arkitekturen beskriver en stödtjänst kallad Engagemangsindex. Den har till uppgift att avlasta aggregeringsplattformen genom att registrera vilka tjänsteproducenter som har uppgifter av en viss typ för en viss person. Denna information gör att en aggregerad tjänst enbart behöver kontakta dessa tjänsteproducenter för att kunna leverera ett fullständigt resultat.



Om en tjänsteplattform har en aggregeringsplattform skall även tjänsten engagemangsindex implementeras. Här beskrivs de regler som tjänsten behöver uppfylla.

Regel #1: Datakommunikation

Engagemangsindex skall stödja alla kommunikationsregler i de RIV TA-profiler som tjänstedomänen itintegration:engagementindex tillämpar.

Regel #2: Tjänstedomän

Tjänsten ska implementera tjänstedomänen itintegration:engagementindex. Det innefattar bland annat:

  • Datamodell för att lagra engagemangsdata.

  • Stöd för att replikera engagemangsdata med andra engagemangsindex, i enlighet med tjänstekontraktsbeskrivningen.

  • Tjänst för att exponera en persons vårdengagemang mot aggregeringsplattformen.

Se tjänstekontraktsbeskrivning, [R6], för komplett information.

9. Tjänsteväxel och anpassningstjänst

Tjänsteväxel och anpassningstjänst är benämningar på två olika koncept som används för att översätta kommunikation till och från RIV TA.

9.1 Tjänsteväxel

En tjänsteväxel används för att översätta mellan den modell för teknisk kommunikation som används inom hälso- och sjukvårdssektorn och modeller som tillämpas av externa parter, såsom myndigheter. Ett exempel är översättning mellan RIV Tekniska Anvisningar och myndigheters SHS-arkitektur.

Tjänsteväxeln utför en generisk protokollväxling, vilket innebär att den kan översätta aspekter som t.ex. protokoll, adressering och säkerhetsmekanismer, för att matcha en specifik, extern arkitektur. Däremot förändrar tjänsteväxeln vanligtvis inte meddelandeinnehåll. Därför behöver tjänsteväxeln inte känna till specifika tjänstekontrakt, utan kan ha en gemensam ändpunkt för all kommunikation.

Den ändpunkt som tar emot RIV-TA-meddelanden för vidarebefordran till en extern part kallas partnerutgång och agerar tjänsteproducent för den aktuella externa samverkansarkitekturen. Motsatsen kallas partneringång och agerar som en tjänstekonsument.

Den gemensamma arkitekturen utgår från att all tjänsteväxling sker i den nationella tjänsteplattformen, och att en varje extern samverkansarkitektur som hälso- och sjukvårdssektorn behöver kommunicera med har en separat tjänsteväxel.

För mer information se [R1] kapitel 5.2 och 5.3.

9.2 Anpassningstjänst

Anpassningstjänster används för att anpassa IT-system inom hälso- och sjukvårdssektorn till RIV TA-standarden. En anpassningstjänst konstrueras vanligtvis för ett specifikt, icke RIV-kompatibelt, IT-system och anpassar in- och utgående anrop mellan RIVTA och systemet. Detta kan innebära att såväl protokoll, adressering, säkerhetsmekanismer och meddelandeinnehåll förändras.

En anpassningstjänst är en valfri komponent som främst används inom regionala tjänsteplattformar. Anpassningstjänster i en tjänsteplattform bör endast användas om leverantören för det aktuella IT-systemet inte kan tillhandahålla en RIV TA-kompatibel anslutningspunkt inom ramen för sitt förvaltningsobjekt.

9.3 Jämförelse

Både tjänsteväxel och anpassningstjänst används för att översätta kommunikation, men har olika syfte och omfattning:

  • En tjänsteväxel används för att översätta valfria tjänstekontrakt mellan RIV TA och en specifik extern meddelandearkitektur.

  • En anpassningstjänst används för att översätta specifika tjänstekontrakt mellan RIV TA och ett specifikt IT-system.



Följande illustration och tabell visar skillnader och likheter mellan tjänsteväxel och anpassningstjänster.

 

Tjänsteväxel

Anpassningstjänst

Kan översätta meddelandeinnehåll

Vanligtvis inte

Ja

Kan översätta adressering

Ja

Ja

Kan översätta protokoll

Ja

Ja

Kan översätta säkerhets-mekanismer

Ja

Ja

Knuten till specifika tjänstedomäner

Nej

Ja

Knuten till specifika IT-system

Nej

Ja

Placeras vanligtvis

Nationellt

Regionalt

Kommunikation

Med system utanför hälso- och sjukvårdsområdet

Med system inom hälso- och sjukvårdsområdet

Exempel

RIV-SHS-växel

Anpassning av SLL:s hälsovalstjänst till tjänstekontraktet GetListings.





Anders Malmros
February 1, 2022

Det är en logisk organisationsidentifierare. För de av Inera erbjudna aggregerande tjänster används mycket riktigt Ineras organisationsnummer, men det finns ingen regel som säger vilken logisk organisationsidentifierare som ska användas. De flesta andra logiska adresser i TAK är, eller startar med, organisationens HSA-ID

Per Carlén
February 1, 2022

Tack för svar!