Vad är egentligen avsikten med elementet LegalAuthenticator för bl.a. GIO?

Issue #384 resolved
Henrik Emilsson created an issue

Vi har inom avvikelsegruppen stött på ett antal fall där LegalAuthenticator för GIO och GLOO inte har mappats med person som har signerat dokumentet (legalAuthenticatorHSAId + legalAuthenticatorName).

Det har visat sig att vissa verksamheter har svårt att mappa LegalAuthenticator för bl.a. GIO då dessa remisser inte signeras så som kontrakten beskriver det:

../../legalAuthenticator 
Information om vem som signerat informationen i dokumentet. Person som ansvarar för utlåtandet.
Signering är inte samma sak som vidimering. Information om vidimering anges i attributet attested i bodyn.

Frågan är vad som egentligen avses med LegalAuthenticator för dessa remisskontrakt? Och stödjer det verksamhetens arbetssätt?

Comments (23)

  1. Jonas Dahl Account Deactivated

    Jag har försökt sätta mig in i TKB:erna för GIO och GLOO. Som jag förstår det så har man definierat tre personroller i TKB:erna: 1) Den som är ansvarig för innehållet i svaret ("accountableHealthcareProfessional", benämns även som författare) 2) Den som som signerat svaret ("OutcomeHeader/legalAuthenticator") 3) Den ("beställare") som har vidimerat svaret ("attested/legalAuthenticator"). Eftersom 1+2 är data som normalt bara finns i laboratoriesystemet så brukar inte ett journalsystem producera denna information, däremot bör journalsystem kunna producera information om den som vidimerat (3). Om jag läser kontraktet rätt så är det aldrig obligatoriskt att ange någon person under 1,2 och/eller 3.

  2. Fredrik Ström Account Deactivated

    Som Jonas noterar signeras informationen i laboratoriesystemet och återfinns vanligtvis inte i journalsystem. Det betyder att information om den som signerat (legalAuthenticator) normalt inte kommer att återfinnas i information från journalsystem. Det är inte något problem då kardinaliteten är 0..1. Detta beskrivs något klarare i GLOO där det står "Information om vem som signerat informationen i dokumentet. Det är normalt laboratorieläkeren som signerar laboratoriesvar. Signering = signering av remissvar. Vidimering anges i attributet attested i bodyn.". I GIO är det inte lika tydligt.

    Jag ska se över beskrivningarna av de tre rollerna som Jonas skriver om i kommentaren ovan, och se om dessa behöver förtydligas. Speciellt ska beskrivningen av legalAuthenticator kanske se över i just remisskontrakt. Här kanske det ska noteras att headern i dessa kontrakt utgår från en standard-header, vilket gör att dessa attribut i många fall inte är relevanta.

  3. Fredrik Ström Account Deactivated

    Min bedömning är att detta inte är en bug och att prioriteten inte bör vara major. Jag tror att kan lösas med att dokumentation förtydligas.

  4. Henrik Emilsson reporter

    Det kan nog bli bra. Har dock en fundering som kvarstår: Det finns ju också en tolkning av dessa element från ett tjänstekonsumentperspektiv. Dels finns ett regelverk för approvedForPatient kopplad till signering, och ett regelverk för hur automatisignering ska gå till, samt på sikt regler för om journalinformation ska släppas till patient (prenumerationstjänsten). Behöver det då förtydligas något kring tolkningen av element ur de perspektiven?

  5. Fredrik Ström Account Deactivated

    Det där är intressanta iakttagelser. Hur regelverket för approvedForPatient är utformat behöver kanske ses över lite. När det gäller remissvar hanteras dessa lite annorlunda än andra informationsmängder, då kliniker i journalsystem inte signerar svaren utan vidimerar dessa. Signeringen sker av ansvarig person, exempelvis labbläkare på labbet som utför analyserna när det gäller labbsvar. Det innebär att det kanske behöver förtydligas hur approvedForPatient samt automatsignering ska fungera, i relation till dessa element.

  6. Andreas Mårtensson

    @fredrikstrom @henemi

    Lite yrvaken efter semester men var har vi regelverket för ApprovedForPatient (och automatsignering (eller menar du låsning)??

  7. Fredrik Ström Account Deactivated

    Det är en bra fråga. Jag har inte koll på regelverket för approvedForPatient och inte heller vad gäller automasignering (eller automatlåsning). Jag tror att en lite översyn av de olika aktörerna som finns i tjänstekontrakten (speciellt med tanke på de kontrakt som har den äldre headern samt de nyare kontrakten som använder den nya headern) i relation till regelverken vore mycket bra. (Notera att GLOO och GIO som är i drift idag använder den äldre headern) Det är kanske en fråga som borde tas upp på TK-gruppen, då jag tror att insatt kunskap om de olika versionerna av headern och om regelverk finns i gruppen.

  8. Andreas Mårtensson

    @fredrikstrom @henemi

    Jag tar upp frågan om att skapa/förtydliga regelverk för approvedForPatient och automatsignering/-låsning med Ewa o Marcus på vårt samordningsmöte. Så det blir ett formellt uppdrag.

  9. Henrik Emilsson reporter

    Missade era kommentarer, sorry!

    Regelverket för ApprovedForPatient står beskrivet i JOL-headerspecen samt i respektive TKB. JoL Header Fältregler 1.1 Ansvarig vårdpersonals beslut, alternativt baserat på verksamhetens policy och regler, huruvida informationen får delas till patient för ändamålet patients egen åtkomst (men-/sekretessprövning). Värdet sätts i sådant fall till true, i annat fall till false. False innebär att informationen inte får delas till patient. Notera att flaggans värde kan för samma information förändras med tiden på grund av att rådrumstid har passerats, eller att verksamheten ändrat policy för vad som lämnas ut till patient. I sådana fall skall källsystemet uppdatera engagemangsindex för att konsumenter skall kunna bli notifierade därom.

    https://bitbucket.org/rivta-domains/riv.clinicalprocess.healthcond.actoutcome/raw/3.1.5/docs/TKB_clinicalprocess_healthcond_actoutcome.docx GetImagingOutcome --> Fältet ../../legalAuthenticator Information om vem som signerat informationen i dokumentet. Person som ansvarar för utlåtandet. Signering är inte samma sak som vidimering. Information om vidimering anges i attributet attested i bodyn.

    https://bitbucket.org/rivta-domains/riv.clinicalprocess.healthcond.actoutcome/raw/3.1.5/docs/TKB_clinicalprocess_healthcond_actoutcome.docx GetReferralOutcome --> Fältet ../../legalAuthenticator Information om vem som signerat informationen i dokumentet. Signering = signering av remissvar. Information om vidimering sker i attributet attested i bodyn. I de fall där informationen har låsts utan signering, representeras detta genom att signatureTime sätts till tidpunkten för låsning, och resterande fält i LegalAuthenticatorType lämnas tomma.

    Anm: Noterar att beskrivning av LegalAuthenticator är olika för tjänstekontrakten i clinicalprocess:healthcond:actoutcome (varav två exempel ovan).

  10. Emmy Damberg Account Deactivated

    Vi kommer att göra en dokumentuppdatering där beskrivningen av fältet imagingOutcomeHeader/legalAuthenticator uppdateras till förslagsvis: "Information om vem som signerat informationen i dokumentet. Det är normalt radiologen som signerar bilddiagnostiska svar. Signering = signering av remissvar. Vidimering anges i attributet attested i bodyn." Det är samma formulering som för GLOO men med radiolog istället för laboratorieläkare och bilddiagnostiska svar istället för laboratoriesvar.

    Någon däremot? Ping särskilt till @fredrikstrom

  11. Fredrik Ström Account Deactivated

    Hallå där!

    Jag är inte inloggad i Bitbucket nu, så jag får svara med ett mail istället. Jag är inte superinsatt i imaging, men beskrivningen i ärendet låter korrekt tycker jag.

    .fs

    Skickat: den 8 december 2017 16:42 Till: Fredrik Ström fredrik.strom@cag.se Ämne: Re: [Bitbucket] Issue #384: Vad är egentligen avsikten med elementet LegalAuthenticator för bl.a. GIO? (rivta-domains/riv.clinicalprocess.healthcond.actoutcome)

    [emmydamberg]

    Emmy Damberg commented on issue #384:

    Vad är egentligen avsikten med elementet LegalAuthenticator för bl.a. GIO?https://bitbucket.org/rivta-domains/riv.clinicalprocess.healthcond.actoutcome/issues/384/vad-r-egentligen-avsikten-med-elementet

    Vi kommer att göra en dokumentuppdatering där beskrivningen av fältet imagingOutcomeHeader/legalAuthenticator uppdateras till förslagsvis: "Information om vem som signerat informationen i dokumentet. Det är normalt radiologen som signerar bilddiagnostiska svar. Signering = signering av remissvar. Vidimering anges i attributet attested i bodyn." Det är samma formulering som för GLOO men med radiolog istället för laboratorieläkare och bilddiagnostiska svar istället för laboratoriesvar.

    Någon där emot? Ping särskilt till @Fredrik Strömhttps://bitbucket.org/fredrikstrom/

    View this issuehttps://bitbucket.org/rivta-domains/riv.clinicalprocess.healthcond.actoutcome/issues/384/vad-r-egentligen-avsikten-med-elementet or add a comment by replying to this email.

    Unwatch this issuehttps://bitbucket.org/api/1.0/repositories/rivta-domains/riv.clinicalprocess.healthcond.actoutcome/issue/384/unwatch/fredrikstrom/9075a3536351ab07f6dee23635b5623d9c6127f2/ to stop receiving email updates.

    [Bitbucket]https://bitbucket.org

  12. Henrik Emilsson reporter

    Hej! Jag funderar på om den textuppdateringen löser grundproblemet. Kanske är ute på tunn is här, men om många har svårt att mappa mot detta fält i dag, så borde det väl bli lika svårt med den nya beskrivningen. Dvs, det är ingen som signerar informationen.

    @jonasdahl Har du någon input i ärendet?

    Med vänlig hälsning, Henrik

  13. Henrik Emilsson reporter

    Alltså, grundfrågan är om legalAuthenticator är ett element som ens är giltigt i dessa remisskontrakt. Och om det inte är giltigt, så finns det regler idag som baseras på detta element. Vilket då eventuellt skulle kräva att man tänkte om kring approvedForPatient.

  14. Jonas Dahl Account Deactivated

    @henemi Jag håller med dig Henrik, attributet legalAuthenticator blir underligt i dessa kontrakt. Någon informationen i attributet kommer med största sannolikhet aldrig kunna produceras och då förvirrar det bara.

  15. Emmy Damberg Account Deactivated

    Nej, det är sant att förtydligandet inte löser grundproblemet. Man skulle behöva göra ett arbete med att analysera problemen och möjliga lösningar på djupet, men det är väl ingenting som kan åtgärdas inom en dokumentationsuppdatering bara. Så ärendet får ligga kvar.

  16. Torbjörn Dahlin

    I GLOO4 efter arbete med terminolog har det konstaterats att termen vidimering inte är alldeles korrekt ("Vidimera innebär att bevittna och bestyrka en avskrifts eller kopias överensstämmelse med originalet."). Vidi-markering som också föreslagits innebär att bekräfta att man sett/tagit del av handling med sin signatur. Vår undersökning visade att i regionerna förekom både termen vidimering och signering beroende på om man fokuserade på att den som signerar gör det i syfte att föra in svaret i journalen (som för journalinformation i allmänhet), alternativt att man tagit emot och vid behov agerat på svarets innehåll (då felaktigt vidimering användes). Vi beslutade att fokusera på det legala att signera informationen då den infogas i journalen och att det är en rutin kopplat till detta för att samtidigt kontrollera om det finns avvikande värden som kan kräva åtgärder. För att komma ut dilemmat har vi i kontraktet möjlighet till två signaturer på ett labbsvar, "ansvarigs signatur" (dvs. ansvarig på labb) och "mottagares signatur" (den HoS-personal som infogar materialet i svaret). båda är optional

  17. Fredrik Ström Account Deactivated

    För länge sedan när kontrakten togs fram handlade diskussionen om huruvida signering skulle användas eller vidimering/vidi-markering. Då kom man fram till att den som signerar är laboratorieläkaren. Då en läkare i journalsystem inte ansvarar för korrektheten i informationen (att tolkningar i labbsvaret är korrekt och att det står rätt saker i svaret) bedömdes då att hen inte kan signera svaret (se "Journalföring och behandling av personuppgifter i hälso- och sjukvården -Handbok vid tillämpningen av Socialstyrelsens föreskrifter och allmänna råd (HSLF-FS 2016:40) " står det "En journalanteckning ska signeras av den som ansvarar för uppgiften, om det inte finns något synnerligt hinder (3 kap. 10 § PDL). I kravet på signering ligger att den som signerar en anteckning bekräftar dess riktighet, det vill säga kontrollerar innehållet så att han eller hon kan gå i god för det". Här var ett av argumenten att läkaren i journalsystemet inte kan kontrollera innehållet och gå i god för det. Därför valdes det då att gå vägen vidimering eller vidi-markering. Just nu har jag inte koll på vilket av dessa som valdes eller motiveringen för valet - men mitt minne är att vidi-markering är det mer korrekta alternativet. Utifrån det ser jag att det inte är lämpligt att ha möjligheten till att två personer signerar svaret. Har ni kontrollerat detta med medicinskt sakkunniga?

  18. Torbjörn Dahlin

    Jo. Det var som sagt två olika skolor, den ena var att man signerade uppgifter som fördes in i journalen, den andra var att man signerade att man tagit del av och vidtagit nödvändiga åtgärder. Alla var inte överens om att man vidtagit eventuella åtgärder så överenskommelsen var: Signering av labbsvar var den normala signeringen av uppgifter som förs in i journalen. Den signerade läkaren tar ansvar av riktigheten på samma sätt som de signerar anteckningen att patienten uppgett att de haft ont i magen en vecka, dvs. att de signerar införandet av laboratoriesvaret i patientens journal för att de så långt de kan avgöra är ett autentiskt laboratoriesvar. Man kan lokalt besluta om undantag från regeln om att uppgifter i journalen ska signeras och därför är mottagarens signatur valfri. Vad man utför i samband med att man signerar det mottagna svaret bestäms lokalt. Majoriteten i referensgruppen föredrog signering framför vidimering/vidi-markering.

  19. Log in to comment