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

2. Terminologi

Följande termer förekommer i dokumentet.

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 Valfria tillägg [R4] Regel #2

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 Valfria tillägg [R4] Regel #4

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:

• RIVTA Basic Profile 2.0: {http://www.w3.org/2005/08/addressing}:To

• RIVTA Basic Profile 2.1: {urn:riv:itintegration:registry:1}:LogicalAddress

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.

* 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.