Att fylla i sjukintyg för Försäkringskassan är nog bland det jobbigaste administrativa jobbet vi har som läkare. Det är rätt mycket att skriva och det är svårt att formulera sig snabbt och precist. Det är dessutom svårt att tolka in vad man ska skriva som “aktivitetsbegränsning”, vilket är det FK baserar sig på mest. Har man en snygg formulering för en typ av fall så vill man gärna återanvända den, i synnerhet som funktionsnedsättning och aktivitetsbegränsning inte varierar så mycket mellan olika patienter med samma problem.
Q.E.D. – utgående remiss
När man skapar remisser i ett journalsystem så är det tämligen stereotypt, dvs det är bara ett relativt begränsat antal olika remisser man normalt skickar för en viss typ av patient. Så vi kan låta systemet lära sig vilka remisser vi ofta använder för en viss kontaktorsak (problem).
Q.E.D. – mallar
Mallar1 är ett problem. De flesta journalsystem tillåter olika mallar som användaren väljer och ofta finner man (i allmänmedicin) mallar som “allmänt”, “diabetes årsbesök” och kanske i ambitiösa fall olika för körkortsintyg m.m. Problemet med dessa mallar är att om det finns för få, eller bara en, så kommer den att ha alldeles för många “sökord” (undertitlar) och bli jobbig att använda eftersom majoriteten av sökorden inte kommer att användas. Finns det mer riktade mallar så har man två andra problem: hitta rätt mall2, samt att en smalare mall ofta saknar just ett eller annat sökord man vill använda. Vissa system tillåter att varje användare skapar sina egna mallar, andra tillåter det inte. I vilket fall som helst är det uppenbart för de flesta att vill man få ut något av systemet så krävs mycket konfiguration inför uppstart och intensivt underhåll efter det. Vilket ingen gör.
Q.E.D. – sökningar
När man har en patient framför sig är det nästan alltid nyttigt att söka efter och använda referensmaterial. Det kan vara riktlinjer och vårdprogram från den egna institutionen, från landstingen, eller från vettiga sites på nätet, som Mayo Clinic, Medline, etc. Problemet idag är att man först och främst behöver veta var man ska leta (vilka sites som är “vettiga”) och vilka sökord som är lämpliga. När man väl har funnit något riktigt användbart så har man i allmänhet inget sätt att spara fyndet vare sig i patientens anteckningar1 eller i journalsystemet för användaren. Problemet blir ju hur man skulle sortera och länka dessa länkar, men med Q.E.D. finns en snygg lösning. Continue reading Q.E.D. – sökningar
Q.E.D.
I förra inlägget talade jag om de tre nivåerna inom medicinsk kunskap och om att det mest produktiva området för framtida utveckling av journalsystem antagligen är i nivå 2 (enligt min indelning i tre nivåer).
Som exempel på ett renodlat verktyg i nivå 2 gav jag en presentation av ett fiktivt system jag kallade Q.E.D. i brist på bättre. (Det spelar mindre roll vem jag gav presentationen till, men här är den i alla fall.) Continue reading Q.E.D.
Watson igen?
(Jag skrev det här som ett inlägg på SFAM forumet, så det är lite i svarsstil.)
Jag tror det är ett misstag att bedöma IT i vårdsituationer utifrån Watson. Watson fyller en viss speciell funktion (om det funkade) som inte konkurrerar med vad vi gör dagligdags. Min bild av hur “medicin” ser ut, sett ur ett kunskapsprocess perspektiv är att det handlar om tre nivåer:
1. Ren kunskap om biologin och patologin, typ EBM, epidemiologi, m.m. I princip inte individuellt patientorienterat.
2. Tillämpning och anpassning (implementering) av ren kunskap i det individuella patientfallet.
3. Kännedom om patientens egenskaper, mätvärden, tidigare tillämpade diagnostiska medel och behandlingar.
Du sköna nya diabetesfria värld
Det låter ju smutt att med “big data” förekomma diabetes.
Förutsatt att man kan förhindra diabetes om man bara är förvarnad förstås. Vilket var en nyhet för mig. Men det kanske går om hela samhället hjälps åt.
Läkarstressens grunder
Läkare är stressade. Många, alltför många, går in i väggen eller blir utbrända (beroende på definition). Är det för att vi jobbar för många timmar? Nej, det finns många andra yrken som jobbar fler timmar och har mindre problem. Är det för att vi inte trivs med jobbet? Nej, det tror jag knappast. De flesta vill nog inte byta yrke. Är vi underbetalda? Knappast det heller.
Ofta ser man tolkningar där orsaken skulle vara att vi läkare inte har tillräcklig kontroll över våra egna arbetsuppgifter, men det har man inte i andra yrken heller. Vi har nog mer kontroll än de flesta. Så vad är problemet, då? Jag kan inte tala för andra, men jag kan introspektera lite grann och reflektera över vad som stressat och frustrerat mig själv över åren (jag har varit läkare nu i 37 år). Den gemensamma nämnaren som jag funnit det har alltid varit osäkerheten. Osäkerheten om man gör ett bra jobb, känslan av att inte kunna tillräckligt och att ha missat något viktigt.
Kontinuitetens underliggande resonemang
Debattartikel i SVD om kontinuiteten i vården. Det författaren argumenterar för är behjärtansvärt. Antagligen. Men varför är vi så övertygade om att kontinuiteten är något positivt? Antagligen är den det, men argumenteringen håller inte. Det behöver tänkas över lite bättre.
Systemens överlevnad
Det finns två tydliga spår vad gäller framtidens vårdsystem. Båda spåren följs samtidigt inom landstingen, t.o.m. inom samma landsting. I SLL följer man spåret mot nästa gigantiska monolit i 3R projektet, medan man följer det rakt motsatta spåret i HIP projektet. Som jag förstått slåss man också internt mot varandra för budget och erkännande.
Våra lokala “små” journalsystemsleverantörer som Cambio och Take Care hotas i princip med utrotning om 3R projektet skulle välja ett annat system typ Epic, eftersom de skulle bytas ut och egentligen inte ha någon relevant marknad över i Sverige. Så det förefaller självklart att de skulle stödja HIP initiativet, men det verkar de inte göra heller.
HIP initiativet innebär att befintliga system öppnar upp sig för interaktion med ett antal mindre, specialiserade, moduler på ett standardiserat sätt. Det gör ju att man kan bygga vidare på vad man redan har och att nuvarande system blir en stomme, en backbone, för framtidens journalsystem.
Men tydligen vill man inte det. Man vill inte släppa den minsta lilla funktion i systemen till andra. Det här kommer inte bara att betyda deras undergång, men kommer också att betyda att vi i framtiden har precis lika monolitiska och rigida system som idag, med enda skillnad att de nu är amerikanska.