Subject: Webservices med OIOXML

Title: CPR Broker Subject: Webservices med OIOXML Side 1 af 118

Abstract This report describes a system for implementing public standards via webservices. The first part of the report is a description of legislation, history and background for the project. This part involves an analysis of the surrounding enviroment as well as a description of allready known problems that the project faces, and requirements given. The second part of the report is a designdocument descriping the approach taken in designing the system to be scalable and modular. The project is initiated by Magenta Aps. An open source company in Copenhagen. The report covers the folowing keypoints: Goverment designed standards and communication. Including the challenges in acting in a political enviroment. Contract first design of XSD and implementation. Perfomance perspectives in webservices. Technologies and standards in use are: SOAP, WSDL, OIOXML, eventdriven architecture and scalabiliity. Authors: Lasse Hansen (070078) and Henrik Pedersen (5153) Academic supervisor: Bo Holst Christensen (bhc@ihk.dk) Project supervisor: Leif Lodahl (leif@magenta aps.dk) Date:29 12 11 Side 2 af 118

Indholdsfortegnelse 1. Indledning...8 1.1. Det Centrale Personregister...8 1.1.1. Problemer ved central registrering af borgere...8 1.2. Fagsystemer...9 1.3. Baggrund...9 1.3.1. Formål med projektet...11 1.4. Åbne standarder...12 1.5. Opsummering...13 2. Problemformulering...14 2.1. Personnummeret...14 2.1.1. Personnummerets opbygning...15 2.1.2. Imigranter...15 2.1.3. Midlertidige borgere...16 2.1.4. Validering og Modulus 11...16 2.1.4.1. Andre valideringsmetoder...16 2.2. OIOXML...16 2.2.1. OIOXML PART...18 2.2.2. Unik nøgle...19 2.2.3. UUID...19 2.3. Fagsystemer...19 2.4. Dataleverandører...20 2.5. CPR Kontoret...21 2.5.1. Baggrund...21 2.5.2. Økonomi...21 2.6. Risikoanalyse...22 2.7. Milestone & tidsplan...22 2.8. Afgrænsning...22 3. Kravspecifikation...24 3.1. Formål...24 3.2. BATOFF...24 3.3. Omgivelser...26 3.3.1. Aktører i kontekst...26 3.3.2. Brugerprofiler...27 3.4. Funktionelle krav...27 3.4.1. Use Cases...30 3.5. Non funktionelle krav...30 3.6. Requirement trace...31 Side 3 af 118

3.7. Opsummering af kravspecifikation...31 4. Analyse...32 4.1. Anvendelsesområdet...32 4.1.1. Omgivelserne...33 4.1.2. PEST(LE)...33 4.1.3. SWOT...35 4.2. Problemområdet...36 4.2.1. Domænemodel...36 4.2.2. Klasseansvar...36 4.2.3. Hændelser...37 4.2.3.1. Batchjob...37 4.2.3.2. DPR viderestilling...38 4.3. Tekniske analyser...40 4.3.1. Personnummervalidering...40 4.3.1.1. Fejl i personnummer...40 4.3.1.2. Algoritmer...41 4.3.1.3. Konklusion på personnummervalidering...44 4.3.2. Webservice interface...44 4.3.2.1. XML...44 4.3.2.2. WSDL...44 4.3.2.3. SOAP...44 4.3.2.3.1SOAP kommunikation...45 4.3.2.4. Sikkerhed...45 4.3.3. Kommunikation til validator...46 4.3.3.1. Konklusion...46 4.3.4. Kommunikation med dataprovider...46 4.3.4.1. DPR...47 4.3.4.2. Andre dataproviders...47 4.3.5. Kommunikation med fagsystem...47 4.3.6. PersonMaster...48 4.3.6.1. Løsningen i dag...48 4.3.7. Egen database eller bruge Dataprovider...48 4.3.8. Sikkerhed og persondataloven...48 4.3.8.1. Transport...49 4.3.8.2. Opbevaring og adgang...49 4.4. Opsummering af analysen...49 5. Design...51 5.1. Indledning...51 5.1.1. Konsekvenser...52 5.2. Kriterier for designet...52 Side 4 af 118

5.2.1. Forretningslogik...53 5.3. DPR (Decentrale Person Register)...53 5.3.1. Sikkerhed...53 5.4. SOAP...53 5.4.1. Sikkerhed...53 5.5. OIOXML...54 5.6. Database design...54 5.6.1. Tabeldesign...55 5.6.2. Design af views...56 5.6.3. Systemtabeller...56 5.6.4. Sikkerhed...56 5.7. Abonnement / Subscription...57 5.7.1. Batchjob...57 5.8. Softwarearkitektur...57 5.8.1. Klasse diagram...58 5.8.2. Moduler...59 5.8.2.1. WS OIOXML PART...59 5.8.2.2. Eventbrokeren...59 5.8.2.3. Dataprovider...59 5.8.2.4. WS CPR2UUID...60 5.9. Sikkerhed...60 5.10. Flow charts...61 5.10.1. DPR Viderestilling...61 5.10.2. Abonnement event...62 5.10.3. SignalHandler...62 5.10.4. Opret abonnement...63 5.10.5. WS CPR2UUID...63 5.10.6. WS Person...64 5.11. Konklusion på design...64 6. Implementering...65 6.1. Valg af sprog...65 6.1.1. C++...65 6.1.2. Perl og Python...65 6.1.3. C#...65 6.1.4. Java...66 6.1.5. Konklusion på valg af sprog...66 6.2. Valg af platform...66 6.2.1. Apache Tomcat...66 6.2.2. Apache Axis2...67 6.2.3. Glassfish...67 6.2.4. Konklusion på valg af platform...67 Side 5 af 118

6.3. Database...67 6.3.1. MySQL...68 6.3.2. PostgreSQL...68 6.3.3. Konklusion på valg af database...68 6.4. Proof of concept...68 6.4.1. WebServicen...68 6.4.2. Skemaer...69 6.4.3. Test...71 7. Test...72 7.1. Personnummervalidering...72 7.1.1. Modulus 11 og dato test...72 7.1.2. Platform test...73 7.1.3. Konklusion på personnummer validatoren...73 8. Konklusion...74 8.1. Den produktorienteret konklusion...74 8.2. Den procesorienteret konklusion...74 Appendix A Folketingsvalget 2011...76 Appendix B Tidsplan...77 Appendix C Gantt...78 Appendix D Milestone...78 Appendix E Risikoanalyse...80 Appendix F Validator test skema...81 Appendix G BATOFF...81 Appendix H Use case specifikationer...82 Appendix I Klasseansvar i analysefasen...96 Appendix J Klasseansvar i designfasen...97 Appendix K Klassediagram i design...102 Appendix L Kriterier for design...103 Appendix M Kildetekst...104 Appendix N OIOXML PART ny version...115 Appendix O Dokumentreferencer...116 Appendix P Personer der har bidraget til projektet...117 Side 6 af 118

Appendix Q Litteraturliste...117 Side 7 af 118

1. Indledning I dette afsnit behandler vi indledningen til rapporten. Vi vil omtale baggrunden for projektet, og introducere nogle begreber der relaterer til projektets omgivelser. Behovet for adgang til valid information har alle dage eksisteret. Siden computerne har gjort deres indtog, er behovet for data der kan stoles på vokset tilsvarende. Dette projekt beskæftiger sig med en lille del af den indsats der gøres for at transformere properitære data, til data der overholder en fælles standard i XML som alle systemleverandører af datasystemer til det offentlige i Danmark kan anvende. 1.1. Det Centrale Personregister Forløberen for CPR var Folkeregisterkortene. Disse kort blev ikke vedligeholdt eller opbevaret centralt. Folkeregisterkortene fra 1924 og frem til 1978 opbevares i dag hos Statens Arkiver. De fleste er digitaliseret, så de kan søges og bruges elektronisk. Går vi længere tilbage i historien var politiet de første til at registrere borgere centralt. Decentral registrering kan vi føre endnu længere tilbage i historien. De første strukturerede registreringer var kirkebøgerne som førtes af de lokale kirker, og registrerede dåb, konfirmation, ægteskab og død. Det Centrale Person Register som vi kender det i dag, blev indført den 2. april 1968. I dag anvendes CPR informationer overalt i den offentlige administration. Det være sig i alt fra sundhedsvæsenet over skatteindbetaling til adresseregister og persontilhørsforhold som forældre og børn. 1.1.1. Problemer ved central registrering af borgere George Orwell skrev i 1948 bogen 1984 om det totalitære overvågningsregime, hvor Big Brother overvåger alle borgere og med en stigende disrespekt for individets rettigheder. Bogen har lagt navn til begrebet Big Brother der i dag bruges som betegnelse for institutioner i staten der overvåger borgerne, eksempelvis efterretningstjenester. Fra et militært synspunkt må man også sige at et komplet centralt register over alle et lands borgere, i en krigssituation vil være et kæmpe aktiv for en fremmed krigsmagt. Historisk kan man filosofere over hvad det ville have betydet under besættelsen 1940 til 1945, hvis et sådan centralt register over alle borgere havde eksisteret. Allerede da CPR blev indført, var der betydelige protester mod denne centrale registrering af Side 8 af 118

uskyldige borgere, men protesterne må siges at være aftaget i dag. Om det så skyldes de tydelige fordele der er ved et centralt register af alle borgere, ligger uden for dette projekt at tage stilling til. 1.2. Fagsystemer Kommunerne har ca. 300 forskellige fagsystemer. Med fagsystemer menes systemer skræddersyet til at løse en konkret opgave i den kommunale administration. Eksempler på sådanne systemer er: Administration af daginstitutionspladser Udbetaling sygedagpenge eller kontanthjælp Økonomisystemer Lønsystem Fælles for de fleste af fagsystemerne er at de behandler borgere identificeret ved et Personnummer. 1.3. Baggrund For ca. 3 år siden kom Steen Deth1, It Chefarkitekt i Gentofte Kommune, på den ide at bruge den nyligt besluttede OIOXML2 standard, til at få ensartet sine datakilder i den kommunale it infrastuktur. Hans motivation var til dels at sikre ensartede data, i første omgang på personer, men også reducere sine omkostninger til integration af fagsystemer. Hvert fagsystem har sin egen datamodel som systemet arbejder med, og nogle fagsystemer opdatere deres personstamdata i batch, andre opdatere realtime fra eksempelvis det Decentrale PersonRegister (DPR). Interfacet til denne opdatering af stamdata er forskelligt fra fagsystem til fagsystem. Hvert fagsystem leverer derfor sit eget interface til en eller flere af de tre dataleverandører. Denne integration er dels en engangsomkostning til udviklingen for hvert fagsystem, samt en betydelig årlig omkostning for vedligehold. Med mere end 300 fagsystemer i en kommune er denne omkostning meget stor, og motivationen for kommunerne er derfor i høj grad øknomisk. Nedenstående er en skitse af hvordan det i dag ser ud hos en kommune. 1 http://digitaliser.dk/user/251041 (29 12 11) 2 Se afsnit om OIOXML på side 16 Side 9 af 118

Illustration 1:Nuværende arkitektur i Gentofte Kommune Sten Deth's ide var derfor at etablere en central komponent i sin infrastruktur, der sørgede for at holde persondata opdateret og tilbød et åbent webserviceinterface baseret på OIOXML til alle fagsystemerne. Efter et ihærdigt arbejde fra hans side i udvalget, med at få lavet OIOXML PART beskrivleserne færdige, etablerede man et samarbejde med Magenta Aps3, der fik ansvaret for selve udviklingen af CPR Brokeren. 3 http://magenta aps.dk/ (29 12 11) Side 10 af 118

1.3.1. Formål med projektet Steen Deth's vision med CPR Brokeren kan bedst beskrives med nedenstående illustration. Illustration 2:Visionen for CPR Brokeren. KMD som dataleverandør ses der her bort fra, da datalevering direkte fra CPR kontoret er det optimale scenarie. Den eksisterende version af CPR Brokeren er i høj grad en prototype og har derfor nogle uhensigtmæssigheder i designet. Opgaven for os er derfor at analysere omgivelserne og standarden, og komme med et forslag til et fremtidigt design der tager hensyn til at eksempelvis et krav om realtime data, høj tilgængelighed og skalerbarhed. Træder vi skridtet længere og ser på fremtiden, vil den byde på integration af andre offentlige datakilder indenfor PART, herundet BBR4 og CVR5. Alle disse informationer skal konsolideres i CPR Brokeren, som jo nok må forventes at skifte navn til den tid, og præsenteres for fagsystemerne via OIOXML PART. 4 Bygnings og Bolig Registret. http://www.bbr.dk/ (29 12 11) 5 Det Centrale Virksomheds Register. http://www.cvr.dk/site/forms/cms/displaypage.aspx?pageid=0 (29 12 11) Side 11 af 118

1.4. Åbne standarder Formålet med åbne standarder er kort fortalt at sikre interoperalitet. Det betyder at uafhængige systemer skal kunne kommunikere sammen uanset hvilken platform, operativsystem eller sprog de måtte være implementeret i. Samtidig sikres det at standarderne ikke ligger under for en ejernes behov for at tjene penge på det, som det eksempelvis ses ved MPEG 46 standarden. I projektets kontekst er det væsentlige at data grundlæggende er ejet af det offentlige repræsenteret ved kommunerne og staten. Men som realiteterne er i dag skal kommunerne købe deres egne data af trediepart, og i nogle tilfælde købe de samme data flere gange til forskellige Fagsystemer. Set fra et samfundsperspektiv er det meget dårlig forretning, og når trediepart, som tilfældet er i CPR, er ejet af en udenlandsk virksomhed, sender det danske samfund årligt mange millioner kroner til de udenlandske ejere, fordi vi køber adgang til vores egne data. Den danske humorist (med mere) Storm P illustrerede dette princip på følgende vis. Illustration 3:Storm P's "Hunden der fodres med sin egen hale" 6 Standard der er underlagt restriktioner for implementering. http://en.wikipedia.org/wiki/mpeg 4 (29 12 11) Side 12 af 118

1.5. Opsummering Vi har i indledningen forsøgt at give et billede af omgivelserne og baggrunden for projektet. Kort fortalt er projektet affødt af en enkelt kommunes vision for hvordan ting kan gøres lidt nemmere. I den ideele verden ville CPR Kontoret, som statens ansvarlige for personnumre, selv implementere OIOXML PART standarden og sørge for at der fandtes en central service for UUID7'er, og vores projekt ville være overflødigt. Men realiterne er at projektets anvendelsesområde i meget høj grad er samfundsvidenskabelig, og derfor drevet af at de politiske beslutningstagere har fokus på det. Set fra vores side er der en hel række af gevinster i offentlig digitalisering, der kunne realiseres for rimeligt enkle midler, hvis blot det var en prioritet. 7 Universally Unique Identifier. http://en.wikipedia.org/wiki/universally_unique_identifier (09 11 11) Side 13 af 118

2. Problemformulering I dette afsnit angives til at starte med en del om baggrunden for projektets omgivelser, og en del om de problematiker der allerede i de indledende faser er identificeret. Slutteligt angiver vi en konklusion på baggrund af problemformuleringen. 2.1. Personnummeret Alle danske statsborgere har et personnummer. Nummeret består af deres fødselsdato og fire ekstra cifre der fortæller om køn, hvilket århundrede de er født og et løbenummer. I dag tildeles et personnummer af CPR Kontoret, med det samme når lægen eller sygeplejersken på hospitalet har registreret fødslen. Personnumre genbruges ikke. I forbindelse med høringen af den nye version af OIOXML er der identificeret et behov for at kunne arbejde med personer der ikke har et personnummer. Side 14 af 118

2.1.1. Personnummerets opbygning Personnummeret er ikke så tilfældigt sammesat som det muligvis kan se ud til. Nedenfor er angivet hvorledes det er opbygget8. Ciffer Indhold 1 og 2 Dato i måneden de er født, angivet med foranstillet '0'. Eksempelvis skrives den femte som '05'. 3 og 4 Måneden de er født, angivet med foranstillet '0'. Eksempelvis skrives juni som '06'. 5 og 6 Årstallet de er født, angivet med foranstillet '0'. Eksempelvis skrives 2007 som '07'. 7 Løbenr. Ciffer 7 Årstal 00 36 37 57 0 3 4 5 8 9 8 og 9 10 58 99 1900 til 1999 2000 til 2036 2000 2057 2000 2036 1937 1999 1858 1899 1937 1999 Løbenummer der sammen med ciffer 7 og personens køn bestemmer valget af ciffer 10. Bestemmes af Modulus 11 beregningen, men er også bestemt således at et lige nummer angiver at personen er hunkøn, og ulige nummer angiver at personen er hankøn. Tabel 1:Personnummerets opbygning 2.1.2. Imigranter Indvandrere og flygtninge der kommer her til fra tredieverdenslande, har ofte kun begrænset information om hvornår de er født. De fleste ved heldigvis at de eksempelvis 23 år gamle, men der er flere eksempler på flygtninge hvor informationerne har været så sparsomme, at man har haft en læge til at vurdere en persons alder. Hvis de ikke kender deres nøjagtige fødselsdag, er proceduren at tildele dem fødselsdagen den 1. januar det pågældende år man mener at de er født. 8 Tabel lånt fra Wikipedia. http://da.wikipedia.org/wiki/cpr nummer (29 12 11) Side 15 af 118

2.1.3. Midlertidige borgere Borgere der tager midlertidig ophold i Danmark, eks. studerende eller udstationerede medarbejdere tildeles også et personnummer. 2.1.4. Validering og Modulus 11 Modulus 11 metoden bruges til at validere et personnummer. Metoden er ikke 100% sikker da vægtene 2, 3 og 4 bruges flere gange, og der kontrolleres heller ikke om det er et nummer der er i brug eller ej. I analysen vil vi komme nærmere ind på detaljerne vedrørende Modulus 11. Et yderligere problem ved denne valideringsmetode er at man hos CPR kontoret begik en fejl, da man modtog en større mængde flygtninge i 2007. I stedet for blot at give dem en anden fødselsdag end den 1. januar, slog man Modulus 11 kontrollen fra og genererede deres personnumre. Det betyder at findes et større antal personer med fødselsdag den 1. januar 1965 eller 1. januar 1966 hvor Modulus 11 metoden ikke kan bruges til validere deres personnummer. De fagsystemer der primært anvender Modulus 11 som validering, implementerer en ekstra tabel med de personnumre der er undtaget for Modulus 11 kontrollen. 2.1.4.1. Andre valideringsmetoder Som der redegøres for i afsnittet om økonomi, vil der i projektet være et krav om at personnumre valideres. Vi vil derfor også kigge på hvilke andre muligheder der er for validering, samt lave nogle analyser på hastigheder for validering, så den optimale model for validering kan vælges. Eksempelvis kunne man forestille sig at Modulus 11 er den hurtigste test at udføre på et personnummer, men som vi har beskrevet er denne metode ikke 100% sikker. Den næste test kunne så være om det er en korrekt dato der er angivet i personnummeret. Man kunne eks. Forestille sig at der ved en fejl var angivet datoen 29. februar 2000 som er en dato der ikke eksisterer. 2.2. OIOXML OIOXML er en kombineret forkortelse af Offentlig Information Online extensible Markup Language. På www.digitaliser.dk findes en samlet oversigt over alle dele af OIOXML. Den mest kendte af understandarderne er efaktura, som er standarden for elektroniske faktura, og skal benyttes ved handel med det offentlige. Denne standards store succes er i høj grad affødt af, at anvendelsen af den var en beslutning taget i Folketinget. Kunne man fra 1. januar 2008 ikke sende sin faktura elektronisk til det offentlige, var man ikke længere leverandør. Det er desværre nok sådan, at en væsentlig del af de gode initiativer indenfor offentlig it, kun bliver en realitet når der sættes lovgivning bag. Det kunne jo være interessant om det blev drevet frem af åbne standarder, og markeder bestående af flere leverandører og kunder. Side 16 af 118

Som en del af Folketingets beslutning B103 (2006)9, som Folketinget vedtog den 2. juni 2006, var det et krav at alle myndigheder skulle opfylde kravet om at stille krav til deres it leverandører om, at alle fremtidig systemer skal understøtte OIOXML. Beslutningen er dog formuleret således at kravet kan fraviges ud fra et comply or explain begreb. Det vil sige at det er obligatorisk at anvende standarderne, med mindre at der er tungtvejende grunde til ikke at gøre det. Af tungtvejende grunde anerkendes følgende: Gør løsningen væsentlig dyrere. Svækker sikkerheden. Medfører funktionelle forringelser. Øger implementeringstiden markant. Medfører konfilkt med standarder i relation til internationale forpligtelser. Ifølge Adam Arndt (AA) fra ITST er der ingen mydighed der har ret til at kontrollere om dette overholdes, og der er findes ingen sanktionsmuligheder for ikke at følge beslutningen. Ifølge AA introduceres det i forbindelse med rapport der dannede grundlag for en fællesoffentlig aftale om brug af åbne standarder10. Der er således ikke nogen centralt overblik over hvor mange gange at man har fraskrevet sig forpligtelsen til at anvende åbne standarder, AA er kun bekendt med at Rigsarkivet har begrundet deres fravalg. Offentliggørelsen af fravalg kan de enkelte instancer selv vælge hvordan de vil gøre. Eks. kan det gøres i deres årsrapporter eller blot som en artikel på deres hjemmeside. It og Telestyrelsen har ansvaret for www.digitaliser.dk og har udgivet mange dokumenter om de standarder man forventer bliver indeholdt i OIOXML. Nedenstående er den begrebsmodel som de knytter til OIOXML, hvor man gerne skulle kunne danne sig et indtryk af hvor eksempelvis PART delen hører til. Det blev lagt op til at de enkelte domæner indenfor standarden skulle udarbejdes i de organisationer de vedrørte. Ideelt i tværfaglige domænebestyrelser, og koordineret af OIO Sekretariatet i It og Telestyrelsen. Ideen med dette var at sikre at standarden var forankret i en organisation der forventes at bestå, og havde interesse i dens anvendelse, især i lyset af at såvel domænebestyrelser og OIO udvalgene var tænkt som kortlivede. Det er for nuværende uklart hvem der har ansvaret for arbejdet med de offentlige åbne standarder. Se bilag om Folketingsvalget 2011 i afsnit A. 9 http://www.ft.dk/samling/20051/beslutningsforslag/b103/index.htm (01 11 11) 10 http://www.itst.dk/it arkitektur og standarder/standardisering/abne standarder/aftale mellem regeringen kl og danske regioner om abne standarder for software (18 11 11) Side 17 af 118

Illustration 4:Begrebsmodel fra It og Telestyrelsens vejledning for OIOXML Som det ses udspringer ideen til OIOXML primært af et behov for ESDH. 2.2.1. OIOXML PART Formålet med OIOXML PART er beskrevet i detaljer af OIO udvalget for Sag og Dokument i Specifikation af serviceinterface for Person11. Dokumentet beskriver blandt andet omkring baggrunden for at lave standarden at: Bindingen mellem persondatasnitflade og fagsystem er 1:1, og derfor meget kritisk overfor ændringer. Erfaringsmæssigt er det vanskeligt for leverandørerne af fagsystemerne at tolke data korrekt. Der skal indbygges fejlhåndtering ved opdateringsjob (batch) og indgriben ved fejl. Det 11 https://www.borger.dk/lovgivning/hoeringsportalen/dl.aspx?hpid=29118 Side 18 af 118

stiller store krav til it kompetencerne hos eks. Kommunerne. Ansvarsfordelingen imellem leverandører, dataprovider og kunden er uklare. I standarden er PART angivet som abstrakt klasse. Det vil sige at den ikke skal anvendes direkte men skal nedarves til eksempelvis Person. Et yderligere formål med standarden er at implementere nogle felter/klasser der ikke eksistere i CPR i dag, eksempelvis kontaktkanaler, lægeoplysninger og at en person kan have flere kontaktadresser tilknyttet (sommerhus og lign.). Adresse er også en abstrakt klasse der skal realiseres i enten AdresseDanmark, AdresseGrønland eller AdresseVerden. AdresseDanmark har nogle relationer til blandt andet BBR. 2.2.2. Unik nøgle Da man begyndte med personnummerregistret blev personnummeret betragtet som en unik og uforanderlig nøgle der følger en person fra vugge til grav. Virkeligheden har vist sig ikke at holde stik med designet, og det sker ofte at en person skifter personnummer af den ene eller den anden årsag. Sten Deth fra Gentofte kommune oplyser at det hos dem, med ca. 70.000 borgere, sker i gennemsnit tre gange om måneden. Desværre er mange systemer indenfor det offentlige af en ældre dato, hvor systemdesignet betragter personnummeret som uforanderligt og unikt, og derfor ikke understøtter at en person kan skifte personnummer. Det er forskelligt hvordan de individuelle fagsystemer håndtere dette, men en del har implementeret løsninger hvor det gamle personnummer optræder som et skyggenummer og derfor stadig udgør den unikke nøgle for personen. En af ulemperne ved denne løsning er at der i et sikkerhedsmæssigt perspektiv, er det problem at en person der har skiftet identitet, stadig kan findes ved det gamle personnummer. Denne problematik 2.2.3. UUID OIOXML PART introducere flere nye felter til klassen person, som ikke i dag findes i CPR Systemet. Et af de felter er Universally Unique Identifier (UUID). Ideen er at en person tilknyttes en globalt unik identifikation der kan bruges som primær nøgle i alle it systemer indenfor det offentlige. Feltet er indført i erkendelse af at personnummer måske nok er unikt, men ikke uforanderligt. Problemet med UUID er at der ikke i dag findes en central løsning der sikrer at UUID også er unikt. I den nuværende version af CPR Brokeren findes der en komponent der hedder PersonMaster, der ser til at uddele UUID og holde orden på relationerne til personnummrene. Denne løsning fungerer dog kun indenfor det pågældende domæne, eks. Gentofte Kommune. I analysen vil vi komme nærmere ind på denne problematik. 2.3. Fagsystemer De fleste af en kommues it systemer er meget fagspecifikke. Det er systemer der specifikt Side 19 af 118

understøtter processerne i forhold til funktionerne, eksempelvis lønsystemer, pladsanvisning, hjemmepleje og udbetalingssystemer. Et af de felter hvor fagsystemer udvikler sig meget, er indenfor Elektronisk Sags og Dokument Håndtering (ESDH). Det er netop ESDH systemer der har affødt behovet for de fælles standarder for data (OIOXML), da data gerne skal kunne udveksles gnidningsløst i mellem forskellige fagsystemer. Som det er i dag er der mange processer i den kommunale administration, der kræver indtastning af de samme data flere systemer, med et stort ressourcespild til følge. Fælles for alle fagsystemer er: De anvender deres egne datamodel der er designet ud fra det enkelte systems funktionelle krav. De har deres egen metode/datavej for import af grunddata som CPR, BBR og CVR. De arbejder alle med Personnumre som et grundelement i deres datamodel. PART standarden, der handler om personer, er derfor også kun en lille del af OIOXML der beskæftiger sig med hele ESDH området. 2.4. Dataleverandører Begrebet dataleverandører dækker over de databaser med stamdata som staten driver. Nedenstående skema er en liste over de almindeligt kendte. CPR BBR CPR Kontoret under Indenrigsministeriet er dem der administrere CPR Systemet. CPR Kontoret er at betragte som en selvejene institution på linie med eksempelvis Kort og Matrikel Styrelsen. Det betyder blandt andet at de ikke er på finansloven og de skal derfor selv finde finansiering til driften, ved at sælge deres produkter. Dette er en politisk beslutning, og har betydet at CPR Kontoret sammen med deres leverandør af hosting CSC, har skulle lave en forretningsmodel hvor de kan tjene penge på brugerne/kunderne af CPR data, primært kommunerne. Før 2005 var det hver enkelt kommune der havde ansvaret for at vedligeholde et register over fast ejendom, og ejerne her af. Siden 2009 er det blevet lagt ud til firmaet KOMBIT A/S, der ejes af Kommunernes Landsorganisation. Formelt er det Erhvervs og Byggestyrelsen der har dataansvaret. BBR data kan frit søges enkeltvis på www.ois.dk, men ønsker man større udtræk fra databasen skal det bestilles og der skal betales for det. Reelt driftes BBR systemet også hos CSC. Side 20 af 118

CVR I registret over virksomheder (CVR) kan der gratis søges begrænset information om virksomheder og deres ejerskab. Vil man have adresse eller brancheudtræk skal man betale en af de private leverandører, der har købt sig til fuld adgang i databasen. Erhvervs og selskabsstyrelsen har dataansvaret, også her er det CSC der drifter systemet. De fleste af de offentlige databaser driftes og vedligeholdes af CSC. 2.5. CPR Kontoret Vi er afgrænset til kun at kigge på det Centrale Person Register. I dette afsnit vil vi beskrive hvor CPR Kontoret passer ind i omgivelserne, samt lidt om økonomien og de reele omstændigheder for hvordan de arbejder. 2.5.1. Baggrund Som tidligere nævnt er forretningsmodellen for CPR Kontoret sådan udformet at de skal tjene penge til egen drift på deres produkt. Produktet er persondata på alle landets borgere. Af data de vedligeholder og gør tilgængelige kan nævnes: Status (Gift, enke, ugift osv.) Relationer mellem forældre, børn og værge Adresse og suplerende informationer og historik om personens adresse bla. til statistik. Statsborgerskab Historik for navneskift 2.5.2. Økonomi I finansloven 2009 er CPR Kontorets hovedopgaver formuleret således12: Som anført i finanslovens oversigt over specifikationer af udgifter på opgaver, varetager CPR administrationen følgende hovedopgaver: Salg af data til CPR's kunder, drift og vedligeholdelse samt udvikling af CPR systemet og dettes produkter, juridisk sagsbehandling, hjælpefunktioner samt generel ledelse og administration. 12 Det Centrale Personregisters årsrapport 2010 Side 21 af 118

Forretningsmodellen er skruet sådan sammen at kunderne (Kommunerne) betaler et beløb for hver forespørgsel på et personnummer. Efter vores oplysninger er beløbet DKK 0,46, så hvis en kommune vil have data på alle landets borgere er det en rimelig stor udskrivning. Derfor abonnere de fleste kommuner også kun på egne borgere og ansatte. Når man så kombinere dette med nogle gamle protokoller for dataudveksling som eksempelvis fastformaterede linier i tekstfiler, skal der ikke meget til før det kan give problemer og udgifter. Et eksempel på dette er fra en af landets store kommuner der oplevede en mindre fejl i et fagsystem der gjorde at den fastformaterede tekstfil blev skiftet et tegn til højre. Det betød at alle personnumre i filen var forkerte og hele forspørgslen med ca. 500.000 linier i var forkert, men kostede stadig den fulde pris for hver enkelt opslag. Ifølge Årsrapporten 2010 var der dette år indtægter ved salg af produkter og serviceydelser for DKK 88.011.000,00. Det vil sige at primært kommunerne betalte ca. 88 mill. kr. for at få adgang til, hvad der grundlæggende er, deres egne data. I samme rapport redegøres der får driftudgifterne således at personale, husleje og afskrivninger udgør DKK 33.850.000. Der resterer så en post der hedder Andre ordinære driftsomkostninger på DKK 44.100.000 hvor det må antages at udgiften til hostingfirmaet (CSC) er indeholdt. Alt i alt må det siges at være en udmærket forretning at handle med persondata. 2.6. Risikoanalyse I appendix E på side 80, har vi redegjort for de risici der kan være forbundet med projektet. Ved hver af de forskellige risicis er der taget højde for følgende: En beskrivelse af den pågældende risiko, en vurdering af om sandsynligheden for risikoen bliver en realitet er høj, mellem eller lav, en vurdering om dens indvirkning er høj, mellem eller lav, og til sidst en analyse af hvorledes risikoen kan afhjælpes. 2.7. Milestone & tidsplan I appendix D på side 78, har vi redegjort for vores milstoneplan og tidsplan. Vi har taget udgangspunkt i risikoanalysen, og fokuseret på de risici som har størst indvirkning i starten af projektet. 2.8. Afgrænsning I dette afsnit behandler vi de punkter som vi, på basis problemformuleringen, har valgt at afgrænse os til. Vi afgrænser i forhold til hvad der er realistisk at nå i projektet, men lægger i designet op til at systemet kan udvides med eksempelvis flere dataleverandører osv. Person Master Side 22 af 118

Problematikken angående at personumre ikke er unikke nøgler og uuids ikke er global unikke, vil vi ikke beskæftige os med. CPR Brokeren skal dog understøtte de generede UUID's som Person Master opretter. Færøerske og Grønlandske adresser Den første version af CPR Brokeren understøtter ikke adresser på Grønland og Færøerne. Da dette problem ikke er første prioritet at løse, vil vi ikke komme nærmere ind på dette. Dataleverandør Ligesom den nuværende CPR Broker vil vi kun understøtte DPR CPR løsningen. Dvs. at CPR Online og KMD ikke bliver taget med i denne omgang, men vi vil arkitekturen tage hensyn til at der skal kunne anvendes flere dataleverandører. Fagsystemer Da vi kun vanskeligt kan få adgang til reelle stamdata, kan vi reelt kun kunne validere data ved hjælp af SoapUi og lignende værktøjer. Vil vi prøve at finde et andet fagsystem til at underbygge testen. Validering af personnummer Vi vil i projektet redegøre og teste forskellige valideringsmetoder i forhold til performance og systemet fejlmargin. Der er et krav om at det skal være muligt at validere mange personnumre i batch. Event baseret Til trods for at CPR/DPR ikke gør, og kun enkelte fagsystemer i dag understøtter realtids opdaterede data, vil vi designe systemet således at der er fuld understøttelse for det. Subscriptions (Abonnementer) Subscriptions er en funktionalitet i den eksisterende version af CPR Broker, der gør at fagsystemer kan abonnere på enkelte personnumre. Når der så sker noget med det personnummer udløser det en event der opsamles af fagsystemet, der så selv bestemmer hvad der skal ske. Under abonnementer er der også en funktionalitet der operere batchorienteret på data. Eks. kan der i systemet hver nat genereres en liste over personnumre der indenfor de næste tre uger fylder 60 år. Det primære mål med projektet er at ende med et solidt design der vil kunne implementeres. Vi er godt klar over at det vil være vanskeligt at nå længere end til en proof of concept installation, men vi vil ikke desto mindre sigte efter at have noget software at fremvise. Side 23 af 118

3. Kravspecifikation Afsnittet handler om den formulerede kravspecifikation. Den er udarbejdet i overensstemmelse med retningslinierne for Objektorienteret Analyse og Design (OOAD) og UML. Kravspecifikationen inddeles i en BATOFF, en beskrivelse af aktører, funktionelle og non funktionelle krav, og en beskrivelse af interfaces. 3.1. Formål CPR Brokeren er en netværksservice der formidler informationer om personer til fagsystemer. CPR Brokeren henter sine data i sin egen database. Data bliver opdateret kontinuerligt ved læsning af DataProviders som eks. DPR. 3.2. BATOFF BATOFF hjælper os til at forstå systemets omgivelser. Det teoretiske grundlag for BATOFF findes Betingelser Anvendelsesområdet Teknologi Dataprovider, i denne kontekst CSC, leverer det Centrale Person Register der danner datagrundlaget for systemet. Leverandører af fagsystemerne skal understøtte OIOXML PART for at kunne benytte systemet. I forbindelse med opslag skal systemet understøtte en form for validering af personnumre der kommer som input. Systemet skal kunne indgå i øvrige it miljø med et minimum af krav til omgivelserne. Systemets arkitektur skal understøtte et fremtidigt behov for skalering. Systemet skal være Open Source. Fagsystemer Objekter Systemet skal tilbyde webservices baseret på SOAP, og OIOXML PART standarderne. Datagrundlaget for servicen skal hentes fra CPR Kontorets register. Systemet skal overholde gældende lovgivning omkring personnumre. Side 24 af 118

Persondata Events Funktioner SOAP Webservices til fagsystemer. Abonnementsservice på personnumre for fagsystemer. Realtime propergering af data. Filosofi Systemet er en formidler(broker) af persondata der placeres i kommunens (kundens) it installation. Systemet omsætter de relationelle data der kommer fra dataprovider og omskriver dem til OIOXML PART standarden. Modularitet så selve brokeren kan fremstå som ren OIOXML. En supplerende tekst omkring BATOFF, kan findes i appendix G. Side 25 af 118

3.3. Omgivelser I dette afsnit beskriver vi systemets omgivelser i detaljer. 3.3.1. Aktører i kontekst Da systemet er et backend system er der som sådan ikke nogle brugere(mennesker) af systemet. Der er dog systemadministratoren der skal have adgang til logfiler og konfiguration, men systemet specificere intet brugerinterface Følgende aktører er identificeret: Fagsystemer: Det forudsættes at fagsystemet kan opdateres via OIOXML PART standarden. Dataprovider: Generelt dataproviders fra forskellige leverandører. I projektet er vi afgrænset til kun at behandle Det Decentrale Person Register. Replikeret database fra CPR med de persondata kommunen abonnerer på. Systemadministrator: Det forudsættes at sysadmin har sat sig ind i hvordan systemet bruges og konfigureres. PersonMaster: En komponent udenfor systemet der uddeler UUID, og mapper dem til personnumre. Illustration 5:Aktører i kontekst Side 26 af 118

3.3.2. Brugerprofiler Fagsystemer: Et it system i kommunen der benytter sig af CPR data. Dataprovider: Der læses kun fra DPR, så der stilles ikke nogen særlige krav til dataproviders for at systemet kan fungere. Systemadministrator: Reagerer på logs og advarsler. Vedligeholder konfiguration af systemet og dataveje. PersonMaster: Har ansvaret for oprettelse af UUID og relationen til personnumrene. 3.4. Funktionelle krav De funktionelle krav er dem vi kan bruge til se om vi opfylder de krav der er sat. FK1: Formål: Det skal være muligt via webservice at søge en person via UUID eller personnummer. Input: Personnummer eller UUID Proces: Valider formatet af input Søg Person Generer svar (OIOXML) Output: OIOXML PART dokument, eller fejlresponse. FK2: Formål: At opdatere systemets egen database med oprettelse af nye personer, eller ændringer på eksisterende personer Input: Personnummer fra DataProvider (DP) Proces: Nyt eller ændret personnummer opdages i DP Opslag til PersonMaster for UUID. Opret/opdater person i db Output: Intet Side 27 af 118

FK3: Formål: At validere om et personnummer er legalt. Input: Personnummer Proces: Valider personnummer i forhold regler. Regler er datovalidering og Modulus 11. Output: Valid eller ikke valid FK4: Formål: At implementere reglerne for datapræsentationen Input: Et dataset Proces: Omsætter felterne i et dataset til det i skemaet specificerede format. Output: Data (dokument) FK5: Formål: At signalere til et Fagsystem at en event er opstået. Input: Event kan være udløst af mange ting, eks. Fejl i batchjob eller abonnement. Proces: Afhængig af Fagsystem og typen af event sendes signal til FS. Output: Ikke defineret FK6: Formål: Ved kørsel af batchjob at overvåge mængden af fejl i opslag, give signal ved grænseværdi. Input: Batchjobejer og grænseværdi. Grænseværdi ngives som absolut værdi eller procentuelt. Proces: Batchjob udføres Fejlopslag tælles Hvis mængden af fejlopslag overstiger grænseværdien, stoppes batchjobbet og der gives signal til ejeren af batchjobbet. Output: Besked om fejl eller succes og data genereret ved batchjob. Side 28 af 118

FK7: Formål: At kunne oprette og nedlægge abonnementer på personer Input: UUID Proces: Opret abonnement eller nedlæg abonnement. Output: Besked om fejl eller succes og data genereret ved batchjob. FK8: Formål: At give administratoren et værktøj til at fejlsøge og monitorere systemet. Input: De enkelte processer i systemet logger input, fejl og output. Proces: Output: Fejl log. De funktionelle krav er overordnet beskrevet og deres implementering ligger ikke fast på dette tidspunkt. I designet vil vi komme ind på hvordan de honoreres. Side 29 af 118

3.4.1. Use Cases I dette afsnit vil overordnet beskrive de use cases der er identificeret i systemet. Illustration 6:Use cases For en nærmere beskrivelse af de enkelte use cases henvises til appendix H på side 82. 3.5. Non funktionelle krav Vores non funktionelle krav kan betragtes som en beskrivelse af nogle begrænsninger som vi sætter for løsningen, og den måde som systemet skal bygges på. NK1 Systemet skal være open source, og kunne publiceres på softwareborsen.dk NK2 Systemet skal understøtte at der kan anvendes mere end en dataprovider, og dataproviders på forskellige operativsystemer og platforme. NK3 Skal kunne installeres og integreres i kundernes eksisterende it miljøer. NK4 Systemet skal være hændelsesorienteret (eventdriven). NK5 Dataudvekslingen til fagsystemerne skal overholde OIOXML/PART standarden, Side 30 af 118

og foregå via SOAP webservices. NK6 En modulær arkitektur af hensyn til skalering og fleksibilitet. NK7 Løsningen skal kunne håndtere personfølsomme oplysninger, der er omfattet af persondataloven. NK8 Systemet skal ikke implementere forretningslogik. Der er et krav om at forretningslogik så vidt muligt holdes ude af selve brogkeren. De steder hvor det er nødvendigt, skal det implementeres som moduler der på et senere tidspunkt vil kunne fjernes fra systemet. 3.6. Requirement trace Vi redegør her for den sammenhæng der er i mellem vores krav, og de use cases de dækkes af. UC1 UC2 UC3 FK1 X FK2 X FK3 UC4 UC5 UC6 UC7 UC8 X X X X FK4 X FK5 FK6 X FK7 X FK8 UC9 X X X X X Tabel 2:Requirement trace af funktionelle krav og use cases. 3.7. Opsummering af kravspecifikation Vi har i kravspecifikationen redegjort for dels de krav der er stillet udefra, samt de krav vi selv har tilføjet. Kravene er opdelt i et antal use cases, der muligvis vil blive revideret i takt med at designet falser på plads. Vi har redegjort for hvorledes vi vil følge kravene igennem projektet, og til slut dokumentere forløbet ved test. Side 31 af 118

4. Analyse I dette afsnit beskæftiger vi os med at analysere alle aspekterne ved projektet. Vi opdeler det i afsnit der beskæftiger sig med generelle analyser som foreskrevet i OOAD, tekniske analyser af validering, platform og sprog. Til slut vil vi på basis af analysen lave en konklusion der bliver forudsætningen for afsnittet om design. 4.1. Anvendelsesområdet I dette afsnit vil vi belyse projektets omgivelser og anvendelsesområde. Her kommer vi også ind på de ting der sket i forløbet, som at der har været folketingsvalg. Vi har valgt de analysemodeller der bedst bidrager til projektet, og i mindre grad om det er den fuldstændig korrekte anvendelse af analysemodellen. Omgivelserne har i forløbet ændret sig markant hvilket vi redegør for lidt mere detaljeret for, i appendix A om folketingsvalget 2011. Men her vil vi forholde os til de omgivelser der var gældende ved projektstart. Side 32 af 118

4.1.1. Omgivelserne Omkring OIOXML er der flere interessenter med forskellige fokusområder. Det har påvirket udbredelsen af standarden at eks. CPR Kontoret ingen interesse har i OIOXML PART, It og Telestyrelsen kun kan arbejde på projektbevilinger, at leverandørerne af fagsystemerne ikke har den store interesse i ikke at kunne sælge den samme ydelse flere gange, og at der i Kommunernes Landsforening er meget stor forskel på hvor langt fremme de enkelte medlemmer er med digitalisering. Illustration 7:Omgivelserne for OIOXML PART standarden Ovenstående tegning skal illustrere de forskellige interessenters engagement og interesse i at få udbredt fælles åbne standarder. I afsnittet om desig vil vi komme nærmere ind på hvordan dette har ændret sig i løbet af projektet. 4.1.2. PEST(LE) Analysen hjælper os til at identificere projektets omgivelser og til dels også de risici der er. Analysen danner et grundlag for at udarbejde en SWOT analyse. Side 33 af 118

Politisk Da projektet omhandler offentlige standarder, er det i høj grad påvirket af de politiske omstændigheder der hersker. I projektets tidlige faser vidste vi godt at der undervejs ville komme et folketingsvalg, men at en konsekvens der af, var at ITST er blevet nedlagt og ansvarsområderne foreløbig lagt ud på fire forskellige ministerier, havde vi ikke lige forudset. Vi bliver derfor særlig hårdt ramt, når det er ITST der har været et af de bærende elementer i udviklingen af OIOXML der forsvinder. Det er vores vurdering at OIOXML består at vi derfor ikke skal lade det få indflydelse på projektet. Økonomisk (Economic) Der er to elementer af økonomi i projektet. Det ene element beskæftiger sig med de omkostninger der må formodes at ligge på kunden, ved valg af denne løsning. Det andet element er den afledte besparelse der på sigt kan opnås ved anvendelse af systemet og offentlige standarder. Samlet set bør der være en gevinst for alle der implementerer systemet og standarderne. Socialt, samfund og kulturelt Når offentlige standarder er fuldt implementeret overalt i det offentlige, vil der være en enorm økonomisk besparelse for samfundet i billigere it og forenklede arbejdsprocesser. For borgerne skulle gevinsten meget gerne ende med at være en stærkt forbedret offentlig service og egenservice. Ved at alle systemer kan tale sammen på tværs, vil det også være langt nemmere at kunne service til borgerne, også over internettet. Teknologi Det meste af den eksisterende it arkitektur og infrastruktur i det offentlige stammer fra en tid før internettet var udbredt og dataforbindelser var meget dyre. Omstændigheder gjorde at alle systemer var orienteret omkring natlige batchopgaver med at udveksle og opdatere data. Dette projekt forsøger at gøre op med denne måde at tænke på! Data skal være opdaterede og frit tilgængelige for alle relevante systemer og brugere. Lovgivning Datatilsynet har igennem ITST godkendt CPR Brokeren i den eksisterende version. Vi forventer ikke at der kommer ændrede krav til dette, men hen over hele projektet have fokus på sikkerhed i systemet. Miljø (Enviroment) Vi har ikke kunne identificere nogle klare miljøkonsekvenser. Side 34 af 118

4.1.3. SWOT SWOT analysen skal anvendes til at belyse hvilke særlige fokusområder der er i projektet. Her beskrives også sammenhængen i mellem elementerne. Analysens punkter er afledt af PEST(LE) analysen. Svagheder (Weaknesses) Styrker Projektet er funderet i en mindre virksomhed Projektet er initieret i en af landets store kommuner. Muligheder (Opportunities) Projektet er funderet i en virksomhed der har gode Det offentlige er begyndt at se potentialet erfaringer med at samarbejde i Open Source og åbne med offentlige partnere. Det giver mulighed for via et standarder. Der er store sparekrav, samarbejde at påvirke så de afledte effekter er beslutningstagere i eks. KL. attraktive. Projektet er funderet i en mindre virksomhed Projektet er funderet i en virksomhed af beskeden størrelse, det kan derfor være svært at få taletid hos de rette. Til gengæld giver størrelsen gode muligheder for hurtige omstillinger og strategiændringer. Trusler Sparekrav kan gøre det vanskeligt at få søsat implementeringsprojekt er. Emnet hører ikke under et specifikt resortområde i det nye folketing. Der er i virksomheden et godt kendskab til de foreninger der kan gøre indflydelse gældende overfor beslutningstagere, når det igen bliver kendt hvem de er. Søge et bredere samarbejde via eksempelvis kommuner eller andre der vil have stor glæde af projektet. Tabel 3:SWOT analyse Konklusionen på SWOT er at der er stort potentiale for projektet i sig selv og afledte projekter med offentlige stamdata. Der er identificeret en væsentlig risiko for at der går bureaukrati i arbejdet med standardiseringen. I bund og grund er det embedsmænd i staten der skal lede arbejdet, men de er underlagt de spilleregler der gælder i det miljø. Det betyder blandt andet at der kun arbejdes på specifikke afgrænsede arbejdsopgaver, og at disse arbejdsopgaver er påvirket af den aktuelle politiske dagsorden. Side 35 af 118

4.2. Problemområdet Dette afsnit beskæftiger sig med at analysere projektets problemområde. 4.2.1. Domænemodel Vi har med baggrund i kravspecifikationen og foranalysen identificeret følgende kandidater til klasser i domænet. I afsnittet om design vil vi omsætte klassekandidaterne og deres ansvar, til de klasser der skal anvendes i implementeringen. Illustration 8:Klassekandidater i domænemodelen Cirklen illustrerer at alle klassekandidater skriver til loggen. Vi har i processen evalueret andre domænemodeller, og er kommet frem til at ovennævnte er bedst til at understøtte kravene til modularitet. 4.2.2. Klasseansvar En beskrivelse af alle klasser og deres ansvar kan findes i appendix I. Side 36 af 118

4.2.3. Hændelser I det eksisterende system er der identificeret et antal specielle hændelser som vi her vil beskrive. 4.2.3.1. Batchjob Nedenestående er et sequence diagram af hvordan den nuværende løsning virker ved kørsel af BatchJob. Illustration 9:Sekvensdiagram for batchjob i den eksisterende løsning Ved et batchjob efterspørger et fagsystem om opdatering af eksempelvis 40.000 personnumre. I den nuværende løsning af CPR Brokeren, som kun håndtere UUID's, skal fagsystemet mappe person numre til UUID's, dette gøres ved at sende en forespørgsel til Person Master (heri er der lavet et plugin, der kan tage en liste af person numre og mappe hele listen på en gang.) Herefter sendes forespørgselen til CPR Brokeren, det er op til fagsystemerne om alle person numre sendes på en gang eller de skal deles op. Normalt sendes 1.000 UUID's ad gangen. Hvis den lokale database ikke er opdateret hentes der ny data hos DPR og CPR Brokeren retunere dataen til fagsystemet. Standard i dag er at systemet ved batchjob ikke foretager DPR Viderestilling. Side 37 af 118

4.2.3.2. DPR viderestilling Nedenestående er et sequence diagram, der viser hvordan den nuværende løsning virker, ved aktivering af DPR viderestilling. DPR viderestilling er en service fra DPR, der giver en her og nu adgang til CPR kontoret med helt opdateret persondata. Det er op til fagsystemerne om DPR viderestilling er aktiveret. Kommunikation foregår på denne måde: Vi antager at det efterspurgte personnummer (PNR) ikke findes i CPR Brokerens lokale database, ej heller i DPR's database og fagsystemet har givet tilladelse til brug af DPR viderestilling: 1. Fagsystemet sender en forespørgsels om PNR til CPR Brokeren. 1.1. CPR Brokeren tjekker om PNR findes og er opdateret i dens lokale database. 1.2.CPR Brokeren spørger om PNR findes og er opdateret i DPR databasen. 2. DPR sender svar tilbage med en fejl besked. 2.1. CPR Brokeren giver signal til DPR viderestilling om opdatering af PNR i DPR's database. 3. DPR viderestilling sender forespørgsel til CPR kontoret om opdatering af PNR. 3.1. CPR Kontoret sender svar tilbage med persondata. Side 38 af 118

4. DPR viderestilling opdatere DPR's database. 5. Data sendes til CPR Brokeren. 5.1. CPR Brokeren sender svar til fagsystemet. Klientprogrammet (cpr brokeren eller fagsystemet) kommunikere med DPR Viderestilling ved at oprette en TCP forbindelse til DPR Viderestilling, og sende fastformateret tekststreng på 12 karakterer, der beskriver opgaven og søgningen der ønskes udført. Svaret der kommer retur fra DPR Viderestilling er ligeledes en fastfomateret tekststreng dog af variabel længde, hvor position 5 og fremefter enten er returdata eller en fejlmeddelelse. Side 39 af 118

4.3. Tekniske analyser I dette afsnit vil vi komme ind på de tekniske aspekter ved projektet. Herunder vil vi behandle algoritmer til validering, samt krav til kryptering. 4.3.1. Personnummervalidering Det er menneskeligt at fejle, og computere er nogle utaknemmelige bæster når det kommer til fejl i data. De behandler alle data ens uanset om det er dårlige data eller korrekte data. I projektet er der krav om at systemet skal kunne validere personnumre der kommer ind. Den primære motivation for dette krav er beskrevet i afsnittet om økonomi. Et batchjob der opdaterer data hvor alle datakolonner eksempelvis er skiftet en gang til højre. Det vil give mange falske personnumre i forespørgslen. Vi vil i dette afsnit belyse fordele og ulemper ved de forskellige validereingstyper, samt redegøre for de hastighedforskelle der er ved programmeringssprog og algoritmer. Til testformål vil vi lave en liste med alle personnumre der opfylder Modulus 11. Den indeholder knap 27 mill. personnumre. Til den fil har vi tilføjet godt 4 mill. falske personnumre. De falske personnumre har alle en valid månedangivelse men resten af cifrene er er valgt så de ikke opfylder Modulus 11. Vi har skrevet små testprogrammer alene med det formål at få nogle pålidelige tal for perfomance. For detaljerede informationer vedrørende de udførte tests, henvises til afsnit 7.1 på side 72. 4.3.1.1. Fejl i personnummer Da projektet omdrejningspunkt er standarder for dataudveksling, falder transmissionsfejl udenfor projektet at behandle, og vi vil i stedet fokusere på de fejl der kan opstå i dataleverancerne fra eksemplevis fagsystemerne. De typiske fejl vi vil opleve er ved batchhåndtering af personnumre hvor der kan ske en fejl i formatet af filen. Typisk et kolonneskift. Der er en minimal chance for at der kan optræde fejlindtastede personnumre, da de fleste fagsystemer validerer input. Et kolonneskift betyder at der i en linie bestående af fastformaterede linier er en kolonne der flytter sig enten til højre eller venstre. Eksempel vises herunder: Ciffer 0 1 2 3 4 5 6 7 8 9 10 11 12 Korrekte data X 2 1 1 0 6 2 5 6 2 8 X X Skiftede data X X 2 1 1 0 6 2 5 6 2 8 X Når det gælder datovalidering, har ciffer 1, 0 3 som acceptable værdier, ciffer 3 har 0 1 som acceptable værdier. Tager vi højde for at kolonnen kun skifter en gang til højre eller venstre, er Side 40 af 118

sandsynligheden for ikke at fange fejlen beregnet til: 2 1 2 = svarende til 8%. 5 5 25 4.3.1.2. Algoritmer Vi har identificeret to metoder for validering af personnumre; Modulus 11 og datovalidering. Modulus 11 virker ved at man tager de enkelte cifre personnummeret og ganger dem med nogle vægte. Summen af dette skal give en restværdi på 0 ved Modulus 11. Ciffer 1 2 3 4 5 6 7 8 9 10 Vægt 4 3 2 7 6 5 4 3 2 1 Et eksempel fra wikipedia er her en mand født 21. oktober 1862, så lad os går ud fra at han ikke længere er i live. Hans personnummer er 211062 5629. Indsættes det i tabellen ser det således ud: CPR 2 1 1 0 6 2 5 6 2 9 Vægt 4 3 2 7 6 5 4 3 2 1 Sum Modulus 11 af sum Sum 3 2 0 36 10 20 18 4 9 110 110 % 11 = 0 8 Tabel 4:Beregning af Modulus 11 Modulus 11 metoden anvendes stadig som primær valideringsform i mange it systemer. Som nævnt i indledningen er der nogle undtagelser for udvalgte datoer, hvor valideringsmetoden ikke kan anvendes. Modulus 11 er væsentlig mere beregningstung i forhold til datovalidering med ca. en faktor 3. Det er begrænset hvor mange effektiviseringer der kan gøres ved Modulus 11. Forskelle i ydelse ligger primært i det enkelte sprogs konvertering af datatyper og håndtering af store arrays. Selve algoritmen kan der ikke optimeres det store på. Side 41 af 118

Illustration 10:Flowchart Modulus 11 Som det ses af illustrationen brydes personnummeret op i de enkelte cifre, og der itereres igennem dem. Vi har undersøgt muligheden for at simplificere algoritmen ved at udføre regneoperationerne på en gang, men afvist det igen da det gør at vi ikke kan teste for legale værdier af personnummeret jævnfør nedenstående. Værdien af det enkelte ciffer i personnummeret beregnes ved at trække ASCII værdien af tegnet '0' fra ASCII værdien af cifferet. Eks. har karakteren 5 værdien 53 og karakteren 0 værdien 48. Trækkes 48 fra 53 fås den ønskede værdi 5 og beregningen kan forsætte. Hvis eksempelvis der har sneget sig et J med værdien 74 ind i personnummeret bliver den beregnede værdi 74 48=23 der ikke ligger indenfor det tilladte interval 0 9. Tabel 5: Beregning og kontrol af de enkelte cifre i personnummeret Side 42 af 118

Datovalideringen kan implementeres på flere måder. Vi er kommet frem til at hvis måneden er det første der kontrolleres, fanger vi den højeste andel af fejl jævnfør den tidligere beregning. Ved at gøre det som det første sparer vi på antallet af beregninger. I datovalideringen tager vi højde for skudår. Illustration 11:Flowchart datovalidering Algoritmen fortager samme beregning af de enkelte cifre, multiplicerer og addere dem til tocifrede positive heltal: ' 250472' ASCII [50, 53, 48, 52,55, 50] dag=(50 48) 10+(53 48)=25 måned=(48 48) 10+(52 48)=4 år=(55 48) 10+(50 48)=72 Tabel 6: Beregning af datoelementer for intervalcheck Side 43 af 118