e-Gestão
The hub of a public healthcare ecosystem
- My role
- Full stack developer · project delivery · database and infrastructure
- Client
- Wi Consultoria
- Sector
- Municipal public health · Brazil
- Period
- 2023 — present
- Status
- In production
Proprietary code. Private client system — the repository isn’t public.
Numbers
400+
municipalities served
Across 26 states. Each isolated as its own tenant.
200+
screens in production
Reports, management, surveillance, citizen portal and panels.
50+
API route modules
Each with its own routes, ACL and export layer.
300+
database migrations
Schema versioned from day one.
7
systems under the hub
R-SUS, SUS Direto, Willy, Call Panel, Visa, BPA Online, Nuvem PEC.
Context
Every municipal health department in Brazil records care in PEC — the citizen electronic health record of e-SUS APS, installed locally, city by city. The data exists but stays trapped: to answer “how is primary care doing here?” a manager depends on manual exports, spreadsheets and goodwill. By the time the answer arrives, the month is over.
The problem
Turn heterogeneous local PEC databases into reporting that is reliable, comparable and auditable — for hundreds of municipalities at once, with rules dictated by Ministry of Health technical notes that keep changing, and never letting one city’s data surface in another’s. And the detail that changes everything: a wrong number here isn’t a UI bug, it’s a health decision made on false information.
The approach
No live querying of PEC. The system extracts, transforms and mirrors into its own PostgreSQL tables, and every report reads from the mirror. That buys three things: the city’s PEC never takes heavy read load, the schema is ours to control, and the same question asked twice gives the same answer. On top of the mirror sits one standardised report shell — filters, table, export — repeated across 200+ screens instead of each reinventing the wheel.
Architecture
- 01
Extraction
Reading the city’s PEC databases. The clinical source of truth, treated as read-only — the system never writes into the health record.
- PostgreSQL
- Knex
- 02
Queued transformation
Async queued pipeline: normalise, dedupe and materialise into mirror tables. The queue is observable, with its own screen — a stuck sync is a visible problem, not a silent one.
- Bull
- Redis
- Node.js
- 03
Indicator layer
Numerator and denominator rules for each indicator become versioned code, with the technical note that produced them recorded alongside. When the Ministry changes a rule, the change is traceable — and the manager sees where the number came from.
- TypeScript
- SQL
- 04
Role-scoped API
Express + Knex, 50+ route modules. JWT in an httpOnly cookie and role-based authorization — internal team, city manager, health professional. The tenant comes from the IBGE code in the URL and is verified server-side, never trusted from the client.
- Express
- Knex
- JWT
- Zod
- 05
Interface and export
Next.js App Router with TanStack Query. PDFs aren’t hand-assembled: a print route renders the same screen in paper layout and Puppeteer captures it. One report, one truth.
- Next.js
- React
- TanStack Query
- Puppeteer
- XLSX
- 06
Operations
Linux VPS with Nginx and PM2, API process separated from the queue worker, S3 for files and web push. Configuration, hardening and deployment are part of my scope.
- Linux
- Nginx
- PM2
- AWS S3
- Web Push
The hard parts
Multi-tenancy that cannot fail once
The six-digit IBGE code lives in the URL, but it isn’t the authorization — it’s only the intent. Every request resolves the municipality server-side and checks it against the user’s role. With 400+ cities on one installation, leaking health data across them isn’t a medium-severity bug; it’s the kind of failure that ends a product.
Screen and PDF must tell the same story
PDF generation used to be a separate generator, in another language, with its own reading of the rules — two sources of truth and guaranteed drift. Moving to rendering the actual page in print mode and capturing it killed the entire bug class of “the report doesn’t match the screen”.
Rules that change by decree
A health indicator is not a stable requirement: the Ministry publishes a new technical note and the numerator changes. The answer was treating the technical note as a first-class artifact, versioned next to the code implementing it and wired to the explanation the manager reads on screen.
Consistency across 200+ screens
At this report count, per-screen creativity is debt. The report shell exists so a new screen is born predictable: filters in the same place, export behaving the same way, empty states looking the same.
What’s mine
- Full stack development of the report screens and the API routes feeding them
- Database modeling, query writing and tuning, and the migrations that version the schema
- The PEC → mirror-table sync pipeline, with queueing and monitoring
- The export layer: print route, PDF capture, CSV and XLSX
- Authentication, role-based ACL and per-tenant isolation
- Configuration, security and deployment of the production servers
- Running the ongoing projects — prioritisation, scope and delivery organisation
Outcome
It runs in production, in daily use inside municipal health departments across more than 400 municipalities in 26 states. It grew from reporting into an ecosystem: seven systems under a single portal, with a call panel in reception and an AI assistant inside the tool itself. For the manager, the concrete change is seeing the indicator during the month instead of learning the outcome afterwards.
What I took from it
- 01Domain before code. The hard part of public health isn’t React, it’s understanding the rule the State wrote.
- 02Mirroring data instead of querying the live source solved performance, stability and reproducibility at once.
- 03One source of truth per answer. Two implementations of the same rule always drift — the only question is when.
- 04A repeatable pattern beats a beautiful screen when there are 200+ of them.
- 05Writing software someone else depends on to do their job is the best engineering school there is.