I’ve regularly seen the divide (sometimes really wide) between the programmer and technical people in an organization and the healthcare professionals. For example, a healthcare IT company recently emailed me about an issue they had with their main developer. They asked the insightful question, “Is it possible to find quality developers who are not, shall we say, “difficult”?”
There’s no simple answer to this question, but let me first suggest that this divide isn’t something that just happens between tech people and non-tech people. I’m sure many doctors feel the same way when dealing with other people who try and do their job. It turns out, people are hard to work with in general.
That disclaimer aside, tech people do like to think they’re in a tribe of their own. Check out this video which definitely comes from a programmer perspective and illustrates the divide that often exists.
Just the fact that the programmer feels like they’re considered a “code monkey” describes a major part of the issue. Much like I wrote about today on EMR and EHR, one of the keys is making a human connection as opposed to treating a programmer like a code monkey that’s just there to do your bidding. While there are exceptions, most people respond to someone who deeply cares about the individual and works to understand their needs as much as the project’s needs or their own needs.
The reason I think there’s usually a big divide between the healthcare people and the tech people is that it’s a real challenge for these two groups to connect. The healthcare people don’t want to talk about Battlestar Gallactica and Game of Thrones and the tech people don’t want to talk about Dancing with the Stars and The Voice. Yet, this is what needs to happen to build trust between the two different groups. It’s a rare breed that enjoys both.
If all of this fails, then try the nuclear option. Bring donuts. Most people can relate to donuts.
“The healthcare people don’t want to talk about Battlestar Gallactica and Game of Thrones and the tech people don’t want to talk about Dancing with the Stars and The Voice.”
Yes he did. He went there.
John,
The divide between the tech side and those they do the work for, and between techs and programmers, have existed since computers were invented. I won’t pretend that financial services companies have completely bridged these gaps, but successful financial firms do deal with it fairly well – and have for decades. Again, one more lesson that HealthIT could stand to learn from FinancialIT – if only HealthIT people weren’t so sure that no one outside their world has any experience or knowledge for them to learn from or were worth hiring.
Ron
Programmers have to remember that as physicians, we take an oath. Essentially “Do no harm” and we have a duty to protect our patients, and yes even from programs, IT and everyone else that has a financial interest in our care. I predict a massive failure over the next year or so as MU2 dies because of ramming speed, overreach and plain ole asking too much without necessary time to evaluate if its actually safe, effective and efficient. As someone that is well aware of programming and physicians, I can tell you a divide exists that will take years to smooth out. With pushing incomplete and basically dangerous “programmers” idea of what the product should be and not what works for the physician, this will be terminal for the MU and HIT program. The costs alone will be too much for physicians to bear with upkeep, updates and just basic system maintenance, let alone
the governments idea of what MU is . So remember programmers, we have a duty, an oath and we solemnly swear it and the whole system depends on that for it to work .
james,
You know it. Of course, I’m a techguy who runs blogs about some of those TV shows. Says something about me I think.
R Troy,
Yes, this is a universal problem that hasn’t been solved in healthcare (at least most of it).
Mike,
Definitely an important thing for programmers to remember. The best ones can and can actually help a doctor achieve that oath even better than they could without technology. That’s the goal, but many fall short and let politics or perspective cloud the decision making process.
This is a subject near and dear to my heart. Having come from other industries and having been a developer, I totally get how hard it is to create solutions to meet the needs of a user without being an expert. The best solution I have ever seen in any industry was when the subject matter experts in the industry decided to become programmers. They created a solution that was light years ahead of the competition because of their intimate knowledge of the needs of the industry. The next best thing to that is to have programmers get the end users super involved in the development of the solution. When I say super involved, I mean have physicians, nurses, practice administrators, insurance experts, billing experts and anybody else that will touch the system involved in every aspect of the project. They help design it, test it, provide feedback at early stages of development, etc. It’s a huge effort, but it pays off in the end. Those same experts helped create the standards for the industry, so their designs were all built around industry standards. It was a beautiful thing.
Great question! This is something my classmates and I have frequently discussed. I am a registered nurse and I will be receiving my master of science in health informatics degree this year; I have learned soo much from obtaining this degree. I truly believe that more clinicians need to become educated about HIT whether it be via a certification, a degree, or being directly involved with an HIT committee or various HIT projects where they work. With this degree I am hoping to use my clinical experience and find a position where I may serve as a liaison between the technical and clinical side of healthcare to improve patient care. Entering into this role should be encouraged more among healthcare professionals. There are many health care clinicians out there who like both, let’s say, Close Encounters AND The Voice…they just haven’t been discovered yet!
I think the “divide” can come about from people’s individual focus. Health care professionals want to get their job done and are usually not so interested in technology itself. Programmers build software and often delight in the technology. Performing well in these different areas requires different skills and ways of approaching situations, and some personalities are naturally better suited than others.
These two groups also have similarities: both are in highly technical areas, each with their own sub-cultures and languages (acronyms and specialist terminologies galore!).
To improve things? At the end of the day it is all about being open-minded and respecting each other for the knowledge and expertise they bring to the project. Spending time together in casual settings outside of work helps. Having a business analyst or user experience person can also help. Many UX people are good at being the bridge between the business/user side and programmers — they have good empathy — it is one of the most important attributes in our industry.
And yes, multiple qualifications/backgrounds can help — I was a programmer before moving into UX and when I say this at the start of a project, I observe the programmers instantly relaxing in relief. However, we are in a world that is changing faster than we can learn, so it’s more important than ever to collaborate.
Christine,
I think you’re rarer than you realize. No doubt there are others like you that like both sides, but not as many as you’d think. I came the other direction and like both shows as well.
Side Note: You may want to check our Health IT job board in your job search: http://healthcareitcentral.com/
Ming, I’ve seen that same relief when talking to programmers. It changes the experience when you can bridge the divide.
This is the exact reason that I am in the position that I am with our company. There is no better solution than to have a person in the industry be in a decision making capacity that also understands the in and out of development. I could code side-by-side with the best of the industry but at the same time can tell you the best way to perform environmental/public health tasks. The key in my opinion is to have more like myself out there. Without this knowledge of both areas, it is extremely important to have very detailed communication for requirements, turn those requirements in to action steps, turn those to a project plan, have scenarios to test the steps for developers and project managers alike. From feedback I receive, the most frustrating part of people trying to use the software is not feeling like the trainer or anyone on the software staff understand their needs. Without a SME, the scope creep gets out of control as people start to get in to the process or the functional needs are not met because the developers don’t understand. I was just at a conference this past weekend where the resounding issue brought up by clinicians was that their needs are not met (specifically related to med-onc and therapeutic radiation). In one case there are few solutions out there that meet their needs as a whole since they are only about 2-3% of the total billing in the hospital. They went with a solution that only deals in radiation and they have some parts that are great for their needs. The actual clinical dosing works great. The actual client documentation, MAR portion and VS documentation has all of the fields the need (for the most part) but is collected in a manner that doesn’t make sense and lacks interoperability with their medical center program. Especially in cases like this where there is a niche market, there is no way around getting an industry clinician from the specific industry to work on the product management team.
If we want people to use EHR as the theoretical way to make things more efficient, we have to consider how the data is captured. It makes the billing, scheduling and many other areas much more efficient. However, in most instances I have ever heard of, EHR software is making users less efficient when it comes to dealing with the actual patient encounter. I think bringing in a subject matter expert (SME) with CURRENT EXPERIENCE IN THE INDUSTRY and significant technical expertise is the only way to bridge this gap.
I’ve seen the same issue across the several vertical markets that I have work in over my career as a User Experience professional.
Companies create “engineering-centric” solutions without first understanding the background, needs and workflows of their users.
The answer is .. User-centered Design.
I would recommend that everyone read the book “The inmates are running the Asylum” by Alan Cooper http://amzn.to/1lyn447
They key to solving this issue is working with usability people to act as “translators” between the functional requirements as defined in functional specification, and the user requirements as defined by actual people that will be using the product.
Doing so, no only creates better, more usable solutions, but saves money too.
Bennett,
What you describe is interesting. The idea of a user centered designer doesn’t matter if the person is a programmer by background or a healthcare person by background, but that their sole focus is on creating the best interface.
I guess the problem with this idea is that we’re all biased by our backgrounds even if our sole focus is the best interface. It’s hard to take your background out of it.
Also, the other thing I’ve seen is that sometimes user centric designers get too artsy in their design and miss some of the practical that’s needed.
There is ownership in this divide on both or even all ends. Operations, healthcare professionals, technical experts (programmers) all approach their jobs from different perspectives based upon training, development, sheer segments of the brain. Arrogance about ones own skill is not a trait for only one part of the relationship, it is shared.
The essential element that I often see in the healthcare world is that the actual mission is not always made clear, evident, reinforced – treating patients! No matter the role we serve in that mix, from actual clinician, through technical support, the ultimate goal is the same, care for human beings. The best way to start resolving the divides and temper the arrogance is to clearly introduce and continually reinforce the end game for all positions on healthcare, patient health, well being and comfort.
I have been working in IT and in business for over 30 years. During that time, I’ve studied people in the work-force who I have come to call “High-Knowledge Workers”. High-Knowledge workers are generally people who are paid for what they know, not just what they know how to do. Programmers and Healthcare workers fall into the extreme ends of this group. High-knowledge workers tend to get frustrated and untrusting of anyone who does know what they know, or more importantly hasn’t had to learn what they’ve had to learn to succeed.
The divide between programmers and other people in the work-force has been raging since the beginning of time. It will continue to do so until people recognize that it takes all kinds of people to build truly effective solutions to problems. The gap is easier to bridge when the two groups of individuals that need to work together to develop solutions to problems consists of only one group of high-knowledge workers.
However, there are many examples of two groups of high-knowledge workers that have successfully worked together to develop solutions to problems. Someone mentioned the fact that the financial industry has been able to bridge this gap effectively for years. Being someone who has worked in the financial IT industry for much of my career, I can agree with that person. However, I have witnessed many times with that same bridge seems to have collapsed.
The solution to this problem that has consistently worked for me is to create a bridge of people who can relate to both groups of high-knowledge workers. Someone who thinks like a programmer, or at least a general engineer (which is basically what programmers are), but can also understand the needs and thought processes of a healthcare worker (someone who has the best interest of their patients and has actually sworn and oath to do no harm. People who can relate to and understand both of these groups can be hard to find within some organizations. But I have been successful in finding them in a number of organizations in many different industries over the years. I have found that you have to look in unexpected places sometimes, but they are always there somewhere.
Once you’ve found these people, you have to have someone who can facilitate the development of a strong relationship between them while putting them into positions to help the two groups work more effective together in developing solutions to the problems being faced.
This is not a simple solution. But it has been shown on numerous occasions to work exceedingly well. Finding someone to organize and mentor these groups of people is essential to success. But once the groups are working well together, you should start to see results that were previously unimaginable.
Mark Hilden
Have a Shark Tank event at the medical center or hospital. Invite technopreneurs to pitch in front of doctors, patients and adminstators.
The winners get to partner with a healthcare development team and pilot the idea in the health system for 6 weeks
Brigham and Womens,the Cleveland Clinic and others have launched the model. Results still too soon to tell.
See the discussion on LinkedIn for my 2 cents.
The missing part is the professional clinical informaticist. These are the experts in EHRS design, and can bridge the gap between software engineering and the intended clinical users.
Getting the right clinical informaticist(s) engaged (along with project managers and other “overhead”) sounds like an expensive proposition for a “translator”. However, getting to accurate engineer-able specs, and proper design, pays off in the long run.
The proper expertise can make all the difference…
I think a number of the respondents dance around this, but just want to add that it’s fairly simple and yet complex in practice. The bottom line is that there is a gap because each profession speaks a different language. This exists no matter what the industry and no matter what the profession. We all know there is a big gap between clinician and patient too for this exact reason! The way to help bridge the gap is by making sure each party is focused on the same desired outcome and each party lets the other apply their skills to get to that outcome. In the case of software development, does the developer know what the clinician wants to achieve? Does each party know each other’s constraints and drivers? With this common understanding, the gap is minimized to the point where each party can be allowed to do what they do to get both to the desired outcome.