...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
| T-bokens tekniska arkitekturStyrande principer, vägledande exempel och teknisk referensarkitektur för vård och omsorg Revision CD ARK_0019 20192020-0212-2008 |
Förord
Den första utgåvan av tekniska arkitektur, populärt kallad för T-boken, togs fram ensidigt av landstingsrepresentanter och speglade därmed i huvudsak landstingsperspektivet för vård och omsorg.
T-boken kommer att vara ett av underlagen när Arkitektur och regelverk inom Inera granskar de nationella projekt och förvaltningsobjekt som pågår för att realisera strategin för nationell eHälsa. En stor fördel som har uppnåtts genom medverkan från kommunrepresentanter är därmed den ökade möjligheten att de nationella projekten och förvaltningsobjekten inom ramen för Inera på sikt även följer en teknisk arkitektur som passar kommuner.
Utgångspunkten för arbetet med den tekniska arkitekturen har varit vård och omsorg. T-boken är en del av det arbete som drivs inom Arkitektur och regelverk inom Inera.
Förord till Revision
...
Revision B av T-boken utkom i februari 2011. Delar av innehållet har blivit inaktuellt, och ett stort antal referenser är inte längre giltiga. Revision C skall ses som en rättningsversion, med relativt begränsade förändringar. Mycket lite nytt material har tillkommit.
En översikt av det som förändrats:
- Revision C publiceras som ett Confluence-dokument.
- Logotyper har bytts ut.
- Texter i fotnötter har inkluderats i den löpande texten.
- Alla referenser till Center för EHälsa i samverkan (CeHis) har tagits bort. I de flesta fall refereras nu istället Inera.
- Alla referenser till VIT-boken har tagits bort.
- Revision C har ett större fokus mot teknisk arkitektur genom att vissa verksamhetsperspektiv och avsnitt om verksamhetsvyn kortats ner.
- Inaktuell referenser har tagits bort eller, där det är möjligt, förändrats att referera aktuell information. Det gäller ex genomgående för gamla referenser till "Nationell IT-strategi för vård och omsorg" och "Nationell eHälsa".
- Vissa avsnitt som beskriver T-boken självt snarare än arkitekturen har kortats ner. Vissa konceptuella figurer har tagits bort.
- I det fall T-boken refererar tjänster som har realiserats efter det att Revision B publicerades har beskrivningarna anpassats till de nu befintliga tjänsternas utformning. Det gäller exempelvis hur Engagemangsindex kan och får nyttjas.
- För detaljer kring t ex domännamnsättning refereras externa anvisningar.
- Avsnittet om "Lokalt driven e-tjänsteutveckling för invånartjänster" har idag ingen användning och har tagits bort.
- Avsnittet med vägledande exempel för replikering av engagemangsindexinformation har tagits bort eftersom det baserades på tjänstekontrakt som inte längre är i bruk.
- Databasschemat för Tjänsteadresseringskatalogen har uppdaterats till den som idag är aktuell i SKLTP.
- Ordlistan i dokumentet har krympts till de som är specifika för T-boken. För övriga arkitekturella termer hänvisas till en extern ordlista.
- Begreppet Källsystemsadressering införs i tillägg till Verksamhetsbaserad adressering.
...
D
Denna revision omfattar endast en mindre uppdatering av riktlinjerna för lokalt driven e-tjänsteförsörjning.
T-boken är en arkitekturell beskrivning av hur man ska lösa interoperabilitetsbehov för informationsdelning inom svensk hälso- och sjukvård. Då hantering av källkod och val av licensmodell inte i huvudsak är en arkitekturell fråga utan ett lokalt beslut i de organisationer som realiserar tjänster enligt T-boken och dess anvisningsdokument har vi valt att förändra skrivningarna i kapitel 4.5.
Innehållsförteckning
Sammanfattning
Många invånare kommer förr eller senare att behöva vård och omsorg från fler huvudmän än en. Till exempel kan en patient behöva få medicinsk vård från flera olika vårdgivare parallellt samtidigt som det krävs färdtjänstresor till själva läkarbesöken samt stöd i hemmet för att klara det dagliga livet.
...
Ordlista och förkortningar för T-boken återfinns i bilaga.
Nyttan med T-boken
Genom att T-boken beskriver vilka förutsättningar som ligger till grund för nationell samverkan, bland annat i form av styrande principer och teknisk referensarkitektur, underlättas arbete med att utveckla IT-stöd för sammanhängande vård och omsorg, på både regional/lokal och nationell nivå.
...
På motsvarande sätt kan även T-boken tillämpas i lokala arkitekturfunktioner för granskning och stöd till projekt och förvaltningsobjekt.
Nyttan med samverkan
- Invånarna får mer sammanhållen hjälp från vården och omsorgen.
- Vårdgivarna kan enklare, säkrare och mer kostnadseffektivt kommunicera med varandra.
...
På sikt kan T-boken komma att utvecklas och innefatta andra områden än vård och omsorg, såsom andra verksamhetsområden inom den kommunala verksamheten.
1 Introduktion till T-boken
1.1 Inledning
Under 2010 har en målbild för eHälsa arbetats fram ur ett verksamhetsperspektiv, med God vård i fokus. Målbilden har tagits fram av Arkitektur och regelverk hos Inera. De övergripande målen för eHälsa, baserat på Socialstyrelsens strategi för God vård, är bland annat att vård av god kvalitet ska vara:
...
För att få en komplett målbild för arkitekturen för e-hälsa, som innehåller hela vård- och omsorgsområdet, måste även det kommunala socialtjänstperspektivet inkluderas.
1.2 Syftet med T-boken
För att bidra till en nationell samverkan kring enskilda individers behov av vård och omsorg över huvudmannagränser behövs en gemensam grund för IT-stödens utformning – en nationell arkitektur att stå på och utgå ifrån vid förverkligande av IT-stöd inom vård och omsorg.
...
Olika vård- och omsorgsgivare kommer att utvecklas i olika takt och har olika ekonomiska och tekniska förutsättningar för att utforma egna interna lösningar. Även förutsättningarna för att ansluta sig till den nationella arkitekturen för samverkan mellan vård och omsorgsgivare skiljer sig åt. Arkitekturen utformas därför så att varje vård- och omsorgsgivare kan ansluta sig i den takt som passar deras behov och förutsättningar.
1.3 T-bokens vision utifrån befintliga behov
Visionen för T-boken är att den genom referensarkitekturen ska möta de behov som uppstår när:
- e-tjänster för invånare, företagare och utförare behöver integreras med informationskällor och verksamhetssystem inom myndigheter
- e-tjänster för såväl invånare som professionen behöver sammanställa uppgifter om den enskilda invånaren baserat på informationskällor spridda över många organisationer och IT-system
- offentliga och privata aktörer inom vård och omsorg behöver integrera sina system med statliga myndigheters e-tjänster (t ex Socialstyrelsen, Försäkringskassan och eHälsomyndigheten)
- medarbetare behöver e-tjänster som spänner över flera informationskällor och verksamhetssystem
- offentliga och privata aktörer inom vård och omsorg behöver utbyta information eller nå skalfördelar, såsom ekonomiska stordriftsfördelar, genom att dela e-tjänster
- medarbetare inom olika organisationer behöver meddela sig med varandra elektroniskt rörande gemensamma ärenden på ett säkert och robust sätt
1.4 Målgrupper
T-boken riktar sig till flera målgrupper som var och en kan ha nytta av olika delar av dokumentet.
1.4.1. Beslutsfattare och beställare
Ett arkitekturramverk som helhet syftar till att förenkla och effektivisera den framtida utvecklingen av IT-stöd. Som beslutsfattare och beställare kan de två inledande kapitlen i T-boken användas för att stämma av om tänkta beställningar är av sådan karaktär att de omfattas av den nationella arkitekturen. Dessa projekt bör då planeras och genomföras så att den nationella arkitekturen följs för att uppnå vinster såsom kostnadseffektivitet, återanvändning av teknik- och tjänsteutveckling samt ökade möjligheter till utbyte av information.
1.4.2. Arkitekturfunktioner nationellt, regionalt och lokalt
Arkitekturfunktioner eller motsvarande kan använda de styrande principerna i kapitel 4 som ett underlag för att kunna avgöra om projekt- och förvaltningsbeskrivningar överensstämmer med de strategiska målen för eHälsa, ur ett tekniskt perspektiv.
...
Även regionala eller lokala arkitekturfunktioner kan använda T-boken för att granska och följa upp sina projekt. En liten organisation, som inte har en arkitekturfunktion eller motsvarande roll, kan använda T-boken i dialog med sina IT-leverantörer inom vård och omsorg för att försäkra sig om att de har förstått den omgivning som IT-systemen skall verka inom.
1.4.3. Ansvariga för nationella projekt och förvaltningsobjekt
Ansvariga för olika projekt och förvaltningsobjekt bör förstå T-boken på en övergripande nivå, för att kunna planera in avstämningar mot referensarkitekturen och på så sätt få möjlighet att planera och följa upp projektarbetet i olika faser och löpande kvalitetssäkra resultatet.
Genom regelbundna avstämningar mot referensarkitekturen underlättas projektarbetet och risken för att få göra omarbetningar i projektet minskar.
1.4.4. Ansvariga för regionala projekt och förvaltningsobjekt
Även om T-boken avser den nationella arkitekturen kan den med fördel även användas i lokalt/regionalt utvecklingsarbete inom vård och omsorg. Dessutom innebär en lokal anpassning med stor sannolikhet att tröskeln för att ansluta sig till den nationella arkitekturen blir betydligt lägre. I vissa fall är det dessutom en nödvändighet att vissa regler efterföljs även lokalt/regionalt, till exempel när det gäller hantering av spärr, eftersom de i sig utgör en grundläggande förutsättning för att den nationella arkitekturen ska fungera.
...
En gemensam arkitektur och tillhörande regelverk, både ur ett verksamhetsperspektiv, informationsstrukturperspektiv och tekniskt perspektiv, leder alltså till interoperabilitet. Med det avses förmågan hos olika system att fungera tillsammans och kunna kommunicera med varandra. Detta skapar förutsättningar för att utbyta information, integrera processer och använda gemensamma tjänster.
2 Behov och scenarier
2.1 Arkitekturens intressenter
Intressenterna i den nationella samverkansarkitekturen är de parter som behöver förändra sin IT-arkitektur drivet av krav från strategin för nationell eHälsa inom vård och omsorg. I den gamla skriften ”Målbild för arkitekturen inom eHälsa I samverkan – och vägen till målet” som har tagits fram av Inera som ett separat projekt, finns ett antal intressenter och deras behov sammanställda, bland annat följande intressenter: Invånare, individ, patient, företrädare, politiker, vårdprofessionen, verksamhetschef, vårdgivare, socialtjänst, myndighet, apotekens servicebolag, patientorganisation, forskare och studerande. Skriften fokuserar på hälso- och sjukvård och är baserad på en vision för hur IT kan bidra till God vård. För att få en komplett målbild och färdplan för arkitekturen för e-hälsa, som innehåller hela vård- och omsorgsområdet, måste även det kommunala socialtjänstperspektivet inkluderas. Utöver de intressenter som redovisats i Målbilden för eHälsa, så har därför ytterligare några intressenter till T-boken identifierats och de anges i tabellen nedan. T-bokens olika kapitel har under framtagningen stämts av mot de behov som intressenterna har uttryckt.
...
Intressent | Behov | Har uttryckts av |
Projekt och förvaltningar av regionala och nationella | Att kunna förlita sig på regionala och nationella standardiserade och konsoliderade integrationsgränssnitt för de integrationer som behöver göras mot vård- och omsorgsgivarnas system. Att det finns förvaltningar, processer och plattformar som ger repeterbarhet, effektivitet, säkerhet och robusthet när nya integrationsgränssnitt ska realiseras. Att en leverantörsoberoende spelplan för en federerad säkerhetsarkitektur för följsamhet mot patientdatalagen och Socialtjänstlagen är beskriven. | Flera nationella projekt och förvaltningsobjekt. … |
Förvaltning av nationella standarder | Att nya standarder för samverkan kan införas successivt. Att etablerade samverkan inte blir ett hinder för att utveckla standarder utgående från nya krav rörande säkerhet, interoperabilitet och kvalité. | Arkitektur och regelverkingens förvaltning av RIV Tekniska Anvisningar, Andra nationella förvaltningsobjekt … |
Vård- och omsorgsgivares IT-förvaltningar. | Att det finns ett nationellt standardiserade, förvaltade och driftsatta integrationsgränssnitt för integration mot tjänster som är gemensamma för alla vård- och omsorgsgivare, så som för de nationella projekten inom ramen för Inera, myndighetstjänster etc. Det är en nödvändighet för att systemleverantörerna ska se strategiskt på att integrera med den framväxande nationella arkitekturen. Att det lokala IT-stödets struktur och sammansättning kan förändras genom lokala beslut, utan att det krävs nationell samordning/fastlåsning som resultat av att befintligt IT-stöd är integrerat med omgivningen. Att säkerhetsarkitekturen för följsamhet mot PDL och SOL är etablerad såväl lokalt som regionalt. | IT-arkitekter hos huvudmän. |
Samverkansorganisationer såsom Sambruk | Flera samverkansorganisationer, såsom Sambruk, arbetar aktivt med arkitektur för kommuner. Sambruk har bland annat producerat intellektuellt kapital i form av handledningar och riktlinjer för en kommuns hela verksamhetsområde (e-arkitektur). I dessa handlingar är mötet med medborgaren och kommunikation med myndigheter väsentliga. |
2.2 Scenariobeskrivningar
Intressenternas behov av samverkan har konkretiserats genom så kallade scenarier. Ett scenario illustrerar en målbild för ett framtida tillstånd i syfte att illustrera för vem och i vilka situationer den tekniska arkitekturen gör nytta. Scenariobeskrivningarna har delats upp i olika områden:
...
Att ta hänsyn till dessa delar vid utformningen av den tekniska arkitekturen är fundamentalt.
2.2.1. Stöd för samverkan i vård och omsorgsprocessen
- Samverkande hälsoärenden
Samverkande hälsoärenden innebär bland annat att vårdens i vissa fall långt drivna specialisering och fragmentering överbryggas. Detta är viktigt för att patienten ska uppleva att vården ser människan som en helhet och hanterar patientens vårdbehov därefter, även om varje enskilt möte rör ett hos patienten specifik och avgränsat vårdbehov. Genom en gemensam informationsstruktur och gemensam teknisk infrastruktur och säkerhetslösningar kan bland annat
...
Eftersom omsorgsverksamheter inom kommuner skriver ut läkemedel är behovet av elektronisk integration med så väl logistiska processer (till exempel Apoteket Farmaci) som förskrivningsprocesser stort.
2.2.2. Stöd för välinformerade och delaktiga medborgare
- e-tjänster för invånare
Vård och omsorg eftersträvar ökad service till invånaren genom att erbjuda tjänster på webben. Det kan gälla tidbokning, kundval, listning, vårdval med mera. Här finns såväl ett kommunalt som ett regionalt och ett nationellt perspektiv.
...
- Alla landsting kan tillhandahålla personinformation enligt ett nationellt standardiserat tjänstekontrakt. Därigenom behöver inte systemleverantörer anpassa sina produkter för lokala gränssnitt. Landsting och kommuner blir på så sätt också fria att välja lösning för personinformation oberoende av vilket verksamhetssystem som används.
2.2.3. Stöd för uppföljning
- Uppföljning och utvärdering
...
Runtom i landet finns det ett stort antal kvalitetsregister inom sjukvården som innehåller information om diagnoser, åtgärder och utfall av olika klinikers vårdarbete. Denna form av data ger varje enskild klinik möjlighet att jämföra sig med riksgenomsnittet, diskutera och analysera internt och vid behov vidta kvalitetsförbättrande åtgärder. Insamling av data till kvalitetsregister av olika slag är i dag belastande för vård- och omsorgspersonal. Samtidigt ökar insikten av värdet och därmed uppstår ytterligare krav på datainsamling.
- Genom kvalitetsregister kan insamling och inmatning av vård- och omsorgsdokumentation för systematisk användning automatiseras och förbättras. Kvalitetsregister är också väsentlig bakgrundsinformation som bör göras tillgänglig för invånarna i kundvals- och vårdvalssituationer, vare sig det gäller ett nyval eller ett omval.
2.2.4. Stöd för kunskapsstyrning
- Kunskapsstyrd vård
För att invånarna ska få bästa möjliga vård ska den vara baserad på aktuell forskning, uppdaterade riktlinjer och analyserad information som baseras på data från uppföljning av vårdens kärnprocess.
- Vård- och omsorgsgivaren ska, genom IT-stöd som innehåller sammanställd kunskap för olika intressenter och vårdsituationer, få ett beslutsstöd så att rätt beslut kan fattas i det ögonblicket beslutet ska tas.
2.2.5. Stöd för resurshantering
- Resurshantering
För att få en effektiv och säker vård och omsorg behöver det finnas både personella och materiella resurser i rätt ögonblick.
- Genom att utveckla integration med standardsystem och beslutsstöd så kan resurshantering stödjas. Genom att data från produktionsuppföljning av kärnprocessen tydliggörs i beslutsstöd kan även olika intressenter inom lednings-, styrnings- och stödprocesser få stöd i resurshantering, både vad gäller personella och materiella resurser.
3 T-boken i ett sammanhang
Strategin för nationell eHälsa – tillgänglig och säker information inom vård och omsorg, är ett av de överordnade regelverken till T-boken. Arkitekturens vägval måste även vara harmoniserade med de lagrum och författningar som rör vård och omsorg.
3.1 Arkitekturens utveckling och praktiska användning
Principerna för hur arkitekturen ska utvecklas, tillämpas och förvaltas baseras på en modell hämtad från TOGAF ADM. TOGAF (The Open Group Architecture Framework) är ett ramverk med metodstöd som utvecklats sedan mitten på 90-talet genom att ta tillvara ”best practice” från olika branscher.
...
Över tiden uppstår behov av att förändra och utöka olika mönster i referensarkitekturen. Avsikten med förändringshanteringen i fas H är att den nationella referensarkitekturen genom kontinuerlig uppdatering ska kunna fortleva som en gemensam arkitekturbeskrivning. Det ställer krav på ett forum som kan samordna förvaltning och vidareutveckling och på så sätt säkerställa att referensarkitekturen över tiden fortsätter fylla sitt syfte. För T-boken så är Arkitektur och regelverk hos Inera detta forum.
3.1.1. Arkitekturens koppling till tjänstehantering
Utmaningarna inom IT-området kan mötas genom utveckling av förmågor (capabilities) inom tjänstehantering (IT Service Management, ITSM), arkitektur och (tjänste)förvaltning. Arkitekturen har en betydande roll i utvecklingen av tjänster, processer och system i perspektiven verksamhet, information, teknik och säkerhet.
Eftersom de olika delarna påverkar varandra måste helheten, Enterprise Architecture, och sambanden mellan de olika perspektiven adresseras oavsett viket av dem som är i fokus för stunden.
...
När det gäller tjänstehantering är det mest använda ramverket, internationellt sett, ITIL v3 (IT Infrastructure Library version 3) Därför är det viktigt att den tekniska arkitekturen harmonierar med ITIL, utan att för den skull förutsätta att ITIL används. Ramverket ITIL är uppdelat i fem faser:
- Tjänstestrategi, Service Strategy (ITIL v3)
- Tjänsteutformning, Service Design (ITIL v3)
- Tjänsteöverlämning, Service Transition (ITIL v3)
- Tjänstedrift, Service Operation (ITIL v3)
- Kontinuerlig tjänsteförbättring, Continual Service Improvement (ITIL v3)
En bärande tanke med ITIL är att tjänster ska kunna hanteras genom hela livscykeln. Tjänstehantering i sig definieras som en uppsättning specialiserade organisatoriska förmågor som kan skapa värde för verksamheten i form av tjänster. För att uppnå de fördelar som eftersträvas måste det finnas processer, styrning och ledning som säkerställer och kvalitetssäkrar arbetet.
...
Driftsatta tjänster, processer och system måste precis som arkitekturen förvaltas. Förvaltningsarbetet med avseende på tjänsteleveranser är till sin natur tvehövdat. Dels handlar det om att kontrollera att tjänstedrift och support upprätthåller en överenskommen servicenivå (SLA) i en leverans och vidta korrigerande åtgärder vid avvikelser, dels att vid förändrade krav planera för nya mål så att tjänster, processer och system kan prestera i enlighet med vad som krävs. Kontinuerligt förbättringsarbete är en process som kan appliceras på andra processer för att vid varje givet tillfälle komma upp till den nivå av prestanda som eftersöks. Förbättringsarbetet i sig får aldrig börja sätta sina egna gränser. Dess syfte är att verka upp till och med en given nivå, alternativt att lyfta upp till en ny överenskommen nivå om beslut tas om detta.
3.1.2. Arkitekturen och processer i samverkan
Nedan illustreras hur processen för arkitekturarbete samverkar med processerna för Tjänstehantering och Tjänsteförvaltning, det vill säga de huvudprocesser som hanterar och förvaltar den realiserade arkitekturen (det färdiga resultatet, även kallat instanser).
...
- Verksamhetens företrädare uttrycker de behov som finns.
- Tjänstestrategiprocessen verkar utifrån den så kallade Tjänsteportföljen med att definiera marknaden, utveckla tjänsten, utveckla strategiska tillgångar samt förbereda införandet. Processens resultat är styrande för arkitekturprocessen.
I Tjänstestrategiprocessen fångas också behoven från verksamheten upp och beskrivs. Uttryckta behov av servicenivåer, kvalitetsaspekter och andra parametrar dokumenteras och hanteras. Om det behövs tas användningsfall fram för att underlätta utvecklingsprocessen. Behoven vägs och bedöms mot gemensamma policyer och principer som är förankrade i verksamheten. - Programkontoret analyserar, designar och utvärderar alternativ samt köper in och/eller utvecklar lösningar. I denna process levererar arkitekturen underlag i form av referens- och lösnings-arkitekturer för vidare bearbetning i de ingående underprocesserna. Ett uppdrag kan behöva itereras, det vill säga växla, mellan arkitekturprocessen och programkontoret flera gånger innan ett fullgott resultat uppnås. Arkitekturfunktionen granskar arbetet för att säkerställa att det följer referens- och lösningsarkitekturer.
- Tjänsteöverlämning kan liknas vid ett stafettlopp; en överlämning av stafettpinnen (Release) från Tjänsteutformning till Tjänstedrift. Här gäller det att kombinera snabbhet och säkerhet för ett bra resultat. Förändringskraven som kommer från programkontoret resulterar i lösningar som kan användas i den operativa miljön. I den mån arkitekturella beskrivningar finns på plats och är användbara kan det hanterade uppdraget gå vidare, i annat fall måste det till insatser från arkitekturfunktionen för att få fram nödvändiga underlag. Ett viktigt verktyg för att arkitekturfunktionen på ett effektivt sätt ska kunna granska projekt och operativ verksamhet är den så kallade konfigurationsdatabasen. Strukturen i databasen bör ägas av arkitekturfunktionen medan processen för Hantering av tjänstetillgångar och konfigurationer ( Service Asset and Configuration Management (ITIL v3)) ansvarar för instanseringen. Uppdatering sker i huvudsak av processen för Release och driftsättningshantering (Release and Deployment Management (ITIL v3)) Konfigurationsdatabasens struktur och instansering hjälper till att identifiera relationer mellan olika konfigurationsenheter vilket är ovärderligt i supportsituationer, förändringshanteringens analys av en föreslagen ändrings inverkan på infrastruktur och/eller processer samt som underlag för kostnadsberäkning av de tjänster som utvecklas.
- Tjänstedrift kan liknas vid IT-avdelningens fabrik. Här levereras IT-tjänster enligt avtalade Tjänstenivåmål. Den stora utmaningen i Tjänstedriftprocessen är att hitta en god balans mellan
- internt fokus i förhållande till externt
- fokus på stabilitet i förhållande till fokus på tillmötesgående
- fokus på kvalitet i förhållande till fokus på kostnad
- fokus på reaktivitet i förhållande till fokus på proaktivitet
- Tjänsteförvaltningsprocessen kontrollerar utfallet mot börläge och återkopplar bakåt till lämpliga processteg. Strategiska och taktiska inriktningsbeslut omsätts till en användbar planering. Tjänste-förvaltningens aktiviteter utförs givetvis på redan realiserade objekt. Modellen visar Förvaltningsprocessens positionering ur ett styrningsperspektiv.
- Tjänsten avslutas och livscykeln är fullbordad.
...
Processen för Kontinuerlig tjänsteförbättring är en löpande process som ska stämmas av mot vision, strategi samt taktiska och operativa mål. I processen tas små steg i syfte att komplettera och ge riktlinjer till de övriga fyra huvudprocesserna. Processen bör integreras i verksamhetens kultur för att där bli en naturlig del i vardagen.
3.2 T-bokens innehåll och tillämpning
T-boken för vård och omsorg är avsedd att tillämpas av arkitekturfunktionen i olika organisationer. För Arkitektur och regelverk hos Inera utgör den det huvudsakliga regelverket för den tekniska arkitekturen. För andra organisationer blir det troligen kompletterande, eftersom det finns behov av att täcka in fler sektorer, samt att man där behöver en arkitektur för anslutning till den nationella.
...
En viktig del av dokumentet är vägledande exempel. De belyser på ett konkret sätt hur referensarkitekturen kan tillämpas för behov som var aktuella när referensarkitekturen fastställdes. En uppsättning av vägledande exempel ingår i detta dokument, men förvaltas också som fristående dokument, i form av målbilder. Därigenom kan de hållas aktuella mellan revisioner av referensarkitekturen.
4
| Ankare | ||||
|---|---|---|---|---|
|
För att hjälpa de projekt som beställer och utvecklar IT-stöd att navigera mot en teknisk arkitektur enligt de långsiktiga behoven, finns sex IT-principer som bland annat säkerställer spårbarhet, skalbarhet, flexibilitet och interoperabilitet.
...
Principerna behöver kommuniceras och tillämpas hos beställare och utförare. Det är arkitekturfunktionens uppgift att styra utveckling och förvaltning av arkitekturen, samt har ansvar att övervaka och vägleda principernas tillämpning och deras förvaltning.
4.1 IT1: IT-principerna är styrande för den tekniska arkitekturen
Det finns en uppsättning styrande principer för tillämpad arkitektur.
4.1.1. Motiv
Följsamhet mot principerna möjliggör löpande styrning mot målbilden för arkitekturen.
4.1.2. Förutsättning
- Principerna kommuniceras och tillämpas hos beställare och utförare genom arkitekturfunktionen, som styr utveckling och förvaltning av arkitekturen, samt har ansvar att övervaka och vägleda principernas tillämpning och deras förvaltning.
- Arkitekturfunktionen är integrerad i processer hos tillämpliga programkontor, beställarfunktioner, projektorganisationer och systemförvaltningar.
- Principerna kommuniceras och tillämpas av dem som styr utveckling och förvaltning inom IT-infrastruktur, vårdgivartjänster och invånartjänster.
- Arkitekturfunktionen underlättar följsamhet mot principerna genom anvisningar och vägledande exempel.
- En teknisk referensarkitektur kommunicerar en teknisk målbild. En teknisk referensarkitektur skapar också förutsättningar för projekten att leverera resultat som är i samklang med de styrande principerna. Visionen ska vara att det upplevs enklare att följa principerna än att inte följa dem.
- I möjligaste mån bör principerna tillämpas, men om principer och regelverk står i konflikt med ett projekts leveransförmåga rekommenderas det att avvikelser klassificeras och dokumenteras så att uppföljning kan ske av respektive arkitekturfunktion. På det nationella planet utgörs arkitekturfunktionen av Arkitektur och regelverk, med berörda förvaltningar.
4.2 IT2: Informationssäkerhet
Tillgänglighet, sekretess, riktighet och spårbarhet ska säkerställas vid all samverkan.
All information som hanteras eller lagras i någon form måste skyddas mot oönskad förändring, påverkan eller insyn. Det ska inte heller vara möjligt för obehöriga att ta del av informationen. De användare som har rätt att ta del av informationen ska komma åt den efter behov och inom önskad tid. Det är också av vikt att kunna identifiera vem som har gjort vad med information och datasystem.
4.2.1. Motiv
Säkerhetstänkande är grunden för förtroende och tillit från invånare, medarbetare och samarbetspartners. Informationssäkerhet innebär att säkerställa:
- Riktighet - Att information inte kan förändras vare sig obehörigen, av misstag eller på grund av funktionsstörning. Informationen ska vara tillförlitlig, korrekt och fullständig
- Sekretess - Att dokument, information och handlingar etc. inte görs tillgängligt eller avslöjas för obehörig
- Spårbarhet - Att i efterhand entydigt kunna härleda specifika aktiviteter eller händelser till ett identifierat objekt - användare, skrivare, dator eller system/program. Det ska gå att se vem som tagit del av informationen, vilka förändringar som har inträffat och av vem som dessa har utförts
- Tillgänglighet - Att information och informationstillgångar kan utnyttjas efter behov, i förväntad utsträckning och inom önskad tid utifrån de krav som ställs på verksamheten. Tillgänglighet innebär inte bara att systemet tekniskt fungerar med utlovade svarstider. Systemet måste dessutom leverera förväntat värde inom rimlig tid.
4.2.2. Förutsättning
- Verksamhetskritiskt IT-stöd designas för att möta verksamhetens krav på tillgänglighet vid frånfall av ett externt beroende. Ju fler beroenden till andra komponenters tillgänglighet, desto lägre egen tillgänglighet.
- Verksamhetskritiska nationella stödtjänster (t.ex. tillgång till behörighetsstyrande information) erbjuder möjlighet till lokala instanser som med tillräcklig aktualitet hålls uppdaterade med nationell master.
- Krav mellan integrerande parter regleras genom integrationsavtal. Integrationsavtal är det avtal där informationsägaren godkänner att en ett visst system får agera mot information genom ett visst tjänstekontrakt. Exempelvis skall enligt integrationsprocessen för den nationella tjänsteplattformen ett avtalsnummer för ett integrationsavtal registreras i samband med att man "öppnar dörren" för en viss tjänstekonsument mot en viss kombination av informationsägare och tjänstekontrakt.
- Arkitekturen måste möjliggöra tillräcklig tillgänglighet vid flera samverkande system.
- En sammantagen tolkning av tillämpliga lagar och förordningars konsekvenser för teknisk realisering av informationsfångst, utbyte och lagring.
- Förutsättningar för spårbarhet etableras i form av loggningsregler för komponenter som deltar i säkert informationsutbyte.
- Integration ska ske över en integrationsinfrastruktur (t.ex. virtualiseringsplattform) som möjliggör uppföljning av tjänsteproducenters fullföljande av SLA.
- Interoperabla, internationellt beprövade och för leverantörer tillgängliga standarder tillämpas för kommunikation mellan parter som har upprättat tillit.
4.3 IT3: Nationell funktionell skalbarhet
Alla element i arkitekturen (tjänstekontrakt, integrationstjänster, nationella e-tjänster, nationella integrations- och plattformstjänster etc.) ska följa ett nationellt perspektiv. Det gäller så väl funktionell omfattning som teknisk kapacitet. Observera att resonemanget även gäller regionalt och lokalt där man också kan dela gemensamma resurser eller tjänster.
4.3.1. Motiv
Det ska vara möjligt för flera organisationer att dela en installation av ett system.
Vidare innebär nationell samverkan potentiellt högre krav på tillgänglighet och kapacitet. Detta ställs på sin spets när invånaren blir användare av e-tjänster som integrerar med verksamhetssystem.
4.3.2. Förutsättning
- Nationella tjänstekontrakt definieras med nationell täckning som funktionell omfattning. Det är möjligt för ett centraliserat verksamhetssystem som användas av alla verksamheter i Sverige att realisera varje standardiserat tjänstekontrakt. Det får inte finnas underförstådda funktionella avgränsningar till regioner, kommuner, landsting eller andra organisatoriska avgränsningar i nationella tjänstekontrakt.
- SLA ska definieras för varje tjänstekontrakt. Detta SLA ska ta hänsyn till framtida kapacitet för tjänstekontraktet med avseende på transaktionsvolym, variationer i användningsmönster och krav på tillgänglighet, i kombination med förmåga till kontinuerlig förändring.
- System och e-tjänster som upphandlas kan utökas med fler organisationer som kunder utan krav på infrastrukturella ingrepp (jämför s.k. SaaS)
4.4 IT4: Lös koppling
Sammanhållen journalföring, effektivt processtöd för hälsoärenden, samordnad vårdplanering och att tillmötesgå invånarens behov av e-tjänster kräver omfattande integration av många organisationers IT-stöd. Dominoeffekter orsakade av förändringar i integrationslandskapet skall förhindras genom lös koppling.
4.4.1. Motiv
Fullföljande av strategin för nationell eHälsa inom vård och omsorg kräver en höggradig integration mellan samverkande parters IT-stöd. Det kan gälla såväl inom som mellan parter med system som ska integreras. Risken är stor att parternas utveckling av IT-stödet kompliceras ju mer integrationer som upprättas. Varje förändring kan komma att behöva samordnas med många parter.
...
Genom nationellt fastställda tjänstekontrakt (eng. Service Contract, OASIS SOA Reference Model) vet systemleverantörer ”integrationsspråket” för de olika processer/system i vilka de förväntas integrera sina produkter (tidbokning, listning, utbyte av journalutdrag, e-recept, samordnad vårdplanering, sjukskrivning etc.). På detta sätt erhålls en standardiserad spelplan för meddelandebaserad integration av e-tjänster och informationskällor. Möjlighet skapas för effektiv utveckling av nationella integrationstjänster och e-tjänster genom att alla informationskällor uppfyller samma tjänstekontrakt för en viss typ av informationsutbyte. Semantiska punkt-till-punkt-beroenden kan därmed undvikas. Tjänstekontrakten är en teknisk slutprodukt av att regelverk för verksamhet, informatik och teknik tillämpas.
4.4.2. Förutsättning
- Meddelandeutbyte baseras på att kommunikation etableras utgående från vem som äger informationen som ska konsumeras eller berikas, inte vilket system, plattform, datalager eller tekniskt gränssnitt som informationsägaren för stunden använder för att hantera informationen. Genom centralt administrerad förmedlingstjänst skapas lös koppling mellan informationskonsument och informationsägarens tekniska lösning.
- En arkitektur som skapar lös koppling mellan konsumenter och producenter, avseende adressering och standarder för kommunikation.
- En nationell integrationspunkt ska kunna erbjudas för varje nationellt standardiserat tjänstekontrakt, som en fasad mot bakomliggande brokiga systemlandskap.
- Nationella tjänstekontrakt förvaltas i en nationellt koordinerad förvaltning.
- För en process inom vård och omsorg kan flera tjänstekontrakt ingå. Därför är det viktigt att alla tjänstekontrakt baseras på en gemensam referensmodell för informationsstruktur.
- Parter som samverkar i enlighet med arkitekturen integrerar med system hos parter som lyder under annan styrning (t.ex. myndigheter, kunder och leverantörer). Det kan leda till att vård- och omsorgsgivare antingen:
- Nationellt bryggar informationen (semantisk översättning) eller
- Nationellt införlivar externt förvaltat tjänstekontrakt som standard.
Observera att semantisk bryggning av information till vårdens referensmodell förutsätter en nationell förvaltning av anpassningstjänster.
- Befintliga system behöver anpassas till nationella tjänstekontrakt. Detta kan göras av leverantörer direkt i produkten, eller genom fristående integrationskomponenter (”anslutningar”). En anslutning bör ligga nära (logiskt vara en del av) det system som ansluts, oavsett om det är i rollen som konsument eller producent för anslutningen som genomförs.
- Interoperabla standarder för meddelandeutbyte tillämpas, så att integration med till exempel en Web Service kan utföras utan att anropande system behöver tillföras en för tjänsteproducenten specialskriven integrationsmodul (s.k. agent).
4.5 IT5: Lokalt driven e-tjänsteförsörjning
E-tjänsteförsörjning i vård och omsorg är i grunden driven från lokala behov. Regelverk för arkitektur stödjer att lokalt etablerade e-tjänster gradvis kan bredda sin bas av användare över vårdgivargränser och så småningom berika det nationella e-tjänsteutbudet. För invånaren erbjuder varje e-tjänstekanal en sammanhållen användarupplevelse (”virtuell portal”) oavsett vilken part som tekniskt och utvecklingsmässigt står bakom en enskild e-tjänst.
4.5.1. Motiv
Nationella e-tjänster uppstår inom nationella utvecklings- eller upphandlingsinitiativ, men också på initiativ av landsting och kommuner, sammanslutningar av landsting eller kommuner eller hos externa aktörer. Nya nationella e-tjänster kan därför uppstå genom lokala och externa initiativ. För att externt och lokalt framställda e-tjänster ska kunna ges nationell status behöver den initiala utvecklingsinsatsen ske på ett sätt som licensmässigt, förtroendemässigt, praktiskt och tekniskt gynnar kontinuerlig breddning av e-tjänstens användning så väl som förvaltning, med nationell tillämpning och ägarskap som möjligt resultat.
E-tjänster till invånare levereras genom nationella, regionala och lokala kanaler. Ett exempel på en nationell kanal för e-tjänster inom vård och omsorg är 1177 e-tjänster, som kanaliserar e-tjänster för kontakt mellan invånaren och vård- och omsorgsgivare. Visionen för e-tjänstekanaler är att varje kanal ska ge invånaren en sammanhållen användarupplevelse – oberoende hur många parter som försörjer kanalen med e-tjänster. Målbilden för varje e-tjänstekanal är en ”virtuell portal”, där lokalt, regionalt och privat utvecklade e-tjänster kan inordnas och ge samma användarupplevelse som om de vore en del av en för kanalen central portalinfrastruktur. Vård och omsorg ges därmed möjlighet att som komplement till programstyrd utveckling av nationella e-tjänster ta tillvara innovationskraften på marknaden och hos huvudmännen.
4.5.2. Förutsättning
- När utveckling av källkod är en del av en tjänsteleverans skall följande beaktas:
- Alla leveranser tillgängliggörs under öppen källkodslicens. Valet av licensformer samordnas nationellt genom rekommendationer.Utvecklingen bedrivs från start i en allmänt tillgänglig (över öppna nätverk) projektinfrastruktur där förvaltningsorganisation kan förändras över tiden inom ramen för en kontinuerligt tillgänglig projektinfrastruktur (analogi: ”Projektplatsen för e-tjänsteutveckling”).Full insyn och åtkomst till källkodkällkod, binärer, versionshantering, ärendehantering, stödforum och andra element för utvecklare i en projektinfrastruktur ) tillgängliggörs ör kunder och vid behov samarbetspartners under projektets och förvaltningens hela livscykel. Valet av licensformer samordnas nationellt genom rekommendationer.
- Upphandlade e-tjänster bör/ska fungera på de vanligaste plattformarna hos vårdgivarna och hos nationella driftspartners (Windows, Linux, Unix) t.ex. genom att vara byggda för att exekvera på en s.k. Java virtuell maskin.
- Gemensam referensmodell för e-tjänsters interna uppbyggnad stimulerar och förenklar återanvändning och överföring av förvaltningsansvar mellan organisationer.
- Minsta möjliga – men tillräcklig – mängd standarder och stödjande gemensamma grundbultar för nationella e-tjänstekanaler säkerställer att även utvecklingsenheter i mindre organisationer kan bidra med e-tjänster för en integrerad användarupplevelse och att en gemensam back-office för anslutning av huvudmän till e-tjänster finns etablerad. I den mån etablerade standarder med bred tillämpning i kommersiella e-tjänster finns (t.ex. för single-sign-on), bör de användas i syfte att möjliggöra upphandling av hyllprodukter.
- Utveckling sker mot globalt dominerande portabilitetsstandarder i de fall mellanvara (applikationsservrar) tillämpas. Det är möjliggöraren för nyttjande av free-ware och lågkostnadsverktyg i organisationer som inte orkar bära tunga licenskostnader för komplexa utvecklingsverktyg och driftsplattformar.
- Nationell (eller regional – beroende på sammanhang vård/omsorg) förvaltning är etablerad (t.ex. s.k. Portal Governance), med effektiva processer för att införliva lokalt utvecklade e-tjänster i nationella e-tjänstekanaler. Systematisk och effektiv allokering av resurser för drift är en viktig grundförutsättning.
- Genom lokal governance och tillämpning av det nationella regelverket får lokala projekt den stöttning som behövs för att från början bygga in förutsättningar för integration i samordnade (t.ex. nationella) e-tjänstekanaler.
4.6 IT6: Samverkan i federation
Samverkan över organisationsgränser sker genom federation, såsom exempelvis identitets- och behörighetsfederering.
4.6.1. Motiv
Syftet med principen för samverkan i federation är att underlätta samverkan över organisationsgränser genom gemensamma överenskomna förutsättningar kring ett säkert informationsutbyte som ingående parter kan ha tillräcklig tillit till.
Federationsprincipen syftar också till att parter i samverkan kan tillåtas ha olika tekniska lösningar, t.ex. kring nätverk och autentiseringsteknik, så länge de gemensamma förutsättningarna är uppfyllda.
4.6.2. Förutsättning
- Federativa utbyten över organisationsgränser bygger på gemensamma överenskomna regelverk, t.ex. kring krav på autentisering av användare i IT-system, tekniska regelverk osv.
- Grunden för ett säkert federativt utbyte är att det finns en tillit till övriga parters respektive organisatoriska och tekniska lösningar. För att mäta och jämföra tillit bör lösningar och processer klassificeras i överenskomna tillitsnivåer.
- Gemensamma gränssnitt i alla federativa utbyten finns framtagna och beskrivna, vilket möjliggör kostnadseffektiva och leverantörsneutrala lösningar.
- Organ och processer behöver finnas för att godkänna utgivare av elektroniska identitetsintyg och certifikat som är giltiga i federationen.
- Aktörer i olika nät, inklusive öppna nät, ska vara välkomna i elektronisk samverkan genom att samverkande komponenter samt kommunikationen dem emellan är säkra.
- En strävan bör vara att gränsöverskridande kommunikation möjliggörs över Internet.
- Vid utformning av IT-lösningar för identitets- och behörighetsfederering, tillämpas de styrande principerna i "Referensarkitektur - Identitet och åtkomst" (http://rivta.se/documents/ARK_0046) avseende bland annat
- att överenskomma ett gemensamt tillitsramverk i federationen
- att kunna jämföra autentiseringslösningars styrka och tilliten till dessa.
- att kunna jämföra olika processer för att utfärda elektroniska identitetshandlingar och skapa tillit till dessa.
- att användarattribut kopplade till identitet och behörigheter hanteras på ett kvalitetssäkert sätt med ett tydligt ansvar för respektive användarorganisation.
- att tillämpa vid var tid överenskomna tekniska ramverk för federativt utbyte.
5 Referensarkitektur
Detta kapitel riktar sig främst till olika arkitekturfunktioner men kan också användas av organisationer som saknar arkitekturfunktion när de för dialog med IT-leverantörer.
...
Vy | Beskrivning |
Verksamhetsvy | Vyn beskrivs med typ-flöden som kompletterats med konkreta exempel. Här beskrivs också begreppet informationsägande, som har en central inverkan på arkitekturens utformning. |
Informationssystemvy | Beskrivningar visar hur det integrerade systemets funktionalitet kategoriseras och fördelas i tjänster, i syfte att realisera IT-stödet som kravställs. Vyn kompletteras med exempel på hur referensarkitekturen kan tillämpas (mål-arkitekturer) för några befintliga och planerade förvaltningsobjekt. Informationssystemvyn beskriver också begreppet tjänstekontrakt som strategi för att realisera semantisk interoperabilitet. |
Teknisk vy | Vyn beskriver identifierade stödtjänster och infrastrukturtjänster. Den beskriver också den federation som uppstår då referensarkitekturen tillämpas lokalt som del i en anslutningsarkitektur. |
5.1 Verksamhetsvy
Verksamhetsvyn beskriver referensarkitekturen utifrån användarens behov av att konsumera och producera information över organisationsgränser med hjälp IT – det vill säga där det finns ett behov av nationell samordning av teknisk arkitektur. Beskrivningen tar sin utgångspunkt i scenarier baserade på de behov som finns. Scenarierna har systematiserats till en allmängiltig modell för informationsåtkomst mellan olika system och organisationer.
...
- var information finns och kan lämnas
- hur de får åtkomst till informationen
5.1.1. Informationsägarskap och verksamhetsbaserad adressering
Informationsägaren är den som ansvarar för och förvaltar en viss typ av information, till exempel innehållet i journaler eller adressuppgifter.
...
Aktivitet | Beskrivning | Länk till informationssystemvyn |
Översikt | Översikten syftar till att sammanställa en nationell vy av patientens/individens engagemang av ett visst slag (det som är relevant för e-tjänsten i fråga). | |
- Steg 1 | Genom nationellt engagemangsindex sammanställs patientens engagemang av aktuell typ. Det är en lista med en post per informationsägare som har information av aktuellt slag om patienten/invånaren. | Tjänsteproducent (Stödtjänst Engagemangsindex) |
- Steg 2 | För varje informationsägare hämtas teknisk adress till aktuell tjänsteproducent för aktuellt tjänstekontrakt. Det finns alltid exakt en per informationsägare, men flera informationsägare kan dela tjänsteproducent. Exakt vad som identifierar en informationsägare är avhängigt tjänstedomän/process. | Tjänsteproducent (Stödtjänst Tjänsteadresseringskatalog) |
- Steg 3 | Varje tjänsteproducent levererar information om patienten enligt aktuellt tjänstekontrakt. När svar inkommit från alla tjänsteproducenter presenteras översikten för användaren (invånare eller medarbetare). | Tjänsteproducent (aktuellt Verksamhetssystem) |
Detaljer | Denna delprocess representerar användarens behov av fördjupad information om enskilda engagemang. | |
- Steg 4 (alt. till steg 5+6) | Om användaren efter att ha betraktat översikten, bestämmer sig för att etablera ett nytt engagemang, görs sökning i utbudskatalogen, efter en utförare (tillika blivande informationsägare). | Tjänsteproducent (Stödtjänst Sortiments- och utbudskatalog) |
- Steg 5 | Användaren har bestämt sig för att begära ytterligare detaljer kring ett av engagemangen i översikten. Som steg 2 men denna gång endast för en informationsägare, och för tjänstekontrakt som syftar till att hämta detaljerad information om ett engagemang. | Tjänsteproducent (Stödtjänst Tjänsteadresseringskatalog) |
- Steg 6 | Med den tekniska adressen från steg 5, kan detaljer kring ett engagemang efterfrågas från aktuell tjänsteproducent. | Tjänsteproducent (aktuellt Verksamhetssystem) |
Redigera | Användaren har beslutat att redigera ett befintligt engagemang eller skapa ett nytt, beroende på om steg 4 passerades eller inte. | |
- Steg 7 | Som steg 2 men denna gång endast för en informationsägare, och för tjänstekontrakt som syftar till att redigera befintligt eller skapa nytt (om steg 4) engagemang. | Tjänsteproducent (Stödtjänst Tjänsteadresseringskatalog) |
- Steg 8 | Användaren redigerar information eller skapar ny information i nationella e-tjänstens redigeringsvy. Med den tekniska adressen från steg 7, kan detaljer kring ett nytt eller befintligt engagemang lämnas till verksamhetssystemet genom aktuell tjänsteproducent. | Tjänsteproducent (aktuellt Verksamhetssystem) |
5.1.2. Konkreta exempel på flödesmodeller
Typ-flödet är representativt för de flesta av behovsbildens scenarion. Några exempel visas nedan:
...
Figur 4 – Flödesmodeller för några scenarion
5.1.3. Detaljering, personlig e-tjänst (invånarens tidbokning)
Exemplet med tidbokning detaljeras som typ-flöde för en nationell, personlig e-tjänst:
...
Figur 5 – Flödesmodell för invånarens tidbokning i vård och omsorg
Att veta vilka informationsägare som ska bidra till översikten
Att sammanställa invånarens tidbok, vore inte förenligt med rimliga svarstider om det förutsatte omedelbart uppslag mot de 100-tals tidböcker som finns i landet. Därför har arkitekturen tagit sin utgångspunkt i att det finns en informationskälla – engagemangsindex – som hålls uppdaterad med tillräckligt aktuell information om vilka informationsägare som har information om en invånare/patient.
Sammanställningen av en översikt kan då ske genom att detta index kontaktas, varefter omedelbara uppslag kan göras, adresserade till ett begränsat antal informationsägare. Nedanstående figur illustrerar engagemangsindex roll att redovisa vilka vårdenheter som håller tidbokningar för en individ.
...
Figur 6 – Engagemangsindex visar att invånaren har bokningar hos vårdenheterna EH1 och EH7
Att hitta informationsägarens informationskälla
Med kunskap från engagemangsindex om vilka informationsägare (verksamheter) som har tidbokningar för en invånare, är verksamhetsadressen till informationen känd (vårdenheternas identitet). Genom en tjänsteadresseringskatalog hittas den information som behövs för att tekniskt kontakta respektive informationskälla och därmed få tillgång till information om individens bokade tider.
...
Figur 7 – Tjänsteadresseringskatalogens användning i tidbokningsscenariot
5.1.4. Säker meddelandehantering över organisationsgränser
Scenarier för säker meddelandehantering och processtöd följer i grunden samma. Några exempel på berörda scenarier är:
...
En del av processen för samordnad vårdplanering handlar till exempel om att identifiera vilka organisationer (informationsägare) som behöver kontaktas för att ge en samlad bild av användarens obehandlade ärenden. När denna information är känd (d.v.s. listan av informationsägare/verksamhetsadresser där medarbetaren kan ha meddelanden), används tjänsteadresseringskatalogen för att hitta de meddelande/ärendesystem som behöver vittjas på inkomna meddelanden och ditt nya meddelande kan lämnas.
Samordnad vårdplanering
För samordnad vårdplanering kan det till exempel handla om att i översikten redovisa för användaren vilka inskrivningsärenden som väntar på att behandlas.
...
I många fall har aktörerna enats om en gemensam informationskälla för ärenden kring samordnad vårdplanering. Det är emellertid inte en förutsättning för arkitekturen. Det är däremot en utgångspunkt för arkitekturen att tillmötesgå varje användares behov av att se alla ärenden/meddelanden i samma översikt, oavsett om det finns en eller flera informationskällor för meddelanden/ärenden.
Sjukskrivningsprocessens fråga/svar
I sjukskrivningsprocessen utbyts säkra meddelanden mellan handläggare hos Försäkringskassan och medarbetare på vårdenheter. Det kan gälla begäran om kompletterande information kring ett medicinskt utlåtande, eller samordning av mötesbokning inför ett samrådsmöte. I fallet med sjukskrivningsprocessen initieras meddelandet (frågan) från Försäkringskassan utgående från ett ankommet medicinskt utlåtande. Information om vilken organisation som meddelandet ska riktas till, är därför redan känt. Sortiments- och utbudskatalogen är därmed inte inblandad. Ur vårdgivarens perspektiv finns bara en part att interagera med (försäkringskassan).
...
Figur 9 – Flödesmodell – säker meddelandehantering i sjukskrivningsprocessen
5.2 Informationssystemvy
I informationssystemvyn beskrivs en generell arkitektur (referensarkitektur) för att realisera behoven ur verksamhetsvyn. Beskrivningen består av en referensmodell för tjänsteorienterad integration och ett antal vägledande exempel.
...
De streckade pilarna i figuren visar sambandet mellan aktiviteter och informationskällor i verksamhetsvyn och realiserande beståndsdelar i referensarkitekturen.
5.2.1. Tjänstekontrakt
Tjänstekontrakt är en viktig förutsättning för lös koppling. Ett tjänstekontrakt specificerar ett behov av funktion och information (i form av IT-stöd) för en aktivitet i en process. Tjänstekontraktet specificerar behovet utgående från tjänstekonsumenters behov av informationsutbyte. Detta skall ske utan koppling eller bindning till något speciellt systems villkor eller förutsättningar att realisera behovet. Det innebär att en tjänsteproducent skall producera information enbart utifrån specifikationen i tjänstekontraktet, inte anpassa det till en speciell tjänstekonsuments förmågor. På motsvarande sätt skall en tjänstekonsument realiseras baserat på tjänstekontraktet och inte ta hänsyn till förmågorna hos enskilda tjänsteproducenter. På detta sätt uppnås principen om lös koppling (IT4).
...
För att kunna tolkas, administreras och versionshanteras behöver de tjänstekontrakt som stödjer en viss process eller informationsbehov grupperas. En sådan gruppering benämns Tjänstedomän. Nationell styrning av tjänstedomäner och uppdelning i tjänster inom tjänstedomäner sker inom nationella arkitekturfunktionen (Arkitektur och regelverk). På samma sätt kan tjänstedomäner byggas upp och förvaltas inom en organisation för att ge struktur åt det interna integrationsbehovet. Det effektivaste är troligen att samordna via systemleverantörernas kundgrupper, så att nationell samordning kan ske och komma kundgrupperna tillgodo.
Uppbyggnad av tjänstekontrakt
Beskrivningen av ett tjänstekontrakt har följande beståndsdelar, som namnges på engelska:
...
Komponent | Beskrivning |
| Domän | Alla tjänstekontrakt tillhör en domän. Hur domäners namnsättning går till beskrivs på rivta.se |
Tjänstekontrakt | Tjänsten uttrycks som ett verb + substantiv, på engelska. Exempel: - GetSubjectOfCareSchedule |
Huvudversion | Anger aktuell huvudversion, som löpande heltal. Tjänstekonsumenter och tjänsteproducenter som realiserar olika huvudversioner av ett tjänstekontrakt är inte kompatibla (kan inte kommunicera). |
Underversion | Anger aktuell underversion, som löpande heltal. Tjänstekonsumenter och tjänsteproducenter som realiserar olika underversioner av ett tjänstekontrakt är kompatibla (framåt/bakåt). |
In-meddelande | Informationsstrukturen som beskriver nyttolasten för frågemeddelandet. Meddelandedefinitioner kan återanvändas mellan tjänstekontrakt. |
Ut-meddelande | Informationsstrukturen som beskriver nyttolasten för svarsmeddelandet (finns inte för alla tjänstekontrakt, beroende tjänsteinteraktionstyp). Informationsstrukturen (eller del av) för nyttolast kan återanvändas mellan tjänstekontrakt. |
Tjänstekontraktens användning
Tjänstekontrakten utvecklas, versionshanteras och publiceras på en öppet tillgänglig projektinfrastruktur. Alla tjänstekontrakt som ligger under en arkitekturfunktions överseende publiceras på ett enhetligt sätt på samma plats. Det underlättar för leverantörer och andra intressenter att hitta, tillämpa dem, samt att räcka in begäran om tillägg och förändringar.
...
RIV Tekniska Anvisningar ger detaljerade regler för utformning av tjänstekontrakt.
5.2.2. Vägledande exempel
I resterande avsnitt inom Informationssystemvyn exemplifieras referensarkitekturens tillämpning genom vägledande exempel inom aktuella områden. Den faktiska realiseringsstrategin för respektive område fastställs av berörda arkitekturledningsfunktioner. Exemplen i t-boken syftar till att verifiera och kommunicera referensarkitekturen.
E-tjänst för invånare
Detta exempel beskriver hur den generella flödesmodellen för e-tjänster (ur verksamhetsvyn) kan realiseras enligt referensarkitekturen.
...
Steg | Beskrivning |
1-fråga | Tidboknings-e-tjänsten ber den nationella, aggregerande tjänsten ”Hämta bokade tider” att sammanställa alla tidbokningar för inloggad invånare. |
2 | Den aggregerande nationella tjänsten för tjänstekontraktet ”Hämta bokade tider” frågar stödtjänsten Engagemangsindex om HSA-id för alla mottagningar där invånaren har tidbokningar. Svaret innehåller en lista med tre vårdmottagningar hos två olika vårdgivare. |
3, 6, 9 | För var och en av mottagningarna frågar den aggregerande nationella tjänsten för ”Hämta bokade tider” den virtuella tjänsten för ”Hämta bokade tider” efter patientens tidbokningar hos respektive mottagning. De tre anropen görs parallellt, för att minska användarens väntan på det sammanställda svaret. |
5, 8, 11 | Den virtuella tjänsten för ”Hämta bokade tider” blir anropad tre gånger, parallellt. Varje anrop avser en informationsägare (vårdmottagning). För varje anrop tar den virtuella tjänsten hjälp av tjänsteadresseringskatalogen (4, 7, 10) för att översätta mottagningens HSA-id till den tekniska adressen för mottagningens ”hämta bokade tider”-tjänsteproducent. Med hjälp av den tekniska adressen kan virtuella tjänsten fråga aktuell tjänsteproducent efter patientens tidbokningar hos aktuell vårdmottagning. |
1-svar | När den aggregerande tjänsten fått svar från de tre anropen till den virtuella tjänsten, sammanställs svaren i en sammansatt lista av invånarens tidbokningar hos de tre mottagningarna. Listan lämnas sedan som svar till e-tjänsten, som presenterar den för användaren. |
12 | Användaren vill omboka den bokade tiden hos en av mottagningarna. Användaren väljer att visa detalj-vyn över bokningen. E-tjänsten använder då den virtuella tjänsten för tjänstekontraktet ”Hämta detaljer om bokning” för att fråga efter detaljer för aktuell bokning hos mottagningen i fråga (mottagningens HSA-id utgör verksamhetsadressen). Den här gången används inte en aggregerande tjänst, eftersom frågan riktas direkt mot en specifik verksamhet (mottagningen). Den virtuella tjänsten för ”Hämta detaljer om bokning” tar hjälp av tjänsteadresseringskatalogen (13) för att översätta vårdmottagningens HSA-id till den tekniska adressen till mottagningens tjänsteproducent för ”Hämta detaljer om bokning”-tjänstekontrakt. Med hjälp av den tekniska adressen kan den virtuella tjänsten fråga aktuell tjänsteproducent efter bokningsdetaljerna för aktuell bokning hos vårdmottagningen i fråga. |
14 | Tjänsteproducenten som realiserar tjänstekontraktet ”Hämta detaljer om bokning” för aktuell vårdmottagning (där bokningen som ska ombokas finns) returnerar svarsmeddelandet med bokningsdetaljerna till den virtuella tjänsten, som i sin tur lämnar svaret till e-tjänsten. |
15 | Användaren redigerar bokningsdetaljerna och anger en ny tid (i den verkliga processen föregås detta steg av att användaren genom e-tjänsten ber vårdenheten redovisa bokningsbara tider). E-tjänsten skickar därefter en begäran om ombokning hos aktuell vårdmottagning till den virtuella tjänsten för tjänstekontraktet ”Boka om” (vårdmottagning är verksamhetsadress). Den virtuella tjänsten ”Boka om” tar hjälp av tjänsteadresseringskatalogen (16) för att översätta vårdmottagningens HSA-id till den tekniska adressen för mottagningens ”Boka om”-tjänsteproducent. Med hjälp av den tekniska adressen kan den virtuella tjänsten vidareförmedla begäran om ombokning till aktuell tjänsteproducent för vårdmottagningen i fråga. |
17 | Vårdmottagningens tjänsteproducenten för tjänstekontraktet ”Boka om” genomför ombokningen och returnerar en kvittens som via den virtuella tjänsten når e-tjänsten. |
Åtkomst till sammanhållen journalföring
För medarbetarens olika tillämpningar, så som nationella patientöversikten och verksamhetens system för vårddokumentation finns behov av åtkomst till information inom sammanhållen journalföring och andra informationsmängder. Gemensamt är att informationen antingen har en nationell ägare (t.ex. läkemedelslista) eller är i behov av en aggregerande tjänst för att nationellt sammanställa informationen från många källor (de system som informationsägaren använder).
...
Figur 14 – Vägledande exempel för patientöversikt
Personuppgifter
Inom vård och omsorg finns många tjänstekonsumenter av personuppgifter – såväl standardsystem som lokalt och nationellt utvecklade system och e-tjänster. Det finns också många tjänsteproducenter som publicerar tjänster för åtkomst av personuppgifter. Ofta samordnas tjänsteproducenterna läns- eller regionvis, men det förekommer också mer lokala tjänsteproducenter, till exempel för information om en enskild kommuns invånare. Därför sker åtkomst enligt standardiserade tjänstekontrakt. Det ger en lös koppling mellan leverantörer av verksamhetssystem (tjänstekonsumenter) och de olika tekniska lösningar som tillämpas för mellanlager av personuppgifter inom olika organisationer. Grundinformationen kommer från skatteverket. Den hämtas till en lokal eller regional tjänst inom huvudman som berikar (illustreras av ) med information från lokala källor (t.ex. telefonnummer och annan information som håller bristande kvalité eller saknas hos Skatteverket). Alla lokala och regionala personuppgifttjänster publicerar sedan information enligt samma, nationella tjänstekontrakt för åtkomst från interna och externa tjänstekonsumenter.
...
Adressetiketten anger i detta fall kommun-kod. Tjänstekonsumenten kan även vara ett lokalt verksamhetssystem som behöver personuppgifter för en person som är mantalsskriven i annat län och därför inte finns i den lokala informationskällan. Genom att en lokal virtuell tjänst anropas (ingår i tjänstekonsumenten i denna figur), sker (vid kommun-kod i annat län) vägval till den nationella virtuella tjänst, som dirigerar frågan till tjänsteproducent hos ansvarigt län.
Replikering av stödtjänst
Stödtjänster är logiskt sett nationella. För att tillmötesgå höga krav på tillgänglighet kan stödtjänster behöva replikeras för att kunna hanteras inom samma infrastruktur som verksamhetskritiska tjänstekonsumenter (d.v.s. att finnas ”nära” tjänstekonsumenten).
...
Komponent | Beskrivning |
Tjänstekonsumenter - Spärrtjänst | Spärrtjänsten som tjänstekonsument möjliggör genom eget användargränssnitt eller genom tjänst (d.v.s. här i dubbla roller – producent mot anv. gränssnitt och som konsument mot övriga spärrtjänster) att registrera ny spärrinformation. Spärrtjänsten behöver integrera funktionalitet och infrastruktur för att orkestrera uppdatering av de andra spärrtjänsterna. Det innefattar att begära information från tjänsteadresseringskatalogen om vilka spärrtjänster som finns och att för var och en av dem (parallellt) anropa virtuell tjänst för registrering av spärrinformation. Spärrtjänsten behöver ha möjlighet till omsändning om en viss verksamhetsdress för stunden inte kan fullfölja tjänstekontraktet. Vid sidan av replikeringsflödet behöver också finnas tjänstekontrakt för initialladdning, så att man i användargränssnittet kan begära att hela innehållet ska skickas med riktat till en specifik instans (”informationsägare”). Detta följer typfallet för användandet av en tjänst i arkitekturen och beskrivs därför inte i figuren. |
Virtuella tjänster - Registrera Spärrinformation | Anrop till den virtuella tjänsten är adresserade med mottagande spärrtjänsts identitet som informationsägare. Efter uppslag i tjänstekatalogen dirigeras meddelandet vidare till tjänsteproducentens tekniska adress. |
Tjänsteproducenter | - Lokal instans av spärrtjänst: I rollen som tjänsteproducent realiserar spärrtjänsten tjänstekontraktet som representerar replikeringsfunktionen: ”Registrera spärrtjänst”. De lokala instanserna är lokala installationer a av samma spärrtjänstprodukt som tjänstekonsumenten. Versionshanteringsstrategin i nationella tjänstekontrakt möjliggör en kontrollerad uppgraderingsprocess för bakåt- och framåt-kompatibilitet mellan olika versioner. - Vårdsystem med inbyggd spärrtjänst: För regioner med ett gemensamt vårdsystem för alla vårdenheter, finns möjligheten att låta vårdsystemet direkt realisera tjänstekontraktet och därmed utgöra spärrtjänst. Om vårdsystemet också erbjuder registrering av spärr, behöver det också ikläda sig rollen som tjänstekonsument enligt tidigare beskrivning. |
5.3 Teknisk vy
I den tekniska vyn beskrivs identifierade stödtjänster och infrastrukturtjänster (plattformsfunktioner). Den beskriver också den federation som uppstår då referensarkitekturen tillämpas lokalt som del i en anslutningsarkitektur.
...
Komponent | Beskrivning |
Ärendestyrning | Plattform för ärendestyrning syftar till att rationalisera hur ärendestyrda rutiner realiseras. När ärendestyrning är ett dominerande inslag i en e-tjänst eller ett verksamhetssystem (så som SVPL, Remisshantering och ärendehanteringssystem) används ett konfigurerbart ärendestyrningsverktyg som bas för realiseringen. Det innebär att följande funktioner inte behöver specialutvecklas för varje verksamhetssystem eller e-tjänst med inslag av ärendestyrning: - Verktyg för att beskriva eller importera flödesbeskrivningar över ärenderutiner i BPMN (standard för att specificera processflöden) - Nya och förändrade ärenderutiner (på BPMN-format) kan ”driftsättas” av användare av verksamhetssystemet - Befintliga tjänster (aggregerande, virtuella, stödtjänster) kan kopplas in som informationskällor direkt av den som modellerar nya flöden (verktyg får stöd av tjänstekontrakten). På så sätt kan automatiska steg i flödet hanteras utan utvecklingsarbete behöver beställas. - Formulär för manuella steg i flödet kan skapas direkt i flödesverktyget, utan utvecklingsarbete behöver beställas. - Genom koppling till befintliga kataloger kan plattformens inbyggda möjligheter till avisering av väntande uppdrag kopplas till verksamhetens standardiserade kanaler för meddelandehantering. Genom att använda dessa funktioner och att kombinera dem med riktade utvecklingsinsatser där kraven inte naturligt låter sig realiseras genom beskrivna funktioner, formas verksamhetssystem och e-tjänster som kan förändras och utvecklas utan behov av nya systemversioner. |
Tjänsteväxel | En tjänsteväxel ansvarar för att översätta mellan den modell för teknisk kommunikation som regleras i denna referensarkitektur och modeller som tillämpas av externa parter, så som myndigheter. Ett exempel är en tjänsteväxel som växlar meddelanden mellan RIV Tekniska Anvisningar och myndigheternas SHS-arkitektur. En tjänsteväxel är en systematisk realisering som genom konfigurationsändring i löpande drift kontinuerligt kan utökas med stöd för nya tjänstekontrakt – för såväl inkommande som utgående tjänsteanrop. Tjänsteväxeln är en nationell tjänst som inte är synlig för tjänstekonsumenter hos huvudmännen. Virtuella tjänster i nationella domänen dirigerar meddelande från huvudmännens tjänsteproducenter till nationell tjänsteväxel (t.ex. för att skicka medicinska utlåtanden till försäkringskassan). Meddelanden från externa parter adresserade till huvudmännen dirigeras via nationell virtuell tjänst till huvudmännens tjänsteproducenter. |
Tjänsteplattform | Tjänsteplattform är ett samlingsnamn för de komponenter som utgör plattform för tjänstebaserad integration över huvudmannagränser. Varje samverkansdomän i en federation (se senare avsnitt) kan ha en egen instans eller ingå i den överordnade domänens plattform. Den nationella samverkansdomänen har en instans som publicerar virtuella tjänster och aggregerande tjänster för alla nationella tjänstekontrakt (aggregerande tjänster och virtuella tjänster beskrivs i informationssystemvyn). All samverkan mellan samverkansdomäner och inom den nationella domänen sker via tjänster i den nationella tjänsteplattformen. - Aggregeringsplattform: Erbjuder infrastruktur för aggregerande tjänster. Dess primära syfte är systematisk realisering av aggregerande tjänster. Som en effekt kan generella aspekter av aggregering förändras i plattformen istället för att alla enskilda tjänster behöver förändras. Det ger gemensam hantering av gemensamma behov, så som felhantering, parallellitet, övervakning, loggning, uppslag i engagemangsindex m.m. - Virtualiseringsplattform: Erbjuder infrastruktur för virtuella tjänster. Dess primära syfte är systematisk realisering av virtuella tjänster. Som en effekt kan generella aspekter av virtualisering förändras i plattformen i stället för att alla enskilda tjänster behöver förändras. Det ger gemensam hantering av gemensamma behov, så som felhantering, åtkomstkontroll, övervakning, vägval. loggning, uppdatering av engagemangsindex, SLA-uppföljning mot tjänsteproducenter m.m. |
Anslutningsarkitektur | Anslutningsarkitektur syftar på systematisk hantering av anslutning av huvudmännens verksamhetssystem som tjänsteproducenter i den nationella arkitekturen. Anslutningsarkitekturen kan bestå av en av huvudmannen tillämpad tjänsteplattform, uppbackad av kompletterande stöd för att integrera verksamhetssystem till nationella tjänstekontrakt och standarder för interoperabilitet (RIV TA). Det kan t.ex. gälla transformering mellan meddelandeformat och åtkomst till informationskällor via specifika protokoll. Anslutningsarkitektur exemplifieras under avsnittet om referensarkitekturen i federation. |
Stödtjänst | Stödtjänsterna bör i möjligaste mån vara utvecklade på ett sätt som ger vårdgivarna möjlighet att följa sina lokala strategier för driftsplattformar. Det gäller så väl val av applikationsplattform (t.ex. Java-plattformen) som val av databas (leverantör med stöd för prioriterade plattformar). Flera av stödtjänsterna har krav på orkestrering för att utföra parallella tjänsteanrop i syfte att aggregera eller replikera information. Vid utveckling av stödtjänster där sådana krav finns, bör paketerade, beprövade komponenter som på ett systematiskt sätt kan hantera orkestrering, integreras i stödtjänstens arkitektur, snarare än att dessa egenskaper tillförs genom egenutvecklade ”mekanismer”. |
- Tjänsteadresseringskatalog | Tjänsteadresseringskatalogen är en komponent inom tjänsteplattformen som ligger till grund för logisk adressering åtkomstkontroll baserad på logisk adressering som utförs i virtualiseringsplattformen. Logisk adressering bygger på att tjänstekonsumenten i anropet anger identiteten för vilken verksamhet eller system som anropet avser istället för att ange den tekniska adressen (anslutningspunkten) adresseringsfunktionen i tjänsteplattformen översätter därefter, med hjälp av tjänsteadresseringskatalogen, den logiska adressen till den tekniska anslutningsadress som plattformen använder för att nå den logiska adressaten. |
- Engagemangsindextjänst | Engagemangsindex (EI) är en nationell tjänst som erbjuder ett mellanlager av indexinformation. Informationen hålls synkroniserad med informationskällor genom att dessa uppdaterar informationen i EI när den förändras i källan. Tjänsten lagrar den information som behövs för att veta var det finns detaljerad information att hämta. Det innebär i de flesta fall (utöver engagemangstyp) invånarens personnummer och Logisk adress för informationsägarens verksamhet (t.ex. vårdgivare, vårdenhet, län, skola eller kommun) eller källsystemet som bär informationen. (vilket som anges beror på om det är verksamhet eller källsystem som används för logisk adressering. Informationen som lagras i engagemangsindex används därefter av aggregerande tjänster för att sammanställa vilken information som finns för en viss individ/entitet. Det är alltså endast aggregerande tjänster som direkt får läsa informationen från engagemangsindex. |
- Meddelandetjänst | En informationskälla som följer nationellt fastställda tjänstekontrakt för att lämna och hämta meddelanden. producenter av dessa tjänstekontrakt (meddelandetjänster) utgör basen för säker meddelandehantering över huvudmannagränser och integreras i olika former av verksamhetsstöd och invånartjänster. |
5.3.1. Tjänsteadresseringskatalog
Modellen nedan beskriver den informationsstruktur som behövs för att representera verksamhetsadressering och behörighetsstyrning i en tjänsteadresseringskatalog:
Figur 18 – Datalager, tjänsteadresseringskatalog
5.3.2. Engagemangsindex
Komponenten Engagemangsindex innehåller aktuell information om en individs aktuella engagemang inom vård och omsorg. Engagemang används här som en generell term för olika typer av relationer mellan vård/omsorg och invånaren, som det finns behov av att känna till för det syfte som engagemangsindex tjänar (se Verksamhetsvy, ”Att veta vilka informationsägare som ska bidra till översikten”). Flera olika engagemangstyper hanteras. Några exempel kan vara Journalateckningar, Diagnoser, Bokad tid, Inskriven.
...
Mönstret för hur index uppdateras beskrivs i informationssystemvyns vägledande exempel ”Uppdatering av engagemangsindex”.
5.3.3. Referensarkitekturen i en federation
Referensarkitekturen förutsätter att huvudmännen ansluter verksamhetssystem i enlighet med nationellt fastställda tjänstekontrakt och fastställd standard för teknisk interoperabilitet. Följande figur visar ett exempel på hur den tekniska referensarkitekturen kan tillämpas lokalt som en del i en anslutningsarkitektur. Arkitekturen i skissen tar hänsyn till federationsprincipen (IT6) genom att perimeterskyddet är samma för Sjunet och Internet.
...
Figuren illustrerar ett exempel på anslutningsarkitektur i federation med lokal (inom huvudman) instans av referensarkitekturen, där integration sker över internet och Sjunet. (Observera att federation här syftar till informationsutbyte. Federation i syfte att stödja navigering mellan e-tjänster över huvudmannagränser (SAML, SSO) är en frågeställning som är oberoende av detta exempel, men som också täcks av IT6.)
Grundläggande egenskaper i arkitekturen:
...
Figur 22 – Referensarkitekturen i federation - huvudmannaperspektivet
T-boken över tiden
Revision | Viktiga förändringar |
Revision A, 2007 | Första utgåvan av T-boken |
Revision B, 2011 | - Nya inledande kapitel (1-2). Arbetet har genomförts i samverkan mellan kommuner och landsting. - Omarbetad struktur, med inspiration från Togaf 9 - Tekniska styrande principer har tillkommit. Tidigare fanns principer enbart från den gemensamma T-boken. - T-bokens sammanhang är beskrivet. Det har tydliggjorts att anvisningar och detaljerade regler för styrning ligger utanför T-boken. - Landstingsvård och Kommunal omsorg omfattas av T-boken (tidigare enbart landstingsvård) - RRR:er har ersatts med styrande principer och referensarkitektur. - T-boken täcker nu också e-tjänsteutveckling - Ett antal nya element och begrepp i arkitekturen har tillkommit. De viktigaste är Stödtjänst, Partneringång/utgång, aggregerande tjänst och engagemangsindex. - Delar av en anslutningsarkitektur för huvudmännen är belyst, liksom huvudmännens system som tjänstekonsumenter. - Detaljer kring tjänsteinteraktionstyper och tjänstekontrakt är utlyft till översiktsanvisningen för RIV Tekniska Anvisningar version 2. - Delar av arkitekturen som relaterar till lagtolkningar och regelverk för PDL har lyfts ut (detaljerade typanvändningsfall) och planeras få styrning genom kommande ställningstaganden från Arkitektur och regelverk. - Detaljerade typanvändningsfall har ersatts med typ-flödesmodeller i t-bokens verksamhetsvy. - En stödtjänst för nationellt patient-/individ-index har tillkommit, i syfte att stödja vårdgivar- och invånartjänsters behov av att skapa nationella översikter av individens engagemang. |
| Revision C, xxxx |
Bilaga – Ordlista och förkortningar
Ordlista
För termer som inte återfinns i denna ordlista hänvisas till ordlistan som är publicerad på rivta.se http://rivta.se/documents/ARK_0035
| Term | Beskrivning |
Arkitektur och regelverk | Arkitektur och regelverk är en arkitekturfunktion på nationell nivå under Inera. |
Back office | Administration funktion som stöder verksamheten. |
Brukare | Kan betyda individ som brukar omsorg |
Förmågor | Så kallade "kapabiliteter", möjliggörare. |
HCC Funktion | En certifikatstyp i SITHS-modellen som används för servers och applikationer för autentisering, kryptering och signering. Certifikaten för en viss Funktion ges ut parvis: ”HCC Funktion för autentisering och kryptering” och ” HCC Funktion för signering”. |
Lingua franca | Ett internationellt hjälpspråk för kommunikation mellan människor med olika modersmål. |
Local governance | Lokal styrning. |
Ramverk | Ett ramverk som reglerar hur utveckling skall ske för att hålla en nationell standard ur tekniskt, säkerhetsmässigt och användbarhetsmässigt perspektiv. Det är en uppsättning regler, riktlinjer och rekommendationer med tillhörande anvisningar som skall vara styrande, vägledande och stödjande. |
Rådgivningsstödet, RGS | Ska stödja telefonsjuksköterskan vid bedömning av vårdbehov hos den som ringer till 1177 Sjukvårdsrådgivningen. Rådgivningsstödet består av tre delar som samverkar med varandra - medicinskt innehåll, katalog och journal. |
Service Level Agreement, SLA | Överenskommelse mellan leverantör och kund bland annat gällande en tjänsts tillgänglighet. |
SITHS | En nationell säkerhetslösning där vårdgivare kan identifiera sig och ge bevis för sin behörighet. SITHS-modellen bygger på att anställda i vård och omsorg har ett personligt elektroniskt ID-kort med ett elektroniskt PKI-certifikat. |
Förkortningar
BHD | Barnhälsodata |
DMZ | Demilitariserad zon |
ITIL | IT Infrastructure Library |
LOV | Lag Om Valfrihetssystem |
NPÖ | Nationell patientöversikt |
PDL | Patientdatalagen |
PKI | Public Key Infrastructure |
RGS | Rådgivningsstödet |
RIV | Regelverk för Interoperabilitet inom Vård och omsorg |
SKL | Sveriges kommuner och landsting |
SLA | Service Level Agreement |
SOL | Socialtjänstlagen |
SVPL | Samordnad vårdplanering |
TOGAF | The Open Group Architecture Framework |
Följande personer har deltagit i framtagandet av T-boken:
T-boken version A | |
|---|---|
| Namn | Organisation, Län |
| Sara 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 |
T-boken version B | |
| Blomberg, Magnus | Jönköping kommun, Jönköping |
| Eltes, Johan | Konsult, Center för eHälsa i samverkan |
| Eriksson, Lennart | Konsult, Center för eHälsa i samverkan |
| Gabrielsson, Stig | Luleå kommun, Norrbotten |
| Granström, Anders | Luleå kommun, Norrbotten |
| Jessica Isegran | Västra Götalandsregionen |
| Kartman, Gunnar | Karlstads kommun, Värmland |
| Lindahl, David | Landstinget Kalmar |
| Mannerhagen, Peter | Västerås stad, Västmanland |
| Meunier, Sara | Center för eHälsa i samverkan |
| Norr, Anders | Landstinget i Östergötland |
Nygren, Åke | Leksands kommun, Dalarna |
| Palmgren, Ulf | Stockholms läns landsting |
| Svensson, Peter | Landstinget i Blekinge |
| Svensson, Stefan | Stockholm Stad, Stockholm |
| Wedin, Roy | Sjuhärad kommunalförbund, Västra Götaland |
T-boken version C | |
| Björn Hedman | Inera AB |
Lars Erik Röjerås | Inera AB |
| Ranjdar Fallyih | Inera AB |
| Rolf Rönnback | Inera AB |
...