Software Design: Clinical

Why I Write Code For Clinical Work

“… putting together the symptoms you have been experiencing and the findings I observed during my examination, I think you have Parkinson’s disease…”

This is what I do. This is the type of thing I say to my patients toward the end of their office visit with me. I hate saying it, and I feel privileged to have a chance to say it in a way that minimizes anguish and injects hope for the future. Figuring out how to best say this for a particular person on a particular visit is one of the most important skilled elements of my work as a clinician. I use all my experience to synthesize what I learned about that person in the past 45 minutes: what symptoms they have been experiencing, what I found on examination, how certain I am of the diagnosis, what might the person be expecting, who are they as an individual, what are their emotional strengths, what have they been worried about. I want my announcement to come from a person who in the past 30 minutes spent time thinking about them and somehow inspired their trust.

If that is my goal during an office visit, to flash-develop a trusting relationship, if I want to be in a position to announce with kindness something that no one would ever want to hear, I can’t tolerate the intrusion of a modern EMR (electronic medical record) system. The four systems I have so far used, all major systems purchased by large academic hospitals, are unsatisfactory. There is no way to use such a system during a patient evaluation and achieve what I described above.

Of three possible solutions to this problem, I consider two unacceptable. One is to talk to the patient without touching the EMR, and instead jot a few lines on a piece of paper or in Word. Later, everything gets typed into the EMR. Many of my colleagues do this, but it is not sustainable. The time they take to enter their notes after the visit must come from somewhere: time with family at home, time funded by research grants, and time funded by endowed professorships. Not only wrong, but also not sustainable while preserving sanity.

Another solution is to reduce the quality of the visit. The visit time now must include time spent clicking through interminable hierarchical menus and checkboxes, entering and re-entering passwords, scrolling through documents using a mouse because the Page UP/Down buttons do not work in a particular window, and so on. The result is less time for thinking and less time for inspiring trust. These go out the window without a peep because they cannot be measured. If I do not check a box that specifies whether the patient previously smoked or never smoked, the practice incurs a financial penalty, and I get reprimanded. If a patient walks out with a 20% larger anguish because I ducked 20% of my trust-building effort, no one will know.

The third solution is, in the phrasing used for a much more important cause, “TAKE BACK THE TIME!”. We clinicians must claim back, from inadequate software, the time to think about and to connect with our patients during our encounter with them. Those of us old enough to remember, learned to use pen and paper without ruining an interaction with a patient. In fact, the image of a person holding a notepad and inviting you to sit down has long been a comforting one. We need software that achieves that—software that replaces what pen and paper used to do: act as tools that integrated seamlessly into our behavior. We need software that includes attention to the human interface: what is the experience of a human using that software, and what is the experience of a patient watching that human use the software. It’s possible to achieve this. The system I designed in 2000 has allowed me to document my clinical encounters without intruding on my relationship with my patients. I chose the development environment (Filemaker) specifically because of its emphasis on the human interface. The few other clinicians who have used it have had an immediately  immediate reaction exactly for the reasons that I value: they find it fast and intuitive to use, because it is much more similar to writing on paper than the typical EMR system is; and they feel comfortable using it while they talk to a patient.

What EMR software needs is far more attention to the user interface, so that it is tailored to how a doctor would normally write on paper during a visit. Entering information into an EMR should be as fast and as natural as it is for doctors older than 50 to write with pen and paper, and for doctors younger than 30 to type a note in Word. One day such an EMR system will hopefully appear. For now, I am using the one I created, and I copy and paste at the end of the visit into the clunky official EMR.

Pluto: Electronic Medical Chart

In 2000 I created an electronic medical record (EMR) system to create notes that I printed and placed in the paper chart. I called it Pluto, in homage to the EMR system that inspired it, MARS (created by Joel Perlmutter at Washington University in St. Louis).

In 2012 Columbia University adopted an institution-wide electronic medical record system. It was faster, however, to continue to use Pluto to prepare my notes and transfer them to the institutional EMR at the end of each patient visit. A few other clinicians have since adopted Pluto as a note preparation system. Having moved to Wash U, I presently use MARS, but Pluto continues to do for me what MARS does not (yet) do, like email me reminders that I set for myself of something I need to do for a patient after a specific date. Pluto also continues to be used by a few colleagues in other departments and institutions.

Pluto will likely remain useful until institution-wide EMR systems adopt a user interface that better approximates elusive features of pen and paper, including fast entry and rapid perusing of previous records (analogous to flipping through a stack of papers).

Pluto is designed as a Filemaker database. A full description, to appear on this website, is in preparation.

Screen Shot 2018-02-07 at 10.07.29 AM

VideoCat: Patient Video Library

From 2001 to 2016 I managed the library of patient videos in the Center for Movement Disorders at Columbia University. I created a workflow to convert the center’s 25 years’ worth of analog media to digital video clips. I then created a database, VideoCat (video catalog) to organize digital video clips.

Major features of VideoCat include the following.

  • Videos can be quickly added by any user

Video clips are generally not secure when they are first created: camcorders use removable media (e.g., SD cards) that cannot be encrypted; smartphones are vulnerable due to their extensive connectivity. Because VideoCat allows immediate upload (and automatic backup) by the user, the unencrypted original clips can be deleted shortly after they are taken, minimizing the risk of breach of patient privacy.

When physicians take a video of an examination finding, they often wish to review it (e.g., with a colleague) soon after the visit. Clips in VideoCat are available for review across the institution’s network as soon as they are uploaded. A colleague in another building can review a clip shortly after it’s taken.

  • A video manager is optional

VideoCat is designed to benefit from, but not require, any time beyond the time it takes the user to upload the video. The amount of time spent on managing a VideoCat library can be seamlessly scaled from minimal to a staff person’s full time. Thus VideoCat can be useful to a single clinician who has no extra time for managing videos, as well as to a movement disorders center with dedicated staff for managing videos.

A few academic centers have the resources to maintain a complex video library. These include staff like a video manager, who can rename and compress videos, edit them for presentation, and enter metadata (patient name, diagnosis, clinical summary). VideoCat can greatly optimize a video manager’s time. It includes scripts for automated or semi-automated renaming, compressing, and joining of video clips. It allows entry of metadata like patient demographics, clinical information, abnormal movements, teaching value, through fast graphical user interfaces. It can thus be used to prepare case conferences in which physicians can ask to review a video clip by remembering only the date of the visit. The video can be shown along with clinical information, and comments made during the conference can be directly added to the record. These features allow a movement disorders group to use videos for clinical care, teaching, and academic work.

Many movement disorders clinicians use videos on their own or as part of a small group that cannot afford staff to manage a video library. VideoCat is designed to be useful to such individuals too. The minimal time needed is what it takes for a user to upload their video clips into VideoCat. All they need to find their videos is the date of the visit.

If they have additional time, users can later add information like patient name, diagnosis, etc, through the same semi-automated scripts and graphical user interface that a video manager would use. What is crucial, however, is that this is not necessary for VideoCat to be useful. Even if videos are just uploaded, VideoCat provides storage that is organized, secure, and accessible over a network.

VideoCat is designed as a Filemaker database. A full description, to appear on this website, is in preparation.


← Software Design: Research — Home →