Do You Hate Your Computer Too?

Sams Ships (3)Apparently doctors hate their computers, according to an article titled Why Doctors Hate Their Computers by Atul Gawande. Gawande started out the article by mentioning Epic, a company a lot of people know of because it is a leading provider of software for the healthcare industry. It’s funny because just the other day, a classmate who will not be named groaned when he heard Epic being mentioned by someone, as he works in a healthcare center.

I found the reading was interesting because I have no intentions of becoming a medical doctor one day but was able to hear about how it is being one while interacting with technology that exists today.

It seems like the tension of logging everything caused the system to make doctors’ lives harder instead of easier; this was noticeable when Sadoughi was talking about how she had to look over all notes from different doctors including herself per patient. Instead of being able to just see what is going on right away; it would take up time to gather all information and even then it was not always helpful because some notes were different than others and became dated. And then work-life balance had to be thrown off a little because people had to spend extra time, up to hours after-hours to catch up with the system and review things from the day.

The real customer for the system seemed to be patients because they have some benefits from using the system like logging when to take medications or see how they are doing. Doctors are also able to monitor how they are doing and communicate with them by being pinged.

The lessons from this system do not only apply to Electronic Medical Record systems; they also apply to working in life because burnout can happen to anyone in the workforce. I thought it was interesting how one of the ways doctors were trying to save time and prevent burnout from technology was by hiring in-hospital scribes or even virtual scribes when necessary.

The reading has caused me to changing the way I think I will work based on if I ever end up creating software that affects people’s healthcare by considering how much time it takes to interact with it, no matter how “cool” or “innovative” it may be. In terms of the topic itself, the reading has caused me to think more about software that has altered people’s professions as a whole; which I thought of before but never this deeply.

I do not disagree with anything in the reading for now as I do not personally know what it is like to work in a profession that is not traditionally non-technical and then gets transformed into something that relies on it.

 

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

Doctors Don’t Like Their Computer’s Huh?

Good day again my fellow readers! Today, I have read (well more like listened but I digress) an article titled, “Why Doctors Hate Their Computers”, from the New Yorker. It tells the findings of a Massachusetts doctor and his experiences when his employing hospital sends him to, “16 hours of mandatory computer training,” to learn the new electronic medical record system, EPIC. This experience then kicks off a search for the reason why these systems make doctors hate them, and the effects it has on those doctors.

The hospital was switching from proprietary software to the EPIC software and as the author has used the system, it has worn him out. To make a long article short, EPIC had added many more steps, clicks, and time to processes that had in the past, gone much quicker. The author mentioned that in the first month of the EPIC rollout in the hospital the IT Helpdesk logged 27,000 tickets. Working in an IT department currently, I may have done a spit-take when I heard this. The author also mentioned that because of these new systems, for every hour of patient interaction there are two hours of paperwork that has to be entered in the system. There was also a Mayo Clinic study that discovered a link between the burnout of doctors and the amount of screentime that they are subjected to. Bad software is literally driving doctors out of their career. This really surprised me. All of us have come up against some bad software design before, but I would never guess that bad software would cause someone to quit their career. As the article went on, the writer revealed that the software creators of EPIC tailor the software to the hospital utilizing it. For his hospital, meetings were held where both doctors and administrators were invited. I immediately thought that the culprit here was the administrators. The folks higher up, or in a different department got their hands in the part and got their interests, prioritized over the doctor’s ones. Then later in the article, he talked to the chief clinical officer at Partner’s Healthcare, who turned the argument on its head. The software is not for the doctors or the administration. It’s for the patient as more patients look at their records and visit notes and want more understanding. This gave me pause as I myself take advantage of these features as a patient. Having access to all this information is very comforting. I had to mull this over for a bit but I came to the conclusion that the patient should be the main customer in this scenario. The whole point of a hospital is to serve the patient and with how care is extending beyond the hospital, the software is going to reflect this. For the Software Capstone, I will be working with AMPATH on their EMR for charity work in Africa. In that scenario, patient interaction will stay primarily in the hospital. In such a scenario I would say that the software should be directed towards the doctor. This reasoning is because the major usability that the patient will get out of it, is not an option for the patient due to their situation. We will definitely leave the option to shift the priority to the patient but, at the moment it appears that the doctors are the current priority in this situation.

This was definitely an interesting article and the next time I visit my doctor I do have an inclination to ask what EMR that they use and how they “like” it.

Until next time readers!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Why Doctors Hate Their Computers Response

A lot of the times in the office, people can get easily frustrated with their tech. This article talks about how there seems to be some sort of disconnect between the technologies and the doctors. To start off, when a software is developed for a certain field, there are certain expectations and requirements that should be met depending on what the service is for. if you are delivering a software for a food business, you should expect it to handle some sort of client interaction along with employee interaction. This also can translate to mass scales where more and more people are using it. When a lot of people are using the same software, there should be a type of initiative to make it simple yet effective to use. If the software that is being developed for a specific purpose isn’t developed correctly or with those things in mind, it can sometimes be detrimental to that business’s practices. In this case, it was a matter of updating a lot of records and technology to keep the systems “relevant”.

In the case of a hospital system, the records are computerized and the new system that was being put in place would be able to handle a lot more. This is the reason why the upgrade was good. The new system would be able to deliver a single platform for recording and communicating medical observations, sending prescriptions to a patient’s pharmacy, ordering tests and scans, viewing results, scheduling surgery, and sending insurance bills. However, with these new systems seem to come a lot of overhead for the people using it. There were quite a few tensions that actually made it more difficult for doctors to get their jobs done. One of these tensions was between the doctors and administrative staff. Often times they disagree on what should and should not be included in the software. Sometimes the staff said adding certain procedures would be more time consuming. Certain fields that doctors didn’t have to fill out before were now being required due to administration simply telling them that they had to be done.

I feel as though the real customer in this situation seems to be the administration. Whenever a new system is implanted, hospitals often have to schedule less appointments just to accommodate for training of the new system. This puts, not only the patients, but doctors and other faculty way behind. From the article, it states that in the first five weeks of a new 1.6 billion dollar system upgrade, there were about twenty-seven thousand help desk tickets were just simple how to questions about the system. The lessons from this implementation don’t only apply to the Electronic Medical Records systems, but other systems dealing with these same mass software upgrades for facilities similar to hospitals. This reading has changed the way I think about the topic because although upgrading something to make it current, doesn’t always necessarily mean it won’t add additional overhead. I agree with the fact that upgrading systems can be important, especially when dealing with thousands of medical records because you want to keep things secure. But at the same time it is important to understand that there should be more efficient ways of training with these software to make them more accessible and understandable for the people using them.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

The Deep End || Sam’s Ships S.S.3

Sams Ships (2)On today’s installment of the individual apprenticeship patterns series, we’re going to discuss The Deep End. The main takeaway of The Deep End is that you should throw yourself into an opportunity even if you are hesitating or unsure. Of course, it is not necessarily telling you to be reckless, it also emphasizes how it is your responsibility to offset the risks of your approach.

I found that this pattern was interesting because as a person, I continuously try to say yes to trying new things or taking on new roles when the opportunity arises. The Deep End is basically the pattern that represents that mindset and reinforces how important trying something you might think is “risky” turns into being one of the best choices you ever made.

The pattern has caused me to change the way I think about software development/engineering based on the “action” it tells us to consider; which is learning to see what choices are affecting where our career is heading and eventually learn how to make choices based on it. I will try to focus on not only reflecting and reviewing what has happened but I will also move forward by actively making decisions based on experiences.

I do not disagree with something in this pattern so far as the “risks” I have taken so far have always turned out bettering me as a person or helped me achieve something greater. Things like taking on new roles within Enactus when I was unsure about how much time it would take on top of my already busy schedule to how to actually do things were part of my worries. In the end, it turned out alright because I was able to work things around my schedule and people who knew what the role(s) consisted of were there for me as a resource or form of support.

Overall, I am pretty content with the things I have jumped into because like Enrique from the Jumping in With Both Feet story, I eventually felt “like a fish in water.” I liked being able to read about someone’s success story of an instance where they went after something and thought “hey, the worst thing that could happen is I don’t like it and I fly back.”

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

First, do no iHarm

In this post, I will be commenting on the New Yorker article “Why Doctors Hate Their Computers” by Atul Gawande, from November 12, 2018. It focused on doctor’s frustrations with the transition to Electronic Medical Records, or EMRs.

Learning about this it has been surprising how painful the transition process has been. I have heard similar complaints from friends in the field, but I did not know how widespread it was.

By the sound of it, it is hundreds of little reasons that make the doctors’ lives harder. For one, it is much harder to add a simple note to a patients’ file. There is a lot of unnecessary information  that needs to be filled out, and many of these fields are mandatory. Another reason is that the computer gives the doctor arbitrary limits, like they cannot view lab results from a week before because their window for viewing it has expired.

Yet another reason is that the user interface is not very user friendly. It takes several more clicks than it should to do any one thing. The list of complaints seem to be endless, and unfortunately the issues brought up in the article are likely just the tip of the iceberg.

The real customer for the system is certainly not the two groups that would ideally benefit the most — the doctors (and nurses and the like) or the patients. It has made the doctor’s jobs much more difficult without much to show for it. The strain that it puts on the doctors are felt by the customers as well. There might be a few advantages, but most are marginal at best.

No, the real customer is the creator of the EMR systems. They stand to profit from it quite a bit. The fact that they were ridged to any outside influence to make the system better shows their true motives.

The lessons from the implementation from this system most certainly do not only apply to the Electronic Medical Record systems. The article touched on one of the patient’s experience in his own life working in construction. He echoed one of the complaints of his doctor, which was that the automated alerts created a signal fatigue, and the solution is to do the old school way of going back to picking up the phone over using the computer.

When I read about the doctor not being able to submit a form unless all the fields were complete, I thought about when I worked at the YMCA when I was sixteen. There was an extensive incident report that took forever to fill out, so consequently, we never used it save for major events. Of course, these were still done on paper, but if a paper could get in the way of doing our job properly, I have no doubt a much more complicated system would as well.

This reading has not changed my opinion because I was already aware on the topic. I have read up on it in the Boston Globe, and I have talked about it with friends who are in the field. The New Yorker article just confirms everything I have already thought about it.

I was hoping the article might forecast what might come. As they are now, EMRs are awful, but they are here to stay. They have only been around for a little over a decade most places. This is just the natural growing pains we have to get through in order to get to something that benefits us all.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Unleash Your Enthusiasm

For this week’s individual apprenticeship pattern, I chose Unleash Your Enthusiasm. This pattern talks about how to handle the enthusiasm you have for work. As a software developer, you will most likely work as part of a team. Most teams are not as passionate or overly enthusiastic about technologies anymore. Most of them are focused on delivering the next project and trying to improve aspects of the development life cycle that are causing them hindrances. That is why sometimes, unleashing your enthusiasm can get people rolling their eyes on you. Some teams are particularly not welcoming of newcomers. You should be careful when unleashing your enthusiasm. It is best to observe the team first.

I found it interesting that unleashing your enthusiasm is in the pattern. I was never really an enthusiastic person, I am more on the analyze first before I do anything side when it comes to enthusiasm. I am actually envious of enthusiastic people since they just speak their minds out and seem to not care what would happen. I always thought that being an enthusiastic person was really great but after reading this pattern it makes sense that you should be careful when unleashing your enthusiasm. Some people do not want to get bothered while working and can get easily annoyed by people asking them questions all the time. But there are also the opposites who loves hearing questions and giving you advice on what to do.

This pattern has caused me to think about ways to approach different people in the team. I think most teams have a diversity of behaviors and some would be welcoming than the other. I think that trying to get the feel for your team before you unleash your enthusiasm would be the best solution to this problem.

I totally agree with this pattern. I think it is good to know that not everybody is willing to listen to you and that you should approach the team carefully. I think you should still be enthusiastic, just be mindful of others. This pattern would definitely help anyone, not just software developers in their life.

From the blog CS@Worcester – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

Why Doctors Hate Their Computers

I thought that the article Why Doctors Hate Their Computers was incredibly interesting and eye-opening. Working in the software development industry, it is easy to think that software can easily replace many systems that are in use across a wide variety of industries. But as this article shows, complex software systems are not always a perfect solution. For example, the Epic electronic medical record system ended up creating more work for doctors because the software made the note-taking process longer and more redundant. While the system did increase patient benefits, those working in the medical field faced negative consequences that created more work, stifled innovation, and decreased face-to-face interaction with patients.

I thought that the most interesting part of this article was the idea that adaptation requires mutation and selection. The pre-computer systems of medical practice were all mutation and no selection, while computerization is all selection and no mutation. This analogy is a very succinct way of describing the advantages and disadvantages of using software systems. I think that software development companies and those in the medical field should work closer together to develop systems that are more customizable and less restrictive on doctors.

I think that the real customer for the system is the hospital administration. While the system did lead to better treatment for patients, which is obviously a good thing, it came at a large cost for the actual doctors. The system was developed mainly with input from the administration, so the focus was on decreasing costs and improving patient outcomes while the opinions of the doctors was ignored. I think that they should have worked more closely with doctors because they are the ones who actually have to use the software every day.

The lessons from the implementation of the Epic system apply everywhere. When developing any type of software, one of the most important goals should be usability. If a software program is not intuitive and easy to use, rather than being a powerful tool it becomes more of a burden. It is always relevant to take input from the actual people who will be using the software while it is being developed. As seen with the Epic system, if this is not done implementation of the software can have opposite of the desired outcomes.

Reading this article reinforced the idea that usability should be a primary goal when developing software. It is important to have other people use the software you are developing and take input from them. I think this article was very well-written. The author backed up his points well and I don’t disagree with anything in the reading. Overall I’m glad I read this article as it offered an interesting perspective and was both informative and entertaining to read.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

Why Doctors Hate Their Computers

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.

Apprenticeship Patterns – Finding a Mentor

As we will be looking for the best skill or training from masters, we need mentors or a mentors who we can look up to.

From the readings and with the understanding if got, finding a mentor is not all that easy, let alone mentors. As someone who want to be an apprentice or who is already an apprentice, he or she must be very careful choosing a mentor. Some of the things he or she must know before choosing a mentor(s).

  1. He or she must know her or his needs and also be very ready to be committed. Once he or she knows what he wants from the mentor then he starts searching. Only he know what things like dreams or desires and what type of person can help him get to where he wants to be. I also learnt from the readings, mentors do not have to be from the same company/industry, country or gender. One has to be more open minded to new possibilities by working outside of your comfort zone.
  2. To really succeed in the working world, one has to search for many mentors as possible. This helps you gain more skills from different areas. For example, you can be learning networking from a particular mentor whilst also learning another area like software programming from a different mentor. With that you are gaining a lot which does not limit you to a particular field or area.
  3. You need to choose very carefully when selecting a mentor. You don’t want to waste all your time learning things that will never be useful in your career. Also while carefully choosing for a mentor, one has to be sure he is very comfortable with the mentor.
  4.  As time passes on, your life evolves, your needs change and the desire for a new mentor may become apparent.  However, the mentors that helped you grow and prosper should never be ignored. Though you may now have different mentors, the relationships you formed with those from the previous chapters in your life must remain active.

From the readings, I got the understating i need not to rush in getting a mentor. When choosing one, i have to be very careful. I should not limit myself to only one mentor but to learn from many mentors. In that case, at least i gain a bit of knowledge in every field. One particular thing that interested me was “Passing along what you have learned from your mentors is one of the ways in which you can begin the transition to journeyman status.” From, i come to understand that in order for me to get to the top or to be a master, i have to also search the knowledge I have gain to others.

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

B3: Be The Worst

          The “Be The Worst” pattern is described as a way be able to keep learning after you begin to hit a roadblock and your rate of learning has plateaued. The book explains that the solution to this problem is to make sure you are around developers who are better than you and can help you identify your weaknesses by comparison. It removes the sense of comfort that builds up once an individual performs better and makes you recover faster from mistakes with more competent team members at your side. The learning process can become smoother through this pattern and allows the individual a better sense of understanding of their skills before and after joining the team. The goal is to not remain the weakest team member and to be constantly working hard to make sure that you can surpass your team members. This can lead to sudden risks of dragging the team down if you cannot catch up quickly enough and affect how you view yourself. The motivation of an individual is tested here as well how much stress one can endure and to push through for the eventual endgame.

          I found that this pattern is very relatable to me which in turn could be useful to apply into my daily life. I find it interesting how much of the situations the book brought up were so similar to problems I’ve faced in the past in terms of moving my skills up to the net level. I found that my learning had plateaued as well and didn’t really understand how to deal with it. The idea of removing my sense of comfort form my first language is thought-provoking because it seems to be very difficult for me to let go of my first language and move on to more difficult concepts. I have always loved learning Java, but this pattern as shown me to look past a single language and continue to grow with the industry. I still am hesitant to let go of my coding habits from Java but realize that I have to make this change immediately. I should surround myself with those that are better than me and try to survive in that environment to evolve my understanding of code at a faster rate. I agree with this pattern completely after fully understanding how it works and how to better my skills through my environment.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.