This is the first in a series of posts about the hows and whys of cardiac simulation, both electrophysiological and mechanical.

The heart is an extremely complicated organ. It’s composed of many different cell types, including cardiomyocytes, conduction system cells such as those in Purkinje fibers, fibroblasts, neurons, and adipocytes. However, the cardiomyocytes make up most of the weight of the heart, and are well-connected to each other by gap junctions. As a result, cardiac tissue can be reasonably well modeled as a syncytium (even though it is not a true syncytium as skeletal muscle is). This is usually formalized using either the monodomain formulation (which only considers current within and between cells) or the bidomain formulation (which also models the current outside of the cells).

Activity within individual cells is modeled using systems of differential equations typically referred to as ‘ionic models’ or ‘Hodgkin-Huxley-type’ models. These systems model how a cell moves ions around to effect changes in its transmembrane potential. It is fortunate that these models have been well-developed from their humble beginnings in the squid giant axon. Very sophisticated models of everything from said axon up to human ventricular myocytes have been created, based on patch-clamp experiments.  Changes in transmembrane potential in one cell create a potential difference relative to neighboring cells, driving the flow of current from one cell to another. It is this effect that couples ionic models to the tissue model described above.

The next post in this series will delve into the different tissue and cell models offered by our CARP simulator.

My name is Rob Blake, and I’m on the team here at Cardiosolv. I work on both the GUI software you’ve seen in the previous posts and our modeling code.

One of the strengths of our cardiac modeling software is the variety of membrane kinetic models that our users can choose from while running a simulation. These “membrane kinetic models” or “ionic models” are ordinary differential equations that describe how ions flow through the cell membrane and within the cell itself.   In the literature you can find models describing the electrical behavior for nearly every different type of cell in the heart.  You can find them for ventricular, atrial, and purkinje cells in a variety of species and in a variety of disease states.

Implementing one of these models from scratch takes significant effort.  The newer models all build on previous work, which means tracing back through multiple paper citations to find the original equations.   These equations are themselves complex– looking quickly through some of our models, I see that most of our models are composed on average of 150-250 equations just to describe a nonlinear system of 15-30 differential variables.  Papers also aren’t the best vehicles for describing the exact equations used.  Prose in the methods section can be ambiguous, and there might be inconsistencies within the paper itself.

Even if you have all the equations laid out clearly before you, you can still make a mistake while transcribing it to a computer.  Amidst 200 equations, you have plenty of opportunities for typos and omissions.  A single missing minus sign can invalidate all your results.  If you’re lucky, a typo will just cause the model to blow up and produce obviously incorrect results.  If you’re unlucky, then a typo could disable an effect that only shows up in pathological circumstances and you’ll never realize your error. Furthermore, it’s very hard to get feedback as you are developing the model.  With the way these models are designed, they either work perfectly or they don’t work at all.  If one differential variable becomes corrupted, it will often affect every other differential variable within 1-2 small steps of the code.  This makes it very difficult to trace back to the cause of an error.

In recent years, implementing these ionic models has gotten easier thanks to CellML, developed by the Auckland Bioengineering Institute. CellML describes these membrane kinetic models unambiguously so you don’t have to trace back through the literature.  CellML group has hundreds of models from published papers available.  For each model, they provide a link to the academic reference, a list of all the equations of the model, and sample code that will help you get started using the model within a package such as CVODE.  From their homepage you can download programs that can read in the CellML file and do simple simulations.  They also mark up which CellML reproduce all traces from the papers in question.

CellML has come leaps in bounds in recent years.  The code generation and the validated traces have only emerged within the last 1-2 years, and with them the typos in CellML have decreased dramatically.  I used to set aside 2 weeks to implement a cellular model from scratch using the equations from CellML as a starting point.  Now I can convert a CellML model into working code in a matter of hours. The site is a boon to researchers.  It allows them to focus on the biology instead of programming.  It encourages collaboration and cooperation amongst scientists and makes their results more accessible for everyone.  I don’t have enough positive things to say about CellML.  I find it essential in my daily work.

Despite all the good things I have to say about CellML, I do have some minor gripes about its design from a end user’s standpoint.  I’ll cover these minor complaints in my next post, along with tips and tricks we use here at Cardiosolv to get around these problems.

Have you ever had an idea for changes to a device, or a new experimental protocol, and wanted to test it? Did you balk at doing an animal study, given the time and money required?

One excellent use of cardiac simulation is to test out new ideas and compare prototypes. It’s not usually necessary to set up a fully realistic simulation or use an animal model to find out if your intuition about an idea is right, or if making a certain change to a design has the desired effect. Using cardiac simulation with our web-based simulation manager, you can easily set up a test, start it running, and have some results when you get back from lunch (or even a coffee break, depending on the size of the simulation and your computational budget). Or you could start doing the paperwork for an animal study. Wouldn’t you rather the simulation scenario?

Of course, the initial creation of a model to match your prototype could be a bit difficult if you haven’t done it before. We can generate appropriate models and get everything set up for you.

It’s also important to recognize that simulation won’t replace an animal study for final vetting before working with human subjects; however, it can save you costly iterations with animals and leave the animal study for final validation.

If you’d like to discuss setting up simulations for your problem, please contact us at +1 (888) 525-2232 or info@cardiosolv.com.