- funded by IMI-JU
- 01 March 2011 - 31 August 2016
- 11 EFPIA members
- 10 Academia and 5 SME's
- Total cost € 23,032,609
MDL is a human writeable and human readable language designed to describe pharmacometric models. It is intended to be largely agnostic about the choice of target tool. MDL should facilitate clear and unambiguous definition of models, with information conveyed in a consistent manner to the PharmML representation and onwards to the target software specific code.New modelling applications may take advantage of the standard without having to re-invent how to describe common modelling processes.
An important concept in the MDL is the separation of data, parameter, model and task descriptions into independent objects. This supports reuse and interchange of the objects which define each component of the model and related modelling task. This independence means that model objects stored in the DDMoRe Model Repository may be combined with user objects outside the repository e.g. a Model Object, Parameter Object and a Task Properties Object may be taken from the Repository and combined with user defined Data. This may be useful when a user wishes to assess whether a library model is predictive for their dataset, as a preliminary step before further model refinement. Modellers will have experience of data files being separate from other components of a model and its task but the equivalents of the other MDL modelling objects (model, parameter, task properties) in existing modelling languages are typically defined in a single monolithic text file. The correspondence between the MDL objects and the target languages has been publicly explained and demonstrated (http://www.page-meeting.org/default.asp?abstract=2712).
Several languages have been created to support modelling and simulation (M&S) activities. Examples of widely used languages are NONMEM (NMTRAN), Monolix (MLXTRAN), BUGS and MATLAB. However, none are shared, creating difficulties for comparison and integration. Many tools have overlapping functionality, and so the choice of one tool over another is driven largely by user preference, availability of tools, experience of the analyst and whether there is sufficient experience readily available to the analyst to provide support and advice on model building techniques specific for the tool in question. Considerable effort is currently required when moving the model from one software tool to another, as models always have to be re-coded in the target software tool language, by hand.
The aim of MDL is that the user writes the model (Model Object) once, then uses this model in the tools they require (and have available) in order to complete their M&S tasks, without any tool specific recoding. This interoperability is a core deliverable of the DDMoRe project.
As described above, MDL provides the user focused layer of model description. This facilitates user understanding and model sharing between analysts. PharmML provides the software interchange standard within DDMoRe to facilitate the transfer of models between target tools by ensuring that all of the necessary information about the model is captured and can be translated automatically to any given target tool that has an appropriate PharmML converter. The Standard Output object (SO) standard provides a consistent format for M & S results and outputs. Its availability as an object within R provides interchange and integration between existing R packages for M & S tasks within the DDMoRe infrastructure.
MDL, PharmML and the SO are the basis for interoperability which is one of the core deliverables of the DDMoRe project.
Very few models can be retrieved from a repository or library, be fit to any given set of data and pronounced valid for inference without further assessment or changes. Thus, the process of fitting models to data, assessing the fit through model diagnostics is an iterative process, culminating in selecting the model which is parsimonious and fit for its purpose in the inferential step – decision making, making predictions for future populations of interest, selecting dose or dosage regimen etc. The combination of features in MDL and the “ddmore” R package facilitates that process. MDL’s structure makes changes to data, models, parameters, tasks transparent – making it clear exactly which elements are changing and which are constant across steps. Using an R script to define M & S task workflow facilitates an unbroken workflow for a given model and dataset, from exploratory analysis, estimation, diagnostics and simulation across a variety of tools without having to recode the model.
The first public release includes a User Guide for MDL. These documents describe the component Model DescriptionLanguage (MDL) and the associated R package "ddmore".
The MDL User Guide gives a comprehensive, structured description of each component of language. Readers should be aware that they are not teaching documents but are intended to specify the language and how it is implemented within the MDL IDE (Integrated Development Environment). The MDL IDE is the primary tool for users to create and edit MDL code. The MDL IDE translates MDL to PharmML and through the R console and R IDE, define and execute workflow tasks with the MDL model.
A set of MDL example models (Use Cases) is provided with the Interoperability Framework Standalone Execution Environment (SEE). Each example includes an associated R script showing example workflow with the Use Case model.
MDL is used to express information about a model that can be translated to a variety of different software targets via PharmML. The current Interoperability Framework SEE supports interoperability with NM-TRAN/NONMEM and MLXTRAN/Monolix. A future version will also include support for WinBUGS, Matlab and R.
You are encouraged to examine MDL examples using the MDL IDE. You may wish to try converting existing NM-TRAN scripts to MDL using the using the nt2mdl tool or using the as.mdl function in the ddmore R package. Conversion using this tool does not guarantee valid MDL, but it can be used to provide a starting point for writing your own models in MDL within the MDL-IDE. You might also try writing MDL scripts from scratch and test how well they can be converted to NM-TRAN by the MDL IDE.
Comments are sought at this stage, using the DDMoRe Forum, about the current structure of the MDL and how it might be enhanced to support existing and future modelling application software packages.