As many in health IT know, medical software implementation specialists often spend a considerable amount of time working on site at the hospital, working hand-in-hand with the facility’s IT staff to ensure their products are working properly and to make sure the client has a good understand of how the technology can be used. Bernard Echiverri, a medical software implementations engineer, was kind enough to share his thoughts about his experiences working with clients in their environment and how one common problem – a lack of time – seems to be pervasive.
1. How much time each day was spent training others to use the software?
This can be very situational, but typically, relatively little time is spent on traditional training if the people I’m working with have attended any of our training events. The majority of time is spent working on actual implementation goals, but since we give the client the option to work collaboratively or to have us “own” the entire project, they often choose to work side by side and get trained as we architect and configure their environment together. It is more of an informal, on-the-job type training environment in these cases.
2. I assume you learn to see things more from a client’s perspective after working on site. What opinions that you had prior to working on site were changed completely after “walking a mile” in the client’s shoes?
I didn’t expect to find that our typical end-users have so many other responsibilities outside of building, managing and administering interfaces. Time is absolutely our most valuable resource, as you can’t create more, and you can never get it back once it has passed. Seeing how the people tasked with the enormous responsibility of architecting and monitoring an entire hospital’s application data flow juggle so many responsibilities, it made me realize how critical it is for them to have a product that is robust enough to handle the wide array of workflows smoothly, while providing them with intuitive configuration and administration user interfaces. It also brought home how we, as vendors, need to constantly evolve our product offerings and find ways to make our user experiences more efficient, and especially, more enjoyable.
3. Is there a common challenge that you have seen among the hospitals where you spent a significant amount of time working with and getting to know the IT staff?
Yes, I think there are a couple of common themes. One is simply not having enough time in the day to accomplish everything that needs to be done. I have yet to meet someone in the healthcare IT field who has said “I’m pretty much all caught up on everything and have nothing left to work on.”
Having tools that enable them to quickly identify the “gaps” between interface specifications, for example, and to test the logic needed to bridge those gaps is critical to accomplishing as many of their goals as they can, as quickly as they can. Similarly, being able to quickly identify and resolve potential issues before they become critical issues has been very helpful.
Finally, never underestimate the power of good documentation. Being able to document your workflow is incredibly helpful when you have a team of people working in the same environment, or when you are picking up where someone else has left off, and need to quickly understand their work.
4. What types of product enhancements or modifications have been made from knowledge you gained from working with clients?
I certainly can’t take credit for anything specific, but on the whole, everyone who is fortunate enough to have direct client interaction plays a role in relaying requests back to our joint team, which assembles weekly to discuss and prioritize such requests. Such changes range from simple aesthetics to ensure the GUI remains clutter free, to more significant changes, such as adding generic looping to the available logic actions (as opposed to specifically looping around known repeating structures in a parsed message). The latter was a change requested by a client several years ago that made such a compelling use case, that it made it into the product on the very next release.
To ensure the product still feels as “new” five years after going live as it does on day one, you must always take those “It would be nice if…” comments from clients seriously, and when it makes sense to do so, incorporate them into the product offering.
5. Talk about the collaboration involved with working on-site with a client. What kind of industry/technical knowledge were your clients able to teach you and what type of technical information do you feel you were able to share with them?
Having the privilege to sit down at a client’s site and work side by side with them in their environment is always informative.
From a client’s perspective, I imagine having someone on-site enabled them to rapidly ensure adherence to best practices; it also perhaps afforded them the ability to vet their ideas prior to implementation of new workflows to ensure the architectures were both scalable and manageable for the long-term strategies.
Learning the strengths and limitations of each of the applications our clients work with really helps identify what tools the team has at their disposal, in terms of interface capabilities such as configurable message encapsulation, transport protocols available, log file filtering, the ability to quickly find and resend specific messages, etc. Having this kind of information really helps us be more efficient when working with other clients that have similar environments and, in some cases, make recommendations on interface architectures or workflows that we wouldn’t have been able to anticipate otherwise.
As an implementation engineer working closely with a client team on-site, I can’t overstate how valuable it is to take every opportunity to listen to your clients and try to see their whole environment from their perspective. Only through maintaining that dialogue can you recognize opportunities to leverage your product to make your client’s lives easier — and that is really the best thing you can do for them.