First-aid quick response method and system based on real-time communication and geographic grid matching

Abstract

The application discloses a first-aid quick response method and system based on real-time communication and geographic grid matching, belongs to the technical field of medical informatization and real-time communication, constructs a three-layer architecture of terminal access layer, core service layer and data supervision layer, adopts a double-layer geographic grid index matching mechanism of Geohash and Google S2, combines an in-memory cache ordered set and a distributed lock to realize millisecond-level automatic allocation of emergency doctors, solves the problems of grid boundary matching omission and high-concurrency resource preemption conflict, configures a low-latency audio and video communication system based on WebRTC+SFU, a doctor on duty pre-connection session pool, ICE candidate pre-acquisition and a multi-layer weak network anti-packet loss strategy, realizes second-level doctor-patient visual docking, and realizes parallel scheduling of multiple types of first-aid resources based on a message queue, and task decoupling and parallel execution are realized. The application supports pre-hospital multi-specialty remote consultation, significantly shortens the golden response window of critical first-aid, and is suitable for county unified first-aid scheduling platforms and large city grid first-aid system deployment.

Description

Technical Field

[0001] This invention relates to the field of medical information technology and real-time communication technology, and more specifically to an emergency rapid response method and system based on real-time communication and geographic grid matching. Background Technology

[0002] The current 120 emergency dispatch system in China relies on the Public Switched Telephone Network (PSTN). The complete handling process is as follows: patient calls to report an emergency → operator records address and injury information → dispatcher manually checks map to match emergency stations → ambulance is notified by phone to dispatch. The entire process depends on manual, sequential handling, which has several unavoidable technical shortcomings:

[0003] First, the sequential workflow results in significant time delays. Each step of the process involves synchronous manual relay operations, with actual measurements showing an average time of 3-8 minutes from alarm activation to the first contact between medical staff and the patient. For cardiac arrest patients, irreversible brain damage occurs after more than 4 minutes of ischemia and hypoxia, and the current dispatch model directly misses the golden window for emergency treatment.

[0004] Second, traditional voice channels cannot transmit on-site visual information. PSTN only supports narrowband audio of 300Hz-3.4kHz and cannot transmit image and video data; emergency doctors can only rely on the caller's description to judge the injury and cannot intuitively grasp the patient's level of consciousness, amount of bleeding, and location of the injury, and cannot carry out standardized remote emergency guidance.

[0005] Third, the positioning relies entirely on verbal descriptions, resulting in large blind spots. The existing system lacks an automatic location reporting channel. When the person reporting the emergency is unconscious, has a language barrier, is in an unfamiliar underground / outdoor environment, or is in extreme panic, the dispatch center cannot obtain accurate coordinates, easily leading to problems such as ambulances being mis-dispatched, lost, or unable to respond.

[0006] Fourth, matching medical staff with emergency vehicles relies on human experience, resulting in low dispatch efficiency. During a call, dispatchers must simultaneously perform address transcription, map search, screening of nearby vehicles, and telephone confirmation of vehicle availability, placing an extremely high cognitive load on human resources. During peak hours, matching errors and slow responses are prone to occur.

[0007] Fifth, social emergency resources are isolated from each other. Certified emergency volunteers, public AED defibrillators, and contracted family doctors in communities are not connected to the unified 120 dispatch system. The first responders cannot be mobilized simultaneously within the critical four minutes, and the situation is left to rely solely on the arrival of the ambulance, thus missing the opportunity for early intervention.

[0008] Existing technologies for optimizing emergency dispatch mainly fall into three categories, but none of them address the three core technological bottlenecks: end-to-end collaborative latency, automated spatial matching, and real-time pre-hospital patient-medical visualization communication.

[0009] First, mobile APP online alarm solutions: only expand the digital alarm entry point, retain the original manual dispatch process, do not have the end-to-end direct communication capability between doctors and patients, and cannot automatically match the nearest on-duty emergency doctor.

[0010] Second, GPS-assisted vehicle dispatching solutions: These solutions only use GPS coordinates as manual reference information for dispatchers and do not build an automated spatial index matching algorithm, making it impossible to retrieve nearby medical and social emergency resources in batches at millisecond levels.

[0011] Third, the in-hospital remote consultation system relies on a dedicated consultation terminal in a fixed computer room. The session establishment process is cumbersome, it does not support pre-hospital connection establishment on mobile devices in seconds, and it cannot be adapted to outdoor mobile emergency rescue scenarios.

[0012] In summary, existing technologies lack an integrated solution and cannot simultaneously achieve millisecond-level spatial resource matching, second-level real-time audio and video communication between medical staff and patients, parallel and synchronous scheduling of multiple types of emergency resources, and high-precision automatic positioning in all scenarios, indicating a significant technological gap. Summary of the Invention

[0013] The purpose of this invention is to provide a rapid emergency response method based on real-time communication and geographic grid matching to address the shortcomings of existing technologies. This method solves problems such as grid boundary matching omissions and high-concurrency resource contention conflicts, ensures basic voice communication channels under extreme network conditions, and automatically reports patient coordinates throughout the process without requiring manual verbal addressing. It significantly reduces the time spent in doctor-patient communication and improves the success rate of pre-hospital treatment for acute and critical illnesses.

[0014] Another objective of this invention is to provide an emergency rapid response system based on real-time communication and geographic grid matching.

[0015] This invention achieves the above objectives using the following technical solution: a rapid emergency response method based on real-time communication and geographic grid matching, characterized by comprising the following steps:

[0016] S1. Receive an emergency SOS request sent by the mobile client and simultaneously start the terminal audio and video acquisition module; automatically collect multi-source positioning observation data of the terminal, and calculate multi-source location information by fusing GPS, Wi-Fi fingerprint, base station TDOA, and pedestrian trajectory through extended Kalman filtering, and output high-precision event coordinates; perform geographic grid encoding on the event coordinates to generate grid identifiers;

[0017] S2. A two-layer spatial index is used to automatically match on-duty emergency room doctors. The first layer queries the pre-stored grid-medical staff mapping set in the cache based on grid identifiers. Medical staff in the set are sorted in ascending order according to real-time patient load, and online candidates that have not reached the load limit are filtered. If there are no available medical staff in the current grid, the second layer constructs a circular buffer with a preset radius centered on the event coordinates, and retrieves cross-grid candidate medical staff through spherical geometric cells. If there are no matching medical staff in the entire area, a fallback allocation is performed across the entire area. A cached distributed lock is used to atomically occupy medical staff resources to avoid multiple requests concurrently preempting the same medical staff.

[0018] S3. After successful matching, the system interacts with SDP session description information and ICE connection candidate addresses via WebSocket signaling service to establish an end-to-end audio and video transmission channel for medical staff and patients based on the SFU media forwarding architecture. A DTLS encrypted session is pre-established and kept active between the on-duty medical staff terminal and the media service within the network. After matching, only SDP renegotiation is performed to reuse the media track. During transmission, congestion control, forward error correction, audio redundancy coding, and packet loss retransmission mechanisms are enabled to adapt to weak network environments. If the audio and video channel connection times out, the system automatically downgrades to SIP voice call. If the voice call fails to connect, the emergency event is automatically transferred to a human emergency call center.

[0019] S4. After the medical staff audio and video channel is established, the ambulance dispatch, the push of certified emergency volunteers, the retrieval of public AED devices, and the notification of family doctors are encapsulated into independent asynchronous messages and distributed to the independent sub-queues corresponding to the message queue. Multiple consumption services process each sub-task in parallel and independently, and the execution of each task does not block each other.

[0020] S5 aggregates the execution results of all dispatch tasks, the emergency resource response status, and the estimated arrival time of resources, and pushes them to the patient terminal and medical staff terminal in real time via a long connection; the medical staff terminal provides video marking, voice emergency guidance, rapid emergency scoring, and multi-specialty remote consultation interaction functions.

[0021] As a further explanation of the above scheme, in step S2, the dual-layer spatial index includes the Geohash index and the GoogleS2 spherical geometry index; the Geohash index is used for O(1) fast query of the belonging grid, with an accuracy level of Level 6; the GoogleS2 index is used for cross-grid extended retrieval, with the cell level adaptively selected as Level 12-14, the buffer radius set to 2km, and the area coverage over-control rate less than 20%.

[0022] Furthermore, in step S2, the distributed lock is implemented based on cached atomic instructions and Lua scripts. The basic lock expiration time is 30 seconds, and the watchdog thread automatically renews the lock time every 10 seconds. The medical staff terminal reports heartbeat data packets to the cache every 5 seconds. If no heartbeat is reported for 3 consecutive heartbeat cycles, the medical staff is automatically marked as offline and removed from the candidate medical staff set.

[0023] Furthermore, in step S3, the weak network adaptation optimization strategy for audio and video transmission includes: the sending end uses Simulcast to concurrently push multi-resolution video streams; dynamically adjusts the media transmission bitrate based on the GCC congestion control algorithm; enables FEC forward error correction and NACK packet loss retransmission mechanism for video transmission; audio uses OPUS encoding superimposed with RFC2198 standard RED audio redundancy encoding to ensure continuous audio and video playback when the packet loss rate is less than 10%; the first frame display time in cold start connection establishment scenario does not exceed 3 seconds, and the first frame display time in pre-connection session reuse scenario does not exceed 1.5 seconds.

[0024] Furthermore, in the process of automatically collecting multi-source positioning observation data of the terminal in step S1, Wi-Fi fingerprint positioning adopts the weighted K-nearest neighbor (WKNN) algorithm, which calculates the indoor location based on the Euclidean distance of the RSSI signal vector; base station positioning adopts TDOA hyperbolic positioning as a fallback positioning source; extended Kalman filtering includes a dual process of uniform motion prediction and observation update, which dynamically corrects the observation noise weights corresponding to various positioning sources.

[0025] Furthermore, in the multi-specialty remote consultation process in step S5, the specific steps include: the receiving medical staff terminal initiates a consultation invitation, and the signaling service forwards the invitation to the SFU media service; the SFU media service copies and distributes the existing medical and patient media streams to the invited specialist medical staff terminal; the SFU automatically distributes the appropriate resolution bitstream based on the real-time network bandwidth of each participating terminal, supports multi-party two-way video interaction, and the entire consultation process is recorded and stored with encrypted audio and video.

[0026] An emergency rapid response system based on real-time communication and geographic grid matching is characterized by comprising a layered terminal access layer, a core service layer, and a data and monitoring layer.

[0027] The terminal access layer includes a public-facing APP, a doctor-facing APP, an ambulance-mounted terminal, and a volunteer-facing APP; the core service layer includes a grid-based matching server, a parallel scheduling engine, and a WebRTC media communication service.

[0028] The public app, ambulance vehicle terminal, and volunteer app establish bidirectional network connections with the core service layer via 4G / 5G networks; the doctor app establishes bidirectional long connections with the grid matching server and WebRTC media communication service.

[0029] The gridded matching server has a built-in geographic grid index module, a spherical geometry extended retrieval module, a medical staff status cache management module, and a distributed lock concurrency control module. The gridded matching server receives SOS emergency requests and fused location coordinates uploaded by the public terminal APP of the terminal access layer, performs two-layer geographic grid matching calculations, and synchronously pushes the medical staff matching results to the parallel scheduling engine and WebRTC media communication service. The gridded matching server has a bidirectional read / write data and a hybrid data storage layer for the supervision layer.

[0030] The parallel scheduling engine is equipped with a message queue middleware, and connects in parallel with ambulance dispatch consumers, volunteer geographic search consumers, AED device query consumers, and family doctor notification consumers. The parallel scheduling engine receives matching success event messages from the gridded matching server, splits them into four independent asynchronous tasks, and distributes them to the corresponding consumers. The volunteer search module uses the geographic search engine to screen certified paramedics within a specified radius and sends volunteer push instructions to the volunteer's app. The ambulance dispatch module uses three-dimensional factors—distance, real-time traffic conditions, and emergency equipment matching degree—to construct a multi-objective cost function to solve for the optimal dispatch vehicle and sends dispatch instructions to the ambulance's onboard terminal. After all consumers have completed their processing, they send the resource response status and ETA data back to the parallel scheduling engine. The parallel scheduling engine then summarizes the status and pushes it to the public app and doctor's app via WebSocket.

[0031] The WebRTC media communication service includes a WebSocket signaling server, an SFU selective forwarding media server, a pre-connected session pool, a SIP voice degradation gateway, and an audio / video recording encrypted storage unit. The WebSocket signaling server establishes long WebSocket connections with both the public-side app and the doctor-side app, exchanging SDP and ICE signaling data. The SFU selective forwarding media server receives audio / video media streams uploaded by the public-side app and copies and forwards them to the doctor-side app. The SIP voice degradation gateway interconnects with the operator's voice network and initiates a voice call to the public-side app when WebRTC connection fails. The audio / video recording encrypted storage unit encrypts the media streams and writes them into the data and regulatory layer's object storage.

[0032] The data and monitoring layer includes a hybrid data storage layer and a global event monitoring platform. The hybrid storage layer contains a relational database, a memory cache, a time-series database, and object storage. The hybrid data storage layer is bidirectionally connected to the grid-based matching server, the parallel scheduling engine, and the WebRTC media communication service, storing real-time status, emergency events, location trajectories, and encrypted audio and video recordings. The global event monitoring platform subscribes in real-time to the full-process event logs pushed by the grid-based matching server, the parallel scheduling engine, and the WebRTC media communication service, triggering resource shortage alarms and providing historical data backtracking and operation auditing interfaces.

[0033] The beneficial effects that can be achieved by adopting the above-mentioned technical solution in this invention are:

[0034] 1. This invention adopts a pioneering dual-layer geographic grid index and distributed lock to solve concurrent matching conflicts, integrates WebRTC pre-connection and multi-layer weak network anti-packet loss to achieve second-level visual communication, message queue parallel scheduling to connect social emergency resources, and multi-source EKF fusion positioning to cover the whole scenario; the whole solution supports horizontal expansion and tiered circuit breaking and degradation, and the system's concurrent carrying capacity and operational stability are greatly improved.

[0035] 2. This invention significantly reduces the golden response time for emergency care. Pre-hospital doctors can intuitively grasp the on-site trauma, consciousness, and respiratory status, and simultaneously guide witnesses to perform basic first aid operations such as cardiopulmonary resuscitation and hemostasis; simultaneously dispatch AEDs and volunteers to the scene, greatly improving the survival rate of patients with cardiac arrest, stroke, and severe trauma, and improving long-term prognosis.

[0036] 3. This invention breaks down the barriers between the 120 emergency medical service system and social emergency medical resources, activates the idle emergency medical capabilities of existing urban volunteers and AED devices; reduces the manual labor intensity of the 120 dispatch center, and promotes the transformation of emergency dispatch from labor-intensive to digital and intelligent; supports tiered deployment in counties, districts and large cities, has low implementation threshold, and is compatible with the current status of emergency medical systems at all levels in China. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of the overall architecture of the present invention.

[0038] Figure 2 This is a flowchart of the gridded matching process of the present invention.

[0039] Figure 3 This is a timing diagram of the WebRTC signaling interaction of the present invention.

[0040] Figure 4 This is a timing diagram for the parallel scheduling of the present invention.

[0041] Figure 5 This is a system deployment architecture diagram of the present invention.

[0042] Figure labeling: 101, Public App; 102, Doctor App; 108, Ambulance Terminal; 109, Volunteer App; 103, Grid-based Matching Server; 104, Parallel Scheduling Engine; 105, Media Communication Service; 106, Monitoring Platform; 107, Data Storage Layer. Detailed Implementation

[0043] In the description of this invention, it should be noted that the directional terms such as "center", "lateral", "longitudinal", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", and "counterclockwise" indicate the orientation and positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. They should not be construed as limiting the specific protection scope of this invention.

[0044] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features. Thus, the use of "first" and "second" to define a feature may explicitly or implicitly include one or more of that feature, and in the description of this invention, "at least" means one or more, unless otherwise explicitly specified.

[0045] In this invention, unless otherwise explicitly specified and limited, the terms "assembly," "connection," and "joining" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can also refer to a mechanical connection; they can refer to a direct connection or a connection through an intermediate medium; or they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0046] In this invention, unless otherwise specified and limited, "above" or "below" the second feature can include direct contact between the first and second features, or contact between the first and second features through another feature between them. Furthermore, "above," "below," and "over" the second feature includes the first feature being directly above or diagonally above the second feature, or simply indicates that the first feature is at a higher horizontal level than the second feature. "Above," "below," and "below" the second feature includes the first feature being directly below or diagonally below the second feature, or simply indicates that the first feature is at a lower horizontal level than the second feature.

[0047] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings, making the technical solution and beneficial effects of the present invention clearer and more explicit. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, but should not be construed as limiting the present invention.

[0048] like Figures 1-5 As shown, this invention is a rapid emergency response method and system based on real-time communication and geographic grid matching, aiming to achieve four core invention objectives:

[0049] 1. Build a Geohash+S2 dual-layer geographic grid index, and rely on memory caching and distributed locks to achieve fully automatic millisecond-level matching of emergency doctors, solving grid boundary matching omissions and high-concurrency resource contention conflicts;

[0050] 2. Construct a WebRTC+SFU low-latency real-time audio and video communication link. Through pre-connection session pool, ICE pre-collection, multi-layer weak network anti-packet loss, and SIP voice degradation mechanism, realize the visual connection between doctors and patients within 3 seconds and ensure the basic voice communication channel under extreme network conditions.

[0051] 3. The system employs message queues to asynchronously and parallelly schedule four types of resources: ambulances, volunteers, AEDs, and family doctors. Tasks are decoupled and executed synchronously, activating the entire social emergency rescue force simultaneously.

[0052] 4. By integrating multi-source positioning and weighted fusion through extended Kalman filtering, positioning blind spots in areas with weak GPS signals such as indoors, tunnels, and canyons are eliminated. The patient's coordinates are automatically reported throughout the process, eliminating the need for manual verbal addressing. Ultimately, the average doctor-patient communication time of the traditional model is reduced from 4.5 minutes to less than 30 seconds, significantly improving the success rate of pre-hospital treatment for acute and critical illnesses.

[0053] The system adopts a three-layer architecture, consisting of a terminal access layer, a core service layer, and a data and monitoring layer.

[0054] 1. Terminal Access Layer: Lightweight terminals for users in all scenarios, including four types of APP / vehicle hardware terminals.

[0055] (1) Public App 101: Used for users to trigger SOS distress calls, collect multi-source positioning, collect and push audio and video streams, and receive doctors' text / voice emergency guidance;

[0056] (2) Doctor App 102: Used to receive matching push notifications, retrieve real-time patient videos, perform standardized injury scoring, initiate multi-specialty consultations, and view the real-time status of nearby volunteers / AEDs / ambulances;

[0057] (3) Ambulance on-board terminal 108: used to report vehicle GPS coordinates in real time, receive dispatch instructions, and view patient on-site video and estimated arrival time (ETA);

[0058] (4) Volunteer App 109: Lightweight without video module, used to receive emergency push notifications, generate walking navigation to the accident scene, and report its own response status.

[0059] 2. Core Service Layer (Core Innovative Modules of the System);

[0060] (1) Grid matching server 103: realizes two-layer geographic index calculation, online status management of medical staff, and Redis distributed lock concurrency control;

[0061] (2) Parallel scheduling engine 104: Based on RabbitMQ message queue, asynchronous tasks are distributed and executed in parallel, including vehicle scheduling, volunteer retrieval, AED query, and family doctor notification;

[0062] (3) WebRTC Media Communication Service 105: Implements WebSocket signaling interaction, SFU media stream forwarding, pre-connection session keep-alive, SIP voice downgrade, and audio and video encrypted recording and storage.

[0063] 3. Data and regulators;

[0064] (1) Hybrid data storage layer 107: Relational database stores emergency event files, memory cache stores real-time medical / vehicle status, time-series database stores continuous location trajectories, and object storage encrypts and saves emergency audio and video recordings;

[0065] (2) Supervision Platform 106: Used for real-time monitoring of global emergency events, automatic alarm for resource shortages, retention of full operation audit logs, and statistical backtracking of historical emergency data.

[0066] Geohash+S2 dual-layer geographic grid matching and concurrency control mechanism:

[0067] 1. Grid coding and index storage rules.

[0068] The city's planar grid is divided using GeohashLevel6 precision, with a single grid size of 1.2km × 0.6km, matching a conventional emergency service radius of 3-5km. The grid code is stored in RedisHash structure to bind and map the relationship between the grid code and the hospital and the on-duty doctor, achieving O(1) ultra-fast query.

[0069] To address the issue of missing matching points at grid boundaries, a parallel Google S2 spherical geometry index was introduced: a 2km circular buffer was constructed with the patient's coordinates as the center, and the circular covering cells were split through the S2Covering interface. The cell level was adaptively selected from Level 12 to 14, and all online medical staff within the coverage area were retrieved in batches, achieving smooth cross-grid expansion matching and controlling the regional over-coverage rate to within 20%.

[0070] 2. Real-time maintenance of medical staff's online status.

[0071] Every 5 seconds, all doctor-side apps report heartbeat data packets. The data packets include the doctor ID, grid to which the doctor belongs, current patient load, location coordinates, and online status. The list of medical staff in each grid is maintained by a Redis sorted set ZSet, with the set score representing the real-time concurrent patient load, and is automatically sorted in ascending order by load.

[0072] Offline determination rule: If no heartbeat is reported for 3 consecutive heartbeat cycles (15 seconds), the medical staff will be automatically removed from the ordered set and marked as offline.

[0073] 3. Three-level progressive matching logic.

[0074] Level 1 (intra-grid matching): Query the ordered set of Geohash grids corresponding to the patient's coordinates, filter online and underloaded medical staff, select the candidate with the lowest load, and the median matching calculation time is <15ms, and the P95 quantile is <50ms;

[0075] Level 2 (Neighborhood Expansion Matching): When there are no available medical staff within the grid, the 8-neighbor Geohash grid is searched first. If there are still no resources, the search is expanded to the 24-neighborhood (3-5km range). The surrounding medical staff are searched in batches based on the S2 index.

[0076] Level 3 (Regional Safety Net Allocation): When there are no matching medical staff within the neighborhood, the lowest-load personnel are allocated from all online medical staff pools in the entire region, and an "Emergency Resources Shortage" alert is sent to the monitoring platform at the same time.

[0077] 4. Redis distributed lock concurrency anti-conflict mechanism.

[0078] In high-concurrency, multi-request scenarios, the same medical staff may be selected by multiple requests simultaneously. Redis atomic locks are used to achieve resource mutual exclusion. The basic locking command is: SET lock:doctor:{ID}{eventID}NXPX30000, with a basic lock expiration time of 30 seconds. A watchdog thread automatically renews the lock duration every 10 seconds. The lock is released immediately after successful acquisition of the medical staff resource and the load value is incremented by 1. Lock release uses a Lua script to verify the lock ownership identifier, preventing accidental deletion of lock resources held by other requests. Locks are automatically released upon timeout to prevent deadlock issues.

[0079] WebRTC+SFU low-latency real-time audio and video communication and disaster recovery and degradation solution.

[0080] 1. Media transmission architecture selection.

[0081] Instead of a pure P2P direct connection solution (which has a high failure rate for NAT traversal on mobile networks), an SFU selective forwarding architecture is adopted: the uplink media stream from the patient's end is pushed to the SFU server, which then distributes it to the doctor's end, naturally supporting subsequent multi-party consultations; the signaling channel relies on a WebSocket long connection.

[0082] 2. Complete signaling interaction process.

[0083] (1) After SOS matching is completed, the patient end creates a PeerConnection, synchronously collects ICE candidate addresses in advance, and generates an SDPOffer carrying H.264 video and OPUS audio encoding parameters;

[0084] (2) The WebSocket signaling server forwards the SDPOffer to the target doctor's terminal;

[0085] (3) The doctor generates an SDPANwer and sends it back to the patient. Both parties complete the ICE connectivity test. The STUN server obtains the public network address, and the TURN server acts as a relay to ensure weak network connectivity.

[0086] (4) The media stream is pushed to SFU for forwarding, and the doctor-patient visual connection is completed.

[0087] 3. Four latency optimization methods.

[0088] (1) Pre-connected session pool: The on-duty doctor terminal in the grid establishes a DTLS encrypted session with SFU in advance and keeps it alive for a long time; after a successful match, only SDP incremental renegotiation is performed to add a new media track, skipping the complete ICE and DTLS handshake process, and the first frame display time is compressed to less than 1.5s;

[0089] (2) ICE candidate pre-collection: The terminal background collects ICE candidates in parallel at the moment of SOS triggering, without waiting for SDP negotiation to be completed, reducing the time spent on one network round trip;

[0090] (3) Layered fast streaming: In the early stage of connection establishment, push 320p / 200kbps low resolution video for fast image output, and dynamically switch to 720p high-definition bitrate after the bandwidth stabilizes;

[0091] (4) Simulcast multi-stream concurrency: The sending end synchronously pushes high, medium and low resolution videos, and SFU automatically distributes the appropriate bitstream according to the network status of the receiving end.

[0092] 4. Full-link weak network countermeasure strategy.

[0093] (1) Bandwidth control: The GCC Google congestion control algorithm is adopted to dynamically adjust the sending rate in real time based on the network delay gradient and packet loss rate;

[0094] (2) Video packet loss resistance: Enable NACK packet loss retransmission + FEC forward error correction redundancy packets;

[0095] (3) Audio packet loss resistance: RFC2198RED audio redundancy coding is adopted, and OPUS built-in FEC is superimposed. There is no obvious audio dropout when the packet loss rate is ≤10%.

[0096] (4) VAD silence detection: DTX discontinuous transmission is enabled during audio silence periods to reduce terminal traffic consumption.

[0097] 5. Disaster recovery and downgrade fallback mechanism.

[0098] If a 10-second connection timeout threshold is set, and the WebRTC audio / video channel fails to be established, the system will automatically switch to the SIP trunk gateway to dial the patient's mobile phone number, and the doctor's end will simultaneously switch to voice call mode; if the voice call still cannot be connected, the emergency event will be automatically transferred to the traditional 120 human operator to ensure that the emergency call channel remains open in extreme scenarios.

[0099] RabbitMQ is a parallel multi-resource scheduling engine for message queues.

[0100] 1. Asynchronous task decoupling parallel architecture.

[0101] After the audio and video communication channel between doctors and patients is established, the parallel scheduling engine publishes four types of independent tasks to the RabbitMQ message queue at once.

[0102] The configuration rules for each queue are as follows:

[0103]

[0104] Each task is executed independently and in parallel. The failure of any task does not affect the execution of other tasks, thus achieving decoupling and parallelization of "direct communication between doctors and patients" and "schedule of surrounding resources," rather than the serial waiting of the traditional model. The processing results of each consumer service (volunteer response status, AED retrieval instructions, ambulance ETA, family doctor notification receipt) are aggregated by the status tracking module and then pushed in real time to the doctor's app and the patient's app for unified presentation via the WebSocket channel.

[0105] 2. Volunteer matching logic.

[0106] The volunteer terminal adaptively adjusts the location reporting frequency: it reports GPS every 5 seconds when in motion and every 60 seconds when stationary, balancing positioning accuracy and terminal power consumption; a volunteer geo_point geographic index is built using Elasticsearch, with a fixed search radius of 500 meters, and a matching score is generated based on distance, first aid certificate level, and historical response rate, pushing notifications to the top 3 volunteers with the highest scores; the push notification uses a dual-channel approach of MQTT + vendor push (APNs / FCM / Android vendor push), and notifications can be received even when the APP is in the background or the process is killed.

[0107] 3. AED device matching logic.

[0108] It pre-stores the static coordinates, opening hours, and detailed location descriptions of all public AEDs; the search radius is fixed at 200 meters, and it automatically generates walking navigation routes, which are simultaneously pushed to the terminals of responding volunteers and ambulances.

[0109] 4. Ambulance multi-objective optimization scheduling algorithm.

[0110] The formula for calculating the overall cost is: Overall Cost = 0.5 × Distance Coefficient + 0.3 × Real-time Traffic Delay Coefficient + 0.2 × Equipment Matching Coefficient; the driving ETA is obtained through the map real-time traffic API; the symptom keywords in the patient's SOS message are extracted using NLP natural language processing, and the ambulance's onboard emergency equipment (ventilator, defibrillator, etc.) is matched, with priority given to vehicles with the highest equipment compatibility.

[0111] EKF Extended Kalman Filter Multi-Source Fusion High-Precision Positioning: Addressing the signal attenuation and positioning drift issues inherent in GPS in indoor, underground tunnel, and high-rise / canyon scenarios, this invention fuses four types of positioning data sources and uses extended Kalman filtering for weighted fusion, achieving an overall positioning success rate of ≥99% and indoor positioning accuracy of ≤20 meters. Specifically:

[0112] 1. GPS positioning: The primary outdoor positioning source, with weights dynamically adjusted based on the number of satellites and the signal-to-noise ratio, achieving an outdoor accuracy of 5-10 meters;

[0113] 2. Wi-Fi fingerprint WKNN positioning: The area's AP fingerprint database is pre-collected, the terminal scans the surrounding Wi-Fi RSSI signals, and the weighted K-nearest neighbor algorithm is used to calculate the indoor coordinates, with an indoor accuracy of 15-30 meters;

[0114] 3. TDOA base station positioning: The location is solved by constructing a hyperbola based on the time difference of arrival of base station signals, with an accuracy of 100-500 meters, and is used as the lowest priority fallback positioning source;

[0115] 4. PDR pedestrian trajectory estimation: Relying on the terminal accelerometer and gyroscope to collect motion data, the position change is recursively estimated within 30 seconds after GPS loss to compensate for short-term positioning interruption.

[0116] Extended Kalman filtering consists of two steps: prediction and update. It dynamically corrects the noise covariance of various positioning sources and outputs smooth, non-jumping fused coordinates, which are then used by the grid matching and navigation scheduling modules.

[0117] Audio-visual remote assessment and early specialist intervention include pre-hospital remote injury assessment and multi-specialist consultation.

[0118] 1. Visual assessment function for single emergency physicians.

[0119] The doctor's end can pull the patient's live video in real time and provides three types of interactive tools: ① Video screenshot marking, where the doctor can circle the hemostasis and chest compression points on the screen and send the marked image back to the patient; ② Short voice emergency commands within 5 seconds can be issued and played; ③ One-click entry of GCS coma score and AVPU consciousness assessment, and the score data is automatically archived in the emergency event file.

[0120] 2. Multi-specialty remote consultation process.

[0121] When an emergency physician determines that a patient has a serious condition such as myocardial infarction, stroke, or severe trauma, they can click "Invite Consultation" to initiate a request. The system then selects online specialists with low workload based on the type of illness. The invited physician accesses the SFU media stream to enable multi-party, two-way video consultation. SFU relies on Simulcast multi-stream adaptation to different participating terminal networks, and the entire consultation process is encrypted, recorded, and stored for post-conference case review.

[0122] End-to-end data security and privacy protection:

[0123] 1. Media transmission encryption: WebRTC enforces DTLS-SRTP encryption, ensuring that the media stream is transmitted in encrypted form throughout, preventing the server from parsing plaintext audio and video;

[0124] 2. Encrypted Storage: Patient identity information, emergency audio and video recordings, and location trajectories are stored using AES-256 encryption. Identity data is stored separately from emergency medical records in a segregated and anonymized manner.

[0125] 3. Full operation audit: Doctors' access to videos, export of emergency records, and data queries on the monitoring platform all generate tamper-proof audit logs, meeting the requirements of medical data compliance regulations.

[0126] System high availability, circuit breaker degradation and expansion mechanisms:

[0127] 1. Horizontal elastic scaling: Matching server, signaling server, and SFU media service are all stateless services, supporting multi-instance cluster deployment and traffic distribution through Nginx load balancing; SFU adopts a central cloud + regional edge node deployment, and terminals access the nearest node to reduce transmission latency.

[0128] 2. Tiered circuit breaker and degradation strategy:

[0129] (1) Matching service circuit breaker: If the failure rate of the request exceeds 10% within 1 minute, the circuit breaker will be automatically broken and the distress request will be switched to the traditional 120 dispatch channel;

[0130] (2) Signaling service degradation: When the number of WebSocket connections reaches the peak threshold, new requests skip the WebRTC connection establishment process and directly trigger SIP voice callback;

[0131] (3) Degrading the scheduling engine: If the message queue has more than 1,000 backlogged tasks, suspend low-priority family doctor notification tasks and prioritize the dispatch of ambulances and volunteers.

[0132] 3. Multi-deployment mode adaptation: Supports four types of solutions: county-level single-machine centralized deployment, large-scale city distributed grid deployment, public cloud multi-tenancy, and local private deployment, adapting to the deployment needs of emergency centers of different sizes.

[0133] Example 1

[0134] This embodiment is a centralized deployment model at the county / district level for a population of 500,000.

[0135] The district has a total population of 450,000. The entire district is uniformly divided into a single Geohash grid, which is linked to the emergency department of the district's People's Hospital and is staffed with four emergency doctors on duty in shifts. The matching, signaling, and SFU media servers are centrally deployed in the district's emergency center computer room, and no edge media nodes are set up.

[0136] After a user triggers an SOS distress call, the system directly matches the doctor with the lowest workload in the hospital, skipping the neighborhood expansion search logic; the volunteer search radius is 500 meters, the AED search radius is 200 meters, and the ambulance is dispatched uniformly by the district emergency center; the overall deployment cost is low, the operation and maintenance are simple, and the matching latency is stable at less than 20ms, making it suitable for emergency dispatch in county-level cities.

[0137] Example 2

[0138] This example demonstrates a distributed grid-based deployment in a large city with a population of 5 million.

[0139] The urban area has a population of 5.2 million and is divided into 80 independent Geohash grids according to street administrative areas. Each grid is bound to the emergency department of a tertiary hospital. The matching and signaling service clusters are deployed in the city government cloud center and load balancing is achieved through Nginx. The SFU media servers are deployed in the computer rooms of hospitals in each jurisdiction as edge nodes, and the terminals access the nearest one to reduce media transmission latency.

[0140] SOS events are prioritized for matching local grid doctors, and neighboring grids are automatically searched when no resources are available; during the evening peak hours from 18:00 to 22:00 every day, service instances are automatically expanded and matched to improve concurrent carrying capacity and adapt to large-scale urban high-frequency emergency rescue scenarios.

[0141] Example 3

[0142] This embodiment demonstrates two deployment environments: public cloud multi-tenancy and local private deployment.

[0143] 1. Public cloud multi-tenant deployment: The system is deployed on a third-party public cloud platform, with emergency medical centers in each district and county accessing as independent tenants. Data is logically isolated between tenants, eliminating the need for self-built data centers. The deployment cycle is short, making it suitable for small and medium-sized prefecture-level cities.

[0144] 2. Local private deployment: The entire system is deployed in the Health Commission's own government data center. All emergency data does not leave the local intranet, meeting the compliance requirements for medical data security protection. It is suitable for provincial capital and provincial unified emergency platforms.

[0145] Terminal hardware adaptation instructions: The public and volunteer apps are compatible with Android 8.0 and above, and iOS 12.0 and above mobile systems; the doctor app also provides a Windows desktop client, which supports real-time viewing of patient videos on hospital large screens; the volunteer app removes the video capture and streaming modules to reduce mobile power consumption and data usage.

[0146] System performance test example:

[0147] Test hardware environment: 8-core 16GB matching server, 4-core 8GSFU media server, Redis 7.0 memory cache; the test network was divided into two groups: a good 4G network (RTT < 50ms, packet loss rate < 1%) and a weak 4G network (RTT ≈ 200ms, packet loss rate 8%). Each group underwent 100 simulated SOS distress stress tests. The key performance indicators are as follows:

[0148] 1. Matching calculation time: 12ms for excellent networks, 15ms for weak networks, and the P95 quantile is less than 42ms, which meets the design threshold of ≤50ms.

[0149] 2. Pre-connection establishment first frame duration: 1.1s for excellent networks and 1.2s for weak networks, both below the design target of 1.5s;

[0150] 3. Cold start connection establishment first frame duration: 2.2s for excellent networks, 2.5s for weak networks, P95 maximum value 2.8s / 3.0s, which meets the ≤3s indicator;

[0151] 4. Parallel scheduling full task completion P95 time: 8.6s for excellent networks, 9.4s for weak networks, below the 10s threshold;

[0152] 5. Multi-source fusion positioning success rate: 99.5% for excellent networks, 99.2% for weak networks, and stable indoor positioning accuracy ≤20 meters.

[0153] The above description is only a preferred embodiment of the present invention. It should be noted that those skilled in the art can make several modifications and improvements without departing from the inventive concept of the present invention, and these all fall within the protection scope of the present invention.

Claims

1. A rapid emergency response method based on real-time communication and geographic grid matching, characterized in that, It includes the following steps: S1. Receive an emergency SOS request sent by the mobile client and simultaneously start the terminal audio and video acquisition module; automatically collect multi-source positioning observation data of the terminal, and calculate multi-source location information by fusing GPS, Wi-Fi fingerprint, base station TDOA, and pedestrian trajectory through extended Kalman filtering, and output high-precision event coordinates; perform geographic grid encoding on the event coordinates to generate grid identifiers; S2. A two-layer spatial index is used to automatically match on-duty emergency doctors. The first layer queries the pre-stored grid-medical staff mapping set in the cache based on the grid identifier. The medical staff in the set are sorted in ascending order according to the real-time patient reception load, and online candidate medical staff that have not reached the load limit are filtered. If there are no available medical staff in the current grid, the second layer constructs a circular buffer with a preset radius centered on the event coordinates, and retrieves candidate medical staff across grids through spherical geometric cells; if there are no matching medical staff in the entire area, a fallback allocation is performed across the entire area; a cached distributed lock is used to atomically occupy medical staff resources to avoid multiple requests concurrently preempting the same medical staff; S3. After successful matching, the system interacts with SDP session description information and ICE connection candidate addresses via WebSocket signaling service to establish an end-to-end audio and video transmission channel for medical staff and patients based on the SFU media forwarding architecture. A DTLS encrypted session is pre-established and kept active between the on-duty medical staff terminal and the media service within the network. After matching, only SDP renegotiation is performed to reuse the media track. During transmission, congestion control, forward error correction, audio redundancy coding, and packet loss retransmission mechanisms are enabled to adapt to weak network environments. If the audio and video channel connection times out, the system automatically downgrades to SIP voice call. If the voice call fails to connect, the emergency event is automatically transferred to a human emergency call center. S4. After the medical staff audio and video channel is established, the ambulance dispatch, the push of certified emergency volunteers, the retrieval of public AED devices, and the notification of family doctors are encapsulated into independent asynchronous messages and distributed to the independent sub-queues corresponding to the message queue. Multiple consumption services process each sub-task in parallel and independently, and the execution of each task does not block each other. S5 aggregates the execution results of all dispatch tasks, the emergency resource response status, and the estimated arrival time of resources, and pushes them to the patient terminal and medical staff terminal in real time via a long connection; the medical staff terminal provides video marking, voice emergency guidance, rapid emergency scoring, and multi-specialty remote consultation interaction functions.

2. The emergency rapid response method based on real-time communication and geographic grid matching according to claim 1, characterized in that, In step S2, the dual-layer spatial index includes the Geohash index and the GoogleS2 spherical geometry index; the Geohash index is used for O(1) fast lookup of the assigned grid with a precision level of Level 6; the GoogleS2 index is used for cross-grid extended retrieval, with the cell level adaptively selected as Level 12-14, the buffer radius set to 2km, and the area coverage over-control rate less than 20%.

3. The emergency rapid response method based on real-time communication and geographic grid matching according to claim 1, characterized in that, In step S2, the distributed lock is implemented based on cached atomic instructions and Lua scripts. The basic lock expiration time is 30 seconds, and the watchdog thread automatically renews the lock time every 10 seconds. The medical staff terminal reports heartbeat data packets to the cache every 5 seconds. If no heartbeat is reported for 3 consecutive heartbeat cycles, the medical staff is automatically marked as offline and removed from the candidate medical staff set.

4. The emergency rapid response method based on real-time communication and geographic grid matching according to claim 1, characterized in that, In step S3, the weak network adaptation optimization strategy for audio and video transmission includes: the sending end uses Simulcast to concurrently push multi-resolution video streams; dynamically adjusts the media transmission bitrate based on the GCC congestion control algorithm; enables FEC forward error correction and NACK packet loss retransmission mechanism for video transmission; audio uses OPUS encoding superimposed with RFC2198 standard RED audio redundancy encoding to ensure continuous audio and video playback when the packet loss rate is less than 10%; the first frame display time in cold start connection establishment scenario does not exceed 3 seconds, and the first frame display time in pre-connection session reuse scenario does not exceed 1.5 seconds.

5. The emergency rapid response method based on real-time communication and geographic grid matching according to claim 1, characterized in that, In the process of automatically collecting multi-source positioning observation data of the terminal in step S1, Wi-Fi fingerprint positioning adopts the weighted K-nearest neighbor (WKNN) algorithm, which calculates the indoor location based on the Euclidean distance of the RSSI signal vector; base station positioning adopts TDOA hyperbolic positioning as a fallback positioning source; extended Kalman filtering includes a dual process of uniform motion prediction and observation update, and dynamically corrects the observation noise weights corresponding to various positioning sources.

6. The emergency rapid response method based on real-time communication and geographic grid matching according to claim 1, characterized in that, In the multi-specialty remote consultation process in step S5, the specific steps include: the receiving medical staff terminal initiates a consultation invitation, and the signaling service forwards the invitation to the SFU media service; the SFU media service copies and distributes the existing medical and patient media streams to the invited specialist medical staff terminal; the SFU automatically distributes the appropriate resolution bitstream according to the real-time network bandwidth of each participating terminal, supports multi-party two-way video interaction, and the audio and video of the entire consultation process is encrypted, recorded and stored.

7. A system adapted to the emergency rapid response method based on real-time communication and geographic grid matching as described in any one of claims 1-6, characterized in that, This includes a layered deployment of the terminal access layer, core service layer, and data and supervision layer; The terminal access layer includes a public-facing APP, a doctor-facing APP, an ambulance-mounted terminal, and a volunteer-facing APP; the core service layer includes a grid-based matching server, a parallel scheduling engine, and a WebRTC media communication service. The public app, ambulance vehicle terminal, and volunteer app establish bidirectional network connections with the core service layer via 4G / 5G networks; the doctor app establishes bidirectional long connections with the grid matching server and WebRTC media communication service. The gridded matching server has a built-in geographic grid index module, a spherical geometry extended retrieval module, a medical and nursing status cache management module, and a distributed lock concurrency control module. The gridded matching server receives SOS emergency requests and fused positioning coordinates uploaded by the public terminal APP of the terminal access layer, performs two-layer geographic grid matching calculations, and pushes the medical and nursing matching results to the parallel scheduling engine and WebRTC media communication service simultaneously. A hybrid data storage layer for grid-based matching servers to read and write data bidirectionally and for the regulatory layer; The parallel scheduling engine is equipped with a message queue middleware, and connects in parallel with ambulance dispatch consumers, volunteer geographic search consumers, AED device query consumers, and family doctor notification consumers. The parallel scheduling engine receives matching success event messages from the gridded matching server, splits them into four types of independent asynchronous tasks, and distributes them to the corresponding consumers. The volunteer search module uses the geographic search engine to screen certified paramedics within a specified radius and sends volunteer push instructions to the volunteer's mobile app. The ambulance dispatch module uses three-dimensional factors—distance, real-time traffic conditions, and emergency equipment matching degree—to construct a multi-objective cost function to solve for the optimal dispatch vehicle and sends dispatch instructions to the ambulance's onboard terminal. After all consumers have finished processing, they send the resource response status and ETA data back to the parallel scheduling engine. The parallel scheduling engine then summarizes the status and pushes it to the public APP and the doctor's APP via WebSocket. The WebRTC media communication service includes a WebSocket signaling server, an SFU selective forwarding media server, a pre-connected session pool, a SIP voice degradation gateway, and an audio and video recording encrypted storage unit; The WebSocket signaling server establishes long WebSocket connections with the public client APP and the doctor client APP respectively, and exchanges SDP and ICE signaling data. The SFU selective forwarding media server receives audio and video media streams uploaded by the public client APP and copies and forwards them to the doctor's client APP; The SIP voice degradation gateway interconnects with the operator's voice network and initiates a voice call to the public-end APP when WebRTC connection fails; the audio and video recording encryption storage unit encrypts the media stream and writes it into the data and the object storage of the regulatory layer. The data and monitoring layer includes a hybrid data storage layer and a global event monitoring platform; the hybrid storage layer includes a relational database, a memory cache, a time-series database, and an object storage; the hybrid data storage layer is bidirectionally connected to a grid-based matching server, a parallel scheduling engine, and a WebRTC media communication service, storing real-time status, emergency events, location trajectories, and encrypted audio and video recordings; The global event monitoring platform subscribes in real time to the full-process event logs pushed by the grid matching server, parallel scheduling engine, and WebRTC media communication service, triggers resource shortage alarms, and provides interfaces for historical data backtracking and operation auditing.

Images