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.
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, apoteksansatte 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 sundhedsdata, 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.
Anvendelse af MinLog 2 forudsætter ikke en certificering. Dokumentet her indeholder alligevel et antal krav til anvendelse af registreringsservicen 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.
Det er væsentligt at bemærke, at registrering i MinLog 2 ikke erstatter logning i kildesystem 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.
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:
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:
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.
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.
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 destinationssystem 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ægepraksissystemer m.v., således at den autoriserede sundhedsperson kan foretage tilsyn via eget system.
I alle nedenstående bekendtgørelser er det fastlagt, at en borger skal have adgang til logoplysninger.
Loggen stilles derfor til rådighed for borgeren i alle tilfælde, og dette sker som udgangspunkt via sundhed.dk.
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.
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.
I dette kapitel beskrives anvendelse af MinLog 2 registreringsservicen. Den præcise tekniske definition af registreringsservicen og opslagsservices findes i snitfladebeskrivelsen samt WSDL og XML-skema- definitionerne. Se 6 - Termer og referencer.
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.
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.
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:
En læge henter en patients medicinkort i FMK via EPJ-systemet. | FMK logger opslaget i MinLog 2. | EPJ-systemet logger dette lokalt, men ikke i MinLog 2. |
Lægen opretter efterfølgende en ny ordination i EPJ-systemet. |
| EPJ-systemet logger dette både lokalt og i MinLog 2. |
Lægen overfører ordinationen til FMK. | FMK logger opslaget i MinLog 2. | EPJ-systemet logger dette lokalt, men ikke i MinLog 2. |
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.
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:
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).
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.
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:
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.
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.
For afdelingssløring er det relevant at se på hvordan sundhedspersoners daglige arbejde registreres.
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.
[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.
[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.
[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.
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. Destinationssystemet vil f.eks. være afhængig af, hvilke organisationsnavne der er registreret i SOR.
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.
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.
|
|
Eksempel på logning med et kildesystem og et destinationssystem | Eksempel på logning med en kæde af to kildesystemer og et destinationssystem |
[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.
|
Eksempel på logning kun ét destinationssystem |
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)”.
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 sammenhæ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:
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.
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.
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.
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.
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.
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.
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:
[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.
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:
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.
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.
Der kan ske opslag, der ikke er må vises for forældre / forældremyndighedsindehaver. 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ældremyndighedsindehaver skal det kaldende system angive dette med ”Ikke forældremyndighedsindehaver” 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ældremyndighedsindehaver, og filtreringen kan derfor kun foretages ud fra en angivelse fra destinationssystemet.
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.
Aktuelt er der ikke identificeret ikke-tekniske krav til anvendelsen af opslagsservicen.
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.
[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”.
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 anvendersystemer 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 anvendersystemer 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.
[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.
[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.
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.
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
MinLog 2 Dokumentationen | https://www.nspop.dk/display/public/web/MinLog2+-+Leverancebeskrivelse |
MinLog 2 Guide til anvendere | MinLog 2 - Min Log Opslag - Guide til anvendere - NSP services - Global Site (nspop.dk) |
MinLog Løsningsbeskrivelse version 1.7 | Link til den oprindelige løsningsbeskrivelse findes på siden: https://www.nspop.dk/display/public/web/MinLog2+-+Leverancebeskrivelse |
Bekendtgørelse om adgang til og registrering m.v. af lægemiddel- og vaccinationsoplysninger | https://www.retsinformation.dk/forms/R0710.aspx?id=163123#Kap6 |
FMK | Fælles Medicinkort https://sundhedsdatastyrelsen.dk/da/registre-og-services/om-faelles-medicinkort |
Sikkerhedsbekendtgørelsen | |
Sundhedsloven |
Version | Dato | Ansvarlig | Beskrivelse |
0.1 | 2017-04-24 | TKN | Udkast |
0.2 | 2017-05-01 | TKN | Opdateret til internt review |
0.3 | 2017-05-09 | TKN | Opdateret med Reason-felt samt omkring opslag i medhjælpsloggen |
0.4 | 2017-05-22 | TKN | Mindre rettelser og tilføjelser |
0.5 | 2017-06-27 | TKN | Opdateret efter input fra Trifork |
0.6 | 2017-08-07 | TKN | Præcisering af Correlation-ID i source og destination |
0.7 | 2018-08-10 | TKN | Mindre rettelser og tilføjelser |
0.8 | 2018-11-05 | TKN | Mindre rettelser og tilføjelser. Ny R.7 omkring ophobning af logninger. |
0.82 | 2019-08-23 | AMA | Mindre sproglige forbedringer |
0.83 | 2019-11-27 | AMA | Henvisning vedr. correlation-ID opdateret |
1.0 | 2020-02-28 | TKN | Enkelte præciseringer, endelig version 1.0 |
1.1 | 2020-06-04 | AMA | Tilretning af R.9 reducering af logdata |
1.2 | 2020-11-13 | AMA | Anbefaling af antal logenties i request - R6 |
1.3 | 2023-13-07 | GETL, ASHA, GNAI | Gennemskrivning, opdatering ift. System-system logning, krav om at der sendes enten cpr eller autorisationsnr. på sundhedsfaglig etc. |
1.4 | 2024-03-07 | HELM | Tilføjelse til afsnit 2.2 vedr. hjemmel til sløring. |
1.5 | 2024-03-13 | HELM | Tilføjelse af anbefaling om kaldefrekvens og nyt krav (R.6.b) og antal logentries pr. kald og kaldefrekvens. |
1.6 | 2024-06-XX | AMA, IHPE | Anbefalinger til registrering i forbindelse med sløring, samt andre relevante tilpasninger. |
