The Big Idea Behind The Creation Of SIP
By Dan Schell, Chief Editor, Clinical Leader
I’ll admit; I was conflicted when I decided to write about the Shared Investigator Platform (SIP). After all, this is a company’s (Cognizant) product, and I don’t write about vendors. I also don’t want to ever seem like I’m promoting or, conversely, disparaging any company’s product or service.
Still, during the three years I’ve been focused on the clinical trials industry, SIP is one of those topics that has surfaced dozens of times in both in-person conversations and online. It’s become the poster child for any discussion around the use and development of sponsor platforms, in general, and that made me curious. Not only did I want to know why there’s so much SIP negativity out there, I wanted to know its origin story and if those complaints are warranted.
I ended up interviewing nine people for this article; some of whom are still using it today, and a few of the original architects who, to a person, never expected their creation to have the reputation it does today. But hold on … let me add a caveat to that last statement. There are still thousands of SIP users out there, and I know plenty of them are likely fans of the platform. But as we all know, unfortunately, the voice of positivity is usually the quietist.
Quick SIP Recap
In case you don’t know about SIP, I’d suggest you start by reading From vision to momentum: How Shared Investigator Platform continues to unite global clinical research. A retrospective on the SIP’s journey — and the road ahead, which Cognizant posted to their website in September 2025. Here’s a snippet from that document that will set the stage for you:
The founding vision was both clear and bold: Create a shared, standardized digital infrastructure that would eliminate duplicative administrative burdens, improve sponsor-site engagement and ensure faster, more consistent trial readiness. SIP brought this vision to life by offering a single, unified platform where investigators and sites could work with multiple sponsors in a consistent, sponsor-agnostic way. This unity transformed SIP from a collection of tools into a shared environment, built to scale with the industry and centered on the needs of sites.
That document also has a really helpful timeline showing how the platform evolved over the past decade.
In this first of a four-part series, I’ll cover some of the main points made from three of SIP’s early architects: Jackie Kent, now retired but who formerly served 23 years with Lilly; Lisa Moneymaker, current chief operating & strategy officer at Medidata and former 18-year employee of Amgen; and Jeanette Teague, a 25-year veteran of BMS who since 2025 has been director, product management for life sciences products and platform at Cognizant.
Meet The New Problems, Same As The Old Problems
What struck me most in talking with all three of these women is how familiar the original problem statement sounds today. Essentially, they were trying to eliminate a collection of mundane, repetitive tasks that sites were complaining about a decade ago, and unfortunately, are still complaining about.
Interestingly, the team did not initially set out to build a completely new platform. Teague remembers TransCelerate asking its member companies to show one another the proprietary investigator portals they already had. The hope was that one might provide a starting point for the shared environment. BMS had its own portal, built with Accenture. Other sponsors brought theirs to the table as well.
Kent remembers other obstacles emerging almost immediately. One existing sponsor platform was single-tenant and would have required a costly rewrite to support multiple companies. There were also concerns about allowing one commercial vendor to become the portal through which multiple TransCelerate members operated. Eventually, the development work went through an RFP process, and Cognizant was selected.
Getting Competitors To Agree Was Part Of The Experiment
It’s easy, looking back, to think of SIP primarily as a technology project. However, my interviews convinced me that doing so misses an important part of what the original team was attempting. Before anyone could build a common platform, competing pharma companies had to agree on common ways of working. Teague remembers those discussions sometimes getting bogged down as representatives brought different company perspectives to the table. She still remembers something Moneymaker would say to get everyone moving: “Guys, let’s stop admiring the problem and just get to the solution.” Teague says she still quotes the line today.
That required something the industry frequently talks about but struggles to do: sponsors had to give up some company-specific preferences for the sake of a common process. Moneymaker recalls an early TransCelerate philosophy that companies should not compete over information that was not intellectual property. Investigator and site information fell into that category. If sponsors could share it safely, they could potentially stop asking sites for the same information again and again.
While researching this series, one thing I learned — that I doubt many people today know or understand — is that all of the TransCelerate SIP team members were volunteers loaned by their companies, yet they were helping define requirements, write user stories, test releases, develop procedures, and coordinate across organizations and development teams. Additionally, sponsors were being asked to adopt a platform whose full value depended on multiple capabilities quickly becoming available, and those capabilities were arriving gradually. “Ultimately, we were too slow; the development was just way too slow,” Kent said. “And, I think we underestimated the amount of ‘people’ infrastructure we needed to provide as TransCelerate.” The longer it took to create enough functionality, the harder it became to generate the volume SIP needed.
Sites Were Involved, But Adoption Was Everything
One common criticism of SIP is that the platform was designed by sponsors without sufficient input from sites. Teague calls that one of the “myths of SIP.” “There was actually a site advisory group that TransCelerate put together that was very involved,” Teague said. “They came to conference room pilots and played in the system and gave us feedback on design and prototypes.” She added that the advisory group intentionally included a diverse mix of operating models, from larger institutions to smaller sites, and that Kent helped make sure that diversity was represented.
Kent also remembers considerable enthusiasm from sites in the early days. The attraction was easy to understand. One proposed capability was an integrated task list that could show a coordinator what needed attention across studies from different sponsors. Instead of navigating separate environments to see what Lilly, Merck, J&J, or another company needed, the coordinator could theoretically see those tasks together. “The sites thought that was magic,” Kent recalled. “But if only Lilly implemented and J&J didn’t, for example, the value diminishes very quickly.”
That dependency may be one of the most important things to understand about SIP. A shared platform becomes more useful as more sponsors use it. If only a handful adopt it broadly, a site still has to maintain the other portals, logins, processes, and training requirements SIP was supposed to reduce.
Moneymaker remembers SIP never getting beyond six onboarded sponsors during her three years with the initiative, even as the number of investigators in the system surpassed 100,000 during that timeframe. Facility and investigator profiles grew because sponsors wanted enough structured information to reduce other repetitive requests, including feasibility questionnaires. That created a difficult tradeoff for sites. To deliver on the promise of entering information once, SIP first needed sites and investigators to enter and maintain a great deal of information. As requirements evolved, early users could be asked to return to their profiles and add dozens of new data points. The payoff depended on enough sponsors actually reusing that information.
Some investigators had dedicated considerable time building and updating profiles without seeing a corresponding flow of studies or reduction in administrative work. “The promise was there,” Moneymaker said. “But as the needs of what it meant to maintain your own profile expanded, I think everybody was caught off guard by what that would mean for the sites and how onerous it could be.” Teague also remembers some sites expecting that joining SIP would lead to more study opportunities, something she says she still hears today. That was never SIP’s intended function; investigator discovery was addressed separately through TransCelerate’s Investigator Registry (IR).
There’s More to SIP’s Legacy Than Just SIP
The complexity of this undertaking extended beyond just the actual final product’s functionality. For example, as Kent noted, “The financial model is tough because it’s a site-serving software that sites don’t have the money to pay for.” When sponsors pay, they naturally want influence over requirements and processes. Yet the more sponsor-specific requirements that creep into a shared platform, the harder it becomes to deliver the simplicity sites were promised.
Moneymaker also points to less visible complications. Sharing investigator information at scale required consents, privacy agreements, data-processing arrangements, and decisions about data ownership. An investigator’s information could not simply be placed into a common database and shown to every current and future participant. Those permissions had to be secured, maintained, and managed as the investigator population continued to expand.
For that reason, Moneymaker is skeptical of the idea that a different software developer alone would have produced an entirely different outcome. A better interface or faster development might have helped, but the underlying challenge still involved aligning large sponsors, maintaining investigator data and consent, changing internal processes, and convincing enough companies to put enough studies on the platform to make it genuinely useful to sites. She summed up the scale of the challenge this way: “We had some of the largest pharma companies paying money and dedicating resources to this project to make it possible, and it still couldn’t get there.”
She adds that the team eventually viewed SIP’s legacy more broadly than simply the platform that would become the permanent industry solution. “SIP will not be the ‘forever system,’ but it broke down barriers around even broaching the idea of data sharing.”
Teague had a similar conclusion. Getting competitors to agree on processes and build a shared environment was itself something the industry had not demonstrated it could do at that scale. “I think we did achieve that. We showed it was possible,” she said. “But not everybody adopted it, unfortunately.”
More than a decade later, perhaps SIP’s most interesting legacy is the idea behind it: competing companies agreeing that some processes and information are more valuable when they are standardized or shared. TransCelerate pursued that same thinking with its IR, which allowed member companies to pool information from consenting investigators to reduce duplicate site qualification activities. Today, IQVIA’s One Home for Sites takes a different approach to the same site-burden problem, connecting systems from different sponsors and vendors through a common access point rather than trying to replace them. And on a much broader scale, CDISC has demonstrated what can happen when an industry agrees to common standards for collecting, structuring, exchanging, and submitting clinical research data. SIP may not have become the universal environment its architects envisioned, but the principle behind it hasn’t disappeared: there are parts of clinical research where everyone doing things their own way creates more burden than competitive advantage.
In future installments, I’ll cover more early team members’ recollections of the SIP creation process and talk with users who will share their feedback.