Residency and GME Management Software: Why Rotation Blocks, Duty Hours and Case Logs Break in the Same Week

Why GME administration breaks once you pass a dozen programs

It is the second week of May. A program coordinator has three windows open: the packaged GME system, a block schedule in Excel that she rebuilds every academic year because the system cannot express her specialty's rules, and an email thread with the affiliated community hospital about which PGY-2s have completed their site orientation and badge access. Two residents are on a rotation that the schedule says is at the VA, but the VA appointment paperwork stalled, so they are actually on the main campus and their duty hours are being logged against the wrong site. Nobody will notice until the annual review, or until a resident files an anonymous survey comment about it, which is worse.

The tooling around this is real and it is not bad. MedHub and New Innovations both cover the core academic year: schedules, evaluations, duty hour logs, procedure logs. Thalamus is genuinely strong at what it does, which is interview season scheduling for recruitment. What none of them holds is the institutional layer that a Designated Institutional Official is actually accountable for: every program's schedule, every resident's credential and licence status at every participating site, every duty hour exception, and the evidence trail behind each Annual Program Evaluation, sitting in one queryable place. The DIO gets that today by asking twenty coordinators for spreadsheets in April.

The consequence is not abstract. Accreditation of a program is a condition of board eligibility for its graduates and of the Medicare direct and indirect graduate medical education payments tied to resident counts. The coordination work that prevents citations is currently done by people re-typing data between systems at 7pm.

Problem 1: block scheduling across participating sites is a constraint problem, not a calendar

A general surgery block schedule is not a calendar. It is a set of hard constraints: each resident needs a defined number of months on trauma, on transplant, on a rural site, and on nights, spread across five years, while every service needs coverage every day, while the ACGME requires one day in seven free of clinical duty averaged over four weeks, while three residents are on parental leave and two are in a research track and one is doing an away elective that the affiliate must credential them for six weeks in advance.

Packaged GME systems store the schedule once you have made it. They do not build it. So the chief resident builds it in Excel over a weekend in March, and the coordinator types it in, and every swap for the next twelve months is an email plus two manual edits. When a resident swaps a night float week, the duty hour projection, the service coverage, and the site attribution all change, and nothing recomputes.

A custom build models the constraints explicitly and solves them. Rotation requirements per specialty and per PGY level, service minimum and maximum coverage per day, site capacity, leave, and the day-off rule become inputs to a solver rather than a human's weekend. Swaps then run through the same solver as a validation, so the system either accepts the swap or tells the chief exactly which constraint it violates before it happens.

Problem 2: duty hours are self-reported, late, and nobody trusts the number

The ACGME limits are published and unambiguous: 80 hours per week averaged over four weeks, one day in seven free averaged over four weeks, and defined limits on continuous clinical work. The number your system reports is not a measurement. It is a set of retrospective clicks by tired people, often batched on a Sunday, often approximating.

Every packaged system has a duty hour module and every one of them has the same problem: the resident is the only sensor. If your residents log conservatively, your data looks clean while your survey results say otherwise, and programs discover that gap in the annual survey rather than in their own dashboard.

What a custom build can do that a packaged one will not: derive a shadow log from systems you already own. Badge swipes at each site, EHR session timestamps, OR case start and stop times, and the published block schedule together produce an expected hours figure. You do not use it for discipline. You use it to prompt: the system nudges a resident whose badge activity and logged hours diverge by more than a set threshold, and it flags to the program director when a service shows a pattern rather than an individual. The point is to find the rotation that is structurally over the limit in November, not to find it in the June survey. Site attribution comes free from the same data, which quietly fixes the VA problem from the opening paragraph.

Problem 3: case logs live in a board's taxonomy, not yours

Surgical and procedural specialties log cases against defined category minimums, and the categories belong to the specialty board and the ACGME Case Log System, not to your hospital. Your OR system records CPT codes and a procedure description written by a scheduler. The mapping between those two is a resident sitting at home typing cases from memory, weeks later, into a case log with different category names.

This is where the packaged tools genuinely stop. They give you a form that matches the national system, which is correct and necessary, and no help at all filling it. The result is chronic under-logging, discovered at the point where a chief resident is short on a category with four months of training left and nothing can be done about it.

A custom build closes the loop with the source. Pull the resident's OR schedule and the coded case record from the hospital system, propose the case log entry with a suggested category mapping, and let the resident confirm or correct with one action inside a week rather than reconstruct a month later. The mapping improves as corrections accumulate because it is a learned mapping, not a static table, and one specialty's corrections do not pollute another's. Then run the projection that actually matters: at the current rate, this PGY-3 finishes 22 cases short in a required category, so the schedule needs to change now. That single report is what program directors buy.

Problem 4: milestones, the CCC, and evidence that is scattered across five tools

Twice a year the Clinical Competency Committee sits down to place every resident on the milestones for their specialty. The evidence for that judgement lives in end-of-rotation evaluations, direct observation forms, procedure logs, in-training exam scores, conference attendance, patient safety event involvement, and the program director's memory. In practice the committee is handed a stack of PDFs an hour before it meets, and the milestone placements end up reflecting recency and the loudest faculty voice.

What a build changes is not the judgement, which is properly human. It is the preparation. Assemble a per-resident evidence packet automatically, organised by competency domain, with the narrative comments grouped and the quantitative trends plotted against the cohort. Record the committee's reasoning at the point of decision so that a resident on a remediation path has a documented history rather than a verbal one. This matters twice: once for the resident who deserves an honest development conversation, and once for the institution when a dismissal or non-promotion is challenged and the evidence trail is the whole defence.

Problem 5: the DIO has no cross-program view until April

The institutional layer is where custom work pays for itself. A DIO needs to answer questions across every sponsored program on demand: which programs are trending down on their resident survey domains, which have faculty evaluation completion below an acceptable rate, which have residents with expired licences or lapsed BLS certification, which sites have Program Letters of Agreement coming up for renewal, and which programs have not held their Annual Program Evaluation. Packaged systems answer these one program at a time, by export.

Build the rollup once and the annual ADS update stops being a fire drill. Resident and fellow rosters, changes in faculty, participating site changes, and scholarly activity get maintained continuously through the year in the system that already owns them, then reviewed and submitted rather than assembled from nothing in a two week window. The same store feeds your IRIS reporting to finance, because the resident FTE by site by month is exactly what the hospital's Medicare cost report needs, and today that reconciliation is a spreadsheet passed between the GME office and the finance office with disagreements resolved by argument.

What this costs and how long it takes

Across the projects Digital Heroes has delivered, the shape for GME is consistent. A first release covering constraint-based block scheduling for your two or three hardest specialties, duty hour capture with the derived shadow log, and evaluation delivery runs $70,000 to $150,000 in 14 to 20 weeks. The institutional platform adding case log integration, milestone and CCC workflow, credential and licence tracking across sites, and the DIO rollup runs $180,000 to $450,000 phased over 8 to 14 months.

What moves the number in this category specifically: the count of participating sites, because every affiliate has its own credentialing office, identity system, and badge infrastructure, and each one is a real integration. The count of distinct specialties, because surgery, radiology, psychiatry and internal medicine have genuinely different scheduling and logging models and you cannot build one and get the others free. And the single biggest variable, which is not software: how many of your scheduling rules exist only as a chief resident's habit. Expect three to five weeks of sitting with coordinators writing down what the rules actually are.

Build versus buy, and when buying is right

Buy if you sponsor a handful of programs at one hospital with stable rotations and no unusual specialty. MedHub and New Innovations do that job, they are maintained against changing requirements, and a custom build would be an expensive way to reproduce them. Keep Thalamus for interview season either way, and integrate it rather than rebuild it: recruitment scheduling is a solved problem and not where your risk lives.

Build when two or more of these are true. You sponsor more than roughly fifteen programs. You have two or more participating sites with separate credentialing. At least one program rebuilds its block schedule outside the system every year. Your DIO cannot answer a cross-program question without emailing coordinators. Your case logging is chronically behind and you find out about category shortfalls too late to fix them with a schedule change. The tipping point is not features. It is that above a certain size the coordination between programs, sites and boards is the institution's actual accreditation risk, and that coordination is currently held by people, not systems.

How to choose a developer for GME software

Ask them to whiteboard the data model before you sign. A developer who has done this draws resident, program, block, rotation assignment, participating site, and a separate site-specific credential object, and they know why the credential has to be per site and time-bounded rather than a flag on the resident. A developer who draws users and shifts has built a staff rostering app and is about to learn accreditation on your budget.

Ask what they have actually integrated in a hospital. Epic and Cerner access takes a security review measured in months, not a sandbox key. Ask whether they have shipped anything through an institutional security assessment and how long it took, and ask for the specific interface, not a claim that they do integrations.

Ask who owns the code, and get it in writing before kickoff. You should own the repository, the cloud accounts, and the unrestricted right to hire someone else to continue the work. At Digital Heroes the client owns the code from the first commit, and we would tell you to walk away from any developer who hedges on that question.