Example Description
-The cardiac pacemaker-
Introduction
The human body is similar to a large software system comprising of many constituent subsystems. For instance, the excretory subsystem manages waste disposal from the body, the circulatory subsystem circulates the blood around the body, the respiratory subsystem handles air circulation, and the central nervous subsystem (CNS) coordinates the sensory requirements of the body.
Whereas the central organ of the CNS is the brain, the circulatory subsystem’s central organ is the heart. Figure 1 below shows how the blood flows in and out of the heart:
Figure 1: Flow of blood in the heart
Every beat of the heart is the result of an electrical impulse which starts in the right upper atrium. It is within this right atrium that a group of special cells called the Sino-Atrial node (SA) is found. This group of cells form the heart’s natural pacemaker. SA node cells initiate an electrical impulse in the heart muscle, stimulating it to contract. The SA node control the heart rate (how fast or slow it beats). The brain and other parts of the body send the SA node messages to speed it up or slow it down. In this way the heart’s rate of contraction is adjusted up or down to meet the body’s need for blood. When the heart is unable to adjust or regulate its own beating rate, doctors usually have to perform surgery on the patient and implant an artificial pacemaker to regulate the heart rate. In the following sections, we refer to this artificial pacemaker simply as the cardiac pacemaker.
Problem statement - The cardiac pacemaker
A cardiac pacemaker is an implanted device that assists cardiac function when underlying pathologies make the intrinsic heart rate too low or absent. In very simple terms, when we talk about a pacemaker, we really are referring to a pacing system which comprises of two subsystems:
1) The pacemaker subsystem which encases a pulse generator with a battery, a timer and a sensing device.
2) Pacing lead which carries tiny electrical pulses from a pacemaker to the heart (pacing) and also relays information about the heart's electrical activity back to the pacemaker (sensing).
A third important subsystem of the pacemaker is the programmer which a doctor or nurse uses to monitor, set and adjust telemetric data pertaining to pacing and sensing.
Depending on medical diagnostics, the doctor can programme the pace maker to pace the Atrium (mainly right Atrium), the Ventricle (mainly right Ventricle) or both (dual pacing) right Ventricle and right Atrium. To pace either an atrium or ventricle, the doctor must set the right pace maker component to monitor the heart’s electrical activity from that chamber. Depending on the sensed heart activity, the pace maker can either be inhibited (so that no pacing is done) or triggered (so that pacing takes pace) or triggered for one chamber and inhibited for another. Thus, a pace maker can work in a AVI, AVT, AAT, AAD, AVD, VVI, VVD, or VVT modes. For example, a pacemaker set to operate in VVI mode means that the ventricle is paced (the first V) if a ventricular sense (the second V) does not occur. If a ventricular sense does occur, then the pace is inhibited (the I).
Most of the time, a pacemaker waits for a sense event. When it decides to pace, the pacemaker conducts an electric current of a programmable voltage (called the pulse amplitude) for a programmable period of time (called the pulse width). Following a pace, the pacemaker is put into a refractory state for a set period of time, during which all cardiac activity is ignored. Following the refractory period, the pacemaker resumes monitoring for the next cardiac event. The rate of pacing is determined by the programmable pacing rate. The period of time the pacemaker will wait [in the waiting state] is computed based on the pacing rate and the pulse width. The refractory period is fixed.
Behaviour specification
This section endeavours to specify the desired behaviour of the cardiac pacemaker with a use case description. As said earlier, a use case description presents interactions between the users of the intended system (pacemaker) with the system. First, a stateless use case description is made and discussed. Secondly, a state-based description is constructed, enacted with a tailor made tool and also discussed to highlight the validation benefits accruing to this approach.
A stateless use case description of the pacemaker
The main components of a UML use case are actors and the use cases. Actors are users (human or otherwise) that interact with the system from outside the system. The system itself can sometimes be treated as special kind of an actor that interacts with its environment. The system in this case is a cardiac pacing system. A doctor or nurse (we refer to these generally as Physician) is the specialist who programmes and implants the pacemaker. A physician is therefore an actor in this system. In section 1 above, we referred to an electrical lead as a link between the heart and the pacemaker. The pacemaker device provides the electrical pulses needed to adjust pacing activity. Thus, the pace making system relies on the pacemaker device for electrical output. In this sense, we treat the pacemaker device (not the system) as an actor. This is all done to help the heart. Thus, we treat the heart as an actor.
We suppose that a patient has been diagnosed with bradycardia, a condition of the heart that necessitates the implantation of a pacing system. The scenario below shows how this is done through to how the pacing system works to help the patient:
CASE tools such as Togethersoft and Rational Rose support annotations alongside use case diagrams. However, this is not mandatory and analysts can easily construct their use cases without having to make any extra notes about key items. Since use case diagrams do not model interaction issues amongst the actors based on events performed, it is not possible to make out what actually happens to a pacemaker as a result of the physician actions (e.g. in event 1 above). In other words, what becomes of the pacemaker when it is programmed by the physician? How does it respond? Answers to the above questions would lead to determining what either the physician or the pacemaker is able to do next to help the heart condition. In the description above, it is as if each step is a self-contained process that need not relate with any other step. In some cases, the result of this presumption can be fatal, especially in mission-critical applications like the cardiac pacemaker. For instance, the last two events pertain to the pacemaker. In event six, the pacemaker will ignore any cardiac events simply because for that time the heart is supposed to be working well based on previous pace-impulse. However, it is not clear where the pacemaker will start when it resumes its pace making task. That is, event 7 must activate the pacemaker so that it can start monitoring the heart again. In a stateless description like the one above, it is not clear whether this requires event 2 to be conducted again, or event 3 or even event 1. If for instance it is event 5 that happens after event 7 occurring, then that can mean the heart will get paced when it is working normally thereby causing an abnormal heart rate, the very condition that is being monitored and mitigated. To understand how the various interacting actors should respond to each other’s events (to know what is viable and what is not viable), we re-write the description so that the internal state of each component is monitored and displayed as communication takes place via event transitions. This state-based description is then animated to prototype the implied behaviour.
A state-based use case description of the pacemaker
Physician programmes pacemaker’s impulse timer:à Physician (initial, impulseTimerSet); Pacemaker (initial, impulseTimerSet)
Physician sets pacemaker working mode:à Physician (impulseTimerSet, pacingModeSet); Pacemaker (impulseTimerSet, pacingModeSet)
Pacemaker interrogates the heart’s electrical activity:àPacemaker (pacingModeSet, awaitingHeartRate); Heart(awaitingPaceRequest, paceRequestReceived)
Pacemaker sends a pacing impulse to the heart:à Pacemaker(awaitingHeartRate, pacingImpulseSent); Heart (paceRequestReceived, paced)
The heart assumes normal rate:à Heart(paced, normalRateAchieved)
Pacemaker ignores cardiac events for a programmed period:à Pacemaker(pacingImpulseSent, atRefractoryState)
Pacemaker resumes monitoring cardiac events:à Pacemaker(atRefractoryState, awaitingHeartRate)
Figure 1 below shows the above description edited in Educator, a tool for authoring and enacting state-based use cases descriptions.
Figure 1: Scenario of a cardiac pacemaker
Figure 2: Enaction pane 1
Figure 2 shows the first available event (programmes impulse timer) and the current states of the primary (The Physician) and secondary (The Pacemaker) actors just before the event is undertaken. The Physician has to set the timer for the impulse timer of the pacemaker so that the pacemaker can monitor the heart rate for the specific heart being paced.
Figure 3: Enaction pane 2
Figure 3 shows that the current state of the interacting actors (The Physician and The Pacemaker) is impulseTimerSet. The event available is enabled so that The Physician can proceed with it.
Figure 4: Enaction pane 3
After pacing mode event is performed, The Physician is and the Pacemaker are both at the pacingModeSet state. The available event is to be initiated by The Pacemaker. At this juncture, The Heart is awaitingPacingRequest embodied in a signal from The Pacemaker. This is what interrogation does.
Figure 5: Enaction pane 4
The above enaction dialog shows that The Pacemaker sends a pacing signal to the heart and awaits the data pertaining the current heart rate. The Heart indicates at this stage that it has received the pacing request.
Figure 6: Enaction pane 5
The heart has now obtained normal rate and the state of the Pacemaker is similar to that of the heart. This is so because The Pacemaker must be aware of whether the heart has been paced or not.
Figure 7: Enaction Pane 6
The above dialog shows that The Pacemaker subsequently ignores sensing any heart activity for some finite time. This is because the heart will have been paced and should be working normal for that time.
Figure 8: Enaction pane 7
The Pacemaker has to resume its activity so that it can monitor The Heart’s activity and correct it forthwith. Therefore, The Pacemaker has to move from a refractory state (state where its not monitoring any cardiac activity) to a state where it can start sensing and sending heart rate.
Figure 9: Enaction pane 8
The point of rejoining is where it sends a pacing signal to the heart.
Figure 10: Enaction pane 9
The heart obtains its normal rate again.
Figure 11: Enaction pane 10
The Pacemaker ignores any further sensing for some time (like in Figure 7 above).
This loops over and over again as the heart demands pace making services from the pacemaker. Using this state machine model, we are able to determine the appropriate behaviour for a cardiac pacemaker based on enactable models. If the enactable model reveals that the observed behaviour is incorrect, the engineer and the physician can revise the description to correct the behavioural flaws. This might involve adding new states (or removing some existing ones), adding/removing some actors, adding new events or removing some existing events, or even changing the existing event relationship.