Indhold

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.

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.

...

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

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.

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.

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.

...

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

Principper og ansvar for logning

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

...

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

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.

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.

...

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.

Borgerens adgang til logoplysninger

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.

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.

...

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

Tryghed og troværdighed

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.

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.

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.

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.

...

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.

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.

...

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.

...

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.

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.

...

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.

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:

...

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.

Tekniske krav til anvendelsen af registreringsservicen

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

...

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. 

Dubletter

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

...

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.

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.

...

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

Krav på feltniveau

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

...

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.

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.

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.

...

Systemnavn

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

...

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

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.17] Hvis der sendes både Correlation-ID for kildesystem og destinationssystem skal disse være ens.

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.

...

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.

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

...

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

Privatmarkering (Kritikalitet)

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

...

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.

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.

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.

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.

...

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

Person-ID

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

...

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.

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.

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.

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

...

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.

Opslagsservices

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

...

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.

Ikke-tekniske krav til anvendelsen af opslagsservices

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

Tekniske krav til anvendelsen af opslagsservices

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.

Håndtering af ukendte source-værdier

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

...

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

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

...

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

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.

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.

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.

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 

...

 Versionering

...