ECHO | Devpost

Inspiration

We made ECHO after talking with physicians, patients, and healthcare technology industry experts about the referral process. Across those conversations, we kept hearing about the same gap: even after a physician decides that a patient needs to see a specialist, there is still a lot of work left to actually connect that patient with the right person.

Finding the right specialist can mean searching through different systems, checking insurance, calling offices, comparing availability, and trying to find someone who can actually see the patient soon enough. For rare or complicated cases, this becomes even harder. We also heard from patients about how much of this work can fall on them after receiving a referral, finding the doctor, checking reviews, figuring out insurance, calling offices, and trying to schedule an appointment.

Those conversations led us to the idea for ECHO: a physician-first referral platform that brings specialist matching, availability, insurance, distance, peer consultation, and clinical trials into one workflow. We wanted to cut through the noise around referrals and put the information that matters in front of the physician, while also reducing the amount of work patients have to take on themselves.

At the end of the process, our goal is simple: help physicians make better-informed referral decisions and help patients get connected to the right care at the right time.

What it does

ECHO starts with the physician's case notes. Claude helps read the notes and identify things like the specialty needed, urgency, and whether the case seems rare or complex. The physician can review this information before matching begins.

From there, ECHO uses a Parse → Gate → Score → Rank → Explain process to find relevant specialists. We didn't want to simply give every specialist a score and pick the highest number. Some things should be hard requirements. Specialists can be filtered out if they don't have the right clinical fit, don't accept the patient's insurance, or can't see the patient within the required timeframe.

Our urgency windows are 3 days for urgent cases, 14 days for soon cases, and 60 days for routine cases. Specialists who are available but can't meet the timeframe are still shown separately as available, but too late, so the physician can see what other options were considered.

The remaining specialists are scored based on clinical fit, availability, insurance, and distance. The weights can change depending on the case. For an urgent patient, getting an appointment quickly matters more, while a rare or complex case puts more emphasis on finding someone with the right expertise.

We also wanted the results to actually make sense to the physician. Instead of only showing a percentage, ECHO explains why a specialist ranked where they did, such as having a strong clinical fit, an appointment available in three days, or being 8.4 miles away. Issues like being out-of-network are also clearly shown.

Claude is intentionally only one part of the process. It provides a clinical-fit tier excellent, good, partial, or poor and a written explanation. It does not decide which specialist is the final choice. The actual filtering, scoring, and ranking happen in our Python code. If Claude isn't available, ECHO falls back to a rules-based keyword match so the system can still work.

The physician also stays involved after matching. A referral moves through Matched → Approved → Booked, and approval is enforced by the backend rather than just being a button on the screen. Nothing gets booked automatically. For more complicated cases, physicians can also use peer consultation to reach another physician for a quick opinion, and ECHO can surface potentially relevant clinical trials for rare conditions.

How we Built it

We built ECHO as a three-person team and split the project into areas we could work on at the same time. Our backend uses Python, FastAPI, PostgreSQL, SQLAlchemy, and Alembic, while the frontend uses React, Vite, TypeScript, Tailwind CSS, and TanStack Query.

One of our biggest decisions was defining our API contract early. This allowed us to work on the frontend, backend, and integrations without constantly waiting for each other. The frontend could initially run against mock data, and once the backend was ready, we could switch to the real API.

We also created a compatibility layer because our frontend and backend had developed slightly different API designs while we were working in parallel. For integrations, we built mock scheduling and insurance services, Google Maps distance calculation, ClinicalTrials.gov trial matching, and a WebSocket-based peer consultation system. We also used interfaces like CandidateProvider and Booker so the matching system doesn't have to care where the data comes from.

Challenges we ran into

One of our biggest challenges was figuring out how to use AI without making it responsible for the entire decision. It would have been simpler to give the case to Claude and ask it to choose the best specialist, but that would make the system harder to explain and test. Instead, we gave Claude a smaller, well-defined role and kept the important rules and ranking logic deterministic.

We also learned that insurance isn't just a yes-or-no situation. An out-of-network specialist might still be the right option for a rare case, so we created four states: in-network, unverified, out-of-network, and not accepted. Only “not accepted” is a hard gate, while the other situations are shown to the physician as part of the tradeoff.

Working as a three-person team also came with challenges. Since we were building different parts at the same time, our APIs didn't always line up perfectly. Instead of having one person stop and rebuild everything, we created a compatibility layer that allowed us to bring the different pieces together.

Accomplishments that we're proud of

We're most proud that ECHO became a working end-to-end system instead of just a collection of individual features. A physician can enter a case, get a ranked list of specialists with explanations, review the options, approve a referral, and move it toward booking.

We're also proud of the separation between AI and the actual decision-making. ECHO isn't saying, “Claude picked this doctor, so book them.” Claude helps us understand the case, while our own system applies the rules, calculates the scores, and gives the physician the final say.

More broadly, we're proud that ECHO addresses both sides of the referral. It helps physicians cut through fragmented information while reducing the amount of work patients have to do after receiving a referral.

What we learned

One of our biggest takeaways was that healthcare has a major coordination problem. The information needed to find the right specialist can exist in many different places, but it isn't always connected when a physician needs it. The same problem continues for patients after a referral, when they may still have to search, compare, call, and coordinate everything themselves.

We also learned that AI doesn't always need to make the final decision to be useful. Giving Claude a smaller, well-defined role made the system easier for us to understand and test while keeping the final decision with the physician.

From a development perspective, we learned how important it is to agree on interfaces early when multiple people are building at the same time. Having an API contract and clear boundaries between our components made it much easier to work independently and bring everything together.

What's next for ECHO

Right now, ECHO is a working prototype, so our next step would be making the system more realistic and production-ready. We'd replace our mock scheduling, insurance, and booking services with real integrations and work with physicians to validate our current scoring weights, gate rules, and urgency windows.

We'd also add proper authentication, real patient notifications, and more reliable peer consultation. We'd want to test our ClinicalTrials.gov matching with real trial data and expand our test cases to cover more unusual situations.

Eventually, we'd like ECHO to become more patient-facing, helping patients understand their referral options and stay connected throughout the process instead of leaving them to navigate the next steps on their own. We'd also like to explore ways for ECHO to help physicians recognize unusual patterns earlier and make referrals more efficiently.

At its core, though, the goal stays the same: help physicians make better-informed referral decisions and help patients get connected to the right care at the right time, while keeping the physician in control.