Registries designed by someone who has sat through the PI meetings.
A working registry, an operational dashboard and a performance-improvement loop tracker in one place — reading and writing the Excel workbook your program already keeps, rather than replacing it with a system nobody will use.
Why we built our own surgical registry
The first registry was built because the existing options did not fit how the service actually ran. That is the whole origin story, and it is also the design brief.
Most registry software is built for the reporting requirement rather than the clinician. It asks for forty fields when twelve would do, it cannot be filled in between cases, and the people entering the data never see anything come back out of it. So data quality degrades, and by the time the performance-improvement meeting comes around the numbers are arguable.
A registry only works if the people entering data can see why it matters. That means short entry paths, sane defaults, fields that match the vocabulary a surgeon already uses, and reports that answer the questions your PI process actually asks — before the meeting, not during it.
Operational metrics, live off the registry
Every entry moves these the moment it is saved. Benchmarked, risk-adjusted comparison is what a national registry is for; this is the local, near-real-time view between those reporting cycles — the gap where most programs are flying blind.
The loop tracker, because loops that never close are the classic finding
Every flagged case is carried through identify → review → action → re-measure → close, and the closure has to be documented before the loop will close. Nineteen editable screening rules propose the cases; screening is advisory, so a case you do not open stays flagged until you deal with it.
Case worklist
Screening proposals, open loops, an aging report, and a record of cases screened and deliberately set aside — with the reason, because “we looked at it and decided not to” is itself documentation.
Screening rules
Nineteen rules you can edit: failed non-operative management, Clavien-Dindo IIIb or higher, missed Level 1 activation, slow transfer acceptance, prolonged length of stay, and the rest. Thresholds are yours to set.
Peer review meetings
Meeting records with composed minutes and attachments, so the minutes are a by-product of the review rather than a separate evening’s work.
Evidence binder
Screening criteria, the full loop register, every closed loop end to end, and all peer review minutes pulled into one printable document. Print to PDF or export the loop register as CSV.
It reads and writes an Excel workbook you already own
There is no database to license, no server to procure, and no vendor holding your data. The registry is a single self-contained file that points at one workbook on your approved network share and becomes the interface for it. Close the app and you still have a spreadsheet anyone can open.
Import the years you already have
Point it at the old log — one worksheet per month is exactly what it expects. It reads every tab, works out where each header row is, and builds a single list of every column that ever appeared, so a column somebody added part-way through year two is handled rather than dropped. Nothing is written until you have seen the preview.
Archive completed years
Keep the active workbook down to open records plus the current year; older years move to per-year archive files so saves stay fast. Archives load back in on demand, so a research search still spans every year you have.
Nothing is trapped
Every view exports to CSV, the evidence binder prints or downloads as a standalone document, and the underlying data is an ordinary Excel file. If you stop using the tool tomorrow you lose the interface, not the registry.
Safe to share
Saves re-read the workbook, apply the change and write it back, so two people working the same afternoon do not overwrite each other. Attachments live in a folder beside the workbook and are indexed, never embedded — which is what keeps a file with hundreds of documents in it usable.
The same registry, pointed at a different service line
Emergency general surgery is where this one started, because that is the service it was built for. Nothing in the architecture is specific to it. The fields, the lookup lists, the screening rules, the metrics and the protocol definitions are all configuration — so a registry for another line is a build, not a rewrite.
Spine
Levels, approach and instrumentation, complication capture, return-to-OR, and patient-reported outcome follow-up at the intervals your practice actually uses.
Total joints
Implant and laterality tracking, length of stay and discharge disposition, 90-day episode complications, and the readmission and revision numbers a bundled-payment conversation turns on.
ICU
Admission source and severity, device days, ventilator and line events, daily-goal compliance, and the mortality and length-of-stay reporting your unit committee reviews.
Sepsis
Recognition-to-antibiotic and fluid timing against your own targets, bundle compliance by element rather than pass or fail, source-control timing, and the escalation trail.
ECMO
Cannulation configuration and timing, circuit events and exchanges, anticoagulation, complications, and decannulation and survival outcomes across a cohort small enough that every case matters.
Stroke
Door-to-imaging, door-to-needle and door-to-groin against the clock, transfer-in timing, and the case log a certification review will ask to see.
Trauma PI
The loop tracker on its own, wired to whichever registry your trauma program already feeds — often the piece that is genuinely missing rather than the case log.
Outside medicine, too
Nothing here requires a patient. A tracker with a defined record, a review workflow, an aging report and an audit trail is the same tool whether the record is a case, an incident, an inspection, a claim, or a piece of equipment. More on non-medical work.
Scope, access control and where the data lives
A registry that holds patient-level data is a different category of project from a website. It carries real obligations around access control, auditability, retention, and where the data physically lives — and, depending on the setup, a business associate agreement with your institution. We scope that explicitly at the start rather than discovering it late.
Two things follow, and we would rather say them here than in a proposal. First, the screenshots on this page show synthetic demonstration data generated in the browser — the tool ships with a demo mode precisely so a program director can look around before any real workbook is involved. Second, this is documentation and workflow support: it helps a program organise, measure and evidence what it does. It does not ensure or guarantee any verification outcome, and anyone who tells you their software does is selling something.
If your institution’s IT and compliance requirements point to a different solution than the one we would build, we will say so.
Scoped and quoted individually
Registries and dashboards vary too much for a price list to be honest. They are scoped from a discovery call and quoted in a written proposal, under Schedule F of the services agreement — and we will tell you their sales-tax treatment in that proposal rather than leaving it to the first invoice.
Related services
Tell us what you need to track
The service line, roughly how many records a year, and what your review process looks like today. That is enough to start.