🔧 Building: now

medical-autonomous-streamlined-triage

Hackathon: Create&Innovate @ UH 2026 by MAES-UH, AIAA-UH, BMES-UH, CougarAI, and oSTEM.

or MAST for short

working on a custom PCB for the patient monitoring device.

GitHub
C++

Recent Commits

GitHub README

MAST Hackathon Project

Shane Abbott, Justin Amaya, Tyler Marleton, Christian White, Karla "Kenny" Madrigal

Overview

Key Design Criteria

Continuous vitals monitoring from wearable patient devices.

Automatic triage status information when patient conditions change.

Real-time transmission of patient data to hospitals.

Reduced workload for EMS personnel, allowing responders to focus on treatment instead of communications.

Components (Tentative)

1. Patient Monitoring Device

Strapped onto the patient as a harness, monitoring vitals such as heart rate, blood pressure, temperature, etc. The deivce would transmit information to the ARU in the vehicle automatically, no human input is necessary.

2. Ambulance Repeater Unit

Amplifies transmissions from the patient monitoring device to nearby hospitals. High wattage to counter urban RF environments. Pings the HTU for open beds and/or other qualifying information and services. Receives PMD data.

3. Hospital Transciever Unit

Located in the hospital, possibly near the radio equipment. Should have excellent RX capabilities. The final step in the process, this is what the hospital staff see, the end product of all incoming patients, in one place.

Kenny: Question, could a filtering system allow doctors to subscribe to patient updates in real-time, receiving only information relevant to their assigned cases? Also, how do cases get assigned? I doubt whether any of these questions are within the scope of our project, and I think we're better off focusing on the existing components.

Project Structure

I'd like for each project inside each directory (electrical/firmware/assembly) to have its own DECISIONS.md so we can keep track of... decisions.

I've initialized KiCad and PlatformIO projects in the electrical/firmware directories. Mech team (Christian, Justin, Shane) can decide how they want to structure the assembly directory.

├── patient-monitoring-device/
│   ├── electrical
│   ├── firmware
│   ├── assembly
│   └── DECISIONS.md
├── ambulance-repeater/
│   ├── electrical
│   ├── firmware
│   ├── assembly
│   └── DECISIONS.md
├── hospital-transciever/
│   ├── electrical
│   ├── firmware
│   ├── assembly
│   └── DECISIONS.md
│   
└── README.md

Getting Started

Prerequisites

Contributing

  1. CLONE the repository, not fork. i mean either way doesnt matter but for the sake of simplicit. yas.
  2. Create a feature branch (git checkout -b feature/your-feature)
  3. Commit changes (git commit -m 'Add feature')
  4. Push to branch (git push origin feature/your-feature)
  5. Open a Pull Request. PRs are to merge from your feature/ branches to the main branch

TODO

  • Define clear project outcome and success criteria
  • [Add additional tasks]

Project Journal

PMD DECISIONS

Mar 14, 2026

from patient-monitoring-device/

HTU DECISIONS

Mar 12, 2026

from hospital-transciever/electrical/

ARD DECISIONS

Mar 12, 2026

from ambulance-repeater/electrical/

PMD DECISIONS

from patient-monitoring-device/

open journal page open source file

The PMD will be a wearable harness measuring HR, SpO₂, skin temp, and motion with an ESP32-C3.

Power-on will avoid exposed switches, using a pull-tab, magnetic, or strap-contact method handled by the mech team. Sensors/electrodes will have secure skin contact, adjustable for different sizes.

Electrodes are peripherals to the PCB, and will be placed in non-invasive areas (particularly for female patients.)

Communication to the ARD will use ESP-NOW, with unit tests simulating multiple PMDs sending randomized packets to ensure reliable many-to-one handling and proper device ID management.

Hardware design will consider antenna keep-out, decoupling, and stable power rails for robust operation.

Electrical

Microcontroller: ESP32-C3 in module form like ESP32-C3-WROOM-02U. (to attach an external antenna to avoid signal shielding) Monitors: Heart rate, respiration, skin temperature, blood oxygen.

The first choice was the MAX86178, which wouldve been the most power efficient and also handle synchronization at the hardware level. However this is locked behind NDA and is sold only to institutions.

VitalICJustification
Heart rateMAX30001ECG and BioZ resp. 2 birds w/ one stone
RespirationMAX30001Same as above
Skin TemperatureTBDbased on mech teams’ electrode/sensor placements
Blood Oxygen (Oxygen Saturation)MAX86141ultra-low power, connected to external LEDs and photodiodes, suitable for more flexible electrode placement. MAX86141 also supports dual channel which can generate a differential signal to cancel out motion artifacts
Q: “Why are we not using the MAX32664 sensor hub”?A: that’s calibrated for finger and wrist configs.

Assembly

Mechanical team should decicde on a harness design and on electrode locations for vitals monitoring. (heart rate, breathing, temperature, etc).

Harness brainstorm:

  • EMS should be able to rapidly strap onto a patient during triage
  • To power on, the mechanical design should consider a reliable activation mechanism (e.g., pull-tab battery, magnetic activation, or strap-contact power) so the device powers on automatically during application without relying on an exposed switch.
  • The harness should also provide secure skin contact points for sensors/electrodes (heart rate/SpO₂ and skin temperature) while remaining quick to apply and adjustable for different patient sizes.
Harness example