SCRS Talks

SCRS West Highlights: The State of Clinical Trial Tech

SCRS

Did you miss SCRS West: Clinical Tech & Innovation Summit? Hear some highlights from the discussions – hot topics, what sites are experiencing, and what's next for trial tech. SCRS Honorary President, David Vulcano, shares key insights from the Summit on how sites and industry partners can navigate tech challenges and optimize collaborative operations.


Jimmy Bechtel:

Thanks and thank you for being part of the Society for Clinical Research Sites on SCRS Talks. I'm your host, Jimmy Bechtel, the Vice President of Site Engagement with the Society. Get ready to dive into pressing clinical research industry topics, celebrate noteworthy achievements, and create a deeper connection with the research community. This is a space to amplify voices and perspectives that shape the landscape of clinical research. Today, we have again with us David Vulcano, the Vice President of Clinical Research, Compliance and Integrity with HCA Healthcare and SCRS's current honorary president. David, thanks for being with us again. For those that might not have heard previous podcasts with us, if you wouldn't mind, we'd love to start out with just a little bit of an introduction from you.

David Vulcano:

Jimmy. Thanks very much. I think you kind of covered the basics but I'm thrilled to be here. It was an exciting time at the SCRS west Conference. As most people know, that is the conference that focuses on site technology, and we definitely have had an increase in a number of technologies and site facing technologies and patient facing technologies that are, introducing some new opportunities as well as new challenges.

Jimmy Bechtel:

Thanks, David. Yeah, And that's exactly what we're here to do today is talk a little bit about what we learned from that SCRS West conference. It's 1 of the goals for every summit is for us to come away with new knowledge, new learnings, new action items. We can take back in a deeper understanding of What we might be able to do going forward to address some of the challenges and again, work towards solutions in this space. So let's start off with talking about the critical changes that we need to improve efficiency and quality of our clinical trials from the site perspective. You know, we talked about a lot of different things, but maybe highlight some of them that you observed at this year's SCRS West.

David Vulcano:

Sure Jimmy, we talked a lot of possible solutions and, and ideas that could be tossed around both from what the sites are able to do themselves, as well as what our sponsor, our CRO and our solution provider colleagues can also do to help improve the site user experience and productivity. I mean, one of the things that's been a constant trend is sites wanting to invest in their own technology. I mean, if you define quality as a reduction of variance. You know, you want to have reduction of variance at the site side to have that quality where the trial is actually being conducted. And we all know the age old problem of multiple pieces of technology, doing the same E. K. G. Machine are different E. K. G. Machines for different studies, different ePROs for different studies, different E consents. different ECRFs, things along those lines. And, for the sites to be able to bring consistency and scalability, decrease costs, increase quality, is to have that same consistent technology. We always joke in the hospital industry that you don't come into the hospital and say, oh gosh, No, I'm sorry. You're blue cross. So you can sit here while we change our EMR system from Epic to Cerner. It's, you know, seemingly tough to have the payers dictate some of the technologies when there's perfectly good technology out there. So sites have been hesitant to invest in their own technology, but we're starting to see that change now. And we're starting to see a lot more sponsors and CROs allow the sites to use the technology that they have either built or bought and that's perfectly adequate of taking care of the job. Other things that both sites and our other sponsors and CRO colleagues can do are mock visits. We talk a lot with Sponsors and CROs that say, gee, you know, we designed this great protocol. And then we decided that we would just walk through everything. And then we realized, my gosh, this is impossible to do. You have to do this before that, this before this, this can't happen until that gets logged in. And they actually learn a lot when they walk through what the patient or site experience would be. And that should be done not only at a sponsor or CRO, but also at the site level, because every site is unique and what may work in the ivory tower or the theoretical box of the sponsor or CRO may not work for every different site with their own unique circumstances. So, when a site gets it they should also do kind of a mock walk through with these visits so that they can learn about on how these different technologies will play into each other and help each other out or potentially cause problems. A third thing that we always hear about is the need to have a downtime strategy. So if we're having an e consent platform, whether it's the e consent is provided by the sponsors or CROs or whether the site is invested in their own e consent platform, to make sure there's always a downtime strategy. Technology works great when it works, but when it doesn't, we need to be able to pivot. And that can be just a general problem with the tech. It could be if there is a cyber. Security issue that you have to shift the paper or it could be preference of the participants of the study when they are just saying, I can't use the electronic consent thing for whatever reason that we can pivot to paper and be able to continue with doing the study and their participation. And then finally is some technology support. We all have problems with. The sites trying to be the help desk for these pieces of technology. And while sites can do a great job and supporting the participants with their facing technology, they're not adequate enough to do everything within that help desk, or are they able to, if it's a site operations technology to do their own help desk issues. So, we proverbially joke about the help desk. That's only available Monday through Friday, eight, 30 to 4 30 eastern standard time in english speaking only and we encourage our colleagues out there that if you are in the position to make investment decisions and technology to make sure that those technologies have adequate help desk support that's multilingual, but most importantly, timely response. Because when the technology isn't working at the site level, it's not working in a theoretical environment. It's likely has failed when we are sitting there with a participant and we're trying to get things done to prevent protocol deviations and do the safety visits timely. Those are some of the key things that we have have talked about some potential solutions and issues to address.

Jimmy Bechtel:

Well, there's a lot to tease out there, right, David? But one of the big themes that I listen to and hear when you talk about these things is sure there's site things that need to be done, and there's sponsor and CRO and service writer things that need done, but none of these are done in a silo. And I think that's what's really important for us all to understand is that we have to come together to think about enact and enable a lot of these solutions and these pathways that you had just mentioned.

David Vulcano:

Jimmy, I think when these technologies are developed, it is apparent that all stakeholders and all potential users are doing it. It's kind of a classic business school problem. When you have a business to business Arrangement, but the people that are purchasing the system are not the end users. You need to have the end users in mind and then all the stakeholders along the chain that are able to use a technology. a tech provider can sell a sponsor CRO on a great dashboard, but if the sites or the participants can't use it, all they're going to have is a great dashboard that shows you all the screen failures and protocol deviations that the technology cost.

Jimmy Bechtel:

Exactly right. And coming together to solve these things. and, and play your appropriate and necessary part in moving these solutions forward, I think is really important. So that's definitely something I would take away and really tell all of our partners that might be listening is understand what your role is in here, whether it be advocating for yourself, raising your voice, using platforms like SCRS to make sure that your voice is heard or bringing these solutions to the sites and bringing them in so that we can solve some of these challenges and do some of these things together, I think is really the direction that we need to head. but we know that sites tend to receive compensation, but we know that that compensation is lacking, particularly in the area of technology management and implementation. So David, you worked with us pretty intensely and helped us develop the invoicables document. And you've been very involved in the financial aspects of running a site and someone that a lot of the industry looks to when it comes to talking through some of those challenges. So what are some of the technology related invoicables? If you want to just name a handful of them that should be built into budgets, really, we'll call it our big ones here that we need to look at to avoid these repetitive justifications or constant asking. what are the things that we should move towards being standard and in other words, in our clinical trial budgets,

David Vulcano:

Yeah, We had some great hoops and hollers on, especially with the budget justifications as you know, why do we have to justify this over and over again when it's something that is done study by study? And that was part of the ideology of our guidance on invoicables That we published over a year ago was to bring some constant definition to these to recognize them as industry standard charges and bring these custom destinations so that it's not a new negotiation every time. So, when it relates to technology, I think sponsors and CROs hopefully recognize that the cost to implement technology has got to be reimbursed in one way or the other. So, you know, invoicables is one strategy on it. If it's event driven events, maybe it is a part of the site's overhead and with more technology, they have to have a higher overhead rate. But specifically on line item invoicables documents, I think we had six that we identified in the invoicables that directly related to this. And I'm talking about not part of say a non refundable startup fee for technology setup, because that's. You know, bundled in some of that, that fee or a study close out fee for tear down or resetting or shipping back the technology. But, the six that, that we, we highlighted were, number one is third party integration fees. So this is to cover the integration of the technology and especially nowadays with cyber security issues and, sites like academic centers and healthcare centers. There's much more cost in integrating technology now than there ever has been, and much more delay in integrating technology than there has been. Most of these famous cyber security breaches were brought in to big companies from third party systems. The, the famous, like the Target breach was HVAC system. It wasn't, they didn't crack Target, they cracked the HVAC that plugged into Target systems. So especially if there are things that Plug into the site's infrastructure or their I. T. platform that this is much more expensive and much more time consuming for sites to be able to on board. So, the faster that we can bring that information that this technology is coming is a key take away from the conference. Don't wait till the last minute, but then also appreciate the increased cost of onboarding that because of the added cyber security risk. Another one I mentioned earlier was the mock quality assurance run through, this is part of a site's quality assurance, and this could be in separate invoicable. It could be part of the overhead fee if they want, but it also could be a separate invoicable. A third one, which is emerging. We're seeing this more and more in in budgets offered out front, outright by sponsors and CROs is the protocol amendment review and set up fee. Now, this is not the IRB fee. Many people say, Oh, well, that's the IRB, but it's not and it's no longer that anymore. If, if the site has five or six or seven different systems that they have to update because of a protocol amendment, then that's five or six or seven or more systems that is cost to the sites. So the protocol amendments review and set up fee gives them the ability to see the revised protocol. Understand all the pieces of technology that they have to update and then take the time to set that up. So it really smooths it out and helps the site accommodate for the cost when the sponsors or CROes change the protocol. Another one that is new is the unscheduled visit fee. Now, historically, this has been for adverse events that have been coming and being evaluated, but more and more sites are experiencing unscheduled visits that are technology related or specifically failure of technology or help desk type related visits where these participants can't get the technology to work. Maybe they broke it, they. You know, dived in a swimming pool with it and it doesn't work anymore. Whatever it is, they're having to come back and get a tech check or replacement technology or things like that. And those are new burdens on the sites that we didn't have a decade ago because of all the new technology that's coming in So those visits we feel should also be compensated as a natural cost of the study. It, it wasn't the site's fault that they jumped in the pool with their e diary. So a fifth one is the non site vendor issue resolutions cost. And that is when the sites are the ones that are burdened with resolving the vendor issues that were technology that they did not provide. This is sometimes an hourly rate as is the sixth one that we talked about was subject help desk fee. And we're starting to see some of those budgets come standard with an hourly rate for help desk fee. I mean, of course there's caps in it and things like that, but nevertheless, it is some costs that the sites are, are bearing that are new because of the technology that is being put forth. So those are some of the things. One other final thing. It's not necessarily an invoicable but it is a financial challenge to the sites is when there is sponsor or CRO provided technology and that technology doesn't work appropriately or it fails for whatever reason. And that failure causes a screen failure. Most sites or many, Studies have a cap on the number of screen failures that the sites have. You can only have five screen failures for the study. So if the sponsor or CRO provided technology is causing those screen failures, the sites feel it unfair that that screen failure is held against them. So the closer they reach that cap, the more screening anxiety a site's going to have on that particular study. And we'll, maybe favor for other studies where it's more generous on the screen failures. So theoretically, the site shouldn't be held accountable for a screen failure that was caused outside of their control. And failure technology is one of those. So those are those are a few of the ways that we can make sure that the sites adequately, have the resources to conduct the studies that they're being asked to conduct.

Jimmy Bechtel:

Excellent David. Lots of really, really great examples there are not only for sites to push forward and the more sites. This is the power of SCRS. The more sites that we have that are asking for these things, even if they don't get them, but asking for them consistently every single time is really what helps move the needle and helps our sponsors and CROs understand, okay, these are true and real costs at the site level and things that as we continue to advocate for hopefully we'll start to see, as we had mentioned, become standard reimbursements covering the costs of executing clinical trials with these technologies on them. And for those that are listening that want to know a little bit more, Definitely check out the invoicables document that we have published on our website. It is available to the public. In addition to that, we do have a nice spreadsheet that you can use to help calculate your own costs. It is a member benefit exclusive access. So David, I want to dive into next a little bit of the training because you had mentioned earlier that this is really a huge issue for sites. The amount of time that they spend is truly cumbersome, right? It becomes a matter of efficiency and taking time away from other important aspects of conducting the clinical trial. We saw from the landscape that each role spends about six hours per training per month on average, right? Coordinators tend to be a little bit more. Investigators tend to be a little bit less. But really, SCRS is looking for the industry to reduce those training hours kind of as a goal here. What we're looking for is reflected in the landscape of about 25 percent by 2025. That's what we're going to be advocating for. Can you share some of your thoughts again based on what we've talked about in such detail at SCRS west on some of the ways that we might accomplish this as an industry?

David Vulcano:

Absolutely. So, we discussed that training should be right sized and, there's so many anecdotal examples of training that was either unnecessarily duplicative or just plain, Silly, You know, the example of, the, I signed in with my username, password, two factor authentication. And then the first five minutes of training was how to set up a username and a password and two factor authentication. The other things is sites sit there sometimes for hours in training. Just watching people fill out forms, just so a training person can show, Oh, this is a form. This is how you fill out. This is a radio button. You can pick one of those. We think this is intuitive now in 2024 when we've all been filling out web pages and things like this for decades now. So. We believed and the crowd believed too, the crowd concurred on this, when we had talked with folks and circulated this idea before we kind of threw that challenge out there of everybody needs to come back and think through your site training and reduce it at least 25 percent by next year to go through it, find out what's superfluous, what's unnecessary and and just trim it out. And if whoever's creating the training, if it's the. Service provider that's creating it. Sponsor CROs just say, Hey guys, this is great site training. Can you reduce it by 25%? Sponsor, CROs, if you have in your in house training, Hey, can we reduce this by 25%? What's really not necessary? So a lot of the ideas, was just. Take the training yourself. See what you think is just silly or redundance or just, plain unnecessary. So in right sizing this, I mean, some of the things that we talked about, number one was let's, let's. Work with the solution providers out there and see if we can find some sort of training reciprocity that's out there. Transcelerate did this pretty well with GCPs eliminated a lot, not all in all cases, but in great number of cases to say, Hey, if you've taken this one GCP course, you don't have to take it for every study. This one's good enough. So we we've kind of encouraged the industry to come up with some training reciprocity so that if I've been trained on this one E pro system for one study, I don't have to be trained on it for another study. Another idea that we talked about was that the sponsors and CROs and the solutions providers should ask the sites their feedback on the training. Many sites say this isn't really done, but once you've done the training on the sites, go back to them, ask them. Hey, what part of that training was useful? What part of the training was not useful so that you can get feedback from the sites so that the people that are designing the training can cut what's not necessary. Or maybe the training missed the mark. Maybe even a site says, Hey, I would rather have training on this than that. So getting feedback from the sites after you've conducted the training to see what was useful, what wasn't. And if you're not gathering this feedback, sites, you should be offering that feedback, don't be scared. Sites often say that they're too scared to give negative feedback to the sponsors or CROs, but we would encourage you not to, go back and in a respectful manner, let them know, Hey, this training, this 10 minute segment was Really kind of a waste of time, or this was so intuitive that I didn't really need to sit through this 20 minutes part of it. We sites often joke that providers come and say, Oh, our system's so intuitive. This is, well, how many hours is a training does it take, Oh, it takes like two hours of training. So if it's so intuitive, why does it need two hours of training? So those types of solutions we think can help the industry meet our challenge that we have issued to say. We would like to see a 25 at least a 25 percent reduction in the number of training hours put onto sites. We think this is an early win. We could probably reduce it further, but there's probably so much fat out there that if we trim the fat, we can get at least 25 percent is our hypothesis.

Jimmy Bechtel:

Well, baby steps, right? I think a step in the right direction, even 25 percent of six hours is two hours per month. That's that's not an insignificant amount of savings. So I think if we can look to reduce that, even just that little bit, it'll make a huge difference for the sites. And I think you gave some really tactful, really practical advice examples and ways that we can look to do this, right? Let's find that low hanging fruit and those, those wasted efforts. The redundancy, I think probably makes up a good portion of that 25% so.

David Vulcano:

Absolutely. And, and like one person on the stage to give an example, there were, they had two different sponsors with. Extremely similar protocols and, one was like four to six hours additional training than the other one was. There was really no additional value to that, that four to six hours. So we think that this is the 25 percent is, is easily doable for anybody that focuses on it. We, channeled the quotes by Blaise Pascal. who said, and I'll get the quote wrong because I don't have it in front of me, but it's along the lines of, I'm sorry that this letter was so long. If I had more time, I could make it shorter. So I think the time has come to not have reckless disregard in the training and accept it as is, and then challenge everyone to developing it, to making it shorter.

Jimmy Bechtel:

Excellent point, David. Yep. It's going to take a little effort for us to step back and review and understand and look at that, right? I mean, you give that quote off the hip kind of jokingly, but truly, in order for us to do this, it's going to take a little bit of understanding, a little bit of CRO part to kind of step back and analyze, okay, what is being done? What is actually necessary here? What are the sites required to do? What is protocol specific? What is maybe something that we might be able to leverage that they've done previously? Or can we really look at their certifications or their licensure and their knowledge and ability and tenure to be able to maybe supersede some of that less than necessary or universal type of training. So again, a funny example, but I think there is some truth to exactly what we need to do here with our training.

David Vulcano:

It is very, very true. And while we always appreciate the offer to be paid and, and, site should be paid to do this protocol specific training that that's required for it. It's not the cost of doing business when it is something that is specific to the protocol. But while we do appreciate the need to be paid for that, it can get kind of insulting for research coordinator to sit through the kind of stuff. We're trying to prevent burnout on these folks and we have our workforce challenges and to make them sit through training that they feel is redundant, boring and unnecessary contributes to that burnout and dissatisfaction with the role of being a research coordinator and, they may seek other things. So it's a bigger issue than just a budgetary issue of, Oh, don't worry. We'll pay you. We appreciate that. And that's how it should be. But we didn't get into business sites to sit through training. We got into business sites to recruit subjects and create quality data. And to the extent that any training to do so is redundant or unnecessary to do that. It's just a distraction from our core business of identifying participants and providing good quality data.

Jimmy Bechtel:

Excellent points, David. As we begin to conclude here and close our great conversation and, really recapping and reflecting on what an awesome event our SCRS West summit was, any other key takeaways from that summit that you might want particularly our industry partners to know, or, bring back?

David Vulcano:

We had a lot of great solutions that we focused on in, bringing up and pointing out some of the issues, and we could work collaboratively on these. There are things that sites can do themselves as well as sponsor CROs and our solution providers can do. So kind of rapid fire, one of these was that sites should provide more and more frequent feedback to the sponsor, CROs and the solution providers on the technology. And, as I mentioned before, Don't be scared. Site should not be intimidated by doing this. And if you do have a problem or a snag and a site find some work around issue, to have the sites not keep that in the silo to to let the other stakeholders know the sponsor, CRO and technology providers. Hey, this didn't work, but this is a work around on this. And in that way, that work around could be shared for the other sites. We don't want to compete against each other by making other people do poor quality. No, the rising tide lifts all the boats on this. So if we don't bring it up, chances are other sites are experiencing this. And, just like we share adverse events for the benefit of the good, we should share these types of adverse experiences with technology and the workarounds we find for the benefit of the good. And then it doesn't circle around the next study. And we get that piece of technology goes, Oh, man, they didn't fix that. Well, you didn't bring it up. Another thing that we talked about was site leadership should be thinking more and more about cyber security with these pieces of technologies as they integrate within your technology is one thing, but many sites don't fully appreciate the emerging threat of cyber security, and it's not just a technical solution. We want to be clear on that. And that was clearly discussed. This is a leadership issue, not just a technology issue. So, sites that sit there and think, Oh, well, the sponsors or CROs providing the technology, I don't have to worry about cybersecurity. You do first, if it's plugging in to your systems, you do. The other part is what if that system fails? What if the tech provider or the CRO has a cyber attack and you can't input your data for six weeks? What are you going to do? How are you going to be able to pivot the paper? So please be still more focused on the emerging issues of cybersecurity management. One quick and easy thing that's was discussed as a solution was that to ask for the sponsors and CROs to Please, send a list as early as possible all the URLs and email domains that are going to be study related. That way, the sites can make sure with their I. T. department that these are white listed early and it will reduce the factor of these things going to junk mail or just being outright blocked by the technology departments. And then another ask was to try to eliminate the surprise required technology on the sites. So, you know, I know that this goes back and forth many sites. So don't tell me everything up front. Just tell me a little bit. But the emerging need with technology, especially with Connected technology that sites are having more and more robust onboarding screening and more length of time to get those onboarded that it will accelerate your startup times if that is disclosed to the site much earlier rather than later, as opposed to. Oh, good. CTA is done. We're ready to do site initiation. Oh, by the way, here's this new AI thing. thing that we want to have plugged into your systems. Well, now you just delay the startup weeks, if not months. So if we know that tech's going to be deployed, please bring it up to the sites up front so that they can start planning the onboarding of that technology. So that's just a number of some of the suggestions that had come out. And, I wish that we could capture them all in, in this podcast, but. It was overall fantastic discussions. Lots of great ideas came out of it that we can go home and start working with to improve the use of technology so that it further enhances our experience and decreases the inhibitions and obstacles to our advancements.

Jimmy Bechtel:

Well, that's great, David. Yes. Excellent points there. Thank you so much for spending the time to share some of the key learnings. I think there's a lot to digest for those that were listening that might not have been able to attend the summit, but I hope a lot of reconfirming that happened through the course of this conversation for those that were able to attend. So again, thank you for being with us today and thank you for sharing some of what you were able to glean from the conference.

David Vulcano:

Thank you very much, Jimmy. And thanks to everyone out there. And let's meet our 25 percent challenge. Let's find the ways to reduce site training by 25 percent next year.

Jimmy Bechtel:

Well, as we wrap up, for those listening, don't forget to explore more site focused resources like that site invoicables toolkit that we talked about on our website, my SCRS. org. You'll find a wealth of content and publications on our website, plus the opportunity to save your spot for upcoming webinars and SCRS summits, like our Global Site Solutions Summit taking place at the end of September, as well as the SCRS West Conference that will be next summer. Thank you for tuning in and until next time.

People on this episode