Brief description of the organization
Waterloo Regional Health Network (WRHN) supports the health and well-being of the communities of Waterloo Wellington and beyond. WRHN is home to 19 areas of care, including seven regional programs that serve patients across the province, in places like Brant, Bruce, Grey, Haldimand, Huron, Norfolk, Oxford, and Perth counties. With three hospital sites, five community sites, and more than 10 partner sites, WRHN is here for patients and families close to home. Our regional programs help care for more than 10 per cent of Ontario's population.
In 2024/2025, WRHN served more than 224,000 patients, providing nearly 741,000 visits. The care we provide supports children and adults of all ages and from many backgrounds through every stage of life. WRHN is committed to working with community members, partners, and local organizations to build a health network, shape services, and deliver care that meets the needs of the diverse and rapidly growing population we serve, now and in the future.
Problem area
Physicians in hospital practice are interrupted constantly by phone calls from nursing staff, allied health, pharmacy, and other clinical teams. A typical inpatient or on‑call physician may field 30 to 80 calls per day, the majority of which concern routine, low‑acuity matters such as medication clarifications, lab result acknowledgments, status updates, or scheduling questions. These interruptions fragment attention, degrade clinical decision‑making during high‑acuity work, contribute to physician burnout, and produce no auditable record of the communication that occurred.
At the same time, a meaningful minority of calls are genuinely urgent and time‑sensitive (critical lab values, patient deterioration, emergent consults), and the current system provides no structured mechanism to distinguish urgent from routine calls before the physician answers. Every call is treated identically, and the burden of urgency assessment falls on the calling party.
An intelligent communication support layer that captures incoming calls, transcribes them, and uses natural language processing to classify urgency, request type, and suggested handling would address this problem. Critically, such a system must be designed as physician‑facing decision support with human confirmation on any action affecting patient care, not as an autonomous triage system. Done well, this becomes an auditable, structured, workflow‑aware communication layer that preserves physician attention for high‑acuity work while ensuring routine matters are still addressed in a timely way.
There is significant potential for joint research publications (NLP performance characterization in clinical communication, workflow impact studies, physician burnout outcomes), grant funding through digital health and AI in healthcare innovation pathways, and eventual commercialization given the broad applicability of this problem across hospital medicine.
Main objectives
Speech‑to‑text accuracy in clinical context. Achieve transcription accuracy sufficient for downstream classification on clinical voice messages, including handling of medical terminology, drug names, numerical values (lab values, vital signs, dosing), and varied speaker accents and call quality. Target word error rate to be defined during requirements phase based on classification performance requirements.
Urgency and request type classification. Build a natural language processing pipeline that classifies transcribed messages along two axes: clinical urgency (high, medium, low) and request type (medication, lab result, status update, consult request, scheduling, other). Classification must produce calibrated confidence scores and route any low‑confidence cases to physician review rather than autonomous handling.
Physician‑facing decision support dashboard. Develop a clean, low‑friction interface that presents classified messages to the physician with full transcript, suggested response category, and one‑click options for callback, delegation, mark‑as‑done, or escalation. Every action that affects patient care requires explicit physician confirmation. The dashboard must be designed for use during clinical work with attention to interruption‑minimal interaction patterns.
Auditability and learning loop. Capture all calls, classifications, physician actions, and outcomes in a structured audit log. Provide a feedback mechanism that lets physicians correct misclassifications, with corrections feeding into model retraining or rule refinement. The audit trail must be designed to support quality review and downstream research.
Translational potential. Position the prototype for downstream regulatory pathway analysis (likely Health Canada Class I or II software as a medical device, FDA SaMD), peer‑reviewed publication, and engagement with hospital IT and digital health partners for pilot deployment.
Scope of work
Requirements definition and architecture design: Review the existing system architecture concept and prior art in clinical NLP, voice transcription, and physician workflow tools. Conduct structured stakeholder interviews with hospital physicians, nursing staff, and clinical informatics representatives to define functional requirements, classification taxonomies, and acceptable performance thresholds. Define the data strategy in collaboration with sponsor, WRHN privacy office, and research ethics board (synthetic data, de‑identified retrospective data, or other approved approach). Produce a formal requirements specification and system architecture document.
Component prototyping: Build initial prototypes of the three core components: speech‑to‑text pipeline (likely leveraging existing models such as Whisper or commercial APIs with clinical fine‑tuning consideration), NLP classification pipeline (urgency and request type), and physician dashboard wireframes with stakeholder usability review. Establish evaluation framework with held‑out test set.
Integration and refinement: Integrate components into an end‑to‑end prototype operating on synthetic or approved sample data. Build a mock or read‑only sandbox EMR integration to demonstrate how classified messages would surface alongside patient context. Refine classification performance through iteration on training data, prompt design, or model selection. Conduct usability testing with physician stakeholders.
Validation and final deliverables: Formal evaluation of the integrated prototype against the requirements specification, including transcription accuracy, classification performance (precision and recall by urgency tier, with attention to high‑urgency recall as the safety‑critical metric), and usability metrics. Document failure modes and edge cases. Produce final design documentation, code repository, evaluation report, and recommendations for downstream development pathway. Final symposium presentation.
Scope constraints: The capstone deliverable is a research prototype, not a clinically deployable system. The prototype will not connect to live WRHN clinical systems, will not handle real patient phone calls during the project period, and will not be used for any actual clinical decisions. Any handling of real or de‑identified patient data is contingent on REB and privacy office approval, with timeline and feasibility to be assessed during Term 1. Auto‑response capabilities, if developed, will be limited to suggested responses presented for physician approval, not autonomous actions affecting patient care.
Deliverables
End‑to‑end research prototype (transcription, classification, dashboard, audit logging) with full source code repository, accompanying design documentation package (requirements specification, system architecture, evaluation framework, performance report, failure mode analysis), and recommendations for downstream development including regulatory pathway considerations.
Team meeting frequency
Standard capstone milestone schedule with weekly or biweekly team‑led meetings as the team prefers. Sponsor available on flexible cadence based on project phase, with denser availability during requirements definition (Term 1) and usability evaluation (Term 3 to Term 4).
Skills and training required
Strong software engineering fundamentals (Python preferred), applied machine learning and natural language processing experience including practical familiarity with modern LLMs and transcription models (Whisper, Hugging Face transformers, OpenAI or Anthropic APIs, or equivalent), full‑stack web development for the dashboard component (React or similar frontend, basic backend API development), human‑computer interaction and usability evaluation methods, and an interest in healthcare informatics. Familiarity with privacy‑preserving ML, clinical NLP literature, or audio signal processing is an asset but not required. Comfort with ambiguous problem definitions and the ability to iterate on requirements with non‑technical stakeholders is more important than any specific technical skill.
Resources required
Sponsor will provide an initial system architecture concept (six‑component design covering voice capture, transcription, NLP classification, automated response, dashboard, and audit loop), structured access to physician stakeholders for requirements gathering and usability review, clinical domain expertise on call types, urgency criteria, and clinical workflows, sample call scenarios and synthetic data for prototype development, and clinical mentorship throughout the project. Sponsor will facilitate engagement with WRHN privacy office, research ethics board, and clinical informatics team for any work involving real or de‑identified patient data. Sponsor can also facilitate introductions to Communitech ecosystem partners and digital health collaborators where relevant for downstream pathway discussions.
NDA or a commercialization agreement for this project?
Yes