From Legacy Portals to Data Pipelines: Safe Water with Browser Automation

Public health work relies heavily on digital systems to support surveillance, reporting, and operations. In practice, this often means working within web-based portals accessed through a browser. Many of these systems were not designed with automation or modern data integration in mind. As a result, routine tasks can consume substantial staff time and, in some cases, make otherwise valuable workflows impractical.

Browser-based automation provides a pragmatic way to work within these constraints. Rather than replacing existing systems, it allows public health teams to interact with them programmatically, freeing capacity for analysis, decision-making, and community impact.

How can browser automation help public health units? #

At Wellington-Dufferin-Guelph Public Health (WDGPH), we use browser automation to integrate browser-only systems directly into data pipelines and operational workflows. This approach allows us to work with existing platforms as they are, without requiring changes from upstream system owners.

Over several years and across multiple projects, retrieval-based workflows have supported two distinct outcomes:

• Net-new capability: some data products and services were not feasible at all when they depended on manual retrieval.
• Process substitution: other workflows replaced routine manual steps, freeing staff time for analysis, interpretation, and follow-up work.

We have focused on read-heavy, low-risk workflows where automation improves reliability and consistency without increasing operational risk.

Tooling: Playwright #

WDGPH has adopted Playwright for its browser automation workflows. The most common use case for a tool like Playwright is for end-to-end user interface testing in software development. In public health, our use case is different. Rather than testing systems we control, we use Playwright to automate interactions with external portals that support core operational workflows. This allows us to integrate legacy or shared systems into modern data processes without introducing fragile, bespoke solutions.

Browser automation versus web scraping #

Traditional web scraping tools, such as Beautiful Soup, are effective for extracting data from static or consistently structured pages. Many public health systems, however, rely on authenticated sessions, dynamic content rendered in the browser, and multi-step workflows. These characteristics make them difficult or unreliable to access through HTML parsing alone.

Browser automation interacts with these systems in the same way a user does, making it more robust for complex, stateful applications commonly found in public health reporting environments.

Playwright and Selenium #

We previously used Selenium for browser automation, including in the retrieval step of this open-source workflow for accessing Public Health Ontario’s Water Testing Information System Electronic Notification (WTISEN) portal. Selenium remains a widely adopted and capable tool. In our experience, however, Playwright has provided a more modern framework with improved handling of dynamic content, built-in waiting mechanisms, and faster execution.

In its first year of use, this has allowed us to build more resilient workflows, faster, and reduced maintenance effort for workflows that depend on external portals which change over time.

Developer experience and maintainability #

Playwright includes code-generation tools that capture automated workflows directly from live browser interactions. This lowers the barrier to development and accelerates iteration, particularly when automating unfamiliar or evolving interfaces. Playwright also offers first-class SDKs in multiple languages, including Python and TypeScript, allowing teams to easily integrate browser automation into automation infrastructure.

Case study: Safe Water #

Safe drinking water is a foundational public health responsibility and an important health equity issue for rural and non-municipal communities that rely on private wells and small drinking water systems. Public health units are responsible for risk assessment, surveillance, compliance monitoring, and response to adverse water quality incidents across these systems. Ontario’s Auditor General has noted that this work remains challenged by fragmented data, inconsistent monitoring, and limited system-level visibility¹. Solutions for more reliable, timely, and integrated information support are direly needed to protect health in our communities.

Delivering an effective safe water program at a public health unit requires coordinating data from no less than three provincially managed, browser-only portals. WTISEN (Water Testing Information System Electronic Notification) provides laboratory test results for private wells and small supplies and is essential for identifying adverse results requiring follow-up. RCat (Risk Categorization Tool) supports public health inspector-led risk assessments for small drinking water systems and defines system risk levels and sampling requirements. LRMA (Laboratory Results Management Application) receives laboratory submissions for small drinking water systems and is used to monitor sampling compliance and manage adverse water quality incidents.

At WDGPH, we have turned to browser automation to support this work. On a daily or weekly schedule, our automations authenticate into each system, navigate to reporting sections, apply specific filters, and download one or more reports. These files are then systematically renamed, validated, transformed, and integrated into downstream data pipelines. The resulting datasets support concrete public health action: generating inspection and follow-up work items, monitoring sampling compliance, tracking adverse incidents, and informing internal and public dashboards.

Because these workflows depend on interactive web applications rather than APIs, browser automation has become essential infrastructure. Playwright allows us to reliably operationalize these routine but critical tasks, reducing manual effort while improving consistency and timeliness. This has enabled WDGPH to strengthen safe water oversight and respond more effectively to known system gaps identified at the provincial level, while laying the groundwork for more equitable protection of drinking water health risks.

From testing and development to operational use #

Initial use cases at WDGPH have focused on low-complexity, high-repetition workflows. This has allowed us to demonstrate value, build internal expertise, and establish operational patterns before considering more complex applications.

Browser automation is not a “set and forget” solution. Over time, changes to upstream systems are inevitable. Effective operationalization therefore includes basic monitoring, failure detection, and alerting so that automation continues to deliver a net productivity gain rather than introducing hidden risk. In practice, these guardrails have been sufficient to support long-running workflows that underpin ongoing services.

Limits and next steps #

Browser automation remains sensitive to upstream interface changes and should be treated as a complementary tool rather than a universal solution. Its greatest value has been in environments where many public health units interact with the same provincially shared reporting systems and face nearly identical constraints.

A natural next step is deeper collaboration across public health organizations to share implementations for common systems. By doing so, public health units can reduce duplicated effort and collectively improve the resilience and sustainability of browser-based workflows that support essential services.