The MQTT protocol is a message transmission protocol based on TCP-IP networks, which adopts a publish-subscribe mode and features openness, simplicity, lightweight, and ease of implementation. It is particularly suitable for limited environments such as low bandwidth, unstable networks, embedded processors, and insufficient memory [5].

Message delivery reliability in MQTT is controlled by Quality of Service (QoS) levels. QoS Level 0 delivers messages at most once without guaranteed delivery; QoS Level 1 ensures messages are delivered at least once but may result in duplication; and QoS Level 2 guarantees exactly-once message delivery with the highest reliability [5]. In this implementation, QoS Level 2 was adopted to ensure that emergency distress messages were accurately delivered and processed by both the hospital rescue management platform and the smart key box terminals.

The front-end of the hospital rescue management platform served as the primary interface for user interaction and emergency coordination. Core functions included user information management, IoT device binding, real-time device status monitoring, interactive message publishing and querying, and collaborative information processing.

Through the platform interface, family members were able to track the status of emergency alerts and device operation, while emergency personnel could receive distress notifications in real time, review basic patient information, and coordinate rescue actions across multiple departments.

With the rapid proliferation of IoT applications, the number and diversity of connected devices continue to grow, posing significant challenges in device registration, status monitoring, data management, and coordinated operation. Heterogeneous IoT devices typically use different communication protocols and data formats, making centralized management and efficient information exchange crucial for ensuring system reliability and scalability—a requirement that necessitates an IoT management platform for unified control [6]. Based on this requirement, a centralized device management backend system was designed to integrate and manage all IoT devices, including smart emergency buttons and smart key boxes. The backend provided a unified management interface and API interface for device status monitoring, remote control, linkage control, and system maintenance.

The backend also supported data exchange with external institutions, such as emergency centers, enabling timely information sharing and coordinated response during emergency events.

To enhance usability and accessibility, mobile-based interactive tools, including WeChat (Tencent) mini programs, were developed. These tools enabled users to receive emergency notifications and system reminders in real time. The mobile interface was seamlessly integrated with the smart IoT platforms, facilitating convenient access to system information and improving overall user experience.

The system deployment environment included in-home IoT call buttons, IoT key boxes, internal and external network server zones, medical work areas, mobile devices used by users and family members, and 120 emergency center system server areas (planned for future integration; the current simulation used SMS-based notification instead of direct dispatch integration). The overall system composition is shown in Figure 1.

Role-based access control is implemented following the principle of least privilege, with distinct roles defined for hospital dispatchers, 120 operators, family members, and other stakeholders. Remote unlocking of the smart key box requires trusted remote authorization. Mutual certificate-based authentication is enforced between devices and the platform. All operational records are stored in an immutable log and subject to regular auditing. Users sign informed consent agreements and are supported with the ability to withdraw consent. Transport Layer Security (TLS) encryption is applied to all data transmission. IoT modules in the system periodically report their status to the server to confirm communication availability. On the management side, abnormal devices are promptly flagged, and notifications are sent to administrators for follow-up action. For system availability, load balancing is introduced such that when a node fails, requests are automatically rerouted to available nodes. System stability is further supported by measures addressing network interruptions (local caching and retransmission), power failures (backup batteries), and false triggers (alert activation requires a long press of ≥3 seconds).

IoT development board served as the core control units for both the intelligent distress button and the smart key box. ESP32 and ESP8266 microcontrollers were selected due to their low power consumption, high performance, high compatibility, and rich peripheral interfaces, making them very suitable for IoT applications [7,8]. These controllers processed user input signals and communicated with smart IoT platforms. The circuit design of ESP32 is shown in Figure 2.

The intelligent distress button functioned as the primary user-facing interface and was designed to be intuitive and easy to operate. A regular hexagonal button with a side length of 35 mm was selected to accommodate older users [9]. To address concerns regarding older adults’ digital literacy and prevent false alarms, the button adopted an antimisoperation design: a single click is ineffective, and users must press and hold the button for at least 3 seconds to trigger an alert. Stable electrical connections and circuit protection measures, including current limiting and electrostatic discharge protection, were incorporated to ensure reliability [10]. Visual indicators, such as LED lights, were used to display device status.

The smart key box was constructed from durable materials to withstand environmental exposure and potential external damage. It supported multiple installation methods, including wall mounting and peephole installation.

An electromagnetic lock served as the access control mechanism, allowing authorized remote unlocking during emergency situations. The system used a 5V 4-wire electromagnetic lock controlled via a relay driven by the ESP8266 microcontroller [11]. A high-level control signal of approximately 0.5 seconds triggered the unlocking mechanism. Lock status feedback signals were monitored in real time to confirm successful unlocking and ensure operational safety.

Flexible power supply solutions were adopted based on device function and usage scenarios. Smart key boxes requiring long-term stable operation were powered by portable power modules or large-capacity lithium batteries (recommended capacity of ≥5000 mAh). Intelligent distress buttons with low power consumption requirements used coin cell button batteries (eg, CR2032) or rechargeable lithium batteries. Voltage monitoring functions were incorporated to alert users when battery levels were low, supporting continuous and reliable system operation.

To evaluate the feasibility and operational performance of the emergency assistance system, functional and integration testing was conducted under simulated real-world conditions. The evaluation covered end-to-end emergency workflows, including distress activation, data transmission, platform response, notification delivery, positioning, and remote unlocking.

The experimental platform and configuration are as follows: the distress button is made using ESP32 series modules as the core, the MQTT message broker uses EMQX platform (Hangzhou EMQ Technologies Co., Ltd.), the server uses an in-house virtual machine running Microsoft Windows Server 2012, with a specific configuration of an 8-core processor, 4G memory, a system database of MySQL 5.7 (Oracle Corporation), a keybox built using ESP8266 series modules and electromagnetic locks, the platform system development tool is Eclipse (Eclipse Foundation), the IoT board development tool is Thonny (Aivar Annamaa), the firmware is MicroPython, and the development computer OS is Windows 11.

Hospital medical staff were recruited as volunteers through an internal hospital announcement. Inclusion criteria were (1) currently employed medical staff familiar with emergency procedures; (2) voluntary participation with signed informed consent; and (3) no severe visual or hearing impairment that would prevent normal operation of the smart emergency button. A total of 5 volunteers (3 females, 2 males; age range 28‐45 years) were enrolled, all of whom played the role of the person initiating the distress call. Other response roles—including hospital platform operators, 120 simulated dispatchers, and simulated family contacts—were performed by research team members and hospital medical staff.

System simulation testing was completed within a single day, with a total duration of approximately 4 hours. Three types of scenarios were designed: (1) active long press of the emergency button (≥3 seconds), (2) antimisoperation testing (short press <3 seconds), and (3) consecutive distress activation (10 minutes of continuous testing, with 3 triggers within a 10-minute window). Each volunteer completed all 3 scenarios sequentially, performing 3 tests per scenario, resulting in a total of 9 simulated distress events per participant. For each distress event, the entire process from button activation to key box unlocking was quantitatively recorded using system logs and structured observation forms. The average duration per event was approximately 2 minutes.

Prespecified key performance indicators were used to assess system effectiveness: (1) distress trigger success rate: the proportion of long presses (≥3 seconds) resulting in successful alert reception by the platform, required to be ≥99%; (2) transmission latency: the time interval from button activation to “received” timestamp in the hospital platform log, required to be ≤10 seconds; (3) lock release completion time: the duration from rescue personnel’s unlock request to key box release, required to be ≤1 minute; and (4) antimisoperation effectiveness rate: the proportion of short presses (<3 seconds) that did not generate an alert, required to be 100%. All indicators were dual-recorded using system backend log timestamps and on-site observation forms.

Two research team members (Lei Feng Jiang, Hui Qing Chen) were present throughout the testing process. They used a structured observation form to document each button operation type, platform feedback status, lock release execution, and any anomalies. Observation form data were cross-checked against system logs by 2 independent reviewers to ensure consistency. Regarding user privacy and security, all system data were stored on servers on the hospital premises, and data transmission was encrypted through interfaces. To ensure comprehensive data collection and support transparent evaluation, 3 types of data sources were used in this study: (1) system backend logs: these recorded key performance indicators including smart emergency button trigger time, response confirmation time, unlock operation logs, and data transmission integrity; (2) simulated emergency scenario observation form: this structured form was used to document the complete distress call process conducted by the 5 medical staff volunteers in the 15-square-meter simulation site; and (3) device stability test records: these provided statistics on system interruptions, functional failures, and false alarm/missed alarm counts during continuous operation.

The system was evaluated in a simulated clinical implementation setting to assess its feasibility, stability, and workflow integration under conditions approximating real-world home emergency scenarios. Following ethical review and approval, a room with an area of 15 square meters was selected as the simulation site, and the system was installed according to the design requirements. This study was conducted as a pilot project. After passing simulation testing, it was put into clinical validation.

As described above, 5 medical staff members were recruited as volunteers to participate in simulation emergency scenarios. During the implementation period, the research team observed the full emergency response workflow, including distress signal triggering, system connectivity monitoring, alert transmission and confirmation, key box unlocking, and information access via the platform. All simulated emergency events progressed through the predefined workflow without system interruption or functional failure.

System-level testing demonstrated that the emergency assistance system was able to support home-based emergency response during simulated acute medical events. Regarding the average time from emergency trigger to successful pre-entry activation, when the smart emergency button is pressed and held for 3 seconds or longer, the system transmits the distress signal to the hospital rescue management platform within 5 seconds, while simultaneously automatically notifying the 120 emergency dispatch center and the patient’s family members, ensuring that the distress message is received and acknowledged within 10 seconds. Upon receiving the emergency alert, the platform accurately detects the GPS location of the person in distress with a positioning error of less than 10 meters. After rescue personnel arrive at the scene, the system completes the remote unlocking process within 1 minute. From the moment of distress activation to receipt and confirmation of the emergency signal by the platform, the complete communication and feedback process was completed within 18 seconds. The system supported a one-click quick distress operation, enabling emergency notification and coordination immediately after activation. Following confirmation by medical personnel, the system enabled remote unlocking of the household entry point within 1 minute of rescue personnel arrival, thereby reducing delays during the critical emergency response window.

When the emergency button was pressed continuously for at least 3 seconds, the ESP32 controller detected the input and provided visual feedback via a flashing indicator light. In a subset of stability tests (10 consecutive activations), the device demonstrated a 100% triggering success rate, while the overall rate across all 45 scenario tests was 97.78%. An example of the emergency button activation process is shown in Multimedia Appendix 2.

Once activated, the emergency button automatically transmitted a distress signal to the backend server via MQTT. The server receives and parses the message and generates automated notifications to on-duty medical staff via text messages. Distress records were simultaneously logged and displayed in the rescue management platform for further processing. An example of a distress notification message is shown in Multimedia Appendix 3.

The rescue management platform provided a centralized interface for managing incoming distress alerts. Pending alerts were displayed with detailed information, including distress type, distress time, button name, detailed address, alarm reception time, alarm confirmation time, alarm confirmation person, alarm processing status, and so on (Figure 3).

Select the corresponding distress message line, click the “distress confirmation” button above to confirm the distress message or cancel the distress call according to the actual situation. The confirmation distress message interface is shown in Figure 4. Medical personnel were able to confirm or cancel distress alerts based on real-time assessment. Upon confirmation, the system automatically initiated notification to the 120 EMS dispatch and synchronized alert information with the EMS system (Multimedia Appendix 4). The platform also allowed authorized staff to access integrated hospital health records, including historical diagnosis and treatment information, medication records, surgical records, and examination records, to support informed decision-making (Multimedia Appendix 5).

When the smart key box (electromagnetic lock control board) receives a home distress request confirmed and forwarded after distress confirmation by medical staff, the smart key box receives a remote unlock command. The key box emitted a visible SOS Morse-code flashing signal and automatically released the electromagnetic lock, enabling rapid access for rescue personnel or nearby responders. A functional example of the lock control module is shown in Figure 8.

The system demonstrated stable and timely operation across all key stages of the emergency response workflow. A total of 45 application scenario tests were completed, consisting of 5 volunteers each performing 3 types of scenarios—active long press (≥3 seconds), antimisoperation test (short press＜3 seconds), and consecutive distress activation (3 triggers within 10 minutes)—with 3 repetitions per scenario. All tests were conducted in a 15-square-meter room equipped with the smart emergency assistance system. In a subset of device stability tests (10 consecutive activations), the triggering success rate was 100%. Across all 45 simulated scenario tests, the overall success rate was 97.78% (44/45), with the single failure attributed to a 3D-printed housing precision issue, which prevented successful activation in a specific instance; the issue was subsequently resolved by optimizing the button printing model. No system interruptions were observed during testing. The system achieved a response time within 10 seconds, 100% antimisoperation effectiveness, GPS positioning accuracy within 10 meters, and a 100% successful unlocking rate within 1 minute.

Upon receiving the emergency alert, the platform successfully detected the GPS location of the person in distress with a positioning error of less than 10 meters. Subsequently, the platform issued a remote unlock command, triggering the electromagnetic lock automatically. Household entry was completed within 1 minute in all test scenarios.

In addition, following patient admission, integration with the hospital information system allowed authorized medical staff to access historical health records, including prior diagnoses and treatment information. This functionality supported timely clinical decision-making and facilitated preparation for subsequent in-hospital emergency care.

The older adult–facing interface requires only a single long press (≥3 seconds). Separately, the health care–facing platform interface was evaluated by 5 medical staff volunteers—4 of them rated the interface design as user-friendly and the functions as convenient, and one suggested that more features could be added to support medical decision-making.

Formal usability testing with older adult users has not yet been conducted.

The simulated implementation demonstrated that the system could be effectively integrated into an institutional emergency response workflow. All simulated emergency events progressed through predefined procedures without system interruption or functional failure.

Overall, the simulated clinical implementation demonstrated that the system could be integrated into an institutional emergency response workflow and support coordinated, time-sensitive actions across multiple roles. No major implementation barriers were identified during the simulation period, supporting the feasibility of the system for home-based emergency assistance in the older population living alone. The overall business process of system design [12] is shown in Figure 9, and the user cases are shown in Figures 10 and 11. A detailed step-by-step implementation workflow is provided in Multimedia Appendix 6.