1. Indhold

2. Indledning

Dette dokument skal medvirke til at sikre, at logning i MinLog 2 sker korrekt og efter ens principper. Borgeren skal opleve, at data i MinLog 2 giver et forståeligt og retvisende billede af, hvem der har tilgået borgerens data. Den sundhedsfaglige organisation skal opleve, at MinLog 2 giver et overblik over opslag, denne er ansvarlig for.

Det er derfor væsentligt, at data har samme kvalitet, uanset om der logges fra f.eks. en central national service, eller om der logges fra f.eks. regionernes EPJ-systemer.

2.1.1. Referencer og termer

Referencer findes sidst i dette dokument, 6 - Termer og referencer, sammen med en oversigt over anvendte termer og forkortelser. For at sikre en korrekt forståelse af dette dokument er der nogle få væsentlige termer, som er nødvendige at få defineret forud for at teksten læses jf. herunder.

MinLog 2 anvendes dels om systemet i sin helhed, se afsnit 2 - Baggrunden for MinLog 2. Desuden anvendes begrebet omkring servicen til borgeropslag, af historiske årsager, idet borgeropslaget oprindeligt var systemets første service. Oftest vil det være tydeligt ud fra sammenhængen, om der menes systemet eller servicen, og hvor det ikke er tilfældet, præciseres servicen som borgeropslag.

Medhjælpsloggen er en service til opslag på logdata for medhjælpere. Dette uddybes yderligere i afsnittet Medhjælpsloggen.

Sundhedspersoner som er f.eks. læger, sygeplejersker, apoteks­ansatte farmaceuter og farmakonomer, samt medhjælp som f.eks. klinikassistenter og sekretærer m.v.

Visse sundhedspersoner har en autorisation, og er i så fald autoriserede sundhedspersoner.

Kildesystemet skal her forstås som det system, der genererer opslaget, som i sidste ende logges i MinLog 2.

Der kan forekomme flere kildesystemer, hvilket er beskrevet under Kilde- og destination-systemer. Kildesystemet skal forstås som primær kilde til opslaget, og kun indirekte kilde til logningen.

For kildesystemer som f.eks. EPJ og EOJ der kalder services på NSP synkront gennem dokumentdelingsinfrastrukturen, skal kildesystemerne ikke selv lave logregistrering ift. MinLog 2, idet dokumentdelingsservicen sørger for dette.

System-til-system-kald som ikke er initieret af en bruger, og som i første omgang ikke medfører at der vises data til en bruger, men som har til formål at overføre data til et andet system, skal ikke logges i MinLog 2. Lovgivning eller den dataansvarlige kan stille krav om at der systemet der er overført data til logger, når der sker opslag der.

Destinationssystemet skal her forstås som det system, der slås op på, som indeholder de ønskede sundheds­data, og som skal logge til MinLog 2. Eksempelvis FMK, Behandlingstestamente, Stamkort, Aftaler mv.

Den detaljerede tekniske anvendelse af MinLog 2 findes i løsningsbeskrivelsen, se kapitel 6 Termer og referencer.

2.1.2. Krav og vejledning

Anvendelse af MinLog 2 forudsætter ikke en certificering. Dokumentet her indeholder alligevel et antal krav til anvendelse af registrerings­servicen og opslagsservices, markeret med hhv. [R.1] og [O.1] osv. Krav som skal overholdes for at sikre en korrekt anvendelse af MinLog 2, ikke mindst hvad angår registreringsservicen, for at sikre en god og ensartet datakvalitet.

3. Baggrund for MinLog 2

Det er væsentligt at bemærke, at registrering i MinLog 2 ikke erstatter logning i kilde­system eller destinationssystem. MinLog 2 er ikke en auditlog. MinLog 2 gør det muligt at udstille logdata samlet til borgere eller sundhedspersoner. Kildesystemer og destinationssystemer er fortsat forpligtigede til at håndtere egen logning efter gældende regler for de specifikke systemer.

3.1. Juridiske krav til logning

En række af sundhedslovens regler indeholder juridiske krav til logning af it-systemer, herunder omfang samt udstilling af loggen. De relevante bestemmelser er på nuværende tidspunkt sundhedslovens § 42c, § 157, stk. 14, nr. 3, og § 157a, stk. 10, nr. 4 samt § 193b, stk. 3, nr. 4.

Bestemmelserne er alle sammen bemyndigelsesbestemmelse, som betyder, at de kræver at Indenrigs- og sundhedsministeren udmønter specifikke bekendtgørelser, før reglerne finder anvendelse.

Indenrigs- og Sundhedsministeren har udmøntet alle bestemmelser, hvorfor der i dag findes regler i følgende bekendtgørelser:

• Bekendtgørelse nr. 191 af 27/02/2024 om adgang til og registrering m.v. af lægemiddel- og vaccinationsoplysninger (herefter FMK/DDV-bekendtgørelsen)

• Bekendtgørelse nr. 193 af 27/02/2024 om drift m.v. af den fælles digitale infrastruktur (herefter NSP-bekendtgørelsen)

 

• Bekendtgørelse nr. 192 af 27/02/2024 om pligt til at registrere logoplysninger og indsigt i logoplysninger

3.2. Principper og ansvar for logning

 Hvem er ansvarlig for registrering til MinLog 2, er det serviceanvenderen eller serviceudbyder?

 Der er en række brugere, der kan fortage et opslag eller en oprettelse/opdatering, f.eks:

• En borger
• En sundhedsperson
• Et system

Når en borger eller fagsystemer uden brugerkontekst via (trust), foretager opslaget via (sundhed.dk), skal medsendes funktion/virksomheds (FOCES) certifikat på Niveau-3. I dette tilfælde, ligger ansvaret for registrering til MinLog 2 altid hos serviceanvenderne selv. Kald med Niveau-3 id-kort fra fagsystemer registreres ikke i MinLog 2 af NSP.

Når serviceanvender er sundhedspersoner, som fortager opslag på borgernes data på en NSP-service, skal der kaldes med et medarbejdercertifikat (MOCES) på niveau-4. I dette tilfælde, er det NSP, der som serviceudbyder har ansvar for at sikre MinLog 2-registrering på vegne af serviceanvenderene.

Ifølge bekendtgørelse om drift m.v. af den fælles digitale infrastruktur § 6, er Sundhedsdatastyrelsen forpligtet til at foretage maskinel registrering (logning) af alle anvendelser af personoplysninger i den fælles digitale infrastruktur. Logningsoplysninger skal indeholde oplysning om

1) hvem der har foretaget opslag med angivelse af fornavn, efternavn samt autorisationsnummer eller titel,

2) behandlingssted, hvorfra opslaget er foretaget, og

3) tidspunkt for opslaget

Samtidig skal der være en klar og selvforklarende tekst, der beskriver, hvilke slags oplysninger der er blevet registreret i MinLog 2.

Dette står også i NSP-bekendtgørelsens § 6, stk. 3, hvoraf det tydeligt fremgår, at Sundhedsdatastyrelsen er forpligtet til at sikre, at patienten får adgang til en overskuelig og letforståelig oversigt over de logningsoplysninger, der er nævnt i § 6, stk. 1, nr. 1-3, og som vedrører opslag i patientens oplysninger.

Uanset hvad der fremgår af lovgrundlaget, bør teksten være ensartet og harmoniseret med lovgivningen.

F.eks.

• når det er en sundhedsperson der slår op, skal der stå enten: ”Opslag/Hentning af oplysninger”, ”Opslag/Hentning af oplysninger, hvor samtykker tilsidesættes”, herunder hvilket system, der er tilgået.
• når det er borgeren selv der har slået op i sin log, skal der stå: ”Egen opslag på MinLog”
• når det er en forælder der slår op, kan der stå: ”Opslag/Hentning af oplysninger fra forældremyndighedsindehaver”
• når det er en fuldmagthaver der slår op, kan der stå: ”Opslag/Hentning af oplysninger fra fuldmagtshaver”
• hvis det er et system der laver opslag på borgerens data, skal oplysningen ikke fremgå, da der er tale om systemteknisk opslag, for at sikre at borgeren modtager den service, som pågældende ønsker - se afsnit 4.4 systemlogning. Et efterfølgende opslag i de data, der er hentet via det systemtekniske opslag, skal imidlertid logges af serviceanvenderen, jf. ovenfor.

3.2.1. Logdata fra de elektroniske patientjournaler

Logning fra EPJ-systemerne sker med baggrund i sundhedslovens § 42c. og bekendtgørelse nr. 192 af 27/02/2024 om pligt til at registrere logoplysninger og indsigt i logoplysninger, med mulighed for sløring af sundhedspersonernes navn.

3.2.2. Medhjælpsloggen

Anvendelse af medhjælp fremgår af bekendtgørelse nr. 1219 af 11. december 2009 om autoriserede sundhedspersoners benyttelse af medhjælp samt dertilhørende vejledning nr. 115 af 11. december 2009 om autoriserede sundhedspersoners benyttelse af medhjælp.

En autoriseret sundhedsperson kan delegere opgaver til medhjælpere, uanset opgave og medhjælpens uddannelse. Der er ikke krav om, at medhjælpen selv er en autoriseret sundhedsperson. Anvender en autoriseret sundhedsperson en medhjælp, er den autoriserede sundhedsperson ansvarlig for at instruere og føre tilsyn med medhjælpen. En autoriseret sundhedsperson er ansvarlig som om denne selv udfører behandlingen.

Medhjælpens opslag og opdateringer kan ske via eget system. Opslag og opdateringer i de nationale services, hvor der mellem kildesystem og destinations­system er etableret en trust-løsning, kan umiddelbart foretages af medhjælpen.

Handlinger, der er foretaget af medhjælperen, skal logges med en tydelig angivelse af brugen af medhjælp og den sundhedsperson, som handlingen er foretaget på vegne af. MinLog 2 udstiller denne information som ”medhjælpsloggen” via en webservice, således at opgaven med at holde tilsyn kan lettes. Medhjælpsloggen gøres tilgængelig via FMK-online. MinLog 2 udstiller desuden en service til opslag i medhjælpsloggen, der kan anvendes af EPJ-systemer, lægepraksis­systemer m.v., således at den autoriserede sundhedsperson kan foretage tilsyn via eget system.

3.2.3. Borgerens adgang til logoplysninger

I alle nedenstående bekendtgørelser er det fastlagt, at en borger skal have adgang til logoplysninger.

• I NSP-bekendtgørelsens § 6, stk. 3 fremgår det, at Sundhedsdatastyrelsen er forpligtet til at sikre, at patienten får adgang til en overskuelig og letforståelig oversigt over de logningsoplysninger, der er nævnt i § 6, stk. 1, nr. 1-3, og som vedrører opslag i patientens oplysninger.
• I FMK/DDV bekendtgørelsens 13, stk. 1 fremgår det, at Statens Serum Institut eller Sundhedsdatastyrelsen stiller en log til rådighed for borgere og for autoriserede sundhedspersoner, der jf. § 6, stk. 2 og § 7, stk. 2, kan delegere adgang til lægemiddel-, cannabisslutprodukt- og vaccinationsoplysninger.
• I bekendtgørelse om pligt til at registrere logoplysninger og indsigt i logoplysninger § 2 fremgår det, at regionsrådet sikrer, at en patient, der er fyldt 15 år, i en periode på to år fra opslagstidspunktet får adgang til en overskuelig og letforståelig oversigt over oplysninger om fornavn, efternavn og titel på den, der har foretaget opslag i patientens elektroniske patientjournal, behandlingssted, hvorfra opslaget er foretaget, og tidspunkt for opslaget, jf. dog § 3.

Loggen stilles derfor til rådighed for borgeren i alle tilfælde, og dette sker som udgangspunkt via sundhed.dk.

3.2.4. Hjemmel til sløring

En sundhedspersons navn og efternavn skal sløres i MinLog2, hvis en organisation har oprettet sløring i forhold til borgeren eller når borgeren har været i kontakt med en afdeling hvor organisationen har oprettet en sløring. Der er hjemmel til at sløre for sundhedspersoners navn og efternavn, når der afleveres data fra kildesystemer til MinLog 2.

Der kan efter d. 12. marts 2024 oprettes sløringer rettet imod en identificeret borger, der har opført sig truende eller på anden måde ubehageligt/upassende. Fra senere i 2024 kan der tillige oprettes sløringer, for alle registreringer for en given afdeling. Disse gælder så for alle borgere som har haft kontakt med afdelingen.

Fra og med d. 12. marts 2024 vil MinLog 2 sløre for logopslag inden for det CVR-nummer, som et behandlingssted måtte have registreret en sløring for (det være sig borgerrettet eller afdelingsrettet). Der er allerede hjemmel for de systemer, som har afleveret data til MinLog 2 inden d. 12. marts 2024, men det er vigtigt i forhold til eventuelle nye kildesystemer, der begynder at aflevere MinLog 2-registreringer til NSP efter denne dato, at systemejer sikrer, at der er hjemmel til sløring.

Bemærk ligeledes, at sløringer er bundet til ledelsesret og pligt, og man kan derfor ikke lave sløringer på tværs af CVR-numre. Hvis en borger har opført sig truende flere steder, skal de pågældende steder hver især oprette en sløring for deres CVR-nummer.

Praksis samt opmærksomhedspunkter vedr. registreringer er beskrevet i afsnittet Logninger som ønskes sløret for borger i MinLog 2.

Læs yderligere om Identitetssløring og afdelingssløring her: Identitetssløring.

3.3. Tryghed og troværdighed

3.3.1. Borgerens adgang til logdata

Sundhedsvæsenet indsamler og opbevarer en mængde informationer omkring borgeren. Informationer som i mange tilfælde er fortrolige eller følsomme. For at sundhedspersoner kan udføre deres opgaver og derved sikre bedst muligt behandling af hensyn til patientsikkerheden, gives der som udgangspunkt sundhedspersoner en forholdsvis let adgang til data om borgeren. En forudsætning for denne model er jvf. lovgrundlag, at borgeren kan have tillid til at adgang til data kun bruges i borgerens interesse.

Logning af sundhedspersoners adgang, og borgerens mulighed for at se denne logning, er en afgørende faktor i, at borgerens tillid bevares. Det er væsentligt, at borgerens adgang til at se logdata er enkel, og at logdata præsenteres på letforståelig vis, uden unødige tekniske eller kliniske termer, men samtidigt også at data ikke forsimples i sådan en grad, at logdata reelt er uanvendelige.

4. Registreringsservice

I dette kapitel beskrives anvendelse af MinLog 2 registreringsservicen. Den præcise tekniske definition af registrerings­servicen og opslagsservices findes i snitflade­beskrivelsen samt WSDL og XML-skema­- definitionerne. Se 6 - Termer og referencer.

4.1. Ikke-tekniske krav til anvendelsen af registrerings­servicen

Systemer der ønsker at aflevere logdata til MinLog 2 skal anvende registreringsservicen. Det er et krav, at servicen anvendes korrekt, og at der afleveres data, som er forståelige for borgere og sundhedsfaglige personer, således at MinLog 2 bidrager til tryghed og troværdighed, jf. afsnit 3.3 - Tryghed og troværdighed.

4.1.1. Ansvarlig for logning

Med introduktionen af MinLog 2 er det muligt for andre systemer at anvende MinLog 2 til at udstille logninger. Eksempelvis EPJ-systemer, FUT eller systemer i praksissektoren.

[R.1] Den dataansvarlige for de data, som der er sket opslag/opdateringer på, kan foretage logninger i MinLog 2.

[R.2] Andre aktører end den dataansvarlige for de data hvorpå der er sket opslag/opdateringer, må ikke foretage logninger i MinLog 2.

Andre aktører end den dataansvarlige skal ikke logge opslag, idet disse ikke har ejerskab til hverken data eller logdata. Eksempelvis må et EPJ-system ikke foretage en logning af opslag i FMK. Dette skal håndteres af FMK. EPJ-systemet kan dog logge opslag i lokale data, inkl. data der tidligere er hentet fra FMK og gemt i EPJ-systemet.

4.1.2. Hvilket system logger

Handlinger i et system, der alene medfører et opslag eller opdatering af et andet system, der logger til MinLog 2, skal ikke logges af det første system i MinLog 2.

[R.3] Logning af et opslag i en national service, som i forvejen logger i MinLog 2, skal ikke logges separat i MinLog 2. En logning af dette tilføjer ikke yderligere information.

Eksempelvis skal opslag i FMK via et EPJ-system ikke logges i MinLog 2 af EPJ-systemet, idet FMK vil logge opslaget.  

Eksempel:

 

4.1.3. Komplethed af logninger

NSP definerer ikke krav til, hvad der skal logges, men logdata skal være meningsfulde for borger og sundhedsfaglige aktører. Det er derfor væsentligt, at logdata er komplette. Dvs. at såfremt en type af handling (opslag eller opdatering) logges, så logges alle handlinger af denne type.

[R.4] Borgeren og den sundhedsfaglige, der ser logdata, skal opleve at logdata er komplette.

Eksempel: Lægers opslag på lægemiddelordinationer på FMK logges i MinLog 2. Det betyder, at alle lægers opslag på alle lægemiddelordinationer skal logges, uanset lægens formål med opslaget og uanset hvad lægemiddelordinationen måtte indeholde.

Borgere og sundhedspersoner vil ikke have kendskab til de forskellige typer af service-opslag, der kan foretages, og det vil derfor ikke være relevant at skelne mellem anvendelse af forskellige services.

Der kan reduceres i logdata, som beskrevet i R.9, f.eks. når logdata ellers vil forårsage flere ens eller næsten ens logninger. Dette vil ikke være i modstrid med krav til komplethed, da det ikke reducerer væsentlig information til borgeren eller den sundhedsfaglige.

4.1.4. Logning af opslag eller opdateringer

Skal MinLog 2 registrering anvendes af et system, vil det være et krav, at systemet som udgangspunkt altid logger opslag.

Der kan dog være undtagelser. NSP definerer ikke krav til undtagelser. Såfremt der eksisterer et lovgrundlag, der udtaler sig om undtagelser skal disse følges.

Eksempler på opslag der er omfattet af undtagelser, kan være opslag af teknisk karakter der foretages, uden at der er brugere, der har set personfølsomme data. Eksempelvis skal følgende ikke logges:

• At der hentes adresserede recepter til et apotekssystem, og hvor der ikke er ansatte på apoteket, der har set data.

Logning til borger-opslaget i MinLog 2 undlades, hvor der alene returneres lister med CPR-nummer men ikke tilknyttede personfølsomme data, idet en efterfølgende anvendelse af disse data vil medføre et nyt opslag og logning i MinLog 2. Eksempelvis skal følgende ikke logges til borgeropslaget i MinLog 2 (altså med angivelse af ”Ikke borger” i Filter-elementet, se medhjælpslog).

• At der hentes receptfornyelsesanmodninger til organisationen (f.eks. en lægepraksis), idet der returneres en liste af CPR-numre med en eller flere recept­fornyelses­anmodninger, men uden tilknyttet personfølsomme data som f.eks. lægemiddel. Først når receptfornyelsesanmodningen behandles slås der op på data for patienten, og dette opslag logges.

Oprettelser og opdateringer skal logges på samme måde som opslag, og skal generelt logges. For oprettelser og opdateringer vil det fremgå af data (medicinkortet, recepten m.v.), hvem der har oprettet eller opdateret dette. Logning af oprettelser og opdateringer skal dog logges for at sikre, at borgeren får et komplet overblik, og ikke skal søge data i flere systemer.

Tilsvarende gælder for en sundhedspersons opslag i medhjælpsloggen. Her vil den sundhedsfaglige aktør ifølge eksempelvis FMK-bekendtgørelsen ikke have lov til at slå op på data i FMK, idet denne sandsynligvis ikke aktuelt har patienten under behandling på tidspunktet, hvor der slås op i medhjælpsloggen.

For borgere gælder at både andres og egne opslag logges, for at kunne identificere misbrug.

4.1.5. Logninger som ønskes sløret for borger i MinLog 2

For at sikre at både personspecifikke og afdelings-sløringer er sløret i borgerens MinLog 2, er der væsentlige betingelser som skal overholdes. For at registreringerne kan sløres med MinLog 2 servicen, er der følgende opmærksomhedspunkter:

1. Den sundhedsfagliges navn

For at sikre ensartet pseudonym er det vigtig at den sundhedsfaglige altid optræder med samme navn i alle systemer der har registreringer af navn / CPR. Hvis navnet er forskelligt, vil det ikke resultere i samme pseudonym på tværs af logninger og på andre relevante services som fx Sundhed.dk og eJournal.

1. Personspecifikke sløringer

For den personspecifikke sløring gælder det, at alle sundhedsfaglige som arbejder for en organisation som sløringen er oprettet på, skal være sløret i borgerens MinLog 2. For at dette kan effektueres skal feltet “organisation” være korrekt udfyldt, se mere om det i [R.28] i afsnittet Organisation. Det vil sige at det skal være muligt at slå op i bagvedliggende systemer for at finde frem til organisationens navn. Se afsnittet Organisation.

1. Afdelingssløringer

For afdelingssløring er det relevant at se på hvordan sundhedspersoners daglige arbejde registreres.

• Hvis sundhedspersonens arbejdsområde sker på forskellige afdelinger, bør dette afspejles i de loglinjer der logges til MinLog 2, særligt hvilken afdeling der logges i Organisation.

Afdelinger der ønskes sløring for kan kun angives med SOR og SHAK koder, og dette skal matche med Organisation for at sløringen slår igennem.

4.2. Tekniske krav til anvendelsen af registreringsservicen

4.2.1. Afkobling

[R.5] Registreringsservicen skal så vidt muligt kaldes asynkront i forhold til brugerens anvendelse af et system (f.eks. FMK eller et EPJ-system).      

Destinationssystemets egen log-database kan være et oplagt sted at sikre en afkobling, ved at data til MinLog 2 periodisk udtrækkes fra denne.

[R.6.a] Registreringsservicen skal så vidt muligt kaldes med data opsamlet over en periode. Der skal sikres en passende vægt mellem datamængden, der kaldes med og antallet af kald pr. tidsenhed.

[R.6.b] Såfremt man forudser behov for at overskride anbefalingerne om 500 entries pr. kald og/eller 20 kald i timen, skal datamængde og kaldefrekvens fastlægges sammen med Sundhedsdatastyrelsen.

[R.7] Det skal sikres, at systemet, der afleverer data til registreringsservicen, ikke kommer bag efter med logninger.

Det skal sikres, at systemet, der afleverer data, har tilstrækkelig kapacitet, således at logninger ikke ophobes. Det kan dog være acceptabelt, at logninger i en travl periode ophobes, så længe der er sikkerhed for, at logninger hurtigt kan afleveres i en efterfølgende periode. 

4.2.2. Dubletter

[R.8] Anvendersystemet skal minimere at der sendes dubletter.

At et anvendersystem sender dubletter, kan ikke fuldstændigt udelukkes, f.eks. i en fejlsituation, hvor netværksforbindelsen er ustabil. MinLog 2 har en algoritme der identificerer og fjerner dubletter. På trods af dette vil fremsendelse af dubletter i væsentligt omfang medføre en unødvendig belastning af netværk og MinLog 2-services.

Algoritmen ser på hver enkelt logdata-entry og laver en sammenligning af alle felter, på den måde identificeres om indhold har været registreret tidligere. I de tilfælde hvor to logdata-entry er helt identiske beholdes den første logdata-entry.

4.2.3. Reducering af logdata

[R.9] NSP definerer ikke tidsrummet for, hvor længe der kan være imellem logninger, der evt. kan slås sammen. Hvis lovgrundlaget for de enkelte kildesystemer udtaler sig om dette, skal dette selvfølgelig følges.

Eksempel: To eller flere opslag på en lægemiddelordination i FMK foretaget af samme læge og på samme patient inden for en godkendt tidsperiode kan f.eks. slås sammen i én logning.

For EPJ-opslag har regionerne aftalt, at der sendes 1 logregistrering pr. dag, pr medarbejder, pr afdeling for samme borger.

[R.10] Reduceres logdata, skal der angives start- og sluttidspunktet for logninger i stedet for et enkelt tidspunkt.

Bemærk, hvis der er tale om forskellige handlinger er det kun logninger som har samme handling og dermed aktivitetstekst der kan slås sammen.

Eksempel: Hvis der har været ét opslag på et stamkort og én opdatering af stamkort vil dette resultere i to separate logninger.

4.3. Krav på feltniveau

Dette afsnit beskriver, hvorledes de enkelte felter i MinLog 2 anvendes til registrering af logdata.

Der skal logges med meningsfulde værdier, idet logningen i værste fald ellers kan bidrage til, at borgeren eller sundhedspersonen ikke oplever MinLog 2 som en troværdig kilde til information om, hvem der har slået op på borgerens data, eller hvad sundhedspersonen har foretaget af opslag.

 [R.11] Er der ingen meningsfulde felter for borger eller sundhedspersoner (herunder medhjælp) skal data ikke logges i MinLog 2.

For at destinationssystemet kan anvende meningsfulde værdier til logning, er det en forudsætning, at destinationssystemet har data til rådighed, herunder at snitfladen mellem kildesystemet og destinationssystemet er indrettet således, at der kaldes med tilstrækkelige data til at kunne logge meningsfulde værdier i MinLog 2. Destinations­systemet vil f.eks. være afhængig af, hvilke organisationsnavne der er registreret i SOR.

4.4. Retningslinjer for Systemlogning

En række services på NSP registrerer oplysninger i MinLog 2, når der sker et opslag af en sundhedsfaglig. Det foregår ved, at servicekaldet følges af en adgangsbillet (SOSI ID-kort på niveau 4), som identificerer brugeren. Servicen på NSP anvender oplysninger fra adgangsbilletten til at registrere i MinLog 2, hvilken sundhedsperson, der har udført kaldet.

Sundhedsdatastyrelsen understøtter ikke systemlogning på vegne af NSP’s anvendere. Dermed undgår man registreringer i borgerens MinLog 2, som kun indeholder organisationsoplysninger. Oplysningerne risikerer at forvirre, og det kan medføre forøget belastning på servicedesk-organisationerne, når borgere henvender sig for at høre om baggrunden for denne type logninger.

4.4.1. Kilde- og destination-systemer

Registreringsservicen indeholder felter til at angive kilde- og destination-systemer, se f.eks. den oprindelige løsningsbeskrivelses afsnit ”Source- og destination-systemer” (i version 1.7 afsnit 4.2.1). Løsningsbeskrivelsen findes her.

[R.12] Systemet der kalder MinLog 2-registreringsservicen skal altid angives i destination-elementet.

Kalder et EPJ-system FMK vil FMK være destination-systemet, og FMK skal logge opslaget i MinLog 2.

[R.13] Såfremt destination-systemet selv kaldes af et kildesystem, bør der angives information omkring kildesystemet i registreringsservicen.

Kalder et EPJ-system FMK, vil EPJ-systemet være kildesystemet, svarende til venstre figur herover. EPJ-systemet kan selv være kaldt af et andet system, f.eks. en borgerportal, og denne vil så igen være yderligere et kildesystem i kæden, svarende til højre figur herover. I så fald bør begge kildesystemer angives, såfremt dette er teknisk muligt.

Når EPJ-systemer tager MinLog 2 registreringsservice i anvendelse, for opslag og opdateringer i EPJ-systemet, vil der ikke nødvendigvis være noget kildesystem, svarende til figuren herunder. Så der skal i dette tilfælde kun udfyldes destinationssystem.

4.4.2. Systemnavn

Systemnavnet skal gøre det muligt at identificere destinationssystemet, som har afleveret data til MinLog 2, og som evt. yderligere logdata findes i.

[R.14] Det er væsentligt, at registreringsservicen kaldes med et systemnavn, der er unikt for den organisation, der registrerer i MinLog 2.

[R.15] Systemnavne skal være generelt forståelige, og kan blive vist sammen med øvrig loginformation for borgere og sundhedsfaglige. Tekniske termer, versionsnumre og lignende bør ikke indgå, medmindre dette er nødvendigt for at skelne to eller flere separate installationer

Har en region f.eks. to separate installationer af et system må hver installation gives et unikt navn f.eks. som ”Aldente (AUH)” og ”Aldente (Midt)”.

4.4.3. Correlation-ID

Såfremt systemet, der kalder registreringsservicen kan medsende et Correlation-ID, vil dette blive anvendt til gruppering. For EPJ-systemers vedkommende kan Correlation-ID f.eks. svare til et forløbs-id eller lignende.

[R.16] Et Correlation-ID skal i denne forbindelse betragtes som ét sammen­hængende forløb for samme patient.

Et forløb i MinLog 2 svarer ikke nødvendigvis til en sundhedsfaglig aktørs login-session i et system.

Der kan ikke gives en fast definition af, hvad der præcist udgør en sammenhæng med samme Correlation-ID i et vilkårligt system. Men følgende kan eksemplificere, hvordan denne sammenhæng kan se ud:

• En sundhedsfaglig brugers opslag på samme patient i FMK-online. Dvs. fra der f.eks. slås op på CPR-nummer og til der slås op på en ny patient, FMK-online lukkes eller login timer ud.
• En sammenhængende indlæggelse på sygehus, registreret i et EPJ-system. Eksempelvis svarende til et id for forløb, indlæggelse eller andet der haves i EPJ-systemet eller PAS.
• En sundhedsfaglig brugers opslag på samme patient i et speciallæge-system, LPS eller tandlægesystem, foretaget inden for et tidsrum på f.eks. en time, hvor brugeren ikke indimellem har slået op på andre patienter.

I snitfladen findes der felter til Correlation-ID i for både kildesystem og destination-system. Dette svarer til, at værdien kan stamme fra både et klientsystem (f.eks. i tilfældet hvor en brugernær applikation har viden til at danne et id (f.eks. ”sessions-id”), der varer indtil en sundhedsfaglig bruger slår op på en ny patient), eller fra et bagvedliggende system der har viden om behandlingsforløb, indlæggelse eller andet (f.eks. tilfældet hvor et EPJ-system indeholder et behandlingsforløbs-id).

[R.17] Hvis der sendes både Correlation-ID for kildesystem og destinationssystem skal disse være ens.

4.4.4. Aktivitet

Aktiviteten er en kort tekst, der beskriver den handling, som brugeren har udført (eller forsøgt udført). Eksempelvis ”Hent medicinkort” på FMK. Hvilke aktiviteter i et system, der skal logges, samt den korte tekst for disse, skal fastlægges i et datasæt, som vil være specifikt for det system, der logger.

[R.18] Datasættet for aktivitet fastlægges sammen med Sundhedsdatastyrelsen i forbindelse med at et destinationssystem tager MinLog 2 i anvendelse.

Når datasættet fastlægges, er det væsentligt at dette gøres i generelle termer, der er forståelige for borgeren. Eksempelvis er ”Statusforespørgsel” og ”Opslag på transaktionsliste” for opslag på CTR ikke velegnede termer, her kunne der i stedet anvendes én fælles term ”Opslag på medicintilskud”. Generelle termer skal desuden medvirk til at kunne reducere data. Se Reducering af logdata.

4.4.5. Årsagsangivelse

I visse tilfælde er det ikke tydeligt for borgeren, hvorfor der er foretaget et opslag. Eksempler på årsager er: en administrator i forbindelse med en support-henvendelse, ved fejlsøgning eller et opslag foretaget af en myndighed, f.eks. Lægemiddelstyrelsen i forbindelse med behandling af en tilskudsansøgning.

[R.19] Hvor årsagen til et opslag eller en opdatering ikke er tydelig for borgeren, bør der medsendes en kort tekst for årsag i Reason-elementet.

[R.20] Teksten er ikke en fritekst, men en enkelt eller få tekster der udfyldes af systemet. Evt. kan administrator-brugerflader og lignende lade administrator vælge mellem få foruddefinerede tekster.

[R.21] For normale opslag, f.eks. lægens opslag på medicinkortet, apotekets opslag på recepter og tilskud skal der ikke angives en årsag.

Formålet med årsags-feltet er at gøre årsagen til ”usædvanlige” opslag tydelig for borgeren, og reducere antallet af supporthenvendelser.

4.4.6. Privatmarkering (Kritikalitet)

Såfremt en handling viser, opretter eller opdaterer privatmarkerede data angives dette i elementet til kritikalitet.

[R.22] Når der slås op på, oprettes eller opdateres data, der indeholder en privatmarkering, skal det angives i MinLog 2-registreringen i Criticality-elementet. Dette skal både ske når den sundhedsfaglige aktør har borgerens samtykke eller når der anvendes værdispring.

[R.23] Ved opdatering skal der logges med Criticality-element, når en privatmarkering oprettes, men ikke når privatmarkeringen fjernes. Har aktøren forud slået op på privatmarkerede data, vil dette være logget.

[R.24] Opslag, oprettelse eller opdatering af data, der ikke er privatmarkerede må ikke angives som sådan i Criticality-elementet. Hvis et opslag blot returnerer ”at der findes privatmarkerede data” men ikke selve det privatmarkerede data, må logningen af opslaget ikke anvende Criticality-elementet.

Som en konsekvens af ovenstående, kan handlinger på privatmarkerede og ikke-privatmarkerede data ikke reduceres til samme logning i MinLog 2, som beskrevet i Reducering af logdata.

4.4.7. Samtykke, værdispring eller ”almindeligt opslag” (Addition)

Det kan angives om et opslag er sket med borgerens samtykke, værdispring eller som ”almindeligt opslag”.

[R.25] Er opslaget, oprettelse eller opdatering sket med samtykke eller værdispring skal dette angives i Criticality-elementet.

4.4.8. Opslagstidspunkt (DateTime, FromDateTime, ToDateTime)

Tidspunktet for opslaget angives enten i DateTime-elementet, såfremt der er tale om et enkelt opslag. Ellers anvendes FromDateTime og ToDateTime til at angive en periode, der omfatter tidspunkterne for opslagene, såfremt der er tale om flere næsten ens opslag, der er reduceret til samme logning i MinLog 2, som beskrevet under Reducering af logdata.

[R.26] Dato og tid skal angives i UTC (zulu tid). Anvendersystemer skal sikre en korrekt tidsangivelse og korrektion til lokal tid, både ved registrering og opslag.

4.4.9. Organisation

Den sundhedsfaglige, der har foretaget opslaget, vil oftest være tilknyttet en organisation, f.eks. vil en læge være tilknyttet en lægepraksis eller et sygehus, en farmaceut eller farmakonom vil være knyttet til et apotek osv.

[R.27] Aktørens organisation skal angives, såfremt den findes.

Der kan være tilfælde, hvor der ikke findes en organisation, eksempelvis for en pensioneret læges opslag i FMK-online.

[R.28] Organisationen skal så vidt muligt angives som en kombination af ID og kilde til ID.

Eksempelvis:

• Sygehus: SOR-ID eller SKS / SHAK-kode.
• Lægepraksis, speciallægepraksis, tandlæge mm: SOR-ID eller Ydernummer.
• Kommunal hjemmesygepleje: SOR-ID eller Kommunekode.
• Private aktører (f.eks. privat hjemmesygepleje): SOR-ID, CVR eller CVR-P.
• Apoteker: SOR-ID, CVR, lokationsnummer, apoteksnummer.

[R.29] Erstatningsydernummer må ikke anvendes. I stedet kan CVR-nummer anvendes, hvis det haves, ellers må organisations-ID undlades.

Der kan findes situationer, hvor destinationssystemer ikke har et meningsfyldt organisations-ID, men i stedet kun et organisationsnavn.

[R.30] Organisationens navn skal altid angives, hvor den sundhedsfaglige aktør, der har foretaget opslaget, er tilknyttet en organisation.

[R.31] Anvendes kun et organisationsnavn og ikke et ID, skal organisationsnavn i sig selv give en tydelig identifikation.

Eksempelvis er et organisationsnavn som ”Sportsklinikken”, “Medical Health Center” mm. ikke gode navne der giver borgeren nogen indsigt i hvilken organisation, der har foretaget opslag på borgerens data. Her vil ”Sportsklinikken, Privathospitalet Kollund” eller “Medical Health Center, Danfoss A/S” give mere mening for borgeren.

I tilfælde hvor der ikke angives et ID for organisation, vil det ikke være muligt at effektuere en afdelingssløring.

4.4.10. Person-ID

PersonID anvendes til identifikation af borgeren og af aktører, der har foretaget opslaget, oprettelsen eller opdateringen, der logges.

[R.32] Borgeren identificeres via CPR-nummer eller eventuelt erstatnings-cpr-nummer.

[R.33] Den sundhedsfaglige aktør kan identificeres med CPR-nummer eller autorisationsnummer.

NSP accepterer ikke andre identifikationsformer på sundhedsfaglige aktører.

Brugerens rolle

[R.35] Den sundhedsfaglige aktørs rolle registreres

MinLog 2 indeholder ikke en rolle-model. Roller registreres, som de er navngivet i destinationssystemet, eventuelt i forsimplet form. Systemer der ikke anvender egentlige roller vil typisk alligevel f.eks. via login kende til en overordnet rolle, f.eks. ”Borger” for opslag foretaget via borgerportaler.

Der vil være en sammenhæng til et evt. angivet autorisationsnummer, det er op til det kaldende destinationssystem at sikre, at sammenhængen er korrekt. Eksempelvis at der ikke kaldes med autorisationsnummer som sygeplejerske og rolle læge, hvis aktøren både er autoriseret sygeplejerske og læge.

Titler og roller i MinLog for opslag via DDS

I forbindelse med opslag via DDS, som ikke foretages af borgeren selv, en fuldmagtshaver eller en forældremyndighedsindehaver, er følgende titler og roller blevet fastlagt for MinLog:

• Sundhedsfaglig – Anvendes både til sundhedsfaglige med og uden administrationsrettigheder.
• Administrativ medarbejder – Anvendes alene i SDS til indtastning af ikke-digitale borgeres ønsker (LOB – national rolle).
• På vegne af sundhedsfaglig – Angiver en rolle, hvor opslag foretages på vegne af en sundhedsfaglig.
• Deltager i patientbehandling – En børnefaglig national rolle for personer, der deltager i patientbehandling, men som ikke er ansat i sundhedsvæsenet.

4.4.11. Handlinger på vegne af en anden aktør

Handlinger kan ske på vegne af en anden aktør, eksempelvis at en klinikassistent foretager opslag på vegne af en læge.

[R.36] Såfremt det kaldende system understøtter ”på vegne af” skal dette registreres i MinLog 2.

4.4.12. Filtrering af logninger der ikke skal vises for borger

Der kan ske opslag, der ikke er relevante for borgerens opslag i MinLog 2, men er relevante for lægens (mm.) opslag i medhjælpsloggen.

[R.37] Såfremt det vurderes, at logninger i destinationssystemet ikke er relevante at udstille for borger i MinLog 2, bør der angives ”Ikke borger” i filter-elementet i registreringen i MinLog 2. Dette bør være undtagelsesvis, og vurderingen skal ske i samarbejde med Sundhedsdatastyrelsen, hvor tryghed og troværdighed i forhold til borgeren skal vægte højest, jf. afsnit 2.2 - Tryghed og troværdighed.

4.4.13. Filtrering af logninger der ikke skal vises for borger

Der kan ske opslag, der ikke er må vises for forældre / forældremyndigheds­indehaver. Eksempelvis registreringer der omhandler præventionsmidler, aborter og blodtransfusioner. Se endvidere Sundhedsloven § 37. Stk. 2

[R.38] Må logdata ikke vises ved opslag foretaget af forældremyndigheds­indehaver skal det kaldende system angive dette med ”Ikke forældremyndigheds­indehaver” i filter-elementet.

MinLog 2 har ud over dette felt ikke information til at vurdere om data skal filtreres fra ved opslag foretaget af forældremyndigheds­indehaver, og filtreringen kan derfor kun foretages ud fra en angivelse fra destinationssystemet.

5. Opslagsservices

MinLog 2 stiller to former for opslag til rådighed: Borgerens opslag på MinLog 2 og en autoriseret sundhedspersons opslag på Medhjælpsloggen.

Disse to services har forskellige formål, men anvendes efter samme principper, og er derfor beskrevet sammen i dette vejledningsdokument.

Hvis en borger har sløringer enten personspecifikke eller afdelingssløringer i dennes MinLog 2 sørger servicen for at disse optræder slørede, så borgeren kun ser et pseudonym i stedet for den sundhedsfagliges navn. Et navn vil altid forekomme som det samme pseudonym. Hvis anvisningerne beskrevet i afsnittet Logninger som ønskes sløret for borger i MinLog 2 er fulgt vil en sundhedsperson derfor også have det samme pseudonym alle steder i loggen.

5.1. Ikke-tekniske krav til anvendelsen af opslagsservices

Aktuelt er der ikke identificeret ikke-tekniske krav til anvendelsen af opslagsservicen.

5.2. Tekniske krav til anvendelsen af opslagsservices

5.2.1. Paginering

Ved opslag kan der forekomme store mængder logninger. Især må dette forventes ved opslag i medhjælpsloggen, men kan også ske ved borgeropslag på MinLog 2.

[O.1] Ved opslag på MinLog 2 borgeropslag og på medhjælpsloggen skal klientsystemer kunne håndtere, at der findes mange logninger, eksempelvis ved anvendelse af paginering.

5.2.2. Håndtering af ukendte source-værdier

[O.2] Klientsystemer skal kunne håndtere, at der kan returneres ukendte værdier i source-attributter.

Eksempelvis kan der på et tidspunkt oprettes et register for erstatnings-cpr-numre, og der kan derved blive returneret f.eks. et person-ID som ”0205170AC2” og kilde (source) ”eCPR”.

Dette medfører også, at det vil være formålstjenligt at indrette brugerfladen således, at der f.eks. ikke hardkodes en label-tekst med ”CPR-nummer”, men label for indhold vælges ud fra indhold af source-attributten. Returneres der en ukendt værdi i source-attributten kan denne vises ”as is” sammen med værdien, altså eksempelvis ”eCPR: 0205170AC2”.

5.2.3. Opslag på id og source-værdier

Id’er på personer og organisationer returneres af MinLog 2 i det omfang, der er registreret værdier, der kan slås op i de registre MinLog 2 anvender. Dvs. CPR- og autorisationsnummer samt SOR, CVR, ydernummer, kommunekode og lokationsnummer (det sidste kun for apoteker).

Der er dog ikke garanti for, at MinLog 2 altid vil kunne returnere et organisationsnavn. Eksempelvis afviser MinLog 2 ikke logninger, hvis et anvendt id ikke findes i registret, der udpeges med source, ud fra en betragtning om at det er vigtigere at dette logges, og opslag eller oprettelser/opdateringer ikke skjules for borgeren.

[O.3] Såfremt organisationsnavn ikke returneres ved opslag i MinLog 2, kan anvender­systemer slå op i yderligere registre, og vise et evt. organisationsnavn der herved fås.

[O.4] Såfremt organisationsnavn returneres ved opslag i MinLog 2, kan anvender­systemer slå op i yderligere registre og vise et evt. Organisationsnavn, der herved fås sammen med organisationsnavn returneret fra MinLog 2. En forudsætning er dog, at dette kan gøres på en brugervenlig og for borgeren let forståelig måde. Organisationsnavn hentet fra andre registre må således ikke erstatte, hvad der evt. returneres fra MinLog 2.

5.2.4. Visning af ”på vegne af”

[O.5] Returneres der ”på vegne af” felter, skal der vises information både om aktøren, der har foretaget handlingen, og aktøren som handlingen er foretaget på vegne af.

Der er dog ingen krav til at begge værdier vises på lige fremtrædende pladser. F.eks. kan aktøren der har foretaget handlingen vises i liste-visninger, men detalje-visninger indeholder begge aktører. Hvis borgeren har en aktiv sløring, eller været indlagt på en sløret afdeling vil begge sundhedsfaglige være sløret.

5.2.5. UTC (zulu-tid)

[O.6] Dato og tid returneres i UTC (zulu-tid). Anvendersystemer skal sikre en korrekt tidsangivelse og korrektion til lokal tid, både ved registrering og opslag.

5.2.6. Visning af tomme felter

Der er ingen specifikke krav til, hvordan tomme felter vises. Tomme felter i data returneret fra MinLog 2 kan dermed vises på samme måde som tomme felter i øvrigt vises i systemets brugerflade, dvs. på samme måde som Sundhed.dk, FMK-online m.v. ellers håndterer tomme felter.

6. Termer og referencer

Herunder findes en kort definition af termer eller en reference til yderligere dokumentation. Specielt skal der bemærkes, at der vedligeholdes en FAQ på nspop.dk 

 

7.  Versionering