Interactive graphical environment for drug model generation Number:7,043,415 from the United States Patent and Trademark Office (PTO) owispatent A method for interactively constructing pharmacological computational models is disclosed. A graphical user interface is presented through which a user may place and connect objects representing pharmacokinetic and pharmacodynamic elements. As the objects are placed and connected, they are converted into an internal format representing the statements of the corresponding computational model. These statements are actively presented to the user in a summarized form, as the computational model is constructed, to enable immediate verification of the model. This summarized form may be a surface syntax showing key equations that make up the model, or they may be graphs of behavior of one or more user-selected variables.<H environment, Interactive, Interactive, gra, 7043415.html, Patent, pto, 7043415

Title: Interactive graphical environment for drug model generation

Abstract: A method for interactively constructing pharmacological computational models is disclosed. A graphical user interface is presented through which a user may place and connect objects representing pharmacokinetic and pharmacodynamic elements. As the objects are placed and connected, they are converted into an internal format representing the statements of the corresponding computational model. These statements are actively presented to the user in a summarized form, as the computational model is constructed, to enable immediate verification of the model. This summarized form may be a surface syntax showing key equations that make up the model, or they may be graphs of behavior of one or more user-selected variables.

Patent Number: 7,043,415 Issued on 05/09/2006 to Dunlavey, et al.

Inventors: Dunlavey; Michael Robert (Needham, MA); Hermann; David J. (Chelsea, MI); Wald; Jeffrey Alan (Cary, NC); Weiner; Daniel Lee (Apex, NC)
Assignee: Pharsight Corporation (Mountain View, CA)

Appl. No.: 823214

Filed: March 30, 2001

Current U.S. Class: 703/12 ; 702/19; 703/2; 715/747; 715/763; 715/765

Current International Class: G06G 7/48 (20060101)

Field of Search: 703/12,11,2 600/300 707/104.1,3 345/848 715/747,763,765 702/19 435/325

References Cited [Referenced By]

U.S. Patent Documents


5434796	July 1995	Weininger
5860917	January 1999	Comanor et al.
5962317	October 1999	Hamzeh et al.
6051029	April 2000	Paterson et al.
6069629	May 2000	Paterson et al.
6078738	June 2000	Garza et al.
6381562	April 2002	Keane
6542858	April 2003	Grass et al.
6647358	November 2003	Grass et al.
6694334	February 2004	DuLong et al.
2002/0120431	August 2002	Keane
2003/0156143	August 2003	Westenskow et al.
2004/0093331	May 2004	Garner et al.

Other References

Van Meurs et al., W.L. Pharmacokinetic-Pharmacodynamic Model for Educational Simulations, IEEE Transactions on Biomedical Engineering, vol. 45, No. 5, May 1998, pp. 582-590. cited by examiner .
Kang et al., D. Bayesian Estimation in Pharmacokinetics/Pharmacodynamics Using Regenerative Sampling-Based Methods, Proceedings of the First Joint BMES/EMBS Conference Serving Humanity, Advancing Technology, Oct. 1999, p. 987. cited by examiner .
Jelliffe et al., R. Population Pharmacokinetic and Dynamic Models: Parametric (P) and Nonparametric (NP) Approaches, Proceedings 14th IEEE Symposium on Computer-Based Medical Systems, Jul. 2001, pp. 407-412. cite- d by examiner .
Katzper, M. Intrinsic Dynamics and Pharmacometric Model Discrimination, Proceedings of the 1995 Winter Simulation Conference, pp. 1066-1072. cite- d by examiner .
Michael R. Dunlavey, Performance Tuning: Slugging It Outl, Dr. Dobb's Journal, Nov. 1993. cited by other .
Michael R. Dunlavey, Differential Evaluation: a Cache-based Technique for Incremental Update of Graphical Display of Structures, Software Practice and Experience, vol. 23, No. 8, Aug. 1993, pp 871-893 (Wiley). cited by other .
High Performance System, Inc., http://www.hps-inc.com/index.html, Mar. 2001. cited by other .
Gabrielsson et al., Pharmacokinetic and Pharmacodynamic Data Analysis: Concepts and Applications, 3rd edition, 2000, pp. 45-46, 175-176. cited by other .
High Performance Systems, Inc. STELLA, An Introduction to Systems Thinking, 2001, 173 pages total. cited by other.

Primary Examiner: Frejd; Russell
Attorney, Agent or Firm: Townsend and Townsend and Crew LLP

Parent Case Text

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application Ser. No. 60/265,750, filed on Jan. 31, 2001.

Claims

What is claimed is:

1. A computer-implemented method for pharmacological computational model construction, comprising: (a) presenting a graphical user interface having a plurality of objects, each object representing one or both of a pharmacokinetic element and a pharmacodynamic element; (b) receiving instructions via the graphical user interface for connection of at least two of the objects; (c) displaying the at least two objects connected in accordance with the received instructions; (d) converting the at least two connected objects into equations corresponding to the pharmacokinetic and pharmacodynamic elements represented by the at least two connected objects, wherein the converting step (d) occurs substantially coincident with the object displaying step (c); and (e) displaying the equations on the graphical user interface substantially coincident with the object displaying step (c).

2. The method of claim 1, wherein the converting step (d) comprises: (f) converting the at least two connected objects into an internal format; and (g) converting the internal format into a surface syntax.

3. The method of claim 2, wherein the surface syntax represents differential equations in an integrator equals rate expression format.

4. The method of claim 2, wherein the objects comprise one of more of compartment blocks, flow blocks, response blocks, and formulation blocks.

5. A computer-implemented method for pharmacological computational model (a) presenting a graphical user interface having a plurality of objects, each object representing one or both of a pharmacokinetic element and a pharmacodynamic element; (b) receiving instructions via the graphical user interface for connection of at least two of the objects; (c) displaying the at least two objects connected in accordance with the received instructions; (d) converting the at least two connected objects into an internal format corresponding to the pharmacokinetic and pharmacodynamic elements represented by the at least two connected objects, wherein the converting step (d) occurs substantially coincident with the object displaying step (c); (e) interpreting the internal format to generate a time-based simulation including calculation of one or more selected variables; (f) plotting the one or more selected variables in a graph; and (g) repeating the interpreting and plotting steps (e) and (f), thereby actively updating the graph as the instructions are received in step (b).

6. The method of claim 5, further comprising: (h) receiving commands via the graphical user interface to modify at least one of the one or more selected variables; and (i) modifying the interpreting step (e) in response to the received commands in step (b); thereby actively updating the graph to reflect changes to the at least one of the one or more selected variables.

7. The method of claim 6, wherein the modifying step (i) comprises revising the internal format.

8. The method of claim 6, wherein one or more of the one or more selected variables depend upon a random variable, wherein the interpreting step (e) generates a value for the random variable upon each repetition, and wherein the plotting step (f) plots the one or more selected variables over plots from previous repetitions, thereby showing variability of the one or more selected variables caused by the random variable within a single graph.

9. The method of claim 6, wherein the internal format comprises a parse tree.

10. The method of claim 6, wherein the one or more selected variables comprise least two selected variables, and wherein the plotting step (f) comprises plotting at least ie selected variable versus another selected variable.

11. The method of claim 6, wherein the plotting step (f) comprises plotting the one or more selected variables versus time.

12. The method of claim 5, further comprising: (j) translating the internal format into text strings representing equations, the equations corresponding to the respective pharmacokinetic and pharmacodynamic elements represented by the two or more connected objects; and (k) displaying the text strings substantially coincident with the object displaying step (c).

13. The method of claim 12, wherein the objects comprise one or more of compartment blocks, flow blocks, response blocks, and formulation blocks.

14. A computer readable medium having stored thereon one or more sequences of instructions for causing one or more processors to perform steps for enabling construction a graphical pharmacological computational model, the steps comprising: (a) presenting a graphical user interface having a plurality of objects, each object representing one or both of a pharmacokinetic element and a pharmacodynamic element; (b) receiving instructions via the graphical user interface for connection of at least two of the objects; (c) displaying the at least two objects connected in accordance with the received instructions; (d) converting the at least two connected objects into equations corresponding to the pharmacokinetic and pharmacodynamic elements represented by the at least two connected objects, wherein the converting step (d) occurs substantially coincident with the object displaying step (c); and (e) displaying the equations on the graphical user interface substantially coincident with the object displaying step (c).

15. The computer readable medium of claim 14, wherein the converting step (d) comprises: (f) converting the at least two connected objects into an internal format; and (g) converting the internal formal into a surface syntax.

16. A computer readable medium having stored thereon one or more sequences of instructions for causing one or more processors to perform steps for enabling construction of a graphical pharmacological computational model, the steps comprising: (a) presenting a graphical user interface having a plurality of objects, each object representing one or both of a pharmacokinetic element and a pharmacodynamic element; (b) receiving instructions via the graphical user interface for connection of at least two of the objects; (c) displaying the at least two objects connected in accordance with the received instructions; (d) converting the at least two connected objects into an internal format corresponding to the pharmacokinetic and pharmacodynamic elements represented by the at least two connected objects, wherein the converting step (d) occurs substantially coincident with the object displaying step (c); (e) interpreting the internal format to generate a time-based simulation including calculation of one or more selected variables; (f) plotting the one or more selected variables in a graph; and (g) repeating the interpreting and plotting steps (e) and (f), thereby actively updating the graph as the instructions are received in step (b).

17. The computer readable medium of claim 16, wherein the steps further comprise: (h) receiving commands via the graphical user interface to modify at least one of the one or more selected variables; and (i) modifying the interpreting step (e) in response to the received commands in step (b); thereby actively updating the graph to reflect changes to the at least one of the one or more selected variables.

18. The computer readable medium of claim 17, wherein one or more of the one or more selected variables depend upon a random variable, wherein the interpreting step (e) generates a value for the random variable upon each repetition, and wherein the plotting step (f) plots the one or more selected variables over plots from previous repetitions, thereby showing variability of the one or more selected variables caused by the random variable within a single graph.

19. The computer readable medium of claim 17, wherein the plotting step (f) comprises plotting the one or more selected variables versus time.

20. The computer readable medium of claim 16, wherein the steps further comprise: (j) translating the internal format into text strings representing equations, the equations corresponding to the respective pharmacokinetic and pharmacodynamic elements represented by the two or more connected objects; and (k) displaying the text strings substantially coincident with the object displaying step (c).

21. A system configured to present a graphical user interface having a plurality of objects, each object representing one or both of a pharmacokinetic element and a pharmacodynamic element, the graphical user interface enabling construction of a graphical pharmacological computational model, the system comprising: (a) a processor; (b) a data storage area; and (c) an execution area configured to: (i) receive instructions regarding connection of at least two of the objects; (ii) display the connected objects in accordance with the instructions; (iii) convert the at least two connected objects into an internal format corresponding to the pharmacokinetic and pharmacodynamic elements represented by the at least two connected objects, in parallel with the object display; (iv) interpret the internal format to generate a time-based simulation including calculation of one or more selected variables; (v) plot the one or more selected variables in a graph; and (vi) repeat the interpreting and plotting, thereby actively updating the graph as the instructions are received.

22. The computer system of claim 21, wherein the execution area is further configured to: (a) receive commands via the graphical user interface to modify at least one of the one or more selected variables; and (b) modify the interpreting in response to the received commands; thereby actively updating the graph to reflect changes to the at least one of the one or more selected variables.

23. The computer system of claim 22, wherein one or more of the one or more selected variables depend upon a random variable, and wherein the plots occur over previous plots, thereby showing variability of the one or more selected variables caused by the random variable within a single graph.

24. The computer system of claim 23, wherein the plots are of the one or more selected variables versus time.

25. The computer system of claim 24, wherein each of the one or more selected variables is plotted using a different color.

26. The computer system of claim 21, wherein the execution area is further configured to: (a) translate the internal format into text strings representing equations corresponding to the pharmacokinetic and pharmacodynamic elements represented by the connected objects; and (b) display the text strings in parallel with the object display.

Description

BACKGROUND

1. Field of the Invention

This invention relates generally to computational models of dynamic processes within living organisms, and more particularly, to systems and methods for enabling generation of computational models of drug behavior.

2. Description of Related Art

Information regarding the behavior of drugs and diseases in the body of a living organism is needed for many purposes in biological science and industry. Generally, this information gives rise to two interrelated disciplines: pharmacokinetics, which is the study of the processes by which a drug is absorbed, distributed, metabolized and eliminated by the body, and pharmacodynamics, which is the study of the action or effects of drugs on living organisms.

Pharmacokinetics and pharmacodynamics are combined to study the efficacy of drugs and the progression of diseases, through the use of computational models. Such computational models are also commonly referred to as drug models or input/output models. Typically, these computational models are stored as software subroutines in a high level language, such as Fortran, for use in a variety of applications. Two applications in particular require these computational models: model fitting of clinical data, and simulation of clinical trials.

The traditional approach to generating these computational models is labor intensive and prone to extensive delays caused by human error. For example, in the case of generating a drug model, typically, a researcher will review all the information available concerning the way in which the drug behaves in the body of interest. In some cases, the researcher might also draw some rough sketches of compartments representing the various organs in the body and showing the flow of the drug through those organs. Then the researcher must figure out the differential equations that model that drug behavior, or alternatively, solve the differential equations using closed form solutions and determine the exponential equations. Finally, the equations must be translated into software, which in turn must be debugged.

Whenever software is written, human error and oversight invariably introduce bugs. Thus debugging of software is a necessary step, which can be tedious and time consuming. Further, the software debugging process is usually not complete until the researcher uses the software in an existing application and analyses the results to see if they make sense. These problems with drug model generation are exacerbated by the fact that many researchers are trained in the life sciences and are not necessarily experts at coding software. Using a trained computer programmer to work with the researcher may introduce needed coding expertise, but can also compound the problem by introducing a communication step to the process, which presents more opportunities for human error.

An early attempt to address the problem of researchers' lack of coding experience was the Advanced Continuous Simulation Language (ACSL). ACSL is a simulation language that allows a researcher to write differential equations, which are then converted into Fortran for insertion into a simulation program. While ACSL was an improvement, the language was not substantially different from the Fortran language itself, thus a researcher still needed knowledge of how Fortran programming works. Moreover, ACSL did not address any of the other significant problems, such as the difficulty of model verification before a simulation has been run.

Graphical drug model builders have also been created. For example, Pharsight Trial Designer 1.2, available from Pharsight Corporation, 800 West El Camino Real, Suite 200, Mountain View, Calif. 94040, includes a graphical model builder component, which allows a researcher to build a drug model using graphical blocks. Once the drug model is completed, the software generates code for use in trial simulation. The generated code implements the appropriate differential equations. However, when errors are made in the construction of the drug model, these errors may not be discovered until after a drug trial simulation is completed. Only after the results of the trial simulation are available is the researcher able to compare the products of the drug model with expectations. Since drug trial simulation frequently involves a large amount of processor time, this attempted solution is inefficient at accelerating the drug model creation process.

In addition to graphical model builders directed specifically to drug model generation, other graphical model builders have also been created. For example, Stella 6.0, available from High Performance Systems, Inc., 45 Lyme Road, Suite 300, Hanover, N.H. 03755-1221, is software designed to render and test mental models of everything from "how a bowl of soup cools to how a galaxy expands . . . and everything in between." While these types of software tools may be used to build drug models, their lack of focus on a particular problem set makes them less effective in the pharmacological context.

Moreover, when errors are made in the construction of a model, these errors are typically not found until after a simulation is completed. For simple simulations this is less of a concern, but for drug trial simulations, these errors can cause extensive delays in drug model verification.

SUMMARY OF THE INVENTION

One aspect of the invention is directed to a system and method for enabling graphical construction of pharmacological computational models using interactive equations display. A graphical user interface, which allows a user to place and connect objects that represent pharmacokinetic and pharmacodynamic elements, is presented. While the objects are placed and connected by a user, the objects are converted into an internal format, such as a parse tree, representing statements for the computational model under construction. Equations for the model under construction are derived from the statements, and actively displayed to the user.

This automatic expression of the graphical model in mathematical terms for examination by the user makes the graphical model builder interactive, thereby accelerating the model building and verification process.

Another aspect of the invention is directed to a system and method for enabling graphical construction of pharmacological computational models using interactive graphing of model outputs. A graphical user interface, which allows a user to place and connect objects that represent pharmacokinetic and pharmacodynamic elements, is presented. While the objects are placed and connected by a user, the objects are converted into an internal format, such as a parse tree, representing statements for the computational model under construction. These statements are then actively interpreted to generate a time-based simulation using the computational model, and one or more user-selected variables are plotted in a graph in real time, while the model is being constructed.

In one embodiment, the method further includes actively modifying the interpretation of the statements, either directly or by modifying the internal format, in response to user commands to modify variables and/or constants in the model under construction. The graph is thereby updated in light of the new variable information in real time. Additionally, in one embodiment, the plotting of the one or more user-selected variables retains a history of prior plots, thereby causing random variables in a model under construction to create fan like graphs, which visually demonstrates variability components in real time.

This real-time plotting of selected variables in a graphical model under construction allows a user to examine the outputs of a graphical drug model in an interactive fashion, thereby accelerating the model building and verification process.

Another aspect of the invention is directed to a computer system and computer readable medium for enabling graphical construction of pharmacological computational models using interactive equations display and interactive graphing of model outputs. Other and further aspects and features of the invention will become apparent from the following drawings and detailed description.

BRIEF DESCRIPTION OF THE FIGURES

Preferred embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings, in which like reference numerals refer to like components, and in which:

FIG. 1 is a block diagram illustrating components of a drug model editor according to one embodiment;

FIG. 2A is an illustration showing an exemplary drug model construction window according to one embodiment;

FIG. 2B is an illustration showing a dynamic graphical interface methodology as used in defining joint multivariate distributions according to one embodiment;

FIG. 3 is an illustration showing an exemplary incompatible units notification according to one embodiment;

FIG. 4 is a table showing primitives for an internal parse tree data structure for use in translating model blocks into equations according to one embodiment;

FIG. 5 is a flowchart depicting a process for providing an interactive graphical drug model editor according to one embodiment;

FIG. 6 is a flowchart depicting a process for translating model blocks into an internal format according to one embodiment;

FIG. 7A is an illustration showing an exemplary drug model construction window and an exemplary drug model equations window according to one embodiment;

FIG. 7B is an illustration showing an exemplary drug model equations window for the drug model shown in FIG. 2A;

FIG. 7C is an illustration showing an exemplary drug model debug window for the drug model shown in FIG. 2A;

FIG. 7D is an illustration showing an exemplary drug model construction window, an exemplary drug model equations window and an exemplary drug model debug window according to one embodiment; and

FIG. 8 is a block diagram illustrating an example computer system in which elements and functionality of the invention are implemented according to one embodiment.

DETAILED DESCRIPTION OF THE INVENTION

The present invention is generally directed toward systems and methods employing a computer-presented graphical user interface through which a user can generate a drug model interactively. For ease in illustration, aspects and features of the invention are disclosed and described herein in terms of a single computer running locally stored software for designing drug models. However, after reading this description, it will be apparent to those skilled in the relevant art(s) that the invention may be implemented in alternative embodiments. For example, alternative embodiments include distributed systems in which a dumb terminal accesses the software over a network connection, and also editors that allow construction of alternative computational models, such as models of disease processes within the body and disease-drug interactions.

FIG. 1 is a block diagram illustrating components of a drug model editor according to one embodiment. The drug model editor includes a display 100 and a programmed computer 120. The programmed computer 120 includes a graphical user interface 124, an equations generator 128, a set of defined blocks 132, a code generator 140, a simulation interpreter 144, and a drug model library 148. In one embodiment, the set of defined blocks 132 includes one or more programmable blocks 136, and the equations generator 128 includes a units tracker 152.

The graphical user interface 124 presents various windows on the display 100, thereby enabling a user to construct, modify, view and debug computational models of drugs using graphic objects. In the illustrated embodiment, these various windows are divided into four general types: a model construction window 104, an equations window 108, a debugging window 112, and a messages window 116. While these windows are shown in FIG. 1 as non-overlapping, they may in fact overlap, be resized, etc., as would be apparent to those skilled in the relevant art(s).

The model construction window 104 displays the graphical model under construction. The equations window 108 displays equations derived from the graphical model. The debugging window 112 displays a plot of variables selected from the graphical model, either against time or against each other. Errors and warnings are listed in the messages window 116. Typical error messages include syntax errors, use of undefined variables in user code, misuse of units, divide by zero, etc.

The available functionality and presentation formatting for the windowing environment generated by the graphical user interface 124 is extensive and well appreciated by those skilled in the relevant art(s). In one embodiment, the graphical user interface 124 uses Microsoft Dialog Windows, which are part of the Windows' operating system. Alternative embodiments include any visual presentation wherein a drug model can be constructed using graphic objects, equations representing the drug model can be generated and displayed at the same time as the drug model is constructed, and the behavior of the constructed drug model can be tested and displayed at the same time as the drug model is constructed using real-time emulation.

In one embodiment, certain error messages, such as misuse of units, are always displayed within the model construction window 104 in a simplified messages window 116. Thus, the messages window 116 is not limited to a separate full window, such as a Microsoft Dialog Window, and in one embodiment is a simple box graphic placed on top of the drug model in the model construction window 104. This embodiment is discussed in greater detail below in connection with FIG. 3.

FIG. 2A is an illustration showing an exemplary drug model construction window according to one embodiment. Referring now to FIG. 2A, a drug model is constructed in a drug model construction window 200 by inserting blocks 202 selected from a menu 204 or by drag-and-drop from a set of icons 206. Each block has ports representing inputs and outputs that can be wired together. The ports correspond to variables in resulting equations.

In one embodiment, input ports are on the left of each block, and output ports are on the right. Any output port can be wired (by click and drag) to any input port. Additionally, a user can specify the names of the ports. In one embodiment, if an input port receives input from more than one wire, it receives the sum of the signals. The blocks 202 can be moved and/or resized by dragging. Groups of blocks 202 can be selected, either by lasso, or by control-click, and moved, cut, copied, or pasted.

In an alternative embodiment, connections between input and output ports are specified by the block placement, and no wiring of outputs to inputs is necessary to create a functioning drug model.

In one embodiment, the blocks are color coded by their function in the drug model. For example, formulation blocks 208 may be colored blue. A formulation block represents the intention to administer a particular drug (i.e. a path of drug administration). Thus, it is also referred to as a dosing/treatment block. Such blocks can be connected to compartment blocks, with the meaning that the drug will go into the connected compartment(s). A formulation block is a placeholder for information about subject adherence, such as delay time and 1-coin or 2-coin models. In one embodiment, placebos are also modeled as formulation blocks 208.

Response blocks 210 are colored green. A response block represents the intention to observe some variable of the drug model, such as concentration in the central compartment, pharmacodynamic effect, etc. Thus, it is also referred to as an observation block. These response blocks 210 may represent any number of protocol observables for use in a simulated clinical trial. For example, the response block CP in FIG. 2A represents a concentration in plasma observation for the drug PainAway.

Compartment blocks 212 represent any object that can store a given chemical compound. These objects are typically a specific organ or set of organs, but may also be manufactured objects such as a patch attached to the skin. Compartment blocks 212 are colored gray and are the heart of the pharmacokinetic model. Although the compartment blocks 212 are primarily intended to model pharmacokinetic compartments, they may also be used for modeling pharmacodynamic compartments. Generally, there are four types of compartments: absorption, central, peripheral, and elimination. Central and peripheral compartments, such as plasma and liver, can optionally have a volume parameter and are therefore able to represent relationships between amount and concentration of particular compounds.

Elimination compartments are typically not shown, but a graphic for elimination compartments is included in this example embodiment for the purpose of clarity.

Absorption compartments are used to represent a reservoir from which a drug is absorbed into the body, such as the gut. For example, a drug input arrow 214 represents oral presentation of formulation PainAway, in which the medication is entered into the gut. From there it is absorbed via the absorption flow into the plasma compartment. This pathway can be used both for bolus (i.e. a pill) or infusion (i.e. an administration of an amount of drug that takes an extended length of time), or any combination thereof. For example, a patch is a treatment regimen that is both an initial bolus and a slow release, thus it could be modeled using the single absorption compartment, formulation, and arrow. Alternatively, it could be modeled using multiple formulation blocks and/or multiple absorption compartments.

Between compartment blocks 212 are flow blocks 216. The flow blocks 216 are used to connect compartment blocks to represent the flow of chemical compound moving from one compartment to another at a certain rate. Flow blocks 216 can be unidirectional or bi-directional. They can also model reactions in which one chemical compound is transformed into another, such as a metabolite. The rate at which material flows from one compartment to the other can be specified in multiple ways, including any of the following: (1) a simple rate parameter, or micro parameter; (2) a clearance parameter; (3) Michaelis-Menten (saturating) kinetic parameters; or (4) a user-code expression. Any flow can be specified to be bi-directional if it is parameterized by a simple rate parameter. Additionally, any flow can have a bioavailability factor specified.

Of most interest in pharmacokinetics are the rates of flow between compartments as a function of time. This is discussed in greater detail below in connection with FIG. 5B.

In addition to the blocks discussed above, additional blocks 202 are provided. These additional blocks can be thought of as falling into four general categories, although these categories are not definitive and tend to overlap one another: (1) basic blocks, (2) math blocks, (3) pharmacodynamic blocks, and (4) other blocks.

In addition to the blocks discussed above, the basic blocks include a population block, an effect compartment block, a formulation block, an annotation block, and a group block. The population block allows specification of variables that define the individual properties of each subject, such as age, gender, body weight, renal clearance, etc. These population variables are also known as population covariates, subject covariates, or just covariates. The population block also allows statistical distributions to be associated with these covariates: either univariate or multivariate distributions. Distributions are categorical or continuous. All continuous distributions have optional high and low truncation limits, and any set of variables can be joined into a joint multivariate distribution.

The shape of each univariate distribution is chosen from among: categorical, normal, lognormal, poisson, weibull, beta, beta with mean and standard deviation, uniform, constant, binomial, negative binomial, exponential, logistic, chi-square, student's t, gamma, and inverse gamma distributions.

Each multivariate distribution can contain either or both of categorical or continuous variables. In the case that a multivariate distribution contains more than one continuous variable, the shape of the distribution is chosen from among normal, log-normal, and student's t, with either a correlation matrix or a variance-covariance matrix.

The population block also allows several sub-populations to be modeled in such a way that the parameters of each univariate or multivariate distribution can differ among different sub-populations. Additionally, within any given sub-population, the distribution may be determined by importing from a file of data, as specified by the user.

An effect compartment block represents a pure concentration in tissue, where the rate parameter of build-up is the same as the rate parameter of loss: dY/dt=(X-Y)*K. An effect compartment is also known as a "biophase."

As is known in the relevant art(s), for a typical drug to have an effect in the body, that drug must get to the location where the effect will occur. Typically, that means the drug must get into a particular kind of tissue, next to a particular kind of cell and bind with one or more specific receptors. The effect compartments are used to model the drug getting from the blood to where it actually does its work, i.e., to model the concentration of the drug next to the cells of interest).

Of significant concern is the amount of the drug next to the cells of interest. For this reason, the volume of an effect compartment is generally irrelevant. In its most general form, an effect compartment represents a delay between the time the drug gets into the blood and the time it begins to cause effects. The effect compartments are purely mathematical compartments, to which a response block may be attached.

An annotation block allows a block of text to be displayed in the graphical drug model, in a variety of fonts, colors, and sizes. A group block serves to enclose a set of other blocks. The blocks inside the group can be optionally visible or hidden, and the entire group can be moved and/or resized as a unit.

The math blocks include a continuous distribution block, a categorical distribution block, a multivariate distribution block, a choose block, an adder block, a multiplier block, a table block, an exponentiate block, a log block, a square block, a squareroot block, an inverse block, an integ block, and a delay block. The choose, adder, multiplier, table, exponentiate, log, square, squareroot, inverse, and integ blocks correspond simply to their respective mathematical functions.

The choose block implements a multiplexer. The adder block adds together two or more input signals. Each input can optionally be negated, so as to be subtracted from the sum, rather than added. The multiplier block multiplies together two or more input signals. Each input can optionally be inverted, so as to divide into the result, rather than multiply. The table block allows an arbitrary function to be entered in tabular form. The output is determined from the input by table lookup with interpolation. The table block can have multiple columns so as to have multiple output variables. The output of the exponentiate block is the exp function applied to the input. The log block output is the natural logarithm of the input. The square block output is the square of the input. The squareroot block output is the square root of the input. The inverse block output is 1 divided by the input. The integ block output is the time integral of the input (i.e. Y=dX/dt, where X is the input).

A continuous distribution block represents a quantity that is known to be variable over time, and for which there is no limit to the number of different values it can take on. When the drug model is used for trial simulation, the available kinds of distributions are normal, lognormal, poisson, weibull, beta, beta with mean and standard distribution, uniform, constant, binomial, negative binomial, exponential, logistic, chi-square, student's t, gamma, and inverse gamma. When the drug model is used for model fitting, the available kinds of distributions are normal, lognormal, and constant.

When the drug model is used for trial simulation, the distribution allows the user to specify an evaluation frequency level, which is evaluated either continuously, whenever an event such as administering a dose or taking an observation occurs, periodically, once per subject, once per center, or once per trial.

A categorical distribution block represents a quantity that is known to be variable over time, and for which the number of possible different values is finite and small. The categorical distribution allows the same evaluation frequency levels as the continuous distribution.

A multivariate distribution block represents multiple quantities that are known to be variable over time. The evaluation frequency can be specified as above. The variable can be specified to be singly or jointly distributed in the same way as they can in the population block except that there are no sub-populations. It can be specified that the distribution should be generated by import from a file, as in the population block.

In the delay block, the output is equal to the input delayed by a time offset. Unlike an effect compartment block, which can also be used to introduce delay, the delay block does not utilize a differential equation. Thus, the delay block may be preferable in certain drug models, such as a pill that does not begin being absorbed until five minutes after ingestion.

The pharmacodynamic blocks include a linear block, an emax block, an indirect block, a discrete effect block, and an event block. In the linear block, the output is a linear function of the input. Thus, output Y=X*A+B where X, A, and B are inputs. In the emax block, the output Y=EMAX*C^Hill/(C^Hill+EC50^Hill), where C, EMAX, EC50, and Hill are inputs.

The emax block represents the most common model of how concentration causes an effect. As discussed previously, drugs bind to receptors on cells in order to cause effects. This binding of receptors is a chemical reaction, thus there is a rate at which the chemical binds and another rate at which the chemical unbinds, for each level of concentration. But because there is always an unbinding rate, the receptors will never be 100% bound by the drug, no matter what the level of concentration. Thus the effect of the drug approaches an asymptotic limit, the Emax, as the drug concentration next to the receptor sites increases.

The amount of concentration needed to obtain half the effect of this limit is called the EC50 of the drug: the effect concentration at 50% of the Emax. The EC50 is essentially an inverse measure of how effective the drug is, and is a commonly used method of specifying a drug's effectiveness. A user can specify the EC50 of the drug by using the emax block, and then wire the output of the emax block into a response block to connect the drug's effectiveness with an observable quantity. Note that the emax block represents a simple computation, so there is no differential equation associated with it.

The indirect block is somewhat like a combination of an emax block and an effect compartment block. Its input governed by an emax factor, and its output is a function of the amount in the block. Thus, the indirect block employs a differential equation.

The indirect block is commonly used to model the situation where the body generates a substance and the generation and elimination of that substance is controlled by a drug. This is common, for example, for neuroactive drugs. The indirect block implements one of four indirect response models. (1) stimulation of buildup (dY/dt=F*Kin-Y*Kout), (2) inhibition of buildup (dY/dt=(1-F)*Kin-Y*Kout), (3) stimulation of loss (dY/dt Kin-Y*F*Kout), and (4) inhibition of loss (dY/dt=Kin-Y*(1-F)*Kout). For each of the equations above, F=X/(X+EC50), and X, EC50, Kin, and Kout are inputs.

The discrete effect block is used to model a categorical response, such as a patient's answers to a questionnaire. Because different people who are in the same state chemically will give different answers, the discrete effect block should include a random element, which is preferably definable. Thus, P(Y>i)=L(X+A(i)), where Y can take one of n output values, 0 through n-1, and L is the inverse of a link function. Based upon the strength of the input, the probability of each particular output is increased or decreased in a manner defined by the link function. The inverse link functions L(x) include logit, probit, log log, complementary log log, linear, and signum (impulse). They are defined as follows:

TABLE-US-00001 logit: L(x) = exp(x)/(1 + exp(x)) probit: L(x) = NCD (x), where NCD is the gaussian normal cumulative distribution function log log: L(x) = exp(-exp(-x)) complementary log log: L(x) = 1 - exp(-exp(x)) linear: L(x) = if x < 0 then 0, else if x > 1 then 1, else x signum: L(x) = if x < 0 then 0, else 1

All of these functions monotonically increase from zero at minus infinity to one at plus infinity. Note that the signum function is a way of saying there is no randomness at all; the function is a simple threshold.

The event block simulates events that take place at unpredictable times, such as seizures. The block has a sampling interval, which is a length of time that it waits between sampling. When it samples, it determines if an event occurred during the prior sampling interval, or how many events occurred during the interval. User-code statements are added to the event block to specify actions to be taken upon each occurrence.

The block can be used in two ways, probability or hazard. When it is used in probability mode, it has a probability expression P. When it samples, it reports one occurrence with probability P, otherwise no occurrence. When it is used in hazard mode, it has a hazard expression H. When it samples, it determines the number of occurrences by evaluating a Poisson distribution. The mean of the Poisson distribution is the time integral of the H expression over the interval.

The other blocks include an expression block, an action-at-times block, a model variables block, and a procedure block. The expression block allows the user to specify the block's output to be a user-programmed expression of its input(s). The action-at-times block allows the user to specify actions to be performed at specific times in the simulation. User code statements specify the actions. The times are specified by user code expressions, and may also be random. This allows models to contain parameters that relate to the time of an event, such as time of urination, or time of entero-hepatic reflux. The model variables block allows the user to specify named variables that can be used either as model parameters, or as history-keeping variables, such as counters or disease-state.

The procedure block allows the user to specify differential equations, and functional variables. A differential equation consists of a named variable (also known as an integrator variable), an initial value expression for the integrator variable, and a rate expression for the integrator variable. A functional variable consists of a named variable (also known as a procedure variable), an initial value expression, and optional statements to set its value. The functional variable cannot be used to hold history. It is only a function of other variables constituting the state of the simulation, such as model variables and integrator variables.

As each variable is added to a procedure block, the variable becomes an output of the block. The only variables that may be set in a procedure block are the local procedure and integrator variables, although global variables can be referenced, and the local procedure variables are all non-static. These limitations are placed on the procedure block to avoid the problems that could otherwise be created by the user. For example, if a user were to change a global variable inside a procedure block, there may be too much opportunity for human error to introduce bugs into the trial simulation, possibly reducing the benefits of the invention.

In addition, a user is prevented from placing a differential equation within conditional code. If a user were to specify, inside a procedure block, a differential equation that is dependent on an if statement, this could make the drug model inaccurate. During a trial simulation, the value of each differential equation must be calculated at each time step for the simulation to work properly, and thus the calculation of a differential equation cannot be left up to the state of the program at run-time.

Referring again to FIG. 1, as each defined block 132 is added to and connected with the graphical drug model using the graphical user interface 124, the equations generator 128 creates the equations that correspond to the selected blocks and connections. In one embodiment, the equations generator 128 creates internal format statements, which are then displayed in a visible surface syntax in the equations window 108. This will be discussed in greater detail below. As discussed above, a number of the defined blocks 132 comprise user-programmable blocks 136. In order to implement these user-programmable blocks 136, a simple programming language is provided.

The programming language comprises a syntax of expressions and statements. Expressions represent values to be computed, and statements represent actions to be performed. Although a particular embodiment is described herein, those skilled in the relevant art(s) understand that multiple variations on the basic programming language are equally applicable.

In one embodiment, the statements include the following: (1) sequence=perform a sequence of statements, (2) if-then-else=perform statements conditionally, (3) call=call a Fortran subroutine, (4) assignment=compute a value and store it in a variable, and (5) differential equation=specify the rate of change of a variable.

In one embodiment, expression operators include the following: (1) expression grouping using "(..)", (2) unit specification using "{..}", (3) prefix operators including "-", ".not.", and "!" (having their standard meanings), (4) infix arithmetic operators including "**", "*", "/", "+" and "-" (having their standard meanings), (5) infix comparison operators including: ".ge.", "le." "ne." "eq." "gt.", and ".lt.", and also ">=""<=", "!=""<>", "==", ">", and "<" (having their standard meanings), (6) infix logical operators including ".and.", "&&", ".or.", and "II" (having their standard meanings), and (7) the conditional operator "x ? y: z" (where if x is true, return y, and otherwise return z).

In one embodiment, standard functions are provided, including the following: (1) "sqrt" for square root, (2) "In" for natural log, (3) "exp" for exponentiation, (4) "sin" for sine, (5) "cos" for cosine, (6) "atan2" for arctangent (full circle), (7) "floor" for greatest integer less than or equal to x, and (8) "abs" for absolute value. Random functions are also provided, including: (1) "unif" to compute a uniformly distributed random number, (2) "normal" to compute a normally distributed random number, and (3) "lognormal" to compute a lognormally distributed random number.

The provided functions may be used with any of the variable types, including: input ports, output ports, procedure variables, integrator variables, model variables, T, and bDropped. T is a variable representing time, and bDropped is a boolean variable indicating if a subject has been dropped out of a study. Additionally, various constants may be specified in various variable types, as is well understood in the relevant art(s), e.g., numeric constants such as 3, 3.1415926, 3e4, 3d4, 3d 4, 0.001d60, string constants such as `this is a string`, and named constants such as Male or Female. Notably, in one embodiment, string constants are only allowed to appear as arguments to subroutines.

FIG. 2B is an illustration showing a dynamic graphical user interface methodology as used in defining joint multivariate distributions according to one embodiment. A block properties window 250 is opened for a population block by a user, such as by double clicking on population block in a graphical drug model. The block properties window 250 shows the various population variables, including BodyWeight in a BodyWeight distribution section 252 and Age in an Age distribution section 254. The block properties window 250 also shows the interrelationships of the population variables, and allows editing of the distributions by clicking the edit buttons.

The interrelationships of the population variables are shown by the X's, or lack thereof, in the interrelation buttons 256. To interrelate BodyWeight and Age, all the user need do is click the interrelation button 258. This causes the BodyWeight and Age variable to become interrelated, and the block properties window 250 becomes the block properties window 260. In the block properties window 260, BodyWeight and Age are now shown to be interrelated in a BodyWeightXAge distribution section 262, and their joint multivariate distribution can be edited by clicking the appropriate edit button.

FIG. 2B demonstrates the principle of a dynamic graphical user interface, which is preferably used in all of the graphical user interfaces (GUIs). Everything about each GUI is variable. When the window size is increased, more options and/or buttons appear. When one button is clicked, more and/or less buttons may be presented. This dynamic interface is implemented using the principles of Differential Execution/Evaluation. For background information regarding Differential Execution/Evaluation, see the Appendix, which is a copy of the article entitled Differential Evaluation: a Cache-based Technique for Incremental Update of Graphical Displays of Structures, written by Michael R. Dunlavey, and published in Software--Practice and Experience, Vol. 23(8), pp. 871 893 (August 1993).

Differential Execution is used to implement the dynamic interfaces, or "dialogs", described above. As is known in the relevant art(s), a dialog box is a window that contains a number of "controls", which are child windows designed to solicit information from the user. Examples of controls are "edit controls", in which the user can enter textual information, "button controls" which look and act like labeled push buttons, and "static controls" which simply display some text for the user to read.

The usual method by which a programmer specifies the design of a dialog box is to create a textual description of the dialog box and its controls within a text file (typically called a "resource" file). An example of such a description is the following:

TABLE-US-00002 IDD1_NEW_STUDY DIALOG DISCARDABLE 0, 0, 251, 199 STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU CAPTION "New Study" FONT 8, "MS Sans Serif" BEGIN LTEXT "Available designs",IDC_STATIC,7,6,56,8 LISTBOX IDC1_LB_DESIGNS,7,16,124,90, LBS_NOINTEGRALHEIGHT | WS_VSCROLL | WS_TABSTOP GROUPBOX "Study Parameters",IDC_STATIC,135,13, 109,94 LTEXT "Treatment Arms:",IDC_1ST_TREATS,141,28, 54,8 EDITTEXT IDC1_EB_TREAT,195,26,28,14, ES_AUTOHSCROLL LTEXT "Periods:",IDC1_ST_PER,141,49,26,8 EDITTEXT IDC1_EB_PER,171,46,33,14,ES_AUTOHSCROLL CONTROL "Study has Lead-in phase", IDC1_CB_LEADIN,"Button",BS_AUTOCHECKBOX | WS_TABSTOP,141,68,94,10 GROUPBOX "Design Description",IDC_STATIC,7,110, 237,46 LTEXT "Static",IDC1_ST_DESC,15,121,222,32 CONTROL "Use &Wizard to guide in defining basic study",IDC1_CB_WIZARD,"Button", BS_AUTOCHECKBOX | WS_TABSTOP,7,162,176, 10 DEFPUSHBUTTON "OK",IDOK,7,179,50,14 PUSHBUTTON "Cancel",IDCANCEL,100,179,50,14 PUSHBUTTON "Help",ID_HELP,194,179,50,14 END

In general, the above description defines a dialog box called "New Study", specifies its size, and gives a list of its controls. LTEXT specifies a static control at a certain position and size relative to the dialog box, containing a left-justified string of text. EDITTEXT specifies an edit control at a certain position and size, in which the user can enter and/or edit a character string. PUSHBUTTON specifies a button control at a certain position and size, with a textual label, that the user can click in order to cause an action. Each control generally contains a string of 4 numbers, giving its offset relative to the upper left corner of the dialog box, and its width and height. It also typically contains a symbolic identifier, such as IDC1_LB_DESIGNS, ID_HELP, IDC.sub.--1ST_TREATS, that the remainder of the application can use to manipulate the controls of the dialog when it is used at run time. Controls also can contain additional "style markers" giving additional information about the appearance and behavior of the controls, such as ES_AUTOHSCROLL which means that the edit control having that style automatically scrolls horizontally as the user moves the cursor within the control.

Dialogs specified in this way are static in the sense that the size, position, contents, and visibility of the controls and of the entire dialog box are essentially fixed, and can only be altered at run time with a certain level of effort and skill on the part of the programmer. Dynamic dialogs, by contrast, allow nearly all aspects of the dialog and its controls to be variable in real time, with little or no effort on the part of the programmer. This allows a single dialog box to serve a much wider variety of needs.

The following example uses the C++ programming language to create dynamic dialogs, but any suitable programming language may be used. To specify a dynamic dialog, one writes a class for it, derived from the CDynDialog base class, and having a function called Contents( ); class CMyParticularDialog: public CDynDialog {public: void Contents( ); };

The Contents ( ) function is then written to specify the contents of the dialog. For example:

TABLE-US-00003 void CMyParticularDialog :: Contents(){ // give title, position, and size of dialog Dialog("My Title", 100, 100, 300, 200); // a static control Static(10, 10, 30, 9, SS_LEFT, "some text"); // an edit control Edit(10, 20, 30, 40, ES_MULTILINE, &sMyString); // a pushbutton control if (PushButton(10, 30, 30, 9, "Do Something")){ // write code in here to take some action that // will be performed when the button is pushed DD_THROW; } }

Thus, the Contents ( ) function is serving the same function as the resource script above, except that it is in the C++ language. The primary advantages of this approach are (1) everything in the dialog can be calculated at the time the dialog is created, such as size and textual content, (2) it is much more tightly integrated with the application data and it is not necessary to write code to move information in and out of the edit controls, and (3) it is not necessary for the controls to have symbolic identifiers, because the action code for the controls can be specified adjacent to the controls themselves.

In addition, the contents and attributes of the controls can be made to be variable, not just at the time of dialog creation, but in real time, with the proper programming of the underlying class. This is done by means of the technique called Differential Execution or Differential Evaluation. In this technique, any given procedure, such as the Contents ( ) function given above, can be executed repeatedly (typically 5 times/sec) in such a way that the subroutines that it calls can determine how their arguments may have changed since the prior execution and can effect incremental changes in what they are displaying. For example, the Static function specifies a static control to display a text string at a given position and size. On any execution, if the text string differs from what it was on the prior execution, the static function can update the text string on the screen. If the size or position changes, then the Static function can move the text string on the screen. The same reasoning applies to all controls and to the dialog box itself The phrase that the subroutines "maintain" their visible ma