SurgOncDB

SurgOncDB

Case log · outcomes · staging · survival
Connecting…
—

Oncologic quality

Case volume by month

Clavien–Dindo distribution

of complications graded

Breakdown by tumor type

within current filters
Tumor type Cases Complication rate Major (≥ IIIa) Median postop stay Median OR time 30d mortality

Most recent cases

click a row to open
DateTypeProcedureApproach ASAClavien–DindoLOS (d)Status

New case

De-identified entry — use a chart reference, not a name.

Case identification

This page is private to you, but isn't a HIPAA-BAA'd system — keep the link to yourself. Every case gets a private case code () — the name and ID below are kept in a separate, owner-only store and are never part of what a shared case record shows.

Initial staging & imaging

Pre-treatment clinical stage, to compare against the pathological stage below.

Neoadjuvant / perioperative treatment

Diagnostic workup timeline

Log dated entries as they come in — initial endoscopy and biopsy, and any restaging studies before surgery.

Operative details

Hospital course

—
Filled in from the two ICU dates. Type it directly if you only know the total.

Complications & postoperative outcomes

The grade follows the treatment, which is what Clavien–Dindo actually classifies. IIIa is an intervention without general anaesthesia and IIIb one under it, so a drain placed in the operating room under general anaesthesia is IIIb.
—

Pathology & staging

T/N/M use generic AJCC-style categories — apply your organ-specific definitions.

Additional notes

Follow-up & survival

add a visit each time you see or hear from this patient
Saved when you click "Update case" above.
Saved when you click "Update case" above.
CodeDatePatientID / MRNHospitalTypeProcedure Clavien–DindoLOS (d)OR (min)StatusData

Backup & capacity

the registry lives inside this page — keep a copy outside it
Full backup

One file with every case, every follow-up visit and the private name/ID store. This is the copy that can rebuild the registry: the CSV is for analysis and does not carry the visits one by one.

Restore

Reads a backup file and writes back only the cases that aren't here. Anything already in the registry is left untouched, so restoring twice changes nothing.

Prototype · not live

The multi-surgeon registry

This tab is a walkthrough of the system designed to let colleagues register their own patients, built and tested but not yet deployed. Everything below uses invented cases — none of your data appears here. The registry you are using today, in the other tabs, is unaffected.

How it is put together

Cloud Run · Firestore · Identity Platform
Browser form + dashboard Cloud Run API + access control Identity Platform login only, no clinical data cases clinical data · case code · no names identities name · MRN · owner and author only attribution who entered it · you only HTTPS
The browser never reads the database directly — the rules deny it outright. Every request passes through one place on the server that decides what to return, so there is no second copy of the permission logic that can drift out of step with the first.

The same case list, seen by three people

switch the role
Signed in as you

Where it stands

✓
Built and tested. Case entry, follow-up with organ-specific outcomes, dashboard, colleague accounts, and an append-only log of who changed what. 36 automated checks, including that a colleague cannot see another surgeon's patients or learn who entered a case.
1
A Google Cloud project. Billing enabled and a region chosen — São Paulo or Santiago; there is none in Colombia. Running cost at this volume is a few dollars a month. Deployment is then one script.
2
Ethics committee approval before colleagues are given access. Retrospective chart review counts as no-risk research, and for that category the committee may waive individual consent.
3
Who owns the consolidated database — you, the university, or a clinic. The design does not depend on this: the project can move to an institutional account later without touching the code.