ISPA Email Campaign: Automating Immunization Notice Sending

Table of Contents

Introduction #

In Part 1 of this series, we described how the data and analytics team at our public health unit (PHU) developed an automated pipeline to generate individualized immunization notices as PDFs. That work focused on accuracy and scalability - transforming student-level immunization data into standardized, reproducible notices with minimal manual effort.

While that pipeline modernized how notices were created, it unlocked an important next step: digital delivery. Notice delivery is done inconsistently across Ontario PHUs, with many relying on school-based distribution to pupils with very limited certainty around delivery. Because our notices were already being generated programmatically and linked to specific students, we were able to pilot email delivery rather than relying exclusively on traditional mail. This article describes how we extended the original notice-generation pipeline to support secure email sending, the technical and operational considerations involved, and what we learned through this pilot.

Existing Process: Mailed Notices #

Prior to this pilot, immunization notices were distributed exclusively through traditional mail. Each year, students identified as having overdue vaccinations in Panorama would be compiled into a mailing list. Notices were generated, printed, and physically mailed to households.

While this approach was reliable and well-established, it also came with several operational challenges. Delivery timelines were inherently slow, with delays between notice creation, sending, and receipt. The process also required significant manual effort, including handling print jobs and mail-outs, and managing returned mail. Additionally, mailing incurred ongoing material and postage costs.

From an evaluation perspective, mailed notices offered limited visibility into outcomes. While delivery was generally assumed, there was no confirmation that notices were received, opened, or acted upon. Incorrect addresses, relocation, or lost mail could further reduce effectiveness without clear feedback signals.

Opportunity for Innovation #

While the notice generation pipeline described in Part 1 was originally designed to support printed mail, it also created an opportunity to rethink how notices could be delivered efficiently and securely.

At the same time, our collaboration with schools in the Wellington-Dufferin-Guelph region had evolved to include secure data transfer mechanisms. Building on this, we designed a schema for email address data supplementary to traditional STIX transfers. This introduced a viable pathway for digital communication that could complement traditional mail.

To support this shift, PDF encryption was added as a formal step within the existing pipeline. Rather than applying security measures downstream, each notice was encrypted at generation time using a templated, student-specific password. This ensured that all outputs were secure by default, enabling their safe transmission through external email systems.

With encryption embedded directly into the pipeline, notice generation and delivery could remain part of a single automated workflow. This allowed email delivery to be introduced as a natural extension of the existing process, rather than as a separate or manual step.

Solution Overview #

The pilot introduced an automated workflow for sending immunization notices via email, building directly on the outputs of the notice generation pipeline.

The solution combined five key components:

Student identification: Extracting a list of students with overdue immunizations from Panorama

Contact matching: Linking student Panorama records to supplementary email addresses

Age filtering: Determining whether the student is 16 or older, to direct the notice to the student or to their parent/guardian(s)

Secure notice generation: Producing encrypted, student-specific PDF notices

Email delivery: Sending notices using a cloud-based email service with a Python API (e.g. Mailgun or Twilio SendGrid)

Where valid email addresses were available and messages were successfully delivered, notices were sent electronically. Where email delivery was not possible, the approach defaulted to traditional mail.

Technical Approach #

Data Integration and Matching #

The workflow began with the same cohort of students identified in Part 1: those with overdue immunizations. Each individual had a unique student identifier, which was then used to link records to contact information stored in STIX.

This matching step was critical to ensuring that each generated notice could be paired with a valid email address. Where multiple addresses existed, all valid contacts were retained. Records without valid or usable email addresses were flagged for fallback to mail.

Students aged 16 and over receive notices directly, and so only student email addresses are considered matches for this category. Notices for younger students are sent to parent or guardian emails.

Email Generation and Delivery #

Email delivery was implemented using a third-party email service with a Python API, allowing for programmatic sending of messages at scale. For our pilot, we used was Mailgun.

Each email was dynamically generated and included:

Contextual messaging about overdue immunizations
Instructions for accessing the attached notice
A templated password for opening the encrypted PDF

The use of an API-based service allowed for efficient batch processing, logging, and integration into the broader pipeline.

Passwords for encrypted notices followed a consistent, templated format and were communicated within the email body. This ensured that attachments remained secure during transmission, with access to sensitive information requiring both the email and the notice password. Keeping encryption as part of the generation pipeline also kept the process fully automated and reproducible.

The email service provided delivery logs indicating whether messages were successfully transferred to recipient mail servers. Emails may still be filtered into spam or quarantine folders or ignored by recipients. As with traditional mail, delivery does not guarantee engagement.

In Mailgun, a “delivered” status indicates that the receiving server accepted the message - it does not confirm that the email reached the inbox, was opened, or was read.

Operational Workflow #

The end-to-end workflow is summarized in the following diagram:

This hybrid approach ensured continuity of service while allowing the team to safely expand digital delivery. Rather than fully replacing mail, email was introduced as a first attempt, with mail serving as a fallback mechanism to maintain equitable access.

Results #

Delivery and Coverage #

Our pilot involved over 9000 students and demonstrated that a substantial proportion of notices (over 97%) could be delivered via email when valid contact information was available. However, a subset of records still required fallback to mail due to missing or invalid email addresses, or delivery failures.

This suggests that email delivery can significantly improve timeliness and operational efficiency when supported by high-quality contact data, while still requiring complementary approaches to ensure full population coverage.

Operational Benefits #

Several efficiencies were observed:

Reduced reliance on printing and postage
Faster delivery timelines compared to mail
Decreased manual handling due to automation
Improved visibility into delivery outcomes through logs

It is estimated that the email campaign saved our PHU $10,000 this ISPA season from reducing printed mail, with $2.13 as cost estimate per mailed letter while our emailing service has a flat rate of $15/month for 10,000 emails.

Limitations #

Despite these benefits, limitations remain:

Email delivery does not guarantee visibility or engagement
Data quality in contact systems directly impacts reach
Additional technical infrastructure and monitoring are required

Notably, these limitations mirror those of traditional mail in different ways - reinforcing that neither method provides perfect assurance of receipt or action.

Privacy Considerations #

Given the sensitivity of immunization data, privacy and security were central to the design of this pilot.

Key safeguards included:

Encryption of all PDF notices prior to distribution
Student-specific passwords to control document access
No personal health information within email body content
Controlled use of external email services for transmission

By including encryption directly within the pipeline, email distribution operated on secure outputs by default. This reduced reliance on manual processes and checks and minimized the risk of inconsistent handling.

This reflects the privacy-by-design approach that our PHU pursues, where protections are integrated into system architecture from the outset rather than applied afterward.

Conclusion #

Building on the automated notice generation pipeline described in Part 1, this pilot demonstrated how secure email delivery can be integrated as a natural extension of existing data workflows. The addition of PDF encryption as a core pipeline step allowed notices to move safely beyond internal systems without introducing manual steps or increased risk.

While email delivery has its uncertainties - just as traditional mail does - it offers meaningful advantages in speed, cost, and scalability. More importantly, it highlights the value of investing in robust data pipelines: once outputs are standardized and secure, new forms of delivery and engagement become possible.

Together, these efforts represent a step toward more modern public health communication - grounded in automation, privacy-by-design, and continuous improvement.