Filtrering och utvärdering baserat på lagrade grundattribut och spärrar

Bakgrundsmaterial från Inera om spärrtjänster: “SAD - Spärr” samt “Användarhandbok Spärradministration”.

Tabellen nedan och dess ID/radnummer används för att klargöra de omfång som olika AQL-frågor gäller. (Se bakgrundskapitlet för mer information om omfång och spärrar.)

AQL-fråga och svar behöver uppdateras om strukturändringsförslaget 2022-02-08 genomförs

Sammanhang och förutsättningar

• samtycke/nödsituation finns om frågan gäller att läsa innehåll i jourjalanteckning ELLER

• systemet vill lista antal dokument på en vårdenhet/vårdgivare om frågan gäller att kolla förekomst eller räkna (ospärrade) anteckningar

Vi beskiver inte engegemansindex här… utan tittar främst på en enskild CDR (jfr VGRs bild och funktion) där det kan finnas data från flera vårdgivare (dock sannolikt långt ifrån alla som har info om denna patient)

Spärrtjänst anropas - det man får som svar är en lista på HSAIDn som representerar spärrade enheter och vårdgivare samt typ av spärr (inre resp yttre spärr)

Värdemängd för BlockTypeType

Den inre spärren (för en vårdenhet) blir automatiskt även en yttre spärr

https://rivta.se/tkview/#/domain/informationsecurity:authorization:blocking

Konstruera lista till AQL-filtrering och till GUI som listar spärrlista

• Vårdgivare 1 AND (ev inkluderade vårdenheter hos vg1 BUT NOT exkluderade vårdenheter hos vg1 )

• OR

• Vårdgivare 2 AND (ev inkluderade vårdenhet hos vg2 BUT NOT exkluderade vårdenheter hos vg2)

Nedanstående exempel på AQL-sökfråga söker fram alla pulsmätningar som passerar tillgångsfiltreringen baserad på vårdgivare eller vårdenhet.

Förprocessning

Spärrtjänsten returnerar (informationCareUnitId, informationCareProviderId, blockType)

Förprocessning av svar från spärrttjänsten krävs för att välja ut vilka enheter i denna CDR som är spärrade

Variabler/variabellistor som kommer ut ur förprocessning

• care_unit_of_user - HSA-ID

• care_provider_of_user - Organisationsnummer

• Lista: externally_blocked_care_providers* används för processning av yttre spärrar av hel vårdgivare.

• Lista: blocked_care_units används för inre (och automatiskt även yttre) spärrar av enskilda vårdenheter.

Notera att varken care_unit_of_user eller care_provider_of_user får finnas i spärrlistorna efter förprocessningen, om de är listade av spärrtjänsten måste de alltså tas bort ur listan innan den infogas i AQL-frågan.

*) omvandlad till organisationsnummer (kan ha varit HSA-ID som input från tjänsten)

En öppen fråga som letar pulsmätningar över 10 slag/minut utan PDL-koll alls, visar den totala mängden matchande exempel i testdatabasen:

Open

Om patienten inte har några spärrar alls så motsvarar detta fall 02, där allt hos vårdgivaren “Stockholms läns sjukvårdsområde“ listas:

Vilket ger nedanstående svar, där vi även har valt detaljerad vy i frågeverktygets gränssnitt för att även visa identifierarnes typ:

Open

Fall 00: …och om “vårdenhetsfiltret” också läggs till och sätts till “Brandbergens vårdcentral“ så ser “WHERE” delen av frågan ut så här…

…vilket ger följande urval:

och samma resultat i verktygets “raw”-format

Spärr, hävande av spärr och undantag

…

Information som är olämplig att spärra

Att en patient är allergisk mot något eller tar vissa mediciner är viktigt för hälso- och sjukvårdspersonal som vårdar en patient som inte kan göra sig förstådd (t.ex. är medvetslös). Spärr av sådan information kan i värsta fall leda till skada eller död i en akut situation. För att förhindra detta finns en möjlighet att undanta läkemedels- och uppmärksamhetsinformation från spärr i den nationella spärrtjänsten. Patienten ges därför möjlighet att välja om spärr ska omfatta även läkemedel och/eller uppmärksamhetsinformation. För att kunna genomföra sådana kategori-baserade val i praktiken behöver någon (Systemägare? Leverantör?) definiera vilken typ av information som räknas in i kategorierna. Detta ligger rutan för PDL-implementationsguidens avgränsningar och behandlas i separata implementationsguider:

• https://openehr.atlassian.net/wiki/spaces/SWE/pages/1995341825

• https://openehr.atlassian.net/wiki/spaces/SWE/pages/1966211073 .

Spärr-baserad filtrering implementerad med AQL

Om vi söker med på hela vårdgivaren “Stockholms läns sjukvårdsområde“ men en lista med spärrade vårdenheter (beroendekliniken och gyn) också anges så ser “WHERE” delen av frågan ut så här…

…vilket ger följande urval:

Vid sammanhållen journalföring (alltså alla samverkande vårdgivare) och samma spärrlista så ser “WHERE” delen av frågan ut så här…

…vilket ger följande urval:

Vid sammanhållen journalföring (alltså alla samverkande vårdgivare) och en kombination av spärrlistor för

• Vårdenheter: Beroendekliniken +Gyn

• Vårdgivare: Annas Mddicinska Fotvård + Danderyds Sjukhus

så ser “WHERE” delen av frågan ut så här…

TODO: visa med variabler och lagrade frågor och REST-API

Logguppföljning

Åtkomstkontrollerna ska göras systematisk och återkommande (4 kap. 3 § PDL). Hur ofta det behöver göras kan exempelvis bero på verksamhetens omfattning, antalet personer med åtkomst, hur behörigheterna delas ut och hur omfattande kontrollerna är. Det är nödvändigt att kontrollerna görs regelbundet och omfattar en så hög andel av logghändelserna att det blir en effektiv kontroll.

(ovan från: https://www.socialstyrelsen.se/regler-och-riktlinjer/foreskrifter-och-allmanna-rad/konsoliderade-foreskrifter/201640-om-journalforing-och-behandling-av-personuppgifter-i-halso--och-sjukvarden/ )

Metod

I en instruktion för vart i informationsmodellen information tillhörande en PDL-loggpost inhämtas i OpenEHR’s informationsmodell så bör loggranskarens uppgift och vilka analyser denne väntas utföra tas i beaktning.

Därtill är finns Ineras redan definierade informationsmodeller i RIV (regelverk för interoperabilitet inom vård och omsorg, rivta.se). Det är vanligt krav på ineteroperabilitet med RIV tjänstekontrakt ställs vid upphandlingar av IT-stöd i det offentliga vård-Sverige.

Dessa är de två perspektiv som beskrivs nedan.

OBSERVATION:

1. Det ser ut att finnas ett antagande att utifrån en eller flera PDL-loggposter kunna göra åtminstone de initiala analyser som lagen kräver, utan att behöva gå in i källsystemet. Ineras beskrivning av loggpost medger inte härledning tillbaka till källinformationen. Det som anges är tidpunkt, aktivitet, resurstyp medarbetarens och patientens identitet. Spårbarhet tillbaka till källinformationen kräver manuellt arbete och därtill vara svår att fastställa.

2. Förväntan på analyser som ska genomföras vid loggranskning kräver ingående kunskap om och direkt närhet till den aktuella verksamheten. Granskning av loggposter för PDL i med hjälp av Ineras loggtjänst kräver ytterligare informationsinhämtning enl resonemang punkt 1.

ATT UTREDA:

1. Kan loggar beskrivet för OpenEHR uppfylla de krav som ställs för att kunna loggranska PDL enl. lag?

   1. Kan dessa loggar användas oförändrat för loggranskning för PDL (se exempel på kriterier för analys nedan)?

2. Går det med OpenEHR loggar skapa upp PDL loggposter enl. Ineras RIV anvisningar?

   1. Behöver PDL-loggar enl. Ineras datadefinition skapas utifrån en samling mer detaljerade loggar från OpenEHR?

   2. Går det att skapa instruktioner för hur översättning av kodverk för Aktivitetstyp, Aktivitetsnivå och Resurstyp ska ske till aktiviteter och informationsmängder i OpenEHR?

   3. OM det är önskvärt att kunna gå från en PDL logg och spåra relevanta OpenEHR loggar, vilka rekommendation ska ges?

VGR Rutin för loggranskning SU

Nedan texter från VGR får agera exempel som beskriver vad en loggranskning kan innebära.

Texterna är hämtade från: https://alfresco.vgregion.se/alfresco/service/vgr/storage/node/content/8947/Loggranskning.pdf?a=false&guest=true

Behörighet

Den som har rätt att utdela behörighet har även en skyldighet att granska loggen. Respektive verksamhetschef ansvarar för granskningen av loggen för sina medarbetare. I de fall då verksamhetschef väljer att delegera handläggningen av loggranskning till annan medarbetare ska delegeringen vara dokumenteras.

Kontroll vid misstanke

Om det finns misstanke om missbruk av behörigheten till patientuppgifter ska en loggranskning genomföras. Det kan också finnas skäl att göra en granskning av loggen för en speciellt sekretess- känslig patient eller vårdtillfälle.

Loggranskning

• särskild händelse

• lokalt känd patient

• specifik diagnos

• vård av patient med skyddade personuppgifter

• på initiativ av patient

Vid tolkning av en logg ska följande beaktas:

• Patientrelation/uppdrag. Har patienten vårdats på aktuell enhet?

• Vilka arbetsuppgifter har medarbetaren? Är det rimligt att medarbetaren har tittat på journaler vid dessa tidpunkter?

• Finns ett namn med i loggen som kan vara av speciellt intresse, t.ex. en känd person?

• Tidpunkter, avvikande klockslag, utanför enhetens öppethållande, utanför personalens schema.

• Namn/släktskap i loggen. Åtkomst som indikerar privat samhörighet istället för patientrelation i en annan relation än vård och behandling, t.ex. anhörig, arbetskamrat eller före detta arbetskamrat

• Patient med diagnos som kan väcka särskilt intresse.

Kommentar: Här ges exempel där ytterligare informationsmängder utöver det som finns i loggposten behövs för att tolka loggposten, det kan handla om:

• Tidigare vårdkontakter

• Legitimation på medarbetaren

• Schemaläggning

• Öppettider för vårdenhet

• Information om familjerelation mellan två individer

• Kodverk för diagnoser och regler för vilka diagnoser som är “intressanta”

Loggranskning vid nödöppning och forcerad spärr

• Vid nödöppning av annan vårdgivares journal genom sammanhållen journalföring (ospärrade uppgifter).

• Vid forcering av spärr, oavsett då forcering skett med samtycke eller nödöppning.

Exempel på granskningskriterier från SALA (Systematisk Automatisk Logg Analys)

I detta utbildningsmaterial för SALA så ges ytterligare exempel på olika granskningsförfaranden för TakeCare (bild 19-23): https://alfresco-offentlig.vgregion.se/alfresco/service/vgr/storage/node/content/workspace/SpacesStore/e4bfb070-8003-4315-a52e-92da06e29e91/Åhörarmaterial SALA 191203.pdf?a=false&guest=true

• Öppnat anställds journal

• Öppnat egen journal

• Öppnat journal på patient med avvikande ålder jmf. med enhetens ålderskriterie, om sådant finns

• Patient med reservnummer

• Patienten har inte haft kontakt med enheten under de senaste 18 månaderna sedan tidigare kontakt

• Patienten har haft kontakt på enheten 3-18 månader tillbaka

• Patienten har inte haft kontakt på spärrgrupp/klinik (vårdenhet?) under de senaste 18 månaderna

• Patienten har haft kontakt med spärrgrupp/klinik (vårdenhet?) under de senaste 3-18 månaderna

• Användaren har inte skapat, sparat, signerat eller kontrasignerat dokument på aktuell patient under de senaste 18 månaderna

• osv…

Ineras format för PDL-loggar

Inera har beskrivit loggranskningstjänster i sin referensarkitektur RIV: https://rivta.se/tkview/#/domain/informationsecurity:auditing:log.

Ineras informationsmodell får anses vara en referens på vad en PDL-loggpost bör innehålla i det enklaste fallet.

Ett antal fält refererar till Ineras kodverk, en samlingssida för dem återfinns här: https://inera.atlassian.net/wiki/spaces/KINT/pages/2648506471/Kodverk+och+urval+i+de+nationella+tj+nstekontrakten

Log

Datatyp som representerar en loggpost enligt PDL. Datatypen beskriver grundformatet för en loggpost.

Fältet logId är normalt ett UUID och ska vara globalt unikt.

System

Datatyp som representerar ett system i loggposten. Det system som skapar loggposten.

Kommentar: SystemId är ett HSA-ID som logiskt identifierar en vårdapplikation. Det finns här inget som kan härleda loggen tillbaka till en specifik byggsten av en vårdapplikation, exempelvis en specifikt tjänst eller en fysisk server.

Aktivitet

Datatyp som representerar vilken typ av aktivitet som utförts, på vilken nivå, tidpunkt samt syftet med aktiviteten.

Aktivitet är på en hög nivå, det finns inget i i Ineras datastruktur som gör det möjlighet att härleda en PDL Log till en samling systemloggar som beskriver aktiviteten i källsystemet.

Aktivitetstyp kan vara följande

läsa, skriva, signera, utskrift, vidimera, radera/makulera

Aktuellt kodverk finns här: https://inera.atlassian.net/wiki/download/attachments/3615655/Kodverk inforesursaktivitetstyp.xlsx?version=2&modificationDate=1520940201822&cacheVersion=1&api=v2

Aktivitetsnivå kan vara följande

Övergripande, Övergripande inom resurstyp, Detaljerad

Syfte kan vara följande (motsvarar medarbetareuppdragets syfte)

Vård och behandling, Administration, Kvalitetssäkring, Kvalitetsregister, Annan dokumentation enligt lag, Statistik

Användare

Datatyp som representerar användaren som utfört aktivitet, tillika ägare av loggpost.

Kommentar: Assignment är namnet på ett medarbetaruppdrag. det finns inget HSA-ID som identifierar det specifika medarbetareuppdraget.

Resurs

Datatyp som representerar en resurs i loggposten. Det finns inte heller här utrymme för en referens där man från en PDL-log kan utan manuellt arbete att härleda till en specifik resurs i källsystemet som var aktuell.

Resurstyp

Exempel på resurstyper:

Finns många fler koder, aktuellt kodverk återfinns här: https://inera.atlassian.net/wiki/download/attachments/3615655/KV Informationstyp2.xlsx?version=1&modificationDate=1616135538325&cacheVersion=1&api=v2

Patient

Datatyp som representerar en patient i en resurs.

IIType beskrivs som att det kan vara olika typer av patient id. Exempelvis personnummer, reservnummer, samordningsnummer, nationellt reservnummer. Flera förekomster av patient id kan inkluderas.

Vårdgivare

Datatyp som representerar en vårdgivare.

Vårdenhet

Datatyp som representerar en vårdenhet.

Framtida och relaterat arbete

Denna version av implementationsguiden (resultat av fas 1) innehåller ännu inte delar om vårdepisod/vårdprocess/hälsoärende och styrning av åtkomst baserat på det - sådant arbete kommer sannolikt påbörjas i December 2021 (fas 2) och sedan uppdateras denna implementationsguide. En tredja fas

Föra att på ett konsekvent leverantörsoberoende sätt definiera och välja ut uppmärksamhetsinformation och aktuell läkemedelsanvändning (som ofta undantas från spärr) bör gemensam svensk förvaltning av t.ex. en uppsättning AQL-frågor och terminologiurval övervägas. Förslagsvis görs detta som en del av den nationella openEHR-förvaltningen.

En separat framtida implementationsguide för arkivering av journalhandlingar bör skrivas för att underlätta PDLs krav på långsiktigt omhändertagande av journalhandlingar. En sådan guide bör åtminstone visa hur data från openEHR-baserade journalsystem arkiveras enligt svenska krav, men om tid finns får den gärna även visa hur man kan använda openEHR-baserade system och t.ex. Integration Information Model (openehr.org) för att importera/arkivera data på ett sökbart sätt även från system som inte baseras på openEHR.

Under arbetet kom vi (orelaterat till PDL) även på att behövs.

Arbetskontext (även kopplat till hälsoärende - är medarbetaruppdrag för grovt?

Avslutning

Appendix C: Saker att ev. arbeta in i andra stycken senare

Stryk vartefter det arbetats in i andra delar. Detta appendix

Exempel på vad en vårdgivare behöver uppfylla i en openEHR-baserad plattformslösning. [Källa: Region Stockholm]

• Plattformen SKA stödja loggning av åtkomst till patientinformation i enlighet med 4 kap. 3§ Patientdatalag (2008:355)

  • Accessloggning

• Plattformen SKA stödja patientens val att spärra åtkomst till sin patientinformation i enlighet med 4 kap. 4§ Patientdatalag (2008:355)

  • Spärr, spara spärr

• Plattformen SKA stödja utvärdering av åtkomst till patientinformation i enlighet med ändamålen i 4 kap. 4§ Patientdatalag (2008:355)

  • Spärr, och utvärdering utifrån verksamhetsuppdrag (t.ex. vård och behandling vs statistik)

• Plattformen SKA stödja åtkomst till spärrad information (bryta spärr) i enlighet med 4 kap. 5§ Patientdatalag (2008:355)

  • Spärr, bryta spärr

• Plattformen SKA stödja åtkomstkontroll vid sammanhållen journalföring i enlighet med 6 kap. 2§ Patientdatalag (2008:355)

  • Samtycke

• Plattformen SKA möjliggöra att patienten motsätter sig överföring av information till kvalitetsregister i enlighet med 7 kap. 2§ Patientdatalag (2008:355)

  • Samtycke

….