Building an AI-Powered Surgical Care Recommendation Platform

Anyone who's tried to figure out which specialist to see for a symptom that doesn't fit neatly into one category knows how much of that process still comes down to guesswork, phone calls, and general web searches that raise more questions than they answer. A healthcare client came to us with a version of that problem at scale: patients needed a faster, more reliable way to work out what kind of surgical care they might need and which doctor could actually help, without waiting on a first consultation just to get pointed in the right direction.

What we built is an AI-driven platform where a patient selects the body part involved, works through a conversation with a chatbot that adjusts its questions based on what they've said so far, and comes out the other end with a recommendation, procedure guidance, matched doctors, and a personalised care plan. No client name attached to this one, but the build is worth walking through in detail, because getting AI-assisted healthcare guidance right involves a lot more caution than a typical chatbot project.

Why This Was Harder Than a Standard Chatbot Build

Symptom-based AI guidance sounds simple until you actually sit down to build it. A generic chatbot can get away with loose, open-ended answers. A healthcare recommendation system can't, because a wrong or vague answer has real consequences, and research this year on general-purpose AI health tools has made that risk fairly public. A widely reported clinical stress test of ChatGPT Health earlier in 2026 found the tool under-triaged more than half of genuine emergency cases in testing, recommending patients wait 24 to 48 hours to see a doctor when they actually needed emergency care. That's the exact failure mode any purpose-built medical guidance platform has to design against from day one.

On top of that general risk, this particular build had its own list of technical hurdles. The chatbot's line of questioning had to change dynamically depending on the symptoms already described, not just follow a fixed script. Patients needed to be kept from describing symptoms unrelated to the body part they'd selected, since letting that slide would throw off every recommendation downstream. The system also had to handle conditions or procedures that simply weren't in its database yet, without the conversation just dead-ending. The landing page itself was built from a lot of nested content blocks that needed to stay manageable for non-technical admins to update. And because doctor recommendations were part of the output, every doctor profile needed real verification, not just a name and a speciality typed into a form.

How the Platform Was Built

A Chatbot That Actually Adapts

Rather than a scripted decision tree, the conversational flow runs on LangGraph, which lets the system branch its questions based on the specific body part and symptoms a patient has already mentioned. Different medical conditions get their own dedicated nodes and prompts, so a patient describing knee pain isn't funnelled through the same generic question set as someone describing shoulder pain. It's a meaningfully different approach from a flat FAQ-style bot, and it's what makes the follow-up questions feel relevant instead of generic.

Keeping Symptoms Tied to the Right Body Part

One of the simplest-sounding fixes turned out to matter the most. The platform only lets a patient select symptoms that are actually associated with the body part they've chosen. It sounds like a small constraint, but without it, a patient can accidentally describe an unrelated symptom and the system ends up recommending a procedure or doctor that has nothing to do with their actual problem. Locking that mapping down was one of the more important accuracy fixes in the whole build.

Not Letting Unsupported Cases Break the Flow

No database covers every condition on day one, and pretending otherwise would have meant either giving patients a wrong answer or leaving them stuck mid-conversation. Instead, when a patient's condition or the procedure they need isn't in the system yet, the query gets automatically escalated to the admin panel with full details attached, so a human reviews it rather than the AI guessing. It's a quiet feature, but it's the kind of guardrail that separates a system built with real caution from one that's just optimised to always produce an answer.

Making the Landing Page Manageable

The public-facing side of the platform involves a landing page with a lot of nested sections and content blocks, which gets unwieldy fast if every update needs a developer. A dedicated admin-side content management layer was built specifically to handle that complexity, so the marketing or clinical team can update messaging and structure without touching code.

Verifying Doctors Before They're Ever Recommended

Since the platform actively matches patients with doctors, doctor data had to be trustworthy from the start. Registration runs through an NPI-based verification process along with an admin approval step, so a doctor profile only goes live and only becomes recommendable once it's actually been checked.

What the Platform Delivers

Patients move through an assessment in minutes instead of waiting on a first appointment just to understand their options, and because the chatbot's questions are shaped by what's already been said, the recommendations that come out the other end line up much more closely with the patient's actual situation. Every assessment, doctor profile, and recommendation lives in a centralised PostgreSQL database with an admin dashboard on top, giving the healthcare team real visibility into what's happening across the platform rather than a black box that just spits out answers.

None of this is designed to replace a doctor's judgment, and the unsupported-condition escalation path exists specifically to make sure it doesn't try to. What it does is remove the friction and guesswork from the very first step of a patient's surgical care journey, and hand off to a human reviewer the moment the system runs into something it genuinely can't handle on its own.

The Bigger Picture for AI in Healthcare

Healthcare has good reason to be cautious about AI-generated medical guidance, and the data backs that caution up. Tens of millions of people already ask general-purpose AI tools health questions every day, and the same 2026 research that flagged ChatGPT Health's under-triage problem is a reminder that broad, general-purpose chatbots aren't built with the guardrails a clinical use case actually needs. A platform like this one is a fairly good example of the alternative: narrower in scope, built around explicit escalation paths instead of forced answers, and designed with LLM development services applied specifically to a constrained, well-understood workflow rather than an open-ended chat.

If your organization is weighing up AI and ML development services for something similarly sensitive, that's really the lesson here —custom healthcare software solutions built this way take longer to get right than a generic chatbot integration, but the extra care in scoping what the AI is and isn't allowed to decide is exactly what makes the difference between a tool clinicians can actually trust and one they have to double-check constantly. That's the kind of custom AI development services work that tends to hold up once it's actually in front of patients.