General Clinical Research Center
Using PDA’s to Automate Vital Signs Acquisition and Storage
(UPAVAS)
EECE 296
Spring 2005
Submitted April 29, 2005
Client:
Dr. Paul Harris
Supervisor:
Dr. Andrew Dozier
Team Members:
Chris Heath
Adam Nagel
Chris Nash
Brendan Soar
Table of Contents
1. Project Summary: 4
1.1. Project History 4
1.2. Summary of Progress 4
2. Requirements: 6
2.1. Operational Requirements: 6
2.2. Physical Requirements: 6
3. System Description 7
3.1. Operational Concept 7
3.2 System Diagrams 7
3.2.1 System Overview 8
3.2.2 PDA/Dinamap Interface 9
3.2.3 PDA/User Interface 10
3.2.4 PDA/MySQL interface 10
3.3 LabVIEW 12
4.0 Hardware Detailed Design 13
4.1 PDA 13
4.2 AirCable 14
4.3 Wireless Network 15
4.4 Web Server/MySQL server 15
5.0 Software Detailed Design 16
5.1 Labview Overview 16
5.2 Dinamap BP_HR Study Overview 16
5.2.1 Logic 16
5.2.2 Dependencies 17
5.3 Showing and Hiding Controls/Indicators 18
5.4 Dinamap BP_HR Study Details 18
5.4.1 ID Acquisition/Verification 18
5.4.1 Create Local Save Files/Directories 19
5.4.2 Establish Bluetooth Communication 19
5.4.3 Main Acquisition Loop 20
5.4.3.1 Wait Loop 21
5.4.4.2 Acquiring a Measurement 22
5.4.4.3 Obtaining a Comment 23
5.4.4.4 Uploading and Writing Data 23
5.4.4.5 Resubmit Data 24
5.4.4.6 Re-establish Bluetooth Communication 25
5.4.4.7 Resubmit Failed Data and Close Communication 25
5.5 GCRCDataSubmit_min.vi 25
5.5.1 Variables 26
5.5.2 Algorithm 26
5.6 gcrcHTTPGetUrl 27
5.7 dinamap model poll 27
5.7.1 Parameters 27
5.7.2 Algorithm 27
5.8 dinamap to pda talk 28
5.8.1 Parameters 28
5.8.2 Algorithm 28
5.9 dinamap serial acquire 28
5.9.1 Parameters 29
5.9.2 Algorithm 29
5.10 dinamap port determination 29
5.10.1 Parameters 30
5.10.2 Algorithm 30
5.11 GCGC_Parser 30
5.11.1 Parameters 31
5.11.2 Algorithm 31
5.12 dinamap resubmit data_v3 31
5.12.1 Parameters 31
5.12.2 Algorithm 31
5.13 dinamap write 32
5.13.1 Parameters 32
5.13.2 Algorithm 32
6 Test/Evaluation Procedure 33
6.1 Bluetooth Communication 33
6.2 Server Communication 34
6.3 File I/O 34
6.3.1 File Write 34
6.3.2 File Read 35
6.4 Product Testing 35
6.4.1 Initial Testing 35
6.4.2 Secondary Testing 36
7 Conclusion 37
8 Recommendations For Future Work 38
1. Project Summary:
The goal of our project was to design and implement a portable device that would automate the data acquisition from a vital signs monitor (Dinamap Pro 1000). Our client, the General Clinical Research Center (GCRC), brings in hundreds of patients each year for various research goals. Some have rare conditions that are of interest to researchers. Many are brought in by pharmaceutical companies for the testing of new medicines. Study subjects are flown in from around the world, at great expense to the center and the study's sponsor, and are only at Vanderbilt’s medical center for a short period of time. During each study, a series of serial blood pressure and heart rate readings are taken of the patients to track their responses to medicines or procedures.
The vital signs monitor that is used to measure all vital signs of the patient is able to trigger, retrieve, and store a minimal amount of measurements for each patient. The problem we faced was to trigger/retrieve the measurements from the Dinamap monitor, and upload the data wirelessly to a server so that the measurements could be seen “live” from anyone with access to the MySQL server or its PHP front-end. Our solution had to be durable enough to not crash under any “reasonable” condition, and ensure that all data that was acquired was saved in multiple locations to ensure no loss of critical information.
1.1. Project History
Before our solution was implemented, nurses were required to trigger the measurements manually, at every time interval. Since each patient is brought in at great cost, any loss or corruption of results is unacceptable. The studies that are performed often last from one to eight hours with measurements every three to five minutes. Once the study is concluded then the data is uploaded manually by a nurse, often using a floppy disk. On some occasions, a computerized system is not available, and nurses must manually trigger and record vitals signs measurements. This introduces a large potential for timing and transcription errors. Each time that an error is introduced into the study the research data becomes less useful, potentially costing the GCRC thousands of dollars. To ensure that such data corruption doesn’t occur, an inexpensive automated solution is needed that will run the studies without consistent monitoring by an operator and that will be able to upload the data to the MySQL server in a reliable manner.
1.2. Summary of Progress
Our handheld solution is able to trigger, retrieve, and upload all vital signs data reliably. We have implemented our solution on a PocketPC running LabVIEW for PocketPC. The PocketPC uses its Bluetooth connection to talk to an AirCable (a Bluetooth-to-serial adaptor) connected to the Dinamap Pro 1000. The PocketPC first triggers a measurement, and then polls the device for the data from the last acquisition. Once the data is received from the monitor, the PocketPC tries to upload the data via the IEEE 802.11b wireless network by sending the data to a web page running a PHP script. The PHP script takes the vital signs data from the URL, parses it, and stores the data into the appropriate database. If the data was successfully uploaded we will receive the proper return codes, if not then we will not receive the proper return codes. If the upload failed, then we simply put the data into a separate file on disc. We keep trying to upload all data that wasn’t uploaded originally during our wait time between measurements. If, at the end of the study, there remains data that hasn’t been uploaded, then the operator is informed of the condition and is instructed to proceed to a designated point where the wireless network is known to be sound. If the data still can’t be uploaded then we pop up another screen for the operator to inform them that they need to hand over the PDA to an administrator so that he/she can use a program running on desktop to upload the data. With three different levels of data uploading checks, we feel confident that all data will be uploaded after each study. If for some unknown reason all data couldn’t be uploaded to the server, at least all the data will be stored locally on the PDA ensuring no data will ever be lost.
2. Requirements:
Our solution requirements can be broken down into two distinct categories, operational and physical. The operational requirements deal with how the solution will work, and what specs it must meet. The physical requirements are more general are relate to the size and cost of the solution.
2.1. Operational Requirements:
Due to the sensitive nature of each measurement we needed to make sure that we always triggered and recorded all the vital signs data at every interval! Therefore our solution had to meet specific timing requirements and be extremely stable.
· Able to trigger/receive measurements every 60 seconds
· Easy to use
· Take a measurement at any time, as well as at specified intervals
· Easy to use by untrained nurses
· Allow setting of measurement intervals
· Program easily modifiable to accommodate future technology
· Electrically Isolated from vital signs monitor
· Multiple levels of redundancy to prevent data loss
· At least 5 year life cycle
2.2. Physical Requirements:
The physical requirements of the system related to the size, power, and cost of the solution. These requirements are as easily quantifiable as the operational requirements, thus the reason for the distinction.
· Easily carried in one hand
· Stored/mounted on the Dinamap stand
· Should not rely on batteries
· Battery power needed for emergency situations
· Cost between $400 - $500 per unit
3. System Description
Our system was designed to be a handheld, data acquisition system that can be easily modified and customized. The device will be used by nurses to automate the process of triggering, retrieving, and uploading all the vital signs data taken by the Dinamap. The device needs to be extremely user friendly for operation by non-technical nurses. Once the nurse initiates the test, the device should be able to run on its own and not require supervision.
The device will be used in near-ideal conditions, operating at room temperature with a power supply attached. Since the patients will not want to be in a room that is terribly uncomfortable we can assume that the temperature in the room will be between 60 – 80 degrees Fahrenheit. The power to the PocketPC and Bluetooth-to-serial data converter will be connected to the same outlet that the Dinamap is connected to. If for some reason there is a loss of power the converter will no longer operate, but both the Dinamap and PocketPC will. This means that we will no longer be able to take measurements but we will not lose any data that is stored on the PocketPC because all measurements will be stored in the device's ROM.
3.1. Operational Concept
We decided that to keep the cost of this project down we would use a few PDAs to interface with multiple Dinamap monitors, since only a few monitors are ever in use at a single time. To allow a PDA to communicate with one of several monitors, we knew that a basic setup process would be needed. So we assigned an AirCable Bluetooth-to-serial adaptor to each vital signs monitor, with a specific channel that the AirCable would listen to. Then the PDA can choose which monitor it will interface to by simply selecting the correct name, thus creating a dedicated channel between the two devices.
Once the operator has created a direct link between the PDA and Dinamap then they will proceed to the study identification screen. The user will enter a study number, which will be verified, and the user will then be shown the measurement screen. Once at the measurement screen, the first measurement will begin. The user can then set the rate at which measurements will be taken. Then the program will trigger and receive the data from the Dinamap monitor, store the data locally, and then try to upload the data to the web server. If the data can’t be uploaded then the data is stored into a separate data file and will be uploaded when the wireless network is available again.
3.2 System Diagrams
The most challenging part of our project was the systems integration aspects. We essentially took off the shelf products, such as the PocketPC, and integrated them into a single package. The reasoning behind using only off the shelf products was simple, we knew that these products had been tested and debugged previously. So we knew that the products we were using worked, so all we had to do was get them to work together.
3.2.1 System Overview
Figure 1: Top level diagram of the solution.
As seen in the above diagram, our PDA/PocketPC has three major interfaces. Our first major interface was to the Dinamap monitor, via the AirCable Bluetooth-to-serial adaptor (explained in section 3.2.2). The second major interface was with the user, thus the reason why we choose to use a PocketPC. PDAs already have an easy-to-use user interface built in, so all we had to do was design an easy-to-use graphical user interface (GUI). Thus one of the major requirements for our development software was the ability to create GUIs relatively easily (explained in section 3.3). The third interface that we had to worry about was the PDA to MySQL server interface. The server interface had to upload the data in a reliable way over the wireless network, and provide feedback so that we would know if the data was uploaded correctly.
3.2.2 PDA/Dinamap Interface
Since we wanted our solution to be as portable as possible, we wanted it to have as few wires attached to our device as possible. So we decided that using the bluetooth connection on the PDA to connect to the Dinamap monitor via the AirCable adaptor would make our solution as mobile as possible.
Figure 2: The interface between the PDA and the Dinamap monitor.
Another major reason for using the adaptor is because our solution is supposed to have at least a 5 year life cycle. PDAs today have a serial port that could be connected to the Dinamap monitor and communicated perfectly, but port is being phased out. To ensure that our solution would be viable for over five years, we decided to communicate via Bluetooth.
As can be seen from the above diagram our PDA will use its built-in Bluetooth capability to talk to a Bluetooth-to-serial adaptor. The adaptor will connect directly to the Dinamap’s serial port, separating our device from the Dinamap and maintaining electrical isolation.
Diagram 2 also shows how each interface connects to the PDA in more detail then our previous diagrams. First, the user interface (UI) will communicate directly with the PDA OS. Then the PDA OS will interface with all other aspects of the system according to the instructions given from the user interface. Diagram 2 also shows how the data storage system will operate. The data storage system will receive all the information from the PDA OS where it will send the data to two distinct locations, local storage and network storage. The local storage will be used to make sure that we always have a copy of all the data, ensuring that we don’t lose any data. The network storage system will be explained in greater detail in section 3.2.4.
3.2.3 PDA/User Interface
One of our main requirements was for our system to be easy to use, since non-technical people will most likely be operating the device. To fulfill this requirement we decided that giving the user an environment that they were most used to would be best, thus we decided to make a GUI.
Figure 3: Screenshot of the GUI.
As seen from the above diagram, the UI is very intuitive. All the operator has to do is type in the patient ID, measurement interval, any comments that they want to enter, and click run. Each of these inputs has a field clearly labeled with drop down menus that can be operated through the stylus associated with the PDA. Thus everything is very visual and only requires the nurse to touch the screen to operate, making our UI very intuitive.