IT Analyst? What IT Analyst?
By Michael J Schuh, MTM Coordinator/Clinician, Assistant Professor of Family Medicine, Palliative Medicine, Pharmacy, Mayo Clinic
We all have been frustrated learning new software. We learn new software all the time. Well-designed software is easy to adopt because it seems like an effortless endeavor for the end user. The key and mouse commands fit well with the operational thought process of the end user and are analogous to past experience with similar software, so entirely new commands or process “language” are unnecessary or more straightforward to learn. This is usually made possible by IT analysts. Or should be…
Healthcare is complex. Not only is it complex, but the public, with a fast food mentality and short attention span, wants healthcare now and wants things to run smoothly. If the order is wrong at a fast food restaurant, it costs some extra time and a little frustration to correct the problem. In healthcare, it can cost a lot of time, a lot of money, and mountains of frustration to correct a problem. Fast food is a generally and arguably less complex business process because one is selling the same product type, and a standardized operation problem is usually at the store or at the employee level. In healthcare, one is selling diverse, highly skilled services and because these are highly skilled, dissimilar services where errors can cost much more in time and money, any information technology software mismatch at the service delivery level is exponentially multiplied. This can affect an entire health system, region, or division, costing millions in labor costs due to employee workarounds, extra training, system modification, or just inefficiency.
Where am I going with this? We know command driven software is more flexible than menu driven software. Great! However, it takes longer, maybe MUCH longer, in the case of an electronic medical record (EMR), for the end user to learn. Therefore, one would think vendors would provide many more IT analysts interfacing with the end user in the very beginning of customizing the software for the customer to better assimilate the language and processes of the end users into the language and processes of the software vendor. They don’t.
Healthcare is complex. Not only is it complex, but the public, with a fast food mentality and short attention span, wants healthcare now and wants things to run smoothly.
It has been the experience of this end user and colleagues that the IT analyst appears only midway or closer to software launch dates only after major work structures and processes in the software have already been decided by the vendor. One must then ask, is this a method to save money for the vendor? Having fewer IT analysts at the start, after the contract has been signed, saves money on paying analysts on the potentially more time-consuming front end than the less time-consuming back end of software implementation. Could it be simple templating of a standard software system? The one size fits all approach. Instead of starting with the end user and working up, it is a top-down approach. You take what the vendor offers and at some point downstream, the customer somehow figures it out. Again, shifting labor costs to the customer to sort it out after implementation causes inefficiencies in time and costs the customer much more money in the long run while saving the vendor money on paying analysts upfront. One doesn’t really know the real costs until later after these extra costs have been incurred in additional training and fixing end user workarounds.
When analysts are involved later in the software EMR implementation process, specific, embedded problems already exist that are more difficult to fix. In one example, it was discovered provider end-user schedule terminology was much different than scheduler end-user terminology and that the terminology of naming schedules all started with the exact same two to four terms, so in a smaller window, different services could not be identified properly. Result? Incorrect orders for incorrect services are scheduled in inappropriate time slots. How about learning dozens, if not hundreds, of new commands, viewed from the perspective of an IT employee, maybe an analyst, but not familiar with end users in that particular medical specialty? Result? End users in different specialties have no idea how to navigate their own operational workflow. If command icons are used, and many times they are, they may not be identifiable from an end-user perspective because maybe there was not enough research done on the front-end polling end users across specialties on the best icons to use. How about the frustration of siloed expertise of software trainers? Trainers seem to be good at their personal fiefdom but ask about an overlapping problem between their fiefdom and another fiefdom and one must play musical experts until one finally finds the one person with that body of overlapping fiefdom knowledge. Because of such software problems some medical providers have experienced in the past, some providers may jump ship for another employer or retire early. I know of one physician who did just that to avoid the frustration experienced again from a prior software implementation adventure.
How can IT analyst gaps be addressed to create more efficiency and lower costs to the customer after implementation? Maybe give more thought to menu versus command driven software decisions at different stages of the software design process. It is assumed the two methods can be combined. So, know when the command is appropriate for the process and when the menu may be more appropriate. If a system is command heavy, make the investment in the appropriate IT analysts in the beginning. Less expensive end-user education, fewer workarounds, less problem-fixing, and more productivity. Customers will appreciate it.