Page History
...
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.
...
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 | |
PostCodeIdentifier | 0000 |
StandardAddressIdentifier | UKENDT |
TelephoneSubscriberIdentifier | 00000000 |
5.3.4 Fejlfyldt CPR-data
...
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 |
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).
...
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 Mangelfuld data : 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> 1234567890 </CivilRegistrationNumberPersonQuery> |
...
</stam:PersonLookupRequest> |
Giver anledning til følgende svar:
Code Block | ||||
---|---|---|---|---|
|
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
...
1234567890 </ns1:PersonCivilRegistrationIdentifier> |
...
…
...
… </ns1:SimpleCPRPerson> |
...
…
<ns6:PersonInformationProtectionIndicator>
false
...
… <ns6:PersonInformationProtectionIndicator> false </ns6:PersonInformationProtectionIndicator> |
...
</ns1:RegularCPRPerson> |
...
<ns:PersonAddressStructure>…</ns:PersonAddressStructure> |
...
</ns:PersonInformationStructure> |
...
</stam:PersonLookupResponse> |
Svar 2: (Personen blev ikke fundet)
Hvis søgningen ikke giver et positivt resultat, returneres der et tomt svar:
<stam:PersonLookupResponse />
...
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<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.
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> |
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.
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> |
Et eksempel på payload ved sletning af CPR-nummer 1234567890 ser således ud:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<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:
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> |