Planning in the Clinic (Part 2 of 2)

Part 2 of 2 

(for part 1, see http://icu.iorahealth.com/blog/2012/05/10/planning-in-the-clinic-1-of-2/)

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. You’ve taken a special interest in gaming in medical software innovation. Where is that going to take us?

A. At the guidance of our awesome product manager, Jess Kadar, I have been reading Jane McGonigal’s book Reality is Broken. Everyone should read it (parent, doctor, gamer, non-gamer, patient …) because it portends the future. Much of my thinking about why I like games comes from her work and her collection of other’s work. Gaming is defined as voluntarily overcoming unnecessary obstacles. Involuntarily overcoming necessary obstacles is called work.

The key then is to overcoming the drudgery of health care by making the work of health care fun. One of the best ways of doing this is socializing our health work. Whether through competition, leader boards, bragging, sharing, storytelling or just keeping each other up to date, there is tremendous power in games. We borrow this from Counterstrike and TF2 and Starcraft. However, what mostly fails is that the underlying game mechanics – taking pills, seeing doctors, getting mammograms – are not only not fun, but highly unpleasant. Starcraft was fun before it became the national sport of Korea. One could argue that repeatedly clicking buttons is not fun, but that is an oversimplification on what makes games games.

I think health care gaming is in its infancy because it is hard to design a game to motivate you to do something that you should already be motivated to do. Who doesn’t want to be in shape and healthy? And yet so few of us are. To try and solve that problem, early health game designers have given away a chance to win an iPad, or a trip to Aruba, or points towards purchases, effectively paying people via games to be helpful. While I think there are important ties between financial and health motivation (mostly that we give up our health for money in the form of poor/quick eating, deferred exercise and missed sleep), these games miss something important. Perhaps, getting back to the social nature of gaming, we need to reward people for getting each other healthy. I might eat a doughnut instead of winning game points, but there is no way in hell I am going to let you eat a doughnut instead of me winning game points.

Another component of non-medical games is that they are amazing at interface design. Many applications just have awful design, making you bend to the will of the designer. Not games. There is no other medium I can think of that so seamlessly sends so much data the way of the user, and has the user begging for more. There are plenty of games with bad interfaces, usually crowding the dustbins of Targets and Walmarts: I just cannot remember playing them (for very long). Contrast this with most medical software, which is just atrocious. I feel like EMR designers secretly hate doctors and wish to torture them, one check box click at a time. There is no way a game would be seriously released (and purchased!) in the sad interface state of so much medical software.

As a disclaimer I have always loved games. Since ColecoVision all the way through modern PC gaming, coming of age during the golden age of SNES RPGs, family board games (the brutal national sport of the Schutzbank household), endless chess matches with my dad (I only have 4 wins in ~26 years), pinball, etc., I have been hooked. I love the meditative state I enter while playing, the opportunity to overcome challenges, experience a story, improve skill, spend active time together with others and simply kick ass.

Q. In the O’Malley, et al., article “Are Electronic Medical Records Helpful for Care Coordination?” the authors write, “realizing EMRs’ potential for facilitating coordination requires evolution of practice operational processes” (Center for Studying Health System Change, 22 Dec. 2009). That’s a big claim. What do you think?

A. To quote Jess Kadar again: “You cannot create software to do your job for you. To write software to solve a problem, you have to know how to solve the problem.” Doctors are pretty bad at care coordination. Non-docs are even worse. Why would we think that people who either don’t coordinate care, or do it poorly, would be able to write software that makes it easy? Good words describing good processes precede good software. We have none of the above. How do you know? Just ask 4 doctors what care coordination is and expect 6 answers.

Q. They also claim “current fee-for-service reimbursement encourages EMR use for documentation of billable events (office visits, procedures) and not of care coordination (which is not a billable activity).” Can you describe some concrete cases where the EMR’s provision for what is billable has resulted in information loss in care coordination?

A. Every time something is documented? That is probably a glib answer to a serious question. Docs started writing notes to document interactions with patients, to communicate the day’s meeting to colleagues, future selves and lawyers. Not terrible, but patients undergo diseases and care continuously. We have hard-coded a discrete method for dealing with continuous problems. Unfortunately the note is just not good enough of technology to handle reality.

Writing a note in a modern EMR is actually a game! Like a perverse version of high stakes Yahtzee, I have to satisfy a number of categories in a number of columns to increase my note score ($). This results in multiple ways of cheating the game – check boxes, templates, copy/pasted text carried from previous notes, words/sentences added as flourish like “All other Review of Systems negative” to score points in the game the easy way. Not that we didn’t do the work, but it is hard enough to ask all of the damn questions, then write down that you did, then write down the answers, then try and make any sense of it. This really is not EMRs fault, it is actually the fault of regulators/payors abstracting what was once a research tool (the E&M code sheet) and turning into a torture device. I will try and withhold my comments on top-down bureaucratized medicine, but the billing sheet is a perfect example.

Care coordination is all about finesse. Calling a patient twice. Emailing a doctor buddy to get someone in earlier. Recognizing just after the patient left that what you just explained did not register with them despite their assurances, or even worse, remember to do something extra. Care coordination is about communication, influence, relationship building, trust and follow through. It is really hard to build software to do that, only to support the human activity. The more I think about medical records, they are ideally a great combination of a CRM and Project management tool—where each patient is both a client and a project.

Q. Andrew, thanks. And game on!

Posted by Andrew Schutzbank and John G. Norman

Planning in the Clinic (Part 1 of 2)

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.

Coming Friday, May 18: Part 2 of 2 (thoughts on gaming, operations, and billing)