Barnhälsodataprojektet Skåne Funktionsspecifikation Samverkanslager Postadress: Box 13, 264 21 Klippan. Besöksadress: Storgatan 33, Klippan. Telefon: 0435-71 99 00 Telefax: 0435-71 99 10 Postadress: Box 53, 221 00 Lund. Besöksadress: Baravägen 1, Lund. Telefon 046-71 99 00 Telefax: 046-71 99 30 Plusgiro: 34 68 83-2 Bankgiro: 312-8154 Organisationsnummer: 837600-9109 E-post: kansliet@kfsk.se Webb: www.kfsk.se
Innehållsförteckning 1 Innehållsförteckning 2 1 Dokumenthistorik 4 1.1 Versioner 4 1.2 Förkortningar/förtydliganden 4 2 Bakgrund 5 3 Framtid 6 4 Syfte 7 5 Ingångsvärden 8 6 Händelsefall 9 6.1 Manuell registrering av ny personpost 10 6.2 Beställning av SITHS-kort 12 6.3 Manuell registrering av flerförekomst 13 6.4 Personpost uppdateras med förändrad arbetsplats 16 6.5 Personpost uppdateras med nya uppgifter 18 6.6 Personuppgiftsförändringar via Befreg 20 6.7 Sekretessmarkering registreras på användaren 21 6.8 Användare avslutas huvudpost 22 6.9 Användare avslutas - flerförekomst 24 6.10 Städprocess körs för användare med avslutad huvudpost 26 6.11 Manuell registrering av organisationsuppgifter (förvaltning/enhet/avdelning) 27 6.12 Manuell förändring av organisationsuppgifter (förvaltning/enhet/avdelning) 28 6.13 Manuell borttagning av organisationsuppgifter (förvaltning/enhet/avdelning) 30 7 Kvalitetssäkringstjänster 32 7.1 Scenario 1 Kvalitetssäkringstjänst inom samverkanslagret 32 7.2 Scenario 2 kvalitetssäkringstjänst utanför samverkanslagret 33 8 Registersökning HSA 34 9 Automatiserad anslutning till samverkanslagret 34 10 Kravställning uppgifter 35 10.1 HSA 35 10.1.1 Personrelaterade uppgifter 35 10.1.2 Organisationsrelaterade uppgifter 37 10.2 SITHS 40 10.3 Samverkanskatalog 41 11 Unika ID 42 11.1 K-id 42 11.2 HSA-id 42 12 Skyddade personuppgifter 43 13 Integrationsprinciper 44 2
13.1 Dataflöde 44 13.2 Matchningsnyckel 44 13.3 Huvudpostmarkering 44 13.3.1 Beräkning av huvudpostmarkering 45 13.4 Urvalskriterier 45 13.5 Organisatorisk struktur 45 13.5.1 Placeringslogik 45 14 Webbgränssnitt för administration 46 3
1 Dokumenthistorik 1.1 Versioner Version Datum Beskrivning Upprättad av 0.1 Grunddokument skapat Thomas Andersson 0.3 2009-03-02 Komplettering av material Thomas Andersson 0.4 2009-03-11 Utveckling händelsefall Thomas Andersson 0.6 2009-03-17 Utveckling händelsefall Thomas Andersson 0.7 2009-03-20 Fastställt händelsefall, kompletteringar Thomas Andersson 0.8 2009-03-27 Komplettering av material Thomas Andersson 1.2 Förkortningar/förtydliganden Förkortning Beskrivning BHD BIF E-dos HSA KFSK Pulsen RS SITHS SKL SVPL SVR Barnhälsodata Bastjänster InformationsFörsörjning Apotekets e-recept tjänst Hälso- och Sjukvårdens Adressregister Kommunförbundet Skåne Pulsen Integration AB, 556353-7579 Region Skåne Säker IT i Hälso- och Sjukvården Sveriges Kommuner och Landsting Samordnad VårdPLanering Sjukvårdsrådgivningen 4
2 Bakgrund Regeringen och Sveriges Kommuner och Landsting (SKL) enades år 2004 om att etablera ett nära samarbete kring IT-utvecklingen inom vård- och omsorgssektorn. Hösten 2004 startade samarbetet och Socialdepartementet tillsatte en nationell ledningsgrupp för IT i vård och omsorg. I gruppen ingick representanter för Socialdepartementet, Sveriges Kommuner och Landsting, Socialstyrelsen, Läkemedelsverket, Apoteket AB och Carelink. Arbetet har utmynnat i en nationell IT-strategi för vård och omsorg som presenterades våren 2006. Den nationella ITstrategin är första etappen i ett långsiktigt nationellt arbete. Som en del av en samordnad, myndighetsövergripande satsning inom ramen för nationell IT-strategi för vård och omsorg, har SKL initierat ett antal projekt avseende Barnhälsodata. Projektet startade 2006 och har nu formulerat verksamhetsprocesser, identifierat verksamhetens behov av information och informationsutbyte, samt tagit fram en informationsmodell som är tänkt att fungera som en nationell standard för offentliga huvudmäns kravspecifikationer vid utformning av ett samlat IT-stöd för elektronisk journalföring inom och informationsöverföring mellan barn- respektive skolhälsovården. En första version av projektets RIV-specifikation är klar sedan tidigare och arbetet inom projektet har gått in i en ny fas med inriktning på fortsatt utveckling och tester av modeller för informationshantering. Det barnhälsodataprojektet har gemensamt med andra nationella satsningar som syftar till att informationen ska följa patienten är beroendet av en effektiv hantering av digitala identiteter och behörigheter. Det projekt jämte Barnhälsodata (BHD) och som har väldigt många likheter med just Barnhälsodataprojektet är Samordnad VårdPLanering (SVPL). Båda utgår från tillämpningar baserat på gemensamma identitets- och behörighetskataloger över huvudmannagränserna. I Skåne har Region Skåne och Skånes kommuner gemensamt beslutat att använda Hälso- och Sjukvådens Adressregister (HSAkatalogen) för verifiering (autenicering)och behörighetstilldelning (auktorisation) av person, roll och identitet. Det handlar främst om att kvalitén på de digitala identiteterna som skapas i HSA-katalogen håller en hög uppgiftskvalitet. Utan att med säkerhet veta om personen är den han/hon utgör sig för att vara så finns ingen stabil grund att basera och leverera tjänster på. Då kommer satsade resurser i olika digitala tjänster, såsom barnhälsodata och SVPL att få svårt att få genomslagskraft i verksamheten. Framtidens digitala tjänster, såsom SVPL och Barnhälsodata (BHD), ställer helt nya krav på den tekniska infrastrukturen. Många organisationer tittar idag på att förflytta sig emot en tjänsteorienterad arkitektur, SOA. Principen med SOA är att verksamheten och informationen hanteras med hjälp av återanvändbara tjänster som skapas utifrån verksamhetens processer. En av hörnstenarna i att skapa förutsättningar för möjligheten att förverkliga SOA är att den tekniska 5
infrastrukturen är etablerad. Utan den så riskerar de nya digitala tjänsterna att bli investeringar som aldrig kan växlas upp till full drift utan att drunkna i administration och manuella rutiner. En komponent i den tekniska infrastrukturen är som nämnts möjligheten att verifiera och behörighetstilldela. I ett scenario där ett landsting, 33 kommuner och ett antal privata företag ska hanteras så är just detta en extra utmaning. Här finns väldigt mycket att vinna med ett samarbete. I hittills genomfört arbete har det även varit påtagligt att de skånska kommunerna befinner sig i olika stadier avseende sättet att hantera digitala identiteter och identitetsrelaterad data. För många kommuner är dessutom avståndet till en effektiv identitetshantering väldigt stort av anledningar som avsaknad kompetens eller brist på ekonomiska medel. För den enskilda kommunen kan det vara en oöverkomlig utmaning att skapa förutsättningar för kommunala och regionala samverkanstjänster vilket lyfter behovet av samarbete. Slutsatsen från ID-projektet inom barnhälsodataprojektet förväntas bli att de skånska kommunerna delar ungefär samma nuläge avseende hur den digitala identiteten skapas och underhålls. Utifrån en sådan övergripande bild går det snabbt att utläsa behovet av att kunna: Kvalitetssäkra identitetsrelaterad data, exempelvis personuppgifter, mot en extern källa (Skatteverket) Överföra digitala identiteter manuellt, semiautomatiskt eller helt automatiskt till HSA-katalogen som har beslutats som gemensam tjänstekatalog för vård- och omsorg Generera unika HSA-id för den digitala identiteten innan den placeras i HSA Eftersom behovet och förutsättningarna är likartade så ter det sig naturligt att samverka kring utvecklingen av dessa tjänster. Förutom att det förväntas vara en snabbare väg fram så förutses ekonomiska vinster för kommunerna i form av fördelningsvinster. En ekonomisk modell som för många kommuner är en förutsättning för att kunna ta klivet in i regionala och kommunala samverkanstjänster. 3 Framtid Formuleringen av en arkitektur och en konceptuell tanke kring ett samverkanslager kräver ett antagande om en förväntad framtid. Att kunna anpassa tjänsteutbudet efter en ständigt föränderlig behovsbild är kritiskt för att nå målet om en billigare och/eller enklare lösning än det kommununika alternativet. Förutom vårdnära tjänster, som är högaktuella i projekt såsom SVPL och BHD, förväntas en framtid med ett än bredare samarbete mellan kommunerna. 6
Gemensamma satsningar i personaladministrativa eller utbildningsnära system förekommer på flera ställen i landet och det finns gemensamma incitament om att nå ut till medborgare med e-tjänster av olika karaktär. Det förefaller orimligt att anta att samverkanslagret ska möta den kompletta behovsbilden och utgöra den kompletta basen för alla kommungemensamma tjänster. Däremot är kravställningen rimlig att samverkanslagret ska erbjuda en skalbarhet för att i framtiden kunna hantera nya behov med ett ursprung ur kommunsamverkan. Ett exempel är en tjänstekatalog som kan användas, åtminstone ur en federationstanke, för att tilldela behörigheter för kommungemensamma tjänster/system. 4 Syfte Detta dokument syftar till att förädla den principiella modell som tidigare framarbetats över ett regionalt och kommunalt samverkanslager. Dokumentet, kallat funktionsspecifikation, gör anspråk på att specificera de funktionskrav som finns i det korta perspektivet samt anta om kommande funktionsbehov. Funktionsspecifikationen är att beakta som ett underlag för kommande teknisk projektering där ett konkret lösningsförslag ska framarbetas. För att slutligen nå en validerad lösning krävs ett införande i förslagsvis ett pilot-/proof Of Conceptprojekt. 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 externa projektintressenter. 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, nationell IT-strategi för vård och omsorg, SVPL samt HSA/SITHS/BIF. 7
5 Ingångsvärden Det finns tydliga nationella, regionala och kommunala ingångsvärden som inverkar på den tilltänkta hanteringen av ett samverkanslager. Nedan följer en enkel sammanställning över de ingångsvärden som anses inverka på valen i funktionsspecifikationen samt kommande tekniska projektering av en lösning. Nationella ingångsvärden Gällande policys och befintliga lösningar för HSA, SITHS och BIF ska tillämpas. Regionala ingångsvärden Samverkanslagrets fysiska placering förväntas vara Region Skånes s.k. DMZ-nät. Kommunikation med tjänster placerade i samverkanslagret skall ske enligt BIF-konceptet med SITHS-kort som autentiseringsmetod. Region Skånes IT-avdelning (RSIT) förväntas äga rollen som systemförvaltare för samverkanslagret. Kommande lösning antas byggas enligt Region Skånes befintliga produktval. Webbgränssnittet i samverkanslagret är att ses som ett administrationsgränssnitt och inte ett ramverk för att publicera e-tjänster. Kommunala ingångsvärden Lösningen ska bygga på tankesättet om att det ska vara billigare och/eller enklare för en kommun att införa tjänster via samverkanslagret än utveckla dem själva på kommununik basis. Samverkanslagret ska erbjuda en flexibilitet som motsvarar kommunernas olika nulägen. Omsatt i praktik så ska såväl manuella som automatiserade anslutningsmodeller rymmas inom samverkanslagrets konceptuella och arkitekturella utformning. Lösningen ska utgå från Internet som kommunikationsväg och skall inte kräva anslutning/kommunikation över Sjunet. Varje ansluten kommun ska vara ansvariga och ägare för den information som läggs upp i samverkanslagrets tjänstekatalog och/eller HSA 8
6 Händelsefall Händelsefall beskriver händelser som ska hanteras av samverkanslagret. De är beskrivna med en kort beskrivande text samt en schematisk bild där flödet vid händelsen kan följas. Följande händelsefall har identifierats i den initiala kravställningen mot samverkanslagret: Manuell registrering av personpost Beställning SITHS-kort Manuell registrering av flerförekomst Personpost uppdateras med ny arbetsplats Personpost uppdateras med nya uppgifter Personuppgiftsförändringar via Befreg Sekretessmarkering registreras på användaren Användare avslutas huvudpost Användare avslutas flerförekomst Städprocess körs för användare med avslutad huvudpost Manuell registrering av organisationsuppgifter(förvaltning/enhet/avdelning) Manuell förändring av organisationsuppgifter (förvaltning/enhet/avdelning) Manuell borttagning av organisationsuppgifter (förvaltning/enhet/avdelning) Händelsefall som är delvis kommununika alternativt är en replikering av befintliga tjänster presenteras under punkt 7-9. 9
6.1 Manuell registrering av ny personpost Manuell registrering av ny personpost innebär att administratör på kommunnivå lägger upp en ny användare som ska hanteras av samverkanslagret tex för registrering av SITHS kort samt registrering i HSA. Detta händelsefall beskriver när administratören ska lägga upp en ny personpost i Metakatalogen via webbgränssnittet. I inledningsskedet är valbara tjänster registrering via Metakatalogen till HSA samt Samverkanskatalogen samt möjlighet att registrera/beställa SITHS-kort. I en förlängning kommer det att finnas fler tjänster som erbjuds via samverkanslagret tex Barnhälsodata. Inloggning mot administrationsgränssnittet sker med hjälp av SITHS-kort. Åtkomst sker över Internet. Förutsättningen för att kunna registrera en anställd är att administratören är utsedd administratör från kommunens sida samt finns i HSA och har ett utfärdat SITHS-kort. Administratören fyller i personnummer och erhåller personens kvalitetssäkrade uppgifter som är hämtade från Region Skånes befolkningsregister(befreg). Den de fall där personen inte finns i det regionala registret så sker en automatisk slagning mot Skatteverkets Navet. Det genomförs också en kontroll av eventuell sekretessmarkering. Skulle personen ha en sekretessmarkering får administratören information om detta och följer SVR, sjukvårdsrådgivningen rekommendationer för användare med sekretessmarkering, vilket innebär att användaren ska ge ett skriftligt medgivande om att finnas med i HSA och i dess förlängning även samverkanskatalogen. Administratören kompletterar med kontaktuppgifter, organisationsenhetsinformation och befattning och yrkesgrupp. Organisationsenhetsinformationen är baserad på kommunernas registrering av sin kommunspecifika organisation vars gränssnitt presenteras i händelsefall under avsnitt 6.11. Befattning väljs ur en lista bestående av AID (Arbetsidentifikation)koder. AID är ett system för gruppering av arbetsuppgifter som används av medlemmar i SKL. De samlade uppgifterna sparas till Metakatalogen som en personpost. Metakatalogen skickar informationen vidare till Samverkanskatalogen och HSA. 10
Manuell registrering av personpost Webbgränsnitt Metakatalog Befreg Samverkans katalog HSA 1.1 Administratör loggar in 1.2 Väljer registrera ny person 1.3 Fyller i personnummer 2.1 Gå till avsnitt Manuell registrering av flerförekomstfinns i Metakatalogen 2.2 Finns personen 4.1 Skapa användare 4.2 Placera användaren i katalogen 5.1 Skapa användare 5.2 Placera användaren i katalogen 1.4 Meddelande om att personen har skyddad identitet 2.3 Skapar användaren Stopp 2.4 Hämta utvalda personuppgifter från Befreg 3.1 Personuppgifter hämtas 1.5 Personuppgifter presenteras 2.5 Finns sekretess markering 1.6 Val av tjänster 1.7 Validering av namn och komplettering av kontaktuppgifter 1.8 Fyller i förvaltning- och enhets tillhörighet 2.6 Uppdatera användaren 2.7 Generera HSA-id och KID 2.8 Uppgifter skickas till utvalda verksamhetssystem 1.9 Tilldelning av yrkesgrupp, befattning, start och slutdatum 1.10 Godkänn inmatningen 1.11 Bekräftelse på att användaren är registrerad 11
6.2 Beställning av SITHS-kort Beställning av SITHS-kort innebär att administratör på kommunnivå kan beställa SITHS-kort via Samverkanslagret. Det är möjligt att göra när administratören lägger upp användaren eller vid ett senare tillfälle. Samverkanslagret ser till att beställningen skickas till Region Skånes SITHS administratör. Detta händelsefall beskriver när administratören ska beställa SITHS-kort på en användare som redan finns i Samverkanslagret. Inloggning mot administrationsgränssnittet sker med hjälp av SITHS-kort. Åtkomst sker över Internet. Förutsättningen för att kunna beställa SITHS-kort är att personen är utsedd administratör från kommunens sida samt finns i HSA och har ett utfärdat SITHS-kort. Administratören fyller i personnummer och erhåller användarens uppgifter om den finns registrerad i Metakatalogen. Administratören fyller i specifik SITHS information. Informationen samlas upp av Metakatalogen och skickas i ett mail till Region Skånes SITHS administratör som i sin tur gör en beställning av kortet. 12
Beställning av SITHS-kort Webbgränsnitt Metakatalog SITHS administratör på Region Skåne Samverkanskatalog HSA 1.1 Administratör loggar in 2.1 Gå till avsnitt Manuell registrering av personpost 1.2 Väljer registrera SITHSkort 1.3 Fyller i personnummer 2.2 Finns personen 1.5 Personuppgifter presenteras 1.3 Fyller i specifik SITHS information 3.1 Utvalda uppgifter för registrering av SITHS skickas i ett mail till SITHS administratören 1.4 Godkänner inmatningen 3.2 Administratör registrerar SITHSanmälan för användaren 1.5 Bekräftelse på att beställning är skickad 6.3 Manuell registrering av flerförekomst Manuell registrering av flerförekomst innebär att administratör på kommunnivå registrerar ytterligare en flerförekomst på en person som redan finns i samverkanslagret. Kan tex vara en person som fördelar sin arbetstid på flera tjänster och som behöver finnas som flerförekomst i samverkanslagret. I samverkanslagret finns information om alla flerförekomster sparade på användaren och en av dessa sätts i systemet som en huvudpost (motsvarande huvudanställning) 13
Detta händelsefall beskriver när administratören ska lägga upp en flerförekomst på en användare som redan finns i Metakatalogen via webbgränssnittet. I inledningsskedet så är valbara tjänster registrering via Metakatalogen till HSA samt Samverkanskatalogen samt möjlighet att registrera/beställa SITHS-kort. I en förlängning kommer det att finnas fler tjänster som erbjuds via samverkanslagret. Inloggning mot administrationsgränssnittet sker med hjälp av SITHS-kort. Åtkomst sker över Internet. Förutsättningen för att kunna registrera en flerförekomst är att personen är utsedd administratör från kommunens sida samt finns i HSA och har ett utfärdat SITHS-kort. Administratören fyller i personnummer och erhåller personens kvalitetssäkrade uppgifter som finns lagrade i Metakatalogen. Administratören fyller i uppgifterna om den nya flerförekomsten såsom kontaktuppgifter, organisationsenhets information och befattning och yrkesgrupp. De samlade uppgifterna sparas till Metakatalogen som en flerförekomst på personen. Metakatalogen skickar informationen vidare till Samverkanskatalogen och HSA. 14
Manuell registrering flerförekomst Webbgränsnitt Metakatalog Befreg Samverkans katalog HSA 1.1 Administratör loggar in 1.2 Väljer registrera flerförekomst 1.3 Fyller i personnummer 1.4 Uppgifter presenteras 2.1 Gå till avsnitt Ny anställningsaknas i Metakatalogen 2.2 Finns personen 2.3 Visa uppgifter 4.1 Finns personen 4.2 Uppdatera användare 4.3 Ev flytta användaren i katalogen 5.1 Skapa användare 5.2 Placera användaren i katalogen 1.5 Val av tjänster 4.4 Skapa användare 1.6 Komplettering/ ändring av uppgifter 4.5 Placera användaren i katalogen 2.4 Uppdatera användare 1.7 Godkänn inmatningen 2.5 Sätt huvudpost 2.6 Uppgifter skickas till utvalda verksamhetssystem 1.8 Bekräftelse på att användaren är registrerad 15
6.4 Personpost uppdateras med förändrad arbetsplats Personpost uppdateras med ny arbetsplats innebär att administratör på kommunnivå registrerar att en användare som redan är registrerad i Samverkanslagret har förändrad arbetsplats. Detta händelsefall beskriver när administratören ska ändra arbetsplats på en användare som redan finns i Samverkanslagret via webbgränssnittet. Administratören loggar in med autentisering med sitt SITHS-kort. Administratören fyller i personnummer och erhåller användarens kvalitetssäkrade uppgifter presenterade i webbgränssnittet och ges möjlighet att ändra till nya arbetsplatsuppgifter. Metakatalogen ser sedan till att uppgifterna uppdateras och vidarebefordras till HSA och Samverkanskatalogen. Metakatalogen kontrollerar också om det finns ett utfärdat SITHS-kort och skickar då ett meddelande via webbgränssnittet till administratören och ger möjligheten att beställa ett nytt SITHS-kort baserat på den nya arbetsplatsen. Behöver användaren ett nytt kort skickas beställningen via systemet till Region Skånes SITHS administratör. 16
Personpost uppdateras med förändrad arbetsplats Webbgränsnitt Metakatalog Samverkanskatalogen HSA SITHS administratören på Region Skåne 1.1 Administratör loggar in 1.2 Väljer Uppdatera arbetsplats info 2.1 Gå till avsnitt Ny användare saknas i Metakatalogen 2.2 Finns personen 3.1 Personen flyttas till ny arbetsplats 4.1 Personen flyttas till ny arbetsplats 5.1 Information per e-mail om nytt SITHS kort pga byte av arbetsplats 1.3 Fyller i personnummer 1.4 Uppgifter presenteras 2.3 Visa uppgifter 1.5 Ändring av arbetsplats 2.4 Uppdatera Användarens arbetsplats 1.6 Godkänn inmatningen 2.5 Uppgifter skickas till utvalda verksamhetssystem 1.7 Meddelande om att användaren har SITHS kort 2.6 Finns utfärdat SITHS kort 1.8 Beställa nytt kort? Stopp 2.7 Skicka meddelande om att SITHS kort finns utfärdat 1.9 Skicka beställning till SITHS administratör 1.10 Bekräftelse på ändring av arbetsplats 17
6.5 Personpost uppdateras med nya uppgifter Personpost uppdateras med nya uppgifter innebär att administratör på kommunnivå registrerar att en användare som redan är registrerad i Samverkanslagret har nya uppgifter. Det kan tex vara ny eller förändrad befattning eller yrkesgrupp. Detta händelsefall beskriver när administratören ska uppdatera uppgifter på en användare som redan finns i Samverkanslagret via webbgränssnittet. Administratören loggar in med autentisering med sitt SITHS-kort. Administratören fyller i personnummer och erhåller användarens kvalitetssäkrade uppgifter via webbgränssnittet och ges möjlighet att uppdatera användarens uppgifter. Metakatalogen ser sedan till att uppgifterna uppdateras och vidarebefordras till HSA och Samverkanskatalogen. Metakatalogen kontrollerar också om det finns ett utfärdat SITHS kort och skickar då ett meddelande via webbgränssnittet till administratören som ges möjlighet att beställa ett nytt SITHS-kort baserat på de nya uppgifterna. Behöver användaren ett nytt kort skickas beställningen via systemet till Region Skånes SITHS administratör. 18
Personpost uppdateras med nya uppgifter Webbgränsnitt Metakatalog Samverkanskatalogen HSA SITHS administratören på Region Skåne 1.1 Administratör loggar in 1.2 Väljer uppdatera personpost uppgifter 2.1 Gå till avsnitt Manuell registrering av personpost 2.2 Finns personen 3.1 Användare uppdateras 4.1 Användare uppdateras 5.1 Information per e-mail om nytt SITHS kort pga byte av uppgifter 1.3 Fyller i personnummer 2.3 Visa uppgifter 1.4 Uppgifter presenteras 1.5 Ändring av uppgifter 2.4 Uppdatera personpost uppgifter 1.6 Godkänn inmatningen 2.5 Uppgifter skickas till utvalda verksamhetssystem 1.7 Meddelande om att användaren har SITHS kort 2.6 Finns utfärdat SITHS kort 1.8 Beställa nytt kort? Stopp 2.7 Skicka meddelande om att SITHS kort finns utfärdat 1.9 Skicka beställning till SITHS administratör 1.10 Bekräftelse på ändring av arbetsplats 19
6.6 Personuppgiftsförändringar via Befreg Personuppgiftsförändringar via Befreg innebär att förändringar på personuppgifter aviseras direkt till samverkanslagret. Detta innebär att förändringar sker per automatik till Metakatalogen som sedan ser till att Samverkanskatalogen och HSA uppdateras med korrekta uppgifter. Vid förändringar på namnuppgifter kontrollerar även Metakatalogen om det finns ett SITHS-kort kopplat till användaren. Om namnuppgifterna har ändrats på en användare som har ett SITHS-kort skickas ett meddelande till Region Skåne SITHS administratör. Personuppgiftsförändringar via Befreg Webbgränsnitt Metakatalog Befreg Samverkans katalog HSA Stopp 3.1 Namnuppgifter uppdateras 4.1 Uppdatera namnuppgifter 5.1 Uppdatera namnuppgifter 2.1 Finns personen 2.2 Uppdatera namnuppgifter 2.3 Namnuppgifter skickas till utvalda verksamhetssystem 2.4 Finns utfärdat SITHS kort 2.5 Skicka meddelande om att SITHS kort finns utfärdat 20
6.7 Sekretessmarkering registreras på användaren Sekretessmarkering registreras på användaren innebär att en användare kan via Skatteverket erhålla en sekretessmarkering. Sekretessmarkering aviseras via Befreg och Navet direkt till samverkanslagret. Detta innebär att sekretessmarkering sker per automatik till Metakatalogen som ser till att meddelande skickas till administratör med information om sekretessmarkering och möjlighet ges till användaren att ge sitt skriftliga medgivande till att förekomma i Samverkanslagret. Sekretessmarkering registreras på användare Webbgränsnitt Metakatalog Befreg HSA SITHS administratör på Region Skåne 3.1 Sekretess markering inkommer 2.1 Finns användaren i Metakatalogen 3.2 Läs över sekretessmarkering till Metakatalogen 2.2 Uppdatera användaren med sekretessmarkering 2.3 Meddelande om att personen har sekretessmarkering Stopp 21
6.8 Användare avslutas huvudpost Användare avslutas huvudpost innebär att administratör på kommunnivå avslutar en användare som inte längre ska finnas i samverkanslagret. Användaren är registrerad på en huvudpost, vilket innebär att användaren har endast en placering i Samverkanslagret. Detta händelsefall beskriver när administratören ska ta bort en användare som redan finns i Samverkanslagret via webbgränssnittet. Administratören loggar in med autentisering med sitt SITHS-kort. Administratören fyller i personnummer och erhåller användarens uppgifter via webbgränssnittet och ges möjlighet sätta ett slutdatum på placeringen i samverkanslagret. Metakatalogen uppdaterar uppgifterna och sätter ett bäst-före-datum på användaren. När slutdatum passerar dagens datum kommer användaren att sättas som inaktiv och när bäst-före-datum har passerat dagens datum initieras en städprocess som är beskrivet i annat händelsefall, se avsnitt 6.10. Metakatalogen kontrollerar också om det finns ett utfärdat SITHS kort och skickar då ett meddelande via webbgränssnittet till administratören att när slutdatum har passerat dagens datum kommer ett meddelande skickas till Region Skånes SITHS administratör med information om att placeringen för användaren har upphört enligt gällande policy för SITHS-kort. 22
Användare avslutas - huvudpost Webbgränsnitt Metakatalog Samverkanskatalog HSA SITHS administratör på Region Skåne 1.1 Administratör loggar in 1.2 Väljer avsluta användare 2.1 Finns användaren 3.1 Finns användaren? 4.1 Finns användaren? 1.3 Fyller i personnummer 2.2 Visa uppgifter 3.2 Inaktivera användaren 1.4 Uppgifter presenteras 3.3 Flytta användaren till passiva poster 4.2 Flytta användaren till passiva poster 1.5 Personpost avslutas 2.3 Hämta utvalda uppgifter 1.6 Godkänn inmatningen 2.4 Finns användaren 2.5 finns flerförekomst 2.6 Uppdatera användaruppgifter på huvudpost 2.7 Sätt bäst-föredatum 1.7 Meddelande om att personposten har SITHS kort och registrerat slutdatum innebär revokering av SITHS kort enligt gällande policy 1.8 Bekräftelse på slutdatum är registrerat 2.8 Sätt status inaktiv 2.9 Se avsluta användare - flerförekomst 2.10 Finns utfärdat SITHS kort 2.11 Skicka meddelande om att SITHS kort finns utfärdat 23 Stopp
6.9 Användare avslutas - flerförekomst Användare avslutas flerförekomst innebär att administratör på kommunnivå avslutar en användares förekomst som inte längre ska finnas i samverkanslagret. Med förekomst med exempelvis en person som har flera anställningar och därmed finns representerad på flera olika ställen. Att ta bort en förekomst innebär att personen kommer att finns kvar i samverkanslagret men med exempelvis en anställning mindre. Detta händelsefall beskriver när administratören ska ta bort en användare som redan finns i Samverkanslagret via webbgränssnittet. Administratören loggar in med autentisering med sitt SITHS-kort. Administratören fyller i personnummer och erhåller användarens uppgifter och flerförekomster via webbgränssnittet och ges möjlighet sätta ett slutdatum på en flerförekomst i samverkanslagret. Metakatalogen uppdaterar uppgifterna och sätter ett bäst-före-datum på flerförekomsten. När slutdatum passerar dagens datum kommer flerförekomsten att sättas som inaktiv och när bäst-före-datum har passerat dagens datum initieras en städprocess som är beskrivet i annat händelsefall, se avsnitt 6.10. Metakatalogen kontrollerar också om den borttagna flerförekomsten var en huvudpost, om så är fallet sätts en ny huvudpost via beräkning på någon av övriga flerförekomster. Metakatalogen kontrollerar också om det finns ett utfärdat SITHS kort och skickar då ett meddelande via webbgränssnittet till administratören att när slutdatum har passerat dagens datum kommer ett meddelande skickas till Region Skånes SITHS administratör med information om att placeringen för användaren har upphört enligt gällande policy för SITHS-kort. 24
Användare avslutas - flerförekomst Webbgränsnitt Metakatalog Samverkanskatalog HSA SITHS administratör på Region Skåne 1.1 Administratör loggar in 1.2 Väljer avsluta användare 2.1 Finns användaren 3.1 Finns användaren 4.1 Finns användaren 1.3 Fyller i personnummer 1.4 Uppgifter presenteras 2.2 Visa uppgifter 3.2 Uppdatera användare med uppgifter från ny huvudpost 3.3 Uppdatera katalogplacering 4.2 Radera aktuell flerförekomst 1.5 Personpost avslutas 2.3 Hämta utvalda uppgifter 1.6 Godkänn inmatningen 2.4 Finns användaren 2.5 finns flerförekomst? 2.6 Uppdatera och markera ny huvudpost 2.7 Uppdatera bäst-före-datum 2.8 Se avsluta användare - huvudpost 1.7 Bekräftelse på personpost är avslutad 25 Stopp
6.10 Städprocess körs för användare med avslutad huvudpost Städprocess körs för användare med avslutad huvudpost innebär att det initieras en städprocess i Metakatalogen där en jämförelse sker på om objektets bäst-föredatum har passerat dagens datum då sker en radering av objektet i Metakatalogen samt i Samverkanskatalogen och HSA. Städprocess körs för användare med avslutad huvudpost Webbgränsnitt Metakatalog Samverkanskatalog HSA SITHS administratör på Region Skåne 2.1 Städprocess körs 3.1 Finns användaren? 4.1 Finns användaren? 3.2 Radera användaren 4.2 Radera användaren 2.2 Har bäst-föredatum passerats 2.3 Radera användaren Stopp 26
6.11 Manuell registrering av organisationsuppgifter (förvaltning/enhet/avdelning) Manuell registrering av organisationsuppgifter innebär att administratör på kommunnivå registrerar kommunens organisation. Kommunens organisation i samverkanslagret är uppbyggd enligt modellen förvaltning/enhet/avdelning. Det är en förutsättning att kommunens organisation är registrerad innan användare kan kopplas till organisatoriska enheter. Detta händelsefall beskriver när administratören ska lägga en ny organisatorisk enhet i samverkanslagret via webbgränssnittet. Administratören loggar in med autentisering med sitt SITHS-kort. Administratören fyller i de uppgifter som behövs för att kunna skapa upp den organisatoriska enheten i samverkanslagret. Metakatalogen kontrollerar så att den organisatoriska enheten inte redan finns registrerad. Om den inte finns skapar Metakatalogen den och ger den ett HSA-id och K-ID. Uppgifterna skickas till Samverkanskatalogen och HSA. Administratören får en bekräftelse på att den organisatoriska enheten är sparad. 27
Manuell registrering av organisationsuppgifter (förvaltning/enhet/avdelning) Webbgränsnitt Metakatalog Befreg Samverkans katalog HSA 1.1 Administratör loggar in 1.2 Väljer registrera ny organisationsenhet 1.3 Ny förvaltning, enhet eller avdelning registreras 2.1 Gå till avsnitt Förändra befintlig organisationsstruktur 2.2 Finns förvaltning/ enheten/ avdelning 4.1 Skapa objekt 5.1 Skapa objekt 1.4 Godkänn inmatningen 2.3 Skapa objekt i metakatalogen 2.4 Generera HSA-id och KID 2.5 Uppgifter skickas till utvalda verksamhetssystem 1.5 Bekräftelse på att organisationsenhet är upplagd 6.12 Manuell förändring av organisationsuppgifter (förvaltning/enhet/avdelning) Manuell förändring av organisationsuppgifter innebär att administratör på kommunnivå uppdaterar kommunens organisation, kan tex vara flytt eller nya uppgifter. Kommunens organisation i samverkanslagret är uppbyggd enligt modellen förvaltning/enhet/avdelning. När det sker en flytt av en organisatorisk enhet kontrolleras det i Samverkanslagret om det finns användare knutna till den och ser då till att de användarna följer med i flytten. Detta händelsefall beskriver när administratören ska förändra/uppdatera en ny organisatorisk enhet i samverkanslagret via webbgränssnittet. Administratören 28
loggar in med autentisering med sitt SITHS-kort. Administratören väljer ut aktuell organisatorisk enhet och fyller sedan i de nya uppgifterna för den organisatoriska enheten i samverkanslagret. Metakatalogen kontrollerar så att den organisatoriska enheten finns registrerad. Om den finns uppdaterar Metakatalogen den vid behov ser till att kopplade användare också uppdateras. Uppgifterna skickas till Samverkanskatalogen och HSA där de uppdateras. Administratören får en bekräftelse på att den organisatoriska enheten är förändrad. Manuell förändring av organisationsuppgifter(förvaltning/enhet/avdelning) Webbgränsnitt Metakatalog Befreg Samverkans katalog HSA 1.1 Administratör loggar in 2.1 Gå till avsnitt Ny organisationsenhet 4.1 Uppdatera objekt 5.1 Uppdatera objekt 1.2 Väljer Uppdatera organisationsenhets information 1.3 Väljer förvaltning/enhet / avdelning som ska uppdateras 2.2 Finns förvaltning/ enheten/ avdelning 1.4 Godkänn inmatningen 2.3 Uppdatera objekt i metakatalogen 2.4 Uppdatera användarna som är knutna till organisationsenheten 1.5 Bekräftelse på att organisationsenhet är uppdaterad 2.5 Uppgifter skickas till utvalda verksamhetssystem 29
6.13 Manuell borttagning av organisationsuppgifter (förvaltning/enhet/avdelning) Manuell borttagning av organisationsuppgifter innebär att administratör på kommunnivå tar bort en organisatorisk enhet i kommunens organisation. Kommunens organisation i samverkanslagret är uppbyggd enligt modellen förvaltning/enhet/avdelning. När det sker en borttagning av en organisatorisk enhet kontrolleras det i Samverkanslagret om det finns användare knutna till den. Om det är så att det finns användare kopplade får administratören ett meddelande om att användare är kopplade till den organisatoriska enheten och den organisatoriska enheten kan ej tas bort. Detta händelsefall beskriver när administratören ska ta bort en ny organisatorisk enhet i samverkanslagret via webbgränssnittet. Administratören loggar in med autentisering med sitt SITHS-kort. Administratören väljer ut aktuell organisatorisk enhet och fyller i att den ska tas bort ur samverkanslagret. Metakatalogen kontrollerar så att den organisatoriska enheten finns registrerad samt om det finns användare kopplade. Om användare finns kopplade får administratören ett meddelande om att den organisatoriska enheten ej kan tas bort på grund av kopplade användare. Annars plockas den organisatoriska enheten bort från Metakatalogen, Samverkanskatalogen och HSA. 30
Manuell borttagning av organisationsuppgifter(förvaltning/enhet/avdelning) Webbgränsnitt Metakatalog Befreg Samverkans katalog HSA 1.1 Administratör loggar in 4.1 Radera objekt 5.1 Radera objekt 1.2 Väljer borttagning av organisationsenhet Stopp 1.3 Väljer förvaltning/enhet / avdelning som ska raderas 2.1 Finns förvaltning/enheten/ avdelning 1.4 Godkänn inmatningen 1.5 Meddelande att organisationsenheten har användare kopplad till sig och ej går att ta bort 2.2 Finns användare kopplade till organisationsenhet 2.3 Radera objekt 1.6 Bekräftelse på att organisationsenhet är borttagen 2.4 Uppgifter skickas till utvalda verksamhetssystem 31
7 Kvalitetssäkringstjänster Nyttjande av kvalitetssäkringstjänster för kommunerna baseras på två olika scenarios. Dessa behandlas något mer ingående nedan. 7.1 Scenario 1 Kvalitetssäkringstjänst inom samverkanslagret Inom samverkanslagret möjliggörs kvalitetssäkring av personuppgifter för kommunerna genom att använda Region Skånes interna befolkningsregister (Befreg). När en ny användare skapas startas en process som kontrollerar om personen finns i Befreg och att personen inte är avliden. Finns personen i Befreg skapas en relation mellan personposten i databasen och användaren i samverkanslagret med avsikten att både kunna få kvalitetssäkrade personuppgifter och att kunna upptäcka förändringar. Förändringar kan exempelvis vara att personen byter namn eller registreras med en sekretessmarkering. Nyttjande av Region Skånes befolkningsregister som en intern kvalitetssäkringstjänst för användare i samverkanslagret bör möjliggöras för att uppfylla nationella krav på kvalitetssäkrade personuppgifter, exempelvis HSA och kravställningar gällande SITHS. Region Skånes befolkningsregister kan därmed tillhandahålla användare inom samverkanslagret med kvalitetssäkrade personuppgifter. Det är viktigt att belysa att tjänsten kan användas inom samverkanslagret, men troligtvis inte i ett större perspektiv som en tjänst för att kvalitetssäkra personuppgifter som täcker in medborgare, elever och personal. Anledningarna till detta är flera, en faktor är att samverkanslagret måste populeras med alla personposter och det är viktigt att ta i beaktning att titta närmare på infrastruktur, skalbarhetskrav och ökade licenskostnader. En annan faktor är att Region Skånes befolkningsregister måste utvecklas med e- tjänster för att kunna leverera aviseringar på förändringar av personposter till en rimlig kostnad om inte e-tjänsterna är idag framtagna och kan tillhandahållas. Är tjänsterna inte framtagna kan det antas att resursinsatser för utvecklingen av e- tjänsterna kommer överstiga konkurrerande e-tjänster som redan har förverkligats och tillhandahålls av Skatteverket befolkningsregister, Navet. 32
7.2 Scenario 2 kvalitetssäkringstjänst utanför samverkanslagret Kommuner nyttjar idag i viss mån e-tjänster från Skatteverket genom sina interna verksamhetssystem, exempelvis personaladministrativa system, elevadministrativa system samt administrativa system inom vård och omsorg. E-tjänster som ofta förekommer är magnetmediumsinläsningar från definierat urvalsavtal med Skatteverket som levereras via fil eller cd-rom. Ett andra alternativ är e-transportfiler som kan beskrivas som urvalsavtal av personuppgifter med definierade ändringsaviseringar eller urval där personposter anges med hjälp av en frågefil och personnummer. Skatteverket har fler e-tjänster som är sammanknutna till Navet. Grundförutsättningar för att nyttja e-tjänster gällande Navet från Skatteverket är generellt sett densamma och förutsätter att ett verksamhetssystem kan importera aviseringsfiler. Kan inte ett verksamhetssystem nyttja/importera aviseringsfiler blir den enda möjligheten att upprätthålla kvalitetssäkrade personuppgifter genom manuell inmatning. Ett lösningsalternativ är en konsolideringsmotor (ESB, Enterprise Service Bus) som införs i syftet att prenumerera på aviseringsfiler från Navet och uppdatera en lokal personuppgiftsdatabas inom kommunen. Därmed kan kommunen frikoppla varje enskilt verksamhetssystem som nyttjar e-tjänster från Navet och använda sig av en och samma unika källa. Resultatet av att använda sig av en Navet-koppling via en konsolideringsmotor med aviseringar är att samtliga uppgifter för användarna inom en kommun hålls kontinuerligt uppdaterade med uppgifter som är korrekta och kvalitetssäkrade i de verksamhetssystem som kan hantera aviseringsfiler. Fördelarna är flera, registreringen av nya användare blir enklare då aktuella uppgifter finns att tillgå, uppdateringen av befintliga användare sker också kontinuerligt och kan levereras med mailnotifikationer när uppdatering sker. De regelbundna aviseringarna innebär att kommunen alltid kommer kunna upprätthålla uppdaterad och korrekt information på sina användare inom två kategorier. Personer som är kommuninvånare Personer som är icke-kommuninvånare För närvarande är detta lösningsalternativ under projektering och genomgår en pilotsättning tillsammans med kommuner i Västra Götalandsregionen. 33
8 Registersökning HSA Registersökning i HSA innebär att deltagande kommuner i samverkanslagret ska ha tillgång att kunna läsa i hela nationella HSA-katalogen. Gränssnittet för att kunna göra detta erbjuds via Region Skånes administratörsgränssnitt som tillhandahålls av SVR. Via sjukvårdsrådgivningen nyttjas ett webb-baserat gränssnitt för registersökning av innehåll i HSA. Gränssnittet länkas in i samverkanslagrets webbgränssnitt som en funktion. 9 Automatiserad anslutning till samverkanslagret De kommuner som idag står med en automatiserad identitetslösning i lokal regi kommer att erbjudas tillgång till samverkanslagret för att automatisera hantering av användare som ska ha tillgång till samverkanslagrets tjänster, i ett första skede gäller det tillgång till HSA och samverkanskatalogen. Informationsflödet mellan samverkanslagret och lokala Metakataloger kommer också att kunna utbytas, exempelvis SITHS-certifikat. Det är viktigt att påtala att utbytet kommer att ske under kontrollerade former i form av att obligatoriska uppgifter ska finnas tillgängliga innan tillgången kan tillåtas. 34
10 Kravställning uppgifter För att identifiera vilka uppgifter som behöver hanteras i samverkanslagret har dess olika kravställare identifierats. Aktuella kravställare är: HSA SITHS Samverkanskatalog 10.1 HSA Kravställningen kring uppgifter för inmatning i HSA utgår ifrån HSA Organisationsträd Objekt och attribut version 3.2.1 vilket är den senast utfärdade listan från Carelink/Sjukvårdsrådgivningen SVR AB. Efterföljande uppgifter ska kunna hanteras i samverkanslagret för inmatning av ny person, enhet eller funktion. Notera att vissa uppgifter är obligatoriska medan övriga är en option. Strävan bör dock alltid vara att inmatningen täcker så många uppgifter som möjligt för att möta målet om en sökbar katalog för de som arbetar med vård och omsorg. 10.1.1 Personrelaterade uppgifter Uppgift Kravställare Kvalitetssäkring Tilltalsnamn HSA obligatorisk uppgift Mot folkbokföringsregister Efternamn HSA obligatorisk uppgift Mot folkbokföringsregister Mellannamn HSA obligatorisk uppgift 1 Mot folkbokföringsregister Fullständigt namn HSA obligatorisk uppgift Mot folkbokföringsregister Objektnamn HSA obligatorisk uppgift Mot folkbokföringsregister Person-id HSA obligatorisk uppgift Kommunspecifik rutin HSA-id HSA obligatorisk uppgift Automatisk generering Befattning HSA önskad uppgift Kommunspecifik rutin Befattningskod HSA önskad uppgift Kommunspecifik rutin Beskrivning HSA önskad uppgift Kommunspecifik rutin Besöksadress HSA önskad uppgift Kommunspecifik rutin Bild HSA önskad uppgift Kommunspecifik rutin Certifikatsnummer HSA önskad uppgift Kommunspecifik rutin 1 Obligatorisk endast om mellannamn finns. 35
Uppgift Kravställare Kvalitetssäkring Chefskod HSA önskad uppgift Kommunspecifik rutin Domäninloggningsnamn HSA önskad uppgift Kommunspecifik rutin Enhetsnamn HSA önskad uppgift Kommunspecifik rutin E-postadress HSA önskad uppgift Kommunspecifik rutin Fakturaadress HSA önskad uppgift Kommunspecifik rutin Fax HSA önskad uppgift Kommunspecifik rutin Förskrivarkod HSA önskad uppgift Kommunspecifik rutin Geografisk plats HSA önskad uppgift Kommunspecifik rutin Giltigt fr o m HSA önskad uppgift Kommunspecifik rutin Giltigt t o m HSA önskad uppgift Kommunspecifik rutin Godsadress HSA önskad uppgift Kommunspecifik rutin HCC HSA önskad uppgift Kommunspecifik rutin HSA Enkel sökning HSA önskad uppgift Kommunspecifik rutin HSA Fonetisk sökning HSA önskad uppgift Kommunspecifik rutin Initial HSA önskad uppgift Kommunspecifik rutin Kortnummer HSA önskad uppgift Kommunspecifik rutin Legitimerad yrkesgrupp HSA önskad uppgift Kommunspecifik rutin Leveransadress HSA önskad uppgift Kommunspecifik rutin Mifareserienummer HSA önskad uppgift Kommunspecifik rutin Minicall HSA önskad uppgift Kommunspecifik rutin Mobiltelefon HSA önskad uppgift Kommunspecifik rutin Nyckelidentitet HSA önskad uppgift Kommunspecifik rutin Organisationsnummer HSA önskad uppgift Kommunspecifik rutin Pekare HSA önskad uppgift Kommunspecifik rutin Postadress HSA önskad uppgift Kommunspecifik rutin Postnummer HSA önskad uppgift Kommunspecifik rutin Slutdatum HSA önskad uppgift Kommunspecifik rutin Smeknamn HSA önskad uppgift Kommunspecifik rutin Specialitet HSA önskad uppgift Kommunspecifik rutin Specialitetskod HSA önskad uppgift Kommunspecifik rutin Språkkod HSA önskad uppgift Kommunspecifik rutin Startdatum HSA önskad uppgift Kommunspecifik rutin Telefonnummer HSA önskad uppgift Kommunspecifik rutin Telefontid HSA önskad uppgift Kommunspecifik rutin 36
Uppgift Kravställare Kvalitetssäkring Titel HSA önskad uppgift Kommunspecifik rutin Tjänstetelefon HSA önskad uppgift Kommunspecifik rutin Webbadress HSA önskad uppgift Kommunspecifik rutin Visas för HSA önskad uppgift Kommunspecifik rutin Växeltelefon HSA önskad uppgift Kommunspecifik rutin Mer utförlig information såsom uppgiftsbeskrivningar, format och kodverk/värdemängd går att utläsa i HSA Organisationsträd Objekt och attribut version 3.2.1 och tas därför ej upp i detta dokument. 10.1.2 Organisationsrelaterade uppgifter Med organisatoriska uppgifter avses uppgifter som används för organisationer och organisatoriska enheter enligt för HSA gällande definitioner. Uppgift Kravställare Kvalitetssäkring HSA-id HSA obligatorisk uppgift Automatisk generering E-postadress HSA obligatorisk uppgift Kommunspecifik rutin Organisationsnamn HSA obligatorisk uppgift Kommunspecifik rutin Organisationsnummer HSA obligatorisk uppgift Kommunspecifik rutin Postadress HSA obligatorisk uppgift Kommunspecifik rutin Telefonnummer HSA obligatorisk uppgift Kommunspecifik rutin Enhetsnamn HSA obligatorisk uppgift Kommunspecifik rutin Beskrivning HSA önskad uppgift Kommunspecifik rutin Besöksadress HSA önskad uppgift Kommunspecifik rutin Bild HSA önskad uppgift Kommunspecifik rutin Certifikatsnummer HSA önskad uppgift Kommunspecifik rutin Fakturaadress HSA önskad uppgift Kommunspecifik rutin Fax HSA önskad uppgift Kommunspecifik rutin Geografisk plats HSA önskad uppgift Kommunspecifik rutin Giltigt fr om HSA önskad uppgift Kommunspecifik rutin Giltigt t o m HSA önskad uppgift Kommunspecifik rutin Godsadress HSA önskad uppgift Kommunspecifik rutin HCC HSA önskad uppgift Kommunspecifik rutin 37
Uppgift Kravställare Kvalitetssäkring HSA Enkel sökning HSA önskad uppgift Kommunspecifik rutin HSA Fonetisk sökning HSA önskad uppgift Kommunspecifik rutin Leveransadress HSA önskad uppgift Kommunspecifik rutin Minicall HSA önskad uppgift Kommunspecifik rutin Mobiltelefon HSA önskad uppgift Kommunspecifik rutin Pekare HSA önskad uppgift Kommunspecifik rutin Postnummer HSA önskad uppgift Kommunspecifik rutin Slutdatum HSA önskad uppgift Kommunspecifik rutin Startdatum HSA önskad uppgift Kommunspecifik rutin Telefontid HSA önskad uppgift Kommunspecifik rutin Tjänstetelefon HSA önskad uppgift Kommunspecifik rutin Webbadress HSA önskad uppgift Kommunspecifik rutin Visas för HSA önskad uppgift Kommunspecifik rutin Växeltelefon HSA önskad uppgift Kommunspecifik rutin Alternativ namnvisning HSA önskad uppgift Kommunspecifik rutin Arbetsplatskod HSA önskad uppgift Kommunspecifik rutin Besöksregler HSA önskad uppgift Kommunspecifik rutin Besökstider för anhöriga HSA önskad uppgift Kommunspecifik rutin Besöksålder på patient HSA önskad uppgift Kommunspecifik rutin Enhetstyp HSA önskad uppgift Kommunspecifik rutin Församlingskod HSA önskad uppgift Kommunspecifik rutin Församlingsnamn HSA önskad uppgift Kommunspecifik rutin Geografiska koordinater HSA önskad uppgift Kommunspecifik rutin HSA Autentiseringsmetod HSA önskad uppgift Kommunspecifik rutin Kommundelskod HSA önskad uppgift Kommunspecifik rutin Kommundelsnamn HSA önskad uppgift Kommunspecifik rutin Kommunkod HSA önskad uppgift Kommunspecifik rutin Kommunnamn HSA önskad uppgift Kommunspecifik rutin Kortnamn HSA önskad uppgift Kommunspecifik rutin Land HSA önskad uppgift Kommunspecifik rutin Logotyp HSA önskad uppgift Kommunspecifik rutin Länskod HSA önskad uppgift Kommunspecifik rutin Länsnamn HSA önskad uppgift Kommunspecifik rutin Områdesansvar HSA önskad uppgift Kommunspecifik rutin 38
Uppgift Kravställare Kvalitetssäkring Remisskrav HSA önskad uppgift Kommunspecifik rutin Tid för drop-in besök utan tidsbokning HSA önskad uppgift Kommunspecifik rutin Verksamhet HSA önskad uppgift Kommunspecifik rutin Verksamhetskod HSA önskad uppgift Kommunspecifik rutin Vårdform HSA önskad uppgift Kommunspecifik rutin Vägbeskrivning HSA önskad uppgift Kommunspecifik rutin Ägarform HSA önskad uppgift Kommunspecifik rutin Öppettider HSA önskad uppgift Kommunspecifik rutin Mer utförlig information såsom uppgiftsbeskrivningar, format och kodverk/värdemängd går att utläsa i HSA Organisationsträd Objekt och attribut version 3.2.1 och tas därför ej upp i detta dokument. 39
10.2 SITHS Kravet på uppgifter för att kunna utfärda ett SITHS-certifikat överlappar i många hänseenden den uppgiftsflora som ovan presenterats avseende HSA. För tydlighetens skull presenteras dessa likväl separat nedan. Likt uppgiftskraven kring HSA så utgår uppställningen från HSA Organisationsträd Objekt och attribut version 3.2.1. Notera att vissa uppgifter är förutsättande för utfärdandet av certifikatet medan övriga är resultatet av ett utfärdat certifikat. Uppgift Kravställare Kvalitetssäkring Geografisk plats SITHS Kommunspecifik rutin HSA-id SITHS Automatisk generering Objektnamn SITHS Mot folkbokföringsregister E-postadress SITHS Kommunspecifik rutin Certifikatsnummer SITHS Rutin SITHS-hantering Giltigt fr o m SITHS Kommunspecifik rutin Giltigt t o m SITHS Kommunspecifik rutin Land SITHS Kommunspecifik rutin Organisationsnamn SITHS Kommunspecifik rutin Enhetsnamn SITHS Kommunspecifik rutin Certifikatspärrlista SITHS Rutin SITHS-hantering Delta-spärrlista SITHS Rutin SITHS-hantering Efternamn SITHS Mot folkbokföringsregister Tilltalsnamn SITHS Mot folkbokföringsregister Kortnummer SITHS Rutin SITHS-hantering Legitimerad yrkesgrupp SITHS Kommunspecifik rutin Mifareserienummer SITHS Rutin SITHS-hantering Titel SITHS Kommunspecifik rutin Utfärdarspärrlista SITHS Rutin SITHS-hantering Mer utförlig information såsom uppgiftsbeskrivningar, format och kodverk/värdemängd går att utläsa i HSA Organisationsträd Objekt och attribut version 3.2.1 och tas därför ej upp i detta dokument. 40
10.3 Samverkanskatalog Uppgift Kravställare Kvalitetssäkring Tilltalsnamn Obligatorisk uppgift Mot folkbokföringsregister Efternamn Obligatorisk uppgift Mot folkbokföringsregister Mellannamn Obligatorisk uppgift Mot folkbokföringsregister Fullständigt namn Obligatorisk uppgift Mot folkbokföringsregister Objektnamn Obligatorisk uppgift Mot folkbokföringsregister Person-id Obligatorisk uppgift Rutin i samverkanslagret 41
11 Unika ID Oavsett om en kommun väljer att administrera samverkanskatalogen manuellt eller via automatiserad hantering skapas unika löpnummer för varje användare, organisationsenhet eller funktionskonto. Principmodellen bygger på flera fördelar där ett unikt löpnummer skapas för att i framtida scenarion kunna återanvändas som namnstandard, matchningsnycklar, historikloggning och för HSA-id generering som är en obligatorisk uppgift för att tillgodogöra sig ett existensberättigande i HSA. 11.1 K-id Unikt löpnummer som genereras vid skapande av nya användare, organisationsenheter och framtida funktionskonto byggs upp enligt: Användare: KNNNNNNN (ex. K1234567) Organisationsenheter: KONNNNNNN (ex. KO1234567) Funktionskonto: KFNNNNNNN (ex. KF1234567) 11.2 HSA-id Unikt HSA-id genereras för nya användare, organisationsenheter och framtida funktionskonto och byggs upp baserat på rekommendation från Sjukvårdsrådgivningen. Varje objektstyp kan endast få ett HSA-id inom varje organisation. Personer som är aktiva i flera organisationer/kommuner, även benämns i dokumentet som flerförekomst, kommer att tilldelas ett HSA-id per organisation. HSA-id byggs upp enligt: Användare: landsbeteckning + organisationsnummer alt personnummer Organisationsenheter: landsbeteckning + organisationsnummer + KONNNNNNN Funktionskonto: landsbeteckning + organisationsnummer + KFNNNNNNN 42
12 Skyddade personuppgifter Den initiala etableringen av samverkanslagret, med tillhörande tjänster, avses genomföras enligt de rekommendationer som utfärdats av Sjukvårdsrådgivningen SVR AB 2008-05-16. Med hantering av skyddade personuppgifter avses en regelmässig hantering av personer med: Sekretssmarkering Kvarskrivning Fingerade personuppgifter I linje med rekommendationen kommer personer med skyddade personuppgifter hanteras med manuella rutiner och tillämpas för personer, med skyddade personuppgifter, som gett ett skriftligt medgivande till att uppgifterna används i HSA-katalogen för exempelvis utfärdande av SITHS-certifikat. Samverkanslagret skall konstrueras på ett sätt som tillåter förädlingar av kravställningar gällande hantering av personer med skyddade personuppgifter men skall avvakta fortsatta rekommendationer från Sjukvårdsrådgivningen SVR AB. 43
13 Integrationsprinciper 13.1 Dataflöde I samverkanslagret kommer uppgifter för användare och organisationsenheter hanteras genom ett dataflöde. Dataflödet visar vilka verksamhetssystem är givare eller prenumererare på uppgifter i samverkanslagret. Uppgift Metakatalog HSA Samverka nskatalog Befreg Personnummer G P P P Tilltalsnamn P P P G Mellannamn P P P G Efternamn P P P G Fullständigt namn G P P HSA-id G P Figur 1. Exempel på grundläggande dataflöde Fullständigt dataflöde för användare och organisationsenheter tas fram under den tekniska projekteringen. 13.2 Matchningsnyckel För att kunna knyta samma användare eller personer i ett flertal olika system måste någon form av nyckel användas, en sk. matchningsnyckel. På så sätt upptäcks förändringar av uppgifter över systemgränserna samt används när man skapar, förändrar, flyttar eller tar bort ett objekt. Det bästa alternativet för matchningsnyckel är beroende av vilket verksamhetssystem som ansluts. I samverkanslagret är följande unika matchningsnycklar identifierade: Personnummer Referensnummer Sökväg till objekt i ansluten katalogtjänst 13.3 Huvudpostmarkering Oavsett om en kommun väljer att administrera samverkanskatalogen manuellt eller via automatiserad hantering måste man avgöra om en användare är en huvudpost eller en flerförekomst. På så sätt skapas rätt förutsättningar för att 44
kunna erbjuda ett användarkonto samt trygga authentiseringsmetoder i samverkanskatalogen. I HSA nyttjas både användarens huvudpost och eventuella flerförekomster. Regler för hur en huvudpost avgörs byggs enligt följande: 13.3.1 Beräkning av huvudpostmarkering Första gången en person läggs upp i samverkanslagret skapas personen som en användare och tilldelas automatiskt en huvudpostmarkering. Läggs personen upp i en annan del av organisationen eller inom en annan kommun skapas en flerförekomst. Avslutas en huvudpost flyttas huvudpostmarkeringen till en flerförekomst. Har personen multipla flerförekomster avgörs huvudpostmarkering genom en jämförelse på start och eventuellt slutdatum. Går det fortfarande inte att avgöra huvudpost sätts en av flerförekomsterna automatiskt som huvudpost slumpmässigt. Denna typ av logik kommer att belysas och testas ytterligare under den tekniska projekteringsfasen. 13.4 Urvalskriterier Urval används för att särkskilja delmängder av användare ur en större gruppering. Urval används för att avgöra om en användare ska skapas i samverkanslagrets ingående verksamhetssystem. Ett exempel är att användare och organisationsenheter som skapas i samverkanskatalogen måste innehålla obligatoriska uppgifter innan de godkänns för att skapas i HSA. 13.5 Organisatorisk struktur Varje enskild kommun måste bygga och förvalta sin organisationsstruktur i samverkanslagret. Organisationsstrukturen kan byggas upp manuellt eller via ett automatiserat flöde. Utgångsläget i samverkanslagret byggs på en speglad struktur mellan HSA och samverkanskatalogen för att behålla dynamik mellan katalogtjänsterna. Organisatoriska förändringar såsom sammanslagningar, flyttar och borttagning av organisationsenheter är funktioner som kommer att hanteras i samverkanslagret. 13.5.1 Placeringslogik När en ny användare eller organisationsenhet skapas måste en definierad placeringslogik för varje kommuns organisationsstruktur tillämpas och hanteras i samverkanslagret. 45
14 Webbgränssnitt för administration Med webbgränssnitt avses det gemensamma administrationsgränssnittet för tjänsterna i samverkanslagret. Kommunerna når gränssnittet över Internet och SITHS-kortet är den autentisering som krävs för inloggning mot gränssnittet. Initialt kommer i första hand HSA- och SITHS-relaterade uppgifter att hanteras i gränssnittet då detta är de tjänster som etableras först i samverkanslagret. Ur ett kortsiktigt perspektiv kan man därför argumentera för att det gränssnitt som Sjukvårdsrådgivningen erbjuder för HSA rimligen borde tillämpas. I ett långsiktigt perspektiv förväntas dock samverkanslagret utökas med fler tjänster varför det är vitalt att nå en arkitektur med ett gränssnitt som kan utgöra den gemensamma administrationspunkten för samtliga tjänster. HSA Tjänst1 Tjänst2 Gränssnitt Gränssnitt Gränssnitt Figur 2. Risker med ett kortsiktigt perspektiv 46
HSA Tjänst1 Tjänst2 IM Gemensamt administrationsgränssnitt Figur 3. Fördelar med ett långsiktigt perspektiv Den funktionella projekteringen gör inte anspråk på att i detalj studera uppbyggnaden av webbgränssnittet förutom vilka administrativa moment som är aktuella i den inledande etableringen. Det förefaller dock som att det finns ett motiv att använda det nationella HSA-gränssnittet för vissa funktioner. I första hand är det addressregisterfunktionen, d v s möjligheten att bläddra i HSA, som inte har en administrativ funktion och därmed rimligen inte behöver utvecklas i administrationsgränssnittet för hela samverkanslagret. Identifieringen av den mest kostnadseffektiva kombinationen ligger som en del i den tekniska projekteringen. En kombination ska dock fortsatt baseras på en administrationspunkt för samverkanslagret. Som framgår i underlaget i övrigt så är ingångspunkten för samverkanslagret en återanvändning av Region Skånes befintliga lösningar och produktval. Därmed ses NordicEdge IM som den produkt som administrationsgränssnittet baseras på. Det är ett formuläruppbyggt gränssnitt vilket förefaller tilltalande med tanke på den förväntande administrationen av person- och organisationsuppgifter i samverkanslagrets olika delar. Viktigt att särskilt belysa är även att webbgränssnittet ej ska förväxlas med ett portalgränssnitt i vilket e-tjänster kan presenteras. Eventuella system som i framtiden placeras i eller mot samverkanslagret kan administreras ur ett behörighets- och åtkomsthänseende i administrationsgränssnittet. Att publicera det faktiska systemet för slutanvändare måste däremot hanteras av portallösningar. För vårdnära system/tjänster som är gemensamma för kommun och landsting så förefaller Region Skånes portalplattform vara den korrekta publiceringspunkten. Kommungemensamma system/tjänster publiceras däremot rimligen i kommunernas egna portaler alternativt i en portalplattform för kommungemensamma tjänster. 47