I’m happy to say that some of the questions I posted on the Cardiac Simulation LinkedIn group have garnered some answers. In particular, the discussions about modeling tools for cardiac simulation and source code access have had some traffic from the developer of CESE and CESE Plus. We’d love to get your opinion on those and other subjects — come sign up! Elizabeth Lipke and Xiao Jie have recently joined the group.

Most of the modern meshing done by CardioSolv and its members is done using a software package called Tarantula. It was used in many of the publications listed on this site. We are now happy to announce that through a partnership with CAE Software Solutions, we sell and support the Tarantula package. It is an excellent companion to our CARP solver, enabling the creation and use of realistic models from medical images. For more information on Tarantula, please see the Tarantula page on CAE’s site.

Researchers at the University of Leeds have announced the development of a new, portable magnetometer that could be used to detect regions of ischemia and other heart conditions in an economical and portable package. The article is light on details, but more will certainly be forthcoming.

If you’re interested or involved in cardiac simulation, and not yet a member of the new Cardiac Simulation Group on LinkedIn, follow the link and join! We’ve got 30 members so far, representing a broad range of companies, academic institutions, and interests. The group also features news feeds from useful Google and PubMed searches, helping you keep abreast of the latest in the field. You are welcome to submit your own news stories announcing your latest relevant publications, or interesting articles that you write or find on the Web.

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 watch the news for cardiac electrophysiology-related stuff, and most of it is press releases from this or that company about their new devices, but this article on theft of “crash cart” defibrillators is one of the more bizarre things I’ve seen. They say that it’s not affecting patient care, as they have more, but what if someone stole one and then a code was called. Someone could go to grab the crash cart only to find it missing (or defibrillator-less).

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.

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?