A service semantics embedded communication method and system for in-vitro diagnostic instruments

Abstract

The application provides a service semantic embedded communication method and system for an in-vitro diagnostic instrument, relates to the technical field of communication, and comprises communication between a server and a client through a preset custom binary protocol frame; the protocol frame comprises a basic frame header and a Data payload, the basic frame header contains an instruction code for indicating a frame type, the instruction code comprises a first instruction code for indicating a service instruction, a second instruction code for indicating a link layer confirmation, and a third instruction code for indicating a service completion event; the Data payload has at least one IVD service semantic field, and the IVD service semantic field is used for representing specific service data in the in-vitro diagnostic field; when a communication layer in the server or the client transmits and receives the protocol frame, the IVD service semantic field in the Data payload is parsed and processed to execute corresponding service logic. The above scheme solves the problem that the existing IVD instrument communication protocol is completely disconnected with service semantics.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a business semantic embedded communication method and system for in vitro diagnostic instruments. Background Technology

[0002] In vitro diagnostic (IVD) instruments play a crucial role in modern healthcare systems. During IVD instrument operation, the host computer (server) needs to send various control commands to the instrument (client), such as pump control, valve control, stepper motor movement, sensor reading, and assembly script execution. After execution, the instrument must return the results. The reliability and efficiency of this process directly determine the overall performance of the IVD system.

[0003] Currently, in the field of IVD instrument communication, the industry uses a variety of communication protocols, mainly including the following: Modbus / TCP protocol: This is a widely used request-response protocol. In this mode, the server must complete the processing of the business logic before returning a response, meaning that the response itself represents the completion of the business processing.

[0004] HL7 / ASTM E1381 standard: This is a standard for medical information exchange, mainly defining message formats and underlying protocols. However, its application scenarios are primarily focused on data exchange between hospital information systems, and it does not include link confirmation mechanisms for real-time instrument control.

[0005] HL7 FHIR Standard: This is a healthcare resource model based on HTTP / REST, defining a structured representation of resources such as patients, diagnoses, prescriptions, and tests. It is an application-layer API and does not handle real-time communication between instruments.

[0006] OPC UA Protocol: This is an industrial information modeling framework that allows users to define complex data types and object relationships. However, its core responsibility is modeling and transmission, not enforcing business rules.

[0007] MQTT / CoAP protocols: These are commonly used messaging protocols in the Internet of Things (IoT) field, supporting device status retention and offline message caching. However, they primarily synchronize the communication status of devices (such as online / offline), and do not involve IVD business status (such as quality control, reagents, samples, etc.).

[0008] Custom binary protocol: Some IVD vendors choose to define their own communication protocol. These protocols usually adopt a simple send-receive acknowledgment mode, equating the ACK signal with the completion of the service.

[0009] While the aforementioned protocols have achieved success in their respective application areas, they still have many limitations when facing the complex business scenarios of IVD instruments. For example, in long-latency business scenarios, traditional confirmation mechanisms may lead to low communication efficiency; in the concurrent management of multiple instruments, the lack of effective isolation mechanisms can easily cause data chaos; more importantly, the core function of all existing communication protocols is to transmit data from point A to point B, without caring about the business meaning of the transmitted data. The business semantics specific to the IVD industry, such as sample identification, reagent batch, quality control status, turnaround time (TAT), and fault type, rely entirely on the application-layer LIMS or ELN system for processing. This disconnect between design and implementation leads to a series of problems such as delayed information synchronization, easy omission of data records, and slow response to abnormal events. Summary of the Invention

[0010] This application provides a business semantic embedded communication method and system for in vitro diagnostic instruments to solve the problem that existing IVD instrument communication protocols are completely disconnected from business semantics.

[0011] In a first aspect, this application provides a business semantic embedded communication method for in vitro diagnostic instruments, the method comprising: The server and client communicate via a pre-defined custom binary protocol frame. The protocol frame includes a basic frame header and a data payload. The basic frame header contains instruction codes indicating the frame type, including a first instruction code indicating a business instruction, a second instruction code indicating link-layer confirmation, and a third instruction code indicating a business completion event. The data payload contains at least one IVD business semantic field, which characterizes specific business data in the in vitro diagnostics field. When sending and receiving the protocol frame, the communication layer in the server or client parses and processes the IVD business semantic field in the data payload to execute corresponding business logic.

[0012] In some implementations, the IVD business semantic fields include sample identifier, transfer chain position, and predecessor hash value; The communication layer is configured to calculate the current step hash value based on the information of the current processing step and the predecessor hash value when sending or forwarding a service instruction frame carrying a sample, and use the current step hash value as the predecessor hash value for the next processing step, so as to form an immutable sample full-link hash tracing chain at the communication layer.

[0013] In some implementations, the IVD business semantic fields include reagent batch number, test item code, and reagent expiration time; The communication layer is also configured to, upon receiving a service instruction frame, verify the legality of the binding between the requested reagent and the sample based on the reagent batch number and the test item code; after the verification is successful, automatically deduct the remaining reagent quantity and record the binding relationship; the verification includes checking whether the reagent is expired or whether the remaining quantity is sufficient.

[0014] In some implementations, the IVD business semantic field includes quality control results; The communication layer is also configured to, upon receiving a protocol frame carrying a quality control failure result, perform a breadth-first traversal in a preset quality control association graph, starting from the instrument that issued the protocol frame, to find all associated instruments that share the same batch of resources, and automatically send a pause command or a warning command to the found associated instruments.

[0015] In some implementations, the IVD business semantic fields include an entry timestamp and an urgency level; The communication layer is also configured to accumulate turnaround time based on the entry timestamp during sample processing, and when the turnaround time reaches multiple preset thresholds set based on the urgency level, automatically send a graded early warning instruction or an accelerated processing instruction to the current processing instrument, and / or send a sample preparation early warning instruction to the downstream instrument.

[0016] In some implementations, the IVD service semantic field includes a fault type; The communication layer is also configured to, upon receiving a protocol frame carrying fault information, calculate the range of affected instruments based on a preset fault impact rule table, combined with the fault type and shared resource relationships, and automatically send pause, downgrade, or warning commands to the instruments within the affected range.

[0017] In some implementations, the instruction codes in the base frame header further include a fourth instruction code for indicating negative acknowledgment, a fifth instruction code for indicating a heartbeat request, and a sixth instruction code for indicating a heartbeat response. The server is configured to return a link confirmation frame carrying the second instruction code after receiving a service instruction frame carrying the first instruction code; and to send a service completion event frame carrying the third instruction code separately after the service processing is completed.

[0018] In some implementations, the client has an adaptive rate controller internally, which is configured to: Periodically assess packet loss rate, average round-trip time, and number of unacknowledged frames; The interval for sending the protocol frames is dynamically adjusted based on the evaluation results; when there is no packet loss, low latency, and low backlog, the interval is reduced to increase the sending rate; when there is packet loss, high latency, or high backlog, the interval is increased to reduce the sending rate.

[0019] In some implementations, the server is also configured to create a separate channel manager instance for each connected client, with each channel manager instance maintaining a separate sequence number space, a separate send queue, and a separate frame processor loop to achieve complete instrument-level isolation.

[0020] Secondly, this application also provides a business semantic embedded communication system for in vitro diagnostic instruments, the system including a server and a client, the server and the client being used to execute any of the methods described above.

[0021] As can be seen from the above, this application has the following advantages: It eliminated ACK storms under long-latency services; achieved adaptive adjustment of communication rate; achieved tamper-proof traceability of samples throughout the entire process; completed zero-error real-time verification of reagent binding; achieved second-level automatic propagation and blocking of quality control failures; provided tiered real-time early warning and automatic accelerated intervention for TAT (Troubleshooting and Acquisition) systems; and achieved automatic and comprehensive calculation and command issuance of the scope of fault impact. Overall, it significantly improved the efficiency, reliability, intelligence level, and service response speed of IVD instrument communication. Attached Figure Description

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

[0023] Figure 1 This is a flowchart of a business semantic embedded communication method for in vitro diagnostic instruments according to this application; Figure 2 This is a schematic diagram of a business semantic embedded communication system for in vitro diagnostic instruments according to this application. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0026] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0027] See Figure 1 As can be seen, this embodiment provides a business semantic embedded communication method for in vitro diagnostic instruments, the method including: S1, communication between the server and the client is conducted via a preset custom binary protocol frame; the protocol frame includes a basic frame header and a data payload, the basic frame header contains instruction codes for indicating the frame type, the instruction codes include a first instruction code for indicating a business instruction, a second instruction code for indicating a link layer confirmation, and a third instruction code for indicating a business completion event; the data payload has at least one IVD business semantic field, the IVD business semantic field being used to characterize specific business data in the field of in vitro diagnostics; when the communication layer in the server or the client sends and receives the protocol frame, it parses and processes the IVD business semantic field in the data payload to execute the corresponding business logic.

[0028] Specifically, in this embodiment, the custom binary protocol frame is a unified carrier that carries all communication information and service data, and its structure is divided into two parts: the basic frame header and the data payload.

[0029] The basic frame header is a fixed header in each protocol frame, used for underlying link control and frame identification. Its specific components are as follows: Start of Frame (SOF): Occupies 1 byte, with a fixed value of 0xAA. The receiver uses this flag to determine the start of a valid frame.

[0030] Instrument Identifier (InstId): Occupies 1 byte and is used to uniquely identify the client instrument that sent or received the frame. The server uses this to distinguish and manage different instrument connections.

[0031] Component Identifier (CompId): Occupies 1 byte and is used to identify a sub-component or functional module inside the instrument, such as a specific pump, valve, or sensor.

[0032] Command Code (CmdCode): Occupying 1 byte, it is one of the core components of this embodiment, used to indicate the type of frame. It includes at least: The first instruction code (e.g., 0x70) is used to indicate a business instruction frame, such as sending an assembly script command.

[0033] The second instruction code (e.g., 0x80): is used to indicate a link-layer acknowledgment frame, i.e., ACK. This frame is only used to confirm that the server has correctly received the client's service instruction, and does not mean that the service has been completed.

[0034] The third instruction code (e.g., 0x90): is used to indicate a business completion event frame. This frame is sent separately by the server after the business logic processing is complete, informing the client that the instruction execution was successful.

[0035] Sequence Number: Occupies 2 bytes, generated by the sender, and is used to uniquely identify a request. The receiver will carry the same sequence number when returning an ACK, so that the sender can match the ACK with the pending acknowledgment request.

[0036] Data length (DataLen): Occupies 2 bytes and is used to indicate the number of bytes in the Data payload that follows.

[0037] Cyclic Redundancy Check (CRC): Occupies 2 bytes and checks the entire frame (from SOF to the end of the data payload) to ensure the integrity of data transmission.

[0038] The data payload is a variable-length data region that follows the base frame header, and its content varies depending on the instruction code. In this embodiment, the data payload contains at least one IVD business semantic field. These fields are not simple binary data, but rather specific business data used to characterize the in vitro diagnostics field. For example, it may contain fields such as sample identifier, reagent batch number, quality control results, entry timestamp, or fault type. The structure and meaning of these fields are predefined at the protocol level.

[0039] The communication process occurs between the server and one or more clients.

[0040] Transmission Phase: When a client needs to perform a business operation (such as processing a sample), its application layer generates business data. The communication layer (not the application layer) is responsible for encapsulating this business data into a protocol frame. It sets the instruction code to the first instruction code (business instruction) and fills the relevant IVD business semantic fields (such as sample ID, reagent batch, etc.) into the Data payload. Then, the frame is sent to the server via the network (such as TCP / IP).

[0041] Reception and Parsing Phase: After receiving the raw byte stream, the server's communication layer first locates the frame start based on the SOF and then parses the basic frame header. By recognizing the instruction code, the server knows that this is a business instruction frame. Next, the communication layer directly parses the IVD business semantic fields from the Data payload according to the predefined protocol format, such as extracting SampleId and ReagentBatchId.

[0042] Business logic execution phase: The key difference lies in the fact that the parsing and processing of these IVD business semantic fields are handled by the communication layer on the server or client side. The communication layer doesn't merely pass data through to the upper-layer application logic; it possesses the ability to understand and process business semantics itself. For example, after parsing the ReagentBatchId, the communication layer can immediately execute the business logic of checking if the reagent has expired, without waiting for intervention from the upper-layer application system. After executing the corresponding business logic, the communication layer may modify data in the protocol frame or trigger the transmission of a new instruction frame.

[0043] Furthermore, in some embodiments, the IVD business semantic field includes a sample identifier, a transfer chain position, and a predecessor hash value; The communication layer is configured to calculate the current step hash value based on the information of the current processing step and the predecessor hash value when sending or forwarding a service instruction frame carrying a sample, and use the current step hash value as the predecessor hash value for the next processing step, so as to form an immutable sample full-link hash tracing chain at the communication layer.

[0044] Specifically, in this embodiment, in order to achieve traceability, the Data payload includes at least the following specific IVD business semantic fields: Sample Identifier (SampleId): An 8-byte field that stores a unique identifier for the sample, such as a hash of a barcode number. This field remains unchanged throughout the sample's lifecycle.

[0045] ChainPosition: A 1-byte field that records the current step number of the sample in the processing flow. For example, the value is 1 for the first step, 2 for the second step, and so on.

[0046] PreviousHash: A 4-byte field that stores the hash value generated by the sample in the previous processing step. For the first processing step, this value is initialized to 0.

[0047] When the communication layer is ready to send or forward a service instruction frame carrying a sample, it automatically performs the following operations to build an immutable traceability chain: Information gathering. The communication layer first extracts relevant information about the current processing step from the Data payload of the protocol frame. This includes at least the sample identifier, the position of the transfer chain, the predecessor hash value, the current timestamp, the physical fingerprint of the instrument that processed the sample, and the batch number of the reagent used.

[0048] Hash calculation. The communication layer concatenates all collected information in a fixed order to form a string or byte array. Then, it uses a cryptographic hash function (such as SHA256) to calculate a fixed-length hash value, called the current step hash value. In practical applications, to improve efficiency, only the first 4 bytes of the SHA256 result can be used as the current step hash value.

[0049] Field Update and Forwarding. The communication layer writes the calculated current step hash value into the data payload of the protocol frame, but not as the PreviousHash; instead, it uses it as the PreviousHash for the next processing step. Simultaneously, it increments the ChainPosition by 1. The frame is then sent to the next processing step.

[0050] When a downstream instrument (or server) receives a business instruction frame, its communication layer automatically performs a hash chain continuity check. It searches the local cache for the previous processing record of that sample based on the SampleId in the frame. If found, it compares the PreviousHash in the frame with the StepHash in the local record. If they are equal, the chain is intact and the data has not been tampered with; if they are not equal, the chain is broken, potentially indicating data loss or malicious tampering, and the communication layer can trigger an alarm.

[0051] Furthermore, in some embodiments, the IVD business semantic fields include reagent batch number, test item code, and reagent expiration time; The communication layer is also configured to, upon receiving a service instruction frame, verify the legality of the binding between the requested reagent and the sample based on the reagent batch number and the test item code; after the verification is successful, automatically deduct the remaining reagent quantity and record the binding relationship; the verification includes checking whether the reagent is expired or whether the remaining quantity is sufficient.

[0052] Specifically, in this embodiment, to achieve reagent management, the Data payload includes at least the following fields: Reagent Batch Number (ReagentBatchId): A 4-byte field used to uniquely identify a batch of reagents.

[0053] TestItemCode: A 2-byte field used to identify the test to be performed, such as blood glucose (GLU) or liver function (ALT).

[0054] ReagentExpireTime: A 4-byte field that stores the expiration timestamp of this batch of reagents.

[0055] When the communication layer of the server or client receives a business instruction frame, it automatically executes the reagent-sample binding verification logic: Reagent lookup: The communication layer first looks up the corresponding reagent entry in the locally maintained table of currently loaded reagents based on the TestItemCode in the frame.

[0056] Validity verification: After the reagent is found, the communication layer will perform a series of verifications: (1) Expiration check: Compare the current system time with the ReagentExpireTime in the frame. If the current time is later than the expiration time, the check fails, the communication layer will reject the binding, and may return an error frame.

[0057] (2) Residual quantity check: Check whether the remaining amount of the reagent recorded locally is greater than or equal to the minimum consumption required for a single test (e.g., 50 microliters). If the remaining quantity is insufficient, the verification fails.

[0058] Batch conflict check: Checks whether the sample (identified by SampleId) has been bound to other batches of the same reagent. If so, it prevents mixing different batches of reagent to avoid cross-contamination or result bias.

[0059] Binding and deduction: If all the above checks pass, the communication layer will perform the following operations: Record the binding relationship: Record the binding relationship between ReagentBatchId and SampleId used in this operation for future reference.

[0060] Automatic deduction of remaining amount: Subtracts the amount consumed in this test (e.g., 10 microliters) from the locally recorded remaining amount of the reagent, and updates the local record.

[0061] Status broadcasting. After successful verification and deduction, the communication layer automatically constructs a new protocol frame to broadcast the latest local reagent status (such as remaining quantity, whether it is locked) to all other associated instruments, thereby achieving cross-instrument reagent status synchronization.

[0062] Furthermore, in some embodiments, the IVD business semantic field includes quality control results; The communication layer is also configured to, upon receiving a protocol frame carrying a quality control failure result, perform a breadth-first traversal in a preset quality control association graph, starting from the instrument that issued the protocol frame, to find all associated instruments that share the same batch of resources, and automatically send a pause command or a warning command to the found associated instruments.

[0063] Specifically, in this embodiment, the Data payload includes a field for characterizing the quality control result, such as QcResult. This field can be a single byte, and its value represents different quality control states, such as 0 for no result, 1 for pass, 2 for failure, and 3 for warning.

[0064] The communication layer maintains a dynamically updated quality control relationship graph. This graph is undirected, where nodes represent each instrument, and edges between nodes represent shared resource relationships, such as sharing the same batch of reagents, standards, or calibrators. The communication layer automatically discovers and establishes these relationships by listening to protocol frames emitted by all instruments, extracting resource usage information from them.

[0065] When the communication layer receives a protocol frame carrying a quality control failure result, it will immediately trigger the following automatic processing procedure: Locate the source point: Identify the instrument that sent the failure frame and use it as the starting point for traversing the association graph.

[0066] Breadth-First Search (BFS): The communication layer starts from the source node and performs a breadth-first search along the edges of the association graph. The purpose of the search is to find all associated instruments that share the same batch of resources as the source node (i.e., the batch that caused the quality control failure). For example, if the quality control failure is due to a problem with reagent batch R456, then BFS will search for all instruments that share R456 with the source node.

[0067] Sending control commands: For each associated instrument traversed by BFS, the communication layer automatically sends corresponding control commands based on the type and severity of the shared resource. For example: For instruments sharing the same batch of expired reagents, a pause command is sent to force them to stop using that batch of reagents and to conduct an investigation.

[0068] For instruments that share potentially affected standards or calibrators, send a warning to remind them to observe subsequent test results.

[0069] Furthermore, in some embodiments, the IVD business semantic field includes an entry timestamp and an urgency level; The communication layer is also configured to accumulate turnaround time based on the entry timestamp during sample processing, and when the turnaround time reaches multiple preset thresholds set based on the urgency level, automatically send a graded early warning instruction or an accelerated processing instruction to the current processing instrument, and / or send a sample preparation early warning instruction to the downstream instrument.

[0070] Specifically, in this embodiment, the Data payload includes the following fields: EnterTimestamp: A 4-byte field that records the time (Unix seconds) when the sample entered the current processing instrument.

[0071] Urgency Level: A 1-byte field used to identify the urgency level of a sample. For example, 0 indicates normal, 1 indicates emergency, and 2 indicates critical. Different urgency levels correspond to different target turnaround times.

[0072] Inside the communication layer is a TAT monitor that tracks all samples being processed: Monitoring Initiation: When a sample enters an instrument, the communication layer parses the EnterTimestamp and UrgencyLevel in the protocol frame and looks up the target turnaround time for the sample based on the UrgencyLevel (e.g., 2 hours for regular samples, 30 minutes for emergency samples). The monitor then creates a tracking record for the sample and begins accumulating the turnaround time.

[0073] Tiered alerts: During sample processing, the monitor periodically (e.g., every 10 seconds) checks the ratio of the current elapsed time to the target turnaround time for each active sample. When the ratio reaches several preset thresholds, different actions are automatically triggered: (1) Reaching 50% threshold: Send a graded warning command to the current processing instrument, indicating that 50% of the target time has been used and please pay attention.

[0074] (2) Reaching the 80% threshold: Send a more urgent graded warning instruction to the current processing instrument, requesting that the processing be accelerated.

[0075] (3) Reaching the 95% threshold: In addition to sending an accelerated processing command to the current instrument, it will also send a sample preparation warning command to the downstream instrument, informing the downstream instrument that an urgent sample is about to arrive and to prepare for seamless connection.

[0076] Timeout Alarm: If the actual time taken for a sample exceeds the target turnaround time, the monitor will trigger a timeout alarm event and record detailed timeout data for post-event analysis.

[0077] Furthermore, in some embodiments, the IVD service semantic field includes fault type; The communication layer is also configured to, upon receiving a protocol frame carrying fault information, calculate the range of affected instruments based on a preset fault impact rule table, combined with the fault type and shared resource relationships, and automatically send pause, downgrade, or warning commands to the instruments within the affected range.

[0078] Specifically, in this embodiment, the Data payload includes a FaultType field to indicate the type of fault that occurred. For example, 0x01 indicates reagent depletion, 0x02 indicates reagent contamination, 0x03 indicates expired calibration, and 0x04 indicates blockage in the waste liquid pipeline, etc.

[0079] The communication layer incorporates a built-in fault impact rule table, which translates IVD industry expertise into computer-executable rules. For example, a rule might define: if a reagent contamination fault occurs, all instruments sharing the same reagent batch should be suspended, and all instruments sharing the same supplier should receive an alert.

[0080] When the communication layer receives a protocol frame carrying fault information, it will execute the following process: Parse the fault type: Extract the value of the FaultType field from the protocol frame.

[0081] Query Impact Rules: Based on the parsed fault type, search for all corresponding rules in the Fault Impact Rule Table. Each rule specifies the type of shared resource to be checked (such as reagents from the same batch, waste liquid pipelines) and the corresponding impact action (such as pause, downgrade, warning).

[0082] Calculating the scope of affected instruments: The communication layer uses its maintained shared resource relationship graph (similar to the quality control relationship graph) to find all other instruments that share the specified resources with the faulty instrument for each rule. For example, if the rule is sharing the same batch of reagents, then all instruments that used the same batch of R456 reagent are found.

[0083] Sending control commands: For each affected instrument identified, the communication layer automatically sends a corresponding command based on the impact action specified in the rules. For example, a pause command is sent to instruments sharing the same batch of reagents, and a warning command is sent to instruments sharing the same supplier.

[0084] Furthermore, in some embodiments, the instruction codes in the basic frame header also include a fourth instruction code for indicating negative acknowledgment, a fifth instruction code for indicating a heartbeat request, and a sixth instruction code for indicating a heartbeat response. The server is configured to return a link confirmation frame carrying the second instruction code after receiving a service instruction frame carrying the first instruction code; and to send a service completion event frame carrying the third instruction code separately after the service processing is completed.

[0085] Specifically, in this embodiment, in addition to the first, second, and third instruction codes, the instruction codes in the basic frame header also include: The fourth instruction code (e.g., 0x81): indicates a negative acknowledgment (NAK). This frame is returned when the server receives a frame that fails to be verified or cannot be processed.

[0086] The fifth instruction code (e.g., 0xA0): is used to indicate a heartbeat request. The client sends this frame periodically to maintain the connection.

[0087] The sixth instruction code (e.g., 0xA1): is used to indicate a heartbeat response. The server replies with this frame after receiving a heartbeat request.

[0088] This implementation describes in detail how the server handles a business instruction that requires a long processing time, completely resolving the ACK storm problem, including: Sending a service instruction: The client sends a service instruction frame with the instruction code as the first instruction code.

[0089] Immediate Link Acknowledgment: After receiving the frame and completing basic frame verification, the server's communication layer immediately returns a link acknowledgment frame with the second instruction code to the client without waiting for the business logic to finish processing. This ACK simply tells the client, "I have received your instruction, the link is working, please do not retransmit." Upon receiving this ACK, the client can stop the timeout retransmission timer for this instruction.

[0090] Asynchronous execution of business logic: The server then places the received business instructions into an asynchronous task queue for processing. This process may take tens or even hundreds of seconds.

[0091] Sending a separate business completion event: Once the server-side business logic is finally completed (for example, the instrument completes a certain action), the server will construct a separate business completion event frame with the third instruction code and send it to the client. Only after receiving this frame does the client truly know that the business has been completed and can continue to issue the next instruction.

[0092] Furthermore, in some embodiments, the client internally includes an adaptive rate controller, which is configured to: Periodically assess packet loss rate, average round-trip time, and number of unacknowledged frames; The interval for sending the protocol frames is dynamically adjusted based on the evaluation results; when there is no packet loss, low latency, and low backlog, the interval is reduced to increase the sending rate; when there is packet loss, high latency, or high backlog, the interval is increased to reduce the sending rate.

[0093] Specifically, in this embodiment, the client integrates an adaptive rate controller, which is responsible for dynamically adjusting the time interval for sending protocol frames in order to maximize communication throughput while ensuring reliability.

[0094] The adaptive rate controller periodically (e.g., every 5 seconds) evaluates three key network metrics: Period Loss Rate: The number of frames that do not receive a link layer ACK within an evaluation period.

[0095] Average round-trip time (avgRtt): The average round-trip time of all successfully acknowledged frames within a cycle.

[0096] PendingCount: The number of frames that have been sent but have not yet received an ACK from the link.

[0097] Based on the evaluation results of these three indicators, the controller will make the following three-state decision: Speedup State: When the evaluation results show no packet loss, low latency (e.g., avgRtt < 50ms), and low backlog (e.g., pendingCount < 5), it indicates that the current network condition is good and there is still room for improvement. The controller will multiply the current transmission interval by a coefficient less than 1 (e.g., 0.9), thereby reducing the transmission interval and increasing the transmission rate.

[0098] SLOWDOWN: When the evaluation results show packet loss, high latency (e.g., avgRtt > 100ms), or high backlog (e.g., pendingCount > 20), it indicates that the network is overloaded. The controller will multiply the current transmission interval by a coefficient greater than 1 (e.g., 1.25), thereby increasing the transmission interval and reducing the transmission rate to avoid further congestion and packet loss.

[0099] Keep-alive (KEEP): When network conditions are between the acceleration and deceleration thresholds, the controller considers the current rate appropriate and therefore maintains the current transmission interval.

[0100] Furthermore, in some embodiments, the server is also configured to create an independent channel manager instance for each connected client, with each channel manager instance maintaining an independent sequence number space, an independent send queue, and an independent frame processor loop to achieve complete instrument-level isolation.

[0101] Specifically, in this embodiment, the server is configured to create an independent channel manager instance for each client instrument that connects to it. Each instance is completely autonomous and has its own independent resources.

[0102] Each independent channel manager instance maintains at least the following three independent resources to achieve complete isolation: Independent sequence number space: Each channel manager instance has its own sequence number counter. This means that even if instrument A and instrument B simultaneously send a frame with sequence number 0x0001, these two sequence numbers belong to their respective independent namespaces, and the server will not confuse them during processing. This fundamentally eliminates the sequence number mixing problem that may occur when multiple instruments are running concurrently.

[0103] Independent send queues: Each channel manager instance has its own send queue. Frames that the server needs to send to a specific instrument will only be placed in the send queue of the channel manager corresponding to that instrument. This ensures that downlink data streams from different instruments do not interfere with each other.

[0104] Independent frame processor loops: Each channel manager instance runs an independent loop (e.g., a separate thread or coroutine) to handle all communication transactions for that instrument, including receiving frames, parsing frames, matching ACKs, and managing retransmissions. This physical isolation ensures that even if communication processing in one instrument is blocked or malfunctions, it will not affect the normal operation of other instruments.

[0105] See Figure 2 It is understood that this embodiment also provides a business semantic embedded communication system for in vitro diagnostic instruments. The system includes a server and a client, and the server and the client are used to execute the above method.

[0106] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the discussion in some embodiments is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the contents of this disclosure, thereby enabling those skilled in the art to better utilize the embodiments.

Claims

1. A business semantic embedded communication method for in vitro diagnostic instruments, characterized in that, The method includes: The server and client communicate via a pre-defined custom binary protocol frame. The protocol frame includes a basic frame header and a data payload. The basic frame header contains instruction codes indicating the frame type, including a first instruction code indicating a business instruction, a second instruction code indicating link-layer confirmation, and a third instruction code indicating a business completion event. The data payload contains at least one IVD business semantic field, which characterizes specific business data in the in vitro diagnostics field. When sending and receiving the protocol frame, the communication layer in the server or client parses and processes the IVD business semantic field in the data payload to execute corresponding business logic.

2. The embedded communication method for business semantics of in vitro diagnostic instruments according to claim 1, characterized in that, The IVD business semantic fields include sample identifier, transfer chain position, and predecessor hash value; The communication layer is configured to calculate the current step hash value based on the information of the current processing step and the predecessor hash value when sending or forwarding a service instruction frame carrying a sample, and use the current step hash value as the predecessor hash value for the next processing step, so as to form an immutable sample full-link hash tracing chain at the communication layer.

3. The embedded communication method for business semantics of in vitro diagnostic instruments according to claim 1, characterized in that, The IVD business semantic fields include reagent batch number, test item code, and reagent expiration time; The communication layer is also configured to, upon receiving a service instruction frame, verify the legality of the binding between the requested reagent and the sample based on the reagent batch number and the test item code; after the verification is successful, automatically deduct the remaining reagent quantity and record the binding relationship; the verification includes checking whether the reagent is expired or whether the remaining quantity is sufficient.

4. The embedded communication method for business semantics of in vitro diagnostic instruments according to claim 1, characterized in that, The IVD business semantic fields include quality control results; The communication layer is also configured to, upon receiving a protocol frame carrying a quality control failure result, perform a breadth-first traversal in a preset quality control association graph, starting from the instrument that issued the protocol frame, to find all associated instruments that share the same batch of resources, and automatically send a pause command or a warning command to the found associated instruments.

5. The embedded communication method for business semantics of in vitro diagnostic instruments according to claim 1, characterized in that, The IVD business semantic fields include the entry timestamp and urgency level; The communication layer is also configured to accumulate turnaround time based on the entry timestamp during sample processing, and when the turnaround time reaches multiple preset thresholds set based on the urgency level, automatically send a graded early warning instruction or an accelerated processing instruction to the current processing instrument, and / or send a sample preparation early warning instruction to the downstream instrument.

6. The embedded communication method for business semantics of in vitro diagnostic instruments according to claim 1, characterized in that, The IVD business semantic field includes the fault type; The communication layer is also configured to, upon receiving a protocol frame carrying fault information, calculate the range of affected instruments based on a preset fault impact rule table, combined with the fault type and shared resource relationships, and automatically send pause, downgrade, or warning commands to the instruments within the affected range.

7. The embedded communication method for business semantics of in vitro diagnostic instruments according to claim 1, characterized in that, The instruction codes in the basic frame header also include a fourth instruction code for indicating negative confirmation, a fifth instruction code for indicating a heartbeat request, and a sixth instruction code for indicating a heartbeat response. The server is configured to return a link confirmation frame carrying the second instruction code after receiving a service instruction frame carrying the first instruction code; and to send a service completion event frame carrying the third instruction code separately after the service processing is completed.

8. The embedded communication method for business semantics of in vitro diagnostic instruments according to claim 1, characterized in that, The client has an adaptive rate controller, which is configured as follows: Periodically assess packet loss rate, average round-trip time, and number of unacknowledged frames; The interval for sending the protocol frames is dynamically adjusted based on the evaluation results; when there is no packet loss, low latency, and low backlog, the interval is reduced to increase the sending rate; when there is packet loss, high latency, or high backlog, the interval is increased to reduce the sending rate.

9. The embedded communication method for business semantics of in vitro diagnostic instruments according to claim 1, characterized in that, The server is also configured to create an independent channel manager instance for each connected client. Each channel manager instance maintains an independent sequence number space, an independent send queue, and an independent frame processor loop to achieve complete instrument-level isolation.

10. A business semantic embedded communication system for in vitro diagnostic instruments, characterized in that, The system includes a server and a client, the server and the client being used to execute the method of any one of claims 1 to 9.

Images