Page History

...

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

...

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) som er en national standard for identitetsbaserede webservices i sundhedssektoren. 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.

...

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. 

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

...

Som klient sender man et ReplicationRequest til servicen. 

Forespørgsel:

...

    </ns1:ReplicationRequest>

  </S:Body>

</S:Envelope> 

Headeren skal indeholde en DGWS 1.0.1 header. 

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

Svar:

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

...

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

Fejl: 

<soapenv:Envelope ...>

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

...

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

...

Hvert entry element har et ’content’-element som indeholder alt domæne-data. I eksemplet ovenfor er det datatypen ’person’ som er indeholdt. 

Det er to slags nøgler som identificerer en record: Unikke nøgler (indeks) og versionsnumre.

...

Revisionsnumre bestemmer en record unikt indenfor en given datatype. Man kan se det som en primær nøgle i en database. Et revisionsnummer er også en slags historisk ID. Det vil sige at det bestemmer en record unikt i historien, i modsætning til unikke nøgler. 

Revisionsnummeret kan findes ved at kigge på entry-elementernes id-element. F.eks. i

...

er 1687637218007236 revisionsnummeret. 

Med andre ord, bestemmer en unik nøgle en bestemt entitet, revisionsnummeret bestemmer et snapshot af den entitet. Begge disse numre er vigtige på flere måder. Den unikke nøgle kan optræde i flere forskellige entry-elementer. Det er på grund af at en entitet ændre sig med tiden, men revisionsnumre vil altid være forskellige.

...

Antallet af records i et register kan være meget stort, i visse tilfælde flere millioner records. Derfor bliver man nødt til at opdele et udtræk i flere kald. Response fra det tidligere eksempel, er et eksempel på en page. Når man er klar til at hente næste page sender man et request med nyt offset i ReplicationResponse beskeden. Offset-parameteren i næste request sættes til det sidste versionsnummeret man har modtaget. 

Det er muligt at angive hvor mange records man højest ønsker i et svar fra servicen ved at sætte parameteren maxRecords i ReplicationRequest forespørgelsen. Der er på serveren en øvre grænse på denne parameter der overskriver for høje værdier i en forespørgelse. Hvis parameteren ikke specificeres i kaldet indsættes denne grænse som antal records.

...

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

-          Autorisationsregistret

-          CPR registret

Enkeltopslag i et af de ovennævnte registre foregår som et webservice kald til stamdataservicen på NSP med angivelse af søgekriterier. De konkrete parametre og eventuelle særlige forhold der gør sig gældende for kald til enkeltopslags-snitfladen på stamdataservicen er beskrevet i de følgende afsnit.

...

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 to services AuthorizationService og AuthorizationCodeService, som tager henholdsvis personens CPR nummer og Autorisationsnummer som input, og returnerer personens navn og samtlige autorisationer der er i kraft for vedkommende.[2] 

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.

...

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

...

    </AuthorizationRequestStructure>

  </S:Body>

</S:Envelope>

Svar:

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

...

    </AuthorizationResponseStructure>

  </S:Body>

</S:Envelope>

I eksemplet er Peter Andersen tilknyttet CPR 1111122222, og han har en autorisation.

...

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

...

    </AuthorizationRequestStructure>

  </S:Body>

</S:Envelope>

...

Svar:

...

</soapenv:Body>

</soapenv:Envelope>

...

Da der ikke er nogen tilknyttede autorisationer, returneres en tom AuthorizationResponseStructure uden angivelse af for- og efternavn.

...

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

For 1.0.2

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

Det anbefales at køre på mindst version 1.0.2 da ikke alle personer kan hentes i 1.0.0 uden validerings fejl. 

For 1.0.3

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

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

...

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

...

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.0 og 1.0.1 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. I de følgende afsnit er kaldmulighederne beskrevet med tilhørende eksempler. 

Servicen er formelt beskrevet i WSDL og XSD skemaer der kan findes her: 

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

...

Eller direkte på driftsoperatørens SVN:

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

Servicen tager hensyn til navnebeskyttelse, og det anbefales at undersøge elementet PersonInformationProtectionIndicator for om værdien er true da personen i så fald er navnebeskyttet.

5.4.1     Endpoints

På samme måde som DetGodeCprOplag findes der 3 endpoints:

...

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

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

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

...

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> 

Svar 1: (Personen blev fundet)

...

        </ns1:PersonCivilRegistrationIdentifier> 

        …

      </ns1:SimpleCPRPerson>

...

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

<stam:PersonLookupResponse />

5.4.5     Kald 2: (Opslag vha. navn)

...

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

...

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>

...

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>

...

</stam:PersonLookupRequest>

Svar 4: (Resultat med flere records)

...

Kilden til dette dokument kan fås ved henvendelse til NSP-operatøren. 

...

...

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

...