Tekniska arkitekturen för vården RIVTA 2.1 2013-04-17

Vision för arkitekturen och de taktiska stegen Målarkitektur Framtidens arkitektur Roadmap mot visionen Strategiskt Mål 2 O.s.v. mot visionen* Strategiskt Mål 1 Uppnått Läge 2 Just enough – Just in time En grundläggande princip inom EA-konceptet är ”Just enough, Just in time”, Principen innebär enkelt att man jobbar med en strategiska mål inom planeringshorisonten. baserat på kända konkreta behov, och i riktning mot en målbild kallad ”framtidens arkitektur” som utformats på en lagom grov nivå utifrån aktuell verksamhetsstrategi. Genom att mäta vad resultatet blev under t.ex. en verksamhetsplan kan man få fram deltat = skillnaden mellan tänkt läge och faktiskt uppnått. Denna skillnad kan därmed tas med i planeringen för nästa strategiska läge. Om vi låter denna iterativa process upprepas kommer vi förhoppningsvis allt närmare den vision vi ställt upp. Själklart skall visionen revideras med jämna mellanrum för att tillse atty inte den blivit omodern. Taktiska delmål Dagens arkitektur Taktiska delmål Delta * Uppnått Läge 1 Nuläge * Delta är skillnaden mellan önskat läge och det faktiskt uppnådda

Nyttoeffekter av god arkitekturstyrning Utveckling av IT-stöd underlättas Projekt- och förvaltningsobjekt blir kostnadseffektiva Kortare ledtid till leverans Minskad komplexitet Ett belysande exempel På innovativa lösningar, men risken för inlåsning är överhängande.. Vem ansvarar för helheten? Bra bild att få upp frågan om vad arkitekturen / planering kan tillföra i det goda exemplet. AdHoc är inte alltid önskvärt. Det är inte heller önskvärt att olika aktörer gör egna specifika lösningar isället för att följa den arkitekturella strategiska vägen. Vad är en trappa? Visar vikten av tydlig kravbild.

Samhällets behov av framtidssäker IT-infrastruktur Federativ lösning för alla olika uppdrag och organisationer Media Skola Miljö Omsorg Kultur Fastighet & Bygg Industri Handel Vård Transport Jordbruk, skog Turism Hantverk Fritid Bank & Försäkring Telekom Lokalt näringsliv FoU El, värme & VA e-id standards domänhantering affärs- modeller licenser transmission Protokoll, IP avtal tekniska plattformar behörighet juridik gränssnitt lagring signering Radio kopparnät TV 3G tomrör PLC lokala nät (fiber) kabel-TV ADSL GSM WiMax radiolänk stomnät WiFi fastighetsnät e-förvaltning processer & service verksamhetsutveckling Mobilitet Mjuk infrastruktur Interoperabilitet Nåbarhet Hård infrastruktur Tillgänglighet IT-infrastruktur förvaltas idag av ett flertal aktörer, nätägare. Elektronisk kommunikation måste som regel passera genom flera aktörers utrustning för att nå en viss mottagare. Störningar i trafiken kan orsakas av fler olika händelser som t ex avgrävd kabel eller fel i elektronisk utrustning för kommunikation. Felsökning måste följaktligen göras av alla inblandade aktörer i händelse av trafikstörning. Det går inte att förutse när trafikstörningar kan uppstå och dagens affärsmodeller ger som regel inte kunden någon garanti för viss trafik kommer fram i rätt sammanhang. Samverkan mellan berörda aktörer bygger idag på frivilliga affärsmässiga förhållanden, Service Level Agreement (SLA). Dagens SLA reglerar som regel i huvudsak ansvarsförhållandet mellan operatörer och omfattar inte garantier för kundens behov . Detta kan inte accepteras som grund för samhällsviktiga elektroniska tjänster, t ex trygghetslarm för äldre, och därför måste nya affärsmodeller tillföras marknaden som ger offentlig sektor möjlighet att upphandla effektiva elektroniska kommunikationer som bygger på: Samtrafik, Prioritet av vissa tjänsters tillgänglighet, Vidaresändningsplikt av vissa tjänster i näten, Säker identifiering i informationsöverföringen Den fråga som detta ställer är hur detta ska finansieras. Ska vissa krav på ovanstående tillgodoses genom finansiering genom allmänna skattemedel eller ska det fortsatt finansieras inom sektorn, d v s av operatörerna och deras kunder? En ytterligare viktig fråga att ta upp i samband med denna bild är att det är absolut vital att man har tillit till att olika kategorier av kunskap får göra sin del av kakan. En bra jämförelse är husbyggen När konsumenten väljer att upphandla en leverantör (husbyggare) så tittar man på funktion, utseende och möjligen arkitektur i form av ritningar. Det är troligen många gånger så att eldragningar, grunduppbyggnad, handikappsanpassning m.fl. reglerade områden inte alls finns med det förväntas bara fungera. Husarkitekter och byggnadsingenjörer gör nog sitt jobb. Detta för att inte tala om det lägsta lagret infrastukturen i form av stadsplaner, avloppsnätsuppbyggnad sam elnäts dimensionering. Det skall bara fungera.

T-boken Finns dels som fullständig. Denna kan vara tung att läsa. Finns även som ”Introduktion till T-boken” som är väsentligt lättare att läsa Mer information finns på http://www.cehis.se/arkitektur_och_regelverk/fordjupad_information/regelverk/ Denna bild kan med fördel användas till att beskriva vilka målgrupper som respektive utgåva har. Den stora T-boken är mer riktad till de arkitekter och utvecklare som vill skriva SAD eller annan teknisk design dokumentation. Den innehåller regler och mönster inte kodningsanvisningar. Länken leder till CeHis site där alla information om det aktuella regelverket finns. Detta inte bara för den tekniska arkitekturen. Introduktion… är mer lämpad för alla som inkörsport och för de icke djupt tekniska som vill förstå vad som finns i T-boken. I denna presentation stannar jag på denna nivå. T-boken behöver ett föredrag i sig själv om den skall förklaras i sin helhet.

Säkerhetsvy med federation (SAMBI) Medlemmar i SAMBI litar på att alla IDP:er följer uppsatta regler som fastställts inom federationen SAMBI Org 1-nät Org 1-nät RIVTA2.1 i öppet, gemensamt nät Org 2-nät SAML IDP Fördelar ur ett säkerhetsperspektiv: Undvika aktiviteter i brandvägg för varje bilateral relation eller hantering av en mängd klient-cert. Gäller även för statliga myndigheter (FK, Apotekens Service) etc. Ge SSO Ge sömlösa hopp mellan federationsmedlemmar Tillföra tillit inom federationen Kräver utbruten säkerhets och inloggning Org 4-nät Org 3-nät (informations-ägare) Organisationstillit “Brokered Circles of trust”: SITHS Funktion, https/tls, TP Tjänsteadresseringskatalog: “Org1 får nå Org2:s info genom tidbokningskontraktet” etc

Övergripande arkitektur RIVTA 2.1 + TP Denna bild är den första i raden av bilder som kommer försöka beskriva vad det är för helhet som vi försöker skapa över tiden. Det gäller i denna bild att ta med en stor mängd * aktörer * system * platser Informationsmängder Stödfunktioner För att få detta att sitta ihop och inte spreta fullständigt kommer den övergripande arkitekturella bilden in. Detta ger att för att slippa onödiga (troligen omöjliga) administrationskosstnader för punkt till punktintegrationer behöver arkitekturen tjänsteplattform med virtuella tjäster. Lite torrare formulerat I informationssystemvyn beskrivs en generell arkitektur (referensarkitektur) för att realisera behoven ur verksamhetsvyn. Beskrivningen består av en referensmodell för tjänsteorienterad integration och ett antal vägledande exempel. Informationssystemvyn beskriver också tjänstekontrakt som strategi för semantisk interoperabilitet och lös Koppling. Referensmodellen illustrerar schematiskt referensarkitekturens beståndsdelar. Pilarna, som symboliserar användning av SOA-tjänster, visar exempel på hur beståndsdelar av olika slag kan samverka: Till dessa vyer hör sedan ett regelverk som måste följas för att helheten skall fungera som avswtt. = RIVTA 2.1

Gemensam plattform – Tekniska komponenter i TP Vägvalsrouter VM Tjänsteproducent Virtuell tjänst HTTPS/TLS Tjänstekonsument Mule ESB Message Tjänstekatalog HTTP En per tjänste-kontrakt Tomcat, MySQL Generell: oberoende av tjänstekontrakt, cachening av data från Tjänstekatalog, statistik över svarstider. http-åtkomst av anropsstatistik och funktion för omladdning av cache. I denna 2:a bild vill jag bara ge en möjlighet att se vad som finns ” i magen ” på TP. Dessa delar stödjer i sin tur alla de olika mönster som kan återfinnas i T-boken. Tillhandahålls som öppen källkod, inkl. anvisningar på EU:s projektplats för öppna myndighetsprojekt(https://code.google.com/p/skltp/) 8

Tjänsteplattformar in en tjänsteorienterad arkitektur Gemensam plattform (TP) Virtuell tjänst Fysisk tjänst (Producent) Röd lokal tjänst Svart gem. tjänst A NPÖ Fr. tj. B Befolkn. tj. C Tidbokn. tj. Gemensamma virtuella kontrakt B A NPÖ VGR VF B Befolkn. Tj. Tidbok TC C Tidbokn.tj. D Psyk. Tj. Tjänste- katalog Lokal VGR SLL Dalarna C Örebro Bild för att förklara hur flödet går när vi har lokala plattformar med virtualisering och därigenom gemensamma kontrakt som kan komma upp på gemensam nivå endast genom registrering i databas. Har med flit inte ritat in konsumenterna eftersom det gör bilden alltför rörig. Det kommer på senare bild. Förklaringen blir då ungefär Vi gör ett korrekt RIVTA 2.1 kontrakt lokalt t.ex. VGR 2. Kod för detta skapas i någon producent lokal VGR och då får vi en röd tjänst. Rätt standard men ännu inte publicerad utanför den lokala nivån. B. Detta kan även ske nationellt som t.ex NPÖ A Då kommer tjänsten direkt gemensamt. Publicering sker på lokal TP och tjänsten finns inom denna räckvidd. Direkt när det finns flera producenter kan samma tjänst lyftas till gemensam nivå med samma kontrakt och detta ger då lokalt driven tjänsteutveckling och samtidigt nationell publicering. B För D så görs kontrakten rätt och de skall godkännas av AL för att kunna bli gemensamma. Så fort detta är klart kan D bli ”samma” som B Den gemensamma plattformen har i sin tjänstekatalog stryrinformation om vart aktuellt anrop skall baserat på verksamhetsbaserad (VG+VE) adressering. Lokalt blir det det omvända finns inte någon producent lokalt försöker man med den gemensamma tjänsten i stället.

Engagemangsindex i regional tjänsteplattform Tjänsteplattformen Källa NPÖ MVK EI Regional tjänsteplattform Bild för att förklara begreppet EI. Det viktiga är att trycka på 1 INTE data 2 Inte Tjockt 3 Bas för att bygga alla möjliga applikationer på nytt sätt via EI + tjänster. 4. Finns som implementation med notifiering och lokal + gemensam del. De kommunicerar med varandra. 5. INTE åtkomligt som tjänst utan endast ett hjälpmedel för TP.

API GW Tredje parts ”appar” via Mina Vårdkontakter Denna konstruktion som bygger dels på den tidigare redovisade arkitekturen med gemensamma virtuella tjänster med gemensamma RIVTA 2.1 kontrakt via tjänsteplattformen. Utöver detta använder APIGW protokollet/standarden OAUTH (samma som mellan facebook och twitter) länk http://tools.ietf.org/html/draft-ietf-oauth-v2-22 The OAuth 2.0 Authorization Protocol draft-ietf-oauth-v2-22 Abstract The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. Det som sker är i stort att via en inloggning på mina vårdkontakter kan innevånaren ge en viss godkänd app tillåtelse att använda oatuh för att företräda innevånaren i appens syfte. När innevånaren går in i appen och identifierar sig som ”gollum” så kommer denna id att skickas ner till apiGW som kan översätta till ”lennart Eriksson” och ställa frågan mot tjänsteplattformen. När svaret returneras kommer alla personliga data att filtreras bort och endast övriga data går ut till appen. Genom att tillgängliggöra denna infrastruktur kan marknaden för app tillverkning öppnas så att marknaden får möjlighet att bygga intressanta appar baserat på individens egna data. Allt vilande på den gemensamma arkitekturen som beskrivits.

SAMBI Identitets och behörighetsfederation Regelverk, Policys, Tillsyn Federationsoperatör .SE Medlemsregister Metadata Tillsyn Anvisningstjänst e-legitimation (t.ex. SITHS) Intyg Inloggning Intygsutfärdare (IDP) E-tjänst (SP) SAMBI ger en federation som bland annat innefattar Vården och Apotekens service AB. Detta gör att medlemmar i SAMBI enklare kan kommunicera med varandra. Genom detta tillitsramverk m.m. Kommer deltagande parter kunna lita på de andra deltagarnas utfärdade intyg. Detta underlättar starkt kommunikation ”över” domängränser. SMS (OTP) Attribut (HSA)

Vad är det vi vill uppnå 1 (verktygslådan) Gemensamma kontrakt i de flesta lägen Tjänsteplattformar på både lokal och gemensam nivå för mindre administration m.m. Lös koppling mellan Konsumenter (GUI) och producenter. Ger enklare och mindre upphandlingar Ny affärsmodell hur system skall beställas/byggas Stödtjänster kommer för det mesta vara klara Spärr, Patientrelation, Samtycke Loggning Intygstjänst med meddelandelåda Notifiering Autentisering med SAML 2.0 inom SAMBI federationen HSA för behörighetsstyrande attribut bl.a. TP med Engagemangsindex Gemensam drift- och testmiljö Räknar på första bilden upp det som vi vill att verktygslådan skall innehålla. Gör den det så kommer det att (bild 2) gå att bygga nya utformningar av lösningar om är mer uppdelade och därmed skapar större konkurrens och även ger kortare och mindre upphandlingar Genom att se till att driften redan finns innan upphandling kan mindre aktörer vara med eftersom de inte behöver hålla med SAS (Software As a Service) = inklusive drift. Deta kan mycket väl tillsammans med ny applikations struktur vara vägen ut ur Träsket/diket 

Vad är det vi vill uppnå 2 (vårdapplikatikoner) Ny grundfilosofi för hur vi styckar applikationer (oftast WEB) Ger nya affärsidéer med klienter separerade från producenter Drift redan klar gör att fler spelare kan bygga för våra behov, ger bättre konkurrens Innevånartjänster Tidbokning är ett exempel. Nya kan skapas av marknaden med hjälp av APIGW lösning NPÖ bas för vidare tjänster Kan i nästa version vara helt baserad på Engagemangs Index och därmed mycket mindre i sin interna utformning. NOD bas för hantering av läkemedel Genom att all information blir tillgänglig via RIVTA kontrakt så ökar det möjligheterna och viljan att djupintegrera systemen med dessa tjänster som bas. En utbyggd finns Pascal som WEB baserad klient för de som inte djupintegrerar Intygstjänsten Kan hantera sjukskrivningsintyg Kan även hantera andra former av intyg. Et axplock av vilka vård nyttor som vi med bas ovanpå de stödtjänster som beskrivits ovan kan skapa för vården och innevånaren.

T.ex. Hur styr man en sån här? Frågor? T.ex. Hur styr man en sån här? eller Hur gör man sen?

SLUT