1      Formål

Nærværende dokument giver et overblik over stamdataservicen med fokus på design og arkitektur. Dokumentet har som formål at give et indblik i det underliggende design, de udstillede snitflader på det overordnede niveau samt særlige forhold vedrørende de udstillede registre. Både aftagere af stamdataservicen, kildedataleverandører samt NSP operatør/driftsleverandør kan med fordel læse dette dokument.

2      Arkitekturoverblik

Stamdata modulet (SDM) er udstillet på NSP, og består af flere komponenter. Der er en række webservices, som tilbyder data-adgang til forskellige registre (enkeltopslag og udtræk af registre), og et dataopsamlings framework, bestående af parsere og importere, der henter data fra en række eksterne kildedataregistre, bl.a. CPR-registret og SKS. Nedenstående figur viser en principskitse over arkitekturen, hvor stamdata services er udstillet på den enkelte NSP instans.

Figur 1  – Stamdatamodulet opsamler data fra kilderegistre og udstiller data på NSP

Adgangen til de data der udstilles via stamdata-services er beskyttet af Den Gode Webservice (DGWS), og adgangskontrollen er styret på basis af CVR-nummer.

3      Logisk Arkitektur

Den logiske arkitektur er opdelt i dataindsamling, replikering til NSP instanserne og udstilling af data gennem services. I de følgende afsnit beskrives disse elementer af arkitekturen.

3.1     Dataindsamling: Stamdata Importer og Parser

Stamdataregistret samler stamdata fra en række kilderegistre hos offentlige myndigheder. Indsamlingen af data implementeres i forhold til hvert enkelt kilderegister ved anvendelse af en registerspecifik Parser, men med anvendelse af en fælles Importer-komponent. Importer-komponenten kører på DoDi-platformen, og er ansvarlig for at indlæse dataset fra registerfiler, der placeres i en dedikeret mappe i filsystemet [1]. Hvert register har sin egen dedikerede mappe som automatisk bliver oprettet af Importer-komponenten.

[1] For hvert register implementeres en transportløsning (f.eks. FTP som push eller pull), der har som opgave at overføre ”rå” registerdata fra kilderegistret til NSP-platformen.

Importeren overvåger filsystemet og aktiverer de registerspecifikke parsere, når nye registerfiler er tilgængelige i filsystemet. De respektive parsere processerer registerfilerne og overfører registerdata til den lokale database. Parsningen kan i princippet bestå af en direkte dataoverførsel fra fil til database, men indeholder i de fleste tilfælde forretningslogik, f.eks. transformationer af data og denormaliseringer.

Hver mappe har tre undermapper:

• input: En inbox som jævnligt undersøges for nye filer
• processing: Indeholder filer som er ved at blive importeret
• rejected: Her placeres filer som ikke kunne importeres i tilfælde af fejl.

Figur 2 – Principskitse af et importforløb, hvor en parser aktiveres af importeren

3.2     Replikering til NSP-instanserne

Dataindsamlingen fra kilderegistrene foregår på DoDi (for yderligere information om NSP-konceptets komponenter henvises til den overordnede NSP-dokumentation).

Figur 3 – principskite af envejs-replikeringen fra DoDi til NSP-instanserne

Stamdatatabellerne registreres i NSP’ens replikeringsmekanisme, og de parsede registerdata replikeres derfor automatisk ud til de enkelte NSP-instanser som illustreret på Figur 3, hvorfra de kan tilgås gennem de udstillede stamdataservices (ikke illustreret).

3.3     Etableringsudtræk og partielle udtræk af hele registre

Stamdataregistret giver mulighed for dels enkeltopslag i de tilknyttede registre, dels mulighed for udtræk af hele registre til opbevaring og anvendelse i den lokale infrastruktur. Disse services beskrives i de følgende afsnit.

3.3.1      Kopiregisterservicen

Der kan foretages komplette registerudtræk ved anvendelse af Kopiregisterservicen (KRS), der er en identitetsbaseret DGWS webservice udstillet på NSP-platformen.

Kopiregisterservicen giver dels mulighed for etableringsudtræk, hvor det komplette register leveres [2], dels såkaldte ”delta-opdateringer”, hvor ændringer i registret siden sidste udtræk leveres. De to typer udtræk er varianter af samme kald, hvor et etableringsudtræk leverer summen af samtlige ændringer i det pågældende registers levetid, og hvor et deltaudtræk leverer summen af ændringer siden sidste kald.

[2] Da registrene kan være af en størrelse, der gør det uhensigtsmæssigt at lave et komplet udtræk i et enkelt kald til KRS, gennemføres det komplette udtræk typisk ved en række på hinanden følgende kald. Dette er dog en teknisk detalje.

Figur 4 – Kopiregisterservicen udstiller snitflader til udtræk af registre

Til at styre hvilke klienter der har adgang til de respektive registre i Stamdata findes der en rettighedstabel. Tabellen opdateres af driftsoperatøren. Der henvises til driftsguiden for en detaljeret beskrivelse af rettighedstildeling.

3.4     Enkeltopslagsservices

For udvalgte registre er der implementeret såkaldte enkeltopslagsservices, der, som navnet antyder, giver mulighed for opslag på enkeltregistreringer i de respektive registre. Alle enkeltopslagsservices implementeres som identitetsbaserede web services.

Figur 5 – Stamdataservicen udstiller snitflader til enkeltopslag for udvalgte registre

Stamdataservicen stiller følgende enkeltopslagsservices til rådighed:

For yderligere information om enkeltopslagsservices henvises til anvenderguiden, der indgår på lige fod med nærværende dokument i den samlede dokumentations­pakke for stamdataservicen.

3.5     Abonnementsservice til CPR-registret

CPR abonnementsservicen på NSP er en service til automatisk opdatering af en liste af CPR numre. De enkelte abonnenter (f.eks. en region eller et sygehus) vedligeholder deres egen liste på NSP, og abonnenterne modtager ændringer i CPR informationerne for de enkelte CPR numre på en given abonnementsliste ved kald til abonnementsservicen.

Set udefra udstiller abonnementsservicen to identitetsbaserede webservice-snitflader (DGWS):

• En vedligeholdelsessnitflade, hvor abonnenter kan vedligeholde deres egen abonnementsliste (dvs. tilføje CPR-numre til listen eller fjerne CPR-numre fra listen).
• En udtrækssnitflade, hvor abonnenter kan forespørge på ændringer i CPR-oplysningerne for de CPR-numre, der er på listen.

Det bemærkes, at abonnementsservicen for CPR-registret udelukkende overvåger ændringer i selve CPR-registret. Ønskes der ajourførte oplysninger vedrørende f.eks. ”egen læge” eller yderinformationer opnås dette gennem brug af kopiregisterservicen for de pågældende registre (se afsnit 3.3 for yderligere information). Abonnementsservicen er skitseret på Figur 6. Som det fremgår af figuren vedligeholdes abonnementslister ved anvendelse af en vedligeholdelsessnitflade udstillet af den generiske opsamlingsservice (GOS), og udtræk af ændrede oplysninger fås gennem den udstillede abonnementssnitflade oprettet til formålet.

Der henvises til anvenderguiden for yderligere information om hvordan snitfladerne anvendes.

Figur 6 – Arkitekturskitse for abonnementsservicen.

For kald til at hente ændrede CPR-numre (getChangedCprs) ser dataflowet fra DoDi til NSP og internt på NSP’en ud som skitseret på Figur 7:

Figur 7 – Dataflow gennem arkitekturen ved brug af abonnementsservicen

4      Særlige forhold

Stamdataservicen anvender en række tabeller til at opbevare stamdataregistrene. Disse tabeller er typisk koblet relativt hårdt op mod kilderegistrenes struktur, og tidligere erfaringer har vist, at der med jævne mellemrum forekommer ændringer i kilderegistrene. Det er derfor forsøgt undgået at andre (NSP-) komponenter end stamdataservicen anvender stamdatatabellerne. Hvor andre komponenter har behov for at anvende stamdata internt på NSP, kopieres data ud i separate tabeller, som komponenterne kan bruge i stedet.

På NSP 2.0 anvendes autorisationsregistrets data af STS (til berigelse og verifikation af autorisationsnummer), og der er derfor oprettet en særlig Autorisationstabel til dette formål som illustreret på figuren nedenfor.

Figur 8 – Enkeltopslagsservicen til autorisationsregistret og STS deler datagrundlag.

5      Fysiske Datamodeller

Datamodellen for hvert enkelt register i Stamdataservicen er defineret i bilaget ’schema.sql’. Nedenfor er registrene beskrevet overordnet i tabelform.

5.1     Doseringsforslag

5.2     CPR-registret

5.3     SKS-registret

5.4     SOR-registret

5.5     Yderregistret

5.6     Autorisationsregistret

5.7     DKMA-registret

5.8     Bemyndigelser

5.9     SOR-NPI relationer

6      Ændringslog

Kilden til dette dokument kan kan erhverves ved henvendelse til NSP-operatøren.