The study also found that more complicated devices were a strong predictor of complications. It was noted in the study that patients with more complex and severe problems typically require the more complex devices, making it difficult to ascertain whether the patients’ health or the devices were at fault. I can understand the motivation of the authors in choosing the wording of their conclusion, but I wonder if maybe it sounds a bit too certain without the caveats written in the article. They concluded, “Complications after de novo defibrillator implantation were strongly associated with device type. Major complications were associated with increased risk of mortality.”

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?

Due to problems with group spamming on LinkedIn, approval is required to join. However, anyone actually involved or interested in cardiac simulation will be admitted immediately. We hope to see you there!

I figure the thief is either ignorant of the devices’ use and just grabbed them as a target of opportunity, or they have some diabolical plan to shock people. It’s not like other hospitals are going to buy them, and I’m sure the property management departments of the affected hospitals have reported the serial numbers to the police, so there go pawn shops. Can you see the sales pitch on Craigslist — “Slightly used high-voltage defibrillators. Bring your patients out of cardiac arrest! Amuse and kill your friends!”

Here’s hoping that the new year brings an end to this senseless theft.

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.

Photo by Dave Morris (CC)

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?

1. Errors: Ionic models are notoriously finicky. Even the slightest typo in an equation can make the model behave incorrectly. If you’re lucky, it’s obvious, like if the cell doesn’t activate at all when stimulated. If you’re not so lucky, you might not even notice until after you’ve published a paper using a model that gives you physiologically incorrect results. Given all of the equations in one model, there are a lot of chances for something to go wrong. (Example: Variables and Equations in the second ten Tusscher human ventricular model) We have extensively validated the output of many of our models directly against the code written by the original authors of the models, to avoid letting any errors go undetected.
2. Features: Hard-coding a simulation that does something simple the same way every time is relatively easy. Writing a simulator that can stimulate using intra- or extracellular voltage constraints, intra- or extracellular current injection, and ground electrodes, with square, sinusoidal, descending ramp, and other waveforms, in an arbitrary model geometry is much more difficult. In each case the boundary conditions must be set differently. Meshes may have one or more regions and several types of elements (tetrahedral, hexahedral, etc). Integrated analysis tools such as activation detection and pseudo-ecg generation have become requisite for doing efficient, useful scientific work with a cardiac simulator. Most of these features are not inherently difficult to build, but there are many of them to implement and test, and that takes a lot of programming time. We’ve done all of this and more already.
3. Parallelization:
   

   Parallel machines are hard to program and we should make them even harder – to keep the riff-raff off them.

   –Gary Montry

   I know how to make 4 horses pull a cart – I don’t know how to make 1024 chickens do it.

   –Enrico Clementi

   For models the size of dog and human hearts, and smaller hearts at high resolutions, a simulation could not until recently be run on one machine. Such simulations cannot be run on a single processor in a useful period of time, even if the machine has enough memory available (and you’re not going to find a machine with uniform memory access times to memory banks that large). Therefore, to run such simulations, the simulator must be capable of parallel computing. This requires knowledge of programming in MPI and/or OpenMP, and debugging follows programming. Parallel debugging is a nightmare, even with good tools. Again, we’ve already done this and our simulator scales very well on the appropriate hardware (see the quote about 1024 chickens above).

When it comes to cardiac simulation research, you have two options. You can spend most of your time reinventing the wheel and what little time you have left doing science, or you can use a working, well-tested, preexisting simulator and spend a little time learning and a lot on the science. Which would you rather do? And which are you qualified for?