# PK-Sim Database Description

## Introduction

PK-Sim uses an [SQLite](https://www.sqlite.org/index.html) database to store data models and templates. In this part of the developer documentation we will present this database with a thorough description of its structure and tables.

More specifically, in the PK-Sim DB, we store:

* Structural models for PBPK modeling of small and large molecules:
* Anatomical and physiological parameters in different animal species and human populations for **healthy** individuals
  * For details regarding parameterization of **diseased** individuals please refer to [tab\_population\_disease\_states](#tab_population_disease_states).
* Templates for small and large molecules.
* Templates for optional processes like
  * Metabolizing pathways
  * Different active transporter types (influx, efflux, bidirectional)
  * Protein binding partners
* Templates for various administration routes and formulations
* Prediction models for
  * Tissue partition coefficients
  * Cellular permeabilities
  * Intestinal permeability
* Templates for events (meals etc.)

The database can be found in the [PK-Sim repository under **src/Db/PKSimDB.sqlite**](https://github.com/Open-Systems-Pharmacology/PK-Sim/blob/develop/src/Db/PKSimDB.sqlite).

### DB Schema Diagrams

For this documentation segment, database schema diagrams were created using the [SchemaCrawler](https://www.schemacrawler.com/). You can find a short description of how to install and use the *SchemaCrawler* for creating schema diagrams [here](https://github.com/Open-Systems-Pharmacology/developer-docs/wiki/Using-SchemaCrawler-for-creating-of-database-schema-diagrams).

## General remarks

When a database value describes a numeric property of a quantity (e.g., parameter value, allowed value range, etc.), the value is always stored in the **base unit of the dimension of the quantity**.

Check the [OSP Dimensions Repository](https://github.com/Open-Systems-Pharmacology/OSPSuite.Dimensions/blob/master/OSPSuite.Dimensions.xml) to see what the base unit of a dimension is!

Some of the common properties used in many tables:

* **display\_name** The name of the entity to be used in the UI in PK-Sim.

  NOTE: MoBi does not support the "display name" concept, so all entities are displayed with their internal name. Also within a model all objects are stored with their internal name. It is therefore advisable to keep the display name the same as the internal name. Exceptions are e.g. special characters like "\*", "|" etc. which cannot be used in internal names.
* **description** Longer description of the entity, which is displayed as a tooltip in PK-Sim and can be edited in MoBi.
* **sequence** Used to sort objects in the UI (unless another sorting algorithm applies, e.g. alphabetical).
* **icon\_name** Defines which icon is used for the entity.

  If not empty: the icon with the given name must be present in the `OSPSuite.Assets.Images`
* {**min\_value**, **min\_isallowed**, **max\_value**, **max\_isallowed**} specifies the allowed range of values for a numeric quantity.
  * **min\_isallowed** and **max\_isallowed** define whether the corresponding bounded value range is open or closed.
  * **min\_value** can be empty. In this case the lower bound is `-Infinity`. The value of **min\_isallowed** will then be ignored.
  * **max\_value** can be empty. In this case the upper bound is `+Infinity`. The value of **max\_isallowed** will then be ignored.

Boolean values are always represented as **integers restricted to {0, 1}**.

:grey\_exclamation: Before renaming or removing basic entities (parameters, containers, observers): you should always **check if the modified entity is explicitly used by its name in PK-Sim or in the OSPSuite.Core**. If so, further code changes are required to reflect the database change! In some cases, the database objects that appear to be unused (when looking only at the database) are actually used in PK-Sim to create objects on the fly.

## Overview diagrams

Each of the following subsections focuses on one aspect and shows only a **subset** of the database tables relevant to that topic. The last subsection shows the complete schema with all tables.

### Containers

A *container* is a model entity that can have children. In the context of PK-Sim, everything except parameters and observers is a container.

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-6da772ef1e650d0637cc6827bddf20901ff420b8%2Foverview_containers.png?alt=media)

#### tab\_container\_names

Describes an abstract container (e.g. "Plasma"), which can be inserted at various places in the container structure defined in [*tab\_containers*](#tab_containers).

* **container\_type** is used, for example, to map a container to the correct container class in PK-Sim.
* **extension** is not used by PK-Sim and is only useful for some database update scripts.
* **icon\_name** defines which icon is used for a container.

There are some "special" containers defined in *tab\_container\_names* that are not used in the container hierarchy defined in [*tab\_containers*](#tab_containers). These containers are only used for **referential integrity when defining some relative object paths** (see the [Formulas](#formulas) section for more details).

#### tab\_container\_types

Defines available container types.

#### tab\_organ\_types

Classifies containers of type `ORGAN`. This classification is used in PK-Sim to group organs in different views (e.g. *Tissue Organs* vs. *Vascular System* vs. *GI Tract* etc.).

* **container\_type** is always set to "ORGAN".
* **organ\_name** is the name of the organ.
* **organ\_type** can be one of the values defined in [enum OrganType](https://github.com/Open-Systems-Pharmacology/PK-Sim/blob/develop/src/PKSim.Core/Model/OrganType.cs).

#### tab\_containers

Defines the container hierarchy and includes **all possible containers** which can appear in a model. When a model is created, some containers are filtered out based on the information in [*tab\_model\_containers*](#tab_model_containers) and [*tab\_population\_containers*](#tab_population_containers) (s. below)

* Each container within a hierarchy is identified by the combination `{container_id, container_type, container_name}`.
  * `container_id` is unique across all containers. In principle, it would be sufficient to use only the *container id* as the primary key. Container type and container name have been included in the primary key for convenience (e.g. when querying data from other tables, it is not always necessary to include *tab\_containers* and *tab\_container\_names* etc.).
* Each container can have a parent container defined by the combination `{parent_container_id, parent_container_type, parent_container_name}`.
  * Containers that appear at the top level of the *Spatial Structure* are defined as children of the special `ROOT` container. The `ROOT` container itself has no parent.

    | container\_id | container\_type | container\_name    | parent\_container\_id | parent\_container\_type | parent\_container\_name |
    | ------------- | --------------- | ------------------ | --------------------- | ----------------------- | ----------------------- |
    | 146           | ORGANISM        | Organism           | 145                   | SIMULATION              | ROOT                    |
    | 777           | GENERAL         | Neighborhoods      | 145                   | SIMULATION              | ROOT                    |
    | 1026          | GENERAL         | MoleculeProperties | 145                   | SIMULATION              | ROOT                    |
    | 4205          | GENERAL         | Events             | 145                   | SIMULATION              | ROOT                    |
  * Top containers of other building blocks (Passive Transports, Reactions, Events, Formulations, ...) are all defined as containers without a parent.
* **tab\_containers.visible** defines if a container is shown in PK-Sim in hierarchy view (TODO rename column to **is\_visible**).
* **tab\_containers.is\_logical** defines if a container is *physical* or *logical* (s. the [OSP documentation](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/spatial-structures-bb) for details).

#### tab\_container\_tags

Describes which additional tags are added to a container.

* the **name** of a container is always added as a tag programmatically and does not need to be added here.

#### tab\_neighborhoods

Defines 2 neighbor containers for each neighborhood of a spatial structure

* There are no rules or restrictions as to which of 2 adjacent containers must be defined as the first and which as the second container. For example, passive transports are defined by the container criteria of their source and target containers, and changing the first and second neighbour containers does not affect the later creation of the transport. Care should only be taken when using the keywords FIRST\_NEIGHBOR and SECOND\_NEIGHBOR in the formulas.
  * Even in the latter case, swapping neighbors may not be critical. E.g. if both neighbor containers have **the same parent container** and the formula uses the path `FIRST_NEIGHBOR|..|Parameter1`, then swapping the formula path with `SECOND_NEIGHBOR|..|Parameter1`would result in the same formula, because F`IRST_NEIGHBOR|..` and `SECOND_NEIGHBOR|..` both point to the same container, making the formula invariant with respect to neighbor switching.
  * But if the formula refers e.g. to `FIRST_NEIGHBOR|Parameter1` - then the neighbor order is relevant.

#### tab\_population\_containers

Defines which containers are created in individual/population building blocks in PK-Sim. For each population, this is a subset of the containers defined in [*tab\_containers*](#tab_containers).

#### tab\_model\_containers

Defines which containers **can** be included into the final model. Whether a container is included into the model is estimated based on the value of the column **usage\_in\_individual** as following:

* if `usage_in_individual = REQUIRED`
  * if the container is available in the individual/population building block used for the model creation: container is added to the model
  * otherwise: error, model cannot be created
* if `usage_in_individual = OPTIONAL`
  * if the container is available in the individual/population building block used for the model creation: container is added to the model
  * otherwise: container is NOT added to the model
* if `usage_in_individual = EXTENDED`
  * container is added to the model in any case
  * containers of this type usually should not be defined in [*tab\_population\_containers*](#tab_population_containers)

### Processes

*Processes* are defined as containers with `container_type="PROCESS"` and must be inserted into [*tab\_container\_names*](#tab_container_names) first; once done they can be inserted into [*tab\_processes*](#tab_processes) and further process-specific tables.

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-6fca65d89a8fad63c9af62695813ad91f3976bd1%2Foverview_processes.png?alt=media)

#### tab\_processes

Contains the following information about a process:

* **template** defines whether a process is always added to the selected model or only on demand.
  * For example, all passive transports or FcRn binding reactions in a protein model have `template = 0`
  * For example, active transports or metabolization reactions which are added only if the corresponding process was configured in a simulation in PK-Sim have `template = 1`
* **group\_name** is used to identify where (in which building blocks or simulations) the processes are used in PK-Sim.
  * Processes with the **parent** group *COMPOUND\_PROCESSES* are templates for active processes (active transport, specific binding, elimination, metabolization, inhibition, induction, ...) used in the compound building block of PK-Sim.
  * Processes with the group *APPLICATION* are application transports.
  * Processes with the group *INDIVIDUAL\_ACTIVE\_PROCESS* are templates for *active transports*, used in an *Expression Profile* building block. These templates have no parameters and are further specified in [*tab\_transports*](#tab_transports) (s. below).
  * Processes with the group *PROTEIN* describe *production* and *degradation* of proteins (enzymes, transporters, binding partners).
  * Processes with the group *SIMULATION\_ACTIVE\_PROCESS* describe the processes which are created in a simulation from both compound process template and individual (expression profile) process template.
  * Processes with the group *UNDEFINED* are processes where the group is not relevant (typically all *passive* processes).

    | GROUP\_NAME                     | PARENT\_GROUP       |
    | ------------------------------- | ------------------- |
    | ACTIVE\_TRANSPORT               | COMPOUND\_PROCESSES |
    | ACTIVE\_TRANSPORT\_INTRINSIC    | COMPOUND\_PROCESSES |
    | APPLICATION                     |                     |
    | ENZYMATIC\_STABILITY            | COMPOUND\_PROCESSES |
    | ENZYMATIC\_STABILITY\_INTRINSIC | COMPOUND\_PROCESSES |
    | INDIVIDUAL\_ACTIVE\_PROCESS     |                     |
    | INDUCTION\_PROCESSES            | COMPOUND\_PROCESSES |
    | INHIBITION\_PROCESSES           | COMPOUND\_PROCESSES |
    | PROTEIN                         |                     |
    | SIMULATION\_ACTIVE\_PROCESS     |                     |
    | SPECIFIC\_BINDING               | COMPOUND\_PROCESSES |
    | SYSTEMIC\_PROCESSES             | COMPOUND\_PROCESSES |
    | UNDEFINED                       |                     |
* **kinetic\_type** is used for the mapping `{Compound process template, Individual process template} ▶️ Simulation process`

  Example: active transports

  * for the active transports there are currently 2 compound templates:

    | process                       | group\_name       | kinetic\_type |
    | ----------------------------- | ----------------- | ------------- |
    | ActiveTransportSpecific\_Hill | ACTIVE\_TRANSPORT | Hill          |
    | ActiveTransportSpecific\_MM   | ACTIVE\_TRANSPORT | MM            |
  * there are different individual active transport templates - specified by their source and target (Interstitial<=>Intracellular, Interstitial<=>Plasma, Blood Cells <=> Plasma etc.) (kinetic type is not specified on the individual building block level and thus is set to "*Undefined*")

    | process                                         | group\_name                 | kinetic\_type |
    | ----------------------------------------------- | --------------------------- | ------------- |
    | ActiveEffluxSpecificIntracellularToInterstitial | INDIVIDUAL\_ACTIVE\_PROCESS | Undefined     |
    | ActiveInfluxSpecificInterstitialToIntracellular | INDIVIDUAL\_ACTIVE\_PROCESS | Undefined     |
    | ActiveEffluxSpecificInterstitialToPlasma        | INDIVIDUAL\_ACTIVE\_PROCESS | Undefined     |
    | ActiveInfluxSpecificPlasmaToInterstitial        | INDIVIDUAL\_ACTIVE\_PROCESS | Undefined     |
    | ...                                             | ...                         | ...           |
  * In the simulation

    * `ActiveTransportSpecific_MM (Compound) + ActiveEffluxSpecificIntracellularToInterstitial (Individual) ▶️ ActiveEffluxSpecificIntracellularToInterstitial_MM (Simulation)`
    * `ActiveTransportSpecific_Hill (Compound) + ActiveEffluxSpecificIntracellularToInterstitial (Individual) ▶️ ActiveEffluxSpecificIntracellularToInterstitial_Hill (Simulation)`

    | process                                               | group\_name                 | kinetic\_type |
    | ----------------------------------------------------- | --------------------------- | ------------- |
    | ActiveEffluxSpecificIntracellularToInterstitial\_Hill | SIMULATION\_ACTIVE\_PROCESS | Hill          |
    | ActiveEffluxSpecificIntracellularToInterstitial\_MM   | SIMULATION\_ACTIVE\_PROCESS | MM            |
    | ActiveInfluxSpecificInterstitialToIntracellular\_Hill | SIMULATION\_ACTIVE\_PROCESS | Hill          |
    | ActiveInfluxSpecificInterstitialToIntracellular\_MM   | SIMULATION\_ACTIVE\_PROCESS | MM            |
    | ActiveEffluxSpecificInterstitialToPlasma\_Hill        | SIMULATION\_ACTIVE\_PROCESS | Hill          |
    | ActiveEffluxSpecificInterstitialToPlasma\_MM          | SIMULATION\_ACTIVE\_PROCESS | MM            |
    | ActiveInfluxSpecificPlasmaToInterstitial\_Hill        | SIMULATION\_ACTIVE\_PROCESS | Hill          |
    | ActiveInfluxSpecificPlasmaToInterstitial\_MM          | SIMULATION\_ACTIVE\_PROCESS | MM            |
    | ...                                                   | ...                         | ...           |
* **process\_type** is used for more detailed process specification within a group and is used for various purposes in PK-Sim (s. e.g. [FlatProcessToCompoundProcessMapper](https://github.com/Open-Systems-Pharmacology/PK-Sim/blob/develop/src/PKSim.Infrastructure/ORM/Mappers/FlatProcessToCompoundProcessMapper.cs), [FlatProcessToActiveProcessMapper](https://github.com/Open-Systems-Pharmacology/PK-Sim/blob/develop/src/PKSim.Infrastructure/ORM/Mappers/FlatProcessToActiveProcessMapper.cs),etc.)

  | group\_name                     | process\_type            |
  | ------------------------------- | ------------------------ |
  | ACTIVE\_TRANSPORT               | ActiveTransport          |
  | ACTIVE\_TRANSPORT\_INTRINSIC    | ActiveTransport          |
  | APPLICATION                     | Application              |
  | ENZYMATIC\_STABILITY            | Metabolization           |
  | ENZYMATIC\_STABILITY\_INTRINSIC | Metabolization           |
  | INDIVIDUAL\_ACTIVE\_PROCESS     | BiDirectional            |
  | INDIVIDUAL\_ACTIVE\_PROCESS     | Efflux                   |
  | INDIVIDUAL\_ACTIVE\_PROCESS     | Influx                   |
  | INDIVIDUAL\_ACTIVE\_PROCESS     | PgpLike                  |
  | INDUCTION\_PROCESSES            | Induction                |
  | INHIBITION\_PROCESSES           | CompetitiveInhibition    |
  | INHIBITION\_PROCESSES           | IrreversibleInhibition   |
  | INHIBITION\_PROCESSES           | MixedInhibition          |
  | INHIBITION\_PROCESSES           | NoncompetitiveInhibition |
  | INHIBITION\_PROCESSES           | UncompetitiveInhibition  |
  | PROTEIN                         | Creation                 |
  | SIMULATION\_ACTIVE\_PROCESS     | BiDirectional            |
  | SIMULATION\_ACTIVE\_PROCESS     | Efflux                   |
  | SIMULATION\_ACTIVE\_PROCESS     | Induction                |
  | SIMULATION\_ACTIVE\_PROCESS     | Influx                   |
  | SIMULATION\_ACTIVE\_PROCESS     | IrreversibleInhibition   |
  | SIMULATION\_ACTIVE\_PROCESS     | PgpLike                  |
  | SPECIFIC\_BINDING               | SpecificBinding          |
  | SYSTEMIC\_PROCESSES             | Elimination              |
  | SYSTEMIC\_PROCESSES             | EliminationGFR           |
  | SYSTEMIC\_PROCESSES             | Metabolization           |
  | SYSTEMIC\_PROCESSES             | Secretion                |
  | UNDEFINED                       | Passive                  |
* **action\_type** is one of {`APPLICATION`, `INTERACTION`, `REACTION`, `TRANSPORT`} (s. [enum ProcessActionType](https://github.com/Open-Systems-Pharmacology/PK-Sim/blob/develop/src/PKSim.Infrastructure/ORM/FlatObjects/ProcessActionType.cs)).
* **create\_process\_rate\_parameter** defines if the `Process Rate` parameter should be created for transport or reaction (s. OSP Suite documentation [molecules](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/molecules-bb) or [reactions](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/reactions-bb) for details.)

#### tab\_process\_types

Defines available process types.

#### tab\_kinetic\_types

Defines available process kinetic types.

#### tab\_process\_descriptor\_conditions

Describes source and target container criteria for transports and source container criteria for reactions

* **tag\_type** can be one of `{SOURCE, TARGET}`

#### tab\_process\_molecules

Describes the reactions which are **always** part of a model (like e.g. *FcRn binding* in the large molecules model) (TODO rename the table, s. the issue <https://github.com/Open-Systems-Pharmacology/PK-Sim/issues/2309>)

* **direction** can be of `IN` (educt), `OUT` (product) or `MODIFIER`

#### tab\_process\_rates

Describes the rate (kinetic) of a process

* Template processes with the **parent** group **COMPOUND\_PROCESSES** and processes with the group **INDIVIDUAL\_ACTIVE\_PROCESS** always have `Zero_Rate` formula, because they are used in the corresponding building blocks where the process rate does not matter. The real rate is then set for the corresponding **simulation** process, e.g.

  | process                                             | calculation\_method | formula\_rate                                   |
  | --------------------------------------------------- | ------------------- | ----------------------------------------------- |
  | ActiveTransportSpecific\_MM                         | LinksCommon         | Zero\_Rate                                      |
  | ActiveEffluxSpecificIntracellularToInterstitial     | LinksCommon         | Zero\_Rate                                      |
  | ActiveEffluxSpecificIntracellularToInterstitial\_MM | LinksCommon         | ActiveEffluxSpecificWithTransporterInTarget\_MM |

#### tab\_model\_transport\_molecule\_names

Restricts which molecules are transported by a passive transport for particular model. As per default, passive transport will transfer all floating molecules from its source container to the target container. In this table, some molecules can be excluded (`should_transport=0`) or transport can be restricted only to the specific molecules (`should_transport=1`). S. the [Passive Transports documentation](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/passive-transports-bb) (TODO rename the table, s. the issue <https://github.com/Open-Systems-Pharmacology/PK-Sim/issues/2309>)

#### tab\_transports

Defines which active transports can be created in the model. (TODO rename the table, s. the issue <https://github.com/Open-Systems-Pharmacology/PK-Sim/issues/2309>)

#### tab\_transport\_directions

Defines all available transport directions (TODO rename the table, s. the issue <https://github.com/Open-Systems-Pharmacology/PK-Sim/issues/2309>)

#### tab\_known\_transporters

Defines a *global* transporter direction for a `{Species, Gene}` combination. When adding a transporter in PK-Sim that is not available in this data table: the transporter direction is set to default and the user is informed that the transporter was not found in the database. See [Localizations, directions, and initial concentrations of transport proteins](https://docs.open-systems-pharmacology.org/working-with-pk-sim/pk-sim-documentation/pk-sim-expression-profile#localizations-directions-and-initial-concentrations-of-transport-proteins) in the OSP Suite documentation.

#### tab\_known\_transporters\_containers

The *global* transporter direction defines the default transporter direction and polarity in each organ. However, some organs may have different transporter properties. To account for this, the *local* transporter direction and/or polarity can be overridden in some organs by entries in this table. See [Localizations, directions, and initial concentrations of transport proteins](https://docs.open-systems-pharmacology.org/working-with-pk-sim/pk-sim-documentation/pk-sim-expression-profile#localizations-directions-and-initial-concentrations-of-transport-proteins) in the OSP Suite documentation.

#### tab\_active\_transport\_types

Defines available **active** transport types (which is a subset of all transport types defined in [enum TransportType](https://github.com/Open-Systems-Pharmacology/OSPSuite.Core/blob/develop/src/OSPSuite.Core/Domain/TransportType.cs)).

### Species and populations

*Species* defines the type of an individual (Human, Dog, Rat, Mouse, ...)

*Population* defines a subtype of a species. For each species, 1 or more populations can be defined.

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-b1fe8c8f8b2519872e03d2250e096bc75475d310%2Foverview_species_and_populations.png?alt=media)

**tab\_population\_containers** specifies which containers are available for the given population and is described in detail [here](#tab_population_containers). See the [Containers](#containers) section for the explanation how this information is used when creating a simulation).

#### tab\_species

Defines a species.

* **user\_defined**
* **is\_human**

#### tab\_populations

Defines which populations are available for a given species.

* **is\_age\_dependent** Specifies whether some population parameters have age-dependent information (such parameters are then defined in [*tab\_container\_parameter\_curves*](#tab_container_parameter_curves)). If a population is age dependent:
  * Age must be provided as an input when creating an individual
  * Age range must be provided as an input when creating a population
  * *Aging* option is available when creating a simulation
  * Age dependent *ontogeny information* will be used for proteins etc.
* **is\_height\_dependent** Specifies whether height information is available for the given population. If a population is height dependent:
  * Height must be provided as an input when creating an individual
  * Height range must be provided as an input when creating a population
  * Organ volumes and some other anatomical parameters are scaled with the height when creating an individual, in simulations with aging etc.
  * Body surface area can be calculated

#### tab\_genders

Provides definition of all available genders.

#### tab\_population\_genders

Define genders available for a population. If no gender-specific data is available: gender is set to `UNKNOWN`.

#### tab\_population\_age

Defines the age range and the default age for the newly created individuals for all age-dependent populations.

* **default\_age\_unit** is the default *user interface* unit used when creating individuals/populations for the given population.

#### tab\_species\_calculation\_methods

If a parameter is defined by **formula** - this formula must be described by a *calculation method* (s. the [Calculation methods and parameter value versions](#calculation-methods-and-parameter-value-versions) section for details). In such a case, this calculation method must be assigned to the species, which happens in *tab\_species\_calculation\_methods*.

* E.g. the calculation method `Lumen_Geometry` describes the calculation of some GI-related parameters based on the age and body height, which is currently applicable only to the species `Human`. Thus this calculation method is defined only for `Human` in the table

#### tab\_species\_parameter\_value\_versions

Is the counterpart of *tab\_species\_calculation\_methods* for parameters defined by a **constant value**. All constant values must be described by a *parameter value version* (s. the [Calculation methods and parameter value versions](#calculation-methods-and-parameter-value-versions) section for details).

One of the reasons for introducing calculation methods and parameter value versions is that sometimes we have **more than one possible alternative** for defining a set of parameters.

* E.g. we have several alternatives for the calculation of body surface area in humans. The corresponding entries in the table [*tab\_species\_calculation\_methods*](#tab_species_calculation_methods) are shown below.

  | species | calculation\_method           |
  | ------- | ----------------------------- |
  | Human   | Body surface area - Du Bois   |
  | Human   | Body surface area - Mosteller |

  The fact that the above calculation methods are **alternatives** is defined by the fact that both have the same **category** defined in [*tab\_calculation\_methods*](#tab_calculation_methods) (see section [Calculation Methods and Parameter Value Versions](#calculation-methods-and-parameter-value-versions) for details). In PK-Sim, the user then has to select exactly one of these calculation methods (in the above example - during the individual creation, because the described parameters belong to the individual building block).

  ![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-111894a0b1f8235a2edef28d0f0aa5d29848819f%2FScreen01_SelectCalculationMethod.png?alt=media)

#### tab\_model\_species

Defines which species can be used in combination with the given model.

#### tab\_population\_disease\_states

The PK-Sim database stores information for **healthy** individuals. For some populations, additional information is available for some disease states. This table indicates which disease states are available for a population. If any:

* User can choose between healthy and one of the diseased states
* If a disease state has been selected: additional input parameters may be required. In the database, these parameters are specified in a parentless container whose name is identical to the name of the selected disease state and with `container_type=DISEASE_STATE`, e.g:

  | container\_id | container\_type | container\_name | parameter\_name | group\_name     | building\_block\_type | is\_input | … |
  | ------------- | --------------- | --------------- | --------------- | --------------- | --------------------- | --------- | - |
  | 5954          | DISEASE\_STATE  | CKD             | eGFR            | DISEASE\_STATES | INDIVIDUAL            | 1         | … |
* Disease-specific parameter values are currently NOT stored in the PK-Sim database. Instead, PK-Sim provides a "DiseaseState" class for each available disease state. In this class, a healthy individual is taken and then modified according to the specification of the given disease state. Examples:

  * CKD (Chronic Kidney Disease) disease state: [CKDDiseaseStateImplementation.cs](https://github.com/Open-Systems-Pharmacology/PK-Sim/blob/develop/src/PKSim.Core/Services/CKDDiseaseStateImplementation.cs)
  * HI (Hepatic Impairment) disease state: [HIDiseaseStateImplementation.cs](https://github.com/Open-Systems-Pharmacology/PK-Sim/blob/develop/src/PKSim.Core/Services/HIDiseaseStateImplementation.cs)

  ![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-704faa2d8ce64be67eb0a294684efc06e672cdb2%2FScreen02_DiseaseState.png?alt=media)

#### tab\_disease\_states

Describes all currently available disease states.

#### tab\_ontogenies

Defines ontogeny factors for some known proteins for a combination of `{Protein, Species}` (s. the [Documentation](https://docs.open-systems-pharmacology.org/working-with-pk-sim/pk-sim-documentation/pk-sim-compounds-definition-and-work-flow#basic-physico-chemistry) for details)

* **molecule** name of the protein.
* **species** name of the species
* **group\_name** specifies the localization of the ontogeny information:
  * `ONTOGENY_PLASMA` is used to set ontogeny factor for the plasma protein binding (s. [Documentation](https://docs.open-systems-pharmacology.org/working-with-pk-sim/pk-sim-documentation/pk-sim-compounds-definition-and-work-flow#basic-physico-chemistry) for details)
  * For enzymes, transporters and binding partners (other than plasma binding partners), ontogeny information can be stored in 2 different ways:
    * Either the same (global) ontogeny factor for all containers. In this case, the group name is set to `ONTOGENY_LIVER_ALL`
    * Or two ontogeny factors: the first one for the intestine and the second one for the rest of the body. In this case, the group name for these 2 factors is set to `ONTOGENY_DUODENUM` and `ONTOGENY_LIVER_NO_GI`, respectively.
* For for a combination of `{Protein, Species, Group}`, ontogeny information is stored in the form of the supporting points `{Postmenstrual age (PMA), Ontogeny factor, Geometric Standard Deviation}`.
  * If the individual's PMA is equal to one of the supporting points: the corresponding ontogeny factor value is used for the calculation.
  * If the PMA of the individual is less than the minimum PMA of the supporting points: the ontogeny factor corresponding to the minimum PMA is used.
  * If the PMA of the individual is greater than the maximum PMA of the supporting points: the ontogeny factor corresponding to the maximum PMA is used.
  * In other cases, the ontogeny factor is calculated by linear interpolation from two supporting points.

### Container parameters

This section describes the definition of `{Container, Parameter}` combinations. Another (dynamic) way to define parameters is described in the section [Calculation method parameters](#calculation-method-parameters) below.

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-eb030fe13709394322472c2383e83d67e6bd89bb%2Foverview_container_parameters.png?alt=media)

#### tab\_parameters

Describes an abstract parameter (e.g. "Volume"), which can be inserted in various containers.

* **dimension** must be one of the dimensions defined in the [OSP Dimensions Repository](https://github.com/Open-Systems-Pharmacology/OSPSuite.Dimensions/blob/master/OSPSuite.Dimensions.xml).
* **default\_unit** \[OPTIONAL] The default unit to use in the UI (unless the user specifies otherwise). Must be one of the units defined for the parameter dimension in the [OSP Dimensions Repository](https://github.com/Open-Systems-Pharmacology/OSPSuite.Dimensions/blob/master/OSPSuite.Dimensions.xml). If empty: the default unit from the [OSP Dimensions Repository](https://github.com/Open-Systems-Pharmacology/OSPSuite.Dimensions/blob/master/OSPSuite.Dimensions.xml) for the parameter dimension is used.

#### tab\_dimensions

Lists the available dimensions.

* **dimension** must be one of the dimensions defined in the [OSP Dimensions Repository](https://github.com/Open-Systems-Pharmacology/OSPSuite.Dimensions/blob/master/OSPSuite.Dimensions.xml).
* **kernel\_unit** is not used. Is only helpful when creating some database reports etc. Must be identical with the base unit of the corresponding dimension defined in the [OSP Dimensions Repository](https://github.com/Open-Systems-Pharmacology/OSPSuite.Dimensions/blob/master/OSPSuite.Dimensions.xml).

#### tab\_container\_parameters

Specifies a `{Container, Parameter}` combination.

* {**container\_id**, **container\_type**, **container\_name**} specifies the container.
* **parameter\_name** specifies the parameter.
* **visible** specifies if the parameter is shown in the PK-Sim UI (when sent to MoBi, this flag is translated into the *Advanced parameter* property.)
* **read\_only** specifies if the parameter can be edited by user in the PK-Sim UI
* **can\_be\_varied** is used to allow the variation of some read-only parameters outside of PK-Sim (e.g. in MoBi or via the R interface).

  Example: for the Arterial Blood container, the following parameters are defined in PK-Sim:

  | container\_name | parameter\_name                | can\_be\_varied | read\_only | visible |
  | --------------- | ------------------------------ | --------------- | ---------- | ------- |
  | ArterialBlood   | Allometric scale factor        | 0               | 1          | 0       |
  | ArterialBlood   | Density (tissue)               | 1               | 1          | 0       |
  | ArterialBlood   | Fraction vascular              | 1               | 1          | 1       |
  | ArterialBlood   | Peripheral blood flow fraction | 1               | 0          | 1       |
  | ArterialBlood   | Volume                         | 1               | 0          | 1       |
  | ArterialBlood   | Weight (tissue)                | 1               | 1          | 0       |

  If we create a sensitivity analysis in PK-Sim, only the parameters `Peripheral Blood Flow Fraction` and `Volume` will be available for variation because of the flag combination `{visible=1, read_only=0, can_be_varied=1}`.

  However, if we send the simulation to MoBi and create a sensitivity analysis there, all parameters from the table above, except `Allometric Scale Factor`, will be available for variation (in *Advanced Mode*), due to `can_be_varied=1`.
* **can\_be\_varied\_in\_population** specifies (together with **is\_changed\_by\_create\_individual** - s. below) if a parameter defined by value or by formula (s. below) can be used for the [User Defined Variability‌](https://docs.open-systems-pharmacology.org/working-with-pk-sim/pk-sim-documentation/pk-sim-creating-populations#user-defined-variability) in populations or population simulations.
* **group\_name** defines how parameters are displayed in the PK-Sim UI (s. below and also see the description in the [OSP documentation](https://docs.open-systems-pharmacology.org/working-with-pk-sim/pk-sim-documentation/pk-sim-simulations#running-a-simulation-in-an-individual)).
* **build\_mode** can be one of the following: `LOCAL`, `GLOBAL`, or `PROPERTY` (s. the [OSP documentation](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/parameters-formulas-tags) for details).
* **building\_block\_type** can be one of the following: `COMPOUND`, `EVENT`, `FORMULATION`, `INDIVIDUAL`, `PROTOCOL`, `SIMULATION`. Used to determine which parameters can be added to a container at the building block level and which at the simulation level.
* **is\_input** is used to specify whether a parameter that has NOT been changed by the user should be exported to the project snapshot or not.

  Why we need this: some parameters have default values **just for user convenience**. In principle, these values should be empty/NaN by default. However, to reduce the amount of user input required, the parameters have been set to some value.

  For example, when creating a new compound, the default value is "`Is small molecule = 1`". When the user creates a new small molecule compound, this value is apparently kept AS IS. But in fact it's a user input, which is implicit here, meaning that the value of "`Is small molecule`" must be exported to the snapshot in any case.
* **is\_changed\_by\_create\_individual** indicates whether a parameter is changed by the *Create Individual algorithm*. This includes both *directly* modified parameters (= age-dependent parameters specified in [*tab\_container\_parameter\_curves*](#tab_container_parameter_curves), see below) and *indirectly* modified parameters (such as the blood flows). Parameters with `is_changed_by_create_individual = 1` always appear in the *Distribution* tab of PK-Sim and are not available for user-defined variability.

#### tab\_groups

Defines the group hierarchy. In the parameter view of individuals/populations/simulations in PK-Sim, each visible parameter is displayed within its group. (s. [OSP Suite documentation](https://docs.open-systems-pharmacology.org/working-with-pk-sim/pk-sim-documentation/pk-sim-creating-individuals#anatomy-and-physiology) for details)

* **parent\_group** specifies the parent group (if any). Groups without a parent are displayed at the top level.
* **is\_advanced** defines whether the group is displayed in the simple view or only in the advanced view.
* **visible** determines whether the group is visible in the parameter view. If a parameter is visible but belongs to a hidden group, it can still be displayed in either the Hierarchy View mode or in the "All" Parameters group.
* **pop\_display\_name** \[OPTIONAL] is used to display parameters in the "User Defined Variability" and "Distribution" tabs of populations and population simulations. If empty: the **display\_name** of the group is used.
* **full\_name** is not used by PK-Sim. Shown in MoBi when a simulation is sent from PK-Sim (MoBi does not provide hierarchical parameter view by group like PK-Sim).
* **unique\_id** Unique group id used to identify a group in MoBi or when importing a simulation from pkml in PK-Sim. Should never be changed in the DB! With each new OSP release a **GroupRepository.xml** file is generated by PK-Sim and placed under **C:\ProgramData\Open Systems Pharmacology\MoBi\X.Y**. Here the complete group information (display name, description, icon, ..) is stored. In pkml files, only the unique group ID is stored.

#### tab\_molecule\_parameters

Describes some global protein parameters (like "Reference concentration" etc.)

The value of a container parameter can be defined in one of three possible ways:

1. By a *formula* specified in [*tab\_container\_parameter\_rates*](#tab_container_parameter_rates).

   A formula is neither species nor population dependent.
2. By *constant value* specified in [*tab\_container\_parameter\_values*](#tab_container_parameter_values).

   A constant value is species dependent but not population dependent.
3. By *age-dependent probability distribution* specified in [*tab\_container\_parameter\_curves*](#tab_container_parameter_curves).

It is possible, that for a combination {`container_id, container_type, container_name, parameter_name`} we have *several entries* in different tables (e.g. several formulas or formula and value etc.).

When creating a building block or simulation, some entries are filtered out because the calculation method or parameter value version of the entry does not belong to the species/population/model of the created building block/simulation.

If we still have more than one entry - the corresponding calculation methods or parameter value versions must be of the **same category** (i.e. they represent possible **alternatives** for the parameter definition). See the sections [Species and Populations](#species-and-populations) and [Calculation Methods and Parameter Value Versions](#calculation-methods-and-parameter-value-versions) for more details.

#### tab\_container\_parameter\_rates

Defines a formula for the given parameter in the given container.

* **container\_id**, **container\_type**, **container\_name** defines the container.
* **parameter\_name** defines the parameter in the given container.
* **calculation\_method**, **formula\_rate** defines the formula (s. the section [Formulas](#formulas) for more details on formulas).

#### tab\_container\_parameter\_values

Defines a constant value for the combination {*Container*, *Parameter*, *Species*, *Parameter Value Version*}.

* **container\_id**, **container\_type**, **container\_name** defines the container.
* **parameter\_name** defines the parameter in the given container.
* **species** defines the species.
* **parameter\_value\_version** defines which parameter value version the given value belongs to (s. the section [Calculation methods and parameter value versions](#calculation-methods-and-parameter-value-versions) for more details).
* **default\_value** parameter value for the combination of the properties above.

#### tab\_container\_parameter\_curves

Describes age-dependent and/or distributed parameters.

How does it work (all bullet points below apply for a combination {`parameter_value_version, species, container_id, container_type, container_name, parameter_name, population, gender, gestational_age`}):

* N supporting age points are defined (N>=1): *Age\_min*, … , *Age\_max*
* For an individual of given age: *mean* and *sd* value are interpolated based on the mean and sd of defined supported points
  * For `Age < Age_min`: `mean(Age) = mean(Age_min)` and `sd(Age) = sd(Age_min)`
  * For `Age > Age_max`: `mean(Age) = mean(Age_max)` and `sd(Age) = sd(Age_max)`
  * For `Age_min ≤ Age ≤ Age_max`: both *mean* and *sd* are linearly interpolated between their 2 adjacent supporting points (if the *Age* is one of the supporting points, then *mean* and *sd* are obviously taken from it without interpolation).
* Distribution type must be always the same for all ages.
* If we have only age dependency but no distribution, we set `distribution_type=”discrete”` (constant) and `sd = 0` for all supporting points.
* If both *mean* and *sd* are constant for all ages: we define only 1 supporting point (usually with `Age = 0`).

#### tab\_distribution\_types

Lists all available probability distributions.

#### tab\_compound\_process\_parameter\_mapping

When creating a process in a compound building block, the values of the *Calculation parameters* of this process are taken from the mapped parameters of the **default individual** for the **default population** (the latter is specified in the PK-Sim options) of the species defined by the user during the process creation (see the [OSP Suite documentation](https://docs.open-systems-pharmacology.org/working-with-pk-sim/pk-sim-documentation/pk-sim-compounds-definition-and-work-flow#adme-properties) for details).

#### tab\_container\_parameter\_rhs

If a parameter is defined by a differential equation, the right-hand side (RHS) of that equation is given in this table.

#### tab\_container\_parameter\_descriptor\_conditions

Is used to restrict the creation of local protein parameters to specific containers.

* **tag** Tag of a container in which the parameter should (or should not) be created.
* **condition** Criteria condition for the tag.
* **operator** Specifies how to combine single criteria conditions for the combination {`container_id, container_type, container_name, parameter_name`}. Must be the same for all entries in this combination. Possible values are 'And' and 'Or'.

#### tab\_conditions (container parameters)

Specifies available (container) criteria conditions. Values must be the same as defined by the [`enum CriteriaCondition`](https://github.com/Open-Systems-Pharmacology/PK-Sim/blob/develop/src/PKSim.Infrastructure/ORM/FlatObjects/CriteriaCondition.cs) in PK-Sim.

<details>

<summary>Currently not used by PK-Sim</summary>

There is another way to describe the value of a container parameter: by an age-dependent probability distribution specified in [*tab\_container\_parameter\_fcurves*](#tab_container_parameter_fcurves). However, this is currently not used by PK-Sim.

The difference to the [*tab\_container\_parameter\_curves*](#tab_container_parameter_curves) is: the age-dependent parameter value and distribution are not defined by the table of support points, but by 2 analytical functions:

$$Mean\ value = f\_1(Age,\ ...)$$

$$Standard\ deviation = f\_2(Age,\ ...)$$

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-8c6085590fac1cd60e9515604ed14b9b1be07f2d%2Foverview_container_parameters_fcurves.png?alt=media)

#### tab\_container\_parameter\_fcurves

* **calculation\_method**, **mean\_value\_rate** define the age-dependent function of the parameter mean value.
* **calculation\_method**, **standard\_deviation\_rate** define the age-dependent function of the parameter standard deviation.
* all other columns have the same meaning as in the [*tab\_container\_parameter\_curves*](#tab_container_parameter_curves).

</details>

### Calculation method parameters

Apart from the container parameters described above, some parameters are created *dynamically* when the model uses a particular calculation method.

Some calculation methods rely on a large number of **supporting parameters**, which are only used to create other parameters and are of no interest once the "main" parameters are created.

To avoid adding tons of supporting parameters for all possible combinations of calculation methods, the concept of "Calculation method parameters" was introduced, which allows adding supporting parameters on demand.

To enable calculation method parameters also in MoBi: with each new OSP release a **AllCalculationMethods.pkml** file is generated by PK-Sim and placed under **C:\ProgramData\Open Systems Pharmacology\MoBi\X.Y**. Here the complete supporting parameter information (parameter properties, location, formula) is stored.

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-4f0b45231590ca29c7892ac651f03e3407d1c299%2Foverview_calculation_method_parameters.png?alt=media)

#### tab\_calculation\_method\_parameter\_rates

Defines which parameters are added dynamically. Another task of this table is to dynamically assign formulas to the "main" parameters initially defined by a *black-box formula*. The latter is described in more detail in the section [Black Box Formulas](#black-box-formulas).

* **parameter\_id** unique id, only used internally in the database.
* **parameter\_name** name of the supporting parameter to add.
* **group\_name**, **can\_be\_varied**, **can\_be\_varied\_in\_population**, **read\_only**, **visible** have the same meaning as for the container parameters.
* {**calculation\_method**, **rate**} define for which calculation method and with which formula the parameter will be added.

#### tab\_calculation\_method\_parameter\_descr\_conditions

Defines the containers in which a supporting parameter should be created. Containers are described by their tags; single criteria conditions for a parameter id are combined by `AND`.

### Formulas

This section describes the formulas defined in the PK-Sim database. This includes:

* formulas defined by an analytical equation (*explicit formulas*)
* *sum formulas*
* table formulas with offset
* table formulas with X argument

An **explicit formula** is defined by the equation $$f(P\_1, ... P\_n; M\_1, ..., M\_k; C\_1, ... C\_j; TIME)$$ where:

* $$f$$ is an analytical function
* $$P\_1, ... P\_n$$ ($$n \geq 0$$) are model parameters
* $$M\_1, ..., M\_k$$ ($$k \geq 0$$) are molecule amounts
* $$C\_1, ... C\_j$$ ($$j \geq 0$$) are molecule concentrations
* $$TIME$$ is the current time (related to the begin of the simulation run)

A **sum formula** is defined by the equation $$f(P\_1, ... P\_n; M\_1, ..., M\_k; C\_1, ... C\_j; TIME;$$ `Q_#i` $$)$$ where:

* `Q_#i` is a *control variable* (parameter, molecule amount, etc.) defined by certain conditions
* all other arguments have the same meaning as in an explicit formula

A **table formula with offset** is defined by 2 quantities (see the [OSP documentation](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/parameters-formulas-tags#table-formulas-with-offset) for details):

* **table object** with the `Table_formula` (defined by the support points { $$time\_i;value\_i$$} )
* **offset object** with the `Offset_formula`.

The X argument of the table object is always the (simulation) time, and the formula returns the value `Table_formula(Time - Offset_formula(Time;...))`.

A **table formula with X argument** is a generalization of *table formula with offset* and is defined by 2 quantities

* **table object** with the `Table_formula` (defined by the support points { $$x\_i;value\_i$$} ).
* **X argument object** with the `XArgument_formula`.

The table's X argument is arbitrary, and the formula returns the value $$Table\_formula(XArgument\_formula(...))$$.

S. the OSP Suite documentation: [Working with Formulas‌](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/parameters-formulas-tags#formulas) and [Sum Formulas](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/parameters-formulas-tags#sum-formulas) for more details on formulas.

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-8f894410a0d1b5371d3078f89e1e4ea52c1238db%2Foverview_calculation_method_rates.png?alt=media)

#### tab\_rates

Describes an abstract formula.

#### tab\_calculation\_methods

Describes a calculation method. A calculation method describes how a **group of quantities** (parameters, molecule initial values, etc.) are defined by their formulas. A decision about which quantities should be described by the same calculation method is usually based on information about which formulas would change when the user switches from one (sub)model to another. For example, if the user chooses a different method for calculating the *Body Surface Area* (BSA) - only the BSA parameter itself is affected, and thus only this parameter is described by the corresponding calculation methods. If the user chooses another method for calculating the surface area between the plasma and the interstitial space - the *Surface Area (Plasma/Interstitial)* parameters in all tissues organs are affected: thus all these parameters are grouped in the same calculation method.

* **category** calculation methods belonging to the same category are alternatives, which can be selected by user (s. also the section [Container Parameters](#container-parameters))

#### tab\_categories

Specifies the categories of calculation methods.

* **category\_type** describes for which building block or simulation all calculation methods of the given category are valid. For example, if the category type of a calculation method is "Individual" - the calculation method will be used when creating an individual. Valid values of the category type are defined by the [`enum CategoryType`](https://github.com/Open-Systems-Pharmacology/PK-Sim/blob/develop/src/PKSim.Core/Model/Category.cs).

#### tab\_calculation\_method\_rates

Defines the formula equation for the combination {`calculation_method, formula_rate`}.

* **calculation\_method** defines the calculation method. Some calculation methods have a special meaning and are described in more detail in the next subsections:
  * `BlackBox_CalculationMethod`
  * `DynamicSumFormulas`
  * `DiseaseStates`
* **formula\_rate** defines the formula.
  * For some frequently used constant rates specific formulas were defined:
    * `Zero_Rate`
    * `One_Rate`
    * `Thousand_Rate`
    * `NaN_Rate`
  * Some calculation methods have a special meaning and are described in more detail in the next subsections:
    * `TableFormulaWithOffset_*`
    * `TableFormulaWithXArgument_*`
* **formula** defines the equation for the combination {`calculation_method, formula_rate`}. Which operators, standard functions, etc. are allowed is described in the [OSP Suite documentation - Working with Formulas](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/parameters-formulas-tags#formulas).
  * It is allowed to leave the **formula** field empty. Quantity with empty formula becomes mandatory user input in PK-Sim UI. This means that only **visible and editable quantities** are allowed to have an empty formula.
  * Formula can be set to $$\pm \infty$$. Valid values for this are:
    * `Inf` or `Infinity`
    * `-Inf` or `-Infinity`
  * It is important to write **efficient formulas**. Check the [WIKI **Writing efficient formulas**](https://github.com/Open-Systems-Pharmacology/OSPSuite.FuncParser/wiki/Writing-efficient-formulas) for details.
  * Constant values in equations should be avoided. It is always better to define a new parameter, set it to the constant value, and then use that parameter in the equation. Exceptions are constants whose meaning is immediately clear (e.g. `1`, `0`, `ln(2)`, etc.). Because:
    * In the parameter definition, we can add description, value origin, etc. All of this information is missing when you use a constant directly in an equation.
    * Unit information is lost and this can easily lead to errors (happens quite often in MoBi, when users add constants to their formulas, see e.g. [this discussion](https://github.com/Open-Systems-Pharmacology/Forum/issues/491)).
* **dimension** the dimension of the formula. Used e.g. by the dimension check in MoBi to make sure that the quantities using the given formula have the same dimension.

#### tab\_rate\_container\_parameters

Parameters referenced by the formula of the combination {`calculation_method, formula_rate`}. Parameters are given by the combination of {`container_id, container_type, container_name, parameter_name`}.

* **alias** is the alias of the referenced parameter used in the calculation. The rules for defining aliases are
  * Aliases of all quantities referenced in the formula must be unique and not empty.
  * Alias cannot be a number.
  * Alias must not contain any of the characters `+ - * \ / ^ . , < > = ! ( ) [ ] { } ' " ? : ¬ | & ;`
  * Alias must not contain blanks.
  * Alias cannot be one of the predefined *standard constants* (s. the [OSP Suite documentation - Working with Formulas](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/parameters-formulas-tags#formulas)).
  * Alias cannot be one of the predefined *standard functions* (s. the [OSP Suite documentation - Working with Formulas](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/parameters-formulas-tags#formulas)).
  * Alias cannot be one of the predefined *logical operators* (s. the [OSP Suite documentation - Working with Formulas](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/parameters-formulas-tags#formulas)).

#### tab\_rate\_container\_molecules

Molecules referenced by the formula of the combination {`calculation_method, formula_rate`}. Molecules are given by the combination of {`container_id, container_type, container_name, molecule`}.

* **alias** is the alias of the referenced parameter used in the calculation. Alias rules apply (s. above).
* **use\_amount** specifies whether the *amount* or *concentration* of the given molecule is used.

#### tab\_rate\_generic\_parameters

Parameters referenced by the formula of the combination {`calculation_method, formula_rate`}. Parameters are given by the combination of {`path_id, parameter_name`}.

* **path\_id** refers to the (relative) object path stored in the table [*tab\_object\_paths*](#tab_object_paths) (s. below).
* **alias** is the alias of the referenced parameter used in the calculation. Alias rules apply (s. above).

#### tab\_rate\_generic\_molecules

Parameters referenced by the formula of the combination {`calculation_method, formula_rate`}. Parameters are given by the combination of {`path_id, molecule`}.

* **path\_id** refers to the (relative) object path stored in the table [*tab\_object\_paths*](#tab_object_paths) (s. below).
* **alias** is the alias of the referenced molecule used in the calculation. Alias rules apply (s. above).
* **use\_amount** specifies whether the *amount* or *concentration* of the given molecule is used.

There are some "special" containers defined in [*tab\_container\_names*](#tab_container_names) that are not used in the container hierarchy defined in [*tab\_containers*](#tab_containers). These containers are only used for **referential integrity when defining some relative object paths**. (TODO s. [the issue](https://github.com/Open-Systems-Pharmacology/PK-Sim/issues/2692))

<details>

<summary>Special containers</summary>

| ref\_container\_name     | description                                                 |
| ------------------------ | ----------------------------------------------------------- |
| .                        | Me                                                          |
| ..                       | Parent                                                      |
| \<COMPLEX>               | Dummy, will be replaced by complex name in PK-Sim           |
| \<FormulationName>       | \<FormulationName>                                          |
| \<MOLECULE>              | Dummy, will be replaced by compound name in PK-Sim          |
| \<PROCESS>               | Template for Compound process in simulation                 |
| \<PROTEIN>               | Template for protein                                        |
| \<REACTION>              | Dummy, will be replaced by reaction name in PK-Sim          |
| ALL\_FLOATING\_MOLECULES | Path entry referencing all floating molecules (Assignments) |
| FIRST\_NEIGHBOR          | Path entry for the first neighbor                           |
| FcRn                     | FcRn                                                        |
| FcRn\_Complex            | FcRn\_Complex                                               |
| LigandEndo               | LigandEndo                                                  |
| LigandEndo\_Complex      | LigandEndo\_Complex                                         |
| NEIGHBORHOOD             | Path entry for the neighborhood                             |
| SECOND\_NEIGHBOR         | Path entry for the second neighbor                          |
| SOURCE                   | Path entry for source amount                                |
| TARGET                   | Path entry for target amount                                |
| TRANSPORT                | Path entry for the transport                                |

</details>

#### tab\_object\_paths

Describes (relative) paths of quantities used in a formula (see the [OSP Suite documentation - Working with Formulas](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/parameters-formulas-tags#formulas) for details). Each entry of an object path is stored separately, with its own id and the id of its parent path entry. Tables *tab\_rate\_generic\_XXX* have the reference to the **bottom element of the object path** (see the example below).

* **path\_id** is the unique id of the path entry.
* **parent\_path\_id** is the id of the parent path entry. If there is no parent path entry: the parent path id is set equal to the path id!
* {**ref\_container\_type**, **ref\_container\_name**} name and type of the container which is referenced by the path entry.

Example:

*tab\_object\_paths* contains the following path entries:

| path\_id | parent\_path\_id | ref\_container\_type | ref\_container\_name   |
| -------- | ---------------- | -------------------- | ---------------------- |
| 260      | 259              | GENERAL              | MOLECULE               |
| 259      | 2078             | NEIGHBORHOOD         | Brain\_pls\_Brain\_int |
| 2078     | 2078             | GENERAL              | Neighborhoods          |

These entries represent the path `Neighborhoods|Brain_pls_Brain_int|MOLECULE`.

In [*tab\_rate\_generic\_parameters*](#tab_rate_generic_parameters) the path is referenced like this:

| calculation\_method                                 | formula\_rate                      | path\_id | parameter\_name                             | alias       |
| --------------------------------------------------- | ---------------------------------- | -------- | ------------------------------------------- | ----------- |
| Interstitial partition coefficient method - Schmitt | PARAM\_K\_water\_int\_brn\_Schmitt | **260**  | Partition coefficient (interstitial/plasma) | K\_int\_pls |

With this, the full path to the referenced parameter is:\
`Neighborhoods|Brain_pls_Brain_int|MOLECULE|Partition coefficient (interstitial/plasma)`

**Sum formulas**

See the [OSP Suite documentation - Sum Formulas](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/parameters-formulas-tags#sum-formulas) for more details.

Sum formulas in the PK-Sim database must have the calculation method **DynamicSumFormulas**.

Compared to the full flexibility of the sum formulas provided in MoBi, there are some restrictions:

* *Control variable* (`Q` in the screenshot below) can only be defined **with 1 letter**.
* Quantity references **relative to the summed object** (the highlighted part of the definition below) are not possible.
* The operator for combining the conditions of each criterion is always \`And'.

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-9d8bd5983bf101e17ce07cf8b3c32842751e516c%2FScreen03_SumFormula.png?alt=media)

#### tab\_calculation\_method\_rate\_descriptor\_conditions

Defines the criteria of the quantities to be summed up for the combination {`calculation_method, rate`}.

* **condition** criteria condition for the target container.
* **tag** the tag of the single condition.

#### tab\_conditions (formulas)

Specifies available (container) criteria conditions. Values must be the same as defined by the [`enum CriteriaCondition`](https://github.com/Open-Systems-Pharmacology/PK-Sim/blob/develop/src/PKSim.Infrastructure/ORM/FlatObjects/CriteriaCondition.cs) in PK-Sim.

**"Black box" formulas**

Some molecule-dependent parameters defined within the spatial structure have a formula that depends on the calculation methods of the specific molecule. Examples of such parameters are partition coefficients, cellular permeabilities, etc.

Within the spatial structure, these parameters are defined by a dummy formula - *black-box formula* - which is replaced by a concrete formula for each molecule.

All black box formulas are combined within the calculation method \`BlackBox\_CalculationMethod'.

The concrete (calculation method dependent) formulas are then defined in the table [*tab\_calculation\_method\_parameter\_rates*](#tab_calculation_method_parameter_rates) (and exported to **AllCalculationMethods.pkml** for MoBi) - see the section [Calculation method parameters](#calculation-method-parameters).

Example of how black box parameters are displayed in MoBi:

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-8943e8606e015cc8d529b42e4de4f97476516ec4%2FScreen04_BlackBoxFormula.png?alt=media)

**Disease state parameters**

Parameters specific to disease states are grouped under the `DiseaseStates` calculation method.

**Table formulas with offset**

If a formula\_rate starts with the prefix **TableFormulaWithOffset\_** (e.g. `TableFormulaWithOffset_FractionDose`) - PK-Sim will create a table formula with offset.

PK-Sim then expects that **exactly 2 referenced quantities are defined for the formula**: one quantity with the alias `Table` and another quantity with the alias `Offset`. Example:

| calculation\_method  | formula\_rate                        | path\_id | parameter\_name | alias      |
| -------------------- | ------------------------------------ | -------- | --------------- | ---------- |
| ApplicationParameter | TableFormulaWithOffset\_FractionDose | 139      | Start time      | **Offset** |
| ApplicationParameter | TableFormulaWithOffset\_FractionDose | 253      | Fraction (dose) | **Table**  |

**Table formulas with X argument**

If a formula\_rate starts with the prefix **TableFormulaWithXArgument\_** (e.g. `TableFormulaWithXArgument_Solubility`) - PK-Sim will create a table formula with X Argument.

PK-Sim then expects, that **exactly 2 referenced quantities are defined for the formula**: one quantity with the alias `Table` and another quantity with the alias `XArg`. Example:

| calculation\_method | formula\_rate                         | path\_id | parameter\_name  | alias     |
| ------------------- | ------------------------------------- | -------- | ---------------- | --------- |
| Lumen\_PKSim        | TableFormulaWithXArgument\_Solubility | 140      | pH               | **XArg**  |
| Lumen\_PKSim        | TableFormulaWithXArgument\_Solubility | 240      | Solubility table | **Table** |

### Calculation methods and parameter value versions

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-2e1a4ec839970aa8fb87ae662843c297fd7f376f%2Foverview_CM_and_PVV.png?alt=media)

**tab\_species\_calculation\_methods** defines which calculation methods are available for the given species and is described in detail [here](#tab_species_calculation_methods).

**tab\_species\_parameter\_value\_versions** is the counterpart of *tab\_species\_calculation\_methods* and defines which parameter value versions are available for the given species. It is described in detail [here](#tab_species_parameter_value_versions).

**tab\_categories** specifies the categories of calculation methods and parameter value versions and is described in detail [here](#tab_categories).

**tab\_calculation\_methods** defines a *calculation method* (**CM**) and is described in detail [here](#tab_calculation_methods). A calculation method describes how a **group of quantities** (parameters, molecule initial values, etc.) are defined by their formulas. A decision about which quantities should be described by the same CM is usually based on information about which formulas would change when the user switches from one (sub)model to another. For example, if the user chooses a different method for calculating the *Body Surface Area* (BSA) - only the BSA parameter itself is affected, and thus only this parameter is described by the corresponding calculation method. If the user chooses another method for calculating the surface area between the plasma and the interstitial space - the *Surface Area (Plasma/Interstitial)* parameters in all tissues organs are affected: thus all these parameters are grouped in the same calculation method. More details on calculation methods are provided in the section [Formulas](#formulas).

#### tab\_models

Defines available PBPK models, which can be selected during the simulation creation (e.g. "Small molecules model", "Large molecules model" etc.).

* **short\_display\_name** is used in some places in the UI, where the fully qualified model display name is too long.

#### tab\_parameter\_value\_versions

Defines a *parameter value version* (**PVV**). A parameter value version describes how a **group of parameters** are defined by their constant values or their distributions. A decision about which parameters should be described by the same PVV is usually based on information about which parameters would change when the user switches from one PVV to another. More details on parameter value versions are provided in the sections [Species and populations](#species-and-populations) and [Container parameters](#container-parameters).

#### tab\_model\_calculation\_methods

Defines which calculation methods are available for a model.

Now, when it comes to creating a building block or simulation, the algorithm for determining which CMs and PVVs to use is as follows:

1. Identify all PVVs with the category type corresponding to the type of the block/simulation.
2. If the building block type is "Individual": remove all PVVs that are not assigned to the species of the individual (via *tab\_species\_parameter\_value\_versions*).
3. Group all remaining PVVs according to their category.
   * For each group with $$\geq$$ 2 PVVs: these PVVs are **alternatives** and the user has to choose exactly one of them to be used in the building block/simulation.
4. Identify all CMs with the category type corresponding to the type of the block/simulation.
5. If the building block type is "Individual": remove all CMs that are not assigned to the species of the individual (via *tab\_species\_calculation\_methods*).
6. Group all remaining CMs according to their category.
   * For each group with $$\geq$$ 2 CMs: these CMs are **alternatives** and the user has to choose exactly one of them to be used in the building block/simulation.

### Applications and formulations

*Applications* are containers with container\_type="APPLICATION"\`.

*Formulations* are containers with container\_type="FORMULATION"\`.

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-2fb9d81d2077244076a1e485b2bd6c4f850ef55f%2Foverview_applications_formulations.png?alt=media)

In the container hierarchy (defined in [*tab\_containers*](#tab_containers)):

* Formulations are always top-level containers with no parent.
* Applications always have a formulation as parent container.
  * For applications that do not require a formulation (e.g. IV), `Formulation_Empty` is defined as the parent container.

| Id   | Type        | Name                    | ParentId | ParentType  | ParentName                   |
| ---- | ----------- | ----------------------- | -------- | ----------- | ---------------------------- |
| 1725 | APPLICATION | Intravenous             | 1718     | FORMULATION | Formulation\_Empty           |
| 1724 | APPLICATION | IntravenousBolus        | 1718     | FORMULATION | Formulation\_Empty           |
| 1722 | APPLICATION | Oral\_Dissolved         | 1717     | FORMULATION | Formulation\_Dissolved       |
| 5101 | APPLICATION | Oral\_Particles         | 5100     | FORMULATION | Formulation\_Particles       |
| 5268 | APPLICATION | Oral\_Table             | 5262     | FORMULATION | Formulation\_Table           |
| 5045 | APPLICATION | Oral\_Tablet\_Lint80    | 5044     | FORMULATION | Formulation\_Tablet\_Lint80  |
| 1728 | APPLICATION | Oral\_Tablet\_Weibull   | 1720     | FORMULATION | Formulation\_Tablet\_Weibull |
| 5344 | APPLICATION | UserDefined\_Dissolved  | 1717     | FORMULATION | Formulation\_Dissolved       |
| 5239 | APPLICATION | UserDefined\_FirstOrder | 1719     | FORMULATION | Formulation\_FirstOrder      |
| 5284 | APPLICATION | UserDefined\_Table      | 5262     | FORMULATION | Formulation\_Table           |
| ...  | ...         | ...                     | ...      | ...         | ...                          |

Each application has a `ProtocolSchemaItem` subcontainer which stores some parameters common to all applications (e.g. `Start time`, `Dose`, etc.) and some application specific parameters (e.g. `Amount of water` for oral applications).

Each application also has an `Application_StartEvent` subcontainer that defines the application start event.

Most applications have an `Application_StopEvent` subcontainer that defines the application stop event.

Other application subcontainers are application specific (e.g. transport(s) *Application* ▶️ *Organism*, other subcontainers, etc.). For example, for the *Intravenous* (infusion) application has the following subcontainers:

| container\_id | container\_type | container\_name         | parent\_container\_id | parent\_container\_type | parent\_container\_name |
| ------------- | --------------- | ----------------------- | --------------------- | ----------------------- | ----------------------- |
| 1731          | GENERAL         | ProtocolSchemaItem      | 1725                  | APPLICATION             | Intravenous             |
| 1739          | EVENT           | Application\_StartEvent | 1725                  | APPLICATION             | Intravenous             |
| 1745          | EVENT           | Application\_StopEvent  | 1725                  | APPLICATION             | Intravenous             |
| 1748          | PROCESS         | Intravenous\_Transport  | 1725                  | APPLICATION             | Intravenous             |

#### tab\_formulation\_routes

Defines the formulations.

* **formulation** is the name of the formulation.
* **container\_type** is always "FORMULATION".
* **route** is the route of administration (IV, oral, dermal, ...) for which the formulation is intended.

#### tab\_applications

Defines the top container of an application.

* **application\_name** is the name of the application.
* **container\_type** is always "APPLICATION".
* **application\_type** is the route of administration (TODO rename, s. [the Issue](https://github.com/Open-Systems-Pharmacology/PK-Sim/issues/2309))

#### tab\_application\_types

Defines all available administration routes (TODO rename, s. [the Issue](https://github.com/Open-Systems-Pharmacology/PK-Sim/issues/2309))

* **application\_type** is the route of administration (TODO rename, s. [the Issue](https://github.com/Open-Systems-Pharmacology/PK-Sim/issues/2309))
* **is\_formulation\_required** indicates whether a formulation definition is required for the given route.

### Events

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-bdd810aad638c7fd6bc8d315548853907db518f0%2Foverview_events.png?alt=media)

*Events* are containers with `container_type="EVENT"`.

In the container hierarchy (defined in [*tab\_containers*](#tab_containers)) event are usually children of containers of type "`APPLICATION`" or "`EVENTGROUP`".

Each event is described by the event condition and the quantities that are changed by this event.

#### tab\_event\_conditions

Defines the event condition of an event.

* {**event\_id**, **event\_container\_type**, **event\_name**} are the id, type and name of the event container.
* {**calculation\_method**, **formula\_rate**} define the formula of the event condition (typically a boolean formula which can return only 0 or 1).
* **is\_one\_time** specifies whether the event is triggered *whenever the event condition is met* (`is_one_time=0`) or only at the *first simulation time point* when the event condition is met.

#### tab\_event\_changed\_container\_molecules

#### tab\_event\_changed\_container\_parameters

#### tab\_event\_changed\_generic\_molecules

#### tab\_event\_changed\_generic\_parameters

Define which parameters or molecule amounts are modified by an event. The referencing of the modified quantities of an event is done in the same way as the referencing of the quantities used in a formula and defined in the tables [*tab\_rate\_container\_molecules*](#tab_rate_container_molecules), [*tab\_rate\_container\_parameters*](#tab_rate_container_parameters), [*tab\_rate\_generic\_molecules*](#tab_rate_generic_molecules), [*tab\_rate\_generic\_parameters*](#tab_rate_generic_parameters) (s. the section [Formulas](#formulas)) for details.

* {**event\_id**, **event\_container\_type**, **event\_name**} are the id, type and name of the event container.
* {**calculation\_method**, **formula\_rate**} defines the formula that will be applied to the changed quantity when the event is triggered.
* **use\_as\_value** defines if the formula is assigned as a formula or as a value of the formula, calculated at the time point of the assignment.
* **use\_amount** (TODO delete - s. [the issue](https://github.com/Open-Systems-Pharmacology/PK-Sim/issues/2696))

S. the [OSP Documentation on events](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/events-bb#event-groups-and-events) for more details.

### Observers

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-8e314b6fbd209577436d53a3b5345ab23e3639ce%2Foverview_observers.png?alt=media)

#### tab\_observers

Specifies an observer.

* **observer** name of the observer.
* **observer\_type**
* **category** always set to `"Observer"`.
* **builder\_type** "`AMOUNT`" or "`CONTAINER`", which corresponds to "Molecule Observer" and "Container Observer in MoBi" (s. the [OSP Suite documentation](https://docs.open-systems-pharmacology.org/working-with-mobi/mobi-documentation/building-block-concepts#observers) for details).
* **is\_for\_all\_molecules**
* **dimension** dimension of the observer.

#### tab\_observer\_rates

Defines the monitor formula of the observer.

#### tab\_observer\_descriptor\_conditions

Defines criteria for containers where the observer will be created. Single container criteria are combined by "`AND`".

* **observer** name of the observer.
* **tag** is a tag of a container in which the observer should (or should not) be created.
* **tag\_type** Is always set to "`PARENT`"
* **should\_have** specifies whether the target container should or should not have the given tag..

### Entities defined by formulas

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-7a5b0d3c2b5ec7b759634f81dbc3aea998971252%2Foverview_formula_objects.png?alt=media)

The picture above shows an overview of all quantities which are described by a formula. Most tables are explained in other sections.

#### tab\_container\_rates

Is currently not used. This table was introduced to define some conditions which cannot be described by the boundary criteria (min/max) of a quantity. E.g. for the condition "Sum of compartment fractions of an organ = 1".

### Proteins

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-b7299440ce14a57a8804a510282d67a0980c95be%2Foverview_proteins.png?alt=media)

#### tab\_protein\_names

Stores the names of known proteins.

#### tab\_protein\_synonyms

Stores synonyms of the protein names.

**tab\_ontogenies** is described in detail [above](#tab_ontogenies).

**tab\_molecule\_parameters** is described in detail [above](#tab_molecule_parameters).

### Models

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-c79bb7277ad2b9c03a72e5a4582f6c0eee5fd84f%2Foverview_models.png?alt=media)

**tab\_models** defines available PBPK models and is described [above](#tab_models).

**tab\_model\_calculation\_methods** is described [above](#tab_model_calculation_methods).

#### tab\_model\_observers

Defines which observers are available for the given model.

**tab\_model\_species** defines which species can be used in combination with the given model and is described [above](#tab_model_species).

**tab\_model\_containers** defines which containers **can** be included into the final model and is described [above](#tab_model_containers).

#### tab\_molecules

Defines the **default** properties (start amount, *IsPresent*, etc.) for administered compounds and endogenous molecules. For each model container, these default settings can be **overwritten** by entries in [*tab\_container\_molecule\_start\_formulas*](#tab_container_molecule_start_formulas) and [*tab\_model\_container\_molecules*](#tab_model_container_molecules) (s. below)

* **molecule** the name of the molecule.
* **default\_is\_present** is the molecule present as per default.
* **start\_formula\_calculation\_method**, **start\_formula\_rate** defined the default start formula for the molecule. E.g. for administered compounds start formula is always zero; etc.
* **is\_floating** defines whether the molecule is floating or stationary.
* **molecule\_type** type of the molecule (administered compound, Enzyme, Transporter, etc.)

**tab\_model\_transport\_molecule\_names** restricts which molecules are transported by a passive transport for particular model and is described [above](#tab_model_transport_molecule_names).

#### tab\_container\_molecules

Used for referential integrity only; not exposed to PK-Sim.

#### tab\_model\_container\_molecules

Overwrites some default (global) molecule properties on the model container level.

* **negative\_values\_allowed** overrides the default setting (**FALSE**; defined programmatically and not in the database).
* **is\_present** overrides the global molecule setting defined in [*tab\_molecules*](#tab_molecules).

#### tab\_container\_molecule\_start\_formulas

Overwrites some default (global) molecule properties on the model container level.

* **calculation\_method**, **formula\_rate** overrides the global molecule start amount formula in [*tab\_molecules*](#tab_molecules).

### Tags

The picture below describes for which objects *descriptor criteria* (*descriptor conditions*) are defined in the database.

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-8062f4df47c33b316fb1b0a26822e093be19ee59%2Foverview_tags.png?alt=media)

#### tab\_tags

Defines all possible tags. The *name* of each container is added as tag programmatically in **OSPSuite.Core**. So there is no need to insert all container names into *tab\_tags* or *tab\_container\_tags*.

#### tab\_criteria\_conditions

Describes all available conditions. Each condition must be available in the [`enum CriteriaCondition`](https://github.com/Open-Systems-Pharmacology/PK-Sim/blob/develop/src/PKSim.Infrastructure/ORM/FlatObjects/CriteriaCondition.cs) in PK-Sim.

All other tables are explained in the previous sections.

### Value origins

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-bf5df69e4274db7c1a656ad5060bd11d92a96d18%2Foverview_value_origins.png?alt=media)

Value origin describes the data source of a value or formula.

#### tab\_references

Describes a data source (e.g. publication).

#### tab\_value\_origins

Describes available value origins.

* **id** is the unique id of a value origin. This id is used in all referencing tables.
* **description** is either empty or refers an entry in *tab\_references*.
* **source** must be one of the values define in [enum ValueOriginSourceId](https://github.com/Open-Systems-Pharmacology/OSPSuite.Core/blob/develop/src/OSPSuite.Core/Domain/ValueOriginSource.cs) (database default: "`Undefined`").
* **method** must be one of the values define in [enum ValueOriginDeterminationMethodId](https://github.com/Open-Systems-Pharmacology/OSPSuite.Core/blob/develop/src/OSPSuite.Core/Domain/ValueOriginDeterminationMethod.cs) (database default: "`Undefined`").

### Representation Info

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-d2f087cb0736738de6272a6a31bece211b60f19b%2Foverview_representation_info.png?alt=media)

#### tab\_representation\_info

Defines the display properties (display name, description, icon) for some entities, which are not covered by other database tables.

## Full schema

![](https://4134099993-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fi85AaLJO3hahKDiryfwl%2Fuploads%2Fgit-blob-281d9b7b7e80e051f34e7cd2c3fa351554754227%2Ffull_db_tables.png?alt=media)

## Tables reference

* [Containers](#containers)
  * [tab\_container\_names](#tab_container_names)
  * [tab\_container\_types](#tab_container_types)
  * [tab\_organ\_types](#tab_organ_types)
  * [tab\_containers](#tab_containers)
  * [tab\_container\_tags](#tab_container_tags)
  * [tab\_neighborhoods](#tab_neighborhoods)
  * [tab\_population\_containers](#tab_population_containers)
  * [tab\_model\_containers](#tab_model_containers)
* [Processes](#processes)
  * [tab\_processes](#tab_processes)
  * [tab\_process\_types](#tab_process_types)
  * [tab\_kinetic\_types](#tab_kinetic_types)
  * [tab\_process\_descriptor\_conditions](#tab_process_descriptor_conditions)
  * [tab\_process\_molecules](#tab_process_molecules)
  * [tab\_process\_rates](#tab_process_rates)
  * [tab\_model\_transport\_molecule\_names](#tab_model_transport_molecule_names)
  * [tab\_transports](#tab_transports)
  * [tab\_transport\_directions](#tab_transport_directions)
  * [tab\_known\_transporters](#tab_known_transporters)
  * [tab\_known\_transporters\_containers](#tab_known_transporters_containers)
  * [tab\_active\_transport\_types](#tab_active_transport_types)
* [Species and populations](#species-and-populations)
  * [tab\_species](#tab_species)
  * [tab\_populations](#tab_populations)
  * [tab\_genders](#tab_genders)
  * [tab\_population\_genders](#tab_population_genders)
  * [tab\_population\_age](#tab_population_age)
  * [tab\_species\_calculation\_methods](#tab_species_calculation_methods)
  * [tab\_species\_parameter\_value\_versions](#tab_species_parameter_value_versions)
  * [tab\_model\_species](#tab_model_species)
  * [tab\_population\_disease\_states](#tab_population_disease_states)
  * [tab\_disease\_states](#tab_disease_states)
  * [tab\_ontogenies](#tab_ontogenies)
* [Container parameters](#container-parameters)
  * [tab\_parameters](#tab_parameters)
  * [tab\_dimensions](#tab_dimensions)
  * [tab\_container\_parameters](#tab_container_parameters)
  * [tab\_groups](#tab_groups)
  * [tab\_molecule\_parameters](#tab_molecule_parameters)
  * [tab\_container\_parameter\_rates](#tab_container_parameter_rates)
  * [tab\_container\_parameter\_values](#tab_container_parameter_values)
  * [tab\_container\_parameter\_curves](#tab_container_parameter_curves)
  * [tab\_distribution\_types](#tab_distribution_types)
  * [tab\_compound\_process\_parameter\_mapping](#tab_compound_process_parameter_mapping)
  * [tab\_container\_parameter\_rhs](#tab_container_parameter_rhs)
  * [tab\_container\_parameter\_descriptor\_conditions](#tab_container_parameter_descriptor_conditions)
  * [tab\_conditions (container parameters)](#tab_conditions-container-parameters)
  * [tab\_container\_parameter\_fcurves](#tab_container_parameter_fcurves)
* [Calculation method parameters](#calculation-method-parameters)
  * [tab\_calculation\_method\_parameter\_rates](#tab_calculation_method_parameter_rates)
  * [tab\_calculation\_method\_parameter\_descr\_conditions](#tab_calculation_method_parameter_descr_conditions)
* [Formulas](#formulas)
  * [tab\_rates](#tab_rates)
  * [tab\_calculation\_methods](#tab_calculation_methods)
  * [tab\_categories](#tab_categories)
  * [tab\_calculation\_method\_rates](#tab_calculation_method_rates)
  * [tab\_rate\_container\_parameters](#tab_rate_container_parameters)
  * [tab\_rate\_container\_molecules](#tab_rate_container_molecules)
  * [tab\_rate\_generic\_parameters](#tab_rate_generic_parameters)
  * [tab\_rate\_generic\_molecules](#tab_rate_generic_molecules)
  * [tab\_object\_paths](#tab_object_paths)
    * [Sum formulas](#sum-formulas)
  * [tab\_calculation\_method\_rate\_descriptor\_conditions](#tab_calculation_method_rate_descriptor_conditions)
  * [tab\_conditions (formulas)](#tab_conditions-formulas)
    * ["Black box" formulas](#black-box-formulas)
    * [Disease state parameters](#disease-state-parameters)
    * [Table formulas with offset](#table-formulas-with-offset)
    * [Table formulas with X argument](#table-formulas-with-x-argument)
* [Calculation methods and parameter value versions](#calculation-methods-and-parameter-value-versions)
  * [tab\_models](#tab_models)
  * [tab\_parameter\_value\_versions](#tab_parameter_value_versions)
  * [tab\_model\_calculation\_methods](#tab_model_calculation_methods)
* [Applications and formulations](#applications-and-formulations)
  * [tab\_formulation\_routes](#tab_formulation_routes)
  * [tab\_applications](#tab_applications)
  * [tab\_application\_types](#tab_application_types)
* [Events](#events)
  * [tab\_event\_conditions](#tab_event_conditions)
  * [tab\_event\_changed\_container\_molecules](#tab_event_changed_container_molecules)
  * [tab\_event\_changed\_container\_parameters](#tab_event_changed_container_parameters)
  * [tab\_event\_changed\_generic\_molecules](#tab_event_changed_generic_molecules)
  * [tab\_event\_changed\_generic\_parameters](#tab_event_changed_generic_parameters)
* [Observers](#observers)
  * [tab\_observers](#tab_observers)
  * [tab\_observer\_rates](#tab_observer_rates)
  * [tab\_observer\_descriptor\_conditions](#tab_observer_descriptor_conditions)
* [Entities defined by formulas](#entities-defined-by-formulas)
  * [tab\_container\_rates](#tab_container_rates)
* [Proteins](#proteins)
  * [tab\_protein\_names](#tab_protein_names)
  * [tab\_protein\_synonyms](#tab_protein_synonyms)
* [Models](#models)
  * [tab\_model\_observers](#tab_model_observers)
  * [tab\_molecules](#tab_molecules)
  * [tab\_container\_molecules](#tab_container_molecules)
  * [tab\_model\_container\_molecules](#tab_model_container_molecules)
  * [tab\_container\_molecule\_start\_formulas](#tab_container_molecule_start_formulas)
* [Tags](#tags)
  * [tab\_tags](#tab_tags)
  * [tab\_criteria\_conditions](#tab_criteria_conditions)
* [Value origins](#value-origins)
  * [tab\_references](#tab_references)
  * [tab\_value\_origins](#tab_value_origins)
* [Representation Info](#representation-info)
  * [tab\_representation\_info](#tab_representation_info)
