The dry run: fake patients, real systems

What does a dress rehearsal actually test?

A dress rehearsal means running a fake patient through every system the real first patient will touch, start to finish, rather than testing each piece in isolation and assuming they'll work together. That means booking through the actual scheduling link, filling out the actual intake and consent forms, opening an actual chart in the EHR, connecting on the actual telehealth platform if sessions will be virtual, and generating an actual invoice or superbill at the end.

The point isn't to catch every possible failure — it's to catch the ones that only show up when the pieces connect: a scheduling link that doesn't sync to the calendar, an e-sign form that emails the wrong address, a telehealth link that a chart note doesn't actually save to the right record. Those gaps are invisible until something flows through the whole chain at once.

Budget a real block of time for this, not a rushed hour between other launch tasks — a thorough dry run of every system typically takes half a day to a full day, depending on how many separate tools are involved. Treat anything that breaks as a finding to fix and re-test, not a minor annoyance to note and move past; the whole point of running the rehearsal before real patients arrive is that a broken step found here costs nothing but time.

Run a fake patient through the intake flow

Use a real email address you control and complete the entire intake flow as a patient would — book the appointment, receive the confirmation, fill out every consent and history form, and check what actually lands in the EHR versus what silently didn't save or arrived in the wrong field. Intake is where most first-impression failures live, because it's the one part of the system a patient touches entirely without staff help.

Time the whole sequence, not just each form. A ten-minute intake that takes a real patient twenty-five minutes because of confusing form order or a broken auto-save is a problem worth finding in a dry run rather than in a first-week review of no-shows and abandoned intakes.

Test the EHR migration and the portal together

If any client data, templates, or notes are coming over from a prior system, run the ehr migration end to end with a test record before trusting it with a real chart — confirm that migrated fields land where expected and that nothing silently truncates or drops during the transfer. A migration that looks complete in a summary report can still have individual records that didn't map cleanly.

Do the same for the portal: log in as a patient would, check a document, message the practice, and confirm what a provider sees on the other end matches what the patient actually submitted. A portal that works perfectly from the admin side and breaks from the patient side is a common and entirely avoidable first-week surprise.

Test the telehealth connection under real conditions

Hold a full test session on the actual telehealth platform, from a different device and network than the one used to set it up, since a connection that works perfectly on the office wifi can fail on a patient's phone over cellular data. Confirm the platform is running on a HIPAA-compliant arrangement with a signed business associate agreement — now that COVID-era telehealth enforcement discretion has ended, that isn't optional groundwork, it's a prerequisite to holding the session at all 1Ref 1HHS Office for Civil Rights (2026).HIPAA and Telehealth.That telehealth must run on HIPAA-compliant arrangements now that COVID-era enforcement discretion has ended, supporting the requirement to confirm a signed BAA before the platform test counts as complete..

While testing the platform, also test the failure path: what happens, and what the patient is told, if the connection drops mid-session. HHS's 405(d) program publishes a small-practice cybersecurity baseline that includes exactly this kind of contingency planning, worth a look before assuming the platform's own reliability is sufficient on its own 2Ref 2HHS 405(d) Program (2026).HHS 405(d) — Aligning Health Care Industry Security Approaches.That HHS's 405(d) program publishes a small-practice cybersecurity baseline, supporting the claim that testing the telehealth failure path is worthwhile groundwork before launch..

Test the compliance layer, not just the paperwork that says it's done

A signed policy sitting in a drawer isn't the same as a tested safeguard — the HIPAA Security Rule expects administrative, physical, and technical safeguards scaled to the practice's size, anchored in an actual risk analysis, not just a document asserting one was considered 3Ref 3HHS Office for Civil Rights (2026).Summary of the HIPAA Security Rule.That the Security Rule requires safeguards scaled to practice size, anchored in a risk analysis, supporting the claim that a signed policy alone doesn't satisfy the requirement.. The dry run is the moment to actually run through that analysis using a free tool built by ONC and OCR specifically for a practice this size, rather than treating it as paperwork to revisit someday 4Ref 4Office of the National Coordinator / ASTP (2026).Security Risk Assessment Tool.That a free, small-practice-sized risk assessment tool exists, supporting the claim that the dry run is a realistic moment to actually complete the risk analysis..

While at it, confirm the basics a real risk analysis would flag anyway: screens lock automatically, devices are encrypted, and the fake patient's test data is fully deleted from every system it touched once the rehearsal is done.

Test the billing and communication mechanics

Generate a real good-faith estimate for the fake self-pay patient and confirm it matches what the No Surprises Act actually requires before a self-pay or uninsured patient is billed — this is federal, not optional, and a template that's wrong is easier to fix on a test run than to explain to a real patient who received it 5Ref 5Centers for Medicare & Medicaid Services (2026).No Surprise Billing.That the No Surprises Act requires good-faith estimates for uninsured/self-pay patients, supporting the claim that the GFE template should be tested for accuracy before a real patient receives one.. Generate the invoice or superbill at the end of the fake visit and check the numbers, the codes, and the practice information are all correct.

Finally, test what happens after the visit: does a no-show or a missed follow-up trigger the recall systems the practice plans to rely on, or does it silently disappear until someone happens to notice weeks later? A recall step that only works when someone remembers to run it manually isn't a system yet — it's a to-do list item, and the rehearsal is the moment to find that out.

Everything tested here should map directly onto the week template already built for opening week, so the rehearsal and the real first week run the same script rather than the rehearsal testing one version of the schedule and opening week running a different one that was never actually tried.