1. Infusion Pump Controller Requirements Definition A Decision-Table Approach by Richard Riehle

2. CARA p Computer-Aided Resuscitation Algorithm p Purpose v Blood Pressure Monitoring v Prevent Hypotension v Fluid Resuscitation

3. Controlling Instrumentation p Infusion Pump p Physiological Monitoring Device v arterial line v non-invasive cuff v pulse wave v others may be added

4. Objective p Use results from PMD v Define acceptable range for BP v Detect out of range conditions p Activate M100 Infusion Pump v Fluid resuscitation measures p Log activity

5. Some General Software Guidelines p Safety Critical Application p Single Computer p Single-threaded Algorithm p Real-time v i.e. tight timing constraints p Must be used in Rugged environment p Remote Communication Option p Marginal User Expertise

6. Functional Software Guidelines p Data Input From Sensors v Single BP Reading p Visual Display of Data p User-controllable range settings p Error Detection v Is sensor behaving correctly? v Is M100 behaving correctly? p Proportional Close-loop Algorithm v drives M100 Infusion Pump

7. Software Behavioral Considerations p Many possible conditions v BP Readings may vary v Possible interruption for maintenance è e.g. change the IV Bag è change location of infusion tube p Relatively few possible actions v Actions require feedback loop for error control Question for future design: Can this be a cyclic executive design or do we need priority preemptive scheduler?

8. Approach to Requirements Definition p Possible Approaches v Structured Methods è Hately-Pirbhai Boeing Method è Buhr Machine charts v Object Modeling è UML and Use Cases è Schlaer-Mellor è CRC Cards v Formal Methods v State Based Modeling Real-time extensitions to Structured Analysis Method

9. Chosen Approach p State Based Modeling p Why? v Single-purpose algorithm v Not an object-oriented problem v Use case: interesting but unnecessary p Decision-tables Will Work Fine p Could also use formal methods, but v There are more conditions than actions v Timing issues are important v Overkill

10. Why Decision Table Approach? p Safety-critical permits no set of conditions to be overlooked. p Algorithmic implementation can map well to decision table p Facilitates Communication v Easy for customer to understand v Easy for programmer to understand

11. Decision Table Model - 1 Condition-1 T T T T F F F F Condition_2 T T F F F T T F Condition-3 T F T F F T F T Action-1 X X Action-2 X X Action-3 X X Action-4 X X X Action-5 X

12. Decision Table Model - Condition Stub Condition-1 T T T T F F F F Condition_2 T T F F F T T F Condition-3 T F T F F T F T Action-1 X X Action-2 X X Action-3 X X Action-4 X X X Action-5 X Condition Stub

13. Decision Table Model - Action Stub Condition-1 T T T T F F F F Condition_2 T T F F F T T F Condition-3 T F T F F T F T Action-1 X X Action-2 X X Action-3 X X Action-4 X X X Action-5 X Action Stub

14. Decision Table Model - Condition Entry Condition-1 T T T T F F F F Condition_2 T T F F F T T F Condition-3 T F T F F T F T Action-1 X X Action-2 X X Action-3 X X Action-4 X X X Action-5 X Condition Entry

15. Decision Table Model - Action Entry Condition-1 T T T T F F F F Condition_2 T T F F F T T F Condition-3 T F T F F T F T Action-1 X X Action-2 X X Action-3 X X Action-4 X X X Action-5 X Action Entry

16. Four Step Process p Define all the Possible Actions v (for ActionStubs) p Define all the Possible Conditions v (for Condition Stubs) p Determine which conditions are Possible v Eliminate those that cannot ever occur p Which Conditions trigger which actions

17. CARA Actions è Monitor Air Pump Line è Monitor Impedance Signals è Display Error Message è Trigger Audible Alarm è Set Alarm Lamp On è Monitor EMF Line è Keep track of infused fluids è Calculate and Log Volume Infused è Record when in manual/automatic mode è Monitor Blood Pressure è Log Blood Pressure reading è Record Source of BP Reading è Record time of BP Reading è Display BP Graph è Display Flow Rate Graph è Display Infused Volume Graph è Display Numerical values for BP, Infused Volume, etc. è Keyboard entry of BP to which CARA with titrate Not an exhaustive list

18. CARA Conditions è Current BP Reading in Range? è Pulse Wave Signal Detection? è Using Cuff Pressure? è Arterial Line? è Beat to Beat Source? è Valid BP Reading? è Cuff Frequency > Some Value? è Drop in BP Occurred? è In Autocontrol Mode? è Pause button Activated? Not an exhaustive list

19. Sample Decision Table for CARA BP <= 60 hg T T T T T T T T F F F F F F F F Valid BP F F F F T T T T F F F F T T T T BP => SetPoint F T T F T T F F F F T T T T F F Prev BP /= Current BP F F T T T F T F F T F T T F F F Action 1 X Action 2 X Action 3 X Action 4 X

20. Summary p Decision Tables are v Simple to Use v Easy to read p CARA lends itself to this approach v Cannot afford undiscovered conditions v Must match all actions to some conditions

21. Questions?