1 Formål

Dokument målrettet systemadministratorer og driftspersoner, som skal kunne håndtere driftsmæssige aspekter af komponenten. Driftsvejledningen skal indeholde information om komponentens version, standard placering af logfiler og konfigurationsfiler, eksterne afhængigheder, og evt. krav til genstart af applikationer hvis komponenten bliver ikke-responsiv. Start/stop vejledning for komponenten beskrives, herunder hvilke andre applikationer der evt. skal genstartes. Kendte fejlkoder som skrives i logfiler dokumenteres, så disse evt. kan overvåges, og tillige danne baggrund for fejlsøgning. En generel læsevejledning til logfiler vedlægges. Det bør angives hvorledes komponenten bedst lader sig overvåge, dvs. en generisk beskrivelse af overvågningen, der ikke er værktøjsafhængig. Evt. specielle krav til backup beskrives, ligesom procedure ved reetablering af komponenten ud fra backup beskrives.

2 Omfattede komponenter

Dette dokument omfatter driften af alle Stamdata importer komponenterne

Listen herunder beskriver hver komponent med type status URL og navnet på filen som skal deployes. Status URL’en kan løbende polles for at checke komponentens status. Status sider er beskrevet mere detaljeret senere i dokumentet.

2.1 Stamdata importer komponenter

2.1.1 Stamdata Data Importere

Hver stamdata importer ligger i sin egen WAR fil, hver importer har sin egen overvågnings URL, der enten fortæller om den enkelte importer er operationsdygtig (HTTP 200 OK), eller om der er fejl i importeren (HTTP 500 ERROR), Overvågningssiden vil give et bud på hvad fejlen er, dog bør man kigge i log-filen for at få alle detaljer med.

Type: Batch

Status Url: http://<hostname>:<port>/<komponent-navn>/
Filnavn: <komponent>.war

3 Opdatering til nye versioner

Når nye versioner af Stamdata komponenterne udkommer, vil der medfølge release notes som forklarer database-migrering, rollback-procedure, service vinduer mv. Til installation af første version af stamdata komponenterne henvises til installationsguiden.

4 Daglig Drift

4.1 Stamdata Importere

Stamdataimporterne er en gruppe filparsere og batch jobs som indlæser og vedligeholder data fra forskellige registre og gemmer dem i en MySQL database. Hver importer har sin egen inbox-mappe som automatisk oprettes når servicen startes. Roden for disse inboxmapper er:

<JBOSS_HOME>/domain/data/sdm4/

Komponenten kigger i sin inboxmappe for at se om der kommer nye filer til import. Det er driftens opgave at placere filer i inboxmapperne når tiden er inde for en opdatering. Hvilke filer der skal bruges og hvor ofte registrene skal opdateres er beskrevet i slutningen af dokumentet. Hver inbox er logisk navngivet efter den tilhørende importer. Se afsnittet om overvågning for monitorering af servicen

4.1.1 Fremgangsmåde for indlæsning af nye data

Parserne forventer data at blive lagt i undermapper af deres rod-mappe, f.eks.:

<JBOSS_HOME>/domain/data/sdm4/<importer>/20120822T201121S231/<file.txt>

<JBOSS_HOME>/domain/data/sdm4/<importer>/20120822T201121S231/<file2.txt>

Undermappernes navne er underordnede. De importeres i leksikografisk orden, og det vil derfor være oplagt at lægge dem så undermappernes navne er tidsstempler som vist i eksemplet.

Skulle der ske en fejl under import, vil der blive lagt en fil ved navn

"LOCKED" i parserens inbox, f.eks.:

<JBOSS_HOME>/domain/data/sdm4/<importer>/LOCKED

Parseren vil ikke forsætte før denne fil er slettet manuelt. Fejl-beskeden kan findes i loggen.

4.1.2 Eksempel for import af nye CPR-data

Her en et eksempel på strukturen for en parsers filsystem. I dette tilfælde er det CPR-parseren:

<JBOSS_HOME>/domain/data/sdm4/cprimporter/

Placeres filen ’D100312.L431101’ (som er en typisk CPR Person fil) i inputmappen begynder parseren at stabilisere data. Man kan gå ind på komponentens monitoreringsside for at se status for import:

http://<hostname>:<port>/cprimporter/status

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

Det er muligt at lave onlineopslag i stamdataservicens kopi af Sundhedsstyrelsens autorisationsregister til fremsøgning af eventuelle autorisationer for en given sundhedsfaglig person. Metoden tager personens CPR-nummer som input, og returnerer personens navn og samtlige autorisationer, der er i kraft for vedkommende [2].

[2] Servicen giver et øjebliksbillede af personens autorisationer, dvs. udløbne og fremtidige autorisationer returneres ikke.

En person kan have flere gyldige autorisationer. Hver autorisation som bliver returneret fra webservicen er forbundet med en uddannelseskode. Tabellen nedenfor viser en liste over kendte uddannelseskoder og deres tilknyttede uddannelse. Der henvises til Sundhedsstyrelsens løbende vedligeholdte liste af uddannelser, hvortil der udstedes sundhedsfaglige autorisationer for yderligere information (http://autregwebservice.sst.dk/autregservice.asmx). Faggruppenavnet bliver også returneret såfremt uddannelseskoden er kendt af enkeltopslagsservicen.

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

Hvis CPR-nummeret fra forespørgselen er tilknyttet en eller flere autorisationer vil også for- og efternavn for personen blive returneret. Forespørges der på et ugyldigt CPR-nummer eller en person uden gyldige autorisationer returneres der af sikkerhedshensyn tomme navnefelter i svaret – også selv om CPR-nummeret er et korrekt CPR-nummer for en eksisterende person.

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.

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

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

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

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

https://fisheye.nspop.dk/browse/public/components/sdm/latest/code/nsp/cpr-ws/src/main/webapp/WEB-INF/wsdl

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

Yderligere indeholder datagrundlaget i nogle tilfælde emailadresser, som ikke overholder reglerne i wsdl-skemaet. Hvis dette er tilfældet vil emailadressen fjernes fra svaret.

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	UKENDT@example.com
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:

<src-root>/Dokumentation/bilag/StamdataPersonLookupService/

Eller direkte på driftsoperatørens SVN:

https://fisheye.nspop.dk/browse/public/components/sdm/latest/code/nsp/cpr-ws/src/main/webapp/WEB-INF/wsdl/

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 første endpoint findes kun af hensyn til bagud kompatibilitet og anvender wsdl-filer, som ligger i mappen: PERSONLOOKUP_1.0.0.

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.

<stam:PersonLookupRequest>
  <CivilRegistrationNumberPersonQuery>
    1234567890
  </CivilRegistrationNumberPersonQuery>
</stam:PersonLookupRequest>

Giver anledning til følgende svar:

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

<stam:PersonLookupResponse />

5.4.4 Kald 2: (Opslag vha. navn)

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.

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

<stam:PersonLookupRequest>
    <BirthDatePersonQuery>1991-09-22</BirthDatePersonQuery>
</stam:PersonLookupRequest>

5.4.6 Kald 4: (Opslag vha. en liste af CPR-numre)

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.

<stam:PersonLookupRequest>
  <CivilRegistrationNumberListPersonQuery>
    <CivilRegistrationNumber>1111111111</CivilRegistrationNumber>
    <CivilRegistrationNumber>2222222222</CivilRegistrationNumber>
    <CivilRegistrationNumber>3333333333</CivilRegistrationNumber>
  </CivilRegistrationNumberListPersonQuery>
</stam:PersonLookupRequest>

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

NSP services > SDM - Driftsvejledning > 123.png

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:

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

<subscribe xmlns="http://nsi.dk/stamdata/2011/09/">
   <cpr>1234567890</cpr>
</subscribe>

Et eksempel på payload ved sletning af CPR-nummer 1234567890 ser således ud:

<unsubscribe xmlns="http://nsi.dk/stamdata/2011/09/">
   <cpr>1234567890</cpr>
</unsubscribe>

Generel information om, hvordan GOS’ens services kaldes, herunder reference til den tilhørende WSDL, findes i dette dokument:

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

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.
Det bemærkes endvidere, at både abonnementslister og tidspunkterne for kald til udtræksmetoderne deles på tværs af samtlige NSP-instanser ved brug af platformens replikeringsmekanisme. Da disse to replikeringer ikke foretages øjeblikkeligt, skal man som klient være forberedt på, at fremtidige requests der foretages tidsmæssigt tæt på det oprindelige, kan returnere cpr-numre, man har set ved tidligere kald.

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:

<CprAbbsRequest xmlns=”http://nsi.dk/cprabbs/2011/10”>
         <since>2008-09-29T03:49:45</since>
</CprAbbsRequest>

<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 ”[...]”.

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

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