Troubleshooting: WHEN and WHY?

When troubleshooting technical problems, I recommend answering six questions regarding the who, what, when, where, why, and how of the situation.  In this post, I will discuss WHEN and WHY.

When does the problem occur?

WHEN an issue occurs, it’s helpful to know the date and time of the onset, and if it is a recurring issue, how often it reappears.  At what point did it go from working acceptably to not?  Does it happen every time you perform a certain function?  Does it occur at the same time every day?  Is it constant?  Does it get better or worse at certain times of the day? 

Troubleshooting: WHAT and HOW?

When troubleshooting technical problems, I recommend answering six questions regarding the who, what, when, where, why, and how of the situation.  In this post, I will discuss WHAT and HOW.

What happened?  And how did it happen?

The WHAT of the problem is the specific issue and the HOW is context around it.  It’s great to write down or capture a screen shot of an error message, but that’s only part of the story.  Telling the help desk, “I got an error,” is like a patient telling a physician, “I am having pain.”  The doctor isn’t going to stop there, and neither will a technician.  The error message is WHAT happened, but the steps you took to get the error are the HOW.  Here are some examples of how the conversation with a technician could start:

Troubleshooting: Who and Where

When troubleshooting technical problems, I recommend answering six questions regarding the who, what, when, where, why, and how of the situation.  In this post, I will discuss WHO and WHERE.

Who does this issue concern?  And where does it occur?

Asking WHO and WHERE is important because it helps to understand how widespread or isolated an issue is.  Is it one user who gets an error message?  Is everyone noticing a delayed response?  Is one group of users experiencing the problem and not another?  You can figure out who is impacted by doing a quick survey or some cursory testing.

Troubleshooting: Keep It in Perspective

Merriam-Webster defines technology as “a capability given by the practical application of knowledge.”

So, if technology adds knowledge and capability to our lives, why does it often make us feel like all those “For Dummies” books were written just for us?

These days we take for granted that our work tools are going to get faster, smarter, and more efficient.  But every new feature, device, or integration can add a degree of complexity to the detective work that is necessary when something goes wrong.  How can we work through those error messages, performance issues, and other hiccups that occur on occasion while maintaining both our good humor and good sense?

On-Site vs. Hosted/Cloud Applications: Data Security and Technical Support

Regardless of where your data resides, it needs to be protected.  It may seem more secure to house your software and patient health information on a server within your facility, but this assumes you have well-maintained hardware, good backups, a bulletproof network, and secure remote access.  It seems scary for confidential data to be “floating around” the internet, but that’s not what really happens in a hosted environment.  Hosted systems are often as secure, if not more, than deployed, because of the dedicated performance monitoring, redundancy procedures, resilient connectivity, and both physical and virtual security measures.

On-Site vs. Hosted/Cloud Applications: Accessibility

If your system is housed on the servers within your facility, it seems that your access would be more secure, practical, and reliable than if it was in a data center in another state.  This, of course, assumes that your hardware is well maintained, your network is in good shape, and that your IT staff is on the ball.  If most of your staff drives to your facility and works in-house, then a deployed network system is ideal.  But these days many transcriptionists and other HIM professionals can work from home, so server-based in-house applications have to be made accessible to remote users in a secure, efficient way.  So, after all the time and money to set up a deployed system, you may have to expend further resources to ensure internet access that protects patient information while also facilitating quick turnaround.  If your organization prefers to have control over all aspects of infrastructure, connectivity, and security, then this is the way to go.

On-Site vs. Hosted/Cloud Applications: Functionality and Cost

Regardless of whether an application will be deployed on one of your servers or accessed across the internet in a hosted mode, you need to find out if the features the software offers will meet your needs.  Historically, deployed systems installed and managed within an organization have allowed for more flexibility and customization, but this isn’t necessarily the case anymore.  Although hosted solutions may be perceived as more “cookie cutter,” many of the up-and-coming hosted solutions have the same or nearly the same feature set as a deployed system.  For example, 3M’s ChartScript and ChartScript.com solutions have comparable feature sets, and they are becoming more similar with each release.  Take any system you are considering for a test drive to determine if it can accommodate your organization’s configuration preferences and workflow for all users, including dictators, transcriptionists, and administrators.

On-Site vs. Hosted/Cloud Applications: Home or Away?

Advances in networking, hardware, and software have created technology options for health information management that are similar to real estate decisions.  For example, investing in a dictation and transcription system might be a huge capital investment, like buying a house, but given the availability of hosted or cloud options, a technology investment could become more of an operational expense, like renting an apartment or paying utilities. As the healthcare documentation industry becomes more virtual and less tied to a physical office (a virtual work “home” away from a physical work “home”), it may be time to rethink how the technology systems we use every day are housed and accessed.

The traditional approach to dictation or transcription is a deployed solution, in which an organization purchases its own hardware, and the software that manages its data and workflow is installed directly on that organization’s hardware.  The software vendor provides support and upgrades for the system, usually for a fee, but routine hardware maintenance, storage, security, and upkeep is the responsibility of the organization.

Wishful Thinking: After Your Enhancement Request is Submitted

After you have submitted your idea, keep an open mind about how the idea is interpreted and implemented.  Your vendor may come up with several ways to accomplish what you need, and even though they may achieve the end result you are looking for, it may not happen in the same way you envisioned, but hopefully it is beyond your expectations.

Also keep in mind that not all enhancement requests are created equal.  Some are small and can easily be added to current projects.  Some are unrelated to anything else in the hopper and have to be tabled for a while.  Others are huge endeavors that would require big changes to internal architecture and logic.  Trust me, the companies you work with want to give you everything you ask, but they also want to do it in such a way that you will be happy with the final result.

Wishful Thinking: Essential Elements of an Enhancement Request

Every enhancement request should have three parts to be considered complete.  In my company, we use agile software development, and as part of that methodology, we create what are called “user stories.”  The three questions to ask when creating a user story are:

Who needs the new feature?

Would the idea benefit transcriptionists, coders, supervisors, senior managers, IT people, QA reviewers, or someone else?  Who will be doing this task?  This gives the idea a context for those who will design and develop the feature.