This week, we were asked to read “Why Doctors Hate Their Computers“, and article written by Atul Gawande. It was a wonderfully written article that gave insight into the period of time where hospitals adopted the new Epic software system, and how they suffered through the process. It gave different outlooks on the computerization of enterprises, the pros and cons, and the contrast between human-centric work environments (adaptable ones) and computer-centric work environments. Adopting this technological overhaul was a major step in healthcare that hospitals across the nation decided to undertake. It came with training for nearly all employees, the hiring of technical staff, policy and routine changes for care providers, and a tremendous amount of headache.

The article dove into statistics of career satisfaction that healthcare providers in different specializations report. On average, doctors spent about 2 hours on their computer for every patient-facing hour the spend in the clinic. There was correlation found between this and job dissatisfaction, and especially between time spent on the computer and burnout rate, as reported using the Maslach Burnout Inventory. Doctors in specialties such as Emergency Medicine, who spend large amount of their time logging information into computers, reported significantly higher rates of burnout and job dissatisfaction when compared to a specialty like Neurosurgeons, even when they spent significantly less time at work. With the overhaul of Epic, doctors had to spend even more time on their computers logging patient information, often after hours and at home. Patients were booked for double the time slots they had previously been booked for, effectively halving the amount of patients seen per day. Not only this, but in a study done by the University of Wisconsin, it was found that the average workday for doctors increased to around 11.5 hours. While reading, it was pretty concerning to think about how these people who are trying to take care of others are doing so on such extreme schedules.

It wasn’t just learning curves that seemed to make the job harder on doctors. The senior vice-president at Epic, Sumit Rana, called one issue “the Revenge of the Ancillaries.” Since Epic was a system that would be used in every position in the hierarchy of the hospital, there were often disagreements regarding what administrative staff wanted the software to do and what doctors wanted the software to do. Since doctors had been used to calling the shots (for the most part) regarding patient healthcare, having restrictions placed upon them was a difficult thing. Not only was there the tension of having to learn and implement a new software system into their daily routine, but there was also tension “politically” in their work environment due to administration.

So who was the real customer for the system? I think it is clear to say it was hospitals, and the technology from a sales perspective was aimed at ease of use for doctors and administrative staff. However, Gregg Meyer, the chief clinical officer at Partner’s Healthcare who oversaw the introduction of Epic, put it really well in my opinion. “‘…we think of this as a system for us, and it’s not’, he said. ‘It is for the patients.’” Meyer is convinced that it will improve over time. The Epic system is new and absolutely massive. In 10 or 15 years, national EMRs will be far better than they are even today. There will be many of the same issues, however there is a tremendous amount of benefit that comes from it. According to the article, “In the first year of the study, deaths actually increased 0.11 per cent for every new function added—an apparent cost of the digital learning curve. But after that deaths dropped 0.21 per cent a year for every function added.” A system that does that seems worth the headache in my eyes. I hadn’t at all considered this viewpoint before reading this article, and it made great sense to me.

I think there is a lot that can be learned from this article far past the domain of hospitals, EMR, or even software in healthcare. The article referenced “The Mythical Man-Month” by Frederick Brooks which I found pretty interesting. It dives into the human aspects of software engineering and working in a computerized workspace. The actual development environment and technology used within the workspace has changed, however things like the scaling of collaboration and teamwork in a project-based environment have remained largely the same. Within the book, Brooks coined something called Brooks’ Law, which states that “adding human resources to a late software project makes it later.” Clearly even back in 1975, they knew a thing or two about the complexity of introducing and launching software products on a large scale — and the implementation of Epic was another example of exactly that.

This pattern, “be the worst” to my understanding means, we should surround ourselves with people who are very clever or know more about the subject or field you are in.

From the readings under “be the worst ” which says “what do i do when my rate of learning has leveled off?” You have taken the time to learn something new, immersed yourself in the subject matter, practiced diligently for a period of time and look up and see that you are ahead of those around you. Now what? There are only so many books, blogs, and other resources you can learn from until you reach a point where you must learn new skills from other humans. We are social creatures, by nature. We rely on each other to survive and part of that survival involves learning from each other. It’s difficult to imagine a world where we all had to learn everything on our own and couldn’t benefit from the knowledge and insight of those around us. So for us be connected with the world we need to learn from others. And also the is a saying not everything that we know, we learn from each other and by that we grow. So the more we learn from other developers, there more we grow as a developer. We can look for people who know more than we do and learn from them. We can also be in a team were you a the least among them. Knowing you are the least, you tend to work harder to keep up with them and also you get to learn new skill from them too.

From the readings “weakest member of the team, you should be working harder than anyone else”. There are risks associated with this strategy. You will be the least effective developer or person around the team. This also means your contributions will not be sufficient whereby dragging the team down. Because of this situation, team members may not put up with you very long. So putting all these risks into consideration, if you are really determined to learn, you will have to strive harder. In other sense, the only choice for you to stay in the team is to learn harder. That also means extra work for you.

Apart from all the risk involve, being the worst is a great way to improve your effectiveness in a given subject area quickly

Reading this pattern has made me know that in my own world i may feel i know everything till it get out of my world to see if really know everything or not. which knowing everything will never be the case. We all learn from each other. And knowing this idea, I will have to surround with people who are more challenging or better that me. Through that i get to learn new skill and better my self.