Problem Solving & Troubleshooting

February 2026 · 16 min

The FC as First Responder

When something goes wrong in a hospital ERP, the FC is the first person called -- not the developer, not the project manager. Staff will walk up to your workstation and say "the system is not working." Your ability to triage, diagnose, and resolve (or escalate) determines your credibility.

Issue Categories:

The 5-Step Triage Method

When a user reports an issue, follow this structured approach before diving into solutions:

Step 1 -- Reproduce Ask the user to show you exactly what they did. Watch their screen. 60% of "bugs" are user errors that become clear when you see the actual steps.

Step 2 -- Isolate Is it happening for one user or all users? One patient or all patients? One workstation or all? This narrows the cause:

Step 3 -- Categorise Is it a P1 (patient care blocked), P2 (workaround exists), or P3 (inconvenience)? This determines urgency.

Step 4 -- Resolve or Escalate If it is configuration or user error, fix it yourself. If it is a bug, log it with full details and escalate to the developer.

Step 5 -- Communicate Tell the user what happened, what you did, and when it will be resolved. Never leave a user hanging without feedback.

Bug Reporting Template

When escalating to the development team, a well-written bug report saves hours of back-and-forth.

Bad bug report: "Billing is not working." Good bug report: "When creating an OPD bill for patient MRN-2024-1052, adding consultation fee (500) + lab test CBC (200) and applying 10% insurance co-pay, the total shows 0 instead of 630. Steps: Open bill > Add services > Select insurance plan 'Star Health Gold' > Apply co-pay 10% > Total field shows 0. Expected: 630. Browser: Chrome 120, Production."

Common Bio Ecko Issues & Fixes

After working with Bio Ecko across multiple implementations, these are the most frequently reported issues and their resolutions:

Data Investigation Techniques

When configuration and user error are ruled out, the FC may need to investigate data. Bio Ecko uses Supabase (PostgreSQL), and the FC should know basic data inspection:

Safe Investigation Rules:

• NEVER run UPDATE or DELETE queries on production without developer supervision
• Always use SELECT with LIMIT to avoid pulling huge datasets
• Always filter by specific patient_id or visit_id -- never scan full tables
• Screenshot your query and results for the bug report

Useful Investigation Patterns:

1. Check patient's visit history: Find all visits for a patient by MRN to verify data continuity
2. Verify bill line items: Check billing_items for the specific bill_id to see if charges were added correctly
3. Track order status: Check lab_orders or radiology_orders for status field (pending, in-progress, completed, cancelled)
4. Audit trail: Check who changed what -- look at updated_at and updated_by fields on the record
5. Duplicate detection: Search for patients with same phone number or same name + DOB combination

When to Escalate Data Issues:

• Data corruption (fields that should never be null are null)
• Cross-table inconsistency (bill exists but visit does not)
• Performance degradation (queries timing out)
• Security concern (user accessed data they should not have)

Escalation Matrix & SLA

Every issue must be resolved within a defined SLA. The FC is responsible for tracking and ensuring compliance:

Escalation Protocol:

1. First 15 min -- FC attempts self-resolution (config fix, user retraining)
2. 15-30 min -- FC logs bug with full details, assigns to developer
3. 30-60 min -- If P1, FC calls Dev Lead directly (phone, not email)
4. 1-2 hours -- If still unresolved, FC informs Project Manager and hospital POC
5. 2+ hours -- PM escalates to steering committee; rollback plan may be activated for P1

Post-Incident Review

After every P1 or P2 incident is resolved, conduct a post-incident review (PIR) within 48 hours:

PIR Template:

The 5 Whys Technique: Keep asking "Why?" until you reach the root cause:

1. Why did billing show 0? -- Because the co-pay calculation returned null
2. Why did it return null? -- Because the insurance plan field was empty
3. Why was it empty? -- Because the plan was not mapped to this TPA
4. Why was it not mapped? -- Because the new TPA was added after master data freeze
5. Why was it not caught in UAT? -- Because the test case did not cover newly added TPAs

Root Cause: Incomplete test coverage for new master data entries. Fix: Add regression test for any master data added after freeze date.

Notes

Related topics