A health screening centre in Kenya should choose a booking system that connects package selection, appointment capacity, payment checks and reception registration. Compare the interface and price after establishing how these steps work together. A form that collects requests without managing confirmation or availability can leave reception staff reconciling calls, chat messages and spreadsheets.
This guide is for facility operators and software buyers. It covers screening-package bookings and operational workflows, not clinical recommendations or a complete hospital information system.
Decide whether you accept requests or confirm appointments
Both models can work, but the customer must understand what happens next.
Request followed by staff confirmation: the customer submits a preferred package and time. Reception checks the relevant conditions before confirming. This can suit facilities that still require manual scheduling checks. The screen should say that the request was received, without promising a confirmed place.
Confirmation when defined conditions are met: the system checks package availability, capacity and other agreed rules before confirming. It must account for staff-entered bookings and changes to availability as well as online orders.
The KUTRRH Wellness Centre page lists screening packages, requires advance appointments and provides several contact channels, including telephone, email and WhatsApp. This is a useful local example for asking how multiple booking channels will feed one record. It does not establish a standard workflow for all Kenyan facilities or reveal how KUTRRH's internal software operates.
If you already use clinical or laboratory software, define what information needs to pass between systems, who maintains it and how failed transfers are handled. A first-phase booking project should not silently include electronic medical records, laboratory reporting, insurance claims or clinical decision support.
Connect packages, time slots and capacity
A package is more than a name and a price. Give suppliers your package list, available dates, expected appointment duration and any relevant staffing, room or equipment constraints. Qualified facility personnel should approve clinical content and preparation instructions before the software displays them.
Use a small demonstration: a slot has capacity for four bookings. Two are confirmed and one pending request temporarily holds a place, leaving one available. Your facility must decide how long a hold lasts, whether an unpaid request reserves capacity and what happens when staff confirm it.
The facility defines whether pending requests hold capacity. Booking confirmation and payment are tracked separately.
DEMO-004, Demo Package A and the capacity figures are demonstration data. In this example a pending request holds one place; that is a design choice, not a universal booking rule. Payment and booking statuses are shown separately so that an unpaid order is not confused with an unconfirmed appointment.
Staff-assisted bookings, online bookings and corporate group bookings should follow the same capacity rules. When equipment becomes unavailable or staffing changes, the system should identify affected appointments and support follow-up rather than continue showing misleading availability.
More complex resource scheduling can be phased in. The initial release still needs a clear owner for capacity, defined actions that reserve or release places, and controlled permission to change those rules.
Check local payment and customer requirements
KUTRRH lists insurance, card and M-PESA payment options. Use this as a prompt to check your own operating model, rather than a requirement to integrate every channel at launch. Establish whether your facility takes full payment, a deposit or payment on arrival.
For M-PESA, ask for a demonstration from payment initiation through reconciliation. Safaricom's Daraja platform offers payment integration and notification capabilities. That does not establish that a proposed booking product has already implemented them. Confirm merchant requirements, activation scope, implementation costs and production testing separately.
Test cancelled payments, delayed notifications, repeated notifications and a successful payment whose booking is still unconfirmed. Each payment should match the correct booking. A customer-supplied screenshot should not substitute for confirmed payment information. Cash and manually reconciled payments also need an operator and a record of what was done.
On a phone, customers should easily find the location, package, arrival time and confirmation status. Display Kenyan appointments in the local time zone, such as EAT, and label amounts clearly in KES. Check English, Swahili and other language needs against your actual users; a Chinese-speaking procurement team does not imply that the customer booking interface should be Chinese-only.
Separate booking information from health reports
Collect the information required for the current booking step. Access to contact details, a package selection and an appointment time should not automatically give every employee access to full health records. Questionnaires, medical history and reports need separately defined purposes, access roles and handling processes.
Ask suppliers to explain:
What reception, finance, clinical and maintenance staff can view, change and export.
How departing employees lose access and how important actions are linked to individual accounts.
Where information is stored, which service providers process it and whether cross-border access or transfers are involved.
How retention, deletion and export are handled, and whether backups can actually be restored.
Whether reminders limit their content to necessary appointment information instead of exposing detailed health information in message previews.
Kenya's ODPC official guidance directory includes material on processing health data and is a starting point for further review. These are procurement questions, not a compliance certification. Assess applicable requirements against the facility's services and actual data flows; request evidence instead of accepting a general assurance that the system is compliant.
Make the supplier demonstrate five situations
Use synthetic information and review both the customer view and reception's workspace:
An ordinary booking: select a package and slot, follow the agreed payment arrangement and receive the correct status and arrival information.
The last available place: two customers attempt to book it; the system applies the agreed capacity limit without confirming both into the same remaining place.
A phone booking: reception enters it and online availability changes accordingly, with the source and operator recorded.
A payment exception: a delayed or repeated notification neither creates duplicate orders nor incorrectly confirms an appointment; someone owns the exception.
Operational handover: close a slot, identify affected bookings, then demonstrate export, staff access changes and backup restoration.
Record accepted results in the delivery scope, distinguishing existing functionality, configuration and new development. A concept image, a module name or one successful booking does not prove that exception handling is complete.
Compare costs against a defined first release
Separate software subscription or licensing, package and calendar configuration, payment integration, messaging charges, migration, training, hosting and maintenance. For existing systems, identify who supplies each interface and who handles later changes. An isolated development price cannot tell you whether the operational scope is complete.
Prepare a package list stripped of personal information, a sample week's schedule, your payment arrangements and the acceptance tests above. Discuss your booking-system requirements with HUACODE, asking the proposal to distinguish ready-to-use capabilities, local adaptations and items still requiring validation. Then compare a packaged solution with a custom implementation.
Sources checked on 21 October 2026. This is software procurement guidance. Third-party sources describe their own services or capabilities and do not establish equivalent HUACODE functionality.