We started Enrollvue in 2023 with a clear enough hypothesis: clinical trial enrollment is slow primarily because sites cannot efficiently find eligible patients within their own EHR data. Build the tooling that makes that identification faster and more accurate, and you reduce the single biggest source of enrollment delay. The hypothesis turned out to be broadly right, but year one taught us that the path from "right hypothesis" to "working product" involves a lot of surprises that no amount of upfront planning fully anticipates.
This is an honest account of what we got wrong, what took longer than we expected, and what clicked faster. We are still a small team working out of Boston, and we have not solved everything. But we learned enough in the first year to know what we are actually building and why.
What We Got Wrong About the Technical Problem
Our initial framing was that the core technical challenge was natural language processing: take a protocol eligibility section, extract the individual criteria, and apply them against EHR data. We had seen enough research on clinical NLP to believe this was a solvable problem with the right engineering investment.
What we underestimated was how heterogeneous the EHR data problem is beneath the protocol-matching layer. The NLP challenge of extracting criteria from a protocol document is real, but it is, relatively speaking, a bounded problem. Protocols are written in English and follow recognizable structures. The EHR side is a different situation entirely. The same piece of clinical information, say the date of a patient's last chemotherapy cycle, might live in a structured order field, in a pharmacy record, in a progress note, in a discharge summary from an outside facility, or not in the local system at all. Matching against it requires knowing which representation exists in a given patient's record and having extraction logic that reaches all of them.
We spent roughly the first four months building against a cleaner data model than actually existed. Our first pilot conversations exposed this quickly, which was painful but necessary. We ended up rebuilding the EHR integration layer with much more explicit handling of data source uncertainty and completeness gaps. That rebuild added about three months to our timeline but produced a system that works in real site environments rather than an idealized version of them.
The Clinical Partner Process Took Longer Than Expected
Getting from "a research coordinator thinks this is interesting" to "the site's IRB, IT, and legal teams have reviewed and approved the integration" is not a fast process at any healthcare institution. We knew this in theory. We learned it viscerally in practice.
Our first clinical partner conversation went well. The coordinator was enthusiastic, the PI was supportive, and they were willing to be an early test site. Then we waited. The IT security review at that institution took eleven weeks. The legal team had questions about our data handling model that required written responses and a follow-up call. The IRB determination that our tool was quality improvement rather than human subjects research took another four weeks on top of that.
By the time we actually deployed at the first site, almost six months had passed since that first conversation. We were not doing anything unusual to cause those delays. That is just the pace at which healthcare institutions move when they are being appropriately careful about a new technology touching clinical data.
The adjustment we made was to stop planning timelines based on when we wanted to be deployed and start building in realistic institution review timelines from the first conversation. We also learned to run multiple partner conversations in parallel rather than sequentially, because some institutions would move faster and we did not want our progress gated on a single slow-moving review process.
What Worked Faster Than We Expected
Protocol criterion parsing. Once we committed to the right representation model, the extraction quality on well-formed protocol documents was better than we had anticipated. The variation in protocol writing style is significant, but the structural patterns of eligibility criteria are consistent enough that our parsing engine handles most protocols we encounter without manual intervention. There is a long tail of ambiguous criteria that still require clinical expert review, and we have not solved that. But the core parsing pipeline is more reliable than we projected.
The other thing that moved faster was coordinator adoption once the tool was actually deployed. We worried that asking coordinators to add a new step to an already busy workflow would create resistance. In practice, coordinators who had been doing manual chart reviews against protocol criteria recognized immediately what Enrollvue was doing for them. The feedback loop from "this used to take me two days, now it takes a few hours" was fast and gratifying. Coordinators want tools that reduce the tedious parts of their job. If you build something that genuinely does that, adoption is not hard.
The Data Privacy Architecture Took Longer But Was Worth It
The architectural decision to keep PHI local to the site, with only de-identified outputs leaving the site's network, was not our first design. Our initial architecture assumed a more conventional cloud data model with a Business Associate Agreement governing PHI handling.
We pivoted to the local computation model after our first IT security review flagged the PHI transfer as a category of risk that would require a more extensive review process. The pivot took about six weeks of engineering work and required rethinking how we structure the matching pipeline. It was the right call. The local computation model has consistently shortened the IT review timeline at every site since, because the data governance question simplifies considerably when nothing identifiable is leaving the institution's controlled environment.
We had to accept some constraints in exchange. Our visibility into matching results is more limited than it would be in a centralized data model. Debugging a specific candidate list issue requires working through the site's coordinator rather than examining the data directly. Those constraints are real, but they reflect how we believe clinical software should work: the institution's data governance model takes precedence over the vendor's operational convenience.
What We Know Now Going Into Year Two
The product works. That sounds like a low bar, but getting clinical software to actually function reliably in real healthcare environments, with real EHR data variability, is not trivial and it is worth acknowledging as an accomplishment.
The problem we are solving is real and consequential. Every conversation with a site coordinator or a sponsor team running a delayed trial reinforces that enrollment delay is not an abstract issue. It is costing drug development years and, in some cases, delaying treatments that could help patients.
We still have a lot to build. The NLP quality for complex temporal criteria is not where we want it. The EHR integration coverage for less common platforms is incomplete. The reporting and analytics layer for sponsors and CROs is early. And the institutional sales process is long enough that we need to be more systematic about pipeline management than a small team naturally tends to be.
Year one was harder and slower than we planned, and more validating than we expected. That combination is probably about what building a useful thing in healthcare tends to look like.