Practice Wise 11/12/11

How is IT like Medicine?

When you have an issue with your software or on your network, what do you do? If you are a clinician or clinical support tech in a medical practice, you call for IT technical support.

When your patients have medical problems, what do they do? They call you. Patients hope that you will have all the answers and will be able to fix their problem in one phone call or office visit. You hope that tech support will push a button and fix your problem in one call.

How likely are you to find the etiology of the patient’s problem the first time you investigate it? How often do you expect that your tech support will? The old adage is that if you put 10 IT engineers in a room and give them all the same problem, you’ll get 10 different ways to approach it.

I don’t often hear this about medical providers, and I think that’s because medicine is a mature practice, IT as a well-defined discipline is still in its infancy.

Over the years, it’s been my mission to (a) help medical practices understand the nature of IT issues and how difficult they can be to resolve, and (b) to help the tech support community understand how to communicate technical information to the practices in a language they can understand.

Lately I’ve started using medical problem metaphors when describing technical issues to clinical staff. By gosh, they get it! Troubleshooting IT issues is a lot like diagnosing medical problems. When a patient presents at the doctor’s office, they rarely know their ICD-9 code. When a medical staff person calls their IT support desk, they rarely state that they’ve lost connection to their database server due to a failed ODBC connection or the loss of the local area network.

Both parties simply state that something is causing them pain. They can describe the pain in terms that they understand. In both cases, it’s our job to interpret that pain and alleviate it.

How does tech support do this? Start acting like doctors. EHR tech support can practice what they preach – apply EHR vernacular to EHR problems. Encourage the practice staff to start acting like patients in describing their symptoms.

Follow the flow of a visit note when troubl shooting IT issues:

• Chief Complaint: clinic staff – state what your pain is.
• History of Present Illness: what were you doing when the issue started, what were the behaviors (symptoms) that made you realize you had an issue?
• Physical Exam: IT staff, observe the user in their environment. Ask if they can reproduce the problem.
• Review Of Systems: IT staff – evaluate the problem by looking at the software, the user profile, the computer, the network, the server, etc.
• Past Medical History: Has this user/computer had problems in the past? Has the network had problems? Does the application have a history of problems? These are possible keys to what is happening now.
• Diagnosis: This is often a best guess, both for doctors – that’s why there are “rule out” diagnosis codes – and technical support staff. The art of diagnosis is a hard-won battle. Have patience. Sometimes the answer is not clear until much testing (trial and error) has been done.
• Rx: IT prescribes parts or processes to fix the issue. Patients follow the directions prescribed. If tech support tells you not to click on something and you click on it anyway, then you choose to break it. If you tell a hypertensive patient to change their lifestyle and take their blood pressure medication and they don’t, well then, they made a choice. It’s hard to keep people from causing their own pain.
• Services Performed: Communicate to the end user what you have done in terms that they can understand. A patient doesn’t understand the complexities of Latin diagnosis-speak. Clinical staff don’t understand the geek speak of TCP IP and database language either. Remember to use the KISS (Keep it Simple Stupid) method. Bring the explanation down to their level. You don’t look smarter just because you speak in a language your audience doesn’t understand.
• Services Ordered: If you as the local IT technician can’t fix it, you contact the vendor (hardware or software) for additional parts or support.
• Assessment and Plan: Tech support — summarize what you’ve found in clear, understandable terms and how you will work together to solve the problem. Client, adhere to your maintenance plan.
• Results: Measure the effectiveness of what you’ve done. Have you fixed the problem? Do you need to do more to get things working again? Is there a cure or ongoing management?

Today’s software products are exceedingly complex. The human body is, too. Both require that we listen to the complaint and work towards a mutually acceptable solution. Sometimes you have a diagnosis without a cure.

I’m not a doctor or an engineer, but I am someone who has travelled in both the clinical and IT worlds professionally. I know that this is a global communication issue that is easy to fix if we realize that we all speak the same language — sorta kinda.

ulie McGovern is CEO of Practice Wise, LLC.