The main objective of PKBugs is to make model specification as simple as possible, thus making MCMC methods easily accessible to practitioners in population PK/PD. To achieve this, we use the same format for data entry as NONMEM (Beal & Sheiner, 1992), that is a rectangular data file where each row (or record) corresponds to an event (e.g. dose, observation) in a chronological series, and each column has a specific meaning (e.g. time = event time, amt = dose received) and is referred to as a data item. In short, model specification entails: (i) data item declaration; (ii) data loading; and (iii) basic user input via simple dialogue boxes and menu commands.
The figure below (click to view full-size) is a screen-shot from the PKBugs model specification process. The example shown pertains to the drug gentamicin (this example data set is packaged as part of the software). Two files/documents are shown: the top file simply contains the names of the data items that appear in the data set and the lower file is the data set itself. These are loaded into the system via the PKBugs menu.
In the above example, the following standard data items (i.e. data items that the PKBugs system recognises) appear:
There are numerous other standard data items that, together with the above, can be used to communicate a wide variety of models to the PKBugs system. These are all described in detail in the documentation that comes with the software. All non-standard data items, e.g. apgar and creat.inv above, are assumed to be potential covariates.
Various 'commands' can be assigned to data items. For example, aliases may be assigned to standard data items, e.g. amt = dose. Also, non-standard data items (i.e. covariates) may be declared as categorical, e.g. apgar = cat, or they may be 'centred', e.g. creat.inv = centred.
After the data item names and the data set itself have been loaded into PKBugs, the two dialogue boxes shown in the example above are used to specify: the number of compartments in the structural model; the residual error structure; the covariate model; and appropriate prior distributions for the population parameters.
The top dialogue box allows a choice of 1, 2, or 3 compartments, with either normal or log-normal residuals. If the user requires a greater choice then he/she should use the "print model" option (see below), which allows almost unlimited flexibility regarding modelling assumptions. The lower dialogue box allows the user to specify the covariate model, e.g. apgar, sex, creat.inv, and pca are selected for the CL parameter in the above example. Selected covariates are incorporated into the model in a log-linear fashion (again, if the user requires more flexibility then he/she should use the "print model" option -- see below). This dialogue box also requests initial estimates for the population parameters. When the Done command button is pressed, PKBugs generates a file (on-screen) containing suggestions for the prior specifications -- these are based on the given initial estimates. The user may edit these to his/her liking before 'confirming' them by loading them into the system, via the PKBugs menu.
Once the model is fully specified, it may either be 'compiled' and analysed immediately, or the equivalent WinBUGS code may be generated using the "print model" option.
The "print model" option (select Print model from the PKBugs menu) generates concise WinBUGS code for the specified model. This allows the user almost unlimited flexibility regarding modelling assumptions. In order to make the code concise, and thus easy to modify and/or restructure, we developed the General PK Model Component. With PKBugs installed on your machine, the General PK Model Component becomes part of the BUGS language, as do many other PK model components. Irrespective of the drug's characteristics and the complexity of the dosing history, the PK model is specified simply by using the syntax "pk.model(arguments)". The required arguments include: a matrix describing the relevant individual's dosing history; the individual's PK parameter vector; the assumed number of compartments; and the appropriate event time. Click on the image below to see concise code for the gentamicin example.
The General PK Model Component combines doses of arbitrary types, taking into account the relative bioavailabilities of different formulations of the drug.
As mentioned above, use of the General PK Model Component allows us to write the equivalent WinBUGS code concisely. This means that the code is easy to modify and/or restructure. For example, it is straightforward to introduce another 'level' into the hierarchical model for conducting an inter-subject/inter-occasion variability analysis (Karlsson & Sheiner, 1993; Lunn & Aarons, 1997), or to replace normality assumptions with Student-t assumptions to provide robustness against outlying observations/individuals. We can also incorporate time-varying covariates and/or complex residual error structures into the model. However, the General PK Model Component was designed from such an abstract perspective that we are largely unaware of its potential uses and limitations!
|Last Updated December 2004|
Site maintained by:
MRC Biostatistics Unit,
Institute of Public Health,
University Forvie site,
Cambridge CB2 0SR