Cross-system sample exchange method and system based on data exchange platform

Abstract

The application discloses a cross-system sample exchange method and system based on a data exchange platform. The method comprises the following steps: receiving sample stream conversion events and business events from each source system, and constructing a directed graph structure of a physical sample chain and a medical order business chain respectively; for a to-be-aligned business object node in the medical order business chain, screening a candidate physical sample entity node in the physical sample chain which simultaneously satisfies a time sequence monotonicity constraint, a bifurcation consistency constraint and a platform routing constraint, and forming a candidate alignment relationship set; calculating an integrated interpretation substitution value for each candidate scheme, and selecting a candidate scheme with the minimum integrated interpretation substitution value as an alignment result; and generating an exchange object record according to the alignment result. The method can improve the accuracy and traceability of cross-system sample exchange object identification in a complex business scenario.

Description

Technical Field

[0001] This application relates to the field of data exchange technology, specifically a cross-system sample exchange method and system based on a data exchange platform. Background Technology

[0002] In medical testing laboratories, hospital information systems, laboratory information systems, and instrument management systems for various testing platforms are typically built and operate independently. Frequent data exchange is required between sample acceptance, transfer, testing, retesting, and report merging. Especially in scenarios where multiple testing platforms such as next-generation sequencing, qPCR, and dPCR are configured simultaneously, the same application form may be split and executed on different platforms. The same sample may also be aliquoted, reused, additionally tested, retested, or cancelled during the testing process. This results in a discrepancy between the flow of the physical entity of the sample and the evolution of the business object, and both continue to change as the process progresses.

[0003] In existing technologies, cross-system sample exchange typically relies on direct association using fields such as sample number, application number, and barcode number, or uses a single master index to maintain the correspondence between physical identifiers and business identifiers. While this approach can meet basic exchange needs when the process is simple, it is prone to mapping path errors when a single business object corresponds to multiple physical sample entities, or when a single physical sample entity carries different business tasks at different stages. These errors often do not manifest as missing fields or format abnormalities, making them difficult to detect promptly using routine data integrity checks. Furthermore, when an application is split into separate items and different packaged samples are used for testing on different platforms, relying solely on field binding may incorrectly map business objects to incompatible physical branches. These issues affect the accuracy of cross-system exchange object identification, thereby impacting the reliability of data synchronization, result backfilling, report generation, and end-to-end traceability. Summary of the Invention

[0004] The purpose of this application is to provide a cross-system sample exchange method and system based on a data exchange platform to solve the problems mentioned in the background art.

[0005] According to one aspect of this application, a cross-system sample exchange method based on a data exchange platform is provided, comprising the following steps: The system receives sample flow events and business events from various source systems. Based on the sample flow events, it constructs a directed graph structure of a physical sample chain and a directed graph structure of a medical order business chain based on the business events. Each node in the physical sample chain represents an independently existing physical sample entity, and the directed edges between nodes represent physical derivation or state transition relationships between physical sample entities. Each node in the medical order business chain represents a business object, and the directed edges between nodes represent logical derivation or merging relationships between business objects. Performing a constrained graph alignment operation on the physical sample chain and the medical order business chain includes: for the business object nodes to be aligned in the medical order business chain, selecting candidate physical sample entity nodes in the physical sample chain that simultaneously satisfy the temporal monotonicity constraint, the fork consistency constraint, and the platform routing constraint to form a candidate alignment relationship set; calculating the comprehensive explanatory value for each candidate scheme in the candidate alignment relationship set, and selecting the candidate scheme with the smallest comprehensive explanatory value as the alignment result; Based on the alignment results, an exchange object record is generated for each successfully aligned business object node and physical sample entity node.

[0006] Preferably, the temporal monotonic constraint is: the request initiation timestamp of the business object node to be aligned is not later than the irreversible termination timestamp of its candidate physical sample entity node; during the filtering process, the data exchange platform maintains a state time interval for each node in the physical sample chain, extracts the request initiation timestamp of the business object node to be aligned, and excludes physical sample entity nodes whose state time interval is incompatible with the request initiation timestamp from the candidates.

[0007] Preferably, the fork consistency constraint is as follows: if an application node in the medical order business chain splits into multiple project group nodes through the splitting edge, then the candidate physical sample entity nodes aligned with it in the physical sample chain originate from the same source container node, and are reached directly from the source container node via the loading edge, or via the packaging generation edge and then via the loading edge or reuse edge to reach the loading entity nodes compatible with the number of the multiple project group nodes. During the screening process, the data exchange platform calculates the number and type of downstream branches for each source container node in the physical sample chain, calculates the number of split branches and the target platform category for each application node in the medical order business chain, and removes candidate combinations with incompatible branch numbers or branch types from the candidate alignment relationship set.

[0008] Preferably, the platform routing constraint is as follows: the target detection platform category declared by the project group node in the medical order business chain is consistent with the detection platform category actually reached by the physical sample chain node it is aligned with; the correspondence between the target detection platform category and the detection platform category is determined by a preset project code and platform category mapping table.

[0009] Preferably, the comprehensive interpretation cost is equal to the weighted sum of the cost of the difference in packaging quantity, the cost of the difference in time span, and the cost of the platform routing change, each multiplied by its corresponding weight coefficient; The cost of the difference in the number of repackaged items is the absolute value of the difference between the number of sub-item branches in the medical order business chain and the actual number of repackaged items in the physical sample chain; the cost of the difference in the time span is the portion of the interval between the business request time and the physical sample state start time that exceeds the preset normal range; the cost of the platform route change is the preset substitution value accumulated when the actual platform of the sample entity in the physical sample chain and the declared platform of the project group node in the business chain are substitutable.

[0010] Preferably, the graph alignment operation further includes verification of backflow constraints: when a new re-examination task node or an additional project node is added to the medical order business chain, the data exchange platform searches for the source container node that is currently aligned with the application form to which the new node belongs in the physical sample chain, traverses the downstream branches of the source container node, and identifies sample entity nodes whose status is not terminated and whose platform category is compatible with the target platform of the new node as priority candidate alignment objects; only when there is no unterminated branch that meets the conditions is the new node marked as waiting for a new sample event.

[0011] Preferably, the types of nodes in the physical sample chain include original sampling container nodes, packaging container nodes, machine-mounted entity nodes, re-inspection entity nodes, and discarded entity nodes; the types of directed edges include packaging generation edges, machine-mounted loading edges, reused edges, re-inspection derived edges, and deregistration edges; wherein, the distinction between machine-mounted edges and reused edges is based on whether the container previously had at least one edge pointing to a machine-mounted entity node. If it did, the current edge is a reused edge; otherwise, it is a machine-mounted edge.

[0012] Preferably, the types of nodes in the medical order business chain include patient anonymity identification nodes, visit identification nodes, application form nodes, project group nodes, additional project nodes, re-examination task nodes, and report merging nodes; the types of directed edges include order placement edges, item splitting edges, additional edge, re-examination application edges, and result merging edges.

[0013] Preferably, the calculation process of the graph alignment operation includes: starting from the business object node to be aligned, tracing upwards in the medical order business chain to the visit identification node, and continuing to trace to the patient anonymous identification node when there is one, to determine the scope of the business subgraph; determining the scope of the physical subgraph in the physical sample chain based on the nodes with existing alignment relationships in the scope of the business subgraph; within the scope of the business subgraph and the scope of the physical subgraph, enumerating candidate physical sample entity nodes in the physical subgraph that satisfy the temporal monotonic constraint and the platform routing constraint for each leaf node in the business subgraph, performing the verification of the fork consistency constraint to remove candidate combinations that do not satisfy the constraint, calculating the comprehensive interpretation cost value for the candidate schemes that pass the verification, and selecting the smallest one as the alignment result.

[0014] In another aspect, this application also provides a cross-system sample exchange system based on a data exchange platform, comprising: The event receiving and graph construction module is used to receive sample flow events and business events from various source systems, construct a directed graph structure of physical sample chains based on the sample flow events, and construct a directed graph structure of medical order business chains based on the business events. In the physical sample chain, each node represents an independently existing physical sample entity, and the directed edges between nodes represent the physical derivation or state transition relationships between physical sample entities. In the medical order business chain, each node represents a business object, and the directed edges between nodes represent the logical derivation or merging relationships between business objects. The graph alignment module is used to perform a constrained graph alignment operation on the physical sample chain and the medical order business chain, including: for the business object nodes to be aligned in the medical order business chain, selecting candidate physical sample entity nodes in the physical sample chain that simultaneously satisfy the temporal monotonicity constraint, the fork consistency constraint, and the platform routing constraint to form a candidate alignment relationship set; calculating the comprehensive explanatory value for each candidate scheme in the candidate alignment relationship set, and selecting the candidate scheme with the smallest comprehensive explanatory value as the alignment result; The record generation module is used to generate an exchange object record for each successfully aligned business object node and physical sample entity node based on the alignment result.

[0015] In another aspect, this application also provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the cross-system sample exchange method based on the data exchange platform as described above.

[0016] In another aspect, this application provides a storage medium having stored thereon computer program instructions that can be executed by a processor to implement the cross-system sample exchange method based on a data exchange platform as described above.

[0017] Another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the cross-system sample exchange method based on a data exchange platform as described above.

[0018] This application constructs a physical sample chain and a medical order business chain separately, and introduces temporal monotonic constraints, fork consistency constraints, platform routing constraints, and a comprehensive interpretation value selection mechanism between the two. This elevates the identification of cross-system sample exchange objects from a static association method based on field equivalence to a constrained alignment method based on structural relationships. It can accurately identify the correspondence between business objects and physical sample entities in complex business scenarios such as sample packaging, reuse, additional testing, and re-examination, reducing hidden errors caused by seemingly correct field matching but incorrect actual mapping paths. At the same time, this invention adopts an event-adaptive access method for new source systems, and the alignment logic does not depend on a single system identification rule, thus possessing good system compatibility and scalability. Furthermore, it can provide a reliable basis for data synchronization, result backfilling, report generation, and full-process traceability by generating exchange object records. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0020] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a schematic diagram of a cross-system sample exchange method based on a data exchange platform, provided as an embodiment of this application.

[0021] Figure 2 This is a schematic diagram illustrating the construction process of the directed graph structure of the physical sample chain and the medical order business chain provided in the embodiments of this disclosure.

[0022] Figure 3 This is a schematic diagram of the graph alignment operation process provided in the embodiments of this disclosure.

[0023] Figure 4 This is a schematic diagram of a cross-system sample exchange system based on a data exchange platform, provided as an embodiment of this application.

[0024] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] 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, and 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.

[0026] The cross-system sample exchange method provided in this disclosure is applicable to medical testing laboratories equipped with multiple detection technology platforms. For example, the laboratory can simultaneously operate a next-generation sequencing (NGS) platform, a quantitative polymerase chain reaction (qPCR) platform, and a digital polymerase chain reaction (dPCR) platform to provide personalized gene testing services for oncology, infectious diseases, and chronic diseases. In this scenario, the hospital information system (HIS), laboratory information system (LIS), and the instrument management systems of each testing platform operate independently and need to frequently exchange sample-related data. Because samples undergo operations such as aliquoting, reuse, additional testing, and retesting during the testing process, the correspondence between their physical identifiers and operational identifiers changes dynamically as the process progresses. The prerequisite for this method is that each source system can output its generated sample flow event data and operational event data. The former includes barcode information, container identifiers, aliquoting records, platform batch identifiers, operation identifiers, timestamps, and well position information; the latter includes application form information, project combination information, and retesting or additional testing request information. The data exchange platform, acting as an intermediary layer between the source systems, receives the aforementioned events and performs subsequent processing.

[0027] The following detailed description, in conjunction with specific embodiments, illustrates the implementation process of the cross-system sample exchange method based on a data exchange platform described in this application. It should be noted that these embodiments are merely for explaining this application and are not intended to limit the scope of protection of this application. Any conventional adjustments or substitutions made by those skilled in the art to the steps without departing from the concept of this application should be included within the scope of protection of this application.

[0028] like Figure 1 As shown in the figure, this application discloses a schematic diagram of a cross-system sample exchange method based on a data exchange platform, including the following method steps: S1. Receive sample flow events and business events from various source systems. Construct a directed graph structure of a physical sample chain based on the sample flow events, and construct a directed graph structure of a medical order business chain based on the business events. In the physical sample chain, each node represents an independently existing physical sample entity, and the directed edges between nodes represent the physical derivation or state transition relationship between physical sample entities. In the medical order business chain, each node represents a business object, and the directed edges between nodes represent the logical derivation or merging relationship between business objects. S2, performing a constrained graph alignment operation on the physical sample chain and the medical order business chain, including: for the business object nodes to be aligned in the medical order business chain, selecting candidate physical sample entity nodes in the physical sample chain that simultaneously satisfy the temporal monotonicity constraint, the fork consistency constraint, and the platform routing constraint, forming a candidate alignment relationship set; calculating the comprehensive explanatory value for each candidate scheme in the candidate alignment relationship set, and selecting the candidate scheme with the smallest comprehensive explanatory value as the alignment result; S3. Based on the alignment result, generate an exchange object record for each successfully aligned business object node and physical sample entity node.

[0029] In some embodiments, for step S1, the data exchange platform receives sample flow events and business events from each source system and constructs two independently maintained directed graph structures respectively.

[0030] The data exchange platform continuously monitors event messages from various source systems. Upon arrival of each event message, the platform first determines whether it is a sample transfer event or a business event based on the type identifier field carried in the message. Sample transfer events refer to events directly related to the generation, transfer, consumption, or status change of physical samples, such as sampling confirmation, dispensing operations, machine registration, operation completion, quality control judgment, and sample cancellation. Business events refer to events related to business processes such as clinical orders, test requests, project arrangements, or report generation, such as order issuance, project splitting, additional test requests, retest requests, and report merging instructions.

[0031] For each source system, the data exchange platform connects via an event adapter. Each source system corresponds to one event adapter, which is responsible for converting the raw event messages output by the source system into a unified standard event format within the data exchange platform. The standard event format includes at least four types of fields: event type identifier, related object identifier, timestamp, and source system identifier. The event adapter only defines the field extraction and format conversion rules and does not involve cross-system field mapping logic. When a new source system is added to the laboratory, only the event adapter corresponding to that system needs to be added. The data exchange platform can then incorporate the events generated by that system into the subsequent processing flow, and the integration of the new events with the existing graph structure is completed by constrained graph alignment operations.

[0032] like Figure 2 As shown, Figure 2 This is a schematic diagram illustrating the construction process of the directed graph structure of the physical sample chain and medical order business chain provided in this embodiment of the disclosure. In step S201, the directed graph structure of the physical sample chain is constructed based on the sample transfer events.

[0033] The physical sample chain is represented by a directed graph structure, which describes the flow and differentiation of sample entities in the actual detection process. Each node in the graph represents a sample entity with independent physical existence, that is, a sample or container that can be independently tracked and manipulated in the real world.

[0034] Based on the stage of the sample entity in the testing process, nodes are divided into the following types: Original sampling container node, corresponding to the initial sample container obtained directly from the patient; Dispensing container node, corresponding to the sub-container separated from the original container or other containers; Loading entity node, corresponding to the sample entity that has been loaded onto a specific testing platform and participated in a certain testing operation; Re-testing entity node, corresponding to the sample entity that re-enters the testing process because the quality control results do not meet the preset standards; Discarded entity node, corresponding to the sample entity that has been consumed or withdrawn from circulation due to expiration, contamination, or other reasons.

[0035] Each node carries at least a container identifier or barcode, a container type identifier, a timestamp indicating entry into the current state, and a current state flag attribute. These attributes are all derived from existing data fields in each source system. In some embodiments, the machine-mounted entity node may also include hole number and batch identifier attributes.

[0036] In the physical sample chain, directed edges between nodes represent physical derivation or state transition relationships between physical sample entities. Edge types include: packaging generation edges, pointing from the source container node to the packaging container node, representing a derivation relationship formed by packaging operations; loading edges, pointing from the container node to the loading entity node, indicating that the sample is loaded onto the testing platform; reuse edges, pointing from an existing container node to another loading entity node, indicating that the same physical container is used for testing operations on different platforms or in different batches; re-inspection derivation edges, pointing from the loading entity node to the re-inspection entity node; and deregistration edges, pointing from any active node to a discarded entity node.

[0037] The distinction between loading edges and reused edges is based on whether the container already has at least one loading edge pointing to other detection platforms. If it does, the current edge is a reused edge; otherwise, it is a loading edge. Each edge carries an operation timestamp, operation type identifier, and source system identifier.

[0038] In one embodiment, the specific construction process is as follows: After receiving a sample transfer event, the data exchange platform parses the container identifier, operation type, timestamp, and platform identifier. If the operation type is sampling confirmation, an original sampling container node is created in the graph, and the original sampling container node can be used as the source node of the physical sample chain.

[0039] If the operation type is a repackaging operation, a repackaging container node is created. The existing source container node in the graph is located using the source container identifier carried in the event, and a repackaging generation edge is established from that source container node to the new repackaging container node. If the operation type is a machine registration, a machine registration entity node is created, and a machine loading edge or reuse edge is established according to the aforementioned distinction criteria. The processing of re-inspection and deregistration events is similar, creating re-inspection entity nodes or deprecated entity nodes and their corresponding derived edges or deregistration edges, respectively. Through the above process, the physical sample chain gradually grows into a directed graph capable of expressing the repackaging, branching, and reuse convergence topology.

[0040] In step S202, a directed graph structure of the medical order business chain is constructed based on the business events. The medical order business chain represents the evolution of clinical business requests in the medical order processing flow using a directed graph structure. Each node in the graph represents a business object, and the directed edges between nodes represent the logical derivation or merging relationships between business objects.

[0041] Node types include: Patient Anonymous Identifier Node, serving as the anonymous attribution node for each visit identifier node under the same patient; Visit Identifier Node, corresponding to a single visit or batch of samples submitted by the patient; Application Node, corresponding to a clinically issued testing application; Project Group Node, representing the collection of projects after the application is split according to the testing platform category; Additional Project Node, representing testing projects added to the original application; Retesting Task Node, representing a retesting task initiated due to result verification requirements; and Report Merging Node, representing the merging relationship where multiple test results need to be summarized into the same report. Corresponding edge types include Order Placement Edge, Item Splitting Edge, Additional Edge, Retesting Application Edge, and Result Merging Edge.

[0042] The construction process of the medical order business chain is similar to that of the physical sample chain: After receiving a business event, the data exchange platform parses the event type and related business identifiers, creates corresponding business object nodes and edges, and inserts them into the directed graph structure of the medical order business chain. For example, when a medical order placement event is received, if the corresponding patient anonymous identifier node does not exist, the patient anonymous identifier node is created first; then, a visit identifier node and an application form node are created, and order placement edges are established from the patient anonymous identifier node to the visit identifier node, and from the visit identifier node to the application form node; when a project splitting event is received, a project group node is created and splitting edges are established from the application form node to each project group node; when an additional testing request is received, an additional project node is created and an additional edge is established.

[0043] The physical sample chain and the medical order business chain are maintained independently within the data exchange platform, evolving independently within their respective directed graph structures. The data exchange platform does not require any single node to simultaneously carry complete physical and business information. In a multi-system environment, the same business object often corresponds to multiple physical sample entities, and the same physical sample entity often carries different business objects at different stages. Traditional single-master index schemes bind physical identifiers and business identifiers to a single record, which can easily lead to mapping path errors when dealing with the aforementioned many-to-many relationships. Superficially, the fields may match, but in reality, the wrong object is being associated.

[0044] In some embodiments, for step S2, a constrained graph alignment operation is performed on the physical sample chain and the medical order business chain. The graph alignment operation establishes a structurally consistent mapping relationship between the physical sample chain and the medical order business chain. For the business object nodes to be aligned in the medical order business chain, which are typically leaf-level nodes such as project group nodes, append project nodes, or re-examination task nodes, the data exchange platform filters candidate physical sample entity nodes in the physical sample chain that simultaneously satisfy the temporal monotonicity constraint, the bifurcation consistency constraint, and the platform routing constraint. The candidate nodes that satisfy all constraints are combined into a candidate alignment relationship set. Subsequently, the comprehensive interpretation cost value of each candidate scheme in this set is calculated, and the candidate scheme with the smallest comprehensive interpretation cost value is selected as the alignment result.

[0045] like Figure 3 As shown, Figure 3 This is a schematic diagram of the graph alignment operation process provided in an embodiment of this disclosure. In step S301, the service subgraph range containing the node to be aligned is determined.

[0046] During alignment calculations, the data exchange platform first starts with the business object node to be aligned and traces backward along the directed edges in the medical order business chain. It continues tracing through the application node until it reaches the visitor identification node. If a patient anonymous identification node exists in the business chain, it continues tracing back to that node, thus determining the scope of the business subgraph containing the node to be aligned. This business subgraph scope covers all business object nodes under the same visitor identification node or the same patient anonymous identification node as the current node to be aligned, along with their logical derivation and merging relationships.

[0047] After determining the scope of the business subgraph, the data exchange platform searches for business object nodes within this scope that have already established alignment relationships with certain nodes in the physical sample chain. Using these aligned physical sample entity nodes as anchor points, it traces upwards along the directed edges in the physical sample chain to its source container node, and then expands downwards from the source container node to determine the scope of the physical subgraph that may be related to the current business subgraph. If there are no business object nodes with established alignment relationships within the scope of the business subgraph, then all nodes in the physical sample chain are used as the initial scope of the physical subgraph.

[0048] In step S302, within the scope of the aforementioned business subgraph and physical subgraph, the data exchange platform enumerates candidate physical sample entity nodes in the physical subgraph for each leaf node in the business subgraph and performs three constraint checks in sequence.

[0049] The temporal monotonicity constraint is validated because it states that the request initiation timestamp of the business object node to be aligned must not be later than the irreversible termination timestamp of its candidate physical sample entity node. In other words, the physical sample entity aligned to a business request must not have been destroyed or irreversibly consumed at the time the request is initiated.

[0050] During the screening process, the data exchange platform maintains a state time interval for each node in the physical sample chain. The start of this interval is the timestamp when the node was created, and the end is the timestamp when the node entered a discarded or irreversibly consumed state. If the node has not yet terminated, the end is marked as open. The data exchange platform extracts the request initiation timestamp of the business object node to be aligned and compares this timestamp with the state time interval of each candidate physical sample entity node. If the request initiation timestamp falls after the end of the state time interval, meaning the physical entity has terminated before the business request was initiated, the two timestamps are incompatible, and the candidate node is excluded. After this step, only time-sequentially feasible physical sample entity nodes are retained in the candidate set.

[0051] The principle is that samples that no longer exist cannot be used in subsequent detection tasks. By introducing temporal verification into the alignment calculation, a large number of candidate relationships that seem to match at the field level but are impossible to hold in the time dimension can be eliminated, thereby reducing the search space and lowering the risk of misalignment.

[0052] The verification of fork consistency constraints focuses on the structural correspondence between the project splitting topology of the business chain and the packaging topology of the physical chain. When a request form node in the medical order business chain splits into multiple project group nodes through a splitting edge, for example, if a request form contains tests that need to be performed on both the NGS platform and the qPCR platform, splitting into two project group nodes—the candidate physical sample entity nodes aligned with these in the physical sample chain should originate from the same source container node, and the number of on-machine entity nodes reached directly from this source container node via the on-machine loading edge, or via the packaging generation edge and then via the on-machine loading edge or reuse edge, should be compatible with the aforementioned multiple project group nodes. If a container in the physical sample chain has only a single on-machine loading edge and no packaging structure, then this container cannot be aligned to multiple project groups under a request form with multiple splitting forks.

[0053] During the specific verification process, the data exchange platform counts the number of downstream branches and the type of detection platform reached by each branch for each source container node in the physical sample chain. Simultaneously, it counts the number of sub-branches and the target detection platform category declared by each branch for each application node in the medical order business chain. For candidate alignment combinations of multiple project group nodes under the same application, the data exchange platform verifies whether these candidate physical sample entity nodes originate from the same source container node or are a set of nodes with a sub-packaging derivation relationship, and whether the number of branches on the physical chain side is not less than the number of sub-branches on the business chain side. Candidate combinations that do not meet the above conditions are removed from the candidate alignment relationship set.

[0054] The reason why fork consistency constraints are effective in differentiating between different branches is that they utilize structural information that naturally exists in the verification process but is not used as the primary criterion in traditional systems, namely, the topology of the fork. Traditional solutions often use sample numbers or application numbers for direct field binding, without distinguishing the derivation relationships between branches after fork. Therefore, when multiple project teams corresponding to one application execute on different platforms and use different fork samples, the field binding solution is prone to aligning the project teams to the wrong physical branches.

[0055] Platform routing constraints require that the target testing platform category declared by the project group node in the medical order business chain be consistent with the testing platform category actually reached by the physical sample chain node it is aligned with. The correspondence between target testing platform categories and testing platform categories is determined by a preset project code to platform category mapping table. This mapping table records which categories of testing platforms each testing project code can be executed on. In some embodiments, this mapping table can be configured to allow certain platform substitution relationships; for example, some projects can be executed on both the NGS platform and the dPCR platform, in which case the project code corresponds to two acceptable platform categories in the mapping table.

[0056] When performing this constraint verification, the data exchange platform extracts the declared target detection platform category from the project group node, extracts the actual detection platform category it arrived at from the login record of the candidate physical sample entity node, and queries the project code-platform category mapping table to determine whether the two are consistent or belong to an allowed substitution relationship. Candidate nodes that do not meet the requirements are excluded from the set.

[0057] After layer-by-layer filtering based on temporal monotonicity constraints, fork consistency constraints, and platform routing constraints, only candidate schemes that simultaneously satisfy all three constraints are retained in the candidate alignment relationship set.

[0058] Optionally, in some scenarios, clinicians may add new tests after the original tests are completed, or require retesting for quality control reasons. In this case, a new retest task node or additional item node is added to the medical order business chain. For such scenarios, the graph alignment operation also performs backflow constraint verification: the data exchange platform searches the physical sample chain for the source container node currently aligned with the application form to which the new node belongs, traverses the downstream branches of that source container node, identifies physical sample entity nodes whose state is not terminated and whose platform category is compatible with the target platform of the new node, and uses these as priority candidate alignment objects. The compatibility is determined according to the consistency or substitutability relationship in the item code and platform category mapping table.

[0059] Provided the sample size is sufficient and the sample has not expired, retesting and additional testing typically reuse existing packaged samples. Only when no unterminated branches satisfying the above conditions exist after traversal will the data exchange platform mark the newly added business object node as awaiting a new sample event, and will not forcibly establish an alignment relationship at the current moment.

[0060] In step S303, the comprehensive interpretation value is calculated for each candidate scheme in the candidate alignment relationship set, and the candidate scheme with the smallest comprehensive interpretation value is selected as the alignment result.

[0061] After all the above constraints have been verified, there may still be multiple formally feasible candidate solutions in the candidate alignment relationship set. The data exchange platform calculates the comprehensive interpretive cost value of each candidate solution and selects the best one.

[0062] The comprehensive explanation of cost is that it equals the weighted sum of the costs of packaging quantity difference, time span difference, and platform routing change, each multiplied by its corresponding weight coefficient. The calculation formula is as follows:

[0063] in, To provide a comprehensive explanation of its value; The cost of the difference in the number of repackaged items represents the result after normalization of the absolute value of the difference between the number of sub-item branches in the medical order business chain and the actual number of repackaged items in the physical sample chain, using a preset quantity benchmark value. The time span difference cost represents the portion of the interval between the business request time and the physical sample state start time that exceeds the preset normal range, and is the result after normalization by the preset time base value. If the interval falls within the normal range, this item is set to zero. The platform routing change cost represents the pre-defined dimensionless substitution cost accumulated when the actual platform of the sample entity in the physical sample chain and the declared platform of the project group node in the business chain are substitutable. If the two platform categories are completely identical, this item is zero. , and These are the weighting coefficients corresponding to the three costs mentioned above.

[0064] The preset dimensionless substitution cost value is a non-negative penalty value pre-configured for the combination of project code, declared platform category and actual platform category. When the declared platform category is consistent with the actual platform category, the penalty value is zero. When the two belong to an allowed substitutable relationship, the corresponding penalty value is obtained by looking up the table according to the preset substitution level in the mapping table of project code and platform category. When the two do not belong to an allowed substitutable relationship, the corresponding candidate scheme is excluded in the platform routing constraint verification stage. The value of the preset dimensionless substitution cost value is limited to a preset range, preferably [0,1].

[0065] The preset normal range is predetermined based on the statistical distribution between the historical business request time and the physical sample status start time of similar detection projects; the preset time benchmark value and the preset quantity benchmark value are predetermined based on the statistical distribution of historical aligned samples; the preset substitution value is predetermined based on the platform substitutable relationship recorded in the project code and platform category mapping table.

[0066] in, , , The alignment accuracy can be determined through statistical regression analysis based on the frequency of various discrepancies and the probability of misalignment in historical sample exchange records of the laboratory. Specifically, using historical records of confirmed correct alignment and confirmed incorrect alignment as training samples, three discrepancy costs as independent variables, and alignment accuracy as the dependent variable, the coefficients of each independent variable are obtained by fitting a logistic regression or similar statistical model, and then normalized as weight coefficients. In scenarios where sufficient historical data is lacking, laboratory managers can also pre-set the alignment based on business priorities.

[0067] Optionally, the three weighting coefficients can all range from 0 to 1, and their sum is normalized to 1. In actual operation, the data exchange platform can periodically recalculate the weighting coefficients based on the accumulated alignment results to adapt to changes in the detection business structure.

[0068] After calculating the comprehensive interpretation cost value by substituting each candidate solution into the above formula, the data exchange platform selects the candidate solution with the smallest comprehensive interpretation cost value as the alignment result. If multiple candidate solutions have the same cost value and are all the minimum, the solution with the smallest difference in time span cost can be selected.

[0069] In some embodiments, for step S3, after the alignment result is determined, the data exchange platform generates an exchange object record for each successfully aligned business object node and physical sample entity node. This record includes business-side identification information (i.e., the business object node's business identifier number, application number, project code, and target detection platform category), physical-side identification information (i.e., the physical sample entity node's container identifier or barcode, container type identifier, actual detection platform category, and status time interval), and an alignment basis summary (recording the verification conclusions and comprehensive interpretation value of the constraints satisfied by the alignment). As the output of cross-system sample exchange, the exchange object record allows downstream systems to perform subsequent operations such as data synchronization, result backfilling, or report generation based on this record.

[0070] In a real-world operating environment, each source system continuously generates new sample transfer events and business events. Upon receiving a new event, the data exchange platform employs a local subgraph incremental recalculation strategy.

[0071] Specifically, when a new event arrives, the data exchange platform first determines whether the event is a sample transfer event or a business event. If it is a sample transfer event, the data exchange platform inserts the corresponding new node and new edge into the physical sample chain, and then determines the source container node associated with the new node. For a packaging operation event, the source container node is the node corresponding to the packaging source container; for a machine registration event, the source container node is the node corresponding to the container where the loaded sample is located.

[0072] The subgraph expanded downwards from the source container node is the affected physical subgraph. The data exchange platform further searches for business object nodes that are currently aligned with any node in the affected physical subgraph to determine the affected business subgraph. If the new event is a business event, the processing method is symmetrical: first, insert the new node and new edge into the medical order business chain; the subgraph expanded downwards from the application order node or visit identification node to which the new node belongs is the affected business subgraph; then, search for physical sample entity nodes that are currently aligned with any node in the affected business subgraph to determine the affected physical subgraph.

[0073] For sampling confirmation events, the original sampling container node created is the source container node; for re-inspection events and deregistration events, the original sampling container node to which the new node belongs is traced upstream, and the original sampling container node is determined as the source container node.

[0074] After determining the affected physical and business subgraphs, the data exchange platform re-executes the aforementioned constrained graph alignment operation only within this scope to obtain a new alignment result. The new alignment result is then compared with the stored alignment result: if they match, the existing exchange object records remain unchanged, and no messages are sent to downstream systems; if they do not match, incremental correction messages are sent only to the changed exchange object records to notify downstream systems to update the corresponding mapping relationships.

[0075] By limiting each recalculation to a local subgraph, the computational overhead of global recalculation in high-concurrency scenarios is avoided. Simultaneously, change detection reduces invalid messages pushed to downstream systems. In some embodiments, subgraphs corresponding to different patients or different patient batches are unrelated and can be distributed across different computing nodes for parallel processing.

[0076] In some embodiments, this method further includes detecting mapping path errors. Traditional single-primary-index schemes establish mappings using field equi-joins. When the same sample number corresponds to different business objects at different stages, or when the same business object is packaged to correspond to multiple physical entities, field equi-joins may establish incorrect mapping paths. These errors do not manifest as missing fields or abnormal formats, making them difficult to detect using conventional data integrity checks.

[0077] In this embodiment, the physical sample chain and the medical order business chain are maintained independently. Alignment operations are determined based on structural constraints such as fork topology, time sequence, and platform routing. Even if a candidate relationship is matchable at the field level, it is excluded if it violates any constraint at the structural level. Optionally, the data exchange platform records anomalies found during constraint verification as alarm information for management personnel to review. The alarm content may include node pairs that do not meet fork consistency requirements, timestamp details of time sequence conflicts, and project and platform combinations that do not match platform routing.

[0078] In some embodiments, when a laboratory replaces its LIS system or adds a new testing platform, the event message format and identification encoding generated by the new system may differ from those of the original system. Since the data exchange platform connects to each source system through event adapters, when adding a new source system, only the corresponding event adapter needs to be added to convert the original event messages of the new system into a standard event format, which can then be incorporated into the directed graph structure of the physical sample chain or medical order business chain.

[0079] The identification of exchanged objects is based on structural constraints rather than field equivalence comparisons; therefore, differences in identifier encoding between the old and new systems do not affect the alignment logic. During the system migration transition period, the data exchange platform can simultaneously receive events from both the old and new systems. Nodes corresponding to the old and new identifiers coexist in the same graph structure, and timing constraints, forking constraints, and platform routing constraints ensure the correct association between the old and new nodes at the structural level.

[0080] By establishing two independently evolving directed graph structures—the physical sample chain and the medical order business chain—and performing graph alignment with multi-dimensional constraints such as temporal monotonicity, fork consistency, platform routing, and backflow, this method transforms the identification of cross-system sample exchange objects from traditional field equivalence matching to structure-level constrained alignment. This method can handle complex scenarios where one application form corresponds to multiple physical samples, and one physical sample carries multiple business tasks, avoiding hidden errors caused by correct field matching but incorrect mapping paths. The incremental recalculation mechanism for local subgraphs limits the calculation scope to local subgraphs affected by new events, reducing runtime computational overhead while maintaining the accuracy of alignment results. The event adapter design ensures that the access process during the addition of a new source system or the system migration transition only involves format conversion adaptation; the graph alignment logic itself does not need to be modified.

[0081] It should be noted that although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowchart can be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0082] Please see Figure 4 , Figure 4 This application provides a cross-system sample exchange system based on a data exchange platform. The system embodiments are similar to... Figure 1 Corresponding to the illustrated method embodiments, this system can be specifically applied to various electronic devices. The system specifically includes: The event receiving and graph construction module 401 is used to receive sample flow events and business events from various source systems, construct a directed graph structure of physical sample chains based on the sample flow events, and construct a directed graph structure of medical order business chains based on the business events. In the physical sample chain, each node represents an independently existing physical sample entity, and the directed edges between nodes represent the physical derivation or state transition relationship between physical sample entities. In the medical order business chain, each node represents a business object, and the directed edges between nodes represent the logical derivation or merging relationship between business objects. Graph alignment module 402 is used to perform a constrained graph alignment operation on the physical sample chain and the medical order business chain, including: for the business object nodes to be aligned in the medical order business chain, screening candidate physical sample entity nodes in the physical sample chain that simultaneously satisfy the temporal monotonicity constraint, the fork consistency constraint, and the platform routing constraint to form a candidate alignment relationship set; calculating the comprehensive interpretation cost value for each candidate scheme in the candidate alignment relationship set, and selecting the candidate scheme with the smallest comprehensive interpretation cost value as the alignment result; The record generation module 403 is used to generate an exchange object record for each successfully aligned business object node and physical sample entity node based on the alignment result.

[0083] Each processing unit and / or module in the embodiments of this application can be implemented by an analog circuit that implements the functions described in the embodiments of this application, or by software that executes the functions described in the embodiments of this application.

[0084] Based on the same inventive concept, this application also provides an electronic device. The method corresponding to the electronic device can be the method in the foregoing embodiments, and its problem-solving principle is similar to that method. The electronic device provided in this application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the methods and / or technical solutions of the foregoing embodiments of this application.

[0085] Figure 5 The diagram illustrates the structure of an electronic device suitable for implementing the methods and / or technical solutions in the embodiments of this application. The electronic device includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) 502 or a program loaded from a storage section 508 into a random access memory (RAM) 503. The RAM 503 also stores various programs and data required for system operation. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input section 506, an output section 507, a communication section 509, and an input / output (I / O) interface 505 are also connected to the bus 504.

[0086] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a storage medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 501, it performs the functions defined in the methods of this application.

[0087] Another embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application described above.

[0088] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of electronic devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0089] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A cross-system sample exchange method based on a data exchange platform, characterized in that, include: The system receives sample flow events and business events from various source systems. Based on the sample flow events, it constructs a directed graph structure of a physical sample chain and a directed graph structure of a medical order business chain based on the business events. Each node in the physical sample chain represents an independently existing physical sample entity, and the directed edges between nodes represent physical derivation or state transition relationships between physical sample entities. Each node in the medical order business chain represents a business object, and the directed edges between nodes represent logical derivation or merging relationships between business objects. Performing a constrained graph alignment operation on the physical sample chain and the medical order business chain includes: for the business object nodes to be aligned in the medical order business chain, selecting candidate physical sample entity nodes in the physical sample chain that simultaneously satisfy the temporal monotonicity constraint, the fork consistency constraint, and the platform routing constraint to form a candidate alignment relationship set; calculating the comprehensive explanatory value for each candidate scheme in the candidate alignment relationship set, and selecting the candidate scheme with the smallest comprehensive explanatory value as the alignment result; Based on the alignment results, an exchange object record is generated for each successfully aligned business object node and physical sample entity node.

2. The method for cross-system sample exchange based on a data exchange platform according to claim 1, characterized in that, The temporal monotonic constraint is: the request initiation timestamp of the business object node to be aligned is no later than the irreversible termination timestamp of its candidate physical sample entity node. During the screening process, the data exchange platform maintains a state time interval for each node in the physical sample chain, extracts the request initiation timestamp of the business object node to be aligned, and excludes physical sample entity nodes whose state time interval is incompatible with the request initiation timestamp from the candidates.

3. The method for cross-system sample exchange based on a data exchange platform according to claim 1, characterized in that, The fork consistency constraint is as follows: if an application node in the medical order business chain splits into multiple project group nodes through the splitting edge, then the candidate physical sample entity nodes aligned with it in the physical sample chain originate from the same source container node, and are reached directly from the source container node via the loading edge, or via the packaging generation edge and then via the loading edge or reuse edge to reach the loading entity nodes that are compatible with the number of the multiple project group nodes. During the screening process, the data exchange platform calculates the number and type of downstream branches for each source container node in the physical sample chain, calculates the number of split branches and the target platform category for each application node in the medical order business chain, and removes candidate combinations with incompatible branch numbers or branch types from the candidate alignment relationship set.

4. The method for cross-system sample exchange based on a data exchange platform according to claim 1, characterized in that, The platform routing constraint is as follows: the target detection platform category declared by the project group node in the medical order business chain is consistent with the detection platform category actually reached by the physical sample chain node it is aligned with; the correspondence between the target detection platform category and the detection platform category is determined by a preset project code and platform category mapping table.

5. A cross-system sample exchange method based on a data exchange platform according to claim 1, characterized in that, The comprehensive interpretation cost is equal to the weighted sum of the cost of the difference in packaging quantity, the cost of the difference in time span, and the cost of platform route change, each multiplied by its corresponding weight coefficient. The cost of the difference in the number of repackaged items is the absolute value of the difference between the number of sub-item branches in the medical order business chain and the actual number of repackaged items in the physical sample chain; the cost of the difference in the time span is the portion of the interval between the business request time and the physical sample state start time that exceeds the preset normal range; the cost of the platform route change is the preset substitution value accumulated when the actual platform of the sample entity in the physical sample chain and the declared platform of the project group node in the business chain are substitutable.

6. The method for cross-system sample exchange based on a data exchange platform according to claim 1, characterized in that, The graph alignment operation also includes verification of backflow constraints: when a new re-examination task node or an additional project node is added to the medical order business chain, the data exchange platform searches for the source container node that is currently aligned with the application form to which the new node belongs in the physical sample chain, traverses the downstream branches of the source container node, and identifies sample entity nodes whose status is not terminated and whose platform category is compatible with the target platform of the new node as priority candidate alignment objects; only when there is no unterminated branch that meets the conditions is the new node marked as waiting for a new sample event.

7. The method for cross-system sample exchange based on a data exchange platform according to claim 1, characterized in that, The types of nodes in the physical sample chain include original sampling container nodes, packaging container nodes, machine-mounted entity nodes, re-inspection entity nodes, and discarded entity nodes; the types of directed edges include packaging generation edges, machine-mounted loading edges, reused edges, re-inspection derived edges, and deregistration edges; wherein, the distinction between machine-mounted edges and reused edges is based on whether the container previously had at least one edge pointing to a machine-mounted entity node. If it did, the current edge is a reused edge; otherwise, it is a machine-mounted edge.

8. The method for cross-system sample exchange based on a data exchange platform according to claim 1, characterized in that, The types of nodes in the medical order business chain include patient anonymity identification nodes, visit identification nodes, application form nodes, project group nodes, additional project nodes, re-examination task nodes, and report merging nodes; the types of directed edges include order placement edges, item splitting edges, additional edges, re-examination application edges, and result merging edges.

9. A cross-system sample exchange method based on a data exchange platform according to claim 1, characterized in that, The calculation process of the graph alignment operation includes: starting from the business object node to be aligned, tracing upwards in the medical order business chain to the visit identification node, and continuing to trace upwards to the patient anonymous identification node when there is one, to determine the scope of the business subgraph; determining the scope of the physical subgraph in the physical sample chain based on the nodes with existing alignment relationships in the scope of the business subgraph; within the scope of the business subgraph and the scope of the physical subgraph, enumerating candidate physical sample entity nodes in the physical subgraph that satisfy the temporal monotonic constraint and the platform routing constraint for each leaf node in the business subgraph, performing the verification of the fork consistency constraint to remove candidate combinations that do not meet the constraint, calculating the comprehensive interpretation cost value for the candidate schemes that pass the verification, and selecting the smallest one as the alignment result.

10. A cross-system sample exchange system based on a data exchange platform, characterized in that, include: The event receiving and graph construction module is used to receive sample flow events and business events from various source systems, construct a directed graph structure of physical sample chains based on the sample flow events, and construct a directed graph structure of medical order business chains based on the business events. In the physical sample chain, each node represents an independently existing physical sample entity, and the directed edges between nodes represent the physical derivation or state transition relationships between physical sample entities. In the medical order business chain, each node represents a business object, and the directed edges between nodes represent the logical derivation or merging relationships between business objects. The graph alignment module is used to perform a constrained graph alignment operation on the physical sample chain and the medical order business chain, including: for the business object nodes to be aligned in the medical order business chain, selecting candidate physical sample entity nodes in the physical sample chain that simultaneously satisfy the temporal monotonicity constraint, the fork consistency constraint, and the platform routing constraint to form a candidate alignment relationship set; calculating the comprehensive explanatory value for each candidate scheme in the candidate alignment relationship set, and selecting the candidate scheme with the smallest comprehensive explanatory value as the alignment result; The record generation module is used to generate an exchange object record for each successfully aligned business object node and physical sample entity node based on the alignment result.

Images