Q.E.D. – recept

Receptförskrivning1 är lite annorlunda och lite mer komplicerat. Vissa element vill vi att systemet lär sig i kontexten “kontaktorsak” eller “bedömning”. Andra element vill vi ta från en mer grundläggande källa. Jag tar elementen en för en.

Recept översikt
Översikt befintliga recept.

Produkt

Valet av produkten kan med stor fördel göras på samma självlärande sätt som vi sett tidigare för de flesta andra delar av journalen. Nämligen att om man tidigare ordinerat Levaxin för patienter med kontaktorsaken “hypothyreos uppföljning” eller bedömningen “hypothyreos”, då är det lämpligt att föreslå samma produkt nästa gång man har en patient med samma kontaktorsak eller bedömning.

Förval.
Förval beroende på bedömningarna.

Dosering

Doseringsinformationen däremot lämpar sig inte för samma mekanism. Om jag ger en patient 50 mikrogram Levaxin per dag så är det inget skäl att tro att det är rätt dos för en annan patient. Här bör man plocka upp doseringsrekommendationer från en läkemedelsdatabas. Ser man till Kåvepenin2 t.ex., så bestäms dosen av patientens ålder och/eller vikt, samt av indikationen, dvs skälet till förskrivningen. Dosen är olika om man behandlar tonsillit, öroninfektion, hudinfektion eller borrelia. Men eftersom Q.E.D. faktiskt har den informationen (kontaktorsak eller bedömning, plus patientens ålder och kanske vikt) så kan systemet plocka upp rätt doseringstabell och föreslå den.

Övriga fält.
Dosering och instruktioner baseras på förval och läkemedelsdatabasen.

Instruktioner

Vid varje ordination skriver vi instruktioner i ett fält. Typexempel är “5 dagar behandling. Mot öroninfektion.” Det instruktionsfältet kan vara inlärt av Q.E.D. precis som de flesta andra element. Det underlättar för läkaren att det kan göras automatiskt.

Kontraindikationer

Det här är något nytt, men oerhört nödvändigt. De flesta system kan ju varna för interaktioner mellan läkemedel, men inget system3 varnar för kontraindikationer, vilket är mycket viktigare. Till exempel att vissa antibiotika inte bör ges till patienter med vissa njurproblem, eller vissa antiallergiska produkter till patienter med vissa hjärtproblem. Enligt min beskedliga mening händer alldeles för många olyckor där man inte sett att kontraindikationen fanns.

Uppgifter om kontraindikationer finns i FASS, men jag tror de inte finns i alla läkemedelsdatabaser4, vilket de naturligtvis borde göra. Om de gjorde det, kunde Q.E.D. matcha alla tidigare kontaktorsaker och bedömningar mot kontraindikationer och direkt varna för möjliga problem.

Multipla bedömningar

När en patient har mer än en bedömning under ett besök eller kontakt, så kan det ibland hända att samma produkt möjligen förskrivs för båda bedömningar. Tänk t.ex. en patient med borrelia och sinuit5. I det fallet kommer systemet vid ordinationen att fråga användaren vilken indikation det används för, för att kunna ge rätt val av dosering och instruktionstext.

Om användaren skriver ut ett preparat som inte tidigare använts för någon av bedömningarna (i fallet multipla bedömningar) och alltså inte finns i förvalen, så bör systemet inte bevara det för att presentera det som förval vid en annan patientkontakt, eftersom det  lätt blir fel. Systemet kan ju inte veta varför det skrevs ut i det fallet, vilken bedömning som var grunden till ordinationen6. Med andra ord bör systemet bara lära sig nya ordinationer i de patientkontakter där det bara finns en enda kontaktorsak eller bedömning. Men systemet kan naturligtvis presentera inlärda ordinationer även i de fall det finns flera bedömningar.

  1. Eller “ordination”. I den här diskussionen gör det inte mycket skillnad.
  2. Levaxin har ett brett område av doseringar som bestäms av det individuella patientfallet, så jag byter till Kåvepenin för exemplet.
  3. Som jag har sett i alla fall.
  4. Av något skäl jag inte känner till.
  5. Nej, det händer inte ofta.
  6. Jo, man kan ju fråga användaren, men jag tror inte det är värt komplikationen. Vår första princip bör vara att inte göra systemet mer invecklat att använda än absolut nödvändigt.

3 thoughts on “Q.E.D. – recept”

  1. 1. Vid förskrivning av vissa recept, tex Levaxin vid kontaktorsaken hypotyreos, bör systemet då kontrollera om tyreoideaprover är tagna inom en rimlig tid bakåt? Ska det kontrollen i så fall vara kopplad till läkemedlet eller kontakorsaken? För Levaxin kanske till kontaktorsaken? Men för andra preparat kanske till läkemedlet? Ex om man står på Metformin och vill kontrollera kobalaminstatus vartannat år. Ska man för kontaktorsaker/preparat ställa in rimliga intervall för uppföljning, eller ska systemet lära sig det själv?
    2. Bör man dela upp kontraindikationskontrollen i flera delar? Delar av det du efterfrågar tror jag det finns stöd för i befintliga databaser. Graviditet, amning, mindre lämpliga läkemedel till äldre, rimlighetskontroller av doser till barn (EPED), njurfunktion (NJUREN hos SLL), kön (janusmed). Man kommer inte åt samtliga kontraindikationer, har inte heller sett någon databas för det.
    3. Önskar en förbättrad interaktionskontroll än den som finns idag. Dels borde systemet varna vid utsättning av preparat, om det kan störa “balansen” som är parerad pga interaktion vid insättningen. Dels borde systemet prioritera upp eller ner varningar baserat på information i journalen. Tex varningen för Trombyl – Citalopram och blödningsrisk kunde kontrollera mot aktuellt Hb-värde. Har inte sett detta i Sverige, men hört talas om det på ett sjukhus i Belgien tror jag det var.
    4. Hur kan man hjälpa användaren när det kommer nya rön och studier om behandling? Tex att man rekommenderar Trombyl 75 mg istället för Trombyl 160 mg? Hur får man stöd för att minska förnyelser av recept slentrianmässigt?
    5. Önskar en Läkemedelsgenomgångs-kontroll, där man kunde utnyttja reglerna och stödet man byggt in för att när som helst med en knapptryckning få upp från systemet relevanta frågeställningar att ta ställning till.

    1. Johan,

      1. I min bok beskrev jag ett annat betydligt ambitiösare system (iotaMed) som skulle kunna klara av den kontrollen genom att ha den specificerad i en “item” i mallen för hypotyreos. Q.E.D. är ett mycket enklare system som inte skulle ha den möjligheten, men jag har tänkt Q.E.D. som en inkörsport där de mer avancerade funktionerna i iotaMed kan läggas till vartefter. De kompletterar varandra. Men redan i Q.E.D. kommer systemet att föreslå TSH, T4, etc när man har en patient för uppföljning av hypotyreos, men det har inte funktionen för kontroll av tidsintervall. Vad man däremot kan göra är att lägga in kommentarer vid provförslagen där man säger att det bör göras vartannat år, t.ex.

      2. Javisst kan man hämta kontraindikationer på mer än ett vis. Man visar dem nog bäst på ett enhetligt sätt, däremot. Men som du säger, det verkar inte finnas i databaser, trots att det mesta finns i FASS.

      3. Ja, absolut. Men det är också något som passar mycket bättre i iotaMed än i Q.E.D. I iotaMed styrs ju rekommendationerna av en för problemet specifik mall som kan innehålla villkor och beräkningar också.

      4. Den här var lätt :). Man kan lägga in rekommendationer direkt i Q.E.D. istället för att vänta på att användare lär systemet. Man kan också lägga in kommentarer som avråder när man använder en viss behandling.

      5. En läkemedelsgenomgång lämpar sig nog också bäst för iotaMed. Det skulle kunna göras som “issue template” och därmed också lätt kunna anpassas för olika regioner och lätt och snabbt uppdateras utan programmering när nya råd kommer ut.

      iotaMed vs. Q.E.D.: iotaMed kräver, för att vara nyttigt, att man ställt upp “issue templates” för de vanligaste kontaktorsaker/problem, men har breda möjligheter att reagera på patientens data i olika sammanhang. För att göra det lätt att underhålla så är skapandet och underhållet av dessa templates distribuerat, dvs läkare själva, eller avdelningar, eller regioner, kan bidra med templates. Q.E.D. å andra sidan är ämnat att med ett absolut minimum av konfiguration och underhåll fånga lågt hängande frukt och att befordra bra vanor, “best practices”, hos läkaren samt sprida dessa bra vanor i gruppen. Det är också tänkt att vara lätt att tillfoga iotaMed funktioner till det när det väl visat sig fungera i praktiken. Och jag tror att andra, precis som du, börjar tänka vidare på allt man kan göra när basen är införd i form av Q.E.D. Men den basen måste nog smygas in först.

Leave a Reply

Your email address will not be published. Required fields are marked *