Team: Zach Sawaged (GSAS ’20), Nathan Maher
About the Venture: Concordare Trials develops a universal digital protocol that standardizes clinical trial setup across software systems. Its platform converts protocols into ready-to-run workflows, reducing manual configuration time and operational errors.
Tell us about Concordare and the problem it aims to solve.
Concordare Trials is building a digital protocol infrastructure for clinical research. Clinical trial protocols are the detailed “guidebooks” that define exactly what has to happen in a study, from procedures and timing to eligibility and safety rules. They are often 300+ pages long and get sent to hospitals, vendors, and software teams so everyone can build and run the study. The problem is that thousands of people end up reading and reinterpreting the same protocol, then rebuilding it into calendars, checklists, and operational documents. That work is slow, expensive, and a major source of errors and protocol deviations.
Concordare turns any protocol into a structured, machine-readable format (our CPTM) using AI, so the protocol becomes a reusable digital backbone. Today, with Concordare Opus, hospitals can instantly generate the operational tools and documents they currently create manually, and sponsors can drive consistency without forcing a heavy new system on every site.
How did the team come together?
I started Concordare because I lived this problem firsthand in clinical operations. I worked at NYU Langone’s Perlmutter Cancer Center for four years and watched teams rebuild the same protocol logic again and again across different tools. It felt obvious that the protocol itself should be digital and reusable. As the concept became real, I pulled in people who understood both the reality of site workflows and what it takes to build durable software. I began reaching out to engineers early in their careers who were ready to dedicate their technical talent to the complicated world of clinical trials. After working with Nathan Maher for a couple months, I knew he was the right fit. He picked up the pain point quickly, drawing on his background in healthcare tech. We’re still growing the team and expect to bring on a couple more experienced clinical and product experts in the next few months. We’ve also built a strong bench of advisors with deep clinical development and product experience who keep us grounded in what will actually work in the field, not just what sounds good on paper.
What sets Concordare Trials apart?
Most “clinical trial software” helps manage parts of a study after the operational work has already been done, or it’s built around a single sponsor ecosystem. Concordare starts earlier and with more “boots on the ground;” we make the protocol itself interoperable. Our CPTM format is designed to work across any sponsor, any site, and any downstream system, so the protocol can drive consistent operations without forcing every site into a new monolithic platform. The practical difference is that we reduce interpretation work instead of just tracking it, and we make adoption easier because sites can use Concordare across all their studies, not just one study at a time. It’s a protocol-centric approach that’s universal by design, with a clear path to integration rather than another disconnected tool.
What motivated you to apply to the Challenge?
NYU is where I trained in biomedical informatics and where i started my career at the NYU Langone Cancer Center, its where the early foundation for Concordare was shaped. So I was always interested in continuing to build within the NYU community. The Entrepreneurs Challenge is a rare mix of disciplined feedback, visibility, and high-quality connections across healthcare, tech, and investing. I’m not looking for generic “startup advice.” We’re looking for sharp, specific input on how to scale distribution in a complex enterprise market. We’re building infrastructure, which means credibility matters. The NYU Entrepreneurs Challenge is a strong platform to show what we’ve built, what we’ve learned from real site workflows, and where we’re going next.
What has been the biggest turning point for you in your startup journey?
The biggest turning point was personal: it was the moment I stopped treating this like an interesting idea and started acting like I had the right to build it. For a long time, I knew the pain intimately from being in the trenches, watching teams grind through 300-page protocols and rebuild the same logic into calendars, checklists, and operational documents over and over. But knowing it’s painful isn’t the same as believing it’s a venture-scale problem, or believing you’re the one who should take it on.
What changed was realizing two things at the same time. First, this isn’t a small inefficiency, it’s a structural bottleneck that touches every trial and forces thousands of people to do redundant work that creates delays and errors. Second, I wasn’t just complaining about it, I understood it deeply enough to design a real fix. That’s when I got the confidenc, to say: I’m going to be the one who makes the protocol machine-readable and turns it into a digital backbone.
What have been the biggest challenges you’ve faced so far?
The hardest part has been building something that is genuinely useful in messy, real-world clinical operations while also meeting the bar for enterprise security, compliance, and integration expectations. Clinical research workflows vary by institution, and people are understandably cautious about changing anything that touches patient-facing operations or regulatory processes. We’ve handled this by staying site-first: we design around what research coordinators and site ops teams already do, then generate outputs that slot into their existing workflow. On the business side, the challenge is navigating long sales cycles and multi-stakeholder buying while still moving fast as an early team. We’ve leaned into pilots with tight scopes, clear success metrics, and an approach that reduces implementation burden instead of increasing it.
What are some recent milestones?
We’ve hit a set of milestones that turned Concordare from “promising” into “real.” On the product side, we’ve gotten strong validation through live pilots, including Rutgers, where we’ve been able to prove that a protocol can be converted into a structured format and actually drive the site-facing outputs teams rely on. In parallel, we’re actively finalizing our implementation process for major institutions like NYU Langone and MSK, which is forcing us to tighten everything: onboarding, security review readiness, training, and repeatable deployment.
On the company side, we’ve also secured funding, which matters because it gives us the runway to build deliberately instead of rushing or compromising on quality. Reaching these milestones has been intense, mostly because clinical operations has no shortage of edge cases and institutional nuance. But it’s also been energizing. Each pilot and implementation makes the problem feel bigger, and the solution more inevitable, because you can see the same operational pain show up everywhere, and you can see users immediately “get it” when the outputs land.
What advice would you give to aspiring entrepreneurs, especially those just starting out?
Your first goal is to truly believe what you’re building matters, and that you’re the right person to build it. That’s a chicken-and-egg problem because confidence often comes from external validation: a real customer, an LOI, a pilot, someone credible who says, “Yes, this is a real need.” The best way to get there is to pick a problem you’ve felt in your bones, not one you can explain in a slide. If you don’t understand the day-to-day pain deeply, you’ll build something that looks right but won’t get adopted.
Start with a narrow wedge that delivers immediate value, then expand from that foothold. Don’t confuse activity with progress either: customer conversations only matter if they change what you build or how you sell. Be honest about what’s hard and design around it instead of hoping it disappears, especially in regulated industries. And ship earlier than you’re comfortable with. Real feedback from real users is what makes the product better and makes you better. Momentum comes from delivering, not planning.