The article Why Doctors Hate Their Computers by Atul Gawande discusses the issues many medical professionals have with the use of new and modern Electronic Medical Record (EMR) technology. The premise of the article is that the software used by doctors, surgeons, etc. to record patient medical information, schedule appointments, and pretty much every clerical medical function necessary.
The article gives a healthy dose of reasons why doctors have so many issues with this software. The big issue that many doctors had was ease-of-use. It can be especially intimidating for less tech-savvy doctors to navigate the system and work with the interface to do the things that they were used to doing by pen, paper and phone-call before. In addition, there are a number of quality of life improvements and minor issues with the system that add up and force doctors to spend more time than they’d like working on their computers instead of with their patients.
I consider accessibility to be one of the most important parts of a functional program. It doesn’t matter if your program is capable of doing everything it is supposed to; if it is too challenging to discern how to make the program do what you want, it might as well do nothing. “Accessibility” is a broad category however, and could be affected by user interface, design choices, and certain features. Making a system as accessible to its users as possible should be a priority in every project, as doing so greatly increases the effectiveness of your system.
Something I found frustrating was how important bureaucratic and political details were to the implementation of these systems. I’ve always found that all the regulation and red-tape, while obviously important, distracts from the main goal. The bigger problem is that with every project, so many different departments have different ideas and goals for what they can get out of it. However, compromise does not always lead to the ideal choice. I think it is important to consider the actual goal behind your product and weight every other goal based on how much it lines up with that one.
Interestingly, looking forward, this article has given me a lot to consider when working on the AWS Food Pantry group project this semester. I will definitely be trying to maintain the accessibility of whatever software we end up making, so that everyone who may find themselves needing to use it can. I am also going to try to balance the needs and goals of every facet that affects the project, whether it be regulation/law, customer needs, and the needs of the business. In this way, we can create the best version of the software we are asked to create.