I am writing this blog post in response to the The New Yorker article “Why Doctors Hate Their Computers” by Atul Gawande. I thought that it was an interesting story. In general it seemed to be a look into how doctors and other medical healthcare workers are fed up with the poorly designed software that they are being forced to use. Some shorter stories about scientists and engineers are also included, and they have similar complaints, which shows that this is not just a problem among doctors using electronic medical records systems.

The main problems that seemed to make the doctors’ jobs harder was the fact that the programs required them to fill out excessive amount of detailed information before they are able to move forward. Their workflow is being interrupted and they are unable to do their job in the same way that previously worked well. The new computer interface may have streamlined some of the process, but it became too bureaucratic and inflexible. The fact that some of them decided to work with the I.T. department to hack the system and write their own better interface was not surprising given how much complaining came before that. It is obvious that the users of the system are not the real customers. The real customers – the people who made the decisions about how the program should control how the doctors work – seem to be the hospital administrators. They worked with the software engineers to design a program that forces the doctors to pay more attention to what they need the doctors to do for them, instead of what the patients need.

I do not think this article will change how I work or how I think about the things I make at the moment, but that is just because I am not making any sort of widely used software for important applications like medical records systems. In the future, though, I might recall this article if I happen to be working on some software application that has a variety of different users with different needs and I am given only one perspective. I imagine the developers of the system that the article is referring to might have been wondering about some of the user experience details. If they recognized that the users of their software are not the same people as the ones telling them how to make the software work, then they might have already had some concerns of their own that they were not able to address because the users, the doctors, are not the ones in charge of how the program they are going to be using is going to work. Something I do wonder because of this article is about how these problems can be avoided.

From the blog CS@Worcester – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

This blog is about the article “Why Doctors Hate Their Computers” in the New Yorker by Atul Gawande. The article talks about the complications the doctors encountered after upgrading the electronic medical record system they used to Epic.

There were some tensions that caused the system to make doctors’ lives harder than easier. It became more political than technical. Staff and doctors had different views on what should be included. Now they added more questions that are “field required” that doctors used to skip that added more time to finish. Another tension was that different doctors can modify a patients profile. Three people will list the same diagnostic in different ways. Some will just list what is required just so the system does not alert them, some are not useful to the doctors who need to know a specific diagnosis.

I agree with Gregg Meyer. He said that “But we think of this as a system for us and it’s not,”  “It is for the patients.” After reading the article, it really seems like it was not made for doctors but for the patients. It was made in a way that every patient should have a record on every required field which made it harder for the doctors to do their work. The system was also used so that patients can log into it to look up their lab results, remind them of the medications they are supposed to take and read the doctors note to the patients. There are more patients than doctors so I think Epic was made so that the patients can easily access it. 

This article was long but it was interesting to read. As someone who is trying to work on the field of software development, I found it interesting how important it was to know the customers we are building it for. I think for us developers, it is easy to make a system that we could understand and use relatively easy, but without the perspective of the end user or the real customer for these systems, it might not be the same scenario for them. There are still a lot of people who are not tech savvy. This lesson of implementation of this system does not only apply to Electronic Medical records systems. For example, there is a show called Silicon Valley, where they made this software for a middle-out compression solution. It was the talk of the town. It was the fastest algorithm at the time. The developer asked his friends (other developers) to look at the finished product, and they all liked it. Then the time came when they were trying to release the software. They had ordinary people testing the software and they couldn’t understand how to use it and what it does. They had to teach them for weeks and there were only a couple testers who learned from it. Moral of the story was the same in the article, for us developers, we have to pretend that we do not know anything about our system sometimes and see if it is friendly enough for others.

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

As you decide to follow a Software Development or Engineering career path, you should consider this path has lot of knowledge that need to be accumulate in case you want to move forward. You could be a Computer Science student or an entirely self taught developer, you should learn how to take advantage from other … Continue reading Apprenticeship Intro →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

The first chapter and the next five chapter introductions draw an outline for a general guide to how to learn. The relevance of software development or of the term “software craftsmanship” seems to go away after the first chapter, where the rest is just about self improvement and how to learn. I agree with the points being made in each chapter, but I am also recognizing that these ideas seem to extend to literally every field of study, and not just software engineering. Throughout most of the reading, I was actually thinking about mathematics and not software development, and the ideas apply just the same.

I think that chapter 5 seems to be the most relevant to me. I know that I have learned a lot already, and I am also aware that there is a lot more that I do not know, and even more that I am not even aware of. There is a lot of content to learn about that I find interesting, and I always seem to find that I am preoccupied with other tasks such that I am unable to spend as much time looking into new interesting material as I would like. I started reading the beginning of chapter five just as I was thinking this, and the chapter opens with a quote, directly relevant to that thought, about how there will always be some distraction from learning, so it is necessary to seek knowledge anyway even when the conditions are unfavorable.

I think the idea of “emptying the cup” from chapter 2 is also relevant. Chapter 1 mentions that somebody may recognize that they are at the beginning, as a newcomer to software development, even if they have already been programming for several years. I think it would be likely to have been exposed to some software development projects and practices during the “several years” of programming, so the term “beginner” does not seem to fit very well for somebody with that much experience. On the other hand, somebody who has been actively learning to the extent described within these chapters will definitely have transcended their level of experience. The idea of a “full cup” comes into play when an experienced person is not inclusive of further experience and knowledge. There is the expression about teaching an old dog new tricks. It is necessary, in order to learn, to actually want to learn.

I can see myself applying the principles in these chapters more so toward my mathematical education than my software development education, only because I am more aware of what I do not know in regards to mathematics. I expect that the focus should shift more specifically toward software development in later chapters; knowledge of careers and how software development works on the level of employment is much less familiar to me than the computer science component of software development, although there is still much more to learn in computer science alone.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Hello, I’m Kristi and I’m Happy to be back for my last semester. I’m going to love the capstone class CS-448!

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.