SwiftCure

Describe your symptom — SwiftCure calls hospitals for you and compares their answers side by side.

Comment

Inspiration

Every version of this project started with the same small, universal frustration. You don't feel well, you don't know which hospital to trust, and the only way to find out is to call one, wait on hold, ask your questions, hang up, and do it all over again for the next one. Nobody enjoys this.

I didn't land here right away, though. The first idea was bigger and louder: an emergency pre-arrival system where an ambulance would notify a hospital before arriving. CALL-E's own safety layer politely refused, since it won't place emergency or critical care calls, and for good reason. I tried a second idea too, a real time, two way voice translator bridging two live speakers mid call. That one taught me that CALL-E is built for task oriented outbound calls with a goal and a structured result, not live audio bridging between two humans. Both rejections turned out to be useful. They pushed me toward something narrower, calmer, and actually buildable. What if the "emergency" wasn't a crisis at all, just the everyday emergency of not knowing which hospital can see you today?

What it does

You describe what's wrong, something like "skin rash for three days" or "knee pain for two weeks." Nothing else. No phone numbers, no hospital names, no forms to fill in about a place you've never called. SwiftCure matches your concern to a care category, then has CALL-E place real phone calls to three different kinds of care: a specialist clinic, a multi specialty hospital, and a smaller focused clinic, one after another. Each call asks the same five questions a real person would ask at the front desk. Is a doctor available and when, is it walk in or appointment only, how long do lab reports take, what do I need to bring, and roughly what will it cost. The answers come back as a clean side by side comparison, with the full call transcript available if you want the receipts.

For this build, the hospital directory is a curated dataset rather than a live search, which mirrors a real limitation worth being upfront about. Not every hospital has a working phone number published anywhere online. Sometimes the only listing is an address, and the only way to find anything out is to actually go there, which is the exact speed bump SwiftCure exists to remove but can't remove if the data simply doesn't exist. A real deployment would need a live directory lookup, like Google Places or a hospital registry, to close that gap, with a graceful fallback to "no number found, here's the address" when a call genuinely isn't possible.

And even when a call does connect, the honest answer is sometimes no. No doctor available for that condition today, or "we don't treat that here at all." SwiftCure treats that as a real, useful result rather than a failure. Knowing a hospital can't help you before you travel there is exactly the kind of information worth a phone call in the first place.

How I built it

The stack is intentionally plain. Node.js and Express on the backend, a single HTML, CSS, and JS page on the front. The real engineering lives in the CALL-E layer. My server plans a call, confirms it, runs it, and then polls for a result, parsing the returned transcript into the comparison fields shown on the dashboard. I built a small seed dataset of hospitals across five care categories, each tagged by type, so the comparison always shows genuinely different kinds of care rather than three interchangeable options.

Challenges I ran into

CALL-E's own safety filter taught me my first real lesson the hard way. Reframing "emergency" language into something calmer wasn't a workaround, it was the actual product decision that made this idea good. From there it was a string of small, honest voice AI problems. Transient network errors during planning and running that needed real retry logic, not just a single try. A polling window that was too short and marked genuinely successful calls as timeouts. A call that got asked to clarify "which language" out of nowhere, fixed by being explicit instead of assuming. And, the most human problem of all, a phone carrier quietly spam flagging repeat automated calls to the same number in one test session, which taught me more about telephony in an afternoon than I expected to learn.

The less technical, more uncomfortable challenge was accepting that the underlying data problem doesn't fully go away just because the calling problem does. Some hospitals simply don't have a discoverable phone number. The internet's picture of healthcare access is patchier than it looks from a search results page. I chose not to pretend otherwise. A hospital with no reachable number is a real dead end, and the honest move is to say so rather than quietly skip it.

Accomplishments that I'm proud of

Getting three real, sequential, structured phone calls to complete end to end, meaning plan, run, poll, extract, and compare, and landing them in a dashboard that actually tells you something useful instead of just "call completed." I'm also proud of resisting the urge to build the flashy version. The idea that seemed most technically impressive, live two way translation, wasn't the right idea. The idea that seemed almost too simple, comparing three hospitals like a person would, just faster, turned out to be the one worth finishing.

What I learned

Voice AI has real texture to it. Silence gets misread as a hang up, carriers have opinions about repeat calls, and a system built for safety will sometimes say no to a design that seemed reasonable on paper. None of that is a flaw to route around. It's the actual shape of the problem space, and designing with it instead of against it is what made this project feel real instead of theoretical.

What's next for SwiftCure

A real hospital directory, using Google Places or a proper registry, instead of seed data, so the comparison works for any location and not just a curated demo set. A dry run or preview mode before any real call is placed, in line with how CALL-E's own community expects phone call tools to behave responsibly. And eventually, the feature I deliberately didn't build first: letting a patient describe their symptom by voice instead of text, so the whole thing starts with a sentence instead of a form.

Share this project:

Updates

Submission history