Vital Sign Integration and Interface

Vital Sign Integration and Interface

David Bach

Damon Tomlin

BME 273

Advisor: Russ Waitman

Professor: Paul King, PhD

April 24, 2001

ABSTRACT

The purpose of this project was to link Marquette vital sign monitors in the pediatric operating rooms of the Vanderbilt University Children’s Hospital to a database that we created. Ultimately, these data would be incorporated into a central database, which anesthesiologists and technicians could access. This would provide these healthcare workers with not only the status of operative patients, but also a wealth of information that they could use as a reference. To accomplish this project, we decided to develop a JAVA program which would take data from the Marquette monitors via a serial connection, display it in a Windows interface, and save it to an Access database. We further subdivided this problem into a serial interface, request packet generator, data parser, visualization, and SQL writer. We tested each of these steps as it was completed, and were pleased to discover that each portion functioned as we desired. Unfortunately, despite the fact that our code successfully sends a request and awaits a response for subsequent manipulation, the Marquette monitor has been shown to send no response packet for parsing. Because this project has no true safety issues and is economically feasible, we suggest that further study be conducted into why the monitor is unresponsive.
INTRODUCTION

The purpose of our project was to link the Marquette vital sign monitors to a computer via an interface that would ultimately put vital sign data into a database. This was to take place in the pediatric operating rooms (POR) of Vanderbilt University Children’s Hospital. Once obtained and archived, the specified vital signs would be transferred from the database to a preexisting SQL Server created for that purpose. The information saved in this database would be used for two primary purposes. First, upon implementation our project would allow for the remote monitoring of vital sign data taken in the POR’s; obviously, this aspect would prove more useful to the doctors and medical staff responsible for pediatric care. Second, the cataloging of surgical data would undoubtedly be valuable in analyzing trends present in surgical procedures; conversely, statisticians and/or engineers would ultimately implement this potential use.

This project is necessary because, while similar setups exist for the Hewlett-Packard models present elsewhere in the hospital, no such system exists for the Marquette monitors. Since these devices are the type preferred by the pediatric anesthesiologists, it was advisable to create a program that interfaced with these monitors, as opposed to emulating other preexisting systems.

As for background on the equipment itself, it is best to begin with a discussion of the source of the data itself: the Marquette monitor. This vital sign monitor consists of two parts, one of which collects data from the leads, and the other, which displays that data to a screen. It was the latter with which we made a serial connection. The portion that contains the leads, which is know as the Tramscope 25, is capable of taking a variety of vital sign measurements, including ECG, temperature, blood gas, invasive and non-invasive blood pressures. From this list of parameters, we selected eleven that we deemed appropriate for archiving.

As for other examples of such projects to which we could refer, there seem to be none available. That is, we could find no literature (save for a few out-of-date web pages) that could serve as a guide for the implementation of this project. Therefore, we enjoyed the advantage of not being force to adopt any particular approach; naturally, this had the disadvantage of having no precedent to follow.

METHODOLOGY

Originally, our plan was to connect the monitors in the nine POR’s together using a Unity Network setup. From this setup we would be able to make an ethernet connection to our computer. After many unsuccessful attempts to get help from GE Medical Systems, the owners of Marquette, we decided to alter our project slightly by using a serial connection to one monitor only.

Once this change was made, we broke the project down into four different sections: Windows interface, database, and serial connection, and data parsing. Because of our change of plans, we decided, after consulting with several computer engineers and scientists, to use the JAVA programming language instead of C++, which was used by the creators of the Marquette monitors. It was our understanding that by using JAVA2,5 we could use the predefined class structures and therefore programming and implementation of the Windows interface and the database/SQL sections would be more expedient.

The first section that we programmed was the interface. For the eleven variables chosen: invasive and non-invasive (systolic, diastolic and mean) blood pressures, temperature, wedge pressure, pulmonary arterial pressure, heart rate, and the ST interval, six graphs were designed to display the data being received. Also included in the interface were serial and database indicators that would flash when a connection was made, and when data was being transferred to the local database.

Next, a database was designed using Microsoft Access4. Using the same variable names assigned in the JAVA code2,5, the table was created. In addition to the eleven vital signs that would be passed to the database, a unique entry number and the date and time were added to the variable list. For the purposes of demonstration, random numbers were generated in the interface code such that they would be passed to the database. This was only an intermediate step to test and make sure that the JAVA SQL and ODBC statements compiled and worked2,5; the test came back with positive results. However, when we debugged the system, it was determined that if data were being transferred to the database, the table must be closed or no new data would get written to it – that seemed to be the only limitation to the database interface.

The Marquette monitor uses an ASYNC COMM serial port that employs an RS-422 connection. Because this RS-422 connection has a non-standard pin-out1,3, however, it was necessary to create our own cable based on Marquette’s Monitoring Data Services Manual and RS-422 adaptor pin-out diagrams1,3. The aforementioned adaptor had to be purchased from because our computer uses a more standard RS-232 serial connection.

The serial part of our program can be broken down into two parts; the first deals with the request packet and the second with the response packet. Before either can be accomplished, though, a serial connection must first be established between the computer and the Marquette monitor. After doing so, the program then writes the appropriate request packet, as specified by the monitor’s manual.

After receiving the appropriate request packet, the Marquette monitor responds by sending a byte stream containing vital sign data back to the computer. The response packet portion of our program is charged with the task of extracting the desired physical parameters from this large quantity of binary data. According to Marquette’s Monitoring Data Services Manual, the response packet is in a nested structure format. That is to say, each structure contains not only its own particular parameters, but also an array of raw bytes which correspond to the appropriate substructures. Our JAVA program was to parse out the eleven parameters from the more than one hundred present in the nested format. It accomplishes this job by seeking out particular parameter identifiers that are specific to the information of interest. Once it finds these identifiers, it extracts the desired data by typecasting bytes which are at a fixed distance from their markers. These typecast bytes become the vital sign data with which we are concerned. After parsing the response data packet, the selected variables are displayed in the Windows interface and sent to the local database, just as the random data was in testing the original system.

RESULTS

As previously stated, originally we had planned to utilize the Unity Network for our data transfer, and possibly purchase programs and hardware from Marquette. We soon discovered that GE Medical Systems had bought out Marquette. Consequently, we attempted to contact GEMS so as to gain information regarding their Marquette product line. Unfortunately, GEMS was not exactly forthcoming with a response to our numerous emails and phone calls. We can only attribute this phenomenon to the fact that our operation is small and nearly unfounded. After a while, however, we were assigned a customer service representative, whom we promptly contacted. As it turned out, this contact was not assigned to our region, but passed our request on to a colleague. This second contact, though considered our technical representative, was unable to help us in giving us the information required because he was apparently bound by a contractual obligation not to do so. He then contacted his counterpart in sales, who was the tardiest with his response out of the entire group. We soon learned that GE Medical would be unable to provide us with the hardware solution we desired; in the time it took us to discover this unfortunate fact, we had pursued other avenues for such devices and found them equally fruitless.

By the end of this process, we were behind schedule and decided to attempt our own hardware solution. To this end, and because such in depth hardware analysis is beyond the scope of our experience, we enlisted the services of several acquaintances in the Computer Engineering and Computer Science departments on campus. They told us that it would be easier and more suited to our lack of experience with network programming and systems to pursue a direct serial connection to the Marquette Monitor. This change in project description was acceptable to our advisor, and we proceeded along the new avenue.

Our consultants also explained the benefits of using JAVA – the Windows interface, the database/SQL statements, and the opening of the serial connection all would be easier to program due to JAVA’s predefined classes and methods2,5. We found their assessment to be accurate; indeed, the implementation of the aforementioned portions of the program went much faster than they would have in a C++ environment. And so, we created the interface program, testing as we went. As mentioned previously, the Windows and database interfaces functioned perfectly. Figure 1 shows a screen shot of our windows interface along with a description of each individual graph. Thedata displayed, is from the random test data.

Unfortunately, we discovered an unforeseen problem with the implementation of our parsing algorithm. This difficulty lay in the typecasting of the data array onto our user-defined structures. We found that, although C could perform this typecasting without hesitation, the JAVA language balked at the task. This was apparently the result of an inherent limitation of the language that we could not have predicted; it seems that such limitations are the consequence of a more sophisticated programming language. This situation led us to develop more efficacious (albeit less elegant and convenient) methodologies for extracting the data – namely, the parsing algorithm that has been detailed in the Methodology section. Ultimately, this trade off would be comparable to the difficulty we would have had with the interface, database, and serial connection if we used C++.

The portion that remains to be mentioned is that concerning the serial connection and our ultimate results. As for the former, we initially had some problems establishing a link between the computer and the Marquette monitor. This error was pointed out by the fact that although our code was supposedly sending a request packet, it was receiving no response packet in return. At the time, we were unsure if this was a result of a faulty serial connection, an incorrect request packet, an inability to read the response packet, or the monitor’s failure to answer our program’s query. Naturally, we ran some tests to determine which of these phenomena was occurring. By creating a serial connection between two computers, we were able to rule out several of these events; more specifically, the fact that our program was indeed opening a serial connection and sending a request packet was proven by the fact that our secondary computer acknowledged that link and received the request packet in its entirety. Furthermore, we found that our program could also receive and save data, were it sent over the serial connection. This lead to our determination that it was not our program, but rather our hardware that was at fault; a thorough investigation was conducted, and we found that we needed to rebuild a serial cable to account for the unusual RS-422 pin-out1,3 of the monitor. For the exact specifications for this cable, we refer the reader to Appendix B.

Ultimately, it certainly bears mentioning that our project was unsuccessful. As for the reason for this failure, we have reason to believe that the fault does not lie in our program. We have proven that our software interacts with the Marquette monitor exactly as specified by the Marquette manual, and yet our program, when executed, initializes and awaits a response packet that never arrives.

At this point, as in any design, especially those used in a hospital setting, it is imperative that safety be taken into account; however, since our project was unable to meet its goal, we must assume that it did for the purpose of this analysis. Because our design project is a computer program, it in itself is not a safety risk. However, because the program is housed within hardware, several safety concerns arise – specifically, a possible tripping hazard. To prevent this danger, we propose that the computer, monitor, and necessary cables be elevated and placed out of the way in the operating room.

Although highly unlikely, it may be possible for the program to malfunction. If this occurs there are two possibilities for the outcome. The first is that the patient is exhibiting normal function, but the program displays and/or records that there is a problem. The second is that the patient is experiencing problems, and the interface does not reflect the situation. Of the two possibilities, the former is more likely to occur, however, the computer monitor would not be something viewed by the physicians and medical technicians in the operating room, and only the person viewing the database would observe this malfunction. If the latter is the case, as previously mentioned, the attending personnel are not likely to be viewing our Windows or database interfaces, and the more primary monitors would provide the proper warnings and pertinent information. We can assume, because the patient is in the operating room when our project is in use, qualified personnel are observing the necessary precautions to prevent any patient distress.

In the evaluation of the costs of this project the following factors must be considered – time spent in development, cost of materials, and the cost of maintaining the system. It was determined that the combined time spent on this project between the two students assigned the topic and their consultants was 596 hours, at a rate of $15.00 per hour that works out to $8,940.00. Because a one-to-one ratio of computers to operating rooms would be required, nine systems would need to be purchased. We priced a complete computer system (Pentium 3 with 128MB and 133MHz SD-RAM) at at approximately $850.00 or nine systems at $7,650.00. We believe that maintenance and energy upkeep would be negligible, and the Marquette monitors have already been purchased for the hospital. After summing these figures a total of $17,265.00 is achieved. Please refer to Appendix C for a more mathematical representation of this analysis. The life cycle of the project is, for all intents and purposes, infinite. As long as the Marquette system is used, our program can be implemented.

As for a cost-benefit analysis, in the first few years, this project is not lifesaving, however, after archiving enough data, trends can be researched that, in the long run, could allow new practices to be adopted that may save lives. This end result could prevent any number of lawsuits against the hospital, so a minor investment at the beginning could offset a large settlement down the road.

CONCLUSIONS

For reasons that we could not decipher, this project proved unsuccessful in the end. There are several facts about which we are certain, however. First, we know that both the Windows visualization and the database interface work correctly both with one another and in their own right. Once collected, the data is displayed in a meaningful, user-friendly format, after which it is written in its entirety to the local database that we have implemented.