Page History
...
Parameter | Beskrivelse | Eksempel |
Register | Det register, der ønskes udtræk fra. | ”cpr” |
Datatype | Hvert register er opdelt i en række datatyper, og et kald til KRS returnerer en enkelt af disse. | ”person” |
Versionsnummer | Af hensyn til bagudkompabilitet versioneres udtræksfunktionaliteten for hvert enkelt register. Parameteren angiver hvilken version af en datatype der ønskes, f.eks. version 1 eller version 2 af datatypen 'Person' i cpr-registret. | ”1” |
Registerversionsnummer | Af hensyn til bagudkompabilitet versioneres udtræksfunktionaliteten for hvert enkelt register. Parameteren angiver hvilken version af er register der ønskes, f.eks. version 1 eller version 2 af cpr-registret. | "1" |
Offset | En parameter, der angiver hvorfra i servicens udtræk af ændrede data svaret skal påbegyndes. | ”1024” |
MaxRowCount | Det maksimalt antal returnerede rækker. Anvendes til at styre størrelsen af svarene fra KRS. | ”512” |
...
Parameter | Beskrivelse | Eksempel |
Register | Det register, der ønskes udtræk fra. | ”CPR” |
Datatype | Hvert register er opdelt i en række datatyper, og et kald til KRS returnerer en enkelt af disse. | ”person” |
Versionsnummer | Af hensyn til bagudkompabilitet versioneres udtræksfunktionaliteten for hvert enkelt register. Parameteren angiver hvilken version af en datatype der ønskes, f.eks. version 1 eller version 2 af datatypen 'Person' i cpr-registret. | ”1” |
Registerversionsnummer | Af hensyn til bagudkompabilitet versioneres udtræksfunktionaliteten for hvert enkelt register. Parameteren angiver hvilken version af er register der ønskes, f.eks. version 1 eller version 2 af cpr-registret. | "1" |
IdList | Liste over id'er der skal laves opslag på. Formatet på id'erne afhænger af hvilken register- og datatype-paremeter der anvendes. Parameteren er påkrævet, og skal indeholde mellem 1 og 5.000 id'er. | ["1112570000","1112570001"] |
Filter | Angive hvis et filter skal benyttes, det angives som et navn. Hvis intet filter bliver givet bruges filter funktion ikke. | "Filter 1" |
Kaldet til Fleropslagsservicen er formelt specificeret i WSDL’en stamdata_rfs.wsdl, der kan rekvireres ved henvendelse til NSP-operatøren.
...
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
Service til kald af rfs med som kan benyttet filter:
<hostnavn>:8080/stamdata-batch-copy-ws-rfs/service/StamdataReplication-20240227
og wsdl kan hentes ved at sætte ?wsdl efter, altså:
<hostnavn>:8080/stamdata-batch-copy-ws-rfs/service/StamdataReplication-20240227?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"?>
...
<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>
<filter>filter 1</filter>
</ns1:ReplicationRequest>
...
Headeren skal indeholde en DGWS 1.0.1 header.
Hvis filter er angivet vil response der blive filteret felter fra svaret. Hvis intet filter angivet svaret det samme som for KRS, og vil gerfor ikke blive gennemgået igen.
Strukturen af Strukturen af responses og faults er den samme som for KRS, og vil gerfor ikke blive gennemgået igen.
3
...
Her følger et mere detaljeret output fra KRS. Tolkning af dette er beskrevet i afsnittet efter.
...
.4.3 Eksempel på svar ved brug af et filter til RFS
<?xml version="1.0" encoding="UTF-8"?> <atom:feed xmlns:atom="http://www.w3.org/2005/Atom" xmlns:S="http:// |
---|
...
...
...
soap/envelope/" xmlns:ns2="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#" xmlns:ns4="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns5="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns7="http://nsi.dk/2024/02/27/StamdataRfs/"> <atom:id>tag:nsi.dk,2011:cpr/person/v1</atom:id> <atom:updated>2024-04-23T12:55:05.129Z</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/17136504000000005006</atom:id> <atom:title/> <atom:updated>2024-04-20T22:00:00.000Z</atom:updated> <atom:content type="application/xml"> <person:person xmlns="http://nsi.dk/-/stamdata/3.0/cpr" xmlns:person="http://nsi.dk/-/stamdata/3.0/cpr"> <cpr>0102451234</cpr> <koen>M</koen> <fornavn>Peter</fornavn> <mellemnavn>Sigurd</mellemnavn> </person:person> </atom:content> </atom:entry> </atom:feed> |
---|
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</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ænget</vejnavn>
<bygningsnummer>42</bygningsnummer>
<husnummer>123</husnummer>
<etage>12</etage>
<sideDoerNummer>th.</sideDoerNummer>
<bynavn>Enby</bynavn>
<postnummer>1448</postnummer>
<postdistrikt>Nø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>
...
<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ænget</vejnavn>
<bygningsnummer>42</bygningsnummer>
<husnummer>123</husnummer>
<etage>12</etage>
<sideDoerNummer>th.</sideDoerNummer>
<bynavn>Enby</bynavn>
<postnummer>1448</postnummer>
<postdistrikt>Nø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:
Code Block | ||
---|---|---|
| ||
<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> |
Code Block | ||
---|---|---|
| ||
<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.
Register | Datatype | Opslagskolonne | Eksempel |
---|---|---|---|
CPR | Person | CPR | 1112579876 |
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.
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 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="
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:
Code Block | ||
---|---|---|
| ||
<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> |
Code Block | ||
---|---|---|
| ||
<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.
...
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 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>1111122222</cpr>
</AuthorizationRequestStructure>
</S:Body>
</S:Envelope>
Svar:
<soapenv:Envelope …>
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
…
</S <soapenv:Header>…</soapenv:Header>
<soapenv<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> AuthorizationResponseStructure>
</soapenvS:Body>
</soapenvS: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:
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
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:
...
...
...
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:
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 |
- _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:
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:
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 email adresser som ikke overholder reglerne i wsdl skemaet, hvis dette er tilfældet vil email 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.
...
- at verificere om et CPR nummer eksisterer. Servicen tager ikke hensyn til om personen f.eks. er afgået ved døden.
- 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
- at hente alder (age) for en given person med udgangspunkt i et CPR nummer.
- at hente fødselsdag for en given person
- at hente værgemål en given person har (som forældre eller værge)
- at hente de navne en given person har
- 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.
- http://stamdatahost/stamdata-personinformation/person/{cpr}
- http://stamdatahost/stamdata-personinformation/person/{cpr}/status
- http://stamdatahost/stamdata-personinformation/person/{cpr}/age
- http://stamdatahost/stamdata-personinformation/person/{cpr}/birthday
- http://stamdatahost/stamdata-personinformation/person/{cpr}/custody
- http://stamdatahost/stamdata-personinformation/person/{cpr}/name
- 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.
Code Block | ||
---|---|---|
| ||
curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632740 |
Response
Der svares med HTTP statuskode 200.
Code Block | ||
---|---|---|
| ||
{"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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
{ }
|
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.
Code Block | ||
---|---|---|
| ||
curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/status |
Response
Der svares med HTTP statuskode 200.
Code Block | ||
---|---|---|
| ||
{"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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
{ }
|
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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
{ }
|
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.
Code Block | ||
---|---|---|
| ||
curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/age |
Response
Der svares med HTTP statuskode 200.
Code Block | ||
---|---|---|
| ||
{"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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
{ }
|
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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
{ }
|
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.
Code Block | ||
---|---|---|
| ||
curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/birthday |
Response
Der svares med HTTP statuskode 200.
Code Block | ||
---|---|---|
| ||
{"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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
{ }
|
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.
Code Block | ||
---|---|---|
| ||
curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/custody |
Response
Der svares med HTTP statuskode 200.
Code Block | ||
---|---|---|
| ||
{"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.
Code Block | ||
---|---|---|
| ||
curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/custody |
Response
Der svares med HTTP statuskode 404.
Code Block | ||
---|---|---|
| ||
{ }
|
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.
Code Block | ||
---|---|---|
| ||
curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632770/name |
Response
Der svares med HTTP statuskode 200.
Code Block | ||
---|---|---|
| ||
{"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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
{ }
|
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.
Code Block | ||
---|---|---|
| ||
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.
...
language | js |
---|
...
- 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.
- http://stamdatahost/stamdata-personinformation/person/{cpr}
- http://stamdatahost/stamdata-personinformation/person/{cpr}/status
- http://stamdatahost/stamdata-personinformation/person/{cpr}/age
- http://stamdatahost/stamdata-personinformation/person/{cpr}/birthday
- http://stamdatahost/stamdata-personinformation/person/{cpr}/custody
- http://stamdatahost/stamdata-personinformation/person/{cpr}/name
- 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.
Code Block | ||
---|---|---|
| ||
curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632740 |
Response
Der svares med HTTP statuskode 200.
Code Block | ||
---|---|---|
| ||
{"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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
{ }
|
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.
Code Block | ||
---|---|---|
| ||
curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/status |
Response
Der svares med HTTP statuskode 200.
Code Block | ||
---|---|---|
| ||
{"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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
{ }
|
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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
{ }
|
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.
Code Block | ||
---|---|---|
| ||
curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/age |
Response
Der svares med HTTP statuskode 200.
Code Block | ||
---|---|---|
| ||
{"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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
{ }
|
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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
{ }
|
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.
Code Block | ||
---|---|---|
| ||
curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/birthday |
Response
Der svares med HTTP statuskode 200.
Code Block | ||
---|---|---|
| ||
{"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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
{ }
|
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.
Code Block | ||
---|---|---|
| ||
curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/custody |
Response
Der svares med HTTP statuskode 200.
Code Block | ||
---|---|---|
| ||
{"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.
Code Block | ||
---|---|---|
| ||
curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632741/custody |
Response
Der svares med HTTP statuskode 404.
Code Block | ||
---|---|---|
| ||
{ }
|
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.
Code Block | ||
---|---|---|
| ||
curl -H "Accept: application/json" http://stamdatahost/stamdata-personinformation/v1/person/2209632770/name |
Response
Der svares med HTTP statuskode 200.
Code Block | ||
---|---|---|
| ||
{"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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
{ }
|
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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
[{"cpr":"0304784567"},{"cpr":"1508902650"}] |
6 Stamdata Filter Management Service (SFMS)
6.1 Struktur af kald til SFM
Opret et nyt filter tager følgende inputs:
Parameter | Beskrivelse | Eksemel |
---|---|---|
Navn | Det navn som filter skal kaldes. | "Filter 1" |
ViewPath | Er informationer på SKRS eller SRFS. Det vil være disse oplysning i dette format: register/version/datatype/Registerversion | "vitamin/1/grunddata/1" |
DataTypeFieldList | Specificer hvilket felter som skal vises ved brug af filter ved visning af en specifik datatype. | "varetype", "alfabetSekvensplads" |
Slet filter tager følgende inputs:
Parameter | Beskrivelse | Eksemel |
---|---|---|
Navn | Det navn som filter skal kaldes. | "Filter 1" |
6.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 FilterFaultResponseType med en beskrivelse af fejlen. Hvis forespørgslen går godt, returnerer servicen en besked af typen FilterResponseType, der indeholder en ”status”-element med status "OK".
6.3 Endpoints eksempel
Forespørgsel på at lave et nyt filter:
<?xml version="1.0" encoding="UTF-8" ?> … |
---|
Forespørgsel på at slette et filter:
Svar:
<?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header> ... </S:Header> <S:Body> <ns3:FilterResponseType xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:ns2="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns3="http://nsi.dk/2024/04/03/StamdataSfm" xmlns:ns4="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns5="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <ns3:status>OK</ns3:status> </ns3:FilterResponseType> </S:Body> </S:Envelope> |
---|
Fejl:
<?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> ... </soapenv:Header> <S:Body> <S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope"> <faultcode>S:Server</faultcode> <faultstring>Filter name was too short, the minimum allowed is '3'.</faultstring> <detail> <ns3:FilterFaultResponseType xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:ns2="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns3="http://nsi.dk/2024/04/03/StamdataSfm" xmlns:ns4="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns5="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/> <ns2:exception xmlns:ns2="http://jax-ws.dev.java.net/" class="dk.nsi._2024._04._03.stamdatasfm.FilterFaultMessage" note="To disable this feature, set com.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace system property to false"> <message>Filter name was too short, the minimum allowed is '3'.</message> <ns2:stackTrace> <ns2:frame class="dk.nsi.filter.management.sfm.webservice.FilterManagementImpl" file="FilterManagementImpl.java" line="177" method="validateFilterName"/> ... <ns2:frame class="java.util.concurrent.ThreadPoolExecutor$Worker" file="ThreadPoolExecutor.java" line="624" method="run"/> <ns2:frame class="java.lang.Thread" file="Thread.java" line="750" method="run"/> </ns2:stackTrace> </ns2:exception> </detail> </S:Fault> </S:Body> </S:Envelope> |
---|
6.4 EndPoints
Der findes følgende endpoints:
...
[1] Det er forventningen, at det er i nær fremtid bliver muligt at adgangsstyre på system-niveau.
...