Smart glasses patrol conversation binding and data consistency fusion method and system

Abstract

The application relates to the technical field of medical data processing, and discloses an intelligent glasses ward round conversation binding and data consistency fusion method and system, which comprises the following steps: establishing a conversation binding object by performing patient identity and bed verification; generating a conversation snapshot object by recording state migration data; constructing data into a unified event format record by combining the conversation snapshot object and performing weak network supplement transmission synchronization; generating a fusion key by extracting attributes and calculating a fusion score object to queue the record; then, performing attribution verification by comparing the snapshot object and the supplement transmission record to generate a conflict record object; finally, obtaining an artificial instruction to generate a closed loop confirmation object to output a structured ward round summary object. The application performs attribution verification by establishing a conversation binding and a snapshot object in combination with a supplement transmission mechanism, reduces the risk of data stringing and guarantees correct data attribution, realizes field-level consistency fusion by using a fusion key and a score to implement shunting, and improves the traceability of medical record archiving by generating a closed loop confirmation object in combination with artificial intervention.

Description

Technical Field

[0001] This application relates to the field of medical data processing technology, specifically to a method and system for binding and integrating smart glasses-based mobile clinic sessions with data consistency. Background Technology

[0002] Existing mobile-based ward round systems are primarily used for medical record retrieval and lack a session modeling mechanism based on individual bedside rounds. In weak network environments such as wards, the system typically relies on offline caching and uploading data directly after network recovery. Due to patient transfers or delays in updating bed information, offline data collection is prone to misidentification with the current actual patient being rounded. Traditional retransmission mechanisms often rely solely on file or timestamp order for data processing, which can lead to previously cached data being mistakenly written into subsequent patients' records, causing data mix-ups and failing to guarantee correct attribution after data retransmission and synchronization in weak network environments.

[0003] The hospital's internal systems comprise multiple independent systems, including electronic medical records, laboratory and monitoring equipment, each with variations in data update timing, review status, and source reliability. When the outpatient system accesses this dispersed, multi-source data, existing processing methods lack unified event format constraints and have not established quantitative measurement models for data correlation attributes. When handling concurrent access of multi-source heterogeneous data, traditional methods typically employ direct merging operations, lacking proactive assessment and alignment mechanisms that consider identity, time, numerical differences, and source dimensions. This results in logically chaotic data processing and makes it difficult to achieve consistent fusion of medical data fields.

[0004] When faced with conflicts arising from the merging of multi-source medical data, traditional data transfer methods often allow data from different systems to directly overwrite each other, lacking multi-version candidate retention mechanisms and manual intervention isolation channels for conflicting data, which can easily damage the underlying formal medical records. After completing clinical data collection and generating rounds results, existing systems struggle to establish strict correlations between the final output medical record summary and the original collection actions, data source identifiers, and doctor confirmation instructions. This one-way transfer model leads to the loss of evidence of data merging or modification, resulting in insufficient audit traceability capabilities after medical record data archiving. Therefore, providing a method and system for binding and integrating smart glasses-based rounds sessions with data consistency is a problem that needs to be solved in this field. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a method and system for binding and integrating smart glasses-based mobile clinic sessions and data consistency. This solves the problems of data mismatch and patient attribution errors caused by weak network retransmission, difficulty in achieving field-level consistency integration of multi-source heterogeneous medical data, and lack of traceability in medical record archiving due to data merging and mutual overwriting.

[0006] To address the above problems, this application provides the following technical solution: The first aspect of this application provides a method for integrating smart glasses-based mobile clinic sessions with data consistency, employing the following technical solution: A method for integrating smart glasses-based mobile clinic sessions with data consistency includes the following steps: Perform patient identity and bed verification to establish a session binding object, record state transition data during the lifecycle of the rounds session, and generate a session snapshot object; Collect bedside data, and in a weak network environment, combine the session snapshot object to perform data retransmission and synchronization, and construct multi-source medical data into a unified event format record; Extract the attributes of the unified event format records to generate fusion keys, calculate fusion scoring objects based on multidimensional consistency metrics, and distribute the unified event format records to a confirmation queue, a pending review queue, or a conflict queue based on the fusion scoring objects. The session snapshot object is compared with the data retransmission synchronization record for attribution verification, and a conflict record object is generated for the data diverted to the conflict queue; Obtain manual intervention instructions for the conflict record object, complete conflict resolution and generate a closed-loop confirmation object, extract the confirmation data records in the confirmation queue, generate a structured round summary object based on the confirmation data records and the closed-loop confirmation object, and output it.

[0007] By adopting the above technical solution, due to the use of a multi-factor patient and bed verification and rounds session status mechanism, combined with the unified event format record, the fusion key and the session snapshot object mechanism, and by retaining multiple versions of candidate data and introducing confirmation instructions during the data fusion process, the technical effects of reducing the risk of data mix-ups, ensuring the correct attribution of data after weak network retransmission, achieving field-level consistent fusion, avoiding data overwriting between different systems, and improving the traceability of medical record archiving are achieved.

[0008] Furthermore, the process of establishing the session binding object and generating the session snapshot object includes: Obtain independent verification factors attached to different physical carriers, perform weighted calculation based on the factor confidence of each independent verification factor and the preset weight to obtain a multi-factor matching score, and when the multi-factor matching score reaches the preset matching threshold, instantiate the session binding object and initialize the binding version identifier. Listen for change events and operation instructions. When a preset trigger event such as patient transfer, bed change, or re-identification is detected, increment the binding version identifier in the session binding object. The lifecycle of the outpatient session is divided into multiple preset state enumeration values. When a transition occurs between the state enumeration values ​​or the binding version identifier is incremented, a snapshot capture action is triggered, and the patient identifier, bed identifier, session identifier, current binding version identifier, current enumeration state, last event sequence number and snapshot time at the current moment are solidified into the session snapshot object.

[0009] By adopting the above technical solution, matching scores are generated and binding associations are established through verification factors related to at least two independent patient identifiers or bed identifiers. The binding version identifier increment rule and session state transition logic are used to control whether operation actions or retransmission data packets are allowed to be written into the same rounds session, thereby reducing the risk of data mix-ups involving patients.

[0010] Furthermore, in the process of combining the session snapshot object to perform data retransmission and synchronization, and constructing multi-source medical data into a unified event format record, the following steps are included: The multi-source medical data packets are disassembled to extract the business field name, business field value, source time, source system, local serial number and the bound version identifier, and a hash operation is performed to generate a content hash value. The content hash value and the local sequence number are used to perform deduplication on the data for data retransmission and synchronization, and the deduplicated data is constructed into a unified event format record that includes at least the source time, receiving time, verification status, binding version identifier, content hash value, event unique identifier and doctor identifier; During network connection interruption, the collected bedside data and the session snapshot object are encapsulated into a network outage cache package and stored locally. After the network is restored, the session snapshot object and the local serial number recorded in the network outage cache package are read and uploaded in the order of the local serial number to perform the data retransmission synchronization.

[0011] By adopting the above technical solution, multi-source medical data is constructed into an event record or network outage cache package containing fields such as the content hash value, the local serial number, the session snapshot object, and the verification status. During weak network retransmission, the content hash value and the local serial number are used for verification and deduplication to ensure that the data can still be correctly attributed after weak network retransmission.

[0012] Furthermore, the process of extracting attributes from the unified event format records to generate fusion keys and calculating the fusion score object based on the multidimensional consistency metric includes: Extract the patient identifier, bed identifier, session identifier, field name, time window, binding version identifier, and source range from the unified event format record and associated context, and concatenate them to generate the fusion key. Create a corresponding field fusion queue for the same fusion key. Within the field fusion queue, the associated attributes of multiple record sources are extracted, and weighted summation and normalization operations are performed on the identity consistency score, time consistency score, source credibility weight, numerical consistency score and doctor confirmation weight to output the fusion score value. The fusion score value constitutes the fusion score object. Specifically, the identity consistency score is calculated based on the patient identifier, the bed identifier, and the bound version identifier; the time consistency score is calculated based on the distance between the source time and the current rounds time window; the source credibility weight is calculated based on the source system and the review status; the numerical consistency score is calculated based on the difference in candidate values ​​of the same-name field; and the doctor confirmation weight is calculated based on the doctor confirmation status.

[0013] By adopting the above technical solution, events within the same patient, bed, session, time window, and version range are grouped based on the fusion key, and the fusion score is output under the weighted normalization of identity, time, source, value, and personnel operation dimension indicators, thus achieving micro-level field-level consistency fusion.

[0014] Furthermore, the process of splitting the unified event format record based on the fusion scoring object includes: When the fusion score value is determined to be greater than or equal to the preset confidence threshold and no conflict is found, the corresponding unified event format record is diverted to the confidence queue. When the fusion score value is determined to be greater than or equal to the preset review threshold and less than the confidence threshold, the corresponding unified event format record is diverted to the queue to be reviewed. When it is determined that the fusion score is less than the review threshold or there is a data conflict, the corresponding unified event format record is diverted to the conflict queue.

[0015] By adopting the above technical solution, the system automatically performs confirmation, verification, and conflict classification judgments based on the fusion score, thereby realizing the diversion and control from the data record level to the explicit conflict dimension.

[0016] Furthermore, the process of verifying the attribution of the session snapshot object with the data retransmission synchronization record includes: Parse and extract the historical patient identity, historical bed identity, historical binding version identity, and historical session status from the historical session snapshot object carried in the data retransmission and synchronization records; Read the currently maintained session snapshot object and extract the current patient identity, current bed identifier, current bound version identifier, and current session state; When it is determined that at least one of the historical binding version identifier, the historical patient identity identifier, the historical bed identifier, and the historical session status is inconsistent with the corresponding current identifier or status, the attribution verification is deemed to have failed, the data in the record is blocked from being written to the target medical record database, and the record is transferred to the isolation record pool.

[0017] By adopting the above technical solution, the patient, bed, session status and binding version are synchronously verified during weak network retransmission. Data that fails the verification is transferred and isolated instead of being directly written to the database corresponding to the current patient or bed, thus ensuring the correctness of the underlying synchronous data ownership logic.

[0018] Furthermore, the process of resolving conflicts and generating a closed-loop confirmation object, and generating and outputting a structured round-trip summary object based on the confirmed data record and the closed-loop confirmation object, includes: The data diverted to the conflict queue is fully collected from multiple candidate event versions to form a candidate event set, and the conflict record object is generated. Upon receiving the manual intervention instruction, the valid data field content is determined. The valid data field content, together with the operation intervention time and the identification of the operating medical personnel, is encapsulated to generate the closed-loop confirmation object. The remaining candidate event versions that were not selected are updated to an archived and hidden state and retained in the underlying audit storage. Extract the confirmation data records and the closed-loop confirmation object from the confirmation queue, and fill them into the electronic medical record structure template by combining the generated conflict summary details and upload processing summary information to generate the structured round of visits summary object; Extract the unique event identifier, the fusion key, and the current bound version identifier from the unified event format record, combine them to generate a low-level traceability pointer, and write the low-level traceability pointer, along with the source system identifier and the closed-loop confirmation object reference, into the metadata node dictionary of the structured inspection summary object to establish a system low-level audit reference traceability chain and backfill it in a controlled manner.

[0019] By adopting the above technical solution, fields identified as conflicting do not directly overwrite the original records. Instead, a set of multiple versions of events is retained and the conflict record object is generated. After personnel operation confirmation, the closed-loop confirmation object is generated, avoiding data overwriting between different systems. At the same time, the unique event identifier, the fusion key, and the reference content of the closed-loop confirmation object are fixed in the roundtable summary object, improving the traceability of medical record archiving.

[0020] The second aspect of this application provides a smart glasses-based mobile clinic session binding and data consistency fusion system, which adopts the following technical solution: A smart glasses-based mobile clinic session binding and data consistency fusion system includes: The session management module is used to perform patient identity and bed verification to establish session binding objects, record state transition data during the lifecycle of the rounds session, and generate session snapshot objects. The front-end interaction module is used to collect bedside data and perform data retransmission and synchronization in conjunction with the session snapshot object in a weak network environment; The data fusion module is used to construct a unified event format record from multi-source medical data, extract the attributes of the unified event format record to generate a fusion key, calculate a fusion score object based on a multidimensional consistency metric, and distribute the unified event format record to a confirmation queue, a pending review queue, or a conflict queue based on the fusion score object. The conflict audit module is used to compare the session snapshot object with the data retransmission synchronization record to perform attribution verification, generate a conflict record object for the data diverted to the conflict queue, obtain manual intervention instructions for the conflict record object to complete conflict resolution and generate a closed-loop confirmation object, extract the confirmation data record in the confirmation queue, generate a structured round-trip summary object based on the confirmation data record and the closed-loop confirmation object, and output it.

[0021] By adopting the above technical solutions, the system reduces the risk of data mix-ups by performing multi-factor patient and bed verification and session status management. The unified event format record and the fusion key introduced by the fusion module ensure the correct data attribution and achieve field-level consistency fusion. Conflict classification, multi-version retention and closed-loop confirmation are performed through audit closed-loop actions, which avoids data from different systems from overlapping and improves the traceability of output data archiving.

[0022] Furthermore, the front-end interaction module includes a multi-factor acquisition unit and an edge preprocessing unit; The session management module includes an identity verification unit and a state machine management unit; The data fusion module includes an event conversion unit and a field fusion unit; The conflict audit module includes an isolation classification unit and a closed-loop generation unit.

[0023] By adopting the above technical solutions, the unit composition of each module of the system has been further refined, and the boundaries and execution logic of the underlying data processing have been clarified.

[0024] Furthermore, the included physical device nodes include smart glasses, edge gateways, mobile clinic management service terminals, and hospital information service terminals; The front-end interaction module runs on the smart glasses and the edge gateway; The session management module, the data fusion module, and the conflict audit module run in the outpatient visit management server, and the outpatient visit management server controls the backfilling and output of the structured outpatient visit summary object to the hospital information server.

[0025] By adopting the above technical solution, the physical execution nodes and module operation positions of the end, edge, and cloud collaborative distribution are clarified, ensuring that the system's preset logical instructions can be controlled, scheduled, and output normally.

[0026] This application provides a method and system for integrating smart glasses-based mobile clinic sessions with data consistency. It offers the following advantages: 1. This application establishes a session binding object by obtaining independent verification factors to perform patient identity and bed verification, records state transition data to generate a session snapshot object during the lifecycle of the rounds session, and combines the session snapshot object to record and perform data retransmission synchronization and attribution verification of multi-source medical data in a unified event format, thereby reducing the risk of data mix-ups with patients and ensuring the correct attribution of data after retransmission in a weak network.

[0027] 2. This application generates a fusion key by extracting attributes from the unified event format records and concatenating them, and opens a corresponding field fusion queue. It then performs a weighted calculation based on identity consistency score, time consistency score, source credibility weight, numerical consistency score, and doctor confirmation weight to output a fusion score value, which constitutes a fusion score object. Based on the fusion score object, the unified event format records are split into execution queues, thus achieving field-level consistency fusion.

[0028] 3. This application generates conflict record objects by collecting candidate event sets of data diverted to the conflict queue to retain multiple candidate event versions, receives manual intervention instructions to generate closed-loop confirmation objects to avoid data from different systems overlapping each other, and writes the generated underlying traceability pointers into the metadata node dictionary of the structured round summary object to establish a system underlying audit reference traceability chain, thereby improving the traceability of medical record archiving. Attached Figure Description

[0029] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0030] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0031] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0032] Figure 1 This is a system architecture diagram of the smart glasses mobile clinic session binding and data consistency fusion system in the embodiments of this application; Figure 2 This is a flowchart of the smart glasses-based mobile clinic session binding and data consistency fusion method in this application embodiment; Figure 3 This is a flowchart illustrating the patient identity and bed allocation verification process in this application embodiment; Figure 4 This is a schematic diagram of the unified event format and fusion key for multi-source data in an embodiment of this application; Figure 5 This is a flowchart illustrating the field-level consistency fusion and conflict routing process in the embodiments of this application; Figure 6 This is a flowchart of the weak network retransmission attribution verification, conflict detection, and doctor confirmation in the embodiments of this application. Figure 7 This is a comparison chart of the amplitude spectrum of the heart rate field in the weak network compensation embodiment of this application; Figure 8 This is a comparison diagram of the power spectrum of the fusion scoring sequence in the embodiments of this application. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0034] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0035] For ease of description, spatial relative terms may be used in the text to describe the relative position or movement of one element or feature relative to another element or feature, as shown in the figure. These relative terms include, for example, "inside," "outside," "middle," "outer," "below," "below," "above," "front," "back," etc. Such spatial relative terms are intended to include different orientations of the device in use or operation, other than those depicted in the figure. For example, if the device in the figure undergoes a positional flip, orientation change, or change of motion, these directional indications will change accordingly. For instance, an element described as "below other elements or features" or "below other elements or features" will subsequently be oriented "above other elements or features" or "above other elements or features." Therefore, the example term "below" can include both upper and lower orientations. The device may be otherwise oriented (rotated 90 degrees or in other directions), and the spatial relative descriptors used in the text will be interpreted accordingly.

[0036] See attached document Figure 1 This application provides a smart glasses-based mobile clinic session binding and data consistency fusion system, including a front-end interaction module, a session management module, a data fusion module, and a conflict audit module.

[0037] The physical device nodes involved in this system mainly include smart glasses, edge gateways, mobile clinic management servers, and hospital information servers.

[0038] The smart glasses are used to collect data from wristbands, bedside signs, bedside images, doctor and patient voice recordings, and doctor's operating instructions. They extract multimodal recognition data and collected features, and perform local caching in weak network environments. The edge gateway connects to the smart glasses and receives event data and cached data packets from the smart glasses, performing local caching, duplicate packet identification, preliminary desensitization, and retransmission sorting in case of network outages.

[0039] The outpatient visit management server handles the outpatient visit session lifecycle, multi-source data consistency calculations, binding version maintenance, session snapshot comparison, and weak network attribution verification. The hospital information server includes data interfaces for the hospital information system, electronic medical record system, laboratory system, imaging system, nursing system, and monitoring equipment. It provides the outpatient visit management server with historical medical records, multi-source laboratory and examination reports, and vital sign data, and receives controlled archived records confirmed by doctors from the outpatient visit management server.

[0040] The front-end interaction module includes a multi-factor acquisition unit and an edge preprocessing unit. The multi-factor acquisition unit runs on the smart glasses and is used to collect wristband information, bedside image, near-field communication data, indoor positioning data, bedside image, doctor and patient voice, and doctor's operation instructions when medical staff arrive at the patient's bedside. It combines the acquisition timestamp to generate device identifier, local serial number, content hash value, and acquisition timestamp.

[0041] The edge preprocessing unit runs on the edge gateway and is used to receive data sent by the multi-factor acquisition unit. It uses content hash values ​​to identify and remove duplicate data packets. During network interruption, it packages the acquired content into a network outage cache packet and stores it in the local cache queue. After the network is restored, it sorts and transmits the retransmitted data according to the local sequence number and acquisition time, and performs cache encryption, hash deduplication, network outage queue sorting, and preliminary desensitization.

[0042] The session management module includes an identity verification unit and a state machine management unit. The identity verification unit receives independent verification factors from the front-end interaction module, calculates a multi-factor matching score based on the matching characteristics and preset weights of each factor, and confirms the correspondence between the patient and the bed when the score reaches a preset threshold, establishing a session binding object. When at least two of the following factors match (wristband, bedside card, near-field communication, location, face, or voiceprint) and the multi-factor matching score reaches the threshold, the identity verification unit allows the establishment of a round-the-clock session. If the patient has been transferred to another bed, the bedside card and wristband are inconsistent, or the doctor's permissions are insufficient, the system enters an identity suspension state.

[0043] The state machine management unit is used to maintain the state transition record of the rounds session throughout its entire lifecycle. It triggers the increment of the binding version based on patient transfer, bed change, patient re-identification, doctor re-entering the same bed and re-verification, session abnormal recovery, patient master index or bed table update operations. It also captures the current state data to generate a session snapshot object each time the state transition or binding version changes.

[0044] The data fusion module includes an event conversion unit and a field fusion unit. The event conversion unit interfaces with the hospital's information service terminal, parses and extracts key data fields from bedside data, vital sign data, laboratory reports, imaging reports, past medical records, doctor's notes, system prompts, and doctor confirmation records from different systems, and converts them into a unified event format record containing source time, reception time, verification status, binding version identifier, content hash value, and doctor identifier.

[0045] The field fusion unit is used to generate fusion keys based on the attributes of unified event records. Unified event records with the same fusion key and whose session snapshot attribution verification has passed are restricted to the same fusion calculation queue. Based on identity consistency, time consistency, source credibility, numerical consistency and doctor confirmation status, a fusion score object for the same field is calculated and generated. Based on the fusion score object, the event is diverted to the confirmation queue, the pending review queue or the conflict queue.

[0046] The conflict auditing module includes an isolation classification unit and a closed-loop generation unit. The isolation classification unit receives network-disconnected cache packets sent by the front-end interaction module in network retransmission scenarios. It compares the historical session snapshots carried in the network-disconnected cache packets with the current session snapshot on the server. When it determines that the original session has been closed, the patient has been transferred to another bed, the doctor has entered a new patient session, or the binding version has changed, it intercepts the corresponding data's medical record write request and stores the data in the isolation record pool. Simultaneously, it categorizes data with conflicts in patient, bed, retransmission, value, version, or source under the same fusion key, retaining candidate events for each version to generate conflict record objects.

[0047] The closed-loop generation unit provides a manual intervention interface to display conflict record objects and data in the isolation record pool. After obtaining front-end intervention instructions, it generates a closed-loop confirmation object. At the end of the round of visits, it extracts the confirmation queue, the queue to be reviewed, the conflict record objects, and the closed-loop confirmation objects to generate a structured round of visits summary object, establishes the underlying audit reference traceability chain, and backfills the controlled data to the hospital information service terminal.

[0048] See attached document Figure 2 This application provides a method for integrating smart glasses-based mobile clinic sessions with data consistency, comprising the following steps: S1. Multi-factor patient identity and bed verification are performed through the identity verification unit in the session management module to establish a session binding object, and the state machine management unit maintains the state transition records and generates session snapshot objects within the life cycle of the round of visits session.

[0049] S2. Collect bedside data through the front-end interaction module and generate and retransmit local network outage cache packets in weak network environments. At the same time, use the event conversion unit in the data fusion module to construct medical data from different system sources into a unified event format record.

[0050] S3. The field fusion unit in the data fusion module generates a fusion key based on the attributes recorded in the unified event format. It calculates the fusion scoring object based on identity, time, source, value and doctor confirmation dimensions, and performs field-level data consistency routing based on the fusion scoring object.

[0051] S4. By comparing the session snapshot object with the isolation classification unit in the conflict audit module, the data to be retransmitted is subjected to attribution verification and data isolation processing. For data with conflicts under the same fusion key, multiple candidate event versions are retained to generate conflict record objects for closed-loop confirmation processing.

[0052] S5. Through the closed-loop generation unit in the conflict audit module, obtain manual intervention instructions to resolve multi-version conflicts, extract the confidence field and closed-loop confirmation object to generate a structured round-trip summary object, and establish a system-level audit reference traceability chain to backfill the output to the hospital information service terminal.

[0053] To more clearly demonstrate the design logic and technical details of this application, the specific implementation methods of each step in the smart glasses mobile clinic session binding and data consistency fusion method will be described in detail below.

[0054] See attached document Figure 3 In the context of smart glasses-based mobile clinics, ensuring accurate attribution of medical data hinges on precisely establishing the binding relationships between patients, beds, doctors, and the current clinic cycle. Based on this, effective status tracking and time-slicing are the underlying foundation for preventing data mismatches in weak network environments. Specifically, the multi-factor authentication and clinic session state snapshot management process is implemented through the following sub-steps: S101. Collect identity and location data from various physical carriers in the bedside environment through smart glasses, and extract feature information that constitutes independent verification factors.

[0055] After medical staff wearing smart glasses arrive at the patient's bedside, they acquire environmental identifiers through onboard image sensors, radio frequency modules, indoor positioning modules, or bedside recognition components. The acquired identifier information includes features extracted from the QR code and near-field communication radio frequency signals on the patient's wristband, features extracted from the optical characters on the bedside sign, and indoor positioning coordinate features resolved by receiving Bluetooth beacons in the ward. It may also include facial recognition features, voiceprint recognition features, and the current medical record information opened by the doctor.

[0056] The identity verification unit has established a physical carrier exclusion rule for the collected information. This means that data in different formats on the same physical carrier are not counted as two independent verification factors. For example, near-field communication chip data and QR code data integrated on the same patient wristband are output as only one independent verification factor; however, the QR code features on the patient wristband and the optical character features on the bedside sign are extracted as two independent verification factors because they are attached to different physical carriers. A valid combination must include at least one of the following: wristband QR code and bedside sign optical characters, wristband near-field communication and in-hospital positioning, facial recognition and bed positioning, wristband QR code and hospital number verification, and voiceprint recognition and the doctor's currently accessed medical record.

[0057] S102. Calculate the multi-factor matching score based on the extracted independent verification factors, and confirm the identity verification result to establish a session binding object when the multi-factor matching score reaches the set threshold.

[0058] After receiving at least two independent verification factors uploaded by the front-end interaction module, the identity verification unit compares them with the patient master index, bed table, hospital number, transfer record, and doctor permissions in the hospital information service. A weighted calculation is then performed based on the comparison confidence level and pre-assigned weights. The specific formula is as follows: ; in, For multi-factor matching scoring; The number of independent verification factors; The serial number of the independent verification factor; For the first Factor weights for each independent verification factor; For the first Factor confidence levels for each independent verification factor; This is the summation operator.

[0059] Because the uniqueness of identity verification via wristband QR code, near-field communication, and patient master index is higher than that of optical characters, indoor positioning, face, and voiceprint, the identity verification unit assigns higher factor weights to wristband QR code, near-field communication, and patient master index verification than to optical characters, indoor positioning, face, and voiceprint. After calculating the multi-factor matching score, the identity verification unit compares it with a preset matching threshold, which is configured to range from 0.75 to 0.90. For emergency departments or isolation wards, the preset matching threshold is increased according to the departmental template.

[0060] When the multi-factor matching score is greater than or equal to the preset matching threshold, the identity verification unit determines that the patient's identity matches the current bed correctly, and then generates an identity verification object containing a session identifier, patient verification factors, bed verification factors, doctor identifier, multi-factor matching score, failure reason, and factor details. Once the identity verification object passes verification, the identity verification unit instantiates a session binding object in memory, writing the session identifier, patient identifier, bed identifier, doctor identifier, binding time, binding factors, binding version identifier, and binding reason into the session binding object. If the patient has been transferred to another bed, the bedside card and wristband are inconsistent, or the doctor's permissions are insufficient, the identity verification object records the failure reason and puts the rounds session into an identity suspension state, preventing the establishment of formal rounds sessions.

[0061] S103. Configure the binding version identifier in the session binding object, and perform dynamic increment control on the binding version identifier according to the preset ward round scenario trigger conditions.

[0062] At the initial creation of the session binding object, the state machine management unit initializes the internal binding version identifier to 1. During the rounds, the state machine management unit monitors change events and medical staff operation instructions from the hospital information server in real time. Once it detects a patient physical transfer, bed change, medical staff issuing a re-identification instruction for a patient in the same bed, a doctor re-entering the same bed and re-verifying, session abnormal recovery, or the hospital information server broadcasting a patient master index update event or bed table update event, the state machine management unit forcibly increments the binding version identifier within the session binding object by 1.

[0063] The dynamically incrementing binding version identifier forms a unidirectional, progressive timeline baseline, enabling the state machine management unit to identify data belonging to historical binding versions by verifying the version baseline carried in the data packets when subsequently receiving offline backlog data. Old version data can be retransmitted, but can only be verified against sessions of the same version at the time of collection. If the current server record has already entered a new version, old data cannot be directly written to the new binding version; it can only enter the isolation record pool or be generated as a new version after confirmation by a doctor.

[0064] S104. Based on time thresholds, network connection status, and medical staff operation instructions, control the flow of the rounds session between preset state enumeration values, and extract time slices to generate session snapshot objects when the state changes or the bound version identifier changes.

[0065] The state machine management unit breaks down the session lifecycle into creation, verification, rounds, pause, pending transmission, confirmation, submission, closing, and abnormal closing states. When the smart glasses detect a network disconnection, the state machine management unit automatically transitions the current session from the rounds state to the pending transmission state. When the medical staff stops inputting data for longer than the set idle timeout threshold, the state transitions to the pause state. When the doctor leaves the bedside area or a new bed is identified, the state machine management unit restores the original session or creates a new session based on the re-verification result. Each state change generates a state transition record containing the session identifier, starting state, target state, operator, trigger source, timestamp, and reason code.

[0066] At the instant any state node transition occurs or the binding version identifier increments, the state machine management unit immediately triggers a snapshot capture action, freezing the current patient identifier, bed identifier, session identifier, current binding version identifier, current enumeration state, last event sequence number, and snapshot time. This frozen field is then packaged and solidified into a session snapshot object. This session snapshot object represents the precise physical association state between the patient, doctor, and bed at the capture moment. Both the weak network cache packet and the retransmission packet carry the most recently captured session snapshot object. For the node transition control flow of the state machine, those skilled in the art can use a conventional finite state automaton model; its state transition logic is well-known in the field and will not be elaborated upon here.

[0067] See attached document Figure 4 After establishing accurate patient binding relationships and time status benchmarks, the data fusion module faces the challenges of standardizing massive amounts of heterogeneous bedside data and ensuring reliable transmission in complex physical environments. To address data barriers arising from different devices and the risks of packet loss and duplicate uploads caused by mobile network fluctuations, the unified access and offline cache synchronization process for multi-source medical data is achieved through the following sub-steps: S201. Receive bedside feature streams and report data from different hardware nodes and business systems through the communication interface in the front-end interaction module.

[0068] The front-end interaction module receives bedside images, doctor-patient voices, doctor's operation instructions, and optically extracted features captured by the smart glasses; it also receives continuous vital signs reports of heart rate, blood pressure, body temperature, and blood oxygen saturation continuously output by the bedside monitoring equipment.

[0069] Simultaneously, the event conversion unit extracts the structured electronic medical record summary of the specified patient, the test results output by the laboratory system, the image report output by the imaging system, nursing system events, doctor's notes, and system prompts from the hospital information server. All data from these different sources maintain their original independent encoding and message format before entering the data fusion module.

[0070] S202. The parsed polymorphic medical data is mapped and reorganized into a unified event format record with standardized constraints using the event conversion unit in the data fusion module.

[0071] The event conversion unit performs a disassembly operation on the incoming heterogeneous packets, extracting the payload and accompanying timestamps from each data stream. The event conversion unit constructs a standard unified event format record structure in memory, fills the extracted payloads into the corresponding field values, and fills the extracted timestamps into the source time field.

[0072] To ensure data traceability throughout the entire data processing lifecycle, the event conversion unit writes the session identifier, patient identifier, bed identifier, doctor identifier, binding version identifier generated in step S1, and the locally generated serial number from the smart glasses into this structure. Through this mapping operation, the originally disparate audio loops, bedside images, vital sign value strings, and text reports are all converted into unified event format records, eliminating data heterogeneity between different business systems.

[0073] S203. Extract key attributes from the unified event format record, perform hash operation to generate content hash value, thereby identifying and intercepting redundant data packets caused by network retransmission.

[0074] Due to duplicate uploads caused by weak network conditions, the edge preprocessing unit introduces packet deduplication logic at the edge gateway. This logic combines key attributes from the unified event format records using preset concatenation rules. The specific calculation formula is as follows: ; in, The content hash value; It is a hash function; To normalize field names; To normalize the values ​​of the field; Source time; For the source system; This is the local serial number; To bind the version identifier; This is a string concatenation operator.

[0075] When the edge preprocessing unit receives uploaded data records, it calculates the corresponding content hash value in real time and uses it in conjunction with the local sequence number to deduplicate the retransmitted data. If the edge preprocessing unit identifies the same content hash value or the same local sequence number, it determines the data packet as duplicate retransmitted data and discards it, thereby preventing duplicate events from entering the consistency analysis stage.

[0076] S204. During the period when the wireless network connection is detected to be interrupted, the collected information to be transmitted is encapsulated into a network disconnection buffer packet and stored in the local memory, and synchronous transmission is initiated in ascending order after the network connection is restored.

[0077] When the front-end interaction module detects a network interruption or weak network condition, it suspends the operation of directly writing data to the server. It then combines and packages the real-time collected information from the smart glasses with the session snapshot object captured in step S1, creating a network outage cache package. The cache package contains a data packet identifier, session identifier, session snapshot object, device identifier, local serial number, event type, collection time, content hash value, and payload pointer. After receiving the network outage cache package, the edge preprocessing unit performs local caching, hash deduplication, network outage queue sorting, preliminary desensitization, and encrypted caching.

[0078] After network recovery, the edge preprocessing unit reads the set of network outage cache packets from local storage, extracts the session snapshot object and local sequence number recorded in each cache packet, and uploads the cached data in order of the session snapshot object and local sequence number, ensuring that data backlogged due to network fluctuations can arrive at the server in the order it was collected. For the specific implementation of feature extraction using hash algorithms, those skilled in the art can use conventional secure hash algorithm function libraries; the principle of hash operation is well-known in the field and will not be elaborated here.

[0079] See attached document Figure 5 After completing the standardized access and anti-duplicate filtering of multi-source heterogeneous data, the data fusion module accumulated a large number of medical events with a unified format. Due to time differences in data updates across different business systems and varying sources of reliability, directly merging these independent events could easily lead to version overwriting or numerical errors in medical record fields. Therefore, the field fusion unit must ensure accurate merging and secure distribution of data within the same round of visits through strict boundary isolation and multi-dimensional reliable quantification scoring. Specifically, the field-level consistency distribution process based on the fusion key and scoring model is implemented through the following sub-steps: S301. Generate a fusion key by combining the identity identifier and session identifier embedded in the unified event format record. Use the fusion key to establish data boundaries so as to force the corresponding unified event format record to be assigned to the corresponding fusion calculation queue.

[0080] Upon receiving a record in the unified event format, the field fusion unit extracts the patient identifier, bed identifier, session identifier, field name, time window, binding version identifier, and source range from the record. The field fusion unit then concatenates these extracted dimension identifiers sequentially according to preset delimiters to generate a unique fusion key string. The specific formula is as follows: ; in, For fusion bond; Identify patients; For bed identification; For session identification; For field names; For time windows; To bind the version identifier; For the scope of sources; This is a string concatenation operator.

[0081] The fusion key constitutes the boundary of the data fusion operation. The field fusion unit allocates a corresponding field fusion queue in memory for each independent fusion key. Only when the fusion key parsed from the incoming unified event format record is completely consistent with the fusion key in the current queue, and the session snapshot attribution verification passes, does the field fusion unit allow the record to be pushed into the queue to participate in subsequent numerical merging operations. Through this grouping and isolation mechanism, the field fusion unit prevents data from being overwritten across patients, beds, or bound versions due to network latency or patient bed transfers.

[0082] S302. Extract the attribute parameters of the unified event format records in the fusion calculation queue, perform multi-dimensional normalization operations, and generate a fusion score object that represents the fusion confidence of the data field.

[0083] Within a single fusion computing queue, the field fusion unit extracts the associated attributes from multiple record sources for the same data field, and constructs a quantitative model by integrating five dimensions: identity consistency, time consistency, source credibility, numerical consistency, and doctor confirmation status. The specific calculation formula is as follows: ; in, This is the integration score; Score for identity consistency; Score for time consistency; As a weight for the credibility of the source; Score for numerical consistency; Confirm the weight for the doctor; , , , and The preset weights for each department template are defined. These preset weights for the department template satisfy the following constraints: ; in, , , , and These represent the preset weights for the department templates; 1 represents the normalization constraint value.

[0084] When calculating dimensional scores, the identity consistency score is determined by whether the patient identifier, bed identifier, and bound version identifier are consistent; the time consistency score is determined by the distance between the source time and the current rounds time window; the source credibility weight is determined by the source system and the review status; the numerical consistency score is determined by the difference in candidate values ​​for the same-named field; and the doctor confirmation weight is determined by whether the doctor has confirmed or modified the data. Through this calculation process, the field fusion unit outputs a range-normalized fusion score to measure the reliability of the field data.

[0085] S303. Identify the specific data type carried in the unified event format record and match the corresponding differentiated fusion and merging strategy when performing fusion score calculation.

[0086] Medical data exhibits diverse clinical attributes, and the field fusion unit implements different feature merging actions based on business characteristics. For continuously acquired vital sign data such as heart rate, blood pressure, body temperature, and blood oxygen saturation, the field fusion unit generates trend events based on time series, and enters a pending confirmation process when abnormal jumps occur or when interface data differs from manually recorded data. For report data output from the laboratory and imaging systems, the field fusion unit prioritizes review status, report time, and source system, with reviewed reports taking precedence over unreviewed drafts.

[0087] For voice conversations and bedside images captured by smart glasses, the field fusion unit processes them as supplementary candidate supporting materials for medical record fields, and binds them to the round, location, and collection time. For doctor confirmation records, the field fusion unit configures them to have the highest priority, generating a new data version of the doctor confirmation record and archiving the old data version.

[0088] S304. Compare the fusion score with the multi-level blocking threshold set by the system, and distribute the corresponding unified event format record to the processing queues at different levels based on the comparison result.

[0089] The field fusion unit pre-sets a confidence threshold and a review threshold in the parameter configuration table, with the confidence threshold being strictly greater than the review threshold. The field fusion unit reads the calculated fusion score. When the fusion score is determined to be greater than or equal to the confidence threshold and no conflict is found, the field data is considered reliable and is guided to the confidence queue to prepare for the medical record archiving stage.

[0090] When the fusion score is determined to be greater than or equal to the review threshold but strictly less than the confidence threshold, the field fusion unit distributes it to the review queue, marking the data as having slight fluctuations. When the fusion score is determined to be strictly less than the review threshold or there is a data conflict, it is determined that the data deviates from the known facts within the current rounds, and it is locked in the conflict queue, preventing its direct overwriting of formal medical records. The calculation logic for the sequence fluctuation slope and numerical variance can be handled by those skilled in the art using conventional statistical calculation libraries; the statistical algorithms are well-known in the field and will not be elaborated upon here.

[0091] See attached document Figure 6 After consistency scoring and triage control, the data fusion module can filter out data with high credibility and directly enter the archiving process. However, in real clinical ward environments, delayed data caused by network connection interruptions often carries outdated status information, and the differences in values ​​from multiple sources inevitably input contradictory records into the data fusion module. To prevent crosstalk and errors caused by historically outdated data and to ensure the traceability of medical facts in contradictory scenarios, the conflict auditing module introduces an interception control and conflict full retention mechanism based on snapshot comparison. Specifically, the retransmission isolation verification and multi-version conflict confirmation process is implemented through the following sub-steps: S401. The isolation classification unit in the conflict audit module receives the network outage cache packet uploaded by the front-end interaction module after the weak network environment is restored, and performs attribution verification and interception by comparing the status data in the network outage cache packet to achieve physical anti-crosstalk isolation.

[0092] Upon receiving the network disconnection cache packet, the isolation and classification unit parses and extracts the encapsulated historical session snapshot object, and then extracts the historical patient identity, historical bed identity, historical binding version identity, and historical session state recorded in the object. Simultaneously, the isolation and classification unit reads the current session snapshot object maintained in real-time by the state machine management unit in the server's memory, and extracts the current patient identity, current bed identity, current binding version identity, and current session state.

[0093] To verify the legitimate attribution of late data, the isolation classification unit executes the underlying Boolean decision logic. The specific attribution verification formula is as follows: ; in, This is the value of the attribution verification result; For historical version identification; This is the identifier for the currently bound version; For identifying historical patients; This serves as the current patient's identification identifier; For historical bed identification; This is the current bed identifier; This is the state of a historical session; This represents the current session state. For logical AND operator.

[0094] When the calculated attribution verification result is false, or the original session has been closed, the patient has been transferred to another bed, or the binding version identifier has changed during the retransmission, the isolation classification unit determines that the batch of retransmitted data should not be directly written to the current patient or the current bed. The isolation classification unit immediately blocks the request to write the data records in the network outage cache packet to the target medical record database from the bottom layer, and strips and transfers the batch of data to the isolation record pool, thereby forming anti-crosstalk isolation.

[0095] S402. Extract multi-dimensional attributes from the data diverted to the conflict queue, perform deviation analysis, identify the specific causes of the conflict, and label them with the corresponding conflict attribute tags.

[0096] For the unified event format records that are sent to the conflict queue in step S3 due to insufficient fusion score or conflict, the isolation classification unit extracts multiple records under the same fusion key and compares the patient identifier, bed identifier, binding version identifier, source system identifier, source time and field values ​​within them.

[0097] When the isolation classification unit finds inconsistent patient identifiers, it marks them as patient mismatch; when the bed identifiers are inconsistent, it marks them as bed mismatch; when data retransmission from a weak network is late and inconsistent with the current session state or version, it marks it as late upload; when the field values ​​of multiple records differ from the preset tolerance range, it marks them as numerical mismatch; when the binding versions are inconsistent, it marks them as version mismatch; when there are inconsistencies between the source systems, it marks them as source mismatch.

[0098] S403. Collect all conflicting data versions under the same fusion key to form a candidate event set, and encapsulate and generate a conflict record object containing data contradiction details and risk rating.

[0099] After marking the conflict attributes, the isolation classification unit allocates a specific memory set structure for all uniform event format records currently in the conflict queue that have the same fusion key. The isolation classification unit does not perform automatic overwrite operations, but treats conflicting old version data records and newly arrived data records as equivalent candidate event versions, collects all candidate event versions, and populates them into the memory set structure to form a candidate event set.

[0100] The isolation and classification unit reads the candidate event set, extracted conflict attribute identifiers, and a preset conflict severity classification dictionary, and combines them to generate a conflict record object containing a conflict identifier, fusion key, conflict type, candidate event set, conflict cause, severity, and doctor's action. The isolation and classification unit then dumps this conflict record object into a closed-loop pool in the database, awaiting subsequent manual intervention and comparison by medical personnel. The specific operations for generating the data object and mapping the database can be handled by those skilled in the art using conventional relational database table structure mapping techniques; the data storage operations are well-known in the field and will not be elaborated upon here.

[0101] Following the preceding fusion, triage, and conflict isolation mechanisms, the conflict audit module has precisely separated secure and reliable data from controversial and contradictory data. To ensure that the data ultimately archived into the target medical record database possesses clinical responsibility attribution and factual traceability capabilities, the conflict audit module introduces a closed-loop operation for physician-authorized intervention, and on this basis, constructs a final data backfilling mechanism with underlying traceability pointers. Specifically, the structured rounds summary aggregation and system audit traceability process is implemented through the following sub-steps: S501. The closed-loop generation unit uses a human-computer interaction terminal to display conflict details, receives manual intervention instructions to generate closed-loop confirmation objects, and forcibly updates the status of unadopted old version data to the archived and hidden status.

[0102] The closed-loop generation unit renders and displays the conflict record objects in the pending closed-loop pool and the data in the isolation record pool through the human-computer interaction interface of the hospital workstation terminal or smart glasses. The closed-loop generation unit receives manual intervention instructions from medical staff regarding the conflict record object or the data in the isolation record pool. The types of manual intervention instructions received include adopting a single version, merging multiple versions, or modifying field values.

[0103] The closed-loop generation unit determines the final valid data field content based on the parsed manual intervention instructions. This valid data field content, along with the intervention time and the medical personnel identifier, is encapsulated to generate a closed-loop confirmation object containing a conflict identifier, doctor identifier, action, final value, new version number, and confirmation time. The closed-loop generation unit updates the versions of other candidate events within the same conflict record object that were not selected by the instruction to an archived and hidden state, stripping them of their direct participation in business calculations and retaining them in the underlying audit storage for traceability.

[0104] S502. After detecting the completion trigger signal of the round of visits, extract the highly reliable data records inside the confidence queue and synthesize them with the generated closed-loop confirmation object to form a complete structured round of visits summary object.

[0105] When the state machine management unit receives the round-trip end instruction issued by the medical staff and triggers the state transition to complete, the closed-loop generation unit actively scans the memory space associated with the current round-trip session identifier, extracts the high-confidence data records currently in the confidence queue, and extracts the closed-loop confirmation object generated in step S501 in parallel.

[0106] The closed-loop generation unit retrieves the processing records from the isolation classification unit within the current rounds cycle to generate conflict summary details and uploaded processing summary information. The closed-loop generation unit reads a preset electronic medical record structure template and fills the confirmation queue data, closed-loop confirmation objects, conflict summary details, and uploaded processing summary information into the corresponding paragraph nodes of the electronic medical record structure template, synthesizing them to generate a structured rounds summary object containing session identifiers, patient identifiers, bed identifiers, doctor identifiers, confirmed fields, pending fields, conflict summaries, and audit references.

[0107] S503. Write the underlying traceability pointer into the metadata node of the generated structured inspection summary object through a feature combination and splicing mechanism to establish an audit reference traceability chain.

[0108] To ensure the traceability of the final medical documents throughout the entire workflow, the closed-loop generation unit embeds an audit reference traceability chain in the underlying non-display fields of the structured medical record summary object. Specifically, for each valid medical data field within the structured medical record summary object, the closed-loop generation unit traces and extracts the unique event identifier, assigned fusion key, and current bound version identifier of the original unified event format record, and generates an underlying traceability pointer based on a combination and concatenation mechanism. The specific generation formula is as follows: ; in, This is a pointer for tracing back to the underlying level. Used as a unique identifier for the event; For fusion bond; This is the identifier for the currently bound version; This is a string concatenation operator.

[0109] The closed-loop generation unit forcibly writes the calculated underlying traceability pointer, along with the source system identifier and the closed-loop confirmation object reference, into the metadata node dictionary of the structured round summary object, thereby ensuring that every medical record field ultimately output can be traced back to the upstream original event, fusion key, version, source system, and doctor confirmation action.

[0110] S504. For data that has not completed conflict intervention operations, execute interception and filtering rules, and convert the verified structured data records into standardized interface protocol messages and backfill them to the corresponding hospital information service.

[0111] Before initiating a data backfill request to the hospital's business system, the closed-loop generation unit executes interception and filtering rules on the fields within the structured round-trip summary object. The closed-loop generation unit verifies the status of the pending closed-loop pool associated with the current round-trip cycle. If it determines that there are data objects that have not yet been processed by medical staff, the closed-loop generation unit forcibly removes the field objects corresponding to the unresolved data and refuses to perform cross-system synchronization operations.

[0112] The closed-loop generation unit extracts only highly reliable data and closed-loop confirmation data from the confidence queue, maps them according to the data type dictionary agreed upon by the hospital system interface module, and converts them into interface protocol messages conforming to the general medical data exchange standard. Data that fails the attribution verification must not be directly written into the official medical record. The closed-loop generation unit sends the interface protocol message through a pre-established network transmission channel and performs controlled backfilling and synchronization to various systems on the hospital information server. For the operation of converting internal memory structure data into interface protocol messages, those skilled in the art can use general data serialization components to implement it. The message structure conversion mechanism is a well-known technology in the field and will not be described in detail here.

[0113] Specific application examples: To better understand the technical solution of this application, the following detailed description is provided in conjunction with specific application scenarios and accompanying drawings. This specific application embodiment is built on a smart glasses-based system for collecting bedside rounds data and backfilling medical records in wards, involving session binding and data consistency fusion. This system runs within a rounds environment comprised of smart glasses, an edge gateway, a rounds management server, and a hospital information server. It is responsible for acquiring patient identity verification data, bedside vital signs data, doctor's voice recordings, laboratory report data, and nursing record data, and performing session binding, weak network retransmission, field fusion, conflict isolation, and closed-loop confirmation processing.

[0114] During the patient identity and bed verification phase, the identity verification unit in the session management module extracts wristband QR codes, bedside nameplate optical characters, and indoor positioning data to calculate a multi-factor matching score. The parameters are set as follows: factor weights corresponding to the wristband QR code. The factor confidence level is 0.40. The factor weight is 0.98; the factor weight corresponding to the optical characters on the bedside sign is 0.98. The factor confidence level is 0.25. The factor weight for indoor positioning is 0.92. The factor confidence level is 0.15. The score is 0.80. The identity verification unit is substituted into the formula to calculate the multi-factor matching score. : ; Substitute the values ​​into the calculation: ; The calculation results show that multi-factor matching score The score is 0.9275. The preset matching threshold is 0.85. Due to the multi-factor matching score... If the patient's identity exceeds the preset matching threshold, the identity verification unit determines that the patient's identity matches that of bed number 12. The system then establishes a session binding object and assigns a binding version identifier. Initialized to 1. When a session enters the rounds state, the state machine management unit captures the current patient identifier, bed identifier, session identifier, binding version identifier, current enumeration state, and last event sequence number, and generates a session snapshot object.

[0115] During the bedside data acquisition and retransmission synchronization phase, the edge preprocessing unit combines a unified event format to record and calculate the hash value of the content. The parameters are set as follows: Normalized field name for Normalize field values The value is 86, and the source time is... It is 09:18:10, and is recorded as such when substituting it into the calculation. Source system for Local serial number 0037 is the version identifier. The value is 1. The edge preprocessing unit is substituted into the formula to calculate the content hash value. : ; Substitute specific fields into the calculation: ; The calculation results show that the same normalized field name Values ​​of the same normalized field Same source time Same source system Same local serial number Same binding version identifier Able to be mapped to a consistent content hash value If the same hash value is received again after the network is restored. or the same local serial number If a data packet is detected as duplicate data by the edge preprocessing unit, the system will discard the data packet and block it from entering the field fusion queue.

[0116] After the unified event format conversion is completed, the field fusion unit generates a fusion key based on the patient identifier, bed identifier, session identifier, field name, time window, binding version identifier, and source range. The parameters are set as follows: Patient Identifier for Bed sign for Session identifier for field name for Time window It is from 09:15 to 09:20, and is recorded as such when substituting it into the calculation. ; Bind version identifier =1, source range for Substituting the field fusion unit into the formula generates the fusion key. : ; After substituting the fields, we get: ; The calculation results show that data from the same patient, the same bed, the same session, the same field, the same time window, and the same binding version are restricted to the same field fusion queue, which can prevent weak network retransmission data from entering the wrong fusion calculation boundary across patients, beds, or versions.

[0117] During the field fusion scoring phase, the field fusion unit combines the identity consistency score. Time Consistency Score Source credibility weight Numerical consistency score Confirm weight with doctor Calculate the fusion score The parameters are set as follows: Identity Consistency Score The time consistency score is 1.00. The source credibility weight is 0.92. The numerical consistency score is 0.95. The weight was 0.96, as confirmed by the doctor. The department template has a preset weight of 1.00. , , , and The values ​​are 0.28, 0.20, 0.18, 0.22, and 0.12, respectively. The field fusion unit is substituted into the formula to calculate the fusion score. : ; Substitute the values ​​into the calculation: ; The calculation results show that the fusion score value The value is 0.9662. The preset confidence threshold is 0.90, and the preset review threshold is 0.70. This is due to the fusion score. If the heart rate exceeds the preset confidence threshold and meets the confidence queue diversion condition, the field fusion unit determines that the heart rate field is confidence data, and the system writes it into the confidence queue and uses it as a valid field in the structured round-trip summary object.

[0118] When a patient is transferred to another bed at 09:23:00, the system re-executes the attribution verification step. The parameters are set as follows: the historical binding version identifier carried in the re-transmitted data. The value is 1, indicating the current version identifier bound to the server. 2; Historical patient identification With current patient identification Consistent, historical bed identification With current bed identifier Inconsistency, historical session state The current session state is pending retransmission. In the mobile clinic status. The isolation classification unit is substituted into the formula to calculate the attribution verification result value. : ; After substituting the parameters into this embodiment, because , And historical bed markings With current bed identifier Inconsistent, therefore: ; The calculation results show that the attribution verification result value A value of 0 indicates that the attribution verification failed. This is because the attribution verification result value... If the write conditions are not met, the isolation classification unit determines that the retransmitted data belongs to historical session snapshot data. The system activates the conflict audit module and transfers the retransmitted record to the isolation record pool. If the body temperature value in the retransmitted record is 37.8℃, while the current bedside monitoring body temperature value is 36.6℃, the system further includes it as a candidate event version in the conflict record object, waiting for the doctor to confirm the closed loop.

[0119] To verify the accuracy and stability of the response strategy, which includes session snapshots, content hashing for deduplication, fusion key grouping, fusion score routing, and attribution verification mechanisms, the system was tested against operational data under the same experimental environment. This embodiment selected 30 simulated outpatient visits, constructing 1080 multi-source event records, including 360 records of data re-uploaded after network outages, 90 records of duplicate uploads, and 45 records of cross-version conflicts. Compared to the conventional method of directly merging based solely on patient identifiers and field names, the number of duplicate writes in this application's system decreased from 90 to 0, the number of cross-version incorrect writes decreased from 18 to 0, the manual traceability rate of conflicting fields increased from 62.2% to 100%, and the traceability rate of field sources in the structured summary increased from 71.5% to 100%.

[0120] See attached document Figure 7 , Figure 7 The horizontal axis represents frequency, and the vertical axis represents amplitude. Conventional retransmission processing methods lack content hashing for deduplication, local sequence number sorting, and fusion key boundary constraints, resulting in multiple abnormal peaks in the heart rate retransmission sequence in the spectrum. The original retransmission sequence exhibits a main peak with an amplitude exceeding 300 at approximately 0.035 Hz, corresponding to the main low-frequency changes in the heart rate field over time. A peak with an amplitude of approximately 160 to 170 appears at approximately 0.09 Hz, a continuous peak cluster with an amplitude of approximately 40 to 70 appears in the range of approximately 0.30 Hz to 0.35 Hz, and a sudden surge peak with an amplitude exceeding 120 appears near approximately 0.42 Hz. After employing content hashing for deduplication, offline retransmission sorting, and a fusion scoring and distribution mechanism, the fused sequence retains the main low-frequency peak at approximately 0.035 Hz, but significantly reduces the mid-to-high frequency abnormal components at approximately 0.09 Hz, approximately 0.30 Hz to 0.35 Hz, and approximately 0.42 Hz. The results validate the ability of this application to suppress abnormal disturbances in weak network retransmission while preserving real changes in vital signs.

[0121] Based on the completion of the spectral verification of the heart rate retransmission sequence, in order to further verify the effectiveness of cross-version isolation in patient transfer and historical data retransmission scenarios, the system compared the power spectra of the fused scoring sequence with and without version isolation enabled.

[0122] See attached document Figure 8 , Figure 8 The horizontal axis represents frequency, and the vertical axis represents power. Conventional processing methods lack a homepage verification mechanism based on session snapshots and binding version identifiers. The fused scoring sequence maintains high power across a wide frequency band, with significant power increases around approximately 0.17Hz and 0.31Hz, and some frequency bands approaching -10dB to -20dB. This indicates that the mixing of historical binding version data with the current session causes periodic or sudden fluctuations in the fused score. This application introduces a homepage verification result value into the system. By blocking inconsistent historical binding versions, bed locations, or session states in the isolation record pool, the overall power spectrum of the data decreased, with most frequency bands stabilizing in the range of approximately -40dB to -50dB, and no further prominent peaks of the same magnitude as the isolation curve of the disabled version reappeared. This result verifies the ability of this application to ensure the stability of fusion scoring and the security of medical record backfilling in scenarios such as weak network retransmission, patient bed transfer, and delayed historical session data.

[0123] The combined calculation results and the verification results in the attached figures show that this application does not simply perform smoothing processing on medical data, but rather limits data ownership through session binding objects and session snapshot objects, and uses content hash values. and local serial number Identify duplicate transmissions using the fusion key. Define the field fusion boundary, complete the confirmation, review and conflict separation through the fusion scoring object, and verify the attribution result value. The closed-loop confirmation mechanism prevents historical data from directly overwriting current medical records. Therefore, this application can improve the consistency, traceability, and controlled backfilling security of medical records in scenarios involving smart glasses-based rounds, bedside monitoring, multi-system data access, weak network data transmission, and patient transfers.

[0124] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0125] Although terms such as first, second, third, etc., may be used in this document to describe multiple elements, components, regions, layers, and / or segments, these elements, components, regions, layers, and / or segments should not be limited by these terms. These terms may be used only to distinguish one element, component, region, layer, or segment from another. Unless the context clearly indicates otherwise, terms such as "first," "second," and other numerical terms used herein do not imply order or sequence. Therefore, the first element, component, region, layer, or segment discussed below may be referred to as the second element, component, region, layer, or segment without departing from the teachings of the exemplary embodiments.

[0126] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for integrating smart glasses-based mobile clinic sessions with data consistency, characterized in that, Includes the following steps: Perform patient identity and bed verification to establish a session binding object, record state transition data during the lifecycle of the rounds session, and generate a session snapshot object; Collect bedside data, and in a weak network environment, combine the session snapshot object to perform data retransmission and synchronization, and construct multi-source medical data into a unified event format record; Extract the attributes of the unified event format records to generate fusion keys, calculate fusion scoring objects based on multidimensional consistency metrics, and distribute the unified event format records to a confirmation queue, a pending review queue, or a conflict queue based on the fusion scoring objects. The session snapshot object is compared with the data retransmission synchronization record for attribution verification, and a conflict record object is generated for the data diverted to the conflict queue; Obtain manual intervention instructions for the conflict record object, complete conflict resolution and generate a closed-loop confirmation object, extract the confirmation data records in the confirmation queue, generate a structured round summary object based on the confirmation data records and the closed-loop confirmation object, and output it.

2. The method for binding and integrating smart glasses-based mobile clinic sessions with data consistency according to claim 1, characterized in that, The process of establishing the session binding object and generating the session snapshot object includes: Obtain independent verification factors attached to different physical carriers, perform weighted calculation based on the factor confidence of each independent verification factor and the preset weight to obtain a multi-factor matching score, and when the multi-factor matching score reaches the preset matching threshold, instantiate the session binding object and initialize the binding version identifier. Listen for change events and operation instructions. When a preset trigger event such as patient transfer, bed change, or re-identification is detected, increment the binding version identifier in the session binding object. The lifecycle of the outpatient session is divided into multiple preset state enumeration values. When a transition occurs between the state enumeration values ​​or the binding version identifier is incremented, a snapshot capture action is triggered, and the patient identifier, bed identifier, session identifier, current binding version identifier, current enumeration state, last event sequence number and snapshot time at the current moment are solidified into the session snapshot object.

3. The method for binding and integrating smart glasses-based mobile clinic sessions with data consistency according to claim 2, characterized in that, The process of combining the session snapshot object to perform data retransmission and synchronization, and constructing multi-source medical data into a unified event format record, includes: The multi-source medical data packets are disassembled to extract the business field name, business field value, source time, source system, local serial number and the bound version identifier, and a hash operation is performed to generate a content hash value. The content hash value and the local sequence number are used to perform deduplication on the data for data retransmission and synchronization, and the deduplicated data is constructed into a unified event format record that includes at least the source time, receiving time, verification status, binding version identifier, content hash value, event unique identifier and doctor identifier; During network connection interruption, the collected bedside data and the session snapshot object are encapsulated into a network outage cache package and stored locally. After the network is restored, the session snapshot object and the local serial number recorded in the network outage cache package are read and uploaded in the order of the local serial number to perform the data retransmission synchronization.

4. The method for binding and integrating smart glasses-based mobile clinic sessions with data consistency according to claim 3, characterized in that, The process of extracting attributes from the unified event format records to generate fusion keys and calculating the fusion score object based on the multidimensional consistency metric includes: Extract the patient identifier, bed identifier, session identifier, field name, time window, binding version identifier, and source range from the unified event format record and associated context, and concatenate them to generate the fusion key. Create a corresponding field fusion queue for the same fusion key. Within the field fusion queue, the associated attributes of multiple record sources are extracted, and weighted summation and normalization operations are performed on the identity consistency score, time consistency score, source credibility weight, numerical consistency score and doctor confirmation weight to output the fusion score value. The fusion score value constitutes the fusion score object. Specifically, the identity consistency score is calculated based on the patient identifier, the bed identifier, and the bound version identifier; the time consistency score is calculated based on the distance between the source time and the current rounds time window; the source credibility weight is calculated based on the source system and the review status; the numerical consistency score is calculated based on the difference in candidate values ​​of the same-name field; and the doctor confirmation weight is calculated based on the doctor confirmation status.

5. The method for binding and integrating smart glasses-based mobile clinic sessions with data consistency according to claim 4, characterized in that, The process of splitting the unified event format record based on the fused scoring object includes: When the fusion score value is determined to be greater than or equal to the preset confidence threshold and no conflict is found, the corresponding unified event format record is diverted to the confidence queue. When the fusion score value is determined to be greater than or equal to the preset review threshold and less than the confidence threshold, the corresponding unified event format record is diverted to the queue to be reviewed. When the fusion score is determined to be less than the review threshold or when there is a data conflict, the corresponding unified event format record is diverted to the conflict queue.

6. The method for binding and integrating smart glasses-based mobile clinic sessions with data consistency according to claim 3, characterized in that, The process of verifying the attribution of the session snapshot object with the data retransmission synchronization record includes: Parse and extract the historical patient identity, historical bed identity, historical binding version identity, and historical session status from the historical session snapshot object carried in the data retransmission and synchronization records; Read the currently maintained session snapshot object and extract the current patient identity, current bed identifier, current bound version identifier, and current session state; When it is determined that at least one of the historical binding version identifier, the historical patient identity identifier, the historical bed identifier, and the historical session status is inconsistent with the corresponding current identifier or status, the attribution verification is deemed to have failed, the data in the record is blocked from being written to the target medical record database, and the record is transferred to the isolation record pool.

7. The method for binding and integrating smart glasses-based mobile clinic sessions with data consistency according to claim 5, characterized in that, The process of resolving conflicts and generating a closed-loop confirmation object, and then generating and outputting a structured round-trip summary object based on the confirmed data records and the closed-loop confirmation object, includes: The data diverted to the conflict queue is fully collected from multiple candidate event versions to form a candidate event set, and the conflict record object is generated. Upon receiving the manual intervention instruction, the valid data field content is determined. The valid data field content, together with the operation intervention time and the identification of the operating medical personnel, is encapsulated to generate the closed-loop confirmation object. The remaining candidate event versions that were not selected are updated to an archived and hidden state and retained in the underlying audit storage. Extract the confirmation data records and the closed-loop confirmation object from the confirmation queue, and fill them into the electronic medical record structure template by combining the generated conflict summary details and upload processing summary information to generate the structured round of visits summary object; Extract the unique event identifier, the fusion key, and the current bound version identifier from the unified event format record, combine them to generate a low-level traceability pointer, and write the low-level traceability pointer, along with the source system identifier and the closed-loop confirmation object reference, into the metadata node dictionary of the structured inspection summary object to establish a system low-level audit reference traceability chain and backfill it in a controlled manner.

8. A smart glasses-based mobile clinic session binding and data consistency fusion system, characterized in that, The method for binding and fusing smart glasses-based mobile clinic sessions and data consistency as described in any one of claims 1-7 includes: The session management module is used to perform patient identity and bed verification to establish session binding objects, record state transition data during the lifecycle of the rounds session, and generate session snapshot objects. The front-end interaction module is used to collect bedside data and perform data retransmission and synchronization in conjunction with the session snapshot object in a weak network environment; The data fusion module is used to construct a unified event format record from multi-source medical data, extract the attributes of the unified event format record to generate a fusion key, calculate a fusion score object based on a multidimensional consistency metric, and distribute the unified event format record to a confirmation queue, a pending review queue, or a conflict queue based on the fusion score object. The conflict audit module is used to compare the session snapshot object with the data retransmission synchronization record to perform attribution verification, generate a conflict record object for the data diverted to the conflict queue, obtain manual intervention instructions for the conflict record object to complete conflict resolution and generate a closed-loop confirmation object, extract the confirmation data record in the confirmation queue, generate a structured round-trip summary object based on the confirmation data record and the closed-loop confirmation object, and output it.

9. The intelligent glasses-based mobile clinic session binding and data consistency fusion system according to claim 8, characterized in that, The front-end interaction module includes a multi-factor acquisition unit and an edge preprocessing unit; The session management module includes an identity verification unit and a state machine management unit; The data fusion module includes an event conversion unit and a field fusion unit; The conflict audit module includes an isolation classification unit and a closed-loop generation unit.

10. The intelligent glasses-based mobile clinic session binding and data consistency fusion system according to claim 8, characterized in that, The physical device nodes included are smart glasses, edge gateways, mobile clinic management servers, and hospital information servers; The front-end interaction module runs on the smart glasses and the edge gateway; The session management module, the data fusion module, and the conflict audit module run in the outpatient visit management server, and the outpatient visit management server controls the backfilling and output of the structured outpatient visit summary object to the hospital information server.

Images