Research
Vitals that are helpful
Getting medical personnel to determine which vitals are the most important to monitor
Devices to measure vitals accurately
Securing mechanism to connect to patient
MCU choices
Picking microcontroller
What we looked for
Connectivity (Bluetooth, WIFI, etc)
Size, physical size and the pin connections to enable connectivity to sensors
Prototyping (physical)
Setting up the MCU
To determine which coding language will be used
Connecting MCU and sensors
Drawing out layout
Making computer drawn model to illustrate
Power up device with sensors and test each sensor individually to ensure that they all work separately while all sensors are connected
See if this works with battery power vs plugged in
How the power consumption works (maybe a model to see how it works over time?)
Setting up the ML for the accelerometer to help to determine if movement is happening
This will help to determine medical emergencies when the patient is home
So this will have to do with where this will be deployed
Setting up rudimentary software for connectivity
Testing RTOS
Real time operating system => sending data to/from device
Wearing device for testing for different lengths of time to see how fast and accurate the data transfer is
Dependent on what device it is connected to -> like a phone via Bluetooth or a hub in a hospital?
Online Integration
Setting up database to hold information
user/professional interface
Deployment + Maintenance
Student uses for the long term
Ability to check for accuracy of results and how the database holds data
Comfort testing
Adapting materials
Ensure that sizing works for may different body types
Research (September 3- September 20)
Picking monitors + MCU and ordering (September 21 - October 20)
Speaking to practitioners (October 25 - February 28)
Nurses
Potentially Doctors? => connect with Sayeed about that
Put together a list of questions for what should be asked that way we can get specific medical information
Prototyping Initial Design(physical) ( November 15 - Jan 31)
Putting together initial design
Testing sensors
Connectivity from device to software
Training ML model for accelerometer
Integration of software for app and data from mcu
Rudimentary integration
Should be able to access data, whether or not it is processed depending on where we want to process the information based on prior knowledge this ideally should not be inside of the MCU since that will cause lag and kill the battery life
Determine how much should be saved on the physical device, and where to store it to ensure that if the device dies it does not lose all of its data
Testing + Maintenance (Feb 1 - April)
Accuracy of sensors
Check each individually
Find the most viable option for our physical design
Speed of data transfer from device to database
Based on proximity
Based on power
Low power
Prototyping App + Data Processing (in Database)
Getting ui functional
Microcontroller connection to database
Enable data transfer and determine parameters for “normal” ranges for HR, etc.
Sending data from database over to app, Real-Time applications
How fast this will update on app/interface
Testing database (Jan 1 - March)
Get fully set up, see how the connectivity will work
Deciding whether or not the computation will be done within the database or after it reaches the software for processing
Wear to test (March - May)
Long-term wear, see how long it takes for battery to wear out
What type of motions render the device useless, and how we can fix this
Compact
Ensure that the design is the smallest volume with the most accurate data
With the different sensors available, plan out different designs to ensure that our end design is the most effective
Integrating data storage to see past vital data to analyze trends and relationships between data categories
Allow for data to be saved in a database per patient
Ensure local data saved on device incase of shut down
Creating data trends with patient information, and make sure that healthcare laws are not violated
Get consent from the patients to access their data
Ensure that if data is being used from multiple different patients that their identity remains anonymous, but their information can still be utilized in an efficient mannor to ensure that the trends can be useful for researchers
Finding a way to centralize vital monitoring for hospital
Instead of just monitoring per patient per room, centralized monitor at say nurse's station so that the data can be monitored
Allow for patients to wear a small device but still allow access for nurses to accurately take their vitals manually
At home patients
Long-term care or chronic illness so that data can be stored and looked over with a physician to speak of causes and potentially relate cases of the same issue together
When targeting to this market, instead of working with different devices/apps that doctors do not have compatible software with
Selecting concept design => how to approach
Investigate different options designs, trade-offs, technical/non-tech issues
Rechargeable battery
Wireless Rechargeable battery (so patient can leave it on)
Use of separate microcontroller and accelerometer
Use of microcontroller with accelerometer capabilities
Finding an easily connectable network of devices to allow for the transfer of data (like Amazon Sidewalk)
What we actually picked:
Using a microcontroller with a built-in accelerometer to minimize size, as well as many digital and analog inputs, rechargeable battery support
Now with the different hardware that we have, we have the ability to work with different heart rate monitors, via red light or electrodes via right arm, right leg, left arm
Below are two concepts wired up to help us find the smallest, most effective device that we can create:
Process Model
Xiao MPU + Accelerometer built-in
Heart rate sensor/ pulse oximeter
Temperature sensor
How often should data be recorded for each sensor? Finding a balance between accurate data representation and device battery life
Accelerometer: high-frequency recording, need instantaneous data
Heart rate: medium frequency, every 1-2 seconds
Pulse oximeter: medium frequency, every 2-3 seconds
Temp sensor: low frequency, every 30 seconds
App => SDK?
Connection between device, database, and app (MQTT sub/pub?)
Arduino coding with microcontroller
How we’re connecting the firmware and database information to work with the app
Have each team member wear for a specific amount of time (3 days? 7days? ) to test the comfort
Test out several different methods of securing the device to ensure that we find the most comfortable, usable method
Adhesive
Elastic
Velcro
Securing
Ensure that the monitors are reading the correct values
Connect via serial monitor for the controller for each sensor separately to ensure that on their own they all work
Once they are all connected, it is important to shape the device in a manner that allows for the different sensors to pick up the correct data
Each monitor will send information via the serial monitor to ensure that the data is being properly transferred
To ensure that the monitor is working other devices/methods will be used on the subject to ensure that the devices are reading the same values
Once the data is being monitored properly with the serial monitor once the device is constructed, the next step will be to ensure that the microprocessor can send the information from the devices to the software application so that it can be monitored in real time
This will ensure that the database is set up correctly to the software
This will ensure that the device is monitoring and showing the correct values
Additionally this will ensure that the ranges that we classify as "normal" reached or exceeded
How long the battery lasts
Range of sensor
Does it need to be connected to a device with a person at all times?
Testing + Maintenance (Feb 1 - April)
Accuracy of sensors
Check each individually
Find the most viable option for our physical design
Speed of data transfer from device to database
Based on proximity
Based on power
Low power
Prototyping App + Data Processing (in Database)
Getting UI functional
Microcontroller connection to database
Enable data transfer and determine parameters for “normal” ranges for HR, etc
Sending data from database over to app, Real-Time applications
How fast this will update on app/interface
Testing database (Jan 1 - March)
Get fully set up, see how the connectivity will work
Deciding whether or not the computation will be done within the database or after it reaches the software for processing
Wear to test (March - May)
Long-term wear, see how long it takes for battery to wear out,
What type of motions render the device useless, and how we can fix this