Anvisning till VIT-boken– VIT-bokens tekniska arkitektur Revision A

RAPPORT 1(87)
2007-03-07 Ver 0.1
Anvisning till VIT-boken – VIT-bokens tekniska arkitektur
Revision A
VIT-bokens tekniska arkitektur
Kontaktperson: Sara Meunier
2007-12-20

Förord
ANVISNING - 2 (87)
2007-12-20 REV A
En vårdgivares 1 övergripande uppgift är att främja hälsa och ge en God Vård på lika villkor åt
Sveriges invånare. Detta är också den viktigaste utgångspunkten för ledning och styrning av
vård och omsorg. Vård och omsorg ska vara tillgänglig, ha god kvalitet och bygga på respekt
för patientens/brukarens självbestämmande och integritet. Goda kontakter mellan brukare,
patienter och personal ska främjas och vården ska så långt som möjligt utföras och
genomföras i samråd med brukaren eller patienten.
För att stödja vård och omsorgs behövs ett kvalificerat IT-stöd som utvecklas i den riktning
som den nationella IT-strategin för vård och omsorg anger. Förslaget till ny patientdatalag
anger regler och begränsningar hur vårdinformation får hanteras inom vården och hur dess ITstöd
kan utformas.
Sammantaget utgör kraven på God Vård, den nationella IT-strategin och ny patientdatalag ett
väsentligt underlag för samverkan och utveckling av verksamhet och IT inom vård och
omsorg. För att få tyngd bakom samverkan och utveckling inom vård och omsorg är det av
yttersta vikt att inblandade parter, bland annat Sveriges Kommuner och Landsting,
Socialstyrelsen och Sveriges vårdgivare, ser utvecklingen som ett strategiskt samarbete. En
kritiskt framgångsfaktor är att samarbetet utgår från en verksamhetsdriven helhet, en
gemensam målbeskrivning, en arkitektur och en gemensam plan för helheten.
Som ett led i att realisera ovanstående intentioner har följande rapporter tagits fram; ”VITboken”
som är en leverans från Arkitektursamordning och ”Anvisning till VIT-boken – VITbokens
tekniska arkitektur” (detta dokument).
Syftet med ”VIT-boken” är att beskriva en nationell arkitektur inklusive styrande principer
och regler för samverkan inom vård och omsorg i Sverige. VIT-boken ska bidra till en God
Vård, ökad arbetstillfredställelse samt ökad effektivitet och produktivitet inom vård och
omsorg.
Syftet med ”VIT-bokens tekniska arkitektur” är att beskriva principer för uppbyggnad av den
nationella arkitekturen i form av en teknisk referensarkitektur samt användningsfall med ett
tekniskt perspektiv på realisering. Detta ska underlätta för nationella projekt att leverera ITtjänster
som uppfyller kraven på ett förutsägbart sätt. Syftet har också varit att nå samförstånd
i inom NARRR-gruppen om den tekniska arkitekturen.
Rapporten utgör NARRR-gruppens beskrivning av den tekniska arkitekturen inklusive
motiveringar och argumentation. Rapporten är en redogörelse för förståelsen just nu
(december 2007). Innehållet kommer att behöva bearbetas ytterligare för att anpassas till olika
målgrupper och sammanhang.
VIT-bokens tekniska arkitektur fokuserar på samverkan mellan vårdgivare. Samverkan avser
bland annat den samverkan mellan vårdgivare som måste finnas i en viss vårdsituation för att
kunna erbjuda God Vård i en individs hälsoärende.
VIT-boken med dess regelverk och VIT-bokens tekniska arkitektur ska tillämpas av och vara
styrande för de tjänster, tillämpningar, projekt etc. som berör eller berörs av den nationella
arkitekturen. Detta inkluderar upphandlingar, kompletteringar, vidareutvecklingar etc. av
produkter och tjänster/tillämpningar inom ramen för den nationella arkitekturen.
1 Dokumentet omfattar även Omsorg även om det inte är explicit uttryckt.

ANVISNING - 3 (87)
2007-12-20 REV A
Arbetet är dock inte färdigt i och med denna rapport. Arbete återstår! Bland annat måste
avsnitten om säkerhet utvecklas och kopplingen mot Verksamheten och
Informationsstrukturen göras tydligare. Vidare måste verksamhetskraven, bland annat kraven
på God Vård, skärpas och analyseras. Krav och behov från Omsorgen måste också beaktas.
Det är av yttersta vikt att läsaren har förståelse för att arbetet med arkitektur inte är statiskt
och att den tekniska arkitekturen inte är ”färdig” i och med denna rapport. Arkitekturen
kommer att behöva förändras över tiden allteftersom behov och drivkrafter förändras.
Arkitektur är inte ett mål i sig utan ett verktyg för att förändra, förbättra och utveckla en
verksamhet. Arkitektur är en process och inte en statisk ”ritning”. Det som beskriv i denna
rapport ska ses som ett börläge vars realisering kommer att ta lång tid – med många
mellanliggande ritningar för arkitekturen. Även börläget kommer att förändras över tiden 2 .
Arbetet med att ta fram VIT-bokens tekniska arkitektur har bedrivits i projektform under
andra halvåret 2007. Projekt kan ses som en andra etapp i ett långsiktigt arbete med en
nationell arkitektur. Uppdraget har genomförts i en projektgrupp som, trots snäv tidsplan för
detta komplexa område, har ställt upp för projektet och tillsammans med styrgruppen för
projektet levererat denna rapport.
Projektgruppens medlemmar:
Sara Meunier Carelink
Anders Börjesson Landstinget i Värmland
Johan Eltes Callista Enterprise
Kurt Helenelund Metamatrix
Lennart Eriksson Stockholms Läns Landsting
Anders Norr Landstinget i Östergötland
Per Torlöf Region Skåne
Jan Edman Landstinget i Västmanland
Tommy Rigo Västra Götalands regionen
Staffan Dahlin Västra Götalands regionen
Per-Arne Lundgren Region Skåne
Torbjörn Ivarsson Region Skåne
Qemajl Imeri Stockholms Läns Landsting
David Lindahl Landstinget i Kalmar
Gunnar Klein Objektfabriken/KI
Peter Alvinsson, Styrgruppordförande Nationell Arkitektur –RRR
Sara Meunier, Projektledare Nationell Arkitektur – RRR
2
Allteftersom verksamhetens krav, behov och målbild växer fram kommer arkitekturens börläge (målbild) att
förändras.

Innehållsförteckning
ANVISNING - 4 (87)
2007-12-20 REV A
1 Introduktion till VIT-bokens tekniska arkitektur ............................................................... 6
1.1 Syfte med VIT-boken .......................................................................................................................... 6
1.2 Syfte med VIT-bokens tekniska arkitektur .......................................................................................... 7
1.3 Samverkan ........................................................................................................................................... 7
1.4 Omfattning ........................................................................................................................................... 7
1.5 Läsanvisningar ..................................................................................................................................... 8
2 Nationell arkitektur för samverkan .................................................................................. 11
2.1 Nationell IT-strategi för Vård och Omsorg........................................................................................ 11
2.2 Konsekvenser av föreslagen patientdatalag .......................................................................................11
2.3 En arkitektur för helheten .................................................................................................................. 12
2.4 Metod för att identifiera tjänster ........................................................................................................ 13
2.5 Styrande principer.............................................................................................................................. 14
2.6 Samverkan ......................................................................................................................................... 16
3 Referensarkitektur ............................................................................................................ 21
3.1 Bakgrund och syfte ............................................................................................................................ 21
3.2 Principer för den tekniska arkitekturen från verksamhetsperspektiv ................................................. 21
3.3 Tillämpning av referensarkitekturen.................................................................................................. 26
3.4 Översikt referensarkitektur ................................................................................................................ 26
3.5 Domänarkitektur ................................................................................................................................ 35
3.6 Tjänsteorienterad arkitektur ............................................................................................................... 35
3.7 Tjänsteinteraktioner ........................................................................................................................... 38
3.8 Tjänstedomäner.................................................................................................................................. 39
3.9 Tjänstetyper ....................................................................................................................................... 42
4 Användingsfall och tekniska komponenter...................................................................... 47
4.1 Utgångspunkter.................................................................................................................................. 47
4.2 Förutsättningar och avgränsningar..................................................................................................... 47
4.3 Interaktionsmönster............................................................................................................................ 48
4.4 Realisering av tjänsteplattform .......................................................................................................... 77
Bilaga 1 – Säkerhet .................................................................................................................. 79
Bilaga 2 – Referenser ............................................................................................................... 83
Bilaga 3 – Ordlista.................................................................................................................... 84
Bilaga 4 – Metodskiss för användningsfall.............................................................................. 86
Bilaga 5 – Målnedbrytning av Nationell IT-strategi för Vård och Omsorg............................. 87

ANVISNING - 5 (87)
2007-12-20 REV A
Figurer
Figur 1 - VIT – boken ................................................................................................................ 6
Figur 2 - Arkitektur som process................................................................................................9
Figur 3 - Arkitektur som stöd på vägen från nuläge till målbild.............................................. 12
Figur 4 - VIT-boken från processer till IT-tjänster .................................................................. 13
Figur 5 - Vård- och omsorg i Sverige ...................................................................................... 16
Figur 6 - Samverkan mellan vårdgivare................................................................................... 17
Figur 7 – Samverkan ”punkt-till-punkt” eller samverkan med gemensam förmedling ........... 18
Figur 8 - Interoperabilitet ......................................................................................................... 19
Figur 9 - Vision för IT-stödet................................................................................................... 27
Figur 10 - Dagens situation för IT-stödet................................................................................. 28
Figur 11 - Punkt-till-punkt samverkan..................................................................................... 28
Figur 12 - Nationella vårdprocesser och IT-stöd ..................................................................... 29
Figur 13 - Samverkan mellan vårdgivares IT-stöd och nationellt IT-stöd............................... 30
Figur 14 - Samverkansdomäner ............................................................................................... 31
Figur 15 - Tjänsteplattform ...................................................................................................... 32
Figur 16 – Sekvensdiagram – nationell tjänsteplattform ......................................................... 33
Figur 17 - Informationsmodell vägvalstjänst ........................................................................... 33
Figur 18 - Sekvensdiagram federerad tjänsteplattform ............................................................ 34
Figur 19 - Domänarkitektur...................................................................................................... 35
Figur 20 - Notation för tjänstekontrakt .................................................................................... 36
Figur 21 - Referensmodell för tjänstekontrakt ......................................................................... 36
Figur 22 - Notation för tjänsteinteraktioner ............................................................................. 38
Figur 23 - Mönster för tjänsteinteraktioner.............................................................................. 38
Figur 24 - Partnerinteraktion.................................................................................................... 39
Figur 25 - Indelning av tjänster och domäner .......................................................................... 39
Figur 26 - Tjänstedomäner ....................................................................................................... 40
Figur 27 - Samverkans- och tjänstedomäner............................................................................ 40
Figur 28 - Tjänstekontrakt och tjänstekomponent.................................................................... 41
Figur 29 - Tjänsteplattform och lösa kopplingar...................................................................... 42
Figur 30 - Orkestrerande tjänst................................................................................................. 44
Figur 31 - Remissdata interaktion är av typen Fråga-Svar....................................................... 45
Figur 32 - Arbetsflödesinteraktioner är av typen Uppdrag-Resultat........................................ 45
Figur 33 - Orkestrering och tjänster ......................................................................................... 45
Figur 34 - Orkestrering och tjänsteplattform............................................................................ 46
Figur 35 - Teknisk realisering med tjänsteplattform................................................................ 78
Figur 36 – Biljett-fasad-klientsamverkan................................................................................. 80
Figur 37 – Samverkan i webklient ........................................................................................... 81
Figur 38 – SOA-tjänst kompletterat med säkerhetsfunktionalitet (signering, kryptering) ...... 82

ANVISNING - 6 (87)
2007-12-20 REV A
1 Introduktion till VIT-bokens tekniska arkitektur
Denna anvisning ”VIT-bokens tekniska arkitektur” är en del av VIT-boken. VIT-boken består
av en övergripande del samt tillhörande anvisningar som presenteras i separata dokument som
t.ex. detta dokument.
1.1 Syfte med VIT-boken
Syftet med VIT-boken är att beskriva en nationell arkitektur inklusive styrande principer och
regler för samverkan inom vård och omsorg i Sverige. VIT-boken ska bidra till en God Vård 3 ,
ökad arbetstillfredställelse samt ökad effektivitet och produktivitet inom vård och omsorg.
Den nationella arkitekturen samt regler, riktlinjer och rekommendationer (RRR:er 4 ) spelar en
avgörande roll för hur framgångsrik samverkan blir. Utan samförstånd, gemensamma mål och
spelregler – ingen samverkan! Den nationella arkitekturen beskriver verksamhetens mål,
strategier och behov samt hur verksamheten stöds av en enhetlig informationsstruktur och en
ändamålsenlig teknisk arkitektur. Den nationella arkitekturen utgör ett ramverk utifrån dessa
perspektiv; Verksamhet, Informationsstruktur och Teknik. Regelverket uttrycks i Regler,
Riktlinjer och Rekommendationer för Verksamhet, Informationsstruktur och Teknik – VITboken!
Figur 1 - VIT – boken
De olika perspektiven i VIT-boken ska ha spårbarhet mellan varandra så att man kan se hur de
överliggande lagren påverkar de underliggande.
3 Motsvarande begrepp för omsorg skulle kunna vara God Omsorg.
4 Se VIT-boken

ANVISNING - 7 (87)
2007-12-20 REV A
1.2 Syfte med VIT-bokens tekniska arkitektur
Syftet med ”VIT-bokens tekniska arkitektur” är att beskriva principer för uppbyggnad av den
nationella arkitekturen i form av en teknisk referensarkitektur samt användningsfall med ett
tekniskt perspektiv på realisering. Detta ska underlätta för nationella projekt att leverera ITtjänster
som uppfyller kraven på ett förutsägbart sätt. Syftet har också varit att nå samförstånd
inom NARRR om den tekniska arkitekturen.
Utgångspunkten har varit en målnedbryting av IT-strategin samt scenarier för verksamheten
formulerade som enkla användningsfall, se Bilaga 4 – Metodskiss för användningsfall.
De principer som återfinns i detta dokument är tillämpliga på nationell nivå. De skulle även
kunna vara tillämpliga lokalt inom vårdgivare 5 , detta har dock inte varit syftet med
anvisningen och om ett lokalt perspektiv skall användas behöver dokumentet vinklas efter
dessa förutsättningar. Lokal tillämpning av VIT-bokens tekniska arkitektur utgör ingen
förutsättning för att delta i samverkan, även om det förutses utgöra den enklaste vägen för de
vårdgivare som saknar motsvarande strukturer.
1.3 Samverkan
Samverkan avser dels den samverkan mellan vårdgivare som måste finnas i en viss
vårdsituation 6 för att kunna erbjuda God Vård i en individs hälsoärende, och dels strukturell
samverkan som syftar till att leda och styra, följa upp, utveckla, förvalta och organisera vård
och omsorg i syfte att möjliggöra effektiv produktion av God Vård.
Samverkan är ett väl använt ord som kan ha olika betydelse beroende på betraktaren. I detta
dokument används samverkan för att beskriva behovet av att kunna komma åt och förmedla
information som behövs i en specifik vårdsituation. Det vill säga att se till att information
finns tillgänglig där och då den behövs och i rätt situation och för rätt brukare.
Samverkan används också i detta dokument för att beskriva en strukturell samverkan lokalt,
regionalt och nationellt, oftast formaliserad, som behövs för att möjliggöra att information kan
göras tillgänglig mellan olika vårdgivare. Samverkan kan ske i form av lokala/regionala
gemenskaper mellan olika vårdgivare för att dels uppnå skalfördelar i utveckling och
produktion och dels för att kunna erbjuda ett sammanhängande stöd i enskilda hälsoärenden,
den senare typen av samverkan benämns i dokumentet för strukturell samverkan.
1.4 Omfattning
VIT-boken med dess regelverk, såsom denna anvisning, ska tillämpas av och vara styrande
för de tjänster, tillämpningar, projekt etc. som berör eller berörs av den nationella
arkitekturen. Detta inkluderar upphandlingar, kompletteringar, vidareutvecklingar etc. av
projekt och tjänster/tillämpningar inom ramen för den nationella arkitekturen.
VIT-bokens primära syfte i dagsläget är dock fokuserat på att underlätta och stödja samverkan
mellan vårdgivare i Sverige för att primärt stärka patientsäkerheten. Om samverkan ska kunna
utvecklas i någon högre grad krävs att varje vårdgivares verksamhetssyn, informationsstruktur
5 Socialstyrelsen: Vårdgivare är statlig myndighet, landsting och kommun i fråga om sådan hälso- och
sjukvårdsverksamhet som myndigheten, landstinget eller kommunen har ansvar för (offentlig vårdgivare) samt
annan juridisk person eller enskild näringsidkare som bedriver hälso- och sjukvårdsverksamhet (privat
vårdgivare). Omsorgsgivare kan vara offentliga (stat, landsting, kommun) eller privata (juridisk eller fysisk
person).
6 Omfattar även omsorgsituation.

ANVISNING - 8 (87)
2007-12-20 REV A
och IT-stöd är synkroniserade. Ju djupare samverkan, desto större synkronisering krävs.
Därför kan VIT-boken i vissa fall även ange anvisningar om hur vårdgivarnas egna IT-stöd
bör vara beskaffade till sin struktur eller till vissa detaljer. Det innebär inte att lokal
utveckling ska stoppas eller att egna lösningar inte ska finnas. Tvärtom ligger det primära
ansvaret lokalt och dess utveckling kan främja helheten genom att tjäna som förebild för nya
samverkanslösningar.
Även om VIT-boken i dagsläget avser den nationella arkitekturen för sammanhållen
patientinformation kan det finnas en möjlighet att i tillämpliga fall även nyttjas i det
lokal/regionala utvecklingsarbetet inom vården.
Primärt ska lösning och arkitektur för samverkan i dagsläget avse samverkan mellan olika
vårdgivare. Samverkan mellan vårdgivare regleras av nationella regler och riktlinjer. En
vårdgivare kan certifieras för att kunna anslutas till den nationella infrastrukturen. Samverkan
kan också avse samverkan mellan flera vårdgivare lokalt eller regionalt i en gemenskap.
Oavsett om samverkan sker mellan olika vårdgivare eller i en gemenskap av vårdgivare så
gäller samma regelverk.
Sekundärt kan samma lösningar och arkitektur även appliceras internt inom en vård eller
omsorgsgivare. Om samma regler och riktlinjer även används inom vårdgivare så innebär det
att tröskeln för att ansluta sig till den nationella arkitekturen blir betydligt mycket lägre. Om
den interna arkitekturen inom en vårdgivare väsentligen 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.
Observera att enligt föreslagen patientdatalag så kan spärrar finnas även mellan vårdenheter
och vårdprocesser inom en vårdgivare 7 . Detta innebär att de lösningar som tas fram på
nationell nivå för att uppfylla patientdatalagens intentioner även bör klara av lokala eller
regionala behov.
Olika vårdgivare kommer att utvecklas i olika takt och de har olika ekonomiska och tekniska
förutsättningar för att utforma egna interna lösningar och för att ansluta sig till den nationella
infrastrukturen för samverkan mellan vårdgivare.
Arkitekturen syftar till att sänka tröskeln för att integrera vårdens information och processer –
t.ex. genom gemensamma lösningar – och på så sätt sänka kostanden och öka nyttan av
samverkan utan att ge avkall på självbestämmanderätten.
Ovanstående resonemang innebär att arkitekturen kommer att utformas som ett ”nätverk av
nätverk” där varje vårdgivare kan ansluta sitt nätverk i den takt som den bestämmer.
1.5 Läsanvisningar
Detta dokument omfattar både vård och omsorg, dock med betoning på vård. Begreppen
patient/kund/invånare/brukare används i de flesta fall som utbytbara begrepp. Dokumentet är
en anvisning till VIT-boken och är omfattande samt täcker in många aspekter. Därför
rekommenderas att läsaren fokuserar på de aspekter som är av primärt intresse vid en första
genomläsning. Däremot är det viktigt att läsa hela dokumentet om läsaren vill få en förståelse
för hur den föreslagna arkitekturen växer fram – från styrande principer till realisering.
7 ”4 § Personuppgifter, som dokumenterats för ändamål som anges i 2 kap. 4 § första stycket 1 och 2 hos en
vårdenhet eller inom en vårdprocess, får inte göras tillgängliga genom elektronisk åtkomst för den som arbetar
vid en annan vårdenhet eller inom en annan vårdprocess hos samma vårdgivare, om patienten motsätter sig det. I
sådana fall skall uppgiften genast spärras”

ANVISNING - 9 (87)
2007-12-20 REV A
Det är av yttersta vikt att läsaren har förståelse för att arbetet med arkitektur inte är statiskt
och att den tekniska arkitekturen inte är ”färdig” i och med denna rapport. Arkitekturen
kommer att behöva förändras över tiden allteftersom behov och drivkrafter förändras.
Arkitektur är inte ett mål i sig utan ett verktyg för att förändra, förbättra och utveckla en
verksamhet. Arkitektur är en process och inte en statisk ritning. Det som beskriv i denna
rapport ska ses som ett börläge vars realisering kommer att ta lång tid – med många
mellanliggande versioner av arkitekturen. Även börläget kommer att förändras över tiden 8 .
Rapporten ger inget tidsperspektiv för hur arkitekturen realiseras. Innehållet i kapitel 1 och 2
utgör delvis antaganden ur ett verksamhets- och informationsstrukturperspektiv som kan
komma att behöva revideras.
Figur 2 - Arkitektur som process
Introduktion
Den läsare som endast vill ha en introduktion så rekommenderas kapitel 1 och kapitel 2 som
ger en översikt, omfattning och grunder för samverkan och arkitektur. Målgruppen för dessa
kapitel är IT-ledning inom vård och omsorg, IT-leverantörer till vård och omsorg, de
nationella projekten inom ramen för realiserandet av den nationella IT-strategin samt de
regionala/lokala organisationerna för IT-utveckling. Avsnitten skall kunna läsas och förstås
även av personer med begränsad teknisk bakgrund.
Referensarkitektur
Den läsare som vill ha en djupare förståelse för den logiska arkitekturen och argumentation
för utformningen av arkitekturen hänvisas läsaren till kapitel 3. Målgruppen för detta kapitel
är framför allt tekniskt kunniga personer, såsom IT-arkitekter hos vårdgivare, leverantörernas
utvecklare och tekniska experter i de nationella projekten. Avsnittet om referensarkitekturen
är krävande för den ovane läsaren.
Användningsfall och tekniska komponenter
Den läsare som vill förstå den tekniska realiseringen av arkitekturen hänvisas till kapitel 4
som beskiver ett tekniskt perspektiv och realisering i form av interaktionsdiagram och
tjänster. Detta kapitel avser att ge läsaren en förståelse för ”hur det hänger ihop”, dvs. där går
8
Allteftersom verksamhetens krav, behov och målbild växer fram kommer arkitekturens börläge (målbild) att
förändras.

ANVISNING - 10 (87)
2007-12-20 REV A
det att följa hur verkliga användningsfall, exempelvis användande av en nationell
patientöversikt eller elektronisk förfrågan om personnummer för nyfödda, representerade som
typfall, stegvis realiseras med hjälp av tekniska komponenter. Där finns också en tydlig
spårbarhet till varför VIT-bokens Regler, Riktlinjer och Rekommendationer har utformats på
det sätt som skett. Målgruppen är även här framför allt tekniskt kunniga personer, såsom ITarkitekter
hos vårdgivare, leverantörernas utvecklare och tekniska experter i de nationella
projekten, men borde kunna läsas och förstås även av personer med begränsad teknisk
bakgrund.

ANVISNING - 11 (87)
2007-12-20 REV A
2 Nationell arkitektur för samverkan
2.1 Nationell IT-strategi för Vård och Omsorg
IT kan vara en katalysator och möjliggörare men är även en förutsättning i allt från att skapa
konkurrensfördelar i den globala konkurrensen till ett strategiskt redskap i verksamhetsutveckling.
Det är väl känt att IT i sig inte löser några problem – men utan IT kan ett
långsiktigt strategiskt förändringsarbete inte nå ända fram.
IT är idag allmänt tillgänglig men det finns ett brett utrymme för förbättring och utveckling.
IT är tillämpbart inom ett brett spektrum av användningsområden och har en potential att
användas i verksamhetens alla processer. IT kan med andra ord genomsyra hela vår
verksamhet.
I den nationella IT-strategin för vård och omsorg från 2006 presenteras en vision som
kortfattat säger att:
• med hjälp av ändamålsenliga IT-stöd får alla patienter en god och säker vård och bra
service,
• invånare/patienter ska på ett enkelt sätt få tillgång till kvalitetssäkrad information om
vård och hälsa som omfattar den egna vården och hälsosituationen
• vårdpersonalen kan ägna mer tid åt patienterna och anpassa vården till varje patients
behov
• IT-används som ett strategiskt verktyg i alla delar av vården och
• de samlade vård resurserna utnyttjas på ett mer effektivt sätt
Sex insatsområden har identifierats som lyfts fram: tillgänglighet för medborgarna, åtkomst
till information över organisationsgränser, verksamhetsstödjande och samverkande IT-stöd,
teknisk infrastruktur och lagar och regelverk.
IT-strategin pekar på behovet av samverkande IT-stöd och gemensam utveckling av ITtjänster.
I vissa fall gäller visionen en funktion – en lösning – en tillämpning.
För att vård och omsorg ska kunna utnyttja de möjligheter som modern IT ger behövs en
helhetssyn på samverkan mellan verksamhet och IT. För att underlätta, vägleda och styra
realiserandet av den nationella IT-strategin för vård och omsorg krävs ett regelverk kring
nationell arkitektur. Det kan inte nog poängteras att IT är ett medel för verksamheten och inte
ett ändamål i sig. Detta innebär att verksamheten måste utvecklas ”hand-i-hand” med ITutvecklingen
och att det oftast är via omdanande utveckling av verksamheten som IT kan
användas till sin fulla potential.
För att i största möjliga mån utforma VIT-bokens tekniska arkitektur efter IT-strategins
intentioner har en målnedbrytning av IT-strategin gjorts. Denna målnedbrytning återfinns i
Bilaga 5 – Målnedbrytning av Nationell IT-strategi för Vård och Omsorg.
2.2 Konsekvenser av föreslagen patientdatalag
Även förslaget till patientdatalag påverkar utformningen av tekniska arkitekturen. För att följa
den nya lagens intentioner har lagförslaget analyserats ur ett samverksansperspektiv. Detta
återfinns i ett separat dokument, ”Nationell Arkitektur - Patientdatalagens konsekvenser,
REVA, 2007-11-30”

ANVISNING - 12 (87)
2007-12-20 REV A
2.3 En arkitektur för helheten
Ett klassiskt problemområde inom IT är att överföra användarnas och ledningens behov och
förväntningar på ett IT-stöd till en för användaren och organisationen effektiv lösning. Ett
annat problem för vård och omsorg i Sverige är att samma behov för olika vårdgivare löses
var för sig och på olika sätt. Detta gör att vårdgivare inte kan dra nytta av
samordningsfördelar med högre kostnader och sämre kvalitet som följd. Detta leder till en
suboptimering och att man inte kan samverka på det sätt den nationella IT-strategin
förutsätter.
Det finns flera ramverk för att beskriva en organisations övergripande arkitektur. Zachmans
ramverk har fungerat som en inspirationskälla. Ramverket omfattar sex perspektiv som
sträcker sig från övergripande verksamhetskrav till installerad teknik och implementerade
program/tjänster. Dessa sex perspektiv har grupperats till de tre tidigare nämnda
huvudområden: verksamhet, informationsstruktur och teknik – VIT. Det finns även andra
ramverk för IT-arkitektur, såsom ODP– Open Distributing Processing från den internationella
standardiseringen (ISO/IEC och ITU), som särskilt fokuserar på distribuerade tjänster, med
fem vyer, som även detta genom dess tre översta vyer motsvarar VIT-bokens indelning i
verksamhet, informationsstruktur och teknik. Detta ramverk har använts för den nya HISAstandarden.
För att få genomslag måste arbetet utforma en långsiktig målbild och konsekvent styras mot
detta mål, där de verksamhetskrav jämte patientens behov, som ska stödjas, måste vara
definierade. Att fullständigt uppnå målbilden kommer att ta tid och det är därför viktigt att
tydliga etappmål tas fram. Arbetet med att realisera IT-strategin är kritiskt beroende av en
konsekvent ledning och styrning mot målbilden med etappmål.
Figur 3 - Arkitektur som stöd på vägen från nuläge till målbild
För att underlätta, vägleda och styra realiserandet av den nationella IT-strategin för vård och
omsorg krävs ett regelverk kring nationell arkitektur för sammanhållen patientinformation.
Regelverket kommer i olika avseenden och omfattning att påverka varje enskild aktör inom
vård och omsorg vilket förstärker vikten av att det löpande bedrivs ett aktivt arbete
lokalt/regionalt för att realisera den nationella IT-strategin.

ANVISNING - 13 (87)
2007-12-20 REV A
2.4 Metod för att identifiera tjänster
För att hitta vilka komponenter och interaktioner som behöver beskrivas och definieras inom
arkitekturen används generaliserade användningsfall, se även Bilaga 4 – Metodskiss för
användningsfall. Om spårbarhet och verksamhetskoppling ska upprätthållas bör nedanstående
metod för definition av vilka tjänster som ska skapas följas. Metoden utgår från processer och
användningsfall definierade av verksamheten över till informationsbehov och sen en koppling
till tjänster som tekniken tillhandahåller. Detta i sin tur leder till en realisering av ett antal
nationella samverkanstjänster och dess beskrivningar.
Figur 4 - VIT-boken från processer till IT-tjänster
Genom att analysera de användningsfall som finns för nationell samverkan kan typiska
tekniska interaktionsflöden skapas. Dessa typfall kan bortse från de enskilda tjänsternas
innehåll. I dessa typfall ska komponenter placeras in och beskrivas.
För nationella projekt är det viktigt att identifiera vilka tjänster och komponenter som är
återanvändbara. De användningsfall som tas fram inom ramen för nationella projekt ska
mappas mot VIT-bokens typfall. Om inget typfall stämmer, eller om nya tjänster eller
komponenter identifieras, ska detta kommuniceras ut till det pågående arbetet med teknisk
arkitektur. För att underlätta följsamhet mot den nationella arkitekturen finns mallar
framtagna för beskrivning av arkitektur och tjänster som ska användas av de nationella
projekten. Exempel på mallar som finns angivna i VIT-bokens lista med anvisningar är:
• Anvisningar arkitekturdokumentation
• Anvisningar tjänstedokumentation
• Anvisning systemdokumentation

ANVISNING - 14 (87)
2007-12-20 REV A
2.5 Styrande principer 9
Följande grundläggande principer är styrande för den nationella arkitekturen och innefattar
både verksamhet, informationsstruktur och teknik. De styrande principerna är långsiktiga och
styrande för utvecklingen av arkitekturen redan idag. De skall användas som vägledning för
pågående och kommande nationella projekt samt förvaltningsobjekt.
Patientfokus
Verksamheten och lösningar ska utformas med invånare i fokus och invånaren 10 ska ses
som samverkande part.
Arkitekturen ska medge möten/vårdkontakter med invånare där flera vårdgivare samtidigt
har en vårdrelation.
Arkitekturen ska stödja invånares hälsoärenden i sammanhängande vårdkedjor där flera
vårdgivare kan vara involverade.
Patienten ska ges möjlighet till flera kontaktvägar med vård och omsorg där det är möjligt
eller önskvärt.
Arkitekturen ska medge att vården organiseras på ett sådant sätt som är optimalt för
patienten.
Tillit, säkerhet och integritet
Arkitekturen ska medge en hög säkerhet i all informationshantering och säkerställa
integriteten för den enskilde invånaren.
Arkitekturen ska bygga på samverkan som baseras på avtal och formella
överenskommelser.
Lösningar och tillämpningar som baseras på arkitekturen ska vara feltoleranta och kunna
fortsätta att fungera även om vissa vårdgivare inte är tillgängliga. Användare ska göras
medveten om avvikelser så att rätt åtgärd kan vidtas.
Arkitekturen ska medge en robust realisering som kan hantera både förutsedda och
oförutsedda händelser som potentiellt kan orsaka skada eller avbrott i vård och omsorg.
Verksamhetsdriven
Arkitekturen ska utgå från verksamhetens mål, behov och krav samt vara följsam mot
lagar och föreskrifter som t.ex. patientdatalagen.
Arkitekturen ska stödja de olika vårdgivarnas processer 11 som kan skilja sig åt.
Arkitekturen ska omfatta samverkan med andra myndigheter och organisationer än
vårdgivare som t.ex. försäkringskassan och apotek samt stödja samverkande processer 12
över vårdgivargränser.
9
Dessa styrande principer är antaganden idag som kan komma att förändras när verksamheten tydligör sina
behov.
10
Patienter, anhöriga, kunder, invånare
11
Processer för vård & omsorg, administration, ledning & styrning samt uppföljning & utvärdering.
12
Se föregående fotnot.

ANVISNING - 15 (87)
2007-12-20 REV A
Subsidiaritet
Arkitekturen ska vara oberoende av hur verksamheten organiserar sig och medge olika
organisationsformer lokalt och regionalt.
Arkitekturen ska medge subsidiaritet, det vill säga lokal beslutsrätt och att beslut fattas så
nära medborgarna som möjligt.
Arkitekturen ska utgå från att varje vård- och omsorgsenhet ansvarar för sin egen vårdoch
omsorgsinformation.
Arkitekturen ska medge att vårdgivare med olika förutsättningar utvecklas i olika takt.
Arkitekturen ska därför baseras på utgångspunkten att samverkan sker i en heterogen
miljö.
Följsamhet mot en föränderlig verksamhet
Arkitekturen ska tillåta att verksamhetens organisation och processer förändras.
Arkitekturen ska baseras på samverkan som förutsätter minimal kunskap och varandras
processer och IT-stöd.
Arkitekturen ska vara skalbar som medger att nya vårdgivare och aktörer ansluts och
samverkar med varandra samt att volymen av samverkan ökar.
Arkitekturen ska vara flexibel så att nya nationella tjänster och tillämpningar kan lanseras
och användas utan att alla vårdgivare samtidigt måste förändra sitt eget IT-stöd.
Arkitekturen ska vara geografiskt oberoende.
Ekonomi och skalfördelar
Gemensamma lösningar ska prioriteras framför egna unika lösningar. Det ska finnas
endast en gemensam lösning för ett visst gemensamt behov.
Arkitekturen ska medge att gemensamma resurser kan utnyttjas.
Arkitekturen ska balansera krav på leverantörsoberoende med krav på kostnadseffektiv
upphandling av tjänster och IT-stöd. Arkitekturen ska vara leverantörsoberoende.
Arkitekturen ska bidra till att minska kostnaderna för administration och förvaltning av
organisationsstrukturer, gemensam infrastruktur och delade tjänster.
Arkitekturen ska reducera leverantörernas kostnader för att ansluta sina tjänster/produkter
till den nationella infrastrukturen.
Arkitekturen ska stödja gemensam upphandling av lokala, regionala och nationella
lösningar med hjälp av gemensamma specifikationer.

ANVISNING - 16 (87)
2007-12-20 REV A
2.6 Samverkan
Fokus i detta avsnitt för den nationella arkitekturen betonar samverkan mellan vårdgivare,
dvs. behovet av att kunna komma åt och förmedla information som behövs i en specifik
vårdsituation. En vårdgivare är statlig myndighet, landsting och kommun i fråga om sådan
hälso- och sjukvårdsverksamhet som myndigheten, landstinget eller kommunen har ansvar för
(offentlig vårdgivare) samt annan juridisk person eller enskild näringsidkare som bedriver
hälso- och sjukvårdsverksamhet (privat vårdgivare) 13 . Även offentliga (stat, landsting,
kommun) och privata omsorgsgivare inkluderas som samverkande parter i denna nationella
arkitektur.
Samverkan innebär att dessa vårdgivare samverkar med varandra 14 , med individen, med andra
intressenter i Sverige och inom EU. Dessutom kan det finnas olika regionala och nationella
kvalitetsregister och biobanker som behöriga ska kunna komma åt.
Samverkan sker i en vårdprocess, patientadministrativ process eller annan verksamhetsprocess
där vårdgivare och andra aktörer samverkar för att kunna möta kundens och
uppdragsgivarens behov. Vilka som samverkar bestäms av den specifika vårdsituationen,
individens historik, behov av koordinering mellan vårdgivare samt av krav på förbättringar.
Landsting A
Offentlig vårdgivare
enhet
Vårdenhet
Vårdenhet
Vårdenhet
Kvalitetsregister
INDIVID
Medborgare
Brukare
Patient
Kund
Kommun X
Offentlig vårdgivare
Vårdenhet
Kommun Y
Offentlig vårdgivare
Kvalitets
-register
Andra samverkande
parter i Sverige
Socialstyrelsen och
andra
tillsynsmyndigheter
Vårdenhet
Privat
Vårdgivare
Vårdenhet
Försäkringskassan
Samtycke
eller spärr
Vård- och omsorg Sverige
(nätverk av potentiellt samverkande aktörer)
Vårdenhet
Kvalitetsregister
Sammanhållen journal
Sammanhållen patientadm
Kunskapsstöd
…
Vårdenhet
Skatteverket
Folkbokföringen
Andra myndigheter
Landsting B
Offentlig vårdgivare
Vårdenhet
Biobank
Kommunal tillsyn
Huvudmän
Åtkomst
Vårdenhet
Vårdenhet
Figur 5 - Vård- och omsorg i Sverige
Landsting C
Offentlig vårdgivare
Vårdenhet
Vård- och omsorg
annat EU-land
(INTE MED I
DENNA OMGÅNG)
Vård- och
omsorgspersonal
Vårdenhet
Vårdenhet
Biobank
Vårdenhet
Vårdgivare - EU
Privat
vårdgivare
Vårdenhet
Vårdenhet
Kvalitetsregister
Vårdenhet
Samverkan kan ske i en specifik vårdsituation (hälsoärende). Samverkan behöver inte betyda
att den behandlande vårdpersonalen bara har tillgång till endast den behandlade patientens
journal. I vissa fall är det nödvändigt med tillgång till andra journaler och erfarenhetsbanker
13 Socialstyrelsens termbank
14 Strukturell samverkan mellan vårdgivare och samverkan mellan vård- och omsorgspersonal

ANVISNING - 17 (87)
2007-12-20 REV A
för att kunna ge bästa möjliga vård. Samverkan omfattar samtycke och vårdrelation vid
sammanhållen journalföring.
Det finns olika domäner 15 för samverkan – från den nationella domänen, via gemenskapsdomäner
till lokala domäner enligt följande:
Den nationella domänen omfattar hela Sverige
Gemenskapsdomäner som kan omfatta regioner, landsting, kommuner och privata
vårdgivare som kan organisera sig i olika gemenskaper
Vårdgivardomäner som omfattar enskilda vårdgivare och vårdenheter.
Samverkan behöver inte vara avgränsad till att dela journalinformation – administrativ
patientinformation, kunskapsstöd, kvalitetsregister, biobanker, uppföljning & utvärdering är
andra möjliga områden för samverkan. Grupper av vårdgivare kan välja att skapa
gemenskaper för att lättare kunna möta individernas behov och för att kunna möta krav på
högre produktivitet (mer vård per krona). Samverkan ska ses ur ett helhetsperspektiv.
Figur 6 - Samverkan mellan vårdgivare
Samverkan sker med hjälp av publika tjänster 16 som respektive aktör tillhandahåller. I Sverige
finns olika aktörer som är informationsägare av den journalinformation som de producerar.
Denna information får endast delas med andra under speciella förutsättningar och ska i övrigt
förvaras på ett betryggande sätt utan möjlighet för åtkomst av obehöriga. Samverkan mellan
aktörer, i de fall samverkan existerar, sker i dagsläget inte på ett enhetligt sätt. Det måste
finnas ett gemensamt regelverk för att samverkan ska ske på ett enhetligt sätt.
2.6.1. Samverkan för informationsutbyte
Det finns ett mycket stort antal vårdgivare som skulle behöva samverka med varandra
utgående från invånares och patienters specifika behov i varje vårdsituation. Vårdgivare i
15 Observara att indelningen i domäner inte behöver vara geografiskt bunden.
16 Avtalade och certifierade

ANVISNING - 18 (87)
2007-12-20 REV A
Sverige kan liknas vid ett stort nätverk där alla vid ett eller annat tillfälle kan ha behov av att
samverka med varandra. För att det ska vara möjligt måste dessa vårdgivare följa regler,
riktlinjer och rekommendationer för samverkan. Vårdgivare i Sverige måste vara
interoperabla!
Samverkan sker alltid genom att utbyta information med relevanta tjänster i en specifik
vårdsituation där patienten kan vara med eller inte. Samverkan kan alltså brytas ner i de
minsta ingående beståndsdelarna som består av tjänsteinteraktioner mellan initiativtagare och
utförare.
OBS detta betyder INTE att alla vårdgivare måste integreras i en ”punkt-till-punkt” lösning.
Tvärtom ska integration ske via en gemensam lösning som gör det möjligt att löst integrera
vårdgivare med varandra med lösa kopplingar. Se figur nedan:
Figur 7 – Samverkan ”punkt-till-punkt” eller samverkan med gemensam förmedling
Denna typ av lösning har använts för samverkan inom offentlig förvaltning i enskilda EU
länder 17 . Fördelarna med denna utformning är många, bland annat medger utformningen att:
• olika vårdgivare ansluter sig till den gemensamma infrastrukturen i olika takt allt efter
vad budget och förmåga medger,
• det är möjligt att ansluta gemensamma delade resurser till samma infrastruktur,
exempelvis kvalitetsregister,
• det är möjligt att ansluta olika webbportaler och gemensamma kundtjänster till den
gemensamma infrastrukturen och
• alla tjänster – såväl lokalt som centralt realiserade - som har del i nationell
samverkan, exponeras i den nationella tjänsteplattformen. Detta leder till att
organisatoriska och systemmässiga förändringar hos samverkande parter endast
påverkar tjänsteplattformen.
2.6.2. Förutsättningar för samverkan
17
Även i eGovernment satsningar utanför EU används denna typ av lösning för samverkan mellan olika
organisationer inom offentlig förvaltning.

ANVISNING - 19 (87)
2007-12-20 REV A
För att olika parter inom vård och omsorg ska kunna samverka med varandra måste olika
förutsättningar vara på plats. Dessa förutsättningar är inte bara tekniska.
Nedanstående figur visar på vilka förutsättningar som måste finnas. Om någon av dessa inte
finns så fungerar inte samverkan!
Gemensam målbild och behovsanalys
utgående från kundens / patientens /
medborgarens, uppdragsgivares och
samhällets behov och önskemål.
Styr och påverkar
Nationell
IT-strategi
Patientdatalag
Riksdag Regering Vårdgivare
STYRANDE
Kommun
Legal interoperabilitet
Process / organisation interoperabilitet
Semantisk interoperabilitet
Teknisk interoperabilitet
EU
VIT Boken
Figur 8 - Interoperabilitet 18
Ytterst drivs krav på samverkan från behovet hos invånare, patienter, vård- och
omsorgspersonal. Politiker, ägare och huvudmän kan via olika regleringar ge villkoren för hur
samverkan får bedrivas. Intresseorganisationer och enskilda vårdgivare är också väsentliga
intressenter för att ge rätta förutsättningar för samverkan inte minst genom normering och
utveckling av samverkan mellan verksamheter. De legala förutsättningarna (legal
interoperabilitet) måste finnas för att kunna samverka. Den nya patientdatalagen ger
förändrade förutsättningar.
Den enskilt viktigaste faktorn är ändå att dessa olika intressenter måste sätta medborgarnas
och patienternas bästa (hälsa, kvalitet, säkerhet, service) i fokus. Verksamheterna måste
utveckla vårdprocesser, prioriteringar i vården 19 och organisering av vården för att reflektera
detta fokus. Förutsättningen för detta är strukturell samverkan där vårdgivare kommer överens
om hur samverkan ska ske för att tillsammans kunna erbjuda God Vård (process/organisations
interoperabilitet).
De olika vårdgivarna och vård- och omsorgspersonal måste ha gemensamma termer för
samma begrepp och överenskomna strukturer för information för att kunna samverka i vården
och för att kunna följa upp och utveckla verksamheten. Förutsättningen för detta är strukturell
samverkan där vårdgivare kommer överens om informationsstrukturerna i vård- och omsorg
(semantisk interoperabilitet).
För att vård- och omsorgspersonal inom olika vårdgivare effektivt ska kunna samverka
behövs i flera fall ett ändamålsenligt IT-stöd. Detta innebär att de olika vårdgivarnas IT-stöd
måste kunna samverka med varandra. Detta kräver standarder och gemensamma
18 Fritt från EU:s initiativ EIF – European Interoperability Framework http://ec.europa.eu/idabc/en/chapter/5883
19 Vård per krona och hälsa per krona
V
I
T

ANVISNING - 20 (87)
2007-12-20 REV A
överenskommelser i form av regler, riktlinjer och rekommendationer. Förutsättningen för
detta är gemensam utveckling och förvaltning av gemensamma IT-lösningar och infrastruktur
baserat på överenskomna standarder (teknisk interoperabilitet).
Observera att samverkan enligt ovanstående har olika typer av förutsättningar – från legala
aspekter till tekniska aspekter. Det går inte att ignorera någon aspekt av interoperabilitet.
Tillsammans utgör alla aspekter en helhet – vilket innebär att när man fokuserar på ett
element av arkitekturen exempelvis tekniken så ser man till dess plats i helheten!

3 Referensarkitektur
ANVISNING - 21 (87)
2007-12-20 REV A
3.1 Bakgrund och syfte
Referensarkitekturen syftar till att beskriva principerna för uppbyggnaden av den nationella
arkitekturen. En referensarkitektur kan ses som en mall för arkitektur. Referensarkitekturen
utgör en principiell design som uppfyller en uppsättning prioriterade krav som anses
tillräckligt allmängiltiga för att hanteras av en tillämpningsoberoende ansats. Mallen ska
underlätta för projekt att leverera IT-tjänster som uppfyller dessa krav på ett förutsägbart sätt.
Referensarkitekturen förväntas vidare etablera en begreppsapparat som stimulerar tydlig och
effektiv kommunikation mellan arkitekturens intressenter.
En referensarkitektur medför i sin tur krav på tekniska komponenter, för att kunna realiseras
på ett rationellt och kvalitativt sätt.
3.2 Principer för den tekniska arkitekturen från verksamhetsperspektiv
§1 De styrande principerna är styrande för den tekniska arkitekturen
De styrande principerna avsnitt 2.5 sida 14 för den nationella arkitekturen anger gränserna för
hur den tekniska arkitekturen kan utformas. Detta avsnitt beskriver de styrande principernas
konsekvenser för teknisk arkitektur.
3.2.1. Patientfokus
Ökat patientfokus ställer krav på en för patienten transparent vårdprocess. Det kan innebära
att patienten i vissa skeden tar en aktiv del i vårdprocessen och alltid ska ha möjlighet att få
information om sin process. Vårdgivarna kommer att vara beroende av interna processer med
internt IT-stöd för sin verksamhet. Arkitekturens huvudutmaning med avseende på
Patientfokus består i att skapa förutsättningar att integrera vårdgivare inom svensk vård och
omsorg i en ur patientperspektivet sammanhållen vård- och omsorgsprocess. En nationell
arkitektur bör därför utgå ifrån en vision om nationell vård- och omsorgsprocess, understödd
av ett nationellt IT-stöd – delvis verkligt – delvis virtuellt. På så vis integreras patienten, såväl
som samverkande vårdgivare i en nationell IT-infrastruktur vars uppgift är att orkestrera den
sammanhållna vårdprocessen.
3.2.2. Tillit, säkerhet och integritet
Säkerhetstänkande är grunden för förtroende och tillit från patienter och vårdpersonal.
Informationssäkerhet innebär att säkerställa:
• Sekretess - att endast behöriga personer tar del av personuppgifter
• Informationskvaliteten - att informationen så långt möjligt är korrekt från början och
att den är oförvanskad (varken medvetna eller omedvetna förändringar)
• Tillgängligheten - att systemet fungerar och ger svar inom den tid som krävs
• Spårbarheten - att man kan följa vem som gjort vad, när och varför
BIFs tjänster för åtkomstkontroll utgör grunden för att säkerställa sekretess och spårbarhet i
en sammanhållen vård- och omsorgsprocess. Endast genom konsekvent tillämpning av BIF,
skapas förutsättningar för följsamhet mot patientdatalagen.

ANVISNING - 22 (87)
2007-12-20 REV A
Men för att åtnjuta tillit krävs också tillgänglighet med tillförlitlighet samt att man kan
garantera informationskvaliteten. 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 för användaren. En patientöversikt med dålig prestanda genom beroende av
anslutningar som ibland inte svarar inom utsatt tid inger inte tillit. En patientöversikt som
alltid svarar inom utsatt tid med information från samtliga kända källor som håller
journaluppgifter för sökt patient, har en större upplevd tillgänglighet. Men för att upplevas
som tillförlitlig behöver också avvikelser från utfäst kvalité redovisas.
Arkitekturen måste byggas på antagandet om att tillförlitlighet är omvänt proportionell mot
det sammanlagda antalet förbindelser mellan det totala antalet samverkande parter. Vidare
behöver arkitekturen utgå ifrån etablerade tekniker för hög tillgänglighet, så som cachening
(inkluderande replikering) och redundans.
3.2.3. Verksamhetsdriven
Helhet
Utgångspunkten för arkitekturen är en helhet där de tre perspektiven Verksamhet,
Informationsstruktur och Teknik utgör en sammanhållen arkitektur. Den föreslagna
arkitekturen ger stor frihetsgrad för hur vård- och omsorg väljer att organisera sig på nationell,
regional eller lokal nivå. Arkitekturen är också neutral i förhållande till verksamhetens vårdoch
omsorgsprocesser. Vidare baseras föreslagen teknisk arkitektur på typfall, utifrån
användningsfall, som reflekterar verklig samverkan mellan vårdgivare.
Följsamhet mot patientdatalagen
Följsamhet mot patientdatalagen ska åstadkommas genom tillämpning av BIF, SITHS och
HSA. För följsamhet mot patientdatalagen behövs ett stort lokalt arbete med anpassningar av
lokala systemen. Att följsamhet mot patientdatalagen sker på lokal nivå är en förutsättning för
arkitekturen. Konsekvenser av patientdatalagens förslag på nationell arkitektur finns
beskrivna i ett separat dokument.
Följsamhet mot den Nationella IT-strategin
Följsamheten mot den nationella IT-strategin åstadkoms genom att arkitekturens främsta
egenskap är säker samverkan för säkert informationsutbyte och förmågan att dela nationella,
regionala och lokala tjänster, se Bilaga 5 – Målnedbrytning av Nationell IT-strategi för Vård
och Omsorg.
3.2.4. Subsidiaritet
Varje vårdenhet ansvar för och har kontroll över sina data
BIF åtkomstkontroll tillämpas för att vidmakthålla varje vårdenhet ansvar för sina data. I den
mån data lagras i gemensam tjänst som delas av flera vårdgivare, tillämpas BIF ÅKT för att
skapa ansvarsmässiga barriärer i enlighet med patientdatalagens intentioner.
3.2.5. Följsamhet mot en föränderlig verksamhet
Skalbarhet
Nationella tjänster ska ha skalbarhet för användning av samtliga potentiella användare i
Sverige. Detta leder till speciellt stora krav för tjänster som direkt betjänar invånare.
Arkitekturen behöver därför utgå ifrån att merparten av etablerade teknologier för skalbarhet

ANVISNING - 23 (87)
2007-12-20 REV A
kommer att användas. Detta omfattar bl.a. replikering, cachening och klustring. Vidare finns
för vissa nationella projekt krav på upplevd hög tillgänglighet under en stor del av dygnets
timmar. De skalbarhetsteknologier som är transparenta för tjänsterna förväntas kunna styras
via SLA och är därför inte behandlade här. Cachening och replikering har identifierats som
värdefulla ansatser med inverkan på arkitekturen. Deras tillämpbarhet måste bedömas från fall
till fall, genom att utvärdera följande egenskaper:
a) förhållandet mellan förändring av information och frågefrekvensen mot den samma
b) tillgänglighetskraven i förhållande till aktualitetskraven.
Tjänsteorienterad arkitektur
Arkitekturen ska vila på principer förknippade med begreppet SOA – Service-Oriented
Architecture (Tjänsteorienterad arkitektur på svenska). Grunden för SOA läggs i det sätt på
vilket aktiviteter i V- och I-delen leder fram till nationellt standardiserade samverkanstjänster
baserade på processer för samverkan. Samverkansprocesser bryts ned i av parterna ömsesidigt
erbjudna tjänstekontrakt. En process definieras av en sekvens av meddelandeutbyten i
enlighet med dessa tjänstekontrakt. Arkitekturen ska möjliggöra en realisering med
meddelandeutbyten i interaktionerna mellan samverkande parter. Genom att realiseringen av
samverkan är baserad på abstrakta kontrakt, utan antagande om vilket system hos den andra
parten som är en konkreta mottagaren, skapas förutsättningar för att minimera antalet
kopplingar mellan samverkande system.
Den tekniska realiseringen förväntas variera över tiden. Aktuell standard återfinns i RIV
tekniska anvisningar.
Administration av systemförändringar ska vara minimal
Samverkan över vårdgivargränser förutsätter samverkan mellan vårdgivares lokala system,
eller säkerhetsmässigt komplett anslutning till nationella tillämpningar. Arkitekturen ska
minimera eventuella dominoeffekter av förändringar i systemen hos en samverkande part och
i nationella tjänster. Arkitekturen ska i detta avseende ta hänsyn till att det för enskilda ITtjänster
kan skapas grupper av vårdgivare som delar infrastruktur så väl som IT-lösningar och
att dessa grupper kan förändras över tiden.
Meddelandeformat
Följsamhet mot nationellt fastställda tjänstekontrakt är en viktig förutsättning för att
undvika dominoeffekt av förändringar som annars riskeras. De nationella RIVbaserade
formaten ska i sina xml-scheman införliva konstruktioner för
utökningsbarhet. Utökning genom dessa konstruktioner ska kunna ske utan påverkan
på konsumenter eller producenter som förlitar sig på grundformatet., så länge inte
bruten bakåtkompatibilitet uttryckligen angivits enligt överenskommen standard.
Anslutningspunkter
Arkitekturen ska minska dominoeffekten av systemförändringar, genom att erbjuda en
nationell lösning för lös koppling (jfr SOA/W3C ”intermediary”). På så sätt kan
förändringar i anslutningspunkter hos en vårdgivare isoleras från övriga parter i
arkitekturen.
Administration av organisationsförändringar ska vara minimal
Arkitekturen ska minimera effekten av omorganisationer inom vård och omsorg, som ett led i
att maximera tillgängligheten hos nationellt realiserade tjänster. En rimlig målsättning är att
isolera behovet av förändringar till de organisationer som deltar i omorganisationen.

ANVISNING - 24 (87)
2007-12-20 REV A
Organisationsförändring kan avse sammanslagningar och andra omstruktureringar vårdgivare
emellan. Det kan också avse organisationers tillträde och utträde i/ur nationell samverkan –
t.ex. sammanhållen patientjournal.
Organisationsoberoende informationsmodell
För att undvika behovet av infrastrukturella ingrepp vid anslutning av en ny
vårdgivare eller vårdenhet till en nationell IT-tjänst, ska tjänstens databas – i den mån
den lagrar strukturerad data – vara modellerad med nationell användning i åtanke.
Varje databas ska om så önskas, logiskt kunna husera landets samtliga vårdgivare. Vid
tjänst som upphandlas i form av utvecklingsentreprenad, skapas förutsättningarna för
framtagningen av V-TIM (Verksamhetens Tillämpade InformationsModell).
IT-tjänster kan till sin funktionella karaktär vara till för att stödja processer som saknar
samverkansvärde eller där ickefunktionella krav förutsätter lokal installation. Även om
dessa fall handlar mer om strukturell samverkan än vårdsamverkan, kan teknik,
processer och affärsmodeller förändras, varför principen för organisationsoberoende
bör gälla generellt. Dessa principer gäller även meddelandeformat som definierar
kontrakt för kommunikation mellan IT-tjänster. Metadata eller URL:er får inte vara
det som logiskt preciserar organisatorisk adressering. Eventuell organisatorisk
adressering ska entydigt framgå eller kunna härledas ur den av V-TIM definierade
strukturen.
3.2.6. Ekonomi och skalfördelar
Leverantörsobroende
Leverantörsoberoende gynnas av enhetlighet i tjänsternas interna arkitektur,
utvecklingsmodeller, tekniker och verktyg, då detta ger lågt beroende till leverantörsspecifika
val av designprinciper. Hög grad av testautomation genom utvecklingscykelns alla faser,
underlättar övertagande mellan leverantörer, så väl som ”hemtagande” av utveckling.
Enhetliga processer för konfigurationsstyrning och ändringshantering tvärs alla
tjänsteleverantörer kan ge stora skalfördelar hos förvaltningsorganisationer.
Minimera kostnad vid ändringar i arkitekturen
Krav på att ändring av transportprotokoll för meddelanden ska ge efterverkning på maximalt
en komponent i leverantörens lösning. Det möjliggör för leverantörer att redan i
upphandlingssituation redovisa kostnader för denna ändring. Arkitekturen ska minimera
antalet tekniska anslutningspunkter för upphandlad lösning i syfte att minimera
komplexitet/kostnad för lösningens utveckling och förvaltning.
Minimera leverantörernas kostnad för anslutning till arkitekturen
Referensarkitekturen ska bidra till att minska leverantörernas kostnad för att ansluta sig till
arkitekturen. VIT-boken bidrar med att underlätta förståelse för olika tjänsters roll i den
nationella samverkan, såsom t.ex. BIF-tjänsternas roll.
Gemensam upphandling av lokala lösningar
Arkitekturen ska ta hänsyn till att det för enskilda IT-tjänster kan skapas för grupper av
vårdgivare som delar infrastruktur och IT-lösningar och att dessa grupper kan förändras över
tiden. Inte alla nationellt upphandlad tjänster har samverkan i vårdprocessen som syfte.
Delade upphandlingar i syfte att nå ekonomiska skalfördelar mellan vårdgivare, ställer krav på
arkitekturen, då den blir möjliggörare för delning av infrastruktur och tjänster för IT-drift.

ANVISNING - 25 (87)
2007-12-20 REV A
Upprätthåll trovärdig förmåga att byta leverantör av plattform
Upphandlade tjänster behöver driftsättas på mellanvara av typen applikationsservers. Att
upphandla mot standarder istället för produkter, understödjer upphandlingsekonomi gentemot
leverantörerna. Det underlättar också för småskaliga vårdgivare att få ekonomi genom tillgång
till lösningar baserade på öppen källkod.

ANVISNING - 26 (87)
2007-12-20 REV A
3.3 Tillämpning av referensarkitekturen
§2 Referensarkitekturen är målbilden som anger inriktningen för den nationella
tekniska arkitekturen
Den beskrivna referensarkitekturen utgör en målbild som kommer att realiseras etappvis över
de kommande åren. Plan och steg för att realisera målbilden beskrivs inte i denna rapport.
Referensarkitekturen anger den tekniska riktningen för utvecklingen av det nationella ITstödet.
Denna rapport anger inte heller teknisk realisering av referensarkitekturen i form av
produkter eller val av specifika teknologier.
Däremot slår den tekniska arkitekturen fast vilka gemensamma principer och komponenter
som ska användas. Dessa är BIF, RIV, SITHS; HSA och Sjunet. De övriga lösningarna och
komponenter som behövs för att realisera målbilden kommer att utvecklas över tiden.
Utgångspunkten idag är därför att praktiska implementationer som ska realiseras inom närtid
utgår från BIF, RIV, SITHS, HSA och Sjunet.
3.4 Översikt referensarkitektur
§3 All nationell samverkan sker via nationella tjänster. Punkt-till-punk samverkan
ska inte användas.
Detta avsnitt ger en konceptuell beskrivning av en referensarkitektur som uppfyller
principerna för en teknisk arkitektur. Referensarkitekturen är en normerande mall för
nationella projekt och vårdgivare som avser samverka i den nationella arkitekturen.
De uppställda principerna är sprungna ur en vision om att skapa en vårdprocess med patienten
i fokus. För att nå visionen behöver Sveriges vårdgivare uppträda som en virtuell fullständigt
integrerad vårdorganisation. I en sådan organisation är alla processer är gemensamma och
utförs med stöd av en homogen tjänsteorienterad arkitektur med en lösning för varje funktion.
Följande symboler används för att definiera referensarkitekturen:
Aktivitet i vårdprocess
IT-stöd för hantering av källdata
Virtuellt IT-stöd som beror av samverkan med operationellt IT-stöd
Vårdgivare
Tjänstegemenskap – gruppering av vårdgivare som konsoliderat
delar av lokalt operationellt IT-stöd för specifik verksamhet

ANVISNING - 27 (87)
2007-12-20 REV A
Nedanstående bild illustrerar detta idealiserade framtida tillstånd.
Vårdgivare
Nationella vårdprocesser
Figur 9 - Vision för IT-stödet
Brukare
Patient
Kund
Nationellt IT‐stöd
I denna vision är allt IT-stöd samordnat på nationell nivå i form av en SOA och därmed
tillgängligt för samtliga vårdgivare enligt modellen "Mjukvara som en tjänst".
Omorganisationer är transparenta för vårdprocessen. Alla vårdenheter ansluter sig till det ITstöd
som behövs för verksamheten utgående ifrån nationellt upphandlade erbjudanden
tillgängliggjorda som tjänster. Organisatoriska förändringar reflekteras automatiskt i alla
tjänster efter uppdatering av nationell organisationsmodell. All information är tidsbunden
vilket gör att ägarskap av journaldata alltid kan härledas. Referensarkitekturen skapar
förutsättning för strukturell samverkan där flera vårdgivare kan utveckla och förvalta
gemensamma specifikationer.
Denna idealiserade vision står i stark kontrast till dagens organisationsbundna processer,
heterogena IT-stöd och informationsstrukturer. Att erbjuda brukare och patienter
sammanhängande hälsoärenden med obrutna vårdkedjor är idag nästan omöjliga att realisera.
Någonting nytt behövs.

ANVISNING - 28 (87)
2007-12-20 REV A
Vårdgivare med lokala processer och lokalt IT-stöd
Brukare
Patient
Kund
Figur 10 - Dagens situation för IT-stödet
Punkt-till-punkt samverkan utan hänsynstagande till tidigare beskrivna principer, leder till
kostsamma och svårföränderliga samverkansmönster med otydlig riktning med avseende på
visionen om patienten i centrum. Om dagens rådande inriktning med punkt-till-punkt
kopplingar får råda även i framtiden kommer komplexitet och därmed kostnader att eskalera.
Följande bild illustrerar samverkan baserad på punkt-till-punkt integration.
Figur 11 - Punkt-till-punkt samverkan

ANVISNING - 29 (87)
2007-12-20 REV A
Punkt-till-punkt integration står i konflikt med merparten av de styrande principerna. För att
nå målen uppställda i den nationella IT-strategin för vård och omsorg, behöver visionen
konkretiseras i en arkitektur som tar sin utgångspunkt i existerande förutsättningar. IT-stödet
kommer under överskådlig framtid att vara lokalt. Punkt-till-punkt integration mellan
vårdgivare undviks genom att samverkan sker via ett upplevt nationell IT-stöd. Enskilda
vårdgivare tillgängliggör information och funktion i lokala system till det nationella IT-stödet,
så som NPÖ, NOD och VpW. Lokala såväl som nationella vårdprocesser kan därmed använda
det nationella IT-stödet, trots att detta i egentlig bemärkelse enbart gör lokala resurser
tillgängliga.
Vårdgivare
Nationella vårdprocesser inom strategiska områden
Virtuellt Nationellt IT‐stöd
Figur 12 - Nationella vårdprocesser och IT-stöd
Detta möjliggör gradvis övergång från samverkan till fullständig integration. Vårdgivare, eller
enheter inom vårdgivare går över tiden samman i gemenskaper 20 , i syfte att konsolidera lokala
IT-stöd till gemensamma och nationella IT-stöd. Ett nationellt IT-stöd kan inte förutsätta en
nationell installation med en delad databas. Gemensamma lösningar uppstår kring IT-tjänster,
som ersätter motsvarande lokalt IT-stöd hos medverkande vårdgivare. Arkitekturen behöver
därmed hantera flera förekomster av samma tjänst.
20 Synsättet med gemenskaper som uppstår ur specifika behov för att sen växa till en nationall gemenskap
motsvaras av hur Internet växte ur lokala nätverk för att sen bli sammanslutning av flera lokala nätver för att
slutligen bli Internet - en gemenskap av nätverk.

Vårdgivare
ANVISNING - 30 (87)
2007-12-20 REV A
NPÖ
JT = Journaltjänst, BS = Beställning och svarstjänst, TB = Tidbok
Virtuellt Nationellt IT‐stöd
NOD
Nationellt upphandlat IT‐stöd i tjänstegemenskaper
Figur 13 - Samverkan mellan vårdgivares IT-stöd och nationellt IT-stöd
Exemplet ovan utgår ifrån att kvarvarande lokalt IT-stöd behöver samverka med de
konsoliderade tjänsterna. De konsoliderade tjänsterna samverkar med de nationella tjänsterna
där antalet integrationer mellan lokalt IT-stöd och nationella tjänster minskar i takt med ökad
konsolideringsgrad. Tjänster i en gemenskap kommunicerar inte direkt med andra
gemenskaper utan all kommunikation sker mot virtuellt nationellt IT-stöd.
3.4.1. Samverkansdomäner
§4 Samverkan sker inom och mellan samverkansdomäner. Den nationell arkitekturen
avser den nationella domänen och samverkan via den.
Arkitekturen kan ännu inte sägas uppfylla kraven på minimalt redigeringsarbete vid
förändringar i system och organisation. Antalet kopplingspunkter för samverkan är minskade i
förhållande till punkt-till-punkt integration, men det finns fortfarande en stor potential till
förbättring. Nedanstående bild delar in samverkan i domäner: Nationell domän,
gemenskapsdomäner och vårdgivardomäner.
JT
JT
TB
BS

Nationella
domänen
Gemenskapsdomäner
Vårdgivardomäner
ANVISNING - 31 (87)
2007-12-20 REV A
Figur 14 - Samverkansdomäner
Genom att betrakta domänerna som anslutningspunkter, i stället för de enskilda IT-tjänsterna,
kan antalet anslutningspunkter hållas på en nivå där förändringar kan isoleras till direkt
berörda parter. Det kommer att finnas lokalt IT-stöd hos vårdgivare under överskådlig
framtid. Detta behöver anslutas till nationell samverkan. I de fall en vårdgivare konsoliderat
delar av IT-stödet genom anslutning till en eller flera gemenskaper, finns sannolikt behov av
integration mellan konsoliderat IT-stöd och vårdgivares lokala IT-stöd. Gemenskapsdomäner
behöver anslutas till nationella domänen.
IT-tjänsterna inom en samverkansdomän ansluts till anslutningspunkt som tar ansvar för att
binda meddelandekontrakt till utförande IT-stöd. Denna anslutningspunkt benämns
fortsättningsvis tjänsteplattform. Tjänsteplattformen isolerar enskilda tjänster från att känna
till vilka domäner vilka IT-tjänster finns i, så väl som dessa tjänsters tekniska adress. Varje
IT-tjänst har därmed en hård koppling till de meddelandekontrakt den är beroende av, men en
lös koppling till IT-stödets struktur – såväl tekniskt som organisatoriskt. Resultatet är en
organisationsoberoende bindning mellan sändare och mottagare.
3.4.2. Tjänsteplattform
§5 Samverkan sker genom anslutning till en nationell tjänsteplattform. Anslutning
kräver att anslutande part och tjänster är certifierade.
Detta kan illustreras genom en liknelse med e-post-hantering. Avsändaren adresserar
mottagaren utan beroende till den infrastruktur som ska förmedla meddelandet. Adressen är
heller inte beroende av var mottagarens server befinner sig (jfr vårdgivarorganisation).
Avsändaren har en enda teknisk anslutningspunkt: ”utgående server”, vilket motsvaras av
domänens tjänsteplattform, som den enda kända anslutningspunkten. När brevet lämnats till
”utgående server”, som använder Internets infrastruktur för att hitta till den nationella
domänens ”utgående server”, som i sin tur hittar vidare till den ”service provider” som

ANVISNING - 32 (87)
2007-12-20 REV A
hanterar mottagarens e-postkonto. Detta motsvaras av tjänsteplattformen i den
samverkansdomän där vald IT-tjänst befinner sig.
För alla parter som deltar i samverkan ska parter och tjänster vara certifierade.
När nationell tjänst för sammanhållen journalföring behöver hämta vårddokumentation från
en journal ägd av en viss vårdenhet, behöver tjänsten bara känna till meddelandekontraktet för
att ställa denna fråga. Frågan ställs till tjänsteplattformen i den nationella domänen, som via
ett konfigurerat regelverk kan översätta HSA-id för utpekad vårdenhet till adressen för den
samverkansdomän som ansvarar för åtkomst av information – oavsett om detta är en
vårdgivardomän eller gemenskapsdomän:
Nationella
domänen
Gemenskapsdomäner
Vårdgivardomäner
Figur 15 - Tjänsteplattform
Tjänsteplattform
Följande sekvensdiagram beskriver schematiskt hur tjänsteplattformen bistår den nationella
tjänsten för sammanhållen journalföring att dirigera ett meddelande till en tjänst mot ett lokalt
journalsystem inom en vård givardomän:

Enhet = HAS‐id för
vårdenhet
Virtuell Tjänst: Hämta
Patientdata
Sammanhållen
journalföring
hämta patentdata (patientid, enhet)
ANVISNING - 33 (87)
2007-12-20 REV A
Nationell domän Vårdgivardomän
:patientdata
hitta verklig tjänst(enhet, meddelandekontrakt)
Tjänsteplattform
:adress till verklig tjänst
Vägvalstjänst Verklig tjänst: Hämta
Patientdatat
hämta patentdata (patientid, enhet)
:patientdata
Figur 16 – Sekvensdiagram – nationell tjänsteplattform
Idén om vägvalstjänsten bygger på följande konceptuella informationsmodell:
Meddelandekontrakt
- name: strng
*
Anslutningspunkt Samverkansdomän
Anslutning
- adress: stri ng
Vårdenhet
- hsaIdentitet: string
Figur 17 - Informationsmodell vägvalstjänst
*
*
*
*
Vårdgiv are
Meddelandekontrakt
= “hämta patientdata”
En omorganisation av eller en förändring av systemstödet hos en vårdgivare skulle innebära
uppdatering av information strukturerad enligt ovan. En tjänst för sammanhållen journalföring
som behöver nå informationen i den nationella domänen påverkas inte av förändringen.

ANVISNING - 34 (87)
2007-12-20 REV A
Om alla vårdgivare har en egen tjänsteplattform enligt ovan, behöver den nationella
vägvalsinformationen bara ändras vid organisatoriska förändringar – inte vid
systemförändringar inom vårdgivare. Följande sekvensdiagram visar interaktion då vårdgivare
lokalt har realiserat domänarkitekturen.
Nationell domän Vårdgivardomän
Sammanhållen
journalföring
Virtuell Tjänst:
Hämta
Patientdata
hämta patentdata (patientid, enhet)
hitta anslutningspunkt(enhet, meddelandekontrakt)
:patientdata
:adress till vårdgivarbuss
Vägvalstjänst Virtuell Tjänst: Hämta Vägvalstjänst Verklig tjänst: Hämta
Patientdata
Patientdata
hämta patentdata (patientid, enhet)
patientdata()
hitta anslutningspunkt(enhet, meddelandekontrakt)
:adress till verklig tjänst
hämta patentdata (patientid, enhet)
:patientdata
Meddelandebuss Tjänsteplattform Meddelandebuss
Tjänsteplattform
Figur 18 - Sekvensdiagram federerad tjänsteplattform

3.5 Domänarkitektur
ANVISNING - 35 (87)
2007-12-20 REV A
§6 Domänarkitekturen skall tillämpas för den nationella domänen.
Arkitekturen inom en samverkansdomän betecknas Domänarkitektur. I överensstämmelse
med uppdragsformuleringen för NARRR, ställs inte krav på en specifik domänarkitektur för
andra domäner än den nationella. En vårdgivare eller gemenskap som delar de vägledande
principer som har ställts upp för referensarkitekturen, kan sannolikt dra fördelar av att
implementera domänarkitekturen inom sin domän. Följande bild illustrerar schematiskt
samverkan mellan domäner som alla tillämpar domänarkitekturen:
Nationella
domänen
Gemenskapsdomäner
Vårdgivardomäner
3.6 Tjänsteorienterad arkitektur
Tjänsteplattform
Tjänsteplattform Tjänsteplattform
Figur 19 - Domänarkitektur
§7 Den nationella arkitekturen ska utgå från en tjänstebaserad arkitektur.
Tjänstekonsumenter ska vara bundna till publicerade tjänstekontrakt.
En domänarkitektur är uppbyggd enligt principerna för en tjänsteorienterad arkitektur – en
SOA. Referensarkitekturen grundas på principer från Carelink PLUS och 3R
Referensarkitekturer. Den nationella referensarkitekturen har utökats i syfte att tydliggöra en
strategi för lös koppling mellan gränssnitt och realisering baserad på en konceptuell
tjänsteplattform.
Service Oriented Architecture (SOA), dvs. tjänstebaserad arkitektur, har valts som
övergripande princip för arkitektur med tjänster i NARRR. En tjänstebaserad arkitektur kan
sammanfattas som en integration mellan system/komponenter där målet är skapa en så liten
grad av beroende mellan systemen som möjligt.

ANVISNING - 36 (87)
2007-12-20 REV A
Integration baseras på att system efterfrågar funktionalitet från varandra enligt förutbestämda
tjänstekontrakt.
SOA är i sig inte tillräckligt för att beskriva hur integrationer hanteras, utan avser endast en
grundläggande struktur och grundläggande principer. SOA avgör inte heller vilken teknisk
plattform som används för realisering.
3.6.1. Tjänstekontrakt
§8 Nationella tjänstekontrakt ska vara utformade enligt RIV.
§9 Meddelandeformat beskrivs enligt fastställda profiler för V-TIM.
En SOA i en samverkansdomän byggs upp av verksamhetslogik som tillgängliggörs enligt
RIV-standarden. Funktionalitet som görs tillgänglig anropas genom att meddelanden skickas
via nätverket över de protokoll som RIV anger. Meddelandet är definierat av ett
tjänstekontrakt. Ett tjänstekontrakt är en namngiven lista av operationer, där operationerna
kan vara av två typer: InUt och In:
Figur 20 - Notation för tjänstekontrakt
Meddelanden kopplas till operationer i form in- och utdata. Alla meddelandeformat i
arkitekturen är nationellt standardiserade.
Tjänstekontrakt
- namn: string
1..*
Operation
- namn: string
-/ ärInUt: boolean = ut-meddelande finns
+ut-meddelande
*
0..1 MeddelandeDefinition
1
*
- namn: string
Figur 21 - Referensmodell för tjänstekontrakt
+in-meddelande

ANVISNING - 37 (87)
2007-12-20 REV A
Utöver struktur och principer för SOA krävs ett antal regler som gör att den tjänstebaserade
arkitekturen kan realiseras i praktiken. Utöver det maskinläsbara kontraktet, enligt
specifikation i RIV tekniska anvisningar, krävs en beskrivning av tjänsten som utgör underlag
vid design.
Beskrivningen ska bland annat omfatta:
• Avgränsning till ett verksamhetsobjekt enligt V-TIM som stöder steg i verksamhetens
arbetsflöden och som är tillräckligt grovkornigt och generellt för att medge
återanvändning av flera tjänstekonsumenter
• Beskrivning av datavalideringar i tjänst. Detta gäller både de som kan ske mot schema
men även de logiska regler som upprätthålls av tjänst.
• Beskrivning av alla felsituationer och felsignaler.
• Beskrivning av säkerhetsmekanismer och åtkomstkontroll t.ex. vilka parametrar och
användarattribut som krävs för att utföra tjänst. Dessa måste följa BIF-ER Ingår i det
som paketeras i SAML-biljett enligt RIV tekniska anvisningar
• Beskrivning av servicenivåer hos tjänsteproducenten avseende tillgänglighet,
prestanda och andra icke-funktionella egenskaper
Utöver det maskinläsbara kontraktet krävs en överenskommelse mellan den organisation som
konsumerar tjänsten och den organisation som producerar tjänsten.
Överenskommelsen bör omfatta bland annat:
• Tjänstekonsumentens behov av icke-funktionella egenskaper
• Hantering av juridiska frågor i samband med tillgång till data
• Kontaktvägar till parternas förvaltningsorganisationer
• Information om tekniska säkerhetsmekanismerna
• Information om hur åtkomstkontrollen och dess parametrar och regler hanteras
Tjänsteproducenterna skiktas i gränssnitt, verksamhetslogik och dataåtkomst. På så sätt kan
tjänsteproducentens tekniska gränssnitt och underliggande system bytas utan att hela
tjänsteproducenten behöver skrivas om. Skiktningen ger även stöd för rationell tillverkning av
inkapslade och sammansatt tjänsteproducenter.
Tjänsteproducentens ansvarar för:
• att säkerhet och åtkomst hanteras genom anrop av Åtkomstkontrollfunktionen enligt
specifikation i BIF
• att spårbarhet hanteras genom anrop av Loggfunktionen enligt specifikation i BIF
• att validering hanteras korrekt och att aktuellt kodverk användes vid denna validering.
• att versionshantering sker genom att utgångna versioner av tjänsteproducentens
gränssnitt hålls kvar i produktion, även efter produktionssättning av nya versioner.
Utgångna versioner kan på så sätt fasas ut under kontrollerade former
Tjänsteproducenternas gränssnitt mot tjänstekonsumenterna ska göras funktionellt orienterade
och vara väl definierade och produktoberoende. Detta innebär att olika lösnings- och
produktspecifika gränssnitt inte får förekomma i tjänstedefinitioner. Definition av tekniskt
gränssnitt ska följa RIV tekniska anvisningar. Definition av meddelandeformatet för
samverkanstjänster följer fastställda format enligt RIV. Meddelandeformat beskrivs enligt
fastställda profiler för V-TIM.

3.7 Tjänsteinteraktioner
ANVISNING - 38 (87)
2007-12-20 REV A
§10 Tjänstekontrakt skall vara definierade inom ramen för en tjänsteinteraktion.
En tjänsteinteraktion är ett eller ett par tjänstekontrakt som tillsammans beskriver en
konversation mellan två parter. En sekvens av tjänsteinteraktioner beskriver en
samverkansprocess, exempel vis ”beställning-och-svar”. Precis som för tjänstekontrakt kan
tjänsteinteraktioner förekomma mellan många olika tjänstekomponenter. Tjänsteinteraktioner
beskrivs med följande symboler:
Initierande roll
Tjänstereferens
re
a
g
ta
tiv
itia
In
Operation i
tjänstekontrakt
U
tfö
ra
re
Tjänstekontrakt
Figur 22 - Notation för tjänsteinteraktioner
Utförande roll
Referensarkitekturen definierar följande mönster för tjänsteinteraktioner:
Fråga-svar
Informationsspridning
Uppdragresultat
Initiativtagare
Initiativtagare
Initiativtagare
Utförare
Utförare
RefArk
Utförare
Figur 23 - Mönster för tjänsteinteraktioner
Nedanstående bild exemplifierar en partnerinteraktion:
Initiativtagaren anropar en InUt-operation
i utförarens tjänstegränssnitt.
Initiativtagarens tjänstekontrakt är
anonymt för utföraren.
Initiativtagaren lämnar information till
utföraren genom att anropa in Inoperation.
Initiativtagarens tjänstekontrakt
är anonymt för utföraren.
Initiativtagaren ber utföraren att utföra en
ett uppdrag genom att anropa en Inoperation.
Utföraren återkommer till
Initiativtagaren med ett resultat genom att
anropa en In-operation definierad av
initiativtagarens tjänstegränssnitt.

Tjänsteinteraktion av typ
Uppdrag ‐ Resultat
3.8 Tjänstedomäner
Initierande
Partner
ANVISNING - 39 (87)
2007-12-20 REV A
TK2
TK1
Figur 24 - Partnerinteraktion
Utförande
partner
TK1: LämnaRemiss tjänst
TK2: TaEmotLabbSvar tjänst
§11 Tjänsteinteraktioner ska vara inordnade i nationella tjänstedomäner.
Tjänsteinteraktioner ordnas i nationellt fastställda tjänstedomäner, för att vara tillgängliga för
design av tjänstekomponenter och samverkansprocesser. Meddelandeformat och
tjänstekontrakt versionshanteras i enlighet med RIV teknisk anvisning. Nedanstående figur
illustrerar principen för tjänstedomäner som en katalogiseringsstruktur. Tjänstedomäner och
dess omgivande strukturer fastställs av TIS.
Huvudområde Tjänstedomän Tjänsteinteraktion Tjänstegränssnitt
Vård
Omsorg
Administration
Remisshantering
Labbhantering
Läkemedelsföreskrivning
Biobank
Statusuppföljning
Koordinera-
Remissprocess
Figur 25 - Indelning av tjänster och domäner
Tjänstegränssnitt 1
Uppdrag -ut
Uppdragsmeddelande
Tjänstegränssnitt 2
Resultat -in
Resultatmeddelande
Tjänstedomänerna är nationellt standardiserad funktionell styckning av verksamhetens
domäner. Även IT-verksamheten kan ha tjänstedomäner. Där organiseras tjänsteinteraktioner
av generell, plattformsorienterad karaktär. BIF är ett exempel på en tjänstedomän inom
huvudområdet IT. Domänkartan blir tydlig när man fokuserar nivåerna Huvudområde och
Tjänstedomän. Observera att detta inte är den normerade modellen.

«Huvudområde»
IT
«Tjänstedomän»
BI F
+ Loggning
Loggning
ANVISNING - 40 (87)
2007-12-20 REV A
«Huvuddomän»
VårdOchOmsorg
StatusFråga
LämnaBeställning
«Tjänstedomän»
BoS
«Huvudområde»
Läk eme del
Medici nFråga
+ LämnaBeställning
+ StatusFråga
«Tjänstedomän»
Journal
«Tjänstedomän»
Läkemedelsregister
+ MedicinFråga
Figur 26 - Tjänstedomäner
Domänkartan och dess innehåll är nationellt. Det tillhör ingen samverkansdomän, eftersom
det är en organisationsoberoende indelning. Tjänstedomänerna definierar förutsättningar för
samverkan, tvärs alla samverkansdomäner. De är obundna till så väl organisation som
systemstöd:
Figur 27 - Samverkans- och tjänstedomäner

3.8.1. Tjänstekomponenter
ANVISNING - 41 (87)
2007-12-20 REV A
§12 Tjänsteinteraktioner ska vara indelade enligt nationella tjänstedomäner.
Tjänsteinteraktioner realiseras av tjänstekomponenter. Dessa är löst kopplade genom att
tjänsteinteraktionerna definieras oberoende av realiserande komponenter. En
tjänstekomponent är en del av ett system som realiserar ett tjänstekontrakt, eller har ett
beroende till ett tjänstekontrakt – d.v.s. spelar rollen av initiativtagare eller utförare i en eller
flera tjänsteinteraktioner. Följande figur belyser skillnaden mellan komponent och kontrakt,
genom att visa flera konstellationer av komponenter för samma tjänsteinteraktion.
t
n
L
TK1 abtjä K1
ite
m
K2
e
nst
R TK2
t
n
L
TK1 abtjä K3 ite
m
K4
e
nst
R TK2
Figur 28 - Tjänstekontrakt och tjänstekomponent
För att tillmötesgå kraven på lös koppling i produktion, realiseras alltid den ena rollen av en
tjänsteplattform, som löser upp adressen till den komponent som realiserar den andra parten,
genom en vägvalskomponent. Därmed upprätthålls organisationsoberoende, enligt tidigare
beskriven princip.

K1
K2
K3
K4
A
B
C
D
ANVISNING - 42 (87)
X
X
2007-12-20 REV A
Tjänsteplattform
?
A
B
A
B
X
K5
K6
K7
Figur 29 - Tjänsteplattform och lösa kopplingar
Denna arkitektur svarar mot kraven på att minimera effekterna av system- och
organisationsförändringar. Minskad effekt av förändringar minskar risken för störningar vid
förändringar och bidrar därmed till ökad tillit. Tjänsteplattformen och dess virtualisering av
nationella tjänster ger en plattform för kontinuerlig framväxt av en nationellt orkestrerad
vårdprocess
3.9 Tjänstetyper
§13 Nationella tjänster ska vara kategoriserade i följande kategorier – atomär tjänst,
orkestrerande tjänst, virtuell tjänst och plattformstjänst
Nationella tjänster är samverkanstjänster och plattformstjänster.
Samverkanstjänster klassificeras enligt följande indelning:
- Atomär tjänst
- Orkestrerande tjänst
- Virtuell tjänst
Därutöver finns tjänster av teknisk karaktär som är plattformstjänster.
3.9.1. Atomär tjänst
En atomär tjänst har ett garanterat tillstånd efter anrop. Det kan vara en frågetjänst eller en
uppdaterande tjänst. En uppdaterande operation i en atomär tjänst utför hela anropet inom en
atomär transaktion. En operation kan därmed aldrig lämna systemet i ett mellantillstånd.
Antingen utfördes allt enligt kontraktet, eller avslutar operationen utan att ha förändrat
systemets tillstånd. Effekter på indirekta anrop av plattformstjänster - så som loggning –
omfattas inte av dessa restriktioner. En uppdaterande metod i en atomär tjänst ska inte

ANVISNING - 43 (87)
2007-12-20 REV A
uppdaterande InUt-operationer i andra SOA-tjänster. En atomär tjänst kan representera
informationsåtkomst så väl som aktiviteter. Ur ett SOA-perspektiv finns ingen hierarki mellan
atomära tjänster. Detta är förutsättning för att på ett robust sätt kunna säkra krav på
konsistenta data ett källsystem. En tjänstekomponent som realiserar ett atomärt
tjänstekontrakt, kan internt återanvända realiseringar i andra tjänstekomponenter. Detta ska då
ske via plattformsspecifika mekanismer för komponentintegration, som inte äventyrar
robusthet med avseende på datakonsistens.
3.9.2. Orkestrerande tjänst
En orkestrerande tjänst är antingen en sammansatt frågetjänst eller en tjänst sammansatt av en
blandning av fråge- och uppdaterande atomära tjänster. Den orkestrerande tjänsten har ett
tjänstekontrakt i linje med en atomär tjänst. Men till skillnad från den atomära tjänsten, finns
inga garantier för att tjänsten gör fullständig tillbakarullning 21 . Dessa tjänster definieras
istället som ett tjänstekontrakt med en tillhörande processbeskrivning. Processbeskrivningen
uttrycker hur den orkestrerande tjänster realiseras i termer av anrop till atomära tjänster.
En orkestrerande tjänst initieras i något av följande scenarion
- Nationell frågetjänst som orkestrerar sammanställning av information genom att
använda atomära tjänster i andra samverkansdomäner.
- Samverkan i vårdprocess. En vårdgivare knyter samman aktiviteter i sin process med
aktiviteter i annan vårdgivares processer. En orkestrerande tjänst kan t.ex. orkestrera
en vårdgivares interaktioner med ett labb hos en annan vårdgivare.
- Reagera på notifiering. En atomär tjänst notifierar en händelse (t.ex. genom BIF
notiferingstjänst). En orkestrerande tjänst prenumererar på händelsen, med ansvar att
orkestrera aktiviteter mot atomära tjänster. Det kan t.ex. gälla en vårdgivares
uppdatering av nationellt patientindex . Lokala källsystem notifierar förändringar i
journaler via BIF notifieringstjänst. En lokal orkestrerande tjänst prenumererar och ser
till att överräcka informationen till patientindex enligt nationellt normerad
tjänsteinteraktion.
- Nytt verksamhetsstöd som behöver kopplas till portal. En vårdgivare vill automatisera
en process med hjälp av arbetsflödesverktyg och existerande atomära tjänster. En
orkestrerande tjänst håller – tillsammans med arbetsflödesmotorn – samman processen
Fiktivt exempel, orkestrerande tjänst
En vårdgivare vill integrera ett labb hos en annan vårdgivare i en automatiserad vårdprocess.
De båda parterna tillämpar en nationellt standardiserad samverkansprocess. Processen
beskrivs nedan som en abstrakt process med BPMN-notation.
21 Observera att kompenserande tjänster kan komma att behövas för att rulla tillbaka tillstånd. Distribuerade
transaktioner med låsningar av tillstånd ska undvikas.

Externt lab VG
Skapa Remiss
Utför labförsök
ANVISNING - 44 (87)
2007-12-20 REV A
Läs labsvar
Skapa labsvar
Figur 30 - Orkestrerande tjänst
Uppdatera journal
Genom SE-RIM och standardiseringsprocessen för tjänsteinteraktioner, finns följande
tjänsteinteraktioner katalogiserade i tjänstedomänerna VårdOchOmsorg.Labbhantering (Se
avsnitt om tjänstedomäner nedan) och IT. Arbetsflöde:
RemissOchSvarsInteraktion
re
a
g
ta
tiv
itia
In
TaEmotLabbsvar
LämnaRemissTjänst
Remiss-och-svarsinteraktioner definierar kontraktet mellan parter som samverkar enligt den
standardiserade processen. Det är en tjänsteinteraktion av typen Uppdrag-Resultat. Båda
parter realiserar sina respektive roller (initiativtagare respektive utförare) genom var sin
orkestrerande tjänst. I vårdgivar-domänen med labbverksamheten, finns en
arbetsflödeskomponent och ett labbsvarssystem. Man skapar en orkestrerande tjänst som
realiserar utförar-rollen i remiss-och-svarsinteraktionen. Processbeskrivningen binds till två
nationellt standardiserade tjänsteinteraktioner: Remissdatainteraktion och
Arbetsflödesinteraktion.
U
tfö
ra
re

RemissDataInteraktion
re
a
g
ta
tiv
itia
In
RemissDataTjänst
U
tfö
ra
re
Figur 31 - Remissdata interaktion är av typen
Fråga-Svar
ANVISNING - 45 (87)
2007-12-20 REV A
ArbetsflödesInteraktion
re
a
g
ta
tiv
itia
In
InitieraArbetsflödeTjänst
NotifieraAvslutatArbetsflödeTjänst
Figur 32 - Arbetsflödesinteraktioner är av typen
Uppdrag-Resultat
Orkestreringstjänsten använder de ingående tjänstekontrakten enligt nedanstående SOA:
RemissDataTjänst
Rem issOchSv arUtförare
LabbProcess
RemissdataIni tiativtagare
RemissDataTj änstUtförare
LämnaRemiss TaEmotLabbsvar
ArbetsflödeInitiativtagare
RemissdataTjänst
NotifieraAvslu tatArbetsflöde
InitieraArbetsflöde
Figur 33 - Orkestrering och tjänster
NotifieraAvslu tatArbetsflöde
InitieraArbetsflöde
U
tfö
ra
re
ArbetsflödeUtförare
Dagens labbsvarsystem stödjer inte tjänstekontraktet RemissDataTjänst. En ny
tjänstekomponent realiseras, i syfte att ansluta systemet enligt det nationellt standardiserade
tjänstekontraktet. Man hade ingen arbetsflödeskomponent sedan tidigare, utan ropade av den
nationellt upphandlade komponenten, som realiserar rollen som utförare i den nationellt
standardiserade tjänsteinteraktionen Arbetsflöde.
Enheten som erbjuder labbtjänsten tillhör en vårdgivardomän som tillämpar den nationella
domänarkitekturen. Samtliga tjänstekomponenter har en enda anslutning till
vårdgivardomänens tjänsteplattform. Det betyder att komponenten som realiserar den
orkestrerande tjänsten ansluts till tjänsteplattformens kända anslutningspunkt. Vägvalstjänsten
behöver konfigureras för bindningen från arbetsflödestjänsten tillbaka till den orkestrerande
tjänsten. Tjänstekomponenten för remissdata och arbetsflödeskomponenten är anslutna sedan
tidigare:

Anslutningskomponent,
befintligt Labsvarsystem
(TK: RemissDataTjänst)
Initiativtagare
Interaktion Arbetsflöde
Tjänstekomponent för
Orkestrerande tjäns t
(t.ex. BPELskript) Utförare
Interaktion RemissOchSvar
Initiativtagare
Interaktion RemissData
Utförare
Interaktion RemissData
ANVISNING - 46 (87)
2007-12-20 REV A
Tjänsteplattform
Figur 34 - Orkestrering och tjänsteplattform
Utförare
Interaktion Arbetsflöde
Arbetsflödes‐
komponent
Nationella
domänens
Tjänsteplattform
Figuren visar den orkestrerande tjänstens realisering. Konsumenter och producenter är löst
kopplade via samverkansdomänens tjänsteplattform. Meddelanden från remitterande
vårdgivare styrs via den nationella domänens tjänsteplattform, som publicerar en virtuell
tjänst för de vårdgivare som vill bedriva samverkan i vårdprocessen.
3.9.3. Virtuell tjänst
En virtuell tjänst är en tjänst som inte realiseras av den publicerande anslutningspunkten. Det
är ett koncept som hör till tjänsteplattformen. Tjänsteplattformen är en tjänstekomponent som
virtuellt realiserar samtliga tjänstekontrakt av värde för samverkansdomänen. På så sätt skapar
tjänsteplattformen lös koppling mellan samverkande tjänstekomponenter.
3.9.4. Plattformstjänst
Plattformstjänster bildar teknisk plattform för realisering av andra tjänster. Tjänstekontrakten i
BIF är plattformstjänster – i vart fall om man undantar utlämnandetjänsten och
vårdrelationstjänsten, som kan sägas stå med ett ben i vårdprocessen.

ANVISNING - 47 (87)
2007-12-20 REV A
4 Användingsfall och tekniska komponenter
4.1 Utgångspunkter
I det föregående avsnittet beskrevs en referensarkitektur. Den ska stödja de användningsfall
som definieras av verksamheten samt även stödja icke-funktionella krav som finns avseende
samverkan mellan vårdgivare.
Den tekniska arkitekturen består av komponenter som behövs och interaktionsdiagram för de
användningsfallen som verksamheten definierat. Genom dessa diagram kan flödet och
interaktionerna mellan de beskrivna komponenterna följas och ses i sitt sammanhang.
En övergripande grund för arkitekturen är en design baserad på SOA-tjänster som publicerar
ett detaljerat och tydligt gränssnitt.
4.2 Förutsättningar och avgränsningar
Dessa standarder och komponenter används för att realisera arkitekturen:
• RIV - Regelverk för interoperabilitet
Behövs för utformning av de meddelanden som ska överföras mellan konsument och
producent av aktuella tjänster. RIV behövs även för den tekniska beskrivningen av hur
anrop av ett gränssnitt ska utformas. RIV definierar även hur identifiering,
åtkomstkontroll, integritet och insynsskydd ska hanteras.
• BIF – Bastjänster för InformationsFörsörjning
RIV hänvisar på flera punkter till BIF för att lösa ett antal av de funktionaliteter som
krävs för ett säkert och korrekt umgänge mellan vårdaktörer. Det gäller t.ex.
identifiering med e-ID kort, åtkomstkontroll för aktuellt objekt för aktuell aktör via
SAML-biljett, loggning av tjänsteutnyttjande, samtyckes- och vårdrelationshantering.
• SITHS och HSA
I dessa arbeten definieras och skapas den infrastruktur som behövs för stark
identifiering av aktör och IT-tjänst. Både SITHS och HSA är förutsättningar för att
BIF skall fungera.
• Sjunet – Transportnät för vård- och omsorg
Sjunet är ett VLAN (Virtuellt LAN), som drivs en nätoperatör. Nätet är skyddat.
Samtliga landsting, ett antal kommuner, ett antal privata vårdgivare inkl
Praktikertjänst och Capio, Skatteverket samt ett tjugotal leverantörer, inklusive
Apoteket, är idag anslutna till Sjunet.

4.3 Interaktionsmönster
ANVISNING - 48 (87)
2007-12-20 REV A
4.3.1. Gemensamt lokalt interaktionsmönster
Gemensamt för alla nedanstående typfall är det interaktionsmönster som sker lokalt hos
vårdgivare A innan anrop. Nedanstående interaktionsdiagram visar vilka steg som ingår före
och efter anrop av tjänst.
Interaktionsdiagram
Nedan beskrivs de interaktioner som ingår i vårdgivare A:s hantering innan anrop. Detta
mönster är samlat här för att det blir svårt att ha detta gemensamma mönster med i samtliga
specifika typfall nedan. Interaktionsdiagrammet förutsätter att:
• Patienten har lämnat sitt samtycke att vårdinformation får lämnas ut till vårdgivare A
• Aktör hos vårdgivare A har vårdrelation till patienten
• Tjänstemäklare används inte i interaktionsmönster eftersom tillämpning och ITtjänster
i produktion antas känna till var aktuell tjänst finns
Vårdgivare A
Användare Arbetsyta Tillämpning Autentisering Vårdtjänst
Åtkomstkontroll
(ÅKT)
Samtycke Vårdrelation Loggning
1 Inloggning
2 Autentisering
2a SAML
3 Visa begärd information
4 Hämta information lokalt
5 Logga anrop
Vårdtjänst från
6 Åtkomstkontroll
6a Finns samtycke?
6b svar Ja
6c Finns vårdrelation?
6d Svar Ja
vårdgivare A behöver
information från
6e Logga att åtkomst har beviljats
vårdgivare B enligt 6f Svar Ja
samverkansarkitektur
7 Hämta data från datalager
7a Returnera data
8 Logga vilken information som returnerat data innehåller
9 Hämta information från Vårdgivare B
10 Paketera meddelandet enligt RIV
11 Returnera begärda datal
12 Returnera begärd bild
13 Användare ser bild
9a Returnera data
Lagring
Vårdgivare B
Vårdtjänst
Interaktionsmönster
beskrivs separat i
respektive
interaktionsdiagram för
de olika typfallen
Stegvis beskrivning av flödet i interaktionsdiagrammet
Nedan beskrivs respektive steg i interaktionsdiagrammet som markerats med en siffra. Ord
med kursiv och fet still är samverkanskomponenter dessa finns beskrivna i kapitel 1.6.4.
1. Aktör startar generellt samverkansmönster genom inloggning till sin arbetsyta.
2. Identifiering av aktör ska ske med metod enligt anvisning.
a. I retur efter fullbordat anrop av Autentiseringstjänst får aktören en SAMLbiljett
med utvalda attribut.

ANVISNING - 49 (87)
2007-12-20 REV A
3. Aktör begär att få titta på utvald patient information, vilken information beror på
aktuellt typfall.
4. Lokaltillämpning anropar lokal tjänst hos vårdgivare A för att hämta önskad
information. Med i denna begäran följer patient ID samt SAML biljett enligt ovan.
5. Lokal tjänst hos vårdgivare A loggar att åtkomst till vårddata har begärts genom anrop
av loggningstjänst. Format på loggdata ska vara utformat enligt generellt loggformat.
6. Tjänst hos vårdgivare A ska nu genomföra kontroll om aktuell begäran kan tillåtas.
Kontroll sker genom att tjänst anropar lokal Åtkomstkontrolltjänst med de parametrar
som avgör åtkomst samt den SAML-biljett som finns med i anrop enligt RIV standard.
Vid denna evaluering kommer tjänsterna för Samtycke och Vårdrelation, även
användas som undertjänster till Åktkomstkontrolltjänsten, för att kontrollera om det
finns samtycke eller vårdrelation.
a. Innan Åtkomstkontroll är klar ska förekomst av samtycke kontrolleras. Detta
sker genom ett anrop till lokal samtyckestjänst.
b. I detta fall antas samtycke föreligga, annars skulle tjänsten avslå begäran.
c. Innan Åtkomstkontroll är klar ska även vårdrelation kontrolleras. Detta sker
genom ett anrop till lokal samtyckestjänst.
d. I detta fall antas vårdrelation föreligga, annars skulle tjänsten avslå begäran.
e. Åtkomstkontrollen hos vårdgivare A loggar att åtkomst till vårddata har
beviljats. Detta sker genom BIF loggningstjänst. Format på loggdata ska vara
utformat enligt generellt loggformat.
f. Åtkomstkontrolltjänst svarar, baserat på regler uppsatta för aktuell tjänst, att
åtkomst är beviljad.
7. Nu hämtas data från datalager upp innan nästa steg av kontroller.
8. Tjänst hos vårdgivare A loggar att åtkomst till vårddata har beviljats. Detta sker
genom BIF loggningstjänst. Format på loggdata ska vara utformat enligt generellt
loggformat.
9. Nu följer de delar som är specifika för respektive typfall nedan
a. Efter genomfört uppdrag ger tjänst hos vårdgivare B ett svar
10. Tjänst paketerar svarsmeddelande enligt definition i tjänstebeskrivning. Paketering
ska följa aktuell RIV-profil och tjänstebeskrivning.
11. Retur till Vårdgivare A:s tillämpning enligt aktuell RIV-profil.
12. Bild med begärda data returneras till aktör.
13. Aktör ser bild på sin skärm.

ANVISNING - 50 (87)
2007-12-20 REV A
4.3.2. Typfall 1 Samverkan med känd vårdgivare
Detta typfall beskriver ett generiskt användningsfall för samverkan mellan två kända
vårdgivare. Typfallet identifierar också de komponenter/tjänster som behövs för att
samverkan ska vara möjlig.
Nils Nilsson är på besök hos Dr A som arbetar för vårdgivare A. Nils Nilsson har haft höga
blodfetter som han tidigare behandlas för hos vårdgivare B. Nils Nilsson vet att de tog ett
blodprov och efter några dagar fick han läkemedel som han inte kommer ihåg namnet på.
Aktör Komponent/Tjänst
Dr A loggar in i sin arbetsplats med
hjälp av e-ID kort och PIN-kod. Dr A
identifieras.
Dr A frågar Nils Nilsson om han får
se det som vårdgivare B har
registrerat i deras
informationssystem. Nils Nilsson
säger ja och Dr A får därmed
samtycke att se informationen.
Dr A har vårdrelation till Nils Nilsson
eftersom Nils Nilsson är bokad för
besök hos vårdgivare A.
Dr A använder en funktion i sitt
lokala system för att se patientens
ordinerade läkemedel.
Dr A får se information utanför
vårdgivare A
Vårdtjänst hos vårdgivare B får en
förfrågan om att visa patientens
ordinerade läkemedel. Vårdtjänsten
(B) loggar förfrågan.
Vårdtjänsten (B) kontrollerar att Dr A
har åtkomst till informationen genom
att
• Kontrollera att Dr A har
Vårdrelation kan automatiskt ha
räknats fram genom att patienten
bokat tid hos vårdgivare A. Vid
bokningen skickades en
notifiering via till
att
uppdragstagare hos vårdgivare A
har vårdrelation till patienten.
Tillämpningen som Dr A
använder kontrollerar att Dr A har
åtkomst till tjänsten.
Här kan det vara aktuellt med
tjänst för att fråga om specifik och
relevant del av journal annars kan
Dr A bli översvämmad med
överflödig information som inte är
relevant för den specifika
situationen. Detta behöver utredas
vidare!
Ska det göras en kontroll om
utlämnandebeslut finns om
samtycke och vårdrelation finns?
Om samtycke och vårdrelation

patientens samtycke
• Kontrollera att Dr A har
vårdrelation till patienten
• Kontrollera att Dr A har
utlämnandebeslut på
informationen
Vårdtjänst hos vårdgivare B skickar
tillbaka lista över patientens
ordinerade läkemedel från vårdgivare
B samtidigt som utlämnande av
information loggas.
Dr A ser nu de läkemedel som har
ordinerats till Nils Nilsson men kan
inte med det underlaget bedöma
åtgärd.
Dr A behöver se det labbresultat som
har gett upphov till läkemedlet. Dr A
använder funktion i sin lokala
tillämpning för att visa labbresultat
från vårdgivare B.
Vårdtjänst hos vårdgivare B anropas.
Vårdtjänsten (B) loggar anropet.
Vårdtjänsten (B) kontrollerar Dr A
har patientens samtycke.
Vårdtjänsten (B) kontrollerar om Dr
A har en vårdrelation till patienten.
Vårdtjänsten (B) kontrollerar om Dr
A har utlämnandebeslut.
Dr A får se patientens labbresultat
från vårdgivare B och kan med hjälp
av den samlade informationen
behandla patienten.
ANVISNING - 51 (87)
2007-12-20 REV A
finns svarar utlämnandetjänsten ja
om inte information är känslig?
Interaktionsdiagram
Nedan beskrivs ett interaktionsdiagram för ”Läs patientens ordinerade läkemedel samt
patientens labbsvar”. Detta mönster utgår från att det finns en applikationsserver som ligger
mellan tillämpningen som vårdpersonalen hos vårdgivare A använder och den nationella
samverkanstjänsten hos vårdgivare B. Skulle inte så vara fallet kommer de steg som utförs av
applikationsserver att flyttas ut till, och utföras av, klientdator hos vårdgivare A i stället.
Interaktionsdiagrammet förutsätter att:
• Patienten har lämnat sitt samtycke att vårdinformation får lämnas ut till vårdgivare A
• Aktör hos vårdgivare A har vårdrelation till patienten

ANVISNING - 52 (87)
2007-12-20 REV A
• Vårdgivare B har avtal med Vårdgivare A på att aktör hos Vårdgivare A får komma åt
vårdinformation hos Vårdgivare B via gemensam BIF-kompatibel säkerhetstjänst.
• Av autentiseringstjänst inom Vårdgivare A genererat SAML-biljett ingår i en med
åtkomstkontrollstjänst hos vårdgivare B gemensam CA-struktur enligt SITHS.
• Aktuell RIV profil används och är utformad enligt anvisning
• Tjänstemäklare används inte i interaktionsmönster eftersom tillämpning och ITtjänster
i produktion antas känna till var aktuell tjänst finns.
Detta interaktionsdiagram är hämtat från de typfall som generaliserats utifrån verkliga
användningsfall. Detta typfall behöver 2 interaktionsdiagram för sin redovisning.

ANVISNING - 53 (87)
2007-12-20 REV A
Stegvis beskrivning av flödet i interaktionsdiagrammet
Nedan beskrivs respektive steg i interaktionsdiagrammet som markerats med en siffra. Ord
med kursiv och fet still är samverkanskomponenter dessa finns beskrivna i kapitel 1.6.4.
I detta kapitel finns även koppling mellan RRR:er och respektive samverkanskomponent.
1. Aktör startar samverkansmönster genom inloggning till sin arbetsyta.
2. Identifiering av aktör ska ske med metod enligt anvisning.
a. I retur efter fullbordat anrop av Autentiseringstjänst får aktören en SAMLbiljett
med utvalda attribut
3. Aktör begär att få titta på patientens ordinerade läkemedel.
4. Lokaltillämpning anropar lokal tjänst hos vårdgivare A för att hämta ordinerade
läkemedel. Med i denna begäran följer patient ID samt SAML-biljett enligt ovan.
5. Lokaltjänst upptäcker att den behöver använda samverkanstjänst hos vårdgivare B. För
att kunna utföra anrop måste den lokala tjänsten göra ett RIV WebService anrop enligt
beskrivning i referens [RIVTA] med ett innehåll enligt av vårdgivare B publicerad
WSDL och tjänstebeskrivning. Denna beskrivning ska följa anvisning.
6. Tjänst hos vårdgivare B loggar att åtkomst till vårddata har begärts genom en
loggningstjänst. Format på loggdata ska vara utformat enligt generellt loggformat.
7. Tjänst hos vårdgivare B ska nu genomföra kontroll om aktuell begäran kan tillåtas.
Kontroll sker genom att tjänst anropar lokal Åtkomstkontrolltjänst med de parametrar
som avgör åtkomst samt det SAML-biljett som ska finnas med i anrop enligt RIV
standard. Vid denna evaluering kommer tjänsterna för Samtycke och Vårdrelation
även kontrolleras som undertjänster till Åktkomstkontrolltjänsten.
a. Innan Åtkomstkontroll är klar ska förekomst av samtycke kontrolleras. Detta
ska framgå av det SAML-biljett som ingår i RIV anrop. Genom att
federationsstruktur finns etablerad mellan deltagare i samverkan kan
vårdgivare B:s samtyckestjänst ge sitt medgivande via att denna tjänst litar på
detta intygande om samtycke från vårdgivare A.
b. I detta fall antas samtycke föreligga, annars skulle tjänsten avslå begäran.

ANVISNING - 54 (87)
2007-12-20 REV A
c. Innan Åtkomstkontroll är klar ska vårdrelation kontrolleras. Detta ska framgå
av det SAML-biljett som ingår i RIV anrop. Genom att federationsstruktur
finns etablerad mellan deltagare i samverkan kan vårdgivare B:s
vårdrelationstjänst ge sitt medgivande att vårdrelation existerar via att denna
tjänst litar på detta intygande om vårdrelation.
d. I detta fall antas vårdrelation föreligga, annars skulle tjänsten avslå begäran.
e. Nu kontrolleras om utlämnande får ske av aktuell informationsmängd. Detta
sker genom anrop av IT-tjänst för utlämnande.
i. Eftersom vårdrelation och samtycke finns kan utlämnande ske av
aktuell informationsmängd.
f. I detta fall antas utlämnande vara OK, annars skulle tjänsten avslå begäran.
g. Åtkomstkontroll hos vårdgivare B loggar att åtkomst till vårddata har beviljats.
Detta sker genom BIF loggningstjänst. Format på loggdata ska vara utformat
enligt generellt loggformat.
h. Åtkomstkontrolltjänst svara att åtkomst är beviljad.
8. Nu hämtas data från datalager upp innan nästa steg av kontroller.
9. Tjänst paketerar svarsmeddelande enligt definition i tjänstebeskrivning. Paketering
ska följa aktuell RIV-profil och tjänstebeskrivning enligt [RIVHL7].
10. Tjänst hos Vårdgivare B loggar vilka data som blev resultatet av aktuell begäran.
Detta sker genom en loggningstjänst. Format på loggdata ska vara utformat enligt
generellt loggformat.
11. Retur till Vårdgivare A:s tjänst enligt aktuell RIV-profil.
12. Ordinerade läkemedel som finns registrerade hos Vårdgivare A och Vårdgivare B sätts
ihop till en gemensam lista som returneras till tillämpningen.
13. Tillämpning skapar bild över vårddata som ska visas för aktör.
14. Aktören får upp redigerad bild på sammanställning vårddata på sin arbetsyta.
De vårddata som hämtades från föregående förfrågan är inte tillräcklig för att aktör ska kunna
behandla patienten. Aktör initierar ett nytt samverkansmönster med en annan tjänst.
15. Aktör startar nytt samverkansmönster genom att begära att titta på patientens labbsvar.
Observera att aktör är redan inloggad och har SAML-biljett.
16. Lokaltillämpning anropar lokal tjänst hos vårdgivare A för att hämta labbsvar. Med i
denna begäran följer patient ID samt SAML-biljett enligt ovan.
17. Lokaltjänst upptäcker att den behöver använda samverkanstjänst hos vårdgivare B. För
att kunna utföra anrop måste lokaltjänst skapa ett RIV WebService anrop enligt
beskrivning i [RIVTA] med ett innehåll enligt av vårdgivare B publicerad WSDL och
tjänstebeskrivning. Denna beskrivning ska följa profil enligt anvisning.
18. Tjänst hos vårdgivare B loggar att åtkomst till vårddata har begärts genom en
loggningstjänst. Format på loggdata ska vara utformat enligt generellt loggformat.
19. Vi förutsätter att vi får positiv besked på vår förfrågan till Åtkomstkontrolltjänsten. Se
steg 7 i föregående sekvensdiagram för detaljer.
h. Det är OK att svara kommer som svar från Åtkomstkontrolltjänst
20. Nu hämtas data från datalager upp innan nästa steg av kontroller.
21. Tjänst paketerar svarsmeddelande enligt definition i tjänstebeskrivning. Paketering
ska följa aktuell RIV-profil och tjänstebeskrivning.
22. Tjänst hos vårdgivare B loggar att svar med vårddata har avgivits. Detta sker genom
en loggningstjänst. Format på loggdata ska vara utformat enligt generellt loggformat.
23. Retur till Vårdgivare A:s tjänst enligt aktuell RIV-profil.
24. Labbsvar som finns registrerade hos Vårdgivare A och Vårdgivare B sätts ihop till en
gemensam lista som returneras till tillämpningen.

ANVISNING - 55 (87)
2007-12-20 REV A
25. Tillämpning skapar bild över vårddata som ska visas för aktör.
26. Aktör får upp redigerad bild på sammanställning vårddata på sin arbetsyta.

ANVISNING - 56 (87)
2007-12-20 REV A
4.3.3. Typfall 2 Samverkan med känd vårdgivare där samtycke saknas
Detta typfall beskriver ett generiskt användningsfall för samverkan mellan två kända
vårdgivare där samtycke saknas. Typfallet identifierar också de komponenter/tjänster som
behövs för att samverkan ska vara möjlig.
Dr A som arbetar för vårdgivare A förbereder sig inför patienten Nils Nilsson kommer på
besök. Dr A hämtar fram information om Nils Nilsson orsak till besöket. Orsaken är att Nils
Nilsson har haft höga blodfetter som han tidigare behandlas för hos vårdgivare B.
Aktör Komponent/Tjänst
Dr A loggar in i sin arbetsplats med
hjälp av e-ID kort och PIN-kod. Dr
A identifieras.
Dr A saknar Nils Nilssons
samtycke att se vårdinformation
utanför vårdgivare A eftersom Nils
Nilsson inte kommer förrän senare
under dagen. Dr A vill förbereda
sig genom att se Nils Nilssons
labbsvar som handlar om
blodfetter.
Dr A har vårdrelation till Nils
Nilsson eftersom Nils Nilsson är
bokad för besök hos vårdgivare A.
Dr A använder en funktion i sitt
lokala system för att se patientens
labbsvar.
Dr A vill hämta in information om
labbsvar utanför vårdgivare A.
Vårdtjänst hos vårdgivare B får en
förfrågan om att visa patientens
labbsvar. Vårdtjänsten (B) loggar
förfrågan.
.
Vårdrelation kan automatiskt ha
räknats fram genom att patienten
bokat tid hos vårdgivare A. Vid
bokningen skickades en
notifiering via till
att
uppdragstagare hos vårdgivare A
har vårdrelation till patienten.
Tillämpningen som Dr A
använder kontrollerar att Dr A har
åtkomst till tjänsten.
Här kan det vara aktuellt med
tjänst för att fråga om specifik och
relevant del av journal annars kan
Dr A bli översvämmad med
överflödig information som inte är
relevant för den specifika
situationen. Detta behöver utredas
vidare!
Vårdtjänsten (B) kontrollerar att Dr Dr A saknar patientens samtycke

A har patientens samtycke
Vårdtjänsten (B) kontrollerar att Dr
A har vårdrelation till patienten
Vårdtjänsten (B) kontrollerar att Dr
A har utlämnandebeslut för att se
informationen
Dr A får i sin skärm ett
meddelande som talar om att
samtycke saknas och för att
informationen ska lämnas ut krävs
det utlämnandebeslut
Dr A begär utlämnandebeslut från
vårdgivare B för att hämta Nils
Nilssons labbsvar genom att
använda en funktion i sitt lokala
informationssystem
Utlämnandeärende initieras hos
vårdgivare B med uppgifter om
vilken information som Dr A vill få
tillgång till
Dr A får i sin skärm ett
meddelande som talar om att
begäran om utlämnandebeslut
behandlas av handläggare hos
vårdgivare B
Dr A jobbar vidare med andra
patienter för att invänta
utlämnandebeslut
En stund senare får Dr A e-post
som meddelar att det nu finns
utlämnandebeslut och att
informationen kan inhämtas
Dr A loggar in i sin arbetsplats med
hjälp av e-ID kort och PIN-kod. Dr
A identifieras.
Dr A saknar Nils Nilssons
samtycke att se vårdinformation
utanför vårdgivare A eftersom Nils
Nilsson inte kommer förrän senare
under dagen. Dr A vill förbereda
sig genom att se labbsvar på
analyser som handlar om
blodfetter.
Dr A har vårdrelation till Nils
Nilsson eftersom Nils Nilsson är
ANVISNING - 57 (87)
2007-12-20 REV A
Dr A saknar utlämnandebeslut
En begäran om utlämnandebeslut
skickas till vårdgivare B
Vårdrelation kan automatiskt ha
räknats fram genom att patienten

ANVISNING - 58 (87)
2007-12-20 REV A
bokad för besök hos vårdgivare A. . bokat tid hos vårdgivare A. Vid
bokningen skickades en
notifiering via till
att
uppdragstagare hos vårdgivare A
har vårdrelation till patienten.
Dr A använder en funktion i sitt
lokala system för att se patientens
labbsvar.
Dr A vill hämta in information om
labbsvar utanför vårdgivare A.
Vårdtjänst hos vårdgivare B får en
förfrågan om att visa patientens
labbsvar. Vårdtjänsten (B) loggar
förfrågan.
Vårdtjänsten (B) kontrollerar att Dr
A har patientens samtycke
Vårdtjänsten (B) kontrollerar att Dr
A har vårdrelation till patienten
Vårdtjänsten (B) kontrollerar att Dr
A har utlämnandebeslut för att se
informationen
Vårdtjänst hos Vårdgivare B
skickar tillbaka lista över
patientens labbsvar från vårdgivare
B samtidigt som utlämnande av
information loggas.
Dr A får se patientens labbresultat
från vårdgivare B och kan med
hjälp av den samlade
informationen behandla patienten.
Tillämpningen som Dr A
använder kontrollerar att Dr A har
åtkomst till tjänsten.
Här kan det vara aktuellt med
tjänst för att fråga om specifik och
relevant del av journal annars kan
Dr A bli översvämmad med
överflödig information som inte är
relevant för den specifika
situationen. Detta behöver utredas
vidare!
Dr A saknar patientens samtycke
Utlämnandebeslut finns registrerat
som ger Dr A rättigheter att hämta
informationen

ANVISNING - 59 (87)
2007-12-20 REV A
Interaktionsdiagram
Nedan beskrivs ett interaktionsdiagram för ”Läs patientens labbresultat efter
utlämnandeförfarande”. Detta mönster utgår från att det finns en applikationsserver som
ligger mellan tillämpningen som vårdpersonalen hos vårdgivare A använder och den
nationella samverkanstjänsten hos vårdgivare B. Skulle inte så vara fallet kommer de steg
som utförs av applikationsserver att flyttas ut till, och utföras av, klientdator hos vårdgivare A
i stället.
Interaktionsdiagrammet förutsätter att:
• Aktör hos vårdgivare A har vårdrelation till patienten
• Vårdgivare B har avtal med Vårdgivare A på att aktör hos Vårdgivare A får komma åt
vårdinformation hos Vårdgivare B via gemensam BIF-kompatibel säkerhetstjänst.
• Av autentiseringstjänst inom Vårdgivare A genererat SAML-biljett ingår i en med
åtkomstkontrollstjänst hos vårdgivare B gemensam CA-struktur.
• Profil som användes är enligt anvisning.
• Tjänstemäklare används inte i interaktionsmönster eftersom tillämpning och ITtjänster
i produktion antas känna till var aktuell tjänst finns
Detta interaktionsdiagram är hämtat från de typfall som generaliserats utifrån verkliga
användningsfall. Detta typfall behöver 2 interaktionsdiagram för sin redovisning.
Vårdgivare A Vårdgivare B
Användare Arbetsyta Tillämpning Autentisering
Tjänst hämta
labbsvar
Notifieringstjänst
Tjänst hämta
labbsvar
Åtkomstkontroll
(ÅKT)
Samtycke Vårdrelation Utlämnande
Notifieringstjänst
Loggning Handläggare
1 Inloggning
2 Autentisering
2a SAML
3 Visa patientens labbsvar
4 Hämta patientens labbsvar
5 Hämta labbsvar från Vårdgivare B
6 Logga anrop
Utelämnat är lokal
7 Åtkomstkontroll
7a Finns samtycke?
åtkomstkontroll och
loggning. Detta
beskrivs i gemensamt
7b svar Nej
7c Finns vårdrelation?
interaktionsmönster
ovan.
7d Svar Ja
7e Får utlämnande ske?
7f Svar Nej
7g Logga att åtkomst nekats
7h Svar Nej
8 Åtkomst nekad
9 Åtkomst nekad
10 Åtkomst nekad
11 Begär utlämnande
12 Begär utlämnande
13 Utlämningsbegäran
14 Utlämningsbegäran registrerad
15 Prövning
Utlämningsbegäran registrerad
16 Registrera beslut
17 Beslut registrerat
18 Notifiering om beslut
19 Utlämningsbeslut (t.ex. e-post)
I detta andra diagram följer händelserna efter det att notifiering gjorts om att utlämnande är
klar.

Tjänst hämta
Användare Arbetsyta Tillämpning Autentisering
labbsvar
20 Inloggning
21 Autentisering
21a SAML
22 Visa patientens labbsvar
23 Hämta patientens labbsvar
32 Användare ser bild
ANVISNING - 60 (87)
2007-12-20 REV A
Vårdgivare A Vårdgivare B
Utelämnat är lokal
åtkomstkontroll och
loggning. Detta
beskrivs i gemensamt
interaktionsmönster
ovan.
31 Returnera labbsvar
Tjänst hämta
labsvar
Åtkomstkontroll
(ÅKT)
Samtycke Vårdrelation Utlämnande Loggning
24 Hämta labbsvar från Vårdgivare B
25 Logga anrop
26 Åtkomstkontroll
26a Finns samtycke?
26b svar Nej
26c Finns vårdrelation?
26d Svar Ja
26e Får utlämnande ske?
26f Svar Ja
26g Logga att åtkomst har beviljats
26h Svar Ja
27 Hämta data från datalager
27a Returnera data
28 Paketera meddelandet enligt RIV
29 Logga vilken information som lämnas ut till Vårdgivare A
30 Returnera labbsvar
Stegvis beskrivning av flödet i interaktionsdiagrammet
Nedan beskrivs respektive steg i interaktionsdiagrammet som markerats med en siffra. Ord
med kursiv och fet still är samverkanskomponenter dessa finns beskrivna i kapitel 1.6.4.
I detta kapitel finns även koppling mellan RRR:er och respektive samverkanskomponent.
1. Aktör startar samverkansmönster genom att logga in till sin arbetsyta.
2. Identifiering av aktör ska ske med metod enligt anvisning.
i. I retur efter fullbordat anrop av autentiseringtjänst får aktör ett SAML-biljett
med utvalda attribut
3. Aktör begär att få titta på patientens labbsvar.
4. Lokaltillämpning anropar lokal tjänst hos vårdgivare A för att hämta labbsvar. Med i
denna begäran följer patient ID samt SAML-biljett enligt ovan.
5. Lokaltjänst upptäcker att den behöver använda samverkanstjänst hos vårdgivare B. För
att kunna utföra anrop måste den lokala tjänsten göra ett RIV WebService anrop enligt
beskrivning i referens [RIVTA] med ett innehåll enligt av vårdgivare B publicerad
WSDL och tjänstebeskrivning. Denna beskrivning ska följa profil enligt anvisning.
6. Tjänst hos vårdgivare B loggar att åtkomst till vårddata har begärts genom en
loggningstjänst. Format på loggdata ska vara utformat enligt generellt loggformat.
7. Tjänst hos vårdgivare B ska nu genomföra kontroll om aktuell begäran kan tillåtas.
Kontroll sker genom att tjänst anropar lokal Åtkomstkontrolltjänst med de parametrar
som avgör åtkomst samt den SAML-biljett som ska finnas med i anrop enligt RIV
standard. Vid denna evaluering kommer tjänsterna för Samtycke och Vårdrelation
även kontrolleras som undertjänster till Åktkomstkontrolltjänsten.
a. Innan Åtkomstkontroll är klar ska förekomst av samtycke kontrolleras. Detta
ska framgå av det SAML-biljett som ingår i RIV anrop. Genom att
federationsstruktur finns etablerad mellan deltagare i samverkan kan
vårdgivare B:s samtyckestjänst ge sitt medgivande via att denna tjänst litar på
detta intygande om samtycke från vårdgivare A.
Lagring

ANVISNING - 61 (87)
2007-12-20 REV A
b. I detta fall antas samtycke inte föreligga. Detta kommer att innebära att
utlämnande hantering måste genomföras.
c. Innan Åtkomstkontroll är klar ska vårdrelation kontrolleras. Detta ska framgå
av det SAML-biljett som ingår i RIV anrop. Genom att federationsstruktur
finns etablerad mellan deltagare i samverkan kan vårdgivare B:s
vårdrelationstjänst ge sitt medgivande att vårdrelation existerar via att denna
tjänst litar på detta intygande om vårdrelation.
d. I detta fall antas vårdrelation föreligga, annars skulle tjänsten avslå begäran.
e. Nu kontrolleras om utlämnande får ske av aktuell informationsmängd. Detta
sker genom anrop av IT-tjänst för utlämnande.
ii. Eftersom samtycke saknas kan inte utlämnande tillåtas utan
menprövning.
f. I detta fall svarar utlämnandetjänst Nej till utlämnande. Tjänsten avslår
begäran om labbsvar.
g. Åtkomstkontroll hos vårdgivare B loggar att åtkomst till vårddata har beviljats.
Detta sker genom BIF loggningstjänst. Format på loggdata ska vara utformat
enligt generellt loggformat.
h. Åtkomstkontrolltjänst svarar att åtkomst är inte är beviljad och att
utlämnandebeslut krävs.
8. Retur till Vårdgivare A:s tjänst med returkod ”Utlämnandebeslut krävs”.
9. Tillämpning skapar bild som beskriver krav på utlämnande.
10. Aktör får upp redigerad bild med knapp för att kräva utlämnande.
11. Aktör trycker på knapp för att begära utlämnande.
12. Tillämpning anropar utlämnandetjänst hos vårdgivare B. Detta anrop följer helt
tidigare mönster för RIV anrop.
13. Inom Vårdgivare B startar utlämnandetjänst ett arbetsflöde som finns definierat hur
prövning ska genomföras och registreras.
14. Svar till tillämpning att utlämnande flöde startats.
15. Menprövning genomförs och resultatet blir att utlämnande kan ske.
16. Handläggare registrerar beslut om utlämnande i utlämnandetjänst.
17. Notifieringstjänst tar emot meddelande om att utlämnandebeslut finns. För att hitta
tillbaka till rätt brevlåda måste denna returadress finnas med i inkommande
meddelande.
18. Notifiering kan gå direkt eller via vårdgivare A:s notifieringstjänst.
19. Notifieringstjänst notifierar via E-post att utlämnandebeslut är klart.
Nu kan Vårdgivare A fortsätta med tidigare förfrågan eftersom de nu finns ett
utlämnandebeslut registrerat hos vårdgivare B
20. Aktör startar samverkansmönster genom inloggning till sin arbetsyta.
21. Identifiering av aktör ska ske med metod enligt anvisning.
j. I retur efter lyckad autentisering får aktör ett SAML-biljett med utvalda
attribut
22. Aktör begär att få titta på patientens labbsvar.
23. Lokaltillämpning anropar lokal tjänst hos vårdgivare A för att hämta labbsvar. Med i
denna begäran följer patient ID samt SAML-biljett enligt ovan.
24. Lokaltjänst upptäcker att den behöver använda samverkanstjänst hos vårdgivare B. För
att kunna utföra anrop måste lokaltjänst skapa ett RIV WebService anrop enligt
beskrivning i [RIVTA] med ett innehåll enligt av vårdgivare B publicerad WSDL och
tjänstebeskrivning. Denna beskrivning ska följa profil enligt anvisning.

ANVISNING - 62 (87)
2007-12-20 REV A
25. Tjänst hos vårdgivare B loggar att åtkomst till vårddata har begärts genom en
loggningstjänst. Format på loggdata ska vara utformat enligt generellt loggformat.
26. Tjänst hos vårdgivare B ska nu genomföra kontroll om aktuell begäran kan tillåtas.
Kontroll sker genom att tjänst anropar lokal Åtkomstkontrolltjänst med de parametrar
som avgör åtkomst samt den SAML-biljett som ska finnas med i anrop enligt RIV
standard. Vid denna evaluering kommer tjänsterna för Samtycke och Vårdrelation
även kontrolleras som undertjänster till Åktkomstkontrolltjänsten.
a. Innan Åtkomstkontroll är klar ska förekomst av samtycke kontrolleras. Detta
ska framgå av det SAML-biljett som ingår i RIV anrop. Genom att
federationsstruktur finns etablerad mellan deltagare i samverkan kan
vårdgivare B:s samtyckestjänst ge sitt medgivande via att denna tjänst litar på
detta intygande om samtycke från vårdgivare A.
b. I detta fall antas samtycke inte föreligga. Detta kommer att innebära att
utlämnandehantering måste genomföras.
c. Innan Åtkomstkontroll är klar ska vårdrelation kontrolleras. Detta ska framgå
av det SAML-biljett som ingår i RIV anrop. Genom att federationsstruktur
finns etablerad mellan deltagare i samverkan kan vårdgivare B:s
vårdrelationstjänst ge sitt medgivande att vårdrelation existerar via att denna
tjänst litar på detta intygande om vårdrelation.
d. I detta fall antas vårdrelation föreligga, annars skulle tjänsten avslå begäran.
e. Nu kontrolleras om utlämnande får ske av aktuell informationsmängd. Detta
sker genom anrop av IT-tjänst för utlämnande.
i. Eftersom samtycke finns registrerat efter tidigare menprövning tillåter
utlämnandetjänst att aktuell information får utlämnas.
f. I detta fall svarar utlämnandetjänst JA till utlämnande.
g. Åtkomstkontroll hos vårdgivare B loggar att åtkomst till vårddata har beviljats
genom en loggningstjänst. Format på loggdata ska vara utformat enligt
generellt loggformat.
h. Åtkomstkontrolltjänst svarar att åtkomst är beviljad
27. Nu hämtas data från datalager upp innan nästa steg av kontroller.
28. Tjänst paketerar svarsmeddelande enligt definition i tjänstebeskrivning. Paketering
ska följa aktuell RIV-profil och tjänstebeskrivning.
29. Tjänst hos vårdgivare B loggar att svar med vårddata har avgivits. Detta sker genom
en loggningstjänst. Format på loggdata ska vara utformat enligt generellt loggformat.
30. Retur till Vårdgivare A:s tjänst enligt aktuell RIV-profil.
31. Labbsvar som finns registrerade hos Vårdgivare A och Vårdgivare B sätts ihop till en
gemensam lista som returneras till tillämpningen.
32. Tillämpning skapar bild över vårddata som ska visas för aktör.
33. Aktör får upp redigerad bild på sammanställning vårddata på sin arbetsyta.

ANVISNING - 63 (87)
2007-12-20 REV A
4.3.4. Typfall 3 Samverkan med okända vårdgivare
Detta typfall beskriver ett generiskt användningsfall för samverkan mellan två okända
vårdgivare. Typfallet identifierar också de komponenter/tjänster som behövs för att
samverkan ska vara möjlig.
Nils Nilsson är på besök hos Dr A som arbetar för vårdgivare A. Nils Nilsson har haft höga
blodfetter som han tidigare behandlas för hos andra vårdgivare. Vilka det är kommer Nils
inte ihåg. Nils Nilsson vet att de tog några prover och efter några dagar fick han läkemedel
som han inte kommer ihåg namnet på. Han vet inte vad det var för prover eller vilken
vårdgivare det var hos.
Aktör Komponent/Tjänst
Dr A loggar in i sin arbetsplats med hjälp
av e-ID kort och PIN-kod. Dr A
identifieras.
Dr A frågar Nils Nilsson om han får se det
som andra vårdgivare har registrerat i
deras informationssystem. Nils Nilsson
säger ja och Dr A får därmed samtycke att
se informationen.
Dr A har vårdrelation till Nils Nilsson
eftersom Nils Nilsson är bokad för besök
hos vårdgivare A.
Dr A använder en funktion i sitt lokala
system för att se patientens labbsvar.
Dr A kontrollerar hos vilka andra
vårdgivare Nils Nilsson har uppgifter. Dr
A får tillbaka en lista över externa
vårdgivare som har någon uppgift om Nils.
Ur denna lista kan Dr A välja ut vilka han
vill titta noggrannare på (B och C).
Vårdrelation kan
automatiskt ha räknats fram
genom att patienten bokat
tid hos vårdgivare A. Vid
bokningen skickades en
notifiering via
till
att
uppdragstagare hos
Vårdgivare A har
vårdrelation till patienten.
Tillämpningen som Dr A
använder kontrollerar att Dr
A har åtkomst till tjänsten.
Här kan det vara aktuellt
med någon form av
lokatortjänst (index över
patienter med information
hos olika vårdgivare). Dr A
ska på nått sätt få veta
vilken information i de
andras journaler som är
relevanta för just denna
vårdsituation
.
Hur kan detta göras i

Dr A får se information utanför
Vårdgivare A
Vårdtjänst hos Vårdgivare B får en
förfrågan om att visa patientens labbsvar.
Vårdtjänsten (B) loggar förfrågan.
Vårdtjänsten (B) kontrollerar att Dr A har
åtkomst till informationen genom att
• Kontrollera att Dr A har patientens
samtycke
• Kontrollera att Dr A har
vårdrelation till patienten
• Kontrollera att Dr A har
utlämnandebeslut på informationen
Vårdtjänst hos vårdgivare B skickar
tillbaka lista över patientens labbsvar
samtidigt som utlämnande av information
loggas.
Dr A får se patientens labbresultat från
vårdgivare B och kan med hjälp av den
informationen behandla patienten.
ANVISNING - 64 (87)
2007-12-20 REV A
praktiken?
Här kan det vara aktuellt
med tjänst för att fråga om
specifik och relevant del av
journal annars kan Dr A bli
översvämmad med
överflödig information som
inte är relevant för den
specifika situationen. Detta
behöver utredas vidare! Hur
kan Dr A selektera
information i journal hos
annan vårdgivare?
Interaktionsdiagram
Nedan beskrivs ett interaktionsdiagram för ”Sök labbsvar och läs hittade labbsvar”. Detta
mönster utgår från att det finns en applikationsserver som ligger mellan tillämpningen som
vårdpersonalen hos vårdgivare A använder och den nationella samverkanstjänsten hos
vårdgivare B. Skulle inte så vara fallet kommer de steg som utförs av applikationsserver att
flyttas ut till, och utföras av, klientdator hos vårdgivare A i stället.
Interaktionsdiagrammet förutsätter att:
• Patienten har lämnat sitt samtycke att vårdinformation får lämnas ut till vårdgivare A
• Aktör hos vårdgivare A har vårdrelation till patienten
• Vårdgivare B har avtal med Vårdgivare A på att aktör hos Vårdgivare A får komma åt
vårdinformation hos Vårdgivare B via gemensam BIF-kompatibel säkerhetstjänst.

ANVISNING - 65 (87)
2007-12-20 REV A
• Av autentiseringstjänst inom Vårdgivare A genererat SAML-biljett ingår i en med
åtkomstkontrollstjänst hos vårdgivare B gemensam CA-struktur.
• Profil som användes är utformad enligt anvisning
• Tjänstemäklare används inte i interaktionsmönster eftersom tillämpning och ITtjänster
i produktion antas känna till var aktuell tjänst finns
Detta interaktionsdiagram är hämtat från de typfall som generaliserats utifrån verkliga
användningsfall. Detta typfall behöver två interaktionsdiagram för sin redovisning.
Vårdgivare A Vårdgivare B
Tjänst hämta Indexerings-
Användare Arbetsyta Tillämpning Autentisering
labbsvar
tjänst
1 Inloggning
2 Autentisering
2a SAML
3 Visa patientens labbsvar
4 Hämta patientens labbsvar
5 Labbsvar hos andra vårdgivare?
Utelämnat är lokal
åtkomstkontroll och
loggning. Detta
beskrivs i gemensamt
interaktionsmönster
ovan.
21 Användare ser bild
20 Returnera labbsvar
Nationella
tjänster
Tjänst hämta
labbsvar
Åtkomstkontroll
(ÅKT)
Se sekvensdiagram
nedan för detaljer nr 5 till 12
Samtycke Vårdrelation Utlämnande Loggning
12 Vårdgivare B har fler labbsvar
13 Hämta labbsvar från Vårdgivare B
14 Logga anrop
15 Åtkomstkontroll
15a Finns samtycke?
15b svar Ja
15c Finns vårdrelation?
15d Svar Ja
15e Får utlämnande ske?
15f Svar Ja
15g Logga att åtkomst har beviljats
15h Svar Ja
16 Hämta data från datalager
16a Returnera data
17 Paketera meddelandet enligt RIV
18 Logga vilken information som lämnas ut till Vårdgivare A
19 Returnera labbsvar
Interaktionsmönster för fråga mot nationell indextjänst. Detta ingår som en del i
samverkansmönster 3. Detta är alltså en förstoring av punkterna 5 till 12.
Lagring

ANVISNING - 66 (87)
2007-12-20 REV A
Vårdgivare A Nationella tjänster
Användare Arbetsyta Tillämpning Autentisering
Tjänst hämta
labbsvar
Indexeringstjänst
Åtkomstkontroll
(ÅKT)
Samtycke Vårdrelation Utlämnande Loggning
1 Inloggning
2 Autentisering
2a SAML
3 Visa patientens labbsvar
4 Hämta patientens labbsvar
5 Labbsvar hos andra vårdgivare?
6 Logga anrop
Utelämnat är lokal
7 Åtkomstkontroll
7a Finns samtycke?
åtkomstkontroll och
7b svar Ja
loggning. Detta
beskrivs i gemensamt
7c Finns vårdrelation?
interaktionsmönster
7d Svar Ja
ovan.
7e Får utlämnande ske?
7f Svar Ja
7g Logga att åtkomst har beviljats
7h Svar Ja
8 Hämta data från datalager
8a Returnera data
9 Paketera meddelandet enligt RIV
10 Logga vilken information som lämnas ut till Vårdgivare A
11 Vårdgivare B har mer information
12 Vårdgivare B har mer information
13 Vårdgivare B har mer information
Stegvis beskrivning av flödet i interaktionsdiagrammet
Nedan beskrivs respektive steg i interaktionsdiagrammet som markerats med en siffra. Ord
med kursiv och fet still är samverkanskomponenter dessa finns beskrivna i kapitel 1.6.4.
I detta kapitel finns även koppling mellan RRR:er och respektive samverkanskomponent.
1. Aktör startar samverkansmönster genom inloggning till sin arbetsyta.
2. Identifiering av aktör ska ske med metod enligt anvisning.
k. I retur efter fullbordat anrop av autentiseringstjänst får aktör ett SAML-biljett
med utvalda attribut
3. Aktör begär att få titta på patientens labbsvar.
4. Lokaltillämpning anropar lokal tjänst hos vårdgivare A för att hämta labbsvar. Med i
denna begäran följer patient ID samt SAML-biljett enligt ovan.
5. Lokal samverkanstjänst anropar med nationell indextjänst för att hitta var labbsvar
finns för aktuell patient. För att kunna utföra anrop måste den lokala tjänsten göra ett
RIV WebService anrop enligt beskrivning i referens [RIVTA] med ett innehåll enligt
av Nationell Patient Översikt publicerad WSDL och tjänstebeskrivning. Denna
beskrivning ska följa anvisning.
För diagram över sekvensnummer 6-11 se diagram 2 för detta typfall.
6. Nationell indextjänst hos loggar att åtkomst till vårddata har begärts genom en
loggningstjänst. Format på loggdata ska vara utformat enligt generellt loggformat.
7. Nationell indextjänst ska nu genomföra kontroll om aktuell begäran kan tillåtas.
Kontroll sker genom att tjänst anropar lokal Åtkomstkontrolltjänst med de parametrar
som avgör åtkomst samt den SAML-biljett som ska finnas med i anrop enligt RIV
Lagring

ANVISNING - 67 (87)
2007-12-20 REV A
standard. Vid denna evaluering kommer tjänsterna för Samtycke och Vårdrelation
även kontrolleras som undertjänster till Åktkomstkontrolltjänsten.
a. Innan Åtkomstkontroll är klar ska förekomst av samtycke kontrolleras. Detta
ska framgå av det SAML-biljett som ingår i RIV anrop. Genom att
federationsstruktur finns etablerad mellan deltagare i samverkan kan Nationell
samtyckestjänst ge sitt medgivande via att denna tjänst litar på detta intygande
om samtycke från vårdgivare A.
b. I detta fall antas samtycke föreligga, annars skulle tjänsten avslå begäran.
c. Innan Åtkomstkontroll är klar ska vårdrelation kontrolleras. Detta ska framgå
av det SAML-biljett som ingår i RIV anrop. Genom att federationsstruktur
finns etablerad mellan deltagare i samverkan kan Nationell vårdrelationstjänst
ge sitt medgivande att vårdrelation existerar via att denna tjänst litar på detta
intygande om vårdrelation.
d. I detta fall antas vårdrelation föreligga, annars skulle tjänsten avslå begäran.
e. Nu kontrolleras om utlämnande får ske av aktuell informationsmängd. Detta
sker genom anrop av IT-tjänst för utlämnande.
f. I detta fall svarar utlämnandetjänst Ja till utlämnande.
g. Åtkomstkontroll hos nationell indextjänst loggar att åtkomst till vårddata har
beviljats genom en loggningstjänst. Format på loggdata ska vara utformat
enligt generellt loggformat.
h. Åtkomstkontrolltjänst svarar OK att lämna ut begärda data.
8. Nu hämtas data från datalager upp innan nästa steg av kontroller.
9. Nationell tjänst paketerar svarsmeddelande enligt definition i tjänstebeskrivning.
Paketering ska följa aktuell RIV-profil och tjänstebeskrivning.
10. Nationell tjänst loggar att åtkomst till vårddata har beviljats. Detta sker genom en
loggningstjänst. Format på loggdata ska vara utformat enligt generellt loggformat.
11. Retur av lista över var labbsvar finns returneras till Vårdgivare A:s tjänst enligt aktuell
RIV-profil. Denna retur kan även ske till en orkestrerande tjänst inom det nationella
tjänstelagret. Arbetet med att anropa alla platser som har data kommer i detta exempel
att ske lokalt hos vårdgivare A. Har retur skett till orkestrerande tjänst kan denna tjänst
utföra dessa anrop innan retur av hela dataunderlaget till tjänst hos vårdgivare A.
Beskrivning återgår nu till diagram 1 för detta typfall
12. Lokaltjänst hos vårdgivare A ser i svarslista att data finns hos vårdgivare B.
13. För att kunna utföra anrop måste lokaltjänst skapa ett RIV WebService anrop enligt
beskrivning i [RIVTA] med ett innehåll enligt av vårdgivare B publicerad WSDL och
tjänstebeskrivning. Denna beskrivning ska följa profil enligt anvisning.
14. Tjänst hos vårdgivare B loggar att åtkomst till vårddata har begärts genom en
loggningstjänst. Format på loggdata ska vara utformat enligt generellt loggformat.
15. Tjänst hos vårdgivare B ska nu genomföra kontroll om aktuell begäran kan tillåtas.
Kontroll sker genom att tjänst anropar lokal Åtkomstkontrolltjänst med de parametrar
som avgör åtkomst samt den SAML-biljett som ska finnas med i anrop enligt RIV
standard. Vid denna evaluering kommer tjänsterna för Samtycke och Vårdrelation
även kontrolleras som undertjänster till Åktkomstkontrolltjänsten.
a. Innan Åtkomstkontroll är klar ska förekomst av samtycke kontrolleras. Detta
ska framgå av det SAML-biljett som ingår i RIV anrop. Genom att
federationsstruktur finns etablerad mellan deltagare i samverkan kan
vårdgivare B:s samtyckestjänst ge sitt medgivande via att denna tjänst litar på
detta intygande om samtycke från vårdgivare A.

ANVISNING - 68 (87)
2007-12-20 REV A
b. I detta fall antas samtycke föreligga, annars skulle tjänsten avslå begäran.
c. Innan Åtkomstkontroll är klar ska vårdrelation kontrolleras. Detta ska framgå
av det SAML-biljett som ingår i RIV anrop. Genom att federationsstruktur
finns etablerad mellan deltagare i samverkan kan vårdgivare B:s
vårdrelationstjänst ge sitt medgivande att vårdrelation existerar via att denna
tjänst litar på detta intygande om vårdrelation.
d. I detta fall antas vårdrelation föreligga, annars skulle tjänsten avslå begäran.
e. Nu kontrolleras om utlämnande får ske av aktuell informationsmängd. Detta
sker genom anrop av IT-tjänst för utlämnande.
i. Eftersom det finns både samtycke och vårdrelation får information
utlämnas.
f. I detta fall svarar utlämnandetjänst JA till utlämnande.
g. Åtkomstkontroll hos vårdgivare B loggar att åtkomst till vårddata har begärts
genom en loggningstjänst. Format på loggdata ska vara utformat enligt
generellt loggformat. Nu hämtas data från datalager upp innan nästa steg av
kontroller.
h. Åtkomstkontrolltjänst svarar att åtkomst är beviljad
16. Nu hämtas data från datalager upp innan nästa steg av kontroller.
17. Tjänst paketerar svarsmeddelande enligt definition i tjänstebeskrivning. Paketering
ska följa aktuell RIV-profil och tjänstebeskrivning.
18. Tjänst hos vårdgivare B loggar att åtkomst till vårddata har beviljats. Detta sker
genom en loggningstjänst. Format på loggdata ska vara utformat enligt generellt
loggformat. Retur till Vårdgivare A:s tjänst enligt aktuell RIV-profil.
19. Labbsvar som finns registrerade hos Vårdgivare A och Vårdgivare B sätts ihop till en
gemensam lista som returneras till tillämpningen.
20. Tillämpning skapar bild över vårddata som ska visas för aktör.
21. Aktör får upp redigerad bild på sammanställning vårddata på sin arbetsyta.

ANVISNING - 69 (87)
2007-12-20 REV A
4.3.5. Typfall 4 Samverkan med externa aktörer (icke vårdgivare)
Detta typfall beskriver ett generiskt användningsfall för samverkan från en vårdgivare till en
icke vårdgivares tjänst. Denna tjänst är inte del av arkitekturen. Typfallet identifierar också de
komponenter/tjänster som behövs för att samverkan ska vara möjlig.
Karin och Nils Nilsson är på förlossningen med deras nyfödda dotter. Vårdpersonal A som
arbetar för vårdgivare A ska skapa ett personnummer för det nyfödda barnet.
Aktör Komponent/Tjänst
Vårdpersonal A loggar in i sin arbetsplats
med hjälp av e-ID kort och PIN-kod.
Vårdpersonal A identifieras.
Vårdpersonal A har vårdrelation till
nyfödda barnet eftersom barnet är
inskriven hos vårdgivare A.
Vårdpersonal A använder en funktion i sitt
lokala system för att skapa ett
personnummer för det nyfödda barnet.
Tillämpningen paketerar meddelandet
enligt RIV och utför ett anrop av en tjänst
på brygga.
Brygga omvandlar RIV anrop till
Skatteverkets protokoll och utför anrop av
Skatteverket.
Vårdpersonal A får tillbaka ett
meddelande som innehåller det nyfödda
barnets personnummer.
Tillämpningen som
Vårdpersonal A använder
kontrollerar att
Vårdpersonal A har
åtkomst till tjänsten (har
egenskapen barnmorska).
Interaktionsdiagram
Nedan beskrivs ett interaktionsdiagram för ”Registrera personnummer för nyfödd”. Detta
mönster utgår från att det finns en applikationsserver som ligger mellan tillämpningen som
vårdpersonalen hos vårdgivare A använder och tjänst publicerad som inte deltar i nationell
samverkan.
Interaktionsdiagrammet förutsätter att:
• Aktör hos vårdgivare A har vårdrelation till patienten
• Tjänstemäklare används inte i interaktionsmönster eftersom tillämpning och ITtjänster
i produktion antas känna till var aktuell tjänst finns

Användare Arbetsyta Tillämpning Autentisering
1 Inloggning
2 Autentisering
2a SAML
3 Skapa personnummer för nyfödd
Tjänst registrera
personnummer
4 Paketera meddelandet enligt RIV
5 Skapa personnummer för nyfödd
ANVISNING - 70 (87)
2007-12-20 REV A
Vårdgivare A Extern aktör A
14 Returnera resultat
15 Returnera resultat
16 Användare ser bild
Åtkomstkontroll
(ÅKT)
7 Åtkomstkontroll
7f Svar Ja
6 Logga anrop
Vårdrelation Loggning
8 Skapa personnummer för nyfödd
Gateway
Samma kontroller som
punkt 5 i gemensam
lokal åtkomstkontroll
11 Paketera meddelandet enligt RIV
12 Returnera resultat
13 Logga returnerat data
Tjänst registrera
personnummer
9 Paketera meddelandet enligt externa aktörens format
10 Skapa personnummer för nyfödd
10a Registrering lyckad
Stegvis beskrivning av flödet i interaktionsdiagrammet
Nedan beskrivs respektive steg i interaktionsdiagrammet som markerats med en siffra. Ord
med kursiv och fet still är samverkanskomponenter dessa finns beskrivna i kapitel 1.6.4.
I detta kapitel finns även koppling mellan RRR:er och respektive samverkanskomponent.
1. Aktör startar samverkansmönster genom inloggning till sin arbetsyta.
2. Identifiering av aktör ska ske med metod enligt anvisning.
a. I retur efter fullbordat anrop av autentiseringstjänst får aktör ett SAML-biljett
med utvalda attribut
3. Aktör registrerar uppgifter om vårdnadshavare.
4. Tillämpningen paketerar meddelandet enligt RIV
5. Lokaltillämpning anropar tjänsten ”Skapa personnummer” hos vårdgivare A för att
registrera vårdnadshavare.
6. Tjänst hos vårdgivare A loggar att anropet genom en loggningstjänst. Format på
loggdata ska vara utformat enligt generellt loggformat.
7. Tjänst hos vårdgivare B ska nu genomföra kontroll om aktuell begäran kan tillåtas.
Kontroll sker genom att tjänst anropar lokal Åtkomstkontrolltjänst med de parametrar
som avgör åtkomst samt det SAML-biljett som ska finnas med i anrop enligt RIV
standard. Vid denna evaluering kommer tjänsterna för Samtycke och Vårdrelation
även kontrolleras som undertjänster till Åktkomstkontrolltjänsten.
a. Innan Åtkomstkontroll är klar ska förekomst av samtycke kontrolleras. Detta
ska framgå av det SAML-biljett som ingår i RIV anrop.
b. I detta fall antas samtycke föreligga, annars skulle tjänsten avslå begäran.
c. Innan Åtkomstkontroll är klar ska vårdrelation kontrolleras. Detta ska framgå
av det SAML-biljett som ingår i RIV anrop.

ANVISNING - 71 (87)
2007-12-20 REV A
d. I detta fall antas vårdrelation föreligga, annars skulle tjänsten avslå begäran.
e. Åtkomstkontrolltjänsten loggar att åtkomst har beviljats genom en
loggningstjänst.
f. Åtkomstkontrolltjänst svara att åtkomst är beviljad.
8. Tjänsten anropar Brygga för att skapa personnummer .
9. Brygga ser till att utforma meddelandet enligt den externa aktörens format.
10. Brygga anropar tjänst hos extern aktör A enligt överenskommen format.
a. Den externa aktören utför sin uppgift och skickar tillbaka resultat av förfrågan
till Brygga
11. Brygga ser till att paketera resultatet enligt RIV-profil.
12. Retur till vårdgivare A:s tjänst enligt aktuell RIV-profil.
13. Tjänst hos vårdgivare A loggar med loggningstjänst resultat av utförd tjänst. Format
på loggdata ska vara utformat enligt generellt loggformat.
14. Retur till tillämpning från tjänst
15. Tillämpning skapar bild med resultatet som ska visas för aktör.
16. Aktör får upp resultatet på sin arbetsyta.

ANVISNING - 72 (87)
2007-12-20 REV A
4.3.6. Komponenter i arkitekturen
I detta kapitel summeras de olika komponenter som använts i ovanstående
samverkansmönster. För varje komponent ges en kort redogörelse för vad som krävs av
aktuell komponent och i förekommande fall finns hänvisning i vilken publikation som
detaljerad beskrivning finns. Även koppling till vilken RRR som stödjer aktuell komponent
finns för alla komponenter. Förteckning över samtliga RRR:er finns i VIT-boken.
Autentiseringstjänst
Autentiseringstjänsten har i uppgift att vid inloggning fastställa aktörens identitet samt
sammanställa och intyga dennes egenskaper i en e-underskriven biljett, som sedan kan
användas som underlag för rättighetsstyrning i övriga IT-tjänster.
En aktör kan vara en fysisk person eller IT-tjänst som behöver åtkomst till andra IT-tjänster.
Denna tjänst finns beskriven i [BIFTS] kapitel 4 IT-tjänst för autentisering.
Tillämpliga RRR:er TS1, TS5
E-tjänstekort
För att följa regler i lagar och möjliggöra ett säkert identifieringssätt för samverkan ska
identifiering göras med hjälp av PKI-baserad inloggning. Den form av godkänd PKI-baserad
inloggning som gäller för hälso- och sjukvårdpersonal är inloggning med ett E-tjänstekort.
Beskrivning finns i [BIFTS] kapitel 4.5 KA 3. Även SITSH modellen definierar hur detta ska
utföras. SITHS infrastrukturen finns sammanfattad i referens [SITHS].
Tillämpliga RRR:er TS1
SAML-biljett
SAML (Security Assertion Markup Language), standard från OASIS (Organization for the
Advancement of Structured Information Standards), är ett standardiserat sätt att definiera och
utbyta autentiserings-, attribut- och åtkomstkontrollsinformation i eXtensible Markup
Language (XML) format. Den huvudsakliga uppgiften är att tillhandahålla standardiserad
interoperabilitet mot autentiserings- och åtkomstkontrolltjänster
Det är för samverkan av största vikt att de i [BIFTS] kapitel 13 specificerade innehållet och
hanteringen av SAML-biljetter följs. Samverkan ställer även krav på att det i de påståenden
som finns i biljetten ingår om uppgift om vårdrelation och/eller samtycke föreligger i aktuellt
fall. Innehåll i denna biljett finns beskrivet i [BIFTS] kapitel 13.4 Biljetbeskrivning och
kapitel 13.5 SAML. Användningen av biljetten finns beskriven i [BIFTS] kapitel 13.6 och
13.7.
Tillämpliga RRR:er TS1
Federationsstruktur
En av grundstenarna för att säkerheten inom arkitekturen ska fungera är att samtliga
samverkansparter deltar i utgivning av certifikat enligt SITHS. SITHS arbetet finns beskrivet i
[SITHSP] och [SITHRA].
Genom att alla BIF säkerhetssystem är med och accepterar certifikat utfärdade inom SITHS
samarbetet kan en signerad SAML-biljett i ett signerat meddelande från en certifierad ITtjänst/komponent
accepteras och användas av en certifierad IT-tjänst/komponent.

ANVISNING - 73 (87)
2007-12-20 REV A
Meddelandet inkluderande SAML-biljetten signerat med SITHS-certifikatet för avsändande
IT-tjänst/komponent Dokumentation av att en vårdgivare (landsting) deltar i SITHS
samarbetet ska uttryckas i ett RAPS (Registration Authority Practise Statement) dokument se
ref. [SITHRA].
Tillämpliga RRR:er TA2, TS5
Brygga
När en nationell samverkanstjänst behöver hämta data från tjänster som inte ingår i den
nationella arkitekturen bör koppling mot detta externa system skötas av en för ändamålet
specifik brygga. På ena sidan finns det samverkanstjänster definierade och på ”baksidan”
finns anrop enligt den standard som aktuell extern partner använder. Detta gör att det endast
är brygga-tjänsten som behöver kunna det och det icke RIV standardiserade protokollet.
Denna designmall finns beskriven för SHS-sfären.
Tillämpliga RRR:er TA1, TA2, TA3, TA3, TS1, TS2, TS3, TS5, TK1, TK2, TD1,
TM1
Indexeringstjänst
I typfall 3 behövs en tjänst som kan peka ut var data finns om aktuell patient. Denna tjänst är i
sig själv en samverkanstjänst. Denna tjänst levererar inte patientdata utan ger lista över var
patientdata förekommer som svar.
Tillämpliga RRR:er TA1, TA2, TA3, TS1, TS2, TS3, TS5, TK1, TK2, TD1, TM1,
TÖ1
Loggningstjänst
För att uppfylla lagar och ge möjlighet till uppföljning ska samtliga delar i arkitekturen utföra
loggning av adekvat data. Loggning ska minimum ske vid de punkter som angivits i
samverkansmönster. Loggning ska utföras enligt beskrivning i [BIFTS] kapitel 11. Format för
loggmeddelande finns beskrivet i [NARRR LOGG].
Tillämpliga RRR:er TS2, TS5
Nationell tillämpning
I de fall som samverkanskomponent även har ett gränssnitt till aktören (GUI) ska detta vara
byggt enligt arkitekturen. Denna komponent finns inte för de flesta samverkanstjänster utan
blir bara aktuell när även en användardialog ingår i det av nationella samverkan erbjudna
lösningen. Normalt ska denna användardialog exponera ett antal underliggande nationella
samverkanstjänster.
Tillämpliga RRR:er TA3, TS2, TS3, TS5, TK1, TK2, TD1, TM1, TÖ1
Notifieringstjänst
Genom att t.ex. vid användning av tjänst för utlämnande så kommer svaret inte synkront med
begäran om utlämnande. Det gör att någon annan funktion måste användas för att nå
avsändare med information om fattat beslut. BIF Notifieringstjänst ger denna möjlighet att
notifiera avsändare och mottagare i denna typ av situation. Detta utan att sändare behöver
känna till mottagare eller sätt som mottagare ska notifieras på. Notifieringstjänsten ska även
garantera att notifiering sker på ett korrekt sätt vad avser:

ANVISNING - 74 (87)
2007-12-20 REV A
• Säkerhet
• Signering
• Garanterad/oförsäkrad leverans
• Säker/osäker leverans
• Kvittens
Meddelandeordning Notifiering är en semantiskt lös koppling och bör därför endast användas
inom en samverkansdomän. Mellan vårdgivardomäner och nationella domänen används
semantiskt kompletta tjänsteinteraktioner av typen Uppdrag-Svar för att uttrycka asynkrona
tvåvägskontrakt. Denna tjänst finns beskriven [BIFTS] kapitel 10.
Tillämpliga RRR:er TK3
RIV WebService anrop
I [RIVTA] (RIV tekniska anvisningar) finns det definierat hur anrop ska göras och hur
innehåll ska specificeras. I de av NARRR definierade samverkansmönstren användes RIVanrop
med data formaterat enligt [RIVHL7] (RIV). Även andra kommande profiler i RIV
kommer kunna användas. En viktig hörnsten för RIV-anrop är Webbservice och XML
anknutna standarder, se [RIVTA] kapitel 4.
En annan mycket central del är hantering av SAML-biljetten. Genom att alla
samverkansmönster kräver att en SAML-biljett finns krävs det att denna biljett förs över i
RIV-header enligt beskrivning i [RIVTA] kapitel 4.1.1.
Tjänster beskrivs dels genom WSDL och XSD-definitioner för tjänst och refererade
meddelandeformat, dels genom tjänstebeskrivningen som ska finnas för alla nationella tjänster
[RIVTV]. Nationellt normerade WSDL-filer anger bindning men saknar adress till
anslutningspunkt (”service port”). De tillförs i samband med realisering av konsument, som i
normalfallet refererar en virtuell tjänst i nationella tjänsteplattformen. Den senare har
dynamiskt uppslag via vägvalstjänst.
Tillämpliga RRR:er TA2, TA3,TS5, TK1, TK2, TD1, TM1,
RIV Web-service svarsmeddelande
När svarsmeddelande ska skapas och skickas med i svar från en RIV Webbservice ska aktuell
RIV profil användas som definierats för tjänst i tjänstebeskrivning. I RIV kan det finnas flera
olika profiler. Ett exempel på profilbeskrivning finns beskriven i [RIVHL7].
Tillämpliga RRR:er TM1
Samtyckestjänst
Samtyckestjänsten ger svar på om patient eller närstående lämnat sitt samtycke eller ej till att
vårdinformation lämnas ut mellan hälso- och sjukvårdsorganisationer. Samtycket kan vara
begränsat till vilka som kan ta del av vårdinformationen samt ha en begränsad giltighetstid.
Patienten kan endast ge samtycke till egen information. Detta finns beskrivet i [BIFTS]
kapitel 6.
Denna tjänst ligger normalt dold inuti Åtkomstkontroll tjänsten. För samverkans arkitekturens
lösningar antas påstående om samtycke komma inpackat i SAML-biljett. Detta medför att för
samverkanstjänster är kontroll av om samtycke finns eller ej endast att kontrollera innehållet i
SAML-biljetten.

Tillämpliga RRR:er TS1, TS3
ANVISNING - 75 (87)
2007-12-20 REV A
Samverkanstjänst
Tjänst inom arkitekturen som helt följer uppsatta RRR:er och därmed är utformad
informatiskt och tekniskt enligt uppsatta regler. Detta gäller även anslutning till övriga
funktioner inom den nationella arkitekturen som t.ex. säkerhetstjänster inom BIF [BIFTS].
Dokumentation av gränssnitt såväl tekniskt som textuell ska följa definierade RRR:er
Tillämpliga RRR:er TA2, TA3, TA4, TS2, TS3, TS5, TK1, TK2, TM1
Tjänstebeskrivning
Strikt definierad dokumentation av hur nationella samverkanstjänst ska användas. I
beskrivning ingår teknisk beskrivning av Webbservice som WSDL och XML-schema för
datadel. Till detta ska det finnas en tydlig textuell beskrivning som beskriver tänkt
användningsområde, informationsmässigt innehåll samt beskrivning hur fel och avvikelser
ska hanteras.
Tillämpliga RRR:er TD1, TM1
Utlämnandetjänst
Syftet med tjänst för utlämnande är att möjliggöra utlämnande av vårdinformation efter
prövning av behörigt utlämnande. Tjänstens ansvar är att motta begäran om utlämnande av
vårdinformation och att ge prövande individ möjlighet att registrera beslut om utlämnande.
Tjänst finns beskriven i [BIFTS].
Beslut efter genomförd prövning meddelas aktör via notifieringstjänst enligt [BIFTS].
Tillämpliga RRR:er TS4, TS5
Vårdrelationstjänst
Syftet med tjänsten är att administrera respektive intyga att hälso- och sjukvårdspersonal har
vårdrelation till patient. Registrering av vårdrelation utförs manuellt. Denna tjänst ligger
normalt dold inuti Åtkomstkontroll tjänsten. För samverkans arkitekturens lösningar antas
påstående om vårdrelation komma inpackat i SAML-biljett. Detta medför att för
samverkanstjänster är kontroll av om vårdrelation finns eller ej endast att kontrollera
innehållet i SAML-biljetten.
Tillämpliga RRR:er TS1, TS3
Åtkomstkontrolltjänst
För alla resurser som deltar i samverkan gäller att de ska skyddas av BIF baserad
åtkomstkontroll. Hur denna fungerar finns beskrivet i [BIFTS] kapitel 5. Åtkomstkontroll ska
vara enligt [BIFTS].
Det finns attribut som på nationell nivå definieras som föremål för styrning av access till BIF
skyddade resurser. Åtkomststyrning ska ske enligt ABAC (Attribute Based Access Control)
se [BIFER] kapitel Egenskapsbaserad rättighetshantering.
Tillämpliga RRR:er TS1, TS3

ANVISNING - 76 (87)
2007-12-20 REV A
Tjänstevirtualisering
All samverkan i arkitekturen sker via virtuella tjänster publicerade i den nationella
tjänsteplattformen. Det ger en fast, organisationsoberoende anslutningspunkt för alla
samverkande vårdgivare. Detta gäller även kommunikation mellan tjänstekomponenter inom
den nationella samverkansdomänen.
Tillämpliga RRR:er TA5
Vägvalstjänst
Vägvalstjänsten är en grundkomponent i domänarkitekturen, som föreskrivs för den nationella
domänen. Vägvalstjänsten konsulteras av virtuella tjänster publicerade av tjänsteplattformen, i
syfte att översätta ett in-meddelande i ett tjänstekontrakt till en den anslutningspunkten för
den tjänstekomponent som är mottagare för meddelandet. När tjänstekomponenten inte är en
nationell anslutning, behöver konsumenten av den virtuella tjänsten ange HSA-id för
utförande enhet. Vägvalstjänsten har tillgång till tabellverk för att dynamiskt översätta HSAid
och format på in-meddelande till av vårdgivare anvisad anslutningspunkt. Detta HSA-id
måste finnas i RIV-header.
Tillämpliga RRR:er TA6
Katalog över nationella tjänsteinteraktioner
Alla standardiserade tjänsteinteraktioner finns katalogiserade i en nationell katalog. Katalogen
avspeglar uppdelningen i tjänstedomäner. Katalogen stödjer projekt med
implementationsobereonde WSDL:er och XSD:er. Alla anslutningspunkter hos vårdgivare är
registrerade i nationella vägvalstjänsten. Vårdgivare behöver bara känna till den generella
anslutningspunkten till nationella tjänsteplattformen. Katalogen är m.a.o. ett hjälpmedel för
projekt under konstruktionsarbetet, men har ingen aktiv roll under pågående
meddelandetrafik.
Tillämpliga RRR:er TA7

ANVISNING - 77 (87)
2007-12-20 REV A
4.4 Realisering av tjänsteplattform 22
Ett vanligt sätt att realisera denna typ av integration är att införa en tjänsteplattform för hur
alla producenter publicerar sina tjänster samt hur konsumenter upptäcker och använder de
eftersökta tjänsterna.
Den nationella tjänsteplattformen bör innehålla minst följande komponenter:
1. Vägvalstjänst
2. Tjänstevirtualisering
3. Katalog över nationella tjänsteinteraktioner
Med tjänstevirtualisering avses principen att alla nationella tjänstekontrakt – oavsett antal och
geografisk spridning av realiserande producenter – uppträder som en virtuell, nationellt
realiserad tjänsteproducent per kontrakt. En vårdgivares anrop av en tjänst hos en annan
vårdgivare sker via nationella tjänsteplattformens virtuella version av kontraktet.
Tjänsteplattformen använder sedan vägvalstjänsten för att hitta och vidarebefordra till den
verkliga tjänsten.
Virtualiseringen kan skapas så snart kontraktet är fastställt. Vägvalstjänstens register
uppdateras sedan löpande allt eftersom vårdgivare vill ansluta lokala tjänsteproducenter för
nationell samverkan. Detta ger fördelar såsom att omorganisation, systemkonsolidering och
andra händelser som har inverkan på lokala anslutningspunkter, enbart innebär uppdatering av
vägvalstjänstens register.
Referensarkitekturen ställer inga krav på lokal instansiering av tjänsteplattformen. Om så
ändå sker, uppstår ett antal fördelar så väl nationellt som lokalt.
Lokala fördelar:
- Punkt-till-punkt-problematik mellan vårdgivarens lokala system kan undvikas,
enligt samma principer som tillämpas nationellt.
- Det nationellt virtualiserade tjänsterna uppträder som lokala, vilket gör att lokala
konsumenter kan konsumera interna tjänster och nationella samverkanstjänster på
samma sätt – d.v.s. genom att vända sig till den lokala tjänsteplattformen.
Nationella fördelar:
- Antalet anslutningspunkter att konfigurera i nationella tjänsteplattformens
vägvalstjänst minskar och därmed också antalet potentiella uppdateringar vid
konsolidering av en vårdgivares IT-stöd.]
Det innebär att en nationell domän, gemenskapsdomäner och vårdgivardomäner bildar en
federation av samverkansdomäner enligt bilden nedan.
22
Vi har här valt att använda ett teknikneutralt begrepp för att inte hamna i diskussion om enskilda produkter
eller teknologier.

NPÖ
NPÖ
Vårdsystem
NPÖ NOD QDB ...
Vårdgivaredomän
Vårdgivare A
BIF
tjänster
NOD
NOD
Vårdsystem
(ett eller flera)
NPÖ NOD QDB ...
Vårdgivaredomän
Vårdgivare B
Vården på Webben
NPÖ NOD TID ...
ANVISNING - 78 (87)
2007-12-20 REV A
Tjänsteplattform
PAS
TID
Kvalitetsregister
QDB
PAS
TID
Nationell
tidbok
TID
Vårdsystem
(ett eller flera)
NPÖ NOD QDB ...
Tjänsteplattform Tjänsteplattform
Gemenskapsdomän
Vårdgivare C, D, E
Omsorgsgivare Y, Z
Figur 35 - Teknisk realisering med tjänsteplattform
Framtida
nationella
applikationer
...
Brygga
Vägvalstjänst
HSA
tjänster
BIF
tjänster
BIF
tjänster

Bilaga 1 – Säkerhet
ANVISNING - 79 (87)
2007-12-20 REV A
En av de återstående och högt prioriterade uppgifterna med att få VIT-bokens tekniska
arkitektur komplett är att utvidga och beskriva området säkerhet. De bärande principerna för t
ex delning av information, säkerhet etc. bör vara centralt i dokumentet och lyftas fram
ordentligt. Några exempel som bör hanteras i fortsatt arbete:
• Ska en operatör på en central driftanläggning över huvud taget kunna ha möjlighet att
kunna ta del av innehåll i meddelanden och databaser?
• Om det ej går att undvika, vilket det borde, hur görs annars teknisk personals access
spårbart, dvs. när man inte går via tjänsternas vanliga gränssnitt? Förklaras tekniskt
och administrativt.
• Hur hindrar man att uppgifterna tankas ut och säljs till försäkringsbolag eller
underrättelseorganisationer i en framtid?
• Hur uppfyller man andemeningen i patientdatalagen så som förslaget ser ut? Vilken
beredskap har vi för olika scenarier, dvs. olika tänkbara slutliga formuleringar i lagen?
• Ska vi över huvud taget lagra identifierbara data på ett fysiskt sammanhållet sätt utan
att alla frågor av denna typ är utredda ordentligt?
Beslut som kan misstänkas vara kontroversiella ska formuleras och lyftas upp till beslut av
kravställare.
Även viktiga principer för certifiering och säkerhet måste beaktas inom helheten i
dokumentet. Säkerheten skall kopplas till den stegvisa beskrivningen i framtagna
användningsfall för att öka förståelse och visa användningssätt.
Nedan finns utdrag från BIFTS (BIF tekniska specifikationer 1.0) och RIVTA (RIV tekniska
anvisningar 1.0), samt lite kompletterande text kring denna typ av säkerhet. Följande syftar
till att ge en förståelse för säkerhetsområdet men har inte bearbetats av NARRR-gruppen utan
kommer att hanteras i ett fortsatt arbete.
Säkerhet utifrån BIF och RIV
Ett centralt begrepp i sammanhanget är tillit och det gäller hela kedjan från att information
skapas av en aktör till att en annan aktör någon annanstans i Sverige utnyttjar denna
information för vård och omsorg. Både en tillit till att informationen är oförvanskad och en
tillit till att den enbart delges enligt regelverket inlagt i [BIFTS].
Säkerhetsmässigt bär varje IT-tjänst själv hela ansvaret för att inte någon obehörig kan ta del
av den service som tjänsten levererar [RIVTA] genom tolkning av fråga och biljett samt att
när tjänsten i sin tur ställer frågor rätt biljett binds till frågan.
Tilliten blir beroende av en kedja av certifierade IT-tjänster/komponenter och en säker
kommunikation mellan dessa.
Varje IT-tjänst/komponent skall vara certifierad av en betrodd och utsedd tredje part,
”certifieringsinstitut”, enligt fastställd anvisning med alla krav på en IT-tjänst/komponent.
Bland stora mängden krav tre exempel: Kontroll av funktionaliteten i IT-tjänstegränssnittet
och funktionen i eventuell konsumtion av andra IT-tjänstegränssnitt, vara övervakningsbar
(tex. svarstid per vårdgivare som utnyttjar tjänsten) med generella verktyg, samtidig kunna
hantera flera versioner av sitt IT-tjänstegränssnitt.

ANVISNING - 80 (87)
2007-12-20 REV A
Någon certifieringsansvarig organisation certifierar tjänsten när den är driftsatt av en
driftansvarig organisation. Om alla fastställda regler är uppfyllda beställer lämpligen den
certifieringsansvariga organisationen ett HCC funktionscertifikat till den certifierade ITtjänsten/komponenten
för aktuell vårdgivare eller myndighet som tar ansvar för helheten och
med angivande av bl.a. aktuell IT-tjänstetyp och instans av tjänsten i certifikatet . Lämpligen
signeras totala koden för IT-tjänsten/komponenten i samband med certifieringen.
Certifierade IT-tjänster läggs lämpligen upp i en katalog med sina egenskaper.
Två bilder från BIF [BIFTS], både exekverande och browserbaserad arbetsplats, illustrerar
situationen.
Figur 36 – Biljett-fasad-klientsamverkan

ANVISNING - 81 (87)
2007-12-20 REV A
Figur 37 – Samverkan i webklient
Tre nivåer av undertecknande / signaturer kan urskiljas. Signaturer ger både
förändringsskydd och oavvislighet.
• e-undertecknande vid skapande av information. Denna signatur följer informationen
och garanterar att den inte förvanskats efter aktörens godkännande. Information som
e-undertecknats kan verifieras vid läsning på en arbetsplats eller av en
sammanställande certifierad tjänst.
• Meddelandesignatur. Vid informationsutbytet signeras de uppgifter som beskriver
meddelandeinteraktionen. Det är meningen att dessa uppgifter och signaturen skall
sparas.
• Transportsignering. Denna yttre signatur garanterar för mottagaren att informationen
överförts oförvanskad och behöver inte sparas efter det att mottagaren kontrollerat
signaturen. Denna signatur möjliggör snabba passager in genom en firewall som kan
avgöra att meddelandet kommer från en betrodd part (signerat med HCC funktion) och
att meddelandet är intakt (t.ex. ingen skadlig kod smugits in) Signaturen ger också den
bindning mellan fråga och biljett som behövs för att IT-tjänster/komponenter skall
kunna garantera respektive lita på att de hör ihop.
Säker kommunikation enligt fastställd anvisning mellan IT-tjänster men även till arbetsplats
Den säkra kommunikationen omfattar all kommunikation dvs. även kvittenser och
felhanteringsmeddelanden.

ANVISNING - 82 (87)
2007-12-20 REV A
Figur 38 – SOA-tjänst kompletterat med säkerhetsfunktionalitet (signering, kryptering)
För att säkerställa att ett meddelande inte förvanskats och för att erhålla oavvislighet signeras
meddelanden med XML-Signature i WS miljö enligt WS-Security. IT-tjänsten/komponenten
skall alltid kontrollera och verifiera signaturen och tanken är att fasaden utför detta. Om
meddelandet förses med insynsskydd genom kryptering används XMLEncryption i WS miljö
enligt WS-Security. Fasaden innehåller även funktionalitet för kryptering och dekryptering.
För att upprätthålla tillitskedjan krävs som nämnts tidigare en signering som binder ihop fråga
och biljett. I webläsarfallet, se bild 37, hanteras säkerheten mellan arbetsplats och certifierad
portal med SSL. Lokalt kan annat transportprotokoll än WS användas men i övrigt samma
krav.
I förvaltningen av nationella regler och anvisningar kommer val av protokoll att följa
utvecklingen av vilka protokoll som är mest accepterade och väl profilerade. Viktigt är att
säkerhetsmekanismerna kommer att ingå även i dessa.

Bilaga 2 – Referenser
ANVISNING - 83 (87)
2007-12-20 REV A
BIFER BIF Rapport BIF-ER__0_6.doc Ej publicerad
BIFTS BIF, Bastjänster för InformationsFörsörjning, Tekniska specifikationer Version
1.0 Juni 2007
LOGG2 Generellt loggformat Exempel från SLL SLLs loggmeddelande version 1.04.xsd,
Beskrivning av meddelandeformat för logginformation version 1.1.doc
NARRR- NARRR mall för loggmedelande i XML. Återstår att skriva.
LOGG
NARRR- NPÖ Beskrivning av indextjänst för patientdata. Återstår att skriva.
NPÖ
NARRR- NARRR Terminologi Version PA6 – REMISSUTGÅVA, 2007-12-16
TERM
ODP För en introduktion till detta synsätt och tillgång till grundstandarderna hänvisas
till www.rm-odp.net.
RIVHL7 RIV HL7 v3.profil, Regelverk för interoperabilitet inom Vård och Omsorg
Version 1.0
RIVTA RIV – Tekniska anvisningar, Regelverk för interoperabilitet inom Vård och
Omsorg Version 1.0
RIVTB RIV Mall för tjänstebeskrivning. Återstår att skriva.
SITHS SITHS Infrastruktur för informationssäkerhet i hälso- och sjukvården. Version
2000-05-15
SITHSP SITHS Policy – SITHS Certifikatspolicy för utgivande av certifikat inom vård
och omsorg
SITHSRA SITHS RA Policy För utgivande av Tjänstecertifikat

Bilaga 3 – Ordlista
ANVISNING - 84 (87)
2007-12-20 REV A
Ordlistan nedan beskiver använda termer och förkortningar. Ordlistan är ett komplement till
en utförligare terminologi som tagits fram som en del av arbetet med den nationella
arkitekturen [NARRR-TERM].
Tillämpning Del av ett system som används av en aktör genom ett
användargränssnitt.
Arbetsyta Den funktion i aktörens arbetsplats som tillhandahåller och utför:
- Autentisering och inloggning
- Single sign on
Start av tillämpningar (t.ex. klinisk portal, journalsystem)
Tjänstekontrakt Kontrakt som beskriver de gränssnitt som förekommer mellan
komponenter i arkitekturen
Carelink PLUS Plattformsutveckling i Sverige. Beskrivning av en
referensarkitektur och några basala tjänster utvecklade av ett
projekt avslutat 2004 där beställare och leverantörer gemensamt
deltog.
HL7 Health Level 7. En av det amerikanska ANSI ackrediterad
standardiseringsorganisation som fastställt en familj av standarder
för datautbyte mellan applikationer i vården.
NPÖ Nationell Patientöversikt. Projekt som drivs av Carelink på
uppdrag av beställarorganisationen, se www.carelink.se
RIV Regelverk för Interoperabilitet inom Vård och omsorg: Ett
fastställt regelverk för vård och omsorg för att säkerställa
interoperabilitet mellan olika vård- och omsorgssystem, för att
underlätta ett strukturerat elektroniskt informationsutbyte.
Regelverket består av övergripande riktlinjer och
metodanvisningar för att ta fram informationsspecifikationer för
varje informationsmängd (meddelande), för att uppnå semantisk
interoperabilitet, samt tekniska anvisningar för att uppnå teknisk
interoperabilitet.
RRR RRR dvs. Regler, Riktlinjer och Rekommendationer där Regler
motsvaras av SKALL krav, Riktlinjer av BÖR krav och
Rekommendationer motsvarar KAN.
Tjänsteproducent Den som tillhandahåller en tjänst. I dagligt tal används ofta ordet
Tjänst när man egentligen menar Tjänsteproducent. En tjänst kan
produceras av flera landsting och leverera samma
svarsmeddelande dock från olika system.
Tjänstekonsument Den som begär av tjänsteproducenten att tjänsten utförs.
Tjänsteplattform Plattform för att ansluta, hitta, förmedla, övervaka och
administrera tjänster.
V-TIM Verksamhetens Tillämpade Informations Modell. Carelinkprojekt
för att utveckla en övergripande informationsmodell beskriven på

ANVISNING - 85 (87)
2007-12-20 REV A
ett sätt så att verksamhetsföreträdare skall kunna förstå den
Åtkomstkontroll Tillämpning av regler för åtkomst till en specifik aktivitet på ett
målsystem.

RAPPORT 86(87)
2007-12-20 REV A
Bilaga 4 – Metodskiss för användningsfall
Verksamhet Teknik
Användningsfall
Doktr A i Landstinget A har träffat patienten Nils Nilsson och skall
skriva en journalanteckning och ordinera läkemedel för rosfeber.
Användningsfall
Vid datorn på sin expedition identifierar Dr A sig via
Doktr A i Autentiseringstjänsten Landstinget A har träffat med patienten sitt e-ID Nils kort Nilsson och dess och PIN-kod. skall
skriva en journalanteckning och ordinera läkemedel för rosfeber.
Han får då tillgång till en vårdtjänst. Han anger där patientens
Användningsfall
Vid datorn personnummer på sin expedition och via identifierar Åtkomstkontrolltjänsten Dr A sig via (ÅKT) får han
Doktr Autentiseringstjänsten A i Landstinget möjlighet A att har skriva träffat med ny sitt patienten text. e-ID Han kort Nils för och Nilsson in dess aktuella PIN-kod. och observationer.
skall
skriva en journalanteckning ………………………………..
och ordinera läkemedel för rosfeber.
Han får då …………………...
tillgång till en vårdtjänst. Han anger där patientens
Vid datorn personnummer på sin expedition och via identifierar Åtkomstkontrolltjänsten Dr A sig via (ÅKT) får han
Autentiseringstjänsten möjlighet att skriva med ny text. sitt e-ID Han kort för in och aktuella dess PIN-kod. observationer.
………………………………..
Han får …………………...
då tillgång till en vårdtjänst. Han anger där patientens
personnummer och via Åtkomstkontrolltjänsten (ÅKT) får han
möjlighet att skriva ny text. Han för in aktuella observationer.
………………………………..
…………………...
Mappas mot
Härleds från
Typfall
Doktor A i Landstinget A har träffat patienten Nils Nilsson
och skall skriva en journalanteckning och ordinera
läkemedel för rosfeber.
Vid datorn på sin expedition identifierar Dr A sig via
Autentiseringstjänsten med sitt e-ID kort och dess PIN-kod.
Han får då tillgång till en vårdtjänst. Han anger där
patientens personnummer och via Åtkomstkontrolltjänsten
(ÅKT) får han möjlighet att skriva ny text. Han för in aktuella
observationer.
Dr A ska därefter ordinera läkemedel. Förnyad kontroll
(osynligt för användaren) i Åtkomstkontrolltjänsten ger
honom tillträde till en läkemedelstjänst, utan att ny
inloggning behöver göras dvs det blir en funktionell singlesign-on
(SSO).
Genom Säker Patientkontexttjänsten aktiveras automatiskt
aktuell patient i Läkemedelstjänsten. Dr A ordinerar
läkemedlet, undertecknar receptet elektroniskt och
aktiverar säker e-förmedling av receptet.
In- och utloggningen, och allt Dr A läst och gjort däremellan,
loggas till Loggtjänsten.
Doktor A
Landsting A
«uses»
«uses»
«uses»
Inloggning
Registrera
vårdinformation
Ordinera läkemedel
«extends»
Hämta
läkemedelslista
Underlag för
Härleds från
V (Arksam, Verksamhetsgrupp) T (NARRR)
Funktionella krav i verksamhetens formuleras i användningsfall.
Användningsfallen mappas mot typanvändningsfall.
Användningsfallen förvaltas av V.
Typanvändningsfallen ses som en representation av verksamhetens krav.
Typanvändningsfallen syftar till att vara generiska och ska beskriva en generalisering av specifika användningsfall.
Ett typanvändningsfall ska kunna representera ett flertal användningsfall. Typanvändningsfall kan behöva
underliggande typanvändningsfall för att närmare konkretisera användningsfall.
I de fall V har identifierat användningsfall som inte kan mappas mot ett befintligt typanvändningsfall tas nytt
typanvändningsfall fram i samarbete mellan V och T.
I typanvändningsfallen ska aktör/intressent anges.
Typanvändningsfall bör dokumenteras kortfattat textuellt samt grafiskt.
Typanvändningsfall förvaltas av T. Initialt tar T fram några typanvändningsfall som utgångspunkt i eget arbete.
Dessa ska delges V så fort som möjligt för att valideras.
Sekvensdiagram
Nationella
säkerhetskrav?
Övriga krav?
Underlag för
Valideras mot
Referensarkitektur
Samverkansarkitektur
VIT-boken
I diskussion med V mappas användningsfallen mot typanvändningsfall. Dessa
ligger till grund för arbete med VIT-bok, referensarkitektur och
samverkansarkitektur.
Sekvensdiagram kan användas för en första nedbrytning av typanvändningsfallen
i syfte att identifiera behov av tjänster, interaktionsmönster m.m.

RAPPORT - 87 (87)
2007-12-20 REV A
Bilaga 5 – Målnedbrytning av Nationell IT-strategi för Vård och Omsorg