You are here

Frequently asked questions

These are the most frequently asked questions.

If you have a question, and your question is not in this list, please use our contact form.

Interoperability Framework

Licenses are required if you wish to use NONMEM, Monolix or Simulx within the Interoperability Framework.

For NONMEM you can obtain a temporary licence from ICON, if you don’t already have one. If you do already have a NONMEM license, you are allowed to use it within the Interoperability Framework under the conditions specified in the Installation Guide. The process for requesting and installing the license is described in Section 8 and Section 9.1 of the Installation Guide. The temporary license obtained from ICON will expire after approx. 45 days of use, but you can then apply for a full commercial license by sending an email request to IDSSoftware@iconplc.com.

For Monolix and Simulx, a temporary license is included within the Interoperability Framework. When launching the Interoperability Framework, you may be prompted to enter an “Activation Key'' (for LIXOFT - Simulator). If so, you will need to enter the location of the Lixoft license file (\Monolix432s\bin\Monolix_mcr\runtime\config\system\access\ddmore.lic). The temporary license will expire after a few weeks, but you can then apply for a full commercial license by sending an email request to license@lixoft.com.

No other licenses are required.

The DDMoRe Interoperability Framework is an integrated infrastructure to enable efficient exchange and integration of models across modelling languages, existing and new tools.
It is built on the system-to-system interchange standard provided by the Pharmacometrics Markup Language (PharmML), facilitating the re-use of models from the DDMoRe Model Repository. The user will interact with the MDL-IDE (Integrated Development Environment), a graphical user interface and editor supporting the Model Description Language (MDL), a language used by modellers to specify models.

In order to get the integration benefits of the Interoperability Framework, users have to work within the framework – when editing models in MDL and when executing tasks with these models.

The DDMoRe R package can in principle also be used in R scripts outside of the Interoperability Framework, but several of the functions in the package rely on services that are only available within the system, so it may be of limited use.
The converter toolbox for converting models to and from PharmML can also be used outside of the Interoperability Framework via a command-line interface.

The Interoperability Framework also offers advantages to users only using a single target tool for estimation. Estimation tasks in e.g. NONMEM can be managed from within an R script by using the functions available in the DDMoRe R package, which means that an entire workflow (from data preparation, through estimation, to model diagnostics, VPC and bootstrap) can be written and executed end-to-end with the framework.

An overview of the features of the Interoperability Framework is available at http://www.ddmore.eu/product/interoperability-framework. The overview shows which features and target tools are supported.
Tutorial videos showing the functionality of the Interoperability Framework are available at http://www.ddmore.eu/tutorials.

With the Interoperability Framework, you can specify models in MDL and with these models you can run tasks such as estimation (in NONMEM, Monolix and WinBUGS), graphical model diagnostics (in R or Xpose), VPC (in PsN), bootstrap (in PsN), simulation (in SimCyp and simulx), and optimal design (in PFIM or PopED) – all from within a single R script – by using the R functions provided in the DDMoRe R package and the integration services provided by the Interoperability Framework.
A more detailed overview of the features of the Interoperability Framework is available at http://www.ddmore.eu/product/interoperability-framework

The Interoperability Framework is available for download at http://www.ddmore.eu/product/interoperability-framework. Please follow the installation instructions provided.

Licenses are required if you wish to use NONMEM, Monolix or Simulx within the Interoperability Framework.

For NONMEM you can obtain a temporary licence from ICON, if you don’t already have one. If you do already have a NONMEM license, you are allowed to use it within the Interoperability Framework under the conditions specified in the Installation Guide. The process for requesting and installing the license is described in Section 8 and Section 9.1 of the Installation Guide. The temporary license obtained from ICON will expire after approx. 45 days of use, but you can then apply for a full commercial license by sending an email request to IDSSoftware@iconplc.com.

For Monolix and Simulx, a temporary license is included within the Interoperability Framework. When launching the Interoperability Framework, you may be prompted to enter an “Activation Key'' (for LIXOFT - Simulator). If so, you will need to enter the location of the Lixoft license file (\Monolix432s\bin\Monolix_mcr\runtime\config\system\access\ddmore.lic). The temporary license will expire on February 1st 2016, but you can then apply for a full commercial license by sending an email request to license@lixoft.com.

No other licenses are required

The SEE has been formally validated by Mango Solutions on the following platform: Windows 7 (32-bit or 64-bit) with SP1 or above. Additionally, during ad-hoc testing, DDMoRe Consortium members outside of Mango Solutions experienced no adverse effects on the following platforms: Windows XP (32-bit or 64-bit), Windows 8 (32-bit or 64-bit), Windows 10 (64-bit), and any non-Windows operating system running a correctly configured Virtual Machine (e.g. VirtualBox) with one of the above Windows versions installed.

For Windows 7, which is the platform on which the Interoperability Framework has been validated, you can check this by right-clicking ‘My Computer’ – In the information window that appears, under ‘System’, you can see the ‘System type’, which will say ’32-bit Operating System’ or ’64-bit Operating System’. If you are running on different version of Windows, please consult an IT representative.

Through a series of pilots within the DDMoRe project we have demonstrated how the IOF can be integrated within high-performance corporate IT environments, in order to use the computing power and job scheduling/load balancing features available therein. We have demonstrated at one industry partner that the IOF can be installed on a Windows laptop (GUI and R on local client) that connects to a high-performance Linux server with job scheduling in LSF for estimation in NONMEM (remote server execution). At a number of industry partners we are working on an IOF Linux server installation (GUI and R on remote server) that connects to a high-performance Linux grid with job scheduling implemented in Univa/SGE for estimation in Monolix and NONMEM (remote grid execution), which will be finalized by the end of August 2016.

MDL does not support the equivalent of “IGNORE” characters or “IGNORE” and “ACCEPT” Boolean clauses to subset data prior to analysis. The data passed to the target software must be only the data to be used in estimation. It is good practice to subset data for analysis using a scripting language, rather than changing data records by hand. We suggest that users use R commands in their script to subset, filter and manipulate data prior to analysis, write the data for analysis to file and then modify the MDL Data Object to reference the appropriate source file in the SOURCE block.
For legacy data, we recommend using the “ignored” function within the “metrumrg” R package (https://r-forge.r-project.org/projects/metrumrg/). This function reads a NONMEM control stream and creates a TRUE/FALSE logical flag for whether the records meet IGNORE and/or ACCEPT criteria specified in the NMTRAN code. This will allow the user to identify which data records have been dropped by NONMEM. Filtering on the original data based on these criteria will allow them to create a dataset ready for analysis with MDL.

This is due to the fact that the R->MDL conversion is done via the JSON format. It is also related to the automatic refresh of the Project Explorer view. This refresh occurs periodically, so it may occur exactly at the moment when the '.json' file is written and so it would become visible. The bottom line is that it will not cause any problems and if it is seen it will shortly be replaced with the '.mdl' equivalent model.

The warning messages you are seeing from the estimate() function, actually come from the component that parses your target tool results (from Monolix or NONMEM) into the standard output object you are seeing in R. You can find an explanation of some of the messages in the documentation available in the ‘docs’ sub-folder of the root folder, wherein the framework is installed.

The DDMoRe consortium was founded early in 2011 by a group of enthusiastic EFPIA partners, academics and SMEs across Europe. Its project aims to establish a set of standards that allow the efficient exchange and re-use of knowledge between all stakeholders in the field of drug, disease modelling and simulation. The set of standards will be designed both for model and workflow encoding, as well as for storage and transfer of models and their associated metadata.

All products delivered at 31st of August 2016 are for free to everybody

All previous newsletters can be obtained from www.ddmore.eu via the following link http://www.ddmore.eu/content/newsletter

The end date of the project is 31st of August 2016

Just take three minutes to watch our elevator pitch

There are 26 partners involved in the project all names and details are given at http://www.ddmore.eu/content/ddmore-project-members

Pharmacometric Workflow

A "pharmacometric workflow" can be thought of as what you might write down in a lab book, in which you record what you did, what you used, how you generated new artefacts (like outputs or plots), and your thought processes behind any decisions that you took during your analysis.
We are developing a tool to capture this information, and to visualize the interdependencies between components of model-based analyses ("provenance"), as well as providing a set of tools to facilitate reporting (run records), audit trailing, and versioning. In addition to supporting these activities, this information will allow the analyst to re-execute complete workflows or parts of a workflow to bring everything "up to date" should something change earlier up the chain.
Pharmacometric Workflow provides efficiency improvements from task initiation to completion with Good Modelling Practice standards. In the ideal situation, execution of a complete pharmacometric workflow could be achieved by just “one click”.

An ontology is a specification of types, properties and the interrelationships of entities that exist in a particular domain.
In DDMoRe, we have chosen the PROV Ontology (PROV-O, http://www.w3.org/TR/prov-o/) developed by the W3C to capture the information required to represent a Pharmacometrics Workflow.
It provides a set of classes, properties, and restrictions that can be used to represent and interchange provenance information generated in different systems and under different contexts. It can also be specialized to create new classes and properties to model provenance information for different applications and domains.

The first version developed will be desktop based, and so will not be available on mobile devices. However, the visualisation of a workflow will be developed with web compatible technologies and so could be viewed with a mobile browser, in principle.

The workflow tool is being developed with flexibility and simplicity in mind. This being said, the key targets for interoperability with this tool are the other components of the DDMoRe ecosystem. It may be that the workflow tool is compatible with other "workflow" products through its use of standardized technology, but our resources are insufficient to make this a development priority.

Audit trial, documentation, automation and more time to develop science

Model Repository

Thanks to the unique combination of contributors from academy and EFPIA, various disease and therapeutic areas relevant for drug development will be covered by the model set of the repository.
The contributors committed to demonstrate the features to be offered by the DDMoRe framework: the models published before the 11th public release were only a first test to serve as a proof of concept.
Now that the new version of the product is about to be published, the content building on the repository undergoes its real initial phase. As a first step about 50 models will be made available to the public during the second half of December 2015. Constant updates from the other DDMoRe partners and the public will allow this initial set of published models to grow at a very high rate.

The content build for the library is supported and driven by the various academic and EFPIA partners of the consortium. These partners committed to build a space for sharing as well as improving knowledge in PK/PD Modelling & Simulation and Pharmacometrics.

You can submit your model in any modeling language, but only PharmML and MDL will allow you to use the DDMoRe framework and the Model Repository features to their full extent and leverage your contribution.
A lot of relevant information and files can be shared on the repository. For more information please visit the Model Repository website. http://repository.ddmore.eu

You can always upload your models and share them with your colleagues without any limitation. The history of the model revisions will be kept and displayed on the repository interface to ease the follow-up.
To maintain a minimal standard of quality and build knowledge on the Repository, the publication mechanism as been thought such that a model should be linked to a peer-reviewed or congress publication to be made public.

The Model Repository can be accessed through a tablet like any regular website.

Upload and download is immediate. You can share your models with selected users right after downloading. To share your models with the public they will have to fulfill the published minimal requirements

Model Certification

The internal review group is a group of DDMoRe contributors which task is to review the models with respect to minimal requirements prior to model publication. These minimal requirements are mainly technical. In the future, the external reviewer group will be made out of experts from various PK/PD Modelling & Simulation and Pharmacometrics fields that will deliver the DDMoRe certification. This certification will be granted upon user request and if the submitted model fulfills higher-level requirements.

Exchange Standards

When installing the Interoperability Framework, it comes with a UseCases project folder pre-installed in the workspace. Within this folder are examples of models in MDL and associated R scripts showing how to use these models for typical modelling tasks.

For NONMEM, a tool is available for translating NMTRAN code into MDL. The tool is available athttp://nmtran-to-mdl.mango-solutions.com/. Please, read the help documentation since some additional information, and certain NMTRAN structure is required to obtain a valid MDL. Alternatively, you can use the tool to generate a template that you can further modify within the Interoperability Framework.

Experienced modellers, who apply several different tools in their work, would want to learn MDL to get the benefit of not having to transcode models for use in different tools or for different purpose.
Beginners or less experienced modellers would want to learn MDL, because this will allow them to work with several different tools without having to learn several different languages.

The MDL is better than existing languages in the sense that it allows models to be specified in the same language, regardless of the target tool to be used for a given task (e.g. estimation), and regardless of whether the model is intended to be used for estimation, simulation, or optimal design, or all of the above. No existing language today allows this.

The MDL has been designed to allow users to specify models in the same language, regardless of the target tool they prefer to use for a given task (e.g. estimation), and regardless of whether they intend to use the model for estimation, simulation, or optimal design. This eliminates the transcoding needed today when using a model in a different tool or for a different purpose.

DDMoRe has developed two new language standards:
· MDL http://www.ddmore.eu/timeline/mdl, the Model Description Language, to be used by modellers for specifying models.
· PharmML http://www.ddmore.eu/timeline/pharmml-06 the Pharmacometrics Markup Language, to be used for system-to-system interchange of models within the Interoperability Framework, and for annotating models in the DDMoRe Model Repository http://www.ddmore.eu/product/model-repository.