Work Report — April 7 to April 21, 2026
Period: April 7–21, 2026 Generated: 2026-04-21
Summary
The dominant theme of this period was hardening: hardening how notifications are routed across services, hardening email delivery against a vendor platform change, and hardening the deployment pipeline across all six backend services. The single most important delivery was the shared notification library — without it, any future change to how alerts are formatted or routed would require six separate coordinated updates with no guarantee of consistency.
What Was Delivered
1. Shared notification routing library
Impact: A single, validated library now governs how all backend services send medical alerts — disease notifications, analysis results, patient updates — through the internal data pipeline (Kafka). Any service that needs to send a notification now calls one place instead of rolling its own logic.
Risk removed: Without this, each of the six services had its own ad-hoc notification code. A change in notification format — or a bug in routing logic — would require six separate fixes. In a system that alerts field teams to epidemiological events, an inconsistent fix is as dangerous as no fix at all.
Effort: Built from scratch in one day (April 20), including data types, message envelope structure, input validation, and the public API. Speed was possible because the design had been agreed upon in advance with colleagues.
2. Email delivery hardened against a vendor platform shutdown
Impact: Both the analyses service and the notification service now send automated emails via Microsoft's modern API, replacing a deprecated authentication method that Microsoft has permanently disabled for Microsoft 365 accounts.
Risk removed: Without this migration, all automated email delivery would have silently stopped — weekly arbovirus surveillance reports, analysis result notifications to field teams. There would be no error visible in our systems; emails would simply not arrive.
Effort: The migration itself was straightforward; the hardening work (fixing draft emails left unsent in the mailbox, authentication failure handling, upload timeout recovery) required additional attention to failure modes that are invisible under normal conditions.
3. Next-generation notification system — foundation
Impact: A new, extensible notification architecture is now partially in place, capable of routing medical alerts through email, SMS, or push channels from a single place, with full context about the patient, sample, or epidemiological trigger attached.
Risk removed: The current system handles notifications service by service with no shared standard. As the number of alert types grows, maintaining consistency across services becomes harder. Without a unified foundation, a missed alert in one service would require investigating six codebases to understand why.
Effort: Design reviewed with colleagues before implementation began — a deliberate decision. The architecture document went through several iterations to ensure the routing model is correct before any code was written.
4. Weekly arbovirus surveillance report made configurable
Impact: The automated weekly report for arbovirus monitoring now supports flexible recipient targeting, custom date ranges, and bilingual content. Country teams can now receive tailored reports without requiring a code change or redeployment.
Risk removed: Previously the report was hardcoded. Adapting it for Sierra Leone vs. Togo required a developer to intervene. Any urgency around a specific country's surveillance window would wait on engineering availability.
Effort: One day of implementation, including internationalization of email content and recipient configuration via command-line parameters.
5. Dependency tooling standardised across all six services
Impact: All backend services now use the same modern package manager (uv), cutting environment setup from ~2 minutes to under 10 seconds and eliminating version drift between services.
Risk removed: Version drift between services — where the same library is pinned to different versions across codebases — has caused unexplained production failures in the past. A standardised toolchain closes this class of bug permanently.
Effort: One to two days per service, running in parallel across the week of April 12–16. Each migration required validating that all existing tests still passed.
6. Reusable deployment pipeline templates
Impact: The continuous deployment configuration for all Django (our web framework) backend services is now consolidated in a shared library. Any new service adopts the full pipeline in one line.
Risk removed: Previously, each service maintained its own copy of the pipeline configuration. Configuration drift between copies has caused silent differences in how services are tested and deployed — a risk that grows every time a service is updated independently.
What Was Prevented
1. Silent breakdown of all automated medical notifications
What almost happened: Microsoft's SMTP Basic Auth shutdown would have cut all automated email delivery with no visible error in our systems. Field teams would have stopped receiving surveillance reports without anyone knowing why.
How it was caught: Proactive migration based on the vendor's advance deprecation notice, completed before the shutdown date.
2. Draft emails left permanently unsent
What almost happened: A specific failure mode caused emails to be composed and saved as drafts in the mailbox but never sent. For a medical surveillance system, a notification that appears sent but was not is worse than a visible error — there is no alert, no retry, no trace.
How it was caught: Identified during the email backend hardening work; fixed alongside the main migration.
3. Production admin backdoor
What almost happened: Development utility commands that create admin accounts and generate test data were present in all six production services. These commands have no legitimate use in a production environment and represent unnecessary attack surface.
How it was caught: Systematic audit across all services; removed in a coordinated cleanup on April 17.
4. Document generation crash from a dependency conflict
What almost happened: A library used to generate Word documents (laboratory reports sent to health centres) was silently broken by an upstream package version change. Affected reports would have failed to generate with no clear error message to the end user.
How it was caught: Identified during routine dependency work; version pinned to restore stability while the upstream library is updated.
What Is In Progress and Why It Takes Time
1. Notification System V2 — full routing engine
What it is: The data models and application scaffolding are in place. The routing engine — channel selection, retry logic, delivery receipts — is the next phase.
Why it cannot be rushed: The system carries patient identifiers, sample IDs, and epidemiological triggers. A routing bug could mean a missed alert reaching a field team too late. Each routing rule needs to be tested against real data shapes before being deployed.
2. Migrating remaining services to the shared notification library
What it is: The analyses service was connected to the new library on April 20. Five other services — patient records, organisations, consultation, bio bank, and forms — need the same migration.
Why it cannot be rushed: Each service has existing notification behaviour that must be preserved exactly during the transition. Field teams must not receive duplicate or missing alerts because of how the migration was sequenced.
Report covers git activity across 8 repositories and engineering work sessions from April 7–21, 2026. Generated 2026-04-21.