Reducing the time it takes to bring a new medical product to market continues to present a challenge to the industry. Indeed, there are a wide variety of processes and systems used to develop a new molecule into a registered pharmaceutical product. Within a single pharmaceutical company, the processes for drug development of one drug are many times inconsistent with the development of another drug. Typically, product planners and study designers in the drug development area do not design their projects with access to information for similar projects that are conducted internally or externally to the company.

Furthermore, the elements that demonstrate the safety and efficacy of a compound--outcomes, measures, data, studies, plans--tend not to be integrated until the end of the drug development life cycle.

As a result, significant inefficiencies, such as lag time, rework, conflicting or inadequate outcomes, and wasted resources adversely impact the drug development process; and correspondingly cause an increased overall cost of drugs and a delay in delivering. life-saving therapies to the market.

Accordingly, there is a demand for better techniques to more efficiently guide medical products through development-- especially in the case of designing clinical trials for drugs to demonstrate safety and efficacy. The present invention provides unique methods, systems and apparatus to meet this demand.

SUMMARY OF THE INVENTION One embodiment of the present invention is a unique product development technique. Other embodiments include unique systems and methods for medical product development.

In a further embodiment, a computer system is programmed to establish an integrated development environment. This system can provide various design, analysis, simulation, documentation, and management tools.

This system can include a knowledge base of certified information from previously designed developments, such as various established ways to prove elemental design objectives. Further features can include a graphic representation of a development design; associated resource allocation, decision logic, and documentation/presentation materials.

Another embodiment of the present invention is a method to facilitate medical product development. This method includes operating a computer program to maintain a database relating to a development strategy for a medical product; entering a number of objectives into the database to characterize the development strategy; establishing a number of proofs with the computer program to test these objectives; grouping the proofs into a number of studies; and executing the studies. Data from the studies can be entered into the database, and at least one of the objectives, proofs, or studies can be modified in response to this data.

In yet a further embodiment, a method includes operating a computer program to maintain a database relating to a clinical testing strategy for a medical product and entering a number of objectives into the database to characterize this strategy. A number of procedures are established to test the objectives that are simulated with the computer program. In response, one or more of the procedures are modified based on this simulation.

Other embodiments include systems or apparatus to implement these methods.

Accordingly, one object of the present invention is to provide a unique product development technique.

Another object is to provide a unique system, method, or apparatus for medical product development.

Further objects, embodiments, forms, advantages, benefits, features, and aspects of the present invention shall become apparent from the description and drawings contained herein.

BRIEF DESCRIPTION OF DRAWINGS Fig. 1 is a diagrammatic view of a computer system of one embodiment of the present invention.

Fig. 2 is a diagrammatic view of an integrated development environment defined with the system of Fig. 1.

Fig. 3 is a flowchart of a development design process using the system of Fig. 1.

Fig. 4 is a graphical depiction of the content of a representative development design provided with the process of Fig. 3 and the system of Fig. 1.

Fig. 5 is graphical depiction of decision logic for the development design of Fig. 4.

Fig. 6 is a graphical depiction of presentation and documentation materials relative to the development design of Fig. 4.

Fig. 7 is graphical depiction of a resource allocation associated with the development design of Fig. 4.

DESCRIPTION OF SELECTED EMBODIMENTS While the present invention may be embodied in many different forms, for the purpose of promoting an understanding of the principles of the invention, reference will now be made to the embodiments illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended. Any alterations and further modifications in the described embodiments, and any further applications of the principles of the invention as described herein are contemplated as would normally occur to one skilled in the art to which the invention relates.

The planning of clinical trials for a new drug often depends on a complex array of interrelated tasks that draw on many different areas of expertise. These trials are further complicated by the need for regulatory input and approval. To proceed with such trials in the United States, an Investigative New Drug submission (IND) is prepared and filed with the Food and Drug Administration (FDA). Upon approval of the IND, Phase I of clinical trials can begin.

In this first phase, the safety of the drug is evaluated by administering it to a number of healthy volunteers.

Following Phase I, Phase II trials are directed to establishing efficacy and dosage by treating patients having the disease state for which the drug is intended to be of therapeutic value. After Phase II trials, Phase III trials are performed on a much larger group in order to establish a statistical basis of proven results for the drug. In the United States, the clinical trial culminates in the submission of a detailed New Drug Application (NDA) to the FDA. Once the NDA is approved, the drug proceeds to production and marketing. It should be appreciated that the clinical trial process often makes efficiency improvements difficult to realize.

In one embodiment of the present invention, a computer- implemented development environment is provided that includes a shared knowledge base accessible by various participating parties to facilitate more efficient clinical trial development for new drugs. The development environment is organized to promote the creation, test, simulation and change management of information about new drug developments-especially in the area of clinical trial design, planning, and execution. For this embodiment, a new drug development design is initially defined by a therapeutic strategy description that can be presented in the form of a conceptual label for the new drug. This strategy is represented in terms of a number of elemental, target objectives. These objectives each correspond to a particular need or want associated with the new drug and can be organized into a hierarchical arrangement of corresponding questions. One or more proofs are associated with each objective. Proofs are activities that are performed to determine if a corresponding objective is being met--providing an answer to each question posed by the objectives. Once proofs are established, they can be individually simulated to determine if any improvements can be made to the development design, and are grouped into various work packages. These work packages can be simulated to identify design improvements as appropriate and are then performed to execute the development in accordance with the design.

In a further embodiment, Fig. 1 depicts a diagram of, computer system 20. Systems 20 includes development subsystem 22 coupled to a number of user sites 24 by computer network 26. Network 26 can include one or more Local Area Networks (LANs) or Wide Area Networks (WANs), such as the Internet, and/or such other network types as would occur to those skilled in the art. Each user site 24 includes at least one network interface device 28. In an embodiment including the Internet in network 26, one or more of interface devices 28 are client computers coupled to subsystem 22 through the Internet. Subsystem 22 includes one or more computer servers 30 and an associated data store 40. The one or more computer servers 30 and/or data store 40 can be a single unit, or distributed among two or more components remotely or centrally located with respect to each other. Subsystem 22 communicates with network 26 via one or more communication ports 50.

Subsystem 22 also includes one or more operator input (I/P) devices 60 and one or more operator output (O/P) devices 70. Input devices 60 can include a conventional mouse, keyboard, trackball, light pen, voice recognition subsystem, and/or a different input device type as would occur to those skilled in the art. Output devices 70 can include a conventional graphic Cathode Ray Tube (CRT) display, Liquid Crystal Display (LCD), or plasma-type display monitor, printer, aural output system, and/or a different output device type as would occur to those skilled in the art. Further, while not depicted, one or more of the interface devices 28 of user sites 24 can include such input and/or output devices, but are not shown to preserve clarity.

Referring further to Fig. 2, system 20 is logically arranged to define a drug development environment 120. For drug development environment 120, the one or more servers 30 are programmed to facilitate the creation, organization, analysis, simulation, documentation, execution, and management of clinical trial drug developments, one of which is illustrated as drug development design 122. Indeed, a number of additional drug development designs can be supported with system 20 and drug development environment 120, but are not shown to preserve clarity.

The one or more servers 30 are arranged to provide a number of software-based development tools 130. Development tools 130 include software procedures to create, manage, simulate, test, schedule, and analyze various aspects of the drug development design 122. Such tools are preferably integrated into environment 120 using common Graphical User Interface (GUI) techniques. Besides development tools 130, drug development environment 120 also includes a knowledge base 140. Knowledge base 140 resides on data store 40 previously described. Knowledge base 140 is arranged to store data associated with drug development design 122, and serve as a repository of information pertinent to the creation and execution of drug development design 122 as will be more fully explained hereinafter.

Access to drug development design 120, tools 130, and knowledge base 140 is provided via a logically defined portal 150 that corresponds to the one or more ports 50 previously described. Portal 150 can be configured to provide a measure of security for selected data by implementing one or more levels of access restriction to the information contained within subsystem 22. Security measures can include one or more conventional firewalls or the like. For the depicted embodiment, portal 150 is illustrated with an output filter 152 to selectively restrict information output to the general public as represented by public user group 160. More specifically, Fig. 2 lists a few representative members of public user group 160 as consumers, pharmacists, advocacy organizations, and physicians.

Besides public user group 160, another group of drug development participants are data gathering group 170 that provide data 172 relevant to planning and execution of a given drug development design. Data 172 is represented as residing on data store 40 in Fig. 2. Typical members of group 170 include investigators conducting experiments relating to the drug under consideration, patients being considered for clinical trials, patients undergoing clinical trials, and physicians conducting clinical trials. In one example, clinical trial patients belonging to group 170 are provided with internet access to facilitate electronic communications concerning various aspects of ongoing clinical trials. In another example, computer network communications can be used in association with one or more network-coupled devices to automatically dispense the drug under study and/or electronically monitor various physical characteristics of a patient. In a further example, electronic teleconferencing (via computer network 26 or otherwise) can be supported to communicate with investigators and/or patients belonging to group 170.

Alternatively or additionally, the interface between group 170 and subsystem 22 can include wireless devices designed to dispense medication, communicate with patients, and/or monitor one or more physical characteristics of a patient.

Another group of participants are evaluating agents 180. Agents 180 include statisticians, clinical scientists, a regulatory liaison, the regulatory agency itself, and marketing personnel. Agents 180 interface with the drug development design 122, knowledge base 140, and/or each other to build a negotiated framework 190 that dynamically adjusts to changes as drug development design 122 evolves and is executed.

Referring additionally to Fig. 3, a flowchart of one process 220 for using drug development environment 120 is illustrated. Process 220 begins in operation 222 with the identification of a therapeutic strategy of the drug for which a development plan is being designed. This strategy can correspond to a conceptual label describing the indications, dosage, contraindications, and the like for the drug under study. The therapeutic strategy is defined in terms of a number of objectives. Each objective is a discrete benchmark that corresponds to a quantifiable and measurable potential outcome. The objectives can be modeled as a set of questions each having two or more possible answers. These potential answers each correspond to a different potential outcome for an associated objective.

One or more objectives can be dependent on the outcome of one or more other of the objectives. In other words, various predecessor objectives can be identified that need to be started and/or completed before one or more corresponding successor objectives. Collectively, these dependent relationships can be used to logically organize the objectives in a hierarchy of different possible sequences of objective outcomes. This arrangement can be in the form of a decision logic tree as will be more fully explained hereinafter. At the highest level of this hierarchy, the objectives represent the needs and wants derived from the conceptual label. At such levels, objectives can typically be grouped into various categories including safety, efficacy, marketing, and manufacture, to name just a few. Attributes that can be associated with an objective include its textual description, author (s), date created, date last modified, category status, market valuation, and pTS (probability of technical success).

To add an objective definition, searching can be conducted of both internal and therapeutic information regarding previously established objectives and competitor products. Once defined, objectives can be routed to market research and regulatory groups belonging to agents 180 to access market liability and probability of regulatory approval, respectively, via portal 150. With the value and probability of regulatory approval defined, therapeutic strategists can continue to refine the therapeutic strategy and identify further objectives directed to establishing desired targets. Part of the strategy management can include identification of resources, timelines, costs, and probability of success. This information permits the movement of resources, timelines, and money among different projects in a simulation mode to facilitate decision-making with regard to different drug developments. From the therapeutic strategy, similar compound or disease state information from existing marketing and regulatory research as well as information from prior internal research can be consulted, and existing objectives can be refined and new objectives added as required to provide a desired level of design definition.

A portion of one non-limiting example of a hierarchical objective outline is depicted as follows for drug RX : I.-Efficacy of Drug RX for a Psychotherapeutic Indication: A.-Drug RX is Superior to Placebo as measured by overall reduction in Psychopathology.

A. 1.-Drug RX Superior to Placebo in reduction of BPRS (Brief Psychiatric Rating Sale) total scores.

A. 1. 1-Mean Change to Baseline A. I. I. 1-Effect Size Estimates A. 1. 1. 1.1-Drug RX-10 A.1.1.1.2-Placebo-6 A. 1.1.2-Variability Estimates A. 1. 1. 2.1-Standard Deviation 10.5 A. 1.1.3-Analysis Method A. 1. 1. 3.1-ANOVA (Analysis of Variance) A. 1. 1. 3.1.1-Treatment/Investigator and related Interactions A. 1.1.3.1.2-Type III sums of squares A. 1. 1. 3.1.3-Raw data A. 1.2-Percent Improvement A. 1.2.1-Analysis Method A. 1.2.1.1-Fisher's Exact Test A. 1.2.1.1.1-Response = % patients achieving at least a 40% improvement from baseline in BPRS total score.

A. 2.-Drug RX is Superior to Placebo in PANSS (Positive and Negative Symptom Sale) total score.

A. 2.1-Mean Change to Baseline A. 2.1.1-Analysis Method A.2.1.1.1-ANOVA A. 1.2. 1. 1. 1-Treatment/Investigator and related interactions A. 1. 2. 1. 1.2-Type III sums of squares A. 1.2. 1.1.3-Raw data A. 3.-Drug RX is Superior to Placebo in CGI (Clinical Global Impression) Severity Scores.

A. 3. 1-Mean Change to Baseline A. 3.1.1-Analysis Method A. 3.1.1. 1 - ANOVA A. 1. 3.1.1.1-Treatment/Investigator and related interactions A. 1.3.1.1.2-Type III sums of squares A. 1.3.1.1.3-Raw data B.-Drug RX is Superior to Placebo in Reduction of Depressive Symptoms for a Drug Currently in Use.

B. 1.-Drug RX is superior to Placebo in reduction of MADRS (Montgomery-Asberg Depression Rating Scale) total scores B. 1. 2-Mean Change to Baseline B. I. 1. 1-Analysis method B.1.1.1.1 - ANOVA B. I. 1. 1. 1. 1-Treatment/Investigator and related interactions B. 1. 1. 1. 1. 2-Type III sums of squares B. 1. 1.1.1.3-Raw data B. 1. 2-Percent Improvement B. 1. 2.1-Analysis Method B. 1. 2.1.1-Fisher's Exact test B. 1. 2.1.1.1-Response = % patients achieving at least a 40% improvement from baseline in MADRS total score II.-Safety of Drug RX for a Psychotherapeutic Indication : A.-Discontinuation Rates due to Adverse Events is not significantly different from Placebo.

A. 1. - Difference in Incidence A. 1. 1-Analysis Method A. I. I. 1 - Pearson's chi-square A. l. l. l. l-Response = % patients who discontinue due to an adverse event A. 2-No one discontinued due to Suicide A. 2.1-Analysis Method A. 2.1.1-Frequency Tabulation A. 2. 1. 1. 1-Response = suicide? B.-No difference between Drug RX and Placebo was seen in Treatment-Emergent Adverse Events B. 1.-Difference in Incidence B. I. 1 - Analysis Method B. I. 1. 1-Pearson's chi-square B. 1. 1. I. 1-Response = % patients with occurrence of event not present at BL (Baseline) or increase in severity of event present at BL C.-No increased risk of Sexual Dysfunction was seen in Patients receiving Drug RX compared to Placebo C. 1.-Difference in Incidence C. 1. 1 - Analysis Method C. 1. 1. 1-Pearson's chi-square C. I. I. 1. 1-Response = % patients with Sexual Dysfunction not present at BL or increase in Severity of Sexual Dysfunction present at BL III.-Health Outcome/Access A.-Drug RX is more Cost-Effective than Existing Treatments B.-Drug RX is more Cost-Effective than a specific existing Drug (s) it is intended to replace.

Questions linked with objectives can be of a type that are formally integrated into the corresponding objective hierarchy initially, or"ad hoc"--that is being introduced into the hierarchy only after the hierarchy has been initially created. Furthermore, the nature of an acceptable answer to a given objective question can be variable, including such types as an expert opinion, an empirical study, forecast, or reference to prior work to name just a few.

For each objective, one or more proofs are selected in operation 224 of process 220. A proof is a means to obtain an answer for a given objective question. Proofs can be designed utilizing one or more development tools 130 or selected from a library of pre-existing proofs contained in knowledge base 140 or otherwise accessible through computer network 26. Pre-existing proofs can be of a certified nature--that is verified by an independent proof standards body--or of a local, uncertified nature. The proof validation process can be implemented using historical data or available external data as appropriate. Conditional 224a of operation 224 corresponds to whether a desired proof is not available. If a proof is not available, it is designed and created in stage 224b. Process 220 then proceeds to operation 226 with the new proof. Also, the new proof can optionally be certified as part of the execution of stage 224b. If the desired proof is available as tested by conditional 224a, then the proof is selected from an appropriate source and process 220 proceeds from operation 224 to operation 226 with the selected proof. In one non- limiting example for the Drug RX, a proof for an efficacy objective might be performance of a specific empirical test, such as"Fisher's Exact Test"listed in the outline previously described.

Indeed, proofs can be of one or more different varieties, such as an opinion type, reference type, and/or analytic type. For the opinion type, the proof is answered by an opinion of one or more experts. For the reference type, research information can support the proof. For the analytic type, the proof is of an empirical nature, such as the Fischer's Exact Test example. The outcome of an analytic proof typically depends on experimental data. An analytical proof type can be defined in an object-oriented fashion using various development tools 130 to assemble input data objects, data collection procedures, scheduling objects, and an output representation type, such as a table, graph, etc. In one example, an analytic proof corresponds to a clinical test that is performed with a designated number of patients and corresponding patient visits. Proofs can be made up of data elements, work instructions and procedures for collecting data, statistical methods, application and frequency analysis, required study groups, and dosage information, just to name a few.

Referring additionally to Figs. 4-7, four different graphical presentation windows 320,420,520, and 620 are illustrated, respectively. Figs. 4-7 correspond to one embodiment of a GUI implementation of the type typically provided with an operator display monitor. Windows 320, 420,520, and 620 each include a corresponding selection tab 321,421,521, and 621, respectively. Selecting one of tabs 321,421,521, or 621 activates the respective window 320, 420,520 or 620. At the bottom of each window are icon bars 322,422,522, and 622, respectively, to select like-labeled auxiliary windows that will be more fully described hereinafter. Tabs 321,421,521, and 621, and icon bars 322,422,522 and 622 can be arranged for selection with a computer graphic pointing device, such as a mouse, trackball, or light pen; a keyboard; and/or such other operator input device type as would occur to those skilled in the art.

Referring specifically to Fig. 4, positioned between tab 321 and icon bar 322 is display region 324. Display region 324 presents graphic map 330 of various elements 331 representative of the content of drug development design 122. Elements 331 include strategy block 332 at the left- most part of map 330 to which a number of objective blocks 334 (individually designated OBJ1, OBJ2, OBJ3, and OBJ4) are linked by right-pointing arrows. Strategy block 332 represents the therapeutic strategy for drug development design 122. Objective blocks 334 represent the objectives for the therapeutic strategy. In turn, objective blocks 334 are relationally linked by right-pointing arrows to corresponding proof blocks 340 (individually designated as PI, P2, P3, P4, P5, P6, and P7). Proof blocks 340 represent the one or more proofs associated with each objective as indicated by the respective arrow linkages. Relational pathways associate each proof block 340 with a corresponding answer block 344. Answer blocks 344 are designated individually as answer blocks Al, A2, A3, A4, A5, A6, and A7 in Fig. 4. Each answer block 344 represents a result from performance of the proof corresponding to the arrow-linked proof block 340. Answer blocks 344 are each relationally linked by a right pointing arrow to a supporting data block 348. Each data block 348 represents supporting data for the answer represented by the arrow-linked answer block 344.

It should be understood that map 330 of Fig. 4 is typically built a block at a time going from left-to-right.

In other words, map 330 begins with formation of strategy block 332 in correspondence with operation 122. Next, objective blocks 334 are formed and relationally linked to block 332. As proof blocks 340 are selected, they are likewise linked to associated object blocks 334. Similarly, answer blocks 344 and data blocks 348 are each displayed in series with a corresponding proof block 340. As elements 331 are added to map 330, detailed information about each element can be displayed in a separate GUI window by selecting the corresponding block 332,334,340,344, or 348 with a point-and-click procedure or a different technique as would occur to those skilled in the art. For example, a textural description of the therapeutic strategy could be accessed by selecting strategy block 332. In another example, the attributes and/or description of an objective or proof could be accessed by selecting the corresponding block 334 or 340. Further details regarding a given answer and/or its supporting data can be accessed by selecting a respective block 344 or 348.

Referring to window 420 of Fig. 5, a further aspect of the drug development design 122 is presented. In Fig. 5, a decision tree 430 is illustrated in display region 424 between tab 421 and icon bar 422 that corresponds to the hierarchical logic dependencies of the various objectives determined with operation 222. Decision tree 430 includes various elements 431, such as conditionals 432 (individually designated by Q1 and Q2) that are representative of questions corresponding to the objectives and results 440 (individually designated by R1, R2, R3, R4, and R5) that are linked to conditionals 432. For the illustrated example, results R1, R2, and R3 each represent a different possible outcome for the objective question Q1. In the case of result R3, objective question Q2 is then encountered which in turn is connected to two possible outcomes represented by results R4 and R5, respectively. Accordingly, decision tree 430 provides a graphical representation of the conditional relationships between elements 431 of drug development design 122, providing a different model of design 122 than map 330. The relationship of proofs to one another is part of a proof design procedure that enables creation of the corresponding decision tree 430. Like elements 331 of map 330, additional details of each element 431 of design tree 430 can optionally be reviewed by selecting the corresponding graphical icon for the conditional 432 or result 440.

Once proofs have been selected in accordance with operation 224, process 220 proceeds to proof simulation operation 226 of Fig. 3. During operation 226, each proof is simulated using external or internal data to optimize proof design and forecast answer scenarios. With regard to the map 330 representation, different coloration or graphical patterns of a given element 331 can be used to represent different development stages such as design, simulation, or execution. Operation 226 can include the optional application of a number of different tools. For example, a data finder agent can be used to search knowledge base 140 for existing proofs that are similar to that being simulated and/or search external data sources, such as the internet, for similar proofs that have already been executed. Another tool can be a data importer that allows data located with the data finder agent to be mapped to the proof for use in simulation. Yet another optional tool is a proof data manager that allows simulation data to be entered by hand, filtered, and modified. Still another tool includes a data browser to view data output by the simulation and a document browser to facilitate identification of documents effected by the proof and provide for viewing of text and documents related to the proof.

Once proofs are simulated, the results are evaluated corresponding to conditional 228 of process 220. For results that indicate an unacceptable proof formulation, control returns to block operation 224 to modify the proofs or select one or more different proofs as required, and then simulate the new/modified proofs in operation 226. Once the proofs are found acceptable as tested by conditional 228, process 220 proceeds to operation 230. Once all proofs are developed, a first draft of an Integrated Summary of Safety (ISS), the Integrated Summary of Efficacy (ISE), and a draft of a corresponding drug label can be generated and reviewed.

Also, the proofs and scenarios can be incorporated into decision tree 430 of window 420.

Referring further to documentation window 520 of Fig.

6, as simulations are conducted, documentation/presentation map 530 is provided in display region 524 between tab 521 and icon bar 534. Map 530 includes elements 531 that correspond to block 532 for a conceptual label, block 534 for the ISS and ISE, blocks 540 for various supporting study reports, and blocks 550 for various corresponding graphs.

The relationships between elements 531 are indicated by right pointing arrow connectors. As in the case of elements 331 and 431 for windows 320 and 420, respectively, elements 531 of window 520 can operate as GUI icons that are selectable to show the corresponding item and/or related information in greater detail. For example, selection of block 532 accesses a textual description of the label.

Similarly, for the ISS or ISE, corresponding documents can be accessed through selection of block 534. Likewise, reports or graphs can be displayed by selecting the corresponding block 540 or 550.

Referring again to process 220 of Fig. 3, in operation 230 work packages are designed that group selected proofs together. For example, various work packages are alternatively represented as studies 362,364, and 366 in window 320 of Fig. 4. It should be appreciated as depicted' for studies 364 and 366, that the work packages can overlap.

The work package design operation 230 includes various development tools 130 to guide the clinical trial planner through the process of selecting appropriate objectives and proofs and combining them into an efficient number and order of studies. This grouping includes identification and management of constraints associated with various studies.

These constraints are focused on costs, resources, timelines and outcomes, and can include corresponding tools to direct a planner to more efficient study compositions. Initial input can be provided by way of a template and prior development information. The plan can be improved by adjusting resources, timeline, study designs, costs, precedence of proofs, and/or other design changes.

Once work packages (studies) are designed, process 220 proceeds to operation 232. In operation 232, the work packages are simulated and the results evaluated in accordance with the test of conditional 234. If the results are not acceptable, process 220 loops back to operation 230 to refine the work package design and perform a new simulation on the refined design.

Referring to window 620 of Fig. 7, as work packages are defined, default resource allocation plans are developed in the form of table elements 631. Elements 631 are presented in display region 624 between tab 621 and icon bar 622.

Elements 631 include table 640 for human resources, table 650 for money resources, and table 660 for time resources.

For the initial performance of operation 230, only the corresponding plan portions 642,652, and 662 would be available for tables 640,650 and 660, respectively.

Once work packaging (study bundling) is accepted as tested by conditional 234, process 220 continues with operation 240. In operation 240, set-up in accordance with the work packages is performed, including obtaining approvals, bids on work to be done, allocating needed resources, and verifying acceptable training of human resources. An execution plan of the approved study protocol, including data capture information, start-up materials, and instructions are automatically created using the work package designs and correspondingly predefined work flows.

After set-up operation 240 is complete, process 220 proceeds to execution stage 242. In execution stage 242, the studies 362,364, and 366 are performed in accordance with the predefined procedures associated with the proofs of design 122, and using the resources as represented by tables 640,650, and 660 of Fig. 7. Document/presentation elements 531 are populated with actual results as the execution progresses. Also, an independent team, that is protected from being biased by the studies, can examine the results to draw inferences and analysis, author customized discussion sections of documents, review conclusion sections of any study reports or summaries, conduct"ad hoc"analysis for inclusion in the final documents, and recommend further steps and/or modifications. Furthermore, as process 220 is executed, the representative blocks of windows 320,420, and 520 can be modified to reflect the changing status.

Alternatively or additionally, as drug development design 122 is executed, the actual allocations of people, money and time, are tracked via blocks 644,654, and 664 of tables 640,650, and 660, respectively.

During and after execution in stage 242, conditional 260 tests whether process 220 is complete. If not, monitoring of process 220 continues in operation 262. From operation 262, conditional 262a is encountered that tests whether any change is needed. If a change is needed, process 220 returns to the appropriate operation to process the change. Only a few of the possible return points are illustrated in Fig. 3 to preserve clarity. Indeed, such changes can be directed to any aspect previously described in connection with process 220 such as the therapeutic strategy, labeling, ISS, ISE, objectives, proofs, proof simulations, work package designs, work package simulations, set up, execution, etc. If no changes are required as tested by conditional 262a, process 220 loops back to conditional 260 until conditional 260 is affirmative, in which case process 220 terminates.

Referring to icon bars 322,422,522, and 622 of corresponding windows 320,420,520, and 620 ; tool/information icons 820, are next further described.

Icons 820 provide a way to graphically select different sets of development tools 130 in correspondence with different operations/stages of process 220. For example, in the case of operation 222, design tools such as a therapeutic area strategy authoring tool, knowledge retrieval tool and competitive intelligence/research tool can be accessed by selecting objective definition icon 822. Likewise, this selection can provide an organization tool to put the objectives into a desired hierarchy of questions, and/or templates to standardize the objectives.

Selection of proof design icon 824 provides access to various proof design tools. These tools can include a proof library manager that is organized according to various categories such as therapeutic class, statistical methods, etc. Furthermore, the existence of and level of proof certification can be indicated. Indeed, the tools can also include management of the proof certification process itself. Besides the library associated tools, a proof search tool can be provided. When it is not desired to use an existing proof, a proof designer tool can be utilized that facilitates an object-oriented definition of a new proof. In the case of an analytic proof type, objects that might be made available include input data, collection procedure objects, scheduling objects, default output objects and the like. Further, tools directed to data collection procedure design, and textual descriptions of the proof are also envisioned, just to name a few other options.

Proof simulation icon 826 provides for various proof simulation tools. Among these tools can be a data finder agent operable to search knowledge base 140 for similar executed proofs and/or external data sources such as the internet. A data importer tool can also be provided that facilitates mapping data to a proof undergoing simulation, such as are found with the finder agent. A data management tool can also be included. To facilitate review of simulation results, a data browser and/or document browser tool can be included. As simulations are completed, the confidence level associated with various relational pathways can be indicated as part of map 330 of window 320 and/or decision tree 430 of window 420.

Work packaging icon 830 accesses work package tools.

Within these tools can be an automated bundler or work packager to bundle proofs into desired studies, including resources to accomplish the work, such as people, time, and money; an associated time schedule; descriptions of assorted tasks and procedures; training materials; instructions; reference materials ; and a sequence of specific tasks.

These work packages can be grouped into different types, including clinical trial, laboratory experiment, manufacturing, marketing, etc. As work packages are created, potential conflicts can be identified and resolved (i. e., patient visit scheduling conflicts), various procedure steps may be consolidated, data redundancies can be identified and removed, and data conflicts resolved.

Work package (Pkg.) simulation icon 832 corresponds to operation 232 providing tools for work package simulation.

These tools define each person or entity involved as an autonomous agent characterizing its behavior and rules for behavior as pertains to the various tasks to be performed.

Tools accessible with icon 832 can also include a search agent to find studies similar to the subject work package, data importers, data browsers, and trade-off analyses.

Set-up icon 840 is selected to facilitate set-up of work packages. Set-up activities include obtaining approvals, soliciting bids on work, allocating actual resources, and training of resources. Icon 840 can also include the set-up of a production environment using the designs and automated workflows from the simulated work packages.

Execution icon 850 accesses information and tools corresponding to execution stage 242. Such tools can include a detailed local patient management system, time data collection system, and automated electronic work flow that are implemented using electronic technologies including, but not limited to, smart cards, portable wireless data collection devices, internet connections, and/or networked medical data collection devices in medical facilities, patient homes, and/or on or in patient's bodies.

This system could be used to facilitate more direct, interactive, and real-time contact/data collection with patients and investigators, and could include voice recognition, natural handwriting, remote sensors, and the like. Other features that could be provided as part of the execution operation include automated dosage dispensing, and remote patient monitoring by internet communication, wireless communication, and/or a different technique known to those skilled in the art.

Icon 862 corresponds to monitoring operation 262, and can be arranged to access details regarding execution progress. For example, enrollment rates, patent visits completed, data problems, etc., can be described in this matter. Furthermore, a change order tool can be included to facilitate modification of designs as required during execution.

Other general tools that can be included are a data viewer and a comparison tool for doing impact analysis, a medical procedure library, and/or a qualification library of conditions used for inclusion or exclusion from a given clinical trial study. It should be understood that the elements presented in windows 320,420,520, and 620 are merely examples provided for illustration purposes, and can vary from design-to-design. Moreover, multiple designs and corresponding windows and tools can be defined with environment 120.

It should be understood that environment 120; process 220, windows 320,420,520, and 620 ; and various associated tools and procedures are provided by operating logic of the one or more servers 30. This logic can be in the form of software programming, firmware, and/or dedicated hardware of an analog and/or digital type.

Many other embodiments of the present invention are envisioned. For example, another embodiment includes a computer system to facilitate medical product development that includes a computer network, a number of clients coupled to the network, and a server coupled to the network.

The server is programmed to maintain a development database that includes a number of development objectives for a development design. These objectives relate to a number of proofs. These proofs are each grouped into a number of studies. The server is operable to provide one or more reports relating data from execution of the studies to the proofs.

In still another embodiment, a computer-readable device encoded with a program executable by a computer system is provided. This program maintains information relating to development of a medical product. The program includes a number of instructions operable to relate a number of hierarchical development strategy objectives for the medical product to a number of proofs to test these objectives. The instructions also relate each of a number of studies to a different set of the proofs and simulate one or more of the proofs or studies. The instructions further provide a number of reports relating to data entered into the computer system resulting from execution of the studies.

All publications and patent applications cited in this specification are herein incorporated by reference as if each individual publication or patent application were specifically and individually indicated to be incorporated by reference. Further, any theory, mechanism of operation, proof, or finding stated herein is meant to further enhance understanding of the present invention, and is not intended to limit the present invention in any way to such theory, mechanism of operation, proof, or finding. While the invention has been illustrated and described in detail in the drawings and foregoing description, the same is to be considered as illustrative and not restrictive in character, it being understood that only selected embodiments have been shown and described and that all equivalents, changes, and modifications that come within the spirit of the inventions as defined herein or by the following claims are desired to be protected.