Фрагментация систем клинических исследований усугубляет проблемы внедрения стандарта SIP

The SIP Problem Is Bigger Than SIP By Dan Schell, Chief Editor, Clinical Leader If you thought I was going to write a series about SIP and not talk to the people who are actually using today, well … you were wrong. If you’re late to the party, in Part 1, I spoke with three members of the original TransCelerate team about the problem they were trying to solve when creating this application. In Part 2 I spoke to two more original SIP architects and went deeper into the design and implementation challenges that followed. One big difference with this part is that all three of the folks I interviewed opted to remain anonymous. So, I’ll refer to them as SIP User 1, SIP User 2, and SIP User 3. Of course, I expected to hear complaints. That is, after all, what prompted me to write this series in the first place. And don’t get me wrong; I heard plenty of them. But, simply concluding that sites don’t like SIP and turning this into a gripe session misses the more interesting story. Some of their frustrations involve the platform itself, while others involve how individual sponsors choose to use it. And some of their complaints even had little to do with SIP specifically. Instead, the underlying message was that the industry continues to ask sites to enter and maintain the same information across an expanding collection of sponsor and CRO systems — which sucks. That’s where these conversations really got interesting to me. The first two articles explained how SIP was supposed to reduce exactly that type of duplication. I knew going into this that the data duplication problem still existed, but I didn’t know, in some ways, that it may be getting worse. When Using SIP Becomes Someone’s Job SIP User 1’s biggest frustration is documents. On one study, her site has more than 600 documents in SIP. The site must determine which ones are relevant, but the way files are named when exported can make that surprisingly difficult. She described downloading a batch of 50 files that were all given essentially the same name. The only way to determine what each contained was to open them individually. “There’s just no feasible way to go through that many documents in a meaningful way,” she said. The volume also can change dramatically from day to day, which, in retrospect, I understand. SIP sends notifications when new documents are uploaded, and User 1 said she might have two documents to deal with one day and 200 another. Search limitations and the number of documents that can be downloaded at once add to the work. But there’s an interesting wrinkle here: User 1 doesn’t place all of the blame on SIP. “I like the idea of SIP, and I don’t think the problems are necessarily caused by SIP alone,” she said. “I think they are sometimes caused by how sponsors use SIP.” She has seen sponsors use SIP more selectively, including for initial setup, without turning it into the repository for seemingly everything associated with a study. Her experience suggests the same platform can create very different workloads depending on what a sponsor decides to do with it. User 3 sees another version of the same problem. Sponsors don’t necessarily agree on what sites must put into SIP or how they should use it. One sponsor might require every field to be completed before considering a site. Another might use SIP primarily to identify investigators and conduct feasibility, then perform startup somewhere else. I understand her frustration here considering the promise of standardization was central to the initial SIP storyline. In Part 1, the people who helped create the platform described competing sponsors sitting together and trying to determine which processes could be standardized rather than insisting on doing everything their own way. According to my interviews, current users are still dealing with those differences. And they have a cost. User 2 told me her organization considered hiring someone just to manage SIP, but after discussing the idea, they decided the potential return wasn’t enough to justify the cost. That may be one of the most consequential criticisms I heard. A site technology platform being annoying is one thing. A site considering whether it needs an employee to manage that platform turns usability into a business issue. It becomes even more consequential when access to studies is involved. User 2 recalled a conversation with someone at a sponsor that runs studies her organization would like to participate in. The message was pretty clear: “They wouldn’t even look at you unless you’re in SIP.” That’s a much bigger problem than whether users like the interface or some random functionality. Someone Has To Maintain This Information There is an obvious counterargument to much of this criticism. Sponsors and CROs need accurate information about sites and investigators. They need to know where investigators work, their qualifications and experience, what facilities are available, and whether a site might be appropriate for a study. Somebody has to collect and maintain that information. So, if SIP disappeared tomorrow, that work wouldn’t disappear with it. Honestly, I don’t think these users are arguing otherwise. What they question is why sites have to perform so much of the same administrative work repeatedly and why the requirements can vary depending on who is asking. User 2 actually started our conversation by warning me against treating SIP as an isolated problem. “My take might be a little bit different from others,” she said. “I think this problem is systemic when it comes to platforms that manage site information this way.” She has encountered similar problems with systems created by other industry organizations. Sites are asked to create investigator profiles, associate physicians with facilities, maintain information, secure access, and learn another workflow. Sometimes simply getting everyone logged in and connected becomes a project. User 1 has had frustrations with other clinical trial platforms as well, including access problems affecting members of her staff. That doesn’t excuse problems with SIP. It does make it harder to argue that replacing SIP with another platform automatically solves them. This also connects directly to something I heard while writing Part 2. Sites were being asked to invest time building and maintaining extensive profiles with the expectation that sponsors could reuse that information. When reuse or study opportunities didn’t materialize, the value proposition started to fall apart. And when only some sponsors participated, sites still had to maintain all the other sponsor systems anyway. These current users described the repercussions of that equation. Fragmentation May Be Making The Problem Worse User 2 said sponsors and CROs are increasingly developing their own systems for collecting and managing site information. I understand why. They need reliable information and apparently aren’t getting everything they need from a common industry platform. But, again, consider what happens downstream. Every organization that solves its own site-information problem can potentially create another platform that sites have to maintain. “Anytime we get a new PI, we have to go into every single one of those apps and enter all that information,” User 2 said. “Your PI retires? You have to go in, make sure that’s updated.” At one point she joked that her organization has “82 platforms” to maintain. She immediately acknowledged the exaggeration, but I’m guessing many sites recognize the underlying problem. A new investigator joins. Enter the information again. Someone leaves. Update it everywhere. A sponsor introduces another portal. Learn another workflow. A CRO develops its own site database. Populate that one too. This is where I keep coming back to the first article in this series. One of the problems the original SIP team identified was the ridiculous number of systems sites were already navigating. One early assessment referenced a coordinator dealing with roughly 60 different logins. SIP was supposed to create a shared, sponsor-agnostic environment where information could be entered and reused instead of repeatedly requested. Years later, User 2 is joking about maintaining 82 platforms. I’m not suggesting those numbers are comparable measurements. In fact, they’re not. But it’s hard to miss what they say about the persistence of the problem. The industry keeps developing technology intended to make clinical trials more efficient, while sites keep accumulating systems they have to feed. There is another irony here. User 2 believes SIP has at least one significant advantage over some competing approaches: It allows investigators to give other personnel permission to maintain their profiles. Sure, that sounds minor until you consider the alternative. If every physician is personally responsible for maintaining profiles across numerous systems, the likelihood that all of that information remains current seems pretty remote. Finally, I wanted to make sure I noted that two of the three users I spoke with for this story were very complimentary about their Cognizant support person, saying they were responsive and helpful. So, it’s not getting the help they need, it’s the amount of assistance sometimes required to accomplish tasks within the platform that really frustrates them. That Original Idea Still Sounds Pretty Good At the end of two of my user interviews, I shifted away from SIP itself and asked what they would actually like the industry to create. “In a perfect world, we could enter this information once, update it quarterly or monthly, and all of those other platforms would integrate with one singular SIP platform,” User 3 said. “They’re only entering the data one time, and we’re only entering it one time.” That sounded pretty similar to the original vision for SIP. User 2 sees that opportunity as well. She believes the industry would benefit from a standardized place where site information could be maintained and accessed broadly. And despite her frustrations, she wonders whether SIP is still positioned to become that platform because the infrastructure and industry recognition already exist. Her concern is that the industry keeps moving in the opposite direction. Sponsors and CROs need better ways to identify and manage sites, so organizations build systems that meet their own needs. Sites then have another system to populate. The more fragmented the landscape becomes, the harder it may be for any shared platform to deliver enough value to persuade everyone to use it. Understandably, these current users pointed to plenty of places where SIP’s original vision hasn’t translated into their day-to-day experience. Their criticisms are legitimate and sometimes severe. But they also described an industry environment that makes the original SIP concept seem as relevant as ever. User 2 called the absence of a truly shared solution “such a miss in the industry.” That actually may be the bigger SIP story; the industry identified the problem years ago but still hasn’t solved it.