A list of parameters with "non default" values should be available

[ju-rgen]

Similar to the Favorites list there should be an entry “Non defaults” in the Parameters tree, which displays all parameters with values different from PK-Sim default, simply identified by their “value origin mode”.

People are interested in those parameters, which are changed. So they should be easily accessible, even when not manually added to the Favorites view. By a good maintenance of the “value origin mode” this can be provided in an easy way.

[msevestre]

Assuming here this will be implemented only in Simulation and Spatial Structure views. Please let me know if this is not the case

[msevestre]

@ju-rgen @Yuri05

I don't think the "Value Origin Mode" property is going to suffice here since the value can be changed in PKSim as well according to other requirements (for example set to Internet, or Journal or whatever). That means that we need to track the origin of the parameter (PKSim or MoBi) separate from the origin of the parameter value

[ju-rgen]

Why not having this node in all building blocks, where Favorites are available?

Yuri05 and I had already discussions, whether the "Value Origin Mode" value is sufficient. We assumed, that other ways of determination would be quite complex and therefore this simple approach seems to bring most advantage at low implementation costs. I do not understand: Why should a user set Value origin mode from PK-Sim-DB to another value like Internet, when not changing the value at the same time?

[msevestre]

What is meant is: If the value origin mode changes everytime a value is set, we won;t be able to know if a parameter was a PKSim parameter or a new Parameter

Example: Parameter

• Lipophilicity (defined in PKSim, value Mode PKSim DB HAS no meaning whatsoever because it is a user input). Yet if the user changes the lipophilicity in MoBi, we should display that the value has changed compared to PKSim. How?

• Volume Liver (defined in PKSim, value Mode PKSimDB makes sense). Now, the value is overriden by the user in MoBi and the mode goes to "Internet" or sthg. There is no way to know, that this parameter came from PKSim originally

[msevestre]

@ju-rgen See our discussion today regarding compound parameters. Not all parameter coming from PKSim have the ValueOriginMode set to PKSim DB.

If the requirement is "Track all PKSim parameter that have changed", we need to define another flag in a parameter "Created in PKsim or MoBi".

otherwise, this requirement needs to be specified again

[msevestre]

@Yuri05 Label risky set because the requirement is not clear

[msevestre]

@ju-rgen Could you try to answer some of the questions below? As a reminder, not all parameters have default values. This requirement is still unclear

[ju-rgen]

The focus is not to identify parameter which have changed after switching from PK-Sim to MoBi.

Instead, the focus is to list all parameters entered explicitely by the user (in contrast to values taken from DB or program defaults). Because those values may need in general to be justified to authorities. (And yes, I am aware, that the usage of default values can require also some justification, but you are normally more suspect of trickery if you change default values.)

So in your two examples both values, the Lipophilicity entered in PK-Sim and the Volume Liver changed in MoBi should have Value Origin Modes != PK-Sim DB / Default, but "Assumption","Internet","Project data" or similar.

Does this answer the question?

[msevestre]

That means that all compound parameter will always be listed (Lipo,MW, solubility etc...) In that case. Is this what is expected? That seems a bit odd to me to be honest because the list will always be quite long....

[ju-rgen]

Hope this list will not get too long (6-10 values per compound, values calculated by PK-Sim formulas should not be displayed), but yes - this is expected. For all these values the modeller needs to set values and document their origin. In case people are interested only in the non Molecule values, it seems to be easy to filter that table - or not?

[msevestre]

it seems to be easy to filter that table - or not? Not as easy as it seems as the info is not available off hand especially in the simulation where the connection to the building block is not available anymore.

But ok, issue is clear at least

[msevestre]

Implemented in PKSim in the Individual and Simulation