Nursing Simulation Lab Software Problems: The 7 That Risk Your Substituted Hours, and How to Avoid Them

Why does a scheduling project turn into a video platform replacement?

The centre asks for scheduling because scheduling is the daily pain. Within a month someone points out that debrief video is on a network drive, someone else notes that examination scoring is on paper, and a third person mentions that the standardised patient roster is a spreadsheet. Each is true. Together they turn a $60,000 to $130,000 first release into the $170,000 to $400,000 full platform, and the audiovisual workstream drags the schedule because it depends on hardware nobody has audited.

What makes this specific to simulation centres is that the audiovisual infrastructure is the most visible thing in the building and the least tractable. Centres are built in phases, so the 2016 rooms and the 2023 rooms have different capture hardware, and some of the older equipment exposes nothing usable at all. A project that begins with cameras spends its first two months in a plant room rather than delivering anything a coordinator can use.

The sequence that works is scheduling and hours reporting first, in 12 to 18 weeks, because those are the daily pain and the accreditation exposure and neither requires touching a camera. Then decide whether you need to replace capture at all. Keeping your existing capture product and building the scheduling, workforce and reporting layer around it, linking to recordings rather than replacing them, is a combination we have delivered more than once and it is frequently the right answer.

What goes wrong with historical hour records when accreditation asks for them?

The records exist. They are just in four places that do not agree. The coordinator's spreadsheet has hours per student. The room calendar has bookings, some of which were cancelled without the calendar being updated. Scenario documents sit in a folder with no link to the session that ran them. Attendance was taken on paper in the room and typed up later, or in some sessions not at all because a technician covered for an absent facilitator.

The migration problem is that you cannot reconstruct participation from a booking. A booking says a room was reserved for a cohort. It does not say which eighteen students were present, which of them ran the scenario and which observed, who facilitated, or whether the debrief happened. Those distinctions are precisely what the evidence claim rests on.

Centres discover this when the migration reaches a term where the coordinator was on leave and the records thin out. There is no honest way to fill that gap retroactively, and inventing it is the one thing you must not do.

The workable approach is to migrate what is defensible, mark the rest as historical with the source noted, and start clean capture from the go live term. Then agree with your programme leadership which cohorts are covered by the new evidence standard and which are not, in writing, before a site visit rather than during one.

Why do the student information system, learning management system (LMS) and capture integrations break after launch?

Identifier reconciliation is the recurring failure, and it is usually harder than anything in the simulation domain itself. The student information system holds one identifier, the learning management system holds another, the placement platform holds a third, and students appear in all three with names that differ by a middle initial. Build without a deliberate identity mapping and the first term of hours reporting contains duplicate students and orphaned sessions.

The second break is enrolment timing. Cohorts change after the term starts, students withdraw, and if the integration is a one time import rather than a scheduled sync, your rosters drift and sessions record participation for students who left.

The third is capture hardware. Integrating three generations of equipment is three integrations, not one, and each vendor's control interface behaves differently under load. The failure appears when four rooms record simultaneously on an examination day and one silently produces no file, which nobody notices until a student appeals a station result.

The fixes are unexciting and effective. Require a named identity mapping strategy, scheduled reconciliation rather than a single import, and an explicit recording verification step that confirms a file exists and is playable at the end of every session rather than assuming it does.

What happens when video retention policy is not decided before you record at scale?

You get a drive nobody dares delete. Student recordings are institutional records, some contain identifiable scenario material, and they accumulate faster than infrastructure teams expect once every room is capturing. Without a policy, deletion becomes a decision each time, so it never happens, and three years later the conversation with your privacy office is much harder than it needed to be.

The harm is not only storage cost. Retaining formative debrief video indefinitely means it is discoverable, and it means a student can ask what exists about them and you have to be able to answer completely.

The decision is not technical and should not be made by the development team. Decide retention by category before you record at scale: examination video kept for the appeal window and the accreditation cycle, formative debrief video deleted at the end of term, research video handled separately under its own consent. Then have the system enforce it automatically, because a policy that depends on somebody remembering is a policy that produces the drive.

Involve your privacy office during discovery rather than after launch. The retention decision changes storage architecture, so making it late is genuinely more expensive than making it early.

Should you build custom or configure what you already own?

If you are a single programme centre with a handful of rooms, standardised on one manufacturer's simulators and capture hardware, running a modest standardised patient programme, buy. Laerdal SimCapture is strong at capture, debriefing and integration with Laerdal simulators. CAE LearningSpace is well engineered around capture and assessment for centres standardised on CAE hardware. EMS SimulationIQ has genuine centre management depth and a long record in large academic centres. A custom build at that scale consumes money better spent on a second high fidelity manikin.

If you already own one of these, the question is narrower than replace or keep. Ask what specifically fails. In this category the gaps are consistent: standardised patient workforce management is thin everywhere because it is a staffing problem rather than a simulation problem, mixed vendor hardware is handled unevenly, hour substitution reporting in the exact shape your board of nursing wants is nobody's default report, and integration with your student information and placement systems is where the coordinator's spreadsheet reappears.

Build when two or more apply. Your centre serves several professions or institutions. You run large examination days where standardised patient logistics and offline scoring are the fragile parts. Your capture hardware spans generations and vendors. You are a health system running simulation across sites for students and staff. Or your board reporting on substituted hours is assembled by hand.

How do hidden costs get into the quote?

The first is audiovisual heterogeneity, which is the biggest single driver and is almost never audited before quoting. Ask for a room by room hardware inventory as a precondition, because three generations of capture equipment is three integrations and some older gear exposes nothing at all.

The second is the number of professions served. A centre shared by nursing, medicine, respiratory therapy and paramedicine carries four competency frameworks, four accreditors and four reporting shapes over shared run data. That is a modelling cost, not a reporting cost, and it lands in the schema rather than in a report builder.

The third is offline examination scoring. Capturing scores locally on a tablet and reconciling on reconnect, with a defined rule for a station scored twice, is real engineering rather than a setting. It is also non negotiable if your teaching spaces lose connectivity, which most do.

The fourth is standardised patient payroll. Hours flowing to payroll means an integration with your finance system and a timesheet approval path, both of which sit outside the simulation domain and outside most quotes.

The fifth is storage growth from video, which is an operating cost rather than a build cost and should be modelled from your actual room count and session volume before you sign anything.

What separates a simulation centre build that works from one that fails?

The first separator is whether the developer schedules a scenario in front of you during evaluation. If reset time, technician availability and facilitator qualification do not appear as constraints without prompting, they are building a room booking tool and your coordinator will keep the whiteboard.

The second is whether the run, not the room, is the scheduling unit. A scenario run consumes a room in a configuration, a specific simulator, a technician, a qualified facilitator, consumables, sometimes a standardised patient, and reset time before the room is genuinely free. Model the run and the scheduler finds valid slots. Model the room and you have automated the wrong object.

The third is what happens when the network drops during an examination. Local capture on the device with reconciliation on reconnect and a conflict rule is the only answer that survives an examination day in a basement teaching space.

The fourth is whether standardised patients are treated as a workforce rather than a resource: case qualifications, casting attributes, availability, an offer and confirmation flow with reminders, training records and portrayal calibration. Confirmation discipline is what prevents a no show on the morning of an examination day.

The last is ownership. Assessment records and student video are institutional records with retention obligations and they should never sit somewhere you cannot fully export. At Digital Heroes the institution owns the repository, the recordings and the cloud accounts from the first commit.