Sammanfattning

Många invånare kommer förr eller senare att behöva vård och omsorg från fler huvudmän än en. Till exempel kan en patient behöva få medicinsk vård från flera olika vårdgivare parallellt samtidigt som det krävs färdtjänstresor till själva läkarbesöken samt stöd i hemmet för att klara det dagliga livet.

Om invånarna ska kunna få sammanhängande vård och omsorg krävs att landsting, kommuner samt privata vårdgivare och utförare kan samordna vårdplanering och andra organisationsöverskridande aktiviteter över organisationsgränserna. För att möjliggöra och effektivisera samarbetet krävs att de olika IT-system som används kan kommunicera med varandra på ett enhetligt och säkert sätt genom hela vård- och omsorgskedjan.

T-boken, (detta dokument) har som syfte att beskriva vad som krävs för att uppnå nationell samverkan kring de tekniska arkitekturfrågor som är nödvändiga för att åstadkomma detta.

Ordlista och förkortningar för T-boken återfinns i bilaga.

Nyttan med T-boken

Genom att T-boken beskriver vilka förutsättningar som ligger till grund för nationell samverkan, bland annat i form av styrande principer och teknisk referensarkitektur, underlättas arbete med att utveckla IT-stöd för sammanhängande vård och omsorg, på både regional/lokal och nationell nivå.

• Beslutsfattare och beställare kan säkerställa att beställningar av projekt- och förvaltningsobjekt blir kostnadseffektiva.
• Ansvariga för projekt och förvaltningsobjekt kan planera och genomföra sina arbeten så att den nationella arkitekturen följs vilket ger en kvalitetshöjande effekt.

• De som arbetar med själva arkitekturen/de tekniska lösningarna får tydlig vägledning genom den tekniska referensarkitekturen.

På nationell nivå leder detta i förlängningen till att de projekt och förvaltningsobjekt som redan i ett tidigt skede använder anvisningarna kommer på rätt spår och slipper göra större eller mindre omarbetningar efter de granskningar som Arkitektur och regelverk hos Inera genomför i olika faser av projektens genomförande.

På motsvarande sätt kan även T-boken tillämpas i lokala arkitekturfunktioner för granskning och stöd till projekt och förvaltningsobjekt. 

Nyttan med samverkan

• Invånarna får mer sammanhållen hjälp från vården och omsorgen.
• Vårdgivarna kan enklare, säkrare och mer kostnadseffektivt kommunicera med varandra.

• Kostnaden för utveckling och drift av IT-lösningar minskar genom återanvändning av till exempel teknik- och tjänsteutveckling samt dokument som ligger till grund för beställningar.

T-bokens innehåll utgår från att olika vård- och omsorgsgivare har kvar sitt eget självbestämmande och handlingsutrymme. Alla ska ha möjlighet att ansluta sig i den takt som passar just deras ekonomiska och tekniska förutsättningar.

På sikt kan T-boken komma att utvecklas och innefatta andra områden än vård och omsorg, såsom andra verksamhetsområden inom den kommunala verksamheten.

1                   Introduktion till T-boken

1.1   Inledning

Under 2010 har en målbild för eHälsa arbetats fram ur ett verksamhetsperspektiv, med God vård i fokus. Målbilden har tagits fram av Arkitektur och regelverk hos Inera. De övergripande målen för eHälsa, baserat på Socialstyrelsens strategi för God vård, är bland annat att vård av god kvalitet ska vara:

• ändamålsenlig
• kunskapsbaserad
• säker
• patientfokuserad
• effektiv
• jämlik
• erhållen i rimlig tid

Om målen ska kunna uppfyllas är en av förutsättningarna att det finns en nationell arkitektur för informationshantering och IT-stöd. För att kunna etablera en gemensam arkitektur, inklusive styrande principer och regler för samverkan inom vård och omsorg i Sverige, finns T-boken.

 T-boken förvaltas av Arkitektur och regelverk under Inera. teknisk arkitektur, som påverkas av krav och behov från de övriga perspektiven.

För att få en komplett målbild för arkitekturen för e-hälsa, som innehåller hela vård- och omsorgsområdet, måste även det kommunala socialtjänstperspektivet inkluderas.

1.2   Syftet med T-boken

För att bidra till en nationell samverkan kring enskilda individers behov av vård och omsorg över huvudmannagränser behövs en gemensam grund för IT-stödens utformning – en nationell arkitektur att stå på och utgå ifrån vid förverkligande av IT-stöd inom vård och omsorg.

En beskrivning av den nationella arkitekturen ur ett tekniskt perspektiv innebär rent konkret bland annat att erbjuda riktlinjer för att möjliggöra att olika IT-system kan kommunicera med varandra på ett enhetligt, standardiserat och säkert sätt. T-boken syftar till att beskriva detta.

Genom tillämpning av den nationella arkitekturen i form av en teknisk referensarkitektur, dess principer för uppbyggnad inklusive ett regelverk, kan projekt och förvaltningsobjekt lättare leverera IT-tjänster som uppfyller kraven på ett önskvärt och förutsägbart sätt.

För att realisera strategin för nationell eHälsa för vård och omsorg är T-boken styrande för det nationella arbetet inom Inera. Alla enskilda huvudmän kan, om de vill, använda T-boken som styrande även för lokal utveckling avseende den tekniska arkitekturen.

Den tekniska referensarkitekturen är ett stöd i beställarprocessen samt utgör ett underlag för granskning av projekt och förvaltningsobjekt. Arkitekturen syftar till att sänka tröskeln för att använda gemensamma lösningar och på så sätt sänka kostnaden och öka nyttan av samverkan utan att ge avkall på vare sig självbestämmanderätten eller funktionaliteten.

Olika vård- och omsorgsgivare kommer att utvecklas i olika takt och har olika ekonomiska och tekniska förutsättningar för att utforma egna interna lösningar. Även förutsättningarna för att ansluta sig till den nationella arkitekturen för samverkan mellan vård och omsorgsgivare skiljer sig åt. Arkitekturen utformas därför så att varje vård- och omsorgsgivare kan ansluta sig i den takt som passar deras behov och förutsättningar.

1.3   T-bokens vision utifrån befintliga behov

Visionen för T-boken är att den genom referensarkitekturen ska möta de behov som uppstår när:

• e-tjänster för invånare, företagare och utförare behöver integreras med informationskällor och verksamhetssystem inom myndigheter
• e-tjänster för såväl invånare som professionen behöver sammanställa uppgifter om den enskilda invånaren baserat på informationskällor spridda över många organisationer och IT-system
• offentliga och privata aktörer inom vård och omsorg behöver integrera sina system med statliga myndigheters e-tjänster (t ex Socialstyrelsen, Försäkringskassan och eHälsomyndigheten)
• medarbetare behöver e-tjänster som spänner över flera informationskällor och verksamhetssystem
• offentliga och privata aktörer inom vård och omsorg behöver utbyta information eller nå skalfördelar, såsom ekonomiska stordriftsfördelar, genom att dela e-tjänster
• medarbetare inom olika organisationer behöver meddela sig med varandra elektroniskt rörande gemensamma ärenden på ett säkert och robust sätt

1.4   Målgrupper

T-boken riktar sig till flera målgrupper som var och en kan ha nytta av olika delar av dokumentet.

1.4.1.            Beslutsfattare och beställare

Ett arkitekturramverk som helhet syftar till att förenkla och effektivisera den framtida utvecklingen av IT-stöd. Som beslutsfattare och beställare kan de två inledande kapitlen i T-boken användas för att stämma av om tänkta beställningar är av sådan karaktär att de omfattas av den nationella arkitekturen. Dessa projekt bör då planeras och genomföras så att den nationella arkitekturen följs för att uppnå vinster såsom kostnadseffektivitet, återanvändning av teknik- och tjänsteutveckling samt ökade möjligheter till utbyte av information.

1.4.2.            Arkitekturfunktioner nationellt, regionalt och lokalt

Arkitekturfunktioner eller motsvarande kan använda de styrande principerna i kapitel 4 som ett underlag för att kunna avgöra om projekt- och förvaltningsbeskrivningar överensstämmer med de strategiska målen för eHälsa, ur ett tekniskt perspektiv.

Regelverket i kapitel 5 beskriver den nationella referensarkitekturen på detaljerad nivå. I det nationella arbetet med realisering av strategin för nationell eHälsa – tillgänglig och säker information inom vård och omsorg, används denna del av T-boken när granskning görs av de nationella projekten och förvaltningsobjekten.

Även regionala eller lokala arkitekturfunktioner kan använda T-boken för att granska och följa upp sina projekt. En liten organisation, som inte har en arkitekturfunktion eller motsvarande roll, kan använda T-boken i dialog med sina IT-leverantörer inom vård och omsorg för att försäkra sig om att de har förstått den omgivning som IT-systemen skall verka inom.

1.4.3.            Ansvariga för nationella projekt och förvaltningsobjekt

Ansvariga för olika projekt och förvaltningsobjekt bör förstå T-boken på en övergripande nivå, för att kunna planera in avstämningar mot referensarkitekturen och på så sätt få möjlighet att planera och följa upp projektarbetet i olika faser och löpande kvalitetssäkra resultatet.

Genom regelbundna avstämningar mot referensarkitekturen underlättas projektarbetet och risken för att få göra omarbetningar i projektet minskar.

1.4.4.            Ansvariga för regionala projekt och förvaltningsobjekt

Även om T-boken avser den nationella arkitekturen kan den med fördel även användas i lokalt/regionalt utvecklingsarbete inom vård och omsorg. Dessutom innebär en lokal anpassning med stor sannolikhet att tröskeln för att ansluta sig till den nationella arkitekturen blir betydligt lägre. I vissa fall är det dessutom en nödvändighet att vissa regler efterföljs även lokalt/regionalt, till exempel när det gäller hantering av spärr, eftersom de i sig utgör en grundläggande förutsättning för att den nationella arkitekturen ska fungera.

Om den interna arkitekturen hos en vård- och omsorgsgivare väsentligt avviker från den nationella arkitekturen så innebär det att kostnaderna för att anpassa sig till den nationella lösningen blir högre.

Samverkan kring en gemensam arkitektur kan utöver den nationella nivån, avse både samverkan mellan vård och omsorgsgivare lokalt eller i en regional gemenskap. 

I dag införskaffas ofta system utifrån ett specifikt behov i en verksamhet, utan att ta hänsyn till hur systemet passar in i en större helhet. I ett längre perspektiv kommer behoven av att kunna utbyta information med andra system utanför den egna domänen att öka. Med en gemensam arkitektur underlättas integration med andra system.

En gemensam arkitektur och tillhörande regelverk, både ur ett verksamhetsperspektiv, informationsstrukturperspektiv och tekniskt perspektiv, leder alltså till interoperabilitet. Med det avses förmågan hos olika system att fungera tillsammans och kunna kommunicera med varandra. Detta skapar förutsättningar för att utbyta information, integrera processer och använda gemensamma tjänster.

2                   Behov och scenarier

2.1   Arkitekturens intressenter

Intressenterna i den nationella samverkansarkitekturen är de parter som behöver förändra sin IT-arkitektur drivet av krav från strategin för nationell eHälsa inom vård och omsorg.  I den gamla skriften ”Målbild för arkitekturen inom eHälsa I samverkan – och vägen till målet” som har tagits fram av Inera som ett separat projekt, finns ett antal intressenter och deras behov sammanställda, bland annat följande intressenter: Invånare, individ, patient, företrädare, politiker, vårdprofessionen, verksamhetschef, vårdgivare, socialtjänst, myndighet, apotekens servicebolag, patientorganisation, forskare och studerande. Skriften fokuserar på hälso- och sjukvård och är baserad på en vision för hur IT kan bidra till God vård. För att få en komplett målbild och färdplan för arkitekturen för e-hälsa, som innehåller hela vård- och omsorgsområdet, måste även det kommunala socialtjänstperspektivet inkluderas. Utöver de intressenter som redovisats i Målbilden för eHälsa, så har därför ytterligare några intressenter till T-boken identifierats och de anges i tabellen nedan. T-bokens olika kapitel har under framtagningen stämts av mot de behov som intressenterna har uttryckt. 

2.2   Scenariobeskrivningar

Intressenternas behov av samverkan har konkretiserats genom så kallade scenarier. Ett scenario illustrerar en målbild för ett framtida tillstånd i syfte att illustrera för vem och i vilka situationer den tekniska arkitekturen gör nytta. Scenariobeskrivningarna har delats upp i olika områden:

• Stöd för samverkan i vård- och omsorgsprocessen.
• Stöd för välinformerade och delaktiga medborgare.
• Stöd för uppföljning.
• Stöd för kunskapsstyrning.
• Stöd för resurshantering.

Att ta hänsyn till dessa delar vid utformningen av den tekniska arkitekturen är fundamentalt.

2.2.1.            Stöd för samverkan i vård och omsorgsprocessen

• Samverkande hälsoärenden

Samverkande hälsoärenden innebär bland annat att vårdens i vissa fall långt drivna specialisering och fragmentering överbryggas. Detta är viktigt för att patienten ska uppleva att vården ser människan som en helhet och hanterar patientens vårdbehov därefter, även om varje enskilt möte rör ett hos patienten specifik och avgränsat vårdbehov. Genom en gemensam informationsstruktur och gemensam teknisk infrastruktur och säkerhetslösningar kan bland annat

• hälsoärenden kan hanteras oberoende av hur vård och omsorg är organiserad
• informationen hållas samman i vårdprocesser
• vårdplan och information kan delas

• Sammanhållen journalföring

Sammanhållen journalföring innebär att olika vård- och omsorgsgivare kan få tillgång till uppgifter i varandras journaler. Detta gäller för den del av journalen som lyder under Patientdatalagen. Det leder till att arbetet kan effektiviseras och att invånarna kan få bättre vård och service.

• Experter som är verksamma i flera kommuner och anlitade av flera vårdgivare, exempelvis specialistkompetens för tolkning av röntgenbilder, får enkelt tillgång till journaler över vård-givargränserna.
• I ärenden kring en brukare där flera utförare, inklusive kommunal omsorg, är involverade kan alla få tillgång till relevant omsorgsdokumentation, oavsett vilken utförare som upprättade informationen. Detta gäller för den del av journalen som lyder under Patientdatalagen.
• Avbrottsfritt byte av utförare/vårdgivare på en vård- och omsorgsenhet. När patienten/omsorgs-tagaren kommer till samma vårdcentral, omsorgsenhet eller skolbyggnad efter att vårdcentralen, omsorgsenheten eller skolbyggnaden har bytt utförare (t.ex. offentlig till privat regi), är behovet stort av smidig åtkomst till vård- och omsorgsdokumentation som ägs av den tidigare utföraren. Observera att omsorg kan ske även i hemmet.
• Omsorgsverksamheter inom skola och äldrevård får tillgång till vårddokumentation från primärvården för de delar som lyder under Patientdatalagen.

• Samordnad vårdplanering

Samordnad vårdplanering innebär att vård- och omsorgsprocesser mellan kommuner och landsting integreras. Det leder i sin tur till att patientsäkerheten ökar samt att invånarna kan få bättre och mer sammanhängande insatser och bemötande. Om den nationella arkitekturen följs kan flera fördelar uppnås.

• Förutom stöd för den administrativa delen som betalningsansvarsrutinen innebär, kan IT-tjänsten ge möjligheter för vård och omsorgsgivare att följa vårdplaneringsprocessen.
• Det blir enklare att följa lagen om betalningsansvar för utskrivningsklara patienter vid sjukhus för viss hälso- och sjukvård som föreskriver att en gemensam vårdplan ska tas fram. Vårdplanen skall justeras av ansvarig läkare på såväl sjukhus som i primärvård samt av ansvarig handläggare i kommunen. Arkitekturell samverkan kan göra det möjligt att bifoga elektroniska kopior i ett elektroniskt processtöd vilket i sin tur kan bemöta behovet av snabbt utbyte av patientrelaterad information mellan de olika aktörerna i vårdplaneringsprocessen. Även sammanhållen journalföring kan bidra till att fylla detta behov.
• Övergripande önskvärda verksamhetseffekter avseende kvalitet och resursåtgång kan uppnås genom rätt information till rätt person vid rätt tillfälle, ökad kvalitet i den information som utbyts mellan parterna, ökad säkerhet och effektivitet i kommunikation och informationsöverföring, minskad administrativ tid och mer tid för patienterna.

• Samverkan med statliga myndigheter

Vård- och omsorgsprocesser har i ökad utsträckning behov av elektronisk integration med statliga myndigheters IT-stöd för att få en effektiv hantering av invånarens ärenden, såsom exempelvis sjukskrivningsprocessen. De olika IT-stöden är standardiserade av respektive myndighet.

• Ett systematiskt angreppssätt inom vård och omsorg skulle avlasta en mängd systemägare genom att de slipper göra myndighetsspecifika anpassningar när de ska kommunicera olika ärenden med myndigheterna.

• Läkemedelsområdet

Eftersom omsorgsverksamheter inom kommuner skriver ut läkemedel är behovet av elektronisk integration med så väl logistiska processer (till exempel Apoteket Farmaci) som förskrivningsprocesser stort.

2.2.2.            Stöd för välinformerade och delaktiga medborgare

• e-tjänster för invånare

Vård och omsorg eftersträvar ökad service till invånaren genom att erbjuda tjänster på webben. Det kan gälla tidbokning, kundval, listning, vårdval med mera. Här finns såväl ett kommunalt som ett regionalt och ett nationellt perspektiv.

• Gemensam arkitektur gör det möjligt att sammanställa information från många lokala informationskällor och sedan presentera ett nationellt perspektiv på informationen.
• Patienten och brukaren blir en aktiv part i sin process genom väl genomarbetade och utbyggda invånartjänster. Till exempel genom att den lokala vårdgivarens insatser kan samspela med tjänster anpassade för patienter och brukare med långvariga vårdbehov.
• Patientmakten stärks också då e-tjänster kan ge patienten/brukaren eller närstående tillgång till vårdplaner.

• e-tjänster för vård och omsorgspersonal

Kundval, vårdval och liknande invånartjänster skapar behov av e-tjänster för ”back-office”-personal som tar hand om specialfall där invånarna själva inte kan använda invånartjänsterna.

• Personalen behöver inte lära sig varje vård- och omsorgsgivares unika IT-system för att uträtta ärenden åt invånare. e-tjänster riktade till vård- och omsorgspersonal erbjuder en nationell eller regional ärendehantering och servicefunktioner.

• Tillgång till invånaruppgifter

Tillgången till invånaruppgifter är en viktig komponent i många scenarier. Det gäller till exempel samordnad vårdplanering och invånartjänster.

Varje landsting och/eller kommun ansvarar för att tillgängliggöra personinformation om de personer som är mantalsskrivna i länet. Huvudkällan är Skatteverkets Navet, men informationen kompletteras ibland från lokala källor.

• Alla landsting kan tillhandahålla personinformation enligt ett nationellt standardiserat tjänstekontrakt. Därigenom behöver inte systemleverantörer anpassa sina produkter för lokala gränssnitt. Landsting och kommuner blir på så sätt också fria att välja lösning för personinformation oberoende av vilket verksamhetssystem som används.

2.2.3.            Stöd för uppföljning

• Uppföljning och utvärdering

Inom kommunal omsorg finns ett stort behov av att på ett strukturerat sätt följa upp och utvärdera olika åtgärder och utförare i biståndsärenden. Kvalitet ska följas upp mot avtal och uppsatta mål för att utvärdera egen och utförares verksamhet. Information från uppföljning och utvärdering utgör också grundinformation som kan användas i kundvalssituationer.

Även för vårdens kärnprocess finns behov av uppföljning.

• Dessa behov kan stödjas genom en gemensam informationsstruktur samt med standardiserade lösningar för hur uppföljningsunderlag ”exporteras” från kärnprocessen till exempelvis nationella kvalitetsregister samt nationella och lokala register för produktionsuppföljning.

• Kvalitetsregister

Runtom i landet finns det ett stort antal kvalitetsregister inom sjukvården som innehåller information om diagnoser, åtgärder och utfall av olika klinikers vårdarbete. Denna form av data ger varje enskild klinik möjlighet att jämföra sig med riksgenomsnittet, diskutera och analysera internt och vid behov vidta kvalitetsförbättrande åtgärder. Insamling av data till kvalitetsregister av olika slag är i dag belastande för vård- och omsorgspersonal. Samtidigt ökar insikten av värdet och därmed uppstår ytterligare krav på datainsamling.

• Genom kvalitetsregister kan insamling och inmatning av vård- och omsorgsdokumentation för systematisk användning automatiseras och förbättras. Kvalitetsregister är också väsentlig bakgrundsinformation som bör göras tillgänglig för invånarna i kundvals- och vårdvalssituationer, vare sig det gäller ett nyval eller ett omval.

2.2.4.            Stöd för kunskapsstyrning

• Kunskapsstyrd vård

För att invånarna ska få bästa möjliga vård ska den vara baserad på aktuell forskning, uppdaterade riktlinjer och analyserad information som baseras på data från uppföljning av vårdens kärnprocess.

• Vård- och omsorgsgivaren ska, genom IT-stöd som innehåller sammanställd kunskap för olika intressenter och vårdsituationer, få ett beslutsstöd så att rätt beslut kan fattas i det ögonblicket beslutet ska tas.

2.2.5.            Stöd för resurshantering

• Resurshantering

För att få en effektiv och säker vård och omsorg behöver det finnas både personella och materiella resurser i rätt ögonblick.

• Genom att utveckla integration med standardsystem och beslutsstöd så kan resurshantering stödjas. Genom att data från produktionsuppföljning av kärnprocessen tydliggörs i beslutsstöd kan även olika intressenter inom lednings-, styrnings- och stödprocesser få stöd i resurshantering, både vad gäller personella och materiella resurser.

3                   T-boken i ett sammanhang

Strategin för nationell eHälsa – tillgänglig och säker information inom vård och omsorg, är ett av de överordnade regelverken till T-boken.  Arkitekturens vägval måste även vara harmoniserade med de lagrum och författningar som rör vård och omsorg.

3.1   Arkitekturens utveckling och praktiska användning

Principerna för hur arkitekturen ska utvecklas, tillämpas och förvaltas baseras på en modell hämtad från TOGAF ADM. TOGAF (The Open Group Architecture Framework) är ett ramverk med metodstöd som utvecklats sedan mitten på 90-talet genom att ta tillvara ”best practice” från olika branscher.

”Hjulet” i figuren nedan är det sätt TOGAF valt att fasindela utveckling, tillämpning och förvaltning av arkitekturen.

Dels finns det gemensamma faser, inringat i rött, som syftar till att beskriva och förvalta den nationella arkitekturen, så att den kan tillämpas av olika arkitekturfunktioner. I nuläget utgörs dessa arkitekturfunktioner av Inera egen arkitekturfunktion, benämnd Arkitektur och regelverk, samt lokala och regionala arkitekturfunktioner hos kommuner, regioner och landsting.

Övriga faser, inringat i grönt, syftar till att införa arkitekturen i enskilda organisationer och hanteras av respektive organisation. De är därför beroende av varje organisations nuläge och prioriteringar. Det är i dessa faser (E-G) som den nationella arkitekturen (beskriven i fas A-D + H) kommer till användning.

Kommentarerna till de olika faserna belyser de primära resultaten från respektive fas för arbetet med den tekniska arkitekturen. För den nationella arkitekturen som en helhet kan varje fas innehålla ytterligare beskrivningar.

Kommentarer i kursiv stil avser resultat som ingår i detta dokument. För de faser som beskriver verksamhetsperspektivet ingår dock bara en kortare sammanfattning i detta dokument i syfte att belysa de verksamhetsmässiga drivkrafterna för den tekniska arkitekturen.

Figur 1 – Detta dokument i ett sammanhang enligt TOGAF

Över tiden uppstår behov av att förändra och utöka olika mönster i referensarkitekturen. Avsikten med förändringshanteringen i fas H är att den nationella referensarkitekturen genom kontinuerlig uppdatering ska kunna fortleva som en gemensam arkitekturbeskrivning. Det ställer krav på ett forum som kan samordna förvaltning och vidareutveckling och på så sätt säkerställa att referensarkitekturen över tiden fortsätter fylla sitt syfte. För T-boken så är Arkitektur och regelverk hos Inera detta forum.

3.1.1.            Arkitekturens koppling till tjänstehantering

Utmaningarna inom IT-området kan mötas genom utveckling av förmågor (capabilities) inom tjänstehantering (IT Service Management, ITSM), arkitektur och (tjänste)förvaltning. Arkitekturen har en betydande roll i utvecklingen av tjänster, processer och system i perspektiven verksamhet, information, teknik och säkerhet.

Eftersom de olika delarna påverkar varandra måste helheten, Enterprise Architecture, och sambanden mellan de olika perspektiven adresseras oavsett viket av dem som är i fokus för stunden.

Genom att identifiera nuläge och målbild kan gapet dem emellan analyseras och resultera i strategier samt aktivitetsplaner som gör att målet kan nås. I utvecklingsprocessen fångas och hanteras olika intressenters behov och förvänt­ningar. Dessa behov omvandlas till funktionella respektive icke-funktionella krav.

Utöver konkreta lösnin­gar kan följande effekter av arkitekturarbetet förväntas:

• En referensarkitektur som fungerar som underlag för beslut i strategiska och taktiska frågor, vilken möjliggör en aktiv ledning och styrning mot verksamhetens mål – en bas för ständiga förbättringar och kvalitetsarbete.
• Underlag som beskriver samband (både enkla och komplexa) som bland annat kan användas vid kostnadsuppskattningar för olika sorters IT-stöd.
• Möjlighet till maximalt hög genomströmning av ändringar med största möjliga kontroll och minsta möjliga risk.
• Säkerställande av skalbarhet och återanvändbarhet.
• Säkerställande av proaktivitet genom att planer och regelverk förvaltas och hålls aktuella.

Som stöd för metodik och process kring arkitekturen kan TOGAF användas, eventuellt kompletterat med The Zachman Framework för klassificering av olika entiteter i arkitekturen.

När det gäller tjänstehantering är det mest använda ramverket, internationellt sett, ITIL v3 (IT Infrastructure Library version 3) Därför är det viktigt att den tekniska arkitekturen harmonierar med ITIL, utan att för den skull förutsätta att ITIL används. Ramverket ITIL är uppdelat i fem faser:

• Tjänstestrategi, Service Strategy (ITIL v3)
• Tjänsteutformning, Service Design (ITIL v3)
• Tjänsteöverlämning, Service Transition (ITIL v3)
• Tjänstedrift, Service Operation (ITIL v3)
• Kontinuerlig tjänsteförbättring, Continual Service Improvement (ITIL v3)

En bärande tanke med ITIL är att tjänster ska kunna hanteras genom hela livscykeln. Tjänstehantering i sig definieras som en uppsättning specialiserade organisa­toriska förmågor som kan skapa värde för verksamheten i form av tjänster. För att uppnå de fördelar som eftersträvas måste det finnas processer, styrning och ledning som säkerställer och kvalitetssäkrar arbetet.

Utveckling av förmågor är en iterativ process vilket innebär att arbetet bedrivs i kortare eller längre återkommande cykler. Ytterst styrs arbetet av den tjänstenivå som ska levereras till verksamheten/brukaren varför det är viktigt att hitta en tillräckligt bra nivå. Det innebär att samtliga inblandade parter måste ha en beredskap att utveckla sina förmågor allt eftersom behov uppstår. Brister det i hanteringen här kan det resultera i:

• avbrott i redan produktionssatta tjänster
• oförmåga att förvalta och utveckla nya tjänster
• oförmåga att föra in nya, eller ändra befintliga, tjänster på ett säkert sätt.

Driftsatta tjänster, processer och system måste precis som arkitekturen förvaltas. Förvaltningsarbetet med avseende på tjänsteleveranser är till sin natur tvehövdat. Dels handlar det om att kontrollera att tjänstedrift och support upprätthåller en överenskommen servicenivå (SLA) i en leverans och vidta korrigerande åtgärder vid avvikelser, dels att vid förändrade krav planera för nya mål så att tjänster, processer och system kan prestera i enlighet med vad som krävs. Kontinuerligt förbättringsarbete är en process som kan appliceras på andra processer för att vid varje givet tillfälle komma upp till den nivå av prestanda som eftersöks. Förbättringsarbetet i sig får aldrig börja sätta sina egna gränser. Dess syfte är att verka upp till och med en given nivå, alternativt att lyfta upp till en ny överenskommen nivå om beslut tas om detta.

3.1.2.            Arkitekturen och processer i samverkan

Nedan illustreras hur processen för arkitekturarbete samverkar med processerna för Tjänste­hantering och Tjänsteförvaltning, det vill säga de huvudprocesser som hanterar och förvaltar den realiserade arkitekturen (det färdiga resultatet, även kallat instanser).

Figur 2 – Samverkansmodell för processer

1. Verksamhetens företrädare uttrycker de behov som finns.
2. Tjänstestrategiprocessen verkar utifrån den så kallade Tjänsteportföljen med att definiera marknaden, utveckla tjänsten, utveckla strategiska tillgångar samt förbereda införandet. Processens resultat är styrande för arkitekturprocessen.
   I Tjänstestrategiprocessen fångas också behoven från verksamheten upp och beskrivs. Uttryckta behov av servicenivåer, kvalitetsaspekter och andra parametrar dokumenteras och hanteras. Om det behövs tas användningsfall fram för att underlätta utvecklingsprocessen. Behoven vägs och bedöms mot gemensamma policyer och principer som är förankrade i verksamheten.
3. Programkontoret analyserar, designar och utvärderar alternativ samt köper in och/eller utvecklar lösningar. I denna process levererar arkitekturen underlag i form av referens- och lösnings-arkitekturer för vidare bearbetning i de ingående underprocesserna. Ett uppdrag kan behöva itereras, det vill säga växla, mellan arkitekturprocessen och programkontoret flera gånger innan ett fullgott resultat uppnås. Arkitekturfunktionen granskar arbetet för att säkerställa att det följer referens- och lösnings­arkitekturer.
4. Tjänsteöverlämning kan liknas vid ett stafettlopp; en överlämning av stafettpinnen (Release) från Tjänsteutformning till Tjänstedrift. Här gäller det att kombinera snabbhet och säkerhet för ett bra resultat. För­ändrings­kraven som kommer från programkontoret resulterar i lösningar som kan användas i den operativa miljön. I den mån arkitektur­ella beskrivningar finns på plats och är användbara kan det hanterade upp­draget gå vidare, i annat fall måste det till insatser från arkitekturfunktionen för att få fram nödvändiga underlag. Ett viktigt verktyg för att arkitekturfunktionen på ett effektivt sätt ska kunna granska projekt och operativ verksamhet är den så kallade konfigurationsdatabasen. Strukturen i databasen bör ägas av arkitekturfunktionen medan processen för Hantering av tjänstetillgångar och konfigurationer  ( Service Asset and Configuration Management (ITIL v3)) ansvarar för instanseringen. Uppdatering sker i huvudsak av processen för Release och driftsättningshantering (Release and Deployment Management (ITIL v3)) Konfigurations­data­basens struktur och instansering hjälper till att identifiera relationer mellan olika konfigurationsenheter vilket är ovärderligt i support­situationer, för­ändrings­hanteringens analys av en föreslagen ändrings inverkan på infra­struktur och/eller processer samt som underlag för kostnads­beräkning av de tjänster som utvecklas.
5. Tjänstedrift kan liknas vid IT-avdelningens fabrik. Här levereras IT-tjänster enligt avtalade Tjänstenivåmål. Den stora utmaningen i Tjänste­driftprocessen är att hitta en god balans mellan 
   • internt fokus i förhållande till externt
   • fokus på stabilitet i förhållande till fokus på tillmötesgående
   • fokus på kvalitet i förhållande till fokus på kostnad
   • fokus på reaktivitet i förhållande till fokus på proaktivitet
6. Tjänsteförvaltningsprocessen kontrollerar utfallet mot börläge och återkopplar bakåt till lämpliga processteg. Strategiska och taktiska inriktningsbeslut omsätts till en användbar planering. Tjänste-förvaltningens aktiviteter utförs givetvis på redan realiserade objekt. Modellen visar Förvalt­ningsprocessens positionering ur ett styrningsperspektiv.
7. Tjänsten avslutas och livscykeln är fullbordad.

Processen för Kontinuerlig tjänsteförbättring är en löpande process som ska stämmas av mot vision, strategi samt taktiska och operativa mål. I processen tas små steg i syfte att komplettera och ge riktlinjer till de övriga fyra huvudpro­cess­erna. Processen bör integreras i verksamhetens kultur för att där bli en naturlig del i vardagen.

3.2   T-bokens innehåll och tillämpning

T-boken för vård och omsorg är avsedd att tillämpas av arkitekturfunktionen i olika organisationer. För Arkitektur och regelverk hos Inera utgör den det huvudsakliga regelverket för den tekniska arkitekturen. För andra organisationer blir det troligen kompletterande, eftersom det finns behov av att täcka in fler sektorer, samt att man där behöver en arkitektur för anslutning till den nationella.

Den nationella arkitekturen ställer krav (även då den tillämpas lokalt) på anslutningsarkitektur för anpassning av lokala system till nationella riktlinjer (kommunikationsprotokoll, säkerhet, tjänstekontrakt m.m.). 

Den tekniska arkitekturen i T-boken baseras på olika intressentbehov (se kapitel 2) samt de principer (se kapitel 4) som utgör det övergripande regelverket. Den tekniska arkitekturen utgörs bland annat av en referensarkitektur som i sin tur består av arkitektur med tillhörande regler samt referensmodeller (se kapitel 5).

En referensarkitektur är ett detaljerat regelverk kring både processer och struktur. Eftersom T-bokens referensarkitektur ska vara brett tillämpbar inom vård och omsorg – nationellt och lokalt - innehåller den inte tekniska anvisningar med detaljerade regler kring komponenter och deras tillämpning. Detta är något som måste kunna anpassas efter lokala behov och prioriteringar.

Däremot finns utpekade komponenter som är strategiska för referensarkitekturen med beskrivning på logisk nivå. Ansvaret för anvisningar finns hos respektive arkitekturfunktion. Vissa anvisningar förvaltas dock av Inera, speciellt de som rör standarder för elektronisk samverkan, och är nödvändiga att tillämpas av övriga arkitekturfunktioner för att få samverkande system.

En viktig del av dokumentet är vägledande exempel. De belyser på ett konkret sätt hur referensarkitekturen kan tillämpas för behov som var aktuella när referensarkitekturen fastställdes. En uppsättning av vägledande exempel ingår i detta dokument, men förvaltas också som fristående dokument, i form av målbilder. Därigenom kan de hållas aktuella mellan revisioner av referensarkitekturen.

4                   Styrande principer

För att hjälpa de projekt som beställer och utvecklar IT-stöd att navigera mot en teknisk arkitektur enligt de långsiktiga behoven, finns sex IT-principer som bland annat säkerställer spårbarhet, skalbarhet, flexibilitet och interoperabilitet.

IT-principerna är:

• vägledande för beslutsfattande i frågor om samverkansarkitektur
• redskap för löpande beslutsfattande under framtagning av referensarkitekturen
• ett stöd vid granskning av projekt

Principerna behöver kommuniceras och tillämpas hos beställare och utförare.  Det är arkitekturfunktionens uppgift att styra utveckling och förvaltning av arkitekturen, samt har ansvar att övervaka och vägleda principernas tillämpning och deras förvaltning.

4.1   IT1: IT-principerna är styrande för den tekniska arkitekturen

Det finns en uppsättning styrande principer för tillämpad arkitektur.

4.1.1.            Motiv

Följsamhet mot principerna möjliggör löpande styrning mot målbilden för arkitekturen.

4.1.2.            Förutsättning

• Principerna kommuniceras och tillämpas hos beställare och utförare genom arkitekturfunktionen, som styr utveckling och förvaltning av arkitekturen, samt har ansvar att övervaka och vägleda principernas tillämpning och deras förvaltning.
• Arkitekturfunktionen är integrerad i processer hos tillämpliga programkontor, beställarfunktioner, projektorganisationer och systemförvaltningar.
• Principerna kommuniceras och tillämpas av dem som styr utveckling och förvaltning inom IT-infrastruktur, vårdgivartjänster och invånartjänster.
• Arkitekturfunktionen underlättar följsamhet mot principerna genom anvisningar och vägledande exempel.
• En teknisk referensarkitektur kommunicerar en teknisk målbild. En teknisk referensarkitektur skapar också förutsättningar för projekten att leverera resultat som är i samklang med de styrande principerna. Visionen ska vara att det upplevs enklare att följa principerna än att inte följa dem.
• I möjligaste mån bör principerna tillämpas, men om principer och regelverk står i konflikt med ett projekts leveransförmåga rekommenderas det att avvikelser klassificeras och dokumenteras så att uppföljning kan ske av respektive arkitekturfunktion. På det nationella planet utgörs arkitekturfunktionen av Arkitektur och regelverk, med berörda förvaltningar.

4.2   IT2: Informationssäkerhet

Tillgänglighet, sekretess, riktighet och spårbarhet ska säkerställas vid all samverkan.

All information som hanteras eller lagras i någon form måste skyddas mot oönskad förändring, påverkan eller insyn. Det ska inte heller vara möjligt för obehöriga att ta del av informationen. De användare som har rätt att ta del av informationen ska komma åt den efter behov och inom önskad tid. Det är också av vikt att kunna identifiera vem som har gjort vad med information och datasystem.

4.2.1.            Motiv

Säkerhetstänkande är grunden för förtroende och tillit från invånare, medarbetare och samarbetspartners. Informationssäkerhet innebär att säkerställa:

• Riktighet - Att information inte kan förändras vare sig obehörigen, av misstag eller på grund av funktionsstörning. Informationen ska vara tillförlitlig, korrekt och fullständig
• Sekretess - Att dokument, information och handlingar etc. inte görs tillgängligt eller avslöjas för obehörig
• Spårbarhet - Att i efterhand entydigt kunna härleda specifika aktiviteter eller händelser till ett identifierat objekt - användare, skrivare, dator eller system/program. Det ska gå att se vem som tagit del av informationen, vilka förändringar som har inträffat och av vem som dessa har utförts
• Tillgänglighet - Att information och informationstillgångar kan utnyttjas efter behov, i förväntad utsträckning och inom önskad tid utifrån de krav som ställs på verksamheten. Tillgänglighet innebär inte bara att systemet tekniskt fungerar med utlovade svarstider. Systemet måste dessutom leverera förväntat värde inom rimlig tid.

4.2.2.            Förutsättning

• Verksamhetskritiskt IT-stöd designas för att möta verksamhetens krav på tillgänglighet vid frånfall av ett externt beroende. Ju fler beroenden till andra komponenters tillgänglighet, desto lägre egen tillgänglighet.
• Verksamhetskritiska nationella stödtjänster (t.ex. tillgång till behörighetsstyrande information) erbjuder möjlighet till lokala instanser som med tillräcklig aktualitet hålls uppdaterade med nationell master.
• Krav mellan integrerande parter regleras genom integrationsavtal. Integrationsavtal är det avtal där informationsägaren godkänner att en ett visst system får agera mot information genom ett visst tjänstekontrakt. Exempelvis skall enligt integrationsprocessen för den nationella tjänsteplattformen ett avtalsnummer för ett integrationsavtal registreras i samband med att man "öppnar dörren" för en viss tjänstekonsument mot en viss kombination av informationsägare och tjänstekontrakt.
• Arkitekturen måste möjliggöra tillräcklig tillgänglighet vid flera samverkande system.
• En sammantagen tolkning av tillämpliga lagar och förordningars konsekvenser för teknisk realisering av informationsfångst, utbyte och lagring.
• Förutsättningar för spårbarhet etableras i form av loggningsregler för komponenter som deltar i säkert informationsutbyte.
• Integration ska ske över en integrationsinfrastruktur (t.ex. virtualiseringsplattform) som möjliggör uppföljning av tjänsteproducenters fullföljande av SLA.
• Interoperabla, internationellt beprövade och för leverantörer tillgängliga standarder tillämpas för kommunikation mellan parter som har upprättat tillit.

4.3   IT3: Nationell funktionell skalbarhet

Alla element i arkitekturen (tjänstekontrakt, integrationstjänster, nationella e-tjänster, nationella integrations- och plattformstjänster etc.) ska följa ett nationellt perspektiv. Det gäller så väl funktionell omfattning som teknisk kapacitet. Observera att resonemanget även gäller regionalt och lokalt där man också kan dela gemensamma resurser eller tjänster.

4.3.1.            Motiv

Det ska vara möjligt för flera organisationer att dela en installation av ett system.

Vidare innebär nationell samverkan potentiellt högre krav på tillgänglighet och kapacitet. Detta ställs på sin spets när invånaren blir användare av e-tjänster som integrerar med verksamhetssystem.

4.3.2.            Förutsättning

• Nationella tjänstekontrakt definieras med nationell täckning som funktionell omfattning. Det är möjligt för ett centraliserat verksamhetssystem som användas av alla verksamheter i Sverige att realisera varje standardiserat tjänstekontrakt. Det får inte finnas underförstådda funktionella avgränsningar till regioner, kommuner, landsting eller andra organisatoriska avgränsningar i nationella tjänstekontrakt.
• SLA ska definieras för varje tjänstekontrakt. Detta SLA ska ta hänsyn till framtida kapacitet för tjänstekontraktet med avseende på transaktionsvolym, variationer i användningsmönster och krav på tillgänglighet, i kombination med förmåga till kontinuerlig förändring.
• System och e-tjänster som upphandlas kan utökas med fler organisationer som kunder utan krav på infrastrukturella ingrepp (jämför s.k. SaaS)

4.4   IT4: Lös koppling

Sammanhållen journalföring, effektivt processtöd för hälsoärenden, samordnad vårdplanering och att tillmötesgå invånarens behov av e-tjänster kräver omfattande integration av många organisationers IT-stöd. Dominoeffekter orsakade av förändringar i integrationslandskapet skall förhindras genom lös koppling.

4.4.1.            Motiv

Fullföljande av strategin för nationell eHälsa inom vård och omsorg kräver en höggradig integration mellan samverkande parters IT-stöd. Det kan gälla såväl inom som mellan parter med system som ska integreras. Risken är stor att parternas utveckling av IT-stödet kompliceras ju mer integrationer som upprättas. Varje förändring kan komma att behöva samordnas med många parter.

Ju fler beroende som upprättas, desto större blir risken att förändringar hos någon part fortplantas till övriga parter. Ibland kan det inte undvikas, men genom strukturerade ansatser redan vid utvecklingen av nya integrationer, kan viss förändringstålighet byggas in.

Ju fler beroenden som är synkrona, desto lägre blir tillgängligheten i det beroende systemet.

För varje typ av nationellt integrationsbehov finns många informationsägare – ofta med regionala eller lokala informationssystem. Det innebär att ett stort antal integrationspunkter kommer att finnas för varje integrationsbehov. Dessa integrationspunkter förändras dessutom över tiden, när system konsolideras och nya parter tillkommer eller utträder. Ett robust, integrerat systemlandskap bygger på att förändringar kan genomföras hos en part utan krav på samordning hos alla integrerade parter.

Genom nationellt fastställda tjänstekontrakt (eng. Service Contract, OASIS SOA Reference Model) vet systemleverantörer ”integrationsspråket” för de olika processer/system i vilka de förväntas integrera sina produkter (tidbokning, listning, utbyte av journalutdrag, e-recept, samordnad vårdplanering, sjukskrivning etc.). På detta sätt erhålls en standardiserad spelplan för meddelandebaserad integration av e-tjänster och informationskällor. Möjlighet skapas för effektiv utveckling av nationella integrationstjänster och e-tjänster genom att alla informationskällor uppfyller samma tjänstekontrakt för en viss typ av informationsutbyte. Semantiska punkt-till-punkt-beroenden kan därmed undvikas. Tjänstekontrakten är en teknisk slutprodukt av att regelverk för verksamhet, informatik och teknik tillämpas.

4.4.2.            Förutsättning

• Meddelandeutbyte baseras på att kommunikation etableras utgående från vem som äger informationen som ska konsumeras eller berikas, inte vilket system, plattform, datalager eller tekniskt gränssnitt som informationsägaren för stunden använder för att hantera informationen. Genom centralt administrerad förmedlingstjänst skapas lös koppling mellan informationskonsument och informationsägarens tekniska lösning.
• En arkitektur som skapar lös koppling mellan konsumenter och producenter, avseende adressering och standarder för kommunikation.
• En nationell integrationspunkt ska kunna erbjudas för varje nationellt standardiserat tjänstekontrakt, som en fasad mot bakomliggande brokiga systemlandskap. 
• Nationella tjänstekontrakt förvaltas i en nationellt koordinerad förvaltning.
• För en process inom vård och omsorg kan flera tjänstekontrakt ingå. Därför är det viktigt att alla tjänstekontrakt baseras på en gemensam referensmodell för informationsstruktur.
• Parter som samverkar i enlighet med arkitekturen integrerar med system hos parter som lyder under annan styrning (t.ex. myndigheter, kunder och leverantörer). Det kan leda till att vård- och omsorgsgivare antingen:
• Nationellt bryggar informationen (semantisk översättning) eller
• Nationellt införlivar externt förvaltat tjänstekontrakt som standard.

Observera att semantisk bryggning av information till vårdens referensmodell förutsätter en nationell förvaltning av anpassningstjänster.

• Befintliga system behöver anpassas till nationella tjänstekontrakt. Detta kan göras av leverantörer direkt i produkten, eller genom fristående integrationskomponenter (”anslutningar”). En anslutning bör ligga nära (logiskt vara en del av) det system som ansluts, oavsett om det är i rollen som konsument eller producent för anslutningen som genomförs.
• Interoperabla standarder för meddelandeutbyte tillämpas, så att integration med till exempel en Web Service kan utföras utan att anropande system behöver tillföras en för tjänsteproducenten specialskriven integrationsmodul (s.k. agent).

4.5   IT5: Lokalt driven e-tjänsteförsörjning

E-tjänsteförsörjning i vård och omsorg är i grunden driven från lokala behov. Regelverk för arkitektur stödjer att lokalt etablerade e-tjänster gradvis kan bredda sin bas av användare över vårdgivargränser och så småningom berika det nationella e-tjänsteutbudet. För invånaren erbjuder varje e-tjänstekanal en sammanhållen användarupplevelse (”virtuell portal”) oavsett vilken part som tekniskt och utvecklingsmässigt står bakom en enskild e-tjänst.

4.5.1.            Motiv

Nationella e-tjänster uppstår inom nationella utvecklings- eller upphandlingsinitiativ, men också på initiativ av landsting och kommuner, sammanslutningar av landsting eller kommuner eller hos externa aktörer. Nya nationella e-tjänster kan därför uppstå genom lokala och externa initiativ. För att externt och lokalt framställda e-tjänster ska kunna ges nationell status behöver den initiala utvecklingsinsatsen ske på ett sätt som licensmässigt, förtroendemässigt, praktiskt och tekniskt gynnar kontinuerlig breddning av e-tjänstens användning så väl som förvaltning, med nationell tillämpning och ägarskap som möjligt resultat.

E-tjänster till invånare levereras genom nationella, regionala och lokala kanaler. Ett exempel på en nationell kanal för e-tjänster inom vård och omsorg är 1177 e-tjänster, som kanaliserar e-tjänster för kontakt mellan invånaren och vård- och omsorgsgivare. Visionen för e-tjänstekanaler är att varje kanal ska ge invånaren en sammanhållen användarupplevelse – oberoende hur många parter som försörjer kanalen med e-tjänster. Målbilden för varje e-tjänstekanal är en ”virtuell portal”, där lokalt, regionalt och privat utvecklade e-tjänster kan inordnas och ge samma användarupplevelse som om de vore en del av en för kanalen central portalinfrastruktur. Vård och omsorg ges därmed möjlighet att som komplement till programstyrd utveckling av nationella e-tjänster ta tillvara innovationskraften på marknaden och hos huvudmännen.

4.5.2.            Förutsättning

• När utveckling av källkod är en del av en tjänsteleverans skall följande beaktas:
• Alla leveranser (källkod, binärer, versionshantering, stödforum och andra element) tillgängliggörs ör kunder och vid behov samarbetspartners under projektets och förvaltningens hela livscykel. Valet av licensformer samordnas nationellt genom rekommendationer.
• Upphandlade e-tjänster bör/ska fungera på de vanligaste plattformarna hos vårdgivarna och hos nationella driftspartners (Windows, Linux, Unix) t.ex. genom att vara byggda för att exekvera på en s.k. Java virtuell maskin.
• Gemensam referensmodell för e-tjänsters interna uppbyggnad stimulerar och förenklar återanvändning och överföring av förvaltningsansvar mellan organisationer.
• Minsta möjliga – men tillräcklig – mängd standarder och stödjande gemensamma grundbultar för nationella e-tjänstekanaler säkerställer att även utvecklingsenheter i mindre organisationer kan bidra med e-tjänster för en integrerad användarupplevelse och att en gemensam back-office för anslutning av huvudmän till e-tjänster finns etablerad. I den mån etablerade standarder med bred tillämpning i kommersiella e-tjänster finns (t.ex. för single-sign-on), bör de användas i syfte att möjliggöra upphandling av hyllprodukter.
• Utveckling sker mot globalt dominerande portabilitetsstandarder i de fall mellanvara (applikationsservrar) tillämpas. Det är möjliggöraren för nyttjande av free-ware och lågkostnadsverktyg i organisationer som inte orkar bära tunga licenskostnader för komplexa utvecklingsverktyg och driftsplattformar.
• Nationell (eller regional – beroende på sammanhang vård/omsorg) förvaltning är etablerad (t.ex. s.k. Portal Governance), med effektiva processer för att införliva lokalt utvecklade e-tjänster i nationella e-tjänstekanaler. Systematisk och effektiv allokering av resurser för drift är en viktig grundförutsättning.
• Genom lokal governance och tillämpning av det nationella regelverket får lokala projekt den stöttning som behövs för att från början bygga in förutsättningar för integration i samordnade (t.ex. nationella) e-tjänstekanaler.

4.6   IT6: Samverkan i federation

Samverkan över organisationsgränser sker genom federation, såsom exempelvis identitets- och behörighetsfederering.

4.6.1.            Motiv

Syftet med principen för samverkan i federation är att underlätta samverkan över organisationsgränser genom gemensamma överenskomna förutsättningar kring ett säkert informationsutbyte som ingående parter kan ha tillräcklig tillit till.

Federationsprincipen syftar också till att parter i samverkan kan tillåtas ha olika tekniska lösningar, t.ex. kring nätverk och autentiseringsteknik, så länge de gemensamma förutsättningarna är uppfyllda.

4.6.2.            Förutsättning

• Federativa utbyten över organisationsgränser bygger på gemensamma överenskomna regelverk, t.ex. kring krav på autentisering av användare i IT-system, tekniska regelverk osv.

5                   Referensarkitektur

Detta kapitel riktar sig främst till olika arkitekturfunktioner men kan också användas av organisationer som saknar arkitekturfunktion när de för dialog med IT-leverantörer.

Med hjälp av referensarkitekturen kan verksamheter planera, granska och följa upp projekt

Referensarkitekturen beskrivs utgående från tre vyer (arkitektur-domäner enl. TOGAF): 

5.1   Verksamhetsvy

Verksamhetsvyn beskriver referensarkitekturen utifrån användarens behov av att konsumera och producera information över organisationsgränser med hjälp IT – det vill säga där det finns ett behov av nationell samordning av teknisk arkitektur. Beskrivningen tar sin utgångspunkt i scenarier baserade på de behov som finns. Scenarierna har systematiserats till en allmängiltig modell för informationsåtkomst mellan olika system och organisationer.

Den grundläggande problemställningen ligger i att hitta ett systematiskt angreppssätt som ger användaren tillgång till komplett information för enskilda individer även om informationen är spridd över olika informationskällor och informationsägare. Användarna behöver veta

• var information finns och kan lämnas
• hur de får åtkomst till informationen

5.1.1.            Informationsägarskap och verksamhetsbaserad adressering

Informationsägaren är den som ansvarar för och förvaltar en viss typ av information, till exempel innehållet i journaler eller adressuppgifter.

Informationsägandets struktur inom vård och omsorg styrs av en mängd faktorer. Några är lagar, förordningar och politisk styrning. Det leder till att informationsägandet kan se olika ut för olika typer av information, till exempel kan det finnas flera informationsägare inom en organisation. Det gäller bland annat vårddokumentation, där vårdenheten är informationsägare och en vårdgivarorganisation består av flera vårdenheter.

En informationsägare kan ha ett lokalt systemstöd för att hantera informationen, eller dela systemstöd med andra informationsägare. Förhållandet mellan systemstöd och informationsägande förändras kontinuerligt. Det innebär en kontinuerligt pågående förändring av den nationella systemkartan och därmed också en utmaning för visionen om en nationellt samlad åtkomst av information för såväl invånare som medarbetare inom vård och omsorg.

Logisk adressering

För att tillmötesgå principen om lös koppling bygger referensarkitekturen på strategin att varje organisation ska kunna förändra relationen mellan informationsägare och informationskälla utan dominoeffekter över organisationsgränserna (i betydelsen informationslänkar mellan IT-system). Informationsägarens identitet blir därför basen i att nå (adressera) information över informationsgränser. Kunskapen om vilket system en viss informationsägare för stunden använder för sin informationshantering, och vilken teknisk anropsadress, denna har kapslas in i en tjänsteadresseringskatalog. Referensarkitekturen inför därför begreppet verksamhetsbaserad adressering, där verksamhet avser den informationsägande verksamheten. Verksamhetens identifierare används då som logisk adress och registeras i tjänsteadresseringskatalogen. Identifieraren kan variera beroende på kontext, se nedanstående tabell.

För vissa tillämpningar så är det ändå inte praktiskt att adressera med verksamhetsidentitet, exempelvis sammanhållen journalföring, eftersom ett och samma system kan representera många verksamheter och för att få en sammanställd lista över information för en viss individ som har information hos flera verksamheter så skulle samma system behöva anropas flera gånger. Därför införs även begreppet Källsystemsadressering. För att ändå upprätthålla en tekniskt lös koppling så förses källsystemen med en identitet och det är denna som adresseras och via tjänsteadresseringskatalogen översätts till den anropsadress som gäller för systemet.

Sättet att uttrycka en verksamhetsadress varierar per informationstyp/informationsområde. Följande tabell belyser frågan om informationsägarskap och tänkbar logisk adressering i ljuset av några representativa scenarier.

Flödesmodellen nedan visar schematiskt hur stödtjänsterna samverkar för att stödja en process som förutsätter integration över informationsägarskaps- och organisationsgränser

Figur 3 – Den generiska flödesmodellen för informationsåtkomstbehov

I följande tabell beskrivs flödesmodellen. Beskrivningen redovisar också länk till informationssystemvyn.

5.1.2.            Konkreta exempel på flödesmodeller

Typ-flödet är representativt för de flesta av behovsbildens scenarion. Några exempel visas nedan:

Figur 4 – Flödesmodeller för några scenarion

5.1.3.            Detaljering, personlig e-tjänst (invånarens tidbokning)

Exemplet med tidbokning detaljeras som typ-flöde för en nationell, personlig e-tjänst:

Figur 5 – Flödesmodell för invånarens tidbokning i vård och omsorg

Att veta vilka informationsägare som ska bidra till översikten

Att sammanställa invånarens tidbok, vore inte förenligt med rimliga svarstider om det förutsatte omedelbart uppslag mot de 100-tals tidböcker som finns i landet. Därför har arkitekturen tagit sin utgångspunkt i att det finns en informationskälla – engagemangsindex – som hålls uppdaterad med tillräckligt aktuell information om vilka informationsägare som har information om en invånare/patient.

Sammanställningen av en översikt kan då ske genom att detta index kontaktas, varefter omedelbara uppslag kan göras, adresserade till ett begränsat antal informationsägare. Nedanstående figur illustrerar engagemangsindex roll att redovisa vilka vårdenheter som håller tidbokningar för en individ.

Figur 6 – Engagemangsindex visar att invånaren har bokningar hos vårdenheterna EH1 och EH7

Att hitta informationsägarens informationskälla

Med kunskap från engagemangsindex om vilka informationsägare (verksamheter) som har tidbokningar för en invånare, är verksamhetsadressen till informationen känd (vårdenheternas identitet). Genom en tjänsteadresseringskatalog hittas den information som behövs för att tekniskt kontakta respektive informationskälla och därmed få tillgång till information om individens bokade tider.

I steg 1 har engagemangsindex redovisat att invånaren har tidbokningar hos vårdenheterna VEH1 och VEH7 (se figuren ovan). Dessa vårdenheter tillhör olika huvudmän – A och C. I steg 2 översätts verksamhetsadressen (vårdenhetens identitet) till teknisk adress (URL till tekniskt gränssnitt) för respektive vårdenhets informationskälla. I exemplet nedan (figuren) hanteras alla A:s och B:s tidbokningar av ett gemensamt system, medan huvudman C har flera bokningsmoduler, beroende på vårdenhet. Denna fördelning finns beskriven i tjänsteadresseringskatalogen. Därigenom kan steg 2 och 5 använda tjänsteadresseringskatalogen för att få VE1 översatt till teknisk adress till A och B:s gemensamma verksamhetssystem och VE7 översatt till teknisk adress till C:s verksamhetssystem för vårdenheterna 7 och 8.

Figur 7 – Tjänsteadresseringskatalogens användning i tidbokningsscenariot

5.1.4.            Säker meddelandehantering över organisationsgränser

Scenarier för säker meddelandehantering och processtöd följer i grunden samma. Några exempel på berörda scenarier är:

• Samordnad vårdplanering
• Remisshantering
• Fråga-svarsrutin för sjukskrivningsprocessen
• Ärenderutiner inom personliga e-tjänster.

Det handlar här om att utgående från ett adressregister eller annan källa till information om motparten, avgöra vilka informationskällor som behöver kontaktas för att läsa och lämna meddelanden. En förutsättning är även här att varje informationskälla som stödjer ett visst informationsbehov uppvisar ett nationellt (eller för samverkansområdet) standardiserad åtkomstgränssnitt (d.v.s. följer samma tjänstekontrakt).

Figur 8 – Flödesmodell för säker meddelandehantering/ärendehantering över organisationsgränser

En del av processen för samordnad vårdplanering handlar till exempel om att identifiera vilka organisationer (informationsägare) som behöver kontaktas för att ge en samlad bild av användarens obehandlade ärenden. När denna information är känd (d.v.s. listan av informationsägare/verksamhetsadresser där medarbetaren kan ha meddelanden), används tjänsteadresseringskatalogen för att hitta de meddelande/ärendesystem som behöver vittjas på inkomna meddelanden och ditt nya meddelande kan lämnas.

Samordnad vårdplanering

För samordnad vårdplanering kan det till exempel handla om att i översikten redovisa för användaren vilka inskrivningsärenden som väntar på att behandlas.

För att sammanställa den informationen används sortiments- och utbudskatalogen som utgångspunkt. Där finns information om vilka omsorgsgivande organisationer som har avtal med landstinget kring samordnad vårdplanering. Dessa organisationer (kommuner, privata utförare) är informationsägare som kan ha ärenden i sina respektive ärendesystem, att visa i användarens ärendeöversikt.

I många fall har aktörerna enats om en gemensam informationskälla för ärenden kring samordnad vårdplanering. Det är emellertid inte en förutsättning för arkitekturen. Det är däremot en utgångspunkt för arkitekturen att tillmötesgå varje användares behov av att se alla ärenden/meddelanden i samma översikt, oavsett om det finns en eller flera informationskällor för meddelanden/ärenden.

Sjukskrivningsprocessens fråga/svar

I sjukskrivningsprocessen utbyts säkra meddelanden mellan handläggare hos Försäkringskassan och medarbetare på vårdenheter. Det kan gälla begäran om kompletterande information kring ett medicinskt utlåtande, eller samordning av mötesbokning inför ett samrådsmöte. I fallet med sjukskrivningsprocessen initieras meddelandet (frågan) från Försäkringskassan utgående från ett ankommet medicinskt utlåtande. Information om vilken organisation som meddelandet ska riktas till, är därför redan känt. Sortiments- och utbudskatalogen är därmed inte inblandad. Ur vårdgivarens perspektiv finns bara en part att interagera med (försäkringskassan).

Figur 9 – Flödesmodell – säker meddelandehantering i sjukskrivningsprocessen

5.2   Informationssystemvy

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:

Figur 10 – Översikt, informationssystemvy

Beståndsdelarna beskrivs i nedanstående tabell:

Nedan länkas verksamhetsvyn till informationssystemvyn i syfte att redovisa hur referensarkitekturen uppfyller behovet av informationsåtkomst.

Figur 11 –

De streckade pilarna i figuren visar sambandet mellan aktiviteter och informationskällor i verksamhetsvyn och realiserande beståndsdelar i referensarkitekturen.

5.2.1.            Tjänstekontrakt

Tjänstekontrakt är en viktig förutsättning för lös koppling. Ett tjänstekontrakt specificerar ett behov av funktion och information (i form av IT-stöd) för en aktivitet i en process. Tjänstekontraktet specificerar behovet utgående från tjänstekonsumenters behov av informationsutbyte. Detta skall ske utan koppling eller bindning till något speciellt systems villkor eller förutsättningar att realisera behovet. Det innebär att en tjänsteproducent skall producera information enbart utifrån specifikationen i tjänstekontraktet, inte anpassa det till en speciell tjänstekonsuments förmågor. På motsvarande sätt skall en tjänstekonsument realiseras baserat på tjänstekontraktet och inte ta hänsyn till förmågorna hos enskilda tjänsteproducenter. På detta sätt uppnås principen om lös koppling (IT4). 

Man kan säga att summan av alla tjänstekontrakt beskriver en idealiserad vy av en tjänsteorienterad arkitektur. Men det handlar inte om att byta ut befintliga verksamhetssystem, utan att beskriva hur processernas behov av informationsutbyte ska realiseras.

Eftersom varje funktion ofta finns realiserad i många olika system i många olika verksamheter, har tjänstekontraktet en central roll i att normera hur nya, nationella e-tjänster och stödtjänster ska integreras med floran av befintliga verksamhetssystem.

Tjänstekontrakten utgör ett lingua franca för den integration av system som är en förutsättning för att realisera den nationella handlingsplanen för e-hälsa. Den kan inte förutsätta att alla verksamhetssystem byts ut och ersätts med fristående tjänstekomponenter. Den kan heller inte förutsätta att varje tjänstekonsument anpassar sitt sätt att integrera till varje förekommande verksamhetssystems specifika gränssnitt. Istället uttrycks integrationsbehoven som nationellt standardiserade tjänstekontrakt designade utgående från den process som är kravställaren på informationsutbytet. Verksamhetssystemen tillförs ”ingångar” för att kunna pluggas in som källor till information och funktion enligt processens villkor.

För att kunna tolkas, administreras och versionshanteras behöver de tjänstekontrakt som stödjer en viss process eller informationsbehov grupperas. En sådan gruppering benämns Tjänstedomän. Nationell styrning av tjänstedomäner och uppdelning i tjänster inom tjänstedomäner sker inom nationella arkitekturfunktionen (Arkitektur och regelverk). På samma sätt kan tjänstedomäner byggas upp och förvaltas inom en organisation för att ge struktur åt det interna integrationsbehovet. Det effektivaste är troligen att samordna via systemleverantörernas kundgrupper, så att nationell samordning kan ske och komma kundgrupperna tillgodo.

Uppbyggnad av tjänstekontrakt

Beskrivningen av ett tjänstekontrakt har följande beståndsdelar, som namnges på engelska:

I tabellen nedan beskrivs tjänstekontraktets beståndsdelar (namngivna på engelska).

Tjänstekontraktens användning

Tjänstekontrakten utvecklas, versionshanteras och publiceras på en öppet tillgänglig projektinfrastruktur. Alla tjänstekontrakt som ligger under en arkitekturfunktions överseende publiceras på ett enhetligt sätt på samma plats. Det underlättar för leverantörer och andra intressenter att hitta, tillämpa dem, samt att räcka in begäran om tillägg och förändringar.

I referensarkitekturen symboliseras tjänstekontrakt med ”slickepinnar”, enligt följande nedanstående figur:

Figur 12 – Varje SOA-tjänst (slickepinne) har ett gränssnitt som följer ett tjänstekontrakt

I figuren ovan följer alla SOA-tjänster (slickepinnar) samma tjänstekontrakt. Den aggregerande tjänsten returnerar en sammanställd lista av svar från samtliga vårdsystem vars tidbokningsmodul har bokningar för aktuell individ. Den virtuella tjänsten dirigerar anrop till tjänsteproducenten för respektive mottagning. Genom att alla verksamhetssystemen har anpassats till samma tjänstekontrakt, kan e-tjänsten tillföras fler och fler bokningsbara mottagningar allt eftersom vårdsystemen skapar ”ingångar” (tjänsteproducenter) enligt fastställt tjänstekontrakt. Den anpassning som görs av ett eller flera verksamhetssystem till ett tjänstekontrakt (med eller utan lokal integrationsplattform) benämns Anslutning. Det sker effektivast om ansvarig organisation har en standardiserad anslutningsarkitektur. Den tekniska vyn beskriver en referensarkitektur för anslutningar.

Strategin med tjänstekontrakt som den beskrivits här, tillämpas för alla typer av tjänsteproducenter – även stödtjänster.

RIV Tekniska Anvisningar ger detaljerade regler för utformning av tjänstekontrakt.

5.2.2.            Vägledande exempel

I resterande avsnitt inom Informationssystemvyn exemplifieras referensarkitekturens tillämpning genom vägledande exempel inom aktuella områden. Den faktiska realiseringsstrategin för respektive område fastställs av berörda arkitekturledningsfunktioner. Exemplen i t-boken syftar till att verifiera och kommunicera referensarkitekturen.

E-tjänst för invånare

Detta exempel beskriver hur den generella flödesmodellen för e-tjänster (ur verksamhetsvyn) kan realiseras enligt referensarkitekturen.

Figuren beskriver en nationell e-tjänst för tidbokning. E-tjänsten är nationell i betydelsen att den visar invånarens tidbokningar hos alla mottagningar i Sverige som är anslutna till tjänsten.

En nationell aggregerande tjänst ansvarar för att sammanställa informationen för översikten (kalendern i detta exempel) genom att samla in information från samtliga informationskällor där användaren har bokade tider. Sammanställningen sker genom att använda den virtuella, nationella tjänsten för invånarens bokade tider. Eftersom den virtuella tjänsten adresseras med mottagningens HSA-id, behöver den aggregerande tjänsten hjälp av stödtjänsten engagemangsindex för att veta vilka mottagningar som har tidbokningar för invånaren/användaren. Den virtuella tjänsten som används för att hämta invånarens tidbokningar hos en mottagning, konsulterar stödtjänsten Tjänsteadresseringskatalog för att få den tekniska adressen till den tjänsteproducent som hanterar tjänsten för respektive mottagnings tidbok.

Aktiviteter som följer efter att översikten visats (nybokning, ombokning, visa detaljer etc.) låter användaren agera mot vald mottagning. Då används motsvarande virtuella tjänster utan ”omvägen” via en aggregerande tjänst.

Sortimentskatalogen används vid nybokning, som hjälp för invånaren att besluta i val av mottagning för nybesök.

Figur 13 – Vägledande exempel för e-tjänster

Not: Riktningen på pilarna anger frågemeddelanden. Svarsmeddelanden från tjänster följer samma väg tillbaka.

Flödets realisering beskrivs utförligt i nedanstående tabell:

Åtkomst till sammanhållen journalföring

För medarbetarens olika tillämpningar, så som nationella patientöversikten och verksamhetens system för vårddokumentation finns behov av åtkomst till information inom sammanhållen journalföring och andra informationsmängder. Gemensamt är att informationen antingen har en nationell ägare (t.ex. läkemedelslista) eller är i behov av en aggregerande tjänst för att nationellt sammanställa informationen från många källor (de system som informationsägaren använder).

Det innebär att aggregerad information om invånare och patienter erbjuds av en aggregerande tjänst per tjänstekontrakt. De exponerar det tjänstekontrakt som de olika översikterna (tjänstekonsumenterna) behöver.

De aggregerande tjänsterna följer mönstret för e-tjänster (med e-tjänsten för tidbokning som exempel), förutom att e-tjänster – till skillnad från hitta/titta-tjänster - ofta är i behov av sortiments- och utbudskatalogen.

Figur 14 – Vägledande exempel för patientöversikt

Personuppgifter

Inom vård och omsorg finns många tjänstekonsumenter av personuppgifter – såväl standardsystem som lokalt och nationellt utvecklade system och e-tjänster. Det finns också många tjänsteproducenter som publicerar tjänster för åtkomst av personuppgifter. Ofta samordnas tjänsteproducenterna läns- eller regionvis, men det förekommer också mer lokala tjänsteproducenter, till exempel för information om en enskild kommuns invånare. Därför sker åtkomst enligt standardiserade tjänstekontrakt. Det ger en lös koppling mellan leverantörer av verksamhetssystem (tjänstekonsumenter) och de olika tekniska lösningar som tillämpas för mellanlager av personuppgifter inom olika organisationer. Grundinformationen kommer från skatteverket. Den hämtas till en lokal eller regional tjänst inom huvudman som berikar (illustreras av  ) med information från lokala källor (t.ex. telefonnummer och annan information som håller bristande kvalité eller saknas hos Skatteverket). Alla lokala och regionala personuppgifttjänster publicerar sedan information enligt samma, nationella tjänstekontrakt för åtkomst från interna och externa tjänstekonsumenter.

Det ger följande arkitektur för åtkomst från tjänstekonsumenter utanför den egna organisationen:

Figur 15 – Vägledande exempel för åtkomst av personuppgifter

Adressetiketten anger i detta fall kommun-kod. Tjänstekonsumenten kan även vara ett lokalt verksamhetssystem som behöver personuppgifter för en person som är mantalsskriven i annat län och därför inte finns i den lokala informationskällan. Genom att en lokal virtuell tjänst anropas (ingår i tjänstekonsumenten i denna figur), sker (vid kommun-kod i annat län) vägval till den nationella virtuella tjänst, som dirigerar frågan till tjänsteproducent hos ansvarigt län.

Replikering av stödtjänst

Stödtjänster är logiskt sett nationella. För att tillmötesgå höga krav på tillgänglighet kan stödtjänster behöva replikeras för att kunna hanteras inom samma infrastruktur som verksamhetskritiska tjänstekonsumenter (d.v.s. att finnas ”nära” tjänstekonsumenten).

Ett exempel kan vara spärrtjänsten som informationskälla. Patientdatalagen kräver att en vårdenhet på patientens begäran kan spärra andra vårdenheters åtkomst av patientens journal. Spärren gäller såväl inom vårdgivare som för sammanhållen journalföring.

Det betyder att spärrar förda för alla vårdenheter inom en vårdgivare behöver vara tillgängliga för vårdgivarens vårddokumentationssystem och regionala översikter. Det betyder också att spärrar behöver vara tillgängliga för tillämpningar som visar information från den nationella aggregerande tjänsten ”Hämta journalutdrag” (se vägledande exempel för ”Åtkomst till sammanhållen journalföring”). Eftersom patientsäkerheten påverkas av tillgängligheten hos vårdgivarnas system för vårddokumentation, är också tillgängligheten till spärrar viktig för patientsäkerheten.

Tillgängligheten för vissa stödtjänster till vårddokumentationssystemen behöver därför garanteras av vårdgivaren. Möjligheten att replikera stödtjänster är utpekad som strategiskt viktig. Mönstret för sådan replikering beskrivs här med spärrtjänsten som belysande exempel.

Figuren nedan visar hur ny information i en instans av spärrtjänsten vidarebefordras till andra instanser. Varje instans har ett datalager.

Figur 16 – Ny spärrinformation i en instans replikeras till övriga instanser.

5.3   Teknisk vy

I den tekniska vyn beskrivs identifierade stödtjänster och infrastrukturtjänster (plattformsfunktioner).  Den beskriver också den federation som uppstår då referensarkitekturen tillämpas lokalt som del i en anslutningsarkitektur.

Referensarkitekturen lyfter fram de infrastrukturkomponenter som behövs för att möjliggöra systematisk realisering av tjänstetyperna från informationssystemvyn. Den beskriver också de stödtjänster som dessa tjänstetyper är beroende av. Referensarkitekturen beskriver inte vilka komponenter som finns etablerade. Det kommer att variera mellan huvudmännen över tiden. Referensarkitekturen ska ses som underlag för strategisk planering av huvudmannens arkitektur-etablering. Här kan t.ex. TOGAF ADM ge vägledning i faserna E-G (se avsnittet ”ARKITEKTURENS UTVECKLING OCH PRAKTISKA ANVÄNDNING”). Den tekniska referensarkitekturen är målbilden som matchas mot nuläget. Beskrivning av gapet blir underlag för strategi och färdplan för att etablera arkitekturens komponenter.

Alla komponenter positioneras här som ”nationella”. Det görs för att minska abstraktionsnivån i beskrivningarna. I de flesta fall kan ”nationell” bytas ut mot ”regional” eller ”lokal” om referensarkitekturen tillämpas för informationsutbyte inom en region. ”Nationell” kan då läsas som ”Regional”. Samspelet mellan nationell infrastruktur och regional infrastruktur beskrivs i avsnittet ”Referensarkitekturen i federation”.

Följande figur ger en överblick av komponenterna i denna beskrivning.

Figur 17 – Komponenter i referensarkitekturen

Komponenterna beskrivs översiktligt i följande tabell:

5.3.1.            Tjänsteadresseringskatalog

Modellen nedan beskriver den informationsstruktur som behövs för att representera verksamhetsadressering och behörighetsstyrning i en tjänsteadresseringskatalog:

Figur 18 – Datalager, tjänsteadresseringskatalog

5.3.2.            Engagemangsindex

Komponenten Engagemangsindex innehåller aktuell information om en individs aktuella engagemang inom vård och omsorg. Engagemang används här som en generell term för olika typer av relationer mellan vård/omsorg och invånaren, som det finns behov av att känna till för det syfte som engagemangsindex tjänar (se Verksamhetsvy, ”Att veta vilka informationsägare som ska bidra till översikten”). Flera olika engagemangstyper hanteras. Några exempel kan vara Journalateckningar, Diagnoser, Bokad tid, Inskriven.

Engagemangsindex är en nationell stödtjänst som används som index till en invånares engagemang hos olika verksamheter: 

• Vid vilka vårdenheter har individen gällande tidbokningar (Tidbokning)?
• Vid vilka vårdenheter finns journaluppgifter om patienten (Vårdrelation)?
• Vid vilka vårdenheter är individen inskriven (Inskriven)?

Genom att använda detta index kan aggregerande tjänster sammanställa och presentera information (t.ex. en patientöversikt) om individen ur ett nationellt perspektiv utan att behöva fråga varje system i landet varje gång för att ta reda på om det finns information.

De informationsbärande systemen uppdaterar indexet via tjänsten Update. Vad och hur indexet ska uppdateras med varierar något från domän till domän och beskrivs i respektive tjänstekontraksbeskrivning

Följande UML-modell beskriver den informationsstruktur som behövs för att representera invånarens engagemang i en engagemangsindextjänst:

Figur 19 – Datalager, engagemangsindex

Mönstret för hur index uppdateras beskrivs i informationssystemvyns vägledande exempel ”Uppdatering av engagemangsindex”.

5.3.3.            Referensarkitekturen i en federation

Referensarkitekturen förutsätter att huvudmännen ansluter verksamhetssystem i enlighet med nationellt fastställda tjänstekontrakt och fastställd standard för teknisk interoperabilitet. Följande figur visar ett exempel på hur den tekniska referensarkitekturen kan tillämpas lokalt som en del i en anslutningsarkitektur. Arkitekturen i skissen tar hänsyn till federationsprincipen (IT6) genom att perimeterskyddet är samma för Sjunet och Internet.

Symbolförklaringar:

	Certifikat: HCC Funktion för autentisering och kryptering. Båda parter i en anslutning uppvisar ett certifikat. Tjänstekonsumentens certifikat förutsätts vara HCC Funktion för autentisering och kryptering (HSA-id i subject.serialNumber). Tjänsteproducentens certifikat förutsätts ha korrekt commonName (matchning mot DNS) och av utgivare som är godkänd av tjänstekonsumentens förvaltning/ägare.
	Certifikat för server-komponenter. HCC Funktion för autentisering och kryptering med värdet på attributet ”subject.commonName”. commonName förutsätts överensstämma med DNS-namn för att nå server-komponentens tjänster. ”vp” betyder ”virtualiseringsplattform”.
	Reverse-proxy. Den komponent i skalskyddet som kan nås från utsidan genom brandväggsöppning. Kan i sin tur nå virtualiseringsplattformen i skyddad zon.

Figur 20 – Exempel, tillämpning av teknisk referensarkitektur inom huvudman

Figuren illustrerar ett exempel på anslutningsarkitektur i federation med lokal (inom huvudman) instans av referensarkitekturen, där integration sker över internet och Sjunet. (Observera att federation här syftar till informationsutbyte. Federation i syfte att stödja navigering mellan e-tjänster över huvudmannagränser (SAML, SSO) är en frågeställning som är oberoende av detta exempel, men som också täcks av IT6.)

Grundläggande egenskaper i arkitekturen:

• Demilitariserad zon (DMZ) mellan externt nät och skyddad zon (internt nät)
• Extern tjänstekonsument styrker sin identitet med ett HCC Funktionscertifikat
• Server-komponenter (reverse proxy, tjänsteplattform, tjänsteproducenter) uppvisar servercertifikat med korrekt commonName i Subject så att klient kan verifiera att det är rätt part som svarar
• Reverse proxy (lastbalanserad) bryter https/tls-sessionen i DMZ, kopierar klientens identitet (tjänstekonsumentens HSA-id) från klient-certet (attribut subject.serialNumber) till http-header och skickar RIVTA-meddelandet vidare till intern tjänsteplattform genom poolad https-session (alternativt är insynsskydd tillgodosett på annat sätt i denna förbindelse)
• Intern tjänsteplattform (virtualiseringsplattformen kompletterad med andra integrationsmönster efter behov) läser av tjänstekonsumentens HSA-Id från http-header om anrop kommer från DMZ, annars från attributet subject.serialNumber i klient-cert (vid internt anrop), genomför behörighetskontroll och vägval baserat på cachad information från tjänsteadresseringskatalog och dirigerar meddelandet vidare till tjänsteproducenten.

I den skyddade zonen finns komponenten Anslutningsstöd, som ger möjlighet att på ett systematiskt sätt normalisera olika verksamhetssystem och andra datakällor till nationella och huvudmanna-specifika tjänstekontrakt enligt nationell standard för teknisk interoperabilitet (RIVTA). I exemplet med direkt koppling från huvudmannens tjänsteplattform till verksamhetssystemet, har leverantören (t.ex. genom beslut i kundgrupp) anpassat systemet till nationella tjänstekontrakt.

När olika huvudmäns tillämpning av referensarkitekturen länkas samman, uppstår en federation enligt följande figur:

Figur 21 – Referensarkitekturen i federation – nationellt perspektiv

I den federerade strukturen uppstår ett antal egenskaper som är gynnsamma för kvalitén i informationsutbytet över huvudmannagränser:

• Varje huvudmans brandvägg kan begränsas till att släppa in trafik från nationella tjänsteplattformen
• Nationella projekt får en motpart hos huvudmannen som ansvarar för att det finns en tjänsteproducent per tjänstekontrakt och att eventuella behov av att normalisera åtkomst till verksamhetssystem och informationskällor tillgodoses av huvudmannen genom lokalt anslutningsstöd.
• Samordningsaktiviteter relaterade till huvudmannens IT-stöd i syfte att ansluta till nationella tjänstekontrakt slår inte upp mot nationella projekt.
• Det är bara tjänsteplattformens (eller plattformarnas) publika nycklar som behöver hanteras av huvudmännen. Effekten av att tjänstekonsumenters och tjänsteproducenters publika nycklars giltighetstid går ut, påverkar därmed bara tjänsteplattformsinstanserna.

Det omvända förhållandet uppstår när tjänstekonsumenter hos huvudmannen kommunicerar med nationella tjänsteproducenter, enligt följande figur:

Figur 22 – Referensarkitekturen i federation - huvudmannaperspektivet

T-boken över tiden

Bilaga – Ordlista och förkortningar

Ordlista

För termer som inte återfinns i denna ordlista hänvisas till ordlistan som är publicerad på rivta.se http://rivta.se/documents/ARK_0035

Förkortningar

Följande personer har deltagit i framtagandet av T-boken: