6 more reasons to apply SD to medical research

@SDWisdom Ken Cooper lists 6 good reasons to apply System Dynamics to medical research. I think there are more if you broaden the definition of ‘medical’ :

7. Dose titration can be dynamically complex and subject to misperceptions of feedback; models make it easy.

8. Chronic autoimmune and mental health problems are embedded in a nest of feedback between the disease and the person’s environment.

9. ERs, hospitals and other delivery systems are loaded with delays, feedback and nonlinearity.

10. Smoking, diet, exercise, and other big health drivers are social phenomena.

11. Diet and exercise are entangled with other systems, like urban design and energy efficiency.

12. The health insurance system, especially in the US where it has evolved into a mess, can’t be redesigned without a systemic perspective.

6 thoughts on “6 more reasons to apply SD to medical research”

  1. Tom, how is #7 different from PBPK work as done with tools such as GNU MCSim? See, for example, https://www.ncbi.nlm.nih.gov/pubmed/19912164 and https://academic.oup.com/bioinformatics/article-pdf/29/3/400/713637/bts671.pdf. Perhaps you’re proposing that such approaches should be used more, and I won’t disagree. MCSim, though, is a perfectly acceptable text-mode SD simulator developed for PBPK without, AFAIK, any knowledge of the field of SD.

    1. I agree that PBPK is essentially the same thing, and probably more advanced in many ways. However, there’s a big difference in emphasis. Per my other post today, PBPK (at least the small amount of the literature I’ve seen) is exclusively focused on the physical side. SD has people in the loop. This is absolutely crucial. (I have personal experience with a series of doctors failing, on a rather spectacular scale, to manage basic bathtub dynamics. Evidently medical training is ineffective on this point.)

      I’m sure you can put the people, or at least the dose titration rules, in the loop in MCSim, but at some point a text-only language is very limiting for communicating and validating what’s going on, so there’s a big role for the SD approach.

  2. I think I agree with all your points. In thinking about fostering change in the medical field, though, I wonder if it’s more effective to say “Look! You can apply this PBPK stuff to hospital management; all you have to do is recognize that doctors and nurses also act according to these sorts of dynamic principles (accumulation, delays, feedback), too” than to say “To get better, you need to confess your inability to think in bathtubs and learn this new field which we can teach you” (which happens to be PBPK applied with a broader boundary).

    Yes, there are certain advantages to a graphical language, but I discovered something important to me with GNU MCSim. In my first model, I wrote the model, compiled it, and set it aside. Then I thought about the types of experiments I wanted to run. A factorial design came to mind, which I coded. Then I ran the suite of models (the entire factorial design) with one command. Then I applied whatever analysis tools I was using at the time to the collection of data that came out of a suite of runs.

    And then I realized that was the first time I think I had started an SD modeling exercise with a designed experiment, and it felt better! It also felt faster: the model, once developed and compiled, was a relatively static system, while the experiments changed more rapidly as I explored new questions. When I had enough information, I went back and recompiled the model and kept asking new questions. The process helped me separate model design and iteration, model experimentation, and experiment analysis in ways that helped me. I had /more/ iteration, but it was better organized and, as a result, it seemed to go faster. I did end up hand-drawing diagrams, though.

    It and other related approaches also enable multilevel modeling (“partial pooling”), which I think will be important for estimation and understanding in the medical / healthcare domain, and I don’t know how to do that in a conventional SD simulator.

  3. Perhaps to set the record straight, I do use Vensim as my predominant simulator and have used iThink in the past. This sort of simulator does bring great advantages: a graphical picture works well for communication with others, Vensim’s capabilities in dealing with units and units checking leads to improved models, automatic equation sorting really helps, integrated analysis tools help especially in working with groups, views or other ways of organizing complex models is really useful as models grow, and so forth.

    My two key points in inverse priority:

    – I surprised myself how much I learned about the way I model by switching to MCSim for a bit. I think that was beneficial, and I don’t think text-mode models are as bad as some fear. Of course, I could do that in Vensim, and I rarely do.

    – I’ve seen power in helping others see that SD isn’t (necessarily) a whole new paradigm but an extension of what they already know. For example, I once showed an engineering manager who had been a controls system engineer a graphical portrayal of his problem as a feedback system. Once he saw that, he caught on, and I didn’t need to say anything else to persuade him that the solution the model was suggesting was credible. I showed someone familiar with PBPK modeling an SIR model, and he was surprised that someone doing business modeling was familiar with epidemiological modeling. When I pointed out that you could use such models to model the adoption of new ideas or new products, he caught on.

    1. We really need to have our cake and eat it too – wrap visually constructed models in experimental design suites more easily.

Leave a Reply to Tom Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.