Going live with a healthcare software solution is an exciting & stressful milestone for a company — but it’s also when the real work begins. After the launch, you need a robust software triage process to ensure your tech solution runs smoothly and meets the client’s expectations.
Does this sound familiar? After the launch, you have all hands on deck and your client is watching you with eagle eyes. Bugs make the board dissatisfied, which makes your developers panic and create quick, patchy fixes that trigger more issues. Soon enough, the launch turns into a firefight — what if we told you there was an easy way to avoid this?
From our experience of 60+ projects, discovering bugs post-launch is nothing to panic about, just a consequence of changing environments and non-standard inputs. As long as you have standardized documentation processes, good communication with the client, and good analytical skills in your development team, you’ll be able to fix most in no time.
We at Vitamin refined this procedure to meet the industry standard. Join us to discover the best practices and prevent alarm bells about small bugs post-release.
The Triaging Process: A Step-By-Step Guide
No QA team or UAT process can catch all bugs and use cases during testing, so we need a system to resolve technical issues that only become apparent after deployment. It’s the only way to prevent downtime and disruptions in care delivery, so our work isn't over when we launch software.
Software triage can’t be a list of bugs on an Excel spreadsheet that get resolved when somebody in your development team has free time. It has to be a structured process to maintain client satisfaction and ensure your tech is doing what it’s supposed to — facilitating the jobs of healthcare professionals and improving patient outcomes.
Step 1: The Intake Process
When end-users report troubles with our software, the first point of contact is a non-technical customer support specialist. But even with their lack of experience with building software, they must collect detailed input about the bug.
The data they collect should include the affected workflow, provider, or patient note — whatever applies to your healthcare software — as well as screenshots whenever possible. A typical report will include issue details, description, and attachments like screenshots or error messages.
Assuming you’ve done your demos and documentation right, Tier 1 and 2 support will be on the IT staff of the user organization. Problems they can’t resolve themselves go to your engineering team.
Step 2: Root Cause Analysis
Once noted and described, harder-to-resolve bugs are escalated to the engineering team for Tier 3 support. At Vitamin, we offer this level to clients like Amplicare for problem-solving beyond the scope of standard CSS.
To tackle this level of software triage, the PM and Tech Lead team up for root cause analysis (RCA).
Engineers conduct a deep dive, often down to the code level, to find the exact cause of the reported bug. This process should generate a comprehensive report that provides clear proof of the problem’s origin — if there’s vagueness, it means the analysis wasn’t detailed enough.
Pro Tip: Apply RCA methodologies like the Fishbone Diagram or Fault Tree Analysis. Note each step, including the findings, analysis methods, and the reasoning behind conclusions.
Step 3: Categorizing Issues
Categorizing the problems found during healthcare software RCA lets you identify patterns and prioritize fixes. Sort them by severity, status, source, frequency, or lifecycle stage.
Remember that perceived errors carry different weights (not everything the end-user has a problem with is even a bug). For instance, if we’re building administrative technology for hospitals, here are the categories we may use:
- Defects — genuine bugs and errors that need fixing so the system operates as intended, like incorrect data display or non-responsive buttons.
- Desired functionalities — features that users expect but are currently missing from the system, like integrations with additional third-party apps.
- Wrong usage — instances where somebody uses the system incorrectly, causing it to misbehave, like entering data in the wrong fields.
Next, it’s time to choose the appropriate software maintenance and support activities.
Step 4: Decision-Making
Once we have a clear report, category, and proof of our analysis, somebody with a business hat takes over the final stage of software triage. They decide whether to:
- Fix the problem immediately, often at your own expense.
- Provide a workaround or an interim fix before the next release.
- Schedule the fix for a later time, balancing urgency and resources.
- Accept the potential loss of a customer if the report is deemed non-critical.
Even though it might sound crazy to lose a client over a bug, not all fixes are worth your time and workforce — and the board will understand that once you put it in numbers. Sometimes, the malfunction is your fault, and you must cover the cost of fixing it. But other times, you’re facing a case of feature creep or misaligned expectations, and you can’t do much about it. In either case, you know how much the issue costs to fix and make a decision that’s the best for the company.
Common Triaging Pitfalls to Look Out For
The Vitamin team has been in the development industry for over eight years, so we’ve seen our share of pitfalls in software maintenance and support. Let’s discuss them so you can learn from our mistakes instead of repeating them.
The biggest weaknesses are undoubtedly poor RCA and ineffective resolution. If your team can’t catch the root cause correctly or resolve it quickly, you risk low customer satisfaction, persistent bugs, and loss of revenue. You waste time and resources, and eventually, the hospital, payer, or group of patients won’t use your app anymore because the button keeps malfunctioning.
Another mistake we see in many companies in healthcare is ignoring user feedback or dismissing bugs they consider minor. The admin staff, nurses, doctors, or patients may lack your tech expertise, but they use this software daily. They should have a structured channel for reporting problems — and you should instruct and encourage them to do so before you launch software.
Then there’s keeping track of triage. If you don’t create a logbook of past bugs, you’re bound to repeat them. It’s the PM’s job to ensure software triage processes are noted and consulted during future projects.
Finally, remember to align technical fixes with business goals. No real-life user will care about cleaned-up code if it doesn’t get functionalities back on track. Know what to prioritize — issues that affect workflows and patient outcomes — and save technical nit-picking for the next time you launch a software version.
Key Takeaways for Post-Launch Success
A software triaging process is essential for any company operating in a live environment. That’s because customer satisfaction depends on your ability to swiftly and accurately address concerns, doubly so in high-stakes healthcare environments.
In healthcare software, it’s all about prioritizing key features, especially if you’re a smaller company working on a limited budget like ourselves. Need help determining what issues are critical? Schedule a consultation, and our Business Analyst will walk you through the necessary steps.
