Läs mer om SLL:s Regionala Tjänsteplattform (RTP)

Transkript

1 1 (10) Läs mer om SLL:s Regionala Tjänsteplattform (RTP) Stockholms läns landstings Regionala Tjänsteplattform (RTP) är en teknisk plattform som förenklar, säkrar och effektiviserar informationsutbytet mellan olika IT-system inom vård och omsorg. Varje tjänst som vill ansluta till RTP använder så kallade tjänstekontrakt, som beskriver hur informationsöverföringen ska gå till mellan de olika systemen och tjänsterna. RTP ägs av Hälso- och sjukvårdsförvaltningen vid Stockholms läns landsting och förvaltas av SLL IT.

2 2 (10) Tjänsteplattform SKLTP och dess komponenter SLL:s Regionala Tjänsteplattform bygger på det nationella konceptet SKLTP från Inera. SKLTP innehåller ett antal komponenter: Övergripande information om komponenterna Virtualiseringsplattform (VP) o exponerar virtuella tjänster. I denna finns en fast anslutningspunkt för ett tjänstekontrakt för en viss version av RIV Tekniska Anvisningar. Tjänsteadresseringskatalog (TAK) o tillhandahåller vägvals- och behörighetsinformation till virtualiseringsplattformen. Informationen utgörs dels av adresser till olika tjänsteproducenter och dels av behörigheter

3 3 (10) för tjänstekonsumenter till olika logiska adressater (verksamhetsadresser). Engagemangsindex (EI) o håller information om invånarens engagemang genom att hållas uppdaterad med information om vilka informationsägare som har information om en invånare/patient. Aggregeringsplattform (AgP) o exponerar aggregerande tjänster som för en viss individ/patient sammanställer en nationell vy av informationen av den typ som är aktuell för tjänsten i fråga. Anpassningsplattformen (AnP) o används i de fall en tjänsteproducent inte tillhandahåller en standardiserad tjänst enligt tjänstekontrakten. I dessa fall kan anropen översättas och detta sker i anpassningsplattformen. Tjänstekontrakt (TK) o Tjänstekontraktsbeskrivningen är ett teknik-oberoende, formellt regelverk som reglerar integrationskraven för konsumenter och producenter. Komponenterna hanteras av SLL:s förvaltning av RTP i Förvaltningsobjekt (Fo) Informationsinfrastruktur, enligt förvaltningsmodell pm3. Eftersom regionalt behov saknas i SLL:s RTP, är inte komponenterna EI och AgP installerade. Vid informationsutbyte som kräver dessa nyttjar RTP NTjP:s EI samt AgP. Stödkomponenter SLL RTP tillhandahåller fyra (4) stödkomponenter: Beställningsstöd (BS) o Ett administrativt stöd för att registrera anslutande system, konsumenter och producenter av tjänstekontrakt inom den nationella samverkansarkitekturen, RIV TA.

4 4 (10) Hippo o Visar vilka integrationer som finns, givet de infrastrukturmiljöer som har angivits. Statistik o Visar statistik över antal meddelanden som har passerat genom SLL:s RTP under givet tidsintervall, per tjänstekonsument, tjänstekontrakt, logisk adressat och tjänsteproducent. Tjänsteplattforms Databas (TP DB) o Innehåller information om integrationer och antal meddelanden via SLL RTP. Ansvar Fo Ii ansvarar för de tio (6+4) komponenterna som är beskrivna i detta dokument. Med ansvar menas, att dessa i sin produktionsmiljö är skyddade och övervakade, enligt existerande drift- och applikations-förvaltningsavtal. Tjänsteplattformen SKLTP Tjänsteplattformen är en integrationsplattform som förenklar, säkrar och effektiviserar informationsutbytet mellan olika IT-system inom vård och omsorg. Tjänsteplattformen består av teknik och regler som är gemensamma för Sveriges vårdgivare genom den nationella referensarkitekturen för vård och omsorg: T-boken. Lösningarna i tjänsteplattformen sker i första hand för att möjliggöra återanvändning av information och samtidigt behålla en lös koppling mellan de som konsumerar och de som producerar information. Den nationella tjänsteplattformen förvaltas av inera. Både den nationella och SLL:s TP är baserad på den öppna integrationsprodukten Mule ESB från företaget MuleSoft. Med hjälp av RIV-metoden utvecklas nationellt standardiserade meddelandeformat för varje typ av tjänst, s.k. tjänstekontrakt. Genom TP får konsumenter en nationell tjänst att vända sig till (s.k. virtuell tjänst) som

5 5 (10) i sin tur kan dirigera meddelanden vidare till rätt tjänst för respektive vårdgivare. På så sätt behöver varje konsument och producent bara förstå ett format och en teknisk dialekt. Detta ger sammantaget en arkitektur där vårdgivarna kan förändra sammansättningen av sitt IT-stöd utan att det påverkar alla konsumenter. Det innebär också att vården kan följa teknikens utveckling genom att gradvis införa nya standarder för kommunikation utan att alla behöver gå med på samma gång. Förändringar kan ske i steg på ett kontrollerat sätt även när IT-systemen är integrerade. Koncept Tjänsteplattformen Konceptet tjänsteplattform beskrivs i ineras T-bok. Där kan man läsa om syfte, ändamål, funktion och konceptuell realisering. Det finns också krav på tjänsteplattformen att stödja de tekniska interoperabilitetsstandarder som CeHis beslutat om, och som Inera nu utvecklar och förvaltar. Produkten SKLTP Produkten som paketerar de mjukvaror som sammantaget kallas Tjänsteplattformen heter "SKL TP". Produkten är en realisering av konceptet Tjänsteplattformen. Tjänstekontrakt Utbyte av information mellan en producent av information och en konsument av information hanteras genom ett tjänstekontrakt (TK). Tjänstekontraktet anger, enligt ett förutbestämt regelverk, hur olika anrop och svar inom en tjänst eller system ska gå till. Exempel: när en invånare använder sig av ett tjänstekontrakt för att ta reda på hur många tänkbara vårdval hen kan göra, är detta ett anrop. Listan som sedan kommer upp med alla vårdenheter som finns att välja bland är ett svar. Tjänstekontrakten samlas i olika tjänstedomäner beroende på område och funktion. Tjänstekontraktet består av 3 delar: ett läsbart dokument; Tjänstekontraktsbeskrivning (TKB), och (minst) två XML-filer: o WSDL-filen, är kuvertet

6 6 (10) o XSD-schemafil som beskriver informationen som ska utbytas Tjänstedomänen Tidbokning (exempel), innehåller alla tjänstekontrakt för den domänen. Både leverantören av konsument-applikationen respektive producentapplikationen måste programmera sin applikation så att den antingen kan anropa ett tjänstekontrakt och ta emot information eller kan ta emot anrop från ett tjänstekontrakt och släppa iväg information. Eller för bägge sakerna. Det innebär att alla it-system som ska nyttja tjänstekontrakt, måste ta sitt ansvar och förändras. Utveckla tjänstekontrakt Om du vill utveckla tjänstekontrakt ska du alltid ta kontakt med RTP:s förvaltning först, för att ta reda på vad som redan finns. Tjänstekontrakten ska vara utformade enligt det nationella regelverket och följa RIV:s tekniska anvisningar. De måste även namnges enligt en särskild standard för e-hälsa, vilket beskrivs i den så kallade VIFO-kartan (förvaltad av Socialstyrelsen). Beställa installation av tjänstekontrakt Ett tjänstekontrakt måste ha en tjänstedomänansvarig. Det är sedan tjänstedomänsansvarig som beställer installationen. När kontraktet är på plats i RTP kan konsumenter och producenter ansluta sig. En beställning behöver göras för respektive miljö (testmiljö, acceptanstest och produktion) mha tillgängligt beställningsstöd. Godkända tjänstekontrakt Fo Ii installerar inga tjänstekontrakt i produktionsmiljön, som inte är godkända enligt den nationella godkännande processen. Virtualiseringsplattform För att meddelanden ska kunna "passera" en TP måste aktuell tjänst finnas som en virtuell tjänst i aktuell TP, dvs, aktuellt TK måste vara installerat (i form av en javaklass) och exekvera där. Det är denna javakod som tar emot anropet från konsumenten. Konsumenten anropar inte TP, konsumenten anropar alltid en virtuell tjänst i TP.

7 7 (10) Ett TK realiseras i form av en virtuell tjänst i TP. Ett nationellt TK måste realiseras i både NTP och RTP för att vara nåbart från RTP. En konsument inom SLL anropar den virtuella tjänsten på RTP. Adresseringsinformation finnas i SLL:s TAK som pekar ut den virtuella tjänsten i NTP. I den nationella TAK pekas en producent ut som är slutgiltig mottagare. Behörighet kontrolleras i SLL:s TAK. Konsumenten måste alltså ha behörighet till logisk adress för aktuellt kontrakt. TK består av en WSDL- och en eller flera XSD-filer. Utifrån dessa generas körbar java-kod (för Mule). Koden exekverar på TP inom en container som kallas "virtualiseringsplattform. Det görs både på den nationella och regionala plattformen (på alla som ingår i meddelandeflöden, alla som måste kunna routa meddelanden baserat på det aktuella kontraktet). Det kallas "virtuell tjänst". Dvs 1:1 förhållande mellan kontrakt och virtuell tjänst. Den virtuella tjänsten läser - via VP - TAK och hämtar upp behörighets- och routinginfo och använder detta för behörighetskontroll samt vägval.

8 8 (10) Tjänsteadresseringskatalog Tillhandahåller vägvals- och behörighetsinformation till virtualiseringsplattformen. Informationen utgörs dels av adresser till olika tjänsteproducenter och dels av behörigheter för tjänstekonsumenter till olika logiska adressater (verksamhetsadresser). Beställa anslutning till tjänstekontrakt När en konsument och/eller producent ska börja utbyta information via tjänstekontrakt, måste konfigurationsinformation om det införas i tjänsteadresseringskatalogen. En beställning behöver göras för respektive miljö (testmiljö, acceptanstest och produktion) mha tillgängligt beställningsstöd. Engagemangsindex Håller information om invånarens besök/engagemang genom att hållas uppdaterad med information om vilka informationsägare som har information om en invånare/patient. EI är en teknisk lösning för att hitta källan där information finns om en patient. Ingen information från EI visas för en slutanvändare utan det är endast information från källan som visas. Aggregeringsplattform Är en plattform inom TP där man kan installera tjänster som sammanställer information från underliggande producenter, så inte konsumenten behöver göra det. Tjänsten i AgP anropar TK i VP. Exponerar aggregerande tjänster som för en viss individ/patient sammanställer en nationell vy av informationen av den typ som är aktuell för tjänsten i fråga. TK realiseras alltid som en virtuell tjänst i VP. Vissa av dessa, t ex GetCareContacts, används också för att implementera en Aggregerande tjänst (AgT). Samma kontrakt används, men exekvering sker genom två olika tjänster i plattformen. När man anropar en AgT sker anropet via den virtuella tjänsten, och där routas man till AgT.

9 9 (10) En AgT implementeras enligt ett specifikt java-interface i det som vi kallar "Aggregeringsplattformen" inom ramen för Tjänsteplattformen. En AgT hittar logiska adresser i EI, och anropar alla dessa (som har information om patienten) parallellt. Anpassningsplattform Används i de fall en tjänsteproducent inte tillhandahåller en standardiserad tjänst enligt tjänstekontrakten. I dessa fall kan anropen översättas och detta sker i anpassningsplattformen, tex bryggan/adaptern till SHS eller en adapter mellan ett TK och ett it-systems egen informationsmodell. HSAid När man ansluter en producent till en tjänsteplattform så är det HSAid för närmaste grannen till tjänsteplattformen som ska anges. Det är även detta HSAid som ska stå som producentens HSAid i samverkansbeställningen. URL som anges pekas ut som adress i TAK och står även i SITHScertifikatet för producenten. Enligt inera: Certifikat har NTP HSAid för produktion HSASERVICES-106J. För RTP:s HSAid:n, se: Ovanstående är viktigt t ex för TakeCare: TakeCare har ett HSAid och xchange har ett annat HSAid och CGMx har ett tredje HSAid xchange och CGMx är TakeCares olika delar/funktioner/plattformar för att släppa ifrån eller ta emot information Beställningsstöd (BS) Ett administrativt stöd för att registrera anslutande system, konsumenter och producenter av tjänstekontrakt samt adressering via

10 10 (10) logiska adressater enligt den nationella samverkansarkitekturen, RIV TA. BS sänder beställningar till ansvarig organisation för konfiguration i berörd TAK. BS innehåller information om anslutande system samt kontaktuppgifter för dem. Hippo Visar integrationer för de tjänsteplattformar vars TAK är tillgänglig i Ineras TAK-api. Visar integrationer för i gränssnittet angivna filtreringskriterier. Visar berörda TAK-ar, dag för dag med historisk information från 10 april Statistik Visar statistik över det informationsutbyte som skett genom SLL:s RTP under önskat tidsintervall från och med 30 juli Statistiken visas per konsumerande tjänst och tjänstekontrakt, per anropande tjänsteproducent och tjänstekontrakt samt tjänstespecifikt. Tjänsteplattforms Databas (TP DB) Innehåller all information om alla integrationer och meddelanden inom SLL RTP. Tillhandahåller data för visning av statistik och för Hippo. Övrigt Se mer på rivta.se, skltp.se och vardgivarguiden.se/rtp.