Patientkunskap Beskrivning Tjänstekontrakt och API:er Version 1.0 Patientkunskap

Transkript

1 Beskrivning Tjänstekontrakt och API:er Version 1.0 1

2 Innehåll Inledning... 3 Tjänster grunden för systemintegrationen... 3 Tjänsteplattform... 3 Tjänstekontrakt... 4 Tjänster/API:er... 5 Koppling tjänstekontrakt och verksamhet... 5 Beskrivning av tjänstekontrakt... 7 Tjänstekontrakt Tjänstekontrakt Tjänstekontrakt Tjänstekontrakt Tjänstekontrakt Tjänstekontrakt Aktörsmatris Bilaga 1 - Förstudie Inledning Syfte Sammanfattning Tre aspekter av IT-arkitektur Vikten av en effektiv systemintegration Punkt-till-punkt integration Standardiserade meddelandetyper Tjänsteplattform Uppbyggnad Tjänsteproducenter Aggregerande och virtuella tjänster Tjänstekonsumenter Aktörer Pågående initiativ Proof-of-Concept regional tjänsteplattform D Mina remisser Formulärtjänsten Mina vårdflöden Argument och fördelar Öppen källkod

3 Inledning Syftet med denna beskrivning är att visa hur integrationen inom byggts upp med hjälp av tjänstekontrakt och API:er. Men syftet är inte enbart att beskriva innehållet i dessa, utan även visa hur integrationen knyter ihop olika delar av patient- och vårdgivarprocesserna. Målgruppen är främst personer med intresse och behov av att utveckla integrationslösningar mellan forsknings- och kvalitetsregister samt beslutsoch verksamhetssystem. Därför har beskrivningarna lagts på en nivå som inte kräver djupa IT- och integrationskunskaper, utan vi har valt att hänvisa vidare till andra dokument och lösningar där utvecklare och arkitekter kan fördjupa sig för att exakt kunna avgöra om befintliga lösningar fyller de egna behoven eller om ytterligare utveckling krävs. Som bilaga till denna beskrivning har vi valt att lägga in den förstudie som föregick själva utvecklingsarbetet, eftersom den beskriver de alternativ och frågeställningar som föregick själva integrationsutvecklingen. Tjänster grunden för systemintegrationen För att komma ifrån en situation där allt större andel av budget och ITresurser satsas på att utveckla nya integrationer mellan system, har man från Ineras sida arbetat med att bygga upp en arkitektur som syftar till att skapa en flexibel och skalbar arkitektur där all data enbart matas in en gång. Arkitekturen bygger på tre grundstenar: 1. Tjänsteplattform 2. Tjänstekontrakt 3. Tjänster/API:er Rekommendationen i förstudien var att bygga på denna arkitektur, något som man tagit fasta på i projektet och haft som grund för sitt utvecklingsarbete. Hur dessa tre komponenter används vid uppbyggnaden av datautbytet inom ramen för beskrivs närmare nedan, men beskrivningen inleds med att presentera dessa tre begrepp lite närmare. Tjänsteplattform Tjänsteplattformen är den tekniska infrastruktur som tar hand om integrationen mellan fler och fler av sjukvårdens system. Tjänsteplattformen kan liknas vid en korridor, där varje dörr i korridoren representerar ett system som är kopplat till själva plattformen. Dörrarna leder till bakomliggande verksamhetssystem och de har fördelen av att vara standardiserade med en tydlig beskrivning av vart de leder och hur de öppnas/stängs. Tjänsteplattformen finns dels på nationell nivå för de kopplingar som är gemensamma för hela landet, men plattformen finns även på regional nivå (i stort som kopior av den 3

4 nationella), främst för att förbättra prestanda samt för att hantera de integrationer som är utvecklade för att fungera i enskilda landsting. Tjänsteplattformen fungerar så att olika tjänster publicerar/prenumererar på information, vilket gör att man inte behöver utveckla skräddarsydda funktioner för att skicka data mellan olika system eller för att publicera dessa direkt för användare. För mer information om tjänsteplattformen läs vidare på Ineras hemsida här: och på Health Innovation Platform (HIP). Tjänstekontrakt Om tjänsteplattformen är korridoren utgör tjänstekontrakten de olika dörrarna i denna korridor. Tjänstekontrakten består av dokument som beskriver hur olika tjänster är uppbyggda och vilken data som utbyts med hjälp av olika tjänster. Eftersom tjänstekontrakten har en standardiserad uppbyggnad, är det relativt enkelt att förstå hur datautbytet går till och vilka data som är tillgängliga via de olika tjänster som bygger på dessa kontrakt. Ett tjänstekontrakt kan omfatta en eller flera tjänster. För har totalt sex stycken tjänstekontrakt definierats. Tjänstekontrakten inom vården kallas för RIV-kontrakt och deras uppbyggnad presenteras närmare på Google Code i så kallade RIV Tekniska anvisningar. Dessa återfinns på webbplatsen 4

5 Tjänster/API:er Tjänster är den strukturerade och återanvändbara kod som utför det som finns i specificerat i respektive tjänstekontrakt. Dessa finns inkluderade som kodexempel via de länkar som angivits för respektive tjänstekontrakt. För dessa koncept (och för flera andra delar av den tekniska plattformen), finns ett antal produktblad framtagna som på ett enkelt och övergripande sätt visar hur dessa delar samverkar. Dessa produktblad återfinns på webbplatsen Koppling mellan tjänstekontrakt och verksamhet Hela patientflödet inom ramen för har utvecklats med hjälp av Service Design metodiken. Resultatet har beskrivits och dokumenterats med hjälp av en så kallad Service Blueprint. För att inte skapa ytterligare beskrivningsmodeller, har vi valt att lägga in en referens till tjänstekontrakten i denna Service Blueprint nedan. En Service Blueprint visar: Patientaktiviteter vilka steg går patienten igenom i aktivitetsflödet? Vårdaktiviteter vilka åtgärder vidtar vården för att möjliggöra detta? Information till/från patient vilka informationsflöden initieras p.g.a. detta? Bakom kulissen (patient/vård) vilka system och aktiviteter involveras som bara patienten respektive vården ser/har tillgång till? Tjänstekontrakt hur integreras de olika systemen med hjälp av tjänstekontrakt? 5

6 Syftet med en Service Blueprint är att visa såväl processtegen som hur dessa påverkar och påverkas av den information som dessa ger upphov till. 6

7 Beskrivning av tjänstekontrakt Nedan beskrivs de sex tjänstekontrakt som utvecklats i syfte att stödja den process som beskrivits ovan. För en djupare teknisk beskrivning av samtliga tjänstekontrakt hänvisas till Google Code. Mer information återfinns här: De tjänstekontrakt som tagits fram i projektet har följande syften: Kommunikation mellan Journal och Beslutsstöd RA Tjänstekontrakt 1 & 2 Kommunikation mellan PER/Beslutstöd och det framtida personligt hälsokonto Kommunikation av biomarkörer mellan forskningsdatabas och Beslutsstöd Kommunikation av kemlabbdata mellan Journal och Beslutsstöd RA Tjänstekontrakt 3 & 4 Tjänstekontrakt 5 Tjänstekontrakt 6 Tjänstekontrakt 1 Syfte Vården sänder strukturerad data från beslutsstödsystem RA till journalsystemet (TakeCare). Journalsystem TakeCare Beslutstöd system RA Information Från RA beslutsstöd sänds information till journalsystemet TakeCare. Informationen omfattar upp till ett drygt 30-tal informationsvärden om patienten, inklusionskriterier för att ytterligare specificera hur RA yttrar sig hos patienten, information om vårdpersonal och vårdenhet, diagnostyp samt läkemedelsinformation (se specifikation via länk nedan). Länkar till teknisk information 7

8 Tjänstekontrakt 2 Syfte Vården registrerar beslutsstödsdata via journalsystemsmallar (TakeCare). Journalsystem TakeCare Beslutstöd system RA Information Via journalsystemets mallar ges möjlighet att registrera patientdata i beslutssystem RA. Informationen omfattar samma information som ovan skillnaden är att man här hämtar data till beslutsstödet från journalsystemet istället för tvärt om. Länkar till teknisk information Tjänstekontrakt 3 Syfte Utlämning av patientdata från Patientens Egen Registrering (PER) till externa tjänster, typ nationellt Hälsokonto, via API Gateway. Tjänsten ska också kunna användas för att kunna lämna ut data via andra tjänster än PER. 8

9 Observera att implementeringen av det nationella Hälsokontot har försenats på grund av överklaganden och krav på att upphandlingen ska göras om. Därför har hela kedjan från PER till Hälsokontot inte kunnat testas! Information Information från patienten om upplevd smärta och svullnad i totalt 28 leder Länkar till teknisk information Tjänstekontrakt 4 Syfte Information från patienten respektive läkaren om upplevd smärta och svullnad i totalt 28 leder, information om labbvärden samt information om läkemedel. För tjänstekontrakt 4 kommer troligen hanteringen att ändras jämfört med ursprunglig plan. När tjänsten planerades, fanns det ingen Formulärtjänst tillgänglig,men i och med att denna utvecklats parallellt inom ramen för projektet Mina Vårdflöden, kan en effektivare hantering genomföras. Istället för att patientappen direkt uppdaterar beslutsstödet som planerats, hämtas istället det formulär som ska användas. När formuläret är uppdaterat, registreras detta i Formulärtjänsten. Beslutsstödet för efter detta en notifiering från Formulärtjänsten och kan då hämta det ifyllda formuläret. Fördelarna med detta blir en mer flexibel hantering som bygger på de tjänster som redan tagits fram. Observera att implementeringen av det nationella Hälsokontot har 9

10 försenats på grund av överklaganden och krav på att upphandlingen ska göras om. Därför har hela kedjan från PER till Hälsokontot inte kunnat testas! Information Information från patienten respektive läkaren om upplevd smärta och svullnad i totalt 28 leder, information om labbvärden för sänka och CRP samt information om läkemedel (namn, dos, start/stopp, anledning till utsättning av läkemedel, typ, samt intervall för intag). Länkar till teknisk information 10

11 Tjänstekontrakt 5 Syfte Tjänstekontraktet notifierar Beslutsstödet när ett positivt labbsvar inkommit i den federerade forskningsdatabasen T-MedFusion, som innehåller information från ett flertal olika forskningsdatabaser. Information Idag hanteras registrering av ACPA-prover, då förekomsten av denna biomarkör har visat sig ha en negativ inverkan på RA-patienters sjukdomsförlopp. I framtiden kommer även andra biomarkörer kunna följas via detta tjänstekontrakt. Länkar till teknisk information Tjänstekontrakt 6 Syfte Överföring av kemlabbsvar från Journalsystem till Beslutsstödsystem RA. Journalsystem TakeCare Beslutstöd system RA Information Innehåller information om typ och datum för prov, sammanfattning av resultatet, måttenhet, om det är ett patologiskt resultat eller inte samt eventuell annan referensinformation. 11

12 Länkar till teknisk information 4d/wiki/GetClinicalChemistryLabOrderOutcome 12

13 Aktörsmatris Aktörsmatrisen nedan syftar till att ge en bild av vilka system som är inblandade i de integrationer som hanteras av de sex tjänstekontrakt som utvecklats inom ramen för patientkunskap. Beslutssystem RA Jounalsystem TakeCare T-MedFusion Patientens Egenregistrering Formulärtjänst Personligt Hälsokonto PER TjK1 x x TjK2 x x TjK3 x x x TjK4 x x x TjK5 x x TjK6 x x 13

14 Bilaga 1 - Förstudie Förstudie - IT-arkitektur - Styrande principer Version

15 Inledning Syfte Syftet med detta dokument är att specificera de styrande principer som bör gälla för QRC:s framtida plattform(ar) för kvalitetsregister. Tanken är att dokumentet ska kunna tjäna som utgångspunkt för kravställning och diskussion med plattformsleverantörer för att aktivt driva utvecklingen i önskad riktning. Dokumentet vill vara en del av skapandet av en gemensam bild inom QRC för de principer som bör gälla. Bilden kan sedan stämmas av mot andra nationella registercentras målbilder för att skapa klarhet i om det finns en gemensam linje som bör drivas inom arkitekturområdet. Sammanfattning Rekommendationerna kring QRC:s IT-arkitektur fokuserar sig kring två områden: Integration via en (regional eller nationell) tjänsteplattform enligt de nationella reglerna och riktlinjerna. Öppen källkod enligt CeHis definition av öppen källkod, genom att förorda tekniska och arbetsmässiga lösningar som bidrar till och uppmuntrar ett aktivt utbyte av idéer, kunskaper och erfarenheter. Dessa två rekommendationer samverkar, då tjänsteplattformen är uppbyggd kring öppna standards. Informationen utbyts sedan med hjälp av tjänstekontrakt. Dessutom ger det nationella SDK-verktyget helt nya utvecklargrupper tillgång till vårddata, vilket i sin tur bör leda till en breddning av de lösningar som erbjuds. Tre aspekter av IT-arkitektur Vi har valt att i dessa sammanhang grovt dela in IT-arkitektur i tre aspekter: Utvecklingsprinciper - de grundläggande tänkesätt som ligger bakom den enskilda utvecklingsinsatsen och den arkitektur detta har lett till nedan. Detta kan exempelvis handla om att man har baserat hela sin utveckling kring en viss plattform (Microsoft, Oracle, Öppen källkod etc.) och de arbetssätt som styr hur utvecklingsarbetet bedrivs. Utvecklingsprinciperna tas i detta sammanhang upp på en övergripande nivå kring öppenhet och samarbete i utvecklingsarbetet. Intern IT-arkitektur - hur olika registerplattformar utformas internt och vilka verktygssviter och ramverk som använts vid utvecklingen av dessa. Denna aspekt berörs inte i detta dokument. Anledningen är att det inte finns någon utvecklingsmetodik eller verktygssvit som per definition är bäst för att bygga upp ett kvalitetsregister. Valen inom detta område speglar istället främst den enskilda leverantörens kompetens, behov och 15

16 strategiska val. I en etablerad IT-organisation med en stor systemportfölj kan det ibland vara viktigt att noga beakta denna aspekt - men risken finns alltid att man då väljer lösningar på tekniska istället för funktionella grunder. Vi har därför valt att inte betona denna del. Extern IT-arkitektur - hur registerplattformarna kommunicerar med sin omvärld i form av externa tilläggstjänster och kopplingar mot andra system (journalsystem, labbsystem etc.). Vi lägger tonvikten på denna aspekt, eftersom kvalitetsregister till sin natur är ett område som samlar in information från många källor. Dessutom är detta ett område där det idag pågår många initiativ inom SLL och andra landsting. Vikten av en effektiv systemintegration Punkt-till-punkt integration Allt sedan datorernas intåg under 1950-talet fram till det tidiga 1990-talet var den huvudsakliga metoden att koppla ihop olika system med varandra så kallad punkt-till-punkt integration. Detta innebar att varje enskilt par av system som behövde utbyta data gjorde detta via en integrationslösning som utvecklades specifikt för detta behov. Metoden är enkel att komma igång med och effektiv om man har få system som ska utbyta data (har man t.ex tre system som behöver kommunicera med varandra behövs bara tre kopplingar utvecklas, men har man fem system växer antalet systemkopplingar till tio! I takt med att antalet system idag räknas i flera hundra, blir en metod som bygger på punkt-till-punktlösningar snabbt ohanterlig. Standardiserade meddelandetyper För att bringa ordning i problemet var nästa steg att övergå till standardiserade meddelandetyper och informationstyper (termer). På så sätt kunde man enas om hur system kunde utbyta data med varandra och därigenom minska problemen med speciallösningar - men i takt med att systembegreppet började lösas upp och mer och mer ersättas av tjänster (där funktionalitet och data kopplas samman) krävdes det nya sätt att se på systemintegration. 16

17 Tjänsteplattform Från och med mitten av 1990-talet gick därför fokus mer och mer över mot en tjänsteorienterad arkitektur (service-oriented architecture eller SOA). När det nu blev fråga om mängder av tjänster som skulle utbyta information baserad på olika tjänsteförfrågningar, behövdes ett nytt tänk - och detta resulterade i tjänsteplattformen - ett mellanlager mot vilket systemen kopplas på ett standardiserat sätt. Genom tjänsteplattformen kunde nu en koppling utvecklas mellan respektive system och tjänsteplattform - och denna kunde återanvändas (efter utveckling för varje användare) av alla olika instanser av samma system. Detta betyder att om kopplingen är specificerad och utvecklad (vilket i SLL-världen görs i form av ett så kallat RIV-kontrakt) kommer den att kunna användas av samtliga systeminstallationer (t.ex. av ett visst journalsystem) utan att nya kopior av denna behöver installeras. Data blir helt enkelt smidiga tillgängliga via tjänsteplattformen, som med hjälp av en vägvalstjänst, håller reda på vilka system som publicerar och prenumererar på vilken information. Inom SLL pågår ett intensivt arbete att samordna utvecklingsinsatser för att minska integrationskostnaderna (enbart Hälso- och sjukvårdsförvaltningen i Stockholm har en uppskattad integrationskostnad mot TakeCare ca 10 MSEK för 2012 _ ) och minska antalet integrationsuppdrag som idag tar upp en allt större andel av tid och budget från leverantörerna av vårdsystem. SLL har idag flera olika integrationslösningar och ett av syftena är därför också att minska antalet integrationsplattformar för att därigenom bidra till standardisering och effektivisering. CeHis har utvecklat förutsättningar för detta via arbetet med integrationsplattformen nationella tjänsteplattformen. Arbete pågår nu i landstingen att ta denna i bruk och påvisa dess lämplighet. QRC:s timing inom detta område är god - inom SLL pågår just nu ett antal proof-of-concepts för att testa och påvisa den regionala 17

18 tjänsteplattformens fördelar. Uppbyggnad Inom SLL undersöks hur man kan implementera den nationella tjänsteplattformen som en regional tjänsteplattform som i stort är en kopia av den nationella. Den regionala tjänsteplattformen har tillkommit för att underlätta inkopplingen av det stora antal system det är fråga om. Tjänsteplattformen består av ett antal olika delar som övergripande beskrivs nedan _ Tjänsteproducenter Här återfinns alla verksamhetssystem, tjänsteväxlar för att på ett säkert sätt koppla in visa lösningar samt de stödtjänster som krävs för att de virtuella tjänsterna (se nedan) ska veta i vilka grundsystem den efterfrågade informationen finns. Aggregerande och virtuella tjänster De aggregerande tjänsterna tar emot informationsbegäran från de överliggande tjänstekonsumenterna (de system/tjänster som efterfrågar information). När begäran tagits emot ställs frågan samman och skickas till de virtuella tjänsterna som med hjälp av stödtjänsterna söker upp rätt information i verksamhetssystemen och/eller via partnerutgången. 18

19 Informationen skickas tillbaka till de aggregerade tjänsterna som ställer samman svaret och skickar detta åter till tjänstekonsumenterna. Tjänstekonsumenter De tillämpningar som efterfrågar information från verksamhetssystemen. Aktörer Olika användarkategorier - individer med olika roller eller tekniska informationsdistributörer som SHS (Spridnings och Hämtnings System). Pågående initiativ Proof-of-Concept regional tjänsteplattform Test av den regionala tjänsteplattformen och SDK via några proof-ofconcepts för att säkerställa konceptets användbarhet, tillförlitlighet och funktionalitet. 4D 4D-projektet belyser hur hälso- och sjukvården kan utformas och bedrivas i samklang med forskningens och utvecklingens behov samt belysa hur forskningens resultat effektivt kan överföras i klinisk praxis genom en pilotstudie med fyra diagnoser. Mina remisser Projektet är i pilotfas och syftar till att tillgängliggöra patienters remissflöde (ej innehåll i form av provsvar etc.) på mobila enheter eller via webben. Projektet genomförs under hösten 2012 och bedrivs tillsammans med ett antal vårdcentraler i Stockholmsområdet. Projektet är en delleverans inom ramen för Mina vårdflöden nedan. Formulärtjänsten Denna tjänst utvecklar ett antal tjänster och gränssnitt som ex.vis journalleverantörer kan använda för att direkt länka in mot vårddata, kallelser etc. och skicka ut enkäter till patienter. Dessa enkäter/formulär kan antingen skickas manuellt eller automatiskt baserat på kallelser och tidbokningar och informationen görs tillgänglig för läkaren direkt vid vårdbesök. Tjänsten har stor potential att vidareutvecklas inom bland annat kvalitetsregisterområdet. Mina vårdflöden Samfinansierat projekt mellan SLL och Vinnova som syftar att ge patienter en totalöversikt över sitt vårdflöde såväl framåt som bakåt i tiden. Såväl Mina remisser som SDK är exempel på delprojekt inom denna leverans. 19

20 Argument och fördelar Det finns ett antal fördelar med den nationella/regionala tjänsteplattformen: Skapar återanvändbara integrationstjänster Skapar möjlighet att på ett smidigt sätt kombinera olika informationsmängder från olika källor till nya säkra tjänster Hela marknaden bjuds in att skapa tjänster baserade på vårdens information Hela marknaden bjuds in att skapa innovativa kompletterande tjänster som syftar till att stödja patientens och vårdens informationsflöden Skapar möjligheten att utveckla nya tjänster på det som redan finns Ändrar eller stör inga lokala processer business as usual med nya möjligheter Inga krav på att data skall centraliseras i nya datalager Återanvänder digitaliseringen av alla lokala system i hälso- och sjukvården QRC kan alltså på detta sätt följa de SLL-standarder som börjar byggas upp. Samtidigt får man möjlighet att utvärdera de testprojekt som nu genomförs för att därigenom dra värdefulla erfarenheter och skapa kontakter som kan användas i det fortsatta arbetet med registerleverantörerna. Genom att ansluta sig till detta koncept, kan QRC också verka för spridningen av lösningar som baseras på informationen inom SDK - något som bör förenkla upphandlingsförfarandet betydligt. 20

21 Öppen källkod Inom kvalitetsregisterområdet finns det idag en mängd olika tekniska lösningar som baseras på olika utvecklingsplattformar. Som påpekas i avsnittet Tre aspekter av IT-arkitektur ovan, tar vi inte ställning till vilka av dessa som är bättre eller sämre - utom när det gäller källkod. Alla system baseras idag på produkter som kontinuerligt utvecklas och förfinas av de experter som använder dessa i sitt dagliga arbete och bidrar med dessa förbättringar till sina kollegor och i slutänden till användarna av de lösningar som tas fram. Flera av dessa produkter kan användas helt utan licenskostnader, medan man i andra fall kan/vill använda varianter där man betalar för användningen för att därigenom tillförsäkra sig en variant som är testad och där man kan få support och/eller utbildning. Detta gäller också i hög grad för de registerlösningar som utvecklas. Öppen källkod är inte automatiskt lika med gratis eller fritt tillgänglig i dessa sammanhang! Istället ger denna typ av verktyg kommersiella utvecklare möjlighet att utveckla lösningar som inte måste baseras på höga licenskostnader för slutanvändaren, vilket motverkar inlåsningseffekter, pressar utvecklingskostnaderna (större utvecklarbas) och i slutänden bör bidra till ett lägre pris för kvalitetsregistren. QRC bör därför aktivt delta i denna utveckling för att få till stånd en kostnadseffektiv utveckling av framtida registerlösningar. Dessutom bör också slutprodukten (i form av nya register, beslutsstöd etc.) och dess arbetsprocesser vara uppbyggda på ett sådant sätt att användarna enkelt kan bidra med förbättringsförslag, felrapporter och frågor till utvecklingsteamet, så att kvalitetsregistrens utveckling blir aktivt användardriven. Arbetet med tjänsteplattformen är också en del i detta arbete. Genom denna och det SDK som utvecklas, får externa utvecklare inom och utanför vården helt nya möjligheter att använda vårddata på ett tekniskt och juridiskt korrekt sätt. Efter licensiering kan helt nya användargrupper nu kan bidra med att kombinera vårddata med extern data i lösningar som tidigare inte varit möjligt. 21