ICC Västra Götalandsregionen Tillämpningsriktlinjer integration

Relevanta dokument
Långsiktig teknisk målbild Socialtjänsten

Lä s mer om SLL:s Regionälä Tjä nsteplättform (RTP)

Avtal om Kundens användning av Journal via nätet Bilaga 1 - Specifikation av tjänsten Journal via nätet (Enskilds direktåtkomst)

Integration. Pernilla Rönn,

Vägledning för innovativ applikations- och tjänsteutveckling

Framtidens vårdinformationsmiljö. September 2018

Hematologiinstrument för patientnära analys

Arkitekturella beslut Infektionsverktyget. Beslut som påverkar arkitekturens utformning

Projektdirektiv. Verksamhet och Informatik (1)

Informationsträff NPÖ

Tjänsteplattformen nationell integration

Svensk Kvalitetsbas kravstandard (1:2016)

Intressent- och behovskarta

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

Digital strategi för Strängnäs kommun

Arkitektur för ansökan/anmälan (utkast)

Nationell Informationsstruktur 2015:1. Bilaga 7: Arkitektur och metodbeskrivning

Tillsammans skapar vi framtidens vårdinformationsmiljö. God och Nära Vård - Skövde den 12 januari 2018

Nationell Tjänsteplattform och säkerhetsarkitektur. Per Brantberg, område arkitektur/infrastruktur

Svensk Kvalitetsbas kravstandard (2:2019) 1. Utfärdare 2. Revisorer 3. Verksamheter. Antagen den 15 maj 2019

Så blev arkitekturen ett kitt mellan IT och den övriga verksamheten

Förvaltningsmodell e- tjänsteplattform

VästKom Göteborgsregionens kommunalförbund. Digitaliseringsstrateg

LAT Lathund anslutning och test

RFI underlag - bilaga 2 Nuvarande Hjälpmedelstjänsten. Version 1.0

Villkor för anslutning till Nationella tjänsteplattformen

Introduktion till VITS-bokens tekniska arkitektur

Underlag för godkännande av tjänsteproducent

Checklista. Konsumentinförande via Agent, Nationell Patientöversikt (NPÖ)

Nationell geodatastrategi

HANDLINGSPLAN DIGITALISERING 2019

Framtidens vårdinformationsmiljö September 2018

RIV TA Basic Profile 2.1 med intygspropagering RIV Tekniska Anvisningar

Godkännande av kundapplikationer

Vad är eklient i Samverkan? Gemensamma krafter för framtida utmaningar

Anvisning och mall för namnsättning av tjänstedomän för tjänstekontrakt

Nationella Programmet för Datainsamling NPDI

Västra Götal an dsregi on en s regi on gem en sam m a styran de doku m en t

Svensk Miljöbas kravstandard (3:2013)

Information om upphandling av Framtidens vårdinformationsmiljö - FVM

Avtal om Kundens användning av

Riktlinjer för styrdokument Dnr 1-306/2019. Gäller fr.o.m

Vad gör en åsna i vården? Mats Ekhammar

VGR IT verksamhetsplan 2018

VERVA. Fujitsu Services Kenneth Landérus F

Beslutas att Rutin Följa upp miljömål, version 1.0, som ska börja tillämpas fr.o.m. den 12 september 2014.

Bilaga 2 Sammanställning av rekommendationer (ur Svenskt ramverk för digital samverkan)

Produktstöd - Vägledning till dokumentationskraven i SS-EN ISO 9001:2000

Framtidens vårdinformationsmiljö SLL

Referensarkitektur för U/H. Ola Ljungkrona Chalmers Per Hörnblad UmU

Undervisningen i ämnet mobila applikationer ska ge eleverna förutsättningar att utveckla följande:

Na tverksdag fo r ledningsansvariga inom Elevha lsans medicinska insats

Avtal om Kundens användning av Personuppgiftstjänsten Bilaga 1 - Specifikation av Personuppgiftstjänsten

SPF - sammanhållen detaljplanerings- och fastighetsbildningsprocess - ett samverkansprogram mellan Lantmäteriet och Boverket

Regler. för styrdokument i Munkedals kommun

RIV Tekniska Anvisningar Release notes

Sjunet Anslutningsavtal Standardregelverk för informationssäkerhet

HSA nätverksträff

Riktlinjer för styrdokument Örebro kommun

Framtidens vårdinformationsmiljö SLL

Nationell kraftsamling för kommunernas digitalisering. Sofie Zetterström, vice vd

Elektronisk remiss. Beskrivning och tjänstespecifika villkor

Riktlinjer för styrdokument

Sverige behöver en öppen teknisk lösning för kunskaps- och beslutsstöd inom hälso- och sjukvård!

TMALL 0141 Presentation v 1.0. Arkitektur på Trafikverket IT 23 oktober 2014

Kulturnämndens Regler för Innovationsstöd för film och rörlig bild

HSA Schemauppdateringsprocess. Version 1.2.1

Arkitektur och metodbeskrivning. Nationell informationsstruktur

Business Model Transformation. Banbrytande affärsmodeller genom transformation av affärsarkitektur

Avtal 1 om Agentens. användning av Ineras Tjänster

Formulärflöden (utkast)

HSA Tjänsteanslutningsprocess. Kriterier och anslutningsinstruktioner för tjänster som vill nyttja informationen i HSA

Kooperativa Förbundets policy för hållbar utveckling (HU)

Kommunens styrdokument

Nationell informationsstruktur 2016:1. Bilaga 7: Arkitektur och metodbeskrivning

IT-strategi för välfärdsteknik Beslutad av omsorgsnämnden

Insamling av hälsodata i hemmet

Regeringens mål för IT-politiken är att Sverige ska vara bäst i världen på att använda digitaliseringens möjligheter.

Införande av en integrationsplattform med Apache Service Mix på LTU

Med digitalisering utvecklar Inera ett hållbart samhälle i världsklass för alla

Kravstandarder för: 1. Utfärdare 2. Revisorer 3. Verksamheter

SIL SOAP API 4.0. beta prerelease

E-strategi för Strömstads kommun

Om öppenhet - format, standard och program. Mats Östling IT-strateg Sveriges Kommuner och Landsting Kommits

Samordningsprogram Hitta och jämför vård 2.0 Mål och aktuell status. April 2016 Sprint 8

IT-Policy för Tanums kommun. ver 1.0. Antagen av Kommunfullmäktige

Gemensam informationsstruktur i gemensamma e-tjänster. Niklas Eklöf, Socialstyrelsen Sonja Kantonen, Inera

Sammanträdesdatum Arbetsutskott (1) 35 KS/2016:51. Handlingsplan för e-hälsa i Östergötland

Framtidens vårdinformationsmiljö. Trollhättan

EA tillämpat genom integrationscentret. Johan Tuvstedt, Integrationsarkitekt

Integrationshandledning DHPC: Ny viktig säkerhetsinformation om läkemedel till hälso- och sjukvården

AL T granskning NeR Version 1.0

Gränssnitt och identiteter. - strategiska frågor inom Ladok3

ÄR KVALITETSREGISTREN EN GIVEN KÄLLA? Tveksamt

Uppdrag om nationell informationsstruktur och nationellt fackspråk

Strukturerad omvärldsbevakning. Version

Standardiserade API:er

Policy för öppen källkod RIV Tekniska Anvisningar

Teknisk guide för brevlådeoperatörer. Annika Melin Version: 1.1

Framtidens vårdinformationsmiljö Information för medarbetare

Transkript:

ICC Västra Götalandsregionen 2019-02-08 Tillämpningsriktlinjer integration

2 Versionshistorik Utgåva/Utkast Datum Beskrivning/Kommentar Utfärdat av 0.1 2018-10-25 Första utkast Erik Frumerie 0.2 2018-12-06 Första version för remiss Erik Frumerie 0.3 2018-12-13 Justeringar efter intern remissrunda inom ICClyftet. Erik Frumerie 0.4 2019-01-02 Uppdaterat med ny version av VGR IT-miljö. Erik Frumerie 0.5 2019-01-10 Uppdatering efter remisskommentarer från Noak Eldh, Lukas Welander och Andreas Bengtsson 1.0 2009-02-08 Godkänd för publicering av ICC-rådet. Kommentarer borttagna och version i pdfformat skapad för publicering på intranät och Öppna program Erik Frumerie Pernilla Abrahamsson Bilagor Utgåva/Utkast Dokumentnamn Utgåva Referenser Nr Dokumentnamn Utgåva 1 Integrationsstrategi för VGR 1.1 2 Styrmodell för IS/IT, Västra Götalandsregionen 3.2

3 Innehåll Versionshistorik... 2 Bilagor... 2 Referenser... 2 Inledning... 4 Syfte... 4 Bakgrund... 4 Drivkrafter... 4 Intressenter... 4 Styrning... 6 Tillämpningsriktlinjer... 6 Läsanvisning... 6 Princip 1: Information är en gemensam strategisk tillgång... 6 Princip 2: Tjänstebaserad integration (SOI)... 7 Princip 3: Lös koppling... 7 Princip 4: Minimera applikationspåverkan... 7 Princip 5: Standardiserade lösningar... 8 Princip 6: Mönsterdriven utveckling... 8 Princip 7: Följsamhet mot nationella arkitekturen... 9 Princip 8: Säkert informationsutbyte... 9 Princip 9: Den regionala tjänsteplattformen erbjuder den enda kontaktpunkten mot den nationella plattformen... 9 Princip 10: Offentliggör officiella tjänstekontrakt... 9 Princip 11: Använd plattformsoberoende och öppna standarder... 9 Princip 12: Integration mellan IT-stöd sker via VGR Tjänsteplattform... 10 Princip 13: Versionshantering av tjänstekontrakt... 10

4 Inledning Syfte Syftet med detta dokument är att ge tillämpningsriktlinjer av VGR Integrationsstrategi [Ref 1] fram till dess att ny målarkitektur för Integration är beslutad. Fram till att den nya målarkitekturen är beslutad gäller den nuvarande integrationsstrategin [Ref 1] som styrande dokument. Syftet med dokumentet är inte att ersätta strategin utan enbart fungera vägledande och förtydligande och ge indikationer om den kommande målarkitekturen. Bakgrund VGRs integrationsstrategi [Ref 1] antogs 2013 och en mindre revidering gjordes 2016. Under de åren som strategin använts har det visat sig att vissa principer som antogs inte har uppfyllt det syfte som först avsågs. Utöver det så täcker inte den existerande strategin nyare organisatoriska och tekniska tankar som självbetjäning (self service) och moderna lättviktiga APIer. En ny målarkitektur för integration för att ersätta den gamla integrationsstrategin är planerad att tas fram under 2019. Drivkrafter Drivkraften till att ta fram ett dokument med tillämpningsriktlinjer är främst för att kunna ge vägledning vid skapandet av alla integrationer till det nya kärnsystemet inom Framtidens Vårdinformationsmiljö (FVM) fram till dess att en ny målarkitektur för integration är skapad. Dock är tillämpningsriktlinjerna skrivna så att de täcker all systemintegration inom VGR, inte bara kärnsystemet inom FVM. Detta är även målsättningen med den nya målarkitekturen för integration. Intressenter Följande intressenter är relevanta att beakta vid skapandet av tillämpningsriktlinjer för integration. Intressent(grupp) Lösningsarkitekter Kommentar Medverkar i analys- och designaktiviteter i projekt och förvaltning för teknisk utformning. Behöver i detta arbete veta vilken strategi och riktlinjer som finns inom systemintegration på VGR för att kunna skapa korrekta lösningsarkitekturer. Integrationsarkitekter Medverkar i analys- och designaktiviteter i projekt och förvaltning specifikt med ansvar för att ta fram lösningsarkitektur för systemintegration(er). Behöver i detta arbete veta vilken strategi och riktlinjer som finns inom systemintegration på VGR för att kunna skapa korrekta integrationslösningar och specifikationer.

5 Arkitekturledningen Ansvarar för att rådge kring och godkänna lösningsarkitekturer inom VGR. Behöver i detta arbete veta vilka integrationsarkitekturer som är godkända eller ej. Domänarkitekt Ansvarar för att systemlandskapet för domänen uppfyller verksamhetens krav. Säkerställer att de lösningar som byggs passar in i ett längre tidsperspektiv. Behöver i detta arbete veta vilken strategi och riktlinjer som finns inom systemintegration på VGR för att kunna skapa korrekta domänarkitekturer. Integrationsdrift och Operativt Center Utför bevakning av driftsmiljöer, applikationer och integrationer. Det är viktigt att önskemål från integrationsdrift och operativt center tillgodoses i tillämpningsriktlinjerna så att integrationerna är möjliga att övervaka. Systemutvecklare inom ICC Arbetar med utveckling av nya och befintliga integrationer, kan delta i alla delar av en integrations livscykel såsom analys, design, implementering, test, förvaltning och dokumentation. Behöver i detta arbete ha kunskap om tillämpningsriktlinjerna. ICC-rådet Projektledare, Objektspeciallister och Objektledare ICCs styrande organ som är ansvarigt för att godkänna systemintegrationslösningar på VGR. Behöver i sina bedömningar tillämpningsriktlinjer att basera sina beslut på. Kan alla vara beställare av integrationslösningar. Behöver då veta vilka principer och riktlinjer VGR har för systemintegration för att kunna göra korrekta beställningar.

6 Styrning Dessa riktlinjer är framtagna av VGRs integrationsfunktion (ICC Integration Competency Centre). ICC och dess beslutande organ ICC-rådet ansvarar både för att ta fram riktlinjer inom systemintegration och för att säkerställa att dessa efterföljs. Om en riktlinje skulle ligga i konflikt med en annan strategisk princip eller riktlinje inom VGR, eller om ett projekt vill göra avsteg från en princip, ska frågan tas upp med ICC-rådet för beslut. Om beslutet inte kan godtas av motparten ska frågan eskaleras till VGRs Arkitekturledning. Se [Ref 2] kapitel 3.6 för mer detaljer om VGRs arkitekturstyrning. Arkitekturstyrning på VGR [Ref 2] Tillämpningsriktlinjer I detta kapitel listas alla principer i Integrationsstrategi VGR [Ref 1] samt förtydliganden och tillämpningsriktlinjer för varje princip. Läsanvisning Kommande kapitel ersätter inte integrationsstrategin [Ref 1] utan fungerar enbart som riktlinjer och vägledning hur den ska tolkas. Läsare som inte är förtrogen med integrationsstrategin bör ha den tillgänglig och läsa varje princip i strategin och sedan dess motsvarande tillämpningsriktlinje. Tillämpningsriktlinjerna är grupperade efter principerna i strategin och varje kapitel har samma titel som dess motsvarande princip i strategin. Kapitlen i tillämpningsriktlinjerna är inte skrivna för att kunna läsas för sig själva utan är enbart förtydligande och förklarande kring principtexterna i strategin. Princip 1: Information är en gemensam strategisk tillgång Denna princip kommer fortsatt att vara en av VGRs huvudsakliga EA-principer. Förutom konsekvenserna som är nämnda i Integrationsstrategin så ger den som konsekvens att

7 informationsflöde och informationsanvändning är överordnat systemmässiga uppdelningar. Det innebär också att integrationsgränssnitt alltid ska byggas med åtanke att de ska kunna återanvändas i andra sammanhang än för den specifika systemintegration som byggs upp (se vidare detaljer i princip 2 och 5) samt att strävan ska vara att all information i ett ITstöd ska vara tillgängligt via integrationsgränssnitt. Princip 2: Tjänstebaserad integration (SOI) Denna princip kommer sannolikt att skrivas om helt i kommande målarkitektur. Fortsatt viktigt är dock att integrationsgränssnitt alltid principiellt ska utformas som återanvändbara tjänster. Förutom att främja återanvändbarhet gör det också att det är enklare att definiera ägarskap samt att dokumentera upp tjänsterna. Notera att en tjänst inte nödvändigt måste utformas som en SOAP-baserad webbtjänst utan också kan vara baserad på messaging, REST eller till och med, i undantagsfall, fil. Det centrala är att den ska kunna beskrivas med ett tjänstekontrakt med en teknisk del (meddelandespecifikation, interaktionsmönster etc.) samt en del som beskriver vilka regler som gäller för att nyttja tjänsten (t.ex. hur ofta den får anropas eller juridiska begränsningar). En tjänst produceras av en eller flera producenter och används av en eller flera konsumenter. Princip 3: Lös koppling Denna princip är en av de viktigare i integrationsstrategin och kommer fortsatt att gälla. Det nuvarande princip saknar är bra definitioner av lös koppling och självbeskrivande. Med lös koppling menas att en integrerande applikation inte ska ha några beroenden till den applikation den integrerar med. Exempel på sådana beroenden är datamodell, protokoll, fysisk topologi eller interaktionsmönster. En integrerande applikation ska istället enbart förhålla sig till ett standardiserat meddelandeformat/tjänstekontrakt, protokoll och interaktionsmönster (se princip 5 och 11). För att stödja lös koppling bör bibehållen kompabilitet eftersträvas vid versionsförändring av meddelandeformat/tjänstekontrakt (se princip 13). En annan aspekt av lös koppling är att även regional tjänsteplattform ska vara löst kopplad till sina anslutande system på det sättet att den inte ska krävas hålla ett tillstånd baserat på anrop från integrerande applikationer. En integration på regional tjänsteplattform ska inte avkrävas att förhålla sig till hur föregående anrop eller svar såg ut eller hur nästa kommer att se ut. Den ska vara tillståndslös (eng. stateless). Med självbeskrivande menas att ett integrationsgränssnitt ska vara strukturerat, lätt att förstå och väl dokumenterat. Princip 4: Minimera applikationspåverkan Denna princip kommer sannolikt att tas bort eller kraftigt revideras i den nya målarkitekturen. Den har lett till att över tid har allt för mycket applikationsnära logik byggts in i tjänsteplattformen. Den strategiska inriktningen ska istället bli att applikationer som integrerar via tjänsteplattformen ska använda sig av regionalt beslutade integrationsmönster och -standarder (som i sig normalt baserar sig på nationella eller

8 internationella standarder, se princip 5 och 11). Om inte en anslutande applikation kan uppfylla de regionalt beslutade integrationsmönstren och -standarderna så är första lösning att använda en applikationsnära integrationslösning (Application Service Bus ASB eller Applikations-connector). I sista hand ska en anpassningstjänst (adapter) byggas på RTjP. Denna applikations-connector ska i sådana fall bekostas av och förvaltas av anslutande applikation. Integrationslandskapet enligt 3R FVM målarkitektur 1.0. Princip 5: Standardiserade lösningar Standardisering kommer fortsatt att vara en viktig princip i framtida målarkitektur och principer. Dock är princip 5 i Integrationsstrategin skriven så att den lämnar lite för mycket utrymme för tolkning. Essensen i principen är att systemintegration i största möjliga mån ska baseras på standardiserade/explicita informationsmodeller, terminologier, format och öppna standarder. En standard ska i första hand vara internationell, i andra hand nationell och i sista hand regional och måste inte vara en ISO-standard, utan kan också vara en de facto-standard. Den centrala integrationsfunktionen (ICC Integration Competency Centre) beslutar och ger vägledning om vilka standarder eller de facto-standarder som ska användas i olika sammanhang. Princip 6: Mönsterdriven utveckling Denna princip gäller fortsatt. Den centrala integrationsfunktionen (ICC Integration Competency Centre) tillhandahåller en mönsterkatalog som styr vilka mönster som är godkända för systemintegration och hur dessa ska implementeras. Utveckling som inte följer ett definierat mönster ska godkännas särskilt av ICC-rådet och kan vara underlag till att ett nytt eller förändrat mönster etableras.

9 Princip 7: Följsamhet mot nationella arkitekturen Denna princip kommer att ändras i kommande målarkitektur. Det centrala som fortsatt kommer att gälla är att VGR ska uppfylla den nationella arkitekturen enligt RIV-TA (Riktlinjer i Vården Tekniska Anvisningar) för samverkan med andra landsting eller vårdgivare. Det ska dock inte tolkas som att RIV-TA alltid är den styrande dogmen för all typ av systemintegration. Det finns scenarion där andra standarder eller de facto-standarder är mer lämpade (se princip 5). Princip 8: Säkert informationsutbyte Detta är i grunden inte en integrationsprincip utan en säkerhetsprincip. Principen om säkert informationsutbyte gäller dock fortfarande. Informations- och säkerhetsklassning ska styra vilka säkerhetsmekanismer som används för en systemintegration. För riktlinjer hänvisas till Enheten för Säkerhet och Beredskap (ESB) på VGR. Princip 9: Den regionala tjänsteplattformen erbjuder den enda kontaktpunkten mot den nationella plattformen Denna princip kommer fortsatt att gälla som den är skriven i Integrationsstrategin. Princip 10: Offentliggör officiella tjänstekontrakt Principen nämner tjänstekontrakt, men det ska inte tolkas som att enbart tjänstekontrakt enligt RIV-TA (Riktlinjer i Vården Tekniska Anvisningar) avses. Principen gäller även för andra gränssnittsspecifikationer som bygger på t.ex. HL7 eller REST. Det centrala är att det ska finnas en gemensam yta för utrönande av vad som finns av existerande, återanvändningsbara integrationslösningar (utbud). Denna yta ska förvaltas av den centrala integrationsfunktionen (ICC Integration Competency Centre) som också beslutar vilka gränssnittsspecifikationer som ska offentliggöras. Princip 11: Använd plattformsoberoende och öppna standarder Principen att använda plattformsoberoende och öppna standarder kommer fortsatt att gälla. Dock kommer denna princip att slås ihop med princip 5 i den kommande målarkitekturen. Se princip 5 för mer detaljer.

10 Princip 12: Integration mellan IT-stöd sker via VGR Tjänsteplattform Den principiella inriktningen kommer även fortsatt vara att integrationer generellt ska realiseras över VGR Tjänsteplattform. Kärnan är dock inte kravet på att alla systemintegrationer byggs via regional tjänsteplattform utan att den centrala integrationsfunktionen (ICC Integration Competency Centre) beslutar och ger vägledning om hur en systemintegration ska realiseras vilket kan innebära att den ska realiseras på ett annat sätt än via Regional Tjänsteplattform. Det centrala är att ICC äger mandatet att besluta vilka systemintegrationstyper som inte ska realiseras på Regional Tjänsteplattform samt att alla systemintegrationer, inklusive de som inte realiseras över Regional Tjänsteplattorm, ska komma ICC till känna. Det gör att ICC kan ta principbeslut kring nya integrationstyper samt kan föra en central dokumentation över alla systemintegrationer oavsett om de är realiserade över Regional Tjänsteplattform eller ej. En anledning att en integration får avsteg från att realiseras på regional tjänsteplattform är till exempel att regional tjänsteplattform inte stödjer interaktionsmönstret eller protokollet som krävs för integrationen. Princip 13: Versionshantering av tjänstekontrakt Denna princip kommer att delvis skrivas om och utvecklas i kommande målarkitektur. Det centrala är att det måste finnas en livscykelhantering av alla integrationsgränssnitt. Livscykelhanteringen innebär delvis att alla gränssnitt måste versionshanteras men också att det måste finnas en tydlig ägare till varje integrationsgränssnitt. Versionshantering innebär också förutom att ett integrationsgränssnitt ska ha en version så ska det finnas riktlinjer om hur länge flera versioner kan leva parallellt och under vilka premisser konsumenter och producenter måste uppgraderas att följa senaste version av ett gränssnitt. Det ska i dessa riktlinjer även framgå hur kompatibilitet upprätthålls eller bryts vid en versionsförändring. 2019-02-08 Dokumentnamn: Tillämpningsriktlinjer integration Diarienummer: Beslutad av: ICC-rådet genom Pernilla Abrahamsson Kontaktperson: Erik Frumerie, VGR IT, Administrativa System