1      Formål

Nærværende dokument indgår i den samlede dokumentationspakke for stamdataregistret på NSP. Dokumentationspakken giver tilsammen det fulde overblik over dokumentationen. ”Guide til anvendere” er målrettet udviklere og arkitekter hos leverandører, som ønsker at anvende funktionaliteten udstillet af stamdataservicen. Guiden kan indeholde kodeeksempler, interaktionsbeskrivelser, servicebeskrivelser, snitfladebeskrivelser mv.

1       Formål

Nærværende dokument indgår i den samlede dokumentationspakke for stamdataregistret på NSP. Dokumentationspakken giver tilsammen det fulde overblik over dokumentationen.

”Guide til anvendere” er målrettet udviklere og arkitekter hos leverandører, som ønsker at anvende funktionaliteten udstillet af stamdataservicen. Guiden indeholder snitfladebeskrivelser,

Guiden kan indeholde kodeeksempler, interaktionsbeskrivelser, servicebeskrivelser, snitfladebeskrivelser mv.

2       Introduktion til Stamdataservicen

Stamdataservicen er en national service udstillet på NSP, som giver adgang til relevante nationale stamdataregistre, opsamlet af NSP fra forskellige myndigheder og dataansvarlige enheder.

Stamdataservicen udstiller flere snitflader, der tilsammen giver mulighed for både at holde komplette lokale kopier af stamdataregistrene ajour og for at lave enkeltopslag i udvalgte registre. For en overordnet beskrivelse af den udstillede funktionalitet henvises der til Arkitektur og Design, der på lige fod med nærværende dokument indgår i den samlede dokumentationspakke for stamdataservicen.

2.1     Adgang til Stamdataservicens funktionalitet

Anvendelse af stamdataservicen forudsætter en aftale med NSP-operatøren. Yderligere oplysninger om betingelserne for anvendelse af stamdataservicen, herunder håndtering af dataansvar og tekniske forudsætninger, kan fås ved henvendelse til NSP-operatørens servicedesk (http://nsp.nsi.dk).

Adgangen til funktionaliteten er styret i flere ”lag”, idet de enkelte stamdataregistre indeholder forskelligartet information, og kan være styret af forskellige politikker. I praksis styres adgangen gennem whitelists på CVR nummer niveau[1] for de enkelte services.

Alle snitflader udstillet af stamdataservicen er baseret på Den Gode Web-Service 1.0.1 (DGWS 1.0.1), med  følgende undtagelser:

• Personinformation servicen, som er en national standard for identitetsbaserede webservices i sundhedssektoren.
• DetGodeCPROpslag-1.0.4.1a, som udstiller IDWS-snitflader
• StamdataPersonLookup-1.2.0, som også udstiller IDWS-snitflader

I forhold til stamdataservicen forudsættes der autentifikation på DGWS niveau 3, dvs. brug af STS-signerede system-IDkort.

NSI leverer gratis biblioteksunderstøttelse af store dele af webservice kommunikationen, herunder generering og parsning af IDkort og headere. Der henvises til DGWS dokumentationen (http://www.medcom.dk/wm110731) for generel information om DGWS og SEAL dokumentationen (http://www.sosi.dk/twiki/bin/view/ProjectManagement/SOSIProducts) for generel information om biblioteksunderstøttelsen.

3       Kopiregisterservicen (SKRS) og Registerfleropslagsservicen (SRFS)

Kopiregisterservicen (SKRS) giver systemer mulighed for at etablere og ajourføre en lokal kopi af et register, som f.eks. CPR-registret eller autorisationsregistret. Registerfleropslagsservicen (SRFS) giver systemer mulighed for at lave opslag på en mængde af objekter ud fra deres id'er. F.eks. en mængde Person-objekter fra Person-registret ud fra deres CPR-nummer.

Som beskrevet i afsnit 2.1 er det nødvendigt at etablere en aftale hos NSP-operatøren for at få adgang til de respektive registre. Præcist hvilke registre og data-typer man får adgang til er afhængigt af aftalen. Der henvises til dokumentet Design og Arkitektur for en oversigt over hvilke registre, KRS pt. kan levere data fra.

En komplet gennemgang af tilgængelige registre, datatyper samt versioner er at finde i dokumentet ”Registerspecifikation for Anvendere”.

3.1.1     Struktur af kald til KRS

Kopiregisterservicen tager følgende input:

Kaldet til Kopiregisterservicen er formelt specificeret i WSDL’en stamdata_krs.wsdl, der kan rekvireres ved henvendelse til NSP-operatøren.

3.1.2     Struktur af kald til RFS

Kopiregisterservicen tager følgende input:

Kaldet til Fleropslagsservicen er formelt specificeret i WSDL’en stamdata_rfs.wsdl, der kan rekvireres ved henvendelse til NSP-operatøren.

3.2     Fejlsituationer

Hvis der er en fejl i forespørgslen, eller der opstår en fejl på serveren, vil servicen returnere en fejlmelding af typen ReplicationFault med en beskrivelse af fejlen (jævnfør WSDL som specificeret i ovenstående afsnit). Hvis forespørgslen går godt, returnerer servicen en besked af typen ReplicationResponse, der indeholder et ”any”-element. Dette any-element er af typen atom baseret på ATOM 1.0 [RFC4287]. ATOM er en syndikeringsprotokol og designet til at holde styr på ændringer i en ressource. I dette tilfælde er ressourcerne datatyperne i et register. Hvordan dette atom-element skal tolkes er forklaret nærmere i afsnit 3.6.

3.3     Endpoint URL

Kopi register servicen er som udgangspunkt konfigureret på

<hostnavn>:8080/stamdata-batch-copy-ws/service/StamdataReplication

og wsdl kan hentes ved at sætte ?wsdl efter, altså:

<hostnavn>:8080/stamdata-batch-copy-ws/service/StamdataReplication?wsdl

Fleropslagssservicen er som udgangspunkt konfigureret på

<hostnavn>:8080/stamdata-batch-copy-ws-rfs/service/StamdataReplication

og wsdl kan hentes ved at sætte ?wsdl efter, altså:

<hostnavn>:8080/stamdata-batch-copy-ws-rfs/service/StamdataReplication?wsdl

3.4.1     Eksempel på kald til KRS

Som klient sender man et ReplicationRequest til servicen.

Forespørgsel:

<?xml version="1.0" encoding="UTF-8"?>

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">

  <S:Header>

                    …

  </S:Header>

  <S:Body>

    <ns1:ReplicationRequest xmlns:ns1="http://nsi.dk/2011/10/21/StamdataKrs/">

      <register>cpr</register>

      <datatype>person</datatype>

      <version>1</version>

      <registerVersion>1</registerVersion>

      <offset>0</offset>

    </ns1:ReplicationRequest>

  </S:Body>

</S:Envelope>

Headeren skal indeholde en DGWS 1.0.1 header.

Bemærk at registerVersion-parameteren er frivillig. Hvis den udelades, svarer det til angive værdien 1.

Hvis alt går som forventet og forespørgslen bliver godkendt modtages et svar:

Svar:

<?xml version="1.0" encoding="UTF-8"?>

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">

  <S:Header>

                    …

  </S:Header>

  <S:Body>

    <ns1:ReplicationResponse xmlns:ns1="http://nsi.dk/2011/10/21/StamdataKrs/">

      <atom:feed xmlns:atom="http://www.w3.org/2005/Atom" xmlns="http://nsi.dk/-/stamdata/3.0/cpr">

        <atom:id>tag:nsi.dkersonLookupWithSubscriptionIntegrationTest.java,2011:cpr/person/v1</atom:id>

        <atom:updated>2011-10-25T07:02:08.045Z</atom:updated>

        <atom:title>Stamdata Registry Feed</atom:title>

        <atom:author>

          <atom:name>National Sundheds IT</atom:name>

        </atom:author>

                    …

      </atom:feed>

    </ns1:ReplicationResponse>

  </S:Body>

</S:Envelope>

Opstår der derimod en fejl, bliver en DGWS 1.0.1 Fault sendt tilbage, f.eks.:

Fejl:

<soapenv:Envelope ...>

  <soapenv:Header>...</soapenv:Header>

  <soapenv:Body>

  <soapenv:Fault>

     <faultcode>Server</faultcode>

     <detail>

       <medcom:FaultCode>expired_idcard</medcom:FaultCode>

     </detail>

     <faultstring>The ID card has expired.</faultstring>

   </soapenv:Fault>

   </soapenv:Body>

</soapenv:Envelope>

3.4.2     Eksempel på kald til RFS

Som klient sender man et ReplicationRequest til servicen.

Forespørgsel:

<?xml version="1.0" encoding="UTF-8"?>

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">

  <S:Header>

                    …

  </S:Header>

  <S:Body>

    <ns1:ReplicationRequest xmlns:ns1="http://nsi.dk/2021/03/03/StamdataRfs/">
        <register>cpr</register>
       <datatype>person</datatype>
       <version>1</version>
       <registerVersion>1</registerVersion>
       <idList>
           <id>1112579876</id>
           <id>2211657418</id>
       </idList>
   </ns1:ReplicationRequest>

  </S:Body>

</S:Envelope>

Headeren skal indeholde en DGWS 1.0.1 header.

Strukturen af responses og faults er den samme som for KRS, og vil gerfor ikke blive gennemgået igen.

3.5     Detaljeret svar fra KRS

Her følger et mere detaljeret output fra KRS. Tolkning af dette er beskrevet i afsnittet efter.

  <atom:feed xmlns:atom="http://www.w3.org/2005/Atom" xmlns="http://nsi.dk/-/stamdata/3.0/cpr">

    <atom:id>tag:nsi.dk,2011:cpr/person/v1</atom:id>

    <atom:updated>2011-11-07T09:56:12.278Z</atom:updated>

    <atom:title>Stamdata Registry Feed</atom:title>

    <atom:author>

      <atom:name>National Sundheds IT</atom:name>

    </atom:author>

    <atom:entry>

      <atom:id>tag:nsi.dk,2011:cpr/person/v1/13206597710000000085</atom:id>

      <atom:title/>

      <atom:updated>2011-11-07T09:56:11.000Z</atom:updated>

      <atom:content type="application/xml">

        <person>

          <cpr>0102451234</cpr>

          <koen>M</koen>

          <fornavn>Hans</fornavn>

          <mellemnavn/>

          <efternavn>Hansen</efternavn>

          <coNavn></coNavn>

          <lokalitet/>

          <vejnavn>Ligusterv&#xE6;nget</vejnavn>

          <bygningsnummer>42</bygningsnummer>

          <husnummer>123</husnummer>

          <etage>12</etage>

          <sideDoerNummer>th.</sideDoerNummer>

          <bynavn>Enby</bynavn>

          <postnummer>1448</postnummer>

          <postdistrikt>N&#xF8;ddebo</postdistrikt>

          <status>01</status>

          <gaeldendeCPR>3105459876</gaeldendeCPR>

          <foedselsdato>1947-12-24T00:00:00+01:00</foedselsdato>

          <stilling/>

          <vejKode>740</vejKode>

          <kommuneKode>314</kommuneKode>

          <validFrom>2011-11-07T10:56:21+01:00</validFrom>

          <validTo>2012-11-07T10:56:11+01:00</validTo>

        </person>

      </atom:content>

    </atom:entry>

  </atom:feed>

3.6     Parsing af output

Responset fra SKRS og SRFS består af et antal metadata-felter, som indeholder overordnet information om de data der er i responset, samt en række entry-elementer. Et entry-element beskriver hvordan et forretningsobjekt så ud i en bestemt periode, repræsenteret ved ValidFrom- og ValidTo-felterne. Med forretningsobjekt menes her en instans af en datatype. Et forretningsobjekt er f.eks. instansen af datatypen 'Person' i CPR-registret med cpr-nummer '0102451234'. Et forretningsobjekt beskrives således af et antal entry-elementer, ét for hver version.

Et udtræk indeholder den fulde historik for det register der forespørges på.

3.6.1     Unikke nøgler

Hver datatype har en nøgle, som identificerer et forretningsobjekt. F.eks. identificeres et Person-objekt i CPR-registret ved sit CPR-nummer. Unikke nøgler for de enkelte datatyper er beskrevet i listen over registre i dokumentet "Registerspecifikation for Anvendere”.

3.6.2     Revisionsnumre

Hvert entry-element indeholder et revisionsnummer, som unikt identificerer den version af forretningsobjektet, der ligger under content-elementet. Dette kan sammenlignes med en primærnøgle i en database, som identificerer en bestemt række.

Revisionsnummeret ligger under entry'ets id-element. I eksemplet fra afsnit 3.5 er der f.eks. følgende id-element, hvor revisionsnummeret er markeret med rød.

<atom:id>tag:nsi.dk,2011:cpr/person/v1/13206597710000000085</atom:id>

3.6.3     ValidFrom- og ValidTo-elementer

Et forretningsobjekt kan have flere versioner, hvilket er repræsenteret med elementerne ValidFrom og ValidTo. Et forretningsobjekt kan ikke have versioner med overlappende gyldighedsperioder, og der kan ikke være "huller" i historikken. Der gives ingen garanti for, hvor langt tilbage historikken rækker.

Bemærk at der kun returneres historiske versioner i SKRS. SRFS returnerer altid den gældende version af et objekt.

F.eks. for datatypen Person, hvis forretningsobjekter identificeres af CPR-numre, kan en ændring af efternavn resultere i følgende versioner:

<person>
          <cpr>0102451234</cpr>
          ...
          <efternavn>Hansen</efternavn>
          ...
          <validFrom>2000-01-01T01:01:01+01:00</validFrom>
          <validTo>2010-10-10T10:10:10+01:00</validTo>
</person>

<person>
          <cpr>0102451234</cpr>
          ...
          <efternavn>Jensen</efternavn>
          ...
          <validFrom>2010-10-10T10:10:10+01:00</validFrom>
          <validTo>2999-01-01T00:00:00+01:00</validTo>
</person>

3.6.4     DateTime

Data af typen DateTime i svaret fra SKRS vil som udgangspunkt være angivet i lokal tidszone, f.eks. '2018-07-11T08:16:47+02:00'. Der kan dog være tilfælde hvor der anvendes UTC, og anvendere skal derfor kunne håndtere begge datoformater.

3.7     Paginering

Svaret fra SKRS kan maksimalt indeholde et fast antal entry-elementer, da det ikke er praktisk muligt at sende indholdet af et helt register på én gang. Størrelsen af responset kan styres med request-parameteren maxRecords. Servicen har dog en øvre grænse, som træder i kraft hvis parameteren er for stor.

Man angiver hvilken side man er interesseret i ved at udfylde offset-parameteren i requestet, som er et revisionsnummer (se afsnit 3.6.2). For at lave et fuldt udtræk sender man således først et request med offset 0, derefter med det sidste revisionsnummer man modtog i responset, og så fremdeles. På et tidspunkt vil svaret være tomt, og man er således færdig med at hente data.

Bemærk at pagineringsmekanismen kan bruges til at lave deltaudtræk, f.eks. hver nat, ved at man holder styr på det seneste revisionsnummer man har modtaget.

Bemærk i øvrigt at der ikke kan anvendes paginering i SRFS.

3.8 Opslagskolonner i SRFS

Dette afsnit beskriver hvilke opslagsmuligheder der tilbydes i SRFS.

Kolonnerne 'Register' og 'Datatype' angiver hvilket register og datatype, der er mulighed for at slå op på. Kolonnen 'Opslagskolonne' indeholder navnet en kolonne, der kan laves opslag på. En oversigt over tabeller kan findes her. Der er pt. kun mulighed for opslag på en enkelt kolonne per datatype.

4       Registre

Der henvises til arkitekturmodellen for en liste over registerbeskrivelser.

5       Enkeltopslag i registre

Stamdataservicen tilbyder en service til såkaldte enkeltopslag i følgende registre:

• Autorisationsregistret
• CPR registret
• Yderregistret

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 IDkort (dvs. DGWS niveau 3).

PersonInformation servicen er dog en undtagelse da dette er en REST baseret service der kun er tilgængelig internt på NSP. Derfor har denne service ikke nogen sikkerhedsprotokol.

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. Der er fire services:

• AuthorizationService
• AuthorizationService-20240105
• AuthorizationCodeService
• AuthorizationCodeService-20240105

De første to tager henholdsvis personens CPR nummer som input og de sidste to tager Autorisationsnummer som input. De  returnerer alle personens navn og samtlige autorisationer der er i kraft for vedkommende. Svaret fra 20240105-snitfladerne indeholder samtlige oplysninger om autorisationerne der er tilgængelige fra autorisationsregisteret. 

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.

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     Endpoints

Der findes følgende endpoints:

• http://stamdatahost:8080/stamdata-authorization-lookup-ws/service/AuthorizationService?wsdl
• http://stamdatahost:8080/stamdata-authorization-lookup-ws/service/AuthorizationCodeService?wsdl
• http://stamdatahost:8080/stamdata-authorization-lookup-ws/service/AuthorizationService-20240105?wsdl
• http://stamdatahost:8080/stamdata-authorization-lookup-ws/service/AuthorizationCodeService-20240105?wsdl

5.2.2     Eksempel: Én eller flere autorisationer

Nedenfor ses et ”solskinsscenarie”, hvor der forespørges på en sundhedsfaglig, der har en enkelt gyldig autorisation.

Forespørgsel:

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

Svar:

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

Forespørgsel:

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

Svar:

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

Hver opmærksom på at der tilføjes Den Gode WebService felter på, så vil nok være nemmere at hente wsdl direkte fra servicen:

For versioner tidligere end 1.0.4.1a, gøres det ved at kalde endpoint med ?wsdl tilføjes som sådan http://endpointurl?wsdl da denne indeholder de tilføjede felter.

For version 1.0.4.1a hentes wsdl filerne (dgws eller idws) på følgende endpoints:

• http://stamdatahost:8080/stamdata-cpr-ws/service-contract/wsdl/MEDCOM_1.0.4.1a_dgws/DetGodeCprOpslag.wsdl
• http://stamdatahost:8080/stamdata-cpr-ws/service-contract/wsdl/MEDCOM_1.0.4.1a_idws/DetGodeCprOpslag.wsdl

Sidst men ikke mindst kan de også hentes med dgws/idws 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 følgende versioner som er tilgængelig på hver deres endpoints. 

For 1.0.4.1a er snitfladerne også udstillet som IDWS-snitflader og tillader dermed borgerkald, dog begrænset til opslag på eget cpr-nummer. 

For 1.0.3

http://stamdatahost:8080/stamdata-cpr-ws/service/DetGodeCPROpslag-1.0.3

For 1.0.4

http://stamdatahost:8080/stamdata-cpr-ws/service/DetGodeCPROpslag-1.0.4

For 1.0.4.1

http://stamdatahost:8080/stamdata-cpr-ws/service/DetGodeCPROpslag-1.0.4.1

For 1.0.4a

http://stamdatahost:8080/stamdata-cpr-ws/service/DetGodeCPROpslag-1.0.4a

For 1.0.4.1a

http://stamdatahost:8080/stamdata-cpr-ws/service/DetGodeCPROpslag-1.0.4.1a

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

For AssociatedGeneralPractitionerStructure er det følgende felter:

Yderligere indeholder datagrundlaget i nogle tilfælde email adresser som ikke overholder reglerne i wsdl skemaet, hvis dette er tilfældet vil email adressen fjernes fra svaret.

Hvis der ikke kan findes en tilknyttet læge i datagrundlaget vil AssociatedGeneralPractitionerStructure være udfyld med følgende værdier

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

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. For at afgøre, om en persons data er beskyttet, ser SDM udelukkende på beskyttelsesstartdatoen ud fra de CPR-data, den modtager.

5.3.6     PersonSpouseStructure

Bemærk, at der siden version 1.0.4 af snitfladen har været indført en PersonSpouseStructure under PersonInformationStructure. Denne vil dog udgå i en fremtidig version, og vil fremadrettet ikke være at finde ved alle opslag i de eksisterende versioner af snitfladen.

5.4     CPR registret: getPersonDetails og getPersonDetailsWithConsent

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 i version 1.0.1 og 1.1.0 har en enkelt snitflade: getPersonDetails, der er implementeret i forskellige udgaver der muliggør forskellige typer af søgninger.
Version 1.1.0 har desuden en snitflade getPersonDetailsWithConsent, der muliggør at hente addressebeskyttet data. Request og response er de samme for begge snifflader. 
Version 1.2.0 har desuden en snitflade searchPersonDetails, der muliggør at fremsøge cpr-numre ud fra navn/fødselsdato. Request for denne snitflade er en begrænset udgave af request for de øvrige snitflader, hvor det kun er muligt at angive navn og fødselsdato. Response er det samme som for de øvrige snitflader.

Version 1.2.0 udstiller IDWS-snitflader, som muliggør borgerkald, dog begrænset til opslag på eget cpr-nummer. Her udstilles snitfladerne getPersonDetails og getPersonDetailsWithConsent. Request og response er de samme for begge snifflader.

I de følgende afsnit er kaldmulighederne beskrevet med tilhørende eksempler.

5.4.0     WSDL

wsdl filerne kan hentes direkte fra servicen:

For versioner tidligere end 1.2.0, gøres det ved at kalde endpoint med ?wsdl tilføjes som sådan http://endpointurl?wsdl 

For version 1.2.0 hentes wsdl filerne (dgws eller idws) på følgende endpoints:

• http://stamdatahost:8080/stamdata-cpr-ws/service-contract/wsdl/PERSONLOOKUP_1.2.0_dgws/StamdataPersonLookup.wsdl
• http://stamdatahost:8080/stamdata-cpr-ws/service-contract/wsdl/PERSONLOOKUP_1.2.0_idws/StamdataPersonLookup.wsdl

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 DetGodeCprOplag findes der 4 endpoints:

http://stamdatahost:8080/stamdata-cpr-ws/service/StamdataPersonLookup-1.0.1
http://stamdatahost:8080/stamdata-cpr-ws/service/StamdataPersonLookup-1.1.0

http://stamdatahost:8080/stamdata-cpr-ws/service/StamdataPersonLookup-1.2.0

De første endpoints findes kun af hensyn til bagud kompatibilitet og anvender wsdl filer som ligger i mapperne PERSONLOOKUP_1.0.1 og PERSONLOOKUP_1.1.0.

Det anbefales man anvender StamdataPersonLookup-1.2.0 i nye projekter, wsdl filerne til denne kan findes i PERSONLOOKUP_1.2.0 mappen.

5.4.2     Whitelistning

Snitflader er beskyttet af en whitelistning. Et cvr nummer skal være whitelistet til ”SDM” og at kalde getPersonDetail, ”SDMwithConsent” for at kalde getPersonDetailsWithContents, og "SDMwithCPR" for at kalde searchPersonDetails.

5.4.3     Mangelfuld data og Fejlfyldt CPR data

Se 5.3.3 Mangelfuld data og 5.3.4 Fejlfyldt CPR data

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

Kald 1: (Opslag vha. CPR-nummer)

<stam:PersonLookupRequest>

  <CivilRegistrationNumberPersonQuery>

    1234567890

  </CivilRegistrationNumberPersonQuery>

</stam:PersonLookupRequest>

Svar 1: (Personen blev fundet)

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>

Svar 2: (Personen blev ikke fundet)

Hvis søgningen ikke giver et positivt resultat, returneres der et tomt svar:

<stam:PersonLookupResponse />

5.4.5     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 returneret. Se kaldet med en liste af CPR-numre for at se scenariet hvor flere person-elementer returneres.

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

Svar 4: (Resultat med flere records)

<stam:PersonLookupResponse>

  <ns:PersonInformationStructure>

    …

    <ns:PersonCivilRegistrationIdentifier>

      1111111111

    </ns:PersonCivilRegistrationIdentifier>

    …

  </ns:PersonInformationStructure>

  <ns:PersonInformationStructure>

    …

    <ns:PersonCivilRegistrationIdentifier>

      3333333333

    </ns:PersonCivilRegistrationIdentifier>

    …

  </ns:PersonInformationStructure>

</stam:PersonLookupResponse>

Kald 5 (Søgeopslag vha. fødselsdato):

Operationen searchPersonDetails tager et navn eller en fødselsdato som parameter, og returnerer personer der matcher parameteren. I nedenstående eksempel er der søgt på fødselsdato.

<stam:PersonSearchRequest>
  <BirthDatePersonQuery>2020-09-30+02:00</BirthDatePersonQuery>
</stam:PersonSearchRequest>

Svar 5

<stam:PersonLookupResponse>
  <ns:PersonInformationStructure>
    <ns:CurrentPersonCivilRegistrationIdentifier>0101027302</ns:CurrentPersonCivilRegistrationIdentifier>
    <ns:RegularCPRPerson>
      <ns:SimpleCPRPerson>
        <ns:PersonNameStructure>
          <ns:PersonGivenName>Peter</ns:PersonGivenName>
          <ns:PersonMiddleName>Sigurd</ns:PersonMiddleName>
          <ns:PersonSurnameName>Andersen</ns:PersonSurnameName>
        </ns:PersonNameStructure>
        <ns:PersonCivilRegistrationIdentifier>0103952595</ns:PersonCivilRegistrationIdentifier>
      </ns:SimpleCPRPerson>
      <ns:PersonNameForAddressingName>Peter,Andersen</ns:PersonNameForAddressingName>
      <ns:PersonGenderCode>male</ns:PersonGenderCode>
      <ns:PersonInformationProtectionIndicator>true</ns:PersonInformationProtectionIndicator>
      <ns:PersonBirthDateStructure>
        <ns:BirthDate>2020-09-30+02:00</ns:BirthDate>
        <ns:BirthDateUncertaintyIndicator>true</ns:BirthDateUncertaintyIndicator>
      </ns:PersonBirthDateStructure>
      <ns:PersonCivilRegistrationStatusStructure>
        <ns:PersonCivilRegistrationStatusCode>1</ns:PersonCivilRegistrationStatusCode>
        <ns:PersonCivilRegistrationStatusStartDate>2020-10-01+02:00</ns:PersonCivilRegistrationStatusStartDate>
      </ns:PersonCivilRegistrationStatusStructure>
    </ns:RegularCPRPerson>
    <ns:PersonAddressStructure>
      <ns:CareOfName>Søren Petersen</ns:CareOfName>
      <ns:AddressComplete>
        <ns:AddressAccess>
          <ns:MunicipalityCode>0461</ns:MunicipalityCode>
          <ns:StreetCode>0234</ns:StreetCode>
          <ns:StreetBuildingIdentifier>10</ns:StreetBuildingIdentifier>
        </ns:AddressAccess>
        <ns:AddressPostal>
          <ns:StreetName>Ørstedgade</ns:StreetName>
          <ns:StreetNameForAddressingName>Østergd.</ns:StreetNameForAddressingName>
          <ns:StreetBuildingIdentifier>10</ns:StreetBuildingIdentifier>
          <ns:FloorIdentifier>12</ns:FloorIdentifier>
          <ns:SuiteIdentifier>tv</ns:SuiteIdentifier>
          <ns:DistrictSubdivisionIdentifier>BirkeBy</ns:DistrictSubdivisionIdentifier>
          <ns:PostCodeIdentifier>6666</ns:PostCodeIdentifier>
          <ns:DistrictName>Überwald</ns:DistrictName>
          <ns:CountryIdentificationCode scheme="iso3166-alpha2">DK</ns:CountryIdentificationCode>
        </ns:AddressPostal>
      </ns:AddressComplete>
      <ns:PersonInformationProtectionStartDate>2000-01-01+01:00</ns:PersonInformationProtectionStartDate>
      <ns:CountyCode>1083</ns:CountyCode>
    </ns:PersonAddressStructure>
  </ns:PersonInformationStructure>
</stam:PersonLookupResponse>

5.5 Enkeltopslag i yderregistret

Det er muligt at lave onlineopslag i stamdataservicens kopi af Sundhedsstyrelsens yderregister til fremsøgning af eventuelle yder oplysninger for en given sundhedsfaglig person. Der er en service YderService, som tager personens Ydernummer som input, og returnerer personens oplysninger i yderregister.

Servicen returner alt gyldig information i yderregistret baseret på opslag med ydernummeret. Se beskrivelsen af Yderregisteret lisen af data felter.

5.5.1     Endpoints

http://stamdatahost:8080/stamdata-yder-lookup-ws/service/YderService

5.5.1     Eksempel: Én eller flere autorisationer

Nedenfor ses et ”solskinsscenarie”, hvor der forespørges på en sundhedsfaglig, der har en enkelt gyldig autorisation.

Forespørgsel:

<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Header>
    …
  </S:Header>
  <S:Body>
    <YderRequestStructure 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">
      <yder>1111122222</yder>
    </YderRequestStructure>
  </S:Body>
</S:Envelope>

Svar:

<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Header>
                    …
  </S:Header>
  <S:Body>
    <YderResponseStructure xmlns="http://nsi.dk/-/stamdata/3.0" >
      <Yder>
        <AmtKode>81</AmtKode>
        <AmtTekst>Nordjylland</AmtTekst>
        <Praksisbetegnelse>Kraniosekral</Praksisbetegnelse>
       CPR registret: getPersonDetails og getPersonDetailsWithConsent <Adresse>Vejen 1</Adresse>
        <Postnummer>5000</Postnummer>
        <Postdistrikt>Vejen</Postdistrikt>
        <Tilgangsdato>20000101</Tilgangsdato>
        <Afgangsdato>20200101</Afgangsdato>
        <HovedspecialeKode>8</HovedspecialeKode>
        <HovedspecialeTekst>Intern Medicin</HovedspecialeTekst>
        <Telefonnummer>12345678</Telefonnummer>
        <Email>test@dk.dk</Email>
        <Web>www.test.dk</Web>
        <CVR>12345678</CVR>
      </yder>
      <person>
        <CPR>1234567890</CPR>
        <Tilgangsdato>20000202</Tilgangsdato>
        <Afgangsdato>20200202</Afgangsdato>
        <PersonrolleKode>11</PersonrolleKode>
        <PersonrolleTekst>Ejer</PersonrolleTekst>
      </person>
      <person>
        <CPR>1234567891</CPR>
        <Tilgangsdato>20000202</Tilgangsdato>
        <Afgangsdato>20200202</Afgangsdato>
        <PersonrolleKode>23</PersonrolleKode>
        <PersonrolleTekst>Vikar</PersonrolleTekst>
      </person>
    </YderResponseStructure>
  </S:Body>
</S:Envelope>

I eksemplet er ydernummeret tilknyttet en praksis med to ansatte.

5.6 CPR registret: personinformation

Stamdataservicen udstiller en REST service der, i sin nuværende form, kan anvendes til

1. at verificere om et CPR nummer eksisterer. Servicen tager ikke hensyn til om personen f.eks. er afgået ved døden.
2. at hente status for en given person med udgangpunkt i et CPR nummer. Denne kode kan blandt andet bruges til at afgøre er afgået ved døden eller på anden måde inaktiv
3. at hente alder (age) for en given person med udgangspunkt i et CPR nummer.
4. at hente fødselsdag for en given person
5. at hente værgemål en given person har (som forældre eller værge)
6. at hente de navne en given person har
7. at returnere en liste af personer der er afdøde udfra en liste af cpr numre og dato som input.

Bemærk: Denne service kan kun anvendes internt på NSP. Derfor har servicen heller ikke nogen sikkerhedsprotokol.

Servicens snitflade er beskrevet via OpenAPI og kan findes i SVN i her.

5.4.1 Endpoints

Servicen kan tilgås på nedenstående endpoint hvor stamdatahost er tilrettet den korrekte host.

1. http://stamdatahost/stamdata-personinformation/person/{cpr}
2. http://stamdatahost/stamdata-personinformation/person/{cpr}/status
3. http://stamdatahost/stamdata-personinformation/person/{cpr}/age
4. http://stamdatahost/stamdata-personinformation/person/{cpr}/birthday
5. http://stamdatahost/stamdata-personinformation/person/{cpr}/custody
6. http://stamdatahost/stamdata-personinformation/person/{cpr}/name
7. http://stamdatahost/stamdata-personinformation/person/deceased

5.4.2 Eksempel 1: Person findes

I dette eksempel kaldes servicen med et CPR nummer der eksisterer.

Request

Request i form af curl udtryk.

curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632740

Response

Der svares med HTTP statuskode 200.

{"cpr": "2209632740"}

5.4.5 Eksempel 2: Person findes ikke

I dette eksempel kaldes servicen med et CPR nummer der IKKE eksisterer.

Request

Request i form af curl udtryk.

curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741

Response

Der svares med HTTP statuskode 404. Bemærk at Content-Type headeren også er application/json når HTTP koden 404 skyldes at CPR nummeret ikke findes.

{ }

5.4.5 Eksempel 3: Status hentes

I dette eksempel kaldes servicen med et CPR nummer der eksisterer, og har status 1

Request

Request i form af curl udtryk.

curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/status

Response

Der svares med HTTP statuskode 200.

{"status":1}

5.4.5 Eksempel 4: Status hentes på person der ikke findes

I dette eksempel kaldes servicen med et CPR nummer der IKKE eksisterer.

Request

Request i form af curl udtryk.

curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/status

Response

Der svares med HTTP statuskode 404. Bemærk at Content-Type headeren også er application/json når HTTP koden 404 skyldes at CPR nummeret ikke findes.

{ }

5.4.5 Eksempel 5: Status hentes på person der findes men ikke har en status

I dette eksempel kaldes servicen med et CPR nummer der eksisterer, men ikke har en status.

Request

Request i form af curl udtryk.

curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/status

Response

Der svares med HTTP statuskode 404. Bemærk at Content-Type headeren også er application/json når HTTP koden 404 skyldes at status ikke findes.

{ }

Eksempel 3: Alder hentes

I dette eksempel kaldes servicen med et CPR nummer der eksisterer, og har alder 6 år

Request

Request i form af curl udtryk.

curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/age

Response

Der svares med HTTP statuskode 200.

{"age":6}

5.4.5 Eksempel 4: Alder hentes på person der ikke findes

I dette eksempel kaldes servicen med et CPR nummer der IKKE eksisterer.

Request

Request i form af curl udtryk.

curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/age

Response

Der svares med HTTP statuskode 404. Bemærk at Content-Type headeren også er application/json når HTTP koden 404 skyldes at CPR nummeret ikke findes.

{ }

5.4.5 Eksempel 5: Alder hentes på person der fines men hvor alder ikke kan beregnes.

I dette eksempel kaldes servicen med et CPR nummer der eksisterer, men hvoer der ikke er angivet en fødselsdato i den tabel alder udregnes fra. (Samme resultat fåes, hvis fødselsdatoen fejlagtig er registret i fremtiden)

Request

Request i form af curl udtryk.

curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/age

Response

Der svares med HTTP statuskode 404. Bemærk at Content-Type headeren også er application/json når HTTP koden 404 skyldes at alder ikke kan udregnes.

{ }

5.4.6 Eksempel 6: Fødselsdag hentes

I dette eksempel kaldes servicen med et CPR nummer der eksisterer, og fødselsdagen 24 december 2012

Request

Request i form af curl udtryk.

curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/birthday

Response

Der svares med HTTP statuskode 200.

{"birthday":"2012-12-24"}

5.4.7 Eksempel 7: Fødselsdag hentes på person der ikke findes

I dette eksempel kaldes servicen med et CPR nummer der IKKE eksisterer.

Request

Request i form af curl udtryk.

curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/birthday

Response

Der svares med HTTP statuskode 404. Bemærk at Content-Type headeren også er application/json når HTTP koden 404 skyldes at CPR nummeret ikke findes.

{ }

5.4.8 Eksempel 8: Værge og forældremål hentes

I dette eksempel kaldes servicen med et CPR nummer der er forældre til 2 børn på 9 og 16 år samt har værgemål over person med cpr 2209632743.

Request

Request i form af curl udtryk.

curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/custody

Response

Der svares med HTTP statuskode 200.

{"parentalCustody":[{"relationCpr":"2209632741","age":9},{"relationCpr":"2209632742","age":16}],"wardCustody":[{"relationCpr":"2209632743"}]}

5.4.9 Eksempel 9: Værge og forældremål hentes på person der ikke har sådanne

I dette eksempel kaldes servicen med et CPR der ikke har værge og fældremål

Request

Request i form af curl udtryk.

curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/custody

Response

Der svares med HTTP statuskode 404. 

{ }

5.4.6 Eksempel 10: Navn hentes

I dette eksempel kaldes servicen med et CPR nummer der eksisterer, og personen har 3 navne (fornavn, mellem og efternavn).

Request

Request i form af curl udtryk.

curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632770/name

Response

Der svares med HTTP statuskode 200.

{"givenName":"Helle","middleName":"Louise","familyName":"Eskesen","nameForAddressing":"Helle Eskesen"}

5.4.7 Eksempel 7: Navn hentes på person der ikke findes

I dette eksempel kaldes servicen med et CPR nummer der IKKE eksisterer.

Request

Request i form af curl udtryk.

curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632771/name

Response

Der svares med HTTP statuskode 404. Bemærk at Content-Type headeren også er application/json når HTTP koden 404 skyldes at CPR nummeret ikke findes.

{ }

Eksempel 11: Find afdøde personer

I dette eksempel kaldes servicen med en liste af CPR numre og en dato. Servicen returnere en liste af person id'er fra input listen, som tilhører afdøde personer, som døde før tidspunktet i inputtet.

Request

Request i form af curl udtryk.

curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/deceased?cpr=0304784567&cpr=1508902650&dato=2023-07-21T17:32:28

Response

Der svares med HTTP statuskode 200.

[{"cpr":"0304784567"},{"cpr":"1508902650"}]

[1]                                          Det er forventningen, at det er i nær fremtid bliver muligt at adgangsstyre på system-niveau.

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