RSIT - Regions Skånes IT-Förvaltning Ansvarig Fredrik S Carlsson Skapat 2009-02-10 Senaste revision 2009-06-11 Teknisk funktionsspecifikation Samverkanslager Region Skåne / Kommunförbundet Skåne
Innehållsförteckning INNEHÅLLSFÖRTECKNING... 2 1 DOKUMENTHISTORIK... 5 1.1 VERSIONER... 5 1.2 REVISIONER... 5 2 FÖRKORTNINGAR... 5 3 DOKUMENTETS BRUKANDE... 5 3.1 DOKUMENTETS SYFTE OCH OMFATTNING... 5 3.2 MOTTAGARE... 5 3.3 LÄSANVISNING... 5 3.4 KONTAKTPERSONER... 6 4 INLEDNING... 7 4.1 INGÅENDE SYSTEM... 7 4.2 KOMPONENTER... 8 4.2.1 Administrationsgränssnitt (Nordic Edge Identity Manager)... 9 4.2.2 Integrationsplattform (Microsoft BizTalk)... 9 4.2.3 Kodserver... 10 4.2.4 Kvalitetssäkringstjänst (Navet)... 10 4.2.5 Metakatalog (Novell Identity Manager)... 10 4.2.6 HSA (Hälso- och sjukvårdens adressregister)... 11 4.3 UPPSÄTTNING... 11 4.4 INFÖRANDE... 11 5 DATAFLÖDE... 12 5.1.1 Personrelaterade uppgifter... 12 5.1.2 Organisationsrelaterade uppgifter... 13 6 ADMINISTRATIONSGRÄNSSNITT (NORDIC EDGE IM)... 15 6.1 BESKRIVNING... 15 6.2 UPPSÄTTNING... 16 6.3 AUTENTISERING... 16 6.4 AUKTORISERING... 16 6.5 MOCKUPS... 16 6.5.1 Översikt... 17 6.5.2 Huvudfönster... 17 6.5.3 Skapa person... 18 6.5.4 Hantera anställningar... 21 6.6 FLYTTA ANSTÄLLNING... 22 6.7 TA BORT ANSTÄLLNING... 23 6.8 SKAPA ENHET... 24 6.9 HANTERA ENHET... 25 6.10 TA BORT ENHET... 26 7 KODSERVER... 27 7.1 BESKRIVNING... 27 7.2 FASTSTÄLLDA VÄRDEMÄNGDER... 27 7.2.1 Befattning och befattningskod... 27 7.2.2 Specialitet och specialitetskod... 28 Sida 2 av 52
7.2.3 Legitimerad yrkesgrupp... 29 7.2.4 Enhetstyp... 30 7.2.5 Verksamhetskod och verksamhet... 30 7.2.6 Vårdform... 30 7.2.7 Visas för... 31 8 KVALITETSSÄKRINGSTJÄNST (NAVET)... 32 8.1 BESKRIVNING... 32 8.2 UPPGIFTER... 32 8.2.1 Förnamn... 32 8.2.2 Initial... 32 8.2.3 Mellannamn... 33 8.2.4 Efternamn... 33 8.2.5 Fullständigt namn... 33 8.3 EFTERKONTROLL... 33 8.4 ÄNDRING AV NAMN... 33 9 METAKATALOG... 34 9.1 KATALOGDESIGN... 34 9.1.1 Katalogstruktur... 35 9.2 OBJEKT... 35 9.2.1 Namnsättning klasser... 35 9.2.2 Namnsättning attribut... 35 9.3 OBJEKTSTYPER... 36 9.3.1 piduser... 37 9.3.2 pidemployee... 38 9.3.3 Organizational Unit... 39 9.4 KOMMUNIKATION MOT INTEGRATIONSPLATTFORM... 40 9.5 REGELVERK... 41 9.5.1 Fullständigt namn, Full Name... 41 9.5.2 Användartyp, pidusertype... 41 9.5.3 Status, pidstatus... 41 9.5.4 Kategori, pidcategory... 42 9.5.5 Fastställda värdemängder... 42 9.5.5.1 Anställningsobjekt pidemployee... 42 9.5.5.2 Organisationsobjekt... 42 9.5.6 Unikt id... 43 9.5.7 Unika anställningslöpnummer... 43 9.5.8 Sökväg till ett objekt... 43 9.5.9 Borttagning av en person... 44 9.5.10 Borttagning av en anställning... 44 9.5.11 Borttagning av en enhet... 44 10 HSA... 45 10.1 BESKRIVNING... 45 10.2 SYNKRONISERING... 45 10.2.1 Från metakatalogen till HSA... 46 10.2.1.1 Urval... 46 10.2.2 Från HSA till Metakatalogen... 46 10.3 SCHEMAMAPPNING... 46 10.4 NAMNSÄTTNING... 48 10.5 UNIK NYCKEL (ASSOCIATION)... 48 10.6 MATCHNING... 48 10.7 RUTINER FÖR SITHS... 49 10.8 REGELVERK... 49 10.8.1 Ärvda attributsvärden för organisatoriska enheter... 49 10.8.2 Placeringslogik... 50 Sida 3 av 52
10.8.3 Flytt av användare... 50 10.8.4 Flytt av enhet... 50 10.8.5 Namnbyte... 50 10.8.5.1 Unikt id för HSA... 50 10.8.6 Certifikatshantering på anställningen... 51 10.8.7 Dummy-värden för SITHS-kort och certifikat... 51 10.8.8 Kompletterande uppgifter för SITHS... 52 10.8.9 Ta bort anställning... 52 10.8.10 Ta bort enhet... 52 Sida 4 av 52
1 Dokumenthistorik 1.1 Versioner Version Datum Beskrivning Upprättad av 0.8 2009-04-27 Grunddokument skapat André Hallberg 1.0 2009-06-10 Slutsammanställning enligt feedback från Region Skåne André Hallberg 1.2 Revisioner Avsnitt Datum Beskrivning Upprättad av 4.2 2009-06-11 Justerat infrastrukturskiss Thomas Andersson 2 Förkortningar Förkortning Beskrivning Pulsen Pulsen Integration AB, 556353-7579 IM Nordic Edge Identity Manager 3 Dokumentets brukande Dokumentet är att betrakta som ett underlag för ett införande. Detta sker förslagsvis i ett pilotprojekt där lösningen valideras innan den erbjuds de skånska kommunerna som en färdig tjänst till en bestämd kostnad. Dokument är vidare dynamiskt och kommer vid behov att uppdateras enligt gällande versions- och revisionshantering. 3.1 Dokumentets syfte och omfattning Detta dokument syftar till att förädla den principiella modell som tidigare framarbetats över ett regionalt och kommunalt samverkanslager. Dokumentet, kallat teknisk funktionsspecifikation, specificerar konkreta lösningsförlag som möter de funktionskrav som framarbetats under den funktionella projekteringen. 3.2 Mottagare Den primära målgruppen för dokumentet är projektmedarbetare samt beslutsfattare inom Region Skåne, Kommunförbundet Skåne samt de skånska kommunerna. Dokumentet skall även kunna användas som underlag vid information till andra projektintressenter. 3.3 Läsanvisning För att kunna ta till sig dokumentets innehåll bedöms en grundläggande insikt krävas inom följande områden: Barnhälsodataprojektet (BHD) delprojekt ID-projektet Nationell IT-strategi för vård och omsorg SVPL Sjukvårdsrådgivningens tjänster HSA/SITHS/BIF Djupgående kunskaper i IT-system Erfarenhet av teknisk dokumentation Övergripande teknisk produktkunskap kring berörda komponenter i lösningen Sida 5 av 52
3.4 Kontaktpersoner Region Skåne Fredrik Carlsson Kompetensområdesansvarig katalogtjänster 0768-87 13 87 fredrik.s.carlsson@skane.se David Johansson Programutvecklare/IT-tekniker 0411-89 70 62 david.a.johansson@skane.se Pulsen Integration André Hallberg Konsult IAM/Utredare 046-38 51 07 andre.hallberg@pulsen.se Thomas Andersson Projektledare 046-38 51 05 thomas.andersson@pulsen.se Sida 6 av 52
4 Inledning 4.1 Ingående system Funktioner i samverkanslagret omfattar följande system: Metakatalog Identity Manager (IM) HSA Navet Kodserver Integrationsplattform Sida 7 av 52
4.2 Komponenter Produktionsmiljö Region Skåne - Internt Kodserver Metakatalog Integrationsplattform Region Skåne Region - Skåne - Externt Externt WS WS WS Sjunet Nordic Edge (IM) LDAPS Automatisk anslutning IM HSA Manuell Manuell WS Skatteverket anslutning anslutning Automatisk anslutning Navet Figur 1. Observera att bilden är ett exempel på infrastrukturen och kan förändras under ett införande Sida 8 av 52
4.2.1 Administrationsgränssnitt (Nordic Edge Identity Manager) Produkten IM används som administrationsgränssnitt och erbjuder funktioner för att lägga upp personer i samverkanslagret och ge möjlighet att administrera anställningar och organisatoriska enheter. Från huvudmenyn möts man av en översiktsbild på strukturen i HSA katalogen och erbjuds möjligheten att administrera användare, anställningar och enheter. Här kan givetvis även befintliga användare, anställningar och enheter administreras i förvaltningssyfte. Väl i gränssnittet möts man av formulär i vilka information kring personer och enheter matas in och förändras. Till skillnad från det nationella gränssnittet så är uppgiftsfloran reducerad till endast basinformation samt information som specifikt krävs för SITHS, SVPL eller E-dos. Utöver ren information så kan personer kompletteras med tillhörande foto och enheter pekas ut på en karta för att erhålla de geografiska koordinaterna. Sistnämnd funktionalitet erbjuds via en eventuell integration mot Google Maps. Informationen kommer att struktureras så att personrelaterad information (ex. namn och personnummer) skiljs från den anställningsrelaterade informationen. Av den anledningen så finns det separata vyer för att administrera personen respektive dess anställningar. Detta ger fördelar i form av att administratörer inte behöver dubbeladministrera information som är personrelaterad samt att information kan knytas till en specifik anställning. Uppgifterna kring person, anställning och enhet är i, den mån det är möjligt, kopplat till fastställda värdemängder (ex. AID-koder, verksamhetskoder och vårdformer). Kraven från SVPL tillsammans med standardiseringsmöjligheter är drivande faktorer för denna hantering. De fastställda värdemängderna hämtas från Region Skånes kodserver som erbjuder dessa fastställda kodverk. Denna typ av information kontrolleras vid varje upplägg och erbjuds som val via rullningslistor i gränssnittet. Administrationsgränssnittet har slutligen en design som erbjuder stora möjligheter till att framöver hantera utökade uppgifter eller andra käll- och målsystem (än HSA). 4.2.2 Integrationsplattform (Microsoft BizTalk) Microsoft BizTalk hjälper till att föra samman information från de ingående komponenterna i samverkanslagret. BizTalk kommer att fungera som ett kommunikationsnav mellan Region Skånes interna och externa nät för att leverera tjänster på ett säkert sätt. BizTalk kommunicerar och samarbetar dynamiskt med andra komponenter i samverkanslagret via Web Services eller XML för utbyte av dokument mellan olika system som är anslutna till integrationsplattformen. Övriga språk som kan tillämpas är exempelvis JDBC, LDAP och ODBC. Valet förväntas bero på aktuell applikation, katalogtjänst eller verksamhetssystem samt konverteringsbehovet vid utbyte av information. Region Skånes BizTalk-installation används redan idag av applikationen Samordnad Vårdplanering (SVPL) samt för att erbjuda tjänster i Region Skånes interna HSA-katalog. Sida 9 av 52
4.2.3 Kodserver Kodservern kommer att etableras av Region Skåne för att kunna användas av flera aktörer. En aktör i sammanhanget är samverkanslagret som använder kodservern för de fastställda värdemängder som är obligatoriska för HSA, SVPL och/eller SITHS. Här krävs och efterfrågas kodverk för såväl person som enhet. De fastställda värdemängder som ska tillhandahållas i samverkanslagret baseras på etablerade källor då sådana finns, exempelvis nationella kodverk från Socialstyrelsen eller Sjukvårdsrådgivningen. För mer information om kodservern, se avsnitt 6. 4.2.4 Kvalitetssäkringstjänst (Navet) Skatteverkets e-tjänst Navet är den tjänst som ska användas för att kvalitetssäkra personuppgifter i samverkanslagret. Detta enligt fattat beslut av Region Skåne vid ett möte med Tieto den 11 juni 2009. Vid detta möte medverkade Fredrik S Carlsson, Peter Bergström, Eva Plym-Forshell och Per-Erik Nygren. Navet Ur samverkanslagrets perspektiv så är det inte ett behov utan ett direkt krav att de uppgifter som matas in är kvalitetssäkrade och följer personuppgiftslagen vid utfärdning av e-legitimationer exempelvis SITHS. Det är ett krav som initialt kommer från utfärdande organisationer för SITHS men som på sikt kommer att finnas för varje enskild tjänst som ska etableras och delas av Region Skåne och de skånska kommunerna. Vidare baseras hela tanken runt HSA-katalogen på att denna endast ska innehålla kvalitetssäkrade uppgifter. 4.2.5 Metakatalog (Novell Identity Manager) Metakatalogen hanterar alla identiteter i samverkanslagret och erbjuder därmed även den kompletta översiktsbilden kring en person och dess anställningar. Komponenten är regelverksstyrd och arbetar med person-, anställnings- och enhetsrelaterad information på ett kategoriserat sätt. Den möjliggör en mer rationell hantering av s.k. flerförekomster, exempelvis en person med flera anställningar inom en eller flera organisationer, och tillser även att förutsättande information såsom HSA-id genereras. Med höjd tagen för framtida utökning av tjänsteutbudet i samverkanslagret, mot exempelvis privata vårdgivare, så genererar metakatalogen även andra unika ID:n. Ett exempel på detta är ett Skåne-unikt K-id (Kommun-ID) för alla anställda. En funktion som inte är ett krav för att möta behoven från SITHS, SVPL och E-dos men som öppnar dörren för framtida federativa e- tjänster. Som identitetslager erbjuder vidare metakatalogen en historik kring HSA-id, K-id, person- och enheter samt certifikat. En historik som, utöver ett rent syfte om spårbarhet och säkerhet, erbjuder möjligheten att återfå egenskaper för en person eller enhet som en gång avslutats. Logiken och regelverken i metakatalogen är händelsestyrda och reagerar i realtid på uppgiftsförändringar som kommer från integrationsplattformen. Uppgifter skapas, förändras och tas därför alltid bort enligt satta regler. En funktion som på sikt kan utökas med beslutsflöden (workflows) för att få en digital godkännandeprocess där utvalda förändringar signeras (godkänns/avslås) av utsedda beslutsfattare. Sida 10 av 52
4.2.6 HSA (Hälso- och sjukvårdens adressregister) HSA en katalogtjänst som upprättats nationellt för att stödja samverkan mellan olika aktörer inom vård och omsorg genom att säkra tillgången till aktuell och korrekt information över organisationsgränserna. Region Skåne har idag en intern HSA-katalog ansluten mot Sjunet. Denna instans kommer inom samverkanslagret att användas för även kommunerna och kommer därmed utgöra den regionala HSA-katalogen för Skåne. Med befintlig DSP-koppling ansluts HSA-katalogen mot den nationella noden enligt gällande riktlinjer från Sjukvårdsrådgivningen. Utöver sin funktion som adressregister så är HSA tillika källan som används vid utfärdande av SITHS-certifikat (Säker IT inom Hälso- och Sjukvård). Denna säkerhetslösning tillämpas praktiskt på olika sätt där s.k. SITHS-kort för anställda inom vård- och omsorg är en högst aktuell tillämpning då SVPL och, inom kort, E-dos kräver detta för autentisering. Administrationen av SITHS-certifikat kommer dock även efter samverkanslagrets inträde att genomföras via SITHS Admin. 4.3 Uppsättning Samverkanslagret kommer att utvecklas och införas i såväl Region Skånes test- som produktionsmiljö. Dessa kommer att vara identiska i sin uppsättning men helt åtskilda. Testmiljön kommer att användas som valideringspunkt för all framtida utveckling. Detta för att säkerställa att införande och lansering av nya tjänster i samverkanslagret sker med hög kvalitet och på ett beprövat sätt. För en mer komplett översyn av teknisk uppsättning av Samverkanslagret, se dokument #27516_Teknisk_Design_Samverkanslagret. 4.4 Införande Införande av den tekniska lösningen rekommenderas ske i tre olika steg: 1) Uppsättning av lösning i testmiljö 2) Pilotuppsättning i produktionsmiljö med tillhörande validering 3) Driftsättning i produktionsmiljö samt lansering av färdig tjänst All uppsättning kvalitetssäkras med hjälp av framtagna testprotokoll (System Acceptance Test) och utsedda pilotkommuner. Sida 11 av 52
5 Dataflöde I samverkanslagret kommer uppgifter för användare och organisationsenheter hanteras genom ett dataflöde. Dataflödet visar vilka verksamhetssystem som är givare (G) eller prenumeranter (P) på uppgifter i samverkanslagret. 5.1.1 Personrelaterade uppgifter Uppgift Nordic Edge (IM) Navet Kodserver Metakatalog HSAkatalog Personnummer G P P Förnamn P G P P Tilltalsnamn P G P P Initial G P P Mellannamn P G P P Efternamn P G P P Personlig bild G P P Fullständigt namn P G P P Objektsnamn (HSA) G P Befattning P G P P Befattningskod P G P P Fax G P P Mobiltelefon G P P Sida 12 av 52
Uppgift Nordic Edge (IM) Navet Kodserver Metakatalog HSAkatalog Växeltelefon G P P Unikt ID P G P HSA-id P G P Status G P Specifika uppgifter för SITHS Mifareslinga P P G Kortnummer P P G Publik nyckel P P G Serienummer P P G Giltighetstid (från och med) P P G Giltighetstid (till och med) P P G 5.1.2 Organisationsrelaterade uppgifter Uppgift Nordic Edge (IM) Navet Kodserver Metakatalog HSAkatalog HSA-id P G P E-postadress G P P Organisationsnamn Organisationsnummer P G P P P G P P Sida 13 av 52
Uppgift Nordic Edge (IM) Navet Kodserver Metakatalog HSAkatalog Postadress G P P Telefonnummer G P P Enhetsnamn G P P Geografisk plats P G P P Länskod P G P P Kommunkod P G P P Kommunnamn P G P P Telefontid G P P Leveransadress G P P Fax G P P Mobiltelefon G P P Växeltelefon G P P Verksamhet P G P P Verksamhetskod P G P P Vårdform P G P P Enhetstyp P G P P Sida 14 av 52
6 Administrationsgränssnitt (Nordic Edge IM) 6.1 Beskrivning Nordic Edge Identity Manager ska användas för att erbjuda användarna ett grafiskt administrationsgränssnitt till de tjänster som erbjuds inom samverkanslagret. Detta innefattar möjligheter att lägga upp och administrera användare, deras anställningar samt enhetsstrukturen. Varje kommun tilldelas behörigheter att administrera sin organisationsstruktur och anställda i HSA-katalogen. Vilka kommunens administratörer är regleras via avtal mellan Region Skåne och kommunen. IM kommer att använda och återanvända de säkra funktioner för skapande och uppdatering som publiceras genom integrationsplattformen. Detta för att minimera underhållet av IMinstanserna vid eventuella förändringar. Samarbetet med integrationsplattformen säkerställer vidare att endast uppgifter som är kvalitetssäkrade och uppfyller kravet från RIV kan registreras. Slutligen så kommer samtliga läsanrop mot Region Skånes interna HSA-katalog att ske via certifikatssäkrade LDAPS-anslutningar. Region Skånes interna nät Integrationsplattform Kopplingar till befintliga system Säker Integrationsplattformskoppling Region skåne DMZ SJUNET DMZ Integrationsplattform Frontend WS WS WS WS-XML HSA LDAPS IM Grafiskt gränssnitt Användare Sida 15 av 52
6.2 Uppsättning IM installeras på två virtuella instanser med syftet om redundans samt framtida lastbalansering om så skulle krävas. Instanserna sätts upp fristående och använder sig av ett gemensamt filsystem där formulär och auktoriseringsmetoder lagras. Servrarna placeras på den del av Region Skånes DMZ-nät som kan nås av externa parter. Detta för att kommunerna, eller andra externa parter, ska kunna få tillgång till administrationsgränssnittet. IM Instans 1 IM Instans 2 Filserver Figur 1. Observera att uppsättningen kan förändras vid pilotinförandet 6.3 Autentisering För säker autentisering används SITHS-certifikat i kombination med BIF-tjänsterna alternativt Nordic Edge Certificate Services. Beslutet om säkerhetsramverk är inte projektets men behöver vara fattat innan ett införande kan påbörjas. Vid autentisering kommer giltighetstiden kontrolleras på användarens SITHS-certifikat att kontrolleras mot utgivaren av certifikatet. Vidare genomförs en automatisk kontroll mot aktuella spärrlistor såsom CRL och/eller OSCP. 6.4 Auktorisering Samverkanslagret kommer initialt att baseras på två olika roller administratörer och läsare. Vilken roll en person tillhör kontrolleras per automatik mot certifikatet. En utsedd administratör för kommunen kommer att vara behörig att läsa och förändra i sin del av HSA. En läsare kan i sin tur endast läsa och bläddra i HSA från administrationsgränssnittets huvudfönster. Gemensamt för båda roller är att de kräver en autentisering med SITHS-kort. 6.5 Mockups Mockups är en modell som beskriver de formulär för funktioner och händelser som kommer att finnas i administrationsgränssnittet. De är framtagna med syftet att beskriva och demonstrera den planerade utformningen av gränssnittet. Sida 16 av 52
6.5.1 Översikt Översikten visar sambandet mellan de mockups som tagits fram för att exemplifiera administrationen av användare och enheter i samverkanslagret. 6.5.2 Huvudfönster 1. Huvudfönstret mot HSA-katalogen visas oberoende om användaren är auktoriserad som administratör eller läsare i samverkanslagret. 2. Är användaren en administratör så har han/hon även valen om att kunna skapa, ändra, söka och ta bort objekt ifrån HSA enligt: 1 2 Sida 17 av 52
6.5.3 Skapa person Väljs funktionen för att skapa en person så möts administratören av följande formulär: 1 2 3 1. Administratören fyller i personnummer och erhåller personens kvalitetssäkrade uppgifter som är hämtas med hjälp av en webbservice. Integrationsmotorn hämtar fullständigt namn, tilltalsnamn, eventuella mellannamn och efternamn från RSV befolkningsregister. 2. Efter att administratören har validerat att det är rätt person så kan en bild läggas till på personen. 3. Administratören kan därefter registrera den information som är relaterad till personens anställning. Informationen till anställningen anges dels som fritext men även enligt fastställda värdemängder som eventuellt hämtas från Region Skånes alternativt direkt från IM-instansernas filsystem. 4. När administratören slutligen väljer att verkställa så kontrolleras uppgifterna i metakatalogen och ett unikt HSA-id genereras för personen. Personobjektet placeras under den enhet som pekades ut i huvudfönstret, se avsnitt 6.5.2. HSA-id följer därefter alltid personens samtliga förekomster i HSA-katalogen inom kommunen. Sida 18 av 52
Nedanstående bildserie följer ett exempel på ett nyupplägg av en person och dess tillhörande anställning. Sida 19 av 52
Söker administratören därefter på personen som lagts upp i samverkanslagret kan man se att personen har en anställning enligt nedanstående bild: 1 2 3 1. HSA-id som genererats för personen. 2. Samtliga anställningar för en person listas i anställningsfönstret för att förenkla för administratören. 3. Ur ett förvaltningshänseende av kvalitetssäkrade personuppgifter meddelas administratören om personens namn i HSA skiljer sig från befolkningsregistret och kan därmed välja att agera utifrån detta. Anledningen att inte ha detta flöde automatiserat är att utfärdade SITHS-certifikat blir ogiltiga. Sida 20 av 52
6.5.4 Hantera anställningar En person kan ha flera förekomster i HSA vilket representeras av en anställning tillsammans med personuppgifterna för personen. Informationen som är knuten till anställningen går att hantera på samma sätt som personuppgifterna från administrationsgränssnittet. Samtliga anställningar för en person listas i anställningsfönstret för att förenkla för administratören: 1 2 3 1. Administratören väljer att söka upp en person i samverkanslagret och klickar därefter på vyn Anställningar för att läsa ut den anställningsinformation som är kopplad till personen. 2. Personen i ovanstående bild har två anställningar registrerade och administratören kan därmed välja vilken anställningsinformation som ska visas. 3. Det går även att skapa nya anställningar från gränssnittet genom att peka ut var den nya anställningen ska ligga strukturmässigt. Dock går detta endast att göra under den kommun som administratören är behörig att administrera. Administratören kan givetvis även välja att ta bort en befintlig anställning. 4. Administratören kan uppdatera med ny information på en specifik anställning eller komplettera med uppgifter under den kommun som administratören är behörig att administrera. Sida 21 av 52
6.6 Flytta anställning Vill man som administratör flytta en anställning så genomförs detta via huvudfönstret: 1 1. Administratören väljer en anställning och pekar ut till vilken enhet som anställningen ska flyttas till. Sida 22 av 52
6.7 Ta bort anställning Likt vid flytt av en anställning så genomförs borttagning av en anställning via huvudfönstret: 1 1. Administratören väljer den anställning som ska tas bort och sedan alternativet Ta bort. Sida 23 av 52
6.8 Skapa enhet Att skapa en enhet utgår likt att skapa en person från huvudfönstret. Vyn för att skapa en enhet ser ut som följer: 1 4 2 3 1. När en administratör skapar enhet måste ett enhetsnamn anges. Även en kort beskrivning om enheten kan läggas till vid behov. 2. Här hämtas fastställda värdemängder in i gränssnittet och används för att beskriva verksamheten. Exempel på fastställda värdemängder som gäller är typ av verksamhet och vilken vårdform som bedrivs. Gränssnittet ger även möjlighet att välja om enheten ska visas för exempelvis andra vårdgivare eller SVPL. 3. Fält som används för adressuppgifter och telefonnummer samt tillhörande telefontider för enheten. 4. Här går det att ange geografiska koordinater för verksamhetens geografiska placering. 5. När administratören väljer att skapa enheten kontrolleras uppgifterna i metakatalogen varpå enheten tilldelas ett unikt HSA-id. Enheten skapas sen i sin tur upp under den organisatoriska förälder som pekades ut i huvudfönstret, se avsnitt 6.5.2. Sida 24 av 52
6.9 Hantera enhet Organisatoriska enheter hanteras genom att söka upp en enhet från huvudfönster, enligt avsnitt 6.5.2. Efter att administratören har valt att söka upp eller ändra en enhet presenteras uppgifterna enligt följande bild: 1 2 1. Enhetens HSA-id presenteras för enheten. 2. Uppgifter som registrerats i samband med den ursprungliga uppläggningen i samverkanslagret. Dessa uppgifter kan givetvis förändras av administratören. Sida 25 av 52
6.10 Ta bort enhet För att ta bort enheter så krävs det ett visst förarbete, nämligen att enheten är tom på underenheter och anställningar. När detta är genomfört kan enheten tas bort enligt: 1 1. Administratören klickar på enheten som ska tas bort och väljer ta bort. (Observera att enheten på bilden inte är tom och borttagning kommer därmed att misslyckas) Sida 26 av 52
7 Kodserver Metakataloge n Kodserver Integrationsplattform 7.1 Beskrivning Kodservern är inte en leverans inom samverkanslagret men kommer att användas för att integrera fastställda värdemängder i administrationsgränssnittet. Fastställda värdemängder som används i samband med administration av användare i administrationsgränssnittet baseras på etablerade källor då dessa finns, exempelvis kodverk från Socialstyrelsen eller Sjukvårdsrådgivningen, enligt: http://www.carelink.se/dokument/forvaltning_och_tjanster/hsa/riv_informationsspecifikation_hs A_Struktur_och_innehall_version_3.3_2009-03-26.pdf. Att kodservern finns etablerad innan införandet av samverkanslagret påbörjas är en förutsättning för ovan nämnd funktionalitet. Om så ej är fallet så finns möjligheten att hantera de fastställda värdemängderna via IM istället. 7.2 Fastställda värdemängder Vid manuell registrering av en ny anställning eller administration av en befintlig så ska fäljande uppgifter hämtas från kodservern med hjälp av en webbservice: Befattning Befattningskod Specialitet Specialitetskod Legitimerad yrkesgrupp 7.2.1 Befattning och befattningskod Denna värdemängd beskriver vad en person arbetar som och reglerar innehållet i attributet befattning (patitlename) och befattningskod (patitlecode). Källan är en AID-etikett från förteckningen Arbetsidentifikation kommuner och landsting (AID). Nedan följer ett antal exempel av befattning och befattningskoder: Befattningskod Befattning Beskrivning Exempel 204090 Läkare ej legitimerad, annan Ej legitimerad läkare under till exempel vikariat eller provtjänstgöring. (Specialitetskod ej tillämplig) Sida 27 av 52
204510 Psykolog Psykolog Psykolog 204511 PTP-psykolog Ej legitimerad psykolog under praktisk tjänstgöring (PTP). 204610 Psykoterapeut Arbetar med behandling av psykiska besvär och sjukdomar samt med utveckling av mänskliga relationer. PTP-psykolog Psykoterapeut 205010 Barnmorska, vårdavdelning 205011 Barnmorska, mottagning/rådgivning Barnmorska, vårdavdelning Barnmorska, mottagning/rådgivning Barnmorska, barnmorska förlossning, barnmorska vårdavdelning Barnmorska öppenvård, barnmorska rådgivning, barnmorska mödravårdscentral 206010 Anestesisjuksköterska Anestesisjuksköterska Anestesisjuksköterska, narkossjuksköterska 206011 Distriktssjuksköterska Distriktssjuksköterska Distriktssjuksköterska 206012 Psykiatrisjuksköterska Psykiatrisjuksköterska Psykiatrisjuksköterska 206013 Ambulanssjuksköterska Ambulanssjuksköterska Ambulanssjuksköterska 206014 Sjuksköterska, handikappoch äldreomsorg/geriatrik Sjuksköterska, handikapp- och äldreomsorg/geriatrik Geriatriksjuksköterska, sjuksköterska äldreomsorg 206015 Intensivvårdssjuksköterska Intensivvårdssjuksköterska Intensivvårdssjuksköterska 7.2.2 Specialitet och specialitetskod Denna värdemängd innehåller yrkesgrupper som har specialiteter utöver grundutbildningen, exempelvis legitimerad läkare, tandläkare och sjuksköterska. Värdemängden reglerar innehållet i attributet specialitet (specialityname) och specialistkod (specialitycode). Källan är Svensk författningssamling (SFS 1998:531, SFS 1998:1513, SFS 1993:100). Nedan följer ett antal exempel av specialiteter och specialistkoder: Specialitetskod Specialitet Läkare 99101 Akutsjukvård 20107 Allergologi 80100 Allmänmedicin Tandläkare 2001 Bettfysiologi 2002 Endodonti 2003 Odontologisk radiologi Sida 28 av 52
Sjuksköterskor 3004 Specialistsjuksköterska: Hälso- och sjukvård för barn och ungdomar 3007 Specialistsjuksköterska: Distriktssköterska 3008 Specialistsjuksköterska: Allmän hälso- och sjukvård med inriktning mot onkologisk vård 7.2.3 Legitimerad yrkesgrupp Denna värdemängd innehåller de legitimerade yrkesgrupperna och reglerar innehållet i attributet legitimerad yrkesgrupp (HSAtitle). Nedan följer ett antal exempel av legitimerade yrkesgrupper: Yrkeskod Yrkesgrupp AP Apotekare AT AU BA BM DT KP LG LK NA OP OT PS PT RC RS SG SF SJ TH TL Arbetsterapeut Audionom Barnmorska Biomedicinsk analytiker Dietist Kiropraktor Logoped Läkare Naprapat Optiker Ortopedingenjör Psykolog Psykoterapeut Receptarie Röntgensjuksköterska Sjukgymnast Sjukhusfysiker Sjuksköterska Tandhygienist Tandläkare Sida 29 av 52
För enheter gäller samma princip som för användare där följande uppgifter ska hämtas: Enhetstyp Verksamhet Verksamhetskod Vårdform Visas för 7.2.4 Enhetstyp Denna värdemängd innehåller olika typer av enheter. Attributet används för att visa om en enhet kan klassas som en specifik typ av enhet, exempelvis: Kod Enhetstyp 01 sjukhus 02 vårdcentral 7.2.5 Verksamhetskod och verksamhet Verksamhetskod används för att tala om vilken typ av vård en vårdgivare kan leverera. Värdemängden reglerar innehållet i attributen verksamhet (businessclassificationname) och verksamhetskod (businessclassificationcode). Ansvarig för ursprung och underhåll av detta kodverk är Sjukvårdsrådgivningen. Nedan följer ett antal exempel på verksamheter och verksamhetskoder: Verksamhetskod Verksamhet 2203 Folkhälsovård 2003 Fotvård 2204 Förebyggande hälsovård 1508 Företagshälsovård 1131 Gastroenterologi 1310 Gastroenterologisk kirurgi 1107 Gastromedicin 1704 Gastroradiologi 1108 Geriatrik 1109 Geriatrisk rehabilitering 1607 Geropsykiatrisk verksamhet/äldrepsykiatri 7.2.6 Vårdform Denna värdemängd används för att särskilja på olika typer av vårdformer och reglerar innehållet i attributet vårdform (caretype). Ansvarig för ursprung och underhåll av detta kodverk är Sjukvårdsrådgivningen. Kod Vårdform 01 öppenvård 02 slutenvård Sida 30 av 52
03 hemsjukvård 7.2.7 Visas för Denna värdemängd används för att tala om för vem ett objekt ska visas. Värdemängden reglerar innehållet i attributet visas för (hsadestinationindicator). Ansvarig för ursprung och underhåll av detta kodverk är Sjukvårdsrådgivningen. Kod Visas för 01 sjukvårdsrådgivning 02 andra vårdgivare 03 allmänhet Sida 31 av 52
8 Kvalitetssäkringstjänst (Navet) Metakataloge n WS Navet Integrationsplattform 8.1 Beskrivning Namnet är en del av identifieringen av en person och det är därför viktigt att personnamn i samverkanslagret överensstämmer med de identitetshandlingar som används i officiella sammanhang, exempelvis körkort och SITHS-godkända ID-kort med tillhörande certifikat. För att säkerställa personuppgiftskvalitet kopplas namngivningen i samverkanslagret till Skatteverkets Navet-tjänst. Därmed säkerställs en fungerande kvalitetssäkring av personuppgifter då dessa valideras mot aktuella uppgifter. Kommunikation sker oberoende beslutad källa via en webbservicetjänst som ansluts mot integrationsplattformen. Samverkanslagret använder därefter tjänsten vid nyupplägg av en person och hämtar ut namnuppgifter med hjälp av frågeställningar på personnummer. 8.2 Uppgifter Följande uppgifter ska hämtas från befolkningsregistret: Förnamn Initial Mellannamn Efternamn Fullständigt namn 8.2.1 Förnamn Förnamn är förnamn i befolkningsregistret. Bland dessa väljs personens tilltalsnamn, något som kan vara registrerat i befolkningsregistret med hjälp av en tilltalsnamnsmarkering. 8.2.2 Initial Den första bokstaven i något eller några av förnamnen som hämtas ifrån befolkningsregistret används som initial(er). Då objektsnamnet (CN) i HSA måste vara unikt så kan det inträffa ett scenario där de riktiga initialerna inte räcker till. Principen ser ut som följer för att skapa ett unikt CN i HSA: 1. Tilltalsnamn (Mellannamn) Efternamn 2. Tilltalsnamn Initial (Mellannamn) Efternamn Sida 32 av 52
3. Tilltalsnamn Intialer (Mellannamn) Efternamn 4. Tilltalsnamn Fiktiv(a) Initial(er) (Mellannamn) Efternamn 5. Tilltalsnamn Fiktiva Initialer+siffra (Mellannamn) Efternamn Initialerna kan vara upp till fyra tecken och hämtas, som principen beskriver, i första hand från befintliga förnamn i befolkningsregistret. Om detta inte ger ett unikt commonname (CN) i HSA så kan andra bokstäver väljas vilket hanteras ifrån administrationsgränssnittet IM. Vid en automatisk anslutning mot samverkanslagret så sker kontrollen mot attributet pidhsacn i metakatalogen som i sin tur genererar en kombination som är unik. Anser användaren därefter att inte kombinationen är acceptabel så kan kombinationen av initialer ändras manuellt via administrationsgränssnittet. 8.2.3 Mellannamn Mellannamn är ett tillägg till efternamn, exempelvis ett flicknamn (vid giftermål). Mellannamn förutsätter att efternamn också finns. Förhållandet mellan mellannamn och efternamn och hur dessa får användas regleras i namnlagen. 8.2.4 Efternamn Efternamn är efternamn i befolkningsregistret. 8.2.5 Fullständigt namn Fullständigt namn är samtliga namn i befolkningsregistret. 8.3 Efterkontroll Förslagsvis sker en kontroll av befintliga namn mot befolkningsregistret och ges en respittid på sex månader för ändring i befolkningsregistret. Skulle inte uppgiften vara förändrad i folkbokföringsregistret efter dessa sex månader så kommer uppgiften per automatik ändras i samverkanslagret efter kontakt med berörd administratör (via gränssnittet). Denna förändring kan förväntas ha bäring på SITHS-certifikatet för personen. Vikten av att fungerande SITHS-rutiner etableras i pilotinförandet är därför stor. 8.4 Ändring av namn Namn kan endast ändras genom ändring i RSV befolkningsregister eftersom det är den tjänst som kommer appliceras i samverkanslagret för kvalitetssäkra namnuppgifter. Sida 33 av 52
9 Metakatalog 9.1 Katalogdesign Katalogen ska vara dimensionerad och förberedd för de skånska kommunerna samt framtida utökningar av identiteter, enheter, tillägg av nya underkategorier och objektstyper enligt nedan. Dimensioneringen baseras på inkomna uppgifter från Kommunförbundet Skåne enligt: År 1 År 3 År 5 5000 personposter Varav ca 1000 personer förväntas vara användare av E-dos och ytterligare 4000 personer förväntas använda SVPL. Gemensamt för dessa användargrupper är att de behöver ett SITHS-kort och därmed även behöver finns i HSA-katalogen. 6000-8000 personposter En förväntad ökning på ytterligare 1000-3000 personer. Gemensamt för dessa är att de behöver SITHS-kort. 15000-20000 personposter Här förväntar sig Kommunförbundet Skåne att samtliga vård- och omsorgsanställda inom kommunerna finns upplagda i HSA-katalogen. Metakatalogen behöver alltså kunna hantera 5000 poster initialt men vara skalbar för minst 20000 personposter sett ur kommunernas perspektiv. Med den givna designen så är metakatalogen kapabel att hantera upp till 80000 objekt. Katalogen kommer initialt att innehålla följande objekttyper: Aktiva objekt Personobjekt Anställningsobjekt (kommunanställda inom vård och omsorg) Organisationsenheter Inaktiva objekt Personobjekt Anställningsobjekt (kommunanställda inom vård och omsorg) Organisationsenheter Med inaktiva objekt avses användare och organisationsenheter som inte längre är aktuella i samverkanslagret, men som inte tas bort för upprätthållning av historik och/eller för att minimera risken att poster i samverkanslagret återanvänds. Sida 34 av 52
9.1.1 Katalogstruktur SAMMETA- TREE Sam Meta System SamOrg WorkOrder Identities Admin Server DriverSet01 Roles Kommuner piduser Driver Kommun A Kommun... pidemployee Enhet A Enhet... Passiva poster Enhet A Enhet... Passiva poster Figur 2. Observera att metakatalogstrukturen kan förändras vid pilotinförandet Container Roles System Meta Identities SamOrg Kommuner WorkOrder Innehåll Innehåller administrationskonton för IM Administratörskonton för metakatalogen, servers, administration och regelverk. Underliggande innehåll styrs ifrån regelverk i metakatalogen. Alla personobjekt och anställningsobjekt. Personobjektet har containeregenskaper (utgör en del av den hierarkiska strukturen) och anställningsobjekt tillhörande en person lagras som lövobjekt under personobjektet. Innehåller alla organisatoriska enheter per organisationstyp Exempel: Kommuner, privata vårdgivare och andra intresseorganisationer Innehåller aktiva/inaktiva organisationsstrukturer per kommun Innehåller schemalagda aktiviteter 9.2 Objekt 9.2.1 Namnsättning klasser Namnsättning av alla nya klasser görs med prefixet pid, exempelvis piduser. Nya klasser ges ett engelskt namn, exempelvis pidemployee. 9.2.2 Namnsättning attribut I stor utsträckning används befintliga attribut i edirectory. I de fall det saknas ett lämpligt attribut som inte ingår som standard utökas schemat och kompletteras med namngivningar enligt Sjukvårdsrådgivningens riktlinjer. Ytterliggare en namngivning av attribut som används internt i metakatalogen namnsätts med prefixet pid och med engelska namn, exempelvis piddepartmentcode. Sida 35 av 52
9.3 Objektstyper På ett objekt av klassen piduser lagras information som är kopplat till den specifika personen. Under detta objekt kan det i sin tur finnas flera underliggande objekt som är förbundet till vilka underkategorier som personen har. Med underkategorier menas att personen har vissa unika egenskaper genom exempelvis kategorier som anställd, vårdgivare, extern leverantör osv. Person tillsammans med multipla underkategorier används därmed för att etablera strukturer och logik som tillåter en flexibel skalbarhet för samverkanslagret och dess uppbyggnad av en persons identitet. Att bryta sönder gamla strukturer som utgår från användandet av enskilda användarobjekt är en framgångsfaktor för att kontrollerat kunna hantera den kompletta identiteten i samverkanslagret. Detta med syftet att etablera: Förutsättningar för användarvänlig åtkomst En rationell hantering av framtida grupper En god hantering av flerförekomster för personer som arbetar i multipla organisationer En skalbarhet med ett perspektiv på framtiden (exempelvis federation) En väl fungerande grund för delegerad administration via IM Sida 36 av 52