Our First Pilot Challenged the Assumptions We Started With

The most surprising lesson was that follow-up volume was not the main obstacle. We started CTPathways with a specific theory about how care coordination fails at small outpatient practices: practices ordered more post-visit follow-up than coordinators could manage manually, so tasks aged without action. We built a sequencing engine to automate the outreach queue, route messages, and surface non-responders without requiring coordinators to track every patient by hand.

That theory was partly right, but direct pilot experience exposed important gaps. Six months of building in real clinical environments, observing care teams use the product, and listening to their concerns taught us more than the prior 12 months of product planning. Here is what changed, why it changed, and what we would have done differently sooner.

We had modeled the coordinator's job incorrectly

We based our original workflow model on interviews. Coordinators said they spent most of their time managing outreach tasks, following up with non-responders, and tracking referral status. That accurately described their formal responsibilities, but not how they actually spent their time.

A full day in a practice showed something different. Coordinator time was dominated by inbound phone calls, provider interruptions requiring immediate action, and the work of moving among systems to answer patient questions. The proactive follow-up we were building for happened in the margins, if at all. Coordinators were not starting with a dedicated outreach block. They were fitting that work around everything else.

This changed the coordinator interface. A sequencing engine with a prioritized queue helped only if a coordinator could use it in 2-minute increments and return without losing context. We rebuilt the queue so each item displays relevant context without a click-through, and completion takes one action. The original design took three or four steps to close a task. We recognized the problem only after watching it happen twenty times in one day.

Providers wanted visibility, not management

Our original product included a provider dashboard showing follow-up status for each patient's care. We assumed providers would want to monitor coordination activity. Instead, they wanted to know effortlessly whether patients needing follow-up were receiving it, not manage a dashboard.

The distinction matters. A dashboard asks a provider to look, then interpret. Providers wanted one signal: is someone on my panel waiting on an open coordination need beyond a concerning time window? They did not want a full status report. They wanted a flag, with the patient's name and issue when attention was needed. No flag meant no action.

We rebuilt the provider component around that need. Its default state is no notification when everything is on track. A notification appears only when a patient has not responded to outreach within a defined window, or when a referral remains unconfirmed beyond a threshold set by the practice. This significantly reduced cognitive load. Several providers in our early-access practices said the absence of dashboard noise was what they valued most, although we had not designed it as a feature. It emerged because providers would not maintain a dashboard.

Message content mattered more than timing

We assumed outreach timing would be the main way to improve follow-up completion. Send a message at the right time of day and cadence, and patients would respond and complete their next steps. Much of our early development therefore focused on timing optimization logic.

Pilot data indicated that message content predicted response rate more strongly than timing. The same message at 9 AM and 11 AM had roughly similar response rates. Adding visit-specific context produced a substantially different response rate. Patients responded to messages explaining why follow-up mattered for their visit, even when generic messages were timed optimally.

This was frustrating because content customization is harder to scale than timing optimization. Timing is algorithmic. Content quality requires either AI-assisted template generation with visit context or manual coordinator customization. We are still working on it, but we stopped investing heavily in timing logic and redirected effort to template quality and EHR data integration that can place the right fields in each message.

We started the BAA conversation too late

We underestimated the onboarding friction created by signing a Business Associate Agreement. A BAA is required under HIPAA for a vendor handling Protected Health Information for a covered entity, and we knew we needed one. We did not anticipate the variation in how small practices manage vendor agreements, or how often the BAA signer is not the person who decided to try the product.

In two early pilot practices, a significant delay separated "the coordinator wants to start" from "the BAA is signed." The BAA required the practice owner's signature, and the practice owner was in the office only two days a week. We now send BAA materials earlier and make electronic review and signing easy. That change alone meaningfully reduced our average onboarding timeline.

What held up after the adjustments

Not every assumption was wrong. Our core hypothesis that referral tracking represented a specific coordination failure held up well. Practices activating our referral module, even before we resolved every coordinator interface issue, showed meaningful improvement in referral confirmation rates within the first 8 weeks. Referrals going dark after being sent was a real problem. Our initial method for surfacing unconfirmed referrals for coordinator action was useful immediately, even in its rough first iteration.

The patient-facing message channel also held up. Patients in pilot practices responded to care-specific SMS messages at rates that supported the outreach approach. We were unsure whether patients would engage with text-based care coordination. The pilot data was clear: patients engage when messages are relevant and easy to answer, and disengage when messages feel like marketing or administrative noise. Clinical relevance remains our guide for when and what to send.

What this means for practices considering us now

We are sharing these learnings because transparency about the building process matters, and because practices considering CTPathways should know the product has been used in real clinical environments and revised around care-team needs. We are not saying it is finished. We are saying direct experience has shaped it in ways a product built primarily in a design studio has not been shaped.

We have fixed most of what we got wrong. We have documented what we are still learning and are actively addressing it. If you are considering care coordination tools, we would rather begin with that honest picture than a polished account of an ideal product.