Cloud data synchronization method for diabetes management

Abstract

The invention relates to the technical field of cloud data synchronization, in particular to a diabetes management-oriented cloud data synchronization method, which comprises the following steps: based on a blood glucose monitoring record, unifying a time zone and verifying a device serial number, generating a terminal version identifier, comparing a cloud version to screen missing entries, and identifying time abnormality and a device source. And forming a version difference mark, judging a missing range and a conflict identifier, updating a synchronization state after sorting, and counting the number of synchronization entries. According to the method, the problems of additional recording of historical data and version conflicts in data synchronization are effectively solved by introducing a dynamic rollback mechanism and timestamp difference comparison, clock differences between devices are automatically detected and adjusted in the synchronization process, timely updating and consistency of data are ensured, invalid synchronization operations are reduced through an intelligent conflict resolution mechanism, and the synchronization efficiency is improved. The accuracy and timeliness of data in diabetes management are ensured, and the data stability and consistency in a multi-terminal environment are improved.

Description

Technical Field

[0001] This invention relates to the field of cloud data synchronization technology, and in particular to a cloud data synchronization method for diabetes management. Background Technology

[0002] Cloud data synchronization technology involves techniques for exchanging and maintaining data consistency between different computing nodes via a network environment. This includes data acquisition from terminal devices, communication link establishment, data encapsulation and transmission, server storage management, and data consistency control between multiple terminals. It is widely used in scenarios such as healthcare, remote monitoring, and smart wearable devices, emphasizing data sharing and continuous updates across devices. Traditional cloud data synchronization methods for diabetes management refer to methods that exchange data such as blood glucose monitoring data, insulin injection records, dietary intake information, and exercise expenditure data between patient terminal devices and remote medical servers.

[0003] Existing technologies rely on static timestamp comparison and version control, lacking flexible responses to data synchronization delays and historical data supplementation in multi-terminal environments. They fail to effectively resolve data conflicts caused by clock differences between devices or network instability, especially in the transmission of important health data such as blood glucose monitoring data and insulin injection records, where untimely synchronization or failure to promptly supplement historical data is likely to occur. Furthermore, existing solutions are limited to version number comparison when handling data version conflicts, failing to handle dynamic changes that occur during data updates, thus affecting the consistency and stability of cloud data. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a cloud-based data synchronization method for diabetes management.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a cloud data synchronization method for diabetes management, comprising the following steps:

[0006] S1: Based on blood glucose monitoring record entries, analyze the time field and device serial number, adjust the time to a unified time zone format, compare the device serial number with entries in the local registry, filter out matching entries, calculate and register the entry summary to the version field, and obtain the terminal version sequence identifier;

[0007] S2: Based on the terminal version sequence identifier, compare the version field with the version field under the same user identifier in the cloud, identify missing version field entries, determine whether there is an abnormal collection time sequence, analyze the device source of the abnormal identifier, calculate the number of missing entries, and obtain the version difference marker.

[0008] S3: Based on the version difference marker, analyze the entry record time, compare the terminal time with the NTP server time, determine the terminal clock drift status, adjust and synchronize the terminal time base, and obtain the time synchronization calibration coefficient.

[0009] S4: Based on the time synchronization calibration coefficient, filter the associated data segment numbers, compare the collection time order of terminal entries and cloud entries, determine the time order difference, and analyze the range of missing entries corresponding to the difference to obtain the data segment rollback trigger index.

[0010] S5: Based on the data segment rollback trigger indicator, compare the version field with the cloud version, determine the version conflict identifier from multiple devices, identify conflict entries and sort them by collection time, adjust the entry status to synchronous submission, and obtain the number of synchronous data entries.

[0011] The present invention improves upon this invention by including the following: the terminal version sequence identifier includes a time identifier, a device identifier, and a version number identifier; the version difference marker includes the missing entry type, time sequence anomaly identifier, device serial number difference, and total number of missing entries; the time synchronization calibration coefficient includes clock drift, synchronization delay, and reference adjustment identifier; the data segment rollback trigger indicator includes time sequence difference, missing entry range, and rollback operation trigger condition; and the number of synchronized data entries includes the number of conflicting entries, version synchronization status, and synchronization confirmation identifier.

[0012] The present invention is improved in that the step of obtaining the terminal version sequence identifier is specifically as follows:

[0013] S111: Based on the blood glucose monitoring record entries, obtain the record time field, adjust it to a unified time zone UTC timestamp representation, compare the device serial number with the serial number registered in the local device registry, identify registered matching entries, determine and remove unregistered entries, and obtain a set of registered matching entries;

[0014] S112: Based on the registered matching entry set, analyze the combination relationship of entry fields, adjust the field order to a fixed concatenation sequence, calculate the entry digest code, register it to the version field, compare the digest code length with the version field format requirements, determine and remove inconsistent entries, and obtain the entry content digest code;

[0015] S113: Based on the entry content digest code, analyze the time order of the associated entries, adjust the entry sorting to ascending order of collection time, compare the consistency of the device serial number and the time index association, determine the association gap and fill in the index mapping, and then calculate the version number increment sequence to obtain the terminal version sequence identifier.

[0016] The present invention is improved in that the step of obtaining the version difference marker is specifically as follows:

[0017] S211: Based on the terminal version sequence identifier, retrieve the version field under the same user identity in the cloud, compare the version number with the version field record, filter the corresponding entries that do not match the version number, determine the integrity of the association between the entry primary key and the collection time field, determine the index of unmatched entries, and obtain the cloud missing entry index set;

[0018] S212: Based on the cloud-based missing entry index set, retrieve the index entry collection time series, compare the adjacent collection time order with the registration order, determine the reverse order entries and skipped order entries, determine the serial number of the abnormal entry source device, and obtain time order abnormal mapping data;

[0019] S213: Based on the time-series anomaly mapping data, count the number of anomaly entries, verify the total number of entries in the cloud-based missing entry index set, determine the consistency of the missing entry type classification, analyze the device serial number difference entries, mark the difference type, and obtain the version difference marker.

[0020] The present invention is improved in that the step of obtaining the time synchronization calibration coefficient is specifically as follows:

[0021] S311: Based on the version difference marker, analyze the corresponding entry record time field associated with it, compare the terminal time with the network time protocol server UTC timestamp, calculate the time difference to form a time offset, determine the continuity of the offset in the time series, and obtain the clock drift determination amount.

[0022] S312: Determine the changing trend of the clock drift determination quantity, calculate the absolute amount of each time offset within the sampling window, summarize to form an offset aggregation quantity, and compare the drift direction of the terminal time difference to obtain the time base correction mark.

[0023] S313: Based on the time base correction mark, calculate the normalized terms of the absolute value of the residual term and the offset aggregation term, compare the one-way delay estimate with the time sampling interval, adjust the terminal time base mark, and obtain the time synchronization calibration coefficient.

[0024] The present invention is improved in that the specific steps for obtaining the data segment rollback trigger indicator are as follows:

[0025] S411: Based on the time synchronization calibration coefficient, analyze the numbering of continuous blood glucose monitoring data segments, filter the data segments to which the associated entries belong, compare the consistency of the numbers of terminal entries and cloud entries, calculate the correspondence of the numbers, and obtain the sequential comparison index sequence.

[0026] S412: Based on the sequential comparison index sequence, calculate the terminal acquisition time difference and the cloud acquisition time difference at the corresponding positions, compare the deviation of the entry number difference, and adjust the segment span and entry size using the formula:

[0027] ;

[0028] Obtain the interval difference measurement coefficient ,in, This refers to the number of items included in the comparison. Refers to the first Collection time for each terminal entry Refers to the first The collection time of each cloud entry This refers to the time span of a data segment, used to normalize the time difference between data collection points. Refers to the first The difference in entry numbers at each location, This refers to the total number of entries in the data segment, used to normalize the entry size based on the difference in entry numbers. This refers to the number of missing entries;

[0029] S413: Determine the corresponding position of the interval difference measurement coefficient in the data segment number sequence, analyze the start and end numbers and span of the missing entry interval set, identify the range of data segment numbers that can be rolled back, adjust the rollback association relationship, and obtain the data segment rollback trigger index.

[0030] The present invention is improved in that the step of obtaining the number of synchronized data entries is specifically as follows:

[0031] S511: Based on the data segment rollback trigger index, obtain the associated entry version sequence, retrieve the corresponding user version record in the cloud, compare the version number identifier with the device serial number source, filter different device entries of the same version, determine the conflict relationship of device serial number source, and obtain version source conflict information.

[0032] S512: Based on the version source conflict information, analyze the collection time field, compare the collection time order of entries of the same version, determine the time order conflict entries, filter the conflict entries to form a time sorting sequence, adjust the entry status mark to synchronous submission status, and obtain the submitted conflict entry sequence.

[0033] S513: Based on the submitted conflict entry sequence, count the number of entries, compare the consistency between the entry version number identifier classification summary result and the entry status marker, determine the entries with inconsistent status and remove them, then adjust the correspondence between the version number identifier and the entry count to obtain the number of synchronized data entries.

[0034] The present invention is improved in that the device serial number refers to the unique identification code of the blood glucose meter or monitoring device, the user identifier refers to the unique identifier of the patient or user to distinguish the data of different users, and the missing version field refers to the situation where the data version field in the cloud database is missing or not updated.

[0035] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0036] This invention effectively solves the problems of historical data supplementation and version conflict in data synchronization by introducing a dynamic rollback mechanism and timestamp difference comparison. The dynamic rollback strategy automatically detects and adjusts the clock differences between devices during the synchronization process to ensure timely data updates and consistency, avoiding the loss of historical data due to device synchronization delays or network interruptions. Each data segment is managed and rolled back separately. Through an intelligent conflict resolution mechanism, invalid synchronization operations are reduced, ensuring the accuracy and timeliness of data in diabetes management and improving data stability and consistency in multi-terminal environments. Attached Figure Description

[0037] Figure 1 This is a flowchart of the main steps of the present invention;

[0038] Figure 2 This is a flowchart illustrating the process of obtaining the terminal version sequence identifier in this invention.

[0039] Figure 3 This is a flowchart illustrating the process of obtaining version difference markers in this invention.

[0040] Figure 4 This is a flowchart illustrating the process of obtaining the time synchronization calibration coefficient in this invention.

[0041] Figure 5 This is a flowchart illustrating the process of obtaining the data segment rollback trigger indicator in this invention.

[0042] Figure 6 This is a flowchart illustrating the process of obtaining the number of synchronized data entries in this invention. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0044] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0045] All user-related information involved in this invention (including but not limited to biometric information, identity verification information, behavioral data, device information, and other data that can be used for identity verification and personalized services) is collected and processed with the user's full knowledge and voluntary consent. The use of data is limited to purposes necessary for providing the technical services of this invention, and reasonable technical and management measures will be taken to ensure the security and confidentiality of users' personal information in terms of information protection and privacy.

[0046] Example

[0047] Please see Figure 1 This invention provides a technical solution, a cloud-based data synchronization method for diabetes management, comprising the following steps:

[0048] S1: Based on the blood glucose monitoring record entries, analyze the recording time and device serial number, adjust the recording time to a unified time zone representation, compare the device serial number with the local device registry entries, filter entries that match the registry entries, calculate the entry content summary and register it in the version field to obtain the terminal version sequence identifier;

[0049] S2: Based on the terminal version sequence identifier, compare the version field with the version field under the same user identity in the cloud, filter the entries corresponding to the missing version field in the cloud, determine the abnormal entry collection time sequence identifier, analyze the serial number of the device from which the abnormal identifier entries are sourced, calculate the number of missing entries, and obtain the version difference marker;

[0050] S3: Based on the version difference marker, analyze the time field of the corresponding entry record, compare the terminal time with the network time protocol server UTC time, determine the terminal clock drift status, adjust the terminal time reference marker, and perform synchronization alignment to obtain the time synchronization calibration coefficient.

[0051] S4: Based on the time synchronization calibration coefficient, filter the continuous blood glucose monitoring data segment number to which the associated item belongs, compare the terminal item collection time order with the cloud item collection time order under the number, determine the time order difference, and analyze the range of missing items corresponding to the difference to obtain the data segment rollback trigger index.

[0052] S5: Based on the data segment rollback trigger indicator, compare the version of the associated entry with the version in the cloud, determine the serial number conflict identifier of the same version from multiple sources, identify the conflict identifier entries and sort them according to the collection time, adjust the entry status mark to synchronous submission status, and obtain the number of synchronous data entries.

[0053] The terminal version sequence identifier includes a time identifier, a device identifier, and a version number identifier. The version difference marker includes the missing entry type, time sequence anomaly identifier, device serial number difference, and total number of missing entries. The time synchronization calibration coefficient includes clock drift, synchronization delay, and reference adjustment identifier. The data segment rollback trigger indicator includes time sequence difference, missing entry range, and rollback operation trigger condition. The number of synchronized data entries includes the number of conflicting entries, version synchronization status, and synchronization confirmation identifier.

[0054] In S1: Recording time refers to the timestamp in the blood glucose monitoring entry, indicating the time the record was collected; Device serial number refers to the unique identifier of the device (such as a blood glucose meter or monitoring device), used to identify the device; Local device registry entry refers to the registration information on the user's device, including the device serial number and related identifiers, used for comparison and matching when synchronizing the local device with the cloud; Matching entry refers to finding the data entry in the local device that matches the record in the cloud when synchronizing data between the local device and the cloud; Version field refers to the version number included in each data entry, indicating the version information of the data, used to track and manage updates and conflicts during the data synchronization process.

[0055] In S2: User Identifier refers to a unique identifier for a patient or user, used to distinguish data from different users and ensure the correct attribution of data; Missing Version Field refers to the situation where certain data version fields in the cloud database are missing or not updated, which means that some data has not been correctly synchronized or updated; Collection Time Sequence Anomaly Identifier refers to the time sequence error detected during the synchronization process, such as in blood glucose monitoring entries, the order of timestamps does not conform to the expected collection order; Missing Entries Count refers to the number of entries that are missing or failed to be synchronized during the synchronization process, which is usually related to the missing version field.

[0056] In S3: Corresponding entries refer to the matching data entries that should be synchronized between the terminal device and the cloud during the data synchronization process; Terminal time refers to the system time of the terminal device (such as a smartphone or blood glucose meter), used for comparison with Network Time Protocol (NTP) time; Terminal clock drift status refers to the deviation or drift between the terminal device's time and the standard time, which may be caused by inaccurate device clock or synchronization problems; Time reference mark refers to the reference time point or identifier used to adjust and synchronize the device time, used to correct the terminal device time; Synchronization alignment refers to adjusting and synchronizing the deviation between the terminal device time and the standard time or cloud time to keep them consistent.

[0057] In S4: Associated entries refer to entries that require time synchronization and rollback processing, and are associated with specific data segments (such as blood glucose data segments); Continuous blood glucose monitoring data segments refer to data blocks consisting of a series of continuous blood glucose monitoring records, which are used to analyze changes in the patient's blood glucose; Terminal entry collection time order refers to the time order in which entries are recorded by the terminal device during data collection; Cloud entry collection time order refers to the way blood glucose data entries stored in the cloud are arranged in chronological order; Missing entry range refers to the time range of blood glucose monitoring data entries that failed to synchronize between the cloud and the terminal device due to synchronization problems or delays.

[0058] In S5: Multi-source devices refer to multiple different devices (such as different models of blood glucose meters or smart bracelets) uploading data at the same time, which may lead to data conflicts; Conflict identifier refers to the data conflict identifier detected during the data synchronization process, such as different devices uploading the same data or having version conflicts; Synchronization commit status refers to the status of data entries marked as successfully synchronized after the data synchronization process is completed, which usually indicates that the entry has been successfully uploaded and updated to the cloud.

[0059] Please see Figure 2 The specific steps for obtaining the terminal version sequence identifier are as follows:

[0060] S111: Based on the blood glucose monitoring record entries, obtain the record time field, adjust it to a unified time zone UTC timestamp representation, compare the device serial number with the serial number registered in the local device registry, identify registered matching entries, determine and remove unregistered entries, and obtain a set of registered matching entries;

[0061] Blood glucose monitoring records are stored in the terminal database in a record-by-record structure. Each record stores the collection time and device serial number. First, the local time value of a record is read, for example, February 20, 2023, 08:15:30. Simultaneously, the time zone offset value set by the terminal system is read. If it's displayed as East 8th time zone, the offset value is 8 hours. Subtracting 8 hours from 08:15:30 gives 00:15:30. This time is then converted to the cumulative number of seconds since January 1, 1970, for example, 1676852130 seconds. This value is written back to the record time field, replacing the original value. Next, the device serial number in that record is read, for example, BG2024020015. The list of registered serial numbers is read from the local device registry. The registration list has three numbers: BG2024020015, BG2024019988, and CGM2023123001. The current record serial number is compared character by character with each number in the list. A match is considered to be made only if the number of characters is the same and every character is completely identical. If they match, the record is added to the matching cache. If they do not match after three consecutive comparisons, the record is considered unregistered and is immediately deleted from the cache. For example, if the serial number BG2024999999 is detected, it is deleted because it is not in the list. Assuming there are 10 original records, after comparison, 8 records are retained, forming a record set containing only the source data of the registered device. Each record undergoes time unification processing and device legality verification to obtain the set of registered matching entries.

[0062] S112: Based on the registered matching entry set, analyze the combination relationship of entry fields, adjust the field order to a fixed concatenation sequence, calculate the entry digest code, register it to the version field, compare the digest code length with the version field format requirements, determine and remove entries that do not match, and obtain the entry content digest code;

[0063] For each record in the registered matching entry set, a field rearrangement operation is performed. The device serial number, unified time (in seconds), blood glucose level, and battery level are read. The device serial number is placed in a preset order, followed by the time (in seconds), then the blood glucose level, and finally the battery level. These four segments are connected with "|" to form a fixed concatenation string, such as "BG2024020015|1708388130|6.8|85". The number of characters in this string is then counted; for example, if the result is 31 characters, the encoded value is read character by character and accumulated. For example, if the accumulated value is 1769, this value is then compared with... The remainder of 100000 is taken as 2456. This value is then converted into an 8-bit string, with leading zeros added to form 00002456. This 8-bit string is written into the version field of the record. The length of the version field is then read. Assuming the version field length is fixed at 8 bits, if the length is 8, the record is retained; if the length is 7 or 9, the record is deleted. For example, if a record generates the result 1234567, it will be deleted because the length is 7. Assuming that one of the 8 records is deleted due to a length mismatch, the remaining 7 records will all obtain a fixed-length digest value, which is then written into the version field to obtain the entry content digest code.

[0064] S113: Based on the item content digest code, analyze the time order of related items, adjust the item sorting to ascending order of collection time, compare the consistency of the association between the device serial number and the time index, identify the association gap and fill in the index mapping, and then calculate the version number increment sequence to obtain the terminal version sequence identifier;

[0065] For the 7 records with digest codes, their uniform time (in seconds) arrays are read, such as 1708388130, 1708388190, 1708388250, 1708388310, 1708388370, 1708388430, and 1708388490. Adjacent items are compared one by one in ascending order. If the preceding value is greater than the following value, their positions are swapped. After ascending sorting, a continuous time series is formed. Then, time index numbers 1 to 7 are generated for each record based on the sorting result. Next, the time difference is checked, and the difference in seconds between two adjacent records is calculated. For example, if the difference between the first and second records is 60 seconds, and the difference between the second and third records is also 60 seconds, if the difference between any two records is found to be greater than 60 seconds, it is compared with the preset sampling interval of 60 seconds. The number of missing records is calculated as (difference ÷ 60 - ...). 1) For example, if the difference between two records is 120 seconds, it is determined that one record is missing, and a blank index number is inserted at the corresponding index position to place it. For example, if the original numbers are 1, 2, 4, 5, 6, 7, then number 3 is inserted and marked as a null record. Then, based on the total number of sorted records, incremental version numbers 1 to N are regenerated. Each version number is combined with the corresponding time value and device serial number. For example, the first record corresponds to version number 1, the second record corresponds to version number 2, and so on, up to N, to form a sequence array structure containing time identifier, device identifier, and version number, thus obtaining the terminal version sequence identifier.

[0066] Please see Figure 3 The specific steps for obtaining version difference markers are as follows:

[0067] S211: Based on the terminal version sequence identifier, retrieve the version field under the same user identity in the cloud, compare the version number with the version field record, filter the corresponding entries that do not match the version number, determine the integrity of the association between the primary key of the entry and the collection time field, determine the index of the missing entries, and obtain the cloud missing entry index set;

[0068] The terminal side has formed a version sequence structure array consisting of a time stamp, a device identifier, and an incrementing number. First, it reads the current user's identity identifier, for example, user number U20260201. It retrieves the data table record corresponding to this user number from the cloud database, extracts all version fields from this table to form a cloud version list. For example, the cloud already has a version number set {1, 2, 3, 5, 6}. Then, it reads the version number set {1, 2, 3, 4, 5, 6, 7} uploaded by the terminal, and performs a value comparison operation on each item. It compares the terminal version number 1 with each item in the cloud list. When an equal value is found, it is marked as a match. If no equal value is found after scanning each item, it is marked as a mismatch. For example, if terminal number 4 does not exist in the cloud set, it is marked as a mismatch; similarly, if number 7 does not exist, it is marked as a mismatch. The mismatched numbers are written to a temporary array Index_miss={4, 7}. Then, the primary key value and collection time field of the corresponding numbered entry are read. For example, number 4 corresponds to primary key PK004 and time 1708388310, and number 7 corresponds to primary key PK007 and time 1708388490. The cloud table is searched to see if there is a record with a primary key value equal to PK004. If it does not exist, it is recorded as a primary key missing type. If the primary key exists but the time field is inconsistent, it is recorded as a time inconsistency type. For example, assuming PK007 exists but the time record is 1708388500, which is 10 seconds different from the terminal time, the time error threshold is set to 30 seconds. When the time difference is less than or equal to 30 seconds, it is determined to be a record within the acceptable time range. If the time difference is greater than 30 seconds, it is determined to be an incomplete association. The numbers with no primary key or time difference exceeding the threshold are confirmed and written into the cloud missing index array. For example, the confirmed index is {4}, thus obtaining the cloud missing entry index set.

[0069] S212: Based on the cloud-based missing entry index set, retrieve the index entry collection time series, compare the adjacent collection time order with the registration order, determine the reverse order entries and skip order entries, determine the serial number of the source device of the abnormal entry, and obtain the time order abnormal mapping data;

[0070] Read the IDs from the missing entry index set in the cloud, for example, {4, 7}. Retrieve the corresponding terminal's time collection array based on the ID; for example, ID 4's time is 1708388310, and ID 7's time is 1708388490. Simultaneously, retrieve the user's complete time series array {1708388130, 1708388190, 1708388250, 1708388310, 1708388370, 1708388430, 1708388490}. Calculate the difference between adjacent times one by one; for example, subtracting 1708388130 from 1708388190 gives 60 seconds. Calculate the difference for each segment sequentially. When a segment with a difference of 120 seconds is found, record it as a candidate segment for skipping order. Set the standard sampling interval to 60 seconds and the skipping order judgment threshold to twice the standard interval, i.e., 1. 20 seconds. When the difference is equal to or greater than 120 seconds, it is marked as a skip entry. When the next time value is less than the previous time value, it is marked as a reverse entry. For example, if 1708388430 appears and then 1708388370 appears, it is determined to be reversed. Then, the serial number field of the device corresponding to the abnormal entry is read. For example, number 7 corresponds to device BG2024020015. If multiple abnormal entries come from the same device, the correspondence between the device number and the abnormal number is recorded in the mapping table. For example, the mapping data {BG2024020015: [7], BG2024019988: [4]} is formed. When a number has both skip and reverse situations, the reverse identifier is recorded first, and then the skip identifier is added to generate the time sequence abnormal number and device serial number correspondence table structure data, and the time sequence abnormal mapping data is obtained.

[0071] S213: Based on the time-series anomaly mapping data, count the number of anomaly entries, verify the total number of entries in the cloud missing entry index set, determine the consistency of the missing entry type classification, analyze the device serial number difference entries, mark the difference type, and obtain the version difference tag;

[0072] Read the time-series anomaly mapping data. For example, if there are 2 anomaly IDs in the mapping, and also read the cloud missing entry index set, which contains 2 entries, compare the anomaly entry count (2) with the missing index count (2). If they are equal, mark them as consistent; otherwise, mark them as inconsistent. For example, if the anomaly count is 3 and the missing count is 2, record 1 difference. Then, for each anomaly ID, read its device serial number. For example, ID 4 originates from BG2024019988, and ID 7 originates from BG2024020015. Compare the device serial numbers character by character. If the source device of the ID matches the terminal... If the device numbers are the same, they are marked as same-source difference type. If the source devices are different, they are marked as multi-source difference type. For example, if the terminal master device is BG2024020015, then number 7 is marked as same-source anomaly, and number 4 is marked as multi-source anomaly. Then, the missing type field is assigned the value of time reverse order type, skip order type, or primary key missing type, and the device difference identifier is attached. For example, the structure record {number 4, type skip order, device multi-source} and {number 7, type primary key missing, device same-source} are formed. The anomaly count, total number of missing items, and device difference type are combined and written into the version difference field record area to obtain the version difference mark.

[0073] Please see Figure 4 The specific steps for obtaining the time synchronization calibration coefficient are as follows:

[0074] S311: Based on the version difference marker, analyze the time field of the corresponding entry record associated with it, compare the terminal time with the network time protocol server UTC timestamp, calculate the time difference to form the time offset, determine the continuity of the offset in the time series, and obtain the clock drift determination quantity.

[0075] Read the anomaly entry numbers from the difference markers, such as numbers 4 and 7, and retrieve their terminal-side unified time (in seconds). For example, number 4's time is 1708388310, and number 7's time is 1708388490. Simultaneously, send a time request to the Network Time Protocol (NTP) server and receive the UTC time (in seconds) values ​​returned by the server. For example, the current server time is 1708388300 and 1708388480. Then, perform a numerical operation to subtract the server time from the terminal time for each anomaly record. For example, the time difference corresponding to number 4 is 1708388310 minus 1708388300, which equals 10 seconds. The time difference corresponding to number 7 is 1708388490 minus 1708388480, which also equals 10 seconds. This difference is recorded in the time offset record array Offset_list={10, 10}. Then, the time offset judgment threshold is set to ±5 seconds. When the absolute value of the difference is less than or equal to 5 seconds, it is judged as a normal fluctuation range. When the difference is greater than 5 seconds and less than or equal to 30 seconds, it is judged as a mild fluctuation. The offset interval is defined as follows: a difference greater than 30 seconds is considered a severe offset interval. In this example, a difference of 10 seconds falls within the 5-30 second range and is marked as a mild offset. Then, the offsets of three consecutive records in the time series are read (e.g., the first is 8 seconds, this one is 10 seconds, and the next is 12 seconds). The three offset values ​​are arranged chronologically, and the differences between adjacent values ​​are compared one by one. For example, 10 minus 8 equals 2 seconds, and 12 minus 10 equals 2 seconds. If the change in adjacent differences is less than or equal to 3 seconds, it is marked as a continuous change. If the change... If the time exceeds 10 seconds, it is marked as a jump state. In the example, the change value is 2 seconds, which is judged as continuous change. The ratio of the number of continuous change entries to the total number of abnormal entries is calculated. For example, if there are 2 consecutive changes, the ratio is 100%. The continuous ratio judgment benchmark is set to 70%. When the ratio is greater than or equal to 70%, it is judged that there is a continuous drift phenomenon. Finally, the average value of the continuous offset amplitude is calculated as (8+10+12) / 3 to get 10 seconds. This value is recorded as the clock drift judgment quantity.

[0076] S312: Determine the changing trend of the clock drift determination quantity, calculate the absolute amount of each time offset within the sampling window, summarize to form the offset aggregation quantity, and compare the drift direction of the terminal time difference to obtain the time base correction mark.

[0077] Read the clock drift determination array. For example, if the offset values ​​for five consecutive samples are 8 seconds, 10 seconds, 12 seconds, 14 seconds, and 16 seconds, arrange them in chronological order and calculate the difference between adjacent values ​​one by one. For example, 10 minus 8 equals 2 seconds, 12 minus 10 equals 2 seconds, 14 minus 12 equals 2 seconds, and 16 minus 14 equals 2 seconds. When the consecutive differences are positive, mark it as a positive drift direction; when the consecutive differences are negative, mark it as a negative drift direction. In this example, all differences are positive, so it is recorded as a positive drift. Then, with the sampling window set to 5 records, take the absolute value of the five offsets and sum them up to get 8 + 10 + 12 + 14 + 16 equals 60 seconds. Divide the sum by the number of samples, 5, to get the average offset. The average value is measured over 12 seconds. This average value is compared with a time correction threshold of 15 seconds. When the average offset is less than 15 seconds, it is marked as a slight correction. When the average offset is greater than or equal to 15 seconds but less than 30 seconds, it is marked as a moderate correction. When the average offset is greater than or equal to 30 seconds, it is marked as a forced correction. In this example, 12 seconds is less than 15 seconds and is marked as a slight correction. Combined with the fact that the drift direction is positive, the time base correction identifier field is generated as "positive + slight". If the average value in subsequent consecutive windows reaches 18 seconds, it is marked as "positive + moderate". The system writes this correction identifier into the terminal time base control field to form a flag data structure, thus obtaining the time base correction flag.

[0078] S313: Based on the time base correction mark, calculate the normalized terms of the absolute value of the residual term and the offset aggregation, compare the one-way delay estimate with the time sampling interval, and adjust the terminal time base mark using the following formula:

[0079] ;

[0080] Obtain time synchronization calibration coefficient ,in, This refers to the time difference between the terminal time and the UTC timestamp of the Network Time Protocol server. This refers to the one-way delay estimate, representing the one-way transmission delay between the terminal and the Network Time Protocol (NTP) server. Refers to the first The time offset corresponding to each sample represents the time difference between the terminal time and the UTC timestamp in that sample. The number of samples indicates the total number of samples included in the summation. The time sampling interval refers to the time interval between two consecutive samples. The terminal reference time marker quantity represents the amount of reference time marker used for alignment on the terminal side. The UTC timestamp refers to the amount of UTC reference timestamp provided by the Network Time Protocol (NTP) server.

[0081] Time synchronization calibration coefficient The time synchronization deviation intensity index is obtained by superimposing the two normalized errors and then multiplying them by the square root of the ratio of a reference time. It characterizes the "comprehensive deviation between the terminal time and the UTC reference time under the constraints of delay compensation and multiple sampling offsets." Specifically, the residual deviation term includes: Meaning: Time difference between the terminal and UTC After deducting the one-way delay estimate The remaining amplitude after the first alignment reflects the remaining deviation; the average sampling offset term: The meaning is: within the sampling window, the average amplitude of the time offset obtained from multiple samples reflects the cumulative level of the offset within the sampling window; sampling interval normalization: the sum of the above two items is divided by... This means: scaling the error scale according to the sampling interval, so that results at different sampling intervals can be compared; reference time scaling term: The meaning is: using the terminal reference time as a marker quantity. Relative reference time scale The scaling factor is applied to the aforementioned normalization result to maintain a proportional relationship between the coefficients and the reference time. Therefore, The larger the value, the stronger the overall deviation between the terminal time and the UTC reference under the current sampling window and delay compensation conditions; The smaller the value, the weaker the overall deviation.

[0082] Around the time base correction mark, the time offset sequence, one-way delay estimate, number of samples, and time sampling interval are called into the calculation. First, interval linear normalization is performed on the time quantities involved. The normalization type adopts min-max normalization, which uses the smallest time quantity observed within the sampling window. With maximum time amount As the normalization interval, the normalization is as follows:

[0083] original Corresponding to normalization ;

[0084] original Corresponding to normalization ;

[0085] Original Corresponding to normalization ;

[0086] original Corresponding to normalization ;

[0087] original Corresponding to normalization ;

[0088] original Corresponding to normalization ;

[0089] Number of samples Substituting the above normalized values ​​into the formula:

[0090] calculate :

[0091] ;

[0092] calculate :

[0093] ;

[0094] ;

[0095] Calculate the fractional part:

[0096] ;

[0097] Calculate the square root part:

[0098] ;

[0099] calculate ;

[0100] Time synchronization calibration coefficient Define the rules for dividing continuous intervals as follows:

[0101] when When this is determined to be a "stable calibration section", it indicates that the normalized residual term is... With average offset term It falls within a low proportion range within the time sampling interval scale;

[0102] when When this is determined to be a "slightly drifted segment", it means that the proportion of the normalized composite offset within the sampling scale has increased;

[0103] when When the condition is met, it is determined to be a "moderate drift segment", indicating that the residual and cumulative offset terms have reached more than one-tenth of the sampling scale after normalization;

[0104] when When the interval is defined as a "significant drift segment", it indicates that the normalized composite offset accounts for a relatively high proportion of the sampling scale.

[0105] Calculated If the result falls into the "stable calibration section", it is used to determine the update magnitude level of the terminal time reference mark. In subsequent processing, the corresponding calibration execution intensity is selected according to the rules of the section to which it belongs.

[0106] Please see Figure 5 The specific steps for obtaining the data segment rollback trigger indicator are as follows:

[0107] S411: Based on the time synchronization calibration coefficient, analyze the numbering of continuous blood glucose monitoring data segments, filter the data segments to which the associated entries belong, compare the consistency of the numbers of terminal entries and cloud entries, calculate the correspondence of the numbers, and obtain the sequential comparison index sequence.

[0108] First, the correction value (e.g., positive 12 seconds) is read, and the data segment number field from the continuous blood glucose monitoring entries is retrieved to form a terminal-side segment number sequence, such as {101, 101, 101, 102, 102, 103, 103}. Simultaneously, the data segment number sequence for the same user is read from the cloud, such as {101, 101, 102, 102, 103, 103}. Then, 12 seconds are added to the time field of each terminal entry to form the corrected time value. The entries are then rearranged in ascending order according to the corrected time. Next, the unique terminal segment number values ​​(101, 102, 103) are extracted and compared with the unique segment numbers in the cloud. When the numbers match, a record is made. The segments are recorded as consistent. When a segment exists on the terminal but not on the cloud, it is recorded as a missing segment. Then, the number of entries in each segment is counted. For example, if there are 3 entries for segment 101 on the terminal and 2 entries for segment 101 on the cloud, the difference is calculated as 3 minus 2 equals 1. The segment difference threshold is set to 1. When the difference is less than or equal to 1, it is marked as a comparable segment. When the difference is greater than 1, it is marked as an abnormal segment. Then, an index is constructed within the terminal segment. For example, segment 101 corresponds to indexes 1 to 3, and segment 101 on the cloud corresponds to indexes 1 to 2. The unmatched index 3 is recorded separately, and all index correspondences are arranged in order of segment number to form a one-to-one correspondence table structure data between segment number and entry index, resulting in a sequential comparison index sequence.

[0109] S412: Based on the sequential comparison index sequence, calculate the terminal acquisition time difference and the cloud acquisition time difference at the corresponding positions, compare the deviation of the entry number difference, and adjust the segment span and entry size using the formula:

[0110] ;

[0111] Obtain the interval difference measurement coefficient ,in, This refers to the number of items included in the comparison. Refers to the first Collection time for each terminal entry Refers to the first The collection time of each cloud entry This refers to the time span of a data segment, used to normalize the time difference between data collection points. Refers to the first The difference in entry numbers at each location, This refers to the total number of entries in the data segment, used to normalize the entry size based on the difference in entry numbers. This refers to the number of missing entries;

[0112] Interval Dispersion Measurement Coefficient This refers to a comprehensive measure of order difference, used to characterize the degree of deviation between the terminal entry sequence and the cloud entry sequence within the same data segment in two dimensions: "collection time order" and "entry number order," as well as the cumulative contribution of the proportion of missing entries to this deviation. Specifically, the order deviation aggregation term includes: The meaning is: for each alignment position First, calculate the "normalized acquisition time difference". Difference from "normalized numbering" The deviation between positions is then averaged over all positions to obtain the average order deviation intensity within the interval; missing contribution item: This means that the degree of missing data is represented by the square root of the missing percentage, and it participates in the summation as an additional difference contribution term in the coefficients. Therefore, The larger the value, the stronger the deviation between the terminal and the cloud at the sequential level within the interval, and the greater the contribution of the missing value. The smaller the value, the weaker the contribution from order deviation and missing values;

[0113] When calculating the sequential alignment index sequence, the terminal acquisition time difference and the cloud acquisition time difference are calculated for each position. Assuming there are 4 entries in the data segment, the given values ​​are as follows:

[0114] Terminal data collection time (Unit: minutes);

[0115] Cloud collection time (Unit: minutes);

[0116] First, calculate each position. Time difference :

[0117] For location , , Therefore, the time difference is:

[0118] ;

[0119] For location , , Therefore, the time difference is:

[0120] ;

[0121] For location , , Therefore, the time difference is:

[0122] ;

[0123] For location , , Therefore, the time difference is:

[0124] ;

[0125] Calculate the difference in entry number for each location. The item numbers are sequentially incremented; calculate the difference in number:

[0126] For location Difference in number:

[0127] ;

[0128] For location Difference in number:

[0129] ;

[0130] For location Difference in number:

[0131] ;

[0132] For location Difference in number:

[0133] ;

[0134] The time difference and the number difference are normalized separately, and the normalization method is as follows:

[0135] Time difference normalization: Divide the time difference at each location by the time span of the data segment. minute;

[0136] Number difference normalization: Divide the number difference at each position by the total number of entries in the data segment. ;

[0137] For the normalization of time difference:

[0138] , , , ;

[0139] For the normalization of the number difference:

[0140] , , , ;

[0141] Calculate the interval difference measure coefficient :

[0142] Substituting the normalized time difference and number difference into the formula for calculation, assuming... And the number of missing entries We can conclude that:

[0143] ;

[0144] The calculation is as follows:

[0145] ;

[0146] ;

[0147] ;

[0148] Set a preset rollback trigger interval, and use this interval to determine the effectiveness of data synchronization. The preset interval for the interval difference measurement coefficient is:

[0149] Low deviation range: This range indicates that the data synchronization error is small, and the time order and numbering order of the entries on the terminal and in the cloud are basically consistent, so no rollback operation is required.

[0150] Medium deviation range: This range indicates that the data synchronization error is moderate, with some deviation, but not enough to affect the reliability of the data. The rollback operation can be selected to be executed according to actual needs.

[0151] High deviation range: This range indicates a large data synchronization error, with significant deviations in time and number between the terminal and cloud entries, indicating a major data synchronization problem that necessitates triggering a rollback operation for adjustment.

[0152] Based on this interval division, the currently calculated If the data is in the high deviation range, it means that the time and number of the current data segment are too different, and a rollback operation needs to be performed. This rollback operation will correct the data based on the synchronization error to ensure the consistency and reliability of subsequent data.

[0153] S413: Determine the corresponding position of the interval difference measurement coefficient in the data segment number sequence, analyze the start and end numbers and span of the missing entry interval set, identify the range of data segment numbers that can be rolled back, adjust the rollback correlation, and obtain the data segment rollback trigger index.

[0154] Read the difference count value corresponding to each data segment. For example, the difference for segment 101 is 1, the difference for segment 102 is 0, and the difference for segment 103 is 1. Combine the difference value with the segment number in sequence to form an array: 101 corresponds to 1, 102 corresponds to 0, and 103 corresponds to 1. Set the interval difference judgment threshold to 1. When the difference is greater than or equal to 1, it is marked as a missing interval; when the difference is equal to 0, it is marked as a complete interval. In this example, segments 101 and 103 are marked as missing intervals. Then read the missing interval number sequence 101 and 103, calculate the difference between the numbers: 103 minus 101 equals 2. When the difference is equal to 1, it is judged as a continuous interval; when the difference is greater than or equal to 1, it is judged as a complete interval. If the interval is 1, it is determined to be a discrete interval. Then, the index range of each segment in the terminal is read. For example, the index of segment 101 is 1 to 3 with a span of 2, and the index of segment 103 is 6 to 7 with a span of 1. The upper limit of the rollback span is set to 3. When the span is less than or equal to 3, it is marked as rollback allowed. When the span is greater than 3, it is marked as rollback prohibited. In this example, both segments meet the conditions. Then, the mapping relationship between the segment number and the starting index in the cloud is established. The starting segment 101, the ending segment 103 and the interval type are recorded as discrete. The segment number range, difference and span are written into the rollback control field to obtain the data segment rollback trigger index.

[0155] Please see Figure 6 The specific steps for obtaining the number of synchronized data entries are as follows:

[0156] S511: Based on the data segment rollback trigger indicator, obtain the version sequence of related entries, retrieve the corresponding user version record in the cloud, compare the version number identifier with the device serial number source, filter different device entries of the same version, determine the conflict relationship of device serial number source, and obtain version source conflict information.

[0157] First, read the version number sequence of all entries within the range. For example, the terminal version numbers in segments 101 to 103 are {4, 5, 6, 7}. Simultaneously, read the device serial number field corresponding to each record. For example, 4 corresponds to BG2024020015, 5 to BG2024019988, 6 to BG2024020015, and 7 to BG2024019988. Then, retrieve version records under the same user identity from the cloud, extracting the cloud version number set and the device source field. For example, if version numbers {4, 5, 6} exist in the cloud and the corresponding devices are {BG2024020015, BG2024020015, BG2024020015}, then perform version number equality checks on each record. The comparison process begins when the terminal version number equals the cloud version number, triggering a device source comparison. For example, terminal version 5 originates from BG2024019988, while cloud version 5 originates from BG2024020015. The device serial numbers are compared character by character. If the lengths are equal but any character is different, the source is determined to be different, and this record is added to the conflict candidate set. The rule for determining different devices with the same version is that if the version number is the same and the device serial number is completely different, a conflict is marked. In this example, version 5 is marked as a source conflict. The conflicting version number and its terminal device source are combined with the cloud device source to form a triplet record, such as {5, BG2024019988, BG2024020015}, forming version source conflict information.

[0158] S512: Based on version source conflict information, analyze the collection time field, compare the collection time order of entries of the same version, determine the time order conflict entries, filter the conflict entries to form a time sorting sequence, adjust the entry status mark to synchronous submission status, and obtain the sequence of submitted conflict entries.

[0159] Read the set of conflicting version numbers from the version source conflict information, for example, {5, 7}. Retrieve the collection time field corresponding to the version number. For example, version 5 has a terminal time of 1708388370 and a cloud time of 1708388360, while version 7 has a terminal time of 1708388490 and no corresponding record in the cloud. Then, compare the terminal time and cloud time for the same version number. If the terminal time is greater than the cloud time, record it as collected later; if the terminal time is less than the cloud time, record it as collected earlier. If the time difference is less than or equal to 30 seconds, mark it as a minor conflict. Time conflicts are marked as significant if the difference is greater than 30 seconds. In this example, version 5 has a time difference of 10 seconds, which is marked as a minor conflict. Version 7 has no cloud time, so it is directly marked as a new conflict entry. Then, the conflict entries are sorted in ascending order by terminal time. For example, version 5 is before version 7, so the sorting sequence {5, 7} is generated. Then, the current status flag field of the entry is read. If the status is "pending", it is changed to "synchronous submission". If the status is already "synchronous submission", it remains unchanged. After updating the status field of each entry, a new entry status list is formed, resulting in the sequence of submitted conflict entries.

[0160] S513: Based on the submitted conflict entry sequence, count the number of entries, compare the consistency between the entry version number identifier classification summary result and the entry status label, determine the entries with inconsistent status and remove them, then adjust the correspondence between the version number identifier and the entry count to obtain the number of synchronized data entries.

[0161] Retrieve the sequence of submitted conflict entries. For example, if the current sequence contains two records, version 5 and version 7, perform an entry count operation to obtain a count value of 2. Simultaneously, categorize and summarize by version number, for example, count 1 entry for version 5 and 1 entry for version 7. Then, read the status flag field of each record and check whether they are all "synchronized commit". If a record has a status other than 1, mark it as inconsistent and remove it from the statistics set. For example, if the status of version 7 is not updated, remove the record and decrement the count by 1. In this example, assuming both are "synchronized commit", keep the count at 2. Then, establish a correspondence table between version number and entry count, for example, {5:1, 7:1}. Then check if there are cases where the same version number corresponds to a count greater than 1. Set the maximum allowed count for a single version to 1. When the count is greater than 1, the record is a duplicate conflict and only the earliest one is retained. In this example, all counts are 1 and no adjustment is needed. Finally, write the number of valid entries into the synchronization statistics field to obtain the number of synchronized data entries.

[0162] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A cloud-based data synchronization method for diabetes management, characterized in that, Includes the following steps: S1: Based on blood glucose monitoring record entries, analyze the time field and device serial number, adjust the time to a unified time zone format, compare the device serial number with entries in the local registry, filter out matching entries, calculate and register the entry summary to the version field, and obtain the terminal version sequence identifier; S2: Based on the terminal version sequence identifier, compare the version field with the version field under the same user identifier in the cloud, identify missing version field entries, determine whether there is an abnormal collection time sequence, analyze the device source of the abnormal identifier, calculate the number of missing entries, and obtain the version difference marker. S3: Based on the version difference marker, analyze the entry record time, compare the terminal time with the NTP server time, determine the terminal clock drift status, adjust and synchronize the terminal time base, and obtain the time synchronization calibration coefficient. S4: Based on the time synchronization calibration coefficient, filter the associated data segment numbers, compare the collection time order of terminal entries and cloud entries, determine the time order difference, and analyze the range of missing entries corresponding to the difference to obtain the data segment rollback trigger index. The specific steps for obtaining the data segment rollback trigger indicator are as follows: S411: Based on the time synchronization calibration coefficient, analyze the numbering of continuous blood glucose monitoring data segments, filter the data segments to which the associated entries belong, compare the consistency of the numbers of terminal entries and cloud entries, calculate the correspondence of the numbers, and obtain the sequential comparison index sequence. S412: Based on the sequential comparison index sequence, calculate the terminal acquisition time difference and the cloud acquisition time difference at the corresponding positions, compare the deviation of the entry number difference, and adjust the segment span and entry size using the formula: ； Obtain the interval difference measurement coefficient ,in, This refers to the number of items included in the comparison. Refers to the first Collection time for each terminal entry Refers to the first The collection time of each cloud entry This refers to the time span of a data segment, used to normalize the time difference between data collection points. Refers to the first The difference in entry numbers at each location, This refers to the total number of entries in the data segment, used to normalize the entry size based on the difference in entry numbers. This refers to the number of missing entries; S413: Determine the corresponding position of the interval difference measurement coefficient in the data segment number sequence, analyze the start and end numbers and span of the missing entry interval set, identify the range of data segment numbers that can be rolled back, adjust the rollback association relationship, and obtain the data segment rollback trigger index. S5: Based on the data segment rollback trigger indicator, compare the version field with the cloud version, determine the version conflict identifier from multiple devices, identify conflict entries and sort them by collection time, adjust the entry status to synchronous submission, and obtain the number of synchronous data entries.

2. The cloud-based data synchronization method for diabetes management according to claim 1, characterized in that, The terminal version sequence identifier includes a time identifier, a device identifier, and a version number identifier. The version difference marker includes the missing entry type, time sequence anomaly identifier, device serial number difference, and total number of missing entries. The time synchronization calibration coefficient includes clock drift, synchronization delay, and reference adjustment identifier. The data segment rollback trigger indicator includes time sequence difference, missing entry range, and rollback operation trigger condition. The number of synchronized data entries includes the number of conflicting entries, version synchronization status, and synchronization confirmation identifier.

3. The cloud-based data synchronization method for diabetes management according to claim 1, characterized in that, The specific steps for obtaining the terminal version sequence identifier are as follows: S111: Based on the blood glucose monitoring record entries, obtain the record time field, adjust it to a unified time zone UTC timestamp representation, compare the device serial number with the serial number registered in the local device registry, identify registered matching entries, determine and remove unregistered entries, and obtain a set of registered matching entries; S112: Based on the registered matching entry set, analyze the combination relationship of entry fields, adjust the field order to a fixed concatenation sequence, calculate the entry digest code, register it to the version field, compare the digest code length with the version field format requirements, determine and remove inconsistent entries, and obtain the entry content digest code; S113: Based on the entry content digest code, analyze the time order of the associated entries, adjust the entry sorting to ascending order of collection time, compare the consistency of the device serial number and the time index association, determine the association gap and fill in the index mapping, and then calculate the version number increment sequence to obtain the terminal version sequence identifier.

4. The cloud-based data synchronization method for diabetes management according to claim 1, characterized in that, The specific steps for obtaining the version difference marker are as follows: S211: Based on the terminal version sequence identifier, retrieve the version field under the same user identity in the cloud, compare the version number with the version field record, filter the corresponding entries that do not match the version number, determine the integrity of the association between the entry primary key and the collection time field, determine the index of unmatched entries, and obtain the cloud missing entry index set; S212: Based on the cloud-based missing entry index set, retrieve the index entry collection time series, compare the adjacent collection time order with the registration order, determine the reverse order entries and skipped order entries, determine the serial number of the abnormal entry source device, and obtain time order abnormal mapping data; S213: Based on the time-series anomaly mapping data, count the number of anomaly entries, verify the total number of entries in the cloud-based missing entry index set, determine the consistency of the missing entry type classification, analyze the device serial number difference entries, mark the difference type, and obtain the version difference marker.

5. The cloud-based data synchronization method for diabetes management according to claim 1, characterized in that, The specific steps for obtaining the time synchronization calibration coefficient are as follows: S311: Based on the version difference marker, analyze the corresponding entry record time field associated with it, compare the terminal time with the network time protocol server UTC timestamp, calculate the time difference to form a time offset, determine the continuity of the offset in the time series, and obtain the clock drift determination amount. S312: Determine the changing trend of the clock drift determination quantity, calculate the absolute amount of each time offset within the sampling window, summarize to form an offset aggregation quantity, and compare the drift direction of the terminal time difference to obtain the time base correction mark. S313: Based on the time base correction mark, calculate the normalized terms of the absolute value of the residual term and the offset aggregation term, compare the one-way delay estimate with the time sampling interval, adjust the terminal time base mark, and obtain the time synchronization calibration coefficient.

6. The cloud-based data synchronization method for diabetes management according to claim 1, characterized in that, The specific steps for obtaining the number of synchronized data entries are as follows: S511: Based on the data segment rollback trigger index, obtain the associated entry version sequence, retrieve the corresponding user version record in the cloud, compare the version number identifier with the device serial number source, filter different device entries of the same version, determine the conflict relationship of device serial number source, and obtain version source conflict information. S512: Based on the version source conflict information, analyze the collection time field, compare the collection time order of entries of the same version, determine the time order conflict entries, filter the conflict entries to form a time sorting sequence, adjust the entry status mark to synchronous submission status, and obtain the submitted conflict entry sequence. S513: Based on the submitted conflict entry sequence, count the number of entries, compare the consistency between the entry version number identifier classification summary result and the entry status marker, determine the entries with inconsistent status and remove them, then adjust the correspondence between the version number identifier and the entry count to obtain the number of synchronized data entries.

7. The cloud-based data synchronization method for diabetes management according to claim 1, characterized in that, The device serial number refers to the unique identification code of the blood glucose meter or monitoring device, the user identifier refers to the unique identifier of the patient or user to distinguish the data of different users, and the missing version field refers to the situation where the data version field in the cloud database is missing or not updated.

Images