Speaker 1: Welcome to Study Startup Timelines and Budget. We're going to discuss how to prepare your CDM or clinical data management team for study startup and this includes outlining roles and responsibilities, talking about training the team, thinking about timelines, deliverables, and the budget. For a project to be successful, the roles and responsibilities of each team member have to be clearly defined and each task has to have an owner who's responsible for ensuring the task is completed on time. Within a project team, you're typically going to find a project manager and for data management, you'll typically have a CDM team lead. This could be a lead data manager, it could be a project data manager, but it's the individual who has overall responsibility for making sure that the project is conducted appropriately and that the database is built, the data is managed, and the data is locked. If the project is a big one, you might also have specialists. These would be task leads who could direct or coordinate the work on really specific tasks such as SAE and AE reconciliation or query management. Most projects do have several team members who also work under the direction of the CDM lead doing the core tasks of reviewing data, managing queries, and reconciling work as directed. You will almost always have a database programmer that will be responsible for creating the database and the edit checks within it and you often, if you're going to be doing some sort of analysis, you will have a programmer that is focused on programming the tables and listings and figures that will help to analyze the data and that's often called a SAS programmer or an analysis programmer or a Biostats programmer. In some organizations, you might have a programmer that does both database and biostatistics programming, but they can be very different skill sets. They usually are very different skill sets, so typically you see that somebody focuses in one area or the other. You also will have an individual that is a coder. We're going to talk more about coding later in the course, but essentially coders are individuals that are familiar with coding dictionaries or medical dictionaries. Many of you have heard the term ICD-9 or ICD-10, the International Classification of Diseases. We hear that a lot if we go to the doctor's office or if we work in a doctor's office. Coders use these types of dictionaries to take any free text that was entered and assign it a numeric code so we can analyze it. In terms of roles and responsibilities, it's also very important to make certain that outside of our little project team, when we are dealing with vendors and sponsors and sometimes multiple vendors, we need to be very clear on who is responsible for what. So if I am working with an external laboratory, I would say, let's sit down and talk about who's going to create specifications for the transfer format and programs, who's going to review the specifications, who will create the data sets, who's going to conduct the transfer, who's going to receive it, and who will be responsible for confirming it's correct and acknowledging receipt. Generally, when you are starting up a study, one of the first things the project team will do will be to define the scope of work, the timelines, the deliverables, and these roles and responsibilities. If you take classes on project management, you'll probably hear the term RACI, which is Responsible, Accountable, Consulted, and Informed, and that's a very common way to sit down and put a matrix in place for all the tasks that the project will be involved in and who is going to be responsible for each of those tasks. What's really important is that everybody knows who is expected to own what task and that it is documented somewhere. You know, I always come back to the documentation. So, training. Remember that everybody that is working in clinical research needs to show that they are qualified to do the role that they're doing, and that means that they have to show that they have the education and training to do it. So, tying this whole concept in with documentation of process, one of the first things that we do is we make certain that there are project-specific instructions or documents in place. We've talked about some of the common ones for data management, such as the data management plan and the DVS and the case report from completion guidelines. All of those need to be up and in place before we begin working on the tasks they cover. We do need to train a lot of different people. We need to make sure that both our client or sponsor are trained on our processes as much as they need to be. They don't need to know everything we do, but they need to know what their role is and what we are responsible for. Everybody needs to know the protocol. Everybody on the team has to read the protocol and understand it and be able to determine that the study is being conducted in alignment with it. It's important to know the budget, so everybody needs to be trained on the budget or aware of it. Everyone has to have an understanding of the timeline as well as the deliverables. So, project-specific instructions, again I know I say this all the time, you're going to hear me talk about about this as well as version control. All of the documents need to be in place prior to beginning the activity that they are documenting. This means, for example, you shouldn't be entering data in the database without some sort of case report from completion guideline or entry instruction already in place. You don't start reviewing the data without a data review plan. Also, different documents have different requirements for approval and signatures. You need to know what those are and for each document before you start using it you have to have the appropriate signatures and approval in place. Version control, we need to make sure that we know what version we're in and that we are updating the documents in real time as we have to make changes to them. And we need to make certain that we document the training that occurred. So, you will have an individual read a document and that's great, but you might be asked six months later, did they read it? And unless you have some notation somewhere where they attest to the fact that they read the document and are trained on it, you can't prove that they did. So, documenting the fact that the training occurred is also a key issue. Timelines. Where do timelines come from? Does the project manager just pull them out of the air and write them down on a board? Who provides input? Well, the team needs to come together and they will develop an initial high-level timeline by taking a look at the contract and the scope of work and the protocol and essentially ordering the tasks that need to be done, the sequence in which they are going to occur, and the time it's going to require to do them. They'll identify very specific deliverables. So, for data management, we're looking at, you know, when do you have to have the database live? When do you need your monthly review listings in place? Is there going to be an interim analysis? What will trigger it? Are you going to be doing quarterly data transfers? All of this information needs to be built into a formal timeline. It can be something as simple as a Word document. Very often, though, teams are using more complex, timeline-specific programs. Microsoft Project is one I see used quite a lot. It's great for this. When you are deciding the durations and dates for these deliverables, you need to make sure you get input from all of the team members that have a stake in it. So, you can't say when a database is going to go live unless you ask the programmer how much time they need to do it and when they can be ready. You can't say that all of the site monitoring will be done unless the site monitors have a chance to talk to you about what is reasonable given their ability to access the site. Always, always, if you have a timeline, communicate any risk problems or concerns to the team and be very clear about that. Don't hide them and hope they'll go away if you ignore them. If you do that, essentially, you will probably run out of time. You will miss a deliverable or you'll impact somebody else. So, it's much better if you feel that there is a risk or if you don't think that you can do your part of a deliverable, you need to escalate that out to the team as soon as possible so they can put a risk mitigation plan in place. So, here's some very simple timelines. I did not do this in MS Project. This is just a little old word document, but what I really wanted you to see is that in a timeline, what you essentially want to do is identify what your deliverable or task is and when you think it will occur, and you also need to identify the sequence. So, if you know that you cannot put the database into production until it is tested, then you have to make sure that you have the database production go live prior to the database being released for entry. So, when you're thinking about timelines at a very basic level, you need to say what the milestone or deliverable is, you need to say when it will occur, and you need to be aware of the sequence or the duration of time that is required. I do want to chat about common deliverables and how we identify deliverables. So, again, we're going to go back to that contract or scope of work. We're going to review that as well as the protocol to make sure we really understand everything at a very simple level, everything we have to do to conduct the study and who's responsible for it. Your deliverables might be internal. So, I might need to give data sets to a statistician or they could be external. Maybe I need to send data to the sponsor for their clinicians to review. Internal deliverables transfer a task or data from one department to another within the same organization, but external deliverables transfer a task or data to an outside party, whether it's a vendor or a sponsor or site. Don't assume internal timelines are not important. They may be the key to an external timeline. For example, data management might have a deadline for completing QC on all data for the interim analysis and releasing that data to Biostats. If data management misses their internal timeline, that could cause Biostats to miss their external timeline. And when you are thinking about deliverables, you need to be monitoring them. You need to be looking for metrics or trends that indicate that maybe you won't complete on time, and you also need to be thinking about whether the work that you're doing is in line with the budget and what you are being paid to do and what you are required to do. So, budget. Where does the budget come from? The sponsor develops an overall budget for running a clinical trial or protocol based on their internal expenses and the revenue that they expect that they're going to get from that and what they have for research, and they'll make some decisions about the scope of the trial and what they are willing to bear as the cost of running it. If the sponsor contracts the project or some portion of it externally to a CRO or some other vendor, then they need to develop an additional budget with that organization that says what they're willing to pay them and go through a contracting process on that. Typically, the vendor makes an estimate of the number of hours required to complete key project tasks based on some assumptions about the project. Once the contract is awarded, the team needs to either meet the budget or demonstrate a compelling reason to negotiate for more hours or dollars, and this is typically referred to as a change order. So, what would be a compelling reason to change or adjust the contracted budget? A change in the project metrics or project assumptions could do it. So, here's an example. If you assumed that the queries were going to be very straightforward, this is not a very clinically complex study, and it's experienced sites, you might say that you're going to be able to resolve six queries in an hour, and you find that the sites actually aren't very experienced or that the patient population is maybe much sicker with more comorbidities than you expected, and you find that you can only resolve three queries an hour, and that based on that, you really need more money for query management. Here's another example. Let's say you assumed in the original budget there would only be 300 patients enrolled in the study, but partway through, the sponsor decides to extend enrollment and allow an additional 100 patients to participate. You need more money and hours to cover that new set of 100 patients and the work that you will be doing on them. Here's some pretty common assumptions that I use when I'm building a data management budget. Some of these are things that are going to be used by other departments as well. So, how many patients are you going to screen and enroll? How many unique case report forms are you going to have? How many total case report forms are you going to get? So, you might have an at one unique adverse event, but you think you're going to collect five pages of it. What is that total up to? Are you going to get a lot of non-CRF data? How many SAEs do you think you're going to get, or AEs, or how many queries? These are things that don't just affect data management, but they affect a lot of the other functional areas as well. So, these are very common assumptions. In data management, I always need to know how many edit checks are going to have to program, how many monthly reports am I going to be developing, or status reports? How many times do I have to transfer the database? How long is the patient screening or enrollment period? What is the duration of study activities? From the time that we start the study up to the time the study closes out, what portion of that time do I have to have a lead data manager active on the study? And are we going to have additional deliverables? For example, will we have a DSMB or Drug Safety Monitoring Board that meets every three months, and am I going to have to produce listings, or tables, or data sets for that? So, here we're looking at some assumptions that I'm going to assume for a trial. So, I'm going to have 150 patients screened, and out of those, a hundred of them are going to qualify and be enrolled or randomized. I'll only have 15 unique CRFs, but total, I'm going to get 1,500 for all these patients. I do have some non-CRF data I'm going to have to reconcile, so I have to figure out what that is and what I have to do with it. I'm going to have only five SAEs. That's great, but I'm going to have to review 500 adverse events to make sure that there aren't any other SAEs in there, and that the ones I do have match with the safety database. I only think I'm going to have four queries per patient, and I'm only going to have 20 edit checks, and I'm only going to do 10 status reports. All of these things are typical examples of what an assumption would look like. I will continue to monitor the budget, and the first thing, in order to monitor it, I need to make sure I know what is included in it, the number of hours, and all of those assumptions that I just discussed. For budgets that are being handled internally, for example, if you were working in a sponsor within an organization, you might not have a budget contracted with somebody else, but there will probably still be some sort of departmental or internal budget that you need to meet, so you'll need to make sure that you know what the assumptions are for that. Then you also need to be, of course, on the lookout for some change in your metrics or assumptions that indicate you're going to go over budget. If you spot it early, is it something that you can respond to or mitigate by maybe negotiating an upcharge or change order with a sponsor, or is it something that you can change in your process? Maybe you are taking, you can only process three queries an hour, but it's because you have not automated the process. Can you automate it and get back down to the ability to do six queries an hour? You also need to think about your deliverables. It could be that you initially said that you were only going to deliver the data on a monthly basis, but somebody on the sponsor side asked you to deliver it twice a month, and you started to do that before you realized that that would be a change in your assumptions. So you want to look for possibilities that you are going to be outside of your assumptions, and again, you'll hear me use the term escalate. You'll need to escalate or communicate that out to the project team so they know the risk. Very briefly, I'm going to do some really simplistic examples of how you can convert budget or estimated hours to the timeline calendar of days or weeks. So in general, we think of a full-time employee as somebody who works about 40 hours a week, and very often this is referred to as a full-time equivalent or an FTE. And in this example here, if I have a task that's going to take me 200 hours to do, that means that if I had five people working 40 hours a week, I could do it in one week. But if I only had one person available to work 40 hours a week, it's going to take them five weeks to get to it. So you can see how the available resource can impact how the timeline and when you can get a task done. So it's one of the parameters. Here, I wanted to take another look at this. So remember that we start with that general set of assumptions that define the budget in the timeline, but as the study progresses, we might find that our assumptions were wrong or that we are being asked to do additional work outside of the initial budget. I often hear this referred to as scope creep, and here are two examples. In this first example, we assumed there would be 15 unique CRFs and that we would create those 15 unique CRF or entry screens in the database, and it would take us 10 hours each. So ultimately that meant we would spend 150 hours creating the database and we would get paid $120 for each hour. So our total budget is $18,000. Now what happens if we end up doing five additional pages and we're like, oh yeah, that's a great idea. We'll add these five pages in here and nobody thinks about the impact on the budget. Suddenly, you are actually, instead of doing 150 hours of work at $120 an hour, you're doing 200 hours of work and it's going to cost you $24,000. But if you haven't negotiated with the sponsor, they won't have to pay you that $6,000 difference. So you need to keep an eye out for changes in the assumptions. In this second example, we here are assuming that the sponsor had, we'd agree to do 50 edit checks. Each one would take us two hours to spec, program, and validate, and that this would take then 100 hours. Again, at $120 an hour, we're getting paid $12,000. If we double the edit checks and we're still getting $12,000, that means that we're going to lose money here because it's taking us, it's costing us $24,000 to do the work. So keep an eye on your budget, your timeline, your assumptions. Make sure that you're very clear with everybody when you have scope creeps so the team can sit down and decide how to handle that and what to do with it.