“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.

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?

Solution of the ODEs and PDEs involved in cardiac simulation is actually rather straightforward, and it’s been implemented over and over by many groups around the world. Even in my former lab, we used four different implementations during the course of my degree (some simultaneously). However, there are three major considerations that make implementation of a useful cardiac simulator difficult.

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?

The title of this blog post may seem to poke fun at simulations, but it’s based on a story recounted in a blog post entitled Simulation: Fact or Fantasy?. In it, Joel Orr describes a NASA engineer’s outrage at his use of the phrase “trial and error” to characterize the design process. The engineer asserted that error had no part in design.

The point that Joel was trying to make (and did make in that post), was that errors — when things don’t come out the way we expect — are valuable sources of information about designs and assumptions. Historically, obtaining such instructive errors required the development and testing of real-world prototypes. However, simulations of all kinds are enabling engineers to test virtual prototypes faster and at a lower cost than was ever possible in the past.

Think about the cost involved in testing even a prototype sensing and therapy algorithm for an existing ICD and lead. Some simple checks can be done by hooking up a programmed device to a pre-programmed input (this is simulation!). However, to fully test the algorithm, an animal study must be done. This brings in the costs in money and time of acquiring, caring for, and doing test procedures on a large enough number of animals to reach statistical significance. Testing the algorithm in a simulated heart requires only one model, whose shape, electrophysiological characteristics, disease status, and starting state may easily be varied over a wide range of parameters. It can be done in a matter of hours or days instead of weeks or months.

What kinds of errors are you taking too long to make now?

We’re developing a self-contained virtual machine image (using Sun’s VirtualBox platform) that will allow you to run an entire CardioSolv Simulation Manager, simulator, and model visualization tools (Meshalyzer) on your machine, just by loading it up in VirtualBox. We are looking for academic users interested in cardiac simulation that would like to test it out and are willing to give us feedback.

The image should be ready within the next two weeks. If you’d like to get on board for this trial of the most powerful, sophisticated, and thoroughly tested cardiac electrophysiology simulation package in the world, please fill out the registration form at the end of this post.

You must be

• A student, postdoc, or faculty member at an educational institution, planning to use the software only for non-commercial purposes
• Willing to install and use Sun’s VirtualBox software (which is free for personal and academic use)
• Willing to give us feedback on your experience with the system

(more…)

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.

• MBRDR Modified Beeler-Reuter-Drouhard-Roberge
• PASSIVE R/C circuit model
• COURTEMANCHE Courtemanche human atrial
• LRDII Luo-Rudy Dynamic guinea pig ventricular
• LRDII_F LRD_II with IK(Na)
• NYGREN Nygren human atrial model
• TT ten Tusscher human ventricular
• PUG Puglisi-Bers LRD_II with heart failure modifications
• RNC Ramirez-Nattel-Courtemanche canine atrial
• DiFranNoble DiFrancesco-Noble sino-atrial node
• TT2 ten Tusscher 2 human ventricular with improved restitution and calcium handling properties
• TTRED Simplified (REDuced) version of TT2
• Kurata Kurata improved sino-atrial node
• UCLA_RAB Shiferaw-Mahajan rabbit ventricular
• GW_CAN
• FHN_RMcC FitzHugh-Nagumo phenomenological model with undershoot removed
• MacCannell_Fb MacCannell fibroblast
• AlievPanfilov Aliev-Panfilov modification of FitzHugh-Nagumo phenomenological model to better match canine action potentials
• SC Shrier-Clay embryonic chick atrial
• LMCG Lindblad-Murphey-Clark-Giles rabbit atrial
• LR1 Luo-Rudy guinea pig ventricular

Available plugins:

• EP Krassowska non-resealing electroporation
• Muscon Hunter-McCulloch-ter Keurs fading memory muscular contraction model
• SAC_KS Kohl-Sachs Stretch Activated Channel, model parameters actually obtained from Tavi-Han-Weckstrom
• IF_KZP Zorn-Pauly human atrial If current
• EP_RS Debruin resealing electroporation
• IA shock-activated current Ia
• IFun hyperpolarization-activated “funny” inward current required for anode break excitation
• I_KATP Ferrero K(ATP) current
• I_NaH –
• I_ACh [ACh]-dependent K channel
• ExcConNHS Excitation-contraction coupling

Is there a model you’d like to use with CARP that’s not on this list? Please let us know!

Brock Tice, VP of Operations at CardioSolv, gave a talk on the titled topic at the University of Minnesota’s Department of Biomedical Engineering graduate seminar on October 19th, 2009. He covered some electrophysiology basics, then gave an overview of his last study as a graduate student (employing CardioSolv technology).

(more…)