 |
|
| Home | Words | Letters | Cells | Objects | This Site | ||||
|
| ||||||||
The primary purpose of this "tutorial" is to help me begin to learn Python and at least one GUI tool set (wxPython). I am simply writing down my thoughts as I go along. There are many different kinds of data objects that would be useful (necessary) in the clinical setting, but I will begin with numeric values and numeric calculations. Most of the key concepts can be demonstrated in a simple application involving five numeric values.
The five numeric values to be handled by this demonstration app are:
Weight: _______ kg Rate: _______ ml/hr Time: _______ hr Volume: _______ ml/day Scaled: _______ ml/kg/day
Weight is a true independent variable entered by the clinician user. In a larger application, this value might be obtained from another outside source, but it is not calculated internally. The infusion rate is the independent variable that the clinician actually enters in order to determine the two derived values: volume and scaled volume. For the most part, the time will be constant (24 hr), but occasionally the clinician may choose to run the day's infusion over 12 hr or 20 hr instead of 24 hr. The volume is a true derived value calculated from the independent variables. The clinician really should have no reason to want to enter this value directly. In contrast, scaled volume is a derived value calculated from time, rate and weight, but the clinician usually thinks of scaled as the independent variable, calculating backward to get the necessary rate in order to administer the desired amount.
Since this demo applies to patients who are infants, the patient weight in kg is expressed to three decimal places (00.000). The infusion pump rate can be set the nearest tenth of an ml/hr (00.0). Time in hours is an integer value as are volume and scaled. The absolute lower limit for weight is around 0.350 kg and the absolute upper limit would likely be 10.000 kg, but the usual range would be 0.500 to 5.000 kg. Time will be from 1 to 24 hours inclusive. The scaled volume could possibly be as low as 5 ml/kg/day and perhaps as high as 400 ml/kg/day. The expected range for the volume will depend upon the weight, and the expected range for rate will depend upon the volume and the time.
The demo should allow the user to enter (and/or adjust) values for the independent variables, calculating and displaying the dependent (derived) values. In particular, the clinician will be able to change the patient weight and the duration (time) of the infusion, then change either the rate or the scaled volume, the application automatically calculating the other. Values outside the absolute range should not be accepted and values outside the expected range should be flagged in some way.
Much of the motivation behind this tutorial/demo is my desire to become familiar with the GUI toolkit wxPython. But even if I decide to use wxPython exclusively, I believe that the core of any application should be independent of the user interface (UI). I begin, therefore, by defining the classes necessary to carry out the functionality described above without regard to UI design or the GUI toolkit used to implement it.
Clinical calculations typically involve discrete fixed-point decimal numbers, (units which are tenths, hundredths or thousandths of some standard unit of measure). For example, many IV pumps can only be set to the nearest tenth of a ml/hr. On occasion the desired units are some other fraction of a standard unit, such as fourths of a gram, halves of a percent, or eighths of a liter-per-minute. In other words, clinically relevant numeric values are discrete (discontinuous) and of relatively low precision.
Standard floating-point operations provide continuous values of far greater precision than the clinician needs or expects, possibly leading to confusion or error. One method of handling this problem is to round off floating-point results to the appropriate number of decimal places explicitly at every step in the calculation. The alternative is to use integer arithmetic, explicitly keeping track of the scaling factors needed to maintain the appropriate units. Either solution works (at runtime), but both require considerable overhead at design time. The SmallDecimal class is defined to eliminate this overhead by taking care of rounding and scaling implicitly.
|
Under evolution 2001-05-31. Take One! © 2000-2001 Donnal Walter |
||||||
| Top of Page |  |
ASPN | FTP Works | Freeservers | XHTML 1.0 | Valid CSS |