Mr. Robert Smith: Welcome to the Almac webinar series. My name is Robert Smith. I’m an Associate Director in Almac Clinical Technologies Clinical Project Services Department

Today, we’re going to talk about smart standardization, a flexible approach to customizing your IXRS [sp] system. So, to review the agenda, the topics we’re going to cover today, we’re going to talk about the way things used to be, the previous state, the custom world. We’re going to talk about the reconfigurable approach that was adopted by many sponsors and many vendors. And we’re going to talk about a slightly different approach, an emphasis on flexible standards. And then, we’re going to talk some considerations going forward and just to wrap up the presentation

So, prior--really at the onset of the IVRS/IWRS industry the common approach was to completely customize a system, to tailor build each system to the specific needs and preferences of an individual study team or an individual study. Now, there are some significant disadvantages to this approach. One there’s definitely a cost factor involved, doing this can be very expensive. You’re paying for a custom build for an entire system. There’s also the idea of timelines. It can take longer to build a custom system, and you’re seeing that in the time that it takes to put a system like that live. There’s also the problems in variance and approach across multiple systems. Each one of your individual study teams will each--maybe each protocol or each clinical area, each therapeutic area, might require a different approach or might request a different approach. So, it’s very difficult to have a standardized approach across all of your different systems, and you can end up with many different systems working in many different ways, which can be difficult for you to manage and difficult for the teams to move studies going forward

So, in many cases what people came to want to adopt is the idea of a reconfigurable system. So, this is a system that’s a template system with building standards. So, you’re going to take what your standards are for your individual company and try to build them into a templated [sp] system. So, you don’t have to go through that process of customizing. Instead the vendor, once you’ve determined what options you want for that particular system, is going to do configurations. The hope here is that you would get faster deployment because there’s no time spent customizing. There’s also the hope that the cost per--on a per study basis would be lower, because you’re not having to go through that effort of customization. However, what often happened when these reconfigurables were actually attempted was that there was a considerable outlay for a reconfigurable build. You’re really trying to build a system that covers all the different “what if” possibilities with any one of your systems. And those of you that might have different therapeutic areas, different geographic areas, different kinds of medications that you’re testing, know that there are a lot of different “what ifs” possible for each study. You’re also--if you’re dealing with individual study teams, it’s hard to keep them in a box. They’re only--they’re going to be limited only by the functionality that’s available in that reconfigurable system. If it’s something that hasn’t been considered when that reconfigurable was specified and built, then that’s not going to be an available option for them, which a lot of times means that you’re still going to need to customize that system for each individual study build, which very much undermines the value and advantage of a reconfigurable system. You’ll also find that if you’ve spent this money to build a reconfigurable system that functionality of that reconfigurable is frozen in time at the time the specifications were written. So, if your product evolves, if your teams evolve, if your structures evolve, perhaps something around your depot management evolves, your fun--the functionality that you specified at the time that reconfigurable built is your limitation. And if something’s changed on your end, then you’re not going to be able to take advantage of that, and you’re still going to have to spend time customizing to account for that time and money

So, now once this is live as well you see some other disadvantages. You have a long-term investment with one vendor. If there’s some kind of problem with that vendor’s delivery, service related, product stability related, you’re tied up with that one vendor. You have no portability, because they’ve really built that product for you. You don’t have anything that you can take to another vendor. As you know, you lose some flexibility as far as negotiation, some flexibility as far as really being able to compare different vendors against each other, if you have locked yourself up with maybe one or two vendors around a reconfigurable system. And the fact that you’re still having to customize on a per study basis, which I believe is the experience of most that have gone to a reconfigurable know that they’re still having to customize each system on a per study basis. You’re still having to have that outlay in cost and time, which in a lot of times if you’re having to heavily customize a reconfigurable you might have been better off starting from scratch with a custom system

So, instead let’s talk about a different approach and that’s really the idea of coming up with standard customizations for your system. So, these are agreed standard functionality that’s going to be implemented per your system. So, this isn’t someone building a templated module or building a templated system and then knowing they’re going to go on reconfigurable. This is a mutual agreement between vendor and sponsor as to what that vendor--or what that sponsors standards are and how that’s going to be implemented on each study. This is really a process, not so much in study build, as it is in documenting those standards and requirements. So, it’s much more of a paper process than it is a build process. And what you probably want to do is determine which areas of functionalities or which clusters of functionalities are really important for your organization to standardize. It could be that you have something that’s standard on all of your studies, maybe it be a depot management, maybe it be a way that your administrative personnel interact with that system. That’s where you’re going to cluster your standards

So, just as a comparison between standards and what we’re calling standard customizations and what we consider prebuilt standards or a reconfigurable, in customizations you can tailor that per study. You’re not limited to the fact that you’re dealing with one template that has to have all of the different options included in it. Those customizations can evolve over time without the need to rebuild. Unless you’re planning on doing something like retrofitting existing systems, systems going forward can evolve in functionality. With a reconfigurable if you want standards--new standards as part of their next system, you’ve got to go and build those new standards into that reconfigurable, which again is additional time and additional cost. And in the case if you’re talking about rebuilding the actual template those costs can be significant and the time can be significant as well. If for some reason during the course of requirements gathering your teams determine that they need a different requirement or they need something that falls outside the normal standard that’s more of a documentation change. You document a new requirement in the requirements documentation and that’s fine. However, if you’re talking about something with a reconfigurable and you need to deviate from your normal standard that’s a programming change. As we talked about before that’s your vendor needing to go in, redo programming in that reconfigurable and, again, incur that additional time and cost. Also you’ll find that many of the vendor’s products themselves evolve. So, maybe their product is evolving. They’re offering new functionality. They’re putting new things in their system. If you’re locked into one reconfigurable it’s quite possible that those standards will not be applied to that reconfigurable and the product that you’re working with will not evolve with those vendors enhancements

So, some of the advantages of using flexible standards or standard customizations. There’s certain need for the client and the vendor’s teams--vendor teams. If everyone goes in knowing what your standard is and what your standard approach is it’s much easier. You get a jumpstart on things. The vendor can come to you with the outline of what your systems typically do and your teams have a starting point. It’s not the old way where it was pretty much a free for all and every team could come in and determine what exactly they wanted on a per study basis. Nor is it the more lockdown reconfigurable approach where you only have a few options. Instead your teams know what the standard is, but they’re free to work from there where they need to deviate from standards, where they need to make an accommodation for a particular study or a particular therapeutic area. It also gives you consistency within your systems and between other systems. It’s easier to predict system function, and you can have a more unified reaction to global changes. A good example of this is we know that in many of the European countries there was a need to evolve the way that systems collected demographic information. There was a need to further mask patient privacy by perhaps collecting dummy birthdates or now using initials. If your--if you had completely customized studies each team might have picked a different approach and you may need to--you had to figure out of all those systems which way did each system work. If you had a reconfigurable system, you know, it might have been locked in to only some approaches, but if you had the ability to really customize and flex with your customization from a standard starting point it’s much easier to react to those kinds of global changes that have to be implemented

So, the question becomes “Where do you really want to focus your standardization efforts,” because as with a reconfigurable the attempt to standardize every piece of the system it’s just too much. It’s not a wise approach to take. And what I would suggest was to perhaps look at some of the areas where you’re commonly doing the same thing from study to study. So, typically this is a lot around data integration. Maybe use the same EDC vendor. Maybe you have the same kind of safety transfer. Maybe you have the same kind of interim analysis going to the same kind of group. Those kind of predictable transfers build [unintelligible] around those because you know that you’re going to need those on each one of the studies. Maybe your depot level inventory management is the same across your organization. Maybe you have a particular material system on the inventory end that you’re always using. Maybe you’re always working with the same depots or the same depot vendor. Having that ability to standardize across that does give you consistency across the systems and doesn’t force each team to rebuild the functionality from scratch, maybe something around reporting, getting information out of the system. It could be that your teams commonly want to see this report on all the different systems or it’s a corporate standard that you have this information always available to your different teams. That’s an area that’s a smart place to customize and it takes the burden off teams trying to figure out each time what they need to do. And then, there’s always the support and maintenance area. This is something that people don’t necessarily consider because it’s technically not part of the study build itself, but it is important to adopt a standardized approach, to let your vendor know this is how I’m always going to react in this situation, or this is how we typically approach these kinds of situations by doing this. Something like how perhaps you deal with site level mis-dispenses or the site might pull a kit off shelf without actually using the IXRS system to assign that container. Having an approach that’s going to be standard with each one of your systems really does add for higher quality data and a much better response from the vendor

So, what not to standardize, and this comes I think from experience and seeing clients over the years trying to standardize different things around these areas. Dosing and medication assignment. Dosing and medication assignment can be completely different from study to just study, very different from therapeutic areas. Think about often the ways that oncology studies dose. We are talking about different cycles and different phases versus something else where you might have predictable visits with a predictable amount of drug being given. Maybe you have weight based dosing. Maybe you have dosing based upon skin area. All those different things need to be factored into the system. And really that’s an area that if you try to come up with a standard approach it’s going to be very difficult, and you’re probably going to spend more time trying to come up with one standard approach and really allowing each team to come in and tailor that for the individual study. Randomization is something else. Randomization designed per protocol can be very different. It could be that you’re employing some kind of dynamic randomization. It could be that you want to try something fancy along the way that the blocks are assigned or something like that. There’s a lot of different ways that randomization design can vary. Trying to come up with a standard approach is again something that is probably more trouble than it’s worth. The visit schedule, again, visits can really vary very significantly between different protocols, and to try to come up with a standard approach it’s just not the best use of your time. Determining whether you should have a soft stop between every visit, whether you should have a hard stop between certain visits, that’s all very protocol specific, and it’s usually the vendors have a standard solution for that, but they’re happy to customize to meet your particular needs and it’s much easier to go through that

Now, just to kind of--a final wrap up, some considerations around what you want to do moving forward with flexible customizations. Know what really the important standard functionality is for your individual operation. Don’t try to get everything. Get the things that really matter to your group. Take the time to fully document your standards. Yes, there’s some--there’s an outlay of effort upfront. It’s far less of an outlay though of trying to build an entire reconfigurable system. It is more of a paper exercise, but it does move you to go ahead, take that time, figure out those standards and get them written down to provide that jumping off point for your teams and the vendor teams. And really if you are thinking or considering the reconfigurable route, understand the investment that’s behind it. The idea that you’re going to have studies that you can quickly deploy, cheap studies that you can easily deploy, sound very attractive, but when you consider all of the different things that you’ve got to take into account from that outlay of initial requirements gathering, from the price of the build of the templated system, to the fact that your teams are going to be held in a particular box when they’re at the individual study level, to the idea that you’re probably going to have to customize anyway, and finally that you’re going to end up with a product that’s locked in with a particular vendor and is really locked in in terms of overall functionality

So, hopefully that was helpful for everyone. Thank you all for your time