Создание единой платформы для клинических испытаний оказалось сложнее, чем ожидалось

Building SIP Was The Hard Part By Dan Schell, Chief Editor, Clinical Leader This is Part 2 of a four-part series. You can read Part 1 here. In Part 1 of this series on the Shared Investigator Platform (SIP), I spoke with Jackie Kent, Lisa Moneymaker, and Jeanette Teague about an idea that was remarkably ambitious for its time: get competing pharma companies to agree on common processes and create a shared environment that could eliminate some of the repetitive work being pushed onto clinical trial sites. Charlie Semenchuk and Jeff Ventimiglia were also part of that original SIP group, but they came at the challenge from different sides. Semenchuk, now senior director, head of GCDO Business & Technology Capabilities at Jazz Pharmaceuticals, was at AbbVie and served as one of SIP’s workstream leads, tech lead for the Investigator Registry (IR), and an original member of TransCelerate’s technology advisory committee. Ventimiglia, now SVP, operations and transformation at Medidata, was at Cognizant, where he was part of the small team charged with turning the industry’s plans and process maps into SIP 1.0. Talking with them helped me better understand something that wasn’t as apparent when I started researching SIP. Creating the vision — as with any huge endeavor like this — may have been the easy part. The real work came once they were faced with building a technology platform that could accommodate competing sponsors, thousands of sites, different processes, evolving requirements, and a business model in which the primary beneficiaries weren’t the customers paying for it. Ugh. Still, both men firmly believe the problem SIP was created to solve was — and is — worth solving. This Wasn’t Just Another Industry Committee There’s another part of the SIP story that has come up in every conversation I’ve had with its original architects: how close the group became. Kent, Moneymaker, Teague, Semenchuk, and Ventimiglia were working for different organizations, but SIP brought them together for an unusually intense stretch of collaboration. These weren’t occasional committee meetings. Members were volunteering substantial portions of their workweeks, traveling and meeting regularly, and trying to solve problems that required them to put their own companies’ preferred ways of working aside. Semenchuk remembers spending as much as two weeks a month with members of the team, sometimes more time than he was spending with his own family. “Most of us that worked on this are all still very close friends,” he told me. For Ventimiglia, those relationships also continued long after his work on SIP ended. Years later, he joined Kent at Medidata, and Moneymaker eventually joined them there as well. “When you say this had become a family for us, it really was,” he said. That closeness is worth remembering when looking back at the decisions the group made. These weren’t people casually sitting on an industry committee. They were deeply invested in making SIP work, professionally and personally. Semenchuk admits he wasn’t even sure that level of cooperation was possible when he first joined the initiative. After spending years working with different sponsor companies as a technology vendor, he knew how much each company liked doing things its own way. “This is never going to work,” he remembers thinking. “There’s no way. No one’s going to behave well. No one’s going to play nice together.” Instead, the opposite happened. The participants generally agreed that many of the processes surrounding sites weren’t areas where sponsors needed to compete. “We genuinely did walk in there saying, ‘Let’s do this for the betterment of clinical trials, and research in general, and make this better,’” Semenchuk says. Ventimiglia still looks back fondly on that experience, although admitting you helped create SIP can apparently make for an interesting introduction these days. He says mentioning his involvement sometimes gets him “this look of evil.” He even recalls meeting a site-network executive who, after hearing Ventimiglia had worked on SIP, “shot darts at me with his eyes.” That’s quite a legacy for a group that set out to make sites’ lives easier. Building One Platform For Everybody In Part 1, I described how the team initially hoped an existing sponsor platform could provide the foundation for SIP. When none could, the group faced the much more difficult task of creating something new. Semenchuk’s perspective provides a look at some of the technical decisions behind that process. For example, one important early requirement was portability. TransCelerate wanted a platform that could be moved to another provider if necessary. That meant the team couldn’t simply choose a proprietary technology environment where many of the capabilities SIP needed were already integrated. Semenchuk points to Salesforce as an example. He had worked extensively with the platform at AbbVie and believed many of the functions SIP needed could have been built there. But doing so would have tied the solution to Salesforce. “We basically concluded that we needed to ‘Frankenstein monster’ these pieces together,” he says. “You need to have a security element. You need to have a personnel ‘CRM-ish’ kind of element that manages contacts and relationships and facilities. Then you need to have a workflow component and a document exchange.” All of those requirements didn’t make the technology impossible to build, but it sure did make an already complicated undertaking a lot harder. Later, Semenchuk says, decisions around ownership of the intellectual property changed. Had the development team known at the outset how that would ultimately be structured, he believes some of its technology choices might have been different. Ventimiglia remembers another layer of complexity. He joined Cognizant after working extensively with research sites at Huron Consulting Group. Not long after arriving, he and two colleagues were handed approximately 10 process maps developed through earlier work and essentially told to start building. Suddenly, he found himself working with representatives from many of the world’s largest pharmaceutical companies. From a career perspective, he calls it “one of the coolest things I’ve ever done.” From a product-development perspective, however, it meant trying to create one platform for stakeholders who didn’t necessarily want the same thing. The More SIP Tried To Do, The Harder It Became Ventimiglia says SIP’s goal was clear: Make life easier for research sites. That’s likely a point many current detractors of the platform don’t know. But sites weren’t the organizations funding the platform. Sponsors were, and sponsors naturally had their own requirements. That tension is not unique to SIP. In the course of reporting on this topic, I’ve heard people acknowledge an uncomfortable truth: Some parts of the industry still seem to view sites less as partners and more as the mechanism for delivering a trial. When that mindset takes hold, reducing site burden can become a nice idea rather than a true priority. That observation isn’t academic for Ventimiglia. His mother was a research coordinator, and he says that experience gave him an early understanding of what coordinators and other site personnel deal with. “I know the burden of the site,” he says. “I know what those people go through, and I know the value that they bring to these patients’ life.” Those competing priorities were already evident during SIP’s development. Ventimiglia remembers sponsors talking about “my sites” and wanting private collections of their preferred investigators and facilities while simultaneously participating in a broader shared database. Meanwhile, sites had their own needs, but contrary to what some believe, those needs were not being ignored. Ventimiglia worked with SCRS to bring roughly 20 site representatives into the development process, including AMCs, independent research centers, and smaller clinics. That reinforces something Teague discussed in Part 1: The claim that sites weren’t involved in SIP’s development is too simplistic. They participated in workshops, design discussions, prototypes, and testing. It’s also probably fair to say SIP’s initial difficulties were more fundamental than whether the right tab was in the right place, for instance. Semenchuk points to one example. He and Pfizer’s Munther Barra argued that the initial user experience needed to be extremely simple, perhaps using a wizard to walk sites through setup. “If you can’t get that user in the first 30 seconds or so, you’ve lost them,” Semenchuk says. “It doesn’t matter how good or powerful the program is, you’ve lost them.” But there was another problem that no interface could completely eliminate. The more sponsors hoped to reuse information and stop asking sites the same questions, the more information needed to exist within the shared profile. That created a paradox. SIP was intended to eliminate repetitive administrative work, but delivering on that promise first required sites to enter and maintain a significant amount of information. Ventimiglia remembers the promise to sites as something almost resembling a professional social network. Sites could build what he describes as their own “Facebook profile,” complete feasibility information and potentially become more visible to sponsors looking for research partners. Approximately 100,000 sites eventually signed up. But the value of all that work depended on sponsors actually using the information. Ventimiglia still hears about that at SCRS. “I spent all of this time building my profile, setting up all my feasibility documents, talking about my negative 40 freezers and all the things that you told me were going to be easier,” he says, describing the complaint he hears from sites. “And then, I have never received a phone call in the last five years since I’ve done that.” His conclusion is pretty straightforward: “Nobody on any side of the equation was getting the value that was promised to them.” After that quote, I want to stress one thing: All of these comments were being made about what happened and was developed in the past. SIP has come a long way since then, and I’m guessing that some (not all) of the issues people had with it years ago may have been resolved. And I’m also guessing that even the people who complain the loudest about SIP would agree that the original intent of this concept was … well, a good idea. It was also an idea where success was very dependent upon scale. After all, the value of entering information once increases dramatically if many sponsors reuse it. But with limited sponsor adoption, sites could end up maintaining SIP while continuing to deal with plenty of other sponsor systems and processes. Again … ugh. The Problems Transcend The Application More than a decade later, neither Semenchuk nor Ventimiglia talks about SIP as though the industry was foolish to attempt it. If anything, both conversations left me thinking about how many of its original problems remain unresolved. Semenchuk wonders whether today’s technology could make an undertaking like SIP easier. AI-assisted development, for example, allows developers to build and change workflows and user experiences much more quickly than was possible when SIP was conceived. (Editor’s Note: Multiple vendors reached out to me after Part 1 was published offering me examples of applications that they are creating that are similar to SIP.) Technology alone, though, doesn’t eliminate the harder problem of interoperability. Semenchuk points to something most of us have probably experienced in healthcare. Hospitals can supposedly be using compatible systems and standards, yet records still don’t always follow the patient as seamlessly as expected. “I’ve gone to places where they’ve assured me that ‘the data is in there’ and ‘everyone can see it.’ But then at another ‘connected’ facility they say, ‘I can’t see anything that they put in here,’” Semenchuk recalls. “Same damn system, same everything. And they can’t even get that right.” His point is hard to dismiss. If healthcare organizations using supposedly connected systems still struggle to exchange information, creating a seamless environment connecting sponsors with thousands of very different research sites isn’t simply a matter of building a better application. Ventimiglia has additional worries. Sponsors increasingly want to work with sites and investigators they already know can perform. At the same time, large site networks and other organizations are consolidating research activity among a smaller group of established research centers. “We still don’t have a good way to identify research-naive sites or single-study sites that want to do more, and then help bring them into clinical research in a meaningful way,” Ventimiglia says. And that’s where his view of SIP becomes particularly interesting. For all the problems associated with building and scaling it, one of its ambitions was to make more sites visible and create a path for them to participate in research. “As much as I can sit here and look at myself and look at SIP and complain about all these things, I do think we’re losing something that in its intent was supposed to bring more research sites in and supposed to expand access to patients,” he says. That brings the story back to the group that started it. Semenchuk, Ventimiglia, Kent, Moneymaker, Teague and their colleagues weren’t simply trying to build another piece of clinical trial software. They were attempting to get competitors to standardize processes, share information, accommodate sites, satisfy individual sponsor requirements, and build a sustainable technology platform around all of it. Ventimiglia still seems struck by the collaboration required to even attempt it. “We had all these people, industry leaders from across every company who really wanted to go out and do something good,” he says. “And in 12 years since, I have never seen the pharmaceutical industry come together like that again.” Indeed, today’s clinical trial industry is still trying to solve many of those same problems. And perhaps understanding just how difficult SIP was to build is as important as debating how well the platform ultimately delivered on its original promise.