No products in the cart.
MODULE 17: TRAINING & END-USER SUPPORT
Section 17.4: Help-Desk Tiers and Ticket Resolution Workflow
Explore the architecture of a sustainable, long-term support model. We’ll deconstruct the tiered help desk structure and the lifecycle of a support ticket, ensuring users have a clear, reliable, and efficient path for getting help.
SECTION 17.4
Help-Desk Tiers and Ticket Resolution Workflow
From Frontline Triage to Deep Diagnostics: Engineering a World-Class Support System.
17.4.1 The “Why”: Beyond a Complaint Hotline — Support as a Clinical Safety Net
The “Go-Live” is over. The command center has been dismantled, the informatics trainers have moved on to the next project, and for the first time, the clinical staff are using the new system on their own. It is in this moment that the true measure of your project’s success begins to unfold. And it is in this moment that the end-user support structure—the help desk—transitions from an afterthought to the single most critical lifeline for your users and your system.
It is a catastrophic mistake to view the help desk as a mere “complaint department” or a necessary evil. A properly engineered support model is not a passive cost center; it is an active, dynamic, and indispensable component of the hospital’s clinical and operational infrastructure. A well-run help desk is a real-time patient safety system, a continuous quality improvement engine, and the primary source of business intelligence for the future of your EHR.
Consider the chaos of an unstructured support model, which is the default in many organizations. A frantic nurse can’t scan a medication, so she calls the pharmacy. A pharmacist gets a strange alert and calls the cell phone of an analyst he knows. A physician is frustrated with an order set and complains to the CMIO in the hallway. In this model, there is no tracking, no prioritization, no data, and no shared learning. Problems are solved (maybe) for one person, at one moment in time, but the system itself never improves. This is not a support model; it is a state of perpetual, reactive crisis.
A structured, tiered help desk system brings order to this chaos. It provides a single, predictable front door for all issues, ensuring that every problem is captured, categorized, prioritized, and routed to the person best equipped to solve it. This structure provides immense value:
- Patient Safety: It ensures that a critical issue—like a system bug preventing the administration of a STAT antibiotic—is immediately identified and escalated, rather than getting lost in an analyst’s voicemail.
- Efficiency: It protects your most valuable and expensive resources—your senior application analysts—from being consumed by basic, repetitive “how-to” questions. It allows them to focus on complex problems that truly require their expertise.
- Data-Driven Improvement: Every interaction, or “ticket,” becomes a data point. When you can systematically track and analyze these data points, you can move from fixing individual problems to solving systemic ones. You can identify which workflows are causing the most confusion, which alerts are firing most often, and which departments are struggling the most. This data is gold; it is the blueprint for all future optimization efforts.
- User Satisfaction: A clear, reliable process for getting help reduces frustration and builds trust in the IT department and the system itself. When users know their issues will be heard, tracked, and resolved, they are more likely to be partners in the system’s success.
This section will provide the masterclass on how to architect this system. We will deconstruct the tiered support model, trace the lifecycle of a support ticket from creation to closure, and define your role as a Pharmacy Informatics Analyst within this critical ecosystem. You will learn to see the help desk not as a burden to be endured, but as a strategic asset to be leveraged.
Retail Pharmacist Analogy: The Pharmacy Workflow as a Tiered Support Model
Your retail pharmacy already operates on a sophisticated, multi-tiered support model every single day. You just don’t call it that. It’s simply your workflow for handling patient “tickets” or requests safely and efficiently.
Tier 1 Support: The Pharmacy Technician. A patient comes to the drop-off window and asks for a refill on their lisinopril. This is a common, straightforward request. The pharmacy technician is your Tier 1 support. They have the training and system access to handle this request independently. They can receive the request, enter it into the system, and resolve the “ticket” by telling the patient it will be ready in 15 minutes. The pharmacist is not involved. This is your “First Call Resolution,” and it is incredibly efficient.
The Escalation: The technician processes the refill, but the system flags a “Refill Too Soon” rejection. The technician cannot resolve this. They do not have the clinical knowledge or authority to override it. Their job is not to guess; their job is to escalate. They gather the necessary information (when was it last filled, why is the patient requesting it early?) and create a “ticket” for the next level of support.
Tier 2 Support: The Staff Pharmacist. You are Tier 2 support. The technician hands you the ticket. You have a deeper level of knowledge and a higher level of system privilege. You talk to the patient and discover they are going on vacation. You perform a clinical assessment, determine an early refill is appropriate, and use your professional judgment and system overrides to resolve the rejection. You have just solved a more complex ticket that was beyond the scope of Tier 1.
Another Escalation: Later that day, you receive a prescription for a new, ultra-high-cost specialty drug. The system returns a rejection you’ve never seen before, mentioning a “clinical documentation requirement for the PBM’s medical affairs department.” You’ve called the insurance help desk, and they are unable to explain the specific requirements. You are now stuck. This problem is beyond the scope of your daily operational expertise.
Tier 3 Support: The Corporate Payer Specialist / Clinical Lead. You escalate this issue to your corporate support team. This is Tier 3. This team consists of specialists who deal with these complex payer issues all day. They have relationships with the PBMs, access to different internal knowledge bases, and the time to spend two hours on the phone navigating the payer’s bureaucracy. They do the deep diagnostic work, discover the required form, help the prescriber’s office fill it out, and ultimately resolve the issue. They then document this solution and share it with the other pharmacies in the district, building the corporate knowledge base.
This entire, seamless workflow—of technicians handling the simple, pharmacists handling the clinical, and corporate specialists handling the esoteric—is the essence of a tiered help desk. It ensures that problems are solved at the right level, by the right person, in the most efficient way possible.
17.4.2 The Architecture of Support: Deconstructing the Tiered Model
The tiered support model is the industry-standard framework for organizing an IT help desk. It structures support into distinct levels, or tiers, based on the complexity of the issues and the skill level required to resolve them. The primary goal is to resolve as many tickets as possible at the lowest, least expensive tier, escalating only when necessary. This maximizes efficiency and ensures that expert resources are used wisely. While models can vary, a mature healthcare IT support structure typically involves four tiers.
Masterclass Table: The Four Tiers of Healthcare IT Support
| Tier | Primary Role | Staffed By | Scope of Work | Key Metric |
|---|---|---|---|---|
| 0 | Self-Service | The End-User | Empowers users to solve their own problems through high-quality documentation. Includes FAQs, searchable knowledge bases, QRGs, and Tip Sheets. | Ticket Deflection Rate. The percentage of issues resolved without a user needing to contact the help desk. |
| 1 | First Response & Triage | General IT Help Desk Staff | The single point of contact. Logs all tickets. Resolves basic, high-frequency issues like password resets, printer mapping, and simple “how-to” questions using scripts and a knowledge base. | First Call Resolution (FCR) Rate. The percentage of tickets resolved during the initial phone call or interaction. |
| 2 | Application & Workflow Support | Application Analysts (You!), Super-Users | Handles issues escalated from Tier 1 that require deep application-specific knowledge and clinical workflow understanding. Investigates unexpected system behavior and user errors. | Resolution Time. The time it takes to resolve a ticket after it has been assigned to the Tier 2 queue. |
| 3 | Deep Technical & Vendor Support | Senior Analysts, System Engineers, EHR Vendor Support (e.g., Epic, Cerner) | Handles the most complex issues escalated from Tier 2, such as suspected software bugs, database problems, or issues requiring code-level analysis. Manages the relationship with the software vendor. | Time to Escalation & Vendor Response Time. The speed at which critical bugs are identified and addressed by the vendor. |
Tier 0: The Foundation of Self-Service
The most efficient and cost-effective support interaction is the one that never happens. Tier 0 is not a group of people; it is a philosophy of empowerment. It involves creating a rich, intuitive, and easily accessible library of resources that allows end-users to find answers and solve problems on their own. Every ticket that is “deflected” by a good Tier 0 resource is a direct saving of time and money for the organization. As a training and informatics specialist, building and maintaining Tier 0 resources is a core part of your job.
Components of a Robust Tier 0 Strategy:
- A Searchable Knowledge Base: This is the heart of Tier 0. It is an internal database of articles, each one addressing a specific problem or question. Every time a Tier 1 or Tier 2 analyst solves a new problem, the final step should be to create a knowledge base article so the next person with that problem can find the solution themselves.
- Intranet Portal with FAQs: A well-organized FAQ page that addresses the top 10-20 most common questions can handle a huge volume of inquiries.
- Embedded Help & Tooltips: Working with the build team to embed context-sensitive help links or tooltips directly within the EHR can answer a user’s question at the exact moment they have it.
- Repository of Training Materials: All QRGs, Tip Sheets, and recordings of training sessions should be stored in a central, easy-to-find location.
Tier 1: The Front Door
Tier 1 is the public face of the IT department. They are the operators, the dispatchers, and the first responders. Their primary tools are excellent customer service skills, a robust ticketing system, and a comprehensive knowledge base provided by the Tier 2 and 3 teams. The goal of Tier 1 is to resolve a high percentage of issues on the first contact. They are trained to follow scripted solutions for common problems.
A Day in the Life of Tier 1: They answer the phone with a standard greeting. They listen empathetically to the user’s issue. They create a detailed ticket. They then search the knowledge base for a matching solution. If a solution exists (e.g., “How to Reset Your Password”), they walk the user through the steps and close the ticket. If no solution is found or the issue is outside their scope, their job is to triage the ticket correctly (assign a priority and category) and escalate it to the appropriate Tier 2 team (e.g., Pharmacy, Lab, Nursing).
Tier 2: The Clinical and Application Detectives (Your Role)
This is where you, the Pharmacy Informatics Analyst, primarily live. Tier 2 support requires a blend of deep application knowledge and rich clinical context that Tier 1 does not possess. You handle the issues that are not in the script. Your job is to be an investigator.
Common Tier 2 Pharmacy Tickets:
- “A nurse is getting a ‘Drug Not in ADC’ error for a medication that I know is in the cabinet.” (This requires you to investigate the ADC profile, the EHR medication record, and the interface between them).
- “The system is firing a duplicate therapy alert for Tylenol and APAP. That’s the same thing. Can you fix it?” (This requires you to understand how the drug database and alert logic are configured).
- “I can’t find the new anticoagulation reversal order set for my patient.” (This could be a user error, a security issue, or a build problem).
- “The system calculated a strange dose for my pediatric patient’s amoxicillin. I don’t think it’s right.” (This requires you to be both a pharmacist and an analyst, checking the patient’s data, the order sentence build, and the underlying dose calculation rules).
Your goal is to resolve these complex workflow and application-specific issues. If you determine the system is not working as designed, and you suspect a software bug or a server-side problem, your role then becomes to meticulously document your findings and escalate the issue to Tier 3.
Tier 3: The Deep Technologists and Vendor Liaisons
Tier 3 is the highest level of internal and external support. This tier is composed of senior analysts with specialized technical skills (e.g., database administrators, interface engineers) and, most importantly, the EHR vendor’s own support team. Issues that reach Tier 3 are typically complex, system-wide, and require access to the back-end of the application or the source code itself.
Your Interaction with Tier 3: As a Tier 2 analyst, you will be the primary person who interacts with Tier 3 for pharmacy-related issues. This is a skill in itself. When you log a ticket with your EHR vendor (e.g., a “Case” with Epic or a “Service Request” with Cerner), you must provide exquisitely detailed, objective information. This includes the exact user who had the issue, the specific patient, the exact time it occurred, screenshots of the error, and a step-by-step description of how to replicate the problem. A well-documented vendor ticket gets resolved faster. A vague ticket will result in days of back-and-forth emails asking for more information.
17.4.3 The Lifecycle of a Support Ticket: From Phone Call to Solution
Every issue reported to the help desk becomes a “ticket” (also known as a case, incident, or record). A ticket is the official electronic record that tracks an issue from its initial report to its final resolution. Understanding the structured journey of a ticket is essential for ensuring that issues are handled efficiently, accountably, and transparently. This lifecycle provides the framework for the entire support operation.
Stage 1: Ticket Logging & Creation — The Foundation of Data
This is the first and most critical step. A ticket that is logged poorly is almost impossible to solve efficiently. Whether the ticket is created by a Tier 1 agent on the phone, or directly by an end-user through a self-service portal, a set of core information is absolutely essential. Your ticketing system should be configured to require this information.
Anatomy of a Perfect Ticket
- User Information: Who is reporting the issue? (Name, department, contact info). This should be auto-populated if the user is logged in.
- The “Affected User”: Is the person reporting the issue the one who actually experienced it? (A manager might call on behalf of a staff member).
- A Clear, Concise Title: “Error when verifying TPN” is much better than “Computer broken.”
- Detailed Description of the Problem: This is the narrative. It should answer three questions: 1) What were you trying to do? 2) What did you expect to happen? 3) What actually happened instead?
- Patient Context (if applicable): The specific Medical Record Number (MRN) or patient encounter. This is non-negotiable for investigating clinical issues.
- Location: Where did this happen? (e.g., Main Pharmacy, ED Satellite, 5th Floor Med Room).
- Timestamps: The exact date and time the issue occurred. This is crucial for searching system logs.
- Urgency & Impact (The User’s Perspective): How is this affecting their work or patient care right now?
- Attachments: Screenshots, screenshots, screenshots. A picture of an error message is worth a thousand words.
Stage 2: Triage, Categorization & Prioritization — Bringing Order to Chaos
Once a ticket is created, it enters the triage queue. This is where a Tier 1 agent or a queue manager makes several critical decisions that will determine the ticket’s entire path.
Categorization: The ticket is assigned a category and sub-category (e.g., Pharmacy > Automated Dispensing Cabinet). This ensures it gets routed to the correct Tier 2 team and allows for meaningful data analysis later.
Prioritization: This is the most important triage function. The priority of a ticket determines how quickly it must be addressed. This is not based on who is yelling the loudest; it is based on a formal, objective matrix that combines Impact (how many users or systems are affected?) and Urgency (what is the risk to patient safety or core hospital operations?).
Masterclass Table: The ITIL Priority Matrix
| Impact / Urgency | High Urgency (Direct patient safety risk, core system down) |
Medium Urgency (Workflow disruption, no immediate safety risk) |
Low Urgency (Cosmetic issue, inconvenience) |
|---|---|---|---|
| High Impact (Entire hospital or department affected) |
P1 – CRITICAL | P2 – HIGH | P3 – MEDIUM |
| Medium Impact (A group of users affected) |
P2 – HIGH | P3 – MEDIUM | P4 – LOW |
| Low Impact (A single user affected) |
P3 – MEDIUM | P4 – LOW | P4 – LOW |
Examples:
- The interface between the EHR and the pharmacy ADCs goes down for the entire hospital. (High Impact, High Urgency = P1 – CRITICAL).
- The label printer in the IV room is not working. This affects the entire IV room staff but not the rest of the pharmacy. There is a backup printer, but it’s slow. (Medium Impact, Medium Urgency = P3 – MEDIUM).
- A single pharmacist reports a typo in the title of a report. (Low Impact, Low Urgency = P4 – LOW).
Stage 3: Investigation and Resolution — The Analyst’s Work
Once a ticket is assigned to your Tier 2 queue, your investigative work begins. This process should be as systematic as a clinical workup.
The S.O.A.P. Note for Tickets: Document Everything
Every action you take should be documented in the ticket’s work notes. A great way to structure this is like a clinical S.O.A.P. note:
- Subjective: Restate the problem in your own words, based on the user’s report. “User reports being unable to find the new reversal agent order set.”
- Objective: State your objective findings. “Logged into the training environment as the user. Navigated to the patient’s profile. I was able to successfully find the order set by searching for ‘antidote’. User was searching for the brand name, which is not yet in the synonym list. Attempted to replicate on two other profiles; behavior is consistent.”
- Assessment: Your diagnosis of the root cause. “This is not a system bug. The issue is a combination of user error (searching for the wrong term) and a content gap in the search synonym build.”
- Plan: What you did to resolve it and what you will do for long-term prevention. “1. Called the user and walked them through searching by the generic name. They are now able to place the order. 2. Submitted a separate enhancement request ticket to have the brand name added to the search synonyms. 3. Emailed the pharmacy department with a Tip Sheet on how to search for the new reversal agents. Closing this ticket.”
Stage 4: Closure and Confirmation — Closing the Loop
A ticket is not truly resolved until the end-user agrees that it is resolved. The final step before closing a ticket is to communicate with the user. This can be a phone call or an email that clearly states what was done to fix the issue and asks for their confirmation that it is working. This simple act of “closing the loop” is vital for customer service and user satisfaction.
Upon closure, the system should automatically send a satisfaction survey. This data, while simple, provides crucial feedback on the performance of the help desk and individual analysts.
Stage 5: Knowledge Creation — The Virtuous Cycle
The final, and most often skipped, stage of the lifecycle is knowledge creation. For any ticket that represents a new problem with a reusable solution, the analyst should be responsible for creating or updating a Tier 0 knowledge base article. This is the mechanism that makes the entire support system “smarter” over time. The work you did to solve one person’s problem can now prevent ten future phone calls, transforming a reactive support event into a proactive, system-wide improvement.
