Tjänsteplattform. Tekniska krav. ARK_0034 Version 1.0.1

Tjänsteplattform Tekniska krav ARK_0034 Version 1.0.1

Innehåll 1. Inledning... 3 1.1 Syfte... 3 1.2 Målgrupp... 3 1.3 Avgränsningar... 3 1.4 Fallstudier... 4 1.5 Referenser... 4 2. Terminologi... 5 3. Allmänt... 5 3.1 Regelverk... 5 3.2 Nationella och regionala och tjänsteplattformar... 6 4. RIV Tekniska Anvisningar... 7 4.1 Information... 7 4.2 Kommunikation... 7 5. Virtualiseringsplattform... 9 5.1 Regler... 9 6. Tjänsteadresseringskatalog... 12 6.1 Regler... 12 7. Aggregeringsplattform... 14 7.1 Relationer till andra tjänster... 14 7.2 Regler... 15 8. Engagemangsindex... 16 8.1 Regler... 16 9. Anpassningsplattform... 17 9.1 Partneringång... 17 9.2 Partnerutgång... 17 Sid 1/18

Versionshistorik Version 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. Sid 2/18

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. Sid 3/18

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. Namn Adress Beskrivning SKL TP http://skltp.se/ Officiell referensimplementation. Bygger på Mule ESB. Regional tjänsteplattform, Landstinget Dalarna http:///documents/tja NSTER_PROJEKT/Tjansteplattform/ implementation_av_regional_tjanste plattform.pdf Landstinget Dalarnas implementation av SKL TP 1.5 Referenser Ref Dokument Beskrivning [R1] T-boken Referensarkitektur för vård och omsorg [R2] [R3] [R4] [R5] [R6] [R7] RIV Tekniska Anvisningar Översikt RIV Tekniska Anvisningar Basic Profile RIV Tekniska Anvisningar Basic Profile Valfria Tillägg 2.1 RIV Tekniska Anvisningar Tjänsteschema Tjänstekontraktsbeskrivning Engagemangsindex WS-I Basic Profile 1.1 http://rivta.se/documents/ark_0019 http://rivta.se/documents/ark_0001 RIV-TA:s tillägg till WS-I Basic Profile http://rivta.se/documents/ark_0002 http://rivta.se/documents/ark_0028 Beskrivning av schema-filer för tjänstekontrakt. http://rivta.se/documents/ark_0005 Beskrivning av tjänstekontrakt i domänen itintegration:engegementindex. http://rivta.se/domains/itintegration_engagementindex.html En specifikation på protokollanvändning i syfte att kunna implementera interoperabla webbtjänster. http://www.ws-i.org/profiles/basicprofile-1.1.html Sid 4/18

[R8] Tjänstekontraktsbeskrivning Tjänsteadressering Beskrivning av tjänstekontrakt i domänen infrastructure:itintegration:registry. http://rivta.se/domains/infrastructure_itintegration_registry. html 2. Terminologi Följande termer förekommer i dokumentet. Term Tjänstekonsument Tjänsteproducent Tjänstekomponent Tjänstekontrakt Tjänstedomän Tjänsteinteraktion Definition 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. 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. Avgränsad mängd programvara som kan utvecklas, integreras, testas, driftsättas och förvaltas fristående. Specifikation som beskriver ett nationellt standardiserat gränssnitt som förekommer mellan tjänstekomponenter i en tjänsteorienterad arkitektur. En enligt VIFO-kartan övergripande, verksamhetsbaserad indelningsgrund för nationellt standardiserade tjänsteinteraktioner. Informationsutbyte mellan tjänstekomponenter baserat på tjänstekontrakt. 3. Allmänt 3.1 Regelverk Följande regelverk ställer krav på tjänsteplattformar: Sid 5/18

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. Sid 6/18

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 RIVTA-regler som berör tjänsteplattformar, samt att hänvisa till de dokument där reglerna har sina gällande formuleringar. 4.1 Information 4.1.1 Användning av tjänstekontrakt Allt meddelandeutbyte ska baseras på tjänstekontrakt, som utformats enligt gällande version 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: [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: [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: [R4] Regel #2 Sid 7/18

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: [R4] Regel #4 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 namn LogicalAddress. Källa: [R3] Regel #8 4.2.6 Exponering av URL:er Tjänsteproducenter och tjänsteplattformar skall exponera URL:er som avslutas med följande beståndsdelar och i följande ordning: 1. Huvudversion av aktuellt tjänstekontrakt 2. Kortnamn på den version av RIV-TA Basic Profile som används Exempel: https://tidbok.landsting.sjunet.org/crm/scheduling/makebooking/1/rivtabp21 Källa: [R3] Regel #19. 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: [R5] Regel #11 Sid 8/18

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 respektive informationsägares tjänsteproducent och förmedlar svarsmeddelandet i retur. Tjänstekonsumenter anger mottagare av en begäran med hjälp av SOAP header LogicalAddress (se kap. 4). Virtualiseringsplattformen har tillkommit för att uppfylla T-bokens arkitekturella princip om lös koppling mellan tjänstekonsumenter och -producenter. 5.1 Regler Regel #1: Datakommunikation Virtualiseringsplattformen skall följa alla kommunikationsregler i RIV TA. 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 SOAP Fault returneras, se regel om felkoder nedan. Sid 9/18

Källa: [R2] Kapitel 8.5 Regel #3: 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 virtuell tjänst kunna skapas och installeras i virtualiseringsplattformen. Källa: [R3] Regel #18 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-version Regel #5: Vidarebefordran av anrop Virtualiseringsplattformen skall, såvida autentisering, åtkomstkontroll, vägval och övrig validering lyckats, skicka tjänstekonsumentens SOAP-meddelande vidare till tjänsteproducenten. Svaret från tjänsteproducenten, oavsett om det är ett ordinarie svar eller ett SOAP Fault, skall därefter returneras till tjänstekonsumenten. Regel #6: Översättning mellan RIV-TA versioner Virtualiseringsplattformen skall vid behov 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: Tjänsteinteraktioner RIV TA definierar följande typer av tjänsteinteraktioner: Fråga-svar synkrona anrop. Uppdrag-Resultat asynkrona anrop. Informationsspridning publish-subscribe. Varje tjänstedomän beslutar om användning av en eller flera av dessa, baserat på sina behov. Idag används enbart interaktionstypen fråga-svar. Virtualiseringsplattformen behöver därför enbart stödja denna interaktionstyp. I framtiden planeras de övriga två interaktionstyperna beskrivas och tas i bruk. Detta kan leda till ytterligare krav för tjänsteplattformar. Källa: [R2] Kapitel 7 Sid 10/18

Regel #8: Felkoder Virtualiseringsplattformen skall returnera SOAP Fault-meddelanden med följande felkoder och i följande felsituationer: Fault code * VP001 VP002 VP003 VP004 VP005 VP006 VP007 VP008 VP009 VP010 VP011 VP012 Fault string * RIV-version inte konfigurerad för den anslutningspunkt som den virtualiserade tjänsten publicerar. SERIALNUMBER ej tillgängligt i konsumentens certifikat. LogicalAddress ej angiven i SOAP Header i inkommande meddelande. Det finns ingen tjänsteproducent definierad i Tjänstekatalogen som matchar logisk adress, tjänstekontrakt och dagens datum. Det finns ingen tjänsteproducent definierad i Tjänstekatalogen som matchar angiven RIV-version. Det finns mer än en tjänsteproducent definierad i Tjänstekatalogen som matchar logisk adress, tjänstekontrakt och dagens datum. Den finns ingen behörighet för den tjänstekomponent som anropar att samverka med tjänsteproducenten. Avser behörigheter definierade i tjänstekatalogen. Ingen kontakt med tjänstekatalogen. Fel vid kontakt med tjänsteproducenten. Ingen adress angiven i tjänsteproducenten Anropande konsument är inte betrodd att göra http-anrop till VP Nödvändiga resurser saknas för att VP skall fungera. * Terminologi från SOAP 1.1 Sid 11/18

6. Tjänsteadresseringskatalog Tjänsteadresseringskatalogen (TAK) har till uppgift att översätta logiska, verksamhetsbaserade adresser, i praktiken HSA-ID, 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. 6.1 Regler 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 majorversion. 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. Sid 12/18

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 majorversion. 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]. Sid 13/18

7. Aggregeringsplattform Aggregeringsplattformen har till uppgift att ge en tjänstekonsument ett svar som sammanställts genom att kontakta flera tjänsteproducenter. 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 också måste ha en virtuell tjänst med samma tjänstekontrakt. 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. Sid 14/18

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. 7.2 Regler 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: SOAP Header ProcessingStatus i svar till konsument En aggregerande tjänst skall infoga en SOAP Header 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. Sid 15/18

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. 8.1 Regler Regel #1: Datakommunikation Engagemangsindex skall stödja alla kommunikationsregler i RIV TA. 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. Sid 16/18

9. Anpassningsplattform En anpassningsplattform (även kallad tjänsteväxel ) ansvarar 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 myndigheternas SHS-arkitektur. Anpassningen kan bestå av både teknisk och semantisk översättning. Anpassningsplattformen är en valfri komponent i en tjänsteplattform och kan innehålla valfritt antal partneringångar och partnerutgångar. För mer information se [R1] kapitel 5.2 och 5.3. 9.1 Partneringång En partneringång låter en extern part ansluta till en tjänsteplattform, via en annan teknisk standard än RIV TA. Partneringången översätter den externa partens kommunikation, information och adressering till motsvarande standarder inom RIV TA. Därefter levererar partneringången informationen till avsedd mottagare via tjänsteplattformens virtuella tjänster. Virtualiseringsplattformen betraktar en partneringång som en tjänstekonsument. 9.2 Partnerutgång En partnerutgång hanterar det omvända scenariot, där tjänstekonsumenter inom vård och omsorg behöver kommunicera med informationsägare utanför hälso- och sjukvårdssektorn. Partnerutgången tar emot meddelanden enligt RIV TA, översätter dem och levererar resultaten till en extern part. Virtualiseringsplattformen betraktar en partnerutgång som en tjänsteproducent. Sid 17/18