Page History
...
Her vil man kunne se om CPRimporteren kører, hvornår CPRimporteren sidst har kørt, og hvilken status den har.
5 Enkeltopslag i registre
Stamdataservicen tilbyder en service til såkaldte enkeltopslag i følgende registre:
- Autorisationsregistret
- CPR-registret
Enkeltopslag i et af de ovennævnte registre foregår som et webservice kald til stamdataservicen på NSP med angivelse af søgekriterier. De konkrete parametre og eventuelle særlige forhold der gør sig gældende for kald til enkeltopslags-snitfladen på stamdataservicen er beskrevet i de følgende afsnit.
5.1 Forespørgsler og dataformat
Enkeltopslags-snitfladen er udstillet som en DGWS 1.0.1 identitetsbaseret webservice. Adgang til enkeltopslagsservices forudsætter en aftale med NSP-operatøren (adgang styres på CVR-nummer). Metoderne for de udstillede registre er beskrevet i separate WSDL-filer, der kan rekvireres ved henvendelse til NSP-operatøren.
Fælles for de udstillede enkeltopslagsservices er at der kræves STS-signerede system ID-kort (dvs. DGWS niveau 3).
5.2 Enkeltopslag i autorisationsregistret
...
[2] Servicen giver et øjebliksbillede af personens autorisationer, dvs. udløbne og fremtidige autorisationer returneres ikke.
...
Uddannelseskode
...
Faggruppenavn
...
4498
...
Optiker
...
5151
...
Fysioterapeut
...
5153
...
Ergoterapeut
...
5155
...
Fodterapeut
...
5158
...
Radiograf
...
5159
...
Bioanalytiker
...
5166
...
Sygeplejerske
...
5175
...
Jordemoder
...
5265
...
Kiropraktor
...
5431
...
Tandplejer
...
5432
...
Klinisk Tandtekniker
...
5433
...
Tandlæge
...
5451
...
Klinisk diætist
...
7170
...
Læge
...
9495
...
Bandagist
4.1.3 Konfiguration af Stamdata importere
Hver importer har en default konfigurationsfil (default-config.properties) der er indlejret i war filen, de eneklte konfigurationsindstillinger kan overstyres ved af en miljø specifik konfigurationsfil (config.properties), der ligger i filsystemet på følgende lokation:
<JBOSS_HOME>/modules/sdm4/config/<komponent>/main/config.properties
Properties
jdbc.JNDIName | JNDI navn for datasourcen, der er konfigureret i JBOSS serveren, default: java:/SDMDS |
sdm.dataDir | Folder navn hvor importeren kan finde datafilerne default: /pack/jboss/domain/data/sdm4 |
spooler.max.days.between.runs | Parameter til overvågning af om en importer har modtaget data indenfor et forventet interval. Hvis denne frist overskrides vil overvågningen rapportere fejl. |
dk.nsi.dgws.sosi.dgwsLevels | Kommasepararet liste af DGWS niveauer som kan bruges når man tilgår denne service. F.eks dk.nsi.dgws.sosi.dgwsLevels=3,4 Default: 3 |
4.2 Database
De enkelte stamdata importere er testet på en MariaDB database.
4.2.1 Skema til stamdata importere
Skema til stamdata importere opdateres automatisk af de enkelte importere, via det indbyggede migrerings framework.
Det skal dog understreges at så lang tid de enkelte NSP services er direkte afhængige af tabel layoutet for stamdata importerne, og der samtidig skal være bagud kompatibilitet vil tabel layoutet ikke ændre sige for stamdata importerne – men kun være splittet ud i importer war filerne.
4.2.2 Databaseopsætning
Følgende indstillinger bør sættes specielt i databasen, disse indstillinger konfigureres i mysql’s konfigurationsfil.
Indstilling | Værdi | Beskrivelse |
Max_allowed_packet | 16M | CPR opslagsservices kan returnere en pæn mængde data, derfor er max_allowed_packet default værdien på 1M for lidt - det anbefales at sætte den til 16M. |
5 Backup
Alle tabeller i stamdatas database skal have daglig backup. Backup må ikke gemmes længere end 2 år pga. lovkrav.
Da der er tale om store mængder data er det vigtigt at holde for øje at det kan tage meget lang tid at genetablere et database image for stamdata.
5.1 Backup af Data Manager input-filer
Alle filer fra dataset som lægges ind i Stamdata indbakker skal der laves backup af. Det vil sige at hver gang der f.eks. ankommer en ny fil fra CPR-registeret skal filen ligges i den pågældende parsers indbakke og samtidigt arkiveres. Hvordan filen arkiveres er op til driften, men filnavnet og dato for ankomst skal kunne spores.
6 Overvågning
6.1 Statussider
For hver komponent er der en status-side som periodisk kan kaldes for at tjekke om servicen kører. Hvis en service ikke kan overvåges via en simple status side vil det fremgå af dens driftsdokumentation.
Status sider fungerer over HTTP, og har følgende statuskoder:
200 | Alt er OK. |
500 | Der er opstået en fejl, og driften bør undersøge komponentens log for fejlmeddelelser. Kan fejlen ikke opklares simpelt, bør driften kontakte support. |
URL’s for status sider kan findes tidligere i dette dokument.
6.1.1 Speciel overvågning af SOR og SOR-Relationer importerne
Da SOR behandles af to forskellige importere, er det et problem for datakonsistensen, hvis den ene af disse to parsere fejler på et datasæt som den anden parser ikke fejler på.
Skulle en af de to parsere afvise en import, er det en hastesag at få rettet den fejl der resulterer i afvisningen i den anden parser, så de to registre kan komme i sync så hurtigt som muligt.
6.2 Logning
Stamdata importerne på BackOffice bruger ikke JBOSS logging, men har hver deres egen log konfiguration som placeres følgende:
<JBOSS_HOME>/modules/sdm4/config/<Importer navn>/main/
Her ligges en log4j.properties, der beskriver hvorledes importeren skal logge, samt konfiguration for SLA logging for netop denne komponent
6.2.1 SLA-Log punkter
For at sikre en struktureret logning på tværs af de forskellige services, benyttes nsp-util også til SLA-Logning fra sdm4 importerne.
Der logges fra 2 logpunkter pr. importer ét punkt fra sdm4-core og ét fra selve importeren, sdm4-core er delt for alle importere og der dannes én linje for hver gang en importer startes.
En log fra sdm4-core ser ud som nedenfor:
03-06-2013 13:34:46,752 [pool-10-thread-1] INFO dk.sdsd.nsp.slalogdata - LogPoint="<importernavn>.ParserExecutor" LogPointUniqId="SDM4CORE_ENTRY" StartTime="2013-06-03 13:34:45.650" EndTime="2013-06-03 13:34:46.752" Duration="1101893 microseconds" MessageId="vitaminimporter-1370259285650" RequestSize=0 ReplySize=0 Result=OK ClientIP="<empty>" SOAPOperation="<empty>" SOAPEndpoint="<empty>" SOAPAction="<empty>" TargetSOAPOperation="<empty>" TargetSOAPEndpoint="<empty>" GenericCallParms(0)= { }
Fra de enkelte importere logges følgene pr datasæt:
03-06-2013 13:34:46,750 [pool-10-thread-1] INFO dk.sdsd.nsp.slalogdata - LogPoint="<importernavn>.process" LogPointUniqId="SDM4. <importernavn>.process" StartTime="2013-06-03 13:34:45.782" EndTime="2013-06-03 13:34:46.750" Duration="967593 microseconds" MessageId="vitaminimporter-1370259285650" RequestSize=0 ReplySize=0 Result=OK ClientIP="<empty>" SOAPOperation="<empty>" SOAPEndpoint="<empty>" SOAPAction="<empty>" TargetSOAPOperation="<empty>" TargetSOAPEndpoint="<empty>" GenericCallParms(2)= { ("input","/pack/jboss/domain/data/sdm4/vitaminimporter/vitaminer") , ("processed_records","634") }
GenericCallParms indeholder altid ”input” som peger på input folderen samt ”processed_records” som indeholder antal indsatte eller ændrede records i databasen.
MessageID indeholder en unik id for kørslen således man kan kæde sdm4-core loggen sdm4-importeren sammen pr. kørsel.
6.2.2 Fejlsøgning
Opstår der en fejlsituation i en komponent, skal driften undersøge den pågældende komponents logfil for loghændelser på ERROR-niveau. F.eks. i tilfælde af at komponenten ikke kan forbinde til databasen. Visse andre fejl er ikke-kritiske. Det vil sige at komponenten kan forsætte med at fungere. De bliver også logget på ERROR-niveau da der hændelsen bør undersøges. Komponenterne vil i så vid udstrækning som muligt forsøge at forsætte på trods af fejl.
Anvendes Splunk til indeksere logfiler bør alle de konfigurerede filer indekseres. Der kan opsættes alarmer i Splunk som aktiveres hvis en hændelse med ERROR-niveau logges. Dette niveau anvendes udelukkende ved alvorlige fejl. Der udover er også hændelser på WARN-niveau interessante da de f.eks. fortæller om folk forsøger at tilgå servicen uden tilladelse ol.
7 Liste af Registre
Hvert register har sin egen registerspecifikations fil som ligger i register mappen sammen med dokumentationen.
8 Ændringslog
Kilden til dette dokument kan findes på:
https://svn.nspop.dk/svn/trifork/sdm4-core/trunk/doc/Driftsvejledning.docx
Version | Dato | Ændring | Ansvarlig
|
1.0 | 2011-04-28 | Initielt Dokument | Trifork |
1.1 | 2011-09-12 | Opdateret med CPR services | Trifork |
1.2 | 2012-06-18 | Tilføjet informationer om schema opdateringer, samt mysql settings og v2 parsere | Trifork |
1.3 | 2012-08-22 | Opdateret med opsplitning af stamdata importere i moduler, samt JBOSS 7 konfiguration på DoDi | Trifork
|
1.4 | 2012-08-24 | Fjernet al dokumentation der ikke er Importer specifik | Trifork |
1.5 | 2013-06-03 | Tilføjet afsnit om sla-log | Trifork |
1.6 | 2014-01-09 | Opdateret kilde link | Trifork KPN |
1.7 | 2019-09-20 | Ajourført (Backoffice og MariaDB) Udstilling kun på NSPOP | NSP Operatør |
...
5.2.1 Eksempel: Én eller flere autorisationer
Nedenfor ses et ”solskinsscenarie”, hvor der forespørges på en sundhedsfaglig, der har en enkelt gyldig autorisation.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
…
</S:Header>
<S:Body>
<AuthorizationRequestStructure xmlns="http://nsi.dk/-/stamdata/3.0" xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#" xmlns:ns4="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns5="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns6="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">
<cpr>1111122222</cpr>
</AuthorizationRequestStructure>
</S:Body>
</S:Envelope> |
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
…
</S:Header>
<S:Body>
<AuthorizationResponseStructure xmlns="http://nsi.dk/-/stamdata/3.0" >
<cpr>1111122222</cpr>
<firstName>Peter</firstName>
<lastName>Andersen</lastName>
<authorization>
<authorizationCode>B1114</authorizationCode>
<educationCode>2131</educationCode>
</authorization>
</AuthorizationResponseStructure>
</S:Body>
</S:Envelope> |
I eksemplet er Peter Andersen tilknyttet CPR 1111122222, og han har en autorisation.
5.2.2 Eksempel: Ingen gyldige autorisationer
Forespørges der på en ikke-eksisterende person eller en person, der ikke har en gyldig autorisation, svares der blot med en tom AutorizationResponseStructure.
I eksemplet nedenfor er headere udeladt, og der henvises til eksemplet i afsnit 5.2.1 for en tilsvarende forespørgsel hvor headere er vist.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
…
</S:Header>
<S:Body>
<AuthorizationRequestStructure xmlns="http://nsi.dk/-/stamdata/3.0" xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#" xmlns:ns4="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns5="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns6="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">
<cpr>1111122244</cpr>
</AuthorizationRequestStructure>
</S:Body>
</S:Envelope> |
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<soapenv:Envelope …>
<soapenv:Header>…</soapenv:Header>
<soapenv:Body>
<AuthorizationResponseStructure xmlns="http://nsi.dk/-/stamdata/3.0">
<cpr>1111122222</cpr>
</AuthorizationResponseStructure>
</soapenv:Body>
</soapenv:Envelope> |
Da der ikke er nogen tilknyttede autorisationer, returneres en tom AuthorizationResponseStructure uden angivelse af for- og efternavn.
5.3 CPR-registret: Det Gode CPR-opslag
Stamdataservicen udstiller mulighed for enkeltopslag i CPR-registret gennem en implementering af ’Det Gode CPR-opslag’ som specificeret af MedCom (http://www.medcom.dk/wm110491).
5.3.1 WSDL
WSDL-filer for servicen kan findes på medcoms svn her:
http://svn.medcom.dk/svn/drafts/CPR-opslag/trunk/CPR-opslag/wsdl/
Vær opmærksom på, at der tilføjes Den Gode WebService-felter på, så det vil nok være nemmere at hente wsdl direkte fra servicen. Dette gøres ved at kalde endpoint med ?wsdl tilføjet sådan: http://endpointurl?wsdl
Denne indeholder de tilføjede felter.
Sidst men ikke mindst kan de også hentes med dgws-felter direkte fra leverandørens svn her:
5.3.2 Endpoints
Det gode CPR-opslag er udstillet i version 1.0.0 og version 1.0.2, som er tilgængelige på hver deres endpoints.
For 1.0.0:
http://stamdatahost:8080/stamdata-cpr-ws/service/DetGodeCPROpslag
For 1.0.2
http://stamdatahost:8080/stamdata-cpr-ws/service/DetGodeCPROpslag-1.0.2
Det anbefales at køre på version 1.0.2, da ikke alle personer kan hentes i 1.0.0 uden valideringsfejl.
5.3.3 Mangelfuldt datagrundlag
Datagrundlaget kan i nogle tilfælde mangle værdier som er påkrævet af wsdl skemaet, hvis dette er tilfældet vil felterne udfyldes med en erstatningsværdi.
For PersonInformationStructureType drejer sig om følgende felter:
...
Felt
...
Erstatningsværdi
...
PersonGivenName
...
UKENDT
...
PersonSurnameName
...
UKENDT
...
PersonNameForAddressingName
...
UKENDT
...
PostCodeIdentifier
...
0000
...
DistrictName
...
UKENDT
...
MunicipalityCode
...
0000
...
StreetCode
...
0000
For AssociatedGeneralPractitionerStructure er det følgende felter:
Felt | Erstatningsværdi |
PostCodeIdentifier | 0000 |
DistrictName | UKENDT |
...
Hvis der ikke kan findes en tilknyttet læge i datagrundlaget vil AssociatedGeneralPractitionerStructure være udfyldt med følgende værdier:
...
Felt
...
Erstatningsværdi
...
AssociatedGeneralPractitionerIdentifier
...
000000
...
AssociatedGeneralPractitionerOrganisationName
...
UKENDT
...
DistrictName
...
UKENDT
...
EmailAddressIdentifier
...
...
PostCodeIdentifier
...
0000
...
StandardAddressIdentifier
...
UKENDT
...
TelephoneSubscriberIdentifier
...
00000000
5.3.4 Fejlfyldt CPR-data
Udover ovenstående erstatningsværdier kan der også være tale om data, som ikke har kunnet indlæses pga. fejlfyldt kildedata. Det kan fx være en dato, der ikke har kunne parses. Hvis der laves opslag på en person, som har fejlfyldt data vil der blive indsat erstatningsværdier for de felter, der er markeret som fejlfyldte eller der vil blive sendt en soap-fejl med beskeden ”Data for personen er markeret som upålideligt”.
Hvorvidt der kommer en fejl eller der anvendes erstatningsværdier og hvad disse vil være sat til, afhænger af konfigurationen, se mere på http://www.nspop.dk
5.3.5 Navne- og adressebeskyttelse
For CPR-opslag gælder det generelt, at hvis en record i CPR-registret er markeret med navne- og adressebeskyttelse, da vil output være beskyttet ud fra følgende regler:
...
Søgning via
...
Hvilke data er beskyttet
...
getPersonInformation
...
Alle output-felter på nær CPR-nummer
...
getPersonWithHealthCareInformation
...
Alle output-elementer dog ikke:
CPR-nummer
Information om tilknyttet læge
Information om sygesikringsgruppe.
...
getPersonDetails
...
Output er ikke beskyttet
Beskyttelse af data sker ved indsættelse erstatningsværdier, værdierne som der bliver erstattet med er afhængig af hvilken XSD type elementet har (dvs. der tages hensyn til de navnebeskyttede felters skema-definition).
Hvorvidt en person er adressebeskyttet kan i svaret bestemmes ud fra ”PersonInformationProtectionIndicator” uanset om output er beskyttet eller læsbart.
5.4 CPR-registret: getPersonDetails
Stamdataservicen udstiller endvidere en variant af ’Det Gode CPR-opslag’, der kan anvendes til søgninger i CPR-registret med følgende input.
- CPR-nummer
- liste af CPR-numre
- fødselsdato
- navn
Servicen har en enkelt snitflade: getPersonDetails, der er implementeret i forskellige udgaver og muliggør forskellige typer af søgninger. I de følgende afsnit er kaldmulighederne beskrevet med tilhørende eksempler.
Servicen er formelt beskrevet i WSDL og XSD-skemaer, der kan findes her:
| Code Block |
|---|
<src-root>/Dokumentation/bilag/StamdataPersonLookupService/ |
Eller direkte på driftsoperatørens SVN:
...
Servicen tager hensyn til navnebeskyttelse, og det anbefales at undersøge elementet PersonInformationProtectionIndicator for om værdien er true, da personen i så fald er navnebeskyttet.
5.4.1 Endpoints
På samme måde som DetGodeCprOpslag findes der to endpoints:
http://stamdatahost:8080/stamdata-cpr-ws/service/StamdataPersonLookup
samt
http://stamdatahost:8080/stamdata-cpr-ws/service/StamdataPersonLookup-1.0.1
...
Det anbefales man anvender StamdataPersonLookup-1.0.1 i nye projekter, wsdl-filerne til denne kan findes i PERSONLOOKUP_1.0.1-mappen.
5.4.2 Mangelfuld data og fejlfyldt CPR-data
Se 5.3.3: Mangelfuldt datagrundlag og 5.3.4: Fejlfyldt CPR-data
5.4.3 Eksempel 1: getPersonDetails(<Personnummer>)
I denne variant af getPersonDetails søges på et specifikt CPR-nummer. Findes personen i CPR-registret, returneres de tilhørende CPR-informationer. Findes personen ikke i CPR-registret, returneres et tomt svar.
I dette eksempel vises et kald, og en række mulige svar, afhængigt af søgeresultatet.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<stam:PersonLookupRequest>
<CivilRegistrationNumberPersonQuery>
1234567890
</CivilRegistrationNumberPersonQuery>
</stam:PersonLookupRequest> |
Giver anledning til følgende svar:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<stam:PersonLookupResponse>
<ns:PersonInformationStructure>
<ns1:RegularCPRPerson>
<ns1:SimpleCPRPerson>
<ns2:PersonNameStructure>
<ns3:PersonGivenName>Peter</ns3:PersonGivenName>
<ns3:PersonSurnameName>Andersen</ns3:PersonSurnameName>
</ns2:PersonNameStructure>
<ns1:PersonCivilRegistrationIdentifier>
1234567890
</ns1:PersonCivilRegistrationIdentifier>
…
</ns1:SimpleCPRPerson>
…
<ns6:PersonInformationProtectionIndicator>
false
</ns6:PersonInformationProtectionIndicator>
</ns1:RegularCPRPerson>
<ns:PersonAddressStructure>…</ns:PersonAddressStructure>
</ns:PersonInformationStructure>
</stam:PersonLookupResponse> |
Hvis søgningen ikke giver et positivt resultat, returneres der et tomt svar:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<stam:PersonLookupResponse /> |
...
getPersonDetails understøtter også søgninger på personnavn. Svar ved kald til denne variant er strukturelt identiske med svar ved søgninger på CPR-nummer eller liste af CPR-numre, og der henvises til disse eksempler for svarmuligheder.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<stam:PersonLookupRequest>
<NamePersonQuery>
<ns:PersonGivenName>Anne</ns:PersonGivenName>
<!-- Det er ikke nødvendigt at angive mellemnavn -->
<ns:PersonMiddleName>Søgaard</ns:PersonMiddleName>
<ns:PersonSurnameName>Petersen</ns:PersonSurnameName>
</NamePersonQuery>
</stam:PersonLookupRequest> |
Angives mellemnavnet ikke, ignoreres det og records med matchende for- og efternavn returneres. Se kaldet med en liste af CPR-numre for at se scenariet, hvor flere personelementer returneres.
5.4.5 Kald 3: (Opslag vha. fødselsdato)
getPersonDetails understøtter også søgninger på fødselsdato. Svar ved kald til denne variant er strukturelt identiske med svar ved søgninger på CPR-nummer eller liste af CPR-numre, og der henvises til disse eksempler for svarmuligheder:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<stam:PersonLookupRequest>
<BirthDatePersonQuery>1991-09-22</BirthDatePersonQuery>
</stam:PersonLookupRequest> |
...
getPersonDetails understøtter også søgninger med en liste af CPR-numre som input. For hvert CPR-nummer på listen returneres CPR.informationerne eller et tomt svar, hvis CPR-nummeret ikke findes.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<stam:PersonLookupRequest>
<CivilRegistrationNumberListPersonQuery>
<CivilRegistrationNumber>1111111111</CivilRegistrationNumber>
<CivilRegistrationNumber>2222222222</CivilRegistrationNumber>
<CivilRegistrationNumber>3333333333</CivilRegistrationNumber>
</CivilRegistrationNumberListPersonQuery>
</stam:PersonLookupRequest> |
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<stam:PersonLookupResponse>
<ns:PersonInformationStructure>
…
<ns:PersonCivilRegistrationIdentifier>
1111111111
</ns:PersonCivilRegistrationIdentifier>
…
</ns:PersonInformationStructure>
<ns:PersonInformationStructure>
…
<ns:PersonCivilRegistrationIdentifier>
3333333333
</ns:PersonCivilRegistrationIdentifier>
…
</ns:PersonInformationStructure>
</stam:PersonLookupResponse> |
5.5 CPR-Abonnementsservice
Stamdata tilbyder mulighed for at man for en liste af CPR-numre kan abonnere på ændringer i CPR-registret. Brugen af abonnementsservicen er skarpt opdelt i to snitflader:
- Vedligeholdelse af abonnementslisten (tilføj og slet CPR-numre)
- Udtræk af ændringer for CPR-numrene på listen
Vedligeholdelsen af abonnementslisten er implementeret ved hjælp af den Generiske Opsamlingsservice (GOS), der er en NSP-baseret service til opsamling af informationer af forskellig art. Til brug for abonnementsservicen anvendes en særlig opsamlingstype, der giver mulighed for dels at tilføje, dels at slette CPR-numre fra listen. I afsnittet nedenfor er det angivet, hvordan dette gøres i praksis.
Udtræk af ændringer for CPR-numrene på abonnementslisten fås ved kald til abonnementsservicen, der overvåger CPR-registret og returnerer en liste af CPR-numre, der har fået opdateret oplysninger i CPR-registret siden sidste udtræk. I kaldet kan det også angives at svaret skal indeholde de komplette CPR-oplysninger for de berørte CPR-numre.
Figur 1 – Skitse af det samlede flow ved brug af abonnementsservicen
Detaljeret information om indholdet af forespørgsler og svar for de enkelte kald findes i de følgende afsnit.
5.5.1 Vedligehold af abonnementslisten
Tilføjelse eller sletning af et CPR-nummer på abonnementslisten håndteres ved et kald til GOS med et request, hvor payload overholder dette skema:
| Code Block |
|---|
<src-root>/common/src/main/resources/xsd/stamdata/subscription.xsd |
Ved tilføjelse af et CPR-nummer til abonnementslisten benyttes elementet subscribe som payload. Ved sletning af et CPR-nummer fra abonnementslisten benyttes elementet unsubscribe.
Et eksempel på payload ved tilføjelse af CPR-nummer 1234567890 ser således ud:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<subscribe xmlns="http://nsi.dk/stamdata/2011/09/">
<cpr>1234567890</cpr>
</subscribe> |
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<unsubscribe xmlns="http://nsi.dk/stamdata/2011/09/">
<cpr>1234567890</cpr>
</unsubscribe> |
...
| Code Block |
|---|
<src-root-til-Behandlingsrelations-servicen>/doc/gos/Guide til Anvendere.docx |
5.5.2 Udtræk af ændringer i CPR-data
Der findes to metoder til at få ændringer i CPR-data for CPR-numrene på abonnementslisten:
- getChangedCprs, der returnerer en liste af CPR-numre, for hvilke CPR-data er ændret
- getSubscribedPersonDetails, der returnerer samme liste som getChangedCprs, men som også indeholder CPR-oplysninger for hvert CPR-nummer på listen
Metoderne tager samme input, nemlig en valgfri angivelse af et tidspunkt, hvorfra ændringer skal registreres, men har forskellig output som beskrevet ovenfor. Angives der ikke et tidspunkt, holder abonnementsservicen selv regnskab med hvornår metoderne er kaldt sidst. Hvis der ved første udtræk af ændringer ikke angives et tidspunkt, sætter servicen selv tidspunktet til en fortidig værdi (1. januar 1970).
| Highlight | ||
|---|---|---|
| ||
Bemærk: De to metoder har fælles lagring af seneste tidspunkt for et kald til en given abonnementsliste. Et kald til den ene metode vil derfor medføre, at ved et efterfølgende kald uden tidsangivelse til den anden metode vil tidsstemplet fra det første kald blive anvendt automatisk. Det anbefales derfor at anvendere af abonnementsservicen enten selv holder regnskab med ”siden sidst”, alternativt udelukkende anvender den ene af de to metoder. |
Fælles for begge metoder er at abonnementslisten automatisk identificeres på basis af det medsendte system IDkort. Cvr-nummer angives derfor ikke eksplicit.
Følgende WSDL’er gælder for de to metoder:
- getChangedCprs: cprabbs.wsdl
- getSubscribedPersonDetails: StamdataPersonLookupWithSubscription.wsdl
De to WSDL’er samt relaterede skemadefinitioner kan rekvireres ved henvendelse til NSP-operatøren.
I Bilag A: Eksempel på kald til abonnementsservicen ses et eksempel på request og response ved et kald til getSubscribedPersonDetails, hvor relevante headere er inkluderet i eksemplet. Nedenfor følger et eksempel på et kald til getChangedCprs, hvor kun body er inkluderet i forespørgsel og svar:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<CprAbbsRequest xmlns=”http://nsi.dk/cprabbs/2011/10”>
<since>2008-09-29T03:49:45</since>
</CprAbbsRequest> |
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<CprAbbsResponse xmlns==”http://nsi.dk/cprabbs/2011/10”>
<changedCprs>1234567890</cpr>
<changedCprs>2345678901</cpr>
</CprAbbsResponse> |
6 Ændringslog
Kilden til dette dokument kan fås ved henvendelse til NSP-operatøren.
...
Version
...
Dato
...
Ændring
...
Ansvarlig
...
1.0
...
2011-04-28
...
Initielt Dokument
...
Trifork
...
1.1
...
2011-09-26
...
Opdateret med cpr tjenester
...
Trifork
...
1.2
...
2011-12-01
...
Kvalitetssikring
...
Lakeside
...
1.3
...
2012-06-19
...
Opdateret med bemyndigelse og NPI-SOR relationer
...
Trifork
...
1.4
...
2013-05-14
...
Tilføjet information om krs endpoint url
...
Trifork
...
1.5
...
2013-05-21
...
Opdateret det gode cpr opslag med wsdl og endpoints
...
Trifork
...
1.6
...
2014-05-14
...
Tilføjet beskrivelse af erstatningsværdier i cpr opslag
...
Trifork
...
1.7
...
2014-07-15
...
Opdateret information om adressebeskyttelse
...
Trifork
Bilag A: Eksempel på kald til abonnementsservicen
Nedenfor ses et eksempel på et kald til abonnementsservicen og det tilhørende svar. Eksemplet indeholder komplette headers, inklusiv IDkort, dog er signaturen og certifikatet erstattet med ”[...]”.
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<ns2:Security xmlns:ns10="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/05/13/" xmlns:ns11="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/" xmlns:ns12="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/09/01/" xmlns:ns13="http://rep.oio.dk/ois.dk/xml/schemas/2006/04/25/" xmlns:ns14="http://rep.oio.dk/medcom.sundcom.dk/xml/schemas/2007/02/01/" xmlns:ns15="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/09/01/" xmlns:ns16="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/11/24/" xmlns:ns17="http://www.w3.org/2000/09/xmldsig#" xmlns:ns18="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns19="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns2="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns20="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/01/17/" xmlns:ns21="http://rep.oio.dk/itst.dk/xml/schemas/2005/02/22/" xmlns:ns22="http://nsi.dk/cprabbs/2011/10" xmlns:ns23="http://nsi.dk/2011/09/23/StamdataCpr/" xmlns:ns3="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns4="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/" xmlns:ns5="http://rep.oio.dk/itst.dk/xml/schemas/2006/01/17/" xmlns:ns6="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/" xmlns:ns7="http://rep.oio.dk/itst.dk/xml/schemas/2005/06/24/" xmlns:ns8="http://rep.oio.dk/xkom.dk/xml/schemas/2005/03/15/" xmlns:ns9="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/">
<wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsu:Created>2011-12-08T09:10:31Z</wsu:Created>
</wsu:Timestamp>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" IssueInstant="2011-12-08T09:05:31Z" Version="2.0" id="IDCard">
<saml:Issuer>TheSOSILibrary</saml:Issuer>
<saml:Subject>
<saml:NameID Format="medcom:other">123</saml:NameID>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:2.0:cm:holder-of-key</saml:ConfirmationMethod>
<saml:SubjectConfirmationData>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:KeyName>OCESSignature</ds:KeyName>
</ds:KeyInfo>
</saml:SubjectConfirmationData>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2011-12-08T09:05:31Z" NotOnOrAfter="2011-12-09T09:05:31Z"/>
<saml:AttributeStatement id="IDCardData">
<saml:Attribute Name="sosi:IDCardID">
<saml:AttributeValue>BWMWK+OPPwTlBMxLxucS6w==</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="sosi:IDCardVersion">
<saml:AttributeValue>1.0.1</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="sosi:IDCardType">
<saml:AttributeValue>system</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="sosi:AuthenticationLevel">
<saml:AttributeValue>3</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="sosi:OCESCertHash">
<saml:AttributeValue>pFQXTvhBFAsCwPy2VkYI6GDTnFQ=</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<saml:AttributeStatement id="SystemLog">
<saml:Attribute Name="medcom:ITSystemName">
<saml:AttributeValue>ACME Pro</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="medcom:CareProviderID" NameFormat="medcom:cvrnumber">
<saml:AttributeValue>12345678</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="medcom:CareProviderName">
<saml:AttributeValue>dk</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" id="OCESSignature">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#IDCard">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>IVexeSZomox+Mq9cNYlSp1L+GX8=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>[...]</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>[...]</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
</saml:Assertion>
</ns2:Security>
<ns18:Header xmlns:ns10="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/05/13/" xmlns:ns11="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/" xmlns:ns12="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/09/01/" xmlns:ns13="http://rep.oio.dk/ois.dk/xml/schemas/2006/04/25/" xmlns:ns14="http://rep.oio.dk/medcom.sundcom.dk/xml/schemas/2007/02/01/" xmlns:ns15="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/09/01/" xmlns:ns16="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/11/24/" xmlns:ns17="http://www.w3.org/2000/09/xmldsig#" xmlns:ns18="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns19="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns2="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns20="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/01/17/" xmlns:ns21="http://rep.oio.dk/itst.dk/xml/schemas/2005/02/22/" xmlns:ns22="http://nsi.dk/cprabbs/2011/10" xmlns:ns23="http://nsi.dk/2011/09/23/StamdataCpr/" xmlns:ns3="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns4="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/" xmlns:ns5="http://rep.oio.dk/itst.dk/xml/schemas/2006/01/17/" xmlns:ns6="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/" xmlns:ns7="http://rep.oio.dk/itst.dk/xml/schemas/2005/06/24/" xmlns:ns8="http://rep.oio.dk/xkom.dk/xml/schemas/2005/03/15/" xmlns:ns9="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/">
<medcom:SecurityLevel xmlns:medcom="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">3</medcom:SecurityLevel>
<medcom:Linking xmlns:medcom="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">
<medcom:FlowID>ccfd937c-91bb-4d7e-8772-ea72573cc96c</medcom:FlowID>
<medcom:MessageID>42foobar</medcom:MessageID>
</medcom:Linking>
<medcom:RequireNonRepudiationReceipt xmlns:medcom="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">no</medcom:RequireNonRepudiationReceipt>
</ns18:Header>
</S:Header>
<S:Body>
<ns22:CprAbbsRequest/>
</S:Body>
</S:Envelope> |
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<ns3:Security xmlns:ns2="http://www.w3.org/2000/09/xmldsig#" xmlns:ns3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns4="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns5="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/" xmlns:ns6="http://rep.oio.dk/itst.dk/xml/schemas/2006/01/17/" xmlns:ns7="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/" xmlns:ns8="http://rep.oio.dk/itst.dk/xml/schemas/2005/06/24/" xmlns:ns9="http://rep.oio.dk/xkom.dk/xml/schemas/2005/03/15/" xmlns:ns10="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/" xmlns:ns11="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/05/13/" xmlns:ns12="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/" xmlns:ns13="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/09/01/" xmlns:ns14="http://rep.oio.dk/ois.dk/xml/schemas/2006/04/25/" xmlns:ns15="http://rep.oio.dk/medcom.sundcom.dk/xml/schemas/2007/02/01/" xmlns:ns16="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/09/01/" xmlns:ns17="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/11/24/" xmlns:ns18="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns19="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns20="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/01/17/" xmlns:ns21="http://rep.oio.dk/itst.dk/xml/schemas/2005/02/22/" xmlns:ns22="http://nsi.dk/cprabbs/2011/10" xmlns:ns23="http://nsi.dk/2011/09/23/StamdataCpr/">
<ns19:Timestamp>
<ns19:Created>2011-12-08T09:10:32Z</ns19:Created>
</ns19:Timestamp>
</ns3:Security>
<ns18:Header xmlns:ns2="http://www.w3.org/2000/09/xmldsig#" xmlns:ns3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns4="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns5="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/" xmlns:ns6="http://rep.oio.dk/itst.dk/xml/schemas/2006/01/17/" xmlns:ns7="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/" xmlns:ns8="http://rep.oio.dk/itst.dk/xml/schemas/2005/06/24/" xmlns:ns9="http://rep.oio.dk/xkom.dk/xml/schemas/2005/03/15/" xmlns:ns10="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/" xmlns:ns11="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/05/13/" xmlns:ns12="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/" xmlns:ns13="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/09/01/" xmlns:ns14="http://rep.oio.dk/ois.dk/xml/schemas/2006/04/25/" xmlns:ns15="http://rep.oio.dk/medcom.sundcom.dk/xml/schemas/2007/02/01/" xmlns:ns16="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/09/01/" xmlns:ns17="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/11/24/" xmlns:ns18="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns19="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns20="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/01/17/" xmlns:ns21="http://rep.oio.dk/itst.dk/xml/schemas/2005/02/22/" xmlns:ns22="http://nsi.dk/cprabbs/2011/10" xmlns:ns23="http://nsi.dk/2011/09/23/StamdataCpr/">
<ns18:Linking>
<ns18:FlowID>ccfd937c-91bb-4d7e-8772-ea72573cc96c</ns18:FlowID>
<ns18:MessageID>743e57ca-f3c2-462a-9fd3-f54e8414dfbd</ns18:MessageID>
<ns18:InResponseToMessageID>42foobar</ns18:InResponseToMessageID>
</ns18:Linking>
<ns18:FlowStatus>flow_finalized_succesfully</ns18:FlowStatus>
</ns18:Header>
</S:Header>
<S:Body>
<ns23:PersonLookupResponse xmlns:ns2="http://www.w3.org/2000/09/xmldsig#" xmlns:ns3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns4="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns5="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2003/02/13/" xmlns:ns6="http://rep.oio.dk/itst.dk/xml/schemas/2006/01/17/" xmlns:ns7="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/" xmlns:ns8="http://rep.oio.dk/itst.dk/xml/schemas/2005/06/24/" xmlns:ns9="http://rep.oio.dk/xkom.dk/xml/schemas/2005/03/15/" xmlns:ns10="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/03/15/" xmlns:ns11="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/05/13/" xmlns:ns12="http://rep.oio.dk/xkom.dk/xml/schemas/2006/01/06/" xmlns:ns13="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/09/01/" xmlns:ns14="http://rep.oio.dk/ois.dk/xml/schemas/2006/04/25/" xmlns:ns15="http://rep.oio.dk/medcom.sundcom.dk/xml/schemas/2007/02/01/" xmlns:ns16="http://rep.oio.dk/ebxml/xml/schemas/dkcc/2005/09/01/" xmlns:ns17="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/11/24/" xmlns:ns18="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns19="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns20="http://rep.oio.dk/cpr.dk/xml/schemas/core/2006/01/17/" xmlns:ns21="http://rep.oio.dk/itst.dk/xml/schemas/2005/02/22/" xmlns:ns22="http://nsi.dk/cprabbs/2011/10" xmlns:ns23="http://nsi.dk/2011/09/23/StamdataCpr/">
<ns15:PersonInformationStructure>
<ns15:CurrentPersonCivilRegistrationIdentifier>0201270145</ns15:CurrentPersonCivilRegistrationIdentifier>
<ns20:RegularCPRPerson>
<ns20:SimpleCPRPerson>
<ns6:PersonNameStructure>
<ns5:PersonGivenName>Peter</ns5:PersonGivenName>
<ns5:PersonMiddleName>Sigurd</ns5:PersonMiddleName>
<ns5:PersonSurnameName>Andersen</ns5:PersonSurnameName>
</ns6:PersonNameStructure>
<ns7:PersonCivilRegistrationIdentifier>0101822231</ns7:PersonCivilRegistrationIdentifier>
</ns20:SimpleCPRPerson>
<ns21:PersonNameForAddressingName>Peter,Andersen</ns21:PersonNameForAddressingName>
<ns5:PersonGenderCode>male</ns5:PersonGenderCode>
<ns17:PersonInformationProtectionIndicator>false</ns17:PersonInformationProtectionIndicator>
<ns17:PersonBirthDateStructure>
<ns10:BirthDate>2011-12-06+01:00</ns10:BirthDate>
<ns17:BirthDateUncertaintyIndicator>false</ns17:BirthDateUncertaintyIndicator>
</ns17:PersonBirthDateStructure>
<ns20:PersonCivilRegistrationStatusStructure>
<ns17:PersonCivilRegistrationStatusCode>1</ns17:PersonCivilRegistrationStatusCode>
<ns20:PersonCivilRegistrationStatusStartDate>2011-12-07+01:00</ns20:PersonCivilRegistrationStatusStartDate>
</ns20:PersonCivilRegistrationStatusStructure>
</ns20:RegularCPRPerson>
<ns15:PersonAddressStructure>
<ns8:CareOfName>Søren Petersen</ns8:CareOfName>
<ns12:AddressComplete>
<ns9:AddressAccess>
<ns7:MunicipalityCode>0461</ns7:MunicipalityCode>
<ns7:StreetCode>0234</ns7:StreetCode>
<ns5:StreetBuildingIdentifier>10A</ns5:StreetBuildingIdentifier>
</ns9:AddressAccess>
<ns12:AddressPostal>
<ns10:StreetName>Ørstedgade</ns10:StreetName>
<ns7:StreetNameForAddressingName>Østergd.</ns7:StreetNameForAddressingName>
<ns5:StreetBuildingIdentifier>10A</ns5:StreetBuildingIdentifier>
<ns5:FloorIdentifier>12</ns5:FloorIdentifier>
<ns5:SuiteIdentifier>tv</ns5:SuiteIdentifier>
<ns10:DistrictSubdivisionIdentifier>Birkely</ns10:DistrictSubdivisionIdentifier>
<ns10:PostCodeIdentifier>6666</ns10:PostCodeIdentifier>
<ns10:DistrictName>Überwald</ns10:DistrictName>
</ns12:AddressPostal>
</ns12:AddressComplete>
<ns14:CountyCode>1083</ns14:CountyCode>
</ns15:PersonAddressStructure>
</ns15:PersonInformationStructure>
<ns15:PersonInformationStructure>
<ns15:CurrentPersonCivilRegistrationIdentifier>1302642907</ns15:CurrentPersonCivilRegistrationIdentifier>
<ns20:RegularCPRPerson>
<ns20:SimpleCPRPerson>
<ns6:PersonNameStructure>
<ns5:PersonGivenName>Peter</ns5:PersonGivenName>
<ns5:PersonMiddleName>Sigurd</ns5:PersonMiddleName>
<ns5:PersonSurnameName>Andersen</ns5:PersonSurnameName>
</ns6:PersonNameStructure>
<ns7:PersonCivilRegistrationIdentifier>0101821234</ns7:PersonCivilRegistrationIdentifier>
</ns20:SimpleCPRPerson>
<ns21:PersonNameForAddressingName>Peter,Andersen</ns21:PersonNameForAddressingName>
<ns5:PersonGenderCode>male</ns5:PersonGenderCode>
<ns17:PersonInformationProtectionIndicator>false</ns17:PersonInformationProtectionIndicator>
<ns17:PersonBirthDateStructure>
<ns10:BirthDate>2011-12-06+01:00</ns10:BirthDate>
<ns17:BirthDateUncertaintyIndicator>false</ns17:BirthDateUncertaintyIndicator>
</ns17:PersonBirthDateStructure>
<ns20:PersonCivilRegistrationStatusStructure>
<ns17:PersonCivilRegistrationStatusCode>1</ns17:PersonCivilRegistrationStatusCode>
<ns20:PersonCivilRegistrationStatusStartDate>2011-12-07+01:00</ns20:PersonCivilRegistrationStatusStartDate>
</ns20:PersonCivilRegistrationStatusStructure>
</ns20:RegularCPRPerson>
<ns15:PersonAddressStructure>
<ns8:CareOfName>Søren Petersen</ns8:CareOfName>
<ns12:AddressComplete>
<ns9:AddressAccess>
<ns7:MunicipalityCode>0461</ns7:MunicipalityCode>
<ns7:StreetCode>0234</ns7:StreetCode>
<ns5:StreetBuildingIdentifier>10A</ns5:StreetBuildingIdentifier>
</ns9:AddressAccess>
<ns12:AddressPostal>
<ns10:StreetName>Ørstedgade</ns10:StreetName>
<ns7:StreetNameForAddressingName>Østergd.</ns7:StreetNameForAddressingName>
<ns5:StreetBuildingIdentifier>10A</ns5:StreetBuildingIdentifier>
<ns5:FloorIdentifier>12</ns5:FloorIdentifier>
<ns5:SuiteIdentifier>tv</ns5:SuiteIdentifier>
<ns10:DistrictSubdivisionIdentifier>Birkely</ns10:DistrictSubdivisionIdentifier>
<ns10:PostCodeIdentifier>6666</ns10:PostCodeIdentifier>
<ns10:DistrictName>Überwald</ns10:DistrictName>
</ns12:AddressPostal>
</ns12:AddressComplete>
<ns14:CountyCode>1083</ns14:CountyCode>
</ns15:PersonAddressStructure>
</ns15:PersonInformationStructure>
</ns23:PersonLookupResponse>
</S:Body>
</S:Envelope> |
...