Indledning

Denne vejledning beskriver de tekniske forretningsregler i forhold til at implementere Fælles Stamkort i et lokalt fagsystem eller en patient/borgerportal. Vejledningen er tiltænkt forretningsarkitekter, systemarkitekter samt systemleverandører, således at disse kan vurdere hvordan Fælles Stamkort kan implementeres i systemerne.

Fælles Stamkort er en forretningsservice baseret på den nationale dokumentdelingsinfrastruktur, som udstiller stamdata fra et antal underliggende registre1  i HL7 CDA format. Vejledningen præciserer brugen af den danske CDA profil til Personal Data Card (PDC-DK) [version 2.0]2, der anvendes til at udstille patientens Fælles Stamkort.
Vejledningen beskriver desuden de tekniske krav og forudsætninger.

De følgende afsnit, beskriver hvordan DK-PDC anvendes, samt hvilke forretningsregler lokale fagsystemer  og patient/ borgerportaler skal implementere for at understøtte Fælles Stamkort

_{1 -  Herunder CPR-register, Sygesikringsregister, Organdonorregister, Livs- og Behandlingstestamenteregister samt stamkortregister
2 - https://svn.medcom.dk/svn/releases/Standarder/HL7/PDC/}

Anden dokumentation

De overordnede forretningsregler til Fælles Stamkort kan ses i dokumentet: Indhold og forretningsregler Fælles Stamkort

Detaljeret teknisk anvenderguide, herunder information om felttyper, feltstørrelser og kardinalitet i dokumentet: FSK Guide til anvendere

Teknisk oversigt

Udveksling af patientens Fælles Stamkort foregår via den nationale infrastruktur til dokumentdeling. Denne understøtter referencearkitekturen for deling af dokumenter og billeder.

For generel introduktion til den nationale infrastruktur om dokumentdeling, se vejledningen ’Kom godt i gang med dokumentdeling’ til deling af dokumenter via Dokumentdelingsservice på NSP lavet af MedCom.

For detaljeret teknisk dokumentation omkring dokumentdeling via NSP, se NSP'ens Dokumentdelingsservice.

For detaljeret information ang. MinSpærring se Min Spærring på NSPOP

Fælles Stamkort er understøttet af to overordnede forretningsservices. Hent Fælles Stamkort samt Opdater Fælles Stamkort, disse services vil indgå i lokale fagsystemer samt patient/borgerportaler.

Hent Fælles Stamkort er implementeret via den nationale løsning for dokumentdeling, og følger derved principperne for denne, herunder adgangskontrol, informationssikkerhed og audit. Udvekslingsformatet er HL7 CDA (DK-PDC 2.0).

Opdater Fælles Stamkort foregår via en webservice integration, hvor der er implementeret endpoints til henholdsvis adgang for sundhedsfaglige samt patienter.

Migrering til Fælles Stamkort er en optionel service til understøttelse af fagsystemernes proces for migrering af stamkortdata til Fælles Stamkort. Processen understøttes af en specifik migreringsgrænseflade på stamkortregisteret, der via system-system integration sikrer, at validiteten samt aktualiteten og derved kvaliteten af data i Fælles Stamkort er så høj som muligt.

Fælles Stamkort on-demand servicen indeholder model og grænsefladebeskrivelser for CDA udvekslingsformatet.
Fælles Stamkort on-demand servicen er implementeret som en on-demand dokumentkilde, der integrerer til en række registre, heriblandt et stamkortregister, der er autoritativt register for oplysninger om patientens pårørende, patientens midlertidige adresse, patientens kontaktoplysninger samt patientens sprog. Læsning af Fælles Stamkort dokumenter fra Fælles Stamkort on-demand servicen foregår via dokumentdelingsservicen på den nationale service platform ved brug af HL7's standard ITI-18 og ITI-43 grænseflader.

Stamkortregister-servicen benyttes til at hente (kun adgang fra Fælles Stamkort on-demand service)  samt redigere patientens stamdata (telefonnummer, pårørende oplysninger, midlertidige adresse, sprog samt tilknytning til læge og tandlæge).  Opdateringer af data, sker via en direkte webserviceintegration til Stamkortregisteret.

Migrering af data fra lokale fagsystemer til Fælles Stamkort

Migrering af stamkortdata fra fagsystemet til Fælles Stamkort inden løsningen ibrugtages i drift, er en mulighed myndigheder med deres fagsystemer kan benytte.

Ved at lave en migrering vil forretningsværdien af at benytte Fælles Stamkort kunne udnyttes hurtigere, da borgere derved hurtigere vil få et overblik over de stamkortdata fagsystemerne har registreret på dem, og således kan verificere og kvalificere disse stamkortdata.

Benyttes migreringsprocessen, skal den kun køre en gang pr. fagsystem, da stamkortdata under migreringen udelukkende vil blive skrevet til Fælles Stamkort, uden hensyntagen til eksisterende data i Fælles Stamkort.

Udførsel af migreringsprocessen skal benytte en ny migreringsgrænseflade på Stamkortregisteret, som har til ansvar at sikre datakvaliteten for migreringen, samt sikre at borgere der allerede har etableret et Fælles Stamkort, ikke får overskrevet dette med ikke validerede data fra fagsystemerne.

Undlader myndigheden at benytte migreringsprocessen for deres fagsystemer, eller for dele af deres fagsystemer bør der laves lokale overvejelser for hvordan stamkort efterfølgende ibrugtages.

Principper for migrering af stamkortdata

#1: Alle stamkortdata migreres ukritisk

Stamkortdata migreres ukritisk, hvilket vil sige der ikke skal tages højde for tidligere udmeldte fletteregler. Forretningsregler skal stadig overholdes, hvilket beskrives nærmere i følgende principper.

Migreringsgrænsefladen vil returnere en fejlkode, i tilfælde af enten et brud på en forretningsregel, eller brud på en af følgende principper. Fagsystemet skal ikke, i det tilfælde det modtager en fejlkode, migrere det pågældende element der giver fejlkoden.
Fagsystemet bør i tilfælde af det ikke kan migrere stamkortdata overveje om det vil beholde lokale stamkortdata til senere synkronisering, eller om det eventuelt vil fjerne lokale data og udelukkende basere sig på de data der eksisterer i Fælles Stamkort.

Konsekvensen af en ukritisk migrering vil være, at der kan være duplikater af data på f.eks. borgerens pårørende. Dette kan borgeren, eller dennes pårørende, enten selv rette op på via brugergrænsefladen på sundhed.dk, eller sundhedspersoner kan hjælpe de borgere der ikke har fået det gjort, eller som ikke er i stand til selv at gøre dette.

#2: Hvor borgere i forvejen har oprettet et Fælles Stamkort vil det ikke være muligt at migrere stamkortdata
Fælles Stamkort skal gøre det muligt at migrere stamkortdata, hvor borgeren allerede har verificeret stamkortdata.
Borgeren kan enten selv have verificeret sine data, eller det kan være gjort af en sundhedsperson på vegne af borgeren, eller af borgerens fuldmagtshavere.

Der returneres en fejlkode fra migreringsgrænsefladen, og fagsystemet skal ikke migrere stamkortdata for denne borger.

Når borgeren efterfølgende har kontakt til myndigheden, og denne myndighed slår borgeren op i fagsystemet, bør fagsystemet allerede have taget stilling til om lokale data beholdes, da fagsystemet i den sammenhængt skal synkronisere med Fælles Stamkort

Eksemplet nedenfor viser hvordan det lokale fagsystem har tilknyttet UUID'er til de pårørende der står registreret lokalt, men ved efterfølgende migrering får fejlkode 800 retur, og derved kan se at borgeren allerede har et verificeret stamkort, og at stamdata ikke er migreret.

Eksempel på migrering hvor borgeren har et verificeret stamkort i forvejen

#3: Alle pårørende oprettes ukritisk

Stamkort data indeholdende pårørende information skrives ukritisk til Fælles Stamkort, altså uden hensyntagen til om der skulle eksistere en pårørende med samme oplysninger i forvejen, i borgerens Fælles Stamkort.

Fagsystemet skal tilknytte en UUID til hver pårørende der migreres, og gemme denne UUID sammen med pårørende oplysninger i fagsystemet. Efterfølgende synkronisering af Fælles Stamkort, når borgeren er i kontakt med myndigheden, vil dermed kunne sikre, hvilke pårørende der har fået rettet op på data, er slettet, eller er migreret fra andre fagsystemer.

Første eksempel nedenfor viser hvordan det lokale fagsystem har tilknyttet UUID'er til de pårørende der står registreret lokalt, og disse migreres til Fælles Stamkort selvom der allerede eksisterer en pårørende med navnet Hans Hansen i Fælles Stamkort. Den eneste forskel på de to Hans Hansen'er i Fælles Stamkort er UUID'en.

Efterfølgende migrerer fagsystem nr. 2, som vist i andet eksempel nedenfor, hvor endnu en dublet af pårørende Hans Hansen oprettes i Fælles Stamkort.

Migrering af pårørende til Fælles Stamkort, resulterende i dubletter

Migrering af pårørende fra fagsystem nr. 2 til Fælles Stamkort, resulterende i flere dubletter

#4: Oprydning i fagsystemer inden migrering

Fagsystemerne bør inden migrering af borgerens kontaktinformation (nuværende 3 typer af telefonnumre - hjemme, mobil, arbejde) - have struktureret egne data i fagsystemet. Fagsystemet skal skrive kontaktinformationen til Fælles Stamkort, eksisterer der et telefonnummer i forvejen, vil migreringsgrænsefladen returnere en fejlkode, og fagsystemet skal ikke skrive borgerens telefonnummer.

Fagsystemet bør overveje hvordan telefonnumre der ikke er migreret skal håndteres lokalt.

Efterfølgende synkronisering af Fælles Stamkort, vil ske når borgeren er i kontakt med en myndighed.

Første eksempel nedenfor viser hvordan det lokale fagsystem i forvejen har struktureret telefonnumrene på borgeren, og ved migreringen får skrevet hjemme nummeret til Fælles Stamkort. Hvorimod andet eksempel nedenfor kun får skrevet hjemme nummeret, men får fejlkode tilbage på mobilnummeret, da dette eksisterer i forvejen.

Migrering af borgerens hjemme telefonnummer til Fælles Stamkort

Migrering af borgerens hjemme telefonnummer, men fejl på borgerens mobiltelefonnummer da dette eksisterer i forvejen.

#5: Fagsystemerne skal udelukkende migrere borgerens sprog, hvis det ikke eksisterer i forvejen

Fælles Stamkort har i forretningsregel nr. 11 defineret at der maksimalt kan være et sprog for borgeren, eksisterer der et sprog i forvejen, vil migreringsgrænsefladen returnere en fejlkode, og fagsystemet skal ikke skrive borgerens sprog.

Fagsystemet bør overveje hvordan sprog der ikke er migreret, skal håndteres lokalt.

Efterfølgende synkronisering af Fælles Stamkort, vil ske når borgeren er i kontakt med en myndighed.

Eksemplet nedenfor viser hvordan det Fælles Stamkort i forvejen har borgerens sprog til dansk, og ved migreringen får en fejlkode tilbage

Migrering af borgerens sprog giver en fejlkode retur

#6: Fagsystemerne skal udelukkende migrere borgerens midlertidige adresse, hvis den ikke eksisterer i forvejen

Fælles Stamkort har i forretningsregel nr. 7 defineret at der maksimalt kan være en midlertidig adresse for borgeren i Fælles Stamkort, eksisterer der en midlertidig adresse i forvejen, vil migreringsgrænsefladen returnere en fejlkode, og fagsystemet skal ikke skrive borgerens midlertidige adresse.

Fagsystemet bør overveje hvordan en midlertidig adresse der ikke er migreret skal håndteres lokalt.

Efterfølgende synkronisering af Fælles Stamkort, vil ske når borgeren er i kontakt med en myndighed.

Eksemplet nedenfor viser hvordan Fælles Stamkort i forvejen har borgerens midlertidige adresse, og ved migreringen giver en fejlkode tilbage til fagsystemet

Migrering af borgerens midlertidige adresse giver en fejlkode retur

Tilslutning og governance i forhold til migreringsgrænsefladen.

Fagsystemer der tilsluttes migreringsgrænsefladen, skal have en whitelisting af det certifikat der benyttes til at skrive data til migreringsgrænsefladen.

Tilslutning skal anmeldes via den nationale servicedesk[1], hvor der oprettes en supportsag. Supportsagen skal indeholde "Subject" fra certifikatet, som følgende eksempel viser

Subject: SERIALNUMBER=CVR:11111111-FID:22222222 + CN=www.test-eksempel.dk – NemLogin (funktionscertifikat), O=Test-eksempel A/S // CVR:00000000, C=DK

Supportsagen skal ligeledes indeholde planlagt dato og tidspunkt for hvornår migreringen ønskes startet, således det kan planlægges fra Sundhedsdatastyrelsen at ikke alle fagsystemerne migrerer på samme tid.

Efter succesfuld migrering, vil whitelistingen for fagsystemet blive fjernet igen

Daglig drift mellem lokale fagsystemer og Fælles Stamkort

Den første synkronisering med Fælles Stamkort, har til målsætning at få ensrettet data i Fælles Stamkort med de allerede eksisterende data i de lokale fagsystemer.

Synkronisering af stamkortdata mellem fagsystem og Fælles Stamkort bør automatiseres i sådan en grad at brugerne af fagsystemet ikke får ekstra arbejdsgange.

Har fagsystemet tilknyttet lokale informationer til eksempelvis en pårørende, skal fagsystemet kunne håndtere at denne pårørende ændres eller slettes i Fælles Stamkort.

Det skal sikres at patientens data ikke går tabt samt at integriteten bevares. Det lokale fagsystem skal derfor følge den viste proces.

De enkelte data-entiteter fra Fælles Stamkort er tilknyttet en unik ID, de lokale fagsystemer skal kunne opbevare denne ID, da den skal benyttes når en data-entitet enten skal opdateres eller slettes. Samtidig har de enkelte data-entiteter tilknyttet informationer om hvornår de er opdateret, samt hvilken organisation eller om det er patienten selv der har opdateret data. Information omkring opdateringstidspunkt skal også gemmes i det lokale fagsystem, således at fagsystemet kan se om data er ændret siden sidste synkronisering.

Følgende eksempel viser data som det ser ud i det lokale fagsystem samt Fælles Stamkort før den første synkronisering.

Fagsystemet indlæser derefter data fra Fælles Stamkort, fletter data med lokale data og skriver efterfølgende nye og ændrede data til Fælles Stamkort

Som det ses har den pårørende Hans Hansen i det lokale fagsystem fået tilknyttet ID 9c13a4e6-fa0e-4740-833b-1e9e80ecc18e fra Fælles Stamkort.
Pårørende Jens Hansen eksisterede ikke i Fælles Stamkort i forvejen og er nu blevet oprettet, ID e5e4bfae-12c3-460b-a51c-6310a72cbc68 fra Fælles Stamkort er blevet tilknyttet det lokale fagsystem.

(Bemærk at ID kan enten dannes lokalt og dermed skrives til Fælles Stamkort, medsendes den ikke vil Fælles Stamkort selv oprette en ID.)

Fælles Stamkort har fået tilknyttet patientens 2. telefonnummer.
Fælles Stamkort har fået tilknyttet patientens foretrukne sprog, i dette tilfælde Dansk.

Felter omkring hvornår de enkelte data-entiteter er opdateret, samt hvilken organisation der har lavet opdateringen er ligeledes tilknyttet det lokale fagsystem (ikke vist på tegningen).

Efterfølgende laver patienten en opdatering af pårørende Jens Hansen via sundhed.dk, hvor patienten tilknytter relationen "Bror" samt at telefonnummeret på den pårørende er ændret.

Næste gang det lokale fagsystem laver et opslag på patientens data, og dermed kontrollerer om der er nye data i Fælles Stamkort. Kan det lokale fagsystem se at tidspunktet for pårørende Jens Hansen er nyere end det lokalt opbevarede tidspunkt, og skal derfor synkronisere data fra Fælles Stamkort ned til de lokale data.

Patienten ønsker at slette det ene af de 2 tilknyttede telefonnummer og gør dette via sundhed.dk.  

Fagsystemet ser ved næste opslag på patientens data, at kontaktinformationer har et nyere tidsstempel end de lokla data, og skal derfor synkronisere data fra Fælles Stamkort ned til de lokale data.
Da det her drejer sig om en sletning af data, skal data fjernes fra det lokale fagsystem, da det ikke længere er validt - da patienten har slettet det.

Adviseringer fra Stamkortregisteret

Fagsystemer bør hente patientens seneste Fælles Stamkort, hver gang der laves opslag på patientens stamdata i fagsystemet. Således kan fagsystemet flette de seneste ændringer fra Fælles Stamkort ind i de lokalt cachede stamdata. Betydningen af dette er at der laves mange opslag på patientens Fælles Stamkort, også når der ikke er sket ændringer.
Hvis fagsystemet derimod modtager en advisering når der er ændring i borgerens data fra stamkortregisteret, kan der laves optimeringer i forhold til antallet af opslag.

Disclaimer:

Den tekniske understøttelse af adviseringer fra Stamkortregisteret følge de overordnede principper udstukket af den Nationale Adviseringsservice (NAS)

Fagsystemerne bør implementere en adviseringskomponent, der håndterer at fagsystemet kan lytte på adviseringer fra Stamkortregisteret.
Den tekniske dokumentation i forhold til brugen af de viste endpoints til NAS, er beskrevet i NAS-2 Anvenderguide

Topic

Navn til Topic for ændringer til stamkortregisteret er: 

Endpoint NSP TEST-1: https://test1.ekstern-test.nspop.dk:8443/nas2
Endpoint NSP TEST-2: https://test2.ekstern-test.nspop.dk:8443/nas2

Beskedformat

Beskedformat for ændringer i Stamkortregisteret, er pakket ind i NAS'ens generelle beskedformat (Markeret med blåt)

Indholdet i notifikationen er neutralt, idet der ikke må inkluderes hvad ændringen omhandler. Følgende værdier ligger i adviseringen

• id: Patientens CPR nummer
• date: Dato for Hvornår ændringen er sket
• type: Type for beskeddefinitionen
• version: Versionsnummer for beskeddefinitionen.
• messageid: unik besked-id på baggrund af enten DGWS eller IDWS kald, derved har fagsystemer mulighed for at se om adviseringen sker på baggrund af fagsystemets egne opdateringer.

Det skal bemærkes, at der godt kan foreligge flere adviseringer for den samme patient, da der vil blive skabt en advisering hver gang der er foretaget en ændring på patientens data i Stamkortregisteret. Fagsystemet skal kunne håndtere dette scenarie. Uanset hvor mange adviseringer der ligger i pullpointet, skal der dog kun foretages en synkronisering.

Ved tekniske fejl er der altid en risiko for at adviseringer går tabt, fagsystemet bør derfor have mulighed for at synkronisere med Fælles Stamkort, selvom det ikke har modtaget en advisering, eksempelvis via en aktiv handling fra en sundhedsperson.

Eksempel

Et fagsystem har modtaget en advisering på at Hans Hansen's data i Stamkortregisteret er opdateret.
En sundhedsperson skal lave et opslag på Hans Hansen, der skal i behandling og som netop er mødt ind på hospitalet.

Hans Hansen data i Stamkortregisteret

1. Hans Hansen har for 2 dage siden oprettet sit telefonnummer via sundhed.dk, da dette ikke var indtastet i forvejen.
2. Stamkortregisteret har udsendt en advisering til beskedkøen: "Ændring på Fælles Stamkort", som fagsystemet "lytter på", og hvor fagsystemet i forvejen har fortalt det vil modtage adviseringer for regionens patienter, her i blandt Hans Hansen.
   Fagsystemet får markeret Hans Hansen's stamdata, således det kan opdateres når en sundhedsperson tilgår Hans Hansen's journal næste gang.
3. Når Hans Hansen møder op på afdelingen, vil sundhedspersonen slå op på Hans Hansens data. Fagsystemet vil synkronisere stamdata, og i dette tilfælde opdatere Hans Hansens telefonnummer fra Fælles Stamkort (ud fra sundhedspersonens medarbejdercertifikat). I dette eksempel har fagsystemet lavet en markering at Hans Hansen's telefonnummer er opdateret således sundhedspersonen er informeret.
   Synkroniseringen bevirker følgende:
   1. Der laves automatisk opslag mod MinSpærring, med sundhedspersonens medarbejdercertifikat, fagsystemet skal agere ud fra svaret. (Eksempelvis gøre opmærksom over for sundhedspersonen at der foreligger en spærring)
   2. Der laves automatisk en behandlingsrelationsopfølgning
   3. Der laves automatisk en registrering i patientens MinLog - således patienten har indsigt i hvordan data er benyttet (i dette tilfælde kan Hans Hansen se at sundhedspersonen har hentet Fælles Stamkort).

System kald ved læsning af Fælles Stamkort

Fagsystemer vil kunne hente egne borgeres stamkort via et system kald udenfor konteksten af en sundhedsfaglig bruger. Dermed har fagsystemet mulighed for at kunne lave en asynkron opdatering af lokale kopier af borgerens Fælles Stamkort, uden en sundhedsfaglig bruger involveres. Fagsystemet kan derved eksempelvis lave brevfletning, generere arbejdslister og kørelister med borgerens opdaterede adresse og kontaktinformation i batch-jobs.

Borgere har dog mulighed for at spærre for deling af sit Fælles Stamkort via MinSpærring. Dette er uanset om brugeren der spærres for har en sundhedsfaglig autorisation, er under bemyndigelse/trust eller er et system.
Både systemer og brugere vil blive fortalt at der foreligger en spærring når et Fælles Stamkort hentes, som beskrevet i Håndtering af spærring og fuldmagt. Fagsystemet skal således kunne håndtere dette, f.eks ved at brugeren foretager et værdispring, eller spørger borgeren om samtykke til at se oplysningerne.
Fagsystemet skal desuden, som lovgivningen foreskriver det, indføre samtykket i patientjournalen.

I forhold til logning, så er programmet blevet meddelt at i forbindelse med overgangen til Minlog version 2, vil Sundhedsdatastyrelsen ikke længere kunne understøtte system-logninger, hvor der ikke er en brugerkontekst tilknyttet. Da bekendtgørelsen om drift m.v. af den fælles digitale infrastruktur (Bekendtgørelse om drift m.v. af den fælles digitale infrastruktur (retsinformation.dk)) kræver logning med brugerkontekst ved al anvendelse af persondata, betyder det at anvender systemer skal registre anvendelsen via MinLog-2, når system-system kommunikation benyttes til at hente en borgers Fælles Stamkort. Ved system-system kommunikation, vil der kun være information om hvilken organisation der har hentet stamkortet, og ikke information om den konkrete bruger. Dette betyder at anvender systemet godt kan synkronisere en borgers Fælles Stamkort via system-system adgang, men at anvender systemet skal lave en registrering i Minlog, når en sundhedsfaglig bruger anvender borgerens data, så borgeren kan se hvem der har tilgået deres Fælles Stamkort. Anvendersystemets Minlog registrering skal indeholde følgende:

• Hvem der har foretaget opslag med angivelse af fornavn, efternavn samt autorisationsnummer eller titel,
• Behandlingssted, hvorfra opslaget er foretaget
• Tidspunkt for opslaget.

Den tekniske dokumentation til Minlog findes på: https://www.nspop.dk/display/public/web/MinLog2+-+Min+Log+Registrering

Teknisk løsning

Den tekniske løsning forudsætter at der kan laves opslag på en borgeres Fælles Stamkort udenfor kontekst af en sundhedsfaglig bruger. Dertil laves der et nyt endpoint for dokument delingsservicen, der kan håndtere dette. Forudsætninger for adgang til dette endpoint vil være en whitelisting af det certifikat fagsystemet benytter til at læse data.
Den tekniske dokumentation til anvendere af servicen findes på https://www.nspop.dk/display/public/web/SFSK+-+Guide+til+Anvendere 

Bemærk: det er udelukkende læsning af Fælles Stamkort, der kan foretages via et system-kald, skrivning skal foretages i kontekst af en sundhedsfaglig bruger (medarbejder certifikat)

Fagsystemer der tilsluttes, skal have en whitelisting af det funktionscertifikat der benyttes til at læse data via systemkald.

Tilslutning skal anmeldes via den nationale servicedesk[1], hvor der oprettes en supportsag. Supportsagen skal indeholde "Subject" fra certifikatet, som følgende eksempel viser

Subject: SERIALNUMBER=CVR:11111111-FID:22222222 + CN=www.test-eksempel.dk – NemLogin (funktionscertifikat), O=Test-eksempel A/S // CVR:00000000, C=DK

Til produktionsmiljøet, skal det være systemcertifikatet for de parter der anvender løsningen.
Til testmiljøer kan systemleverandørernes systemcertifikater også whitelistes.

Endpoint NSP TEST-1:

• ITI-18 (Søgning): https://test1-cnsp.ekstern-test.nspop.dk:8443/sfsk/dgws-wsdl/iti18.wsdl
  
• ITI-43 (Udtræk): https://test1-cnsp.ekstern-test.nspop.dk:8443/sfsk/dgws-wsdl/iti43.wsdl
  

Endpoint NSP TEST-2:

• ITI-18 (Søgning): https://test1-cnsp.ekstern-test.nspop.dk:8443/sfsk/dgws-wsdl/iti18.wsdl
  
• ITI-43 (Udtræk): https://test1-cnsp.ekstern-test.nspop.dk:8443/sfsk/dgws-wsdl/iti43.wsdl
  
  

Grænsefladerne vil være uændrede i forhold, da det stadig er ITI-18 og ITI-43 kald til dokumentdelingsservicen der benyttes, der vil dog være et nyt endpoint, der udelukkende kan benyttes til at hente Fælles Stamkort via et system kald. Dette endpoint kan ikke benyttes til af hente andre typer af dokumenter (Aftaler, Planer, PRO-skemaer m.v.)

Har borgeren spærret for deling af sit Fælles Stamkort, kan fagsystemerne godt hente data ind lokalt, fagsystemerne skal dog kunne håndtere dette, ved eksempelvis at gemme denne spærring lokalt - eksempelvis som et flag der kontrolleres inden stamkortet benyttes. Fagsystemerne skal kunne advisere brugerne om at borgerens Fælles Stamkort er spærret, og enten give brugeren mulighed for at foretage et værdispring, eller anmode borgeren om et samtykke, inden data benyttes. Værdispring eller samtykke skal indføres i fagsystemets journalsystem som Sundhedloven angiver det.
Der indføres ligeledes en mulighed for fagystemet, til at lytte på adviseringer angående borgerens spærringer, se Håndtering af spærring og fuldmagt, derved kan fagsystemet fjerne den lokale spærring, og benytte data som loven foreskriver det.
Fagsystemet kan også vælge ikke at have en lokal kopi af en borger Fælles Stamkort, hvis borgeren har lavet en spærring. Det er op til fagsystemets egne processer at kunne håndtere dette.

Teknisk implementering

Afsnittet indeholder tekniske vejledninger til hvordan Fælles Stamkort kan integrereres i lokale fagsystemer og patient/borgerportaler.

Fagsystemer og borgerportaler der skal benytte Fælles Stamkort, skal godkendes og certificeres af MedCom. Testprotokollerne for certificering til Fælles Stamkort, hvor version 1.0 er gældende for modtagelse, kan findes på MedCom's hjemmeside under: Testprotokoller for modtagelse af Fælles Stamkort

Yderligere information om om hvordan CDA dokumenter er opbygget kan findes hos IHE, under: IHE - Hvad er HL7 CDA?

Indhold i Fælles Stamkort

Indholdet i Fælles stamkort er defineret i CDA profilen: Personal Data Card (PDC-DK) [version 2.0].
Update 10/10-2022: MedCom har opdateret Errata, hvori der er enkelte præciseringer samt rettelser af fejl i forhold til PDC-DK 2.0., Errata'en kan hentes på MedCom's hjemmeside, og er gældende sammen med PDC-DK 2.0 profilen.

Indholdet er struktureret således at generelt stamdata om patienten er en del af den generiske CDA header, som beskriver alle typer af CDA dokumenter. Den generiske CDA header er beskrevet i dokumentet: HL7 Implementation Guide for CDA Release 2.0 CDA Header (DK CDA Header)₃.
Body delen af dokumentet component.structuredBody indeholder staminformation om patienten, der enten er taget fra registre eller tastet ind manuelt.
Nedenstående tabel giver et indblik i hvilket indhold der findes i Fælles Stamkort, samt hvad der er kilden.

Fælles Stamkort CDA dokumenter er alle udstedt af Sundhedsdatastyrelsen via SOR enheden: "Fælles Stamkort udstedelse" med SOR-ID: "1126211000016009"

_{3 http://svn.medcom.dk/svn/releases/Standarder/HL7/CDA-Header/}

Visning af felter i Fælles Stamkort

Tabellen viser hvilke data elementer der skal vises til slutbrugerne for Fælles Stamkort.

Bemærk at har man patientens CPR-oplysninger fra eksempelvis egen registerkopi, bør disse benyttes. Fælles Stamkort trækker CPR oplysninger fra sin egen registerkopi.

Nogle felter er ikke obligatoriske, hvilket vil sige det er ikke sikkert de findes i patientens Fælles Stamkort, men hvis de findes - skal de vises for slutbrugeren.

Tekniske forudsætninger

Se Administrative forudsætninger for at få adgang til NSP'en.

Fælles stamkort udstilles via services på NSP'en, disse skal tilgås gennem en afkoblingskomponent "DCC'en" DCC'en viderestiller kald til underliggende services, så der er ikke en WSDL for DCC'en. Se DCC Dokumentation for adgang til servies gennem DCC'en.

NSP services kan tilgås enten via Den Gode Webservice eller via OIO-IDWS (Udelukkende patient adgang).
Den Gode WebService benytter XMLDSIG til at signere SAML assertions ud fra X.509 certifikater/nøgler - for adgang til Fælles Stamkort skal sundhedspersoner have et gyldigt Nem-ID Medarbejdercertifikat (MOCES) - for mere information om den gode webservice, se: https://www.medcom.dk/standarder/webservice-standarder/den-gode-webservice

Til at understøtte SAML har Sundhedsdatastyrelsen udviklet biblioteker til Java og .NET (SEAL biblioteket) Dette bør benyttes så vidt det er muligt, se STS Dokumentation

Søgning på Fælles Stamkort

For at søge på en patients Fælles Stamkort, skal der laves en ITI-18 forespørgsel via NSP'ens dokumentdelingsservice.

WSDL til DDS Registry findes her: https://wsdl.nspop.dk/ddsregistry?wsdl

Når der søges på et stamkort, kan der søges på de værdier der er angivet i dokument metadata. Fælles Stamkort benytter MedCom's metadata profil version 0.96, der kan hentes på https://svn.medcom.dk/svn/releases/Standarder/IHE/DK_profil_metadata/

Typisk angives patientens kun CPR nummer, samt en typecode - For Fælles Stamkort er typecode "PDC", og da Fælles Stamkort er en on-demand dokumenttype angives dette også. Se følgende eksempel.

		<AdhocQueryRequest xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0">
			<ResponseOption returnType="LeafClass" returnComposedObjects="true"/>
			<AdhocQuery xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d">
				<Slot name="$XDSDocumentEntryPatientId">
					<ValueList>
						<Value>'2512489996^^^&1.2.208.176.1.2&ISO'</Value>
					</ValueList>
				</Slot>
				<Slot name="$XDSDocumentEntryTypeCode">
					<ValueList>
						<Value>('PDC^^1.2.208.184.100.1')</Value>
					</ValueList>
				</Slot>
				<Slot name="$XDSDocumentEntryType">
					<ValueList>
						<Value>('urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248')</Value>
					</ValueList>
				</Slot>
			</AdhocQuery>
		</AdhocQueryRequest>

Svaret indeholder referencen til Fælles Stamkort dokumentet, der skal benyttes efterfølgende til at udtrække selve Fælles Stamkort dokumenter

		<ns3:AdhocQueryResponse xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns7="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns8="http://www.w3.org/2000/09/xmldsig#" xmlns:ns9="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns10="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns11="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" totalResultCount="1" status="urn:ihe:iti:2007:ResponseStatusType:PartialSuccess">
			<RegistryObjectList>
				<ExtrinsicObject mimeType="text/xml" objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b52" home="1.2.208.176.8.1.12">
					<Slot name="creationTime">
						<ValueList>
							<Value>20191129120611</Value>
						</ValueList>
					</Slot>
					<Slot name="languageCode">
						<ValueList>
							<Value>da-DK</Value>
						</ValueList>
					</Slot>
					<Slot name="repositoryUniqueId">
						<ValueList>
							<Value>1.2.208.176.43210.8.10.12</Value>
						</ValueList>
					</Slot>
					<Slot name="sourcePatientId">
						<ValueList>
							<Value>2512489996^^^&1.2.208.176.1.2&ISO</Value>
						</ValueList>
					</Slot>
					<Name>
						<LocalizedString xml:lang="en-US" charset="UTF-8" value="Fælles stamkort"/>
					</Name>
					<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b52" nodeRepresentation="" id="urn:uuid:2dc69467-1a1a-43a5-a300-7ff085dc4ad7">
						<Slot name="authorInstitution">
							<ValueList>
								<Value>Sundhedsdatastyrelsen^^^^^&1.2.208.176.1.1&ISO^^^^634491000016008</Value>
							</ValueList>
						</Slot>
					</Classification>
					<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b52" nodeRepresentation="001" id="urn:uuid:76545ece-d1f8-46fe-84ad-69b84caba60c">
						<Slot name="codingScheme">
							<ValueList>
								<Value>1.2.208.184.100.9</Value>
							</ValueList>
						</Slot>
						<Name>
							<LocalizedString xml:lang="en-US" charset="UTF-8" value="Klinisk rapport"/>
						</Name>
					</Classification>
					<Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b52" nodeRepresentation="DK FSK Schema" id="urn:uuid:9216fb14-c16f-499c-bb48-f67b956aac59">
						<Slot name="codingScheme">
							<ValueList>
								<Value>urn:ad:dk:medcom:fsk:full</Value>
							</ValueList>
						</Slot>
						<Name>
							<LocalizedString xml:lang="en-US" charset="UTF-8" value="DK FSK Schema"/>
						</Name>
					</Classification>
					<Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b52" nodeRepresentation="554041000005106" id="urn:uuid:0cde4f59-9e49-4dfb-925a-9325564dc47e">
						<Slot name="codingScheme">
							<ValueList>
								<Value>2.16.840.1.113883.6.96</Value>
							</ValueList>
						</Slot>
						<Name>
							<LocalizedString xml:lang="en-US" charset="UTF-8" value="sundhedsforvaltning"/>
						</Name>
					</Classification>
					<Classification classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b52" nodeRepresentation="52460-3" id="urn:uuid:f6aec0bd-8ee0-4ad3-932f-cb4c6314fa84">
						<Slot name="codingScheme">
							<ValueList>
								<Value>2.16.840.1.113883.6.1</Value>
							</ValueList>
						</Slot>
						<Name>
							<LocalizedString xml:lang="en-US" charset="UTF-8" value="Patient Information"/>
						</Name>
					</Classification>
					<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b52" nodeRepresentation="N" id="urn:uuid:84b2075d-0ded-4bec-b50a-c67d9cbb83d2">
						<Slot name="codingScheme">
							<ValueList>
								<Value>2.16.840.1.113883.5.25</Value>
							</ValueList>
						</Slot>
						<Name>
							<LocalizedString xml:lang="en-US" charset="UTF-8" value="normal"/>
						</Name>
					</Classification>
					<ExternalIdentifier registryObject="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b52" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="0202999573^^^&1.2.208.176.1.2&ISO" id="urn:uuid:f8d811f5-1d9a-4774-a49c-0c90c01ce0d8">
						<Name>
							<LocalizedString value="XDSDocumentEntry.patientId"/>
						</Name>
					</ExternalIdentifier>
					<ExternalIdentifier registryObject="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b52" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b52" id="urn:uuid:da6376b7-0cb9-4bfd-a80e-241cff0be6de">
						<Name>
							<LocalizedString value="XDSDocumentEntry.uniqueId"/>
						</Name>
					</ExternalIdentifier>
				</ExtrinsicObject>
			</RegistryObjectList>
		</ns3:AdhocQueryResponse>

Der er tre værdier der skal benyttes:

1. HomeCommunityId - der beskriver det domæne dokumentet befinder sig i.

   Værdien hentes ud fra ...ExtrinsicObject/@home
   
   

2. RepositoryUniqueId - der bekriver den kilde under domænet der opbevarer dokumentet
   Værdien hentes ud fra ...ExtrinsicObject/Slot[@name=’repositoryUniqueId’]/Value List/Value
   
   
3. DocumentUniqueId - der identificerer selve dokumentet
   Værdien hentes ud fra ...ExtrinsicObject/ExternalIdentifier[@identificationScheme=’urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab]/@value

Yderligere information omkring forespørgsler via dokumentdeling kan ses i Brugervejledning til forespørgsler via DDS

Hentning af Fælles Stamkort

For at hente en patients Fælles Stamkort, skal der laves en ITI-43 forespørgsel via NSP'ens dokumentdelingsservice.

Som beskrevet ovenfor benyttes de tre værdier: HomeCommunityId, RepositoryUniqueId og DocumentUniqueId til at hente dokumentet.

WSDL til DDS Repository findes her: https://wsdl.nspop.dk/ddsrepository?wsdl

		<ns2:RetrieveDocumentSetRequest xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns2="urn:ihe:iti:xds-b:2007">
			<ns2:DocumentRequest>
				<ns2:HomeCommunityId>1.2.208.176.8.1.12</ns2:HomeCommunityId>
				<ns2:RepositoryUniqueId>1.2.208.176.43210.8.20.12</ns2:RepositoryUniqueId>
				<ns2:DocumentUniqueId>1.2.208.176.43210.8.20.12^c6d6d930-6c34-4eb0-a363-a1cf759b8587</ns2:DocumentUniqueId>
			</ns2:DocumentRequest>
		</ns2:RetrieveDocumentSetRequest>

Det svar der returneres er patientens Fælles Stamkort, indeholdende de dataelementer der er beskrevet under indhold.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:ns2="urn:hl7-org:sdtc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" moodCode="EVN" xsi:schemaLocation="urn:hl7-org:v3 http://svn.medcom.dk/svn/releases/Standarder/HL7/Generic/Schema/CDA_SDTC.xsd">
	<realmCode code="DK"/>
	<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
	<templateId root="1.2.208.184.16.1"/>
	<id root="1.2.208.184" extension="f88f5d86-814d-418d-9a85-0dd04b2309a2" assigningAuthorityName="MedCom"/>
	<code code="PDC" codeSystem="1.2.208.184.100.1" codeSystemName="MedCom Message Codes" displayName="Stamkort"/>
	<title>Personal Data Card for 1010880846</title>
	<effectiveTime value="20220125130312+0100"/>
	<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
	<languageCode code="da-DK"/>
	<recordTarget typeCode="RCT" contextControlCode="OP">
		<patientRole classCode="PAT">
			<id root="1.2.208.176.1.2" extension="1010880846" assigningAuthorityName="CPR"/>
			<addr use="H">
				<streetAddressLine>Lønvejen 469</streetAddressLine>
				<postalCode>0445</postalCode>
				<city>Tjørnuvík</city>
				<country>DK</country>
			</addr>
			<patient classCode="PSN">
				<name>
					<given>Julia</given>
					<given>B65</given>
					<family>Hansen</family>
				</name>
				<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>
				<birthTime value="19881010"/>
			</patient>
			<providerOrganization>
				<id root="1.2.208.176.1.4" extension="905120" assigningAuthorityName="Yderregisteret"/>
				<name>Læge Mette Larsen</name>
				<telecom use="WP" value="tel:68441743"/>
				<addr use="H">
					<streetAddressLine>Morbærvej50</streetAddressLine>
					<postalCode>7321</postalCode>
					<city>Gadbjerg</city>
				</addr>
			</providerOrganization>
		</patientRole>
	</recordTarget>
	<author>
		<time value="20220125130312+0100"/>
		<assignedAuthor>
			<id root="1.2.208.176.1.1" extension="1126211000016009" assigningAuthorityName="SOR"/>
			<representedOrganization>
				<name>Fælles Stamkort udstedelse</name>
			</representedOrganization>
		</assignedAuthor>
	</author>
	<custodian>
		<assignedCustodian>
			<representedCustodianOrganization>
				<id root="1.2.208.176.1.1" extension="1126211000016009" assigningAuthorityName="SOR"/>
				<name>Fælles Stamkort udstedelse</name>
			</representedCustodianOrganization>
		</assignedCustodian>
	</custodian>
	<documentationOf typeCode="DOC">
		<serviceEvent classCode="ACT" moodCode="EVN">
			<templateId root="1.2.208.184.10.1.11"/>
			<effectiveTime>
				<low value="20220125130312+0100"/>
				<high nullFlavor="NA"/>
			</effectiveTime>
		</serviceEvent>
	</documentationOf>
	<documentationOf typeCode="DOC">
		<serviceEvent classCode="ACT" moodCode="EVN">
			<templateId root="1.2.208.184.10.1.10" extension="2019-09-10"/>
			<id root="1.2.208.184.100.10" extension="pdc-v2.0" assigningAuthorityName="MedCom"/>
		</serviceEvent>
	</documentationOf>
	<component typeCode="COMP" contextConductionInd="true">
		<structuredBody classCode="DOCBODY" moodCode="EVN">
			<component typeCode="COMP" contextConductionInd="true">
				<section classCode="DOCSECT" moodCode="EVN">
					<templateId root="1.2.208.184.16.1.10.20.1" extension="2019-08-14"/>
					<text>
						<paragraph>Øvrige oplysninger</paragraph>
						<table width="100%">
							<tbody>
								<tr>
									<th>Oplysning</th>
									<th>Værdi</th>
									<th>Kilde/Indtastet af</th>
									<th>Sidst ændret/Indtastet den</th>
								</tr>
								<tr>
									<td>Borgerens navn og adresse</td>
									<td>
										<list>
											<item>Julia B65 Hansen</item>
											<item>Lønvejen 469</item>
											<item>0445 Tjørnuvík</item>
											<item>DK</item>
										</list>
									</td>
									<td>CPR</td>
									<td>Ikke oplyst</td>
								</tr>
								<tr>
									<td>Sygesikringsgruppe</td>
									<td>
										<list>
											<item>1</item>
										</list>
									</td>
									<td>CPR</td>
									<td>Ikke oplyst</td>
								</tr>
								<tr>
									<td>Registreret organdonor</td>
									<td>
										<list>
											<item>Nej</item>
										</list>
									</td>
									<td>Dansk Center For Organdonation</td>
									<td>Ikke oplyst</td>
								</tr>
								<tr>
									<td>Registreret behandlingstestamente</td>
									<td>
										<list>
											<item>Nej</item>
										</list>
									</td>
									<td>Sundhedsdatastyrelsen</td>
									<td>Ikke oplyst</td>
								</tr>
								<tr>
									<td>Registreret livstestamente</td>
									<td>
										<list>
											<item>Nej</item>
										</list>
									</td>
									<td>Sundhedsdatastyrelsen</td>
									<td>Ikke oplyst</td>
								</tr>
							</tbody>
						</table>
					</text>
					<entry typeCode="COMP">
						<observation classCode="OBS" moodCode="EVN">
							<templateId root="1.2.208.184.16.1.10.20.1.26" extension="2019-08-14"/>
							<id root="1.2.208.184" extension="dd4170b0-27e2-4625-ae8a-eb053a90cbda"/>
							<code code="CitizenNameAddr" codeSystem="1.2.208.184.100.1" codeSystemName="MedCom Message Codes" displayName="Borgerens navn og adresse"/>
							<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="PN">
								<given>Julia</given>
								<given>B65</given>
								<family>Hansen</family>
							</value>
							<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="AD" use="H">
								<streetAddressLine>Lønvejen 469</streetAddressLine>
								<postalCode>0445</postalCode>
								<city>Tjørnuvík</city>
								<country>DK</country>
							</value>
							<author>
								<templateId root="1.2.208.184.16.1.10.20.31" extension="2019-08-14"/>
								<time nullFlavor="NI"/>
								<assignedAuthor>
									<id root="1.2.208.176.1.2" extension="NI" assigningAuthorityName="CPR"/>
									<representedOrganization>
										<name>CPR</name>
									</representedOrganization>
								</assignedAuthor>
							</author>
						</observation>
					</entry>
					<entry typeCode="COMP">
						<observation classCode="OBS" moodCode="EVN">
							<templateId root="1.2.208.184.16.1.10.20.1.27" extension="2019-08-14"/>
							<id root="1.2.208.184" extension="13ca1449-df19-408f-aedc-b8734a891294"/>
							<code code="CoverageGroup" codeSystem="1.2.208.184.100.1" codeSystemName="MedCom Message Codes" displayName="Sygesikringsgruppe"/>
							<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="II" root="1.2.208.176.1.99.99.99" extension="1" assigningAuthorityName="Sygesikringen"/>
							<author>
								<templateId root="1.2.208.184.16.1.10.20.31" extension="2019-08-14"/>
								<time nullFlavor="NI"/>
								<assignedAuthor>
									<id root="1.2.208.176.2.7" extension="NI" assigningAuthorityName="Sygesikringen"/>
									<representedOrganization>
										<name>Sygesikringen</name>
									</representedOrganization>
								</assignedAuthor>
							</author>
						</observation>
					</entry>
					<entry typeCode="COMP">
						<observation classCode="OBS" moodCode="EVN">
							<templateId root="1.2.208.184.16.1.10.20.1.28" extension="2019-08-14"/>
							<id root="1.2.208.184" extension="5d9d425c-acf3-4c61-ace7-766237052ee7"/>
							<code code="OrganDonorRegistration" codeSystem="1.2.208.184.100.1" codeSystemName="MedCom Message Codes" displayName="Registreret organdonor"/>
							<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="II" root="1.2.208.176.1.10" extension="false" assigningAuthorityName="Dansk Center For Organdonation"/>
							<author>
								<templateId root="1.2.208.184.16.1.10.20.31" extension="2019-08-14"/>
								<time nullFlavor="NI"/>
								<assignedAuthor>
									<id root="1.2.208.176.1.10" extension="NI" assigningAuthorityName="CPR"/>
									<representedOrganization>
										<name>Dansk Center For Organdonation</name>
									</representedOrganization>
								</assignedAuthor>
							</author>
						</observation>
					</entry>
					<entry typeCode="COMP">
						<observation classCode="OBS" moodCode="EVN">
							<templateId root="1.2.208.184.16.1.10.20.1.29" extension="2019-08-14"/>
							<id root="1.2.208.184" extension="70f56d3b-e30f-4dfa-8a0a-b41a8f0b3e58"/>
							<code code="TreatmentWillRegistration" codeSystem="1.2.208.184.100.1" codeSystemName="MedCom Message Codes" displayName="Registreret behandlingstestamente"/>
							<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="II" root="1.2.208.176.1.9" extension="false" assigningAuthorityName="Sundhedsdatastyrelsen"/>
							<author>
								<templateId root="1.2.208.184.16.1.10.20.31" extension="2019-08-14"/>
								<time nullFlavor="NI"/>
								<assignedAuthor>
									<id root="1.2.208.176.1.9" extension="NI" assigningAuthorityName="Sundhedsdatastyrelsen"/>
									<representedOrganization>
										<name>Sundhedsdatastyrelsen</name>
									</representedOrganization>
								</assignedAuthor>
							</author>
						</observation>
					</entry>
					<entry typeCode="COMP">
						<observation classCode="OBS" moodCode="EVN">
							<templateId root="1.2.208.184.16.1.10.20.1.30" extension="2019-08-14"/>
							<id root="1.2.208.184" extension="b11ffc4e-7ebd-4c3e-924c-5bffa7b37906"/>
							<code code="LivingWillRegistration" codeSystem="1.2.208.184.100.1" codeSystemName="MedCom Message Codes" displayName="Registreret livstestamente"/>
							<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="II" root="1.2.208.176.1.8" extension="false" assigningAuthorityName="Sundhedsdatastyrelsen"/>
							<author>
								<templateId root="1.2.208.184.16.1.10.20.31" extension="2019-08-14"/>
								<time nullFlavor="NI"/>
								<assignedAuthor>
									<id root="1.2.208.176.1.8" extension="NI" assigningAuthorityName="Sundhedsdatastyrelsen"/>
									<representedOrganization>
										<name>Sundhedsdatastyrelsen</name>
									</representedOrganization>
								</assignedAuthor>
							</author>
						</observation>
					</entry>
				</section>
			</component>
		</structuredBody>
	</component>
</ClinicalDocument>

Opdatering af Fælles Stamkort

Fælles Stamkort læses som beskrevet via dokumentdeling, men opdateres via Stamkort register servicen

WSDL findes under: https://wsdl.nspop.dk/#skr hvor der både er referencer til snitfladen for sundhedspersoner via Den Gode Webservice (DGWS) samt snitfladen for patientadgang via OIO-IDWS.

Den tekniske anvenderguide til Stamkortregisteret giver detaljeret information om dataudvekselingsformater samt XML eksempler på oprettelser, opdateringer og sletninger

Sikkerhed, roller og rettigheder

For adgang til Fælles Stamkort skal der for sundhedspersoner eksistere et gyldigt SOSI-ID kort som er signeret af NSP'ens Secure Token Service, dokumentationen for SoSI-ID kort og STS ligger under: Anvenderguide til STS

Patientdata portaler skal benytte det fællesoffentlige OIO-IDWS, der er vedligeholdt af Digitaliseringsstyrelsen - dokumentation til OIO-IDWS findes på Digitaliser.dk, STS'en har en omvekslingsservice for OIO-IDWS bootstraptokens til et signeret identitytoken, for adgang til Fælles Stamkort webservicen kald er benyttes et STS signeret identitytoken.

Sundhedspersoner, med en sundhedsfaglig autorisation har adgang til Fælles Stamkort. Sundhedspersoner uden sundhedsfaglig autorisation skal have tilknyttet en rettighed før disse kan få adgang. Lokale organisationer kan enten tilknytte disse rettigheder via Sundhedsstyrelssens Elektroniske Brugerstyring (SEB), eller give rettigheden via den lokale identifikations- og rettighedstyring.

Følgende rollebeskrivelser anvendes i forbindelse med Et samlet patientoverblik.

En sundhedsperson kan ikke have tilknyttet flere roller på samme tid - dette skal administreres via den lokale identifikations- og rettighedsstyring.

 Bemærk: SEB-dokumentationen samt vejledningen ved oprettelse af en rolle er ved at blive tilrettet, så rettigheden for nspSundAsisstR2 afspejler ovenstående.

Håndtering af spærring og fuldmagt

Spærring

Patienten kan have spærret for at data fra Fælles Stamkort må deles med andre parter i sundhedssektoren, i det tilfælde vil fejlkoden "Consent Filter Applied” blive returneret (se nedenstående xml eksempel for ITI-18 spærrede dokumenter). Det betyder at patienten har spærret for deling af Fælles Stamkort til en specifik sundhedsperson, eller at spærringen er lavet specifikt mod deling af Fælles Stamkort (via SOR-id: 1126211000016009). Klienten skal håndtere at der er angivet en spærring, og give sundhedspersonen mulighed for at få adgang til Fælles Stamkort under specielle vilkår. 

For adgang til det spærrede Fælles Stamkort kan klienten enten angive et værdispring, eller angive at der ligger et explicit samtykke til at se data, og så sende forespørgslen igen med “ConsentOverride” flaget sat til “True”. Der laves logning i dokumentdelingsinfrastrukturen der angiver at en spærring er tilsidesat. Klienten skal samtidig angive årsagen (Eksempelvis: eksplicit samtykke fra patienten for at få adgang til data) til at spærringen er tilsidesat i eget journalsystem, da der kan forventes at være opfølgning på tilsidesatte spærringer.

Yderligere teknisk information omkring spærring og forespørgsler via dokumentdeling kan ses i Brugervejledning til forespørgsler via DDS

<rs:RegistryError codeContext="urn:dk:nsi:Consent Filter Applied" errorCode="XDSRegistryError" severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/>

Adviseringer på borgerens spærring

Har en borger spærret for deling af Fælles Stamkort, og benytter løsningen for system-system kald, som beskrevet i afsnit 3.5 - System kald ved læsning af Fælles Stamkort, vil fagsystemet have et behov for at blive adviseret hvis borgeren ændrer sine spærringer.

Fagsystemerne bør implementere en adviseringskomponent, der håndterer at fagsystemet kan lytte på adviseringer fra MinSpærring (Samtykkeservicen)
Den tekniske dokumentation i forhold til brugen af endpoints til NAS, er beskrevet i NAS-2 Anvenderguide

Topic

Navn til Topic for ændringer til MinSpærring (samtykkeservicen) er: 

Beskedformat

Beskedformat for ændringer i MinSpærring (samtykkeservicen), er pakket ind i NAS'ens generelle beskedformat (Markeret med blåt)

Indholdet i notifikationen er neutralt, idet der ikke må inkluderes hvad ændringen omhandler. Følgende værdier ligger i adviseringen 

• id: Patientens CPR nummer
• date: Dato for hvornår ændringen er sket
• version: Versionsnummer for beskeddefinitionen.

Det skal bemærkes, at der godt kan foreligge flere adviseringer for den samme borger, da der vil blive skabt en advisering hver gang der er foretaget en ændring på borgerens spærringer. Fagsystemet skal kunne håndtere dette scenarie.

Ved tekniske fejl er der altid en risiko for at adviseringer går tabt, fagsystemet bør derfor have mulighed for at synkronisere med Fælles Stamkort, selvom det ikke har modtaget en advisering på at en borger har ændret en spærring, eksempelvis via en aktiv handling fra en sundhedsperson.

Fuldmagt

Patient/borgerportaler kan give patienternes pårørende adgang via den Fælles Offentlige Fuldmagtsservice, hvortil der er tilknyttet en brugergrænseflade på Borger.dk.

Bevis for fuldmagter er understøttet i OIO-IDWS identitytokens signeret af STS'en, dog understøtter dokumentdelingsservicen ikke OIO-IDWS - så fuldmagter er i stedet etableret via en trust-løsning hvor patientportalen selv håndterer kontrol af fuldmagter.

Information angående angivelse af fuldmagter via dokumentdelingsservicen, kan ses i HSUID header dokumentation.

Ændringslog