Why Doctors Hate Their Computers Response

Hello and welcome back to benderson’s blog, today is a very special day as I’m uploading a second blog but this blog has nothing to do with the patterns that I have been discussing lately, this blog will be about an article I read that talks about why doctors hate their computers. I know this sounds weird but it is a common occurrence with doctors, I actually go to a doctor who constantly talks about how she hates her computer and that it annoys her when it doesn’t work how it is supposed to. Anyways this article was very long but also a good ready and I would like to share my opinion on the article with you guys.

The article had a lot of thought provoking ideas and explained how the computer systems had pros and cons to them in the medical field and how the doctors used them. I found it interesting that doctors were spending about double the time putting information into the computer for their patients. I also thought it was interesting and sad that family physicians were experiencing depression and suicidal thinking after having to do eleven and a half hours of a day of work. When the article was talking about scribes, I thought that was a good solution to a time consuming problem because that would save a lot of many hours copying and putting information about a patient into the system. As the software was being upgraded, simple tasks that would only take about two clicks were jumping up to eleven clicks to complete the same task which is weird since a system update is supposed to make things usually quicker and easier. The tensions that made the doctors lives harder rather than easier from the system were the things that I previously stated which were that the software made things that used to be easier difficult to put into the system and more time consuming. This caused the doctors to become more stressed out and made their days longer than usual, it did make getting to medical records most of the time faster, just a couple of clicks instead of going through a whole bunch of papers but for other things, it made them way harder to do.

The real customer for the system was for the patients and not the doctors. The reason I think this is because the problem for the doctors is implementing all the symptoms and medical problems that the patients have and it is a very patient centered system where the only thing a doctor really needs about themselves is who they are taking care of and their credentials. This system is basically a “all you know about” your patient, so the system is for doctors but the real customer’s are the patients.

The lessons from the implementation of this system do not only apply to Electronic medical record systems as this happens with basic databases that contain information about a work place and their clients. A business could have a very similar based framework for the clients with certain attributes like a patient would have for a hospital, and implementing these certain attributes could be as a pain as a butt as it is for a doctor to do it for their patient. The reading has made me more aware of the problem with computer systems and doctors but doesn’t really change my opinion of the topic as I think it is useful in the long run to have everything stored in a system, just that it may need some tune ups to make it faster and easier for the doctors. One thing I would say that would be a problem with a computerized system is that if the computers go down for a period of time, you would have to revert to the physical form to make sure you have everything on a patient before hand. All in all though, “Why Doctors Hate Their Computers” does have some interesting points on why doctors hate their computers and very reasonable ones at that but in the long run, having a computerized system is beneficial for more efficient and faster help for patients.

From the blog CS@Worcester – Benderson's Blog by Benderson's Blog and used with permission of the author. All other rights reserved by the author.

Why Doctors Hate Their Computers

As we all progress through the software development track, learning new skills and how to implement solutions to modern problems, we rarely stop to evaluate how our work or programs we create will affect other people. Yes, we have goals of efficiency, security, and user friendliness which guide us to develop the most useful technologies we can. However, even in following all of our rules to a T, we may create unforeseen consequences on the clients we develop for.

This article Why Doctors Hate Their Computers is a great demonstration of unintended consequences of modern software development as it behaves in the real world, being used on a large-scale. Essentially, the article describes a new electronic medical record software called Epic, whose goal was to create a single interface which doctors, patients, and hospital staff can share information and carry out their work more efficiently. The problem with this software was the scale of which it was being implemented. The upgrade from the old system was just too big with too many factors, and the robustness of the program actually served to make medical professionals jobs even harder and more tedious than before.

While they described Epic’s features and goals, my first impression was that it seemed like an excellent idea. Take all of the doctor’s online work tasks, bring them into a single program where patients and hospital staff can add information; it seemed like a grand unifying software that could easily be an industry standard. However, as I read the author’s experience with the hospital actually implementing the software, I became less convinced.

One aspect of this implementation which shocked me was the hospitals plans to compensate for the reduction in productivity that would accompany any large-scale change. According to the author, his hospital group allocated $1.6 billion on the transition – while the cost of the software itself was around $100 million. The majority of the cost was either being paid out to IT professionals who would install and train staff, or wrote off as lost patient revenues from temporary loss of productivity. This is a tremendous amount of investment to get the systems updated. The problem was with the scale of implementation. A possible solution is having “ambassadors” implement the change and then train the rest of their coworkers would be a better system. At least this way people could ease into the transition and get feedback.

This astronomical cost would be arguably worth it if it really cut down on the complexity of the existing system and resulted in a more efficient experience for the customers and a better workday for the staff. Unfortunately this wasn’t the case. The author’s colleagues experienced frustration, cluttered data, and longer hours at the computer. Significant time and energy that should have been given to the patients were now being spent on learning and/or fixing the system, which defeats the purpose of the upgrading the system in the first place.

Though the developers aren’t necessarily to blame. Without a first hand understanding of the needs and bottlenecks of the medical industry, developers rely on our tried and true model of efficiency, which may unintentionally have the opposite effect if complexity becomes too much. Large scale software updates like this should be taken slowly, where developers work closely with clients to fully understand their needs. When the system is ready to be released, it should be live tested with a few “ambassadors”, who can give constructive feedback and train their coworkers, rather than a company wide transition that can be exorbitantly expensive and time-consuming.

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

Finding out with Doctors and Computers

For this week, I have decided to read also “Why Doctors Hate Their Computers” by Atul Gawande. The reason I have chosen to read is because in the world we live in now, we have people that are struggling with the changes towards their job aspects and having to deal with problems that are rather unfavorable to an extent. I believe this article will help me understand from a perspective in making sure the problem is clear and finding out what is the real source of it.

What I think is useful from this article is that the perspective can give a similar scenario that which people can relate to learning and end up become frustrated. So let us say that we have a task that is completely new to our workload and it turns out it is in an another language. It is true that we have just to get some help to translate them, but what if it is another language you must learn prior to that? This is the same from this article when it comes to doctors forced to work with unfriendly software.

What I think is harder from the system is the EMR being reliable with good physician input. Learning what medication to give is easy with enough practice and knowing it is. But getting the records needed is very difficult considering it is just a faxed report. The real customers for this system would be those who need of accommodations. This is because as a community, we tend to have options like sending by email instead of verbally, doing things by paper, giving checklists.

The lessons in this article not only applied to the Electronic Medical Records System but also to all technology that requires records. With the lessons, they should make sure that with whatever technology gives the records as requested instead of being just a general report as part of the system. From reading most of the article, I will say it has definitely changed my way of thinking to the medical record system in hospitals. In the past, I usually think it would be on point with learning what medicine to take and what conditions patients would have but now from this perspective, I can understand why doctors would be frustrated in the updating technology to find records needed.

What I think from this article I will disagree is the purpose of EMR being the best thing to turn to for the sake of getting records. I believe that the EMR is meant for billing instead of medical records since it does feel like it takes the amount of time in seeing the patients, which is important. It could be also medical errors that can lead to false information by the responses the patient gives when diagnosed. For this reading overall, I will say this is a good read in learning the perspective of doctors with technology. This one I believe can be difficult at first to get used to since it is from a perspective, but it provides information that relates to technology that constantly change across.

 

Link to the blog: https://www.newyorker.com/magazine/2018/11/12/why-doctors-hate-their-computers

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

Re: “Why Doctors Hate Their Computers”

After reading the article on “Why Doctors Hate Their Computers” I found the use of scribes for doctors to be rather interesting. The patients and doctors were both missing out on valuable face to face time because of the tediousness of the software and the constraints of the system. I was shocked to find out that the scribes were making minimum wage in most cases as well as the turnover rate to be as ridiculous as most of them only lasted mere months. I feel that if the pay was increased, the position would be drastically beneficial for both parties involved. The doctors would be relieved of their note-taking duties for the most part, while the scribes, who were often med-school students, or those seeking medical schooling, got some hands on experience in a doctor’s office. This goes without saying that the additional patients per doctor that was happening to the example in the article, defeats the whole purpose. The whole struggle to finding a happy medium between functionality and feasibility for clients is not limited to the world of medical software but a struggle that exists in almost every avenue of software, even the consumer market.

One of the biggest tensions for the doctors is the concept of getting to the next patient as quickly as possible, while maintaining a personal relationship with patients, all at the same time maintaining the monotonous documentation system that the software has become. The doctors have taken on additional tasks without additional personnel being hired to lighten the overall man-hours required to perform all of the tasks for individual patients. The scribes help with the doctor’s desire for more face to face time with their patients but again, defeat the original purpose of the software, to be more efficient than a paper system. Those without scribes were often taking on hours of work to do at home as they simply did not have time to complete their note-taking during regular office hours. While the system was meant to make lives easier for doctors, it often wasn’t.

Despite the results, the customer for the system is still the doctors. They’re the ones who are directly using the software as well as giving input to the developers for changes. Some may argue that it is the patients as the whole service of medical care is for them, but like Quickbooks is for accountants, Epic is for doctors.

The lessons from the implementation of this system apply to almost every industry. The man at the end of the article is a perfect example of this, as he was experiencing similar problems at his job as a construction supervisor. Many individuals are losing their direct interaction time aspects of their jobs to devote the time to using software in one way or another.

I’ve always thought of this battle between ease of use and complete functionality as a struggle that directly works in the world of security. People are always afraid of being hacked, or their information stolen but if the system is complicated, and has extra steps for users to ensure security, users want an easy way out. Whether it be simple passwords, or a lack of use of two-factor authentication, users often want the easiest means of use over the most secure means.
Link to the article here: https://www.newyorker.com/magazine/2018/11/12/why-doctors-hate-their-computers

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Kindred Spirits

This week I read through Kindred Spirits from Chapter 2. This pattern is reflects on the stage of life of an apprentice who feels like they might not fit in entirely well with a company’s culture, perhaps because they have different interests or a different level of enthusiasm. Perhaps your organization is not very tight-knit and you’d prefer it to be. The solution is to make sure you reach out to meet those who are like you, and that you actively stay involved in what those people are doing. Read books, remember names, and attend meet-ups. Even getting coffee from time to time and discussing ideas can help immensely when your work life isn’t feeling satisfactory. You may even find yourself in a spot where you are offered a position to work alongside those kindred spirits who are just like you.

I found this pattern pretty interesting because, due to graduation coming up, I personally have been pretty concerned about finding a work environment that I really enjoy — as I’m sure everyone is from time to time. I know that I’m someone who seeks to get involved in the places I spend my time, and that if I join a company it is important to me that I’m not coming into work, getting things done, and then leaving. I want to find coworkers that I connect with, work that I can get invested in, and people who are enthusiastic and encouraging. From what I’ve heard and from what the chapter suggests, organizations that a truly encouraging are often few and far between. It may not even be the entire company, it could just be that those you who associate with on a day to day basis are not quite as enthusiastic about your work as you are. As a result, I really enjoyed the tips that this pattern suggested. Make sure you remember those who are similar to you and who have shared goals in mind, and that you keep those people as close as possible.

It’s important to keep track of who you meet, who inspires you, who knows what you know and is passionate about what you’re passionate about. Make lists of communities and try to get involved in them. One thing I’d like to do personally is to attend some software conferences — I know there are plenty and I know many are not outrageously expensive, so it’d be a really great way to meet people and make connections. It’s important to keep those you you mesh well with close to you, as those people will provide you with opportunity and friendship like no others.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

“Why Doctors Hate Their Computers” Reaction

The article “Why Doctors Hate Their Computers” by Atul Gawande discusses the effects of the computerization American hospitals over the past decade.

I found it interesting that the computerization of many of the processes that health professionals use, such as recording medical observations, sending prescriptions, ordering tests, etc., ended up actually causing doctors to spend more hours working than they had before (spending about two hours doing computer work for every hour spent with a patient). This is surprising to me because cutting out the overhead of physically performing these tasks should have done the opposite. Yet, in practice, it seems that that is not always the case. Small details that doctors would have been able to ignore now act as roadblocks. For example, commonly skipped questions in a form may now prevent the doctor from submitting the form until filled. Although these questions alone may only take a few seconds to get an answer to, this could potentially add up and take a lot of time away from actually talking to the patient instead of just requesting information to fill in a form.

Another interesting topic was some of the potential solutions to solving the lack of doctor-patient interaction caused by doctors having to check off boxes in a form on their computer. Having someone else, whether in-person or through a camera, transcribe all of the data from a visit is a great solution to the issue. Of course, the cost of paying someone to do that is something that hospitals may not be willing to provide. There’s also the factor of a patient feeling less comfortable knowing that someone else is listening in on their conversation.

I feel that the real customer for the system was the hospital system itself (Partners HealthCare). While I think keeping their technology up to date is a good investment in the long run, the ones seeing the adverse effects are the doctors themselves. Computerizing all of the data and processes helps the hospital to be able to protect confidential data and ensure that all legally required information is gathered from patients.

The lessons from the implementation of this system apply to much more than just Electronic Medical Record systems. It’s likely that the computerization of any industry would see many of the same issues such as the decrease in human interaction and the frustrations in the software decreasing productivity. Although, in less regulated industries, these frustrations may be more limited.

This reading brought up an issue that I hadn’t really considered before. A lot of people, especially computer science students, are probably of the opinion that the computerization of any industry is a good thing. To an extent I still think that this is true, but you should consider the possible effects it may have on all parties involved.

Source: https://www.newyorker.com/magazine/2018/11/12/why-doctors-hate-their-computers

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Relationship between Doctors and their computers

What I found interesting about the article on Why Doctors Hate Their Computers is the entire process or evolution of the software. The entire journey the doctors had to go through in order to accommodate the software that has begun to invade their profession. As with many different situations, being able to play around with something new that you haven’t used before is exciting. However, after a period of time has passed, you will notice how the change has affected your life. This is what has happened to the doctors that once praised the new software to hating it. Before software was introduced, all paper-based systems were balanced around human behavior. Such technology did not account for that and focused around efficiency. The downside to this is the difference in efficiency for computers did not translate one to one for efficiency in humans. Which lead to a decrease in efficiency for the lives of doctors world-wide who has come to depend on such systems. Due to this, doctors started hiring more workers in order to reduce the time loss and complications generated from using the software designed to “help” doctors to increase human efficiency again. This process is never ending as it continues to try and find a balance which is indeed interesting.

The reoccurring problem that causes the doctors lives to be harder than easier would be the data entry process. Asking questions and storing the answers require time, and time is limited per patient. By increasing the number of fields that doctors had to fill, reduces the load and helped other jobs elsewhere but reduces the time available to help patients and increased the workload for doctors.

The real customer for the system is not the doctors but those above the doctors who chose to believe that doctors would appreciate the system. By appealing to a certain client and not directly to those who are going to use it will definitely create an issue. However, once the system is in place, the doctors will have no say in whether they want to use the system or not. The amount of money spent on the new system must be used to get their money’s worth.

Also, the lessons from the implementations of this system also apply elsewhere as more and more people are gaining access to computers. As such they become dependent on software that could potentially improve their workflow. These situations are what is needed to continually improve software and tune them as needed to satisfy the customer’s needs. Software and humans are alike, as they are ever evolving and adapting to new situations thrown at them. The article is very relatable to how new software has effected society as a whole today and was a very interesting read.

 

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Concrete Skills

Hello and welcome back to benderson’s blog! This week we are discussing another pattern in the Apprenticeship Pattern book called “Concrete Skills”. Concrete skills discusses the problem of wanting to join a team that will lead you to a big learning experience but they probably won’t let you join do to you not having the credentials to work on the project therefore being a rock in a bag that they got to carry across the finish line, in other words you would be holding them back instead of helping them move forward with the project. The book provides the solution of maintain your concrete skills as it may influence them to trust you and let you on the project. Some of examples of concrete skills they provided were; writing build files in various popular languages, knowledge of open source frameworks and standard libraries. This still may not get you hired to the job as managers would have to take a leap of faith on you but having these skills will make that leap of faith a little bit closer. The book also suggests collecting the CVs of the people you respect as you can learn from their CVs and pick out certain things that they do well with and learn from it, this will allow you to create something to show that you have learned and may get you on the team.

The pattern “Concrete Skills” is intriguing as it is how every job usually works that has high end problems with it and needs the best workers on it. The most knowledgeable will always be working on those projects as the people who need the experience and want to learn will have to sit out on it as they can’t hold the team back from completing the project on time. Now the goal of the person that has to sit out of the high-end projects has to become the most knowledgeable to be able to work on the next high end project or join this one. This pattern talks about the ways you can do that and it’s through learning from outside sources, online research or even your colleagues are a couple of outlets you can use to become the one of the most knowledgeable in your workforce. Acquiring a CV from one of the people working on the high-end project would be a great way learn and be like that person which will greatly increase your chances of being hired for the job. Concrete skills is exactly what you need for the baseline but you need to rise to the occasion to improve those skills and become one of the best.

From the blog CS@Worcester – Benderson's Blog by Benderson's Blog and used with permission of the author. All other rights reserved by the author.

Why Doctors Hate Their Computers

This week we were tasked with reading an article titled Why Doctors Hate Their Computers. One of the very first things that stuck out to me was that doctors spend around two hours of work on their computer per day. I thought that this is a lot of time to be spending on the computer for a doctor. As a computer science major, I did not initally think that two hours of computer time during the work day was not bad. After some thinking and consideration, I realized it was not normal for most other jobs to spend this much time at a computer during their day. To add onto this two hours of computer time for doctors, they also spend most of their face time with patients staring at a computer screen. I can definitely believe this because when I go to the doctor they are typically on the computer and filling out forms and information while trying to perform my physical. I understand that computers make the filing aspect of the job easier, and it is very nice to have the information of all your patients at your fingertips. However, I can also see where this gets distracting. Instead of being able to have face-to-face interactions with your patients you now have to talk indirectly to your patients while you try to fill out forms on the computer. Thinking about if from the patient point of view, your doctor is not paying attention to you, and is rather sitting at his computer and staring at a screen instead of addressing you directly.

Another issue that comes up with doctors using computers is the increased stress on the IT departments. The doctors often run into issues with their computers and in turn pull IT service request tickets. This puts an added stress on the IT departments and the doctors get frustrated with their computers because they often run into problems. Another issue is that doctors may not be a technically literate as people in another field (say computer science for example) and thus might not understand how the computer functions or why they might be having a problem. Some of the problems that we would consider to be “minor” such as login issues, not being able to open a file or find a link, may be a “major” problem for some of these doctors who are not as technically literate as us. The doctors will then get frustrated, take out tickets for the IT department and the IT department sees these as “minor” issues and therefore take their time getting to the issue (especially if there are more pressing matters or if the IT department is extremely busy). The added stress between the doctors and the IT departments can be curbed by having doctors take computer courses or have the IT departments offer to give the doctors “how-to” guides. I believe that in this solution we will see a decrease in stress between doctors and hopefully they will see computers more as an aid rather than a pain and hindrance to their jobs.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Team Dynamics and Mindset

For the third week’s reading, I chose to read the pattern, Unleash Your Enthusiasm. This pattern is about handling the excitement of being a software developer once you join a team. Joining a team brings responsibilities such as considering how the team functions. The enthusiasm you bring into the team could be accepted or rejected. Depending on what happens, you are required to handle it correctly. For example, being overly enthusiastic could potentially backfire such as making a bad impression in front of a well-established team that is currently low on morale. For teams open to excitement, you can be yourself, as they are accepting of possible ideas and creativity you could bring. This type of environment allows yourself to throw ideas with very little to lose as well. By being a newcomer, it’s said that you are in a unique position of having a fresh perspective for the team. As with any team, improvements and suggestions can be made by all members, as such, your opinion also matters.

What I found interesting about this pattern is the excerpt about a study on the collective mind of aircraft carrier crews. The conclusion of the research was that its healthier for a team to having people of all levels of experience. This is true in a sense that if you have a team of all veterans, it’s very easy to be in a mindset where you could do no wrong. While incorporating members that have less experience, the veterans would benefit from reviewing basic information that they could potentially overlook or forget. As such, new comers do have a unique role as stated earlier in the pattern. Another interesting part of this pattern would be the action it proposes. It seems to be assessing the thought process in rejecting an idea you have before getting opinions from those you are suggesting it to. By surfacing the scrapped idea and presenting it to said person/group, the individual could learn more about their idea and maybe more. Taking risks is apart of life and sometimes proposing ideas aren’t as risky if you benefit from learning from your peers.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.