Milestone II

Plan

1. 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

2. Picking microcontroller

   • What we looked for

   • Connectivity (Bluetooth, WIFI, etc)

   • Size, physical size and the pin connections to enable connectivity to sensors 

3. 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

       1. So this will have to do with where this will be deployed

   • Setting up rudimentary software for connectivity

4. 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?

5. Online Integration

   • Setting up database to hold information 

   • user/professional interface

6. 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 

Time Breakdown

1. Research (September 3- September 20)

2. Picking monitors + MCU and ordering (September 21 - October 20)

3. 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 

4. 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

5. 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

6. 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 

7. 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

8. 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

1. Compact

1. • 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 

2. 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

     1. Get consent from the patients to access their data

     2. 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

3. 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 

4. 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 

Design Concepts

Selecting concept design => how to approach 

• Investigate different options designs, trade-offs, technical/non-tech issues 

1. Rechargeable battery 

2. Wireless Rechargeable battery (so patient can leave it on)

3. Use of separate microcontroller and accelerometer

4. Use of microcontroller with accelerometer capabilities

5. 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 

What hardware we’re using

• 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

How will we analyze our hardware? 

What software we’re using?

• App => SDK?

• Using Amazon Sidewalk 

• 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

How we are testing 

• Wearability

  • 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 

• Monitoring the data

  • 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

      1. Each monitor will send information via the serial monitor to ensure that the data is being properly transferred

      2. 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

      1. This will ensure that the database is set up correctly to the software

      2. This will ensure that the device is monitoring and showing the correct values

         1. 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