HealthCam

01 · Architecture

Capture once. Run multiple analyzers.

HealthCam 3.0 routes each webcam segment to enabled analyzers in parallel and aligns their results with active-app context. A service registry discovers capabilities; manifests configure native processes and Docker containers. Structured results go to an authenticated cloud API.

02 · Engineering decisions

Designing for replaceable components

I built the capture, orchestration, service lifecycle, ingestion, database pipeline, and web application. The heart-rate analyzer integrates pyVHR; the blink analyzer uses MediaPipe landmarks with my own processing logic.

03 · Data engineering

Prepare summaries before the dashboard needs them

Raw JSONB telemetry is retained in PostgreSQL. GitHub Actions runs incremental SQL aggregation on a five-minute schedule and a daily reconciliation job. Dashboards query summary tables instead of repeatedly scanning the full telemetry history.

db.user.findUnique.mockResolvedValue({ id: "user-1" });
db.recordingPayload.count.mockResolvedValue(INGEST_RATE_LIMIT.max);

const response = await POST(
  request(validCloudRequest(), { "x-api-key": "valid-key" }),
);

expect(response.status).toBe(429);
expect(response.headers.get("Retry-After")).toBe("60");
expect(db.recordingPayload.create).not.toHaveBeenCalled();

04 · Research & evaluation

Evaluating one analyzer within the platform

For my thesis, I integrated pyVHR, a PHuSe Lab research package from the University of Milan, as the webcam heart-rate analyzer (rPPG). HealthCam’s capture, orchestration, storage, and dashboard layers are separate from that estimator’s accuracy.

Mean absolute error≈ 11.6 BPM

App-level differences≈ 3 BPM

I aligned estimates with a Polar H10 reference and examined error, agreement, and lighting. The tested setup could not reliably resolve these differences; the finding applies to that estimator configuration and experiment.

Source: HealthCam 2.0 thesis presentation, slides 10–11.

Replaceable analyzers were an architectural goal of the project. The experiment limits how this estimator can be used; another analyzer can reuse capture, orchestration, and ingestion.

Method, sources, and reproducibility limits

05 · Data handling

Video stays on the device

The agent uploads results, application/window context, timestamps, and file metadata. Video and sidecar files are deleted after successful analysis and upload; failures can retain them locally. Derived data is still sensitive. Local APIs currently require a trusted development machine because they lack authentication.

What you can evaluate today

The system, the result, and the next steps.

2.0 · Thesis: separated services and initial rPPG evaluation. 3.0 · Today: manifests, a capability registry, and multiple parallel analyzers.

The demo demonstrates the interface. Local execution requires private repository access, manual configuration, and compatible hardware. An experimental thesis and portfolio project, not a medical device.