Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 at sppærre spærre for deling af stamdata, herunder Fælles Stamkort

...

Fagsystemerne bør implementere en adviseringskomponent, der håndterer at fagsystemet kan lytte på adviseringer fra Stamkortregisteret samt , 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

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 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 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 kræver logning med brugerkontekst ved al anvendelse af persondata, betyder det at anvender systemer skal registre registrere anvendelsen via MinLog-2 , når system-system kommunikation benyttes til at hente en borgers Fælles Stamkort. Ved system-system kommunikation, vil der kun være information 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 Anvendersystemets Minlog registrering skal indeholde følgende:

...

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

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: SERIALNUMBER=CVR:11111111-FID:22222222 + CN=www.test-eksempel.dk – NemLogin (funktionscertifikat), O=Test-eksempel A/S // CVR:00000000subject=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 systemkald til Fælles Stamkort: https://www.nspop.dk/display/public/web/SFSK+-+Guide+til+Anvendere

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

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

...

Fagsystemer og borgerportaler der skal benytte Fælles Stamkort, skal godkendes og certificeres af MedCom. Testprotokollerne for certificering til Fælles Stamkort, hvor version 1.0 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?

...

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.

...