Cross posted from a conversation I had with the great John G. Norman over at Iora Health's ICU Blog:
In the earliest days of ICIS (Iora's Clinical Intelligence System, our version of a medical record) planning, stakeholders and members of the product and engineering teams noticed affinities between our ideal Electronic Medical Record (EMR) system and the project planning systems used in software and design.
Q.Andrew, one of the things that interested you in Trajectory, Pivotal Tracker, and Basecamp was the ability to manage tasks. How is that important in the clinical setting, and why isn’t it such a big feature in existing EMRs?
A.A task list (or scut list) is really at the heart of medical work. When caring for a patient there are myriad things that must be done, spanning routine clinical work such as ordering labs, more complex synchronous tasks such as communications with a family member or another doctor, and synthesizing complex clinical information to determine the next iteration of diagnosis, further testing and therapy for a given issue. And these tasks are generated by multiple members of a team and assigned to multiple members of a team. Given the stresses of clinical life, the performance pressure of having a patient in front of you, and little undistracted time to do work, the more complex tasks often get shifted to later, frequently never. Chaos and distraction increase the likelihood that these tasks are forgotten. But because the work we generate needs to get done, it felt natural to me that tracking, managing and thinking about tasks was of prime importance. In other words, a task list really represents the “work” part of clinical work. If we are going to take advantage of information and networking technologies, I can’t think of a better application of those technologies to a problem so horribly flawed by paper and verbal communication.
As interns, we each kept our own self-generated lists of things to do for each patient, our scut lists. An intern’s day consists of making and checking boxes. Easy ones first, asynchronous hard ones second, and the synchronous hard ones (meetings, calls) last. This method was inherently flawed because no one could check in on my progress, see if I needed help, or lighten my load. When I delegated a task, I had few ways to verify that it was done without interrupting the person that I asked for help. One stroke of brilliance had us photocopy our paper scut lists at the end of the “rounds” when all decisions were supposedly made. This allowed everyone to at least have the same starting conditions but was barely superior to individual lists. The closest successful implementation in the physical world was a large but portable white board in an Intensive Care Unit (ICU) visible to all, edited by all and serving as a single source of truth.
It is not entirely true that tasks are absent from current EMRs, it is just that the task feature, reflecting the culture of medicine that spawned it, fails to recognize that the doctor doesn’t do everything. Other EMRs I’ve used manage tasks like a message system, where disenfranchised phone/secretarial staff can transfer work, untriaged and unstarted to the appropriate physician. As a result, the task list/inbox feature of most EMRs is amongst the most dreaded, as physicians’ days end with a long string of unprocessed work. By contrast, because we went about building our team and culture differently, our task list is (and I can say this now that I am practicing) a method of team communication, delegation and accountability. It is by no means perfect, but leaps and bounds beyond what I have seen before.
There is a more fundamental issue here, which is the notion of “magic time” in medicine. “Magic time” is the time when doctors are supposed to do all of the things they do not in front of patients, like think about clinical issues, research clinical problems, make calls to family & specialists, read and write correspondence, etc. The problem is that there are always more patients with pressing concerns, and so there never is any time without patients in front of the doctor. As a result, we promise to call/write/think/research but often fail to do so, not out of malice, but because no opportunity exists to do so. With a task list we can begin to enumerate our days work, and do crazy things like assigning time to complete each task, and begin to actually recognize when we are overloaded, rather than waiting until the walls come crumbling down around us.
It is a joke that to make it through medical school you better have a good ToDo list. There are hundreds of forms, facts, meetings, certifications, etc. that must be met just to make it to doctor, almost none of which require the intelligence, creative thinking or compassion we hope make up the core of our physicians. I confess that I am a ToDo junkie, starting with beloved Palm Desktop and have now painstakingly migrated my ToDos to a platform that is iPhone, PC, iPad, and Mac OS friendly.
Q. In engineering nowadays, we tend to work off of a single backlog of tasks, with the highest priority task at the top, with the expectation that it will get done first. In a perfect world, how are medical tasks organized?
A. In a perfect world, each member of the team (patient included) would work of a common list and do the highest priority thing that they can do at any given time. Without sounding too naïve or presumptuous, I imagine there is more fungibility in who can do what on an engineering team. However most of good primary care is paperwork and nearly anyone can do it.
Having said that, there are two major problems with what I just said. The first is that priority means different things to different people—this is not unique to medicine. Threats to life and limb usually make it to the top. But for most of office-based medicine, there are murkier things. Important tasks like “eat more vegetables” or “remember to recheck the creatinine” often get put aside in favor of more urgent tasks. Paperwork forms, especially related to employment and always due today by 5pm, medication refills on the last day of the prescription and requests from regulatory bodies always bubble to the top of the list. Much of this is our fault as a clinical team—our process to handle such requests is woefully inadequate. Some would be alleviated by advanced planning on behalf of our patients (like if they had a todo list?). However, so many problems in medicine are not caused by either party in the room, but rather the result of decisions by regulators, lawyers & payors, who seem to assume all patients and doctors are either frauds or morons, loading up lives with meaningless paperwork designed (but unable) to mitigate such putative abuse.
The second problem with the ordering of tasks is that we have more than one patient at a time. Always. Is Ms. Jones’s high blood sugar more or less of a problem than Mr. Smith’s high cholesterol? Can such a distinction even be made? Rather than looking at importance, a near impossible task even with infinite resources, we again turn to urgency as our guide. Ms. Jones is coming in tomorrow, Mr. Smith next week. Therefore, let us take care of her sugar first.
This is a long way of saying that I don’t know what an ideal task list would look like, other than visible to everyone on the team, and dynamic. Which is how we designed it for ICIS.
Q. How do you deal with information overload?
A. Caffeine, long nights, frustration, delegation, more frustration, more caffeine, refusing to do certain things (looking at you insurance company forms) and finally, redesigning primary care from the ground up.
I actually found that in my private and professional life, the ability to get everything down on one list, spend a little time researching/describing the task problem when needed, and then assigning a time, place and resources to solving the problem has positive effects on both my psyche and my productivity. In other words, I deal with information overload with a really good Task list. (Notice a theme yet?)
Q. How do you balance what is the software’s responsibility and what is the doctor’s responsibility?
A. That’s easy—in front of the patient it is always the software’s fault. More seriously, something I have learned building software is to remember that it is just words. What I mean by that is that we must have a really good description of our problem and the solutions we would like to try before committing them to software. Not to be all waterfall, as it is rare that any solution we plan will actually be the right one, but rather that if I cannot describe my process to handle a problem without software, there is no way in hell I can create software to solve my problems.
Software is good at repeatable steps, never forgetting, and churning numbers. It can either recognize patterns, or help me recognize patterns (which is a huge part of clinical decision making, and probably all of human endeavor). It doesn’t need much sleep and can be in many places at once, but cannot feed or care for itself. It also, short of Skynet, cannot learn like a doctor can. Therefore it is the job of software to do what it is good at: automate steps that require no intervention, recognize patterns when my brain cannot, forget nothing, and help display things for me so I can use my honed clinical brain.
I tell all of my students and residents on day 1 that the most important part of being on a clinical team is that you have to do what you say you are going to do. Without confident delegation, a team will grind to a halt, and melt into a dysfunctional and wasteful group. The corollary is that to be a good team member, you must raise alarm as soon as you cannot do what you said you will. I expect the same from my software. If it claims that it will warn me about drug interactions, it better do it every time. If it is going to remind me that I didn’t do something that I set out to do, it better do it every time. If it said that my prescription was delivered, it better have been delivered. And if not, it better get my attention and tell me otherwise.
The time will come when software can do more and more of the physician work. What that really means is that we have gotten really good and describing the problems we face, and how we go about finding a solution. With better ideas come better words, better words leads to better software. Part of why I like being in the software world is that I think I have pretty good words for my processes.
Posts
No comments:
Post a Comment