Biogears as a server-side engine for browser-based medical training simulations?


First of all, I absolutely love the concept and goal of Biogears. One of the big challenges in developing training simulations is having the virtual patient dynamically respond to the injury and interventions in a clinically realistic way. This requires valid mathematical simulations to drive things behind the scenes -- but not everyone has the time, resources, or expertise to develop such simulations. Nor should everyone be "re-inventing the wheel". Enter Biogears ... and I find that to be totally awesome ;-)

I've downloaded the toolkit and SDK and have started exploring. I've posted to a couple other discussions some issues I've run into, which others have too. My particular interest is investigating whether I can wrap Biogears in some .net (C#) code so as to make it a server-side engine for browser-based training sims. The front end for said sims could be HTML5/Canvas -- e.g., using EaselJS -- or it could be Unity3D exported as HTML5. (Or Flash, of course, but no need to elaborate on that...).

Along these lines, I have some questions for the Biogears team (or for others who may be exploring similar concepts):
1) To what extent is this an explicit goal for Biogears? Have you investigated this possibility internally? Or have you possibly already decided it is not a feasible objective?
2) Clearly the current implementation does not perform well enough to serve as such an engine. Here I'm referring to the current slow speed of execution which has been noted and confirmed elsewhere. I understand there are plans to optimize the code and improve performance. Is it an objective to have it run fast enough to realistically provide a flight-sim like capability?
3) Related to the above, it seems that part of the optimization may involve NOT having a single, comprehensive, mechanistically-accurate physiological simulation that serves all needs. Perhaps you are considering making it so only the minimally required simulation "modules" are loaded and used? Or perhaps creating a simpler (swappable?) components that are more phenomenological in nature and therefore less computationally intensive?

I'd love to hear any answers/thoughts on these questions that you are willing and able to share. In the meantime I'm going to poke around with creating a .net implementation if only as a crude proof-of-concept.

Thanks for taking on this difficult but important challenge!

Andrew Corbett, PhD
Davis, CA


  • abrayabray Entry Level
    Hi Andrew,

    Thanks for the enthusiasm for the BioGears mini build! We will be posting updates to our engine through out the year (one is due out next month!) And we will be releasing our Beta build this fall, so things are very much still a work in progress.

    To address your first and second questions/topics:

    I think BioGears easily supports the use case you have expressed. For example, the GUI toolkit provided is actually written in Java, as part of this implementation I wrote a wrapper in Java that exposes the engine controls interface directly for use in a Java based application environment. A C# wrapper could be created following this example. In the Source code download, go into the src directory, there are 3 folders: engine, gui, and cdm. There are Java folders in each of those. You can see the Java wrapper that provides the Java to C++ interface under the engine folder. You should easily be able to set up a C# container that holds an instance of a BioGears engine.

    At this point you should become familiar with the general engine interface, it is located under in the source code here: src\cdm\cpp\PhysiologyEngine.h and it was written to be able to drive the engine much like a flight-sim capability. Your first task would be to provide a simulation 'heart beat', be it from the server side or as part of your wrapper in it's own thread (Call advance time at your desired frequency). You can also see in the Java code how I push data back to the Java side from the engine. It is sampled, but works very well for our GUI. You can balance this communication per your application requirements. Note that our engine currently computes data at a rate of 1/165s (That amount of data can be overwhelming)

    Note that BioGears DOES run faster than real time. It does take a minute or 2 of clock time to stabilize the engine, but we are simulating about 3 to 4 minutes of the body for it to stabilize. We are working to lower this stabilization time, as well as speed up our engine in general.

    The next step is to pass instructions to the engine for it to act upon. The instructions are know as 'Actions' in the BioGears architecture. Actions are defined by a schema here: src\cdm\xsd\PatientActions.xsd (there are other action types, such as anesthesia, but the patient ones are usually what you want)

    Since you will need to cross language barriers between your C# and the C++ engine, the xml standard is helpful in provided a language agnostic form for instructions. The actions are small can be quickly serialized and processed between languages, but if you really have a need for speed, you can implement specific action handling methods in your C# wrapper to efficiently handle high frequency actions. But most actions are not high frequency, and once that are (for example CPR) have an sibling action that does not require a real time pressure source that would be required by a manikin. Under the src\cdm\java I have implemented many of the actions for use from the Java side. Note that although we currently DO NOT pass these over in a 'flight-sim' like manner from the GUI, doing so would not be too difficult, and I may extended the engine interface to handle this better.

    I think that should get you started to use BioGears for your intended purposes. It should be pretty straight forward, and we have plans to make this even easier in our architecture in the near future. I could also get into a few more levels of detail for you as well.

    As for your third item:

    I do believe we have a comprehensive, mechanistically-accurate physiological simulation that serves many needs, and we also do allow for swappable components that may be either lower or higher fidelity. (In the future, our beta build will have more to address this, if you want specifics, please let us know) The architecture is centered around a validated simulation of a healthy body's cardiovascular, respiratory systems. (At a certain fidelity level as described in our methodology, NOTE we also simulate other systems, but those two are our core) This design helps to generically supporting modeling of various reposes for specific patient insults. I believe we have designed the our system so that, if a certain insult is not currently supported, there is a consistent integration path for extending the engine to support new insults. We are not currently providing mechanisms to turn on and off various systems, they are all always running during a simulation, but you are correct in that it could be a method of optimization if you know you will not need the modeling of a particular system, and validation requirements can still be met.

    Thanks again for your interest!
  • Hi Abray,

    Thanks for the encouragement and all the useful details and pointers. That will do a lot to get me rolling.

    Regarding "flight-sim" capability... I'm happy to hear about the plans for increasing execution speed and particularly the ability to swap in modules of varying fidelity depending on the purpose.

    In my own work, my simulation engines have needed to run much faster than real-time in order to provide a viable learning experience -- i.e., one that doesn't take too long. In fact, one of the big problems I've faced is the need for the sim to run super fast at some times, then close to real time at others, depending on the rate of change in the patient and/or the frequency of required interventions. So, in my mind, it would need to be able to simulate from a minute/sec up to an hour/sec depending on the clinical problem and it's natural time course. Of course this wouldn't be the case for applications with manequins, or for teaching mechanistic physiology, or doing research -- but for online training simulations I think this would be the target. Is your thinking or experience different on this?

    Just for full transparency, I'll say that I'm an independent contractor and don't have an immediate project for which I am pursuing this idea. However, the value is imminently clear to me and I'm taking the view that "if I build it they will come". Also, while I've done tons of web-application programming at many different layers, this particular challenge is new territory for me (i.e., building a server-side engine around your Biogears code) and so your comments are very helpful and I may pick your brain further if I get stuck, if that is ok.

    Thanks again,
  • edited February 2015
    I understand that there will be a new release within a month or so. I think it makes sense for me to hold off attempting to create a server-side engine until that release comes out.

    I have further thoughts on optimization, but I'm moving that conversation to another thread.

Sign In or Register to comment.