Booking a dialysis slot is not booking a doctor
A multi-location, multi-speciality hospital management platform where consultation appointments and resource bookings — scans, dialysis, procedure rooms — run through one engine that understands they are different problems.
Built with SmartDocx AI Systems Private Limited, a healthcare technology venture co-founded by GegoSoft's founder.
- SECTOR
- Hospital operations
- SCOPE
- Multi-location, multi-speciality
- TEAM
- 4 members
- ARCHITECTURE
- Microservices
- STATUS
- Private Beta
Why most hospital booking systems are really clinic booking systems
A clinic appointment involves one scarce thing: the doctor. Find a gap in the doctor's calendar, put the patient in it. Every calendar product ever built does this, and it is why hospital software often looks solved from the outside.
A dialysis session is not that. It needs a machine, a chair, a nurse with the right competency, a block of several hours, and turnaround time afterwards before the station is usable again. A CT scan needs the scanner, a technician, patient preparation before, and a radiologist to report after — and the reporting does not have to happen while the patient is present. Neither booking has a single owner whose calendar can be checked.
A hospital does not schedule people. It allocates several scarce things at once and hopes they line up.
We built the booking engine around resources rather than around practitioners. A doctor is one type of resource. A dialysis station is another. A booking is a claim on one or more resources for a duration, and availability is computed from whether every required resource is free — not from whether one person has a gap.
What made the engine hard
Duration is not fixed
Consultations run in short standard slots. A dialysis session runs for hours. The same grid has to represent both without forcing one into the other's granularity.
Availability is layered
A practitioner has working hours, a location has opening hours, a resource has service windows, and any of the three can be overridden for a specific date. The effective availability is the intersection.
Seniority gates access
Reception can book a general consultation. A super-specialist's time frequently should not be bookable by reception at all. The booking rules differ by who is booking, not only by who is booked.
Locations are not identical
A hospital group's branches have different equipment, different specialities and different hours. One schema has to describe all of them without a branch-specific codebase.
Blocking must be immediate
When a doctor is called into theatre, reception needs slots gone now — not after a settings change propagates. Blocking is a direct action on the grid.
The referral ladder, encoded
Hospitals run a progression: reception books a consultation, the doctor refers to a specialist, the specialist refers upward again. That ladder exists for a reason — the scarcest clinical time should be reached by referral rather than by whoever called first.
Most systems leave this to convention and a shared understanding at the front desk. We put it in the availability model. Each practitioner tier has its own bookability rules defining who may place a booking against it, so a super-specialist's calendar cannot be filled from the front desk simply because slots appear open.
The effect is quiet and worth stating plainly: the schedule enforces the clinical pathway instead of depending on staff to remember it during a busy morning.
What the platform covers
Technology choices and why
Shared foundations with the other LifeBridge platforms, so that records, scheduling, pharmacy and AI services interoperate rather than integrate.
NestJS microservices
Booking is the busiest service in the platform and scales independently of records and reporting. Separating it keeps a Monday morning rush off everything else.
MongoDB
Resource definitions differ by branch and by service type. A document model absorbs that without a schema migration per new equipment class.
Next.js
The slot grid is dense and updated constantly. Server rendering keeps first load fast for reception staff who reopen it all day.
Confirmations and reminders on the channel patients read, which affects no-show rates more than email ever did.
Claude and Sarvam
Claude for reasoning over operational data and report generation; Sarvam for Indic language handling in patient-facing interactions.
Nginx
Routing across services with TLS termination at the edge.
How the team built it
A four-person team. GegoSoft engineers use Claude Code as standard daily tooling, and on a booking engine the highest-value use was test coverage — availability logic has a large number of edge cases, and generating exhaustive cases against a specification is exactly the work that gets skipped under deadline.
The availability model, the resource abstraction and the referral rules were the team's design. Every change passed normal review before merge.
Where it stands
The platform shares its service architecture with the LifeBridge EMR, pharmacy and AI agent products, so a prescription raised during a consultation reaches the pharmacy without an integration layer between them.
Common questions
Can GegoSoft build a hospital management system for us?
Yes. We can build from scratch or adapt the LifeBridge architecture where requirements overlap. Which is more economical depends mainly on how unusual your scheduling and clinical workflows are, and that is what we assess first.
What is resource-based booking?
Booking that allocates equipment, rooms and staff together rather than just a practitioner's time. A dialysis session or a scan needs several scarce things simultaneously, and availability is only real when all of them are free.
Does it handle multiple hospital branches?
Yes. Branches can have different specialities, equipment and operating hours under one platform, with availability configured per location.
Can it integrate with our existing EMR or lab system?
Usually, though it depends entirely on what your current systems expose. We assess available APIs and data access before committing to an integration scope.
How does it handle DPDP obligations?
The hospital is the Data Fiduciary under India's Digital Personal Data Protection Act and holds the obligations; the platform is a Data Processor. Role-based access, tenant separation and access records are built so those obligations are achievable. Full enforcement begins 13 May 2027.
Scheduling more than consultations?
Tell us what your hospital books today and where the current system forces workarounds. Resource scheduling is where most hospital software quietly fails, and it is the part we will look at first.
Start a conversation See all case studies