Indledning

Denne vejledning beskriver de tekniske implementeringsregler 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 3.0]2, der bl.a. anvendes til at udstille patientens Fælles Stamkort inklusiv borgerens status for Fravalg af Genoplivning v. Hjertestop. 
 
Bemærk: Fælles Stamkort version 2.0 er lukket ned pr. 15/1-2025, grundet ibrugtagningen af Fravalg af Genoplivning v. Hjertestop. 

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

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

Anden dokumentation

Som en del af Fælles stamkort findes Fravalg af Genoplivningsforsøg. Denne løsning kan der læses yderligere om her:  https://www.nspop.dk/display/FGVH 

Teknisk oversigt

Udveksling af patientens Fælles Stamkort foregår via den nationale infrastruktur til deling af dokumenter. Denne understøtter referencearkitekturen for deling af dokumenter og billeder. Med indførslen af Fælles Stamkort 3.0 er det ikkelængere muligt for borgere at frabede sig deling af stamoplysninger. Oplysningerne i Fælles Stamkort deles som dokumentdeling via synkroniseringsservice til Fælles Stamkort (SFSK). 

  
Fælles Stamkort er understøttet af to overordnede services - Hent Fælles Stamkort samt Opdater Stamkortregister. Disse services vil indgå i lokale fagsystemer samt 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 3.0). 

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

Fælles Stamkort komponenten (FSK) beskriver model og grænsefladebeskrivelser for CDA udvekslingsformatet. 
Fælles Stamkort komponenten 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. Indhentning af Fælles Stamkort foregår via synkroniseringsservicen (SFSK) på den nationale service platform ved brug af HL7's standard ITI-18 og ITI-43 grænseflader. 
Anvenderrettet dokumentation om Synkroniseringsservicen (SFSK) ligger beskrevet under https://www.nspop.dk/display/public/web/SFSK+-+Guide+til+Anvendere 

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

Migrering af data fra lokale fagsystemer til Fælles Stamkort

Det er ikke længere muligt at anvende migreringsservicen. Funktionaliteten vedr. migrering er arkiveret, anvend fremadrettet den beskrevne proces for synkronisering af data mellem lokale fagsystemer og Fælles Stamkort 

Dokumentation for migrering bibeholdes indtil servicen er lukket ned, og kan ses under: Migrering af data fra lokale fagsystemer til Fælles Stamkort

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 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 hvem der har opdateret data – om det er borgeren selv eller en given organisation. Information omkring opdateringstidspunkt skal også gemmes i det lokale fagsystem, så 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 to tilknyttede telefonnumre og gør dette via sundhed.dk.

Fagsystemet ser ved næste opslag på patientens data, at kontaktinformationer har et nyere tidsstempel end de lokal 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. 

Lokal information tilknyttet data i Stamkortregisteret

Da hver data-entitet i Stamkortregisteret har tilknyttet et unikt id, er det muligt at have lokale informationer, der kun befinder sig i eget fagsystem, tilknyttet data i stamkortregisteret.  
Bemærk: Det er ikke et krav at fagsystemer skal kunne understøtte yderligere tilknytning af data til informationen i Fælles Stamkort. 

Information der kan ligge lokalt, kan være: 

• Telefonnummer som borgeren ikke ønsker delt via Fælles Stamkort 

• Midlertidig adresse som borgeren ikke ønsker delt via Fælles Stamkort 

• Pårørende oplysninger som borgeren ikke ønsker delt via Fælles Stamkort 

• Prioritet for kontakt til pårørende 

• Yderligere information angående pårørende, som ikke ønskes delt, eller kan deles via nuværende grænseflade 

Eksempelvis kan pårørende Hans Hansen fra ovenstående eksempler med ID: 9c13a4e6-fa0e-4740-833b-1e9e80ecc18e være 1. prioritet som skal kontaktes når det er en indlæggelse for borgeren, men 2. prioritet når det handler om kommunale ydelser. Fagsystemet på hospitalet har derved tilknyttet information om 1. prioritet til Hans Hansen, hvorimod det kommunale fagsystem har tilknyttet 2. prioritet til Hans Hansen. 
Skulle borgeren ikke længere ønske Hans Hansen som pårørende, og derved sletter denne, kan fagsystemerne tilsvarende slette de tilknyttede oplysninger når de modtager ændringen via Fælles Stamkort.  

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ølger 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, organdonorregisteret, livs- og behandlingstestamenteregisteret samt register for fravalg af genoplivningsforsøg v. hjertestop. Den tekniske dokumentation i forhold til brugen af de viste endpoints til NAS, er beskrevet i NAS-2 Anvenderguide . 

Information om organdonorregisteret, livs- og behandlingstestamenteregisteret samt register for fravalg af genoplivningsforsøg v. hjertestop kan fremfindes på https://www.nspop.dk.

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
Endpoint NSP Produktion: Der skal laves en sundhedsdatanetaftale mod: Service #2127 (195.80.254.10 nas-prod.nsp.dsdn.dk (http_8080, tcp-8443))

Beskedformat 

Beskedformat for ændringer i Stamkortregisteret, er pakket ind i NAS'ens generelle beskedformat. Se Stamkortregisterets anvenderguide for detaljeret beskrivelse af formatet. Bemærk at indholdet i notifikationen er neutralt, idet der ikke må inkluderes, hvad ændringen omhandler, kun at der er sket en ændring på borgerens data i stamkortregisteret. 

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, bør der kun foretages en synkronisering, således nyeste data hentes. 

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 to 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 en behandlingsrelationsopfølgning
   2. Der laves 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). (Registreringer til MinLog foretages af fagsystemer selv, hvis der anvendes systemkald) 

System kald ved læsning af Fælles Stamkort

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

I forhold til logning kræver 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),at der laves logning med brugerkontekst ved anvendelse af persondata. 
Det betyder, at anvendersystemer selv skal registrere brugeranvendelsen af Fælles Stamkort til MinLog når system-til-system kommunikation benyttes til at hente en borgers 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 herunder MinLog's vejledningsdokument, som angiver kravene til, hvordan der skal logges. 
Der bliver udført test og godkendelse af anvendersystemerne i forhold til logning jvf. Test af Fælles Stamkort.

Teknisk løsning

Den tekniske løsning forudsætter, at der kan laves opslag på en borgers Fælles Stamkort udenfor kontekst af en sundhedsfaglig bruger.  
Den tekniske dokumentation til anvendere af synkroniseringsservicen til Fælles Stamkort (SFSK-servicen findes i SFSK's anvenderguide. 

Der er ligeledes understøttelse af systemkald for oprettelse/ændring af data i stamkortregisteret, se dette i anvenderguide til stamkortregisteret. 

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=CN=TestCert Org, serialNumber = UI:DK-O:G:34e1043d-2d2a-4e3d-ab40-743db4276b12, O = Min Organisation, organizationIdentifier = NTRDK-12345678, 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 og TEST-2: Se anvenderguiden for synkroniseringsservice til Fælles Stamkort: https://www.nspop.dk/display/public/web/SFSK+-+Guide+til+Anvendere

Endpoint Produktion: Skal hentes via MedCom's aftalesystem til sundhedsdatanettet, som bekrevet under Administrative forudsætninger for tilslutning#Aftalemedsundhedsdatanettet

Synkroniseringsservicen (SFSK) følger principperne for dokumentdeling, så det er ITI-18 og ITI-43 kald, der benyttes. Dette endpoint kan udelukkende benyttes til at hente Fælles Stamkort, og kan derfor ikke benyttes til at hente andre typer af dokumenter (Aftaler, Planer, PRO-skemaer m.v.). 

Teknisk implementering

Afsnittet indeholder tekniske vejledninger til, hvordan Fælles Stamkort kan integreres i lokale fagsystemer og borgerportaler. 

Fagsystemer og borgerportaler der skal benytte Fælles Stamkort, skal godkendes og certificeres af MedCom samt End-2-End testes, inden produktionsadgang kan godkendes, som beskrevet under: Test af Fælles Stamkort.  

Yderligere information 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 3.0. 

Bemærk for version 3.0 vil errata fremadrettet blive indarbejdet i et "build" versionsnummer, eksempelvis til version 3.0.1. Build versionsnumre er præciseringer og rettelser der ikke ændrer på snitfladerne. 

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"

tel:\+?[-0-9().]+

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

Tekniske forudsætninger

Se Tilslutning 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 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 Guide til anvendere 

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

Snitflader og endpoints til SFSK er beskrevet i SFSK's guide til anvendere 

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. 

For Fælles stamkort, er der desuden følgende forretningsmæssige XDS-metadata, som skal anvendes i søgninger: 

• Typecode: PDC 

Når der forespørges på Fælles Stamkort, laves der et opslag til underliggende registre. Derfor  forespørges der altid på dynamiske (on-demand) dokumentkilder. Angives denne værdi ikke, returneres kun data fra statiske dokumentkilder. 

• Type: urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248 (for dynamiske "on-demand" dokumentkilder)

Fælles stamkort udstilles i en overgang i flere formater (version 2.0 og version 3.0). Angives formatkoden ikke, returneres begge versioner. Formatkode bør anvendes, så klienter ved hvilken version af standarden som efterspørges. 

• FormatCode:
  • urn:ad:dk:medcom:pdc-v2.0:full  (Fælles stamkort version 2.0) - Formatkode for version 2.0 returnerer pr. 15/1-2025 ikke længere data
  • urn:ad:dk:medcom:pdc-v3.0:full  (Fælles stamkort version 3.0)

Værdierne (klassifikationerne) som anvendes i XDS-metadata er defineret i et regneark hos MedCom, se: DK-IHE_Metadata-Common_Code_systems-Value_sets.xlsx

		<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="$XDSDocumentEntryFormatCode">
                    <ValueList>
                        <Value>('urn:ad:dk:medcom:pdc-v3.0:full^^1.2.208.184.100.10')</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>
                <Slot name="$XDSDocumentEntryStatus">
                    <ValueList>
                        <Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')</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:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success">
	<RegistryObjectList>
		<ExtrinsicObject mimeType="text/xml" objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="1.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" home="1.2.208.176.8.1.12">
			<Slot name="creationTime">
				<ValueList>
					<Value>20240125090207</Value>
				</ValueList>
			</Slot>
			<Slot name="languageCode">
				<ValueList>
					<Value>da-DK</Value>
				</ValueList>
			</Slot>
			<Slot name="repositoryUniqueId">
				<ValueList>
					<Value>1.2.208.176.43210.8.20.12</Value>
				</ValueList>
			</Slot>
			<Slot name="sourcePatientId">
				<ValueList>
					<Value>2708599967^^^&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="1.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" nodeRepresentation="" id="urn:uuid:8519e993-c2eb-441e-8d05-b474181718e7">
				<Slot name="authorInstitution">
					<ValueList>
						<Value>Fælles Stamkort udstedelse^^^^^&1.2.208.176.1.1&ISO^^^^1126211000016009</Value>
					</ValueList>
				</Slot>
			</Classification>
			<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="1.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" nodeRepresentation="001" id="urn:uuid:5f794583-a64d-484c-9642-a69363ffcb0b">
				<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="1.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" nodeRepresentation="urn:ad:dk:medcom:pdc-v2.0:full" id="urn:uuid:7b3aecee-6e15-4944-a511-8e5822b92536">
				<Slot name="codingScheme">
					<ValueList>
						<Value>1.2.208.184.100.10</Value>
					</ValueList>
				</Slot>
				<Name>
					<LocalizedString xml:lang="en-US" charset="UTF-8" value="DK PDC schema"/>
				</Name>
			</Classification>
			<Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="1.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" nodeRepresentation="554041000005106" id="urn:uuid:8a6b8eb1-6fd5-45a7-9e52-0ac8dbfa4ddd">
				<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:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="1.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" nodeRepresentation="408443003" id="urn:uuid:d6f3da90-aea3-4230-8137-538e34e6bb39">
				<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="almen medicin"/>
				</Name>
			</Classification>
			<Classification classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="1.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" nodeRepresentation="PDC" id="urn:uuid:ad6e5960-7481-41c0-9e73-a0859eb336f3">
				<Slot name="codingScheme">
					<ValueList>
						<Value>1.2.208.184.100.1</Value>
					</ValueList>
				</Slot>
				<Name>
					<LocalizedString xml:lang="en-US" charset="UTF-8" value="Stamkort"/>
				</Name>
			</Classification>
			<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="1.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" nodeRepresentation="N" id="urn:uuid:6c343c23-cb63-466d-a3f8-ba34be3128d5">
				<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="1.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="2708599967^^^&1.2.208.176.1.2&ISO" id="urn:uuid:9fe7321b-2796-4954-be43-c1f52f1eae1d">
				<Name>
					<LocalizedString value="XDSDocumentEntry.patientId"/>
				</Name>
			</ExternalIdentifier>
			<ExternalIdentifier registryObject="1.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="1.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" id="urn:uuid:f0572561-ae53-48c6-b223-f4559b5d3530">
				<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]/@registryObject

Hentning af Fælles Stamkort

For at hente en patients Fælles Stamkort, skal der laves en ITI-43 forespørgsel via SFSK

Snitflader og endpoints til SFSK er bekrevet i SFSK's guide til anvendere

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

<RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007">
	<DocumentRequest>
		<HomeCommunityId>1.2.208.176.8.1.12</HomeCommunityId>
		<RepositoryUniqueId>1.2.208.176.43210.8.20.12</RepositoryUniqueId>
		<DocumentUniqueId>1.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff</DocumentUniqueId>
	</DocumentRequest>
</RetrieveDocumentSetRequest>

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

Se bl.a MedCom's testeksempler under: http://svn.medcom.dk/svn/releases/Standarder/HL7/PDC/Eksempler/ 

Opdatering af Fælles Stamkort

Fælles Stamkort læses som beskrevet via SFSK, men de data der ikke findes autoritative registre for, opdateres via stamkortregister 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 dataudvekslingsformater 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 Sundhedsstyrelsens Elektroniske Brugerstyring (SEB), eller give rettigheden via den lokale identifikations- og rettighedsstyring. 
For Fælles stamkort er der fire forskellige måder for Sundhedspersoner uden sundhedsfaglig autorisation at få adgang til borgerens Fælles Stamkort. 

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.

Håndtering af frabedelse og fuldmagt

Frabedelse af deling af sundhedsdata 

Det er pr. 1/12-2024 ikke længere muligt for borgere at frabede sig deling af stamoplysninger jvf Bekendtgørelse om drift m.v. af den fælles digitale infrastruktur (retsinformation.dk) 

Fuldmagt

Borgerportaler kan give borgeres 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 dokumentdelingsinfrastrukturen, herunder SFSK ikke fuldmagter via 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 SFSK, kan ses i HSUID header dokumentationen. 

Ændringslog

Historiske ændringer