Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

T-bokens tekniska arkitektur

Styrande principer, vägledande exempel och teknisk referensarkitektur

för vård och omsorg


Revision D

ARK_0019

2020-12-08


Förord

Den första utgåvan av tekniska arkitektur, populärt kallad för T-boken, togs fram ensidigt av landstingsrepresentanter och speglade därmed i huvudsak landstingsperspektivet för vård och omsorg.

T-boken kommer att vara ett av underlagen när Arkitektur och regelverk inom Inera granskar de nationella projekt och förvaltningsobjekt som pågår för att realisera strategin för nationell eHälsa. En stor fördel som har uppnåtts genom medverkan från kommunrepresentanter är därmed den ökade möjligheten att de nationella projekten och förvaltningsobjekten inom ramen för Inera på sikt även följer en teknisk arkitektur som passar kommuner.

Utgångspunkten för arbetet med den tekniska arkitekturen har varit vård och omsorg. T-boken är en del av det arbete som drivs inom Arkitektur och regelverk inom Inera.  

Förord till Revision D

Denna revision omfattar endast en mindre uppdatering av riktlinjerna för lokalt driven e-tjänsteförsörjning.

T-boken är en arkitekturell beskrivning av hur man ska lösa interoperabilitetsbehov för informationsdelning inom svensk hälso- och sjukvård. Då hantering av källkod och val av licensmodell inte i huvudsak är en arkitekturell fråga utan ett lokalt beslut i de organisationer som realiserar tjänster enligt T-boken och dess anvisningsdokument har vi valt att förändra skrivningarna i kapitel 4.5. 



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. 


Intressent

Behov

Har uttryckts av

Projekt och förvaltningar av regionala och nationella
e-tjänster för invånare och medarbetare

Att kunna förlita sig på regionala och nationella standardiserade och konsoliderade integrationsgränssnitt för de integrationer som behöver göras mot vård- och omsorgsgivarnas system.

Att det finns förvaltningar, processer och plattformar som ger repeterbarhet, effektivitet, säkerhet och robusthet när nya integrationsgränssnitt ska realiseras.

Att en leverantörsoberoende spelplan för en federerad säkerhetsarkitektur för följsamhet mot patientdatalagen och Socialtjänstlagen är beskriven.

Flera nationella projekt och förvaltningsobjekt.

Förvaltning av nationella standarder

Att nya standarder för samverkan kan införas successivt. Att etablerade samverkan inte blir ett hinder för att utveckla standarder utgående från nya krav rörande säkerhet, interoperabilitet och kvalité.

Arkitektur och regelverkingens förvaltning av RIV Tekniska Anvisningar,

Andra nationella förvaltningsobjekt

Vård- och omsorgsgivares IT-förvaltningar.

Att det finns ett nationellt standardiserade, förvaltade och driftsatta integrationsgränssnitt för integration mot tjänster som är gemensamma för alla vård- och omsorgsgivare, så som för de nationella projekten inom ramen för Inera, myndighetstjänster etc. Det är en nödvändighet för att systemleverantörerna ska se strategiskt på att integrera med den framväxande nationella arkitekturen.

Att det lokala IT-stödets struktur och sammansättning kan förändras genom lokala beslut, utan att det krävs nationell samordning/fastlåsning som resultat av att befintligt IT-stöd är integrerat med omgivningen.

Att säkerhetsarkitekturen för följsamhet mot PDL och SOL är etablerad såväl lokalt som regionalt.

IT-arkitekter hos huvudmän.

Samverkansorganisationer såsom Sambruk

Flera samverkansorganisationer, såsom Sambruk, arbetar aktivt med arkitektur för kommuner. Sambruk har bland annat producerat intellektuellt kapital i form av handledningar och riktlinjer för en kommuns hela verksamhetsområde (e-arkitektur). I dessa handlingar är mötet med medborgaren och kommunikation med myndigheter väsentliga.


http://www.sambruk.se/



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änsteutformningService 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.
  • Grunden för ett säkert federativt utbyte är att det finns en tillit till övriga parters respektive organisatoriska och tekniska lösningar. För att mäta och jämföra tillit bör lösningar och processer klassificeras i överenskomna tillitsnivåer.
  • Gemensamma gränssnitt i alla federativa utbyten finns framtagna och beskrivna, vilket möjliggör kostnadseffektiva och leverantörsneutrala lösningar.
  • Organ och processer behöver finnas för att godkänna utgivare av elektroniska identitetsintyg och certifikat som är giltiga i federationen.
  • Aktörer i olika nät, inklusive öppna nät, ska vara välkomna i elektronisk samverkan genom att samverkande komponenter samt kommunikationen dem emellan är säkra.
  • En strävan bör vara att gränsöverskridande kommunikation möjliggörs över Internet.
  • Vid utformning av IT-lösningar för identitets- och behörighetsfederering, tillämpas de styrande principerna i "Referensarkitektur - Identitet och åtkomst"  (http://rivta.se/documents/ARK_0046avseende bland annat
    • att överenskomma ett gemensamt tillitsramverk i federationen
    • att kunna jämföra autentiseringslösningars styrka och tilliten till dessa.
    • att kunna jämföra olika processer för att utfärda elektroniska identitetshandlingar och skapa tillit till dessa.
    • att användarattribut kopplade till identitet och behörigheter hanteras på ett kvalitetssäkert sätt med ett tydligt ansvar för respektive användarorganisation.
    • att tillämpa vid var tid överenskomna tekniska ramverk för federativt utbyte.

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): 

Vy

Beskrivning

Verksamhetsvy

Vyn beskrivs med typ-flöden som kompletterats med konkreta exempel. Här beskrivs också begreppet informationsägande, som har en central inverkan på arkitekturens utformning.

Informationssystemvy

Beskrivningar visar hur det integrerade systemets funktionalitet kategoriseras och fördelas i tjänster, i syfte att realisera IT-stödet som kravställs.

Vyn kompletteras med exempel på hur referensarkitekturen kan tillämpas (mål-arkitekturer) för några befintliga och planerade förvaltningsobjekt.

Informationssystemvyn beskriver också begreppet tjänstekontrakt som strategi för att realisera semantisk interoperabilitet.

Teknisk vy

Vyn beskriver identifierade stödtjänster och infrastrukturtjänster.  Den beskriver också den federation som uppstår då referensarkitekturen tillämpas lokalt som del i en anslutningsarkitektur.


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.

Scenario

Beskrivning

Ägarskap

Adressbegrepp

Kundval

Vissa kommuner har infört kundval inom omsorg. Det innebär att en brukare efter biståndsbeslut kan välja utförare för sitt bistånd. Brukaren kan också göra omval eller icke-val. Omsorg enligt LOV ska alltid också vara tillgänglig från kommunen. Kundval administreras av kommunerna.

Kommun.

kommunkod

Vårdval

Vårdval innebär att en medborgare ber sitt landsting redovisa vårdenheter som är tillgängliga för listning. Landstinget kan ha avtal med gränskommuner i andra landsting och redovisar då även dessa vårdenheter för sina invånare.

Landsting

Landstingskod

Tidbokning

Patientens tidbokning sker utgående från mottagning. Det är i hög grad en spegling av att patienten ringer eller på annat sätt direkt eller via ombud meddelar sig med personalen på en vård- eller omsorgsenhet för att få en tid bokad.

Vårdenhet/mottagning.

Vårdenhetsid

Medicinskt utlåtande

Läkare på en vårdenhet utfärdar ett medicinskt utlåtande som skickas till Försäkringskassan. Försäkringskassan kan begära kompletterande uppgifter av den läkare som utfärdade utlåtandet.

Informationsägarskapet hos uppgiftslämnaren är det samma som för patientjournalen (vårdenhet enl. PDL), då det som lämnats ut dokumenteras i journalen.

Informationsägandet på myndighetssidan är nationellt – d.v.s. på bolagsnivå.

Vårdenhetsid (myndighetsid på mottagande sidan)

Sammanhållen journal

Sammanhållen journalföring (hitta, titta) förutsätter att journalutdrag kan utbytas över vårdenhets- och vårdgivargränser, under beaktande av de restriktioner som ställs av lagar och förordningar. Det innebär att sök- och visningsfunktioner i nationella eller lokala tillämpningar genom meddelandeutbyte bereds åtkomst till journalanteckningar i andra vårdgivares journalsystem.

Vårdenhet, enligt definition i PDL.

Källsystemsid

Sammanhållen vårdplanering

Vid sammanhållen vårdplanering upprättas gemensamma vårdplaner mellan den kommunala omsorgsgivaren och en eller flera vårdgivare inom landstinget. Vi har en konkurrensutsatt marknad med privata aktörer som agerar på nationell nivå inom både vård och omsorg. Samordnad vårdplanering sker vanligen genom att vård- och omsorgsgivare delar systemstöd för den gemensamma SVPL-processen. Nationella privata aktörer har eget systemstöd, varför meddelandekanaler mellan olika aktörers SVPL-processtöd i en framtid kan behöva upprättas. Informationen som hanteras är planer och status kring vårdprocessinstanser, där varje instans är kopplad till en patient.

Den som tillfört en informationsmängd i processen (t.ex. utskrivningsmeddelande) är ägare för respektive informationsmängd. Dessutom dokumenterar varje part sin bild av hälsotillstånd och aktiviteter i respektive dokumentationssystem (Se sammanhållen journalföring).

Vårdenhetsid


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.

Aktivitet

Beskrivning

Länk till informationssystemvyn

Översikt

Översikten syftar till att sammanställa en nationell vy av patientens/individens engagemang av ett visst slag (det som är relevant för e-tjänsten i fråga).


-        Steg 1

Genom nationellt engagemangsindex sammanställs patientens engagemang av aktuell typ. Det är en lista med en post per informationsägare som har information av aktuellt slag om patienten/invånaren.

Tjänsteproducent (Stödtjänst Engagemangsindex)

-        Steg 2

För varje informationsägare hämtas teknisk adress till aktuell tjänsteproducent för aktuellt tjänstekontrakt. Det finns alltid exakt en per informationsägare, men flera informationsägare kan dela tjänsteproducent. Exakt vad som identifierar en informationsägare är avhängigt tjänstedomän/process.

Tjänsteproducent (Stödtjänst Tjänsteadresseringskatalog)

-        Steg 3

Varje tjänsteproducent levererar information om patienten enligt aktuellt tjänstekontrakt. När svar inkommit från alla tjänsteproducenter presenteras översikten för användaren (invånare eller medarbetare).

Tjänsteproducent (aktuellt Verksamhetssystem)

Detaljer

Denna delprocess representerar användarens behov av fördjupad information om enskilda engagemang.


-        Steg 4

(alt. till steg 5+6)

Om användaren efter att ha betraktat översikten, bestämmer sig för att etablera ett nytt engagemang, görs sökning i utbudskatalogen, efter en utförare (tillika blivande informationsägare).

Tjänsteproducent (Stödtjänst Sortiments- och utbudskatalog)

-        Steg 5

Användaren har bestämt sig för att begära ytterligare detaljer kring ett av engagemangen i översikten.

Som steg 2 men denna gång endast för en informationsägare, och för tjänstekontrakt som syftar till att hämta detaljerad information om ett engagemang.

Tjänsteproducent (Stödtjänst Tjänsteadresseringskatalog)

-        Steg 6

Med den tekniska adressen från steg 5, kan detaljer kring ett engagemang efterfrågas från aktuell tjänsteproducent.

Tjänsteproducent (aktuellt Verksamhetssystem)

Redigera

Användaren har beslutat att redigera ett befintligt engagemang eller skapa ett nytt, beroende på om steg 4 passerades eller inte.


-        Steg 7

Som steg 2 men denna gång endast för en informationsägare, och för tjänstekontrakt som syftar till att redigera befintligt eller skapa nytt (om steg 4) engagemang.

Tjänsteproducent (Stödtjänst Tjänsteadresseringskatalog)

-        Steg 8

Användaren redigerar information eller skapar ny information i nationella e-tjänstens redigeringsvy. Med den tekniska adressen från steg 7, kan detaljer kring ett nytt eller befintligt engagemang lämnas till verksamhetssystemet genom aktuell tjänsteproducent. 

Tjänsteproducent (aktuellt Verksamhetssystem)



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:

Beståndsdelar

Beskrivning

Aktörer

Aktörer använder IT-stödet genom de kanaler som står till förfogande.

Medarbetare

Medarbetare inom professionen, hos kommuner, landsting och privata aktörer. De kan även agera ombud för en invånare.

SHS…

Kanaler för externa systemaktörer som lyder under andra regelverk än denna referensarkitektur (EPSOS avslutades 2014).

Invånare

Privatpersoner som agerar i egen identitet eller som ombud för annan invånare. Avser även invånare i rollen som patient/Vårdtagare och dess anhöriga.

Tjänste-konsumenter

Informationssystem där aktörens agerande leder till automatiskt informationsutbyte med andra system (tjänsteproducenter).

Verksamhets-system

Verksamhetssystem i rollen som tjänstekonsument, som integrerar med information från andra källor. Verksamhetssystemet når extern information och funktion genom en extern integrationspunkt per typ av tjänst.

Exempel:

-        Vårdsystem använder tjänsten ”skapa e-recept” för att skapa ett nytt e-recept hos apotekens service.

-        Lokalt journalsystem använder tjänsten ”hämta journalutdrag” för att ge användaren en nationell vy över patientens vårdhistorik.

-        Vårdsystem använder tjänsten ”registrera medicinskt utlåtande” för att skapa ett sjukskrivningsärende hos försäkringskassan.

-        Ett system för samordnad vårdplanering använder tjänsten ”hämta bokade tider” för att hämta alla tidbokningar som patienten har hos olika vårdgivare

Partner-ingång

Det finns tjänstekonsumenter hos myndigheter och andra organisationer som tillämpar andra regelverk för integration än vård- och omsorg. En partneringång översätter från den externa partens standarder för säkerhet, kommunikation och adressering till motsvarande standarder inom vård- och omsorg.

Exempel:

-        Ta emot meddelanden från myndigheternas SHS-infrastruktur och efter omkuvertering enligt RIV Tekniska Anvisningar, dirigera vidare till aktuell tjänst inom vård och omsorg.

-        Ett konkret exempel är tjänst för att rapportera sjukskrivningsintyg till försäkringskassan. Frågemeddelandet enligt RIV Tekniska Anvisningar skickas till tjänsteväxel för omformning och vidareförmedling in försäkringskassans SHS-nod. Kvittensen levereras i det omvända förloppet.

E-tjänst

E-tjänster för invånare och medarbetare av typen Direkttjänst kopplas till verksamhetssystem och andra informationskällor genom tjänster (aggregerande och virtuella tjänster).

Exempel på e-tjänster av typen direkttjänst:

-        Olika e-tjänster i 1177 e-tjänster med online-koppling till bakomliggande verksamhetssystem, så som Tidbokning och Listning (vårdval/kundval).

-        Nationella patientöversikten webbapplikation, som försörjs med information från aggregerande tjänster.

E-tjänster av typen Ärenderutin är e-tjänster vars realisering består i konfigurerade ärendeflöden i därför anpassade verktyg. Beroende på krav från enskilda processer, behöver dessa konsumera tjänster som tillhandahåller information från verksamhetssystemen.

Exempel:

-        Back-office-flödet för invånartjänster av ärende-typ

-        Remiss-och-svarshantering

-        Samordnad vårdplanering

Aggregerande tjänster

En aggregerande tjänst är en integrationstjänst som för en viss individ/patient sammanställer en nationell vy av informationen av den typ som är aktuell för tjänsten i fråga.

För att inte behöva vända sig till alla informationsägare i landet, är aggregerande tjänster beroende av stödtjänsten Engagemangsindex. Där finns uppdaterade nationella index över vilka informationsägare som har information av vilket slag kring en viss invånare/patient. På så sätt erhåller aggregerande tjänster information om vilka verksamheter som behöver kontaktas genom virtuell tjänst för att samla in information.

Varje aggregerande tjänst förlitar sig på en virtuell tjänst av samma typ (tjänstekontrakt) för att förmedla varje frågemeddelande (ett per informationsägare) till respektive informationsägares tjänsteproducent.

Exempel:

-        Tjänsten ”hämta journalutdrag” hämtar och sammanställer journalinformation av begärd typ från alla vårdenheter som har journalinformation om aktuell patient.

Engagemangsindex

Syftet är att tillhandahålla en indextjänst på nationell nivå som även kan tillämpas regionalt och i andra samverkansstrukturer. Ett engagemangsindex är en förutsättning för översikter som annars skulle krävt anrop av ett orimligt antal tjänsteproducenter på spekulation.

Indexet uppdateras av de informationsbärande systemen genom tjänsten Update. Respektive tjänstedomän specificerar specifika regler för uppdateringen och hur tjänstekontraktet Update ska användas.

Virtuella tjänster

Integrationstjänst som är en nationell ställföreträdare för alla lokala tjänsteproducenter som uppfyller ett tjänstekontrakt. Den uppträder som om det fanns en nationell tjänsteproducent, men dirigerar vidare frågemeddelanden till respektive informationsägares tjänsteproducent och förmedlar svarsmeddelandet i retur. Det sker med hjälp av en adressetikett som tjänstekonsumenten bifogar frågemeddelandet.

Detta symboliseras i bilden av en ikon:

I samband med vidareförmedling verifieras att tjänstekonsumenten är behörig att integrera med adresserad informationsägare.

Virtuella tjänster använder den i meddelandekuvertet obligatoriska logiska adressen (informationsägande verksamhets eller källsystems identitet) för att efter uppslag i tjänsteadresseringskatalogen (stödtjänst), vidarebefordra frågemeddelandet till rätt tjänsteproducent (under förutsättning att informationsägaren godkänt anrop från tjänstekonsumenten).

Exempel:

-        Den virtuella tjänsten ”Hämta individens tidbokningar” förmedlar frågemeddelanden vidare till respektive vårdenhets tjänsteproducent.

-         Den virtuella tjänsten ”Hämta individens listningar” (kundval/vårdval) förmedlar frågemeddelanden vidare till respektive läns eller kommuns tjänsteproducent.

Tjänste-producenter

Tjänsteproducenter uppvisar ett tekniskt gränssnitt som möjliggör för tjänstekonsumenter att genom frågemeddelanden förändra eller begära information.

Det tekniska gränssnittet följer fastställda standarder för säker meddelandebaserad kommunikation (teknisk interoperabilitet). De hanterar frågemeddelanden och producerar svarsmeddelanden enligt för funktionen fastställt nationellt tjänstekontrakt (semantisk interoperabilitet).

Verksamhets-system

Ett verksamhetssystem agerar vanligen tjänsteproducent för att den eller de informationsägare vars information hanteras i systemet ska tillgängliggöras för åtkomst av tjänstekonsumenter i egen eller annan verksamhet. Det sker antingen direkt i verksamhetssystemet, genom att det anpassats till aktuella tjänstekontrakt, eller genom en s.k. anslutningsarkitektur.

I det senare fallet tillämpas vanligen någon form av integrationsmellanvara – så som produkter av kategorin ”enterprise service bus” för att utgående från systemets ursprungliga gränssnitt tillgängliggöra tjänsten enligt aktuellt tjänstekontrakt.

Eftersom en organisation kan ha många informationsägare och därigenom flera olika informationssystem för samma tjänstekontrakt, riskerar kontaktytan för nationella initiativ bli komplex. Det är i dessa fall angeläget att organisationen kan erbjuda en kontaktpunkt – såväl organisatoriskt som tekniskt som motpart i nationella integrationsprojekt. Det kan t.ex. ske genom en integrationsverksamhet med processer, verktyg och metoder för en anslutningsarkitektur.

I det fall ett upphandlat system (”hyllprodukt”) ska anpassas till ett nationellt tjänstekontrakt, samordnas detta med fördel genom kundgrupper. Med kundgrupper avses användarföreningar som samordnar beställningar av ny funktionalitet i de fall utvecklingen inte ingår i leverantörens utvecklingsplaner.

 Ikonen i figuren symboliserar att tjänsteproducenter av denna typ vanligen finns i många förekomster för samma funktion. Det förekommer att flera organisationer delar systeminstans. Det sker t.ex. då ett landsting erbjuder privata vårdgivare använda landstingets gemensamma system för vårddokumentation. Ett annat exempel är system vars funktion syftar till att samordna processer förutsätter med verkan av flera organisationer. Samordnad vårdplanering är ett sådant exempel. Ett gemensamt system delas då vanligen av landsting och kommuner.

Exempel:

-        Region Skånes regionala tjänsteplattform publicerar tjänsteproducenter enligt de nationella tjänstekontrakten för invånarens vårdvalsprocess (kundval).

-        Stockholms Läns Landsting har uppdragit åt systemleverantören att anpassa listningssystemets gränssnitt efter de nationella tjänstekontrakten för invånarens vårdvalsprocess. Systemet har därmed blivit tjänsteproducent för listningskontrakten.

Partner-utgång

Partnerutgången hanterar på ett systematiskt sätt (utan semantisk bindning) frågemeddelanden från tjänstekonsumenter inom vård och omsorg adresserade till informationsägare utanför vård och omsorg som tillämpar andra tekniska standarder (engelsk term: ”Gateway”)

 Ikonen i figuren symboliserar att det inom vård och omsorg finns en nationell instans av infrastruktur partnerutgång mot externa parter.

Exempel:

-        Ta emot ett fråge-meddelande från nationell virtuell tjänst inom vård- och omsorg som är adresserad till en SHS-myndighet (t.ex. försäkringskassan). Tjänsteväxeln utför omkuvertering enligt SHS-standard och dirigerar vidare till aktuell SHS-nod.

Stödtjänster

Stödtjänster är tjänsteproducenter som tillhör den tekniska domänen, eller hanterar information som inte är bunden till någon specifik verksamhetsprocess.

 Ikonen i figuren symboliserar att en stödtjänst logiskt sett är nationell, men att det av tillgänglighetsskäl, kommersiella eller juridiska skäl kan finns flera instanser (t.ex. inom ett landsting eller en kommun). Dessa hålls dock synkroniserade, så att varje instans representerar det nationella perspektivet, eller samverkar i federation på ett transparant sätt.

Exempel:

-        Personuppgiftstjänst

-        Spärrtjänst (invånarens spärr mot sammanhållen journalföring)

-        Katalogtjänster (Adressregister, tjänsteadresseringskatalog etc.)


Infrastruktur

Understödjande infrastruktur som skapar förutsättningar för åtkomst, informationsutbyte, identifiering etc. Understödjer alla lager på olika sätt.

-        PKI-infrastruktur (smarta kort, certifikatsutgivning, OSCP etc.)

-        Datanät, brandväggar, ”reverse proxies”

-        Tjänst för autentisering och intygsstämpling

-        Mellanvara som utgör plattformar (systematisk realisering) för olika tjänstetyper (virtualiseringsplattform för virtuella tjänster, orkestreringsmellanvara för aggregerande tjänster, arbetsflödesmotorer för ärendeflödestillämpningar etc.)

-        Tjänsteväxel för systematisk realisering av partneringångar och partnerutgångar

Infrastruktur bör i största möjliga mån bygga på externt förvaltade standarder och stödja federation utan produktberoenden eller beroenden till centraliserade lösningar. Interoperabilitet, portabilitet och tillgänglighet är nyckelord.


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).

Komponent

Beskrivning

Domän

Alla tjänstekontrakt tillhör en domän.

Hur domäners namnsättning går till beskrivs på rivta.se

Domännamnsättning - anvisning

Tjänstekontrakt

Tjänsten uttrycks som ett verb + substantiv, på engelska. Exempel:

- GetSubjectOfCareSchedule

Huvudversion

Anger aktuell huvudversion, som löpande heltal. Tjänstekonsumenter och tjänsteproducenter som realiserar olika huvudversioner av ett tjänstekontrakt är inte kompatibla (kan inte kommunicera).

Underversion

Anger aktuell underversion, som löpande heltal. Tjänstekonsumenter och tjänsteproducenter som realiserar olika underversioner av ett tjänstekontrakt är kompatibla (framåt/bakåt).

In-meddelande

Informationsstrukturen som beskriver nyttolasten för frågemeddelandet. Meddelandedefinitioner kan återanvändas mellan tjänstekontrakt.

Ut-meddelande

Informationsstrukturen som beskriver nyttolasten för svarsmeddelandet (finns inte för alla tjänstekontrakt, beroende tjänsteinteraktionstyp). Informationsstrukturen (eller del av) för nyttolast kan återanvändas mellan tjänstekontrakt.

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:

Steg

Beskrivning

1-fråga

Tidboknings-e-tjänsten ber den nationella, aggregerande tjänsten ”Hämta bokade tider” att sammanställa alla tidbokningar för inloggad invånare. 

2

Den aggregerande nationella tjänsten för tjänstekontraktet ”Hämta bokade tider” frågar stödtjänsten Engagemangsindex om HSA-id för alla mottagningar där invånaren har tidbokningar. Svaret innehåller en lista med tre vårdmottagningar hos två olika vårdgivare.

3, 6, 9

För var och en av mottagningarna frågar den aggregerande nationella tjänsten för ”Hämta bokade tider” den virtuella tjänsten för ”Hämta bokade tider” efter patientens tidbokningar hos respektive mottagning. De tre anropen görs parallellt, för att minska användarens väntan på det sammanställda svaret.

5, 8, 11

Den virtuella tjänsten för ”Hämta bokade tider” blir anropad tre gånger, parallellt. Varje anrop avser en informationsägare (vårdmottagning). För varje anrop tar den virtuella tjänsten hjälp av tjänsteadresseringskatalogen (4, 7, 10) för att översätta mottagningens HSA-id till den tekniska adressen för mottagningens ”hämta bokade tider”-tjänsteproducent. Med hjälp av den tekniska adressen kan virtuella tjänsten fråga aktuell tjänsteproducent efter patientens tidbokningar hos aktuell vårdmottagning.

1-svar

När den aggregerande tjänsten fått svar från de tre anropen till den virtuella tjänsten, sammanställs svaren i en sammansatt lista av invånarens tidbokningar hos de tre mottagningarna. Listan lämnas sedan som svar till e-tjänsten, som presenterar den för användaren.

12

Användaren vill omboka den bokade tiden hos en av mottagningarna. Användaren väljer att visa detalj-vyn över bokningen. E-tjänsten använder då den virtuella tjänsten för tjänstekontraktet ”Hämta detaljer om bokning” för att fråga efter detaljer för aktuell bokning hos mottagningen i fråga (mottagningens HSA-id utgör verksamhetsadressen). Den här gången används inte en aggregerande tjänst, eftersom frågan riktas direkt mot en specifik verksamhet (mottagningen).

Den virtuella tjänsten för ”Hämta detaljer om bokning” tar hjälp av tjänsteadresseringskatalogen (13) för att översätta vårdmottagningens HSA-id till den tekniska adressen till mottagningens tjänsteproducent för ”Hämta detaljer om bokning”-tjänstekontrakt.

Med hjälp av den tekniska adressen kan den virtuella tjänsten fråga aktuell tjänsteproducent efter bokningsdetaljerna för aktuell bokning hos vårdmottagningen i fråga.

14

Tjänsteproducenten som realiserar tjänstekontraktet ”Hämta detaljer om bokning” för aktuell vårdmottagning (där bokningen som ska ombokas finns) returnerar svarsmeddelandet med bokningsdetaljerna till den virtuella tjänsten, som i sin tur lämnar svaret till e-tjänsten.

15

Användaren redigerar bokningsdetaljerna och anger en ny tid (i den verkliga processen föregås detta steg av att användaren genom e-tjänsten ber vårdenheten redovisa bokningsbara tider). E-tjänsten skickar därefter en begäran om ombokning hos aktuell vårdmottagning till den virtuella tjänsten för tjänstekontraktet ”Boka om” (vårdmottagning är verksamhetsadress).

Den virtuella tjänsten ”Boka om” tar hjälp av tjänsteadresseringskatalogen (16) för att översätta vårdmottagningens HSA-id till den tekniska adressen för mottagningens ”Boka om”-tjänsteproducent.

Med hjälp av den tekniska adressen kan den virtuella tjänsten vidareförmedla begäran om ombokning till aktuell tjänsteproducent för vårdmottagningen i fråga.

17

Vårdmottagningens tjänsteproducenten för tjänstekontraktet ”Boka om” genomför ombokningen och returnerar en kvittens som via den virtuella tjänsten når e-tjänsten.

Å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.


Komponent

Beskrivning

Tjänstekonsumenter

-        Spärrtjänst


Spärrtjänsten som tjänstekonsument möjliggör genom eget användargränssnitt eller genom tjänst (d.v.s. här i dubbla roller – producent mot anv. gränssnitt och som konsument mot övriga spärrtjänster) att registrera ny spärrinformation.

Spärrtjänsten behöver integrera funktionalitet och infrastruktur för att orkestrera uppdatering av de andra spärrtjänsterna. Det innefattar att begära information från tjänsteadresseringskatalogen om vilka spärrtjänster som finns och att för var och en av dem (parallellt) anropa virtuell tjänst för registrering av spärrinformation.

Spärrtjänsten behöver ha möjlighet till omsändning om en viss verksamhetsdress för stunden inte kan fullfölja tjänstekontraktet. Vid sidan av replikeringsflödet behöver också finnas tjänstekontrakt för initialladdning, så att man i användargränssnittet kan begära att hela innehållet ska skickas med riktat till en specifik instans (”informationsägare”). Detta följer typfallet för användandet av en tjänst i arkitekturen och beskrivs därför inte i figuren.

Virtuella tjänster

-        Registrera Spärrinformation

Anrop till den virtuella tjänsten är adresserade med mottagande spärrtjänsts identitet som informationsägare. Efter uppslag i tjänstekatalogen dirigeras meddelandet vidare till tjänsteproducentens tekniska adress.

Tjänsteproducenter

-        Lokal instans av spärrtjänst: I rollen som tjänsteproducent realiserar spärrtjänsten tjänstekontraktet som representerar replikeringsfunktionen: ”Registrera spärrtjänst”. De lokala instanserna är lokala installationer a av samma spärrtjänstprodukt som tjänstekonsumenten. Versionshanteringsstrategin i nationella tjänstekontrakt möjliggör en kontrollerad uppgraderingsprocess för bakåt- och framåt-kompatibilitet mellan olika versioner.

-        Vårdsystem med inbyggd spärrtjänst: För regioner med ett gemensamt vårdsystem för alla vårdenheter, finns möjligheten att låta vårdsystemet direkt realisera tjänstekontraktet och därmed utgöra spärrtjänst. Om vårdsystemet också erbjuder registrering av spärr, behöver det också ikläda sig rollen som tjänstekonsument enligt tidigare beskrivning.


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:

Komponent

Beskrivning

Ärendestyrning

Plattform för ärendestyrning syftar till att rationalisera hur ärendestyrda rutiner realiseras. När ärendestyrning är ett dominerande inslag i en e-tjänst eller ett verksamhetssystem (så som SVPL, Remisshantering och ärendehanteringssystem) används ett konfigurerbart ärendestyrningsverktyg som bas för realiseringen.

Det innebär att följande funktioner inte behöver specialutvecklas för varje verksamhetssystem eller e-tjänst med inslag av ärendestyrning:

-        Verktyg för att beskriva eller importera flödesbeskrivningar över ärenderutiner i BPMN (standard för att specificera processflöden)

-        Nya och förändrade ärenderutiner (på BPMN-format) kan ”driftsättas” av användare av verksamhetssystemet

-        Befintliga tjänster (aggregerande, virtuella, stödtjänster) kan kopplas in som informationskällor direkt av den som modellerar nya flöden (verktyg får stöd av tjänstekontrakten). På så sätt kan automatiska steg i flödet hanteras utan utvecklingsarbete behöver beställas.

-        Formulär för manuella steg i flödet kan skapas direkt i flödesverktyget, utan utvecklingsarbete behöver beställas.

-        Genom koppling till befintliga kataloger kan plattformens inbyggda möjligheter till avisering av väntande uppdrag kopplas till verksamhetens standardiserade kanaler för meddelandehantering.

Genom att använda dessa funktioner och att kombinera dem med riktade utvecklingsinsatser där kraven inte naturligt låter sig realiseras genom beskrivna funktioner, formas verksamhetssystem och e-tjänster som kan förändras och utvecklas utan behov av nya systemversioner.

Tjänsteväxel

En tjänsteväxel ansvarar för att översätta mellan den modell för teknisk kommunikation som regleras i denna referensarkitektur och modeller som tillämpas av externa parter, så som myndigheter. Ett exempel är en tjänsteväxel som växlar meddelanden mellan RIV Tekniska Anvisningar och myndigheternas SHS-arkitektur.

En tjänsteväxel är en systematisk realisering som genom konfigurationsändring i löpande drift kontinuerligt kan utökas med stöd för nya tjänstekontrakt – för såväl inkommande som utgående tjänsteanrop.

Tjänsteväxeln är en nationell tjänst som inte är synlig för tjänstekonsumenter hos huvudmännen. Virtuella tjänster i nationella domänen dirigerar meddelande från huvudmännens tjänsteproducenter till nationell tjänsteväxel (t.ex. för att skicka medicinska utlåtanden till försäkringskassan). Meddelanden från externa parter adresserade till huvudmännen dirigeras via nationell virtuell tjänst till huvudmännens tjänsteproducenter.

Tjänsteplattform

Tjänsteplattform är ett samlingsnamn för de komponenter som utgör plattform för tjänstebaserad integration över huvudmannagränser. Varje samverkansdomän i en federation (se senare avsnitt) kan ha en egen instans eller ingå i den överordnade domänens plattform. Den nationella samverkansdomänen har en instans som publicerar virtuella tjänster och aggregerande tjänster för alla nationella tjänstekontrakt (aggregerande tjänster och virtuella tjänster beskrivs i informationssystemvyn). All samverkan mellan samverkansdomäner och inom den nationella domänen sker via tjänster i den nationella tjänsteplattformen.

-        Aggregeringsplattform: Erbjuder infrastruktur för aggregerande tjänster. Dess primära syfte är systematisk realisering av aggregerande tjänster. Som en effekt kan generella aspekter av aggregering förändras i plattformen istället för att alla enskilda tjänster behöver förändras. Det ger gemensam hantering av gemensamma behov, så som felhantering, parallellitet, övervakning, loggning, uppslag i engagemangsindex m.m.

-        Virtualiseringsplattform: Erbjuder infrastruktur för virtuella tjänster. Dess primära syfte är systematisk realisering av virtuella tjänster. Som en effekt kan generella aspekter av virtualisering förändras i plattformen i stället för att alla enskilda tjänster behöver förändras. Det ger gemensam hantering av gemensamma behov, så som felhantering, åtkomstkontroll, övervakning, vägval. loggning, uppdatering av engagemangsindex, SLA-uppföljning mot tjänsteproducenter m.m.

Anslutningsarkitektur

Anslutningsarkitektur syftar på systematisk hantering av anslutning av huvudmännens verksamhetssystem som tjänsteproducenter i den nationella arkitekturen. Anslutningsarkitekturen kan bestå av en av huvudmannen tillämpad tjänsteplattform, uppbackad av kompletterande stöd för att integrera verksamhetssystem till nationella tjänstekontrakt och standarder för interoperabilitet (RIV TA). Det kan t.ex. gälla transformering mellan meddelandeformat och åtkomst till informationskällor via specifika protokoll.

Anslutningsarkitektur exemplifieras under avsnittet om referensarkitekturen i federation.

Stödtjänst

Stödtjänsterna bör i möjligaste mån vara utvecklade på ett sätt som ger vårdgivarna möjlighet att följa sina lokala strategier för driftsplattformar. Det gäller så väl val av applikationsplattform (t.ex. Java-plattformen) som val av databas (leverantör med stöd för prioriterade plattformar).

Flera av stödtjänsterna har krav på orkestrering för att utföra parallella tjänsteanrop i syfte att aggregera eller replikera information. Vid utveckling av stödtjänster där sådana krav finns, bör paketerade, beprövade komponenter som på ett systematiskt sätt kan hantera orkestrering, integreras i stödtjänstens arkitektur, snarare än att dessa egenskaper tillförs genom egenutvecklade ”mekanismer”.

-        Tjänsteadresseringskatalog

Tjänsteadresseringskatalogen är en komponent inom tjänsteplattformen som ligger till grund för logisk adressering  åtkomstkontroll baserad på logisk adressering som utförs i virtualiseringsplattformen.

Logisk adressering bygger på att tjänstekonsumenten i anropet anger identiteten för vilken verksamhet eller system som anropet avser istället för att ange den tekniska adressen (anslutningspunkten) adresseringsfunktionen i tjänsteplattformen översätter därefter, med hjälp av tjänsteadresseringskatalogen, den logiska adressen till den tekniska anslutningsadress som plattformen använder för att nå den logiska adressaten.

-        Engagemangsindextjänst

Engagemangsindex (EI) är en nationell tjänst som erbjuder ett mellanlager av indexinformation. Informationen hålls synkroniserad med informationskällor genom att dessa uppdaterar informationen i EI när den förändras i källan. Tjänsten lagrar den information som behövs för att veta var det finns detaljerad information att hämta. Det innebär i de flesta fall (utöver engagemangstyp) invånarens personnummer och

Logisk adress för informationsägarens verksamhet (t.ex. vårdgivare, vårdenhet, län, skola eller kommun) eller källsystemet som bär informationen. (vilket som anges beror på om det är verksamhet eller källsystem som används för logisk adressering.

Informationen som lagras i engagemangsindex används därefter av aggregerande tjänster för att sammanställa vilken information som finns för en viss individ/entitet. Det är alltså endast aggregerande tjänster som direkt får läsa informationen från engagemangsindex.

-        Meddelandetjänst

En informationskälla som följer nationellt fastställda tjänstekontrakt för att lämna och hämta meddelanden. producenter av dessa tjänstekontrakt (meddelandetjänster) utgör basen för säker meddelandehantering över huvudmannagränser och integreras i olika former av verksamhetsstöd och invånartjänster.



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

Revision

Viktiga förändringar

Revision A, 2007

Första utgåvan av T-boken

Revision B, 2011

-        Nya inledande kapitel (1-2). Arbetet har genomförts i samverkan mellan kommuner och landsting.

-        Omarbetad struktur, med inspiration från Togaf 9

-        Tekniska styrande principer har tillkommit. Tidigare fanns principer enbart från den gemensamma T-boken.

-        T-bokens sammanhang är beskrivet. Det har tydliggjorts att anvisningar och detaljerade regler för styrning ligger utanför T-boken.

-        Landstingsvård och Kommunal omsorg omfattas av T-boken (tidigare enbart landstingsvård)

-        RRR:er har ersatts med styrande principer och referensarkitektur.

-        T-boken täcker nu också e-tjänsteutveckling

-        Ett antal nya element och begrepp i arkitekturen har tillkommit. De viktigaste är Stödtjänst, Partneringång/utgång, aggregerande tjänst och engagemangsindex.

-        Delar av en anslutningsarkitektur för huvudmännen är belyst, liksom huvudmännens system som tjänstekonsumenter.

-        Detaljer kring tjänsteinteraktionstyper och tjänstekontrakt är utlyft till översiktsanvisningen för RIV Tekniska Anvisningar version 2.

-        Delar av arkitekturen som relaterar till lagtolkningar och regelverk för PDL har lyfts ut (detaljerade typanvändningsfall) och planeras få styrning genom kommande ställningstaganden från Arkitektur och regelverk.

-        Detaljerade typanvändningsfall har ersatts med typ-flödesmodeller i t-bokens verksamhetsvy.

-        En stödtjänst för nationellt patient-/individ-index har tillkommit, i syfte att stödja vårdgivar- och invånartjänsters behov av att skapa nationella översikter av individens engagemang.

Revision C, xxxx


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

TermBeskrivning

Arkitektur och regelverk

Arkitektur och regelverk är en arkitekturfunktion på nationell nivå under Inera.

Back office

Administration funktion som stöder verksamheten.

Brukare

Kan betyda individ som brukar omsorg

Förmågor

Så kallade "kapabiliteter", möjliggörare.

HCC Funktion

En certifikatstyp i SITHS-modellen som används för servers och applikationer för autentisering, kryptering och signering. Certifikaten för en viss Funktion ges ut parvis: ”HCC Funktion för autentisering och kryptering” och ” HCC Funktion för signering”.

Lingua franca

Ett internationellt hjälpspråk för kommunikation mellan människor med olika modersmål.

Local governance

Lokal styrning.

Ramverk

Ett ramverk som reglerar hur utveckling skall ske för att hålla en nationell standard ur tekniskt, säkerhetsmässigt och användbarhetsmässigt perspektiv. Det är en uppsättning regler, riktlinjer och rekommendationer med tillhörande anvisningar som skall vara styrande, vägledande och stödjande.

Rådgivningsstödet, RGS

Ska stödja telefonsjuksköterskan vid bedömning av vårdbehov hos den som ringer till 1177 Sjukvårdsrådgivningen. Rådgivningsstödet består av tre delar som samverkar med varandra - medicinskt innehåll, katalog och journal. 

Service Level Agreement, SLA

Överenskommelse mellan leverantör och kund bland annat gällande en tjänsts tillgänglighet.

SITHS

En nationell säkerhetslösning där vårdgivare kan identifiera sig och ge bevis för sin behörighet. SITHS-modellen bygger på att anställda i vård och omsorg har ett personligt elektroniskt ID-kort med ett elektroniskt PKI-certifikat.

 


Förkortningar

BHD

Barnhälsodata

DMZ

Demilitariserad zon

ITIL

IT Infrastructure Library

LOV

Lag Om Valfrihetssystem

NPÖ

Nationell patientöversikt

PDL

Patientdatalagen

PKI

Public Key Infrastructure

RGS

Rådgivningsstödet

RIV

Regelverk för Interoperabilitet inom Vård och omsorg

SKL

Sveriges kommuner och landsting

SLA

Service Level Agreement

SOL

Socialtjänstlagen

SVPL

Samordnad vårdplanering

TOGAF

The Open Group Architecture Framework


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


T-boken version A

Namn                                                                    Organisation, Län
Sara MeunierCarelink
Anders Börjesson Landstinget i Värmland
Johan Eltes Callista Enterprise
Kurt Helenelund Metamatrix
Lennart ErikssonStockholms Läns Landsting
Anders Norr Landstinget i Östergötland
Per Torlöf Region Skåne
Jan EdmanLandstinget i Västmanland
Tommy Rigo Västra Götalands regionen
Staffan Dahlin Västra Götalands regionen
Per-Arne Lundgren Region Skåne
Torbjörn Ivarsson Region Skåne
Qemajl Imeri Stockholms Läns Landsting
David Lindahl Landstinget i Kalmar
Gunnar Klein Objektfabriken/KI
Peter AlvinssonStyrgruppordförande Nationell Arkitektur –RRR
Sara MeunierProjektledare Nationell Arkitektur – RRR

T-boken version B

Blomberg, MagnusJönköping kommun, Jönköping  
Eltes, Johan     Konsult, Center för eHälsa i samverkan
Eriksson, Lennart        Konsult, Center för eHälsa i samverkan
Gabrielsson, Stig Luleå kommun, Norrbotten
Granström, Anders    Luleå kommun, Norrbotten
Jessica IsegranVästra Götalandsregionen
Kartman, Gunnar Karlstads kommun, Värmland
Lindahl, David  Landstinget Kalmar
Mannerhagen, Peter   Västerås stad, Västmanland
Meunier, Sara     Center för eHälsa i samverkan
Norr, Anders                              Landstinget i Östergötland

Nygren, Åke                                                      

Leksands kommun, Dalarna
Palmgren, Ulf    Stockholms läns landsting
Svensson, Peter         

Landstinget i Blekinge

Svensson, StefanStockholm Stad, Stockholm
Wedin, Roy     Sjuhärad kommunalförbund, Västra Götaland

T-boken version C

Björn Hedman Inera AB

Lars Erik Röjerås       

Inera AB
Ranjdar Fallyih   Inera AB
Rolf Rönnback      Inera AB

       

                 

                      







  • No labels