(T-boken), rev B - Center för eHälsa i samverkan

Center för eHälsa i samverkan 

Hornsgatan 20, 118 82 Stockholm 

Vxl: 08-452 70 00 

Mob: 070-549 2449 

Sara Meunier, CTO 

Sara.meunier@cehis.se 

www.cehis.se info@cehis.se 

28 februari 2011 

VIT(S)-bokens tekniska arkitektur 

(T-boken) 

Styrande principer, vägledande exempel och teknisk referensarkitektur 

för vård och omsorg 

Revision B, 2011-02-28 

Center för eHälsa i samverkan koordinerar landstingens och regionernas samarbete för att förverkliga den nationella IT-strategin för vård och omsorg. 

Centret ska skapa den långsiktighet som krävs för att utveckla och införa gemensamma eHälsostöd, infrastruktur och standarder som förbättrar 

informationstillgänglighet, kvalitet och patientsäkerhet. Center för eHälsa i samverkan styrs av representanter från landsting och regioner, Sveriges 

Kommuner och Landsting (SKL), kommunerna och de privata vårdgivarna.

Förord 


Den första utgåvan av VIT-bokens 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. 

En nyhet i denna nya utgåva av T-boken är att representanter från både landsting och kommuner varit delaktiga 

i arbetet! Den har tagits fram av Arkitekturledningens tekniska expertgrupp vid Center för eHälsa i samverkan, 

nedan kallat CeHis, tillsammans med kommunrepresentanter, utsedda i samråd med Catharina Mann, SKL. 

CeHis har bildats med uppgift att koordinera landstingens och regionernas eHälso-samarbete, se www.cehis.se. 

Den nya utgåvan är uppdaterad enligt behov av vidareutveckling som uppmärksammats genom praktisk 

tillämpning av utgåvan från 2007 samt den vision för referensarkitektur som togs fram 2009 inom ramen för 

projektet ”Teknisk infrastruktur”, en del av aktionsprogrammet för Kommunal IT-samverkan i vård och omsorg. 

T-boken kommer att vara ett av underlagen när Arkitekturledningen inom CeHis 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 CeHis på sikt även följer en teknisk arkitektur som passar kommuner. 

Följande personer har deltagit i framtagandet av denna utgåva av T-boken: 

Namn Organisation, Län 

Blomberg, Magnus Jö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 Isegran Vä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, Stefan Stockholm Stad, Stockholm 

Wedin, Roy Sjuhärad kommunalförbund, Västra Götaland 

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 Arkitekturledningen hos CeHis. Som nästa steg är det önskvärt att harmonisera begrepp 

och beskrivningar med pågående arbete inom e-delegationen. För kommuner är det även önskvärt med fortsatt 

arbete inom andra verksamhetsområden vilket kan resultera i framtida förändringar och tillägg i T-boken. 

2 (85)

Innehåll 


SAMMANFATTNING ............................................................................................................................................................. 4 

NYTTAN MED T-BOKEN ........................................................................................................................................................... 4 

NYTTAN MED SAMVERKAN ..................................................................................................................................................... 5 

1 INTRODUKTION TILL T-BOKEN .............................................................................................................................. 6 

1.1 INLEDNING ................................................................................................................................................................. 6 

1.2 SYFTET MED T-BOKEN ............................................................................................................................................... 7 

1.3 T-BOKENS VISION UTIFRÅN BEFINTLIGA BEHOV ......................................................................................................... 7 

1.4 MÅLGRUPPER............................................................................................................................................................10 

2 BEHOV OCH SCENARIER ..........................................................................................................................................11 

2.1 ARKITEKTURENS INTRESSENTER ...............................................................................................................................11 

2.2 SCENARIOBESKRIVNINGAR .......................................................................................................................................13 

3 T-BOKEN I ETT SAMMANHANG .............................................................................................................................17 

3.1 ARKITEKTURENS UTVECKLING OCH PRAKTISKA ANVÄNDNING .................................................................................17 

3.2 T-BOKENS INNEHÅLL OCH TILLÄMPNING ..................................................................................................................23 

4 STYRANDE PRINCIPER .............................................................................................................................................28 

4.1 IT1: IT-PRINCIPERNA ÄR STYRANDE FÖR DEN TEKNISKA ARKITEKTUREN .................................................................28 

4.2 IT2: INFORMATIONSSÄKERHET .................................................................................................................................29 

4.3 IT3: NATIONELL FUNKTIONELL SKALBARHET ...........................................................................................................30 

4.4 IT4: LÖS KOPPLING ...................................................................................................................................................30 

4.5 IT5: LOKALT DRIVEN E-TJÄNSTEFÖRSÖRJNING .........................................................................................................32 

4.6 IT6: SAMVERKAN I FEDERATION ...............................................................................................................................33 

5 REFERENSARKITEKTUR ..........................................................................................................................................35 

5.1 VERKSAMHETSVY .....................................................................................................................................................35 

5.2 INFORMATIONSSYSTEMVY ........................................................................................................................................46 

5.3 TEKNISK VY ..............................................................................................................................................................68 

T-BOKEN ÖVER TIDEN .......................................................................................................................................................81 

BILAGA – ORDLISTA OCH FÖRKORTNINGAR............................................................................................................83 

ORDLISTA ..............................................................................................................................................................................83 

FÖRKORTNINGAR ...................................................................................................................................................................85 

3 (85)

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. 

VIT-bokens tekniska arkitektur, 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 och möjliggör utbyte av information för att uppnå önskade effekter av den nationella 

strategin för eHälsa 1 . 

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

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 Arkitekturledningen hos CeHis 3 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. 

1 Nationell eHälsa – strategin för tillgänglig och säker information inom vård och omsorg, 

http://www.sweden.gov.se/content/1/c6/14/84/29/b38c1b84.pdf 

3 CeHis har bildats med uppgift att koordinera landstingens och regionernas eHälso-samarbete, se www.cehis.se. 

4 (85)

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. 

5 (85)

1 Introduktion till T-boken 

1.1 Inledning 


Under 2010 har en målbild för eHälsa 4 arbetats fram ur ett verksamhetsperspektiv, med God vård 5 i fokus. 

Målbilden har tagits fram av Arkitekturledningen hos CeHis 6 . 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 VITboken. 

VIT-boken utgör ett ramverk utifrån perspektiven; Verksamhet, 

Informationsstruktur och Teknik. Säkerhet ingår som en integrerad del i 

respektive perspektiv. 

VIT-boken förvaltas av Arkitekturledningen under CeHis. I VIT-boken 

ingår bland annat en teknisk arkitektur, den så kallade T-boken, 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. T-boken har därför tagits fram av 

representanter från både landsting och kommuner. 

4 Målbild för arkitekturen inom eHälsa i samverkan - och vägen till målet. Skriften finns publicerad på www.cehis.se. 

5 God Vård har beskrivits av Socialstyrelsen i anslutning till föreskriften om ledningssystem för kvalitet och patientsäkerhet, 

Den vänder sig till verksamheter som omfattas av hälso- och sjukvårdslagen och tandvårdslagen, vilket påverkar både 

kommuner och landsting. http://www.socialstyrelsen.se/Lists/Artikelkatalog/Attachments/9406/2006-101-2_20061012.pdf 

6 CeHis har bildats med uppgift att koordinera landstingens och regionernas eHälso-samarbete. CeHis styrs av representanter 

från landsting och regioner, SKL, kommunerna och de privata vårdgivarna, se www.cehis.se. 

6 (85)

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 CeHis. 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 Apotekens Service AB) 

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 

7 (85)


Referensarkitekturens omfattning utifrån olika intressentperspektiv och de behov den ska möta illustreras av 

figuren nedan, ur en enskild organisations perspektiv. Referensarkitekturen beskriver inte den interna IT-miljön 

(rutan i mitten) utan beskriver snarare förutsättningar för anslutning till den nationellt samordnade arkitekturen 

(rutan till höger och rutan till vänster). 

Kommunikation 

med andra 

landsting, 

kommuner och 

utförare 

Ingångar för invånare, 

företagare och utförare 

Kundvård och gemensamma vyer över kundengagemang, 

ärenden, diarium, kunder, … 

Verksamhetssystem per förvaltning eller bolag 

Integration och standardiserade meddelanden 

Gemensamma register 

Gemensamma 

stödsystem 

Ingång för medarbetare 

Figur 1 – Konceptuell arkitektur för e-förvaltning ur den enskilda organisationens perspektiv 

8 (85) 

Kommunikation 

med statliga 

myndigheter


På motsvarande sätt kan en bild ritas upp utifrån det nationella perspektivet, där T-bokens uppdrag är att 

beskriva både den nationella spelplanen (rutan i mitten) med gemensamma register, gemensamma 

stödtjänster, standard för integration etc. samt beskriva hur kommunikationen med andra parter skall 

samordnas (rutan till höger och rutan till vänster), se bild nedan. 

Samordna 

kommunikation 

med landsting, 

kommuner och 

utförare 

Ingångar för Invånare, 

företagare och utförare 

Gemensamma vyer och processtöd för invånare, 

myndigheter, medarbetare, utförare 

Integration och standardiserade meddelanden 

Gemensamma register 

Nationella 

spelplanen 

Gemensamma 

stödtjänster 

Ingång för medarbetare 

Figur 2 – Konceptuell arkitektur för e-förvaltning ur det nationella perspektivet 

Det finns andra infrastrukturella frågeställningar såsom nättopologier och autentiseringsmodeller som har en 

bredare tillämpning än en arkitektur för samverkan. Dessa beslutas, beskrivs och drivs av andra initiativ än det 

för T-boken. Befintlig infrastruktur betraktas som en förutsättning eller ett ingångsvärde för T-boken. När 

förutsättningarna förändras kan T-boken därmed också behöva förändras. 

9 (85) 

Samordna 

kommunikation 

med statliga 

myndigheter

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, såsom 

projekten ”Vården på Webben” och ”Informationsväg Försäkringskassan” (elektroniska läkarintyg). 

Granskningen av de nationella projekten och förvaltningsobjekten görs av Arkitekturledningen under CeHis. 

Eftersom kommunrepresentanter har varit med i framtagandet av denna utgåva av T-boken ökar möjligheten 

att de nationella projekten och förvaltningsobjekten inom ramen för CeHis på sikt följer en teknisk arkitektur 

som också passar kommunerna. 

Ä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 ITsystemen 

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. 

10 (85)

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. Oavsett om samverkan sker mellan enskilda vård- och 

omsorgsgivare eller vård- och omsorgsgivare i en regional gemenskap gäller samma regelverk. 

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. 

Samverkan kring en gemensam arkitektur, både ur ett verksamhetsperspektiv, informationsstrukturperspektiv 

och tekniskt perspektiv, leder alltså till interoperabilitet, det vill säga förmågan hos olika system att fungera 

tillsammans och kunna kommunicera med varandra, som gör det möjligt att lättare utbyta information, 

integrera processer och använda delade tjänster genom användandet av ett gemensamt regelverk. 

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 skriften ”Målbild för arkitekturen inom 

eHälsa I samverkan – och vägen till målet” 7 som har tagits fram av CeHis 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. Behoven har uttryckts av flera 

7 Målbild för arkitekturen inom eHälsa i samverkan - och vägen till målet. Skriften finns publicerad på www.cehis.se 

11 (85)


olika intressenter, bland annat genom ett förfrågningsunderlag som ingick i förstudien för ”Ramverk för 

samordnas tjänsteutveckling”, hos Inera AB. 

Intressent Behov Har uttryckts av 

Projekt och 

förvaltningar av 

regionala och 

nationella 

e-tjänster för 

invånare och 

medarbetare 

Förvaltning av 

nationella 

standarder 

Vård- och 

omsorgsgivares ITförvaltningar 

Samverkansorganisationer 

såsom Sambruk 

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 PDL och SOL är 

beskriven. 

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

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 CeHis, 

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 ITstöd 

är integrerat med omgivningen. 

Att säkerhetsarkitekturen för följsamhet mot PDL och 

SOL är etablerad såväl lokalt som regionalt. 

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. 

Flera nationella projekt och 

förvaltningsobjekt 

… 

12 (85) 

Arkitekturledningens förvaltning av RIV 

Tekniska Anvisningar, 

Andra nationella förvaltningsobjekt 

… 

IT-arkitekter hos huvudmän 

Claes-Olof Olsson verkställande 

tjänsteman och 

Janne Dicander IT-chef Jönköpings 

kommun samt projektledare Öppen 

Teknisk Plattform

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 

13 (85) 

Samverkande hälsoärenden innebär bland annat 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 specifikt och avgränsat vårdbehov. Genom en gemensam informationsstruktur och 

gemensam teknisk infrastruktur och säkerhetslösningar kan bland annat 

- hälsoärenden hanteras oberoende av hur vård och omsorg är organiserad 

- informationen hållas samman i vårdprocesser 

- vårdplan och information 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årdgivargrä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/omsorgstagaren 

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 

14 (85) 

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. Det är dock viktigt att ta hänsyn till de olika lagrum som 

för närvarande gäller för samordnad vårdplanering respektive sammanhållen journalföring. Här finns 

olikheter i vad som idag är möjligt att göra. 

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 

i stort. 

- En effektiv och systematiserad integration mot IT-stöd inom vård och omsorg kan hantera säkerhet 

och rutiner som krävs i och med att apoteken gått från en organisation till många.

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

e-tjänster för invånare 


15 (85) 

Vård och omsorg eftersträvar ökad service till invånaren genom att erbjuda tjänster på webben. Det 

kan gälla tidbokning, kundval, valfrihetssystem, 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, valfrihetssystem, vårdval och liknande invånartjänster skapar behov av e-tjänster för ”backoffice”-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 


16 (85) 

Runtom i landet finns det ett åttiotal 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. Tidigare hette denna strategi ”nationell IT-strategi för vård och omsorg” men bytte 

namn under 2010 till Nationell eHälsa för att lyfta fram hur framtidens vård och omsorg som helhet ska fungera 

och förbättras med hjälp av e-tjänster. T-boken hanterar de mål som sätts upp i denna strategi. 

Arkitekturens vägval måste även vara harmoniserade med de lagrum och författningar som rör vård och 

omsorg. För att säkerställa detta behövs det gemensamma tolkningar av lagrummen som sedan kan översättas 

till tekniska och säkerhetsmässiga förutsättningar. Inom ramen för Socialstyrelsens projekt Nationell 

Informationsstruktur, har en vägledning tagits fram, som belyser viktiga områden och principer för 

informationssäkerhet 8 . Rapporten vänder sig till dem som behöver få en bredare inblick i 

informationssäkerhetsområdet och vad som måste beaktas i samband med informationshantering inom vård 

och omsorg. Där ingår även en förteckning över ett antal lagar och författningar som reglerar området vård och 

omsorg, samt en analys av krav på informationshantering som dessa lagar för med sig. 

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 9 

ADM. TOGAF ä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 CeHis egen arkitekturfunktion, benämnd Arkitekturledningen, 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. 

8 http://www.socialstyrelsen.se/Lists/Artikelkatalog/Attachments/17988/2010-4-6.pdf 

9 The Open Group Architecture Framework 

17 (85)


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. 

H: Förvaltning av 

referensarkitekturen 

G: Stöd och styrning till 

pågående projekt för 

följsamhet mot 

referensarkitektur m.h.a. 

anvisningar, 

förvaltningar, styrande 

principer etc 

F: Migrationsplannering 

Gemensamma 

faser 

G. 

Styrning av 

realisering 

H. 

Förändringshantering 

F. 

Migrationsplanering 

Sektors- eller 

organisations-specifika 

faser 

Preliminär 

A. 

Arkitekturvision 

Kravhantering 

E. 

Möjligheter 

och 

lösningar 

IT-strategiska prioriteringar, 

Regelverk V- I - S, Målbild för 

Cehis, Lagar och förordningar 

A: Styrande principer för teknisk arkitektur, 

scenarion, intressentbeskrivningar 

B. 

Verksamhetsarkitektur 

D 

Teknikarkitektur 

C. 

Informationssystemarkitektur 

E: Strategier för 

realisering av teknisk 

arkitektur 

B: Flödesmodeller för 

informationsåtkomst med 

exempel från scenarion 

C: Referensarkitektur och 

dess tillämpning i olika 

scenarion 

D: Beskrivning på logisk nivå av 

grundtjänster och infrastrukturtjänster, 

samt tekniska anvisningar 

Figur 3 – 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 Arkitekturledningen hos CeHis detta forum. 

18 (85)

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 10 , 

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 11 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äntningar. Dessa behov omvandlas till funktionella respektive icke-funktionella krav. 

Utöver konkreta lösningar 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 12 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 13 . 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 14 

Tjänsteutformning 15 

10 IT Service Management, ITSM 

11 Enterprise Architecture 

12 Produceras eventuellt i samverkan med konfigurationshanteringen 

13 IT Infrastructure Library 

14 Service Strategy (ITIL v3) 

15 Service Design (ITIL v3) 

19 (85)

Tjänsteöverlämning 16 

Tjänstedrift 17 

Kontinuerlig tjänsteförbättring 18 . 


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 organisatoriska 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änstehantering 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). 

16 Service Transition (ITIL v3) 

17 Service Operation (ITIL v3) 

18 Continual Service Improvement (ITIL v3) 

20 (85)

Verksamhetens 

behov 

1 

2 

Tjänstestrategi 

styrning 

3 

”blueprints” 

granskning 

Tjänsteutformning 

granskning 

4 

Kontinuerlig tjänsteförbättring 

Tjänsters livscykel 

Tjänsteöverlämning 


Tjänsteförvaltning 

Figur 4 – Samverkansmodell för processer 

1. Verksamhetens företrädare uttrycker de behov som finns. 

5 

Drift Support 

6 

Tjänstedrift 

21 (85) 

Arkitekturprocess baserad 

på TOGAF 

Service Management baserad 

på ITIL v3 

Förvaltningsprocess 

Avslutad tjänst 

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. Tjänsteutformningsprocessen 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ösningsarkitekturer 

för vidare bearbetning i de ingående underprocesserna. Ett uppdrag kan behöva itereras, 

det vill säga växla, mellan arkitekturprocessen och Tjänsteutformningsprocessen 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ösningsarkitekturer. 

7


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ändringskraven som kommer från Tjänsteutformningsprocessen resulterar i lösningar som kan 

användas i den operativa miljön. I den mån arkitekturella beskrivningar finns på plats och är användbara 

kan det hanterade uppdraget 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 19 ansvarar 

för instanseringen. Uppdatering sker i huvudsak av processen för Release och driftsättningshantering 20 . 

22 (85) 

Konfigurationsdatabasens struktur och instansering hjälper till att identifiera relationer mellan olika 

konfigurationsenheter vilket är ovärderligt i supportsituationer, förändringshanteringens analys av en 

föreslagen ändrings inverkan på infrastruktur och/eller processer samt som underlag för kostnadsberä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änstedriftprocessen ä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änsteförvaltningens 

aktiviteter utförs givetvis på redan realiserade objekt. Modellen visar Förvaltningsprocessens 

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 huvudprocesserna. Processen bör integreras i verksamhetens kultur för att där bli en naturlig del 

i vardagen. 

19 Service Asset and Configuration Management (ITIL v3) 

20 Release and Deployment Management (ITIL v3)

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 

Arkitekturledningen hos CeHis 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 CeHis 

arkitekturledning, speciellt de som rör standarder för elektronisk samverkan, och är nödvändiga att tillämpas av 

övriga arkitekturfunktioner vid 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. 

Figuren nedan ger en principiell bild av vilka beståndsdelar som ingår i T-boken, vad som ingår i den nationella 

referensarkitekturen och hur den relaterar till andra organisationers uppgifter. De olika delarna i figuren 

beskrivs var för sig i tabellen som följer. Bilden är ett exempel på fördelning, men uppgifterna kan ligga under 

annat ansvar än vad som visas i figuren också. 

På den nationella nivån återfinns bland annat anvisningar, vägledande exempel samt beskrivning av process för 

granskning och stöd av projekt och förvaltningsobjekt hos CeHis 21 . 

21 www.cehis.se 

23 (85)

Element Beskrivning 


Figur 5 – T-bokens omfattning och tillämpning 

Programkontor Enhet som ansvarar för projektportföljen och ansvarsfördelning mellan 

förvaltningsobjekt. Har ett samlat grepp om samtliga projekt och 

förvaltningsobjekt inklusive status, ekonomi, risker med mer. Förvaltar 

projektmodeller och ser till att beställningar av nya projekt görs på ett 

korrekt sätt. 

Har vanligen stöd av arkitekturfunktionens experter inom säkerhet, 

teknisk, verksamhets- och informationssystemarkitektur som kan bidra 

med att identifiera återkommande integrationsbehov (mönster) som 

behöver få en rationell, systematiserad realiseringsmodell. Det kan leda 

till nya krav på stödtjänster, standarder och tekniska plattformar som 

behöver hanteras inom ramen för programkontorets beställningar. 

Som exempel, är Arkitekturledningen stöd till programkontoret inom 

CeHis kansli. 

24 (85)

- Process- och 

informationsmodel 

ler 


Modeller över verksamhet och information, som styr utveckling och 

förändring av verksamhetsstödjande IT-tjänster. Dessa modeller följer 

regelverk för Verksamhetsarkitektur och Informationsarkitektur. 

- Tjänstekontrakt Systemoberoende tekniska kontrakt som reglerar samspelet mellan 

olika komponenter i systemlandskapet, med utgångspunkt i process- 

och informationsmodeller. Dessa är upprättade enligt anvisningar för 

teknisk interoperabilitet i den tekniska arkitekturen vilket innebär att 

tjänstekontraktet säkerställer teknisk interoperabilitet genom att följa 

anvisning vid upprättandet. Ett enskilt tjänstekontrakt består av ett 

innehåll (nyttolast), kuvert och regler vilket är grunden för semantisk 

interoperabilitet. Semantisk interoperabilitet i sin tur förutsätter en 

gemensam referensmodell för informationsstruktur. 

- Infrastrukturmodeller 

Modeller över det infrastrukturella landskapet. Här beskrivs bland 

annat de komponenter som realiserar logiska infrastrukturkomponenter. 

Modellerna säger vilka servrar som finns, hur koppling 

mellan internet och Sjunet ska se ut, var en specifik komponent finns i 

drift, vilka produkter som exempelvis en tjänsteplattform är baserad 

på, vilken databas som ska användas i ett visst syfte etc. 

Det som säkras genom dessa modeller är att man kan svara på frågor 

som "vem påverkas om katalogen stannar?", "vi får ett fel i Mina 

vårdkontakter, vilka olika beroenden finns det och var ska vi börja 

felsökningen?", "Jag är ny här och ska integrera med nationella 

infrastrukturen. Hur ser landskapet ut? Vad kommer jag åt från 

internet?" 

Projekt och förvaltningar Projekten förändrar systemlandskapets sammansättning. De får 

förutsättningar (information, process och tjänstekontrakt) från 

programkontoret och tekniskt regelverk från den tekniska 

arkitekturfunktionen. Projekten beskriver lösningens tekniska 

arkitektur i granskningssyfte på ett sätt som föreskrivits av 

arkitekturfunktionen. Det kan t.ex. vara i form av en s.k. SAD (Software 

Architecture Document) 22 . 

22 SAD definieras av OMG som en del av UP (Unified Process) och betyder Software Architecture Document 

25 (85)

Arkitekturfunktion för 

teknisk arkitektur 

- Process för 

granskning och 

stöd 


Utarbetar och tillämpar regelverk för arkitektur. Den tekniska 

expertgruppen inom CeHis tillämpar TOGAF för utveckling och 

förvaltning av arkitekturen 

Inom CeHis tillämpas en granskningsprocess som har tagits fram för att 

harmonisera med övriga processer inom CeHis. På samma sätt behöver 

varje tillämpande arkitekturfunktion besluta om den process där 

regelverket ska tillämpas. 

- Behov, IT-Principer Behovsbild i form av arkitekturens intressenter och 

scenariobeskrivningar utifrån verksamhetsperspektiv beskrivs i detta 

dokument. 

- Referensarkitektur 

- Redovisning av intressenter och deras behov (på scenarionivå), 

lagrum m.m. 

- Styrande principer för den tekniska arkitekturen vilka utgör det 

övergripande regelverket 

Beskrivs delvis i detta dokument. Utgör det detaljerade regelverket för 

arkitektur. 

- Arkitektur med regler beskriver mönster för arkitektur som ska 

tillämpas av projekt och förvaltningar. Arkitekturen beskriver 

också teknisk infrastruktur på logisk nivå, som bidrar till 

systematisk realisering av återkommande mönster. Likaså 

beskrivs grundtjänster som utgör förutsättningar för 

arkitekturen. 

- Anvisningar beskriver detaljerat hur tekniska komponenter ska 

tillämpas, vilka standarder som gäller (samt ev. 

organisationsspecifika profiler av standarder). 

- Vägledande exempel underlättar för projekten genom att visa 

praktiskt hur referensarkitekturen kan tillämpas för befintliga 

och planerade lösningar. Det kan ske genom 

referensapplikationer eller genom att peka på goda exempel 

bland förvaltningsobjekten. Här kan också finnas verktyg som 

automatiserar vissa återkommande moment i projektarbetet. 

- Förvaltningsprocessen beskriver organisation och process för 

regelverkets förvaltning. Större revisioner görs typiskt i 

projektform som en del i TOGAF, medan förvaltningsprocessen 

26 (85)

- Tekniska 

komponenter 

23 Definition hos OASIS SOA Reference Model. 


beskriver hur löpande ändringshantering sker. 

- Referensmodeller 23 förklarar arkitekturens ingående delar och 

hur de kan sättas samman till lösningar. Referensmodeller kan 

sägas vara arkitekturens ”lingua franca”, det vill säga det 

gemensamma språket. 

Beskriver organisationens fastställda och livscykelhanterade 

(standardiserade) komponenter i arkitekturen. Detta gränsar mot 

konfigurationsstyrning (t.ex. ITIL). TOGAFs TRM (Technology Reference 

Model) kan användas som indelningsgrund för att strukturera 

komponentförteckningen. 

- Komponentkatalog. Katalog över vilka mjukvaror som används 

till vad och vilken status de har enligt livscykelmodellen (t.ex. 

pilot, standard, utfasning, avförd) 

- Livscykelmodell för komponenter. Beskriver livscykelmodell, 

process och organisation för beslut om nya komponenter och 

hur deras status förändras enligt livscykelmodellen. 

27 (85)

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 ITinfrastruktur, 

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 Arkitekturledningen, med berörda förvaltningar. 

28 (85)

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. 


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. 

29 (85)


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. 


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. 

30 (85)


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. 


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: 

o Nationellt bryggar informationen (semantisk översättning) eller 

o Nationellt införlivar externt förvaltat tjänstekontrakt som standard. 

31 (85) 

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

förvaltning av bryggningstjänster.


32 (85) 

För att införliva ett externt förvaltat tjänstekontrakt förutsätts det en transparent, robust och uthållig 

tjänstekontraktsförvaltning hos den externa parten. 

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 Mina Vårdkontakter, 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. 


När utveckling av källkod är en del av en tjänsteleverans skall följande beaktas: 

o Alla leveranser tillgängliggörs under öppen källkodslicens. Valet av licensformer samordnas 

nationellt genom rekommendationer. 

o Utvecklingen bedrivs från start i en allmänt tillgänglig (över öppna nätverk) projektinfrastruktur 

där förvaltningsorganisation kan förändras över tiden inom ramen för en kontinuerligt tillgänglig 

projektinfrastruktur (analogi: ”Projektplatsen för e-tjänsteutveckling”).


33 (85) 

o Full insyn och åtkomst till källkod, versionshantering, ärendehantering, stödforum och andra 

element för utvecklare i en projektinfrastruktur under projektets och förvaltningens hela 

livscykel. 

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

o 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 etjä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) etjänstekanaler. 

4.6 IT6: Samverkan i federation 

Samverkan över organisationsgränser sker genom federation, såsom exempelvis identitetsfederering. 

4.6.1. Motiv 

Motivet är att uppnå nät-neutralitet, autentiseringsneutralitet och federationsneutralitet. Syftet med principen 

för samverkan i federation är att underlätta gränsöverskridande samverkan. 


Att gemensamma gränssnitt i alla federativa utbyten finns framtagna och beskrivna, vilket möjliggör 

kostnadseffektiva och leverantörsneutrala lösningar. 

Det behövs organ och processer 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 är säkra.


Att Ingående parter i federationen är överens om ett antal gemensamma ståndpunkter: 

o att stark autentisering likställs med 2-faktors autentisering 

34 (85) 

o att vid samverkan acceptera följande metoder för stark autentisering; eID, PKI med lagring av 

nyckelpar på SmartCard eller motsvarande och metoder baserade på engångslösenord, antingen 

genererade i en fysisk enhet eller säkert distribuerad till fysisk enhet 

o att tillämpa en gemensam certifikat- och utfärdarpolicy, likvärdig med SITHS, som ett 

minimikrav för egen eller annans PKI 

o att sträva mot en autentiseringslösning, framför flera olika, för att realisera stark autentisering i 

den egna organisationen och i federation 

o att enbart acceptera SAMLv2, eller senare version, vid identitetsfederering samt tydliggöra att 

det i förekommande fall är det enda sättet att logga in och säkerställa det inte finns någon 

bakväg in 

o att tillämpa ett gemensamt ramverk för att ingå i en federation 

o att tillämpa en gemensam katalogpolicy, med utgångspunkt från HSA policy, som ett minimikrav 

för egna kataloger 

o att stäva mot att all gränsöverskridande kommunikation skall vara möjlig både över Sjunet och 

över Internet. Det är den egna organisationen som beslutar vilken tillgänglighet som är tillräcklig 

för anslutningen 

o att sträva efter att möjliggöra kontroll av trafik till och från den egna infrastrukturen i en eller få 

kontrollpunkter 

o Att utgå från att kommunikation över Internet och Sjunet har ett likvärdigt skyddsbehov

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. 

35 (85)


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 

Arkitekturen beskriver svaret på dessa frågor genom att peka på behovet av följande nationella (eller nationellt 

samordnade) basinformationstjänster: 

Sortiments- och utbudskatalog (denna tjänst har även affärs- och processmässiga drivkrafter som ligger 

utanför den tekniska arkitekturens uppdrag att beskriva). Tjänsten svarar på frågan ”Vilken verksamhet 

har jag behov av att utbyta information med?” (t.ex. ”Vilka tandkliniker kan jag välja att boka tid hos?”) 

Engagemangsindex. Tjänsten svarar på frågan ”Vilka informationsägare behöver mitt IT-stöd kontakta 

för att sammanställa en översikt kring ett visst informationsbehov?” (t.ex. ”i vilka vårdenheters 

tidböcker har jag bokningar?”) 

Tjänsteadresseringskatalog. Tjänsten svarar på frågan ”Vilken informationskälla ska mitt IT-stöd utbyta 

information med, för att nå en viss informationsägare?” (t.ex. ”Vad är den tekniska adressen till det 

system som hanterar min tandkliniks tidbok?”) 

5.1.1. Informationsägarskap och verksamhetsbaserad adressering 

Informationsägaren är den som ansvarar 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. I 

dag är till exempel trenden att samla hanteringen av alla vårdenheters vårddokumentation i en gemensam 

informationskälla stark. 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. 

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 kapslas in i en 

36 (85)


tjänsteadresseringskatalog. Referensarkitekturen inför därför begreppet verksamhetsbaserad adressering, där 

verksamhet avser den informationsägande verksamheten. 

Sättet att uttrycka en verksamhets adress varierar per informationstyp/informationsområde. Följande tabell 

belyser frågan om informationsägarskap i ljuset av några representativa scenarier. 

Scenario Beskrivning Ägarskap 

Kundval / 

Valfrihetssystem 

Vissa kommuner har infört fritt valsystem 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. Vissa 

kommuner har infört valfrihet inom vård och 

omsorg i enlighet med LOU och LOV. 

Valfrihetssystemet administreras av kommunerna. 

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. 

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. 

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. 

Kommun 

Landsting 

Vårdenhet/mottagning 

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å 

Rapportering till Insamling av vårddokumentation till Källan (d.v.s. 

37 (85)

kvalitetsregister kvalitetsregistren startar i journalsystemen. För 

varje kvalitetsregister finns en definierad 

insamlingsprocess i vårdsystemen som 

representeras av inmatningsformulär. När 

formuläret för ett uppföljningsmål fyllts i, skickas 

ett meddelande med vårddokumentation till 

aktuellt kvalitetsregister. 

Sammanhållen 

journal 

Samordnad 

vårdplanering 

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. 

Vid samordnad 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 SVPLprocesstö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. Det är viktigt att se till 

lagrummet för samordnad vårdplanering. Här 

finns olikheter jämfört med sammanhållen journal 


uppgiftslämnaren) äger 

informationen, men då 

det här (per definition 

enl. PDL, men tolkningen 

diskuteras) handlar om 

att lämna information, 

blir det snarare relevant 

att resonera om ägaren 

av analysuppdraget, som 

på abstrakt nivå (för 

detta syfte) bäst beskrivs 

som kvalitetsregistret i 

sig 

Vårdenhet, enligt 

definition i PDL 

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) 

38 (85)

för vad som är möjligt att göra. 


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 

1. Informationsägare 

där individen har 

engagemang av aktuell 

typ 

Sortiments- och utbudskatalog 

Engagemangsindex 

Tjänsteadresseringskatalog 

Lokala informationskällor 

2. Teknisk adress till 

informationskälla (logisk 

adressat) 

Översikt Detaljer Redigering 

3. Översiktinfo för 

ett engagemang 

4. Möjliga nya 

engagemang av 

aktuell typ 

5. Som 2. 

6. Detaljer om ett 

bef. engagemang 

7. Uppdatering av 

bef. el. skapande av 

nytt engagemang 

Figur 6 – 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. 

- 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 

Engagemangsindex) 


(Stödtjänst 

Tjänsteadresseringskata 

log) 

39 (85)

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

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

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

- Steg 6 Med den tekniska adressen från steg 5, kan detaljer 

kring ett engagemang efterfrågas från aktuell 

tjänsteproducent. 

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. 

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



(aktuellt 

Verksamhetssystem) 


(Stödtjänst Sortiments- 

och utbudskatalog) 


(Stödtjänst 


log) 


(aktuellt 



(Stödtjänst 


log) 


(aktuellt 


40 (85)

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: 

Patientöversikt 

Tidbokning 

Vårdval 

Min Hälsoöversikt Journalanteckning N/A 

Min nationella Kalender Tider hos mottagning Ombokning 

Mina vårdval Mitt Vårdval i ett Län Ändrat vårdval 

Del av SVPL Mina ärenden / meddelanden Ett enskilt ärende Besvara / agera 

Figur 7 – 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: 

1. Vårdenheter (hsaid) 

där individ finns i 

tidböcker 




Lokala informationskällor (tidbok) 




respektive vårdenhets 

tidbok 

3. Individens 

tidbokningar hos 

vårdenhet 

(5. Som 2) 

(4. Vårdenheter – 

hsaid - med önskad 

vård i sitt utbud) 

6. Detaljer om bef. bokning 

och om bokningsbara tider 

hos vårdenhet 

7. 

Ombokningsuppdrag 

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

41 (85)

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. 



tidböcker 




Lokala informationskällor (tidbok) 




respektive vårdenhets 

tidbok 

3. Individens 


vårdenhet 

(5. Som 2) 







…… …… 

7. 


till vårdenhet 

VEH1 VEH2 VEH3 VEH4 VEH5 VEH6 VEH7 VEHN 

Organisation A Organisation B Organisation C 

42 (85) 

Informationsägande 

vårdenhet 

Figur 9 – 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. 



tidböcker 




Informationskälla (tidbok) 


Invånarens nationella kalender Tider hos mottagning Ombokning 


respektive tidbok 

3. Individens 


vårdenhet 




…… …… 

VEH1 – 

VEH6 

VEH7 – 

VEH8 

(5. Som 2) 




VEH9 

Organisation A och B Organisation C 

VEH10 

7. 


till vårdenhet 

Informationens 

fördelning över 

Informationskällor 

Figur 10 – Tjänsteadresseringskatalogens användning i tidbokningsscenariot 

43 (85)


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: 


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

1. Organisationer som 

ingår i t.ex. SVPL 



Mina ärenden / meddelanden Ett enskilt ärende Besvara / agera 


respektive organisations 

meddelandetjänst 

Lokala informationskällor (meddelande/ärendesystem) 


3. Lista av ärenden 

/ meddelanden 

(4.Vid nytt 

meddelande/ärend 

e: Organisationsid) 

(5. Som 2) 

6. Meddelandeinnehåll / 

ärendedetaljer 7. Svarsmeddelande 

/ ny ärendestatus 

Figur 11 – 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. 

44 (85)



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


Mina ärenden / meddelanden Ett enskilt ärende Fråga/ svara 

Informationskällor (meddelande/ärendesystem) 



respektive organisations 

meddelandetjänst 

2. Lista av ärenden 

/ meddelanden 

(3. Som 2) 

4. Meddelandeinnehåll / 

ärendedetaljer 5. Svars- eller 

frågemeddelande 

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

45 (85)

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: 

Beståndsdelarna beskrivs i nedanstående tabell: 

Beståndsdelar Beskrivning 

Figur 13 – Översikt, informationssystemvy 

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

- Medarbetare 

- SHS, 

Epsos… 

Medarbetare inom professionen, hos kommuner, landsting och privata aktörer. 

De kan även agera ombud för en invånare. 

Kanaler för externa systemaktörer som lyder under andra regelverk än denna 

referensarkitektur. 

46 (85)


- 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änstekonsumenter 

- Verksam 

hetssystem 

- Partneringång 

Informationssystem där aktörens agerande leder till automatiskt 

informationsutbyte med andra system (tjänsteproducenter). 

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 erecept 

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 

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 Mina Vårdkontakter med online-koppling till 

47 (85)

Aggregerande 

tjänster 


bakomliggande verksamhetssystem, så som Tidbokning och Listning 

(vårdval/kundval /fritt valfrihetssystem). 

- 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 

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 individens tidbokningar” sammanställer tidbokningar 

från alla vårdmottagningar (informationsägare) där en patient har en 

tidbokning. 

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

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 

48 (85)

Tjänsteproducenter 

- Verksam 

hetssystem 

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 

verksamhetsadressen (informationsägande verksamhets 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/valfrihetssystem/vårdval) förmedlar frågemeddelanden vidare 

till respektive läns eller kommuns tjänsteproducent. 

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

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 

49 (85)

- Partnerutgång 


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

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

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. 

50 (85)

- Stödtjänster 


försäkringskassan). Tjänsteväxeln utför omkuvertering enligt SHSstandard 

och dirigerar vidare till aktuell SHS-nod. 

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 

- Engagemangsindex 

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

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

- Tjänst för åtkomstkontroll 

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. 

51 (85)

1. Informationsägare 

där individen har 

engagemang av aktuell 

typ 




Lokala informationskällor 


informationskälla (logisk 

adressat) 



3. Översiktsinfo för 

ett engagemang 

4. Möjliga nya 

engagemang av 

aktuell typ 

Figur 14 – 

5. Som 2. 

6. Detaljer om ett 

bef. engagemang 

7. Uppdatering av 

bef. el. skapande av 

nytt engagemang 

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, utan uttalad koppling eller bindning till något speciellt 

systems villkor eller förutsättningar att realisera behovet. 

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. 

52 (85)


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 

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

Huvuddomän Den mest övergripande indelningsgrunden. Exempel: 

- EHR (Electronic Health Record) som omfattar alla tjänster som har att 

göra med processer för utbyte av vårddokumentation inom 

sammanhållen journalföring. 

- CRM (Customer Relationship Management) som omfattar invånarens 

processer för att välja och ta beslut relaterade till utbudet av vård och 

omsorg. 

Underdomän Den detaljerade, specifika områdesbeskrivningen. Exempel: 

- Scheduling (under CRM): Individens tidbokningsprocess 

- Listning (under CRM): individens vårdvals/kundvalsprocess 

- Ehr Exchange (under EHR): Utbyte av journalutdrag inom sammanhållen 

journalföring 

- Accesscontrol (under EHR): Tjänster för åtkomstkontroll inom 

sammanhållen journalföring 

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

- GetSubjectOfCareSchedule i underdomän Scheduling och huvuddomän 

CRM. 

53 (85)


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. 

Följande figur beskriver referensmodellen för tjänstekontrakt i UML-form: 

Tjänstekontraktens användning 

Figur 15 – Tjänstekontraktets uppbyggnad - referensmodell 

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. 

54 (85)


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

Figur 16 – 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. 

55 (85)

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. Eftersom exemplen också används i arkitekturledningens löpande arbete förvaltas 

originalen fristående från t-boken. De kan då komma att användas som målbilder för projekt och 

förvaltningsobjekt. 

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. 

56 (85)


Figur 17 – 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 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 

5, 8, 

11 

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. 

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 

57 (85)


tjänsteproducent efter patientens tidbokningar hos aktuell vårdmottagning. 

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

58 (85)

Lokalt driven e-tjänsteutveckling för invånartjänster 


Referensarkitekturen ska vara tillämpbar för lokalt driven e-tjänsteutveckling. Det innebär att en sammanhållen 

användarupplevelse för invånaren kan erbjudas utan krav på att alla e-tjänster inom en e-tjänstekanal är 

driftsatta i en central portalplattform. Entrén till en e-tjänstekanal (t.ex. ”Min Sida”) kan vara hårt kopplad till 

kanalens plattform, men länkar till enskilda e-tjänster inom kanalen kan leda till webbapplikationer som 

utvecklats och förvaltas av kommuner, regioner, landsting eller privata aktörer. Länkar i den lokalt realiserade etjänster, 

kan i sin tur leda till nationellt realiserade e-tjänster och så vidare. För att en sådan virtuell portal ska 

kunna uppstå och samtidigt upplevas som vore alla e-tjänsterna utvecklade och integrerade i en central etjänstekanal 

av en och samma utvecklingsavdelning (jmf Mina Vårdkontakter), behövs regelverk och 

stödtjänster. 

Information och presentationsmallar för inramning, meny-innehåll och andra element som varje e-tjänst inom 

en e-tjänstekanal behöver, finns tillgängliga som stödtjänster för samordnat innehåll. Det möjliggör lokal och 

parallell utveckling och drift av fristående e-tjänster. Dessa stödtjänster kan ha sin realisering i e-tjänstekanalens 

centrala plattform, eller som fristående tjänster. Genom att informationsutbytet sker över standardiserade 

tjänstekontrakt hålls dörren öppen för att förändra strategin för stödtjänsternas realisering. Följande figur 

beskriver en arkitektur för lokalt driven e-tjänsteutveckling: 

Figur 18 – Vägledande exempel för lokalt driven utveckling av invånartjänster 

I tabellen nedan beskrivs nyckelkomponenterna i exemplet (utöver de som redan beskrivits i det generella 

exemplet för e-tjänster): 

59 (85)


Sammanhållen 

användarupplevelse 


Den virtuella portal som bildas genom att e-tjänster underordnas ett 

gemensamt regelverk med tillhörande stödtjänster: 

- Nationellt samordnat innehåll: Alla delar av webbsidan som inte är 

specifik för e-tjänsten och som föreskrivs av det nationella 

regelverket. Det täcker bl.a. ”branding”, all navigering till andra etjänster 

(t.ex. i menyform) och generella funktioner som är 

tillgängliga på alla sidor, så som invånarens inkorg. Dessa delar 

produceras av en fristående, nationell tjänst som används av alla 

e-tjänster som är del av den virtuella portalen. 

- E-tjänstens yta: Den del av webbsidan som den enskilda e-tjänsten 

genererar innehåll för. 

- Entré till virtuell portal: Invånarens startsida i e-tjänstekanalen 

(länkning direkt till alla e-tjänster i den virtuella portalen är 

möjlig). 

- Nationell E-tjänst: En e-tjänst som är utvecklad med avsikt att vara 

tillämpbar för alla organisationer. 

- Lokal/regional e-tjänst: En e-tjänst som är utvecklad i regional regi 

och inledningsvis bara aktiveras för huvudmannens organisation 

eller enskilda enheter. 

Meddelandetjänst Ett exempel på nationell stödtjänst som möjliggör för alla e-tjänster (och 

andra tjänstekonsumenter) – oberoende av var de förvaltas, var de är i 

drift och vilka organisationer de betjänar, att generera meddelanden till 

professionen och medborgaren, som t.ex. kan visas som del i ”samordnat 

innehåll” (se nedan). 

Samordnat innehåll Den nationella stödtjänst som öppnar upp för skapandet av en virtuell 

portal. Tjänsten är specifik för en e-tjänstekanal. Tjänsten är beroende av 

flera underliggande informationskällor så som e-tjänsteerbjudande och etjänsteutbud. 

Varje e-tjänst i den virtuella portalen använder denna tjänst 

för att rendera huvuddelen av en webbsida, för att sedan själv fylla på 

innehåll i den yta som är specifik för e-tjänsten. 

60 (85)

Å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änstedomän. 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. 

Personuppgifter 

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

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 

61 (85)


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 kvalitet 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 20 – 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. 

Uppdatering av engagemangsindex 

Syftet är att tillhandahålla en engagemangsindextjä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 

62 (85)


Engagemangsindextjänsten är stödtjänst till aggregerande tjänster. Aggregerande tjänster är alltså 

engagemangsindextjänstens huvudsakliga tjänstekonsument. Engagemangsindex har också ett värde av generell 

karaktär för e-tjänstekanaler så som Mina Vårdkontakter. Genom engagemangsindex kan en e-tjänstekanal 

konstatera vilka e-tjänster (baserat på invånarens totala engagemangsuppsättning) som är aktuella att 

sammanställa i kanalens entré (t.ex. ”Min sida”). 

Aggregerande tjänster realiseras på ett systematiskt och enhetligt sätt (”generiskt”). De betjänas därför bäst av 

ett generiskt tjänstekontrakt som täcker alla engagemangstyper. Engagemangsindextjänsten behöver periodiskt 

eller händelsestyrt uppdateras med information från de verksamhetssystem som utgör informationskällor. 

I exemplet tillämpas referensarkitekturen när engagemangsindextjänsten ska uppdateras från 

informationskällorna. Engagemangsindextjänsten agerar då i rollen som tjänstekonsument som via en virtuell 

tjänst når information från lokala, regionala och eventuella nationella informationskällor. Eftersom information 

ska hämtas från alla kända källor som har information som engagemangsindextjänsten behöver, bör 

tjänsteproducenterna kontaktas parallellt. Realiseringen av engagemangsindextjänsten har därför många 

likheter med aggregerande tjänster. Det lyfts fram i figuren nedan genom en symbol i tjänstekonsumenten. 

För att möjliggöra effektiv realisering är det viktigt att varje tjänsteproducent endast anropas en gång. 

Verksamhetsbaserad adressering kan därför inte tillämpas på samma sätt som för verksamhetsnära 

tjänstekontrakt. Istället behöver tjänsteproducenterna betraktas som informationsägare. Men för att det ska 

kunna ske, behöver tjänsteadresseringskatalogen publicera en tjänst vars tjänstekontrakt ger 

engagemangsindextjänsten möjlighet att fråga vilka informationsägare (d.v.s. tjänsteproducenter identifierade 

av t.ex. deras HSA-id) som sammantaget existerar för tjänstekontraktet ”Redovisa Alla Engagemang”: 

63 (85)


Figur 21 – Vägledande exempel för replikering av engagemangsinformation (”pull”) 

Efter detta uppslag (steg 1 i figuren), kan engagemangsindextjänsten orkestrera parallella anrop till den virtuella 

tjänsten för ”Redovisa Alla Engagemang” (steg 2 i figuren). Den kan då med hjälp av tjänsteproducentens 

identitet använda information i tjänsteadresseringskatalogen för att på vanligt vis dirigera frågemeddelandet till 

tjänsteproducenten i fråga (steg 4 i figuren). 

Tjänsteadresseringskatalogen kan här antas hålla information om med vilken periodicitet en tjänsteproducent 

accepterar att ”Redovisa Alla Engagemang”. På så sätt kan engagemangsindextjänsten hålla index uppdaterat. 

Den bör också kunna redovisa statistik över kvaliteten i uppdateringar från olika tjänsteproducenter. 

Eftersom det blir en fördröjning mellan att informationskällan uppdateras och att detta speglas i 

engagemangsindex, riskerar användare av till exempel e-tjänster för invånare att bli missledda. Risken uppstår 

när användaren agerande i e-tjänsten resulterat i en förändring av engagemanget (t.ex. ändrat ett vårdval) som 

sedan inte speglas i en efterföljande navigering till översikten (eftersom index inte hunnit uppdateras sedan 

verksamhetssystemet uppdaterades av invånaren). Detta kan hanteras genom att tillåta virtuella tjänster att 

direkt uppdatera index. 100 % exakthet kan inte garanteras för översikter som är beroende av indextjänsten, 

men med denna form av direktuppdatering kan risken för inkonsistens minimeras. 

Figuren nedan visar detta i ett sammanhang. Tidigare exempel för e-tjänster har här kompletterats med 

direktuppdatering av index i samband med att en nybokning genomförs (steg 15 + 15b). När användaren 

återvänder till översikten efter genomförd nybokning kommer engagemangsindex att rapportera 

bokningsengagemang hos en ny mottagning och den aggregerande tjänsten att fråga efter bokade tider hos den 

64 (85)


mottagningen. Det leder i sin tur till att den nya bokningen direkt syns i översikten (”min kalender”). Lösningen 

består i att Engagemangsindex-tjänsten har utökats med tjänsteproducent för tjänstekontraktet 

”Direktuppdatera index”. Det ger invånaren en konsistent bild av informationen utgående från eget agerande. 

Men ev. uppdateringar som sker av medarbetare direkt i verksamhetssystemen kommer fortfarande att visas 

först vid nästa ”pull”: 

Figur 22 – Korrekt översikt efter uppdatering av källa. 

Det som i figuren ovan benämns ”Replikera index” är det som beskrivs i figuren dessförinnan. 

Direktuppdateringskontraktet hos Engagemangsindex bör också vara tillgänglig för informationskällor (t.ex. 

verksamhetssystem) med behov av att direkt spegla förändringar som inte initieras av invånaren: 

65 (85)

Replikering av stödtjänst 


Figur 23 – Direkt-uppdatering av Engagemangsindex från källan (push) 

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. 

66 (85)


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 24 – Ny spärrinformation i en instans replikeras till övriga instanser. 


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 

67 (85)

Virtuella tjänster 

- Registrera 

Spärrinformation 


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. 

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. 

5.3 Teknisk vy 

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

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 

68 (85)


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. 

Komponenterna beskrivs översiktligt i följande tabell: 


Figur 25 – Komponenter i referensarkitekturen 

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

69 (85)


70 (85) 

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


71 (85) 

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

72 (85) 

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 nationell tjänst som erbjuder 

administration och åtkomst av information som ligger till grund för 

verksamhetsbaserad adressering och åtkomstkontroll som utförs i 

virtualiseringsplattformen. Det betyder att 

virtualiseringsplattformen har ett beroende till ett nationellt 

tjänstekontrakt för att hämta vägvalsinformation från 

tjänstekataloger, men också till tjänstekontraktet för flygande 

uppdateringar mot av engagemangsindex. 

- Engagemangsindextjänst Engagemangsindex är en nationell tjänst som erbjuder ett 

mellanlager av indexinformation. Informationen hålls 

synkroniserad med informationskällor. 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 identitet för 

informationsägarens verksamhet (t.ex. vårdgivare, vårdenhet, län, 

skola eller kommun) 

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


- Stödtjänster för virtuell portal Dessa tjänster utgör sammantaget det som behövs för att nå 

visionen om lokalt driven e-tjänsteutveckling och virtuella portaler. 

Se vägledande exempel ”Lokalt driven e-tjänsteutveckling” för 

bakgrund. 

73 (85)

5.3.1. Tjänsteadresseringskatalog 


UML-modellen nedan beskriver den informationsstruktur som behövs för att representera 

verksamhetsadressering och behörighetsstyrning i en tjänsteadresseringskatalog: 

5.3.2. Engagemangsindex 

Figur 26 – Datalager, tjänsteadresseringskatalog 

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 Listad (vårdval/kundval), Bokad tid, Inskriven och Har Journal. 

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 individ listad enligt vårdval (Vårdval)? 

Vid vilka vårdenheter är individen inskriven (Inskriven)? 

74 (85)


Tack vare detta index, kan tillämpningar sammanställa och presentera information (t.ex. en tidbok eller 

patientöversikt) om individen ur ett nationellt perspektiv utan att behöva fråga varje system i landet varje gång. 

Följande UML-modell beskriver den informationsstruktur som behövs för att representera invånarens 

engagemang i en engagemangsindextjänst: 

Figur 27 – Datalager, engagemangsindex 

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

engagemangsindex”. 

75 (85)

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: 

76 (85) 

Certifikat: HCC Funktion för autentisering och kryptering. Båda parter i en RIVTAförbindelse 

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 28 – Exempel, tillämpning av teknisk referensarkitektur inom huvudman 

Figuren illustrerar ett exempel på anslutningsarkitektur i federation 24 med lokal (inom huvudman) instans av 

referensarkitekturen, där integration sker över internet och Sjunet. 

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 

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

77 (85)


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. 

78 (85)


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

figur: 

Figur 29 – Referensarkitekturen i federation – nationellt perspektiv 

I den federerade strukturen uppstår ett antal egenskaper som är gynnsamma för kvaliteten 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. 

79 (85)


Det omvända förhållandet uppstår när tjänstekonsumenter hos huvudmannen kommunicerar med nationella 

tjänsteproducenter, enligt följande figur: 

Figur 30 – Referensarkitekturen i federation - huvudmannaperspektivet 

80 (85)

T-boken över tiden 

Revision Viktiga förändringar 

Revision A, 2007 Första utgåvan av T-boken 

Revision B, 2011 

(Färdigställs efter denna 

remissutgåva) 


- 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 VIT-boken. 

81 (85) 

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

- Detaljerade typanvändningsfall har ersatts med typflödesmodeller 

i t-bokens verksamhetsvy.


82 (85) 

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

Bilaga – Ordlista och förkortningar 

Ordlista 


Arkitektur Beskrivning av ett systems grundläggande struktur med dess 

delar och relationer mellan dessa och till omgivningen samt 

principer för systemets utveckling. 

Arkitekturledningen Arkitekturledningen är en arkitekturfunktion på nationell nivå 

under CeHis. 

Autentisering Kontroll av uppgiven identitet, till exempel vid inloggning, vid 

kommunikation mellan två system eller vid utväxling av 

meddelanden mellan användare. 

Back office Administration funktion som stöder verksamheten. 

Bastjänster för informationsförsörjning, BIF Stödtjänster som enhetligt ska garantera säkerheten vid 

informationsutbyte – rätt information till rätt person. 

Brukare Kan betyda individ som brukar omsorg 

Federation Sammanslutning av flera självständiga enheter, till exempel 

organisationer. 

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

Informationsstruktur Uppsättning begrepp, termer och informationsmodeller samt 

koder och klassifikationer. Behövs för att fullfölja och 

harmonisera projekt och förvaltningsobjekt. 

Integrationstjänst Ett samlingsnamn för tjänster som syftar till att knyta samman 

tjänstekonsumenter och tjänsteproducenter. Referensarkitekturen 

beskriver följande typer av integrationstjänster: Virtuell tjänst, 

Aggregerande tjänst. 

Interoperabilitet Förmågan hos olika system att fungera och kommunicera med 

varandra. 

83 (85)


Lingua franca Ett internationellt hjälpspråk för kommunikation mellan 

människor med olika modersmål. 

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

Referensarkitektur En referensarkitektur är en abstrakt arkitektur som används som 

en mall för att skapa konkreta arkitekturer. Referensarkitekturen 

innehåller principer och guidelines som bestämmer hur system 

skall designas. 

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. 

SOA-tjänst Ett gränssnitt för automatiserad samverkan (t.ex. ett webservice-gränssnitt) 

som följer ett fastställt tjänstekontrakt. 

Referensarkitekturen beskriver följande typer av SOA-tjänster: 

Integrationstjänst, Tjänsteproducent. 

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 IDkort 

med ett elektroniskt PKI-certifikat. 

Tjänstekontrakt Ett dokument som reglerar och styr hur kommunikationen ska 

utformas mellan två system. 

84 (85) 

En maskinläsbar, system- och plattformsoberoende definition av 

ett maskin-till-maskin gränssnitt.

Förkortningar 

BHD Barnhälsodata 


BIF Stödtjänster för informationsförsörjning 

CeHis Center för eHälsa i samverkan 

DMZ Demilitariserad zon 

HSA Hälso- och Sjukvårdens Adressregister 

IFK Informationsförsörjning kvalitetsregister 

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 

85 (85)

(T-boken), rev B - Center för eHälsa i samverkan

Create successful ePaper yourself

Delete template?

Save as template?