From Clinical Work to Clinical Productivity: It’s the Little Things…

by Jerome Carter on September 29, 2014 · 8 comments

I taught a graduate informatics course at UAB for six years.  During that time, one piece of advice I always gave students was, “solve problems and you will always be in demand.”   Now, most go after the big problems: cancer, diabetes, food shortages, poverty, etc. because fame, and possibly fortune awaits the brilliant people who solve them.    However, when looking back over the history of human progress, one thing that becomes obvious is that solving seemingly small problems also offers significant rewards–if not much in the way of celebrity.

Small problems are important because everyone has them.  Cancer is a big problem, the common cold, a small one.  Solving a problem that everyone has brings little in the way of notoriety because it really does not seem to be much of an achievement.  Most people, without fanfare, simply incorporate the solution into their everyday routines and keep moving.

My first car was a used 1968 Impala that cost $625.00.  Driving through drizzling rain meant hitting the windshield wipers every few minutes, waiting for the view to get blurred again, and then hitting the wipers once more.  Tedious–not life threatening, but very irritating.  Intermittent windshield wipers are my favorite example of a solution to a small problem.  Unlike misery, which is the result of a big problem, irritation is something that lasts for only a few moments and then disappears until the next time.  Irritation is an out-of-sight-out-of-mind type of thing, which is why little problems get so little respect.

The path to solving a problem begins once it is recognized as being worth solving.  For big problems, this is easy—misery is usually obvious.  Small problems, however, are considered to be just part of life.  They provide us with something to bemoan–briefly–under our breaths, but we just deal with them.

My ruminations on small problems began this morning when I was trying to figure out the best way to water my garden.  There is no good way to avoid wasting water with the equipment I have.  After giving it a few minutes serious thought, I gave up, deciding my time was better spent elsewhere.   It’s a small problem…

My time in primary care was filled with small problems that I cursed on a regular basis.   At the time, I shrugged off those irritants as being part of practicing medicine.  After all, others had the same or similar problems.    Now here is the big question: Were all of these irritants simply part of practicing medicine or were they solvable small problems that, once addressed, would make life better for all?

Asking this question has led to what I will call the “Theory of EHR Complaints.”    It goes something like this…   Paper charts were just part of practicing medicine. We got used to them.  EHR systems showed up and they solved some of the small problems peculiar to paper records: lost charts, bad writing, lack of remote access, no search capability, etc.  Even though we had made our peace with papers charts, we welcomed the solutions to these problems.

Now that EHR use has increased and MU is upon us, there are complaints about data entry, note readability, data quality, user interfaces, workflow disruptions and workarounds.   These are new small problems.  They grow out of EHR design, and are added to the problems of everyday practice (i.e., clinical work) that already existed.

All of the things that I mumbled about under my breath every day, that kept me awake at night, that made me have to go into the office on Sunday to look at a chart—I never documented them.  I did not keep a list. I never expected anyone to address them because, well…they were just part of practicing medicine.  The recent articles by Sinsky (1), Krist (2) on EHR support for primary care are the first of what I hope are the start of an ongoing effort to document the small problems common to clinical practice.

EHR systems are not the sole source of problems.  Some they create, others they exacerbate, and yet others they make obvious for the first time (e.g., the need for better collaboration tools).  Addressing problems through better EHR designs cannot be done piecemeal.  It requires a holistic view of clinical work that can be modeled and then used as a basis for EHR design.  EHR systems are trying to assist with clinical work without ever having had a model of clinical work or a notion of the small problems of clinical care.

Since we are inured to small problems, it is difficult to mount a campaign to address them.  Doing so may even seem like whining at times.   They do not show up in surveys and feature-request lists because they are “just part of practicing medicine.”   Acceptance of small problems as part of life may well be the reason that asking people what they want in a piece of software usually results in requests for help with big problems.  Watching them work and listening to their complaints is how small problems are uncovered.

Here are a few examples of small problems I cursed every day.

Tracking results — once, within a single week, I had six or seven male patients whose routine urinalyses were positive for blood.   This resulted in chart pulls and calls to the lab to see if they had noticed an unusual spike in hematuria readings (hoping for lab error).   Eventually, I created a spreadsheet to track follow-ups and referrals for the group.  The spreadsheet was on my desktop computer, which meant I could not access it in the clinic.   Printing it did not help.

Tracking an abnormal result is not simply about that specific result but also every interaction between doctor, patient, consultants, family, and facilities until the problem is solved.  The spreadsheet helped, but I think something more akin to air traffic control software would have been better.

Interacting with patients – like most doctors, I had patients who would call about a broken nail and those who would only call if they were actively bleeding from their eyes.   Early in my career I found that if the first group knew it was easy to contact me, they often calmed down a lot. The second group I tried to contact personally between visits.   Of course, I came up with ways of managing my interactions, but I was never satisfied with the solutions.

Managing care plans – patients with chronic conditions require a lot of oversight.  I had one patient with both asthma (frequently requiring oral steroids) and diabetes who required constant oversight.   It would have been nice to have had access to a timeline view of pertinent data when making decisions.

Everyone who takes care of patients has their list, though very likely the list has never been shared.  Studies of workarounds and workflow disruptions add to the list( 3, 4).  Turning these lists into software features and user interface designs takes imagination and insight.  It is worth remembering that requirements, no matter how detailed, are only wishes until someone figures out how to turn them into usable software.

Clinical productivity, at some level,  is a measure of the degree to which the small problems encountered day-in and day-out are handled efficiently and effectively.  Providing assistance for clinical work requires uncovering and addressing small problems. And modeling clinical work is an absolute requirement for building systems that intimately support clinical care.

Solutions to big problems are met with applause and awards.  However, providing solutions for small problems offers rewards as well–better patient care and less frazzled clinical professionals are very good things.  I have long since forgotten the name of the guy who invented intermittent windshield wipers, but I do remember that he was awarded over $100 million for his efforts…

  1. Sinsky CA, Beasley JW, Simmons GE, Baron RJ. Electronic health records: design, implementation, and policy for higher-value primary care. Ann Intern Med. 2014 May 20;160(10):727-8.
  2. Krist AH, Beasley JW, Crosson JC, Kibbe DC, et al. Electronic health record functionality needed to better support primary care. J Am Med Inform Assoc. 2014 Jan 15. [E]
  3. Friedman A, Crosson JC, Howard J, Clark EC, Pellerano M, Karsh BT, Crabtree B, Jaén CR, Cohen DJ. A typology of electronic health record workarounds in small-to-medium size primary care practices. J Am Med Inform Assoc. 2013 Jul 31.[E]
  4. Flanagan ME, Saleem JJ, Millitello LG, Russ AL, Doebbeling BN. Paper- and computer-based workarounds to electronic health record use at three benchmark institutions. J Am Med Inform Assoc. 2013 Mar 14. [E]
Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 8 comments… read them below or add one }

jim ryan October 6, 2014 at 10:09 AM

great article, as a practicing family doc i feel the same way. my question is when do we begin to implement a process to resolve and evolve our way through these issues. i’ve been in practice for 5 years and used to write my own software for multimedia performance, and when i started to practice had planned on being creative with the software i use, clearly i was naive. i ultimately had to go independent to have the latitude to make and develop software, and explore systems that are based on the clinical work flow. i have come up with some ideas and am actively testing prototypes, the point is that is should not have been such a complicated path. i reached out to the software company that i was using initially (EPIC), i wanted no money, only to be involved in improvement, they threw me a token title without any meaningful input. we physicians and out patients ideally need true research clinics, ultimately supported and integrated into our medical schools. nodes where novel architectural models can be explored, and the knowledge shared. i have reached out to several medical schools, met with deans, they all agree, but change is not occurring. we need SOME kind of network to support us explorers, who have to deal with the realities of managing a real practice as well as exploring software. i agree with the naming of problems, but we need to work practically on their solutions.
do you have any advice on how someone like myself might move forward? thanks.

Reply

Jerome Carter October 7, 2014 at 3:14 PM

Jim, thanks for your comment. Over the years, I have run into problems similar to what you describe in getting companies or organizations to try new methods. My time at UAB was a wonderful exception. Keep in mind that new ideas and new ways of doing things are rarely welcomed with open arms. Visionary leaders who see the future and who are willing to support truly different approaches are few and far between.

It would be wonderful to have true informatics labs as in every medical center where one could explore design, workflow and other ideas, but that is not likely to happen, as you have learned. In addition, there are no outlets for discussing clinical software design on a scientific or professional level. Blogs are one of the outlets that allow those of us with an interest in software engineering, mathematics, clinical care, etc. to exchange ideas, algorithms, techniques, and tools. EHR Science exists because of my desire to find others who are interested in the nuts and bolts of creating software that supports clinical care.

The number of clinical professionals who are sufficiently interested in software design to the point where they would learn OOA&D, software patterns, graph theory, workflow patterns, and a development stack is quite small, though it does seem to be growing. The forum will return to EHR Science soon to promote discussion. But I really wish an Association for Clinical Computing existed that would give all of us informatics geeks a place to interact.

Of course, another avenue would be to stop trying to convince anyone that an idea is workable or worth trying and build something to prove the point. One thing I really like about Apple’s ecosystem is that it provides a way to create and distribute professional software with a minimum of hassle. Automatic data encryption plus Healthkit is a winning combo for me.

I am definitely going to try to build some clinical informatics apps for OS X/iOS, and I am open to an organization for informatics geeks as well.

Reply

jim ryan October 7, 2014 at 9:20 PM

i’m glad i found your blog Jerome.
“It would be wonderful to have true informatics labs as in every medical center where one could explore design, workflow and other ideas, but that is not likely to happen, as you have learned.”
why do you think this is?

Reply

Jerome Carter October 7, 2014 at 10:04 PM

Why? Software development is not given the same intellectual status as writing papers and doing other types of research. I think too many people have the idea that software is easy to write and all that is required is that one hire enough programmers. Some of this is due to the “Visual Basic” effect which is a perception that tying a front-end form to a back end database is what programming consists of mainly. A large number of enterprise applications fit this description, so much so, that many would deny that programming is math. That software engineering is a real field with PhD level degrees goes unappreciated.

There also seems to be a mindset that all one needs to do to get better software is give a group of programmers a set of requirements. This can be seen in the growing demand that software vendors build better systems–the assumption being that designing sophisticated clinical care system is relatively straightforward.

Of course, the opposite is true. No one knows the best interface for clinical work, or the key data structures needed to best represent computable concepts, or the algorithms required to do decision support, quality monitoring or allow for adaptive clinical workflows. These are all research areas that must be tested experimentally in software designs. Failure to appreciate the amount of research and creativity required to produce good software is why more informatics labs do not exist.

Reply

jim ryan October 12, 2014 at 6:57 PM

well said, i agree with the above, and would add with the affordable health care act so soon behind the first waves of MU money both the insurance, and emr companies are scrambling to manage rapid growth leading to quantity over quality. but yet us explorers must explore, and stay true to our nature. are there any particular journals that might support formation of informatics labs?

BobbyG October 3, 2014 at 1:55 PM

Cited you on my blog again. Blog.KHIT.org

Reply

Jerome Carter October 3, 2014 at 2:33 PM

Thanks for the mention!

Reply

Jerome Carter October 12, 2014 at 9:17 PM

How would a journal offer support? One place where detailed discussions of clinical systems design is welcomed is the IEEE yearly health informatics conference. Aside from that, there is little of this nature published in mainstream informatics journals. now I am beginning to wonder is the absence means such articles are unwelcome or that very few are being submitted for whatever reason. Hmmm…

Reply

Previous post:

Next post: