Open source-løsning skal spare kommuner for CPR-opslag hos KMD

Hvorfor lade mange forskellige it-systemer hente samme oplysninger flere gange, fra forskellige eksterne datakilder, og betale for det hver gang, når man kan samle alle opslag og spare penge?

Det er kort sagt ideen bag den såkaldte CPR Broker, som skal hjælpe kommunerne med at få styr på alle de mange opslag, de kommunale it-systemer hver dag har i registre hos CPR-kontoret, KMD og andre datakilder om borgerne.

Ved at sætte en ekstra database ind mellem kommunernes it-systemer og de eksterne registre, kan man få samlet alle data ét sted, så nogle opslag bliver overflødige og kan klares internt.

Her fortæller Leif Lodahl fra Magenta om projektet, som blev udført for Gentofte Kommune og IT- og Telestyrelsen.

Hvad går projektet ud på?

»Kommuner har en hel masse systemer, som henter persondata fra en række forskellige kilder. Vi har identificeret mindst 18 it-systemer hos kommunerne, som henter data med CPR-nummer som nøgle, og hvert af systemerne har en proprietær integration med datakilden. Nogle bruger også flere datakilder samtidigt.

Vi skubber CPR Broker ind imellem datakilderne og it-systemerne, så kommunerne kan få et overblik over, hvilke datakilder de bruger til persondata. Samtidigt bliver alle data så stillet til rådighed på en standardiseret måde, efter IT- og Telestyrelsens standard PART.

De rå persondata kommer fra CPR-kontoret, men så beriger leverandørerne dem med ekstra information, så det passer til deres systemer. Og kommunerne betaler for alle disse opslag.

Først udviklede vi løsningen til Gentofte Kommune, og i version 2 har vi i samarbejde med IT- og Telestyrelsen opgraderet CPR Broker til at følge den nye standard på området, PART, som ikke var klar, da vi udviklede version 1. Nu bliver CPR Broker også testet i Ballerup og Odense.«

Hvad er målet med projektet?

»Ved at samle og flette alle de data, som kommunerne henter, beriger vi dem. Det kunne man ikke før. Det var kun i hvert enkelt it-system, man samlede data, og det sker proprietært.

CPR Broker giver også mere konsistente datakilder, fordi det hele bliver samlet. Der er forskellig opdateringsfrekvens på de forskellige datakilder, og derfor kan man ikke helt stole på, at de er opdaterede, når man får dem enkeltvis.

Mange oplysninger er også de samme, så med tiden kan kommunerne spare penge ved at reducere antallet af datakilder, man skal abonnere på.«

Hvilken teknologi indgår i projektet?

»Vi bruger en Microsoft SQL-database og .Net-programmering. Det ligger på en Microsoft IIS-server. Det var et pragmatisk valg, da Gentofte Kommune, som i første omgang drev projektet, kun bruger Microsoft-servere og ikke har Linux-servere. Og mange kommuner har på samme kun Microsoft-servere i kælderen.

Men vi er i øjeblikket i gang med at gøre det muligt at bruge MySQL eller en anden generisk database, så man selv kan bestemme. Vi forventer, at vi kan gøre det helt uafhængigt, så man ikke er tvunget til at have software fra en bestemt leverandør.«

Hvad var tidsplanen for projektet?

»Vi udviklede version 1 tilbage i 2009, hvor vi var to programmører på opgaven i tre måneder. Dengang var der jo ingen standard for de data, så vi opfandt bare selv et interface.

Så kom PART-standarden for persondata i 2010, og IT- og Telestyrelsen spurgte, om vi ville implementere den i CPR Broker. Det gjorde vi med med version 2, som var klar i februar 2011. Her var vi også to programmører på, siden november, men fik også assistance fra IT- og Telestyrelsen.«

Hvilke udfordringer stødte I på undervejs?

»Rent teknisk er OIOXML-skemaerne ret voldsomme og meget komplekse. Vi vidste, at der var meget høje kvalitetskrav, og at vi måtte være ekstremt præcise i vores implementering af standarderne. Vi udviklede CPR Brokeren parallelt med, at standarden var i høring, så der kom kommentarer og mindre ændringer undervejs. Men det var et vilkår, der var.

Ellers har udfordringen mest været at forklare konceptet ude hos kommunerne. Det er en applikation uden brugergrænseflade, så vi kunne ikke fremvise skærmbilleder. Den udveksler data mellem to andre applikationer, og det er svært at forklare.

Det var også svært at forklare business casen for at lave det som et open source-projekt. Vi ejer ikke koden, og kommuner kan downloade den gratis og installere den. Men det betød, at vi skulle skaffe sponsorer, og der har vi skullet forklare vigtigheden af, at leverandøren ikke ejer koden.

Hvis KMD eller CSC havde lavet den, skulle kommunerne betale et løbende abonnement, når produktet var klar, men her skulle sponsorerne have penge op af lommen på et tidligt tidspunkt, ligesom hvis man køber et hus som et projekt, der ikke er bygget endnu. Den forretningsmodel er forholdsvis ny for kommunerne.

Til gengæld ejer KMD eller CSC ikke koden, og kommunerne kan selv bestemme, hvad der skal ske fremover, og hvem der skal udvikle næste version. Det kan godt være nogle andre end os.«

Hvilke gode råd kan du give videre?

»I sådan et projekt som dette, der er så standardspecifikt, er det vigtigt at få IT- og Telestyrelsen med. Det har været så skønt at have deres arkitekter med, for de har en grundviden, som har sparet os for rigtig meget arbejde.

For open source-modellen gælder det om, at man skal have et community på plads, og man skal aftale hele modellen. Hvem har ansvaret for CPR Broker? Hvem bestemmer hvilke features, der skal med i den næste version? Og hvilken teknologi skal der bruges? Løsningen kan være at stifte en forening for CPR Broker med en bestyrelse, der så bestemmer over udviklingen.

Vi har fået mange gode råd fra IT- og Telestyrelsen om, hvordan man gør det levedygtigt. Der er flere open source-projekter i Danmark, der ikke når længere end version 1.0, fordi man glemmer at sikre sig, at der også i fremtiden er en governance-model for projektet. Man skal sikre sig et community, der forpligter.«