Local Health Monitor

A related local dashboard adapting the event-monitoring pattern to public health information.

Local Health Monitor analytics and source registry with fictional built-in health demonstration records.
Detail of the actual analytics and source registry with fictional records. This is not a health advisory.

Screenshots use synthetic or built-in fictional demonstration data.

View full screenshot

The problem

Public health sources describe different kinds of signals: advisories, research, trial changes, and quantitative reports. A local interface needs to normalize those differences without suggesting clinical certainty.

My contribution

I directed the source-integration requirements, domain adaptation, and validation workflow. This project shares the local dashboard pattern with Conflict Monitor; it is presented as related work rather than an unrelated architecture.

Architecture

The application reuses a React/FastAPI/SQLite local-service pattern with health-specific fields, parsing, filters, and confidence rules. Separate local ports keep it independent from the Conflict Monitor runtime.

Local Health Monitor architecture diagram. A text description follows.
Read the architecture flow
  1. 1Source-specific adapters
  2. 2Topic + field extraction
  3. 3Event matching
  4. 4SQLite store
  5. 5FastAPI and confidence rules
  6. 6React dashboard
Conceptual data flow, simplified from the inspected implementation. Scroll horizontally when needed, or use the text version above. Components can communicate in both directions.

Adapt the data contract, preserve uncertainty

Source-specific adapters normalize topics and quantitative fields before event matching. Rules expose confidence and severity alongside the original source links. The code contains adapters for public feeds, WHO notices, PubMed, and clinical-trial information.

The tradeoff

An adapter in source is not proof that a remote endpoint works today. Heuristic classification is not clinical validation. The public case study keeps those boundaries explicit.

A verified implementation boundary, with clear test gaps

Three existing local tests pass: a manual-event round trip and two scoring scenarios. The source establishes the data flow and adapter structure. No ingestion throughput or medical accuracy measurement is established.

Local Health Monitor evidence summary
Existing test cases3 passed
Shared patternLocal event dashboard
Clinical validationNot established

Method and scope

Private copied-source tests with disposable SQLite and configuration. Remote services, live ingestion, and production data were not part of this check.

Verification and limits

The test suite is narrow. Broader fixtures for deduplication, parsing, endpoint failures, and browser flows would improve the evidence.

  • This is not a clinical decision support tool or a guarantee of outbreak coverage.
  • Confidence values are heuristic, not calibrated probabilities.
  • Remote adapter availability and epidemiological sensitivity or specificity remain unverified.
  • The configured CARTO basemap required an API key during capture. The screenshot focuses on the actual analytics and source registry.

These results describe the inspected project and stated test conditions. They are not a guarantee for every input or machine.