From Computing and Software Wiki

Revision as of 16:52, 28 October 2008

Introduction

This page contains answers to the Frequently Asked Questions about the Pacemaker Challenge. Before asking a new question by contacting Alan Wassyng or Mark Lawford, please Read The Fine Documents listed below. In particular, many questions about the requirements of pacemakers are answered in the recommended reference text Cardiac Pacemakers Step by Step, An Illustrated Guide by S. Serge Barold et al. ISBN 978-1-4051-1647-3.

Requirements

The basis of the system requirements are the following Design Input Documents (DID):

1. The informal English prose requirements document from Boston Scientific available through the SQRL Pacemaker Challenge website.
2. S. Serge Barold, Roland X. Stroobandt, and Alfons F. Sinnaeve, Cardiac Pacemakers Step by Step, An Illustrated Guide, Blackwell Futura, 2004. ISBN 10: 1 4051 1647 1, ISBN 13: 978 1 4051 1647 3
3. The Pacemaker Hardware Reference Platform Details - including the general overview document of the hardware reference platform, the circuit schematic and Bill of Materials (BOM).

The questions and answers are generally organized following the structure of the informal requirements document from Boston Scientific. In this section any references to sections or pages are for that document unless explicitly stated otherwise.

General Questions

• Why is the spec so non-specific? Why doesn't it tell me everything I need to know?
  A: The PACEMAKER System Specification is an sanitized editing of a real-world system requirements document, from which a real system-of-systems was designed, built, sold, and used.

Furthermore, the spec presumes the reader has domain knowledge to achieve its perspicuousness. This domain knowledge has been superbly summarized in a "cartoon" book, Step-by-Step (SbS), obviously derived from slides for a course for electrophysiologists who (will) use pacemakers to treat bradycardia. Many frequently-asked-questions reveal that the questioner has not read SbS, because the answers are contained therein.

As much as possible, the spec defines requirements, not design. Requirements define what a system should do; designs define how the system does it. Verification asserts the how meets the what.

• Why was the spec created?
  A: The impetus for creating the spec was to provide a subject for the demonstration of formal methodologies on a real-world problem of tractable size. The properties demanded in Section 5 would be translated into a mathematically-precise notation (requirements); a mathematically-precise implementation would be claimed to uphold those properties (design), and some formal verification method (model-checking, proof, etc.) that the design meets its requirements.
  During the arduous process of sanitizing a Company Confidential document to get approval for public release, no alternative uses of the spec were envisioned. That the spec would be used as subject of senior EE hardware design projects, senior software engineering projects, IEC62304 tutorial, or student contest at ICSE was unanticipated. Let SQRL know if you use the spec for some other purpose.

Section 2.5.2 Implant Phase

7. Testing the system sensing and pacing efficacy.

• What kind of test is made?
• Which of these parameters are evaluated?
  A: See #6 in the section above 2.5.2

Section 2.5.3 Predischarge Follow-up (Page 12)

2. Reprogramming to final pre-discharge value

• Is there any special values for parameters?
  A. No. This just means that the doctor can change parameters after implant, but before the patient leaves the hospital.

Section 3.2.4 Printed Reports

1. A Trending Report shall be available.

• What is a trending report?
  

A. A trending report summarizes heart history since the last follow-up, typically three months. It will include histograms and sensor trending. Lead impedance and sense amplitude may also be included. SbS has other examples of data accumulated and reported. This is an area of implementer's discretion.

Section 3.4.3 Rate Sensing

• What exactly is a rate sensing?
  A. Rate sensing converts an analog voltage to a discrete sense event when that voltage exceeds a programmed threshold; the time between sense events determines the patient's heart rate.

• How are cardiac cycle lengths measured?
  A. The time between ventricular events is the cardiac cycle length, except for atrium-only pacing modes which uses the time between atrial events.

• Based on the event markers?
  A. Yes. VS/AS indicates an intrinsic contraction; VP/AP indicates a contraction caused by a pace.

• What is a rate detection decision?
  A. Choice of event marker. The timing of event markers determines heart rate in beats per minute.

• How do rate detection decisions affect the pacemaker behavior?
  A. Fundamentally. It determines how the device responds based on mode (DDD, VVIR, etc.) and the programmed timing parameters.

• “Rate shall be evaluated on an interval-by-interval basis.” Is there any defined interval for this measurement?
  A. The cardiac cycle interval.

Section 3.6.1 Permanent State (Page 17)

The normal pacing parameters programmed shall be used in the permanent brady state.

• Which are these normal pacing parameters?
  A. The ones that are currently programmed.

Section 3.6.2 Temporary Bradycardia Pacing

The temporary brady parameters programmed shall be used in the temporary brady state.

• Which are these temporary brady parameters?
  A. An identical set of parameters to the permanent parameters, but changes in temporary parameters do not affect permanent parameters.
  

The temporary state shall be capable of being used to temporarily test various system parameters or provide patient diagnostic testing.

• Which parameters are tested?
  A. Any or all parameters that the physician wishes to try temporarily.
• What is the "patient diagnostic testing".
  A. Testing impedance/amplitude/threshold.

3.6.3 Pace-Now State

The first Pace-Now pacing pulse shall be issued within two cardiac cycles plus 500ms from the time of the last user action required to activate the Pace-Now State.

• Can you explain this to me, please?
  A. The cardiac cycle is the time between cardiac events. If the Pace-Now-State is activated, the first pulse must occur within the time stated, measured from the time the activating action occurred.

3.6.5 Power-On Reset (POR) State

All functions shall be disabled until the battery voltage exceeds the POR trip voltage.

• What is a POR trip voltage?
  A. The minimum battery voltage necessary to pace.

3.7 Magnet Test

3. When the magnet is removed, the device shall automatically assume PRETEST OPERATION.

• What is the “PRETEST OPERATION“?
  A. Whatever the PG was doing immediately prior to the application of the magnet.

• What is changed in the pulse generator (PG)?
  A. Nothing.

• Do you have any more details for the Magnet Test?
  A. Putting a magnet causes a pacing rate indicating energy left (voltage) in the battery:
  • 100 ppm => beginning of life (new) (no batt voltage stated)
  • 85 ppm => elective replacement indicated (old) batt=2.654 V

4.4 Battery Status (Page 21)

1. Monitoring voltage information shall be provided

• How is this made? What kind of information shall be provided?
  A. There is an on-board voltmeter. The information provided shall be battery voltage.

2. Battery Status indicator information shall be provided.

• What is this information?
  A. How much energy is left in the battery. A typical visual representation is a “gas gauge”.

Section 4.5 Threshold Test (page 21)

• How does it happen?
  A. Loss of capture is observed by the change in shape of the ECG PQRS complex. See SbS 27.

• Which parameters are evaluated?
  A. Pace voltages and pulse widths.

• During this test, should the pacemaker change its current bradycardia state?
  A. Temporarily pace faster than the intrinsic rate (at which the heart beats unassisted).

Section 4.6 - Bradycardia History (Page 22)

• Which parameters are adjusted in this case?
  A. All.

Section 4.6.1 Rate Histograms

• I can’t understand what does mean: "Distributions shall be recorded for all ..."
  A. A histogram

• What is a paced event? And a sensed event?
  A. A paced event is the issuing of a pacing pulse. A sensed event is the detection of an atrial or ventricular contraction.
  Examples of histograms can be found on SbS 279-281.

Section 4.6.2 Rate Trending (Page 23)

The system shall be configurable to record and display the following data items separately or concurrently over a programmable duration and storage method: 1. Pacing rate 2. sensor data.

• Could it be explained in another way?
  A. Device records pacing rate and acceleration (in milliG); DCM displays charts with time on horizontal axis, rate and XL on vertical axis.

Section 4.6.4 Sensor Trending

The system shall provide off-line prediction analysis of sensor indicated rate with or without intrinsic rate for the synchronized data collected.

• Can you explain this to me, please?
  A. Sensor trending displays the motion detected by the accelerometer, and the corresponding rate paced. XL and rate are sampled periodically, and displayed together to help the physician adjust a patient's rate response parameters.

Section 4.7 Real-time Electrograms

• What are Electrograms?
  A. Electrograms display the voltages sensed by the PACEMAKER leads inside the heart much like an oscilloscope. PACEMAKER has two electrograms, one for the atrium and on for the ventricle. Electrograms are frequently displayed synchronized with one or more Electrocardiogram (ECG) signals measuring voltage change on the patient's skin. Real-time electrograms are displayed by a DCM immediately upon detection by the device. Transmitting real time electrograms demands much of the telemetry bandwidth between DCM and device.

Section 4.9 Faults and Error Handling (page 26)

• What kind of malfunctions must we handle?
  A: All faults that can occur that your system detect. Comprehensive fault collection and reporting are important criteria for design evaluation.

Section 5 Bradycardia Therapy (page 27)

• How do all the features and parameters interact?
  A: Non-trivially. In essence, each feature adds more rules about when to pace and when not to pace. As more rules are added, it becomes increasingly difficult to make them all true together.

In VOO mode with LRL=60 bpm, the only rule is to pace each second. In VVI mode, senses inhibit paces, the rule becomes to pace whenever neither a pace nor a (non-refractory) sense has occurred in the past second.

Rules that say: "inhibit, cause, or delay this action, when that occurs, except when thus" start to pile-up. That's what makes the spec a non-trivial subject for formal methods. Assuring that the device will satisfy any combination of features, is a challenge for validation as well as verification.

Time is what makes embedded systems fundamentally different from mere state transformation.

Section 5 defines all the timing behavior declaratively. It says what should result, not how to achieve it. Read them as invariants over the life of the device: LRL - there will be no duration of time longer than the LRL period without a heart beat (except for hysteresis pacing). URL - no paces will be faster than the upper rate limit. VRP - ventricular senses soon after ventricular paces or senses will be ignored

SbS has many examples, sometimes using slightly different names (AV interval instead of AV delay). Read the text starting at SbS 291 first, then read all of SbS from the beginning.

How the requirements in Section 5 are expressed in a formal representation demonstrates its power and expressiveness. Formal specifications should reference paragraph numbers so that they may be traced and validated. That a formal representation corresponds to its English-language equivalent should be self-evident.

Section 5.2 Upper Rate Limit (URL) (page 29)

This section said URI is the min time between a ventricular event and the next ventricular pace.

• Why is URI effective in modes without ventricular pacing nor sensing, such as AAT, AOO (Table 6, page 28)?
  A: “URI” should be “URL interval” in the question. For AAT, trigger paces must not be faster than URL. AOO is constant rate pacing at LRL. So long as LRL < URL (one of many implicit parameter constraints) AOO will pace slower than URL.
  The requirement could have been broadened to atrial-only modes. Alternatively, strict reading that URL does not apply to atrial-only modes is acceptable as well.

Section 5.3.3 Dynamic AV Delay (page 29)

When using Dynamic AV delay, the delay should stay between a max and a min value. In section 5.3.3, it says the way the new AV delay is calculated as follows:

"The previous cardiac cycle length is multiplied by a factor stored in device memory to create the dynamic AV delay."

• The range of values that such a factor can take is not specified in the

document. What happens if we multiply the cardiac cycle length by the factor and get a value outside the max/min range for the dynamic AV?
A. The factor must be calculated to stay within min-max. Hint: consider intervals at LRL and URL.

Section 5.5 Noise Response (page 30)

• What kind of signal the pacemaker should recognize to change its pacing mode?
  A: How noise (spurious signals) is detected is implementer's choice and responsibility. Asynchronous pacing is AOO, VOO, or DOO, depending on the programmed mode.

Section 5.6 Atrial Tachycardia Response (ATR) (page 31)

In section 5.6.1 of the document, explaining the AT detection algorithm, points 1 and 2 do not clearly define the start and stop of AT.

"1. AT onset shall be detected when the intervals between atrial senses are predominately, but not exclusively, faster than URL.
2. AT cessation shall be detected when the intervals between atrial senses are mostly, but not exclusively, faster than URL. "

The only difference between start/stop is "predominately" vs. "mostly".

• What is the interpretation of these statements?
  A. Both of those def'ns for ATR were deliberately fudged to hide the actual algorithm. In essence, the algorithm allows some slow beats among the fast ones to enter ATR, to leave it's the opposite. "predominately" and "mostly" were carefully chosen.
  The implementer gets to define the implementation, but it must be fast. 30s tracking Afib at MTR is really hard on sick patients.

• The definition of what the device should do for Atrial Tachycardia Response (ATR) leaves the algorithm for deciding when to mode switch loosely defined. Please explain why a physician would prescribe ATR to help me devise an algorithm that meets the requirement.
  A. In DDD mode, ventricular paces track atrial senses after a sensed AV delay. When the atrium naturally beats faster with exercise, ventricular contractions due to paces quicken in lockstep. For patients whose problem is poor conduction, this prescription restores people who could barely walk across a room, to normal life. Immediately. Many patients who got the real device felt like kids again, the day after implant.

Unfortunately, some patients can get electrical "storms" in their right-atria which if tracked, would inappropriately pace sick hearts at URL. Therefore, when the atrial rate is "too fast", ATR switches to a non-tracking mode, VVI. When the storm subsides, no longer "too fast", ATR switches back to DDD mode.

To prevent mode switching except for sustained atrial storms, the spec requires that the rate of recent atrial senses be "predominantly" faster than URL to switch from DDD to VVI, and "mostly" faster to stay in VVI. A possible, but not very good, algorithm for deciding when to mode switch, would be:

When at least 4 of the last 5 atrial senses have periods shorter than the URL interval (in ms), then ATR mode switch from DDD to VVI. When no more than 2 of the last 5 atrial senses have periods shorter than the URL interval, then ATR mode switch from VVI back to DDD.

All manufacturers of pacemakers use different criteria for ATR mode switching; all claim their criteria work the best, certainly better that the one above; and all meet the requirement as stated in the spec.

Sudden drops in pacing rate from URL to LRL are unpleasant for patients. Rate smoothing is often used in conjunction with ATR to moderate pacing rate changes arising from pacing mode changes.

Section 5.9 Rate Smoothing (page 35)

One of the questions we had for the pacemaker was regarding the rate smoothing algorithm. We were wondering if the pacing rate was suppose to increase based on a percentage of the current pacing rate or the rate we are suppose to be pacing at (Lower rate Limit).

A. The percentage is applied to the previous cardiac cycle. Although the physician may define up-rate smoothing of 3%, the period must decrease so that the rate is 1.03x faster => divide by 1.03 instead of multiply by 0.97. Rate smoothing is VERY important, trumping all other rate modifiers.

Hardware Reference Platform

Availability and Cost

• When will the pacemaker boards be available for purchase?
  A. There are a limited number of boards (43) available right now!
• How much do pacemaker boards cost?
  A. $350 (CDN) plus shipping. This includes programming cables compatible with the Microchip ICD2 and the PICKit2 programmer. We are selling these boards at cost. You are welcome to try to build your own but be forewarned that they use a lot of surface mount parts!

Getting Started

• What else do I need to get started?
  A. You need the following:
  • A power supply,
  • serial cable or USB/Serial cable,
  • a compiler or assembler that supports the PIC18F4520 microcontroller (e.g. Microchip's MPLAB C18 Compiler or the Small Device C Compiler (SDCC)),
  • and a PIC programmer/debugger such as the Microchip ICD2 or PICKit2.
  • We'd also recommend an oscilloscope and signal generator or computer with and A/D card and some software such as Labview. These are helpful for debugging and generating input signals.
• What are the power supply requirements?
  A. We recommend a 12V 150+ mA power supply with a standard 2mm jack. We have also run the boards off of a 9V 200mA adapter and a standard 9V (| PP3) battery without any problems.

How do I order pacemaker boards?

Send an email to Mark Lawford.