Stress-free ECG
QNX gives Burdick's Quest a running start

Glenn Isensee, Burdick

Heart disease is not only one of the primary concerns of healthcare professionals today, it's also one of the most expensive to treat. Procedures commonly used to treat advanced heart disease - angioplasty, nuclear imaging, and cardiac bypass - don't come cheap. As a result, it has become increasingly important to find ways to evaluate cardiac patients using lower-cost, noninvasive technologies.

Our solution is Quest, a computer technology that measures and analyzes ECG data while a patient exercises on a treadmill. Designed to update aging equipment in acute care facilities, clinics, physicians' offices, and cardiac rehabilitation centers worldwide, the system provides healthcare workers with a reliable, cost-effective, and safe platform for collecting and analyzing ECG data.

Critical requirements

Choosing an OS for a medical device is no easy process; there are myriad requirements to consider. One of the most important is, of course, safety. It was very important that we find a robust and mature realtime OS - one that had a history of fault tolerance in critical applications.

We also had a long checklist of other issues. As medical devices go, an ECG stress-testing machine is a particularly large software project that requires a robust filesystem, a comprehensive set of library functions, and realtime performance. And, with a very aggressive development schedule, we had to choose an OS with a complete development environment including drivers for key devices like touchscreens, disk drives, graphic subsystems, and support for standard x86 motherboards.

Another critical requirement for Quest was a reliable solution for transporting ECG data. It is becoming more and more important for healthcare systems in general, and our system in particular, to be able to exchange data with other hospital information systems and cardiology data management equipment.

Also, since we wasted precious resources customizing the OS we'd used on previous projects, management insisted that this time we choose an OS that would allow us to concentrate solely on the application, rather than the OS itself.

Finally, since Quest is used by physicians and other healthcare workers who don't necessarily have much computer training (and are perpetually short of time), it was essential that the system have an efficient yet simple-to-use interface.

We spent a lot of time looking at various operating system technologies and even started development with another OS, but when we boiled everything down, QNX and the Photon microGUI were the only products that offered everything we were looking for.

Under development

Quest's product definition and conceptual development stages took the better part of three years, but the actual software code, written in conjunction with Sterling Computer Systems, took a mere 14 months - lightning fast for a medical device! We attribute part of this speed to QNX's POSIX-compliance - it was easy for our Unix developers to apply their skills. Also, some of our personnel had prior familiarity with QNX. But that aside, the dedicated team of QSSL developers working to enhance the OS, update drivers, and keep up with all the changes in hardware saved us a lot of work.

Going into the project we realized that we couldn't possibly keep up with all the rapid changes in silicon-graphics chips, motherboards, and so on. QSSL worried about all this for us, and even worked with us to write specific device drivers.

The Quest system is Pentium-based, with a PCI-bus interface for data acquisition and a PC Card slot for upgrades to software, and additional storage. We use Photon for the graphical display. Quest supports a touchscreen, standard serial ports and protocols, 1024 x 768 graphics, expandable memory, TCP/IP networking, an IDE disk drive, and a standard keyboard.

Cooperating processes

We liked the design advantages that a pure microkernel architecture gave us. Quest's architecture takes full advantage of QNX's ability to divide the operation of a system into a number of cooperating processes. These processes communicate both through message passing and shared memory.

Data acquisition

Data acquisition ECG data is acquired from a patient (8 channels at 500 samples/second) and is handled through a data acquisition process. Digital filters are applied to remove high-frequency noise (resulting from patient muscle artifact), line-frequency noise, and low-frequency variation of the signal (resulting from patient respiration and electrode movement). This data is passed into a shared memory segment that holds the last 30 seconds of ECG results. From there, data can be easily accessed by a number of other processes in the system.

The data acquisition program also provides a timing standard for the system, which we refer to as the "heartbeat," by maintaining a millisecond clock synchronized to the sample rate of the data arriving from the patient. This means we don't have to be concerned with drifting between the clock in the patient acquisition module and the PC's internal clock.

Display program

Display program The display screen is "owned" by the display program. The program extracts data from the shared memory segment at a regular rate and displays a subset of those waveforms on the screen in real time. In addition, user interaction with the system is controlled by the same program through onscreen widgets. If a user changes the subset of ECG data that's displayed on the screen, the effect is immediate. It's interesting to note that user interaction with the screen elements, including the display of other dialogs, has little impact on the waveform display. This illustrates the efficiency of the Photon display engine.

ST analysis

An important part of any stress test system is its ability to analyze the "ST segment," which is the part of the waveform received immediately after the "beat." Variations in the level of this segment during exercise testing give a very useful indication of the health of the coronary arteries feeding the heart. Analysis of the ST segment is undertaken by a separate program in the Quest system. This program runs every 10 seconds and bases its analysis on 20 seconds of data extracted from the shared memory buffer. The display program updates the screen with the results of the analysis as they become available.

Reporting

Output from the Quest system is also available in the form of printed reports. A separate program extracts the pertinent data from a shared memory buffer at a 1 millisecond rate and generates the scan lines necessary to feed a 200 dot-per-inch thermal printer.

Long-term storage of the ECG analysis data is controlled by yet another program that spools data to disk at a regular rate. This data can be saved to an internal hard disk at the end of the stress test or archived to a PCMCIA disk.

Shared memory

Shared memory is very important to Quest's operation. Not only does it contain the most recent ECG data and all of the text strings, it also contains the current state of an exercise test and user setup requirements. Therefore, it was essential in our design to ensure secure and consistent access to shared memory. This was achieved very simply with QNX. We allocated a priority level not used by any other process, and mandated that any process requiring more than simple atomic access to a shared memory element adjust its priority level to that value, and adjust its scheduling algorithm to FIFO (from round robin). This was accomplished with just a few lines of code and works extremely well.

Custom keyboard

The hardware design of Quest specified a one-size-fits-all keyboard to be used internationally. Specially manufactured for us, the keyboard is a subset of a standard keyboard but uses the "Ctrl" key to assign an additional character set to a number of keys.

Because QNX allowed us to design our own .kdef file (which defines how key combinations should be translated into Unicode values), the integration of this keyboard was particularly easy. Sample .kdef files and associated tools are actually provided as part of the Photon 1.1 release, and we found that within an afternoon our software developers had created a .kdef file that mapped the Quest keyboard to the correct Unicode values.

Within Quest, text strings are stored as Unicode values and converted to DBCS format just before presentation to the appropriate onscreen widgets. On the other hand, the character set used by the plot formatter to generate a paper output conveniently maps directly to the internal Unicode values. In this way, Unicode allows us to support the required international character sets.

In a graphical user interface it's not always easy to tell which element of the user interface currently has the keyboard focus. However, it's very important that certain key combinations be immediately recognized within the Quest system. For example, our application requires absolute activation of a key press to ensure that the treadmill will stop. The QNX implementation in Photon enabled us to resolve this by allowing us to customize an "event" loop in the Photon library. The templates Photon provided were easy to understand so modifications were quick and painless.

Internationalization

At the beginning of software development, we decided to make internationalization a main feature of the system. Indeed, handling international strings was one of the first processes we tackled. No text strings are hard-coded into the Quest software. Instead, each time a string is required we pass an index pointer to a routine. All keys correspond to translated strings stored in a text definition file that accommodates all the languages supported by Quest. A separate utility, run as part of the make process, generates the include file that cross-references the keys to an array of indexes. The impact on make time is insignificant.

At run time, a configuration file indicates which language should be loaded, and only those strings are loaded into a shared memory segment, together with a pointer array that is related directly to the indexes. In this manner, a string lookup becomes a simple pointer resolution and is very fast. In addition, text strings specified for widgets within PhAB are related, through interrogation of the appropriate PhAB-generated include files, to keys in the text definition files. This enabled us to update dialogs and windows to the correct language strings as they appear on the screen (realization).

Safe and efficient

The treadmill is controlled through a serial RS-232 communication link. A separate program sends commands to the treadmill and interrogates the status received back. Since the treadmill can reach speeds of 10 mph at a slope of up to 25% it must remain under control at all times. We achieved this by fitting the treadmill control process with watchdog timers that must be hit periodically. If any part of the system fails, the treadmill control terminates, causing the fail-safe mode to stop the treadmill immediately.

Since the patient must attempt to reach a certain exercise level to generate a diagnostic ECG result, we incorporated various standard exercise protocols that a healthcare worker can choose from to provide a common basis for interpreting the results of the stress test. These protocols control the speed and slope of the treadmill over the course of the test and can be customized and stored by the healthcare worker administering the test. Photon allows the user to display and edit the large number of parameters of the protocol on a single screen.

Integrating information

An ECG is a personal signature relating to the health of your heart, but in many cases a complete cardiac assessment occurs only when this data is integrated with other cardiac data such as echo (ultrasound) cardiography, nuclear imaging data, and previous ECGs. Coordinating all of this cardiac data in a central system is becoming vital to cardiologists; providing network solutions is critical. Thanks to QNX, Quest has networking support built in.

Photon microGUI

The Photon microGUI was a particularly important aspect in our choice of QNX. With Quest we had to be very careful about how many windows were being presented at once, how they were positioned, and what got covered up - the GUI had to provide different widget sets and ease presentation so that all of our screens were intuitive and not missing critical information.

PhAB let the project team use many predefined graphical controls and place them directly from PhAB menus onto the application user interface screens. The ease of doing this cannot be understated since this very rapid prototyping and code generation allowed healthcare professionals to evaluate the UI during Quest's development.

Optimizing Quest

Unfortunately our development schedule didn't allow the luxury of an optimization phase. We just didn't have time to go back and tweak a little here and there. Luckily, with QNX we really didn't have to - we were able to get a safe, reliable product to market without this phase. With other operating systems, this would have been unthinkable.

Development savings

Compared with projects requiring customization of the OS, we were tasked only with getting Quest's application code operable. This we did very quickly, saving us the equivalent cost of about 3 developers.

The majority of these savings were realized with the QNX development environment alone. Because we were able to develop on non-target systems, many of our development engineers could use standard, off-the-shelf PCs. We didn't have to spend money buying target systems or building prototypes just to develop the software. This was significant because sometimes there were as many as 6 or 7 developers all working on debugging the hardware and software.

The one to beat

We feel that the QNX OS has really helped Quest achieve a leadership position in the industry. It's satisfying to know that we're the one to beat. But we know there's still work to be done on Quest. For instance, because of certain cost factors and the kinds of requirements Quest has, we're seriously considering using QNX/Neutrino for future versions. We think that going with Neutrino will put our products into an even more cost-effective situation without having to scrap the application code we've already developed.

With Quest we have a great software base from which we can build subsequent derivations of ECG monitoring systems and further applications in exercise testing. We'll be focusing next on improving algorithms, ease of use, network-"ability," interprocess communication, and remote access to stress tests for teaching and clinical situations.