1. 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 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 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
1 - Herunder CPR-register, Sygesikringsregister, Organdonorregister, Livs- og Behandlingstestamenteregister samt stamkortregister
2 - https://svn.medcom.dk/svn/releases/Standarder/HL7/PDC/
2. 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: Fælles Stamkort - Teknisk guide til anvendere
3. 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.
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.
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 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 og 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 indeholder model og grænsefladebeskrivelser for CDA udvekslingsformatet. Bemærk: denne opdateres til at understøtte PDC-DK version 3.0
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 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.
3.1. Migrering af data fra lokale fagsystemer til Fælles Stamkort
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
3.2. 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.
3.2.1. Lokal information tilknyttet data i Stamkortregisteret
Da hver data-entitet i Stamkortregisteret har tilknyttet en 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 der skal kontaktes når det er en indlæggelse, 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.
3.3. 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:
Fælles Stamkort udstiller data fra en række af forskellige registre, herunder:
Adviseringer blive udsendt fra Stamkortregisteret, når der er sket ændringer i
Der udsendes ligeledes adviseringer fra organdonorregisteret, livs- og behandlingstestamenteregisteret samt register for fravalg af genoplivningsforsøg v. hjertestop Ændringer af patientens data i de resterende registre, vil der ikke blive udsendt adviseringer for. |
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:
http://sundhedsdatastyrelsen.dk/PersonalDataCard/2020/11/01:DataCardUpdated |
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 (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.
<NotificationMessage> |
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
- Hans Hansen har for 2 dage siden oprettet sit telefonnummer via sundhed.dk, da dette ikke var indtastet i forvejen.
- 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. - 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:- Der laves automatisk en behandlingsrelationsopfølgning
- 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).
3.4. 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.
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 anvender systemer selv skal registrere brugeranvendelsen af Fælles Stamkort til MinLog når system-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. 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
Der er ligeledes understøttelse af systemkald for oprettelse/ændring af data i stamkortregisteret, se den speicaliserede grænseflade til dette i dokumentationen 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
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
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.)
4. 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.3 er gældende for modtagelse, kan findes på MedCom's hjemmeside under: Testprotokoller for modtagelse af Fælles Stamkort
Bemærk: Testprotokollerne er under opdaterering til Fælles Stamkort version 3
Yderligere information om om hvordan CDA dokumenter er opbygget kan findes hos IHE, under: IHE - Hvad er HL7 CDA?
4.1. Indhold i Fælles Stamkort
Indholdet i Fælles stamkort er defineret i CDA profilen: Personal Data Card (PDC-DK) [version 2.0] og [version 3.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.
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)3.
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"
Kode |
Beskrivelse |
Eksempel |
Kilde |
Patientens CPR-nummer er en del af den generiske CDA header recordTarget.patientRole.id |
Patientens CPR-nummer Patientens CPR-nummer er en del af den generiske CDA Header. |
<id assigningAuthorityName="CPR" extension="2512489996" root="1.2.208.176.1.2"/> |
CPR – register |
Patientens navn og adresse er en del af den generiske CDA header recordTarget.patientRole.addr |
Patientens navn og adresse Patientens navn og adresse er en del af den generiske CDA Header. |
<addr use="H"> Bemærk at har patienten navne eller adressebeskyttelse vises "BESKYTTET NAVN/ADRESSE" |
CPR - register |
Information om patientens pårørende component.structuredBody. templateId code |
Oplysninger om patientens pårørende, som patienten selv har angivet. Oplysningerne er: · Pårørendes Navn · Pårørendes Relation · Pårørendes Telefonnummer · Fritekstfelt, hvor der f.eks. kan angives "bor i Canada" Bemærk der kan kun angives flere observation med patientens pårørende Validering: Telefonnumre valideres i forhold til om de overholder formatet
reg. exp. for telefonnummer
tel:\+?[-0-9().]+ |
<templateId root="1.2.208.184.16.1.10.20.1.25" extension="2019-08-14"/> Bemærk: Der tilføjes ikke automatisk pårørende angivet i CPR-registeret (f.eks. værger og ægtefæller) - eneste undtagelse herfor er børn under forældremyndighed, eller personer som har forældremyndighed over et barn (se næste række) |
Indtastet information fra stamkortregisteret |
Patientens børn under forældremyndighed component.structuredBody. templateId code
|
Hvis patienten har forældremyndighed over et eller flere børn, kan børnene vises i Fælles Stamkort. Bemærk: Hvis patienten er biologisk forælder, men ikke har forældremyndigheden over barnet, vises barnet ikke i Fælles Stamkort. Bemærk: Hvis patienten er værge for et barn, men ikke har forældremyndigheden over det pågældende barn, vises barnet ikke i Fælles Stamkort. Bemærk: Der kan kun angives flere observationer med patientens børn under forældremyndighed. |
<templateId root="1.2.208.184.16.1.10.20.1.23" extension="2019-08-14"/> <!-- Value representing the name of the child of whom the patient has custody --> <!-- Value representing the relationship the patient has to the child of whom the patient have custody → |
CPR - register |
Patientens forældremyndighedshavere component.structuredBody. templateId code
|
Hvis patienten er et barn, kan forældremyndighedshavere vises i Fælles Stamkort. Bemærk: Hvis barnet har biologiske forældre som ikke har forældremyndigheden over barnet, vises de biologiske forældre ikke i Fælles Stamkort. Bemærk: Hvis barnet er myndling under en værge, men værgen ikke har forældremyndigheden over det pågældende barn, vises værgen ikke i Fælles Stamkort. Bemærk: Der kan kun angives flere observationer med barnets forældremyndighedshavere. |
<templateId root="1.2.208.184.16.1.10.20.1.23" extension="2019-08-14"/> <!-- Value representing the name of the Custodian of whom the patient is in custody --> <!-- Value representing the relationship the patient has to the custodian of whom the patient is in custody → |
CPR - register |
Patientens telefonnummer component.structuredBody. templateId code |
Patientens kontakt telefonnummer (3 telefonnumre kan angives (hjemme "H", mobil "MC", arbejde "WP"). Bemærk: Der kan kun angives en observation med patientens telefonnumre. |
<templateId root=”1.2.208.184.16.1.10.20.1.24” extension=”2019-08-14”/> <value xsi:type=”TEL” use=”WP” value=”tel:33112244”/> <value xsi:type=”TEL” use=”MC” value=”tel:66774433”/> |
Indtastet information fra stamkortregisteret |
Patientens midlertidige adresse component.structuredBody. templateId code |
Patientens midlertidige adresse inklusiv et tidsinterval for hvornår patienten befinder sig på den midlertidige adresse. Bemærk: Det er ikke nødvendigt at angive et sluttidspunkt (effectivetime.high) for den midlertidige adresse. Bemærk: Er slutdatoen overskredet på forespørgselstidspunktet, returneres den midlertidige adresse ikke fra Fælles Stamkort. Bemærk: Der kan kun angives en observation med patientens midlertidige adresse. |
<templateId root="1.2.208.184.16.1.10.20.1.21" extension="2019-08-14"/> |
Indtastet information fra stamkortregisteret |
Patientens egen læge recordtarget.patientRole. |
Kontaktoplysninger til patientens egen læge. Bemærk: Det er ikke alle patienter der har tilknyttet en læge - elementet er derfor optionelt. |
<providerOrganization> <id extension="123456" root="1.2.208.176.1.4" assigningAuthorityName="Yderregisteret"/ <name>Lægerne Hansen</name> <telecom use="WP" value="tel:+4512345678"/> <telecom value="mailto:test@testyder.dk"/> <addr use="H"> <streetAddressLine>Ydervej 42</streetAddressLine <postalCode>1234</postalCode> <city>Yderby</city> </addr> </providerOrganization> |
Yderregisteret |
Patientens tandlæge component.structuredBody. templateId code |
Hvis patienten har tilknyttet en tandlæge, kan Fælles Stamkort indeholde kontaktoplysninger til tandlægen. Patienten skal selv angive tandlægen, Fælles Stamkort vil efterfølgende hente kontaktoplysninger på patientens tandlæge fra Yderregisteret. |
<templateId root="1.2.208.184.16.1.10.20.1.22" extension="2019-08-14"/> |
Yder id på tandlægen er indtastet i stamkortregisteret, Ved opslag, hentes seneste information om tandlægen fra yderregisteret. Der returneres ikke personnavne på tandlæger, kun kliniknavne. Der kan dog være kliniknavne som indeholder tandlægens personnavn. |
Sygesikringsgruppe component.structuredBody. templateId code |
Patientens sygesikringsgruppe. |
<templateId root="1.2.208.184.16.1.10.20.1.27" extension="2019-08-14"/> |
Sygesikringsregisteret |
Patientens foretrukne kommunikationssprog. component.structuredBody. templateId code |
Patienten kan registrere hvilket sprog de foretrækker at kommunikere på. Er feltet ikke forudfyldt, kan det antages at sproget er ”Dansk”. Bemærk: Der kan kun registreres et sprog pr. patient. |
<templateId root="1.2.208.184.16.1.10.20.1.20" extension="2019-08-14"/> |
Indtastet information fra stamkortregisteret |
Behandlingstestamente component.structuredBody. templateId code |
Information om patienten har registreret et Behandlingstestamente kan vises i Fælles Stamkort. Fælles Stamkort må IKKE vise indholdet i registreringen, kun OM der lavet en registrering. Bemærk: En patient kan have registreret enten et Behandlingstestamente eller et Livstestamente, ikke begge testamenter på samme tid. |
<templateId root="1.2.208.184.16.1.10.20.1.29" extension="2019-08-14"/> |
Behandlingstestamenteregister |
Livstestamente component.structuredBody. templateId code |
Information om patienten har registreret et Livstestamente kan vises i Fælles Stamkort. Fælles Stamkort må IKKE vise indholdet i registreringen, kun OM der lavet en registrering. Bemærk: En patient kan have registreret enten et Behandlingstestamente eller et Livstestamente, ikke begge testamenter på samme tid. |
<templateId root="1.2.208.184.16.1.10.20.1.30" extension="2019-08-14"/> |
Livstestamenteregister |
Organdonorregistrering component.structuredBody. templateId code |
Information om patienten har en Organdonorregistrering kan vises i Fælles Stamkort. Fælles Stamkort må IKKE vise indholdet i registreringen, kun OM der lavet en registrering. |
<templateId root="1.2.208.184.16.1.10.20.1.28" extension="2019-08-14"/> <id extension="bf5b7087-b8dd-41f3-91c8-d2e0a8955c3a" root="1.2.208.184"/> <code code="OrganDonorRegistration" codeSystem="1.2.208.184.100.1" codeSystemName="MedCom Message Codes" displayName="Registreret organdonor"/> <value xsi:type="II" root="1.2.208.176.1.10" extension="true" assigningAuthorityName="Dansk Center For Organdonation"/> |
Organdonorregisteret |
Fravalg af genoplivningsforsøg v. hjertestop component.structuredBody. templateId code |
Bemærk: Gælder udelukkende for Fælles Stamkort version 3 Bemærk: At visse typer fagsystemer kan begrænse visning til udelukkende fravalgsoplysningen, jvf. Fælles Stamkort, forretningsregel #17 Værdien (value) kan antage følgende værdier: “true” = Borgeren har et aktivt fravalg til genoplivningsforsøg v. hjertestop registreret “false” = Borgeren har ikke registreret, eller har ikke et aktivt fravalg til genoplivningsforsøg v. hjertestop registreret
|
<templateId root="1.2.208.184.16.1.10.20.1.31" extension="2023-07-01"/> <id extension="d90df5cb-602c-44d5-8cc6-9fb7ed9b8df9" root="1.2.208.184"/> <code code="NoResuscitationRegistration" codeSystem="1.2.208.184.100.1" codeSystemName="MedCom Message Codes" displayName="Registreret fravalg af genoplivningsforsøg v. hjertestop"/> <value xsi:type="II" root="1.2.208.176.1.11" extension="true" assigningAuthorityName="Sundhedsdatastyrelsen"/> |
Registrer til fravalg af genoplivningsforsøg v. hjertestop |
3 http://svn.medcom.dk/svn/releases/Standarder/HL7/CDA-Header/
4.2. Tekniske forudsætninger
Se Administrative forudsætninger for 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
4.3. 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, eller via systemkaldskomponenten SFSK. Det er samme forespørgsel bare foretaget på forskellige endpoints.
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.
For forløbsplaner, er der desuden følgende forretningsmæssige XDS-metdata, som skal anvendes i søgninger:
- Typecode: PDC
Når der forespørges på Fælles Stamkort, laves et opslag til underliggende registre, derfor forespørged 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.
- FormatCode:
- urn:ad:dk:medcom:pdc-v2.0:full (Fælles stamkort version 2.0)
- 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
Svaret indeholder referencen til Fælles Stamkort dokumentet, der skal benyttes efterfølgende til at udtrække selve Fælles Stamkort dokumenter
Der er tre værdier der skal benyttes:
- HomeCommunityId - der beskriver det domæne dokumentet befinder sig i.
Værdien hentes ud fra ...ExtrinsicObject/@home
- RepositoryUniqueId - der bekriver den kilde under domænet der opbevarer dokumentet
Værdien hentes ud fra ...ExtrinsicObject/Slot[@name=’repositoryUniqueId’]/Value List/Value
- 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
4.4. 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
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/
4.5. 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
5. 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.
For Fælles stamkort er der 4 forskellige måder for Sundhedspersoner uden sundhedsfaglig autorisation at få adgang til borgerens Fælles Stamkort.
Integrationsmetode | Beskrivelse | Er national rolle nødvendig? | |
---|---|---|---|
1 | Fagsystem opbevarer og vedligeholder lokal registerkopi af Fælles Stamkort |
Det lokale fagsystem opbevarer og vedligeholder en lokal registerkopi af data fra Fælles Stamkort (via SFSK), og har til ansvar at holde registerkopien synkroniseret når der notificeres om ændringer i underliggende registre. I dette tilfælde er det ikke nødvendigt at tildele nationale roller til ikke autoriserede sundhedsfaglige, da det er det lokale anvendersystem som står for tildeling af rettigheder. Det lokale anvendersystem har til ansvar at skrive til borgerens Minlog når data tilgås (både fra autoriserede og ikke autoriserede sundhedsfaglige) |
Nej |
2 | Fagsystem laver synkront system til system-baseret opslag på Fælles Stamkort | Opslag på Fælles Stamkort via SFSK når data skal anvendes, men med anvendelse af system-certifikat adgang. Ligeledes er det i dette tilfælde ikke nødvendigt at tildele nationale roller til ikke autoriserede sundhedsfaglige, da det er det lokale anvendersystem som står for tildeling af rettigheder. Det lokale anvendersystem har også her til ansvar at skrive til borgerens Minlog når data tilgås (både fra autoriserede og ikke autoriserede sundhedsfaglige). |
Nej |
3 | Fagsystem laver synkront bruger-baseret opslag på Fælles Stamkort | Opslag på Fælles Stamkort via SFSK når data skal anvendes, men med anvendelse af bruger-certifikat adgang. Her er det nødvendigt for ikke autoriserede sundhedsfaglige at have tildelt en national rolle, da SFSK skal sikre at brugeren har de nødvendige rettigheder inden adgang til data gives. SFSK står ligeledes for at logge opslaget til borgerens Minlog. |
Ja |
4 | Opslag på Fælles Stamkort for ikke autoriserede sundhedsfaglige via Sundhedsjournalen | Opslag for ikke autoriserede sundhedsfaglige via knapløsning til Sundhedsjournalen, eller via direkte login på Sundhedsjournalen. Sundhedsjournalen anvender integrationsmetoden beskrevet i punkt. 3, derfor skal ikke autoriserede sundhedsfaglige have tilknyttet en national rolle, hvis de skal have adgang til Fælles Stamkort via Sundhedsjournalen. | Ja |
Følgende rollebeskrivelser anvendes i forbindelse med Et samlet patientoverblik.
Rollenavn |
Rollebeskrivelse |
Notation som indsættes i SOSI IdKort ved udstedelse |
nspSundAssistR1 |
Giver ret til at læse Fælles Stamkort (FSK) Se detaljeret beskrivelse af alle nationale roller her: Beskrivelse af de nationale roller i produktion - NSP services - Global Site (nspop.dk) samt overordnet dokumentation for SEB her: SEB - Sundhedsvæsenets Elektroniske Brugerstyring - Sundhedsdatastyrelsen Services (nsi.dk) |
urn:dk:healthcare:national-federation-role:code:41001:value:SundAssistR1 |
nspSundAssistR2 |
Giver ret til at læse Fælles Stamkort (FSK) Giver også adgang til at læse andre dokumenter, der deles via dokumentdelingsinfrastrukturen jvf. Sundhedslovens §42a stk. 4 Se detaljeret beskrivelse af alle nationale roller her: Beskrivelse af de nationale roller i produktion - NSP services - Global Site (nspop.dk) samt overordnet dokumentation for SEB her: SEB - Sundhedsvæsenets Elektroniske Brugerstyring - Sundhedsdatastyrelsen Services (nsi.dk) |
urn:dk:healthcare:national-federation-role:code:41002:value:SundAssistR2
|
En sundhedsperson kan ikke have tilknyttet flere roller på samme tid - dette skal administreres via den lokale identifikations- og rettighedsstyring.
6. Håndtering af spærring og fuldmagt
Bemærk: pr. 1/12-2024 er det ikke længere muligt at borgere kan spærre for deling af Fælles Stamkort
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øttersynkroniseringsservicen til Fælles Stamkort 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 synkroniseringsservicen til Fælles Stamkort, kan ses i HSUID header dokumentation.
7. Ændringslog
Version | Dato | Beskrivelse | Ændret af |
---|---|---|---|
2.1.0 | 2024-12-03 | Pr. 1/12-2024 kan borgere ikke længere spærre for deling af Fælles Stamkort, dokumentation omkring spærring af Fælles Stamkort er derfor fjernet. | SDS |
2.0.3 | 2024-10-22 | Beskrevet præcisering af når "fravalgsregister" ikke er tilgængeligt | SDS |
2.0.2 | 2024-10-21 | Præciseret adgang via nationale roller for forskellige integrationsmetoder, herunder når system til system integration anvendes. | SDS |
2.0.1 | 2024-03-12 | Tilpasset efter offentliggørelse af BEK nr 193 af 27/02/2024, hvor spærring ikke længere eer muligt for deling af stamoplysninger | SDS |
2.0 | 2023-12-11 | Tilpasset Version 3.0 af Fælles Stamkort, således både version 2.0 og 3.0 er beskrevet sideløbende | SDS |
Historiske ændringer
0.8 | 2019-12-06 | Udkast til Teknisk implementeringsguide til Fælles Stamkort | SDS |
1.0 | 2020-01-06 | Offentlig efter afsluttet kommenteringsrunde | SDS |
1.0.1 | 2020-01-21 | Tilrettet link til standard for Fælles Stamkort | SDS |
1.1 | 2020-03-27 |
Tilrettet efter opdatering af testprotokol for CDA profilen Desuden mindre tekstuelle rettelser |
SDS |
1.2 | 2020-05-28 | Indført afsnit som præciserer hvorledes data skal synkroniseres mellem lokale fagsystemer og Fælles Stamkort | SDS |
1.2.1 | 2020-06-26 | Præcisering omkring hvilke datafelter fra Fælles Stamkort, der skal vises for slutbrugerne. | SDS |
1.2.2 | 2020-10-21 | Opdateret med specifik reference til testprotokol for modtagelse af Fælles Stamkort | SDS |
1.3 | 2021-01-26 | Opdateret med migreringsgrænseflade | SDS |
1.3.1 | 2021-02-11 | Tilrettet AdhocQueryRequest eksemplet med on-demand documenttype angivelse | SDS |
1.3.2 | 2021-02-23 | Tilrettet eksempel på ITI-18 forespørgsel, da det benyttede forældet codesystem navn | SDS |
1.4 | 2021-03-04 | Opdateret med vejledning til adviseringer fra Stamkortregisteret | SDS |
1.5 | 2021-03-12 | Tilføjet beskrivelse omkring mulighed for system-system kald ved læsning af Fælles Stamkort | SDS |
1.5.1 | 2021-09-14 | Opdateret med endpoint beskrivelse for system-system kald | SDS |
1.5.2 | 2021-11-18 | Opdateret med endpoint beskrivelse for system-system kald til NSP-TEST-2, samt whitelisting og Minlog information | SDS |
1.5.3 | 2022-01-25 | Opdateret med endpoint beskrivelse for adviseringer, samt præciseringer af notifikationsformatet | SDS |
1.5.4 | 2022-04-20 | Opdateret med reference til ny Errata for PDC-DK CDA standarden fra MedCom | SDS |
1.5.5 | 2022-10-10 | Opdateret med reference til ny Errata for PDC-DK CDA standarden fra MedCom, Errata præciserer tilknytning af relationer i forbindelse med forældremyndighed. | SDS |
1.5.6 | 2023-03-01 | Opdateret link til MedCom Header v. 1.4. | SDS |
1.5.7 | 2023-03-20 | Rettet rettighed for nspSundAssistR2 - rollen giver kun adgang til Aftaleoversigten og Fælles Stamkort |
SDS |
1.5.8 | 2023-04-26 | Fjernet beskrivelse af manuel indtastning af tandlæge |
SDS |
1.6 | 2023-09-21 | Arkiveret beskrivelse af grænseflade til migrering af data fra lokale fagsystemer |
SDS |
1.6.1 | 2024-03-12 | Rettet rettighed for nspSundAssistR2 - rollen giver adgang til alle dokumenter der deles via dokumentdelingsinfrastrukturen |
SDS |