University of South Carolina

Scholar Commons

Senior Theses Honors College

Spring 2018

Development of Rule-Based Recognition Systems for Continuous

Monitorization of Pulse Oximetry
Brian Delehanty
University of South Carolina - Columbia

Follow this and additional works at: https://scholarcommons.sc.edu/senior_theses

Part of the Biomedical Devices and Instrumentation Commons

Recommended Citation
Delehanty, Brian, "Development of Rule-Based Recognition Systems for Continuous Monitorization of
Pulse Oximetry" (2018). Senior Theses. 245.
https://scholarcommons.sc.edu/senior_theses/245

This Thesis is brought to you by the Honors College at Scholar Commons. It has been accepted for inclusion in
Senior Theses by an authorized administrator of Scholar Commons. For more information, please contact
[email protected].
Development of Rule-Based Recognition Systems for
Continuous Monitorization of Pulse Oximetry

Final Report | Spring 2018

Design Team
Noor Al Zadjali Group Leader
Patrick Buckley Lab Technician
Brian Delehanty Programming Expert
Kimanh Vo Project Manager
Dr. Homayoun Valafar Sponsor
Nick Boltin Advisor

803-777-3767

University of South Carolina

Columbia, SC

Page 2 of 24
Table of Contents

Section Page

1. Introduction 3
1.1 Problem Definition 3-4
1.2 Problem Solution 4
1.3 Alternative Solution 4-5
1.4 Goals and Objectives 5-6

2. Design 6-7

3. Methodology 7-9

4. Results 9-12

6. Conclusion 13-14
6.1 Budget 14-15

7. Future Plans 15-16

8. References 17

9. Appendix 18-23

Page 3 of 24
1. Introduction
1.1 Problem Definition
A critical role of the circulatory system is to deliver macromolecules, cells, and oxygen
throughout the body. Of the numerous medical conditions that may affect a patient’s
arterial oxygen saturation, asthma and chronic obstructive pulmonary disease afflicts over
one billion people worldwide.1 Hypoxemia occurs when the oxygen concentration is
abnormally low in the blood, which is commonly associated with conditions such as
hypoventilation and the reduced pressure of the lungs. Essentially, if the blood doesn’t
carry enough oxygen or the heart is not pumping blood effectively, the tissue will
experience hypoxia and suffer permanent damage within minutes.2

Pulse oximetry is a non-invasive and inexpensive clinical method that can collect real-time
information about a patient’s pulse rate (PR) and blood oxygen saturation level (SpO2),
Pulse oximeters are commonly used to quickly measure a patient’s PR and SpO2 levels in
hospitals and clinics, and they have recently become prevalent in patient home care.3

Pulse oximeters determine the oxygenation percentage of arterial blood by transmitting

and comparing light intensities transmitted and received from one red LED (760 nm) and
one infrared LED (850nm) through a small part of the body such as a fingertip. 4 Comparing
these intensities makes it possible to calculate the percent of hemoglobin saturated with
oxygen based on the amount of light absorbed. Oxygenated hemoglobin absorbs infrared
light, and reduced hemoglobin absorbs red light wavelengths. The pulse oximeter
determines SpO2 by comparing the degree of absorption of each LED. The pulsating flow of
blood causes spikes in light absorption levels, which are then used to determine the
patient’s heart rate.

While pulse oximeters can determine a patient’s PR and the SpO2 of their blood, most do
not have an alert feature that notifies caregivers of changes in these measurements. 5 Due to
this missing feature on portable pulse oximeters, pulse oximetry is largely limited to either
quick data collection or constant supervision. The pulse oximeters that do include these
features are far more expensive than their counterparts. Fingertip pulse oximeters are also
susceptible to error from vasoconstriction if the patient is not kept in a well-insulated and
controlled environment. As it stands, there are few devices used in clinical settings that
continuously monitor a patient’s PR and SpO2. Electrocardiograms (ECGs) can be used to
continuously monitor a patient’s heart rate for abnormalities and that can then be
reported, but they are far more cumbersome and expensive than pulse oximeters. ECGs
require numerous electrode leads to be placed on the patient and are susceptible to motion
artifacts. ECGs also fail to provide any information about the patient’s SpO2. This
information can be obtained by using arterial blood gas analysis, but this is an invasive
method that requires the physician to gather blood samples at regular intervals. The

Page 4 of 24
relative ease of using pulse oximeters and their noninvasive nature makes them the ideal
monitoring method for our project.

1.2 Problem Solution

This project enhances the ability to use low-cost technology, such as pulse oximetry, to
monitor patients while they sit in the waiting room rather than having to check them into a
room before beginning the monitoring process. The low cost of pulse oximeters relative to
other monitoring devices, such as ECGs, makes them ideal for monitoring large numbers of
patients in clinical waiting areas or homecare settings. The project aims to create an
algorithm that can connect or wirelessly record pulse oximeter readings to detect and
trigger an alert when a patient’s of different ages and different thresholds, PR or SpO2 level
begins to decline. Computer algorithms can be used to quickly interpret data and carry out
a task based on that data. By designing this program in such a way that it records and
stores patient data as well as being easily adjusted by the physician, it is possible to tailor
the alert system to typical baseline values for the patient. In turn, this algorithm can use the
baseline measurements to detect abnormalities by determining if the heart rate is within
an acceptable range unique to that patient. Supplementing pulse oximeters with this alert
system will make these useful devices far more viable for continuous monitoring of
patients in both clinical and home-care settings. This project establishes a foundation for
the development of a wearable device that can continuously monitor the patient’s PR and
SpO2 without hindering his ability to perform daily activities or compromising the integrity
of the device.

1.3 Alternate Solution

The alternative solution for the project was to utilize LabVIEW software along with
MATLAB for the development of a rule-based algorithm that can identify and trigger an
alert when abnormal values for both PR and SpO2 are detected. MATLAB is useful in
programming for complex pattern recognition algorithms; however, the software will
require heavy machine learning and practice to gain practical knowledge, consequently
extending the timeline causing a delay in the project and making the completion of the
project before the deadline rather difficult.

Since both the Bluetooth and USB connections pulse oximeters purchased required gaining
access to their specific universally unique identifier (UUID) and the media access control
(MAC) address, which is difficult to obtain due to privacy laws and corporate
confidentiality. The Biomedical Engineering Department provided Pulse Diagnostics with a
USB connection pulse oximeter which can be connected to the BioRadio units via USB
connection. The PR and SpO2 level readings can be transferred from the pulse oximeters to
the LabVIEW system via Bluetooth connection. The setup for the equipment utilized is
illustrated in Figure 1.

Page 5 of 24
Figure 1. USB link pulse oximeter setup. The setup includes the BioRadio pulse oximeter
connection. Data is transferred from pulse oximeter to LabVIEW system via Bluetooth
connection.

1.4 Goals and Objectives

The main intention of this project is to develop an alert program that will take advantage of
a simple and inexpensive biomonitoring device to maximize potential cost-effectiveness
and ease of use in both emergency situations and home care. As it stands, the pulse
oximeter device themselves are relatively affordable, but the ones with monitoring and
analysis capabilities increase the price by at least 500% (according to price-matching the
average cost of pulse oximeters without programming to the least-expensive model of the
pulse oximeter with programming). This project will cover the initial steps in advancing a
simple and basic pulse oximeter to a powerful yet minimalistic tool that can take into
consideration each patient’s unique resting PR and SpO2 ranges. Software program
LabVIEW 2016 from National Instruments and BioRadio devices with pulse oximeter
attachments from Great Lakes Neurotechnologies will be provided by the Biomedical
Engineering Department at the University of South Carolina. Together, LabVIEW and
BioRadio devices will be coupled to create an alert system that can interpret the readings of
a pulse oximeter, alert for concerning and critical ranges, and distinguish the ranges of
normal and abnormal PR and blood SpO2 customized and can be easily tailored to the
patient.

Page 6 of 24
Upon completion of this project, the program will be able to readily obtain and analyze
real-time data from a Bluetooth-connected pulse oximeter, able to readily customize the
ranges of PR and SpO2 to fit the needs and unique conditions of each patient, as well as
record, save, and transfer the data to a text file.

The goals and objectives of this project are as follows:

Goal 1: Develop LabVIEW system compatible with BioRadio pulse oximetry sensors for
data collection.
Objective 1a: Link BioRadio software to LabVIEW to display collected pulse
oximeter data on 2 separate graphs
Objective 1b: Set programming to collect data every 500 ms.
Goal 2: Design LabVIEW to analyze and filter data.
Objective 2a: Develop rule-based system on LabVIEW to recognize and send alert
for concerning behavior using values 50 to 60 bpm PR, 100 to 110 bpm PR, and 85
to 90% SpO2.
Objective 2b: Develop rule-based system on LabVIEW to alert for immediate
attention for critical behavior after 15 seconds of persistent activity of <50 bpm PR,
>110 bpm PR, and <85% SpO2.
Goal 3: Verify program can write and save data to a file, and annotate coding program for
ease of understanding.
Objective 3a: Develop programming to transfer and save data from LabVIEW
environment to a text file of 2 Hz to determine optimal performance (limit excess
raw data while retaining key data points).
Objective 3b: Provided at least 1 descriptive explanation for each function and
command to easily navigate program and allow for customization of threshold
ranges for each unique patient case.

2. Design
The overall design of the program is described in fine detail in both the results section as
well as the methodology section. This section will describe and illustrate the key features
used in the program, detailing their role in the program. The front panel is the user
interface for the program. The front panel contains PR and SpO2 graphs as well as control
that the user can select. The Block Diagram contains the script for the program along with
annotations to be used for future groups. By placing the bulk of the program in a case
structure, we can easily add or remove functions to the program without running the risk
of breaking the program as a whole. It helps keep the program organized, and it will
potentially allow future groups to make the program compatible with other biomonitoring
sensors.

Page 7 of 24
Within the case structure there are several cases, including the event handler. The event
handler is the default case the program enters upon running the program. The program
will stay in this case until the user selects start data collection on the front panel. The
second case in the case structure is the data collection case which collects data from the
BioRadio, graphically and numerically displays PR and SpO2, and converts data into a text
file. This case also contains Boolean operators which will prompt the program to switch to
the “AbnormalityDetected” case if given thresholds are exceeded. The abnormality detected
case also collects data from the BioRadio, graphically and numerically displays pulse rate
and SpO2, and converts data into a text file. If this case is run, an error message will appear
to the user. This case will return back to the Data collection case if pulse rate and SpO 2
return back to normal.

Within these case structures, there are WHILE loops which are essential for data
processing. WHILE loops allow the program to perform a task continuously until instructed
to do otherwise by the user. Toggle buttons were created to artificially raise the readings,
while allowed for testing of the alert mechanism to ensure the program could successfully
identify rise in PR and SpO2. Shift registers are used to pass information from one iteration
of the WHILE loop to the next iteration. For the purpose of this project, shift registers were
used to save the most recent 15 s of data collected to be averaged and compared to the
Boolean comparators. A 500 ms timer is applied to each WHILE loop iteration, which set
data collection at a rate of 2 Hz. The various BioRadioSDK sub-VI functions allow the
program to communicate with the BioRadio device for data collection and acquisition. The
queue, enqueue, and dequeue elements allows the program to easily switch between cases,
in accordance with the user’s input values. Boolean comparator function compare the data
acquired from the pulse oximeters to the alert thresholds specified.

3. Methodology
To complete the first goal, a signal processing, and data acquisition code was written in
LabVIEW that collects data from a pulse oximeter. Fundamental programming functions,
such as WHILE loops, case structures, event structures, queue statements, and other
LabVIEW functions were used in the code. Pulse Diagnostics used the weekly meetings
with Nick Boltin to learn the basics of programming in LabVIEW. In addition to these
meetings, the LabVIEW toolbar was integral in learning how to program. The toolbar
contains a short description of all functions and objects as well as examples of how to use
them. The first step in writing the program was to establish Bluetooth connectivity with a
pulse oximeter. There was difficulty in initially establishing this connection because
medical devices have laws protecting the manufacturers from revealing certain
information. Most pulse oximeters do not display their UUID and MAC address, which is
vital for connecting to the device. To overcome this, the group used the BioRadio with pulse
oximeter attachment from Great Lakes NeuroTechnologies, provided by the Biomedical

Page 8 of 24
Engineering Department. The Bluetooth connection was established by downloading an
software development kit. The kits contains important sub-VIs which search for the
BioRadio using Bluetooth connectivity, interpret the data from the pulse oximeter and
convert the data into numerical values. Aside from the BioRadioSEARCH sub-VI, these
functions were placed in a WHILE loop so that the data is continuously processed. After
these functions were established, a case structure was written to keep the program
organized and to separate the different parts. The case structure has an “EventHandler”
case, “DataCollection” case, and “AbnormalityDetected” case, as named in the program.
When the program is started, it will immediately connect with the pulse oximeter and enter
the “EventHandler” case, where it will await input from the user. Control buttons were
inserted into the Front Panel, which allow the user to start and stop data collection. The
“EventHandler” case was written so that once a “Start Data Collection” button is selected,
the program switches between cases and will begin to run the data collection case. The
next step was to write the data collection case capable of collecting the data from the pulse
oximeter and displaying it graphically. Inside the case structure another WHILE loop was
inserted for data processing with a timing function set at 500 ms. Then the read and write
functions were inserted as well as a LabVIEW graphing function. This graphing function
unbundles the data from the pulse oximeter and graphically displays the values for both
SpO2 and PR on the Front Panel. Indicators were also added which numerically display the
values for PR and SpO2 on the front panel for the user.

To complete the second goal, Boolean statements were written that establish a threshold
for PR and SpO2 values. These Boolean statements establish a healthy range for SpO2 and
PR and can be found in both the “DataCollection” case and the “AbnormalityDetected” case.
These Boolean statements use the average value of the PR and SpO2 over a 15 s period. To
do this, case registers were added to the WHILE loop so that the data points from the
previous 15 s are saved after each iteration of the WHILE loop. Then, those values are
averaged using an averaging function. That average value is sent through a Boolean
statement that determines if that value is within the threshold for PR and SpO2. If the value
is not, this prompts the program to send an error message and switch cases in the case
structure. The range of healthy values was determined based off researched standard
values based on age, weight, and gender of the average healthy adult. However, the
patient’s physicians can adjust these values based on medical conditions and any chronic or
current conditions. The physician will not be able to do this on the front panel; however,
there are easy to follow instructions that detail how to change these values in the block
diagram. If the patient’s PR or SpO2 fall out of the acceptable range, an abnormality
detected case is run from the event handler, and an visual error message is sent to the user.
As stated in the goals and objectives, there will be two thresholds for SpO2 and PR. There
will be an initial threshold set based on concerning values and then a second threshold set
based off critical values. Once again these values were based off researched values for the

Page 9 of 24
average healthy individual, however, the physician can decide to adjust these values as
well. If the threshold for concerning values is exceeded, the first abnormality detectanct
case will be run. From this case, there are two possible ways the program can proceed. If
the values return to normal within the 15 s time frame, the program will return back to the
regular data collection case. However, if these values elevate or fall even more, the program
will send a second error message indicating immediate attention is needed.

To complete the third goal, a data saving function was added to the program. This function
was discovered on the LabVIEW toolbar and it converts the pulse oximeter into an excel
spreadsheet and saves the data. When a control button on the front panel is selected, the
program starts saving data with a frequency of 2 Hz. The largest data collection period the
Pulse team tried was 20 minutes, however the Pulse team and our advisor Nick Boltin
believe the program can save data over a two hour span. Once the save data button is
selected for a second time, the program stops saving the data and converts the data into a
text file available to the user. 2 Hz is an arbitrary value that was selected based off advice
by Pulse’s advisor Nick Boltin. However, testing was completed to confirm that this value is
optimal. As stated in the objectives, this value was adjusted in 0.5 Hz increments in order to
determine the optimal frequency. 2 Hz was determined to be the ideal frequency because it
limited bulk information without losing any important data.

4. Results
Currently, our program has met all of our objectives. Once the program is started, the
program will present the user with a front panel displayed in Figure 2. It is able to
establish a connection to the BioRadio using a series of sub-VIs released as part of a
LabVIEW software development kit by Great Lakes National Institute. Upon connecting to
the BioRadio, the program illuminates an LED on the front panel, allowing the user to verify
that a connection has been established. From this point forward, the patient can start or
stop data collection as needed by clicking the corresponding buttons.

Page 10 of 24
Figure 2. LabVIEW Front Panel observable by the user. The key features include a
button to enable data saving, a chart to display PR over time, a chart to display SpO 2 levels
over time, a button to start data collection, a button to stop data collection, and a button to
stop the entire program in the event that the program crashes and needs to be restarted.

There is also a clearly labeled button to start or stop writing data to a file on the computer.
This button can be pressed activated at any point before or during data collection. Once the
“start data collection” button is pressed, the program automatically begins running the case
displayed in Figure 3. It will continuously collect data every 500 ms, and compare the
average of the collected data values to the thresholds. This data will be displayed on the
corresponding graphs on the front panel. “Increase PR” and “Increase SpO2” buttons have
been included to artificially elevate readings for purpose of testing the alert system only,
and will be hidden from the user in the completed program.

Page 11 of 24
Figure 3. LabVIEW Block Diagram of the coding for the data collection case. The
entirety of data collection happens within a WHILE loop that repeats every 500 ms (2 Hz).
Each data point is averaged with previous readings and then compared to threshold values,
and written to a document. If a threshold is exceeded, the loop is terminated, an alert is
triggered, and the program switches to the “AbnormalityDetected” data collection case.

In the event that one of these thresholds is exceeded, the WHILE loop is terminated, an
alert message and auditory cue will be triggered, and the program will automatically shift
to the “AbnormalityDetected” data collection case that is displayed in Figure 4. Data
collected in this case will automatically be written to files on the patient’s computer. This
will allow the patient to have a record of exactly when an abnormality was detected and of
how long it persisted regardless of whether they pressed the “Save Data” button. In the
event that the readings return to the healthy range, a similar alert and auditory cue inform
the patient that their readings have returned to normal, and the program continues in the
“DataCollection” case from Figure 3. Once in this case, data will only be written to the file if
the patient selects that option. We have designed our program in this manner to make the
transition between collection cases as seamless as possible and to make the program easy
to use for the patient.

Page 12 of 24
Figure 4. LabVIEW Block Diagram of coding for the “AbnormalityDetected” case. It is
a mirrored copy of the data collection case, but includes “and” Booleans for thresholds to
verify that all readings are in the healthy range before returning to the data collection case.

Completion of this project will yield a successfully developed can expect to successfully
develop a LabVIEW program compatible with BioRadio pulse oximeters to collect, record,
and save real-time data. The program will also allow primary care providers the ability to
easily configure and customize the concerning and critical ranges to suit and address their
patient’s unique conditions. The LabVIEW Bioradio pulse oximetry programming will
provide an improvement on an already useful and cost-effective biometric device.

Along with the immediate results described above, this project will also provide proof of
concept for further clinical studies and applications. This project is evidence that constant,
consistent, and convenient monitorization of patient PR and SpO2 rates can be obtained
and recorded for later and further analysis over time. The LabVIEW programming also
provides the option of customizing the ranges for which the program will alert for, enabling
primary care providers to tailor to each subject’s unique health conditions, as well as refine
and improve patient care.

The success of this project will set the foundation for future patient care. Information can
readily and continuously be obtained, the patients themselves will have a better
understanding of their condition and are encouraged to play an active role in their health.

Page 13 of 24
6. Conclusion
Pulse Diagnostics made a great progress toward the completion of the project, as can be
seen from the results section. The first goal of establishing the LabVIEW system was
achieved during Fall 2017 semester and can be seen in Figure 5. Both objectives of the goal
were achieved as the group managed to link the BioRadio unit to the LabVIEW system to
display both the PR and SpO2 on two separate plots. There were some issues experienced
while performing this task, since the establishment of the Bluetooth connection with the
pulse oximeters was hard to achieve since the MAC address and UUID of both pulse
oximeters could not be obtained. The group also managed to achieve the second goal which
was basically to establish an alarm system in the LabVIEW environment that is capable of
interpreting the pulse oximeter readings that includes alert for concerning ranges and
distinguish the ranges of the normal and abnormal vital signs. Upon the completion of the
goal, the group experienced both administrative and technical issues which caused delays
in the time scheduled for the completion of the task. The administrative issue that banned
the group from accessing the LabVIEW system was resolved by re-downloading the
Software Development Kit (SDK) file from the Great Lakes NeuroTechnologies website into
a folder that has public access to the group members. It appeared that the issue was mainly
getting the permissions to read a folder that needed administrative access. The technical
issue the group experienced was the unbundling of the 2-D array and creating a case
structure to enable the formation of the thresholds. The issue was resolved by referring to
the subarray and the reconstruction of the LabVIEW system. After completing the first and
second goal, the group members were capable of verifying that the program is functional
and is capable of writing and saving data to a text file of 2 Hz. There were no issues
experienced in the final step of the project which allowed the confirmation of the
completion of the project.

Since pulse oximeters are considered to be practical and cost-effective, one limitation is
that aren’t capable of detecting the occurrence of heart attack, since it alters the rhythm of
the heart but not necessarily the PR. Thus, it can be said that pulse oximeter utilized in this
project is currently designed for healthy users only. In addition, the pulse oximeters
currently used function through USB connection, then the connectivity can be altered in the
occurrence of a malfunction such as loss of connection in the case of the device being
unplugged through accident or rather intentionally. Thus, having a limited range of
movement despite having consistent data collection.

Page 14 of 24
Figure 5. Illustrates the LabVIEW system. The system is capable of collecting data from
the PR and SpO2 within 15 seconds time interval.

6. 1 Budget
The University of South Carolina Biomedical Engineering Program provided the project
with a budget of an amount of $1,000. The equipment mentioned in Table 1 are essential
for the completion of this project by May 2018. Certain adjustments had to be made, as the
Matlab software had to be eliminated from use, however, it did not have an impact on the
overall budget as it was provided to Pulse Diagnostics group by the College of Engineering.
The two pulse oximeters that will be utilized for this project are necessary for measuring
PR and SpO2, in addition to obtaining data that will be analyzed using softwares LabVIEW.
The first pulse oximeter mentioned in Table 1 is compatible with Bluetooth, to allow for
wireless transfer of information from the pulse oximeter to the LabVIEW software. The
second pulse oximeter is USB-compatible, for secure data collection in the event the
Bluetooth pulse oximeter device fails. The LabVIEW software will be available for use in the
Biomedical Engineering laboratory and will enable the measurement of the data obtained
from the pulse oximeter. The biomedical engineering department provides the BioRadio
unit which will allow the recording and transmitting of both the SpO2 and PR from the pulse
oximeter utilized and display them in the programmable channels. The project equipment
in Table 1 was revised and approved by project advisor Nick Boltin.

Page 15 of 24
Table 1. Pulse Diagnostics’ budget. The total budget estimated for the analysis of Pulse
Oximeter Sensor Data project.
Material Price Use

Bluetooth Fingertip Pulse $38.95 Measure PR and SpO2 .

Oximeter Oximetry Blood
SpO2 Monitor and PR
Monitor for Apple and
Android

24HR Recorder Pulse $34.00 Measure PR and SpO2.

Oximeter Blood Oxygen
Monitor with PC software

LabVIEW Provided by Used to measure and capture PR and

the Biomedical SpO2 obtained from pulse oximeter.
Engineering
Department

Avantree aptX Low Latency $32.38 Establish and receive Bluetooth

LONG RANGE Bluetooth 4.1 connections from non-Bluetooth
Adapter for PC, Driver-Free computers to the pulse oximeters.
Wireless USB Audio Dongle

BioRadio device with pulse Provided by Recording and transmitting of the SpO2
oximeter attachment the Biomedical and PR from the pulse oximeters
Engineering utilized.
Department

Total cost $105.33

7. Future Plans
Since our program is only capable of transferring and saving data from the LabVIEW
environment to text file of 2 Hz on a local database, future groups could pursue and build a
client-server relationship by adding a server component. The server components could be
expanded to include a remote database such as such Engineering Workstation (EWS) and

Page 16 of 24
possibly Amazon services, but this server-database relationship must be the chief focus of
future research. In addition, the general principle behind this program could possibly be
expanded to include other biomonitoring sensors such as Photoplethysmography (PPG),
which is utilized to measure the volumetric changes in the peripheral blood circulation.
The project could also be expanded to include blood glucose monitors to enable continuous
monitoring of glucose concentration in the bloodstream. The two areas mentioned need to
be further explored and researched since this project is mainly based on obtaining a proof
of concept. A possible function future groups could also add to the program is to include
different tiers of thresholds since the program is only limited to determining if the values
are within the norm or not. The ability to alter user/client threshold parameters could
potentially be added to the user interface of the program since people with different type of
disorders, such as pneumonia or any other pulmonary disease, could have lower PR and
SpO2 levels compared to other patients; therefore, it can be said that the integration of the
ranges tailored to a patient’s pre-existing conditions could lead to developing a better
monitoring system. Finally, another future investigation would be to introduce different
pattern recognition techniques since they have been used widely in the area of signal
processing, thus, could be explored in this application. These promising techniques include
but are not limited to Decision trees, which is a predictive modeling approach utilized in
statistics, data mining and machine learning. The Artificial neural network is also another
technique considered, and which happens to be the main tool used in machine learning.
The functionalities mentioned to be pursued by future groups are suggested and approved
by the project advisor Nick Boltin.

Page 17 of 24
References
1. Vold ML, Aasebø U, Wilsgaard T, Melbye H. 2015. Low oxygen saturation and
mortality in an adult cohort: the tromsø study. BMC Pulm Med 15:9.
2. Jevon, P. 2000. Pulse oximetry: practical procedures for nurses. Nursing Times
96:43-44.
3. Jensen L, Onyskiw J, Prasad NGN. 1998. Meta-analysis of arterial oxygen saturation
monitoring by pulse oximetry in adults. Heart & Lung 27:387-408.
4. Carroll, P. 1997. Pulse Oximetry at your fingertips. RN 60:22-27.Lowton, K. 1999.
Pulse oximeters for the detection of hypoxaemia. Prof Nurse 14:343-350.
5. Lowton, K. 1999. Pulse oximeters for the detection of hypoxaemia. Prof Nurse
14:343-350.
6. Blood Sugar Level Ranges. Normal and Diabetic Blood Sugar Level Ranges -Blood
Sugar Levels for Diabetes.

Page 18 of 24
Appendix

Figure A1. Left half of the LabVIEW Block Diagram “DataCollection” case.
LabVIEW programming is quite large, and stitching the image together resulted in
decreased resolution and visibility for the purpose of this report. This represents the left
half of the LabVIEW “DataCollection” case, with annotations for future teams to better
understand the purpose of each function.

Page 19 of 24
Figure A2. Right half of the LabVIEW Block Diagram “DataCollection” case.
LabVIEW programming is quite large, and stitching the image together resulted in
decreased resolution and visibility for the purpose of this report. This represents the right
half of the LabVIEW “DataCollection” case, with annotations for future teams to better
understand the purpose of each function.

Page 20 of 24
Figure A3. Left half of the LabVIEW Block Diagram “AbnormalityDetected” case.
LabVIEW programming is quite large, and stitching the image together resulted in
decreased resolution and visibility for the purpose of this report. This represents the left
half of the LabVIEW “AbnormalityDetected” case, with annotations for future teams to
better understand the purpose of each function.

Page 21 of 24
Figure A4. Left half of the LabVIEW Block Diagram “AbnormalityDetected” case.
LabVIEW programming is quite large, and stitching the image together resulted in
decreased resolution and visibility for the purpose of this report. This represents the left
half of the LabVIEW “AbnormalityDetected” case, with annotations for future teams to
better understand the purpose of each function.

Page 22 of 24
Figure A5. Left half of the LabVIEW Block Diagram “EventHandler” case.
LabVIEW programming is quite large, and stitching the image together resulted in
decreased resolution and visibility for the purpose of this report. This represents the left
half of the LabVIEW “EventHandler” case. The right side is not shown, as it is empty white
space to accommodate the size of the program within the other cases.

Page 23 of 24
Figure A6. Left half of the LabVIEW Block Diagram “FirstTime” case.
LabVIEW programming is quite large, and stitching the image together resulted in
decreased resolution and visibility for the purpose of this report. This represents the left
half of the LabVIEW “FirstTime” case. The right side is not shown, as it is empty white space
to accommodate the size of the program within the other cases.

Page 24 of 24