Omarbetade funktioner i NyA

Transkript

1 Omarbetade funktioner i NyA Registrera personuppgifter blir Hantera person Funktionen som hittills har hetat Registrera personuppgifter har bytt namn till Hantera person, och vissa förändringar har gjorts. Ett interims skapas samtidigt som en person skapas det finns inget separat användargränssnitt för att först skapa ett interims Personnummerbyte initieras och genomförs direkt här. Att radera en person helt och hållet från NyA görs också härifrån. Reglerna för att ta bort en person har också skärpts nu krävs det att ingen anmälan finns alls för att borttagning ska få tillåtas; inte heller får ett alias finnas på personen. En persons föredragna kommunikationssätt (epost eller vanlig post) anges här istället för som tidigare på anmälan. Det blir då ett enda val för personen. Logiken för förhållandet mellan kommunikationssätt och kontaktuppgifter har också förenklats: Har en person kommunikationssätt e-post är e-postadress obligatorisk och tvärtom. En person kan nu endast ha två (2) telefonnummer: hemtelefon och mobiltelefon, istället för som tidigare tre (3). Hela användargränssnittet ser dessutom lite annorlunda ut, där informationen presenteras i lite annan ordning. Personnummerbyte Efter införandet av UUID som nyckel i systemet, kommer ett byte endast innebära att byta ett värde i en tabell, vilket gör hanteringen mycket enkel för systemet. Nytt användargränssnitt Personnummerbyte alltså processen att byta på en person och inget annat kommer numer att initieras från fönstret Hantera person. Det kommer inte längre att hanteras av samma fönster som hanterar sammanslagningar, utan får en helt egen hantering. Det kommer inte längre krävas att handläggaren först skapar ett interims och sedan byter det, utan interimspersonnumret skapas av systemet i samband med bytet.

2 Byte från fiktivt Söker en handläggare fram ett fiktivt är fälten för födelsedatum och kön aktiva. a) Om ett byte ska göras till ett interims, och det födelsedatum och kön som redan är angivet stämmer, räcker det att kryssa i rutan Byt till interims och sedan spara, för att sedan systemet ska generera ett interims i bakgrunden b) Om ett byte ska göras till ett interims, och det födelsedatum och kön som redan är angivet INTE stämmer, räcker det att korrigera födelsedatumet och/eller könet och sedan spara. Då genereras ett nytt interims. Kryssrutan Byt till interims behöver inte kryssas i. c) Om ett byte ska göras till ett svenskt, räcker det att skriva in det nya svenska personnumret i fältet för. Om personnumret är ledigt och om formatet är korrekt, görs ett byte direkt i bakgrunden vid Spara. Byte från interims Hanteringen är snarlik den för fiktiva, med undantaget att man inte kan byta till ett nyskapat interims med kryssrutan Byt till interims. Tanken är att om födelsedatum och kön redan stämmer, behöver inget byte göras. Behöver man korrigera födelsedatum eller kön eller byta till ett svenskt är det samma metod som (b) och (c) ovan. Byte från svenskt För personer med svenska kan inte födelsedatum eller kön ändras. Inte heller kan ett byte göras till ett interims. Däremot kan byten göras till andra svenska, i de fall någon faktiskt bytt i verkligheten. Inga byten till fiktiva Det kommer liksom tidigare inte vara möjligt att göra ett byte till ett fiktivt (Fnummer). Fiktiva ska endast användas tillfälligt för att hantera nyinkomna användarn på sökandewebben för personer som saknar svenskt. Interims ges till dessa så fort deras personuppgifter i någon mening verifierats. Görs ett byte borde personens uppgifter vara verifierade, och därför kan byten endast ske till svenska och interims, inte fiktiva.

3 Sammanslagning Handläggaren som utför en sammanslagning, kommer nu att få upp en lista över de konflikter som systemets har identifierat. Detta eftersom det helt enkelt är för kostsamt ur ett utvecklings- och underhållsperspektiv att hitta klara, tydliga och otvetydiga verksamhetsregler att bygga ett automatiskt förfarande på. Det blir således bättre totalt sett om handläggaren får utreda varje konflikt för sig. Nya verksamhetsprocesser i NyA Går inte längre att skicka endast pappersutskick till alla i en omgång Eftersom kommunikationssättet från och med nu sitter på person istället för anmälan, kommer det inte gå att sätta ett visst kommunikationssätt på alla sökande i en given antagningsomgång och sedan beställa utskick i enlighet med detta. Man kan alltså inte sätta kommunikationssätt vanlig post till alla sökande, redan då man registrerar personens anmälan, och sedan låta batchen för att skicka antagningsbesked skicka ut pappers-ab till dessa. Bedömningen är att det inte är någon antagningsmyndighet i någon lokal antagningsomgång som längre har det här behovet. Men om så skulle finnas eller dyka upp senare, får man ändra dessa sökandes föredragna kommunikationssätt direkt i databasen just då man har behov av att göra utskicket och sedan ändra tillbaka. Etablera person i systemet Skapa interims som lärosäte Vill ett lärosäte skapa interims i NyA, för att sedan använda i Ladok 2, kommer dessa personer att behöva skapas helt och hållet i klienten. Det kommer att inte att gå att enbart skapa ett interims, som tidigare, utan hela personen måste skapas. En stor och tydlig förändring är att inga interims kommer att visas förrän det är sparat och tilldelat till en person. Personnummerbyte Processer för att säkerställa identitetsuppgifter Eftersom fiktiva inte är pålitliga vad gäller personuppgifternas korrekthet (andradatumformat i andra länder, det är slarvigt ifyllt, etc.), tillåts de inte att föras över till Ladok

4 vare sig i Ladok2 eller i Ladok3. Istället ska personnumret bytas till interims innan överföring kan ske. Idag görs detta om den sökande har blivit behörig till minst ett alternativ. Då Ladok förväntar sig att uppgifter på ett interims är korrekt vad gäller namn, födelsedatum, kön, m.m., måste verksamheten ha processer för att säkerställa detta. Då funktionerna i NyA nu har blivit enklare i detta avseende bör möjligheterna att säkerställa informationen vara större än tidigare. Det kommer dock att vara ganska lätt att göra ett byte, så därför krävs det att handläggaren själv söker igenom systemet och hittar eventuella dubbletter sedan tidigare. Användar på sökandewebben i samband med byte Tidigare har det varit ett problem vid byte (och sammanslagning också för den delen) att personer har fått ologiska typer. Svenska har i vissa fall kunnat få epostn och så vidare. Det har nu korrigerats så att det finns en grundläggande logik bakom detta. I typfallen behåller personen sitt, sin typ och sitt lösenord. Byter man däremot bort ett bekräftat eller obekräftat (ett svenskt byts till ett annat svenskt ), kommer användart att raderas. Detta för att säkerställa att rätt person verkligen är innehavare till t. Personen skapar då ett nytt användar på sökandewebben, baserat på sitt nya, och en ny aktiveringskod skickas hem i brevlådan. Anmälan och meriter och så vidare behålls naturligtvis. Är det kort om tid till sista svarsdag eller liknande, får verksamheten arbeta fram rutiner för att hantera det. Matris över konflikthantering vad gäller användar Från-PNR Till-PNR Kontotyp Detta händer Interims- Interims- E-post- Från-personens e- post- flyttas över. Interims- E-post- Från-personens e- post- flyttas över. Interims- E-post- Användart raderas. E-post- Användart raderas. Bekräftat Användart raderas. Obekräftat Användart raderas.

5 Sammanslagning Beroende på hur sammanslagningen ser ut, alltså vilka ingående typer det handlar om, finns det olika saker att tänka på. Här kommer en uppställning: Olika typer av sammanslagning Från- Till-PNR Typfall PNR Interims Interims Interims Interims Interims Person utan svenskt har skapat och fått sitt F-nummer bytt till T-nummer minst två gånger. Person utan svenskt, som redan har ett interims, har skapat ett nytt på sökandewebben, baserat på e- postadress. Person utan svenskt, som redan har ett interims, har skapat ett nytt på sökandewebben, baserat på sitt nya svenska. Person utan svenskt, som redan har ett fiktivt, har skapat ett nytt på sökandewebben, baserat på sitt nya svenska. Oklart om det finns ett scenario där man vill att ett interims ska ta över. Oklart om det finns ett scenario där man vill att ett fiktivt ska ta över. Oklart om det finns ett scenario där man vill att två svenska ska slås samman. Ett tänkbart är detta: Person med svenskt Kommentar/att tänka på Personen bör i möjligaste mån få hjälp med att kunna logga in på sitt befintliga och göra om anmälan där, så att det blir rätt och så att det är den sökande själv som gör det. Därefter bör det fiktiva personnumret tas bort ur systemet. Stöds inte av systemet. Har någon felaktigt angivit ett svenskt vid anmälan, får anmälan göras om, se kapitel Varför får inte sammanslagningar görs hur som helst Stöds inte av systemet. Har någon felaktigt angivit ett svenskt vid anmälan, får anmälan göras om, se kapitel Varför får inte sammanslagningar görs hur som helst Bör endast genomföras när det handlar om samma individ som förekommer i systemet under två olika svenska, eftersom information om meriter och avgifter följer med vid

6 får nytt av Skatteverket (personen har bytt kön eller får sitt korrigerat efter invandring) och skapar ett nytt på sökandewebben utan tanke på att personen redan hade ett sedan tidigare. sammanslagning. Sammanslagning av två olika individer bör i möjligaste mån undvikas, och istället bör den personen som felaktigt använt sig av en annan persons få hjälp med att manuellt göra om sin anmälan och sitt användar. Interims Fiktiva ska aldrig bli gällande efter en sammanslagning interimspersonnumret är det meningsfulla personnumret. Stöds inte av systemet. Varför får man inte göra sammanslagningar hur som helst? Det finns tre mycket starka argument till varför sammanslagning inte ska användas för att byta bort ett felaktigt angivet svenskt : Vid anmälan hämtas uppgifter automatiskt på det svenska personnumret: folkbokföringsuppgifter, information om avgiftsskyldighet, meriter från BEDA och Ladok samt högskoleprov, m.m. Vid sammanslagning förs dessa uppgifter automatiskt över till det som blir kvar. Om det inte är samma fysiska person är det väldigt dåligt om uppgifterna förs över. Vi kan oftast inte veta vem som har initierat en sammanslagning. Om man har felaktigt angivet någon annans vid anmälan, då har man lyckats anmäla någon annan. Det var kanske inte riktigt meningen, men det finns processer (aktiveringskod till folkbokföringsadressen, t.ex.) som ska fånga upp det. Då får man göra om anmälan så att man anmäler sig på rätt. Det är då egentligen den personen som man anmälde i första steget som ska uppmärksamma oss på att den inte vill ha sin anmälan, annars har vi plockat bort en anmälan för någon utan att den personen vet om det! De här problemen kräver ganska ordentliga fall-till-fall-utredningar. Har någon anmält sig på fel, är det sannolikt att det finns andra problem med uppgifterna. Det går nästan inte att förutsäga vad som ska bli rätt när allt är färdigt; det vore i alla händelser väldigt kostsamt att ha en automatisk hantering för att ta bort, bedöma och hantera de här randfenomenen. Det finns också ett extraargument som inte är lika starkt, men det går ut på att det helt enkelt kan betraktas som överservice att städa upp efter en sökande som uppenbarligen gjort alldeles fel. Då är det mycket bättre om en sökande får göra om, göra rätt och göra så att anmälan blir på det sättet som avsågs från början. Är det efter sista anmälningsdag får det, som vanligt, bli en fråga för respektive lärosäte att ta ställning till om anmälan ändå ska godtas som i tid.

7 Automatisk hantering Trots det som ovanstående sagts om nackdelarna med automatisk hantering, finns det några områden där en regel har kunnat hittas eller där det inte är lämpligt med en manuell hantering. Användar på sökandewebben Användar har i nuvarande implementation en rörig hantering, där det kan sluta med att en person får ett svenskt, men ett epost kopplat till sig, eller tvärtom: Ett interims får ett bekräftat användar. Det har vi försökt rätta till i den nya sammanslagningsfunktionen. Om vi hade låtit handläggaren välja vilket användar som ska bli gällande, på samma sätt som med andra konflikter, hade det kunna bli väldigt svårt för handläggaren. Vad är det egentligen man väljer? Lösenordet? Användarnamnet? Kontotypen? På grund av den här oklarheten, har vi valt att ta fram en regel för vad som händer med användart efter olika sammanslagningar. Det som flyttas över är lösenord och typ. Till-personens fungerar som användarnamn och/eller den e-postadress som fyllts i för personen. Matris över konflikthantering vad gäller användar Från-PNR Till-PNR Interims Interims Interims Interims Interimsperson- nummer Interims Interims Interims Interims Interims Interims Interims Fråntyp Till-typ E-post- E-post- JA E-post- Inget NEJ Inget E-post- NEJ E-post- E-post- JA E-post- Inget NEJ Inget E-post- NEJ Inget Inget Obekräftat Bekräftat Konflikt? Detta händer NEJ NEJ Till-personens e-post- blir gällande. Från-personens e-post- flyttas över. Till-personens e-post- blir fortsatt gällande. Till-personens e-post- blir gällande. Från-personens e-post- flyttas över. Till-personens e-post- blir fortsatt gällande. Till-personens obekräftade blir fortsatt gällande. Till-personens bekräftade blir fortsatt gällande. E-post- Inget NEJ Användart raderas. Interims- E-post- Obekräftat JA Till-personens obekräftade

8 Från-PNR Till-PNR Fråntyp Interims E-post- Inget Inget Till-typ Bekräftat Obekräftat Bekräftat Konflikt? Detta händer JA NEJ NEJ blir gällande. Till-personens bekräftade blir gällande. Till-personens obekräftade blir fortsatt gällande. Till-personens bekräftade blir fortsatt gällande. E-post- Inget NEJ Användart raderas. E-post- E-post- Obekräftat Bekräftat JA JA Till-personens obekräftade blir gällande. Till-personens bekräftade blir gällande. Ladok-meriter Dagens problem Ett av de största problemen i sammanslagningen gäller Ladok-meriter. I nuvarande implementation försöker NyA pussla ihop meriterna så gott det går och hämtar därefter om alla meriter från Ladok. Meriterna som sedan kommer från Ladok skriver dock över befintliga meriter i NyA. Detta eftersom sanningen vad gäller akademiska meriter ju ligger i Ladok. Problemet är bara att förmodligen har inte motsvarande sammanslagning eller byte gjorts på Ladok-sidan. Därför är inkommande meriter inaktuella, vilket leder till att de meriter som finns i NyA faktiskt inte är korrekta. Idag finns det heller inget sätt för Ladok att meddela NyA att sammanslagningen är gjord i alla relevanta Ladok-system. Det går således inte heller för NyA att vänta på att Ladok är klar med sin sammanslagning, innan meriterna läses över. Förenklad hantering mot Ladok2 Förändringen vi gör mot Ladok2-systemen är att systemet identifierar konflikter utifrån en förenklad definition, sparar till-personens meriter i de fall konflikt finns och sedan hämtar vi inte om meriterna från Ladok, utan en vanlig meritprenumeration läggs in. Det vill säga, så fort meriterna har ändrats i Ladok, kommer ändringen att meddelas NyA på samma sätt som görs för vanliga sökande som inte genomgått sammanslagning. När så bytet eller sammanslagningen görs i Ladok, har meriterna uppdaterats och meriterna läggs in i NyA.

9 Den förenklade konfliktdefinitionen är nu att per merittyp, får bägge etableringarna inte ha meriter från samma högskola. Då är det en konflikt som löses genom att från-personens meriter tas bort. Vi bedömer det som väldigt osannolikt att samma individ studerat vid samma högskola under två. Vanligare är att det har skett på två olika högskolor. Med den här metoden raderar man därför väldigt få meriter till en förhållandevis låg kostnad. Förbättrad hantering mot Ladok3 En av de största förändringarna i NyA av Ladok3-anpassningarna är att om en sökande har en anmälan i en pågående antagningsomgång så kommer de akademiska meriterna automatiskt att synkroniseras. Det blir alltså inga batchöverföringar kring detta, utan det kommer att föras över automatiskt, med så kallade feeds-händelser. Detta innebär alltså Ladok-meriterna automatiskt kommer att föras över till NyA, så fort sammanslagningen är klar. Då finns det heller ingen anledning att låta NyA försöka passa ihop de meriter som finns. Gör man en sammanslagning så kastar NyA de akademiska meriter som finns på respektive, alltså alla meriter. Därefter hämtar NyA in meriter från Ladok3 som sedan läggs in i NyA igen. Skillnaden mot hanteringen mot Ladok2 blir då att det sker mer eller mindre omedelbart. För att undvika att meriter läggs in innan det att sammanslagningen är gjort i Ladok, så kan vi här bygga in att NyA väntar på Ladok och att Ladok signalerar att de är klara. Detta går alltså inte att få till inom Ladok2 men är tänkbart med Ladok3. Områden som kräver särskilt övervägande Vissa områden behöver särskilda överväganden från den handläggare som utför sammanslagningen för att det ska bli rätt. Anmälan I nuvarande implementation av sammanslagning, sparas endast den anmälan med sökalternativ som sist är tillagt. Den andra anmälan raderas helt och hållet. Detta oavsett om det är före eller efter urval, om antagningsomgången är avslutad eller ej, eller om den sökande har blivit antagen till något. Det sker också helt utan spår i klienten. Att hantera ett överklagande eller liknande i den situationen blir mycket komplicerat. I det nya förfarandet blir handläggaren uppmärksammad på att det finns en konflikt och får möjlighet att lösa problemet. Handläggaren får då bedöma vilken anmälan som ska bli gällande med vilka sökalternativ. Handläggaren kan flytta sökalternativ från ena anmälan till den andra eller genom att hela anmälan raderas. När en handläggare manuellt raderar en anmälan måste en tjänsteanteckning skrivas, så är det även idag. Det ger möjlighet för spårbarhet direkt i klienten. Handläggaren kan då beskriva vad som är gjort och varför. Den sökande bör då också informeras.

10 Anmälan efter urval När en anmälan har passerat urval, och sökalternativen överförts till Ladok, blir ovanstående hantering omöjlig. Då är det inte längre möjligt att plocka bort enskilda sökalternativ eller hela anmälan. Då måste istället tidigare förfarande där sammanslagningen med tvång raderar anmälningar användas. Skillnaden blir dock att handläggaren, genom kryssmarkeringar, kan välja vilken anmälan som ska sparas. Rimligen bör handläggaren välja den där den sökande är antagen på flest sökalternativ, men det kan också finnas andra överväganden som måste göras. En tjänsteanteckning som beskriver vilken anmälan med vilka sökalternativ och deras radresultat är också lämplig att skriva i dessa fall. Det är också möjligt att printa den anmälan som ska raderas och skicka till skanningsbyrån, så att den blir tydligt arkiverad. Här får verksamheten hitta en bra lösning som bäst tar tillvara spårbarhetsbehoven. Ärendehistoriken efter sammanslagning Under vissa förutsättningar kommer ärendehistoriken att bli missvisande efter en sammanslagning. Det sker när personnumret som ska tas bort har gjort den anmälan som ska bli gällande. Detta beror på hur databasloggarna skrivs och ser ut, och det har inte gått att hitta en tillfredsställande lösning under projektet. Logg-tabellerna för sökalternativ (det vill säga alla loggtabeller som har PICKED_COURSE_OFFERING som huvudtabell) är alldeles för många för att det ska gå att byta person-id på dem. Databasen gör helt enkelt time-out innan det är klart. Eftersom ärendehistoriken läser direkt från loggtabellen, kommer de att bli missvisande och visa de poster som tillhör den anmälan som togs bort. Detta är ytterligare ett skäl till att den sökande själv ska uppmanas att göra om och göra rätt, snarare än att städa upp med hjälp av sammanslagning. Det är också ytterligare ett skäl att i möjligaste mån se till så att det är till-personens anmälan som blir kvar efter sammanslagningen. Alias Aliashanteringen har inte påverkats, utan det nya systemstödet har enbart följt den befintliga verksamhetsprocessen. En sak att konstatera är att sökande med enbart folkbokföringsadresskydd, som alltså vill använda Antagning.se för att göra och följa sin anmälan, inte av systemet måste ha en tidsbegränsad adress istället. En person med e-post som kontaktsätt får sakna postadress.