Subject: Webservices med OIOXML

Størrelse: px
Starte visningen fra side:

Download "Subject: Webservices med OIOXML"

Transkript

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

2 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 Project supervisor: Leif Lodahl aps.dk) Date: Side 2 af 118

3 Indholdsfortegnelse 1. Indledning Det Centrale Personregister Problemer ved central registrering af borgere Fagsystemer Baggrund Formål med projektet Åbne standarder Opsummering Problemformulering Personnummeret Personnummerets opbygning Imigranter Midlertidige borgere Validering og Modulus Andre valideringsmetoder OIOXML OIOXML PART Unik nøgle UUID Fagsystemer Dataleverandører CPR Kontoret Baggrund Økonomi Risikoanalyse Milestone & tidsplan Afgrænsning Kravspecifikation Formål BATOFF Omgivelser Aktører i kontekst Brugerprofiler Funktionelle krav Use Cases Non funktionelle krav Requirement trace...31 Side 3 af 118

4 3.7. Opsummering af kravspecifikation Analyse Anvendelsesområdet Omgivelserne PEST(LE) SWOT Problemområdet Domænemodel Klasseansvar Hændelser Batchjob DPR viderestilling Tekniske analyser Personnummervalidering Fejl i personnummer Algoritmer Konklusion på personnummervalidering Webservice interface XML WSDL SOAP SOAP kommunikation Sikkerhed Kommunikation til validator Konklusion Kommunikation med dataprovider DPR Andre dataproviders Kommunikation med fagsystem PersonMaster Løsningen i dag Egen database eller bruge Dataprovider Sikkerhed og persondataloven Transport Opbevaring og adgang Opsummering af analysen Design Indledning Konsekvenser Kriterier for designet...52 Side 4 af 118

5 Forretningslogik DPR (Decentrale Person Register) Sikkerhed SOAP Sikkerhed OIOXML Database design Tabeldesign Design af views Systemtabeller Sikkerhed Abonnement / Subscription Batchjob Softwarearkitektur Klasse diagram Moduler WS OIOXML PART Eventbrokeren Dataprovider WS CPR2UUID Sikkerhed Flow charts DPR Viderestilling Abonnement event SignalHandler Opret abonnement WS CPR2UUID WS Person Konklusion på design Implementering Valg af sprog C Perl og Python C# Java Konklusion på valg af sprog Valg af platform Apache Tomcat Apache Axis Glassfish Konklusion på valg af platform...67 Side 5 af 118

6 6.3. Database MySQL PostgreSQL Konklusion på valg af database Proof of concept WebServicen Skemaer Test Test Personnummervalidering Modulus 11 og dato test Platform test Konklusion på personnummer validatoren Konklusion Den produktorienteret konklusion Den procesorienteret konklusion...74 Appendix A Folketingsvalget 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 Appendix L Kriterier for design Appendix M Kildetekst Appendix N OIOXML PART ny version Appendix O Dokumentreferencer Appendix P Personer der har bidraget til projektet Side 6 af 118

7 Appendix Q Litteraturliste Side 7 af 118

8 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 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 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 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

9 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 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 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 ( ) 2 Se afsnit om OIOXML på side 16 Side 9 af 118

10 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 aps.dk/ ( ) Side 10 af 118

11 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. ( ) 5 Det Centrale Virksomheds Register. ( ) Side 11 af 118

12 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. 4 ( ) Side 12 af 118

13 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. ( ) Side 13 af 118

14 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 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

15 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 og til til 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 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. nummer ( ) Side 15 af 118

16 Midlertidige borgere Borgere der tager midlertidig ophold i Danmark, eks. studerende eller udstationerede medarbejdere tildeles også et personnummer 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 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 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 OIOXML OIOXML er en kombineret forkortelse af Offentlig Information Online extensible Markup Language. På 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

17 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 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 ( ) 10 arkitektur og standarder/standardisering/abne standarder/aftale mellem regeringen kl og danske regioner om abne standarder for software ( ) Side 17 af 118

18 Illustration 4:Begrebsmodel fra It og Telestyrelsens vejledning for OIOXML Som det ses udspringer ideen til OIOXML primært af et behov for ESDH 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

19 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 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 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 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 Fagsystemer De fleste af en kommues it systemer er meget fagspecifikke. Det er systemer der specifikt Side 19 af 118

20 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 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å 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

21 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 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 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 Ø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

22 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 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 ,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 Der resterer så en post der hedder Andre ordinære driftsomkostninger på DKK 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 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 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 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

23 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

24 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 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 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

25 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

26 3.3. Omgivelser I dette afsnit beskriver vi systemets omgivelser i detaljer 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

27 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 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

28 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

29 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

30 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 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

31 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 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 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

32 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 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 Men her vil vi forholde os til de omgivelser der var gældende ved projektstart. Side 32 af 118

33 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 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

34 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

35 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

36 4.2. Problemområdet Dette afsnit beskæftiger sig med at analysere projektets problemområde 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 Klasseansvar En beskrivelse af alle klasser og deres ansvar kan findes i appendix I. Side 36 af 118

37 Hændelser I det eksisterende system er der identificeret et antal specielle hændelser som vi her vil beskrive 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 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 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

38 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 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 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 CPR Kontoret sender svar tilbage med persondata. Side 38 af 118

39 4. DPR viderestilling opdatere DPR's database. 5. Data sendes til CPR Brokeren 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

40 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 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 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 Korrekte data X X X Skiftede data X X 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

41 sandsynligheden for ikke at fange fejlen beregnet til: = svarende til 8% 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 Vægt 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 Indsættes det i tabellen ser det således ud: CPR Vægt Sum Modulus 11 af sum Sum % 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

42 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

43 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: ' ' 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

Minikonference om Sag og Dokumentstandarder 15. juni 2011, Odense

Minikonference om Sag og Dokumentstandarder 15. juni 2011, Odense CPR Broker version 2.0 Minikonference om Sag og Dokumentstandarder 15. juni 2011, Odense Steen Deth, Chefarkitekt sde@gentofte.dk CPR data hvor svært (og interessant) kan det være? Kommune Borgerservice

Læs mere

Danske Kommuner, september 2012

Danske Kommuner, september 2012 I mange år har private IT-leverandører typisk KMD og CSC tjent penge, hver gang en medarbejder i en kommune laver et opslag i eksterne datakilder, eksempelvis CPR-registeret i Indenrigsministeriet. Det

Læs mere

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 Holsteinsgade 63 2100 København Ø Att. Palle Aagaard FESD Grænseflade til CMS-løsninger, høringssvar fra Gentofte Kommune Gentofte Kommune har med

Læs mere

CPR BROKER Whitepaper

CPR BROKER Whitepaper CPR BROKER Whitepaper Copyright 2013 I mange år har private it-leverandører typisk KMD og CSC tjent penge, hver gang en medarbejder i en kommune laver et opslag i eksterne datakilder som for eksempel CPR-registreret

Læs mere

Tempus Serva. - er NEM IT til alle virksomheder

Tempus Serva. - er NEM IT til alle virksomheder TM - er NEM IT til alle virksomheder Introduktion Virksomheder bør ikke stræbe efter de alt omfattende visioner og tro, at de med analyse og projektmodeller kan udvikle den optimale digitale løsning. I

Læs mere

OI OXML som obligatorisk, åben standard. - uddybende vejledning. 1 Om dette dokument. 2 Baggrund. 2.1 Datastandardisering

OI OXML som obligatorisk, åben standard. - uddybende vejledning. 1 Om dette dokument. 2 Baggrund. 2.1 Datastandardisering OI OXML som obligatorisk, åben standard - uddybende vejledning 1 Om dette dokument Dette dokument beskriver anbefalet praksis for at anvende OIOXML som åben, obligatorisk standard. IT- og Telestyrelsen

Læs mere

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har

Læs mere

Scope dokument for Advisservice

Scope dokument for Advisservice 18. marts 2013 AHI Scope dokument for Advisservice Indhold 1. Advisservice... 2 2. Advis håndtering i KMD Sag... 2 3. Hændelse og Advis... 3 4. Advis løsningsmodel... 4 5. Abonnementsopsætning... 5 6.

Læs mere

XML webservice for pensionsordninger. Version 1.0 Draft A

XML webservice for pensionsordninger. Version 1.0 Draft A XML webservice for pensionsordninger Version 1.0 Draft A Dokumentoplysninger Titel: Projekt: Webservice for pensionsordninger EDI kontorets branchekoordinerede dataudveksling Forfatter: Bidragsydere til

Læs mere

Projekt DAF. Digitale annonceordrer og fakturaer Funktionel kravspecifikation Infrastruktur

Projekt DAF. Digitale annonceordrer og fakturaer Funktionel kravspecifikation Infrastruktur IT & Operational Developement Projekt DAF Digitale annonceordrer og fakturaer Funktionel kravspecifikation Infrastruktur Politiken Jyllandsposten Berlingske Tidende OMD Carat Mediaedge:CIA Mediacom Initiative

Læs mere

WHITEPAPER DokumentBroker

WHITEPAPER DokumentBroker WHITEPAPER DokumentBroker Copyright 2013 DokumentBrokeren er en selvstændig arkitekturkomponent, som uafhængigt af forretningsapplikation og kontorpakke, genererer dokumenter af forskellige typer og formater,

Læs mere

Digital post Snitflader Bilag A2 - REST Register Version 6.3

Digital post Snitflader Bilag A2 - REST Register Version 6.3 Digital post Snitflader Bilag A2 - REST Register Version 6.3 1 Indholdsfortegnelse A2.1 INTRODUKTION 4 A2.1.1 HENVISNINGER 4 A2.2 OVERSIGT OVER FUNKTIONSOMRÅDE 5 A2.2.1 OPRET / HENT OPLYSNINGER OM SLUTBRUGER

Læs mere

NemHandel i cloud - sikkerhedsmæssige overvejelser. Helle Schade-Sørensen IT og Telestyrelsen

NemHandel i cloud - sikkerhedsmæssige overvejelser. Helle Schade-Sørensen IT og Telestyrelsen NemHandel i cloud - sikkerhedsmæssige overvejelser Helle Schade-Sørensen IT og Telestyrelsen Agenda Lidt om NemHandel Rationalet for valg af cloud Overvejelser vedr. sikkerhed Løsning og erfaringer indtil

Læs mere

Markedsinfo. Microsoft Dynamics NAV 2009 SP1 Klassisk. Side 1 Copyright: Naddon version 201009

Markedsinfo. Microsoft Dynamics NAV 2009 SP1 Klassisk. Side 1 Copyright: Naddon version 201009 Markedsinfo Microsoft Dynamics NAV 2009 SP1 Klassisk Side 1 Microsoft Dynamics NAV 2009 SP1 Rollebaseret Indholdet i dette dokument må på ingen måde gengives helt eller delvist hverken på tryk eller i

Læs mere

Markedsinfo. Microsoft Dynamics NAV 2009 SP1 Rollebaseret. Side 1 Copyright: Naddon version 201009

Markedsinfo. Microsoft Dynamics NAV 2009 SP1 Rollebaseret. Side 1 Copyright: Naddon version 201009 Markedsinfo Microsoft Dynamics NAV 2009 SP1 Rollebaseret Side 1 Microsoft Dynamics NAV 2009 SP1 Rollebaseret Indholdet i dette dokument må på ingen måde gengives helt eller delvist hverken på tryk eller

Læs mere

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel 02. december 2014 Indhold INDHOLD... 1 INDLEDNING... 2 STANDARDER... 4 OIOUBL e-handelsstandard... 4 OIORASP - transportprotokol... 5 BETINGELSER FOR ANVENDELSE AF

Læs mere

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB Det er Web Services, der rejser sig fra støvet efter Dot Com boblens brag. INTRODUKTION Dette dokument beskriver forslag til fire moduler, hvis formål

Læs mere

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER

ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER ANALYSE AF SIKKERHEDSSTANDARDER OG -LØSNINGER Kommunernes it-arkitekturråd 8. maj 2014 AGENDA Væsentligste observationer og konklusioner Relevans for kommuner STRATEGI OG ARKITEKTUR Analysen giver et bud

Læs mere

Personnummeret i CPR-systemet

Personnummeret i CPR-systemet CPR-KONTORET Dato: 1. juli 2008 Sagsbeh.: jøm/ Personnummeret i CPR-systemet Holmens Kanal 22 Telefon: +45 72 26 97 35 Internet: cpr@cpr.dk DK - 1060 København K Telefax: +45 72 26 97 42 Hjemmeside: http://www.cpr.dk

Læs mere

Strategi 2013-2017 Danmarks Miljøportal

Strategi 2013-2017 Danmarks Miljøportal Strategi 2013-2017 Danmarks Miljøportal Introduktion Danmarks Miljøportal (DMP) har ansvaret for en digital infrastruktur på miljøområdet, der gør det muligt for myndigheder og offentlighed at få nem adgang

Læs mere

Faktaark for DAR 1.0

Faktaark for DAR 1.0 1. december 2014 HEGK Faktaark for DAR 1.0 Overordnet beskrivelse og baggrund for DAR 1.0 Indholdsfortegnelse 1. Indledning... 2 2. Baggrund og formål... 3 DAR i dag... 3 Fremtidige DAR 1.0... 4 3. Teknik...

Læs mere

Guide til kravspecifikation

Guide til kravspecifikation Side 1 af 10 10. november 2008 Guide til kravspecifikation Version 1.0. Denne guide indeholder en række råd til brug i kravspecifikationer for IT systemer, der skal anvende NemLog-in løsningen. Hensigten

Læs mere

Dygtig.NET / C# udvikler med stor erfaring fra både offentlige organisationer og private virksomheder.

Dygtig.NET / C# udvikler med stor erfaring fra både offentlige organisationer og private virksomheder. .NET UDVIKLER NATIONALITET: DANSK PROFIL Dygtig.NET / C# udvikler med stor erfaring fra både offentlige organisationer og private virksomheder. Stor erfaring omkring databasedesign, datahåndtering og MS

Læs mere

OIOXML dokumentationsguide Person

OIOXML dokumentationsguide Person OIOXML dokumentationsguide Person OIOXML dokumentationsguide Person . Ejerskab Indenrigs og Sundhedsministeriets CPR-kontor i medfør af Bekendtgørelse af lov om Det Centrale Personregister, jf. lov nr.

Læs mere

FKG datamodellen Version 2.3.1 ArcGIS integration Sidste revisionsdato: 23. maj 2014

FKG datamodellen Version 2.3.1 ArcGIS integration Sidste revisionsdato: 23. maj 2014 FKG datamodellen Version 2.3.1 ArcGIS integration #1 FKG Fælleskommunale Geodatasamarbejde FKG datamodellen Version 2.3.1 ArcGIS integration Sidste revisionsdato: 23. maj 2014 1 FKG datamodellen Version

Læs mere

15. oktober. Maskine Udlejning. Jacob Weng, Jeppe Boese og Mads Anthony. Udlejningsvirksomhed. Roskilde Tekniske Gymnasium 3.4

15. oktober. Maskine Udlejning. Jacob Weng, Jeppe Boese og Mads Anthony. Udlejningsvirksomhed. Roskilde Tekniske Gymnasium 3.4 Maskine Udlejning 15. oktober 2010 Jacob Weng, Jeppe Boese og Mads Anthony Roskilde Tekniske Gymnasium Udlejningsvirksomhed 3.4 Indholdsfortegnelse Problemformulering:... 2 Planlægning:... 2 Analyse af

Læs mere

Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU)

Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU) Foranalyse Projekt: PDM-kerne Projektleder : Jacob-Steen Madsen (jsm), Syddansk Universitet (SDU) Projektdeltagere: 1. Indledning og baggrund Mogens Sandfær (MS), Danmarks Tekniske Universitet (DTU) Jørgen

Læs mere

Kommentar fra KMS til Specifikation af Serviceinterface for Person

Kommentar fra KMS til Specifikation af Serviceinterface for Person Kommentar fra KMS til Specifikation af Serviceinterface for Person Organisation Side Kapitel Afsnit/figur/tabel /note Type af kommentar (generel (G), redaktionel (R), teknisk (T)) Kommentar KMS-1 G Godt

Læs mere

Anvendelse af dobbelthistorik i GD2

Anvendelse af dobbelthistorik i GD2 Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi GD2 - Adresseprogrammet Anvendelse af dobbelthistorik i GD2 Implementerings regler og eksempler på dobbelthistorik MBBL- REF: Version:

Læs mere

Løsningsbeskrivelse. Den fælleskommunale Serviceplatform

Løsningsbeskrivelse. Den fælleskommunale Serviceplatform Løsningsbeskrivelse Den fælleskommunale Serviceplatform Januar 2014 1 Indhold 2 Serviceplatformen... 2 3 Hjemmesiden www.serviceplatformen.dk... 3 3.1 Administrationsmodul... 4 3.2 Servicekatalog... 4

Læs mere

ectrl vejledning ectrl Opsætning af elektronisk rering

ectrl vejledning ectrl Opsætning af elektronisk rering ectrl vejledning ectrl Opsætning af elektronisk rering Indholdsfortegnelse Opsætning 3 Debitoropsætning 4 Opsætning af afsendelsesmodulet. 6 Check af anden opsætning. 11 Elektronisk fakturering. 13 Opsætning

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

Balancen mellem de interne nødvendigheder og de eksterne påvirkninger reguleres i kommunens it-strategi som præsenteres herunder.

Balancen mellem de interne nødvendigheder og de eksterne påvirkninger reguleres i kommunens it-strategi som præsenteres herunder. It-strategi 1.0 Indledning Flere og flere forretningsprocesser i kommunerne stiller krav til it-understøttelse, og der er store forventninger til at den offentlige sektor hænger sammen inden for it-området.

Læs mere

Konference om Cloud Computing 18. maj 2011. Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD

Konference om Cloud Computing 18. maj 2011. Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD Konference om Cloud Computing 18. maj 2011 Proof of Concept for transition til Cloud Lars Ravndrup Thomsen, Solutions Architect, KMD POC, hvad er det? En søgning på internettet viser, at de fleste sites

Læs mere

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase Indholdsfortegnelse 5. Administrationsdatabase... 2 5.1 Metadata... 2 5.2 Administrationsdata... 3 5.2.1 Indstillingsmuligheder... 3 5.2.2 Webside... 4 5.2.3 Klikafgift (Udgået)... 4 5.2.4 Modtageboks...

Læs mere

Kulturministeriets it-arkitekturpolitik

Kulturministeriets it-arkitekturpolitik Kulturministeriets Kulturministeriets Januar 2012 Udgivet af Kulturministeriet Udarbejdet af Kulturstyrelsen H.C. Andersens Boulevard 2 1553 København V www.kulturstyrelsen.dk post@kulturstyrelsen.dk Kulturministeriets

Læs mere

DBC Strategi 2017. DBC har nye udfordringer i de kommende år

DBC Strategi 2017. DBC har nye udfordringer i de kommende år DBC Strategi 2017 DBC har nye udfordringer i de kommende år Digital transition er stadig det grundvilkår, der bestemmer DBC s strategi. Også i de kommende år. Med alt hvad det indebærer med teknologi,

Læs mere

Indlæsning af tilskud fra UVM

Indlæsning af tilskud fra UVM Indlæsning af tilskud fra UVM Brugervejledning version 1.0 Side 1 Indholdsfortegnelse Indledning... 3 Download bogføringskladde fra brevportalen... 3 Gem regneark på din arbejdsplads... 3 Bearbejdning

Læs mere

FORSLAG TIL MASSEAFSENDELSE

FORSLAG TIL MASSEAFSENDELSE FORSLAG TIL MASSEAFSENDELSE Digital Post og Fjernprint 2015-03-11 Dagsorden 1. Velkomst 2. Nuværende OIO-rest 3. Udfordringer 4. Afrunding Nuværende OIO-REST løsning Digital post De nuværende Digital Post

Læs mere

Introduktion til Støttesystem Organisation

Introduktion til Støttesystem Organisation Introduktion til Støttesystem Organisation 1. Om dokumentet Dette dokument formidler et overblik over Støttesystemet Organisation i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse

Læs mere

Kort om CoinDB (Mønt- og seddelsamling):

Kort om CoinDB (Mønt- og seddelsamling): Kom godt i gang med CoinDB programmet fra PetriSoft (Holder styr på din Mønt- seddel- eller frimærkesamling) Kort om CoinDB (Mønt- og seddelsamling): CoinDB er et Windows program, der anvendes af mønt-

Læs mere

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet. MOX og APOS2 Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.

Læs mere

Aktstykke nr. 28 Folketinget 2009-10. Afgjort den 19. november 2009. Økonomi- og Erhvervsministeriet. København, den 9. november 2009.

Aktstykke nr. 28 Folketinget 2009-10. Afgjort den 19. november 2009. Økonomi- og Erhvervsministeriet. København, den 9. november 2009. Aktstykke nr. 28 Folketinget 2009-10 Afgjort den 19. november 2009 28 Økonomi- og Erhvervsministeriet. København, den 9. november 2009. a. Økonomi- og Erhvervsministeriet anmoder om Finansudvalgets tilslutning

Læs mere

Navision Stat 7.0. CVR Integration. Overblik. Side 1 af 15. 30. april 2015 ØS/ØSY/MAG

Navision Stat 7.0. CVR Integration. Overblik. Side 1 af 15. 30. april 2015 ØS/ØSY/MAG Side 1 af 15 Navision Stat 7.0 30. april 2015 ØS/ØSY/MAG CVR Integration Overblik Introduktion I denne vejledning kan du læse om, hvordan du validerer dine debitorers og kreditorers data op imod Det Centrale

Læs mere

Kom godt igang med Inventar registrering

Kom godt igang med Inventar registrering Kom godt igang med Inventar registrering (InventoryDB) (Med stregkodesupport) programmet fra PetriSoft Introduktion... 1 Inventar registrering... 2 Værktøjsudleje... 3 Service database til reperationer

Læs mere

Guideline. EAN-systemet

Guideline. EAN-systemet Guideline Hammershusgade 17 DK-2100 København Ø Tel: 39 27 85 27 Fax: 39 27 85 10 www.ean.dk for anvendelsen af EAN-systemet til entydig identifikation af målepunkter i EL-forsyningssektoren samt EAN-13

Læs mere

Fælles Bibliotekssystem

Fælles Bibliotekssystem Fælles Bibliotekssystem Møder med leverandører af 3. partssystemer, der integrerer til FBS Afholdt d. 22. og 23. oktober 2014 Spørgsmål til organisation, rammeplan og tilslutningsforløb: 1. Hvem leverer

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 (Draft) Side 1 af 9 Så ligger udkastet klar til den kommende version af ISO 9001. Der er sket en række strukturelle ændringer i form af standardens opbygning ligesom kravene er blevet yderligere

Læs mere

PS102: Den menneskelige faktor og patientsikkerhed

PS102: Den menneskelige faktor og patientsikkerhed IHI Open School www.ihi.org/patientsikkerhed PS102: Den menneskelige faktor og patientsikkerhed (1 time) Dette modul er en introduktion til emnet "menneskelige faktorer": Hvordan indarbejdes viden om menneskelig

Læs mere

Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up

Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up Accelerace har gennem de seneste 7 år arbejdet tæt sammen med mere end 250 af de mest lovende

Læs mere

KRAVSPECIFIKATION for underretningsstatistik

KRAVSPECIFIKATION for underretningsstatistik Ankestyrelsen Data og Analyse Den 4. marts 2014 KRAVSPECIFIKATION for underretningsstatistik Kontakt: Jesper Nyholm, Statistiksektionen, jny@ast.dk, tlf. 61 89 75 07 1 af 12 1. Indledning I denne kravspecifikation

Læs mere

LUDUS WEB. Installations- og konfigurations-vejledning. Den 7. april 2009. J.nr.: 4004 V0624 09

LUDUS WEB. Installations- og konfigurations-vejledning. Den 7. april 2009. J.nr.: 4004 V0624 09 LUDUS WEB Installations- og konfigurations-vejledning Den 7. april 2009 J.nr.: 4004 V0624 09 CSC Scandihealth A/S, P.O. Pedersens Vej 2, DK-8200 Århus N Tlf. +45 3614 4000, fax +45 3614 7324, www.scandihealth.dk,

Læs mere

Introduktion til Støttesystemet Beskedfordeler

Introduktion til Støttesystemet Beskedfordeler Introduktion til Støttesystemet 1. Om dokumentet Dette dokument formidler et overblik over brugen af den fælleskommunale. Formålet er at give læseren en forståelse af, de væsentligste begreber, forudsætninger

Læs mere

Håndbog Til CPR services. Bilag 8 GCTP-standard m.m. CPR-kontoret

Håndbog Til CPR services. Bilag 8 GCTP-standard m.m. CPR-kontoret Håndbog Til CPR services Bilag 8 GCTP-standard m.m. CPR-kontoret Datavej 20, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 82 51 10. Hjemmeside: www.cpr.dk Side 2 af 14 Indholdsfortegnelse

Læs mere

EffEKTIvISER hverdagen AMPAREX brugervenligt OG InTEGRERET SOfTWARE TIl OPTIKERE Kunde håndtering KASSe (POS) MArKedSføring

EffEKTIvISER hverdagen AMPAREX brugervenligt OG InTEGRERET SOfTWARE TIl OPTIKERE Kunde håndtering KASSe (POS) MArKedSføring Effektiviser hverdagen AMPAREX brugervenligt og integreret software til optikere dtering Kunde hån S) KASSE (PO øring Markedsf DU BEHØVER IKKE VÆRE PÅ KONTORET FOR AT SERVICERE DINE KUNDER AMPAREX s unikke

Læs mere

7. Forslag om optagelse af standarden OVF i OIO Kataloget (B)

7. Forslag om optagelse af standarden OVF i OIO Kataloget (B) Et emne, som allerede har affødt en del debat, er den obligatoriske brug af elektronisk kommuni kation, som blandt andet sidestiller en e mailhenvendelse med en henvendelse modtaget med pa pirpost, hvilket

Læs mere

OS2 Opgavefordeler. Løsningsbeskrivelse Version 2. Udarbejdet af Miracle A/S Simon Møgelvang Bang smb@miracle.dk

OS2 Opgavefordeler. Løsningsbeskrivelse Version 2. Udarbejdet af Miracle A/S Simon Møgelvang Bang smb@miracle.dk OS2 Opgavefordeler Løsningsbeskrivelse Version 2 Udarbejdet af Miracle A/S Simon Møgelvang Bang smb@miracle.dk 15/2/2015 Løsningsbeskrivelse for OS2 Opgavefordeler 1. Introduktion... 3 2. Kontekst... 3

Læs mere

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav.

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav. Miniprojekt2011 Projektbeskrivelse Der skal fremstilles en lille java application på PC, hvor brugeren kan foretage interaktioner med en simpel database på disken via et grafisk brugerinterface. Formålet

Læs mere

ectrl vejledning ectrl Opsætning af elektronisk fakturering

ectrl vejledning ectrl Opsætning af elektronisk fakturering ectrl vejledning ectrl Opsætning af elektronisk fakturering Indholdsfortegnelse Opsætning 3 Debitoropsætning 4 Opsætning af afsendelsesmodulet 6 Check af anden opsætning 11 Elektronisk fakturering 13 Opsætning

Læs mere

Solrød Kommunes supplerende kravspecifikation, som uddyber og præciserer kraven

Solrød Kommunes supplerende kravspecifikation, som uddyber og præciserer kraven Solrød Kommunes supplerende kravspecifikation, som uddyber og præciserer kraven Krav Beskrivelse Prioritet Krav opfyldt -krav til integration med fagsystemer 3.1.1 3.1.2 3.1.3 3.1.4 Ejendoms- og Miljødatabasen,

Læs mere

Dagens program. Domæner. change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog. Hvad er widgets.

Dagens program. Domæner. change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog. Hvad er widgets. Dagens program Har alle fået? Har nogen betalt for meget? Hav jeres koder klar Domæner change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog Hvad er widgets Hvad er

Læs mere

24-03-2009. Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S

24-03-2009. Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S 24-03-2009 Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S Problemstilling ved DBK integration i BIM Software Domæner og aspekter Det domæne, der primært

Læs mere

Microsoft Dynamics AX Scanfak. Fall

Microsoft Dynamics AX Scanfak. Fall 1 Microsoft Dynamics AX Scanfak Fall 16 - faktura management & workflow Med faktura management & workflow systemet Scanfak fra GITS kan du afhjælpe de tunge administrative rutiner ved håndtering af kreditor

Læs mere

GeoEnviron Web-løsninger

GeoEnviron Web-løsninger 2012 Troels Kreipke 01-01-2012 Indhold Generelt... 3 Web-løsninger... 3 XML-firewall... 4 GeoEnviron_WebService... 4 Installation af web-løsninger uden brug af GeoEnviron_WebService... 5 GeoEnviron_WebService...

Læs mere

Registre og kliniske kvalitetsdatabaser - en introduktion. Lau Caspar Thygesen Lektor, ph.d.

Registre og kliniske kvalitetsdatabaser - en introduktion. Lau Caspar Thygesen Lektor, ph.d. Registre og kliniske kvalitetsdatabaser - en introduktion Lau Caspar Thygesen Lektor, ph.d. Introduktion Stigende brug af registre Infrastruktur forbedret Mange forskningsspørgsmål kan besvares hurtigt

Læs mere

MØDE OM INTEGRATION GENNEM ØKONOMI I RAMMEARKITEKTUREN 27/8-2015

MØDE OM INTEGRATION GENNEM ØKONOMI I RAMMEARKITEKTUREN 27/8-2015 MØDE OM INTEGRATION GENNEM ØKONOMI I RAMMEARKITEKTUREN 27/8-2015 Introduktion ERP-leverandører har været med i afklarings- og specificeringsforløb siden 2013. Der vil være gentagelser og opsummeringer

Læs mere

Adgang til eksterne referencedata, integration til egne systemer og søgning i egne kundedata som en samlet Master Data Management (MDM) løsning.

Adgang til eksterne referencedata, integration til egne systemer og søgning i egne kundedata som en samlet Master Data Management (MDM) løsning. idq MDM Edition Adgang til eksterne referencedata, integration til egne systemer og søgning i egne kundedata som en samlet Master Data Management (MDM) løsning. Hvad er Master Data Management? Master Data

Læs mere

Dokumentationsguide for dansk Bankkonto

Dokumentationsguide for dansk Bankkonto Dokumentationsguide for dansk Bankkonto OIOXML dokumentationsguide for dansk Bankkonto Denne guide er udarbejdet af Peter Neergaard Jensen, IT- og Telestyrelsen, i regi af Kernekomponentgruppen under XML-projektet

Læs mere

GIS indlæsning af kreditorer og betalingsform. Brugervejledning 1.0

GIS indlæsning af kreditorer og betalingsform. Brugervejledning 1.0 GIS indlæsning af kreditorer og betalingsform Brugervejledning 1.0 Indhold 1 Indledning... 5 2 Opsætning af GIS grænseflade til kreditor indlæsning... 5 2.1 Oprettelse af en datastrøm... 7 2.2 Filsystem...

Læs mere

Skalerbar CRM løsning

Skalerbar CRM løsning Skalerbar CRM løsning Cubizz eksperter i effektiv afsætning! Cubizz Mission Vores mission er at hjælpe vores kunder med at øge omsætningen, men til en lavere omkostning pr. omsætningskrone dvs. mere effektivt

Læs mere

Oktober 2013 HLG/XIGA. Opstartsvejledning ATS Engros 1/12

Oktober 2013 HLG/XIGA. Opstartsvejledning ATS Engros 1/12 Oktober 2013 HLG/XIGA Opstartsvejledning ATS Engros 1/12 1. ATS Engros vejledning for aktører Formålet med dette dokument er at beskrive, hvordan du kommer i gang med at anvende ATS til test af certifikat

Læs mere

It-sikkerhedstekst ST5

It-sikkerhedstekst ST5 It-sikkerhedstekst ST5 Identificering af en fysisk person med henblik på udstedelse af faktorer til et personligt login Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST5 Version

Læs mere

Dm071 / Dm072 - Obligatorisk projekt 3: Design af model

Dm071 / Dm072 - Obligatorisk projekt 3: Design af model Dm071 / Dm072 - Obligatorisk projekt 3: Design af model Fag: Projektet omhandler emner fra fagene Software Design og Software Konstruktion. Formål: Formålet med projektet er at give dig mulighed for sammen

Læs mere

Microsoft Dynamics. Fall. 16 AX Scanfak

Microsoft Dynamics. Fall. 16 AX Scanfak 1 Microsoft Dynamics Fall 16 AX Scanfak 1 2 - faktura management & workflow Med faktura management & workflow systemet Scanfak fra GITS kan du afhjælpe de tunge og kedelige administrative rutiner ved håndtering

Læs mere

Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7. OIO Serviceprincipper

Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7. OIO Serviceprincipper Bilag 12 - Fælles arkitekturramme for GD1-GD2-GD7 OIO Serviceprincipper Version: 1.1 Status: i høring i PF for GD1 og GD2 Oprettet: 4. juni 2014 Dato: 4. juni 2014 Dokument historie Version Dato Beskrivelse

Læs mere

Integration mellem webcrm og NN Markedsdata

Integration mellem webcrm og NN Markedsdata Integration mellem webcrm og NN Markedsdata I samarbejde med NN Markedsdata (NNM) tilbyder webcrm følgende 3 tillægsmoduler, der giver mulighed for direkte integration mellem webcrm og NN Markedsdatabasen,

Læs mere

DaTelTek ApS ich 4 SpAPI Telenor Serviceprovider API

DaTelTek ApS ich 4 SpAPI Telenor Serviceprovider API DaTelTek ApS ich 4 SpAPI Telenor Serviceprovider API Release 4.0.0 DaTelTek ApS Birkevej 4 DK-4640 Faxe Denmark CVR: 31 06 05 59 +45 32 22 22 22 www.dateltek.dk info@dateltek.dk Indholdsfortegnelse Ændring

Læs mere

Projekt: VAX NemHandel 4.0

Projekt: VAX NemHandel 4.0 Ejer: mysupply ApS Projekt: VAX NemHandel 4.0 Emne: Dette dokument beskriver de tekniske specifikationer for VAX NemHandel 4.0 samt krav til miljøet, herunder hardware og software, hvori VAX NemHandel

Læs mere

LaserNet v6.6 Release Nyhedsbrev

LaserNet v6.6 Release Nyhedsbrev LaserNet v6.6 Release Nyhedsbrev NY Input Management-Løsning! Indhold: LaserNet v6.6 LaserNet Webinars NY LaserNet Input Management-løsning Nyt Produkt: LaserNet Client Nye Features & Functions Ny medarbejder

Læs mere

e-tl System til System kommunikationstest

e-tl System til System kommunikationstest e-tl System til System kommunikationstest Version Dato Forfatter Kommentarer Distribueret til 0.5 22/10-07 Anders Bohn Jespersen Udgave til workshop 24/10. 0.6 24/10-07 HGK Opdateret med beskeder. 0.9

Læs mere

Kort om Umbrella. Den 6. oktober 2009. 1. Umbrella

Kort om Umbrella. Den 6. oktober 2009. 1. Umbrella Den 6. oktober 2009 Kort om Umbrella 1. Umbrella Umbrella er et fælleskommunalt samarbejde om udvikling af digitale selvbetjeningsløsninger. De udviklede løsninger skal sikre en videreudvikling af borgerservicen

Læs mere

TEKNISKE FORHOLD VEDR. ADGANG TIL VP.ONLINE. Brugervejledning

TEKNISKE FORHOLD VEDR. ADGANG TIL VP.ONLINE. Brugervejledning TEKNISKE FORHOLD VEDR. ADGANG TIL VP.ONLINE vp.online 2011 01-10-2011 Indholdsfortegnelse 1 PROBLEMER MED AT SE VP.ONLINE... 3 2 BROWSER KONFIGURATION... 6 3 SKRIVEADGANG TIL DREV... 7 4 SESSION TIMEOUT

Læs mere

Tilslutning til ecomone Basis (OIO Faktura)

Tilslutning til ecomone Basis (OIO Faktura) Tilslutning til ecomone Basis (OIO Faktura) 1. november 2009, Version 1.1 1. POST DANMARKS ECOMONE BASIS (OIO FAKTURA)... 3 1.1 BEGREBER... 3 2 KANALER... 3 3 MODEL FOR DATAUDVEKSLING... 4 4 KOMMUNIKATION...

Læs mere

FACILIA a-kasse seminar 22. september 2010. Velkomst. Keith Fobian DANA

FACILIA a-kasse seminar 22. september 2010. Velkomst. Keith Fobian DANA FACILIA a-kasse seminar 22. september 2010 Velkomst Keith Fobian DANA 1 FACILIA a-kasse seminar 22.september 2010 - program Tidsplan Emne Init. 12.00 12.30 Sandwich 12.30 12.35 Velkomst KF 12.35 12.50

Læs mere

FSFIs lynguide til DFRs elektronisk bevissystem

FSFIs lynguide til DFRs elektronisk bevissystem FSFIs lynguide til DFRs elektronisk bevissystem Dette er en kort guide i anvendelsen af Dansk Førstehjælpsråd elektroniske bevissystem. Guiden viser og forklarer hvordan du som instruktør og medlem af

Læs mere

Vejledning til leverandører ifm. CPR-abonnement

Vejledning til leverandører ifm. CPR-abonnement Vejledning til leverandører ifm. CPR-abonnement Dette notat beskriver de forhold som man som leverandør og kommune skal være opmærksom på når man ønsker at modtage CPR-data i abonnement fra Serviceplatformen.

Læs mere

Kravspecification IdP løsning

Kravspecification IdP løsning Kravspecification IdP løsning Resume IT-Forsyningen, som varetager IT-drift for Ballerup, Egedal og Furesø Kommuner, ønsker at anskaffe en IdP/Føderationsserverløsning, der kan understøtte en række forretningsmæssige

Læs mere

Rejsekort A/S idekonkurence Glemt check ud

Rejsekort A/S idekonkurence Glemt check ud Rejsekort A/S idekonkurence Glemt check ud 9. marts 2015 1 Indhold 1 Introduktion 4 1.1 Problembeskrivelse........................ 4 1.2 Rapportens opbygning...................... 4 2 Ordliste 5 3 Løsning

Læs mere

Internet Information Services (IIS)

Internet Information Services (IIS) Internet Information Services (IIS) Casper Simonsen & Yulia Sadovskaya H1we080113 06-11-2013 Indholdsfortegnelse Problemformulering... 2 Hvorfor:... 2 Hvad:... 2 Hvordan:... 2 Problembehandling... 3 Introduktion...

Læs mere

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK Mission Critical o Projekt Information management o Processer, metoder & værktøjer. Side 1 of 11 Projekt information Projekt information management inkluderer alle de processer, som er nødvendige for at

Læs mere

Digital Signatur OCES en fælles offentlig certifikat-standard

Digital Signatur OCES en fælles offentlig certifikat-standard Digital Signatur OCES en fælles offentlig certifikat-standard IT- og Telestyrelsen December 2002 Resumé Ministeriet for Videnskab, Teknologi og Udvikling har udarbejdet en ny fælles offentlig standard

Læs mere

Notat ang. visning af dagsordener og referater på hjemmesiden ved skift til SBSYS esdh system.

Notat ang. visning af dagsordener og referater på hjemmesiden ved skift til SBSYS esdh system. Notat ang. visning af dagsordener og referater på hjemmesiden ved skift til SBSYS esdh system. I dette notat gøres rede for Hvordan visning af dagsordener og referater teknisk set kører i dag, Valg af

Læs mere

Få mere succes med email marketing Velkomst flow og drop-basket flow mm. MailPlatform.dk - 2012

Få mere succes med email marketing Velkomst flow og drop-basket flow mm. MailPlatform.dk - 2012 Få mere succes med email marketing Velkomst flow og drop-basket flow mm. MailPlatform.dk - 2012 Ordbog ECP = ecommerce platformen, dvs. shop systemet. EMM eller ESP = E-mail marketing platformen FB = FaceBook

Læs mere

Digital Sundhed Program for infrastruktur og sikkerhed

Digital Sundhed Program for infrastruktur og sikkerhed SDSD Projektmodel Kravspecifikation 007d.01 Stamdata Register Infrastrukturprogrammet fase 2 FMKi projektet Dato: 13.12.2010 Version: 1.0 Udarbejdet af: Digital Sundhed Sammenhængende Sundhed i Danmark

Læs mere

Integration af DocuBizz og Helios

Integration af DocuBizz og Helios Integration af DocuBizz og Helios v. 0.2 Side 1 af 7 Integration af DocuBizz og Helios 1 Overordnet beskrivelse... 1 2 Format for de overførte data... 1 3 Overførsel af stamdata fra Helios til DocuBizz...

Læs mere

Bibliotek.dk som lokal grænseflade notat

Bibliotek.dk som lokal grænseflade notat Bibliotek.dk som lokal grænseflade notat Dette notat skal beskrive løsningsmodeller for bibliotek.dk som lokal grænseflade som opfølgning på det notat som blev lavet i 2007 1 og på den workshop som blev

Læs mere

PHP Quick Teknisk Ordbog

PHP Quick Teknisk Ordbog PHP Quick Teknisk Ordbog Af Daniel Pedersen PHP Quick Teknisk Ordbog 1 Indhold De mest brugte tekniske udtryk benyttet inden for web udvikling. Du vil kunne slå de enkelte ord op og læse om hvad de betyder,

Læs mere

Arkitekturrapport: KITOS - Kommunens It-Overbliks System

Arkitekturrapport: KITOS - Kommunens It-Overbliks System Arkitekturrapport: KITOS - Kommunens It-Overbliks System Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug af den fælleskommunale rammearkitektur. Rapport ejes af projektets it-arkitekt.

Læs mere

SOA i Lægemiddelstyrelsen - fra spaghetti til lasagne. Mikael Bay Skilbreid, leder af facility management og it IBM Softwaredag 2006

SOA i Lægemiddelstyrelsen - fra spaghetti til lasagne. Mikael Bay Skilbreid, leder af facility management og it IBM Softwaredag 2006 SOA i Lægemiddelstyrelsen - fra spaghetti til lasagne Mikael Bay Skilbreid, leder af facility management og it IBM Softwaredag 2006 19. september 2006 Agenda Udfordringer overvejelser om SOA Visionen driver

Læs mere