Home care service cloud side collaborative management method and system

Abstract

The invention discloses a home nursing service cloud side collaborative management method and system, and the method comprises the steps: carrying out the integrity verification of nursing request data, recognizing a transmission abnormal section, and carrying out the priority packaging according to the emergency degree of data related to the abnormal section; performing weighted evaluation by integrating the geographic coordinates of the nursing personnel and the real-time load state to screen an optimal service node, and establishing a downlink push channel to transmit task information; the edge side caches task data to form a local mirror image, and supports off-line service execution and nursing record retention in a weak network environment; identifying synchronous interruption through link detection and activating a breakpoint resume strategy, and performing conflict pre-detection on unsynchronized data to screen out a safe section to construct recovery configuration; and determining a confirmation node based on the time delay distribution of the synchronization progress, and executing bidirectional response verification to complete cloud edge data synchronization. The method adapts to the network fluctuation characteristics of the home scene, and can guarantee the priority response of the nursing request and the reliable transmission of the service data.

Description

Technical Field

[0001] This invention relates to the fields of smart healthcare and the Internet of Things, and in particular to a cloud-edge collaborative management method and system for home care services. Background Technology

[0002] Home-based care services are an important measure to address population aging, and their service quality and response efficiency are directly related to the health protection of those receiving care. The introduction of a cloud-edge collaborative architecture enables care service management to take into account both the resource scheduling capabilities of the cloud and the real-time response characteristics of the edge. However, the uncertainty of the network environment in the home setting brings many challenges to the practical application of this architecture.

[0003] Current home care management solutions lack effective anomaly identification and differentiated handling mechanisms at the data transmission level. When nursing requests are partially lost during transmission, recovery often relies on complete retransmission, increasing network load and delaying response to urgent requests. At the task assignment level, existing solutions rely heavily on static qualification matching rules for selecting caregivers, failing to incorporate service distance and current staff status into dynamic decision-making. This can easily lead to an imbalance where some caregivers have backlogged tasks while others are idle. At the data synchronization level, when edge devices experience upload interruptions due to network fluctuations, there is a lack of precise means to distinguish between transmitted and pending data during synchronization recovery, and a lack of predictive ability for cloud-edge data version conflicts, making it difficult to guarantee data consistency. Summary of the Invention

[0004] This invention discloses a cloud-edge collaborative management method and system for home care services. It locates transmission anomalies in nursing request data and encapsulates retransmission requests according to urgency. It comprehensively evaluates the geographical location and load status of nursing staff to select the optimal service node. It establishes a task mirror on the edge side to support offline service execution and record retention. It adopts a strategy that combines breakpoint resume and conflict pre-detection to achieve data consistency recovery in interruption scenarios. It completes the synchronization closed loop of nursing service data through latency evaluation and two-way verification.

[0005] The first aspect of this invention proposes a cloud-edge collaborative management method for home care services, comprising the following steps: Obtain nursing service request data uploaded by edge nodes, perform message integrity verification on the nursing service request data to identify abnormal data segments, and retransmit and encapsulate the abnormal data segments according to their urgency and priority to form a service request data frame. Based on the service request data frame, cloud resource routing is matched to form a dispatch route configuration. The dispatch route configuration is then subjected to proximity-weighted filtering to extract target service nodes. Downlink push channels are then constructed through the target service nodes. The downlink push channel is edge-cached and mapped to form a local task image. Offline services are executed based on the local task image to generate nursing record data. Incremental marking is applied to the nursing record data to generate data packets to be synchronized. The link connectivity detection is performed on the data packets to be synchronized to identify synchronization interruption characteristics. Based on the synchronization interruption characteristics, the breakpoint resume strategy is activated to form a resume offset parameter. The resume offset parameter is used to perform incremental difference extraction on the nursing record data to construct a consistency recovery configuration. Based on the consistency recovery configuration, service status is polled to form a synchronization completion curve. End-to-end latency assessment is performed on the synchronization completion curve to determine the data confirmation node. Based on the data confirmation node, two-way response verification is performed to complete the cloud-edge collaborative management of home care services.

[0006] A second aspect of this invention provides a cloud-edge collaborative management system for home care services, comprising: The data receiving module is used to acquire nursing service request data uploaded by edge nodes, perform message integrity verification on the nursing service request data to identify abnormal data segments, and retransmit and encapsulate the abnormal data segments according to their urgency and priority to form a service request data frame. The routing distribution module is used to perform cloud resource routing matching based on the service request data frame to form a dispatch route configuration, perform proximity-weighted filtering on the dispatch route configuration to extract target service nodes, and construct a downlink push channel through the target service nodes. The edge caching module is used to map the downlink push channel to the edge cache to form a local task image, execute offline services to generate nursing record data based on the local task image, and implement incremental marking on the nursing record data to generate data packets to be synchronized. The breakpoint resume module is used to detect the link connectivity of the data packet to be synchronized, identify the synchronization interruption characteristics, activate the breakpoint resume strategy based on the synchronization interruption characteristics to form a resume offset parameter, and use the resume offset parameter to perform incremental difference extraction on the nursing record data to construct a consistency recovery configuration. The synchronization confirmation module is used to poll the service status based on the consistency recovery configuration to form a synchronization completion curve, perform end-to-end latency assessment on the synchronization completion curve to determine the data confirmation node, and perform bidirectional response verification based on the data confirmation node to complete the cloud-edge collaborative management of home care services.

[0007] The beneficial effects of this invention are reflected in the following points: 1. By accurately locating and analyzing the urgency of the data carried by abnormal transmission segments, nursing requests containing critical information such as abnormal vital signs can be prioritized for retransmission, avoiding delays in the response time of emergency requests caused by traditional overall retransmission methods; the introduction of a dual-dimensional weighted evaluation of distance quantification and load perception in the nursing staff selection process not only shortens the travel time for nursing staff to reach the service location, but also prevents the excessive concentration of tasks on a small number of people, making the allocation of service resources more balanced and reasonable. 2. The task mirroring mechanism built on the edge side allows nursing staff to still obtain task details and execute services normally even after entering network blind spots. Nursing records generated during the service process are persistently stored and incrementally marked locally, so the execution of nursing services is no longer subject to the real-time network connection status, and the integrity of data retention is also guaranteed. 3. The resume strategy designed for synchronous interruption scenarios can resume transmission from the breakpoint instead of starting from the beginning. Combined with the conflict pre-detection mechanism, it can predict the version differences between edge data and cloud data, and select data segments without conflict risk for priority synchronization, which saves network bandwidth and avoids data overwrite risk. The confirmation threshold dynamically generated based on the actual latency distribution can adapt to changes in network conditions at different times. Combined with two-way response verification, it can ensure that both cloud and edge parties reach a consistent confirmation of the synchronization result. Attached Figure Description

[0008] The accompanying drawings illustrate specific examples of the technical solutions described in this invention and, together with the detailed embodiments, form part of the specification, serving to explain the technical solutions, principles, and effects of this invention.

[0009] Figure 1 This is a flowchart illustrating a cloud-edge collaborative management method for home care services according to the present invention.

[0010] Figure 2 This is a structural block diagram of a cloud-edge collaborative management system for home care services according to the present invention. Detailed Implementation

[0011] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0012] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0013] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0014] The technical solutions of the embodiments of this application will be described below.

[0015] like Figure 1 As shown, this embodiment of the invention provides a cloud-edge collaborative management method for home care services, including the following steps S110-S150: Step S110: Obtain nursing service request data uploaded by edge nodes, perform message integrity verification on the nursing service request data to identify abnormal data segments, and retransmit and encapsulate the abnormal data segments according to their urgency priority to form a service request data frame.

[0016] Specifically, the process involves acquiring nursing service request data uploaded by edge nodes. Edge nodes are deployed in home care service terminal devices. When a nursing need arises, they initiate a data upload request to the cloud. The cloud listens for connection requests from edge nodes through a pre-defined communication port. After authentication and a handshake, a data transmission channel is established, and the cloud begins receiving nursing service request data. The nursing service request data includes fields such as the nursing recipient's identifier, nursing need type, request initiation timestamp, and location coordinates. Each field is arranged and encapsulated according to a predefined message structure. The message header carries a version number and message type identifier to support compatible parsing of different version protocols. When a nursing recipient presses the help button at home via a smart call terminal, the edge node automatically collects their identity information and current location, encapsulates this information into nursing service request data, and uploads it to the cloud platform. The edge node uses a packet-splitting mechanism to split the nursing service request data into multiple data packets for transmission. Each data packet carries a sequence number and packet verification information. The cloud reassembles the received nursing service request data according to the data packet sequence number and returns a confirmation response to the edge node after reconstruction.

[0017] Perform message integrity checks on nursing service request data to identify abnormal data segments. The message header of the nursing service request data undergoes format verification, checking whether the message length field matches the actual received length, and verifying that the message version number is within the supported range. Sequence number continuity checks are performed on each data packet in the nursing service request data. If the sequence number difference between adjacent data packets is greater than one, a data packet is considered missing; if the same sequence number appears multiple times, a data packet is considered duplicated. Cyclic redundancy check (CRC) is used to verify the checksum of the nursing service request data payload. The verification result is compared with the original checksum carried at the end of the message. Inconsistent checksums indicate that the data has been corrupted or tampered with during transmission. In residential areas with unstable network signals, nursing service request data initiated by the recipient may experience partial data packet loss due to signal attenuation during wireless transmission. Sequence number continuity checks will identify missing data packet sequence numbers. If the terminal device has firmware defects causing incorrect checksum calculations, checksum verification will detect this type of data corruption. Data segments that fail integrity checks are marked as abnormal data segments, and the position offset and impact range of the abnormal data segments in the original message are recorded. The cloud maintains a status tracking table for abnormal data segments. When the number of retransmissions of an abnormal data segment exceeds a preset threshold, an abnormal alarm is triggered to notify the operation and maintenance personnel to intervene and handle the situation.

[0018] In some embodiments, the step of retransmitting and encapsulating the abnormal data segment according to its urgency priority to form a service request data frame includes: locating the abnormal position of the abnormal data segment to obtain a missing field index; performing urgency field association analysis based on the missing field index to extract the service urgency level; performing priority encoding on the service urgency level and the missing field index to form a retransmission priority identifier; and performing priority framing and encapsulation on the abnormal data segment according to the retransmission priority identifier to form a service request data frame.

[0019] The process involves locating the anomaly in the data segment and obtaining the missing field index. The starting offset and length of the anomaly in the original message are parsed to determine the byte range covered by the anomaly. This byte range is represented as a closed interval from the starting byte to the ending byte. The byte range of the anomaly is mapped to the field definition table of the nursing service request message. This table records the name, starting position, and length of each field in the message. Position comparison identifies the specific fields affected by the anomaly. Each field record in the field definition table is traversed to determine if its byte range intersects with the byte range of the anomaly. Fields with intersection are identified as the affected fields. When a patient initiates a request via a wearable device, if the anomaly happens to cover the field area containing vital signs data during transmission, the generated missing field index will point to the vital signs field and the health status field. Based on the numbering information of the affected fields in the field definition table, a missing field index corresponding to the anomaly is generated. This missing field index is represented as a sequence of field numbers, with elements recorded sequentially according to the order of the fields in the message. When an abnormal data segment spans multiple field boundaries, the missing field index contains the numbers of all affected fields and indicates whether each field is completely missing or partially damaged. Completely missing means that all bytes of the field fall within the range of the abnormal data segment, while partially damaged means that only some bytes of the field are affected.

[0020] Based on the missing field index, an urgency field correlation analysis is performed to extract the service urgency level. A correspondence table is established between each field in the nursing service request message and its urgency weight. The urgency weight reflects the degree to which missing fields affect the timely response of nursing services. The urgency weight for vital sign-related fields is set to 5, the urgency weight for location coordinates is set to 3, and the urgency weight for general descriptive fields is set to 1. These weight values ​​are configured and dynamically adjusted according to the priority requirements of actual nursing services. The urgency weight value corresponding to each missing field is queried one by one from the missing field index. All weight values ​​are summed to obtain the comprehensive urgency score S = Σ(i=1 to n)Wi, where i is the urgency weight value of the i-th missing field, and n is the number of missing fields. When the missing field index includes vital sign fields such as blood pressure and heart rate, since the urgency weight of these fields is 5, the comprehensive urgency score will exceed the threshold for determining the urgency level. The overall urgency score is compared with a preset grading threshold to determine the service urgency level corresponding to the current retransmission request. Service urgency levels include three levels: Urgent, Moderate, and Normal. A comprehensive urgency score of 8 or higher is classified as Urgent, a score between 4 and 7 as Moderate, and a score below 4 as Normal. Different service urgency levels correspond to different retransmission response time limits. The Urgent level requires edge nodes to complete data retransmission in the shortest possible time, ensuring that requests with missing critical data are prioritized for recovery.

[0021] The service urgency level and the missing field index are prioritized to form a retransmission priority identifier. The primary classification code for retransmission priority is determined based on the service urgency level: urgency level maps to primary classification code 01, moderate urgency level to primary classification code 02, and normal level to primary classification code 03. The primary classification code determines the basic priority order of retransmission requests; a smaller primary classification code value indicates a higher priority. Sub-classification codes are determined based on the number and distribution characteristics of fields in the missing field index. The number of fields in the missing field index is used as the primary factor for sub-classification codes; a larger number of fields indicates more severe data loss, and the corresponding sub-classification code priority is higher. The positional distribution of each field in the missing field index within the message structure is analyzed, and the interval distance between adjacent affected fields is calculated. The more dispersed the field distribution, the larger the variance of the interval distance, indicating higher retransmission recovery complexity, and the sub-classification code is correspondingly upgraded. The primary classification code and sub-classification codes are concatenated to form a complete retransmission priority identifier. The identifier format is a combination of the primary classification code, sub-classification code, and timestamp sequence number. The timestamp sequence number is used to distinguish the order of different requests within the same priority. When multiple care recipients simultaneously initiate requests and all experience data transmission anomalies, the cloud system uniformly sorts them based on the retransmission priority identifiers generated for each request. Requests with the same main category code are further prioritized according to their sub-category codes, and if the sub-category codes are also the same, the final order is determined by the timestamp sequence number. When the service urgency level is determined to be urgent and the missing field index shows that multiple critical fields are missing, the generated retransmission priority identifier will have the highest priority, ensuring that this request is processed first.

[0022] The abnormal data segment is prioritized and encapsulated into a service request data frame based on the retransmission priority identifier. The retransmission priority identifier is written into the priority field of the frame header of the retransmission request frame. Edge nodes can directly read this field after receiving the frame data to determine the urgency of the retransmission task. A data location information block is constructed based on the byte range of the abnormal data segment. This block contains the starting offset, data length, and original data packet sequence number of the abnormal data segment. Edge nodes can accurately locate the source data that needs to be retransmitted based on this location information. Retransmission control parameters are configured, including retransmission timeout, maximum number of retries, and acknowledgment mode. The retransmission timeout is set differently according to the service urgency level, with the shortest timeout for urgent levels and a more lenient timeout for normal levels. The retransmission priority identifier, data location information block, and retransmission control parameters are assembled according to a predefined frame structure, with a frame start delimiter, frame length field, and frame end checksum added sequentially to encapsulate a complete service request data frame. The service request data frame adopts a compact frame structure design, with a small space occupied by the control field and a high effective payload ratio. The service request data frame carries both the care object identifier and the request initiation timestamp. These two identifiers, as key metadata fields, together with the location information of the abnormal data segment, constitute the complete retransmission request content. Upon receiving the service request data frame, the edge node parses the retransmission priority identifier in the frame header and assesses whether the execution order of the current transmission tasks needs to be adjusted based on the load of its local task queue. For service request data frames identified as urgent, the edge node immediately suspends the currently executing ordinary transmission tasks and prioritizes responding to this retransmission request to complete the data recovery of the abnormal data segment.

[0023] Step S120: Based on the service request data frame, perform cloud resource routing matching to form a dispatch route configuration, implement proximity-based weighted filtering to extract target service nodes, and build a downlink push channel through the target service nodes.

[0024] Specifically, cloud resource routing is performed based on service request data frames to form dispatch route configurations. The cloud parses the nursing need type and location coordinate fields carried in the service request data frames. The nursing need type determines the professional qualification requirements of the required nursing staff, and the location coordinates determine the geographical constraints of the service response. Bathing services and rehabilitation nursing have different qualification requirements for nursing staff. The cloud queries the resource pool for a list of nursing staff with the corresponding service qualifications based on the nursing need type in the service request data frame. The resource pool maintains attribute information such as professional skill tags, qualification levels, and current online status for each nursing staff member. This attribute information serves as a filtering condition for route matching; nursing staff whose qualification levels do not meet the nursing need type requirements are excluded in the initial screening stage. The list of qualified nursing staff is then geofenced against the location coordinates in the service request data frames to filter out available nursing resources within the service response radius. The matching results are encapsulated into a dispatch routing configuration, which includes key information required for routing decisions, such as a list of candidate nurses, each nurse's qualification level, geographical location, and estimated arrival time. The estimated arrival time is calculated based on the distance between the nurse's current location and the service target location, as well as the average travel speed.

[0025] In some embodiments, the step of implementing proximity-based weighted filtering to extract target service nodes in the dispatch routing configuration includes: extracting a set of geographic coordinates of nursing staff and the location of the service target from the dispatch routing configuration; quantifying the distance between the set of geographic coordinates of nursing staff and the location of the service target to generate a distance weight matrix; performing load-aware weighted fusion on the distance weight matrix to form a comprehensive scoring sequence; and selecting the optimal node to determine the target service node based on the comprehensive scoring sequence.

[0026] The geographical coordinates of nursing staff and the service target location are extracted from the dispatch routing configuration. The data structure of the dispatch routing configuration is parsed, the candidate nursing staff list field is located, and the current geographical coordinates of each nursing staff member are read record by record. Geographical coordinates are represented in latitude and longitude form and include a coordinate acquisition timestamp to indicate the timeliness of the location information. The read geographical coordinates are validated; both longitude and latitude values ​​must be within the valid range. Coordinate records outside the range are marked as invalid and excluded from further processing. The geographical coordinates of all candidate nursing staff are aggregated to form a nursing staff geographical coordinate set. Each record in the nursing staff geographical coordinate set contains four attributes: nursing staff identifier, longitude value, latitude value, and coordinate acquisition timestamp. Nursing staff may be moving during service intervals; records with coordinate acquisition timestamps exceeding the validity threshold need to have their credibility weight reduced during subsequent distance quantization. The service target location of the care recipient is extracted from the service request information field in the dispatch routing configuration. The service target location is also represented in latitude and longitude coordinates. When the care recipient specifies a particular location for service, the service target location is the coordinates of that location, not the care recipient's current location. For example, if the care recipient requests a caregiver to provide service at their parents' residence, the service target location should be the coordinates of the parents' residence. The cloud performs coordinate validity verification on the service target location, eliminating abnormal coordinate values ​​that clearly exceed the service area.

[0027] A distance weight matrix is ​​generated by quantifying the distance between the set of nurses' geographic coordinates and the service target location. Using the service target location as a reference point, the geographic distance between each coordinate point in the nurses' geographic coordinate set and the reference point is calculated one by one. The distance calculation uses the spherical distance formula: d = R × arccos(sin(φ1) × sin(φ2) + cos(φ1) × cos(φ2) × cos(Δλ)), where d is the spherical distance between two points, R is the Earth's radius, φ1 and φ2 are the latitudes of the two points respectively, and Δλ is the difference in longitude between the two points. This formula calculates the arc distance on the Earth's surface based on latitude and longitude coordinates. The above distance calculation is performed on each coordinate point in the nurses' geographic coordinate set to obtain the geographic distance value from each nurse to the service target location. For nurses whose coordinate collection timestamps have exceeded the validity period threshold, their geographic distance values ​​are amplified using an attenuation coefficient to reduce their proximity advantage; the attenuation coefficient is positively correlated with the duration of the timeout. The patient is located in a residential community, and there are five qualified caregivers within a 3-kilometer radius. A distance-weighted matrix records the distance between each caregiver and the target location, along with their corresponding weight. The caregiver closest to the target location receives the highest distance-weighted value. The calculated geographical distance values ​​are normalized and mapped to a standardized weight range; the closer the distance, the higher the mapped weight. Each caregiver's identifier and their corresponding distance-weighted value are organized into a matrix, forming a complete distance-weighted matrix. Rows in the matrix correspond to different caregivers, and columns correspond to distance weights and their confidence levels, among other attributes. The distance-weighted matrix records both the original distance values ​​and the normalized weighted values.

[0028] For example, the step of performing load-aware weighted fusion on the distance weight matrix to form a comprehensive scoring sequence includes: extracting a set of candidate nursing staff identifiers from the distance weight matrix; querying the current task load based on the set of candidate nursing staff identifiers to obtain the load saturation; evaluating the service idleness of the load saturation to generate a load matching score; and weighted fusion of the load matching score with the distance weight matrix to form a comprehensive scoring sequence.

[0029] A candidate nurse identifier set is extracted from the distance weight matrix. The row indices of the distance weight matrix are traversed, and the unique nurse identifier corresponding to each row is read. Nursing identifiers are generated using a unified encoding rule to ensure global uniqueness, and the identifier format includes three parts: region code, registration number, and check digit. All read nurse identifiers are aggregated to form a candidate nurse identifier set. The number of identifiers in the candidate nurse identifier set is consistent with the number of rows in the distance weight matrix, and the identifiers are arranged in the set according to their row order in the distance weight matrix. The validity of the identifiers in the candidate nurse identifier set is verified by querying the nurse status database to confirm whether the nurse corresponding to each identifier is currently in a serviceable state. Nursing identifiers with cancelled accounts, suspended service qualifications, and currently on leave need to be removed from the candidate nurse identifier set, and the row records corresponding to these removed identifiers are marked as invalid in the distance weight matrix. The distance weight matrix contains records of ten candidate nurses. After status verification, two nurses are found to be on leave, and the final candidate nurse identifier set retains eight nurses in a serviceable state. After verification, the candidate nursing staff identifier set retains only the identifiers of nursing staff who are currently available for service, ensuring the effectiveness of queries and matching.

[0030] The load saturation is obtained by querying the current task load based on the candidate nurse identifier set. Using the identifiers in the candidate nurse identifier set as the query key, the current task load records for each nurse in the task scheduling database are queried in batches. Each identifier in the candidate nurse identifier set corresponds to a nurse's profile record in the database, which maintains the real-time status of the nurse's task load. The task load record includes the number of tasks the nurse is currently executing, the number of tasks completed today, the length of the queue of pending scheduled tasks, and the start time of the first task of the day. The continuous working time up to the current moment is calculated based on the start time of the first task of the day; this continuous working time is used to assess the nurse's fatigue level. A nurse with a daily service capacity of eight tasks who has completed five tasks and is currently executing one has relatively limited capacity to take on new tasks. Based on the various indicator values ​​in the task load record, combined with the rated daily service capacity of each nurse in the candidate nurse identifier set, the load saturation of each nurse is determined. The load saturation is expressed as a percentage, equal to the ratio of the currently undertaken task volume to the rated service capacity. A higher load saturation indicates that the workload of nursing staff is closer to saturation. The load saturation of each nursing staff member is associated with their identifier and stored to form a mapping table from identifier to load saturation.

[0031] A service idleness assessment is performed on the load saturation to generate a load matching score. The service idleness score is obtained by inversely mapping the percentage value of the load saturation; the lower the load saturation, the higher the service idleness, indicating that nursing staff have a greater capacity to handle services. The formula for calculating the service idleness score is A = (CN) / C × 100%, where A is the service idleness score, C is the rated service capacity, and N is the current workload. The service idleness score and load saturation are complementary, and their sum is always equal to 100%. Matching levels are determined based on the service idleness score: a service idleness score of 70% or higher is considered a high matching level, a service idleness score between 30% and 70% is considered a medium matching level, and a service idleness score below 30% is considered a low matching level. The matching level is converted into a quantified load matching score: a high matching level corresponds to a score of 0.9, a medium matching level corresponds to a score of 0.6, and a low matching level corresponds to a score of 0.3. The load matching score uses the same numerical range as the distance weight for weighted calculation. Nurses working continuously for more than four hours will have their load matching score reduced according to a fatigue coefficient, even if their workload saturation has not yet reached its limit. The fatigue coefficient is calculated by dividing the continuous working time by the standard eight-hour workday. For example, if a nurse has a service idle rate of 60% but has worked continuously for six hours, their fatigue coefficient is 0.75, and their load matching score will be reduced by 25% to prevent excessive fatigue from affecting service quality. The fatigue coefficient increases with the continuous working time; the longer the continuous working time, the greater the reduction in the load matching score, thus ensuring the quality of nursing services and the health of nursing staff. The load matching scores of each nurse are updated in the mapping table, and these scores, along with previously stored workload saturation data, form a corresponding evaluation result.

[0032] The load matching score and distance weight matrix are weighted and fused to form a comprehensive score sequence. A correlation between the two data points is established using nurse identifiers to ensure correct pairing of the distance weight value and load matching score for the same nurse. A fusion coefficient is set for the distance weight and load matching score; this coefficient determines the relative importance of the two indicators in the comprehensive score. The fusion coefficient can be configured and adjusted according to business strategies. In emergency nursing scenarios, the distance fusion coefficient is set to 0.7 and the load fusion coefficient to 0.3, prioritizing nurses with closer proximity to shorten response time. When service quality stability requirements are high, the load fusion coefficient is appropriately increased to prioritize nurses with lighter loads. A weighted fusion operation is performed on each nurse using the formula E = α × Wd + β × Wl, where E is the comprehensive score, Wd is the distance weight value, Wl is the load matching score, α is the distance fusion coefficient, and β is the load fusion coefficient. The fusion operation is performed on each identifier in the candidate nurse identifier set one by one. All nursing staff's comprehensive scores are arranged in order of their identifiers to form a comprehensive score sequence. Each element in the sequence contains two attributes: the nursing staff identifier and the corresponding comprehensive score.

[0033] The optimal node is selected to determine the target service node based on the comprehensive scoring sequence. The comprehensive scoring sequence is sorted from highest to lowest score, and the nurse at the top of the sort is the candidate with the best comprehensive performance. The edge node identifier of the nurse at the top of the comprehensive scoring sequence is extracted, and the online availability of this edge node is verified. If the edge node is online and the communication link is normal, it is determined as the target service node, and the node identifier and associated nurse information of the target service node are recorded in the dispatch result data. If the edge node corresponding to the nurse at the top of the sort is offline or in a communication abnormal state, the search continues along the comprehensive scoring sequence until a normal edge node is found as the target service node. During peak service periods, multiple nurses with high rankings in the comprehensive scoring sequence may be busy. In this case, the edge node corresponding to the first available nurse is selected according to the sequence order. The estimated arrival time and other attributes of the selected target service node are written into the dispatch result record, and the task load status of the nurse is updated. Once the target service node is determined, the downlink channel establishment process is triggered immediately.

[0034] A downlink push channel is established through the target service node. The cloud initiates a channel establishment request to the target service node, carrying configuration information such as the channel identifier, encryption key negotiation parameters, and channel validity period in the request message. After receiving the channel establishment request, the target service node pre-allocates local resources, including allocating a data receiving buffer and registering message listening callbacks. After completing preparation, it returns a channel readiness confirmation to the cloud. Upon receiving the readiness confirmation, the cloud marks the channel status as active, and the downlink push channel with the target service node is officially established. The downlink push channel uses a long-connection mechanism to maintain a persistent communication link between the cloud and the edge node. The cloud pushes information such as nursing task details, special precautions for the nursing subjects, and service time limits to the edge node in real time through the downlink push channel. The downlink push channel supports message priority marking. Push messages for emergency nursing tasks will be transmitted and processed first, while ordinary task messages will be pushed in a first-in-first-out order. When a network anomaly occurs at the target service node, causing the downlink push channel to be interrupted, the cloud initiates a channel reconstruction mechanism and temporarily stores the messages to be pushed during the interruption. If a nursing staff member enters an underground parking lot and causes a network signal interruption, the task details to be pushed will be temporarily stored and automatically resent after the nursing staff member returns to the ground and the signal is restored.

[0035] Step S130: The downlink push channel is edge-cached and mapped to form a local task image. The offline service is executed based on the local task image to generate nursing record data. Incremental marking is performed on the nursing record data to generate data packets to be synchronized.

[0036] Specifically, the downlink push channel is edge-cached to form a local task image. Edge nodes continuously receive nursing task data pushed from the cloud through the downlink push channel. The task data includes basic information about the patient, a list of nursing services, service time requirements, and special precautions. All content is encapsulated and transmitted according to a predefined data structure. Edge nodes allocate a dedicated task cache space in their local storage area. The cache space capacity is configured based on the edge node's storage resources and the expected task scale. The cache space uses a circular buffer structure to support efficient data writing and reading. The task data transmitted through the downlink push channel is parsed and stored according to the predefined data structure. The parsing process extracts each field from the task data and converts it to a local storage format. The storage process writes the parsed data to the corresponding location in the cache space. The cached data is indexed and organized according to task identifiers. An index record is created for each task, containing the task identifier and the storage address of the task data in the cache space, supporting quick retrieval and access to the corresponding task details based on the task identifier. When nursing staff travel to the patient's residence, they may pass through areas with weak network signals. The edge nodes cache nursing task details through the local task image, ensuring that nursing staff can view complete service requirements and precautions even when offline upon arrival. Edge nodes establish version tags for cached task data. These version tags use incrementing sequence numbers to indicate the data update order, with an initial version number of one, incremented by one after each data update. When the cloud pushes task update information via the downlink push channel, the edge node compares the version number in the update information with its local version tag. If the version number is newer, the local cache is refreshed and the version tag is updated; otherwise, the update information is ignored to avoid data rollback. The complete set of task data stored in the cache space is then encapsulated into a local task image.

[0037] In some embodiments, the step of generating nursing record data by performing offline services based on the local task image includes: parsing a nursing task list from the local task image; performing abnormal vital sign detection based on the nursing task list to generate a vital sign status marker; associating the vital sign status marker with the local task image based on urgency to form an urgency nursing entry; and persistently storing the urgency nursing entry with priority to form nursing record data.

[0038] The nursing task list is parsed from the local task image. The data structure of the local task image is read, the task item list field is located and parsed item by item. The task item list in the local task image is stored in a structured format, and each task item includes attributes such as service type code, service content description, estimated execution time, and execution sequence number. All parsed task items are arranged and organized according to their execution sequence number to form an ordered nursing task list. During the parsing process, health background information about the nursing subjects is extracted from the local task image. This health background information includes past medical history, allergy information, and a list of currently taken medications. This health background information serves as supplementary reference information for the nursing task list, used to adjust abnormality thresholds during subsequent vital sign monitoring. Historical vital sign baseline values ​​are extracted from the nursing subject's health record field in the local task image. These historical vital sign baseline values ​​record the daily normal range of various vital sign indicators for the nursing subject. Each service item in the nursing task list is arranged sequentially according to its execution sequence number. If the nursing subject has a health condition requiring special attention, such as diabetes or hypertension, it will be prominently marked in the nursing task list to remind nursing staff to pay attention to relevant contraindications during the service.

[0039] Based on the nursing task list, abnormal vital signs are detected and vital sign status markers are generated. Real-time vital sign data, including blood pressure, heart rate, body temperature, and blood oxygen saturation, are collected from the nursing subjects according to the vital sign monitoring services included in the task list. The collected vital sign data is compared with historical baseline values ​​to identify any abnormal deviations. The comparison process uses preset abnormality judgment rules, which include the upper and lower limits of the normal fluctuation range for each vital sign indicator. Normal blood pressure ranges are 90-140 mmHg systolic and 60-90 mmHg diastolic; normal heart rate ranges are 60-100 beats / minute; normal body temperature ranges are 36.0-37.3℃; and normal blood oxygen saturation ranges are 95%-100%. An abnormality marker is triggered when any vital sign indicator exceeds its normal fluctuation range. The thresholds of the abnormality judgment rules are adjusted based on the underlying disease types in the health background information. The upper limit of the normal blood pressure range is appropriately relaxed for nursing subjects with hypertension, while the judgment of abnormal heart rate is more stringent for nursing subjects with heart disease. A linked analysis is performed on multiple vital signs indicators involved in the nursing task list. When multiple indicators deviate simultaneously, such as elevated blood pressure and heart rate exceeding normal levels, the abnormality level needs to be raised. Based on the abnormality detection results, vital sign status tags are generated. These tags record the current status rating of each vital sign, including levels of normal, mild abnormality, moderate abnormality, and severe abnormality. Vital sign status tags generated during the execution of the nursing task list are linked to nursing service records.

[0040] The urgency of vital sign status markers is correlated with the local task image to form urgency care entries. The status rating of each vital sign indicator in the vital sign status markers is read. Vital sign indicators with severe abnormalities correspond to the highest urgency level, indicating a potential health risk requiring immediate treatment; vital sign indicators with normal conditions correspond to the lowest urgency level, indicating that the indicator is stable. The basic urgency configuration of the care recipient is obtained from the local task image. The basic urgency configuration is pre-set according to the care recipient's care level and the severity of underlying diseases. Care levels are divided into four levels, with level one care recipients having the highest basic urgency configuration and level four care recipients having a lower basic urgency configuration. For care recipients who are bedridden for a long time or have serious underlying diseases, the basic urgency configuration in the local task image is usually set to a higher level. The urgency of vital signs determined by the vital sign status markers is comprehensively correlated with the basic urgency configuration in the local task image, and the final urgency level is determined according to the principle of taking the highest value. The urgency level is bound and encapsulated with the corresponding nursing service record to form an urgency nursing entry. The urgency nursing entry fully includes the execution record of the nursing service and the urgency level identifier corresponding to the record. When the vital signs are marked as severely abnormal, the urgency nursing entry generated will be marked as the highest urgency level.

[0041] Emergency care items are prioritized and persistently stored to form nursing record data. Storage priority is determined based on the urgency level indicated in the emergency care item; higher urgency levels result in higher storage priority in the persistent queue. A tiered storage strategy is used for local storage on edge nodes. High-priority emergency care items are stored in faster-responding storage areas. Blood pressure abnormalities recorded by caregivers during service are considered high-urgency items and are stored in faster-responding storage areas to facilitate priority uploading to the cloud and triggering health alerts after network recovery. Emergency care items are written to persistent storage according to a unified data format. During the writing process, a storage timestamp and data integrity verification information are added. The storage timestamp records the persistence time of the data item and is used to determine the age of the data item during incremental marking. The data integrity verification information uses a CRC32 checksum and is carried as a verification field when encapsulating data packets to be synchronized. After the storage operation is completed, the local data index table is updated. The index table records metadata such as the storage location, urgency level, and synchronization status of each emergency care item. The set of all persistently stored emergency care items is marked as nursing record data, which is a complete data archive of this nursing service process.

[0042] Incremental marking is implemented for nursing record data to generate data packets to be synchronized. Edge nodes maintain synchronization status identifiers for nursing record data, with newly generated nursing record data initially marked as unsynchronized. Change detection is performed on unsynchronized nursing record data to identify data fields added or modified since the last synchronization. Nurses may supplement or correct record content multiple times during service, and each modification triggers an update of the corresponding field's change marker. The detected new and changed data are extracted and encapsulated according to the data format required by the cloud interface. During encapsulation, metadata information such as a timestamp, operation type identifier, and data verification code are added to each data record. The operation type identifier is determined based on the data entry's status in the local data index table: newly created entries are marked as "added," existing entries with changed content are marked as "modified," and existing entries that have been removed are marked as "deleted." The data verification code is extracted from the data integrity verification information generated during persistent storage. Since nurses supplement service records multiple times during care, the incremental marking mechanism only encapsulates the newly added and modified content into data packets to be synchronized, avoiding duplicate transmission of synchronized historical data. The encapsulated data set is organized into synchronization data packets. These packets contain only incrementally changed nursing record data, rather than the full dataset, effectively reducing the amount of data transmitted over the network. Edge nodes place these synchronization data packets into a synchronization task queue to await uploading.

[0043] Step S140: Perform link connectivity detection on the data packets to be synchronized to identify synchronization interruption characteristics, activate the breakpoint resume strategy based on the synchronization interruption characteristics to form a resume offset parameter, and use the resume offset parameter to extract incremental differences from the nursing record data to construct a consistency recovery configuration.

[0044] Specifically, link connectivity detection is performed on the data packets to be synchronized to identify synchronization interruption characteristics. Before initiating the upload of the data packets to be synchronized, the edge node sends a link probe message to the cloud to detect the current network connection status. The link probe message is in the form of a lightweight heartbeat packet, carrying a timestamp and sequence number field. The sequence number field is used to identify the sending order of the probe messages and detect message loss. The cloud immediately returns a response upon receiving the probe message. The edge node evaluates the link connectivity based on the round-trip time of the probe message and the success rate of the response. When nursing staff move from indoors to outdoors or enter an elevator during service, the network connection status may change abruptly. A sudden increase in round-trip time or loss of response indicates an abnormality in the link. If the link probe shows normal connectivity, the edge node begins to upload the data packets to be synchronized in fragments, continuously monitoring the transmission confirmation status of each data fragment during the upload process. When multiple consecutive data fragments fail to receive a confirmation response from the cloud, the edge node determines that the synchronization process has been interrupted, records the time of the interruption, the amount of data successfully transmitted, and the link status parameters before the interruption. The link status parameters include the average round-trip time and packet loss rate before the interruption. These interruption-related information are summarized and encapsulated into a synchronization interruption feature, which describes when, where, and why the synchronization process was interrupted. The synchronization interruption feature also includes the sequence number and verification information of the last successfully acknowledged fragment before the interruption. This information is the key basis for triggering the breakpoint resumption mechanism. The link state parameters are used to assess whether the transmission strategy needs to be adjusted during channel reconstruction.

[0045] In some embodiments, the step of activating the breakpoint resumption strategy based on the synchronous interruption feature to form the resumption offset parameter includes: locating the breakpoint location identifier by performing interruption time location on the synchronous interruption feature; querying the urgency of the data to be transmitted based on the breakpoint location identifier to generate an urgency priority sequence; sorting the urgency priority sequence by priority to form a priority transmission queue; and performing resumption offset analysis on the priority transmission queue to form the resumption offset parameter.

[0046] The interruption time is located and the breakpoint location identifier is obtained by analyzing the synchronization interruption features. The interruption time recorded in the synchronization interruption features is parsed, and this time corresponds to the confirmation timestamp of the last successfully transmitted data fragment. Based on the interruption time, the corresponding fragment index number is found in the transmission sequence of the data packets to be synchronized. This index number identifies at which data fragment the transmission process was interrupted. The fragment index number is cross-validated with the data offset recorded in the synchronization interruption features to ensure the accuracy of the breakpoint location. The offset is calculated using the formula O = Σ(i=1 to n)Li, where O is the breakpoint offset, Li is the data length of the i-th confirmed fragment, and n is the index number of the last confirmed fragment. Li is extracted from the metadata of each confirmed fragment recorded in the synchronization interruption features. If a synchronization task is interrupted due to network fluctuations while transmitting the fifteenth data fragment, the breakpoint location identifier points to the starting offset position of the fifteenth fragment. The generated breakpoint location identifier is stored in a structured format, containing fields such as task identifier, fragment index, byte offset, and interruption timestamp. The synchronous interrupt feature may record information about multiple interrupt retries. When locating the interrupt, the position of the last valid transmission is used as the reference point for identifying the breakpoint location.

[0047] Based on the breakpoint location identifier, the urgency of the data to be transmitted is queried to generate an urgency priority sequence. The range of data fragments that have not yet been transmitted is determined according to the fragment index and byte offset recorded in the breakpoint location identifier. Starting from the fragment pointed to by the breakpoint location identifier, this fragment and all subsequent fragments belong to the data to be transmitted. The list of data fragments to be transmitted is traversed, and the nursing record entries associated with each fragment are read one by one. The association between fragments and nursing record entries is established and recorded in the fragment metadata during the data encapsulation stage. The urgency level marked at the time of generation for each nursing record entry is queried. The urgency level is determined based on the vital sign status during the nursing service execution stage. The query operation retrieves the corresponding urgency attribute value in the local data index table using the identifier of the nursing record entry. Nursing records containing abnormal vital sign information usually have a higher urgency level; for example, records corresponding to patients with significantly abnormal blood pressure or heart rate will be marked as urgent. Records of ordinary service processes, such as assisting with meals or daily care, have a relatively lower urgency level. Each data fragment to be transmitted is associated with its corresponding urgency level and mapped. The mapping results are stored in key-value pairs, where the key is the fragment identifier and the value is the urgency level. All mapping results are aggregated to form an urgency priority sequence. The urgency priority sequence records the identifier of each fragment to be transmitted and its corresponding urgency level in list form. The initial order of the elements in the list is consistent with the order of the fragments to be transmitted in the original data packet. The range to be transmitted, determined by the breakpoint position, determines the starting boundary of the urgency priority sequence.

[0048] The urgency priority sequence is sorted to form a priority transmission queue. Records in the urgency priority sequence are sorted from highest to lowest urgency level using a stable sorting algorithm to ensure that records with the same urgency level maintain their relative positions according to the original fragment order. Maintaining the relative position helps maintain data continuity and simplifies the reassembly process at the receiving end. After sorting, the data fragments with the highest urgency level are placed at the head of the sequence. These fragments contain nursing information that is most critical for timely cloud response; for example, records of patients with abnormal vital signs are placed before records of ordinary services. The sorted urgency priority sequence is then converted into a priority transmission queue data structure. This conversion process restructures the list structure into a queue structure, with the enqueue end corresponding to the tail of the list and the dequeue end corresponding to the head of the list. The queue structure supports sequential dequeue operations. Resuming transmission tasks obtain the next fragment to be transmitted sequentially through dequeue operations, with the dequeue order consistent with the sorted priority order. If a data fragment associated with severe vital signs abnormalities exists in the urgency priority sequence, that fragment will be prioritized for transmission at the top of the priority transmission queue, ensuring that the health abnormality information of the cared-for individual reaches the cloud as soon as possible to trigger an alarm response. The first element of the priority transmission queue corresponds to the data fragment that most urgently needs to be uploaded. Resumption tasks are processed sequentially starting from the first element, and each fragment is removed from the priority transmission queue after processing.

[0049] A continuation offset analysis is performed on the priority transmission queue to generate continuation offset parameters. Each data fragment record in the priority transmission queue is traversed, and the byte offset position and length information of each fragment in the original data packet are analyzed. Since the order of the priority transmission queue may differ from the original transmission order, the transmission offset parameters of each fragment need to be replanned to support out-of-order transmission and receiver reassembly. In the original transmission order, the third fragment is a normal service record, and the seventh fragment is a vital sign abnormality record. After priority reordering, the fragment of the vital sign abnormality record will be transmitted first. The continuation offset parameters record this offset mapping relationship of out-of-order transmission. An independent offset descriptor is generated for each fragment in the priority transmission queue. The descriptor contains the fragment's starting offset in the source data, fragment length, and target reassembly position. The format of the offset descriptor is {fragment ID, source offset, length, target position, urgency}. The offset descriptors of all fragments are organized according to the order of the priority transmission queue to form the continuation offset parameters. The continuation offset parameters not only record where to start the continuation but also record the transmission priority order and reassembly rules of each fragment. The resume offset parameter enables the cloud to correctly reassemble data when it receives out-of-order fragments, ensuring that the finally recovered nursing record data is consistent with the local data on the edge node. The edge node persistently stores the resume offset parameter and reads and executes it after the link is restored. Even if the resume process is interrupted again, it can continue to recover based on the existing resume offset parameter.

[0050] In some embodiments, the step of using the continued transmission offset parameter to perform incremental difference extraction on the nursing record data to construct a consistency recovery configuration includes: locating the unsynchronized segment of the nursing record data according to the continued transmission offset parameter; performing conflict pre-detection analysis on the unsynchronized segment to generate a conflict risk identifier; using the conflict risk identifier to screen for safe segments and identify conflict-free difference data blocks; and constructing an incremental update queue based on the conflict-free difference data blocks to form a consistency recovery configuration.

[0051] The unsynchronized segments of nursing record data are located based on the resume offset parameters. The breakpoint offset positions and the list of fragments to be transmitted, recorded in the resume offset parameters, are read, and synchronization boundaries are defined in the nursing record data based on this information. Data before the breakpoint position indicated by the resume offset parameters has been confirmed for synchronization; data at and after the breakpoint position belongs to the unsynchronized segment. The storage structure of the nursing record data is scanned, and all data entries falling within the unsynchronized segment are extracted. The amount of data in the unsynchronized segment depends on the progress of the synchronization task when the interruption occurred. The synchronization task was interrupted when 60% of the progress was completed. The 40% of nursing record data after the breakpoint position indicated by the resume offset parameters belongs to the unsynchronized segment. Service records added by nursing staff during the interruption are also included in the unsynchronized segment. Nursing record data may have been updated during the synchronization interruption. Nursing staff continue to provide services to patients and enter new records while waiting for the network to recover; some synchronized segments may also have been modified. By comparing the last modification timestamp of each entry in the nursing record data with the synchronization interruption time, entries modified after the interruption time are appended to the unsynchronized segment, ensuring that all changed data is included in the subsequent discrepancy analysis. After the complete boundary of the unsynchronized segment is determined, a list of data entries within that segment is extracted for conflict detection.

[0052] For example, the step of performing conflict pre-detection analysis on the unsynchronized segment to generate a conflict risk identifier includes: dividing the unsynchronized segment into blocks according to importance to obtain a hierarchical data block sequence; performing differential verification on the hierarchical data block sequence according to importance level to generate hierarchical verification values; concatenating and encoding the hierarchical verification values ​​according to priority order to form a hierarchical verification chain; and performing lightweight aggregation on the hierarchical verification chain to generate a conflict risk identifier.

[0053] Unsynchronized segments are prioritized and divided into hierarchical data block sequences. The business attributes of each data item in the unsynchronized segment are analyzed, and the data is categorized according to its importance. Vital sign monitoring data and abnormal alarm information are considered high-importance data, directly related to the assessment of the patient's health status; routine service records such as daily living assistance and companionship records are considered medium-importance data; auxiliary instructions and remarks are considered low-importance data. Unsynchronized segments are divided into multiple data blocks according to their importance level, with data items of the same importance level grouped into the same data block. Unsynchronized segments may contain both abnormal blood pressure information recorded by nursing staff and confirmations of routine service completion; the former is grouped into high-importance data blocks and the latter into medium-importance data blocks, ensuring that important data receives priority processing. Data blocks of each importance level are arranged in descending order to form a hierarchical data block sequence, with each element in the sequence corresponding to a specific importance level data block. The order of the hierarchical data block sequence determines the priority of conflict detection and synchronization processing, ensuring that important data receives priority processing during conflict analysis and resynchronization.

[0054] The hierarchical data block sequence is subjected to differentiated verification based on its importance level to generate hierarchical verification values. Each data block in the hierarchical data block sequence is verified separately, with different strength verification algorithms used for data blocks of different importance levels to balance security and efficiency. High-importance data blocks use strong verification algorithms such as SHA-256 to perform a complete hash operation on the data content to ensure that any subtle changes are detected; even minor modifications to the vital signs data of the care recipients must be accurately identified. Medium-importance data blocks use standard verification algorithms such as MD5 to reduce computational overhead while ensuring verification reliability. Low-importance data blocks use lightweight verification algorithms such as CRC32, verifying only key fields to reduce processing time. Each data block in the hierarchical data block sequence undergoes a corresponding verification operation to generate a hierarchical verification value for that data block. The hierarchical verification value reflects the characteristic summary of the data block content. Identical content generates the same hierarchical verification value; changes in content will cause changes in the hierarchical verification value. The hierarchical verification values ​​of each data block can be compared with the verification values ​​of existing data in the cloud to quickly identify data areas with discrepancies.

[0055] The hierarchical checksums are concatenated and encoded in priority order to form a hierarchical checksum chain. The hierarchical checksums corresponding to the hierarchical data block sequence are arranged in order of importance, with high-importance data blocks' checksums listed first and low-importance data blocks' checksums listed last. Concatenation encoding is then performed on the arranged hierarchical checksum sequence. Concatenation encoding links adjacent checksums together using a hash chaining algorithm to form a chain structure. The chain code of the first node is C1 = H(V1||IV), where V1 is the first hierarchical checksum, IV is a preset initialization vector, and the encoding formula for subsequent nodes is Ci = H(Vi||Ci-1), where Ci is the chain code of the i-th node, Vi is the i-th hierarchical checksum, Ci-1 is the chain code of the previous node, H is the hash function, and || is the join operation. During concatenation encoding, the previous hierarchical checksum serves as one of the input parameters for encoding the next checksum, forming a dependency relationship between checksums. This chain dependency ensures that any change to any data block will affect the encoding result of subsequent nodes in the chain. If the content of a highly important data block changes, its hierarchical checksum value will change, leading to a chain reaction of changes in the chaincode values ​​of that node and all subsequent nodes in the hierarchical checksum chain, quickly locating the data discrepancies. The complete result of the concatenated encoding is encapsulated into a hierarchical checksum chain, which stores the checksum information and concatenation relationship of each hierarchical data block in a compact data structure. The hierarchical checksum chain can be transmitted between edge nodes and the cloud for quickly comparing the consistency status of the data on both sides.

[0056] A lightweight aggregation process is performed on the hierarchical check chain to generate conflict risk identifiers. The hierarchical check chain is compressed, and key features of the check values ​​of each node in the chain are extracted and aggregated. The aggregation operation uses a digest algorithm to generate a fixed-length feature code for the entire content of the hierarchical check chain. This feature code uniquely represents the current data state of the unsynchronized segment, and the length of the aggregated feature code is much smaller than the data volume of the original hierarchical check chain. Edge nodes send feature code query requests to the cloud. The cloud calculates and returns the corresponding feature code based on the data segment identifier. Both the edge node and the cloud calculate the feature code for the unsynchronized segment. If the feature codes at both ends are consistent, it indicates that there is no data difference and synchronization can be directly marked as complete. If they are inconsistent, further comparison of the hierarchical check chain is needed to locate the specific difference. The feature code of the hierarchical check chain is compared with the feature code returned by the cloud to determine if there is a difference between the two sets of data. If the feature codes are consistent, it indicates that the data content of the edge node and the cloud is the same, and there is no conflict risk. If the feature codes are inconsistent, further analysis of the check values ​​of each node in the hierarchical check chain is performed to locate the specific difference. Due to the characteristics of concatenated encoding, the first data block with a difference can be quickly located through node-by-node comparison. Based on the signature comparison results and difference location analysis, the final conflict risk identifier is generated. The conflict risk identifier integrates the aggregation results of the hierarchical verification chain and detailed difference location information.

[0057] The process involves identifying conflict-free data blocks by using conflict risk markers to filter data from unsynchronized segments. Each data entry in the unsynchronized segment is traversed, and the conflict risk marker for each entry is read and categorized according to risk level. Data entries with a risk-free marker can be directly synchronized without additional conflict resolution; these entries are typically new nursing records or data not yet stored in the cloud. Data entries with a low-risk marker employ an optimistic locking mechanism for synchronization attempts. The local version number increments with each data modification, while the latest version number of each data entry is stored in the cloud for comparison. Edge nodes send update requests to the cloud carrying their local version number. If the cloud version number matches the local version number, synchronization is successful; otherwise, the conflict resolution process begins. Data entries with a high-risk marker require temporary suspension of synchronization and are recorded in a conflict queue awaiting manual intervention or automatic conflict merging. For example, if there are discrepancies between vital sign data recorded by nursing staff and examination data uploaded by the hospital, professional judgment is required. The filtered risk-free and low-risk data entries are organized into conflict-free data blocks, which are subsets of data in the unsynchronized segment that can be safely incrementally synchronized. Conflict-free differential data blocks are sorted according to the urgency level of the data entries, with higher urgency entries listed first for priority synchronization. The filtering process also generates a list of conflicting data entries to record high-risk data entries for subsequent processing.

[0058] An incremental update queue is constructed based on conflict-free differential data blocks to form a consistent recovery configuration. Data entries in the conflict-free differential data blocks are organized into an incremental update queue according to their synchronization order. Each element in the incremental update queue includes the data entry content, target storage location, and operation type identifier. The operation type identifier distinguishes whether the entry is an add, modify, or delete operation. The cloud executes the corresponding data processing logic based on the operation type identifier: add operations create new records, modify operations update existing records, and delete operations remove specified records. Queue metadata information is added to the incremental update queue, including the total queue length, data checksum, source edge node identifier, and generation timestamp. The checksum in the metadata is used by the cloud to verify the integrity of the received data. The relationships between entries in the conflict-free differential data blocks are preserved in the incremental update queue. Entries with dependencies maintain the correct processing order; for example, vital sign measurement records need to be synchronized before health assessment records based on those vital signs. Resumption control parameters are configured, including breakpoint offset, fragment transmission order, and retry strategy. The retry strategy uses an exponential backoff mechanism, with an initial retry interval of 2 seconds, doubling the interval for each subsequent retry, and a maximum of 5 retries. Configure anomaly handling contingency plans, including transmission timeout retry mechanisms, verification failure rollback strategies, and channel interruption switching schemes. Configure conflict handling strategies, which determine how to handle conflicting data based on the list of conflicting data entries and the conflict queue. Integrate the incremental update queue with the resume control parameters, anomaly handling contingency plans, and conflict handling strategies, and encapsulate them into a consistency recovery configuration. The consistency recovery configuration includes the content of conflict-free differential data blocks that need to be synchronized, the synchronization execution strategy, and the anomaly handling contingency plans.

[0059] Step S150: Based on the consistency recovery configuration, the service status is polled to form a synchronization completion curve. End-to-end latency assessment is performed on the synchronization completion curve to determine the data confirmation node. Based on the data confirmation node, two-way response verification is performed to complete the cloud-edge collaborative management of home care services.

[0060] Specifically, a synchronization completion curve is generated by polling the service status based on the consistency recovery configuration. Edge nodes initiate data synchronization tasks according to the incremental update queue in the consistency recovery configuration, uploading data items to be synchronized to the cloud sequentially according to the queue order. After each data item is uploaded, the edge node sends a status query request to the cloud to obtain the processing status of that item. The status query uses an asynchronous polling mechanism to avoid blocking subsequent data uploads. The cloud processes the received data, including verification, storage, and index updates. After processing, the status is updated to "confirmed." If processing fails, a corresponding error code is marked, including data verification failure and insufficient storage space. Items with failed data verification are added to the retry queue for re-upload. If storage space is insufficient, a cloud capacity expansion alarm is triggered. Edge nodes periodically poll the synchronization status of each data item in the consistency recovery configuration. The polling interval is dynamically adjusted according to network conditions: the polling interval is set to 1 second when the round-trip latency is less than 100ms, 3 seconds when the round-trip latency is between 100ms and 500ms, and extended to 5 seconds when the round-trip latency exceeds 500ms. The number of entries in the three states—confirmed, pending, and failed—is counted. The synchronization completion rate at each polling time is recorded as P = Nc / Nt × 100%, where P is the synchronization completion rate, Nc is the number of confirmed entries, and Nt is the total number of entries. As the synchronization task progresses, the synchronization completion rate gradually increases. The completion rates at each time point are connected in chronological order to form a synchronization completion curve. Entries in the retry queue are re-uploaded according to the retry policy in the consistency recovery configuration. Entries that fail after exceeding the maximum number of retries are marked as synchronization anomalies and recorded in the anomaly log.

[0061] In some embodiments, the step of performing end-to-end latency assessment on the synchronization completion curve to determine the data confirmation node includes: extracting transmission timestamps for each stage from the synchronization completion curve; performing segmented latency analysis based on the transmission timestamps for each stage to obtain a latency distribution; performing fluctuation characteristic analysis on the latency distribution to generate an adaptive latency threshold; and determining the data confirmation node by comparing the adaptive latency threshold with the latency distribution.

[0062] Extract transmission timestamps for each stage from the synchronization completion curve. Divide the synchronization completion curve into multiple stages according to the synchronization progress, with each stage corresponding to a certain proportion of data synchronization tasks. Stage division can be done using an equal-interval method, uniformly dividing the completion rate from zero to 100% into ten segments, or an adaptive method can be used to dynamically determine stage boundaries based on the curve shape, setting stage boundary points where the curve slope changes significantly. Read the timestamps corresponding to the start and end points of each stage on the synchronization completion curve. These timestamps record the specific moments when the synchronization task enters and leaves each stage. The synchronization task takes 120 seconds from start to completion, divided into ten stages at 10% progress intervals. The transmission timestamps for each stage record the moments when 10%, 20%, and up to 100% of the progress is completed. The moment the first data fragment is sent at the start of the synchronization task is used as the first timestamp, and the corresponding timestamp is recorded when each stage goal is achieved. Organize the extracted timestamps according to the stage order to form a sequence of transmission timestamps for each stage. The difference between adjacent timestamps in each stage reflects the synchronization time of the corresponding stage. The slope of the synchronization completion curve changes at different times, which is reflected in the interval distribution of transmission timestamps at each stage. A uniform interval distribution indicates a stable synchronization rate, while a large fluctuation in the interval distribution indicates a significant change in the synchronization rate, which may correspond to fluctuations in network conditions or cloud load.

[0063] Segmented latency analysis is performed based on the transmission timestamps of each stage to obtain the latency distribution. The difference between adjacent timestamps in the transmission timestamp sequence of each stage is calculated to obtain the actual duration of each stage: Di = Ti+1 - Ti, where Di is the duration of the i-th stage, and Ti and Ti+1 are the start and end timestamps of that stage, respectively. The duration of each stage is divided by the amount of data completed in that stage to obtain the average transmission latency per unit data volume: di = Di / Si, where di is the average transmission latency per unit data volume in the i-th stage, and Si is the amount of data transmitted in the i-th stage. The average transmission latency of each stage is summarized to form a latency sequence, which reflects the changes in transmission efficiency at each stage during the synchronization process. Statistical analysis is performed on the latency sequence to extract statistical indicators such as the maximum latency (dmax), minimum latency (dmin), mean latency (μ), and standard deviation (σ). If the synchronization period corresponding to the transmission timestamp of each stage includes network switching or cloud load fluctuations, the latency value of that stage may deviate significantly from the mean. Synchronization latency is usually lower during late-night hours when cloud load is low, while latency may increase significantly during peak daytime service periods. The statistical analysis results are organized into a time delay distribution data structure. The time delay distribution includes the time delay values ​​at each stage and the overall statistical indicators. The time delay distribution fully describes the variation pattern and dispersion of time delay during the synchronization process.

[0064] An adaptive latency threshold is generated by analyzing the fluctuation characteristics of the latency distribution. The trend of latency values ​​at each stage of the latency distribution is analyzed to identify whether the latency is stable, increasing, or decreasing. Trend identification uses linear regression to fit the latency sequence and obtain the trend slope. A positive trend slope exceeding a preset threshold indicates that the network condition is deteriorating, and the adaptive latency threshold is adjusted proportionally to adapt to the deteriorating trend. A negative trend slope indicates that synchronization conditions are improving, and the adaptive latency threshold can be appropriately tightened to accelerate the confirmation frequency. The dispersion of the latency distribution is evaluated. A large standard deviation indicates severe latency fluctuations and an unstable network environment; a small standard deviation indicates relatively stable latency and a good network environment. The adaptive latency threshold is dynamically generated based on the mean and standard deviation of the latency distribution. The threshold formula is T = μ + k × σ, where T is the adaptive latency threshold, μ is the mean latency, σ is the standard deviation of latency, and k is a configurable sensitivity coefficient. The sensitivity coefficient k is set according to the business's tolerance for latency. For emergency care tasks, a value of 1.5 is used to tighten the adaptive latency threshold and improve timely confirmation, while for regular tasks, a value of 2.5 is used to relax the threshold and reduce confirmation overhead. The adaptive latency threshold automatically adjusts according to actual network conditions. When network conditions are good, the threshold is tightened to improve timely confirmation; when network conditions are poor, the threshold is relaxed to avoid frequent timeout alarms.

[0065] Data confirmation nodes are determined by comparing the adaptive latency threshold with the latency distribution. The latency values ​​of each stage in the latency distribution are compared one by one with the adaptive latency threshold to identify stages where the latency values ​​are close to or exceed the threshold. Stages where the latency value exceeds the adaptive latency threshold may indicate transmission anomalies, requiring data confirmation at the end of the stage to promptly detect problems. If the latency of a stage suddenly increases above the threshold, data transmission in that stage may be interfered with and requires close monitoring. Multiple consecutive stages with latency values ​​significantly lower than the adaptive latency threshold can be merged for batch confirmation, reducing the frequency of confirmation communication overhead. Frequent confirmations are unnecessary when the synchronization process is smooth. Each confirmation time point is marked on the synchronization completion curve; the corresponding synchronization progress positions are the data confirmation nodes. The distribution of data confirmation nodes balances confirmation timeliness and resource efficiency. More densely packed data confirmation nodes are used in critical stages to improve the timeliness of anomaly detection, while more sparsely packed confirmation nodes are used in stable stages to reduce system overhead. The final location list of data confirmation nodes is output to the synchronization task scheduling module. When the synchronization progress reaches each data confirmation node, the scheduling module triggers the corresponding confirmation request process. The fluctuation characteristics of the latency distribution determine the density of the data confirmation nodes. The segment with drastic fluctuations in latency distribution corresponds to a denser number of data confirmation nodes.

[0066] The cloud-edge collaborative management of home care services is completed through bidirectional response verification based on data confirmation nodes. At each data confirmation node, the edge node initiates a data confirmation request to the cloud, carrying a list of data items involved in the confirmation and local verification information. After receiving the confirmation request, the cloud verifies whether the data items listed in the request have been successfully stored and whether the data integrity has passed the verification. The verification methods include comparing data length, checksum, and key field content. The cloud encapsulates the verification result into a confirmation response message and returns it to the edge node. The response message contains the confirmation status of each data item and a storage certificate generated by the cloud. The storage certificate is recorded in the local synchronization status table for storage proof in subsequent data traceability and dispute resolution. After receiving the confirmation response, the edge node verifies the legality of the response message, checks whether the list of data items in the response is consistent with the request, and ensures that the response content has not been tampered with or lost. The edge node updates the local synchronization status table according to the confirmation results of the data confirmation nodes. Confirmed data items are marked as synchronized successfully, and items that failed to be confirmed are added to the retry queue. Items in the retry queue are processed first at the next data confirmation node. After a nursing staff member completes a home visit, the edge node completes verification at three data confirmation nodes, and all nursing record data is successfully synchronized to the cloud. The cloud then updates the patient's health record and generates a service completion report. When all data confirmation nodes pass verification and the synchronization completion rate reaches the target value, the data synchronization task for this nursing service is completed. The cloud then aggregates the synchronized nursing record data, updates the patient's health record and service record, and completes the entire cloud-edge collaborative management process for home care services.

[0067] To implement the cloud-edge collaborative management method for home care services corresponding to the above method embodiments, and to achieve the corresponding functions and technical effects. See also Figure 2 , Figure 2 This diagram illustrates a structural block diagram of a cloud-edge collaborative management system 200 for home care services provided in an embodiment of this application. For ease of explanation, only the parts relevant to this embodiment are shown. The cloud-edge collaborative management system 200 for home care services provided in this embodiment includes: The data receiving module 201 is used to acquire nursing service request data uploaded by edge nodes, perform message integrity verification on the nursing service request data to identify abnormal data segments, and retransmit and encapsulate the abnormal data segments according to their urgency and priority to form a service request data frame. The routing distribution module 202 is used to perform cloud resource routing matching based on the service request data frame to form a dispatch route configuration, perform proximity-weighted filtering on the dispatch route configuration to extract target service nodes, and construct a downlink push channel through the target service nodes; Edge caching module 203 is used to perform edge caching mapping on the downlink push channel to form a local task image, execute offline services to generate nursing record data based on the local task image, and perform incremental marking on the nursing record data to generate data packets to be synchronized. The breakpoint resume module 204 is used to detect the link connectivity of the data packet to be synchronized, identify the synchronization interruption characteristics, activate the breakpoint resume strategy based on the synchronization interruption characteristics to form a resume offset parameter, and use the resume offset parameter to perform incremental difference extraction on the nursing record data to construct a consistency recovery configuration. The synchronization confirmation module 205 is used to poll the service status based on the consistency recovery configuration to form a synchronization completion curve, perform end-to-end latency assessment on the synchronization completion curve to determine the data confirmation node, and perform bidirectional response verification according to the data confirmation node to complete the cloud-edge collaborative management of home care services.

[0068] The aforementioned home care service cloud-edge collaborative management system 200 can implement a home care service cloud-edge collaborative management method according to the above method embodiments. The options in the above method embodiments are also applicable to this embodiment, and will not be detailed here. The remaining content of this application embodiment can be referred to the content of the above method embodiments, and will not be repeated in this embodiment.

[0069] The above embodiments are not an exhaustive list based on the present invention, and there may be many other embodiments not listed. Any substitutions and improvements made without departing from the concept of the present invention are within the protection scope of the present invention.

Claims

1. A cloud-edge collaborative management method for home care services, characterized in that, include: Obtain nursing service request data uploaded by edge nodes, perform message integrity verification on the nursing service request data to identify abnormal data segments, and retransmit and encapsulate the abnormal data segments according to their urgency and priority to form a service request data frame. Based on the service request data frame, cloud resource routing is matched to form a dispatch route configuration. The dispatch route configuration is then subjected to proximity-weighted filtering to extract target service nodes. Downlink push channels are then constructed through the target service nodes. The downlink push channel is edge-cached and mapped to form a local task image. Offline services are executed based on the local task image to generate nursing record data. Incremental marking is applied to the nursing record data to generate data packets to be synchronized. The link connectivity detection is performed on the data packets to be synchronized to identify synchronization interruption characteristics. Based on the synchronization interruption characteristics, the breakpoint resume strategy is activated to form a resume offset parameter. The resume offset parameter is used to perform incremental difference extraction on the nursing record data to construct a consistency recovery configuration. Based on the consistency recovery configuration, service status is polled to form a synchronization completion curve. End-to-end latency assessment is performed on the synchronization completion curve to determine the data confirmation node. Based on the data confirmation node, two-way response verification is performed to complete the cloud-edge collaborative management of home care services.

2. The method according to claim 1, characterized in that, The step of retransmitting and encapsulating the abnormal data segment according to its urgency priority to form a service request data frame includes: The missing field index is obtained by locating the abnormal position of the abnormal data segment. Based on the missing field index, perform an urgency field correlation analysis to extract the service urgency level; The service urgency level and the missing field index are used to form a retransmission priority identifier by priority encoding. The abnormal data segment is encapsulated into a service request data frame based on the retransmission priority identifier.

3. The method according to claim 1, characterized in that, The step of implementing proximity-based weighted filtering to extract target service nodes in the dispatch routing configuration includes: Extract the set of geographical coordinates of nursing staff and the location of the service target from the dispatch routing configuration; The distance between the set of geographical coordinates of the nursing staff and the location of the service target is quantified to generate a distance weight matrix; The distance weight matrix is ​​subjected to load-aware weighted fusion to form a comprehensive scoring sequence; The optimal node is selected based on the comprehensive scoring sequence to determine the target service node.

4. The method according to claim 1, characterized in that, The process of generating nursing record data by executing offline services based on the local task image includes: Parse the nursing task list from the local task mirror; Based on the nursing task list, abnormal vital signs are detected and vital sign status markers are generated; The vital sign status markers are associated with the local task image to form an emergency care entry; The urgent care items are prioritized and persistently stored to form care record data.

5. The method according to claim 1, characterized in that, The method for generating the resume transmission offset parameter based on the synchronous interruption feature activation breakpoint resume transmission strategy includes: The interruption time is located and the breakpoint location identifier is obtained by analyzing the synchronous interruption feature. Based on the breakpoint location identifier, query the urgency of the data to be transmitted and generate an urgency priority sequence; The urgency priority sequence is sorted by priority to form a priority transmission queue; The priority transmission queue is subjected to a resume offset analysis to generate resume offset parameters.

6. The method according to claim 1, characterized in that, The step of using the continued offset parameter to perform incremental difference extraction on the nursing record data to construct a consistency restoration configuration includes: The unsynchronized segment of the nursing record data is located based on the resume offset parameter; Conflict pre-detection analysis is performed on the unsynchronized segments to generate conflict risk identifiers; The conflict risk identifiers are used to filter and identify conflict-free data blocks in safe zones. An incremental update queue is constructed based on the conflict-free differential data blocks to form a consistent recovery configuration.

7. The method according to claim 1, characterized in that, The process of performing end-to-end latency assessment on the synchronization completion curve to determine the data confirmation node includes: Extract the transmission timestamps for each stage from the synchronization completion curve; Segmented delay analysis is performed based on the transmission timestamps of each stage to obtain the delay distribution; The time delay distribution is subjected to fluctuation characteristic analysis to generate an adaptive time delay threshold; The data confirmation node is determined by comparing the adaptive latency threshold with the latency distribution.

8. The method according to claim 3, characterized in that, The process of applying load-aware weighted fusion to the distance weight matrix to form a comprehensive scoring sequence includes: Extract the candidate nursing staff identifier set from the distance weight matrix; Based on the candidate nurse identifier set, query the current task load to obtain the load saturation; The load saturation is evaluated for service idleness to generate a load matching score; The load matching score is weighted and fused with the distance weight matrix to form a comprehensive scoring sequence.

9. The method according to claim 6, characterized in that, The step of generating conflict risk identifiers by performing conflict pre-detection analysis on the unsynchronized segments includes: The unsynchronized segments are classified and divided into hierarchical data block sequences based on their importance. Perform differential verification on the hierarchical data block sequence according to its importance level to generate hierarchical verification values; The hierarchical check values ​​are concatenated and encoded in priority order to form a hierarchical check chain; The hierarchical verification chain is aggregated in a lightweight manner to generate conflict risk identifiers.

10. A cloud-edge collaborative management system for home care services, characterized in that, include: The data receiving module is used to acquire nursing service request data uploaded by edge nodes, perform message integrity verification on the nursing service request data to identify abnormal data segments, and retransmit and encapsulate the abnormal data segments according to their urgency and priority to form a service request data frame. The routing distribution module is used to perform cloud resource routing matching based on the service request data frame to form a dispatch route configuration, perform proximity-weighted filtering on the dispatch route configuration to extract target service nodes, and construct a downlink push channel through the target service nodes. The edge caching module is used to map the downlink push channel to the edge cache to form a local task image, execute offline services to generate nursing record data based on the local task image, and implement incremental marking on the nursing record data to generate data packets to be synchronized. The breakpoint resume module is used to detect the link connectivity of the data packet to be synchronized, identify the synchronization interruption characteristics, activate the breakpoint resume strategy based on the synchronization interruption characteristics to form a resume offset parameter, and use the resume offset parameter to perform incremental difference extraction on the nursing record data to construct a consistency recovery configuration. The synchronization confirmation module is used to poll the service status based on the consistency recovery configuration to form a synchronization completion curve, perform end-to-end latency assessment on the synchronization completion curve to determine the data confirmation node, and perform bidirectional response verification based on the data confirmation node to complete the cloud-edge collaborative management of home care services.

Images