An offline medical data collection and breakpoint resuming method and system based on a portable terminal and a medium

Abstract

The application relates to an offline medical data acquisition and breakpoint continuation method and system based on a portable terminal and a medium, and relates to the technical field of medical data analysis. The offline medical data acquisition and breakpoint continuation method comprises the following steps: scanning a physical sign detection device according to a peripheral device driving middleware of the portable terminal, identifying a device communication protocol, and establishing a communication transmission link; reading resident identity information according to a terminal operation mode, receiving and analyzing original sign data through the communication transmission link, and packaging the original sign data into a data packet to be uploaded; storing the data packet to be uploaded in an encrypted manner in a local database, detecting a network connection state, and triggering a data synchronization service instruction; according to the data synchronization service instruction, the data packet to be uploaded is transmitted to a cloud server in batches in time sequence and in combination with a breakpoint continuation mechanism; and through the breakpoint continuation mechanism, the data entry problem caused by a poor network environment in household follow-up visits in primary medical treatment is solved, and automatic acquisition and non-susceptible uploading of sign data are realized.

Description

Technical Field

[0001] This application relates to the field of medical data analysis technology, and in particular to a method, system and medium for offline medical data acquisition and breakpoint resume based on a portable terminal. Background Technology

[0002] In primary healthcare services and public health follow-up scenarios, medical staff often need to conduct door-to-door physical examinations and follow-ups in communities, villages, or residents' homes. However, these scenarios often face problems such as unstable network signals or even no network coverage. Most existing mobile healthcare systems rely on real-time online connections. Once the network is interrupted, the data collected by vital sign monitoring devices cannot be uploaded to the public health system in real time, forcing medical staff to manually record the data and then re-enter it when they return to a network environment.

[0003] Existing patents disclose a method for collecting health sign monitoring data based on a mobile gateway, comprising the following steps: 1) A Bluetooth terminal device registers on a cloud platform; 2) A mobile terminal binds to the Bluetooth terminal device, saving it as a first binding relationship, and uploads this first binding relationship to the cloud platform; 3) The mobile terminal receives user information, binds itself to the user, saving it as a second binding relationship, and uploads this second binding relationship to the cloud platform; 4) The mobile terminal receives health sign data measured by the Bluetooth terminal device, filters the health sign data, and uploads it to the cloud platform; 5) The cloud platform verifies the validity of the received health sign data based on the first and second binding relationships, and saves the valid health sign data in the corresponding directory. Compared with existing technologies, the above invention has advantages such as improving data validity, making data traceable, and facilitating data collection by multiple terminal devices.

[0004] The existing technical solutions mentioned above have the following drawbacks: 1. The interface protocols of existing vital sign detection devices from different brands are different, making it difficult for mobile terminals to uniformly manage and drive multiple peripherals, resulting in low data collection efficiency; 2. When the network signal is unstable or there is no network coverage, medical staff have to manually record the data and then re-enter it after returning to a network environment, which increases the workload of medical staff, is prone to human input errors, and cannot guarantee the real-time performance and consistency of the data. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the purpose of this application is to provide a method, system, and medium for offline medical data collection and breakpoint resume based on a portable terminal. Through the breakpoint resume mechanism, it solves the data entry problem caused by poor network environment during home visits in primary healthcare, realizes automated collection and seamless uploading of vital sign data, eliminates the workload and error rate of secondary data entry, and improves the work efficiency and data accuracy of public health follow-up.

[0006] This was achieved using the following technical solutions: Firstly, this application provides a method for offline medical data acquisition and breakpoint resumption based on a portable terminal, including: Based on the peripheral driver middleware of the portable terminal, a vital sign detection device is scanned to identify the device's communication protocol and establish a communication transmission link; The system reads resident identity information according to the terminal's operating mode, receives and parses raw vital signs data via the communication transmission link, and encapsulates it into a data packet to be uploaded. The system encrypts and stores the data packets to be uploaded to the local database, checks the network connection status, and triggers a data synchronization service command. According to the data synchronization service instructions, the data packets to be uploaded are transmitted to the cloud server in batches according to the time sequence and the breakpoint resume mechanism.

[0007] By adopting the above technical solution, the peripheral driver middleware automatically scans the vital sign detection device and identifies the communication protocol to establish a transmission link. Combined with the terminal operation mode, it reads the identity information and parses the original vital sign data into a data packet to be uploaded. After being encrypted and stored in the local database, the data synchronization service is triggered according to the network connection status. The interrupted transmission mechanism is used to transmit the data to the cloud in batches according to the time sequence, which significantly improves the plug-and-play nature of vital sign data collection, the reliability of offline storage, and the integrity of upload in weak network environments in community medical scenarios.

[0008] This application is further configured to: scan the vital signs detection device based on the peripheral driver middleware of the portable terminal, identify the device communication protocol, and establish a communication transmission link, including: The peripheral driver middleware of the portable terminal is used to listen to the signals of the vital signs detection device and collect the broadcast signals of the device. The broadcast signal of the device is filtered according to the device connection status to obtain the broadcast signal to be connected; The target broadcast signal is obtained by filtering the broadcast signals to be connected according to the database of vital sign equipment names; The target broadcast signal is parsed to identify the device communication protocol, and the corresponding protocol driver is matched by combining the protocol driver library. Verify the connection with the device based on the protocol driver and generate a communication transmission link.

[0009] By adopting the above technical solution, based on the peripheral driver middleware of portable terminals, the broadcast signals of vital sign detection devices are filtered for connection status and matched with the name database. The target signals are parsed to identify the communication protocol and match the protocol driver to complete the verification connection and establish a reliable transmission link. This realizes plug-and-play automatic discovery and multi-protocol adaptive access of vital sign devices, improving the convenience, compatibility and field deployment efficiency of device connection.

[0010] This application is further configured to: read resident identity information according to the terminal's operating mode, and receive and parse raw vital sign data via a communication transmission link, encapsulating it into a data packet to be uploaded, including: Read residents' identity information and construct blank vital signs information collection forms according to their ID card numbers; The operating status of the vital signs detection equipment is identified, raw vital signs data is obtained, the communication transmission link is activated, and the data receiving and listening thread is started. Based on the data collection timestamp, the original vital sign data is filtered, denoised, and correlated to obtain a standard vital sign data package. The data receiving and listening thread receives and parses standard vital sign data packets to extract payload data. The payload data is separated according to the field name and associated with the blank vital signs information collection table to obtain the resident vital signs data table; The resident vital signs data table is encapsulated based on the timestamp and device serial number to generate a data package to be uploaded; The peripheral driver middleware performs a self-detection of the network status, determines the terminal's operating mode, and generates a data upload task based on the data packets to be uploaded.

[0011] By adopting the above technical solution, a blank vital sign table is constructed by reading residents' identity information, the communication link is activated and the listening thread is started, the original vital sign data is processed by filtering and noise reduction and collaborative association algorithms, the effective payload is extracted and filled into the vital sign table, and the data packet to be uploaded is encapsulated according to the timestamp and device serial number. At the same time, the network status is self-checked to determine the terminal operating mode and generate the upload task, thus realizing accurate collection, reliable encapsulation and adaptive uploading of vital sign data, improving data quality and transmission integrity.

[0012] This application further specifies: encrypting and storing the data packet to be uploaded to a local database, detecting the network connection status, and triggering a data synchronization service instruction, including: The data packets to be uploaded are serialized to obtain a binary biometric data byte stream; The binary vital signs data byte stream is encrypted using the device key to generate ciphertext data blocks; Based on the local database interface of the portable terminal, the database transaction mechanism is triggered to insert or update the encrypted data block and mark it as to be uploaded; Poll the external network interfaces to obtain network connection status and network signal strength, and filter the connected network interfaces. Based on the connected network interfaces, heartbeat detection is performed on the cloud server to calculate network link reachability and response latency. A network quality score is obtained by weighting network signal strength, network link reachability, and response latency. If the network quality score is greater than the platform service communication limit, the currently connected network interface is determined to be available; otherwise, it is determined to be unavailable. If a connected network interface changes from an unavailable state to an available state, a synchronization trigger command is generated to start the data synchronization service process. The status of the encrypted data blocks is queried according to the data synchronization service process, and the encrypted data blocks to be uploaded are extracted in ascending order of collection timestamp to establish a secure transmission channel. The encrypted data blocks to be uploaded are aggregated based on the secure transmission channel to generate data synchronization service instructions.

[0013] By adopting the above technical solution, local ciphertext blocks are generated through serialization encryption and marked for uploading. The network quality is comprehensively evaluated using a polling interface and a heartbeat detection algorithm to trigger the synchronization process. Then, the ciphertext blocks are extracted and aggregated in sequence to achieve breakpoint resumption. This significantly improves the reliability, security, and integrity of vital sign data uploading in weak network environments.

[0014] This application is further configured to: transmit data packets to be uploaded to the cloud server in batches according to the data synchronization service instructions and in chronological order, combined with a breakpoint resume mechanism, including: Parse the data synchronization service command to extract the maximum number of data to be transmitted in a single transmission and the transmission timeout threshold; The encrypted data blocks to be uploaded are arranged in chronological order to generate a queue to be uploaded; Based on the maximum number of data packets transmitted in a single batch and the network quality score, the maximum number of data packets transmitted in a single batch is adjusted, and the actual number of data packets transmitted in a batch is calculated. Examine the encrypted data blocks in the upload queue and calculate the data block size; If the data block size is greater than the safe volume threshold, the current ciphertext data block is split into ciphertext data blocks, and a block verification sequence number is generated. The terminal's digital certificate is authenticated through a secure transmission channel, and a batch list of data blocks is received. Upload encrypted data blocks or encrypted data segments one by one according to the data block batch list, and provide feedback on data confirmation identifiers and reception verification values; Based on the data confirmation identifier and the received verification value, update the upload status of the corresponding encrypted data packet in the local database, mark it as uploaded, and record the upload completion time; If a network interruption or timeout occurs during the upload of encrypted data packets, the anomaly location is performed on the encrypted data blocks or encrypted data segments of the current batch, and the breakpoint data packets are extracted. Parse the breakpoint data packets, extract the data packet type, and trigger the corresponding breakpoint resume mechanism; If the data packet type is a ciphertext data block, extract the position of the transmitted bytes and record the interruption time; If the interruption time exceeds the transmission timeout threshold and the number of reconnections exceeds the number threshold, the breakpoint resumption mechanism is triggered to parse the current encrypted data block and determine the interrupted fields. If the interrupted field is part of the payload, or a preceding field of the payload, then the current ciphertext data block is marked as needing to be re-uploaded. If the interrupted field is a subsequent field of the payload, then mark the current ciphertext data block as pending verification, and extract and segment the corresponding ciphertext data packet from the local database to obtain the original payload; If the original payload is the same as the current payload, then the current payload remains unchanged. No, then replace the current payload with the original payload; If the data packet type is encrypted data block, the corresponding block verification sequence number is extracted as the trigger point for the breakpoint resume mechanism, and the position of the transmitted bytes is recorded.

[0015] By adopting the above technical solution, the upper limit of the number of transmissions in a single transmission and the timeout threshold are extracted by parsing the synchronization instructions. The encrypted data blocks are sorted by time and the batch size is dynamically adjusted according to the network quality. Excessive data blocks are split and assigned a verification sequence number. After digital certificate authentication, they are uploaded in batches and the local status is updated. In case of network interruption, the interruption data packet type (complete block or segmented block) is parsed. For interruptions in the preceding sequence of the payload, retransmission is triggered. For interruptions in the following sequence, the original data is compared and verified locally to repair data inconsistencies. For segmented interruptions, the transmission is resumed precisely based on the verification sequence number. This improves the integrity and transmission efficiency of medical vital signs data in weak network environments.

[0016] Secondly, this application also provides an offline medical data acquisition and breakpoint resume system based on a portable terminal, which adopts the following technical solution: An offline medical data acquisition and breakpoint resume system based on a portable terminal, comprising the following methods for implementing offline medical data acquisition and breakpoint resume: The peripheral device parsing module is used to scan the vital signs detection device based on the peripheral driver middleware of the portable terminal, identify the device communication protocol, and establish a communication transmission link; The data aggregation module is used to read residents' identity information according to the terminal's operating mode, and to receive and parse the raw vital signs data through the communication transmission link, and encapsulate it into a data packet to be uploaded; The synchronization encryption module is used to encrypt and store the data packets to be uploaded to the local database, and to detect the network connection status and trigger the data synchronization service command. The breakpoint resume module is used to transmit data packets to be uploaded to the cloud server in batches according to the data synchronization service instructions and in chronological order, combined with the breakpoint resume mechanism.

[0017] By adopting the above technical solution, the peripheral driver middleware automatically scans the vital sign detection device and identifies the communication protocol to establish a transmission link. Combined with the terminal operation mode, it reads the identity information and parses the original vital sign data into a data packet to be uploaded. After being encrypted and stored in the local database, the data synchronization service is triggered according to the network connection status. The interrupted transmission mechanism is used to transmit the data to the cloud in batches according to the time sequence, which improves the plug-and-play nature of vital sign data collection, the reliability of offline storage, and the integrity of upload in weak network environments in community medical scenarios.

[0018] Thirdly, this application also provides an electronic device, comprising: One or more processors; Memory, used to store one or more programs; When one or more programs are executed by one or more processors, the one or more processors implement any of the methods in the above scheme.

[0019] Fourthly, this application also provides a storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by a processor to implement the offline medical data acquisition and breakpoint resume method based on a portable terminal as described above.

[0020] In summary, the beneficial technical effects of this application are as follows: The breakpoint resume mechanism solves the data entry problem caused by poor network environment in the home visit follow-up of primary medical care, realizes the automatic collection and seamless uploading of vital signs data, completely eliminates the workload and error rate of secondary entry, and significantly improves the work efficiency and data accuracy of public health follow-up. By parsing synchronization commands to address network interruption anomalies, and by parsing the breakpoint data packet type (complete block or segmented block), retransmission is triggered for preceding interruptions of the payload, and local raw data comparison and verification are performed for subsequent interruptions to repair data inconsistencies. For segmented interruptions, the transmission is resumed precisely based on the verification sequence number, thereby improving the integrity and transmission efficiency of medical vital sign data in weak network environments. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating the offline medical data acquisition and breakpoint resume method in this application; Figure 2 This is a flowchart illustrating step S3 in this application; Figure 3 This is a flowchart illustrating step S4 in this application; Figure 4 This is a schematic diagram of the offline medical data acquisition and breakpoint resume system in this application. Detailed Implementation

[0022] The present application will be further described in detail below with reference to the accompanying drawings.

[0023] Reference Figure 1 This application discloses a method for offline medical data acquisition and breakpoint resumption based on a portable terminal, comprising: S1: Based on the peripheral driver middleware of the portable terminal, scan the vital signs detection device, identify the device communication protocol, and establish a communication transmission link; S2: Read resident identity information according to the terminal's operating mode, and receive and parse the raw vital signs data through the communication transmission link, and encapsulate it into a data packet to be uploaded; S3: Encrypt and store the data packets to be uploaded to the local database, and detect the network connection status to trigger the data synchronization service command; S4: Based on the data synchronization service instructions, transmit the data packets to be uploaded to the cloud server in batches according to the time sequence and the breakpoint resume mechanism.

[0024] In this embodiment, after the portable terminal is powered on, it scans for nearby vital sign monitoring devices (such as blood pressure monitors and blood glucose meters) via Bluetooth or USB interface. The terminal's built-in general peripheral driver middleware reads the device's broadcast packets or descriptors, identifies the device type and manufacturer's protocol, and establishes a communication link.

[0025] Medical staff select "offline follow-up mode" on the terminal and input or read resident identity information (such as ID card). The terminal establishes a local transaction. When the detection device sends vital sign data, the middleware parses the raw data into a standard format (such as JSON), and appends the resident ID, timestamp, device serial number, and "not uploaded" status flag, encapsulating it into a data packet to be uploaded.

[0026] The packaged data packet to be uploaded is written to the local SQLite database on the terminal. During the writing process, sensitive vital signs data is encrypted using the AES encryption algorithm to ensure that data is not leaked in the event of device loss.

[0027] The terminal runs a network monitoring service in the background, periodically checking the network connection status. When it detects that the network has changed from disconnected to connected (such as connecting to the hospital's intranet Wi-Fi), it triggers the data synchronization service.

[0028] The synchronization service queries the local database for all data packets marked "not uploaded" and sends HTTP requests to the cloud server in batches according to time sequence. After the server receives the request successfully, it returns an acknowledgment code. Upon receiving the acknowledgment code, the terminal marks the corresponding local data packet as "uploaded" or removes it from the pending transmission queue. If the network is interrupted again during transmission, the system records the ID of the last successfully sent data packet and continues transmission from the next record with that ID after the network is restored.

[0029] Preferably, step S1 includes: The peripheral driver middleware of the portable terminal is used to listen to the signals of the vital signs detection device and collect the broadcast signals of the device. The broadcast signal of the device is filtered according to the device connection status to obtain the broadcast signal to be connected; The target broadcast signal is obtained by filtering the broadcast signals to be connected according to the database of vital sign equipment names; The target broadcast signal is parsed to identify the device communication protocol, and the corresponding protocol driver is matched by combining the protocol driver library. Verify the connection with the device based on the protocol driver and generate a communication transmission link.

[0030] In this embodiment, the application on the portable terminal calls the scanning interface of the underlying hardware (such as Bluetooth or Wi-Fi) through the peripheral driver middleware to prepare to start the search.

[0031] For Bluetooth devices, this will enter "central device" mode, listening for broadcast signals from surrounding "peripheral devices" (i.e., vital sign detection devices). A timeout can be set for this process, such as a continuous scan for 5 seconds.

[0032] During the scanning process, the middleware collects information about each discovered device, such as device address, signal strength (RSSI), device name, and broadcast data. The middleware can then perform preliminary filtering based on this information (such as a specific service UUID or device name) to quickly pinpoint the target biometric detection device.

[0033] Middleware identifies a device's communication protocol by parsing data packets sent by the device during the broadcast phase or at the beginning of a connection. Devices typically declare the services and protocols they support in their broadcast data.

[0034] The peripheral driver middleware internally maintains a "protocol driver library." It matches the read protocol identifier with the drivers in the library. For example, if it identifies a Bluetooth heart rate service (UUID 0x180D), it matches the corresponding heart rate protocol driver. Many systems support this automatic discovery mechanism by implementing the ProtocolDiscovery interface.

[0035] Once a match is successful, the middleware will dynamically load the corresponding protocol driver instance. This driver instance contains all the logic for data interaction with this type of device.

[0036] The middleware uses the identified protocol to initiate a connection request to the target device. Taking Bluetooth as an example, this process typically has a timeout limit (such as 10 seconds). Once the connection is successful, a physical data transmission link (such as a Bluetooth link) is established.

[0037] Once the connection is established, the middleware will further explore all the "services" and "features" offered by the device. For example, for a vital signs monitor, it might discover "heart rate service," "battery service," and so on.

[0038] At this point, the middleware has fully mastered the device's communication protocols, supported services, and specific data read / write interfaces, thus preparing for subsequent application-layer data collection.

[0039] Preferably, step S2 includes: Read residents' identity information and construct blank vital signs information collection forms according to their ID card numbers; The operating status of the vital signs detection equipment is identified, raw vital signs data is obtained, the communication transmission link is activated, and the data receiving and listening thread is started. Based on the data collection timestamp, the original vital sign data is filtered, denoised, and correlated to obtain a standard vital sign data package. The data receiving and listening thread receives and parses standard vital sign data packets to extract payload data. The payload data is separated according to the field name and associated with the blank vital signs information collection table to obtain the resident vital signs data table; The resident vital signs data table is encapsulated based on the timestamp and device serial number to generate a data package to be uploaded; The peripheral driver middleware performs a self-detection of the network status, determines the terminal's operating mode, and generates a data upload task based on the data packets to be uploaded.

[0040] In this embodiment, the Kalman filter algorithm is used for filtering and denoising to smooth out Gaussian noise and abnormal jumps in the original vital signs data.

[0041] In this embodiment, after the portable terminal is powered on, it automatically runs the peripheral driver middleware, detects the current network status and peripheral connection status, and determines the "running mode" of this operation (such as online real-time upload mode or offline temporary storage mode).

[0042] Based on the card reader (NFC / ID card reading module) or scanner configured on the terminal, resident identity information is collected in the following ways: For ID card reading: Place the resident ID card close to the terminal's NFC sensing area, and the driver middleware will call the ID card security control module to decrypt and read the text information such as name, ID number, address, and facial photo stored in the ID card chip.

[0043] If it is a QR code / barcode scan: The terminal camera scans the health pass code or test barcode provided by the resident, parses the encoded data, and extracts the individual's unique identifier ID.

[0044] If manual input is required: The terminal provides a data entry interface, where the operator manually enters the name and ID number based on the resident's ID document.

[0045] After identity information collection is completed, the terminal middleware confirms that the communication transmission link (Bluetooth, Wi-Fi or USB) between the terminal and the vital signs detection device (such as a thermometer, pulse oximeter, ECG patch) is active and starts the data receiving and listening thread.

[0046] The vital signs detection device sends the measurement results to the terminal via a link in a specific format (such as a byte stream or hexadecimal message), and the middleware receives the raw data packet.

[0047] The middleware, driven by the protocol of the device type, parses the raw data packets byte by byte: extracting the frame header, data length, checksum, and payload.

[0048] According to the protocol specifications, the raw values ​​in the payload (such as AD values) are converted into actual physical quantities (such as body temperature 36.5℃, blood oxygen saturation 98%). A timestamp and device serial number are then added to create a structured vital signs record.

[0049] The retrieved resident identity information and the parsed vital signs data are linked and bound together using the "personnel unique identifier ID" to form a complete "resident-vital signs" record.

[0050] Check if the record contains all required fields (name, ID, vital signs, measurement time). If any fields are missing, trigger a remeasurement or prompt for additional data entry.

[0051] The associated data is serialized and encapsulated according to the platform interface specifications: In online mode: the records will be assembled into a JSON or XML message, and a header (including terminal ID, software version, and data packet sequence number) and a footer checksum (MD5 or CRC32) will be added to form the data packet to be uploaded.

[0052] In offline mode: records are appended to the upload queue in the local encrypted database, and a corresponding queue index file is generated.

[0053] Reference Figure 2 Preferably, step S3 includes: The data packets to be uploaded are serialized to obtain a binary biometric data byte stream; The binary vital signs data byte stream is encrypted using the device key to generate ciphertext data blocks; Based on the local database interface of the portable terminal, the database transaction mechanism is triggered to insert or update the encrypted data block and mark it as to be uploaded; Poll the external network interfaces to obtain network connection status and network signal strength, and filter the connected network interfaces. Based on the connected network interfaces, heartbeat detection is performed on the cloud server to calculate network link reachability and response latency. A network quality score is obtained by weighting network signal strength, network link reachability, and response latency. If the network quality score is greater than the platform service communication limit, the currently connected network interface is determined to be available; otherwise, it is determined to be unavailable. If a connected network interface changes from an unavailable state to an available state, a synchronization trigger command is generated to start the data synchronization service process. The status of the encrypted data blocks is queried according to the data synchronization service process, and the encrypted data blocks to be uploaded are extracted in ascending order of collection timestamp to establish a secure transmission channel. The encrypted data blocks to be uploaded are aggregated based on the secure transmission channel to generate data synchronization service instructions.

[0054] In this embodiment, the encapsulated data packet to be uploaded (JSON / XML format, containing resident identity information, vital sign measurement values, timestamp and terminal ID) is converted into a binary byte stream.

[0055] The byte stream is encrypted using either the Chinese national cryptographic algorithm SM4 or AES-256, and a device key pre-programmed into the terminal's security chip is used to generate ciphertext data blocks. The encryption process is completed within the terminal's trusted execution environment, ensuring that the key does not leave the chip.

[0056] The portable terminal inserts or updates the encrypted ciphertext data blocks and associated index information (such as data packet sequence number, collection time, personnel ID, and upload status flags) into the local SQLite database's pending upload data table via the local database interface, either as a binary large object or a file path. This process enables database transaction mechanisms to ensure the atomicity of the write and to create an index for subsequent queries.

[0057] The portable terminal operating system periodically polls all available network interfaces, including cellular networks, Wi-Fi, and Ethernet, to obtain the connection status and signal strength of each interface.

[0058] For each network interface in a connected state, the end-to-end reachability and response latency of the network link are verified by sending lightweight heartbeat packets (such as HTTPS HEAD requests) or Ping probe packets to a preset cloud platform server.

[0059] The network quality score is calculated based on the detection results, including indicators such as connection bandwidth, packet loss rate, and latency. If any available network interface meets the platform service communication requirements (e.g., latency <200ms, packet loss rate <5%), the network connection is determined to be "available"; otherwise, it is determined to be "unavailable".

[0060] When the network connection status changes from "unavailable" to "available", or when the synchronization timer expires, or when the operator manually clicks the synchronization button, a trigger command is generated to start the data synchronization service process.

[0061] The synchronization service queries the local database for records marked as "pending upload" and extracts the encrypted ciphertext data blocks and their associated index information in ascending order of collection timestamp.

[0062] The synchronization service and the cloud platform server establish a secure, mutually authenticated channel via the TLS 1.3 protocol. Portable terminals use their digital certificates for authentication.

[0063] Reference Figure 3 Preferably, step S4 includes: Parse the data synchronization service command to extract the maximum number of data to be transmitted in a single transmission and the transmission timeout threshold; The encrypted data blocks to be uploaded are arranged in chronological order to generate a queue to be uploaded; Based on the maximum number of data packets transmitted in a single batch and the network quality score, the maximum number of data packets transmitted in a single batch is adjusted, and the actual number of data packets transmitted in a batch is calculated. Examine the encrypted data blocks in the upload queue and calculate the data block size; If the data block size is greater than the safe volume threshold, the current ciphertext data block is split into ciphertext data blocks, and a block verification sequence number is generated. In this embodiment, the safe volume threshold is 1MB. When the data packet volume exceeds this threshold, block splitting is automatically triggered.

[0064] The terminal's digital certificate is authenticated through a secure transmission channel, and a batch list of data blocks is received. Upload encrypted data blocks or encrypted data segments one by one according to the data block batch list, and provide feedback on data confirmation identifiers and reception verification values; Based on the data confirmation identifier and the received verification value, update the upload status of the corresponding encrypted data packet in the local database, mark it as uploaded, and record the upload completion time; If a network interruption or timeout occurs during the upload of encrypted data packets, the anomaly location is performed on the encrypted data blocks or encrypted data segments of the current batch, and the breakpoint data packets are extracted. Parse the breakpoint data packets, extract the data packet type, and trigger the corresponding breakpoint resume mechanism; If the data packet type is a ciphertext data block, extract the position of the transmitted bytes and record the interruption time; If the interruption time exceeds the transmission timeout threshold and the number of reconnections exceeds the number threshold, the breakpoint resumption mechanism is triggered to parse the current encrypted data block and determine the interrupted fields. If the interrupted field is part of the payload, or a preceding field of the payload, then the current ciphertext data block is marked as needing to be re-uploaded. If the interrupted field is a subsequent field of the payload, then mark the current ciphertext data block as pending verification, and extract and segment the corresponding ciphertext data packet from the local database to obtain the original payload; In this embodiment, the preceding fields are the fields in the payload located before the preset segmentation point, including the patient identification and measurement timestamp; the following fields are the fields in the payload located after the preset segmentation point, including vital sign measurement values ​​and device calibration information.

[0065] If the original payload is the same as the current payload, then the current payload remains unchanged. No, then replace the current payload with the original payload; If the data packet type is encrypted data block, the corresponding block verification sequence number is extracted as the trigger point for the breakpoint resume mechanism, and the position of the transmitted bytes is recorded.

[0066] In this embodiment, if the transmission is interrupted, the current data packet is processed differently according to the interruption position, including: if the interruption position is in the pre-processing part of the data packet payload, the data packet is marked as to be re-uploaded; if the interruption position is in the post-processing part of the data packet payload, the data packet is compared and verified with the local original data and then the upload continues.

[0067] In this embodiment, after the portable terminal receives the data synchronization service instruction, the synchronization service process parses the instruction parameters (such as the maximum number of transmissions per session, timeout threshold, and retry strategy) and creates a unique identifier (SyncTaskID) for this synchronization task.

[0068] The synchronization service connects to the local database, queries data packet records with the "upload status flag" set to "pending upload" in ascending order of collection time, and generates a queue of data packets to be uploaded in chronological order. If the queue is empty, the synchronization task is terminated and logged.

[0069] Based on the maximum number of data packets that can be transmitted in a single batch for this synchronization task (e.g., 50 packets per batch) and the network quality assessment results (e.g., bandwidth, latency), the actual number of data packets transmitted in each batch is dynamically calculated. If the network quality is poor, the number of packets per batch is automatically reduced to decrease the load on a single transmission.

[0070] The synchronization service queries the local database's resume record table to check if a previously interrupted synchronization task (i.e., an incomplete batch of the preceding SyncTaskID) still exists. If it exists, it loads the starting position of the batch and the list of completed data packet IDs, and jumps directly to step six to resume the transmission; if it does not exist, it proceeds normally to the next step.

[0071] According to the queue order, retrieve the data packet records that should be transmitted in the current batch from the queue to be uploaded, extract the encrypted ciphertext data blocks, data packet sequence numbers and associated index information, and form a batch transmission list.

[0072] If a single data packet in a batch exceeds a preset threshold (e.g., 1MB), the synchronization service will split the encrypted data block of that data packet into multiple blocks, generate a block sequence number and MD5 checksum for each block, and record them in the batch list.

[0073] The synchronization service establishes a two-way authentication secure channel with the cloud server via TLS 1.3, sends the terminal digital certificate to complete the authentication, and exchanges metadata for this batch (batch size, packet ID list, total number of blocks).

[0074] Upload chunks or data packets one by one in the order of the batch list. After each chunk / data packet is uploaded, the cloud returns an acknowledgment identifier and a receipt verification value for that chunk / data packet. The synchronization service updates the corresponding upload progress status (e.g., "Cheap 3 / 10 uploaded") in the local database.

[0075] After all chunks / data packets in the current batch have been uploaded, the synchronization service sends a batch end flag to the cloud. The cloud then aggregates and verifies the MD5 values ​​of all chunks in the batch and returns the batch integrity verification result.

[0076] In this embodiment, medical staff use a portable handheld terminal to collect patients' vital signs data (such as electrocardiogram waveform, blood oxygen saturation, and blood pressure), and package it into encrypted data blocks according to the HL7 / FHIR standard (each data packet encapsulates a complete examination report of approximately 2MB), or upload it to the cloud-based electronic medical record system in fixed 10KB blocks. During the upload process, if the connection times out due to unstable 4G signal or excessive satellite link latency (failure to reconnect after 3 attempts), the terminal automatically locates the breakpoint and extracts the data packets that were not fully transmitted. If the interruption occurs within the payload after the packet header, and the interruption position falls within the pre-order field of the payload: that is, the header field in the data packet that is located before the actual medical data and is used to identify the patient's temporary ID and sampling timestamp, the terminal determines that this field is corrupted and marks the entire data block as needing to be re-uploaded. If the interruption occurs in the post-order field of the payload: that is, the tail field that is used to store the HMAC-SHA256 integrity check value generated based on TLS negotiation after the medical data, the terminal triggers a verification process, retrieves the original payload from the local encrypted database for comparison, and if the verification matches, the currently received data is used; otherwise, the original data is replaced. If the upload mode adopts a segmented strategy, the system selects to continue segmented transmission from the most recently successfully confirmed sequence number based on the recorded segment verification sequence number and the position of the transmitted bytes. This ensures that medical data can still be reliably and completely transmitted back to the hospital in the field under harsh communication conditions, providing timely and accurate diagnostic basis for remote consultation.

[0077] Reference Figure 4 An offline medical data acquisition and breakpoint resume system based on a portable terminal, applied to the offline medical data acquisition and breakpoint resume method, includes: The peripheral device parsing module is used to scan the vital signs detection device based on the peripheral driver middleware of the portable terminal, identify the device communication protocol, and establish a communication transmission link; The data aggregation module is used to read residents' identity information according to the terminal's operating mode, and to receive and parse the raw vital signs data through the communication transmission link, and encapsulate it into a data packet to be uploaded; The synchronization encryption module is used to encrypt and store the data packets to be uploaded to the local database, and to detect the network connection status and trigger the data synchronization service command. The breakpoint resume module is used to transmit data packets to be uploaded to the cloud server in batches according to the data synchronization service instructions and in chronological order, combined with the breakpoint resume mechanism.

[0078] In this embodiment, during chronic disease follow-up at a community health service center, family doctors use portable smart terminals to collect vital sign data such as electrocardiogram (ECG), blood pressure, blood oxygen saturation, and blood glucose for elderly residents in the area. The terminal automatically scans and identifies various vital sign monitoring devices (such as 12-lead ECG recorders, electronic blood pressure monitors, pulse oximeters, and blood glucose meters) connected via Bluetooth / USB through peripheral driver middleware. It establishes a communication transmission link based on the GATT service UUID broadcast by the device and a custom protocol signature, achieving seamless plug-and-play peripheral compatibility. The data aggregation module, based on the terminal's current operating mode (offline / online), reads residents' social security cards or ID cards via NFC / RFID to obtain identity information. It then receives the raw vital sign signals returned by each peripheral device through the established communication link, performs protocol parsing, dimension conversion, and outlier removal, and encapsulates the data according to the HL7 FHIR standard into a JSON data packet containing the resident ID, collection timestamp, and device serial number, and marks it with a batch processing number.

[0079] The synchronization encryption module encrypts the data packet using the AES-256-GCM algorithm and stores it in the terminal's local SQLite database. Simultaneously, it periodically checks network connectivity (e.g., 4G / 5G or Wi-Fi signal strength). Once the link is restored, it triggers a data synchronization service command, selecting either full or incremental synchronization mode based on the configured upload strategy. Upon receiving this command, the breakpoint resume module extracts unuploaded records locally in batches according to the data packet generation time and sends them to the cloud-based public health data platform via HTTPS PUT requests. If network jitter causes a TCP connection timeout or an HTTP status code other than 200 during the upload process, the system automatically records the current batch's block checksum number and the offset of transmitted bytes. After network reconstruction, it invokes the breakpoint resume mechanism with a Range header to continue transmission from the last interrupted position, ensuring that each resident's health record is archived completely and without loss to the cloud server. This effectively solves the problem of data loss or duplicate collection caused by unstable signals in grassroots medical scenarios.

[0080] Thirdly, an electronic device includes: One or more processors; Memory, used to store one or more programs; When one or more programs are executed by one or more processors, the one or more processors implement any of the methods in the above scheme.

[0081] Fourthly, a storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by a processor to implement the offline medical data acquisition and breakpoint resume method as described above.

[0082] The embodiments described in this specific implementation are preferred embodiments of this application and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A method for offline medical data acquisition and breakpoint resumption based on a portable terminal, characterized in that, include: Based on the peripheral driver middleware of the portable terminal, a vital sign detection device is scanned to identify the device's communication protocol and establish a communication transmission link; The system reads resident identity information according to the terminal's operating mode, receives and parses raw vital signs data via the communication transmission link, and encapsulates it into a data packet to be uploaded. The system encrypts and stores the data packets to be uploaded to the local database, checks the network connection status, and triggers a data synchronization service command. According to the data synchronization service instructions, the data packets to be uploaded are transmitted to the cloud server in batches according to the time sequence and the breakpoint resume mechanism.

2. The method for offline medical data acquisition and breakpoint resumption based on a portable terminal according to claim 1, characterized in that, The step of scanning vital signs detection devices based on the peripheral driver middleware of portable terminals, identifying device communication protocols, and establishing communication transmission links includes: The peripheral driver middleware of the portable terminal is used to listen to the signals of the vital signs detection device and collect the broadcast signals of the device. The broadcast signal of the device is filtered according to the device connection status to obtain the broadcast signal to be connected; The target broadcast signal is obtained by filtering the broadcast signals to be connected according to the database of vital sign equipment names; The target broadcast signal is parsed to identify the device communication protocol, and the corresponding protocol driver is matched by combining the protocol driver library. Verify the connection with the device based on the protocol driver and generate a communication transmission link.

3. The method for offline medical data acquisition and breakpoint resumption based on a portable terminal according to claim 1, characterized in that, The process of reading resident identity information according to the terminal's operating mode, receiving and parsing raw vital sign data via the communication transmission link, and encapsulating it into a data packet to be uploaded includes: Read residents' identity information and construct blank vital signs information collection forms according to their ID card numbers; The operating status of the vital signs detection equipment is identified, raw vital signs data is obtained, the communication transmission link is activated, and the data receiving and listening thread is started. Based on the data collection timestamp, the original vital sign data is filtered, denoised, and correlated to obtain a standard vital sign data package. The data receiving and listening thread receives and parses standard vital sign data packets to extract payload data. The payload data is separated according to the field name and associated with the blank vital signs information collection table to obtain the resident vital signs data table; The resident vital signs data table is encapsulated based on the timestamp and device serial number to generate a data package to be uploaded; The peripheral driver middleware performs a self-detection of the network status, determines the terminal's operating mode, and generates a data upload task based on the data packets to be uploaded.

4. The method for offline medical data acquisition and breakpoint resumption based on a portable terminal according to claim 1, characterized in that, The process of encrypting and storing the data packets to be uploaded to the local database, detecting the network connection status, and triggering a data synchronization service instruction includes: The data packets to be uploaded are serialized to obtain a binary biometric data byte stream; The binary vital signs data byte stream is encrypted using the device key to generate ciphertext data blocks; Based on the local database interface of the portable terminal, the database transaction mechanism is triggered to insert or update the encrypted data block and mark it as to be uploaded; Poll the external network interfaces to obtain network connection status and network signal strength, and filter the connected network interfaces. Based on the connected network interfaces, heartbeat detection is performed on the cloud server to calculate network link reachability and response latency.

5. The method for offline medical data acquisition and breakpoint resumption based on a portable terminal according to claim 4, characterized in that, The process of encrypting and storing the data packets to be uploaded to the local database, detecting the network connection status, and triggering the data synchronization service instruction also includes: A network quality score is obtained by weighting network signal strength, network link reachability, and response latency. If the network quality score is greater than the platform service communication limit, the currently connected network interface is determined to be available; otherwise, it is determined to be unavailable. If a connected network interface changes from an unavailable state to an available state, a synchronization trigger command is generated to start the data synchronization service process. The status of the encrypted data blocks is queried according to the data synchronization service process, and the encrypted data blocks to be uploaded are extracted in ascending order of collection timestamp to establish a secure transmission channel. The encrypted data blocks to be uploaded are aggregated based on the secure transmission channel to generate data synchronization service instructions.

6. The method for offline medical data acquisition and breakpoint resumption based on a portable terminal according to claim 1, characterized in that, The process of transmitting data packets to be uploaded to the cloud server in batches according to the data synchronization service instructions in chronological order, combined with the breakpoint resume mechanism, includes: Parse the data synchronization service command to extract the maximum number of data to be transmitted in a single transmission and the transmission timeout threshold; The encrypted data blocks to be uploaded are arranged in chronological order to generate a queue to be uploaded; Based on the maximum number of data packets transmitted in a single batch and the network quality score, the maximum number of data packets transmitted in a single batch is adjusted, and the actual number of data packets transmitted in a batch is calculated. Examine the encrypted data blocks in the upload queue and calculate the data block size; If the data block size is greater than the safe volume threshold, the current ciphertext data block is split into ciphertext data blocks, and a block verification sequence number is generated. The terminal's digital certificate is authenticated through a secure transmission channel, and a batch list of data blocks is received. Upload encrypted data blocks or encrypted data segments one by one according to the data block batch list, and provide feedback on data confirmation identifiers and reception verification values; Based on the data confirmation identifier and the received verification value, update the upload status of the corresponding encrypted data packet in the local database, mark it as uploaded, and record the upload completion time.

7. The method for offline medical data acquisition and breakpoint resumption based on a portable terminal according to claim 6, characterized in that: The step of transmitting the data packets to be uploaded to the cloud server in batches according to the data synchronization service instructions in chronological order, combined with the breakpoint resume mechanism, also includes: If a network interruption or timeout occurs during the upload of encrypted data packets, the anomaly location is performed on the encrypted data blocks or encrypted data segments of the current batch, and the breakpoint data packets are extracted. Parse the breakpoint data packets, extract the data packet type, and trigger the corresponding breakpoint resume mechanism; If the data packet type is a ciphertext data block, extract the position of the transmitted bytes and record the interruption time; If the interruption time exceeds the transmission timeout threshold and the number of reconnections exceeds the number threshold, the breakpoint resumption mechanism is triggered to parse the current encrypted data block and determine the interrupted fields. If the interrupted field is part of the payload, or a preceding field of the payload, then the current ciphertext data block is marked as needing to be re-uploaded. If the interrupted field is a subsequent field of the payload, then mark the current ciphertext data block as pending verification, and extract and segment the corresponding ciphertext data packet from the local database to obtain the original payload; If the original payload is the same as the current payload, then the current payload remains unchanged. No, then replace the current payload with the original payload; If the data packet type is encrypted data block, the corresponding block verification sequence number is extracted as the trigger point for the breakpoint resume mechanism, and the position of the transmitted bytes is recorded.

8. An offline medical data acquisition and breakpoint resume system based on a portable terminal, used to implement the offline medical data acquisition and breakpoint resume method as described in any one of claims 1-7, characterized in that, include: The peripheral device parsing module is used to scan the vital signs detection device based on the peripheral driver middleware of the portable terminal, identify the device communication protocol, and establish a communication transmission link; The data aggregation module is used to read residents' identity information according to the terminal's operating mode, and to receive and parse the raw vital signs data through the communication transmission link, and encapsulate it into a data packet to be uploaded; The synchronization encryption module is used to encrypt and store the data packets to be uploaded to the local database, and to detect the network connection status and trigger the data synchronization service command. The breakpoint resume module is used to transmit data packets to be uploaded to the cloud server in batches according to the data synchronization service instructions and in chronological order, combined with the breakpoint resume mechanism.

9. A storage medium storing at least one instruction, at least one program, a code set, or an instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the offline medical data acquisition and breakpoint resume method as described in any one of claims 1 to 7.

Images