LÖSNINGSFÖRSLAG. Persondatabas

Sidan: 1 (26). LÖSNINGSFÖRSLAG Persondatabas

Sidan: 2 (26) INNEHÅLL 1. NULÄGE...4 2. LÖSNINGSFÖRSLAG...5 2.1 Grundläggande om lösningsförslaget...5 2.2 Nyregistrering av personuppgifter...6 2.3 Uppdatering av personuppgifter...7 2.4 Uppgifter från PDB till respektive system...8 2.5 Kommunikationen mellan Ladok och PDB...9 2.6 Kommunikationen mellan Slör/Pir och PDB...10 2.7 Kommunikationen mellan DCE och PDB...11 2.8 Kommunikationen mellan Trax och PDB...12 2.9 Kommunikationen mellan Vakans och PDB...13 2.10 Kommunikationen mellan Resax och PDB...14 2.11 Kommunikationen mellan PDB och nytt system...15 3. KOSTNADSKALKYL (SAMTLIGA BELOPP AVSER 1000-TAL KR)... 16 3.1 Kostnader totalt...16 3.2 Kostnader för anpassningar i befintliga system... Fel! Bokmärket är inte definierat. 3.3 Kostnader för Utveckling av PDB med tillhörande gränssnitt... Fel! Bokmärket är inte definierat. 3.4 Kostnader i samband med installation av PDB...Fel! Bokmärket är inte definierat. 3.5 Informationskostnader internt Chalmers... Fel! Bokmärket är inte definierat. 3.6 Kostnader för anslutning av nytt system...16 3.7 Förtjänster och möjligheter...17 4. PLAN FÖR IMLEMENTERING... 18 5. PERSONUPPGIFTER OCH INTEGRITET... 19 5.1 Personuppgiftslagen (PUL) och PDB...19 5.2 Ansvar för integriteten i PDB...19 6. DATABASENS LOGISKA STRUKTUR... 20 6.1 Personuppgifter...20 6.2 Roll-uppgifter...21 6.3 Detaljerade uppgiftsdefinitioner...21 7. DATABASENS TEKNISKA STRUKTUR... 22

Sidan: 3 (26) 7.1 Dynamiska fält...22 7.2 Interna uppgifter i PDB...22 7.3 Teknisk design...22 8. INFORMATIONSPLAN... 23 8.1 Efter beslut om införande av PDB:...23 8.2 Informations-aktivitet startad...23 8.3 Efter hand som systemen ansluts till PDB:...24 9. RISKER... 25 9.1 Identifierade risker i samband med införande av PDB...25 9.2 Åtgärder för att eliminera risker...26 BILAGOR Bilaga Dokumentnamn

Sidan: 4 (26) 1. Nuläge Nuläge NY-REG NY-REG KOMPL ÄNDRA TA BORT KOMPL ÄNDRA TA BORT Ladok Slör/Pir KOMPL ÄNDRA TA BORT NY-REG DCE NY-REG KOMPL ÄNDRA TA BORT Vakans Trax KOMPL ÄNDRA TA BORT NY-REG Resax KOMPL ÄNDRA TA BORT NY-REG Förutsättning: Personer - av olika kategorier - med olika ärenden - dyker upp vid olika tillfällen - hos olika instanser Resultat: Ingen gemensam information. Olika uppgiftsinnehåll i olika system. Mycket dubbel-registrering. Persondatabas, 2001-11-15 3 Det finns idag cirka 80-100 kända system som hanterar personinformation. De flesta systemen består av ett mindre personregister med adresser, tel-nr och mail-adresser för att kunna nå personer inom den egna organisationen.. Det finns också ca 10-20 större system som innehåller mer funktionalitet. Av dessa valdes 6 system ut för att utgöra första vågen av samordning av personinformation inom Chalmers: Ladok Slör/Pir DCE Resax Trax Vakans Huvudsystemet för hantering av information om studerande personer Utbetalning av lön och arvode till Chalmers-anställda och arvoderade Hanterar dator-konton, användar-id och epost-adresser Reseadministration-system Passerkort-system Telefoni-system som hanterar anknytningar och rums-nummer Kommunikationen mellan systemen finns i mycket liten omfattning. Personinformation matas in separat i respektive system, vilket innebär mycket dubbelregistrering samt risk för att informationen förvanskas pga fel-registrering. Dessutom hålls informationen inte uppdaterad i samtliga system. Det saknas bestämda rutiner för hantering av personinformation inom Chalmers. Sammantaget ger detta att informationskvaliteten på personinformation är låg.

Sidan: 5 (26) 2. Lösningsförslag 2.1 Grundläggande om lösningsförslaget Grunden för ett lösningsförslag är att de system som hanterar personinformation ska ha tillgång till aktuella och korrekta uppgifter samt att hanteringen ska vara effektiv och säker. I den föreslagna lösningen ska det också vara enklelt att ansluta nya system. Lösningsförslag NY-REG NY-REG KOMPL ÄNDRA TA BORT KOMPL ÄNDRA TA BORT KOMPL ÄNDRA TA BORT Ladok Slör/Pir PDB reg KOMPL ÄNDRA TA BORT KOMPL ÄNDRA TA BORT Vakans PDB Trax KOMPL ÄNDRA TA BORT DCE Resax KOMPL ÄNDRA TA BORT Förutsättning: Personer - av olika kategorier - med olika ärenden - dyker upp vid olika tillfällen - hos olika instanser Resultat: Gemensam information. Samma uppgiftsinnehåll i olika system. Ingen dubbel-registrering. Persondatabas, 2001-11-15 4 Den grundläggande principen i lösningsförslaget är att de 6 systemen lämnar bestämda personuppgifter till en central persondatabas (PDB) och får tillgång till vissa bestämda uppgifter från PDB. De tekniska förutsättningarna för att kommunicera med PDB varierar för de befintliga systemen. Det krävs därför att varje system får sin egen tekniska kommunikationslösning till PDB. Arbetssättet för hantering av personuppgifter blir tydligt och enkelt. Det finns två vägar för nyregistrering/uppdatering av personuppgifter: Ladok-behöriga nyregistrerar/uppdaterar PDB via Ladok (studenter) Sekt/Inst-sekreterare nyregistrerar/uppdaterar PDB via PDB-reg (alla andra personer) PDB-reg är ett web-formulär kopplat till PDB där man nyregistrerar/uppdaterar personuppgifter i PDB. För att identifiera en person i PDB används begreppet PERSON-ID som kan innehålla personnummer eller fingerat personnummer (genererat av Ladok-modul).

Sidan: 6 (26) 2.2 Nyregistrering av personuppgifter Lösningsförslag Nyregistrering Ladok-behörig Studerande Forskarstuderande Sektionssekreterare Institutionssekr Anställd Arvoderade Stipendiat Praktikant Gästforskare Emeritus Entrepenör Bulk uppdat Ladok PDB-reg Folkbokf-adress PDB Uppdrag Titel / Tjänstebenämning engagerad av Persondatabas, 2001-11-15 5 Bilden visar de två vägarna för nyregistrering mot PDB.

Sidan: 7 (26) 2.3 Uppdatering av personuppgifter Lösningsförslag Uppdatering Sektionssekreterare Institutionssekr DCE-behörig Vakans-behörig Ladok-behörig Studerande Forskarstuderande Anställd Arvoderade Stipendiat Praktikant Gästforskare Emeritus Entrepenör Samtliga roller vid behov Samtliga roller vid behov Ladok PDB-reg DCE Vakans Folkbokf-adress Uppdrag Titel / Tjänstebenämning engagerad av E-post adress Användar-id Tfn-anknytning PDB Persondatabas, 2001-11-15 6 Bilden visar de två vägarna för uppdatering mot PDB, via Ladok och via PDB-reg. Dessutom kan DCE och Vakans komplettera PDB med viss information (epost-adress, användar-id, rumsnummer, tfn-anknytning) i de fall informationen finns för personen.

Sidan: 8 (26) 2.4 Uppgifter från PDB till respektive system Lösningsförslag möjliga uppgifter från PDB PDB Folkbokf-adress Epost-adress Användar-id Engagerad av Roll Uppdrag Tfn-anknytning Engagerad Tfn-anknytning av from-tom avdatum from-tom avdatum gäller Engagerad from-tom avdatum Ladok Slör/Pir DCE Trax Vakans Resax system system x system x x Persondatabas, 2001-11-15 7 Bilden ger en överblick över vilken information PDB kan tillhandahålla för de uppgiftshämtande systemen. Bilden visar också PDB s logiska datastruktur: en person har ett antal uppgifter knutna till sin person (personuppgifter) varje person har en till flera roller och till varje roll finns ett antal uppgifter (roll-uppgifter) Varje uppgift som ett system hämtar ur PDB ska ha ett bestämt och välmotiverat syfte godkänt av PDBägaren samt förankrat med PULO.

Sidan: 9 (26) 2.5 Kommunikationen mellan Ladok och PDB Lösningsförslag Ladok PDB Ladok Ladok Folkbokf-adress PDB Folkbokf-adress Epost-adress Användar-id Engagerad av Ladok uppdateras i realtid mha databas-trigger via vy mot databasen Roll Uppdrag Tfn-anknytning Engagerad Tfn-anknytning av from-tom avdatum from-tom avdatum gäller Engagerad from-tom avdatum uppdateras i realtid mha databas-trigger Persondatabas, 2001-11-15 8 Kompletterande detaljer i kommunikationen mellan PDB och systemet kommer att klarläggas och bestämmas i realiseringsprojektet.

Sidan: 10 (26) 2.6 Kommunikationen mellan Slör/Pir och PDB Lösningsförslag PDBreg PDB Slör/Pir PDBreg Roll Uppdrag Engagerad av uppdateras i realtid mha web-formulär PDB Folkbokf-adress Epost-adress Användar-id Engagerad av Roll Uppdrag Tfn-anknytning Engagerad Tfn-anknytning av gäller Engagerad from-tom Tfn-anknytning av datum from-tom avdatum gäller Engagerad from-tom avdatum Slör/Pir uppgifter skickas via email till löne-adm Persondatabas, 2001-11-15 9 Kompletterande detaljer i kommunikationen mellan PDB och systemet kommer att klarläggas och bestämmas i realiseringsprojektet.

Sidan: 11 (26) 2.7 Kommunikationen mellan DCE och PDB Lösningsförslag PDB DCE PDB PDB Folkbokf-adress Epost-adress Användar-id Engagerad av Roll Uppdrag Tfn-anknytning Engagerad Tfn-anknytning av from-tom avdatum from-tom avdatum gäller Engagerad from-tom avdatum DCE E-post adress Användar-id uppdateras i realtid via vy mot databasen PDB uppgifter görs tillgängliga via en vy mot databasen Persondatabas, 2001-11-15 10 Kompletterande detaljer i kommunikationen mellan PDB och systemet kommer att klarläggas och bestämmas i realiseringsprojektet.

Sidan: 12 (26) 2.8 Kommunikationen mellan Trax och PDB Lösningsförslag PDB Trax PDB Folkbokf-adress Epost-adress Användar-id Engagerad av Roll Uppdrag Tfn-anknytning Engagerad Tfn-anknytning av from-tom avdatum from-tom av datum gäller Engagerad from-tom av datum Trax uppgifter görs tillgängliga via en vy mot databasen Persondatabas, 2001-11-15 11 Kompletterande detaljer i kommunikationen mellan PDB och systemet kommer att klarläggas och bestämmas i realiseringsprojektet.

Sidan: 13 (26) 2.9 Kommunikationen mellan Vakans och PDB Lösningsförslag PDB Vakans PDB PDB Folkbokf-adress Epost-adress Användar-id Engagerad av Roll Uppdrag Tfn-anknytning Engagerad Tfn-anknytning av gäller Engagerad from-tom Tfn-anknytning av datum from-tom avdatum gäller Engagerad from-tom avdatum Vakans Tfn-anknytning uppdateras i realtid via vy mot databasen PDB uppgifter görs tillgängliga via en vy mot databasen Persondatabas, 2001-11-15 12 Kompletterande detaljer i kommunikationen mellan PDB och systemet kommer att klarläggas och bestämmas i realiseringsprojektet.

Sidan: 14 (26) 2.10 Kommunikationen mellan Resax och PDB Lösningsförslag PDB Resax PDB Folkbokf-adress Epost-adress Användar-id Engagerad av Roll Uppdrag Tfn-anknytning Engagerad Tfn-anknytning av from-tom avdatum from-tom avdatum gäller Engagerad from-tom avdatum Resax uppgifter görs tillgängliga via en vy mot databasen Persondatabas, 2001-11-15 13 Kompletterande detaljer i kommunikationen mellan PDB och systemet kommer att klarläggas och bestämmas i realiseringsprojektet.

Sidan: 15 (26) 2.11 Kommunikationen mellan PDB och nytt system Lösningsförslag PDB system x PDB Folkbokf-adress Epost-adress Användar-id Engagerad av Roll Uppdrag Tfn-anknytning Engagerad Tfn-anknytning av from-tom avdatum from-tom avdatum gäller Engagerad from-tom avdatum system x uppgifter görs tillgängliga via en vy mot databasen Persondatabas, 2001-11-15 14 Kompletterande detaljer i kommunikationen mellan PDB och systemet kommer att klarläggas och bestämmas i det aktuella anslutningsprojektet.

Sidan: 16 (26) 3. Kostnadskalkyl (samtliga belopp avser 1000-tal kr) 3.1 Kostnader totalt Budget Budget Budget Budget Resurs Projekt-tid 17 arbetsveckor Person resurser timmar i projektet Extern kostnad Projektledning 544 490 Information, sammanställningar 408 367 Kvalitetssäkring 68 61 Intern kostnad Projektchef 102 66 Projektgruppsmedlemmar externa 650 585 Projektgruppsmedlemmar interna 450 293 Ej debiterbar kostnad Informationsplan, åhörare 240 Styrgruppsmedlemmar 30 20 Referensgruppsmedlemmar 90 59 Deltagare risksem 36 23 Summa interna resurser 2,378 1,503 382 318 Omkostnader Intern OH 60 lokalkostnad vid möten (12 st) 13 Reserv Summa intern overhead 0 0 73 0 Totalsumma resurser 2,378 1,503 455 318 66% 20% 14% Projekt-total 2,276 Varav debiterade kostnader 1,958

Sidan: 17 (26) 3.2 Kostnader för anslutning av nytt system Email variant (budgetversion) Anslutning av nytt system Utv Drift Support Utv Drift Support Anpassning till PDB 50 5 5 10 0 0 summa Anslutning nytt system 50 5 5 10 0 0 varav konsult-pengar 0 0 3.3 Förtjänster och möjligheter Förtjänster och möjligheter ökad datakvalitet PUL-krav (korrekt data) minskad väntetid, stress, irritation snabbare hantering eliminering av 100-tals listor/reg 200 tfn-kat på web insamling för tryck av tfn-kat 40 trycka tfn-kat vid valfri tidpunkt minskat behov av tryckt tfn-kat 200 minskat dubbelarbete 50 enklare, bättre adm rutiner lättare att städa 50 ökad säkerhet minskat manuellt arbete presentera personuppgifter till individ möjlighet för individen att själv uppdatera adress möjlighet till sökning/utskick till olika kategorier möjlighet till Integrering Trax/person/kurs/rumsnr vägvisningssystem 100 640

Sidan: 18 (26) 4. Plan för imlementering Implementeringen av PDB måste ske med mycket god kontroll över kvaliteten, på såväl den lagrade informationen som Bygg och testa databasen (PDB) samt användargränssnittet (PDBreg). Testa att låta ett system uppdatera PDB och verifiera att det fungerar med kvalitet. Upprepa punkten ovan för vart och ett av de uppdaterande systemen. Verifiera att alla uppgifter i PDB uppdateras korrekt, även när uppgifterna krockar från olika system. Testa att låta ett system hämta uppgifter från PDB. Upprepa punkten ovan för vart och ett av de hämtande systemen.

Sidan: 19 (26) 5. Personuppgifter och integritet 5.1 Personuppgiftslagen (PUL) och PDB Personuppgiftslagen (PUL) trädde i full kraft 2001-10-01. För de personuppgifter som hämtas till PDB gäller: Endast de personuppgifter som har ett motiverat syfte för något annat system ska tas in i PDB För de personuppgifter som lämnas ut från PDB gäller: Endast de personuppgifter som har ett motiverat och av PULO godkänt syfte i det mottagande systemet kan lämnas ut. För hanteringen av Personuppgifter i PDB gäller, som för personuppgifter generellt: Endast de personer som har till sin uppgift att hantera den specifika personens uppgifter ska ha tillgång till dessa. (konkret innebär detta att t ex en sektions-sekreterare endast får hantera personer inom sin sektion). För de PDB-anslutna system gäller samma princip, dvs de får endast tillgång till de uppgifter de behöver och endast för de personer de har rätt att hantera (Ladok studenter, Slör/Pir anställda). 5.2 Ansvar för integriteten i PDB Ägaransvaret för PDB är mycket viktigt ur PUL-perspektivet. De uppgifter som lämnas ut från PDB till anslutande system ska ha PDB-ägarens godkännande samt ha ett välmotiverat syfte granskat av Chalmers Personuppgifts-ombudsman (PULO). Även uppgifter som hämtas in till PDB ska ha ett välmotiverat syfte granskat av PULO. De behörighetsregler som ger tillgång till uppgifter i PDB ska vara väl dokumenterade och vara granskade av PULO.

Sidan: 20 (26) 6. Databasens logiska struktur Lösningsförslag, entitetsmodell (logisk DB-struktur) Personuppgifter: Folkbokf.adress E-post adress Användar-id engagerad av Rolluppgifter: Roll Uppdrag Titel / Tjänstebenämning Tfn-anknytning engagerad av Persondatabas, 2001-11-15 20 PDB innehåller två typer av information, uppgifter knutna till person och uppgifter knutna till personens olika roller. 6.1 Personuppgifter De uppgifter som är knutna till personen (oavsett personens roll): NAMN FOLKBOKF ADRESS BOSTADSADRESS HEM-TELEFON EPOST-ADRESS ANVÄNDAR-ID UPPGIFTSSKYDD ENGAGERAD AV GÄLLER FROM-TOM DATUM Personens fönamn (samtliga), tilltalsnamn och efternamn. Eventuellt kan ytterligare namnfält tillkomma ( chalmersnamn ) eftersom vissa personer önskar använda annat namn än det folkbokförda. Komplett adress hämtad från folkbokföringen. Aktuell bostadsadress om annan än folkbokf adress. Telefon-nummer till hemmet (ev även mobiltfn-nr). Personens epost-adress inom Chalmers (hämtat från DCE). Personens användar-id inom Chalmers (hämtat från DCE). Markering ifall personen vill att allmänna personuppgifter ska undantas från publicering inom/utom Chalmers. på den som initialt engagerade (tog hit) personen. From-tom-datum från när uppgifterna börjar resp slutar att gälla.

Sidan: 21 (26) 6.2 Roll-uppgifter De uppgifter som är knutna till personens olika roller inom Chalmers: ROLL UPPDRAG TITEL / TJÄNSTEBENÄMNING KOSTNADSSTÄLLE RUMS-NUMMER TELEFON-ANKNYTNING ENGAGERAD AV GÄLLER FROM-TOM DATUM Benämning på rollen (ett antal valida roller finns att välja mellan). Benämning på uppdraget personen har inom rollen. Personens titel/tjänstebenämning i rollen. Kostnadställe ansvarigt för kostnader inom rollen. Personens rums-nummer i rollen (hämtas från Vakans). Personens telefon-anknytning i rollen (hämtas från Vakans). på den som initialt engagerade personen i rollen. From-tom-datum från när uppgifterna börjar resp slutar att gälla för rollen. Alla personer innehar minst en roll (ex.vis Studerande, Anställd, etc). En person innehar inte sällan flera roller (ex.vis Anst + Stud eller Anst-1 50% + Anst-2 50%) om man är anställd och går en kurs på Chalmers eller om man är verksam inom två olika Chalmers-sektioner. En person kan vid sidan om sin normala roll ha andra roller som t ex projektledare etc. 6.3 Detaljerade uppgiftsdefinitioner Ytterligare arbete med att definiera detaljer gällande personuppgifterna (fälten) krävs i realiseringsprojektet.

Sidan: 22 (26) 7. Databasens tekniska struktur 7.1 Dynamiska fält Det ska vara enkelt att komplettera databasen med ytterligare personinformations-objekt (fält). Det innebär att databasens fysiska struktur behöver vara dynamisk. Varje enskilt fält kommer därför att lagras dynamiskt. Fysiskt fält i databasen: Fysiska fältets innehåll: FÄLTNAMN-1 EFTERNAMN FÄLTVÄRDE-1 Karlsson FÄLTNAMN-2 HEMTELEFON FÄLTVÄRDE-2 031-263748 Det gör det enkelt att dynamiskt lägga till nya uppgifter (fält) i databasen. En risk med detta är att performance påverkas negativt vid mycket stora datamängder. PDB kommer dock inte att rymma så stora datamängder att performance kommer att påverkas märkbart (ska dock testas). 7.2 Interna uppgifter i PDB För att möjliggöra spårbarhet och underlätta felsökning kommer PDB att innehålla vissa interna uppgifter, som t.ex: användar-id på den person som senast registrerat/uppdaterat en uppgift tidpunkt för senaste registrering/ärndring av en uppgift från vilket system en uppgift hämtats ev ytterligare uppgifter vid behov 7.3 Teknisk design Databasens och tabellernas detaljerade design kommer att bestämmas i realiseringsprojektet.

Sidan: 23 (26) 8. Informationsplan Nedan ses en förteckning över vilka personer/funktioner skall informeras, när det skall ske, vilken information de skall få samt hur informationen skall förmedlas. 8.1 Efter beslut om införande av PDB: Tur- ordning Personer/funktioner Typ av information Hur, på vilket sätt? 1 Studentkåren/personal- organisationen Hur PDB fungerar i stora drag och hur elever/anställda påverkas. Ett möte med vardera kåren/personal- organisationen 2 Alla berörda Bred information, övergripande om PDB-lösningen och motiven bakom 3 Chefer för användare Hur PDB fungerar i stora drag och påverkar verksamheten. Webben, Chalmerstidningen Tjänstevägen via email 4 Sekreterare, studerandeadministratörer (och deras chefer) Hur PDB fungerar, hur införandet påverkar mitt arbete (otekniskt perspektiv) Två möten per sektion 5 Övriga anställda Hur PDB fungerar i stora drag, vilka uppgifter som skall lagras samt motiven bakom Dekanus informerar 6 Elever Hur PDB fungerar i stora drag, vilka uppgifter som skall lagras samt motiven bakom Individuellt utskick (om PUL kräver det), kårtidningen, sektionstidningar, informationsmöte (kvällstid?) 8.2 Informations-aktivitet startad Efter riskseminariet beslutade vi i projektet att påbörja genomförandet med att informera de närmast berörda, dvs den administrativa personal (sekt/inst-sekreterare) som kommer att ansvara för registreringen av personer i persondatabasen, om PDB-projektet och vad det kan komma att innebära för deras arbetssituation. Informationen har hittills fått ett mycket positivt mottagande.

Sidan: 24 (26) 8.3 Efter hand som systemen ansluts till PDB: Turordning Personer/funktioner Typ av information Hur, på vilket sätt? 1 Löneadministratörer, TRAXadministratörer, telefoniadministratörer, datanissar Hur PDB fungerar i stora drag och rutinerna kring PDB. 2 Systemansvariga Tekniska detaljer och helheten Dialog Ett (eller flera?) möte/möten SSPA och andra företag knutna till Chalmers får ta del av den allmänna informationen via webben, Chalmerstidningen etc. Vid behov kan dessa komma att informeras ytterligare.

Sidan: 25 (26) 9. Risker 9.1 Identifierade risker i samband med införande av PDB Ett Risk-seminarie genomfördes och följande risker identifierades angående införandet av PDB. Riskerna har bedömts ur aspekterna sannolikhet (1 låg och 5 hög) samt konsekvens (1 ringa och 5 stor). Prioritet är produkten av sannolikhet och konsekvens. Låg < 8 Medel 8-16 Hög > 16 Nr Risk 1 Uppdatering mellan systemen och PDB sker för sällan vilket orsakar dubbelarbete/merarbete. Sannolikhet Konsekvens S*K Prioritet 2 4 8 Medel 2 Uppgifter saknas vid registreringen. 2 4 8 Medel 3 Uppgifter kommer in för sent (gamla uppgifter cirkulerar). 2 4 8 Medel 4 Oklart ägarskap och ansvar för uppgifter. 5 5 25 Hög 5 Olika uppgiftsformat och uppgiftsinnebörd i systemen kan orsaka problem att synkronisera uppgifterna. 6 Teknisk integrering och anpassning av befintliga system kan vara svårt och bli dyrt. 5 4 20 Hög 5 5 25 Hög 7 Avsaknad av tydlig ledning för PDB. 5 5 25 Hög 8 Svårt att få acceptans för ändrade arbetsrutiner. 5 5 25 Hög 9 Otillförlitliga behörighetsregler kan orsaka problem med PUL. 10 Personer reagerar negativt när de blir medvetna om att de är registrerade i PDB. 5 5 25 Hög 5 5 25 Hög 11 Tillgänglighetskraven på PDB kan inte tillgodoses. 2 5 10 Medel 12 Säkerhetskraven på PDB kan inte tillgodoses. 2 5 10 Medel

Sidan: 26 (26) 9.2 Åtgärder för att eliminera risker De risker som har prioritet hög eller medel anges nedan med en åtgärd. Nr Åtgärd/aktivitet för att eliminera risker 1 PDB ska få in uppdateringsuppgifter i realtid från lämnande system. Respektive system avgör själv när och hur ofta uppdatering från PDB ska tas in. 2 Befintliga uppgifter registreras. Saknade uppgifter kompletteras när de är tillgängliga. 3 Alla uppgifter i PDB är tidsmärkta, vilket förhindrar gamla uppgifter att gälla. I övrigt se punkt 1. 4 Ansvar och ägarskap för PDB och personuppgifter ska definieras i detalj och placeras i Chalmers organisation. 5 Varje personuppgift i PDB ska definieras vad gäller innebörd och format. 6 Teknisk integrering och anpassningar i befintliga system ska undersökas och specificeras vad gäller tekniska möjligheter samt kostnader för anpassning och drift. 7 Systemägar-rollen för PDB ska definieras och placeras (se punkt 4) 8 Information till och dialog med samtliga berörda om det förändrade arbetssättet vid flera tillfällen under projektets gång (säkerställs i informationsplan). 9 Entydiga behörighetsregler ska godkännas av PULO och fastställas av projektets styrgrupp samt blivande systemägare för PDB. 10 Informera samtliga personer som kommer att figurera i PDB om vilka uppgifter som lagras, säkerhet och sekretess, orsaken till PDBs existens, samt framtidsvisioner för PDB (säkerställs i informationsplan). 11 Tillgänglighetskraven på PDB ska definieras och utgöra underlag för lösningens utformning. 12 Säkerhetskraven på PDB ska definieras och utgöra underlag för lösningens utformning.