Inside modality-aware booking
Why a generic 'book an appointment' agent can't run a radiology front desk, modality rules, prep, contrast and referral checks, and what we built instead.
A generic “book an appointment” agent breaks the first time someone asks for an MRI. This post explains why, and what we built instead.
The problem in one sentence
In radiology, “the appointment” is a five-variable function of the modality, the body part, the contrast requirement, the funding pathway, and the radiologist on shift, and the patient on the phone usually only knows two of those variables.
What goes wrong with a generic agent
A generic booking agent treats the appointment as a single slot in a calendar. It hears “MRI” and offers Tuesday at 10:30. But the right answer depends on:
- Which MRI machine. A 1.5T MRI is not a 3T MRI for cardiac imaging.
- Which body part. A cervical-spine MRI takes 25 minutes; a multiparametric prostate MRI takes 60.
- Contrast or no contrast. A contrast study needs a radiologist available and more staff on the floor, so it only fits a slot where the roster supports it. The RANZCR standards set the expectations each practice then encodes as its own rules.
- Funding pathway. Bulk-billed vs. private vs. workers-compensation determines the slot pool the booking can come from.
- Referring practitioner. Some specialists require the patient to call back with a referral number; some don’t.
If the agent doesn’t ask about these, the booking is wrong. If the agent asks about all of them, the patient hangs up.
What we built
Modality-aware booking is a first-class object in TriageWorkflow. Each clinic defines:
- The modalities they offer (and which machine handles each)
- The body-part taxonomy and per-body-part duration
- The contrast/no-contrast rules per body part
- The funding pathways and their slot pools (and the roster behind them)
- The referrer-specific intake requirements
TriageVoice, TriageChat and TriageForms read this configuration in real time. When a patient asks for an MRI, the agent’s next question is shaped by what it already knows from the conversation, not by a generic decision tree.
The result
A booking made this way captures everything reception would have asked for on a manual call, so fewer bookings come back for correction. The patient leaves with the right slot the first time.
What’s next
We’re rolling the same model out to surgical scheduling next, with a different five-variable function but the same shape.
A wrong booking is a bad experience twice
Once when the patient arrives and cannot be scanned, and again when someone has to ring them back. Talk to us about the rules your intake should be applying, across your website and your phone, so a booking is right the first time.