IQVIA Holdings Inc. (IQV) Earnings Call Transcript & Summary

Good morning, everyone. Welcome to today's live broadcast, eCOA IRT eConsent, Simplifying User Experience and Driving Process Efficiencies Through Integration and Automation. I'm Lisa Henderson, the Editorial Director of Applied Clinical Trials, and I'll be your moderator for today's event. We are pleased to bring in this webcast presented by Applied Clinical Trials and sponsored by IQVIA Technologies. I would now like to share a statement from our sponsor. IQVIA is a leading global provider of advanced analytics, technology solutions and clinical research services to the life sciences industry. IQVIA creates intelligent connections to deliver powerful insights with speed and agility, enabling customers to accelerate the clinical development and commercialization of innovative medical treatments that improve health care outcomes for patients. With approximately 82,000 employees, IQVIA conducts operations in more than 100 countries, and you can learn more at www.iqvia.com. So before we begin, we have a few important announcements. This webcast is designed to be interactive. We encourage you to ask questions during the event. [Operator Instructions]. You can enlarge your slide window by clicking on the small icon in the bottom right corner of the media player, and your slides will advance automatically during the event. If you have any technical problems viewing or hearing this presentation, please click on the Question Mark Help widget in the top right of your presentation window. So now I'd like to introduce today's speakers. We are pleased to be joined today by Anthony Mikulaschek, Sonia Fischer and Evan Slotter. And I think I pronounced Anthony's wrong -- name wrong, but I'm going to get it right this time. As Vice President of eCOA Operations at IQVIA, Anthony Mikulaschek manages all operations, data management, quality management, training and eCOA project work associated with IQVIA eCOA. Anthony has extensive experience in validated system implementation, systems integration, business process reengineering, IT operations and consulting. He has successfully led the development, delivery and management of technology solutions for over 30 years, including 26 in the pharmaceutical sector. Sonia Fischer is a Health Information Technology leader with a focus on data interoperability. With over 20 years of experience in health care technology, Sonia is now focused on bringing her knowledge of clinical sites and software systems to the clinical trials industry as the Customer Integrations Manager for patient consent at IQVIA. In this role, she collaborates with clients on interoperability initiatives focused on connecting systems in order to improve clinical workflow and the patient experience from the point of consent. And Evan Slotter has over 16 years experience in IRT system design, development and operations management. He is focused on bringing standardized component libraries and end-to-end solutions to enable more robust and efficient operations for clinical trials. He brings more than 30 years of experience within the clinical tech and pharmaceutical and integrated circuit industries. In his current role, Evan is working on clinical trial technology solutions, enabling decentralized clinical trials direct-to-patient and harmonizing patient data capture in areas around IRT, eCOA and eConsent. So thank you all for joining us today. And Sonia, would you like to get us started.

Thank you, Lisa. Yes, I'll move over to our agenda. Before we get started, I just want to remind everyone to enter your questions into the chat. We're going to have Q&A at the end, and we want to make sure that this is an interactive webinar. So what are we going to talk about today? We're going to focus on critical concepts in clinical trials, optimizing integrations with technology. And we're going to focus on consent, IRT and COA throughout the webinar. So why clinical trials and product integration strategies are more important than ever? We're going to explore how to eliminate redundant activities, how to leverage clinical data quickly to generate insights and improve study optimization and how all of that combined accelerates the time to database lock. So clinical trial technology and integration strategies are more important than ever. As we all know, with the pandemic and decentralized trials coming up through the pandemic, we've had to increase our ability to reach patients where they are. And that's not just a goal through DCT and hybrid trials. That's a goal through patient-centricity. We want to make sure we keep the patient at the center of the trial. And in doing so, we need to figure out how we can offer technology solutions to meet that goal and not us put technology solutions in place, but make sure that those solutions work together and don't add to the burden of site staff. So what's behind the demand for these orchestrated solutions, bringing these technologies together and making sure they work as a whole instead of potentially up to 5, 7 pieces of technology that a site may have to adopt? So clinical trials have become more complex and data-driven. And with the ability to collect more and more data, that's a wonderful thing, but it does increase the amount of data that we have to parse through in order to get to the answers that we're seeking in clinical trials. So we want to embrace the advancements in technology and data acquisition. But in doing that, we also have to figure out ways to eliminate this additional site burden. We shouldn't put technology in place and expect that the site users are going to adopt that technology using processes that were in place with paper. We have to look at ways to streamline the workflow and make sure that the data is flowing from system to system in order to reduce site burden, increase the study efficiency and quality. And how do we do that? We do that through technology design and change management. We do that through process improvement. As we're designing the technology, we need to think about places where we can improve the existing processes where we're looking at data in multiple systems. How can we set up a process where there's a single system for entry and the data flows as appropriate and that potentially, there are alerts that can enhance the process for the site staff and allow them to focus in on what needs to be done in a just-in-time manner with technology? So with that focus on sites, as a former site user, site staff member and user of multiple technologies, trial sites expect the technology to improve the quality of the site. They don't want technology to be used just for technology's sake, just to say that we're digitally enabled. So we have the traditional trial challenges of protocol amendments, patient engagement and retention, management of trial supply and data redundancy, ensuring data integrity. And then on top of that, we're adding these new technology challenges as we introduce new technology platforms. As I mentioned, some of that includes proliferation of data from multiple sources where they have to be reconciled during and at the end of the trial. This introduces the possibility of data entry errors. And we really need to focus in on data integrity. So these disparate data sources also make reporting a challenge because you're pulling data out of multiple systems. Site users have to reconcile that data, pull reports together to figure out what action items need to be taken. And we have the technology in place. Through integration, we can improve that process and allow those things to happen in the background, instead of the site users being forced to take that on themselves and increasing site burden. So on the flip side, we also need to consider the trial participants. And as we all know, through the pandemic, this increased even more, that trial participants expect flexibility. They expect that we are going to meet them where they are. This is a study that -- survey that was done in 2021 by IQVIA. And in 2021, survey participants pointed out that just 26% of them will travel more than 20 miles to a trial site. So if you think of rural areas, 20 miles is not that far, but it can be a world away for a clinical trial site. You're not going to have a bunch of options within that rural area like you might have in an urban area or an academic medical center. And with that, 68% expect the trial to include digital auctions. They've gotten used to being able to electronically consent or figure out answer assessment questions on their own device without having to go into a trial site to manage that. So 68% are expecting that, and more than 50% of the consumers are comfortable using digital forms of communication. And since this was -- this survey was done in 2021. I would expect that that's only going to increase. So with that, I've set the playing field here, and I want to pass it over to Anthony so he can dig a little bit deeper into the technology that we're going to talk about today.

Thank you, Sonia. How do I advance into the next slide? Excellent. Wait for the camera to activate. All right. We're going to go ahead and get started. From the standpoint of technology, so a clinical trial, Sonia mentioned, uses a lot of different types of technology, you can from a clinical standpoint, from a site perspective, from a subject perspective and from a sponsor perspective. We're going to kind of focus on 3 different pieces of technology that are commonly used in clinical trials. All 3 focus on the subject, all 3 focus on the site as well. The site has a tremendous amount of responsibility for utilizing these systems, and 2 in particular have a pretty deep activities with the subject. So the first one is eConsent. The eConsent system is a system that allows -- instead of always managing paper from a paper consent standpoint, your eConsent system helps build the informed consent package and manages the application of those packages to the subjects, allowing the site to follow 21 CFR Part 11 -- Part 50 standards to ensure that consent is provided by the subject electronically. If there's any reconsenting that needs to happen, that's a big -- there can be a big burden on a site. It can be a big burden on subjects to be able to track that to see who's actually reconsented so they can continue on the trial or more importantly, revoke consent. These systems help manage that, and the application of the data in that system utilized in other systems can help facilitate ensuring that the subjects participate in the study as defined within the protocol. I'm going to flip over to the right-hand side of the slide to talk about eCOA real quick before I talk about IRT. COA, clinical outcome assessments, is an area where you're actually getting that direct patient interaction. The site usually enables the subject within the system -- the subject then. Most of your technology, most of your COA technology, it can be web-based, but the really good technology is app-based to help facilitate some advanced features within the mobile platforms these days. And those platforms allow the subject to answer standard industry assessments in instruments for clinical outcome assessments or it could be a steady diary that the subject has to do on a daily basis. 20 years ago, 30 years ago when the COA industry was first getting started in clinical trials, this is all paper-based and you had to manage paper, just like the consent process is all paper-based. Then obviously, the application of technology for those business processes allowed efficiencies, allowed reduction in errors, transparency, audit trails, et cetera, all those good things that you get when you apply technology we won't talk about the bad things. But from a COA standpoint, capturing that data, being able to analyze those results real-time, tremendous benefit to the study, especially looking at real-time results, tracking compliance, et cetera. So now let's talk about IRT. IRT systems are the systems that help track investigational product. It helps track subjects as they're moving along in the trial in terms of lab work usage of IP, usage of comparator products. And within at least the IQVIA solution, it's the glue that kind of combines or connects the eConsent in the eCOA system. So your site focuses on the IRT system. They don't have to log into an eCOA system. They don't have to log into a consent system. They can for certain manage reports, but they can get all their work done directly within the IRT system, reducing the burden for the site from that standpoint. Also allowing the systems to talk to one another to share data amongst themselves also can provide a tremendous benefit in terms of data redundancy. And Evan -- I'm not going to steal too much of Evan's thunder there, but that's going was going to talk about. But that's where you can get certainly some benefits utilizing these technologies. I want to recognize that clinical trial has a plethora of technology. Right now, we're focusing on these core pieces of technology and really focusing on some of the best-of-breed capabilities within these domains. So not all technology and not all integrations are the same. So I'd like -- I'm going to talk about -- I mean I've got 2 slides here. I want to talk about what makes a technology solution a good solution. And then we'll talk a little bit about the actual particulars and we were looking at eConsent, IRT and eCOA. So first off, what's -- how do you define a high-quality tech solution? Is it just that it's using the latest and greatest bleeding-edge technology? No. We work -- as everybody on this call and then this webinar probably is aware of, and if you're not, I'd be stunned. We're working in a heavily regulated environment. FDA, EMA, PMDA, those are the top 3. There's other regulatory agencies around the world that we have to adhere to the regulations to be able to provide therapies and medications and devices for submissions for marketing approval. So in working in that regulated environment, certain things that we need to do to make sure that we're operating it correctly. So people process technology. That's the core. Anybody who's been audited or inspected understands this. So I'll just go through it here real quick. From a regulatory experience standpoint, a good high-quality solution, it's going to be Part 11-compliant. It's going to be Part 50-compliant. It's going to follow GCP, GXP standards, possibly ENSO and ISO standards as well, as well as Annex 11. And there's a number of other standards that you need to follow to be able to ensure that you are performing within the boundaries of the regulations. And it's -- the next piece of it is from a technology know-how. And when you're looking at technology solutions, technology changes, changes a lot. So when we were talking about this and putting this slide together is, it's not so much is that somebody is using the latest and greatest technology that's out there. It's -- is there a plan for technology adoption and technology growth. So high-quality tech solution is going to have a framework for adopting new technology or a framework to build on what technology they currently are utilizing to expand capability. That helps to find a high-quality tech solution and a high-quality partnership as well. And core to that is that second bullet there, it actually has to solve a problem. The technology can't just be cool technology for it to be cool technology. It's got to actually solve a business problem or anticipate a business problem and prevent that. And then also high-quality tech solution is does the organization have experience. Once again, people process technology. It's a proven track record. And every technology needs their first customer. So how is that first customer relationship? Where SOP is well defined or people done by the seat of their pants? So it's pretty easy through an audit process or just through a handful of questions you could help define whether -- marketing slides are great, but is there actually some meat behind that? Is it is a high-quality actual solution? So with that, let's talk about some actual capabilities that you would look for when we're talking about IRT, eCOA and eConsent. So first and foremost, let me throw out an example. A site logs in, and they have a new subject. If none of these systems -- just these 3 systems, let alone all the technology that's inside the systems and I'm going to kind of reference back to some of what Sonia was talking about. The management site having to log in to each individual system. Well, that's difficult. And what if they had to create that subject in each individual system? That would -- just that amount of work alone could frustrate a site, could say, get them to the point where we say that they don't want to deal with this study. It's not a value to them. It takes too much work. They comply in to the sponsor. They need to be reimbursed greater because it's greater manpower. So eliminate that. So if you can have synergy in reducing that, just a simple redundancy and having systems talk about creating a subject. You create the subject in the IRT system, they get created in the eConsent system, they could create in the eCOA system, eliminating that redundancy in steps. Very simple thing. Single sign-on is another one. You sign onto one system, you could automatically go to another system. In removing that redundancy, you also improve your data quality. Imagine if a subject number created in one system. We all deal with human error in the IT field. You can easily fat-finger a data entry in one system that you didn't do in another system. So now you have a reconciliation problem and other systems downstream may not be able to work. So by linking these systems together, you can improve your data quality as well. Once again, it's kind of a cascading effect of eliminating that redundancy automatically improves that data quality. You could also get some additional insights in terms of what you're doing by combining the data sets because now you have continuity and your data is fluid between these systems. You provide greater insights in terms of study optimization and improve some decision-making. And ultimately, by allowing these things to be tied together and expedite, you can accelerate time lines. It's just that road work that you're eliminating to help sites be more efficient in how they're executing. Obviously, you're not going to reduce the time line if there's something that's drug-dependent or therapy area-dependent. But just from a clinical standpoint of work and helping to ease that site burden, ease that subject burden if they had to deal with multiple devices, they can use one device, et cetera. So with that as a background in terms of what makes a high-quality technology solution and the 3 core areas that we're talking about now, I'm going to pass it off to Evan to go into a little bit more detail.

Okay. Thanks, Anthony. Yes, as we -- as I continue what Anthony was mentioning, this workflow optimization in this orchestration that we're doing here, as he mentioned, if you look at the bigger box on the left, the nonintegrated systems, there are multiple duplicate activities have to happen. Each of the 3 systems, sites have to be imported, added into the system, they need to be activated. Site users need to be created in each of these systems and then just in the site itself, then if there are updates and address or the users, they all have to be done in all the separate systems. Then the sites, they're having to work with all the patients. As he mentioned -- as Anthony mentioned, patients have to be created in all 3 of the platforms. And not only that, if there's changes to -- and in the demographics for the patients that also has to be done in all 3 systems. So just by looking at these workflow diagrams, you can see that the nonintegrated, there is a lot of activities going on. And if you look at the integrated systems, we've reduced a lot of the redundancy, a lot of the actions that the sites have to do multiple times. We're able to -- in the IRT, when the site is activated or even when the site is imported into the system, we can automatically create that site in the eCOA system. When the eCOA or the eConsent system, once the patients have created and consented, they can automatically then be sent and created in an IRT, which then later on in turn can be created right in the eConsent system. So just by that simple -- these 2 workflows, you can see how much redundancy we're reducing the risk for data entry error for compliance. The quality, we're taking this huge step forward. So if we move that to the next slide here. These are a lot of the activities that go on in doing study. And the site is centered a lot of the times on a lot of these activities. So with this solution orchestration that we're doing, even if you look at one of the first things that is going on with the site, after site initiation, they need to get their initial drug supply when it's time for dispensing to occur. So an example of that where we can help with the drug supply is sites have to do actions in some cases. A lot of times, the initial drug supply is sent to a site after the site has been activated in the IRT. However, there are times with protocols where it's not necessary to send it during site activation. Could be a lower enrolling study, could be very high drug cost that they don't want to send the drug to every site until they know they're going to be enrolling patients. In one of these cases or in these cases where they don't want to send it until they have patients screened, the site goes in, in the eConsent system. They go through -- the patient signs the consent, and then the site has to go into the IRT and screen the patient in the IRT system in order for the initial drug supply to be triggered to be sent to the site. In a study that I'm aware of in our system, the site forgot to do the screening of the patient in the IRT system. And then when the patient came in for their initial dispensing during randomization, the drug supply didn't -- was not arrived at the site. So by this orchestration when eConsent on the patient has already signed in from consent, that information is directly automated -- automatically sent to the IRT. IRT creates that patient, which then automatically triggers the initial drug supply shipment to the site. So that eliminates the site because the site, as we all know, they have many activities outside of our systems that they have to take. They have to manage -- they're taking care of the patients. I see the slide change. Hold on. Another activity that we can coordinate, device management for eCOA. The IRT, it does the logistics and the managing of all the study IMP ancillaries and many other materials that are needed at the sites to conduct a study. So we just add another part of that. We can also control when devices need to be sent to the site. We can do -- automate it, forecasting for that, just like we can with any of the other materials in the study. So we can reduce the burden on the other platforms since we're doing that type of logistical work already. Another thing that we've done for a few studies where when the patient comes in, whatever visit that would be that they're going to be given their mobile device in order to start assessments. The IRT -- we've sent notifications the day before, a couple of days before to the site and say, hey, you need to prepare that device for when the patient comes in. And it gives a list, and you need to make sure that this patient does the follow-on assessments. So there are examples that we do that in IRT all the time. We give advanced notices to the site that a shipment is coming. So we just add this as another layer to help decide out with all the activities they need to take care of. In randomization, we can combine the assessment information from eCOA that is -- as assessments are completed from patients to make decisions in the IRT system. In a few studies that I've been involved with, there was -- at least in some of them, 1 or 2 assessments must have been completed by the patient in order for them to be eligible to be randomized. So the IRT can look in the data that it got from eCOA because they've got the assessment information from eCOA system. And in the case when the investigator goes to randomize that patient, if those assessments were not completed, it does not allow the randomization to occur. And it can tell the investigator, please have the patient complete these assessments now, then we can complete the randomization. So there are many ways to do that. Also what's in randomization, there are questions within assessments that can be used for stratification, can be used for eligibility, for dispensing that made those decisions. So many different ways the assessments can be used to manage and automate some of the processes in IRT. Now in some studies, when assessments are not needed for that, well, then we don't pull the assessments in. We don't want to duplicate data where it's not needed, but where it's needed and can be beneficial and help the site do its work is part of this orchestration is designing it in such a way that it's smart, how we've taken care of the data management as well as the activities within the study. Other things that we can do with the data between the systems and automate it, is we can do alerts to the site besides that randomization. There was a study I'm aware of that we did where -- when the patient was dispensed medication, they had to complete 1 or 2 assessments before they left the site's location. So we're able to -- in the IRT, we know when the dispensing occurred because that transaction takes place in that system. So from that, we set a timer of whatever it would be for that particular study. If the patient didn't complete that assessment because we didn't receive an assessment yet, we can alert the site right away and say, hey, this patient did not complete X assessment. Please have them do that before they leave the site. It helps with compliance, making sure that the protocol is adhered to, and it also helps with the patient's treatment schedule. Then through that, we can combine all that data in one set of compliance-type reporting, where the investigators that users can go there, can look at not only just IRT data, can look at the eConsent data and look at the eCOA data and how it intermingles together to give a complete picture that the investigator doesn't need to go to 3 different systems to look at the data and say, oh, okay, these patients, I need to take extra time with because something wasn't done or something in the reports to let them know that they need to pay attention to that. So it's a really good way to help the site's total experience and to make their day go better and they can spend more time with the patients, which is what we all want. So if we move on into the next slide. So if we look at this slide, it more breaks down one of the process flows itself, the orchestration. In the first, starting on the left side, we can see that the patient and the site user, they're working in the eConsent system. The site presents the documentation -- the documents for the protocol. The patient can then sign those, that document collection, give consent. And then from that activity, the eConsent triggers a notification that, that has occurred. The IRT picks that up. We can automatically create a patient in the system so that whatever the first visit is for a patient in the IRT can be completed automatically. Then from there, stepping through to the right, the IRT then, whatever the next visit would be that the patient needs to complete, whether it's a demographics update or whatever it is, randomization, then the IRT can have the patient-created eCOA system. Then the eCOA system sends out the notification to the patient on their mobile device with their temporary password and gets them set up with their assessments all automatically. Then, as I mentioned before, the assessment data from the patient's activities on the assessments, the IRT can then make decisions, as I mentioned from the previous slide. Through the routine dispensing visits, there are times through many different studies where the number of assessments and which assessments that need to be completed by the patient does change through the course of the study. Through those visits on -- without the knowledge of the site, we can change -- update, say, a randomization, there's new assessments to be done or at other dispensing or other type visits throughout the study, depending on the treatment of the patient, if there's any problems, there could be multiple paths that the assessment take. There might be different assessments or even if they have to drop out of those studies and their follow-up assessments, all those can be triggered automatically through the IRT, allowing that I thought the site doesn't need to go into the eCOA system. And again, then we also have all the reporting, we gained all that flow and not have to do the duplication of all the reporting. The data is synced up between systems because it's automatically done. We don't have to do all the data entry error checks because it is seamless in that. Moving on. Taking this one step because there's a whole lot of activities going on at the site. So if we just take one process flow here in the orchestration, you can see in the eConsent activity, the patients created -- the patient consents to the document collection for that protocol. That triggers an automated process in the IRT. No user has to go do that activity. It's completed. Any notifications that need to come from the IRT from that action are automatically then sent to the sites they know that is taking place. From that, when it's correct time for the patient to be created in a eCOA system, that is linked in with the next IRT action that needs to be completed. The patients create it, credentials are sent, and the patient is now set up and able to do all of those activities all within that, hopefully, a shorter amount of visit with the investigator. Then again, all the assessments, as they're being recorded near real time, they're being sent to the IRT system. So we can do any analysis or any alerting, anything we need to do to help the site manage that patient properly. Through randomization, assessments could be changed. And in other visits, the assessments could be changed. And at the proper time, when the treatment is complete and if assessments are over, we can also deactivate that patient in the eCOA system so that no longer they're going to get messages on their mobile phones. And of course, their schedule is finished. Then at the end of the study, this helps with data reconciliation. It helps with getting ready for database lock. It eases and reduces the effort at the sites and the monitors, making sure all the data is correct in all the different systems because through the beginning, everything has been synced up properly, all the identifications, all that are synced up between all the systems. And with that, I will pass it back over to Sonia.

Thanks, Evan. So before I go over the slide, I just want to again remind everyone to enter your questions into the chat so that we can focus some time on Q&A and respond to anything that we may not have addressed already. So bringing this full circle, why are we trying to orchestrate these solutions? We have technology, we need the technology for complex trial designs. We need the data in order to make better decisions. But overall, orchestrating these products and integrating these processes into the orchestrated solution, we're focused on saving time and effort for the site staff. So this slide has a lot of information, so I'm going to break it down into a couple of key points that we want you to take with you from this integrated offering. So first of all, by eliminating redundant data entry and combining multiple sources of data into an integrated reporting capability, you're going to limit the data reconciliation needed per study. And when we model the study, a Phase II study, we came up with sometimes that, frankly, to me, were a little bit shocking even though I worked at a site. And I know how much time is wasted running between product to product, entering data in multiple systems and trying to reconcile data we came up with 150 hours of savings through this orchestrated solution. And that's just in data reconciliation per study. So small acts can have big impact here. And then on the other side, which is where I really like to focus my attention with subject creation in one system that flows to multiple other systems, subject status changes that might happen due to an amendment being applied, requiring reconsent, if that's flowing into other systems and triggering actions there without site staff having to dig into the data to figure out where a participant is in the trial, some actions that might need to be taken and they can do those a little bit faster, then you can save time per subject. And through this modeling, we estimated the time savings is about 50 minutes per subject. And 50 minutes, while in your day-to-day life, that might not seem like a whole lot in a clinical trial, that's a huge chunk of time. And site staff, instead of spending that additional 50 minutes entering data into one system or another, they could be spending more time answering participant questions or maybe getting another participant into the door and started on the clinical trial or again, former site staff, they may just have time to eat lunch that day. And that's important too. So the overall goal of orchestration and integration should always be to improve processes, to save time and effort where possible to eliminate redundancies and to remove the need for data reconciliation. If we can have technology do this for us, we should implement that. So with that, I am going to pass it back to our moderator, Lisa, and I just want to encourage everyone to ask questions once again.

Excellent. Thank you so much, Sonia. And Anthony and Evan, that was a comprehensive discussion about the 3 processes and the orchestration, and it was extremely informative. So I thank you for that. Audience, before we get started on the Q&A session, I just want to remind you how to submit your questions. [Operator Instructions]. So let's get started. I'm going to bring up our questions and -- perfect. Okay. So the first question, why consider orchestrating an IRT eCOA integration at the outset of study planning rather than launching the study with individual solutions with the plan to -- that's a good question, with a plan to integrate the solutions later. I'm not sure who wants to take that one.

I'll go ahead and take that one. So the -- and this has been applied to a couple of questions that we're seeing come across. So an integration like this, there's a couple of pieces with it. First off, it's work. It's amount of work that needs to be done to be able to tie the systems together. But not only does it work from a technology standpoint, but it's also work from planning and prepping for what has to happen at the sites and what has to happen with the subjects. For example, sites need to be trained in how to utilize the different systems. The site -- while they're working on your clinical trial, they might be working on 5 or 6 other clinical trials for other sponsors. So there is always site training and there's subject training that need to be done. If you're doing that type of an integration where you're really trying to get some really true benefits in reducing redundancies and reducing steps, all that training material needs to be redone, all that training material has to be rewritten, reapplied, et cetera. Also from a data integration standpoint, how these systems talk to one another, like the IRT and the eCOA system, some of the examples that Evan gave us, as you are -- if somebody is being administered investigational drug and they are -- that's flagged within the IRT system that they passed screening and that investigational drug cannot be released to that subject. That then triggers a particular clinical outcome assessment in the eCOA system. These 2 systems need to be configured to be able to do that and they need to understand that, okay, this is not going to be something that's going to be site-based, it's going to be -- or human-based. It's going to be electronic-based activation within the eCOA system. So all that needs to be planned for, it might be different types of notifications. It might be different types of reminders that are sent. So you really want to plan this stuff upfront. So you really know what needs to be done because as soon as you start changing systems and you start changing how things operate, all of a sudden -- remember, we talked about all those regulatory needs. Well, you got to go through IRBs and ERBs if you're dealing with subjects or things that interface with the subject, training materials for sites, all that have to be redone, and you really don't want to have to -- if you can avoid doing that, that's just a tremendous amount of burden that you want to -- you can avoid with some proper planning upfront and implementation upfront before you go live. That's why when we built these integrations, we built them flexible enough so that we can configure them, not code them, but configure them as a part of our build process and our SOPs are defined as such where we actually do that evaluation and how they're supposed to be configured prior to them actually going live. I don't know if Evan wants to add anything to that. I know he's deeply involved with these.

No, I think you covered it very well. It is from the get-go. You are going to confuse the sites and everyone involved. If you're going to make a huge change like that in the middle of a study that's when more mistakes are going to get made because they're going to be so confused. You're going to overwhelm the help desks. And patients are going to get frustrated because they're sitting there waiting for all this to get fixed or it to fix. So yes, it's better to do it right from the beginning.

Excellent. Thank you both for that -- for your insights and the answers. So our next question, does this integration work when using a BYOD, bring-your-own-device, approach?

Yes. A lot of that's going to depend on your technology. And -- but from an IQVIA standpoint, our platform is BYOD-friendly. We have -- from a COA standpoint, we have a dynamic design concept, where once you design something, you have anchor points on the screen. It depends on screen is big or small. It maintains this anchor point, so you have a consistent look and feel. You get through IRB approval a lot easier that way. So yes, it definitely supports BYOD model because you're not going to do BYOD really on the site basis. The site is going to have a standardized tablet. They're going to use web interface for consent, and they're going to be logging into the IRT system. So really, your BYOD is focusing on the subject and focusing on the COAs. And so yes, it does support BYOD in that regard because of how you design that. Not all COA systems manage it that way. A lot of your more advanced ones, like I had mentioned previously on the other slide, have adapted the technology to be able to do that.

Excellent. The next question, this is a long question. We've had quite a bit of data connectivity issues at times in various geographical areas, depending on what data provider was available, data plan coverages and device limitations. What are we doing to proactively think of new methods to decrease this risk and resolve these issues more quickly when the issues arise? So if you don't have wireless or cell connectivity is unsuccessful in transmitting data. So your data connectivity issues, basically, I would say, is this question.

Yes, I can take this one as well from a COA standpoint because it's most of the time where you're going to see that because your consent in your IRT are going to be done in clinic on devices that are usually connected, either connected to WiFi right there in the clinic or in the hospital setting or hardwired into the network. From a COA standpoint, connectivity issues, it's a huge problem 15, 20 years ago, even 10 years ago and for certain solutions still today. Your COA solutions you really need to look for ones that can work online and off-line. And then when you're working off-line, there has to be ensured that the technology has a way to sync up because these -- all these integrations that we're talking about, they need to talk to one another. That doesn't mean that the subject cannot -- shouldn't be able to do their work if they've been notified, I say work, do their assessment. But they should be able to then sync up. And once they sync up and they do reach an area where they can have connectivity, whether it be cellular or WiFi, then that data is then passed into these systems and the appropriate responses are provided back. Another mechanism and to ensure if you're going that route because that's a very effective route to ensure compliance to ensure subjects can be able to do their work. The other thing we need to make sure is that you have active monitoring of that because you can in a situation we're subject -- and we've seen this. They put their device in airplane mode. One example I'm thinking of it was not a BYOD study. It was a provision study where the device is provisioned to the subject. And they put their device in airplane mode and they forgot. But they were still able to do their work because the solution, the COA solution actually worked in an off-line mode. Now on the other side of the processing, your IRT team, your eConsent team, they should be monitoring that or whoever is monitoring the station on say, okay, well, we haven't seen any data from subject 123 in the last couple of days. We need to probably reach out to them or send them a notification or notify the site to reach out to that subject so they can notify them that maybe they have forgot to -- either they forgot to do their subject responsibilities in terms of COAs or they're doing them off-line and they need to upload. A good high-quality solution is going to have that data on that device encrypted. And so when the subject finally connects, it's uploaded to the system, it syncs up and all the other activities are then triggered.

Great. Monitoring that very good point. So the next question, while integrations between various digital vendors decreased site and subject burden, it is often accompanied by longer start-up time lines and increased errors during the build. So what are some solutions to these challenges?

I think I can take that one.

Go ahead, Evan.

It depends on the orchestration of the platforms that are integrated. We've developed ours in such a way that it's more configurable than having to do custom coding. It's very flexible in the way -- and that's more of this orchestrating working very well. It can work with many complex studies. And it comes down to the beginning when you're designing the protocol. How do you want these systems to work together? What is the end goal? What's the data you need to prove your drug is effective? So doing that initial work upfront, talking with the vendors first, why you're making some of these decisions, will help along. And then it doesn't have to be a longer process. If you have the right systems, the right orchestration, it doesn't have to be longer. It can be -- it can all be done in parallel. It's no different than if they were independent and not orchestrated. They can all -- if you have it orchestrated well enough, it's configurable. You won't notice the difference. And one thing that you get with this orchestrated is you can actually have on UAT for the client because what the integration is the client can do the UAT maybe in 1 or 2 days because you're doing all 3 systems at the same time.

Good points. Excellent point. So let's answer this question about the orchestration. Does the orchestration delay time lines?

So I'll go ahead and answer that one, unless Evan or Sonia, want to. So delay, no. So what Evan was talking about, we had -- you have technology that is purpose-built to support integration. And let's go back to the slide I had on a high-quality technology solution. You have SOPs, you have experience on how these things are put together, and you follow all the industry standards that you have to in working in a regulated environment. So if your vendor or vendors have those components, then the initial time line that you're given to build the integration or to configure the integration and to test it should be pretty accurate because they know what they're doing. So it may not match the initial time lines that you wanted because it is additional work, but if it's set up in a way, that should all be known. So it should be a known time line in a time estimate. And so there should not be a delay. If the vendor has done this before and is following industry standards, has SOPs driven for UAT, et cetera, that help drive that. And then there's opportunities for optimization like Evan said. You can have one UAT instead of separate UATs. And there's some other opportunities for optimization in terms of requirements gathering is -- when you're starting to review the protocol on how to do from a business standpoint and from a clinical business standpoint, how the integration is going to solve some of the clinical business problems. You can consolidate those meetings to help compress time lines. So there's opportunity for optimization even in the configuration process, but also if you from a time frame standpoint, you should have an accurate time frame upfront if you're working with a high-quality tech solution.

So agree, you have to communicate your time lines. Excellent. The next question, the attendee agrees that the system should be integrated. However, how does this change when you have different systems for each technology since not all sponsors or trials are fortunate to have one vendor for all 3 of the technologies.

I can take that one. So real-world example, this happens every day. And with our technology, that is why we focused on making sure that our integrations were a matter of configuration. For eConsent, we're developing a catalog of APIs that can be used with any technology so that you can use the consent product and then perhaps use Cenduit IRT or our eCOA solution or slide in another IRT or eCOA solution. We want to make sure that this technology works for the sites that need to use the technology. We don't want to add the limitation that it must be used together. We have very robust technology that can be used standalone or in combination, it's even more powerful. But when we're designing these integrations, that's key in our thought process of looking at what the workflow is going to be for the site and acknowledging that it may not always include these 3 pieces of technology.

Excellent. Thank you, Sonia. So revisiting our questions since we only have a couple of minutes left. Our next question, do you have a recommended study size scenario that can maximize the benefit of this system considering cost and resource input, for example, a multisite study over 5 sites with a total participants over 100?

I'm not sure there's really one answer to that because it depends on the complexity of the study, protocol design. There are so many inputs into that equation.

So let's -- let me give a real-life example, Evan, that you and I worked on. And this was one where the sponsor had -- there was a requirement that they need to have a baseline eCOA assessment done prior to investigational product being administered. And then once the investigational product was administered to the subject, then they were able to go to their normal course of activities for the investigational product. Very, very cut-and-dry example. And what happened was they did not have an integrated solution. It was -- they had a number of different vendors that provided them the technology for their solution. It wasn't IQVIA's. And they had a technology hiccup in that they could not get the subjects working appropriately within the eCOA system. And they -- the sites just went ahead and administered the investigational product without the assessments being done. What happened was all that data had to be thrown out for those subjects. They couldn't be able to submit to regulatory bodies. So it's not so much is that there were 50 subjects or 10 sites or 1,000 subjects where you really get the value. You got to take, like Evan said, the complexity of the protocol and the true value in terms of how the integration can help facilitate the execution of the protocol to achieve the goals of the protocol. And that's really -- that's a part of that -- the process of doing the configuration, making sure that you have a round hole and you have a round peg and this is a nice -- and it's a good fit depending on how deep you go into the orchestration. So in that example, if there's 10 subjects, it would have been worth the integration, let alone 1,000. So it really depends on the protocol.

Excellent. Of the multiple constituencies in the trial process, which ones need buy-in to adopt an orchestrated system? Where do you encounter the most resistance?

It's a good question. And I'm -- we should go around on this. I think we're all smiling here because it -- I don't know if there is one individual constituents because I think from -- I have more majority of my experience in the eCOA side. It all depends on who you're dealing -- it's the people. It's not an individual. It's usually -- whether it's an individual site or it's an IRB or it's a regulator or it's a sponsor, it all depends on that person's previous experiences and how they feel about doing this. I'll let Evan or Sonia expand upon that.

Yes. It is their comfort level. If they have never been involved with that technology at all, yes, they're always apprehensive with that. And with this orchestration, you don't have to use all 3 platforms. You can just use the 2 of them. It is -- the way we've developed this configuration that you can use any 2 and it works. Yes, it's hard to convince someone if they haven't dealt with it before, but it can be to show the difference individually versus with the combined and to get them to look and feel and actually see the difference in demo system to show them.

Or if they've had a really negative experience in the past.

Right.

Right. So it's more process and change management. You introduce it with the trials that make sense and then talk through it and demonstrate the capabilities.

Excellent. We're out of time. I want to thank the audience for attending and participating in today's event. Thank you, Sonia, Evan and Anthony, for your excellent insights. And I want to thank our sponsor, IQVIA Technologies, for making today's webcast possible. Audience, please, if you could participate in a brief survey that will appear on your screen after the presentation has ended. You will also receive an e-mail alerting you when this webcast will be available for replay, and we encourage you to forward that announcement to your colleagues who may have missed today's live event. So again, thank you very much, and we will see you next time. Bye-bye.