Telehealth Go-Live Test: The Whole Patient Journey | DigiKat

This is general operational guidance, not legal, clinical or regulatory advice.

A form that submits is the easy bit. I've watched plenty of telehealth builds pass every form test, then wobble the first time a real patient cancels, pays twice or uploads the wrong file.

The test that matters follows one patient from first enquiry to follow-up. Can staff see the same state the patient sees? Do exceptions stop safely? Does the right person know what happens next? If you can answer yes on test records, you're close to ready.

This is the checklist we use with telehealth clinics running HubSpot or a connected patient-operations stack.

Why the journey is the unit of testing

A digital clinic rarely runs on one workflow. It runs on a chain. A patient submits information, staff review it, a clinician gets involved, documents or pathology are requested, payment is taken, fulfilment starts and follow-up continues.

Each hand-off can succeed on its own while the whole journey still breaks. A message fires for the wrong stage. A payment clears but the operational record never updates. A routine reminder keeps going after a clinician has paused the case. You only catch these when you test end to end.

Start with one record and one journey state

Before you add more automation, decide which record you trust. HubSpot can hold the patient's contact and communication context. Clinical systems stay the source of truth for clinical information and decisions.

Then give the journey one controlling status. For example:

• Intake received
• Information incomplete
• Awaiting staff review
• Consultation booked
• Clinician action required
• Payment pending or confirmed
• Fulfilment in progress
• Follow-up due
• Exception: needs a person

Avoid three different status fields that can disagree. Write down which field controls the journey, who can change it and which systems may write back to it. If your portal has grown a forest of properties, clean that up first. Testing a messy record just tests the mess.

Keep clinical decisions with clinicians

The Medical Board of Australia's telehealth guidelines expect the same standard of care as a face-to-face consultation. They also say prescribing through questionnaire-based tools, without a real-time consultation, is not good practice.

So your test plan should mark every step as administrative or clinical.

• Automation can handle: collecting details, confirming receipt, organising documents, routing a case, preparing a summary, sending an approved reminder and flagging an exception.
• A clinician handles: assessing suitability, interpreting results, diagnosing, choosing treatment, prescribing and approving clinical changes.

Our rule is simple. Bounded agents do permitted admin work. People approve. Clinicians make clinical decisions. Every test should check that automation stops at that line.

The six stages to test

1. Intake and identity

• Does a new submission create or update the right record?
• Are duplicates caught before staff act on them?
• Are consent and communication preferences captured?
• What happens when an email or phone number is missing, or shared by two people?
• Can staff see exactly what's incomplete?

2. Booking and changes

• Does the booking land on the right record and calendar?
• Have you tested time zones, reschedules, cancellations and no-shows?
• Do reminders stop when an appointment is cancelled or replaced?

3. Documents and results routing

• Can the system spot a missing document without interpreting it?
• Do uploads attach to the right record with the right access?
• Is clinical review recorded before admin steps continue?

4. Payment and fulfilment

• Does a successful payment update the status once, and only once?
• Are failed, abandoned, refunded and duplicate payments handled?
• Does fulfilment wait for every required approval?
• Can staff tell whether an issue belongs to the clinic, payment provider, pharmacy or courier?

5. Communications

• Does each email and SMS match the actual journey state?
• Are sensitive details kept out of channels that don't suit them?
• Are bounces, opt-outs and failed sends visible to staff?
• Do messages avoid implying a clinical decision that hasn't been made?

6. Exceptions

• Does every failure create a visible task or ticket with an owner?
• Can staff recover without creating a second patient record?

Test without flooding everyone's inbox

Big test runs create their own problem. Staff inboxes fill with dummy alerts, false urgency spreads, and the one message that matters gets buried. A few controls fix most of it:

• Use synthetic patient data. Never copy live health information into a test.
• Send test messages to a controlled mailbox or allow-list.
• Put a clear test marker in every subject line.
• Turn off non-essential escalations while you test individual steps.
• Write down how many messages you expect before each run, then compare.
• Have a person approve turning live enrolment and external sending back on.

HubSpot's workflow test tool helps with the first pass. It previews how a chosen record would move through a workflow without running the actions, and preview emails go to you instead of the contact. It won't show you how three workflows and two integrations behave together, so you still need the end-to-end run.

Build a small test pack

An improvised click-through isn't a test. A test pack is a set of named test records with the expected result written down for each stage. At minimum, include:

• one clean new patient
• one returning patient
• one duplicate identity
• one missing-information case
• one cancelled or rescheduled consult
• one failed payment and one refund
• one clinician pause
• one pharmacy or fulfilment exception
• one failed message
• one request the agent must refuse or hand to a person

For each one, record the expected owner, status, message, audit evidence and recovery action. Mark it pass, fail or conditional, and give every defect an owner. Screenshots alone won't tell you who is fixing what. Keep the pack and rerun it after every release.

Use a go-live gate with named people

Before launch, name a business owner, a clinical owner and a technical owner. Agree which failures block launch and which can be handled with a documented manual workaround.

The Australian Commission on Safety and Quality in Health Care is developing national safety and quality standards for virtual care. Whatever the final standards say, clear ownership, escalation and evidence are easier to design in now than to bolt on later.

If the change touches how you collect or share personal information, the OAIC's guide to undertaking privacy impact assessments is a practical way to find and treat privacy risks before you switch on.

The go-live checklist

• One trusted record and one controlling journey state
• Every clinical step marked human-only
• Role-based access, with only the data each role needs
• Synthetic test records for happy and exception paths
• A controlled test mailbox and expected message counts
• Human approval for clinical, payment and unusual actions
• An owner for every queue and escalation
• Duplicate, cancellation, refund and failure handling tested
• Audit evidence for workflow actions and overrides
• A rollback plan and a watched post-launch period

What good looks like

Good telehealth automation is easy to explain. The record is clear. Patients can self-serve safely. Agents stay inside admin boundaries. A person can see, approve and override what matters. If your workflows are getting harder to explain each month, start with a few simple ones that do real work.

Want a second pair of eyes on one patient journey before it goes live? Talk to us about telehealth and we'll map the record, the hand-offs and the test pack with you.