RIV Tekniska Anvisningar Tjänsteplattform
| RIV Tekniska Anvisningar Tjänsteplattform
Version 2.0 ARK_0034 2024-09-18 |
Innehållsförteckning
- 1 RIV Tekniska Anvisningar Tjänsteplattform
- 2 Innehållsförteckning
- 3 1. Inledning
- 3.1 1.1 Målgrupp
- 3.2 1.2 Syfte
- 3.3 1.3 Tillgänglighet
- 3.4 1.4 Avgränsningar
- 3.5 1.5 Fallstudier
- 4 2. Terminologi
- 5 3. Informationsutbyte via tjänsteplattformar
- 6 4. Generella regler för en tjänsteplattform
- 6.1 TP Regel #1 Användning av tjänstekontrakt Utgått
- 6.2 TP Regel #2 Transportprotokoll
- 6.3 TP Regel #3 Autentisering
- 6.4 TP Regel #4 Bevarande av ursprunglig avsändares identitet i http-header
- 6.5 TP Regel #5: Propagering av ursprunglig sändares identitet i http-header
- 6.6 TP Regel #6: Säkerställ att anropande tjänsteplattform är betrodd
- 6.7 TP Regel #7: Vidarebefordran av anropskedja i RIV-header
- 6.8 TP Regel #8: Skydd mot rundgång
- 6.9 TP Regel #9: Vidarebefordran av http-headers
- 6.10 TP Regel #10 Logisk adressering
- 6.11 TP Regel #11 Exponering av URL:er Utgått
- 6.12 TP Regel #12 Hantering av tekniska fel
- 6.13 TP Regel #13: Felhantering vid nekad åtkomst från tjänsteproducent
- 6.14 TP Regel #14: Tjänsteplattformar ska propagera SOAP fel
- 7 5. En tjänsteplattforms komponenter
- 7.1 5.1 Tjänsteadresseringskatalog
- 7.1.1 5.1.1 Anropsbehörighet
- 7.1.1.1 Explicit behörighet
- 7.1.1.2 Hierarkisk behörighet
- 7.1.1.3 Standardbehörighet
- 7.1.2 5.1.2 Vägval
- 7.1.2.1 Explicit vägval
- 7.1.2.2 Hierarkiskt vägval
- 7.1.2.3 Standardvägval
- 7.1.2.4 Exempel: Hur kan olika vägvalsmekanismer kombineras i en anropskedja
- 7.1.3 TAK Regel #1: Lagring av vägvalsinformation
- 7.1.4 TAK Regel #2: Exponering av vägvalsinformation
- 7.1.5 TAK Regel #3: Lagring av anropsbehörigheter
- 7.1.6 TAK Regel #4: Exponering av anropsbehörigheter
- 7.1.7 TAK Regel #5: Tjänstekontrakt
- 7.1.1 5.1.1 Anropsbehörighet
- 7.2 5.2 Engagemangsindex
- 7.3 5.3 Virtualiseringsplattform
- 7.3.1 VP Regel #1: Datakommunikation
- 7.3.2 VP Regel #2: Åtkomstkontroll
- 7.3.3 VP Regel #3: Generera tjänst med utgångspunkt från WSDL Utgått
- 7.3.4 VP Regel #4: Vägval för anrop
- 7.3.5 VP Regel #5: Vidarebefordran av anrop
- 7.3.6 VP Regel #6: Översättning mellan RIV-TA versioner Utgått
- 7.3.7 VP Regel #7 Tjänsteinteraktioner Utgått
- 7.3.8 VP Regel #8: Felkoder
- 7.3.9 VP Regel #9: Propagering av ursprunglig sändares identitet i http header
- 7.3.10 VP Regel #10: Säkerställ att anropande tjänsteplattform är känd
- 7.3.11 VP Regel #11: Vidarebefordran av anropskedja i RIV-header
- 7.3.12 Regel #12: Skydd mot rundgång
- 7.3.13 Regel #13: Vidarebefordran av RIV-headrar
- 7.4 5.4 Aggregeringsplattform
- 7.4.1 5.4.1 Logisk adressering av aggregerande tjänst
- 7.4.2 5.4.2 Relationer till andra tjänster
- 7.4.2.1 Virtualiseringsplattform
- 7.4.2.2 Tjänsteadresseringskatalog
- 7.4.2.3 Engagemangsindex
- 7.4.3 AgP Regel #1 Datakommunikation
- 7.4.4 AgP Regel #2 Generera tjänst med utgångspunkt från WSDL-filer
- 7.4.5 AgP Regel #3 Utgående anrop till tjänsteproducenter
- 7.4.6 AgP Regel #4 Sammanställning av information
- 7.4.7 AgP Regel #5 ProcessingStatus i svar till konsument
- 7.4.8 AgP Regel #6 Filtrering av ej åtkomliga och ej kompatibla källsystem
- 7.5 5.5 Anpassningsplattform
- 7.5.1 5.5.1 Tjänsteväxel
- 7.5.2 5.5.2 Anpassningstjänst
- 7.5.3 5.5.3 Jämförelse
- 7.1 5.1 Tjänsteadresseringskatalog
Versionshistorik | |||
Utgåva | Revision Datum | Beskrivning | Ändringarna gjorda av |
1.0 |
| 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. | Lars Erik Röjerås Mattias Nordvall |
1.0.1 |
| Korrigerat vissa formuleringar och illustrationer. Nytt stycke om förhållandet mellan nationella och regionala tjänsteplattformar. | Mattias Nordvall |
1.1 |
| 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 | Mattias Nordvall |
1.2 |
| 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. | Mattias Nordvall |
1.3 |
| Uppdaterat Regel #6 under kapitlet Aggregeringsplattform. | Mattias Nordvall |
1.4 | 2017-12-07 | 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. | Björn Hedman |
1.5 | 2018-08-27 | Reglerna 2 och 4 har utökats med beskrivning av HSA-baserat vägval och anropsbehörighet samt användning av "*". | Lars Erik Röjerås |
1.6 | 2021-03-12 | Tagit bort Mule-referens i 1.4 Fallstudier. Uppdateringar och tillägg under kapitel 5 Virtualiseringsplattform:
| Anders Malmros |
1.7 | 2021-06-28 | Rättat fel i regel #12. Felkod VP014 skall användas vid rundgång, inte VP013 | Anders Malmros |
1.8 | 2022-01-25 | Lagt till ny felkod VP015 i regel #8, Felkoder | Anders Malmros |
1.8.1 | 2022-02-23 | Rättat felaktiga referenser till RIVTA Basic Profile 2.1 Valfria tillägg i kapitel 4.2.3 och 4.2.4 | Anders Malmros |
2.0 | 2024-09-18 | Allmänt strukturerat om innehållet och lagt till bilder och förtydliganden Lagt till exempel för att förtydliga: Logisk adressering genom tjänsteplattformar, kapitel 3.1 Användning av olika vägvalsmekanismer i en anropskedja, kapitel 5.1.2 Hur logisk adressering fungerar till och inom aggregerande tjänst, kapitel 5.4.1 Ändrat namnsättning på regler så att de har ett prefix för vilken komponent de avser. exempel: TP Regel #2 där TP står för Tjänsteplattformen och är allmänna regler VP Regel #1 där VP står för Virtualiseringsplattformen Felkoder: Lagt till ny felkod VP016, Kapitel 5.3 Tagit bort Regler: Dessa är markerade med genom strykning och texten “Utgått”
Flyttat ett antal regler från VP till TP
Lagt till Regler:
Ändringar av övriga formuleringar som ej var formella regler
Avsnittet referenser har tagits bort och ersatts av länkar i löptext | Anders Malmros Björn Hedman |
1. Inledning
Tjänsteplattformar skapar förmågan för tjänstekonsumenter att nå tjänsteproducenter, med stöd av logisk adressering, via en teknisk anslutning. Tjänsteplattformar förekommer dels i en nationell instans (NTjP), men även hos regionala aktörer inom hälso- och sjukvårdssektorn. För att underlätta bred samverkan kan tjänsteplattformar kopplas ihop.
Tjänstekonsumenter och tjänsteproducenter ansluts till någon av dessa tjänsteplattformar. Tjänsteplattformarna hanterar därefter adressering via vägval, samt åtkomsthantering via anropsbehörigheter för att förmedla informationen.
För samverkan via någon av de förvaltningsgemensamma tjänster som förmedlas via NTjP behöver tjänsteproducenter och tjänstekonsumenter, eller den tjänsteplattform som de är anslutna till, vara anslutna till den nationella instansen. Det behövs även konfiguration för behörighet och logisk adressering.
Detta dokument beskriver regelverket för RIV Tekniska Anvisningar Tjänsteplattform.
Hälso- och sjukvårdssektorn i Sverige har på uppdrag av Sveriges Kommuner och Regioner och under ledning av Inera, gemensamt tagit fram en nationell teknisk arkitektur i syfte att stödja samarbete över organisationsgränserna.
Enligt referensarkitekturen 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 realiseras med valfri programvara såvida reglerna i detta dokument kan uppfyllas.
1.1 Målgrupp
Målgruppen för detta dokument är lösningsarkitekter och utvecklare som ska realisera en tjänsteplattform enligt T-boken och RIV Tekniska Anvisningar.
1.2 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 och dess komponenter.
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 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.5 Fallstudier
Det finns en referensimplementation av en tjänsteplattform - (SKLTP - Confluence (atlassian.net)). Denna referensimplementation förvaltas aktivt och utgör grunden för den förvaltningsgemensamma tjänsteplattformen Nationell tjänsteplattform (NTjP).
Det har även gjorts ett antal regionala implementationer av tjänsteplattformar av den typ som beskrivs i detta dokument. För ytterligare erfarenhetsutbyte kring dessa, kontakta respektive regions tjänsteplattformsförvaltning.
2. Terminologi
För beskrivning av termer se RIV Tekniska Anvisningar SOAP Webservices.
3. Informationsutbyte via tjänsteplattformar
Nedan beskrivs hur en tjänsteplattform ska hantera logisk adressering och anropsbehörigheter, både fristående och i samverkan med andra plattformar.
3.1 Logisk adressering
Tjänstekonsumenter skickar alltid sina meddelanden till den tjänsteplattform tjänstekonsumenten är ansluten till och adresserar meddelandet med mottagarens logiska adress. Om den logiska adressen finns i den anropade tjänsteplattformens tjänsteadresseringskatalog vidarebefordrar tjänsteplattformen meddelandet till den tekniska anslutningsadress som är knuten till den logiska adressen. Anslutningsadressen kan antingen representera faktiska tjänsteproducenten eller en annan tjänsteplattform. I det senare fallet upprepas processen tills den faktiska tjänsteproducenten nås.
Den första tjänstekonsumenten som ansluter till en tjänsteplattform benäms “ursprunglig tjänstekonsument” och den sista tjänsteproducenten i anropskedjan kallas “faktisk tjänsteproducent”. Mellanliggande tjänsteplattformar är både tjänsteproducenter och tjänstekonsumenter men då i en virtuell form, med virtuell menas att de varken behandlar eller håller den information som hanteras.
Den logiska adressen skickas alltid vidare till nästa part för vidarebefodran, filtrering av svar eller liknade.
Eftersom adresseringsmodellen är grundläggande i arkitekturen är det viktigt att ha god förståelse för denna, se RIV-TA Översikt och T-boken för detaljer
Figuren nedan visar hur en tjänstekonsument skickar ett meddelande adresserat till ett källsystem.
Tjänstekonsumenten anropar tjänsteplattformen med den tekniska anslutningsadressen ntjp.inera.se och använder källsystemets HSA-id (SE1601) som logisk adress i meddelandet.
Tjänsteplattformen översätter med hjälp av TAK den logiska adressen till den tekniska anslutningsadress som gäller för den aktuella tjänsteproducenten (p1.vgr.se).
Tjänsteplattformen anropar tjänsteproducenten med den tekniska anslutningsadressen men skickar också med den logiska adressen i meddelandet.
Notera att vid adressuppslag mot TAK används tjänstekontraktet och logisk adress i kombination som unik nyckel för att slå upp den tekniska anslutningsadressen.
3.1.1 Logisk adressering genom multipla tjänsteplattformar
När meddelanden skickas mellan tjänsteplattformar tar dessa rollen som tjänstekonsument och/eller tjänsteproducent gentemot varandra och övriga tjänstekonsumenter.
Vid logisk adressering genom multipla tjänsteplattformar bibehålls den logiska adressen vid varje länk i förmedlingskedjan, men de tekniska anslutningsadresserna (URL:erna) ändras genom adressuppslag i respektive plattforms TAK.
Exempel: Hur förhåller sig logisk adress till producentens tekniska identitet
I exemplet så representerar den logiska adressen "SE1611" ett källsystem (källsystemsadressering). Det faktiska källsystemets URL är “p1.vgr.se” men i anropskedjan representeras den logiska adressen av ett flertal olika URL:er
I exemplet används SITHS funktionscertifikat både som klient- och servercertifikat för att styrka den tekniska identiteten
Konsument är konfigurerad att rikta alla sina anrop för ett visst tjänstekontrakt till adressen “ntjp.inera.se” och behöver därför inte slå upp adressen till tjänsteproducenten (NTjP) men behöver verifiera att den som man ansluter till via URL:en “ntjp.inera.se” är rätt part och det görs via funktionscertifikatet för “ntjp.inera.se”. Konsumenten använder den logiska adressen “SE1611” i meddelandets kuvertering.
NTjP tar emot anropet och slår upp att anrop till den logiska adressen "SE1611" ska skickas vidare till “rtp.vgr.se”. Ntjp validerar funktionscertifikatet för “rtp.vgr.se”. NTjP har ingen möjlighet att via servercertifikatet säkerställa att “rtp.vgr.se” företräder "SE1611" men förlitar sig på att informationen i NTjPs TAK är korrekt och genomför därför anropet.
RTP tar emot anropet och gör i sin tur ett uppslag av den logiska adressen "SE1611" som pekar på “p1.vgr.se”. RTP validerar serverns funktionscertifikat för att säkerställa att det är rätt system som svarar på anropet.
3.2 Anropsbehörighet
För att stödja hantering av anropsbehörigheter via en eller flera tjänsteplattformar förmedlas ursprunglig tjänstekonsuments identitet i http-headern x-rivta-original-serviceconsumer-hsaid. Om ursprunglig tjänstekonsument dessutom utför anropet å en annan bakomliggande verksamhets vägnar förmedlas verksamhetens identitet i http-headern x-rivta-acting-on-behalf-of-hsaid.
Tjänsteplattformar tar beslut om anropande tjänstekonsument har behörighet att utföra tjänsteanropet.
Detta kan antingen göras explicit eller så kan det delegeras till anropande part baserat på organisationstillit.
Den faktiska tjänsteproducenten kan ta åtkomstbeslut baserat antingen på identiteten för den anropande tjänstekonsumenten, ursprunglig tjänstekonsument, dess uppdragsgivande part eller en kombination av dessa.
Nedanstående bild visar den vanligaste realiseringen av åtkomsthanteringen vid samverkan över flera tjänsteplattformar.
Åtkomstbeslutet för ursprunglig tjänstekonsument delegeras till första tjänsteplattformen i anropskedjan.
Efterföljande tjänsteplattformar verifierar endast föregående tjänsteplattforms åtkomstbehörighet.
Den faktiska tjänsteproducenten verifierar sista tjänsteplattformens åtkomstbehörighet och i vissa fall även ursprunglig konsuments och uppdragsgivande verksamhets åtkomstbehörighet.
Om åtkomstbehörighet saknas returneras ett felmeddelande. Detta gäller för hela kedjan.
4. Generella regler för en tjänsteplattform
Alla tjänsteplattformar ska tillämpa de regler som beskrivs i detta dokument samt de principer och regler som beskrivs i:
En tjänsteplattform behöver i dagsläget stödja RIV-TA Basic Profile version 2.1. För logisk adressering behöver en tjänsteplattform vara bakåtkompatibel mot RIV-TA Basic Profile 2.0, se avsnitt om logisk adressering nedan.
Syftet med detta kapitel är att ge en sammanfattning av de regler från RIV-TA som berör tjänsteplattformar och alla dess ingående komponenter, samt att hänvisa till de dokument där reglerna har sina gällande formuleringar. Regler prefixas med “TP” (tex TP Regel #1).
Observera att komponenter dessutom kan ha kompletterade regler som beskrivs under respektive komponent.
TP Regel #1 Användning av tjänstekontrakt Utgått
Motiv att ta bort regeln: Det är svårt att motivera varför en tjänsteplattform inte skulle få hantera andra protokoll och anses vara en onödig begränsning
TP Regel #2 Transportprotokoll
Tjänstekomponenter skall skicka och ta emot anrop över HTTPS, om inte annat anges i regelverk för specifika tjänstekomponenter.
Motiv: Följsamhet mot RIV Tekniska Anvisningar Basic Profile 2.1
se även RIV Tekniska Anvisningar - Kryptering för ytterligare information.
TP Regel #3 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.
Motiv: Följsamhet mot RIV Tekniska Anvisningar Basic Profile 2.1
TP Regel #4 Bevarande av 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.
Tjänstekonsumentens identitet (HSA-ID) skall hämtas från inkommande klientcertifikat
Identiteten sätta i http-headern i utgående anrop till vilket kan vara till en tjänsteplattform eller den faktiska tjänsteproducenten.
För beskrivning av x-rivta-original-serviceconsumer-hsaid se RIV Tekniska Anvisningar Basic Profile 2.1, Regel #23.
Motiv: Följsamhet mot Detta görs för att nästa komponent i kedjan inte kommer att kunna läsa ursprungsavsändarens certifikat.
Observera: Det är endast betrodda tjänsteplattformar som får sätta denna header. Regel 4,5,6 ska läsas i samverkan
TP Regel #5: 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 om http-headern är satt i ett inkommande anrop så skall tjänsteplattformen föra vidare http-headern i anropet till nästa part i anropskedjan.
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.
TP Regel #6: Säkerställ att anropande tjänsteplattform är betrodd
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 är betrodda. För anrop där denna kontroll misslyckas skall ett felmeddelande 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.
TP Regel #7: Vidarebefordran av anropskedja i RIV-header
En tjänsteplattform skall sätta och 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 faktiska 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.
TP Regel #8: 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.
TP Regel #9: Vidarebefordran av http-headers
Utöver reglerna TP Regel #5 och TP Regel #7 så gäller att en tjänsteplattform alltid skall vidarebefodra http-headers vars namn börjar med "x-rivta-". Dessa vidarebefordras oförändrade.
Motiv: Detta ger möjlighet att föra vidare information även om anropet passerar en eller flera mellanliggande tjänsteplattformar.
TP Regel #10 Logisk adressering
Alla tjänstekomponenter skall förutsätta att inkommande meddelanden har en specificerad mottagare i form av en logisk adress. En tjänsteplattform behöver i dagsläget stödja förmedling av anrop utformade enligt RIV TA Basic Profile version 2.0 och 2.1. Det enda skillnad som behöver göras från ett förmedlingsperspektiv är att utläsa den logiska adressen från olika SOAP headers.
RIV-TA Basic Profile 2.0: {http://www.w3.org/2005/08/addressing }:To
RIV-TA Basic Profile 2.1: {urn:riv:itintegration:registry:1}:LogicalAddress
Motiv: Följsamhet mot RIV Teknisk Anvisningar Basic Profile 2.0, Regel #8, respektive RIV Tekniska Anvisningar Basic Profile 2.1, Regel #8
TP Regel #11 Exponering av URL:er Utgått
TP Regel #12 Hantering av 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 Fault. Detta till skillnad från logiska fel, som ska kommuniceras med vanliga svarsmeddelanden och definieras i respektive tjänstekontraktsbeskrivning.
Motiv: Följsamhet mot RIV Tekniska Anvisningar Basic Profile 2.1, Förtydligad hantering av tekniska fel.
TP Regel #13: Felhantering vid nekad åtkomst från tjänsteproducent
Den virtuella tjänsten ska, när den får ett HTTP 403 Forbidden, omforma detta fel till ett SOAP Fault utformat med felkod VP016 enligt vad som beskrivs i VP Regel #8.
Motiv: Följsamhet mot RIV Tekniska Anvisningar Basic Profile 2.1, Regel #28 Hantering av nekad åtkomst.
TP Regel #14: Tjänsteplattformar ska propagera SOAP fel
En tjänsteplattform som tar emot ett SOAP fel ska propagera detta till nästa aktör i en anropskedja
Motiv: Fel måste hanteras och distribueras på ett enhetligt sätt inom och mellan alla komponenter som omfattas av regelverket RIV-TA.
5. En tjänsteplattforms komponenter
Nedanstående avsnitt beskriver de ingående komponenterna lite mer i detalj och redovisar komponentspecifika regler som kompletterar de som gäller allmänt för tjänsteplattformen.
Endast komponenterna Virtualiseringsplattform och Tjänsteadresseringskatalog är obligatoriska att realisera.
5.1 Tjänsteadresseringskatalog
Tjänsteadresseringskatalogen (TAK) är en stödtjänst som erbjuder administration och åtkomst av information som ligger till grund för den adressering och behörighetskontroll som utförs i en komponenter inom tjänsteplattformen. TAK har till uppgift att:
Hantera information om vägval genom att översätta logiska adresser till tekniska adresser, i praktiken URL:er.
Hantera information om konsumenters åtkomstbehörighet.
Den primära konsumenten av informationen i tjänsteadresseringskatalogen är komponenter inom tjänsteplattformen. Konsumtion av TAK inom en tjänsteplattform regleras inte av några nationella tjänstekontrakt. För extern konsumtion finns vissa nationella tjänstekontrakt, se regel #5 nedan.
5.1.1 Anropsbehörighet
Det finns tre olika sätt att sätta upp anropsbehörigheter i TAK: som explicit behörighet, hierarkisk behörighet, eller som standardbehörighet. Explicit behörighet är grunden för behörighet i en tjänsteplattform. Detta kan kompletteras med hierarkisk och standardbehörighet i en viss instans beroende på behov och möjligheter.
Explicit behörighet
En tjänstekonsument ges behörighet att göra ett anrop med ett visst tjänstekontrakt och adressera anropet till en specificerad logisk adressat.
Hierarkisk behörighet
En tjänstekonsument ges behörighet att göra ett anrop med ett visst tjänstekontrakt och adressera anropet till alla adressater under en specificerad nod i HSA organisationsträd som stödjer tjänstekontraktet.
De logiska adresserna ska bestå av ett HSA-id som representerar en verksamhet eller organisation. Genom att tillföra information om de hierarkiska sambanden mellan logiska adresser (exempelvis via en fil över organisationsträdet i HSA) skapas möjligheten att definiera behörighet via en överliggande adress i hierarkin. I de fall där ingen explicit behörighet hittas så hämtas närmast överliggande logiska adress i hierarkin och prövar om den har behörighet definierat. Detta upprepas tills en behörighet hittas eller roten nås.
Roten i organisationshierarkin består definitionsmässigt av den logiska adressen "SE".
Standardbehörighet
En tjänstekonsument ges behörighet att göra ett anrop med ett visst tjänstekontrakt och adressera anropet till alla adressater som stödjer tjänstekontraktet. Standarbehörighet defineras genom att den logiska adressen "*" ingår i konfigurationen av en åtkomstbehörighet för tjänstekonsument i en tjänsteplattforms tjänsteadresseringskatalog.
Detta kan vara mycket användbart för samverkan där en tjänstekonsument ska nå alla logiska adresser för ett tjänstekontrakt. På detta sätt behövs endast en behörighetstakning istället för hundratals. Ett exempel är att en vårdgivares via dess tjänstekonsument vill kunna skicka elektronisk remiss till andra vårdgivare i Sverige som erbjuder denna tjänst. Ett annat tillämpningsområde kan vara för att ge tjänsteplattformar anropsbehörighet till varandra.
5.1.2 Vägval
Det finns tre olika sätt att sätta upp vägval i TAK: som explicit vägval, hierarkiskt vägval, eller som standardvägval. Explicit vägval är grunden för logisk adressering i en tjänsteplattform. Detta kan kompletteras med hierarkiskt och standardvägval i en viss instans beroende på behov och möjligheter.
Explicit vägval
En tjänsteproducent adresseras med en specificerad logisk adress. Vid en sökning i tjänsteadresseringskatalogen förväntas en exakt matchning av den logiska adressen för att en teknisk anslutningsadress ska returneras.
Hierarkiskt vägval
En tjänsteproducents tekniska anslutningsadress kan logiskt adresseras med verksamhetsadresser under en specificerad nivå i ett verksamhetsträd som nyttjas.
De logiska adresserna ska bestå av ett HSA-id som representerar en verksamhet eller organisation. Genom att tillföra information om det hierarkiska sambanden mellan logiska adresser (exempelvis 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ämtas närmast överliggande logiska adress i hierarkin och prövar om den har vägval definierat. Detta upprepas tills ett vägval hittas eller roten nås.
Roten i organisationshierarkin består definitionsmässigt av den logiska adressen "SE".
Standardvägval
En tjänsteproducents tekniska anslutningsadress kan logiskt adresseras med vilken logisk adress som helst. Alla logiska adressater kommer matchas mot samma vägval. I TAK representeras ett standardvägval av att den logiska adressaten registreras som en asterisk (“*”).
Exempel på tillämpning är att en regional tjänsteplattform kan definiera ett standardvägval till den nationella tjänsteplattformen för att inte behöva registrera samtliga logiska adresser som finns i den nationella TAKen. Detta blir särskilt tillämpligt för sådana adresser där den nationella plattformen använder hierarkiskt vägval men där den regionala plattformen inte gör det.
Exempel: Hur kan olika vägvalsmekanismer kombineras i en anropskedja
RPT1 använder standardvägval till “ntjp.inera.se” (NTJP) om det inte finns något explicit vägval konfigurerat för den angivna logiska adressen
Eftersom ”SE161123” inte finns konfigurerat så skickas anropet till “ntjp.inera.se” (NTJP)
NTJP använder hierarkiskt vägval om det inte finns explicita vägval konfigurerade för den angivna logiska adressen
Eftersom “SE161123” inte finns konfigurerat så söker NTJP i HSA trädet
“SE161123” hittas och ligger under “SE1601”
Eftersom “SE1601” har explicit vägval så skickas anropet till “rpt.vgr.se” (RPT2)
RTP2 använder enbart explicita vägval
Eftersom “SE161123” finns konfigurerat så skickas anropet till producenten “p1.vgr.se”
TAK 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.
TAK Regel #2: Exponering av vägvalsinformation
Tjänsteadresseringskatalogen skall exponera sin registrerade vägvalsinformation till tjänsteplattformens komponenter över valfritt gränssnitt.
TAK 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
TAK Regel #4: Exponering av anropsbehörigheter
Tjänsteadresseringskatalogen skall exponera sina registrerade anropsbehörigheter till tjänsteplattformens komponenter över valfritt gränssnitt.
TAK Regel #5: Tjänstekontrakt
Tjänsteadresseringskatalogen ska implementera den nationella tjänstedomänen infrastructure:itintegration:registry för att stödja externa tjänstekonsumenter. Se http://rivta.se/domains/infrastructure_itintegration_registry.html.
5.2 Engagemangsindex
Om en tjänsteplattform har en aggregeringsplattform kan även engagemangsindex behöva implementeras. Här beskrivs engagemangsindexets funktion övergripande och de regler som engagemangsindex behöver uppfylla.
Engagemangsindex är en stödtjänst där det finns information om vilka källsystem som har information om en invånare/patient. Engagemangsindex har till uppgift att avlasta aggregerande tjänster genom att peka ut vilka tjänsteproducenter som har uppgifter av den typ som den specifika tjänsten hanterar. Med hjälp av denna information behöver tjänsten enbart kontakta dessa tjänsteproducenter för att kunna leverera ett fullständigt resultat.
Engagemangsindex är utförligt beskrivet i T-boken (Referensarkitektur för vård och omsorg - T-boken) samt i tjänstekontraktsbeskrivningen för domänen: engagemangsindex - itintegration:engagementindex.
Engagemangsindex har även en tjänstedomän som innehåller de tjänstekontrakt som används för att hantera informationen. För detaljer se aktuell Tjänstekontraktsbeskrivning för EI i domänen engagemangsindex - itintegration:engagementindex.
Engagemangsindex producerar tre tjänster
Update används av informationsbärande system för att uppdatera information i indexet
FindContent används av aggregerande tjänster för att söka efter information i indexet
ProcessNotification används för att synkronisera information mellan index. ett index kan vara producent eller konsument eller både och beroende på synkroniseringmönster
EI Regel #1: Datakommunikation
Engagemangsindex skall stödja alla kommunikationsregler i de RIV TA-profiler som tjänstedomänen itintegration:engagementindex tillämpar.
EI 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 för engagemangsindex för komplett information.
5.3 Virtualiseringsplattform
Virtualiseringsplattformen uppfyller T-bokens arkitekturella princip om lös koppling mellan tjänstekonsumenter och -producenter. Den logiska adressen pekar ut en tjänsteproducents URL via information i TAK. På detta sätt döljs systems tekniska anslutningsadress från tjänstekonsumenten. En verksamhet kan därmed förändra sin systemstruktur utan att behöva påverka logiska adresser och därmed tjänstekonsumenter. Det enda som behöver uppdateras är informationen om anslutningsadress i TAK.
Virtuella tjänster 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 en tjänsteproducent men vidarebefordrar endast frågan till den faktiska producenten som den logiska adressen representerar och returnerar svaret till tjänstekonsumenten.
En virtuell tjänst består översiktligt av två funktionsblock
En tjänsteproducent baserad på samma tjänstekontrakt som den virtuella tjänsten
En tjänstekonsument som anropar producenten. tjänstekonsumenten tar hjälp av tjänsteadresseringskatalogen (TAK) för att:
Validera att aktuell tjänstekonsument har rätt att anropa den den logiska adressaten med det tjänstekontraktet.
Erhålla den tekniska adressen (URL) till mottagande tjänsteproducent.
VP Regel #1: Datakommunikation
Virtualiseringsplattformen skall följa alla kommunikationsregler i aktuella RIV-profiler.
VP Regel #2: Åtkomstkontroll
Virtualiseringsplattformen skall ha möjlighet att vid inkommande anrop kontrollera åtkomstbehörigheten för kombinationen av följande:
Anslutande tjänstekonsument.
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-profil.
Behörighet kan kontrolleras mot TAK enligt nedanstående metoder:
(Observera att metod 2 och 3 är valfria)
Explicit behörighet
Hierarkisk behörighet
Standardbehörighet
Om varken 1, 2 eller 3 identifierar en behörighet så returneras ett VP007-fel till tjänstekonsumenten.
VP Regel #3: Generera tjänst med utgångspunkt från WSDL Utgått
VP 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, eller via andra metoder, baserat på:
Meddelandets logiska mottagaradress
Anropat tjänstekontrakt, inklusive tjänstedomän och kontraktets huvudversion
Anropad RIV-profil
Uppslag av vägval kan göras enligt nedanstående metoder och prioritet:
(Observera att metod 2 och 3 är valfria)
Explicit vägval
Hierarkiskt vägval
Standardvägval
Om varken 1, 2 eller 3 identifierar ett vägval så returneras ett VP004-fel till konsumenten.
VP 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. Se också TP regel #14
VP Regel #6: Översättning mellan RIV-TA versioner Utgått
VP Regel #7 Tjänsteinteraktioner Utgått
VP 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. Se också TP regel #14
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. |
soap:Server | VP016 [namn tjänsteplattform] Åtkomst nekad av tjänsteproducenten. |
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.
VP Regel #9: Propagering av ursprunglig sändares identitet i http header
Flyttad till TP Regel #5
VP Regel #10: Säkerställ att anropande tjänsteplattform är känd
Flyttad till TP Regel #6
VP Regel #11: Vidarebefordran av anropskedja i RIV-header
Flyttad till TP Regel #7
Regel #12: Skydd mot rundgång
Flyttad till TP Regel #8
Regel #13: Vidarebefordran av RIV-headrar
Flyttad till TP Regel #9
5.4 Aggregeringsplattform
Aggregeringsplattformen exponerar aggregerande tjänster baserade på RIV TA tjänstekontrakt.
En aggregerande tjänst är en integrationstjänst som baserat på information i Engagemangsindex sammanställer information, oftast för en viss person. Informationstypen styrs av det tjänstekontrakt som den aggregerande tjänsten baseras på. Villkoret för att kunna använda ett tjänstekontrakt i en aggregerande tjänst är att kontraktets svarsmeddelande är utformat så att svaret kan vara en lista och därigenom stöder att flera svar sammanfogas.
Principerna för aggregerande tjänster är beskrivet i T-boken. För information om realisering av en aggregerande tjänst på en specifik tjänsteplattform hänvisas till respektive tjänsteplattformsförvaltning.
En aggregerande tjänst består översiktligt av fyra funktionsblock
en tjänsteproducent baserad på samma tjänstekontrakt som den virtuella tjänsten
en aggregeringsfunktion som slå ihop svar från samtliga producenter till en lista
en funktion för informationslokalisering som identifierar vilka producenter som bär information av den aktuella typen. Ofta använder denna funktion stödfunktionen engagemangsindex.
En tjänstekonsument som kontrollerar om konsumenten har behörighet att anropa de identifierade producenterna samt slår upp teknisk anslutningsadress för dessa.
5.4.1 Logisk adressering av aggregerande tjänst
Även aggregerande tjänster adresseras via logiska adresser. Ur tjänstekonsumentens perspektiv uppträder en aggregerande tjänst som en tjänsteproducent. Den exekverar på komponenten Aggregeringsplattform inom ramen för en tjänsteplattform. Principerna för aggregerande tjänster beskriv i T-boken (Referensarkitektur för vård och omsorg - T-boken).
Hur den logiska adressen för en aggregerande tjänst utformas bestäms av den organisation som tillhandahåller den.
En aggregerande tjänst som finns på den nationella tjänsteplattformen adresseras primärt med Ineras organisationsidentifierare som logisk adress.
Om det skulle finnas flera aggregerande tjänster för samma tjänstekontrakt så adresseras dessa med organisationsidentifieraren +lämpligt suffix.
För regionala/lokala aggregerande tjänster hanteras adresseringen enligt lokala beslut.
Observera att i figuren ovan framgår att den logiska adressen 556559-4230, som finns i anropet till nationella tjänsteplattformen, enbart pekar ut den aggregerande tjänsten. Den aggregerande tjänsten kommer dock i sin tur att anropa respektive tjänsteproducent baserat på de logiska adresser som finns i EI-posterna (inringade med röd streckad linje i bilden ovan). Precis som i fallet med en virtuell tjänst så översätts de logiska adresserna till URL:er genom uppslag mot TAK.
5.4.2 Relationer till andra tjänster
Virtualiseringsplattform
En aggregerande tjänst exponerar samma tjänstekontrakt som motsvarande virtuella tjänst. Tjänsteplattformen ska utifrån en och samma URL kunna styra vilken komponent i tjänsteplattformen som hanterar anropet: en virtuell tjänst, en aggregerande tjänst eller en anpassningstjänst beroende på den logiska adressen i kuverteringen.
Tjänsteadresseringskatalog
Varje aggregerande tjänst i aggregeringsplattformen uppträder som en tjänsteproducent, och behöver således registreras i tjänsteadresseringskatalogen (TAK).
Detta gör att aggregerande tjänster kan anropas via virtualiseringsplattformen, förutsatt att tjänstekonsumenter anger rätt logisk mottagaradress.
Engagemangsindex
Enligt mönstret i T-boken använder sig aggregeringsplattformen av 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 tillgång till den lokala instansen av engagemangsindex.
AgP Regel #1 Datakommunikation
Aggregeringsplattformen skall följa alla kommunikationsregler i RIV-TA.
AgP 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 2.1. Utifrån dessa artefakter skall en aggregerande tjänst kunna skapas och installeras i aggregeringsplattformen.
Källa: RIV Tekniska Anvisningar - Basic Profile 2.1 Regel #18
AgP 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.
AgP 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.
AgP 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 RIV Tekniska Anvisningar - Basic Profile 2.1 med status för anrop till aggregerande tjänster 2.1: Regel #2.
AgP 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ällsystems logiska adresser.
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).
5.5 Anpassningsplattform
Anpassningsplattformen kan realisera funktionera av typen tjänsteväxel och anpassningstjänst som är benämningar på två olika koncept som används för att översätta kommunikation till och från RIV-TA.
5.5.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 Referensarkitektur för vård och omsorg - T-boken kapitel 5.2 och 5.3.
5.5.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 RIV-TA 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.
5.5.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. |