Residency Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does modelling every specialty's block rules at once go wrong?

The institution sponsors twenty programmes, so the project scopes twenty. General surgery, internal medicine, radiology and psychiatry all need block schedules, so surely one scheduling engine covers them. It does not, or rather it does only if the engine is genuinely constraint driven and somebody has written down each specialty's constraints, which is the work everyone underestimates.

The reason this is specific to GME is that a block schedule is not a calendar. It is a constraint problem: each resident needs a defined number of months on trauma, on transplant, on a rural site and on nights across several years, while every service needs daily coverage, while the Accreditation Council for Graduate Medical Education (ACGME) requires one day in seven free of clinical duty averaged over four weeks, while three residents are on parental leave, two are in a research track and one is on an away elective the affiliate must credential six weeks ahead. Surgery, radiology and psychiatry express those constraints differently enough that building one and getting the others free is not how it goes.

The fix is to take your two or three hardest specialties first, model their constraints explicitly, and prove the solver against a real academic year before extending. In Digital Heroes delivery experience a first release covering constraint based block scheduling for those specialties, duty hour capture and evaluation delivery runs $70,000 to $150,000 in 14 to 20 weeks. The institutional platform adding case log integration, milestone and clinical competency committee workflow, credential tracking across sites and the reporting rollup for the Designated Institutional Official runs $180,000 to $450,000 phased over 8 to 14 months. Budget three to five weeks of that first release purely for writing down rules that currently live in someone's head.

What goes wrong when schedules and case logs are migrated mid academic year?

Someone proposes a January go live because that is when the budget cleared. The academic year is already half run: blocks are assigned, swaps have accumulated, evaluations are partly complete, and residents have logged cases against categories under one set of assumptions. Migrating in the middle means reconciling all of that state, and the state is inconsistent because half the swaps were agreed by email and never entered anywhere.

This is worse in GME than in most categories because the data has consequences beyond reporting. A duty hour record attributed to the wrong site, or a case log entry that loses its board category on import, becomes part of a resident's training record and eventually part of a board eligibility question. Fixing it later requires the resident to reconstruct events from memory, which is exactly the data quality problem the system was meant to remove.

The fix is to align cutover to the academic year and use the intervening months to run parallel. Import completed history as read only, so evaluations and prior case logs remain visible for the clinical competency committee, and start live capture on the new year with clean assignments. If a mid year start is unavoidable, run duty hours and case logs in the new system while leaving the block schedule in the old one for the remainder of the year, because the schedule is the piece with the most unrecorded state behind it. Never migrate a partially completed evaluation cycle. Let it finish where it started.

Why do EHR, badge and operating room integrations break after launch?

The derived duty hour feed works in testing at the main campus. Then it meets the affiliated community hospital, which has its own badge system and its own identity directory, and the Veterans Affairs site, which has its own everything and a separate appointment process. A resident whose affiliate paperwork stalled is physically at the main campus while the schedule says otherwise, so badge activity and expected location disagree and the system starts producing alerts nobody can action.

The specific difficulty is that every participating site is a different institution with a different security posture. Access to Epic or Cerner data takes a security review measured in months rather than a sandbox key, and each affiliate runs its own review. A project plan that shows integrations as parallel two week tasks has priced engineering and ignored governance, which is where the calendar actually goes.

Three fixes. Start every site's security review in week one, before the code that needs it exists, because that queue does not compress. Design the derived duty hour feed as a prompt rather than a control: when badge activity and logged hours diverge beyond a threshold, nudge the resident and flag a pattern to the programme director, rather than blocking or auto correcting. And make identity mapping per site an explicit, maintained object, since the same resident has a different identifier at every institution and reconciling those by name will fail on the first shared surname. Ask a prospective developer what they have pushed through a hospital security assessment, at which centre, and how long it took.

What happens when site credentials and duty hour attribution are not covered?

The build models a resident with a credential status, as a flag. Then a resident is cleared at the main campus, pending at the affiliate and expired at the Veterans Affairs site, all at once, and the flag cannot express it. So the coordinator keeps the real picture in a spreadsheet and an email thread with the affiliate, which is the arrangement the software was bought to replace.

Site attribution fails alongside it. Hours logged against the wrong site are not a cosmetic error: they distort which rotation appears to be over the eighty hour average, and they mislead the finance office, because resident full time equivalent by site by month is exactly what the hospital's Medicare cost report needs. Today that reconciliation happens by passing spreadsheets between the GME office and finance and settling discrepancies by argument, and a system that attributes hours wrongly makes the argument worse rather than better.

The fix is a data model decision made before any screen is drawn. Credentials, badge access and site orientation are time bounded objects attached to a resident and a specific site, not flags on a resident record. That lets the system block an assignment starting before the affiliate has cleared the resident, and it makes attribution a property of the assignment rather than an assumption. Ask a developer to whiteboard this. One who has built GME software draws resident, programme, block, rotation assignment, participating site and a separate site specific credential object without prompting. One who draws users and shifts has built a staff rostering application and is about to learn accreditation on your budget.

Should you build custom or configure what you already own?

Stay with the packaged system if you sponsor a handful of programmes at one hospital with stable rotations and no unusual specialty. MedHub and New Innovations both cover the core academic year competently, including schedules, evaluations, duty hour logs and procedure logs, and they are maintained against changing requirements, which is real ongoing value you would otherwise fund yourself. Keep Thalamus for interview season either way and integrate it rather than rebuild it, because 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 programmes. You have two or more participating sites with separate credentialing offices. At least one programme rebuilds its block schedule outside the system every year. Your Designated Institutional Official cannot answer a cross programme question without emailing coordinators. Your case logging runs chronically behind and category shortfalls surface too late to fix with a schedule change.

The tipping point is not features. Above a certain size the coordination between programmes, sites and boards becomes the institution's actual accreditation risk, and that coordination currently sits with people rather than systems. What the packaged tools do not hold is the institutional layer: every programme's schedule, every credential status at every site, every duty hour exception and the evidence behind each Annual Programme Evaluation, in one queryable place.

How do hidden costs get into the quote?

Four places, and the largest is not software at all.

• Rule discovery. The scheduling logic that exists only as habit has to be interviewed out of coordinators and chief residents. Expect three to five weeks and insist it appears as its own line, because a quote without it has assumed a requirements document that does not exist.
• Participating sites. Each affiliate brings a credentialing office, an identity system, a badge infrastructure and its own security review. Price per site, not per integration type.
• Specialty count. Surgery, radiology, psychiatry and internal medicine have genuinely different scheduling and logging models. A quote covering the scheduler in the singular is quoting one of them.
• Security review calendar. Months, not weeks, at most academic centres, and outside a developer's control. It belongs in the schedule as a dependency with a start date, not as an assumption.

What separates a GME build that works from one that fails?

Four things.

The solver validates swaps rather than only storing them. When a resident swaps a night float week, the duty hour projection, service coverage and site attribution all change, so the swap should run through the same constraint engine that built the schedule and either be accepted or refused with the specific constraint named. A system that records swaps without recomputing anything is a spreadsheet with a login.

Case logs are closed against the source. Pull the resident's operating room schedule and the coded procedure record from the hospital system, propose the log entry with a suggested board category, and let the resident confirm or correct within a week rather than reconstruct a month later. The mapping improves as corrections accumulate. Then run the projection that programme directors actually buy: at the current rate this resident finishes short in a required category, with enough time left to change the schedule.

Committee preparation is automated and committee judgement is not. Assemble a per resident evidence packet by competency domain, with narrative comments grouped and quantitative trends plotted against the cohort, and record the committee's reasoning at the point of decision. That matters twice, once for a resident who deserves an honest development conversation, and once for the institution when a non promotion is challenged and the evidence trail is the whole defence.

You own it, in writing before kickoff: the repository, the cloud accounts and the unrestricted right to hire someone else to continue. At Digital Heroes the client owns the code from the first commit, and a developer who hedges on that question is building a dependency you will pay for repeatedly.