Programmers’ Guide to Working with Physicians

keyboard with steth 700
​One of the great benefits of working as a software developer in the Homer Warner Center is that we reside on the IMED Campus and are in close proximity to the clinicians and clinical settings where much of our software is used. But the demands for a physician’s time are great, and we must be very considerate and use their time efficiently. As one of our favorite collaborators Dr. Allan Morris likes to say:“If you find that 24-hours in a day is not enough time to get your job done, you should consider working nights”. 
Following are some suggestions on how to work with physicians effectively in a software development project.

Plan and conduct efficient design meetings
  • Be accommodating to the physician’s schedule whenever possible.

  • Travel to the physician for the meeting, if possible.

  • Be on time and be ready to start on time. Make sure you have the necessary resources, such as projectors, white boards, etc. Food is nice too; physicians are oftentimes hungry. And don’t be surprised when they are late.

  • Address physicians formally. Call them ‘doctor’ unless you know them well or they say to call them by first name.

  • Have an agenda and manage the meeting to the agenda.

  • Take another team member so they can:
    • Take notes. It’s too hard to be engaged in design and have to take notes too, and it breaks up the creative flow.

    • Be another set of ears.

  • Consider recording the meeting, but inform people if you do. Smart phones do a surprisingly good job at this. Archive the audio in your documentation repository.

  • Send out action items with specific assignments. (Minutes are nice but can be a lot of work.)
Learn the medicine, learn the language

Your software will be better if you understand the clinical concepts and process it is supposed to represent. You will communicate more effectively if you understand the clinical terminology used by the physician.

  • Whenever you hear a medical term you don’t understand, learn it. If you’re in a meeting you can often discretely do an online search it. If not, ask for an explanation.

  • Create a project dictionary of medical terms. It’s simple to copy and paste from the web into your dictionary.

  • Software should not just be an ‘online’ care process. What unique capability can the computer bring to a human process? You must first understand the medicine.

  • Most physicians aren’t preoccupied with technology

    Most physicians don’t understand or care much about technology. They don’t speak your language.
    • It’s usually not beneficial to try to explain complicated technical things, like why things can’t be done or why things don’t work.
    • Take responsibility for their understanding

    • Physicians can have a lot on their minds and feign understanding when they just want to get away from you. If you make understanding your responsibility you will have fewer issues down the road.

    • Look for visual clues that they are paying attention. Simple things like eye contact or conversation.

    • State the issue in multiple ways and ask if they agree or understand.

    • Quiz them. Ask questions that confirm their understanding of what you just explained. And don’t “lead the witness”.

    • Use visual design artifacts to aid communication: flow charts, tables, Visio diagrams, functional prototypes.

    • Always mock-up the user interface with a functional prototype.

    • Avoid lengthy and complicated emails unless there is no other option.
    Expect Change

    Getting software right is hard.  It seldom happens the first time.  Users don’t know what they want until you get it in front of them and they decide it doesn’t work. As the innovation mantra goes, “Fail fast, fail often!”