What I Wish I’d Known Before … Working with Doctors on Technology Projects

I wish I had known that once I crossed the line to help IT that I would be an IT person and no longer viewed as a credible physician. My former peers became dismissive of my opinions, coming up with a variety of reasons — I hadn’t been in practice as long as them, I no longer saw as many patients as them, I wasn’t in a procedural specialty, etc. Looking back on their behavior, it was bullying, plain and simple.

How often one person can derail an entire initiative regardless of the validity of the reasoning.

I wish I had known the depth of ignorance on both sides of the tech / physician engagement. Be it the languages used, the ability to decipher thoughts and requirements, the ability to say, “No, not that, but maybe this.” I wish there was more empathy on both sides of the house and more diligence in learning from each side.

From the tech side, realizing that the doc/nurse in front of you has a job to do that isn’t to interact with the computer. That our tech needs to make it easier to do that job and not harder. That clinicians have trained very hard to get where they are and that it is appropriate to ask the “why” question so you can learn from their experience — and by asking why your product will be better suited to the task and use. That when the tech side makes assumptions they need to validate those assumptions against the clinicians experience. And, that the clinical roles are not all the same — learn the workflows of the roles under development.

For the doctors, realizing that customization is expensive across the development life cycle — almost as expensive as flexibility. That there is a need to be prescriptive while still being flexible. That you should call out bad design and usability, but show them how you want to use the system. Use your active listening skills to ensure that they understand what you are conveying. Realize that we don’t hate you and aren’t trying to kill your patients or ruin your practice — even if it feels like that at times

For both, that there is a need to exchange the data, information, knowledge, and wisdom that is the potential of electronic health records. Think about how your suggestions and decisions will impact analytics, research, and semantic exchange.

Lastly, maybe walking a mile or six in the other guy’s shoes wouldn’t hurt as long as you don’t get to thinking a little experience gives you great competence (e.g. the Dunning-Kruger effect).

A savvy physician who understands IT and the challenges we face and yet holds us accountable is the most powerful and effective program sponsor I have ever had. This physician leader, who practiced emergency medicine, pushed and led our IT organization to achievements we didn’t think were possible. He provided air cover to the program with physician colleagues across the organization. He had built trust with that community over decades of steady delivery of IT-related projects that met the needs of the physician community without incorporating the latest shiny thing. His participation was invaluable. I have seen few like him, but he was worth his weight in platinum.

I wish I’d known just how many of them would tell me “I took some programming classes in college” and would then proceed to inform me how an application should be built. Cool story, doc. I took a CPR class once, so let me tell you how to treat pulmonary hypertension.

I have also worked with some great physicians who were really open to the discovery process, and in my non-scientific sampling, the ones most tolerant of unexpected or undesired behavior were primary care physicians and the least-tolerant were orthopedic specialists. I’m not sure which way causality runs, but physicians whose entire job function is the human narrative and who trade in identifying root cause from a flood of poorly-described symptoms are way more amenable to testing things out and trying them in an unfinished state than people whose entire job is fixing an already-defined problem.

The vendor is going to have its own idea of how the software implementation plan should go and this will likely include a recommendation for staff, including doctors, to watch some videos and maybe do some reading before the vendor staff show up at the office. However, the doctors will most likely NOT do this and that changes much. Never did figure out why a doc would spend many thousands of dollars on a system and not take the vendor’s suggestion. This most often leads to a planned failure or less than successful launch and more down the road issues and the aforementioned tantrums and bad-mouthing of the vendor (couldn’t be the doctor’s fault, right?)

Maybe a possible solution would be to have the doctor sign a contract outlining the vendor recommendation to study up before go-live and an agreement to pay extra for on-site staffing when things go bad if they don’t do the pre-study.

Doctors usually want to buy a system that is totally customized to their workflow and uniqueness (think lots of $$$$$) but pay for a “one size fits all” commodity software (think much less $$).

Some docs still think they can work a full day of patients and have a successful go-live.

That there are many more physicians who are helpful and positive than those that are negative and resistant. It is just that the resistant ones make a lot more noise, commotion, and are experts at getting attention. It takes strong organizational leadership and the willingness to put some teeth into the medical bylaws to hold the resistant physicians accountable for their negative actions.

Maybe to be a little more appreciative. Looking back, some of the best projects I’d worked on. A chief pathologist who never missed a project meeting, gave a personal number for emergencies, and taught us all about lab billing. Another chief pathologist who validated an ancient AP system conversion, patiently looking side by side, old and new, checking every procedure type. In the end, 25 years of data converted, no errors. An anesthesiologist who remained obstinate through an entire Lean event, pushing the team to the edge of insanity, then led the implementation and blew down barriers in the department we did not know existed. Many other great memories of physicians who were not only generous with their time but were also key contributors.

I wish that I had known that doctors are flawless beings incapable of making a mistake and that an EMR will not work and do the same task a dozen different ways every time a doctor interacts with it.

The pervasive power of delayed adolescence fused with authority, enabled by administrative leadership complicity and medical leadership effeteness.

Every doctor I’ve worked with will not admit upfront to ignorance about system capabilities or their lack of knowledge about software in general. Why would they? Start new projects with level-setting demonstrations about what your system can do (or will soon be able to do). Physicians will react to what they see presented and offer specific insights rather than speaking in generalities.

Understand your audience. Understand what the physicians and other providers want to get out of the system. Frame your language in a way that they can understand what you’re saying. I’ve seen too many people jump into wonky language when describing projects, systems, or configurations. If they don’t understand you, they will assume the worst. And then it will be much more difficult to convince them to change anything.

Practicing medicine is an art, not only a science, so there is no cookie cutter treatment for every patient and scenario. If you understand that up front, you will not be disappointed that your plans / solutions / workflows do not work with every provider or department. You need to always seek second opinion.

That all those years of babysitting and talking kids down from tantrums would come in so handy in my future.