The authors of ionic models (see also the list of ionic models we currently offer) are typically wet-lab savvy — they patch-clamp cells and run special experiments on them, stepping voltage up and down and whatnot, to understand the behavior of the ion channels in the cell’s membrane. They then assemble what they learn into a system of ordinary differential equations using Hodgkin-Huxley and Markov network formulations. These systems may be solved using a number of methods to reproduce with some degree of accuracy the electrical (and electrochemical) processes that take place in such a cell.
A number of methods for publishing ionic models exist, as highlighted in a recent discussion in the Cardiac Simulation LinkedIn group. Sergey mentions in particular MIRIAM and CellML. Our own Rob Blake has highlighted some of the pros of CellML on this blog. I must prod him to highlight also the significant cons. The most basic methods of ionic model publication are the inclusion of variables and equations in papers, and the publication of original code. For an example of how the equations and variables are normally published, have a look at the Luo and Rudy Dynamic (II) model (PDF) paper, starting on page 16, in the Appendix. Alternatively, Kirsten ten Tusscher has published C++ source code for her models. We have used that source code, for example, to thoroughly validate our TT and TT2 models.
I am generally a proponent of the publication of working ionic model code, specifically that used for the plots and other output in the corresponding publication. As any scientist who has ever written code and published something related knows, by the time the relevant paper is published you will have forgotten much of the details around running your own code. If you ‘clean it up’ a bit and post a single, supposedly-final version of your code with the article, it’s quite likely something will be off a bit from the ‘live’ code you used while writing the paper. But even that is better than trying to go back and extract the equations from the code after you’ve got everything working correctly. The wonderful thing about having such code available is that it’s possible to test new implementations against the original under all sorts of conditions, including disease conditions (for example, hyperkalemia) and extremely long run-times.
Have you published an ionic model? How do you feel about publishing code? CellML models? Equations? Have you ever tried to reimplement an ionic model from a paper? From a CellML model? How did it go?
Posted: February 19, 2010 at 14:36 by Brock Tice, VP of Operations
Tags: cardiac simulation, cellml, ionic models | Comments (0)
Simulation in Rabbit Ventricles
“Medical science is increasingly turning to computational models to study the possible effects of drugs and surgical interventions, before moving on to patient trials. One active area of research is in heart modelling. The structure of a patient’s heart can be obtained through MRI scans, this data is then placed on a computer and used to construct a model heart. Researchers can study the electrical activity in this model heart, which controls heart beats. Problems such as arrhythmia can be identified and possible surgical interventions can be tested on the model before being used on the patient.”
–Supercomputing Online, HPCwire, Nexxus Scotland
The linked articles (very similar to each other) are about the underlying simulator used by CardioSolv. It was developed primarily by two of CardioSolv’s founders, and is now in use by them both academically and within CardioSolv. The articles discuss academic use and development.
Posted: November 18, 2009 at 18:15 by Brock Tice, VP of Operations
Tags: cardiac simulation, CARP | Comments (0)
Perhaps you’ve heard about the passionate protests opposing animal research (and the counter-protests supporting it). Whether you’re opposed to animal research altogether, want to minimize it to avoid it as much as possible, or just want to avoid the cost and hassle,
in-silico research can help address your concerns.
Although simulation models are developed from animal (and human) tissues and tests on animals, it is now also possible to develop them without harm to either animals or people thanks to better non-invasive imaging techniques. Furthermore, only one animal is required to create a simulation model that can be used over and over again. The rabbit heart geometry information collected by Vetter and McCulloch in 1998, for example, has been used for hundreds of simulations within our lab alone, and has also been used in many other labs around the world. Only one rabbit was sacrificed for probably a thousand different experiments.
Generation of geometrical models (meshes, as opposed to cellular-level ionic models) using medical imaging techniques has other advantages. For example, models could be created from a given animal’s heart before, during, and after creation of an infarct, all from the same heart. If using excised hearts, a different heart would be required for each stage of infarction, and they could not be directly compared with each other in the same way that models from several stages in the exact same heart could be.
The FDA is interested in simulation data in support of device submissions. At a workshop this spring, numerous examples of simulation data in support of a wide variety of devices were presented. Two former members of the lab from which I graduated are currently employed at the FDA, and were at that meeting — there are people at the FDA who are very familiar with cardiac simulation. Simulations aren’t going to replace animal testing and clinical trials in FDA submissions any time soon. However, they can be used to reduce the number of animal trials you need to do, and can offer additional, cost-effective support of claims in device submissions.
How do you feel about animal testing? How much does it cost you in money and time?
Posted: November 16, 2009 at 11:00 by Brock Tice, VP of Operations
Tags: animals, cardiac simulation, geometry, meshes | Comments (0)
This is the second post in a series of posts about the hows and whys of cardiac simulation, both electrophysiological and mechanical. The first and previous post was Conceptual Background.
In this post, I’ll catalog the ionic models and plug-ins currently available for use in the CARP simulator.
Is there a model you’d like to use with CARP that’s not on this list? Please let us know!
Posted: November 6, 2009 at 13:50 by Brock Tice, VP of Operations
Tags: cardiac simulation, ionic models | Comments (0)
When modeling cardiac tissue, there are two dominant approaches: bidomain, in which both the intra- and extracellular spaces of the tissue are represented, and monodomain, in which only the intracellular space is represented. The bidomain approach is essential when the effects of stimuli, bath, or extracellular conductivities need to be considered. However, when the primary interest has to do only with wave propagation, monodomain is often sufficient.
Given bidomain’s greater realism, one might think that it should always be used. However, it comes with a much greater computational cost; bidomain simuluations are much slower than otherwise-identical monodomain simulations. Therefore, it’s important when setting up cardiac electrophysiology simulations to carefully consider which approach will work best.
Our simulator and web interface give you the choice. By simply checking a box, you can switch your simulation from monodomain to bidomain and back. You can also compromise by setting an option that will primarily use monodomain, but will use bidomain every few steps. This has minimal effects on the outcome of the simulation, but can reduce simulation time noticeably when compared with a full bidomain run. We’d be happy to discuss your simulation problem with you, and help you determine which type of cardiac simulation is appropriate for solving it. You can find our contact information here.
Posted: August 8, 2009 at 9:47 by Brock Tice, VP of Operations
Tags: bidomain, cardiac electrophysiology, cardiac simulation, monodomain | Comments (0)
