Building a Search Engine That Actually Helps Patients Find Trials

Most clinical trial search tools feel like they were designed in 2005. You type in a condition, get a wall of text, and hope for the best. The data is there—ClinicalTrials.gov is massive—but the interface often buries the needle in a haystack of bureaucratic jargon.

I built TrialsNearMe because I was tired of helping family members navigate the noise. The goal was simple: create a lightweight, fast interface that filters 22,000+ U.S. studies by location and condition without requiring a PhD in information architecture. This isn’t about reinventing the wheel; it’s about polishing the hubcaps so you can actually see where you’re going.

The Data Pipeline: Keeping It Fresh Without Heavy Lifts

The core challenge with aggregating public data is staleness. If your database is two months behind, you’re sending patients to closed studies or outdated contact info. For TrialsNearMe, freshness is non-negotiable.

Instead of scraping continuously and risking rate limits or inconsistent schemas, I set up a daily sync process. The script pulls the latest XML dumps from ClinicalTrials.gov, parses the essential fields—condition, location, eligibility criteria, and contact details—and normalizes them into a searchable JSON structure.

Why JSON? Because it’s lightweight and plays nicely with modern frontend frameworks. By pre-processing the data on the backend, the frontend doesn’t need to do heavy lifting. It just renders what’s already clean and structured. This approach keeps the initial load time under one second, even on slower mobile connections. The entire dataset is refreshed every 24 hours, ensuring that when a patient sees "Recruiting," they truly are.

Frontend Simplicity: Less Clicks, More Context

Many health sites overload users with filters that don’t matter. Do you really need to filter by "Phase 1" vs. "Phase 2" if you’re just trying to find a dermatologist in Austin? Probably not. Most patients care about three things: Is this for my condition? Is it near me? How do I talk to them?

The interface reflects this minimalism. There’s no sidebar full of checkboxes. Just a search bar and a results list. Each card shows the study title, location, and eligibility summary. If you need more, you click through. If you don’t, you’ve already found what you need.

I used a lightweight CSS framework to handle responsiveness. It’s not fancy, but it’s reliable. The layout adapts from mobile to desktop without complex media queries. The focus is on readability: high contrast, clear typography, and ample whitespace. No pop-ups, no cookie banners that block content, no unnecessary animations. Just information, presented clearly.

One subtle feature I added was smart contact extraction. Many trials list multiple contact points—principal investigator, site coordinator, administrative office. TrialsNearMe highlights the most relevant contact method based on the study type. For smaller, local studies, it prioritizes the direct site coordinator. For larger multi-site trials, it surfaces the central coordination email. This small heuristic saves users time and reduces confusion about who actually answers the phone.

Performance Matters More Than Features

In healthcare tech, performance isn’t just a metric; it’s accessibility. Many patients using these tools are on older devices or have limited bandwidth. Heavy JavaScript bundles, complex state management libraries, and unnecessary dependencies can cripple usability.

TrialsNearMe uses vanilla JavaScript for interactivity. No React, no Vue, no Angular. Just native DOM manipulation and fetch APIs. The bundle size is under 50KB gzipped. This means near-instant load times and minimal battery drain on mobile devices.

I also implemented a simple caching strategy. Search results are cached in localStorage for the session, so returning to a previous query doesn’t trigger a new network request. If the data changes overnight, the cache invalidates automatically. It’s a basic approach, but it works reliably without introducing complexity.

Testing was straightforward. I used Lighthouse to audit performance and accessibility scores, aiming for 95+ in both categories. The results were consistent across desktop and mobile. No major optimizations were needed beyond the initial setup, which speaks to how well lightweight architectures perform when done correctly.

Why This Still Matters

Clinical trials are often invisible to patients until they’re actively searching. By then, they’re usually overwhelmed and frustrated. A tool that cuts through the noise doesn’t need to be clever—it needs to be clear. TrialsNearMe isn’t trying to be the most feature-rich platform. It’s trying to be the fastest path from question to answer.

The code is open-source, and the architecture is deliberately simple. It’s a reminder that you don’t need microservices or GraphQL to build something useful. Sometimes, a well-structured JSON feed and a clean interface are enough.

What’s the biggest friction point you encounter when searching for health information online? Is it the interface, the data quality, or something else entirely?