Informatics
From an overarching process or value stream perspective, the time taken from when the oppor- tunity to test a compound arises (its original prepa- ration date) to when the data is available for inter- pretation is important. This time lapse includes a number of sub-processes, as well as waiting time between steps, and the time taken to reach deci- sions. However, a project team may be interested in the turnaround time from when they decide they want a test run, until they get the result. This excludes the time it has taken them to reach the view that they want a test run, perhaps with rea- sonable justification in some cases, since perhaps they were awaiting other results in order to decide. Underneath this project cycle, there may be a num- ber of subprocesses, which often lie within a departmental boundary, such as a compound man- agement group which receives requests and despatches samples to testers and the testing groups such as pharmacology and DMPK. In each of these departmental cases, individuals are often directly associated with the execution of the test, and are therefore sensitive to the transparency and exposure these data can bring, unless cycle times are short. Inevitably, since there are sensitivities about prompt decision-making, and individual work cycles, debate and discussion can ensue around which is the ‘correct’ cycle time to monitor. The nature of the test in question can also play a major role: for example, rapid set-up and cycle- time in vitro assays are often uncontroversial, but downstream in vivo assays, which can involve extensive run-in times, and may also include exten- sive dosing periods, can appear to have long cycle times. They are usually placed downstream, and the compounds are selected based on a battery of upstream results and decisions, and therefore the overall registration to result cycle times can look very substantial when expressed as a proportion of the entire project lifetime. Many practitioners may feel that these long cycle times are beyond influ- ence and manipulation, and as such, they can feel that making these long cycles transparent is unhelpful and frustrating. On the other hand, for a project manager, it can aid planning to know at the outset that the project may only get one or two shots at a pivotal sub-chronic study, and the com- pound needs to be synthesised as much as nine months before the deadline for the data. In this way, it becomes clear that there is no ‘correct’ time- stamp or use of the data, since it depends on what questions one is asking, what one is trying to achieve, and where one starts from as a baseline. Fortunately, the funnel drawing tool is sufficiently flexible to enable visualisation of any timestamp,
Drug Discovery World Winter 2011/12
as long as the raw data is available in the source databases. Whatever the sensitivities, it is clear that from a drug discovery improvement point of view, the total time taken from opportunity to outcome is the one which adds most delay, contains most waiting and decision-making, and offers the great- est potential improvement opportunity to the research manager.
Knowing the key dates one wishes to capture and how to use them is important but in practice it can be challenging to capture these in a consis- tent manner. Such consistency is important for correct and insightful interpretation of the fun- nels, but collecting data from a wide variety of experimental paradigms can make this problemat- ic. For example, the definition of experiment start date for a short duration experiment is straight- forward, and the opportunity for error due to variation is minimal. However, the start of longer term experiments can be ambiguous (eg the first day of dosing?; the day the animals commence pre-conditioning?). Furthermore, not all organisa- tions are in a position to record elaborate studies in their in-house databases, since the data is often complex to describe for electronic capture and the number of such studies is often relatively small.
47
Figure 3 Informatics Infrastructure. The funnels are connected up to a reporting system and to several scientific data repositories via a highly structured data warehouse
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72 |
Page 73 |
Page 74 |
Page 75 |
Page 76 |
Page 77 |
Page 78 |
Page 79 |
Page 80