...

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] samt tilpasningen mod Fravalg af Genoplivning v. Hjertestop (PDC-DK) [version 3.0]2, der anvendes til at udstille patientens Fælles Stamkort.

Bemærk: i en overgangsperiode vil version 2.0 og version 3.0 af Fælles Stamkort være tilgængelige på infrastrukturen samtidig, dette er indtil Fravalg af Genoplivningsforsøg ved hjertestop er implementeret forventelige forventeligt ultimo 2024

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

...

For detaljeret information ang. MinSpærring se Min Spærring på NSPOP
Bemærk: For Fælles Stamkort 3.0 er det ikke længere muligt for borgeren at spærre for deling af stamdatastamoplysninger, herunder Fælles Stamkort

...

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

Image RemovedImage Added

Fælles Stamkort komponenten indeholder model og grænsefladebeskrivelser for CDA udvekslingsformatet. Bemærk: denne opdateres til at understøtte PDC-DK version 3.0 også
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 dokumentdelingsservicen 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 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.

...

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: 

...

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) (Bemærk: For Fælles Stamkort version 3 kan der ikke lngere længere spærres for deling af Fælles Stamkort)
   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).

...

Borgere har dog mulighed for at spærre for deling af sit Fælles Stamkort via MinSpærring (Bemærk: Dette bortfalder fra Fælles Stamkort version 3). 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 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)) kræver at der laves logning med brugerkontekst ved al anvendelse af persondata, .
Det betyder det at anvender systemer selv skal registrere anvendelsen via MinLog-2 brugeranvendelsen af Fælles Stamkort til MinLog 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:

...

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 borgeres borgers 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 

...

Endpoint NSP TEST-1 og TEST-2: Se anvenderguiden for systemkald synkroniseringsservice til Fælles Stamkort: https://www.nspop.dk/display/public/web/SFSK+-+Guide+til+Anvendere

Image Removed

Bemærk: Da det jvf bekendtgørelsen ikke skal være muligt at spærre for deling af stamoplysninger pr. 1/12-24, vil Fælles Stamkort fra dette tidspunkt udelukkende blive udstillet via Synkroniseringsservice til Fælles Stamkort

Image Added

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

...

Fælles stamkort udstilles i en overgang i flere formater (version 2.0 og version 3.0) - angives formatkoden ikke, returneres begge versioner.

• FormatCode:
  • Fælles stamkort version 2.0: urn:ad:dk:medcom:pdc-v2.0:fullfull  (Fælles stamkort version 32.0: )
  • urn:ad:dk:medcom:pdc-v3.0:fullfull  (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>

...

		<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:ihenames:ititc:2007ebxml-regrep:ResponseStatusType:PartialSuccessSuccess">
			<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.43210.8.1.12">
		20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" home="1.2.208.176.8.1.12">
			<Slot name="creationTime">
						<ValueList>
							<Value>20191129120611<<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.1020.12</Value>
						</ValueList>
					</Slot>
					<Slot name="sourcePatientId">
						<ValueList>
							<Value>2512489996^^^<Value>2708599967^^^&1.2.208.176.1.2&ISO</Value>
						</ValueList>
					</Slot>
					<Name>
						<LocalizedString xml:lang="en-US" charset="UTF-8" value="FællesFælles stamkort"/>
					</Name>
					<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b521.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" nodeRepresentation="" id="urn:uuid:2dc694678519e993-1a1ac2eb-43a5441e-a3008d05-7ff085dc4ad7b474181718e7">
						<Slot name="authorInstitution">
							<ValueList>
								<Value>Sundhedsdatastyrelsen^^^^^<Value>Fælles Stamkort udstedelse^^^^^&1.2.208.176.1.1&ISO^^^^634491000016008<ISO^^^^1126211000016009</Value>
							</ValueList>
						</Slot>
					</Classification>
					<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b521.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" nodeRepresentation="001" id="urn:uuid:76545ece5f794583-d1f8a64d-46fe484c-84ad9642-69b84caba60ca69363ffcb0b">
						<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">
		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>urn:ad:dk:medcom:fsk:full<<Value>1.2.208.184.100.10</Value>
							</ValueList>
						</Slot>
						<Name>
							<LocalizedString xml:lang="en-US" charset="UTF-8" value="DK FSKPDC Schemaschema"/>
						</Name>
					</Classification>
					<Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b521.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" nodeRepresentation="554041000005106" id="urn:uuid:0cde4f598a6b8eb1-9e496fd5-4dfb45a7-925a9e52-9325564dc47e0ac8dbfa4ddd">
						<Slot name="codingScheme">
							<ValueList>
								<Value>2.16.840.1.113883.6.96</Value>
							</ValueList>
						</Slot>
						<Name>
							<LocalizedString<LocalizedString xml:lang="en-US" charset="UTF-8" value="sundhedsforvaltning"/>
						</Name>
					</Classification>
					<Classification classificationScheme="urn:uuid:f0306f51cccf5598-975f8b07-434e4b77-a61ca05e-c59651d33983ae952c785ead" classifiedObject="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b521.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" nodeRepresentation="52460-3408443003" id="urn:uuid:f6aec0bdd6f3da90-8ee0aea3-4ad34230-932f8137-cb4c6314fa84538e34e6bb39">
						<Slot name="codingScheme">
							<ValueList>
								<Value>2.16.840.1.113883.6.1<96</Value>
							</ValueList>
						</Slot>
						<Name>
							<LocalizedString xml:lang="en-US" charset="UTF-8" value="Patientalmen Informationmedicin"/>
						</Name>
					</Classification>
					<Classification classificationScheme="urn:uuid:f4f85eacf0306f51-e6cb975f-4883434e-b524a61c-f2705394840fc59651d33983" classifiedObject="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b521.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" nodeRepresentation="NPDC" id="urn:uuid:84b2075dad6e5960-0ded7481-4bec41c0-b50a9e73-c67d9cbb83d2a0859eb336f3">
						<Slot name="codingScheme">
							<ValueList>
								<Value>2<Value>1.162.840208.1184.113883100.5.25<1</Value>
							</ValueList>
						</Slot>
						<Name>
							<LocalizedString xml:lang="en-US" charset="UTF-8" value="normalStamkort"/>
						</Name>
					</Classification>
					<ExternalIdentifier registryObject="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b52" identificationScheme<Classification classificationScheme="urn:uuid:58a6f841f4f85eac-87b3e6cb-4a3e4883-92fdb524-a8ffeff98427f2705394840f" valueclassifiedObject="0202999573^^^&1.2.208.176.43210.8.1.2&ISO20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" nodeRepresentation="N" id="urn:uuid:f8d811f56c343c23-1d9acb63-4774466d-a49ca3f8-0c90c01ce0d8ba34be3128d5">
						<Name>
		<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="XDSDocumentEntry.patientIdnormal"/>
						</Name>
					</ExternalIdentifier>Classification>
					<ExternalIdentifier registryObject="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b521.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" identificationScheme="urn:uuid:2e82c1f658a6f841-a08587b3-4c724a3e-9da392fd-8640a32e42aba8ffeff98427" value="urn:sds:fsk:stamkort:4dfd86a1-ccdd-4463-8d06-2e6d2f4f2b522708599967^^^&1.2.208.176.1.2&ISO" id="urn:uuid:da6376b79fe7321b-0cb92796-4bfd4954-a80ebe43-241cff0be6dec1f52f1eae1d">
						<Name>
							<LocalizedString value="XDSDocumentEntry.uniqueIdpatientId"/>
						</Name>
					</ExternalIdentifier>
				</ExtrinsicObject>
			</RegistryObjectList>
		</ns3:AdhocQueryResponse>

Der er tre værdier der skal benyttes:

...

<ExternalIdentifier registryObject="1.2.208.176.43210.8.20.12^9a6d387b-db0f-4075-aeb3-63a5ad45f3ff" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab

...

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.

...

...

" 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

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

<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

...

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

 BemærkBemæ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

Bemærk: Spærring for deling af Fælles Stamkort udgår i forbindelse med Fælles Stamkort version 3.0

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. 

...

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.

Image RemovedImage Added

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

...

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

...

Historiske ændringer