These examples show how I approach operational problems, workflow design, validation, and practical delivery. They are written at a concise level to respect confidentiality while showing the type of work I have done.
Case Study 1
Copilot-assisted QA workbook workflow
KPMG Canada
Background
In my current role supporting KPMG Canada’s RPA team, part of my work involves testing new processes and change requests, coordinating UAT, and validating business logic before release. Within that context, I saw an opportunity to improve how QA EA test-plan workbooks were prepared.
Problem
Workbook preparation involved repeatable structure but still required significant manual setup. The challenge was not only efficiency, but also how to use AI assistance without weakening QA ownership over coverage, logic, and final quality.
Constraints
The output needed to remain reviewable and usable in a real QA workflow. Accuracy, formatting, hyperlinks, coverage, and business logic still required human validation, so the workflow could not simply rely on model output without control points.
Solution
I designed a structured Copilot-assisted workflow for draft workbook preparation using reusable prompts, template inputs, organized source views, and review checklists. The goal was to generate a more complete first draft while preserving QA control over logic, completeness, formatting, and final validation. Rather than replacing the QA process, the workflow was designed to support it with more structure and consistency.
Validation
The workflow was reviewed through QA ownership checkpoints, including coverage review, hyperlink and formatting checks, logic review, and final output validation. This kept the generated draft within a controlled review process rather than treating it as a finished deliverable.
Reflection / Next Step
This experience reinforced my interest in human-in-the-loop workflow design. If I were to extend it further, I would formalize the workflow into a more reusable internal asset with clearer input patterns, output evaluation criteria, and versioned prompt or template guidance.
Case Study 2
Schema synchronization automation
St. Teresa’s Hospital, Hong Kong
Background
At St. Teresa’s Hospital, I worked on a downtime-related pharmacy workflow that depended on data migration between source and target databases in a production-sensitive environment.
Problem
The process was manual, high-risk, and difficult to rely on during outage scenarios. It needed not only data copying, but also a way to keep target-side table structures aligned with the source system before migration.
Constraints
The workflow had to operate safely in a real operational environment, handle multiple tables in sequence, reduce human error, and surface failures clearly enough for support follow-up. This was not treated as a casual internal script.
Solution
I developed a VB.NET and T-SQL tool that loaded a configured table list, retrieved schema metadata from source and target databases, compared structural differences, and updated the target schema by creating missing tables or adding missing columns before copying data. The workflow was designed to make migration more repeatable and reliable rather than depending on manual intervention at each step.
Validation
The implementation used ordered processing, transaction-based schema updates, logging, and error alert handling to support safer execution. This aligned the solution with operational reliability rather than simple one-off automation.
Reflection / Next Step
If I were extending this further, I would add clearer execution reporting, stronger rollback visibility, and more explicit monitoring around migration outcomes and exception categories.
Case Study 3
Patient allergy API logic fix
St. Teresa’s Hospital, Hong Kong
Background
In the same hospital environment, I encountered a long-standing issue affecting patient allergy data. Because clinicians relied on this information, the problem had implications beyond a typical bug and needed a dependable resolution.
Problem
The issue was difficult to reproduce consistently and had remained unresolved over time. The challenge was to move beyond surface symptoms, identify the true cause, and implement a fix that would restore reliable downstream data usage.
Constraints
This was a live healthcare context, so correctness and trust were essential. It was not enough to produce a temporary patch; the fix needed to be logically sound and validated in a way that reduced the risk of introducing new issues into a critical module.
Solution
I approached the issue through root cause analysis rather than symptom chasing. By tracing the data flow and reviewing API behavior, I identified that the logic was calling an incorrect endpoint for the scenario. I then modified the logic to use the correct API path and treated the work as a full quality cycle rather than a narrow code change.
Validation
After implementing the fix, I designed and executed regression testing to confirm not only that the issue was resolved, but also that related behavior remained stable. This helped restore data integrity and confidence in the affected workflow.
Reflection / Next Step
This case strengthened my instinct to think in terms of hidden failure points, data correctness, and edge cases. If I were taking it further, I would want stronger diagnostic visibility around similar API-dependent flows so that future issues could be detected and isolated faster.