Sources: 5 · Verified 2026-09-18
A request that cannot be served at its first location creates a measurement problem before it creates a scheduling problem. The same caller may be eligible for referral to a second branch, may be offered a slot that belongs to a different owner, may face travel constraints that were never captured, and may end in a disposition that no one records. If those four elements are not tied to one visible request record, any comparison of overflow performance across locations is an artifact of record keeping rather than a finding about operations. This brief frames a routing measurement study for multi site service networks. It defines the record unit, the fields that must travel with a request, the observation window, and the inference boundary. It draws on public guidance from BLS, AHRQ, NIST, the U.S. Census Bureau, and CDC for measurement design, data quality, and transparent evaluation. No performance statistics are asserted here because none are established by those sources for this specific routing context.
Workflow at a glance
| Factor | Details |
|---|---|
| Scope | Define the request as the unit, set the observation window, and state inclusions and exclusions before collecting data. |
| Ownership | Record which location or clinician owns each offer, with a timestamp, so accountability is traceable across the routing path. |
| Boundary | A retrospective cohort can describe what happened in the window; it cannot establish cause without a defensible comparison. |
Research Question and Scope
The research question is narrow: when a request overflows from a full or ineligible location to another branch, clinician, or provider, what must be recorded on the same request record for cross location comparisons to be defensible? Scope covers multi site service networks that keep one visible request record while routing internally. It excludes requests that are abandoned at intake, requests handled entirely by an external referral partner with no shared record, and walk in traffic with no prior request. The unit of analysis is the request, not the appointment, because one request can generate multiple offers and one appointment can satisfy multiple requests in some referral arrangements. Required intake fields include request identifier, originating location, requested service or clinician type, date and time of first contact, channel, and stated constraints such as travel radius, language, and availability windows. Required routing fields include eligibility determination, reason for overflow, offer owner at each step, offer timestamp, and expiration. Required disposition fields include final state, final location, time to disposition, and reason for closure. The CDC Program Evaluation Framework supports stating evaluation questions and intended use before data collection, which is why these fields are specified in advance rather than reconstructed after the fact. The U.S. Census Bureau Statistical Quality Standards support documenting definitions, sources, and known limitations so that downstream users can judge fitness for use.
Required scheduling checkpoints
| Category | Specific Tasks | Time Saved / Week |
|---|---|---|
| Intake |
| Not established by cited sources; measure duplicate entry minutes per request before and after field consolidation. |
| Readiness |
| Not established by cited sources; measure rework minutes caused by missing eligibility or ownership fields. |
| Disposition |
| Not established by cited sources; measure reconciliation time spent resolving collapsed or conflicting dispositions. |
- Category
- Intake
- Specific Tasks
- Capture request identifier, channel, and first contact timestamp
- Record requested service, clinician type, and originating location
- Record travel radius, language, and availability constraints
- Time Saved / Week
- Not established by cited sources; measure duplicate entry minutes per request before and after field consolidation.
- Category
- Readiness
- Specific Tasks
- Record eligibility determination and reason for overflow
- Assign offer owner and log offer timestamp and expiration
- Flag rule changes inside the observation window
- Time Saved / Week
- Not established by cited sources; measure rework minutes caused by missing eligibility or ownership fields.
- Category
- Disposition
- Specific Tasks
- Record final state as scheduled, ineligible, declined, expired, or unreachable
- Log final location and time to disposition
- Report missingness by field and by location
- Time Saved / Week
- Not established by cited sources; measure reconciliation time spent resolving collapsed or conflicting dispositions.
Weak notes versus actionable records
| Cost Factor | In-House Control | SchedulingAppointment VA |
|---|---|---|
| Definition control | Definitions written and revised internally, with direct access to routing rules and staff. | Definitions must be documented and transferred; ambiguity surfaces as inconsistent coding. |
| Field completeness | Entry occurs at the point of contact, but staff may skip optional fields under volume. | Entry depends on a written field specification and a completeness check at handoff. |
| Ownership traceability | Offer ownership can be assigned directly in the scheduling system. | Ownership must be recorded per offer with timestamps to remain traceable across parties. |
| Disposition accuracy | Final states reflect internal knowledge but may be collapsed for convenience. | Final states depend on agreed value sets; mismatched categories distort comparisons. |
Definition control
- In-house
- Definitions written and revised internally, with direct access to routing rules and staff.
- Our VA
- Definitions must be documented and transferred; ambiguity surfaces as inconsistent coding.
Field completeness
- In-house
- Entry occurs at the point of contact, but staff may skip optional fields under volume.
- Our VA
- Entry depends on a written field specification and a completeness check at handoff.
Ownership traceability
- In-house
- Offer ownership can be assigned directly in the scheduling system.
- Our VA
- Ownership must be recorded per offer with timestamps to remain traceable across parties.
Disposition accuracy
- In-house
- Final states reflect internal knowledge but may be collapsed for convenience.
- Our VA
- Final states depend on agreed value sets; mismatched categories distort comparisons.
Methodology and Data Quality
The design is a retrospective cohort of request records over a defined observation window, paired with a prospective validation sample. The window should be long enough to include normal demand variation and short enough that routing rules and location capacity are stable; document any rule changes inside the window and treat them as strata or exclusions. Sampling follows NIST Engineering Statistics Handbook guidance: define the population, state the sampling frame, and describe how records were selected. A simple approach is a census of overflow requests in the window, with a random sample of non overflow requests as a comparison group. Data quality checks follow the U.S. Census Bureau Statistical Quality Standards: each field has a definition, an allowed value set, an owner, and a completeness threshold. Key checks include duplicate request identifiers, timestamps that precede first contact, offers with no owner, dispositions with no timestamp, and eligibility flags that conflict with the stated reason for overflow. Missingness must be reported by field and by location, because differential missingness across locations can create apparent performance gaps. The AHRQ CAHPS Improvement Guide supports linking measurement to a defined improvement cycle, so the study should name the decision the data will inform, such as whether to change referral eligibility rules or offer ownership. Any statistic reported should carry its denominator, its observation window, and its exclusion list.
Analysis Plan and Inference Boundary
Analysis proceeds in three layers. First, descriptive counts: requests by originating location, overflow reason, eligibility outcome, offer count, and final disposition, each with a denominator and a time window. Second, time measures: time from first contact to first offer, first offer to acceptance or decline, and first contact to final disposition, reported as distributions rather than single averages because scheduling delays are typically skewed. Third, comparison across locations, using the same request definition and the same disposition states. Inference is bounded by the design. A retrospective cohort can describe what happened in the window; it cannot establish that a routing rule caused an outcome unless assignment to routing paths was effectively random or a suitable comparison was constructed. Confounding is likely: locations differ in service mix, staffing, payer mix, and geography, and these differences travel with the request. The CDC Program Evaluation Framework supports separating findings from interpretation and stating alternative explanations. Practical rules: report the number of requests excluded and why; do not compare locations on acceptance rate without also reporting offer volume and offer ownership; do not treat a disposition of no appointment as a single category when it can mean ineligible, declined, expired, or unreachable. Where a number is not established by a source, state the measure to be collected rather than supplying a figure.
A controlled scheduling workflow
| Success Factor | How To Do It | Results You Get |
|---|---|---|
| Single request record | Use one persistent request identifier across locations, offers, and dispositions. | Routing paths can be reconstructed without joining incompatible extracts. |
| Explicit eligibility | Record eligibility outcome and the specific reason for overflow at the point of decision. | Ineligible and capacity driven overflow can be separated in analysis. |
| Offer ownership log | Log owner, timestamp, and expiration for every offer made during routing. | Accountability is traceable and offer volume is countable per location. |
| Stable disposition states | Adopt one value set for final states and apply it across all locations. | Cross location comparisons rest on the same categories and denominators. |
- Success Factor
- Single request record
- How To Do It
- Use one persistent request identifier across locations, offers, and dispositions.
- Results You Get
- Routing paths can be reconstructed without joining incompatible extracts.
- Success Factor
- Explicit eligibility
- How To Do It
- Record eligibility outcome and the specific reason for overflow at the point of decision.
- Results You Get
- Ineligible and capacity driven overflow can be separated in analysis.
- Success Factor
- Offer ownership log
- How To Do It
- Log owner, timestamp, and expiration for every offer made during routing.
- Results You Get
- Accountability is traceable and offer volume is countable per location.
- Success Factor
- Stable disposition states
- How To Do It
- Adopt one value set for final states and apply it across all locations.
- Results You Get
- Cross location comparisons rest on the same categories and denominators.
Limitations and Alternative Explanations
Several failure modes recur in overflow measurement. First, denominator drift: counting appointments instead of requests, or counting only requests that reached an offer, which inflates apparent success by dropping early exits. Second, ownership ambiguity: an offer made by one location but attributed to another, which makes accountability untraceable and distorts location comparisons. Third, travel constraint omission: if travel radius and mode are not captured at intake, a declined offer may be recorded as patient choice when it was a distance problem. Fourth, disposition collapse: merging ineligible, declined, expired, and unreachable into one state hides the operational lever that would change the outcome. Fifth, window mismatch: comparing locations over different date ranges or with different capacity events inside the window. Sixth, eligibility rule changes mid window without stratification. Alternative explanations for any observed difference include case mix, staffing levels, referral partner behavior, and data entry practice. The U.S. Census Bureau Statistical Quality Standards call for documenting these limitations with the data. The AHRQ CAHPS Improvement Guide supports testing changes in small cycles before broad conclusions, which is a reasonable response when confounding cannot be removed. NIST guidance on sampling reinforces that a sample cannot repair a biased frame; if the frame excludes requests that never reached routing, the study describes routed requests only.
Responsible Use of Findings
Findings from this study should be used to improve record keeping and routing decisions, not to rank locations on a single headline number. A responsible use is to publish a small set of definitions, then report each location against those definitions with denominators, windows, and exclusions visible. Another responsible use is to route improvement work to the specific field that is failing, such as eligibility capture or offer ownership, rather than issuing a general performance message. Scheduling roles already carry substantial administrative load; BLS describes medical secretaries and administrative assistants as handling records, correspondence, and scheduling related duties, so adding fields without removing duplicate entry is a real cost that should be measured. The AHRQ CAHPS Improvement Guide supports iterative measurement tied to a defined aim, and the CDC Program Evaluation Framework supports stating intended use and audiences up front. Limits to state plainly: this brief does not report observed rates, does not compare named organizations, and does not claim that any routing configuration is superior. Where a decision depends on a number that is not established by a cited source, the correct next step is to define the measure, assign an owner, set the observation window, and collect it before acting.
Research methodology
The study design is a retrospective cohort of appointment request records over a fixed observation window, with a prospective validation sample to test field completeness and definition stability. The record unit is the request, identified by a single request identifier that persists across locations, offers, and final disposition. Each record carries intake fields, routing fields including eligibility and offer ownership, and disposition fields with timestamps. Records are included when a request was created in the window and reached at least one routing decision. Records are excluded when the request was abandoned at intake, when no shared record exists, or when routing rules changed inside the window without stratification. Descriptive analysis reports counts, distributions, and missingness by field and location.
Scope is limited to multi site service networks that keep one visible request record and route internally. It does not cover external referral partners without shared records, walk in traffic, or requests abandoned before routing. No performance statistics are asserted because the cited public sources do not establish routing outcome rates for this context. Any figure used in a local decision must be collected under the definitions in this brief.
Data sources and methodology
This brief reports published findings as stated by each source. It does not combine study populations into a new benchmark; local operators should treat the figures as context and measure their own workflow.
- BLS Occupational Outlook Handbook: Medical Secretaries and Administrative Assistants: Occupational duties and outlook for medical scheduling roles.
- AHRQ CAHPS Improvement Guide: Structured measurement and quality improvement guidance.
- NIST Engineering Statistics Handbook: Descriptive analysis, sampling, and measurement design.
- U.S. Census Bureau Statistical Quality Standards: Data quality and documentation standards.
- CDC Program Evaluation Framework: Transparent evaluation questions and interpretation.
Related content
Common questions
Why is the request, not the appointment, the unit of analysis?
Can this study show that one routing rule causes better outcomes?
What should be done when a needed number is not available?
Define the record before comparing locations
Before any cross location overflow comparison is published, confirm that one request record carries eligibility, offer ownership, travel constraints, and final disposition with timestamps. If any of those fields is missing or inconsistently coded, the comparison measures record keeping rather than routing performance. Start by documenting definitions and the observation window, then collect the fields that are absent.
Book a Free Consultation →