Preclinical Species vs. Human: Structural Insonsistencies!

[StephanSchaller]

Structures of PBPK Models across species are not consistent (unexpectedly!!). Animals differ from Human in 2 major parts of the model:

• GI Tract
• Glomerular filtration
• … and the missing (in animal) parameters: “Age”, “Height”, “MeanHeight”, “BMI”, “Gestational age” …

GI-Tract

Differences in the GI-Tract appear, but really are not that complex. For each Segment, the values of the reference values for these 5 parameters have to be “rewired”:

1. *|Organism|Lumen|Duodenum|Proximal radius
2. *|Organism|Lumen|Duodenum|Length
3. *|Organism|Lumen|Duodenum|Distal radius
4. *|Organism|Lumen|Duodenum|Default thickness of gut wall
5. *|Organism|Lumen|Duodenum|Volume (gut wall)

To do so, “Height” has to be set to zero and the following mapping rules (from the animal to human parameters) applied:

1. The constant „Proximal radius“ -> „r1_p0“ in the human model
2. „Length“ likewise -> „L_p0“
3. „Distal radius“ likewise -> „r2_p0“
4. „Default thickness of gut wall“ -> „Thickness_p1“ in human model (except for stomach, here map on „Thickness of gut wall)
5. “Volume (gut wall)” (used to calculate mucosa volume) is slightly more complex a. Human: V_intconstFactor b. Animal: V_intArea_i/totalArea_I (i = segment, I = total tract (small or large)) c. HOWEVER, using the Animal Formula for human results in about the same as with the constant factors (Table 6) d. --> Exchanged human with animal formula!!

Table: GutWall Volume calculation factors for Mucosa Volume. Comparing the existing constant factors ("HumConstFactor") with values derived from a formula ("HumCalcFacto").

V_GutWall Segment	HumConstFactor	HumCalcFactor	Difference (col2/col3)
*|Organism|Lumen|Duodenum	0,08700	0,0993	14%
*|Organism|Lumen|UpperJejunum	0,24900	0,2126	-15%
*|Organism|Lumen|LowerJejunum	0,18400	0,1989	8%
*|Organism|Lumen|UpperIleum	0,32400	0,2650	-18%
*|Organism|Lumen|LowerIleum	0,15600	0,2242	44%
*|Organism|Lumen|Caecum	0,08471	0,0732	-14%
*|Organism|Lumen|ColonAscendens	0,15529	0,2047	32%
*|Organism|Lumen|ColonTransversum	0,32000	0,3163	-1%
*|Organism|Lumen|ColonDescendens	0,24000	0,1534	-36%
*|Organism|Lumen|ColonSigmoid	0,13500	0,1899	41%
*|Organism|Lumen|Rectum	0,05500	0,0624	13%
Factor_total	1,99	2	1%

Glomerular Filtration

For the kidneys in humans, “GFR (specific)” is defined as:

• (PMA^Hill/(TM50^Hill+PMA^Hill)(1-GFR_premat)+GFR_premat) GFR_mat / V_kid_std
• We can take the constant “GFR (specific)” in animals, multiply it by the animal “V_kid” and map it on the “GFR_mat” in humans.
• “|Organism|Gestational age” (as “|Organism|Age”) should be set to zero,
• and “GFR_premat” should be set to 1.? --> or 0,258?
• animal “V_kid” needs to be mapped on the human “Volume (standard kidney)”

Feature suggestion

We should align model structures so that they become structurally identical

[msevestre]

@StephanSchaller

We should align model structures so that they become structurally identical

Could you explain why you need this? Model structure can and is different between species and even within the same species for different population (pregnant model) coming soon. Trying to align the structure (e.g. number of parameters, container structure etc.. ) for all species would be a nightmare and goes against the flexibility that we have managed to achieve in the suite.

Structures of PBPK Models across species are not consistent (unexpectedly!!).

Again this is by design. Why should all species have the same structure? Rat does not have a Gall Bladder for example.

[msevestre]

Also I cannot understand why you would want to define parameters such as BMI ,BSA, Height etc.. for all species .

[PavelBal]

Could you explain why you need this?

Well, this is what PBPK is about - translating between species. This works for PK-Sim models, but any (PD) model extended in MoBi cannot be easily translated because of the incosistencies. The required workflow could be as follows:

1) Create a PD (i.e., a disease) model in MoBi (see Glucose-Insulin-Model published here as an example) for any species. 2) Translate the model to other species by creating a parameter set through Matlab or R "createPKSimIndividual".

I think, everything goes down to the problem of not being able to create individuals (also of different species) in MoBi.

[StephanSchaller]

Parameters: “Age”, “Height”, “MeanHeight”, “BMI”, “Gestational age” … were just listed for the sake of completeness.

Now, to your other question. Maybe @Yuri05 can also comment:

I would like to change the species in MoBi Models, where I have coupled a number of PBPK Compound models with some complex additional reactions (e.g. for mechanistic pharmacodynamics).

Given the above mentioned structural differences I cannot even do this in MoBi, as a PSV building block from e.g. Minipig would not work with the original Spatial Structure from a human, right?

But, ... well I see while writing this, @PavelBal also answered ... and that's pretty much it: I want to change Species/Individuals in a scripted environment like MATLAB or R.

[StephanSchaller]

AND: @msevestre it is really not a nightmare! What I have listed above are the ONLY differences!

And I also have to contradict you when you say it "...goes against the flexibility that we have managed to achieve in the suite." The flexibility comes from the generic concept of PBPK and that builds on the idea that in principle all mammalian species have the SAME properties (structurally). In rats, the gallbladder has just withered away through evolution. And that's easily solved by a parameter but without changing the structure!

For extensions like e.g. pregnancy, it is no problem. We just have to make sure we can "switch them off" with a parameter. This is another issue and may be useful in the future but requiring a separate entry.

To retain the unparalleled powerful M&S framework of PKSim/MoBi we have to make sure we strictly stay generic!!!

[msevestre]

Thanks for the clarification @StephanSchaller and @PavelBal. I understand where you are coming from and why a unique structure would make scripting life easier. (I am not going to use the word generic because I believe we have a different understanding of what the word generic means here)

Where we are in agreement:

• @PavelBal mentioned earlier, inter-species scaling works well in PK-Sim and the issue seems to be very much related to PD extensions and scripting.

• @StephanSchaller proposed a way to unify the definition of the GI-Tract between species. This will have to be assessed by our GI gurus but this makes perfectly sense.

What I still do not understand

@StephanSchaller you said:

generic concept of PBPK builds on the idea that in principle all mammalian species have the SAME properties (structurally).

You also proposed to switched on and off specific model structure with flags set to 0

We just have to make sure we can "switch them off" with a parameter.

From the scripting point of view, I understand your point. But think about what it would mean with the platform that is open to model extensions. Think about the potential models for

• fetus (combines with mother model)
• prostate model
• Extended gonads models
• tumor
• a new lung model that is only validated for human (with extensive parameterization)
  • ...

In my opinion, adding all possible scenarios into a single structure and switching those features with flag is not an acceptable solution because of the added complexity and also the confusion it would create (Human Male with fetus model or Mouse with prostate). Nevermind the fact that regulatory authorities would probably very much dislike it.

Since it seems that the ultimate goal is to be able to change species from Matlab and R, maybe that is where improvement could be made. For that I need more input.

Here is what we have so far available in the OSP Suite in MoBi directly or via Matlab (and potentially R but I am not sure about that)

• generate individual and population from Matlab and setting the values in an existing simulation.

• use a PSV for Pig in a human model as far as I know. the PSV takes precedence over everything and overrides de-facto any spatial structure parameters. But if a parameter in the PSV is not found, it will be ignore (and if not, it's a bug:)).

• Also a well define PSV would override any formula or create formula instead of constant value

so the question that remains is: What is missing?

Cheers,

[StephanSchaller]

In my opinion, adding all possible scenarios into a single structure and switching those features with flag is not an acceptable solution because of the added complexity and also the confusion it would create (Human Male with fetus model or Mouse with prostate). Nevermind the fact that regulatory authorities would probably very much dislike it. <

I have to disagree. I believe this complexity can be handled quite easily. Call it object-oriented PBPK modeling. And more so within a framework such as the OSP. It will be consistent throughout all "features" of the OSP (In PKSim MoBi and via scripting in R and MATLAB). And I believe this is more intuitive and thus less confusing.

Also a well define PSV would override any formula or create formula instead of constant value <

"...well defined..." is exactly the problem. The PSVs carries the same structural inconsistencies as described above in my very first comment. They do not match and thus do not overwrite. Here the examples from above:

1. The constant „Proximal radius“ found in the Minipig PSV needs to overwrite „r1_p0“ in the human PSV
2. „Length“ found in the Minipig PSV needs to overwrite „L_p0“ in the human PSV
3. „Distal radius“ found in the Minipig PSV needs to overwrite „r2_p0“ in the human PSV
4. ...

But this is not possible given the different names.

generate individual and population from Matlab and setting the values in an existing simulation <

This only works "within-species"! The parameter set generated here is only enough to scale within the same species but fails to cover all relevant physiology to scale between species (I have already discussed this with @Yuri05 in a lengthy mail conversation).

so the question that remains is: What is missing? <

Same as before, a consistent model structure!

I know it seems complex at first, but we just have to think bigger!

Cheers!

[msevestre]

Call it object-oriented PBPK modeling

Well one of the most important principle of good OO programming is SRP (Single Responsibility Principle)... check it out when you have time.

Coming back to the issue at hand: Again, making sure that stuff that is the same BEHAVES the same is clear and I have no objection to that. The when, if and how this will be implemented need to be discussed but this absolutely make sense.

As for the rest, we will have to agree to disagree. In my opinion, managing complexity by adding it all in one place is not the way to go.

[StephanSchaller]

...one of the most important principle of good OO programming is SRP (Single Responsibility Principle)...

Makes sense, but I argue, that here, responsibilities don't change... the model ist still used under the exactly same principles (..of working with PBPK models) and for the same purpose (capturing PK data with PB principles), even when changing species.

...and what about the "Liskov substitution principle", where derived classes (species PBPK model) must be substitutable for their base classes (generic PBPK model)?

;-)

[msevestre]

Liskov has nothing to do with this.

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it

That would mean that if a method use a Generic PBPK model, it needs to run with the specific one as well (Mouse) without knowing it. Anyways as I mentioned earlier, we will have to agree to disagree

On Sun, Jan 21, 2018 at 11:09 AM esqlabs GmbH notifications@github.com wrote:

...one of the most important principle of good OO programming is SRP (Single Responsibility Principle)...

Makes sense, but I argue, that here, responsibilities don't change... the model ist still used under the exactly same principles (..of working with PBPK models) and for the same purpose (capturing PK data with PB principles), even when changing species.

...and what about the "Liskov substitution principle", where derived classes (species PBPK model) must be substitutable for their base classes (generic PBPK model).

;-)

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/Open-Systems-Pharmacology/PK-Sim/issues/378#issuecomment-359259427, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_jVdiFBLoMNi4wi1ePJl5E4DsRGD9jks5tM2FXgaJpZM4P0GLb .

[StephanSchaller]

...if a method use a Generic PBPK model, it needs to run with the specific one as well (Mouse)...

That's exactly what I want for the toolboxes ;-)

But whatever the argument for how this is solved (or not) it goes without saying, that it would be of great value to substitute/change the species in a MoBi PBPK/PD model without special and complex workarounds.

[msevestre]

The intent is clear. Bloating the model to support all possible current and future extensions for all species is just not the right way to do it. We need modularity and interoperability.

That's exactly what I want for the toolboxes ;-)

Feel free to submit pull requests. Community contributions is always welcome

[StephanSchaller]

We need modularity and interoperability.

Exactly. But in MoBi, we currently have neither (or at least very limited or cumbersome to achieve). We'll work on making the Toolboxes cope (see linked thread for Open-Systems-Pharmacology/R-Toolbox/issues/38 in RToolbox above)

[StephanSchaller]

NOTICE: We have "QCed" the scaling (as described above) of simulations (on R-Toolbox/xml-level) and it works. We have generated the "same" PBPK model for human and animal in PKSim and simulation results for "original" PKSim-derived animals and "original" PKSim-derived human scaled to animal (via R/Matlab and the described scaling routine) are identical.

BUT: as mentioned in R-Toolbox issue #39, this only works, if you Keep the structure "original", i.e. leave original formula-based parameters as they are!

[Yuri05]

I agree with @msevestre: it makes no sense to create "All in One" PBPK model. What we could do: align parameterization of the models for different species.

Means: if 2 models are structurally identical (same organs/compartments, processes etc.) it would be possible to switch between species just by applying a new set of parameter (start) values.

After alignment of parameterization it would be possible to scale between species by exchanging parameter start values in MoBi e.g. for:

• (non-pregnant) Human <==> Minipig
• Mouse <==> Dog ...

I would not be possible to scale between species by exchanging parameter start values in MoBi e.g. for:

• (non-pregnant) Human <==> (pregnant) Human
• Human <==> Rat
• Mouse <==> Rat ...

The scaling will also work only if parameter start values of both species were made for structurally identical models. E.g. after overriding a protein model for human with a parameter start values created for Minipig (but for small molecules model), the result will be incorrect.

[PavelBal]

Means: if 2 models are structurally identical (same organs/compartments, processes etc.) it would be possible to switch between species just by applying a new set of parameter (start) values.

Sounds great. For sturcturally non-identical models, changes must be performed on the Mobi/PK-Sim level, and not on the xml level.

[StephanSchaller]

What we could do: align parameterization of the models for different species.

Great. That's a start. I'll keep bargaining for the Rat...

E.g. after overriding a protein model for human with a parameter start values created for Minipig (but for small molecules model), the result will be incorrect.

Okay, that's a no-brainer.

[Yuri05]

@StephanSchaller I assume the new way of parameter splitting into SpatStruct and Individuals in V12 solves the issue. If not: feel free to reopen.