Sidan 1 av 5 Mötesanteckningar: Arbetsmöte 2 Persondatabas Närvarande Lill Andersson, administrationsansvarig (MD) Ingrid Riedl, administratör/sekreterare (F) Karin Weber, applikationsansvarig PA-systemet (CA) Gunilla Walther, kanslichef (ED) Stellan Englén, systemadministratör Ladok (CA) Catarina Olsson, studievägledare (M) Börje Sennung, IT-chef (M) (projektchef) Glenn Palstam, Sigma nbit AB, Sigma nbit AB Ej närvarande Henrietta Wicktorsson, avtalsansvarig, IT- och service-avd., (Telematik) Kopia för kännedom till Thomas Bjerkhede, Sigma nbit AB Anne-Charlotte Karlsson, Sigma nbit AB Datum Mötesdatum Tid 09.00 12.00 Plats Sal Beta, maskinhuset plan 1 Bilaga Bilaga A: pers-objekt_tabell.pdf Agenda: 1. Sammanfattning/resultat från föregående möte 2. Diskussion lösningsförslag för verksamheten 3. Reflektion och sammanfattning 1. Sammanfattning/resultat från föregående möte Glenn sammanfattade det som gjorts på förra mötet genom att visa ett par bilder, se nedan.
Sidan 2 av 5 IDAG Slör/Pir Ladok DCE Vakans Trax Resax 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. Kommentarer till bild 1: o Under resultat; detta gör det svårt att använda datan/informationen till något annat än det som det är avsett för. IDÉ Slör/Pir DCE Ladok Vakans Resax Trax PDB Gemensam Person-info Förutsättning: (samma) 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.
Sidan 3 av 5 Kommentarer till bild 2: o Är det tekniskt möjligt att göra detta? Glenn säger; JA! o Börje anser att det är mer en politisk fråga att få folk att lämna ifrån sig information. o Karin tror att det svåraste är att hålla databasen uppdaterad. o Det borde vara så att det kontinuerligt pumpas information från PDB till de andra systemen för att hålla uppdateringen igång. o Stellan undrar om det måste vara så, kan det inte vara tvärtom? Börje säger att då uppstår ju problemet med att det sker uppdatering på mer än ett ställe. o Idag är det svårt att automatiskt importera till systemen, det verkar ju lättare att stoppa in i den gemensamma delen. o Det finns ju en hel del andra system som säkert skulle vilja använda denna databas. Kommentarer till bild 3 tabellen med de olika personinformationsobjekten som fanns i kallelsen till möte 2. Denna tabell med gjorda ändringar kan studeras i Bilaga A. o Ingrid vill lägga till i Resax: hemadress, personnummer, kontering, namn o Tillägg i DCE: namn o Tillägg i SLÖR/PIR: anknytning, hemtelefon o Titel och uppdrag är inte samma sak, men titel och tjänstebenämning skulle kunna vara samma sak, t.ex. i vakans. o Man borde använda uttrycket folkbokföringsadress istället för hemadress, och istället för tillfällig adress borde man använda bostadsadress. o I RESAX används bostadsadress, likaså i VAKANS. o Det borde finnas en motsvarighet för anställningsperiod för eleverna. o Stellan anser att det borde finnas en huvudpost för alla nödvändiga uppgifter, och sedan ett antal underposter, beroende på vilken kategori man tillhör. Det som är i huvudposten borde föras in i PDB. Jag anser att det som är rött borde delas upp i två nivåer. o Börje påpekar att avbrott i studier är mycket intressant för studenter, och det måste finnas med. 2. Diskussion lösningsförslag för verksamheten Ett antal frågeställningar diskuterades, och nedan följer frågorna med kommentarer från deltagarna. - Vilka personkategorier skall registreras?(chalmers + GU) o Anställda, entreprenörer (konsult, hantverkare, restaurangpersonal, väktare, inhyrd personal), gästforskare, forskarstuderande, studerande grundutbildning, stipendiater, styrelseledamöter, alumni, emeritus, prao/praktikanter o Se till att få med någonstans vem som dragit hit personen dvs. någon form av kontaktperson. - Vilka uppgifter skall vara de grundläggande personuppgifterna? (Se de röda objekten i tabellen i Bilaga A) o För vissa kategorier så kan ju vissa fält få vara tomma, t.ex. hemadress på entreprenörer. o Det borde väl vara olika grunduppgifter för olika kategorier? o Det finns ju människor som ändrar personnummer, och det måste kunna hanteras. o Det måste finnas något unikt, för det finns ju flera personer som har samma födelsedata. o Man borde kunna använda funktionen som genererar ett personnummer i LADOK. Man kör alltså personnummer så långt det går, annars genererar man ett.
Sidan 4 av 5 o Tre nivåer på information; grunduppgifter för alla, grunduppgifter per kategori, samt systemspecifika uppgifter. o Grunduppgifter: Namn (O), e-postadress, folkbokföringsadress, bostadsadress, personnummer (O), vem drog hit personen, org.tillhörighet/hemvist, hemtelefon o (Grunduppgifter): Användarid är en grunduppgift som genereras någon annanstans och skickas till PDB. Lösenord (grunduppgift som hålls i något annat system), foto o Kategorispecifika: Uppdrag, titel, tjänstebenämning, rumsnummer, telefonanknytning, närvaroperiod, antagningar, giltighetstid trax-kort, avbrott på studier, examen o Systemspecifika: Rättningsprotokoll, prestationer/resultat, anst. omfattning tid, tjänstledighet, anställningsdatum, behörighetsnivå, vilka dörrar öppnas, examinator, handledare, skatteuppgifter, lön, kontering, kund, projektinnehavare, leverantör, bank/personnummer o Hur skall det gå till rent praktiskt? Någon form av webgränssnitt där man talar om vilken kategori personen är och då får reda på vilka uppgifter som måste matas in. Man kan givetvis importera information också från t.ex. VHS, skattemyndigheten etc. o Det är viktigt att definiera in- och utmatningsgränssnittet. o Ett tråkigt fenomen som skulle kunna uppstå är att det är en fördröjning från det att grunduppgifterna lagts in till dess att man kan lägga in systemspecifika. Hur skall detta hanteras? Det borde gå att lösa med någon typ av transaktion varje gång något matas in i PDB. Information måste hämtas/lämnas till PDB momentant för att det skall fungera smidigt. o Karin anser att det borde finnas en knapp så att man kan hämta hem uppgifter om en person när man vill, istället för att det sker automatiskt. Detta kan ju bestämmas i varje system specifikt hur man vill ha det. o Börje anser att det i PDB borde finnas någon mekanism som skickar ut en signal om att något har hänt. Så kan man välja om man vill hämta det eller ej. o Det måste kunna gå att skicka information båda vägarna till och från PDB. Catarina anser att det blir ett merjobb om hon skall registrera t.ex. en adressändring först i PDB och övriga registreringar (t.ex. en kurs) i ett annat system. - Vem ska registrera grundläggande uppgifter samt grunduppgifter per kategori? o Den instans där en person dyker upp först. - Vem ska registrera systemspecifika uppgifter per kategori? o Samma personer som idag. - Vem skall få lov att ändra i PDB? o Vissa uppgifter måste man vara försiktig med, t.ex. namn och personnummer. Det kan inte vem som helst ändra, det får bara administratörer i PDB ändra. Studenter och anställda får lov att ändra adress och telefon, men inget annat. - Vem skall få ta bort uppgifter i PDB? o Ingen. Man kan få städa i sitt egna system dock. Om en person är avliden är viktigt att hantera på ett korrekt sätt. Det måste signaleras till alla system på något sätt. Det måste läggas in som en uppgift på något sätt, kanske ett datum som talar om när personen senast var aktiv på något sätt. - Vem skall får titta på uppgifterna i PDB?
Sidan 5 av 5 o Individen skall alltid kunna se sina egna uppgifter, så mycket som är tekniskt möjligt, men inte andras. o Den som lägger in uppgifter, får också titta på dem, och ändra. Systemadministratörer för PDB alltså. - I vilken ordning måste uppgifterna komma in? o Grundläggande före Kategorispecifika. (Grundläggande) måste också in ganska fort, det måste ju kunna genereras direkt vid registrering. - Vad skall användas som unikt person-id? o Personnummer blir ett unikt Chalmers-ID, och har man inget personnummer så genereras ett. Detta måste sparas och gå att ändra, och det måste finnas en funktion som jämför det gamla och nya personnumret för att hålla koll på att det är samma person. 3. Reflektion och sammanfattning Diskussionen avslutades och Glenn informerade lite om vad som skall hända på nästa möte. Mötet avslutas Vid protokollet Justeras Glenn Palstam