Different cardiovascular models for different clinical problems with different time-scales

edited February 2015 in General Discussion
This is a continuation of a conversation from another discussion, but I thought it deserved it's own thread...

Right now Biogears is " running anywhere between real time (1 second real time to simulate 1 second of our patient/scenario) to 5x real time (10 seconds of real time to simulate 50 seconds of our patient/scenario)" (Per Abray from another discussion)

I suggest that this is too slow to support many desired applications of Biogears for simulation-based learning. In my own work, I have simulated from a minute/sec up to an hour/sec depending on the clinical problem and it's natural time course. And indeed, Abray confirmed that they are working on optimizing the code, and also making it possible to swap out sub-models of differing complexity/resolution. The following describes a specific suggestion along the lines...

I would guess that the major reason for the current performance is the computational demand of simulating the cardiovascular system at a fine temporal scale. Clearly the temporal scale has to be very fine in order to simulate individual beats and ECG patterns, as you appear to be doing. Therefore the time slices (dt) are very small and the calculations intensive, and so it naturally takes a long time to simulate -- accounting for the current ratio of simulated:real time. Of course, if the Biogears folks tell me I'm mistaken in this assumption then you can ignore the rest of this and I'll just quote Rosanne Rosanadana and say "Never mind." ;-)

This fine-grained simulation of the cardiovascular system obviously makes good sense for training around acute trauma or cardiovascular insults, where the temporal details matter a lot and decision making has to occur on the scale of seconds-to-minutes. However, there are many clinical problems where this high resolution of cardiovascular function is not needed, and becomes a barrier to building effective learning simulations. This would include any clinical problem that evolves over hours -to-days such as poisoning, pain management, diabetes crises, kidney failure, etc.

With this in mind, I propose that you create an explicit, low-resolution cardiovascular model to use for these types of cases. One typical approach is to treat the cardiovascular system as a closed fluid flow system (with pump & compartments) in which heart rate and blood pressure respond to changes in volume and resistance at various points in the circuit (and vice versa), but only at a gross level -- you can predict current heart rate (and other system variables) but you can't represent individual beats (not mathematically anyway). One example of this approach can be found in Chapter 5 of Hoppensteadt & Peskin's "Mathematics in Medicine and Life Sciences", Springer, 1992. I've actually implemented this as a simple systems model.

I suspect that this one enhancement -- having two cardio models at 2 different resolutions, and providing a toggle to choose betwen them -- would relieve a lot of the computational load for clinical scenarios that don't require fine-grained modeling of heart function. I can't think of another physiological process that would even require the same fine temporal resolution as cardio function does.

I'd love to hear other thoughts on this...

andrew

Comments

  • Hello Biogears Engineers,

    Any thoughts on the idea I posted above? Is my thinking correct re calculation cycles required for the cardiovascular module? Are you already thinking of implementing something along the lines I suggest?

    It's impressive what you all are accomplishing here...

    Regards,
    andrew
  • edited March 2015
    I've been spending some time with the Biogears code and documentation and have a clearer idea of how things are implemented.

    It's clear that what I suggested above doesn't really make sense with respect to how Biogears is constructed. For two reasons:
    1) You already have a pump & compartments model with more compartments and more detail than what I describe above. And that's truly awesome, and very powerful.
    2) The detailed calculations for the cardiac cycle -- in Cardiovascular::CardiacCycleCalculations() -- appear to be tightly coupled with the rest of the computations under the cardiovascular system.

    I remain convinced, however, that it would be valuable to be have a "mode" in which the cardiac cycle is not modeled in detail, thereby allowing a larger time-step and making it feasible to simulate clinical problems that evolve over longer time frames. I hope to spend more time studying Cardiovascular.cpp to see if there are ways to customize how CardiacCycleCalculations() and its related functions work. My goal being to model just the average HR, BP, etc. without breaking dependencies throughout the rest of the cardiovascular system calculations. I'll keep you posted...

    andrew
  • I was able to spend more time with the code and documentation and have posted a proposed approach in the Cardiovascular folder here: https://www.biogearsengine.com/forums/discussion/12/proposed-variant-of-cardiovascular-module-without-an-explicit-cardiac-cycle#latest
Sign In or Register to comment.