Fable
Triage Desk and Consultation Coordination Office
A large general hospital set up a triage desk in its outpatient hall. Patients described their symptoms upon entry, and the triage nurse determined whether they should register for internal medicine, surgery, or dermatology based on the description. The basis for triage was the symptoms themselves—stomachache to internal medicine, fracture to surgery, rash to dermatology. The nurse did not diagnose, only routed.
The hospital also had a consultation coordination office, handling another kind of allocation problem. When a case involved multiple departments—for example, a diabetic patient who fell and broke a bone needed both blood sugar control and orthopedic surgery—the coordination office decided, based on each department's expertise and scheduling, which endocrinologist and which orthopedic surgeon would handle it jointly. The coordination office did not analyze symptoms; it only matched doctors' capabilities.
For a while the hospital was doing process optimization, and someone proposed merging the triage desk and the coordination office into a unified dispatch center. The new center ran for two weeks before something went wrong: a patient with abdominal pain was triaged to internal medicine, but after examination the internal medicine doctor found it was an ectopic pregnancy requiring immediate transfer to gynecological surgery. The unified dispatch center had routed by symptoms to internal medicine, but lacked the ability to recognize that this was a cross-department case requiring emergency gynecological intervention.
A retrospective review found that triage is about making a quick directional judgment based on the surface features of symptoms, while scheduling and coordination requires understanding new requirements and cross-domain dependencies that emerge during task execution. The former matches a single initial path based on the semantic features of the input; the latter dynamically adjusts the combination of executors based on task progress. After merging them, the reliability of both dropped at the same time.
The hospital restored the two-tier structure of the triage desk and the coordination office, but added a linkage rule: when the coordination office receives a case transferred from the triage desk, if during execution in the initial department it is found that other departments need to be involved, the coordination office has the authority to allocate resources directly without returning to the triage desk for re-routing. The triage desk handles the first hop at the door, and the coordination office handles all subsequent hops.
Later someone drew a diagram to explain dual-layer routing: the triage desk is the router at the request entry point, deciding the first stop after reading a single sentence; the coordination office is the orchestrator during task execution, watching task progress and adjusting the subsequent team composition at any time. Compressing these two networks into one means the first stop may already be judged wrong, and no one later corrects it.
Two years later, when the hospital's IT department organized its architecture documentation, it classified the triage desk under intent recognition and semantic routing, and the coordination office under consultation coordination and capability routing. The same word "routing" appeared in both, but one handled entry-point distribution and the other handled execution coordination. A note was written at the end of the document: don't use a gateway as an orchestrator, and don't make an orchestrator do entry-point distribution.