If a patient monitor claims that it can measure heart rates from 15 to 300 beats per minute, you–as a patient or health-care provider–want to be sure that it can. Consequently, some way of validating the monitor’s performance is essential.
Validation is a much abused word these days in the medical-device industry. The idea is simple: test the product against its requirements. But it is the many critical requirements and variables involved when dealing with human life that compound the difficulties of validating the results.
To appreciate the validation process, look at how two organizations explain it. The FDA defines validation, with respect to a device, as “…establishing and documenting evidence that the device is fit for its intended use.”1 ISO 9001 says “…validation shall be performed to ensure that the product conforms to defined user needs and/or requirements,” and is normally performed under operating conditions on the final product.2
To add fuel to the fire, tests also must be devised to show predictable operation outside these limits. When each of the requirements is proved in this manner, the quality of the product is enhanced and the evidence of compliance to specifications satisfies international regulatory agencies.
Modern patient monitors are often multiprocessor designs with specialized instrumentation front ends. Custom display systems accommodate the need for real-time data acquisition, digital signal processing and instantaneous display of waveforms and calculated data.
Most monitors measure respiration, pulse oximetry (SPO2), invasive and noninvasive blood pressures, temperature and cardiac output (ECG). To test such a device in the manner that it will be used presents some challenges.
Automated Validation
It is virtually impossible to fully test most products with off-the-shelf test tools. For the automated testing of a patient monitor, two elements are needed:
A remote-control interface which affords computer control of the normal user interface and computer access to all of the calculated parameters on the screen and audible alarms.
A patient simulator that presents the electrical load of the sensors, generates physiological waveforms and simulates the fault conditions which must be detected by the monitor.
Remote-Control Interface
When remote control and diagnostics are embedded in product software, the architecture of that software is an important consideration. The software path followed to “press a key” through the remote-control interface must be as close as possible to that followed when a key is actually pressed. Likewise, when a value is read via this remote interface, it should be acquired from the “closest point” to the display.
Displayed parameters can be acquired in two ways. One method captures the actual calculated parameter value, such as heart rate or temperature, from the physiological algorithm. This method is used to verify that the monitor is calculating parameters accurately.
The second method gets a predetermined signature or checksum for an area of the display from the display memory. This method is not as useful for acquiring calculated parameters which may fall in a range, but can be used to check that messages and labels are displayed correctly.
Commercial Patient Simulators
Patient simulators are available for most of the parameters that patient monitors measure. However, these simulators are geared for the widest possible market. Most simulators are used by biomedical technicians in hospitals for a quick check of the operation of a monitor before it is connected to a patient.
For their size and cost, an amazing number of features are built into commercially available simulators. But there are shortcomings.
To perform the heart-rate test previously mentioned, a simulator with heart rates of, perhaps, 10, 14, 16, 80, 120, 240, 299, 301 and 310 beats per minute is needed. Commercial simulators typically produce heart rates at fixed points within the physiological range, allowing for a rough, qualitative assessment of the monitor but not testing outside the normal range.
To multiply the problem, heart-rate meters must be tested with QRS waveforms of varying widths and amplitudes, with and without P-waves and T-waves of varying widths and amplitudes, and up to 8 electrodes with independent generators for each (Figure 1).3
The complexity of testing with ECG waveforms alone illustrates the need for a comprehensive patient simulator for all patient parameters.4 Due to the specialized nature of the application, the simulator must suit both the test hardware and software requirements.
Many programs are available for collecting data from multiple A/D converters, but very few for D/A converters or arbitrary function generators. Even if one of those programs fits the bill for creating and playing back waveforms, none will handle the 30 or so channels of analog output on specialized hardware.
Development of Patient Simulator
Physiological signals are typically very low level, from either electrodes or sensors. Individual parameter simulators, such as ECG and blood pressure (IBP), must be electrically isolated from each other to avoid crosstalk and interference.
To achieve this isolation, each parameter must have its own power supply and optically isolated data channel. The data channel should be capable of greater than 60 kB/s to support 30 channels of 16 bits updated once a millisecond.
The ECG simulator must generate high-resolution waveforms (5 m V) for each of up to 8 electrodes. It must also produce pacemaker pulses of varying widths down to 50 m s and amplitudes to 1 V. Other conditions that must be simulated include dry electrodes and electrode disconnected.
Respiration is measured as a varying impedance across two of the ECG electrodes, typically in the range of 0.1 W to 20 W variance from a baseline impedance of 200 W to 5,000 W . The circuit to generate respiration is logically grouped with ECG.
IBP is measured with a strain gauge and ratiometric to the excitation voltage provided by the monitor. To produce an accurate output signal, the simulator circuit must also use the excitation voltage provided and mimic the load and source impedance of a strain gauge.
SPO2 sensors measure the absorption of red and infrared (IR) light shone through the patient’s finger. By comparing the red and IR amplitudes, the percentage of hemoglobin carrying oxygen is determined. The monitor provides signals to control the intensity of the red and IR light sources, so the simulator must receive the intensity signals, and attenuate and modulate them in the same manner as the patient’s finger.
Both oxygen saturation and pulse rate can be measured. This parameter must have an extremely wide dynamic range (~24 bits) to simulate the wide range of patients and tissue types–from newborns to adults.
Cardiac output and temperature are measured using precision thermistors. To simulate the thermistor, a programmable resistor circuit has been devised. It produces a resistance from 750 W to 11,000 W ± 0.2% to simulate temperatures between -6° C and 52° C in increments of 0.1° C. Figure 2 is a diagram of a system showing all required functions.
Test Scripts
A command interpreter program that runs on the PC directs commands to the patient simulator and the patient monitor. In this way, setting the patient simulator mode and gathering data and controlling the patient monitor can be accomplished from a central point. A test script is formed by collecting a set of these commands in an ASCII file that can be read and executed by the command interpreter (Figure 3).
Results are gathered in their simplest form by logging all of the transactions that the command interpreter has with both the patient simulator and the patient monitor. These log files can be postprocessed to ascertain failures. Eventually, the pass-fail evaluation can also be made more real-time when the test requirements stabilize.
Summary
Adequate testing of patient monitoring systems demands that they contain embedded diagnostic tools and that a comprehensive multiparameter patient simulator be developed with the capability to generate waveforms and all of the error conditions that can occur. The patient simulator is not only necessary for requirements validation, but also indispensable for the fine-tuning of physiological signal-processing algorithms.
References
1. Federal Register, 21 CFR, Part 820.3 (cc), Medical Devices; Current Good Manufacturing Practice (CGMP) Regulations; Proposed Revisions, Nov. 23, 1993.
2. ISO 9001: 1994; Paragraph 4.4.8, Quality Systems–Model for Quality Assurance in Design, Development, Production, Installation and Servicing.
3. ANSI/AAMI American National Standard for Cardiac Monitors, Heart Rate Meters and Alarms, Association for the Advancement of Medical Instrumentation, Arlington, VA.
4. Armington, R.M. and Crosby, W.R., Framework for a Comprehensive Method of Evaluating Heart Rate and Arrhythmia Monitors, Computers in Cardiology, pp. 509-512, IEEE Computer Society, 1988.
About the Author
Wayne R. Crosby has been involved in developing and testing patient monitors at Siemens Medical Systems for more than 14 years, most recently for product validation. Previous assignments included functional board test and product development. Siemens Medical Systems, 16 Electronics Ave., Danvers, MA 01923, (508) 750-7500.
Copyright 1995 Nelson Publishing Inc.
May 1995