Overblik

Stamkortregistret (SKR) er en service med operationer til registrering og udstilling af stamdata for borgere. Dette inkluderer pårørende, midlertidige adresser, sprog mm. Servicen beskrives i det følgende, som forudsætter kendskab til HL7 CDA og webservices.

Ændringslog

HL7 CDA

Modellen der anvendes til at repræsentere stamdata er HL7 CDA (se evt. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7), som er en XML-baseret standard til repræsentation af kliniske data. HL7 CDA er et begrebsapparat, som kan repræsentere en enorm mængde af forskelligartede data, hvoraf kun en lille delmængde anvendes i SKR. Det anbefales derfor at studere eksemplerne der refereres her på siden frem for modellen der defineres af HL7 CDA, da de giver et mere præcist billede af hvilke data der kræves og returneres af de forskellige operationer. CDA-terminologien gør, at man kan kvalificere de forskellige begreber gennem attributter (fx at en adresse er en hjemmeadresse ved at angive use="H"), og derfor sker der validering i SKR af, at disse attributter anvendes korrekt, så der ikke er tvivl om hvordan data skal fortolkes. Dvs. i praksis sker der en strengere validering end WSDL og XSDer dikterer.

Et stamkort består kort fortalt af borgerens navn- og adresseoplysninger samt et antal pårørende (med tilhørende kontakt- og fritekstoplysninger), evt. midlertidig(e) adresse(r), og borgerens sprog. SKR indeholder operationer til vedligehold af disse data. Der sker registrering af, hvem der opdaterer de forskellige elementer af borgerens stamkort, og disse oplysninger udstilles på stamkortet.

Begreber

Et stamkort repræsenteres som et "ClinicalDocument", som er grundpillen i CDA. Ifm. SKR er der lavet en extension til CDA, som gør det muligt at repræsentere pårørende, midlertidige adresser, sprog mv. som entry-typer i dokumentets "structuredBody". Nedenfor ses ClinicalDocument-strukturen som det benyttes i SKR:

Selve dokumentets "header" indeholder (udover personen der senest har opdateret stamkortet) de statiske data, som trækkes fra CPR-registeret, og ikke kan opdateres gennem SKRs operationer. De egentlige stamkort-data ligger under "StructuredBody", som indeholder en liste en "entry"-sektioner. Disse kan i SKR-sammenhæng have indhold af typen relatedPerson, temporaryAddress, language og healthprovider. De to førstnævnte har sin egen id, som skal benyttes hvis man ønsker at slette eller opdatere entiteten via de relevante operationer. Hvis man fx ønsker at opdatere stamdata på en pårørende (RelatedPerson), så skal man bruge id'et man finder på vedkommende i "GetPersonalDataCard" til det request man sender til "UpdateRelatives"-operationen. Tilsvarende for midlertidige adresser.

Ifm. HL7 CDA er der defineret en række "OIDer", som hver især definerer et udfaldsrum for forskellige id/kode-typer. Meningen er, at der til et id (på fx en person, altså CPR-nummer) defineres et OID, som kan betragtes som en type-erklæring. For SKR er følgende OIDer aktuelle:

* id defineres endeligt af MedCom.

På oidref.com kan man i øvrigt se betydningen af enkeltcifre i de fleste OIDer, fx http://oidref.com/2.16.840.1.113883.1.3

Snitflade

Sundhedsfaglige anvender servicen gennem en DGWS­-snitflade, som skal kaldes med et MOCES niveau 4 medarbejdercertifikat. Sundhed.dk har dog undtagelsesvis whitelisting til at kalde med et niveau 3 certifikat.

Borgere anvender servicerne gennem en IDWS­-snitflade og har adgang til alle operationer. Der understøttes ikke fuldmagter.

Snitfladerne skal kaldes skal kaldes gennem NSP'ens DCC endpoint (afkoblingskomponenten) via DGWS/IDWS Proxy-service. Sidstnævnte rammes ved at kalde URL'en <server>/skr/skr . I driftsvejledningen er beskrevet mere detaljeret hvad der findes af endpoints.

Server-URL'er for de forskellige test-miljøer kan findes på Endpoints for eksterne testmiljøer.

Stamkortet kan desuden hentes som et "on demand"-dokument via Dokumentdelingsservicen (DDS).

<server>/skr/wsdl

<server>/skr/wsdl/dgws20190801

<server>/skr/wsdl/idws20190801

WSDL

WSDLen for SKR indeholder nedenstående operationer:

De enkelte operationer forklares i de følgende afsnit.

Serviceoperationer

Nedenfor beskrives de forskellige operationer i SKR servicen. For hver operation gives eksempler på request/response (for simpelhedens skyld uden DGWS/IDWS headers). Eksemplerne tjener dels til formål at give overblik over hvad der skal til for at bruge en operation, men demonstrerer samtidigt hvilke attributter der er krævet. Dvs. de forskellige requests angiver hvad der som minimum skal angives (dog ikke i situationer hvor der fx slettes to pårørende i samme request - ingen services kræver mere end én liste-indgang).

GetPersonalDataCard

Request-eksempel: GetPersonalDataCard_request.xml

Response-eksempel: GetPersonalDataCard_response.xml

(1): Mangler kun hvis der ikke findes et stamkort

(2): Mangler kun såfremt kald til CPR-enkeltopslag (SCES) fejler

I situationer hvor der endnu ikke er oprettet et stamkort, vil svaret være uden "structuredBody", men stadig med CPR-data i headeren: GetPersonalDataCard_Only_CPRE_response.xml

Hvis der skulle opstå en teknisk fejl ifm. kommunikationen med CPR, vil svaret kun indeholde udvalgte attributter: GetPersonalDataCard_CPRE_down_response.xml

UpdateContactInformation

Request-eksempel: UpdateContactInformation_request.xml

Response-eksempel (indeholder ingen data): UpdateContactInformation_response.xml

CreateRelatives

Request-eksempel: CreateRelatives_organisation_request.xml

Request-eksempel med Id: CreateRelativesWithId_request.xml

Response-eksempel (indeholder ingen data): CreateRelatives_response.xml

UpdateRelatives

Request-eksempel: UpdateRelatives_request.xml

Response-eksempel (indeholder ingen data): UpdateRelatives_response.xml

DeleteRelatives

Request-eksempel: DeleteRelatives_request.xml

Response-eksempel (indeholder ingen data): DeleteRelatives_response.xml

CreateTemporaryAddress

Request-eksempel: CreateTemporaryAddress_request.xml

Request-eksempel med id: CreateTemporaryAddressWithId_request.xml

Response-eksempel (indeholder ingen data): CreateTemporaryAddress_response.xml

UpdateTemporaryAddress

Request-eksempel: UpdateTemporaryAddress_request.xml

Response-eksempel (indeholder ingen data): UpdateTemporaryAddress_response.xml

DeleteTemporaryAddress

Request-eksempel: DeleteTemporaryAddress_request.xml

Response-eksempel (indeholder ingen data): DeleteTemporaryAddress_response.xml

CreateLanguage

Request-eksempel: CreateLanguage_request.xml

Request-eksempel med id: CreateLanguageWithId_request.xml

Response-eksempel (indeholder ingen data): CreateLanguage_response.xml

UpdateLanguage

Request-eksempel: UpdateLanguage_request.xml

Response-eksempel (indeholder ingen data): UpdateLanguage_response.xml

DeleteLanguage

Request-eksempel: DeleteLanguage_request.xml

Response-eksempel (indeholder ingen data): DeleteLanguage_response.xml

CreateHealthProvider

Request-eksempel: CreateHealthProvider_request.xml

Request-eksempel med Id: CreateHealthProviderWithId_request.xml

UpdateHealthProvider

Request-eksempel: UpdateHealthProvider_request.xml

DeleteHealthProvider

Request-eksempel: DeleteHealthProvider_request.xml

MigratePersonalDataCard

Request-eksempel: Migrate_request.xml

Fejl situatuioner i forbindelse med MigratePersonalDataCard

Udover xml valideringsfejl og interne fejl kan migrerings snitflade returnerer følgende fejlkoder. 

Fejl fordi stamkort i skr er verificeret af borgeren. Fejlkode 800

I denne situation har borgeren allerede verificere stamkortet i skr.

Der forsøges migrering af sprog, men da borgeren allerede har verificeret stamkortet fejles med fejlkode 800. 

Request-eksempel: FailVerifiedLanguageExist_request.xml

<SOAP-ENV:Body>
  <SOAP-ENV:Fault>
	<faultcode>SOAP-ENV:Server</faultcode>
	<faultstring xml:lang="en">800: Fejl i request i forbindelse med migrering af stamkort, Fælles Stamkort er verificeret af borgeren</faultstring>
  </SOAP-ENV:Fault>
</SOAP-ENV:Body>

Fejl fordi stamkort i skr allerede indeholder telefonnummer af samme type. Fejlkode 810

I denne situation har stakmkortet i skr allerede et arbejdstelefonnummer.

Der forsøges migrering af arbejdstelefonnummer.

Request-eksempel:  FailWorkPhoneExist_request.xml

<SOAP-ENV:Body>
  <SOAP-ENV:Fault>
	<faultcode>SOAP-ENV:Server</faultcode>
	<faultstring xml:lang="en">810: Fejl i request i forbindelse med migrering af stamkort, Der eksisterer et telefonnummer af type arbejde i forvejen</faultstring>
  </SOAP-ENV:Fault>
</SOAP-ENV:Body>

Fejl fordi stamkort i skr allerede indeholder sprog.  Fejlkode 820

I denne situation indeholder stakmkortet i skr borgerens sprog.

Der forsøges migrering af sprog.

Request-eksempel: FailLanguageExist_request.xml

<SOAP-ENV:Body>
  <SOAP-ENV:Fault>
	<faultcode>SOAP-ENV:Server</faultcode>
	<faultstring xml:lang="en">820: Fejl i request i forbindelse med migrering af stamkort, Borgerens sprog eksisterer i forvejen</faultstring>
  </SOAP-ENV:Fault>
</SOAP-ENV:Body>

Fejl fordi stamkort i skr allerede indeholder midlertidig adresse.  Fejlkode 830

I denne situation indeholder stakmkortet i skr en midlertidig adresse på borgeren.

Der forsøges migrering af midlertidig adresse.

Request-eksempel: FailTemporaryAddressExist_request.xml

<SOAP-ENV:Body>
  <SOAP-ENV:Fault>
	<faultcode>SOAP-ENV:Server</faultcode>
	<faultstring xml:lang="en">830: Fejl i request i forbindelse med migrering af stamkort, Borgerens midlertidige adresse eksisterer i forvejen</faultstring>
  </SOAP-ENV:Fault>
</SOAP-ENV:Body>

Addr

Bemærk at der på en "addr"-struktur skal anvendes attribut isNotOrdered="false", da funktionalitet afhænger af en bestemt rækkefølge af streetAddressLine.

Organization

Organisation anvendes til at beskrive navn, adresse mv. for en tandlæge

DataEnterer

Den generelle dataEnterer-struktur der anvendes på diverse request, samt på relatedPerson, temporaryAddress og language, ser ud som følger (organisationsoplysninger skal angives hvis der er tale om en sundhedsperson):

DataEntererMigration

Den generelle dataEnterer-struktur der anvendes på Migrations requestet,  ser ud som følger, da det er en systembruger der benyttes ved migrationssnitfladen skal organisationsoplysninger angives: