Det hedder vel CPR registeret?

Hvis man rettede de kapacitetsproblemer og fejl der måtte være der, fik alle vel gavn af det?

...."i gang med at reducere betalingen af kopiregistre i egne systemer".

Vi er lang forbi det punkt hvor den ene hånd ikke ved hvad den anden gør. Nu skal der eksterne til at beskrive hvordan man får kontrol med den rebelske hånd :-)

Er det både læse og skrive adgang kommuner har brug for til CPR? - Hvis det kun er læse, så er NSP en mulighed, selvom deres fokus er sundhedsvæsnet.
https://www.nspop.dk/display/web/Overblik+over+NSP+services

http://services.nsi.dk/nsp

Det nuværende CPR er ikke særligt moderne, men til gengæld dyrt at abonnere på.
Kombit har sparet kommunerne mange penge og tid ved at have deres egen kopi som kommunerne kunne læse fra, men der er bare mangler i forhold til hvad vi forventer af en moderne database og brug i dagens Danmark og omegn. F.eks. er adresser på svenske og tyske statsborgere, der har arbejde i Danmark men bor hjemme noget man kan håbe at finde i hvad der minder om et note felt. e-mail-adresse ? Glem det. Og det kører et tegnsæt kun med a-z og æøå
Samtidigt trænger det til en datavask, jeg er f.eks. registreret som at have skiftet navn (aldrig gjort) og have et ikke dansk tegn i mit navn og det mest eksotiske jeg har er altså et W.
CPR kontoret har givet god service, men hvis staten ikke tør/vil modernisere det, så tror jeg at Kombit er det næste logiske valg til dette.

... det her er altså en triviel opgave, et team af dygtige danske udviklere og en fornuftig opensource platform ville kunne levere et kørende system på max et år, og vel og mærke et system der kan levere alle forespørgsler som det offentlige måtte ønske.

Mén vi kommer sku nok til at betale et tre-cifret million beløb for at CSC kan udvikle det på en forældet platform med den obligatoriske kopi til NSA.

Jeg skrev et designforslag til dette område i et gammelt blogindlæg.

Kommunerne er mere end velkomne til at bruge ideen:

http://www.version2.dk/blog/giv-et-bud-paa-intelligent-offentlig-it-44046

Det er sjældent det tekniske der er besværligt/tidskrævende i mange offentlige IT-projekter. Det er alt det udenom.
Der er nødt til at være et "filter" eller "forsvar" foran udviklerne, ellers får de intet lavet.

Noen kommuner gjorde for år tilbake tiltak og utviklede en open-source CPR Broker. Ideen er at alle klient programmer der konsumerer CPR data programmeres til en felles snittflate i CPR Broker - altså en felles standard.

CPR Broker kan hente CPR data fra forskjellige kilder - KMD (Kommunedata), DPR (Decentral Person Register, lokal database kommunen abonnerer på), CPR Kontoret og KOMBIT Serviceplatformen.

I takt med at offentlige grunndata slippes fri gratis, eller mye billigere end tidligere, er prisen på CPR data fra CPR Kontoret faldet drastisk i pris. Spørsmålet er nå om kommunene velger å bruke CPR Broker, der også kan mellomlagre data (cache) eller KOMBIT Serviceplatformen. Det beste ville være om KOMBIT velter at bruke CPR Broker og det arbeide der er lagt i denne standard og bruke det som neste snittflate på Serviceplatformen sin CPR del - om mulig.

Les mere: http://www.os2web.dk/document/cprbroker

Det er ikke alle offentlige IT prosjekter der koster milliarder, men det vil være dumt at et høyt IT utviklet land som Danmark har to CPR registre, fordi det ene er for dyrt.

Der er ret gode argumenter for at bevare kopiregistrene.

Det er fint system-design at man abonnerer på ændringer fra CPR systemet.
Kopiregisteret giver performance, oppetid og mulighed for at reagere proaktivt på ændringer.

Efter min mening burde mange flere systemintegrationer designes ud fra det mønster. CPR registeret er gammelt, men det er præcist samme arkitektur, som anbefales hvis man vil integrere på tværs i en microservice arkitektur.

Det kan så godt være at prisen og teknologien bag CPR-systemet er forældet. Men lad os diskutere arkitektur, prissætning og teknik hver for sig.

Argumentet for at centralisere er udelukkende at spare abonnementer hos CPR. Hvis alle kommuner kan dele et abonnement, så sparer de en masse. Men samfundsøkonomisk sparer vi ikke noget. Hvis de erstatter god arkitektur med noget SOA, hvor alle kalder alle, så har vi samlet tabt.

Vi har tilføjet adgang til CPR data via serviceplatformen i alle vores produkter. Dette betyder at vi nu supportere adgang til CPR data via 4 forskellige services, hvor service platformen fra KOMBIT er et af dem.

Det lyder i første omgang lidt fjollet, at der skal være så mange. Men det betyder også at vores kunder kan begynde at anvende service platformen hver for sig uden at alle i kongeriet skifte samme dag. Og det er faktisk en rar måde at udrulle en integration på.

Service platformen vil nok udkonkurrer både DPR fra CSC og P-Data fra KMD. Service platformen mig bekendt meget billigere, og der tages ikke penge for hver data opdatering. Dog vil de andre services ikke helt forsvinde, da kommuner osv har andet software, hvor sådan en ny integration ikke kan tilføjes. Men det kan vi selvfølgelig være ligeglade med.

Så velkommen til CPR data via service platformen. Den vil vi anbefale indtil der kommer en anden løsning der er endnu bedre. For os er det også starten på den fælleskommunale rammearkitektur. Det går ud på at man lader flere virksomheder byde på offentlige opgaver, men forlanger at alle bud kan udveksle nogle data via bestemte web services som beskrives af KOMBIT inden udbuddet. Det er også et stort skridt frem.

Økonomien omkring CPR Data blev beskrevet i et bachelor-projekt i 2011: http://blog.magenta-aps.dk/wp-content/uploads/2012/01/Projekt_8.pdf

Citat:

"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."

Kombits arbejde retter sig mod at fjerne behovet for KMD's P- og V-dataprodukter, der er rene kopier af CPR- og CVR-data. Meningen er, at alle kald fra fagsystemer skal ske til Serviceplatformen. Det skal ikke forveksles med Dataffordeleren, der er et statsligt projekt. Begge datasamlinger er kopiregistre.

Kombit havde desværre ikke mulighed for at følge fx phk's opfordring til at redesigne CPR, selvom der var forsigtige følere fra referencegruppen. Der var ikke rigtigt nogen med magt, der svarede, da man luftede behovet.

Der er ellers et stort behov, eftersom CPR er designet for næsten 50 år siden. Dataindholdet kunne og burde være meget anderledes og meget gerne segmenteret, som phk også er inde på. Jeg kunne fx godt tænke mig, at pensioniststatus var registreret, eftersom denne er relevant ift administration af vinterbeboelse i sommerhusområder eller lån til betaling af ejendomsskat, men man kunne også godt diskutere mange andre felter. Kontaktinformationer fx.
Så kunne man måske samtidig fjerne oplysninger om fokekirketilhørsforhold fra 'forsiden'! Og måske undlade at registrere stilling og stillingsdato, hvis man ikke gider at vedligeholde den slags data. (Vi har fx mange mennesker, der er registreret som 'Skoleelev'. Den yngste er 38 år).
Man kunne også give borgerne mulighed for at rette i egne (udvalgte) data.

Der i praksis fungerer til batchkorsler og avancerede søgninger hvori der skal joines med organisationens øvrige forretningsinformationer.
Kopiregistre er den eneste arkitektur der giver mulighed for integration dybt nede i databasen. Der er simpelthen ikke nogen RDMS databaseoptimisere som virker over et SOA snit.
Det er katastrofalt hvis forretningsorienterede IT konsulenter blande det forretningsmæssig behov for billigere adgang til CPR data - sammen med IT-arkitektur.
Der er i så fald stor risiko for at (endnu mindre IT kyndige) beslutningstagere også blander det sammen og følger de implicitte anbefalinger. I værste fald, fører det til dyre, komplekse, sårbare og langsomme løsninger.

Der er da heller ikke noget, der tyder på, at man ikke fremover vil kunne købe eller selv opsætte abonnementer på en decentral løsning. Du kan fx bruge Serviceplatformens SFTP til et CPR-abonnement.

@Mikkel Mikjær og Lasse Bendixen.

Som jeg husker det var der en del udfordringer ved forsøget på den modernisering af CPR systemet, som blev skrinlagt tilbage i 2011. En af dem var af systemet reelt var udokumenteret i bedste fald dårlig dokumenteret og at hverken leverandør eller kunde havde det fulde overblik over systemets opførsel. Det blev der vist brugt en del krudt på.

Jeg tænker et hold af dygtige udviklere også ville have haft deres hyr med at analysere den egentlige opførsel af systemet inden de skulle kode det igen, hvis systemet vel og mærke stadig skulle leveres under samme betingelser.