Mötesanteckningar: Referensmöte 1 Persondatabas (PDB)

Transkript

1 Sidan 1 av 5 Mötesanteckningar: Referensmöte 1 (PDB) Närvarande Gunnar Rehbinder, IT- och teleservice Kate Larsson, projektledare infoproj. F Paul Waserbrot, F och teknisk F Anna Stedt, F och tekisk F Inga-Lill Schragen, CA Christer Bernérus, CITES/MD Per Andersson, Datanätgruppen Tore Lund, Biblioteket Hasse Freij, MDC Valter Nordh, K (KDS) Börje Sennung, IT-chef M (projektchef) Glenn Palstam, Sigma nbit AB, Sigma nbit AB Ej närvarande Kopia för kännedom till Thomas Bjerkhede, Sigma nbit AB Anne-Charlotte Karlsson, Sigma nbit AB Datum Mötesdatum Tid Plats Sal Delta, Maskinhuset plan 1 Bilaga Agenda: Bilaga A: Presentation refgruppsmte 1_ver1.ppt 1. -projektet, bakgrund 2. Nuläge 3. Lösningsförslag 4. Synpunkter 5. Projektinformation 6. Avslutning Nästa möte: klockan i sal Delta

2 Sidan 2 av projektet, bakgrund Glenn presenterade bakgrunden till projektet, projektdeltagare, tidsaspekter samt mål med projektet. 2. Nuläge Glenn visade den bild över nuläget som tagits fram under arbetsmötena, beskrev hur det fungerar i dag och förklarade vilka system som har tagits med i projektet och varför. 3. Lösningsförslag Glenn berättade om det lösningsförslag som tagits fram under arbetsmötena. Förklarade hur PDB skall fungera och hur strukturen skall se ut. Glenn visade även exceltabellen på de olika personkategorierna och personuppgifterna. 4. Synpunkter Frågor till deltagarna: - Vilka problem och hinder ser ni? - Vilka för- och nackdelar ser ni? - Vilka möjligheter ser ni? Kommentarer från deltagarna: o Kan man lägga in registrerad av som en uppgift i systemet, eller kommer det finnas med automatiskt? Glenn svarar att det kommer att loggas automatiskt vem som har registrerat informationen. o Emeritus finns även i Resax! o Passerkorten idag kan inte klara av att registrera personnummer. o Det är ett taget beslut att det inte skall registreras personnummer, men det går att göra det i systemet, systemet kan klara av det. o Alumni, kommer de att ligga i DCE och ha ett konto? Börje svarar att ja, så är det. o Det handlar ju om att man vill blockera adressen som inte längre används, den skall inte ges till någon annan. o Man får ju separera på vad som används och vad som är blockerad information. Börje säger att man kastar ingen information, men man flaggar den som död eller liknande. o Ett bäst före datum borde finnas även på DCE för alumni. o I TRAX så raderas information, kort tas bort, vilket är av volymskäl. o Det blir svårt att lagra ansvarsavtal i DCE o Hur fungerar det om man matchar in i flera av kategorierna? Börje svarar att i de flesta fall så har man en egenskap första gången man kommer hit, och då blir det den initiala informationen. o Det gäller ju att skapa verktyg för personerna som skall mata in informationen, så att han/hon klarar av att registrera i rätt kategori. o Är schemat tänkt att vara tvingande, så att en person av en viss kategori måste ta första kontakten via ett visst system, eller är det mer en statistisk beskrivning av verkligheten? Börje svarar att det nog mer är en statistisk beskrivning av verkligheten. Det gäller att det första systemet registrerar så mycket information så att det finns en chans för andra att göra något av det i något annat system.

3 Sidan 3 av 5 o Det måste finnas ett bra gränssnitt och ett bra verktyg för de administratörer som skall registrera denna information, så att det verkligen fungerar. Detta är ett viktigt perspektiv som man inte får glömma. Det här med bäst före datum är ju också jätteviktigt. o Börje svarar att bäst-före-datumet kommer att fungera, men exakt hur det blir beror ju på hur synkroniseringen sker. Men denna funktion kommer att finnas med, PDB kommer t.ex. tala om för TRAX att kortet har gått ut gör något! o Har ni tänkt bygga systemet så att information trycks ut, eller skall informationen hämtas? Börje tror att man måste ha både och, t.ex. bäst-före-datumet borde nog tryckas ut. Det är bra om PDB har någon pejl på vad de olika systemen är intresserade av, så att det inte går signaler till alla system alltid så fort det har hänt något. Man kanske också skall skilja på bulkuppdateringar och enstaka uppdateringar. o Angående de fingerade personnummerna, skulle en person kunna ha flera genererade personnummer? Börje svarar nej, vi skall använda LADOKs funktion för att generera personnumret, men har man väl fått ett så är det det personnumret som gäller. o Vad händer då om man efter ett tag får ett riktigt personnummer, kan det bli dubbelregistrering då? Börje svarar att nej, för det skall finnas historia på personnumren. o Men om namnet stavas fel då, kan det inte bli dubbelregistrering? Det kanske kan hända, men det kommer inte att ta mer än kanske högst en vecka innan det upptäcks och korrigeras. o Vilka skall kunna registrera? Det måste vara tillämpbart för sekreterare etc., det måste vara lätt att använda för de som skall använda det. o Kan man koppla på flera system i bilden? Börje svarar att ja det är meningen. Det intressanta är ju de system som ännu inte är gjorda. o Finns det möjlighet att lägga in två adresser i systemet? Börje svarar att ja det finns det, i LADOK finns det redan två adresser inlagda. Något man måste tänka på är att man definierar fälten mycket väl, så att de personer som registrerar vet exakt vad som skall registreras i ett visst fält. Det finns ju möjlighet att lägga in fler adressposter om man så vill. o Skall det vara möjligt att kunna se vad som finns lagrat på sig själv, och hämta ut det? Börje svarar ja, meningen är att man skall kunna se allt som har med sig själv att göra. o Kan man även se historien på vad som hänt? T.ex. vilken källa som matat in min information? Då blir det ju en integritetsfråga åt andra hållet. Det är ju viktigare att det blir ändrat om något är fel. o Man skall kunna få ut alla uppgifter om sig själv, såvida de inte är belagda med sekretess. o Det gäller att skilja på information om en person, och information om spårbarhet i informationsgången. Då får man ju införa någon slags kod, så att man i alla fall kan se vilken avdelning, tjänsteman eller system som ändrat något. Som systemägare vill man ju veta vad som är fel, så att man kan undvika att det blir fel igen. Glenn går igenom olika scenarios för olika personer som kommer i kontakt med Chalmers. Kommentarer från deltagarna: o Vem är det som har access att ändra i systemet, hur definierar man det? Börje svarar att det är olika per roll och olika per fält. Kanske man kan ändra sin adress själv, men namnet kan man inte ändra, du har ett officiellt namn. Det finns ju en gradering redan idag på vem som får ändra var. En sådan måste göras i PDB också givetvis. o Hur vet personalmannen/administratören på en sektion att ett visst personnummer tillhör just den sektionen? Börje svarar att det finns organisationstillhörighet inlagd i PDB, så där

4 Sidan 4 av 5 kan man ju se det. Glenn säger att vi måste följa de behörighetsregler som finns idag, om vi skall skapa egna så kan detta ta tid o Man skall ju komma ihåg att detta är en databas som skall byggas. Behörighetssystem måste ju ligga så att säga i den yttre cirkeln. o Det är viktigt att bestämma vilken information de här systemen skall släppa ifrån sig till PDB. o Om man nu kör som på bilden, så finns det ju fortfarande sju ställen där man kan registrera information. Det handlar ju om användarvänlighet, att kunna ändra adress på någon t.ex. i flera av systemen som egentligen inte har nytta av adress (vilket ökar användarvänligheten) ökar ju komplexiteten ganska mycket. Vi kommer ju att definiera vilka system som får uppdatera vilken information, vilket lägger nivån på komplexiteten. o Är det realistiskt att tänka sig att PDB pratar t.ex. med folkbokföringen? Börje svarar att det är möjligt, det kanske skulle kunna förenkla en hel del vad gäller namn etc. o Det är viktigt att definiera vilka som får lova att uppdatera de som gör jobbet! Det gäller att ta reda på vilka personer som gör jobbet på varje sektion idag det kan ju variera mellan olika sektioner. Man måste alltså inventera på varje sektion vem som gör vad idag, och så utgå från det, eller får man bestämma vilka personer som skall få lov att göra det på varje sektion. o Det är viktigt med ett gränssnitt där man kan se vad man skall registrera och vad som redan finns registrerat. Glenn förklarar att detta som görs idag är första steget till en sådan lösning. Vi måste utgå från de gamla system som redan finns, och hur de fungerar. o Den funktionalitet man vinner idag är att man kan mata in information i t.ex. LADOK, och så finns det tillgängligt för de andra systemen. o Det är viktigt att få in ett användargränssnitt för att skapa användartryck, om alla har sett det och gillar detta så är det mycket lättare att implementera. o Hinder som jag ser är integrationen med andra system, samt den politiska delen med ägarskapet av system etc. o Det får ju inte bara bli en fasad, som inte fungerar. Man måste ha på fötterna innan man går ut och säger att det är fantastiskt. o Säkerheten måste vara integrerad i det här, så att inte kreti och pleti kan gå in! o En nackdel är att en del människor kommer att känna sig berövade, det kan komma bli svårt att få personer att lämna ifrån sig information. Det finns risk att man trampar på ömma tår. o En fördel är att man slipper det där som faller mellan stolarna. Man kan få rätt uppgifter och få tag i dem! o Felkällorna minskar ganska kraftigt men konsekvenserna ökar om det väl blir fel. o Det kan vara otroligt arbetsbesparande om det fungerar det är en stor möjlighet! o På kemi har vi en fotodatabas som redan är i drift, det skulle ju kunna vara en möjlighet i framtiden att koppla in den till PDB. o En möjlighet som jag tror är att man i många system skulle kunna skippa och ha personinformation över huvud taget. Idag lagrar man det i många system i onödan. Mötesdeltagarna rekommenderar att projektet kör vidare på den linje som presenterades idag. o Glöm inte att förankra lösningen lokalt, och belys vad vi har för nytta av det! 5. Projektinformation Glenn visade länken till projekthemsidan där projektets framsteg kan följas:

5 Sidan 5 av 5 6. Avslutning Glenn avslutade mötet och uppmanade alla deltagare att komma med kommentarer till Glenn eller Anna via mail eller telefon. Mötet avslutas Vid protokollet Justeras Glenn Palstam