A health screening booking system needs one reliable view of capacity across the website, reception desk and group bookings. To prevent overbooking, it should check availability, allocate the required capacity and create the booking as one coordinated operation. Seeing an available time on a screen is not the same as having a confirmed place.
For a screening centre buying software, three questions matter: what does a place represent, which booking states consume capacity, and what happens when two channels request the last available place? The examples below turn those questions into practical acceptance checks. They are proposed business rules, not claims about an existing product.
Define what a place actually includes
A morning limit of 30 visitors does not mean every package and arrival window can accommodate 30 people. Packages may need different staff, rooms or equipment. A system that limits only the overall order count can still create resource conflicts.
Ask the operations team to define four things for each package:
The promise to the visitor: is the booking an arrival window or the exact start time of a service? An arrival window should not imply that every screening activity starts immediately.
The capacity unit: are you counting people, packages or a particular resource? One group order for five people must not consume only one place.
The time occupied: which intervals does the service use, including any required preparation or turnaround? The centre must approve durations; software defaults are not clinical guidance.
Shared resources: do different packages use the same equipment or staff? Their availability must be shared rather than independently treated as free under each package.
A first implementation can start with an arrival-window limit and the resource constraints that actually affect booking. Add detailed scheduling for individual screening steps only where it is needed. The HL7 FHIR R4 Slot documentation distinguishes availability states and describes slots that can accommodate more than one appointment up to a defined capacity. That is a useful modelling reference, but adopting a data format does not itself prevent overbooking.
Separate confirmed places, active holds and availability
Consider a demo centre with six places for a package from 09:00 to 10:00. Four are confirmed and one is temporarily held. Only one place remains:
Available places = capacity 6 − confirmed 4 − active holds 1 = 1.
This simplified calculation applies to the same capacity pool after package and resource requirements have been satisfied. If a required resource has no suitable time left, spare headcount alone must not allow the system to confirm a package that needs it.
Website and reception share capacity: at most one of two new requests receives the final place.
Website and reception bookings compete for the same remaining place. These are demonstration figures: the illustration shows that at most one of two new requests should be confirmed when only one place is available. It is not a performance report for a real product.
Define which states reserve capacity:
Viewing or selecting a time: this does not reserve a place by default. If selection does create a hold, the system needs to return an explicit hold record.
Temporary hold: associate it with a booking, an expiry time and release rules. The business sets the duration; there is no universal number of minutes specified here.
Confirmed: this consumes the agreed capacity and resources. A booking payable at reception must not be released merely because its payment state is unpaid.
Waitlisted: this is not a confirmed place. When capacity becomes available, the system still needs to recheck eligibility, notify the visitor and complete confirmation.
Keep payment and booking states separate. If a successful payment notification arrives after a hold has expired, the system should not simply turn the expired booking into a confirmed one. It must recheck capacity or send the case for staff review. Refund and rescheduling policies need their own rules; the concern here is avoiding duplicate allocation or release.
Decide who gets the last place at submission
Ask the vendor to open two booking sessions that both show one remaining place. Submit one from the website and one from reception at the same time. Only one should receive confirmation. The other should receive a clear availability message and an option to select again or join a waitlist.
The important check is not whether a button becomes disabled. It is how the server handles requests arriving together. Capacity validation and allocation should be one indivisible operation from the perspective of competing requests. The development team should explain the implementation and provide test evidence.
Include three failure cases:
Repeated clicks and network retries: a retry of the same booking request must not create a second order or consume capacity twice. If the first response is lost, the original result should be recoverable.
Failure during saving: the system must avoid leaving capacity deducted without a booking, or a confirmed booking without its allocation. Failed operations need a way to be inspected and recovered.
Repeated payment notifications: processing the same payment more than once must not create extra confirmations or deduct capacity again.
The NHS App's official booking help notes that another person may take a selected appointment before the user finishes booking. This supports a simple distinction between displayed availability and a completed reservation; it does not mean a screening centre should copy the NHS workflow.
Apply the same rules to staff, groups and closures
Phone, messaging and walk-in bookings kept only on paper or in a separate spreadsheet are invisible to the online capacity calculation. Reception bookings should enter the same capacity pool and retain their source and staff record. If a channel genuinely needs a reserved allocation, explicitly partition it from the total instead of offering the same places twice.
For group bookings, decide whether the whole group must fit or partial confirmation is permitted. The displayed headcount, capacity deduction and confirmation message must agree. Do not silently mark unallocated group members as confirmed.
When equipment becomes unavailable, staff are absent or operating hours change, require a workflow that:
Stops new bookings for the affected capacity.
Identifies confirmed bookings, active holds and waitlist entries that may be affected.
Preserves existing commitments and contact records rather than deleting them automatically.
Rechecks resources and capacity before reopening availability.
If a schedule change reduces capacity below the number already confirmed, show the conflict and assign a person to resolve it. Displaying zero availability is not enough to reveal the existing shortfall. Any permitted manual overbooking should require appropriate authority, a reason and a visible record of its effect.
Put the scenarios into vendor acceptance tests
Use simulated records and test the public booking journey alongside reception. Retain the observed results:
Competing for the final place: two new requests submitted together produce at most one confirmation, with total allocation within the demo limit.
Duplicate submission: repeated clicks or retries of one request produce one valid booking and one capacity allocation.
Expired hold: capacity can be reassigned after expiry, and a later payment on the old request cannot bypass the current limit.
Shared-resource conflict: two packages requiring the same resource during overlapping intervals are blocked or referred for review rather than both being promised that resource.
Group headcount: an order for three people consumes three places. With only two remaining, the agreed all-or-nothing or explicit partial-confirmation rule applies.
Temporary closure: closing a time stops new confirmations while existing bookings remain traceable with a named operational owner.
Repeated release: processing the same cancellation or hold-expiry event twice does not add availability twice.
Also give the vendor a realistic estimate of simultaneous booking activity and agree on test conditions and evidence. A two-person demonstration checks one conflict case. It does not establish that the system will prevent overbooking under every workload.
Compare proposals against your booking rules
Prepare an anonymised sample week showing packages, headcount limits, constrained resources, staff booking procedures, temporary-hold rules and manual override permissions. Attach the acceptance scenarios and ask each vendor to distinguish existing features, configuration, development work and unsupported requirements.
Use HUACODE's booking-system enquiry page (Chinese) to share this rule set and discuss the fit of available software or required adaptations. Establish how every channel uses the same capacity before comparing calendar designs and development prices.
Sources checked: 22 October 2026. This article offers software procurement and acceptance-testing guidance, not clinical scheduling standards. Demonstration rules and concept visuals are not evidence of existing HUACODE functionality or measured performance.