Cross-institution patient primary index dynamic matching system based on reinforcement learning

Abstract

The invention relates to the technical field of medical information, and particularly discloses a cross-institution patient primary index dynamic matching system based on reinforcement learning, which introduces a reinforcement learning mechanism, that is, a matching task is processed through a hierarchical mixed decision model. Specifically, firstly, new patient records and retrieved candidate records are paired to obtain a record pair set, and then, a contextual gambling machine is utilized to perform rapid and accurate automatic decision making on record pairs with high confidence. And when the conditions of fuzzy similarity and uncertain decision are encountered, the system seamlessly switches to the deep Q network to carry out finer strategy evaluation, or transfers the task to manual auditing, so that the decision risk of a single model in a complex scene is avoided. In this way, balance between automation efficiency and decision robustness is achieved, an intelligent EMPI matching process capable of dynamically adapting and self-optimizing is finally constructed, and the bottleneck in the prior art is effectively solved.

Description

Technical Field

[0001] The present application relates to the field of medical information technology, and more specifically, to a cross-institutional patient master index dynamic matching system based on reinforcement learning. Background Art

[0002] In modern healthcare informatization, the Inter-Institutional Master Patient Index (EMPI) is central to enabling regional medical data interoperability and building comprehensive patient health records. However, due to inconsistent data standards across medical institutions, patient records often contain issues such as name spelling discrepancies, inconsistent or missing ID number formats, and address changes. This results in multiple independent records for the same patient across different institutions. Accurately linking these dispersed records to a unique patient identity requires efficient and accurate matching technology. Traditional EMPI systems often rely on rule-based fuzzy matching algorithms or fixed similarity threshold models. While these approaches address this issue to some extent, their static matching logic struggles to adapt to the dynamic nature of medical data. For example, when new institutions join the platform, their unique data formats or quality fluctuations often significantly reduce the matching accuracy of pre-set rules. This requires extensive manpower to reconfigure rules and repeatedly adjust thresholds, resulting in high maintenance costs and inability to meet the growing demand for real-time matching.

[0003] To overcome the limitations of traditional methods, the industry has begun exploring the application of machine learning, particularly reinforcement learning, to patient record matching. Reinforcement learning uses trial-and-error interaction between an intelligent agent and its environment to autonomously learn optimal decision-making strategies from feedback from historical matches (such as manual review results). In theory, it can dynamically adapt to data changes and reduce manual intervention. However, directly applying reinforcement learning to complex EMPI matching scenarios faces challenges. First, matching decisions depend not only on the similarity between records but also on contextual information such as data source reliability and record quality. A single reinforcement learning model struggles to effectively integrate this multi-dimensional, heterogeneous information. Second, in practical applications, matching decisions require a balance between automated processing and manual review. For fuzzy matches with low confidence, forcing the model to make a match or no match decision can easily introduce incorrect links or miss correct ones. Over-reliance on manual review compromises efficiency.

[0004] Therefore, there is no reinforcement learning matching solution in the prior art that can balance automation efficiency under high confidence and decision robustness under low confidence. Summary of the Invention

[0005] In order to solve the above technical problems, this application is proposed.

[0006] According to one aspect of the present application, a cross-institutional patient master index dynamic matching system based on reinforcement learning is provided, which includes: a new patient record acquisition module for acquiring new patient records from external medical institutions; an index key generation module for generating index keys based on the standardized new patient records after standardizing the new patient records; a candidate module for performing a candidate set search in an EMPI database based on the index keys to obtain a candidate record set; a pairing module for pairing the new patient record with each candidate record in the candidate record set to obtain a record pair set; a record pair processing module for performing multi-dimensional similarity calculation and context feature addition on each record pair in the record pair set to obtain a record pair feature vector list; a decision module for inputting each record pair feature vector in the record pair feature vector list into a hierarchical hybrid decision model to obtain a decision result list, the hierarchical hybrid decision model including a contextual bandit model and a deep Q network; and a decision result list execution module for executing the decision result list to obtain an updated EMPI database or a manual review task.

[0007] Compared with the prior art, the present application provides a cross-institutional patient master index dynamic matching system based on reinforcement learning. In order to solve the problems of poor adaptability of traditional static rules and high manual maintenance costs, a reinforcement learning mechanism is introduced, that is, matching tasks are handled through an innovative hierarchical hybrid decision model. Specifically, the new patient records and the retrieved candidate records are first paired to obtain a set of record pairs, and the context gambling machine is used to make fast and accurate automated decisions on the record pairs with high confidence, effectively coping with data quality fluctuations. When encountering situations where similarity is fuzzy and decision-making is uncertain, the system seamlessly switches to a deep Q network for more refined strategy evaluation, or transfers the task to manual review, thereby avoiding the decision-making risks of a single model in complex scenarios. In this way, contextual information is integrated, and while ensuring high-precision matching, a balance between automation efficiency and decision robustness is achieved, and ultimately an intelligent EMPI matching process that can dynamically adapt and self-optimize is constructed, effectively solving the bottleneck faced by the prior art. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The above and other purposes, features, and advantages of the present application will become more apparent through a more detailed description of the embodiments of the present application in conjunction with the accompanying drawings. The accompanying drawings are intended to provide a further understanding of the embodiments of the present application and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the present application and do not constitute a limitation of the present application. In the drawings, the same reference numerals generally represent the same components or steps.

[0009] Figure 1 This is a block diagram of a cross-institutional patient master index dynamic matching system based on reinforcement learning according to an embodiment of the present application.

[0010] Figure 2 Schematic diagram of data flow of a cross-institutional patient master index dynamic matching system based on reinforcement learning according to an embodiment of the present application.

[0011] Figure 3 This is a block diagram of a record pair processing module in a cross-institutional patient master index dynamic matching system based on reinforcement learning according to an embodiment of the present application.

[0012] Figure 4 This is a block diagram of a decision module in a cross-institutional patient master index dynamic matching system based on reinforcement learning according to an embodiment of the present application.

[0013] Figure 5 This is a data flow diagram of the decision result list execution module in the cross-institutional patient master index dynamic matching system based on reinforcement learning according to an embodiment of the present application. DETAILED DESCRIPTION

[0014] The following describes embodiments of the present disclosure in more detail with reference to the accompanying drawings. While the drawings illustrate certain embodiments of the present disclosure, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

[0015] It should be understood that the various steps described in the method embodiments of the present disclosure may be performed in a different order and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this respect.

[0016] This application is proposed to address the problems existing in the aforementioned prior art. Figure 1 This is a block diagram of a cross-institutional patient master index dynamic matching system based on reinforcement learning according to an embodiment of the present application. Figure 2 Schematic diagram of data flow of a cross-institutional patient master index dynamic matching system based on reinforcement learning according to an embodiment of the present application. Figure 1 and Figure 2As shown, according to an embodiment of the present application, a cross-institutional patient master index dynamic matching system 100 based on reinforcement learning includes: a new patient record acquisition module 110 for acquiring new patient records from external medical institutions; an index key generation module 120 for generating index keys based on the standardized new patient records after standardizing the new patient records; a candidate module 130 for performing a candidate set search in the EMPI database based on the index keys to obtain a candidate record set; a pairing module 140 for pairing the new patient record with each candidate record in the candidate record set to obtain a record pair set; a record pair processing module 150 for performing multi-dimensional similarity calculation and context feature addition on each record pair in the record pair set to obtain a record pair feature vector list; a decision module 160 for inputting each record pair feature vector in the record pair feature vector list into a hierarchical hybrid decision model to obtain a decision result list, wherein the hierarchical hybrid decision model includes a contextual bandit model and a deep Q network; and a decision result list execution module 170 for executing the decision result list to obtain an updated EMPI database or manual review task.

[0017] Specifically, the new patient record acquisition module 110 is used to obtain new patient records from external medical institutions. It is understandable that in the process of regional medical information integration, the core goal is to establish a unified electronic health record for each patient throughout his or her life cycle. However, patients' medical treatment behavior is naturally cross-regional and cross-institutional, and their health information is scattered in various independent hospitals, clinics or physical examination centers. If these scattered records cannot be effectively integrated, information islands will be formed, leading to problems such as repeated examinations, medication conflicts, and incomplete medical history. Therefore, in order to break down these barriers and achieve the continuity and integrity of patient information, the first prerequisite is to actively and continuously collect patient information from different data sources. It is the starting point and data entry of the entire dynamic matching process, ensuring that any newly generated patient information can be promptly included in the main index system for identification and archiving.

[0018] In a specific implementation, the new patient record acquisition module 110 is implemented as follows: the system deploys a secure and standardized data interface. This interface is based on medical information exchange standards such as HL7 or FHIR and uses the HTTPS protocol for encrypted transmission to ensure the security and compliance of data exchange.

[0019] When a new patient registers or visits an external medical institution, such as the First People's Hospital of City A, its internal information system (HIS) triggers an event. This event packages the newly generated patient record into a standard message format, such as an XML or JSON file containing basic patient information. This file might contain fields such as: {Name: "Zhang Wei", ID Number: "32010119850315XXXX", Date of Birth: "1985-03-15", Address: "No. 123, C Street, District B, City A", Data Source: "First People's Hospital of City A", Record Creation Time: "2023-10-26T09:30:00"}.

[0020] Next, the HIS system of City A's First People's Hospital actively pushes this message to a designated server endpoint through a preconfigured secure data interface, or the solution's new patient record acquisition module periodically pulls it. Upon receiving this data packet, the new patient record acquisition module first performs security checks, such as verifying the source IP address and API key, to ensure the legitimacy of the data source. Once these checks pass, the module parses the data packet and extracts structured patient information.

[0021] Specifically, the index key generation module 120 is configured to generate an index key based on the standardized new patient record after standardizing the new patient record. Accordingly, when processing patient data from different medical institutions, a serious challenge is data heterogeneity. Even for the same patient, their name may differ due to typos or aliases, such as Zhang Wei and Zhang Wei; address formats may vary widely, such as No. 123, Street C, District B and No. 123, Street C, District B; and ID numbers may differ by 15 or 18 digits or contain non-numeric characters. Directly searching the massive EMPI database using this raw, noisy data is not only inefficient, like looking for a needle in a haystack, but also misses a large number of potential matches due to minor discrepancies. Therefore, before conducting large-scale searches, the data must be cleaned and normalized, and core identifiers that are resistant to minor changes and have high discriminability must be extracted. Based on this, after standardizing the new patient records, this application generates index keys based on the standardized new patient records to build an efficient and accurate fast channel for subsequent candidate set retrieval through data standardization and index key generation.

[0022] In a specific implementation, the index key generation module 120 is implemented as follows: First, data standardization is performed. This stage aims to eliminate differences in format and expression. For the name field, the module will convert full-width characters to half-width characters, remove spaces, and convert Chinese characters to standard pinyin, for example, Zhang Wei is converted to zhangwei. For the ID number field, the module will verify its format and length, remove all non-alphanumeric characters, and uniformly upgrade the 15-digit old version number to 18 digits. For the date of birth field, it is uniformly formatted as YYYYMMDD, that is, 19850315. For the address field, the module will use the preset address dictionary and word segmentation algorithm to perform structured splitting and key element extraction. For example, No. 123, Street C, District B, City A is standardized to {Province: "Province A", City: "City A", District: "District B", Street: "Street C", House Number: "123"}, and remove minor information. After this stage, a standardized new patient record is obtained.

[0023] Next, an index key is generated based on this standardized record. The design goal of the index key is to have a certain degree of fault tolerance and high selectivity. This embodiment adopts a combined index key strategy to generate index keys of multiple different dimensions to improve the recall rate. For example, the following index keys can be generated: 1. Name Pinyin + Date of Birth key, combine the standardized name Pinyin with the date of birth to generate zhangwei19850315. This key is very efficient for accurate names and birthdays. 2. ID number key, directly use the standardized 18-digit ID number as the index key, which is the key with the highest discrimination. 3. Soundex (name) + Date of Birth key, to deal with spelling errors, apply the Soundex algorithm to the name Pinyin zhangwei to obtain a phonetic code, such as Z520. Then combine it with the date of birth to form Z52019850315. The Soundex algorithm can map strings with similar pronunciations but different spellings to the same code, thereby tolerating spelling errors. 4. Address key element key, extract the core elements in the standardized address, such as Street C, District B, City A, and combine them. Ultimately, the output is a standardized new patient record and a collection containing multiple index keys, such as {"zhangwei19850315", "32010119850315XXXX", "Z52019850315", "City A, District B, Street C"}.

[0024] Specifically, the candidate module 130 is configured to perform a candidate set search in the EMPI database based on the index key to obtain a candidate record set. It should be understood that when processing massive amounts of patient master index data, performing detailed similarity comparisons of a new record against millions or even tens of millions of existing records in the database would incur enormous computational overhead, completely failing to meet the real-time requirements of healthcare services. This matching approach is not only inefficient but also consumes significant computing resources. Therefore, an efficient screening strategy is required to quickly identify a highly relevant subset within the massive database, within a manageable range, before conducting a refined comparison. This subset should include all truly potentially matching records while excluding the vast majority of clearly irrelevant records. Therefore, to achieve this crucial rough screening process, the present application utilizes the index key generated in the previous step by performing a candidate set search in the EMPI database based on the index key, transforming the challenge of a full database scan into an efficient, narrow-scope, precise matching problem.

[0025] In a specific implementation, candidate module 130 is implemented as follows: This module interacts with a specially optimized EMPI database. This database not only stores the complete records of all patients but also pre-generates multiple index keys for each record using the same algorithm as that used by index key generation module 120. A high-speed search engine (for example, using B-tree or hash indexes) is also built for these index key fields. In other words, the EMPI database is not simply an information repository, but rather the cornerstone and historical repository of the entire matching system. Its construction is an ongoing, cumulative process: whenever a new patient record is confirmed as a new identity through the matching process, the record's complete information, along with its standardized data and the various index keys generated (such as ID number, name pinyin + date of birth, Soundex, etc.) are stored in the database and assigned a globally unique patient identifier (EMPI-ID). At the same time, the database management system creates an efficient index structure for these pre-generated index key fields. For example, hash indexes are used for high-cardinality, unique fields like ID numbers to achieve near-constant-time lookups, while B-tree indexes are used for fields like name pinyin and address that may require range or fuzzy queries. This database continues to grow and enrich over time, forming the criteria for matching decisions and search targets.

[0026] Candidate module 130 traverses each key in the input index key set and uses them to query the corresponding index fields in the EMPI database. The specific operation is as follows: First, the index key 32010119850315XXXX is used to search the EMPI database's ID number hash index for an exact match, and the matching EMPI-ID is returned. If the query hits a record, its unique identifier is EMPI-001. Next, the index key zhangwei19850315 is used to search the database's name pinyin + birthdate B-tree index. If the query hits EMPI-001 and another record EMPI-002 (possibly a patient with the same name and birthday), the index key Z52019850315 is then used to search the database's Soundex (name) + birthdate index fields. This query might hit EMPI-001, EMPI-002, and possibly a record named Zhang Wei, EMPI-003, since Zhang Wei's Soundex code might also be Z520. Finally, a query using the index key "City A, District B, Street C" against the database's address key element index field might return EMPI-001 and other records, such as EMPI-004, that reside in the same area. After all parallel query tasks complete, the candidate module collects all returned EMPI-IDs into a temporary, potentially duplicated list [EMPI-001, EMPI-001, EMPI-002, EMPI-001, EMPI-002, EMPI-003, EMPI-004]. The module then performs efficient deduplication on this list, generating a unique set of candidate IDs, {EMPI-001, EMPI-002, EMPI-003, EMPI-004}. This set represents all potential matches that could be associated with the new record across any dimension. Finally, the module initiates a batch database read operation, extracting all the detailed information for these four records from the EMPI database at once based on this set of IDs. The final output candidate record set is [complete information for record EMPI-001, complete information for record EMPI-002, complete information for record EMPI-003, and complete information for record EMPI-004].

[0027] Specifically, the pairing module 140 is used to pair the new patient record with each candidate record in the candidate record set to obtain a set of record pairs. It is understandable that after completing the rough screening of the candidate set, a small list of potential matches that are highly relevant to the new patient record is obtained. However, this list itself is only a set of independent records. The subsequent decision model needs to analyze not individual records, but the relationship between the new record and each candidate record. The core of the decision lies in comparison, that is, determining whether the new record A and the candidate record B refer to the same person. If they are not clearly organized into paired comparison units, the subsequent similarity calculation and feature extraction will become disordered and chaotic. Therefore, before entering the refined analysis stage, a clear and structured comparison framework must be established to solidify the one-to-one comparison relationship. Based on this, in the present application, the new patient record is paired with each candidate record in the candidate record set to obtain a set of record pairs.

[0028] In a specific implementation, pairing module 140 is implemented as follows: the module iterates through each candidate record in the candidate record set and combines each candidate record with the unique source record to form a record pair. This process can be imagined as a simple loop or mapping operation, converting a one-to-many potential relationship into multiple one-to-one entities to be analyzed. The module first extracts the complete information of the first record in the candidate record set, namely EMPI-001, and then pairs the source record Zhang Wei with EMPI-001 to generate the first record pair. Next, it processes the second candidate record, EMPI-002, and also pairs it with the source record to generate the second record pair. This process continues, processing EMPI-003 and EMPI-004, respectively, to generate the third and fourth record pairs.

[0029] After traversing all candidate records, the output is a structured set of record pairs. This set is represented by a list or array, where each element is a tuple or object containing a source record and a candidate record. For example, the final output data structure is: [(source record, candidate record EMPI-001), (source record, candidate record EMPI-002), (source record, candidate record EMPI-003), (source record, candidate record EMPI-004)].

[0030] Specifically, the record pair processing module 150 is used to perform multi-dimensional calculation of similarity and context feature addition on each record pair in the record pair set to obtain a list of record pair feature vectors. It should be understood that simply pairing new records with candidate records to form record pairs is far from sufficient for the subsequent reinforcement learning model to make intelligent decisions. The model cannot directly understand the original text such as Zhang Wei and Zhang Wei. What it needs is quantified and computable input. The basis for decision-making, that is, whether two records point to the same person, essentially depends on the degree of similarity between them in multiple dimensions such as name, ID card, address, etc., as well as implicit information such as data source and record quality. If these qualitative, multi-dimensional information are not converted into a unified, numerical expression, the model will not be able to compare and judge. Therefore, in order to convert the original, unstructured record pairs into a language that can be understood and processed by the machine learning model, that is, a numerical feature vector, the present application performs multi-dimensional calculation of similarity and context feature addition on each record pair in the record pair set. Figure 3 FIG. 1 is a block diagram of a record pair processing module in a cross-institutional patient master index dynamic matching system based on reinforcement learning according to an embodiment of the present application. Figure 3 As shown: In a specific implementation, the record pair processing module 150 includes: a name similarity calculation unit 151, which is used to calculate the Jaro-Winkler distance between the name field in the new patient record and the name field in the candidate record as name similarity; an ID number similarity calculation unit 152, which is used to calculate the Levenshtein distance between the ID number in the new patient record and the ID number in the candidate record as ID number similarity; an address similarity calculation unit 153, which is used to calculate the cosine similarity between the address in the new patient record and the address in the candidate record as address similarity; a birth date similarity calculation unit 154, which is used to accurately compare the birth date in the new patient record with the birth date in the candidate record to obtain the birth date similarity.

[0031] In a specific implementation, record pair processing module 150 operates as follows: Record pair processing module 150 receives a set of record pairs from pairing module 140 as input. Each record pair in this set is processed in parallel by a series of computational units within this module to generate a quantized feature vector. For example, consider the source record Zhang Wei and the candidate record EMPI-003, whose name is Zhang Wei, whose ID number is the incorrectly entered 32010119850315XXXX (32010119850315XXXA), whose address is No. 123, C Street, District B, City A, and whose date of birth is March 15, 1985. The processing process is as follows.

[0032] First, the name similarity calculation unit 151 quantifies the degree of similarity between two name fields, such as Zhang Wei in the source record and Zhang Wei in the candidate record. It's worth noting that the Jaro-Winkler distance algorithm demonstrates exceptional robustness and accuracy when dealing with short strings like names, particularly in combating common typos (such as misspellings and substitutions of similar-sounding characters). Unlike simple edit distance, it considers not only character identity but also character order and position, with a particularly strong reward for string prefix matches. This is highly consistent with the fact that the surname is typically placed at the beginning of Chinese names, effectively distinguishing between Zhang Wei and Li Wei. Specifically, the Jaro-Winkler algorithm's calculation process consists of two main steps. First, it calculates the basic Jaro similarity. This step involves finding matching characters in the two strings, Zhang Wei and Zhang Wei. The definition of matching here is relatively loose, meaning that the positions of two identical characters in their respective strings cannot differ too far. The distance threshold is half the length of the longer string minus one. In this example, Zhang Hewei and Zhang Hewei are both within each other's search range, so the matching character is Zhang. Next, the algorithm calculates the number of transpositions, that is, the number of times the matching characters are in a different order in the two strings, where the number of transpositions is 0. Based on the number of matching characters and the number of transpositions, the Jaro similarity can be calculated using a specific formula, which is: Jaro similarity = (1 / 3) * ((m / |s1|) + (m / |s2|) + ((mt) / m)), where s1 and s2 are the two strings to be compared, |s1| and |s2| are the lengths of the two strings, m is the number of matching characters in the two strings, and t is the number of transpositions. Before applying this formula to the example of this application, that is, comparing Zhang Wei (s1) and Zhang Wei (s2), the key parameters m and t in the formula must be determined. The premise for calculating m is to define the range of matching, that is, the maximum matching distance, which is calculated by taking half of the maximum length of the two strings, rounding down, and then subtracting one. For Zhang Wei and Zhang Wei, both of length 2, the maximum matching distance is zero, that is, only the same characters in exactly the same position in the two strings are considered to be matched. According to this rule, the first character Zhang of s1 matches the first character Zhang of s2, while the second character Wei does not match Wei. Therefore, the number of matching characters m is 1. The next step is to calculate the number of transpositions t. Transposition refers to the situation where the matching characters in two strings appear in an inconsistent order in their respective strings. The matching characters in the two strings need to be extracted in the original order to form two matching sequences. For Zhang Wei and Zhang Wei, their respective matching character sequences only have one character Zhang. Since the two sequences are exactly the same and there are no characters in inconsistent order, the number of transpositions is zero, that is, t is equal to 0. Finally, all the calculated parameters are substituted into the Jaro similarity formula for the final calculation.Substituting this into the formula yields: (1 / 3)*((1 / 2)+(1 / 2)+((1-0) / 1)). The final result is approximately 0.667. This value is the basic Jaro similarity, which objectively quantifies the similarity between Zhang Wei and Zhang Wei in character composition and arrangement. Next, the algorithm enters the Winkler correction. This step is intended to give additional credit to strings with prefix matches. The algorithm examines the length of consecutive matching characters from the beginning of the two strings, called the common prefix length. In the case of Zhang Wei and Zhang Wei, the common prefix is ​​Zhang, with a length of 1. The Winkler correction uses this common prefix length and a scaling factor, such as 0.1, determined through experimentation and tuning. This effectively weights the original Jaro similarity. The formula is: Jaro-Winkler = Jaro + Common Prefix Length*p*(1-Jaro). The resulting Jaro-Winkler similarity value is higher than the original Jaro similarity because it rewards correct last name matches. After this series of detailed calculations, the unit ultimately outputs a value between 0 and 1, such as 0.70, which not only reflects the overall high similarity between the two names, but also appropriately reflects the slight differences due to the different ending characters.

[0033] At the same time, the ID card number similarity calculation unit 152 begins processing the ID card number field. It obtains the source record's 32010119850315XXXX and the candidate record's 32010119850315XXXA (this is just an example of incorrect input). The unit uses the Levenshtein distance algorithm, which calculates the minimum number of single-character edits (insertions, deletions, or substitutions) required to convert one string into another. In this example, changing from the former to the latter requires replacing the trailing X with an A, resulting in an edit distance of 1. To normalize this distance to similarity, the formula 1-(edit distance / length of the longer string) is used. Therefore, the ID card number similarity is 1-(1 / 18)≈0.94.

[0034] Next, the address similarity calculation unit 153 processes the address field. It obtains the source record's address, No. 123, Street C, District B, City A, and the candidate record's address, No. 123, Street C, District B, City A. The core of this unit is a deep learning-driven text representation model, employing a domain-adaptive fine-tuned BERT model. The BERT model is essentially a multi-layer bidirectional encoder based on the Transformer architecture, incorporating a multi-layer self-attention mechanism and a feedforward neural network. A key component of the model is its massive parameter matrix, specifically the weights and biases, learned through unsupervised pre-training on a massive corpus of general text. The unit's processing begins with preprocessing the original address text. First, an address string, such as No. 123, Street C, District B, City A, is broken down by a specialized tokenizer into a series of tokens, such as ['[CLS]', 'A', 'City', 'B', 'District', 'C', 'Street', 'Road', '123', 'No.', '[SEP]']. These tokens are then fed into a fine-tuned BERT model. Within the model, each token is first mapped to an initial embedding vector, to which a positional encoding vector is added to preserve its order within the address. This sequence of vectors, imbued with positional information, then flows through the model's multi-layer Transformer encoder. At each layer, a self-attention mechanism calculates the association weights between each token and all other tokens in the address, enabling the model to understand contextual relationships. For example, "street" and "street" are equivalent in certain contexts. After multiple layers of complex nonlinear transformations, the model ultimately generates a context-rich output vector for each input token. To obtain a single vector representing the entire address, the unit employs a pooling strategy. A common strategy is to take the output vector corresponding to the special start symbol [CLS]. Another strategy is to average pool the output vectors of all tokens, taking the dimension-wise average. In this way, two slightly different addresses, "No. 123, Street C, District B, City A," and "No. 123, Street C, District B, City A," are each converted into two high-dimensional, dense address vectors. Finally, the unit calculates the cosine similarity between the two address vectors. This value measures the cosine of the angle between the two vectors. The result will be very close to 1.0, for example, 0.99, thus accurately quantifying the high degree of consistency between the two addresses at the semantic level.

[0035] Finally, the birth date similarity calculation unit 154 retrieves the birth date fields from both records, which are both 1985-03-15. This unit performs an exact string or date object comparison. If the two dates are identical, the similarity is 1.0; if there is a difference of even a single day, month, or year, the similarity is 0.0. In this example, the two dates are identical, so the birth date similarity is 1.0.

[0036] In a specific implementation, the record pair processing module 150 also includes: a context information extraction unit 155, used to extract context information related to the matching task, the context information including the data source, record quality score and processing timestamp; a similarity arrangement unit 156, used to arrange the data source, record quality score, processing timestamp, name similarity, ID number similarity, address similarity and date of birth similarity into a record pair feature vector.

[0037] Specifically, the subsequent processing of the record pair processing module 150 is jointly performed by the context information extraction unit 155 and the similarity ranking unit 156. These units are responsible for integrating the discrete similarity scores and background information into standard inputs usable by the machine learning model. The implementation process of the context information extraction unit 155 is a process of information aggregation and quantification. The input of this unit is a single record pair, such as the pairing of the source record Zhang Wei and the candidate record EMPI-003. Its task is to extract predefined contextual information from the metadata of this record pair. First, it extracts data source information. When the source record is obtained, it contains the identifier of its source institution, such as the First People's Hospital of City A. The candidate record EMPI-003 also stores its original source in its database entry, such as the Community Health Service Center of District B. To enable the model to process this categorical information, the unit queries a preset institution coding table and maps the First People's Hospital of City A to its unique numeric code, such as 101, and the Community Health Service Center of District B to 205. Next, the unit extracts the record quality score. This score is a score obtained by evaluating the completeness and standardization of the record based on a series of preset rules. For example, a record containing a standard 18-digit ID number, a structured address, and no obvious missing fields may have a quality score of 0.95; while a record that lacks a contact number and has an ambiguous address may have a score of only 0.70. The unit obtains the quality scores of the source record and the candidate record separately. Finally, the unit extracts the processing timestamp, which is the exact time when the current system performs the matching operation. This timestamp is converted to a numerical value, such as the number of seconds since a certain era (such as January 1, 1970), to capture the temporal characteristics of the matching behavior. After the context information extraction unit 155 completes information extraction and quantification, its output is passed to the similarity ranking unit 156 together with the similarity score obtained by the previous calculation unit. The input to this unit is all the discrete numerical features for a record pair: for example, name similarity 0.70, ID number similarity 0.94, address similarity 0.99, date of birth similarity 1.0, source record data source code 101, candidate record data source code 205, source record quality score 0.95, candidate record quality score 0.88, and processing timestamp 1698282000. The core function of the similarity ranking unit 156 is to organize these numerical values ​​into a one-dimensional numerical array, or feature vector, according to a predefined, fixed order. For example, the ranking order set by this unit is: [name similarity, ID number similarity, address similarity, date of birth similarity, source data source code, candidate data source code, source record quality score, candidate record quality score, timestamp].According to this order, the unit arranges and combines the above values ​​to generate the final record pair feature vector: [0.70, 0.94, 0.99, 1.0, 101, 205, 0.95, 0.88, 1698282000]. After each record pair in the record pair set has gone through the above process, the final output of record pair processing module 150 is a list of record pair feature vectors.

[0038] Specifically, the decision module 160 is configured to input each record pair feature vector in the list of record pair feature vectors into a hierarchical hybrid decision model to obtain a list of decision results. The hierarchical hybrid decision model includes a contextual bandit model and a deep Q-network. Accordingly, after obtaining the quantized record pair feature vectors, the system faces the final decision-making challenge: for each record pair, should it be determined as a match, a mismatch, or whether it should be submitted for review due to high uncertainty? Traditional fixed rule engines lack flexibility and cannot adapt to the diversity and complexity of data. A simple machine learning model may also struggle to strike a balance between efficiency and accuracy. In real-world applications, the matching relationships of many record pairs are obvious and can be processed quickly and automatically; however, a small number of ambiguous cases require deeper and more complex analysis. Using a single, heavyweight, and complex model to handle all cases would result in a significant waste of computing resources; conversely, using a lightweight model could lead to errors in complex situations. Therefore, this step introduces a hierarchical hybrid decision model to establish an intelligent triage mechanism: a contextual bandit handles the vast majority of cases, while uncertain cases are passed through a deep Q-network. This maximizes overall system processing efficiency while ensuring high accuracy.

[0039] In a specific implementation, Figure 4 FIG is a block diagram of a decision module in a cross-institutional patient master index dynamic matching system based on reinforcement learning according to an embodiment of the present application. Figure 4 As shown, the decision module 160 includes: an action expected immediate benefit calculation unit 161, which is used to input the record pair feature vector as a context into the contextual bandit model to obtain the expected immediate benefit of each action; a confidence calculation unit 162, which is used to calculate the confidence based on the expected immediate benefit of each action; a final action generation unit 163, which is used to determine whether the confidence exceeds a preset high confidence threshold, and in response to the confidence exceeding the preset high confidence threshold, determine the action with the highest expected immediate benefit as the final action; a decision result generation unit 164, which is used to input the record pair feature vector as the current state into the deep Q network in response to the confidence not exceeding the preset high confidence threshold to obtain the decision result.

[0040] In a specific implementation, the decision module 160 is implemented as follows: First, the action's expected immediate reward calculation unit 161 is performed. The contextual bandit model employs a linear upper confidence bound (LinUCB) model. This model maintains a separate parameter matrix for each possible action: match, mismatch, and submit for review. The weights and biases of these parameter matrices are obtained through offline training on a large amount of historical matching data. The model's architecture includes a feature mapping layer and three parallel linear regressors, one for each action. Upon receiving the input feature vector, the feature mapping layer may first expand it, for example by adding cross terms or polynomial terms to enhance its expressiveness. This expanded feature vector is then input into each of the three linear regressors. Each regressor performs a matrix multiplication operation, multiplying the input vector by its own parameter matrix to calculate an expected immediate reward for the corresponding action. For example, for the input feature vector, the model may output: an expected reward of 0.15 for a match action, 0.88 for a mismatch action, and 0.35 for a submit for review action.

[0041] Next, the confidence calculation unit 162 evaluates the degree of certainty of the model's decision based on these expected benefits. The calculation logic of this unit is: first find the maximum and second largest values ​​of the expected benefits among all actions. In this example, the maximum benefit is 0.88, which corresponds to mismatch, and the second largest benefit is 0.35, which corresponds to being sent for review. Then, the difference between these two values ​​is calculated, that is, 0.88-0.35=0.53. The larger the difference, the clearer the model's judgment on the best option and the higher the distinction from other options. In order to normalize this difference into a standard confidence score, it can be mapped through a Sigmoid function, or the difference can be directly used as a measure of confidence. Here, 0.53 is used as the confidence level.

[0042] Then, the final action generation unit 163 makes a judgment based on this confidence. A high confidence threshold is preset inside the unit. This threshold is obtained by testing and tuning on the validation set, and is intended to balance the automation processing rate and accuracy, for example, it is set to 0.5. The unit will compare the calculated confidence of 0.53 with the preset threshold of 0.5. Since 0.53 exceeds 0.5, the high confidence condition is met. Therefore, the unit will directly adopt the suggestion of the contextual bandit model and determine the action with the highest expected immediate benefit, that is, the mismatch, as the final action of the record pair. This decision result will be recorded, and the processing flow of the feature vector ends here without entering the more complex deep Q network layer.

[0043] When the upper-level contextual bandit model lacks sufficient confidence in the decision of a record pair, it means that this case is likely to be a complex problem. For example, two records are highly similar in name, but there are slight differences in the ID numbers, and the reliability of the data sources is inconsistent. In this case, a simple linear model may not be able to capture the complex, nonlinear interactions between features. Directly making a match or mismatch decision is very risky, and switching to manual review will reduce automation efficiency. Therefore, the system needs a system that can understand the potential associations behind these fuzzy features from a higher dimension and evaluate the long-term impact of each decision. To this end, the present application inputs the record pair feature vector as the current state into the deep Q network to obtain the decision result, so as to conduct an in-depth analysis of the complex record pairs, in order to make the best final decision while maintaining a high accuracy rate.

[0044] In a specific implementation, the decision result generation unit 164 includes: an action Q value generation subunit 1641, which is used to input the record pair feature vector as the current state into the deep Q network to obtain the Q value of each action; a probability calculation subunit 1642, which is used to calculate the final selection probability of each action based on the Q value and temperature parameter of each action; and a final action determination subunit 1643, which is used to determine the action corresponding to the one with the highest final selection probability as the final action.

[0045] The implementation is as follows: When the confidence score of a record pair does not exceed the preset high confidence threshold, the decision result generation unit 164 is activated. It receives the record pair feature vector from the previous stage as input. If a record pair feature vector (name and ID number are both highly similar, but not an exact match) results in a low confidence score, it will be input as the current state s into the deep Q network of this unit.

[0046] The deep Q network (DQN) on which the action Q value generation subunit 1641 relies is a multi-layer feedforward neural network whose core function is to approximate a complex Function, that is , which is used to evaluate the expected value of the future cumulative benefits that can be obtained by performing an action a in the current state s. The architecture of the network includes an input layer with the same number of neurons as the dimension of the feature vector; several hidden layers, which use nonlinear activation functions such as ReLU to capture the complex relationship between features; and an output layer with the number of neurons equal to the size of the action space, which is 3 here, corresponding to matching, mismatching, and sending for review. The weights and bias parameters of the network are obtained through the training process of deep reinforcement learning. When the above feature vector is input into the pre-trained DQN network as the current state s, it will undergo nonlinear transformation layer by layer of the network, and finally obtain three values ​​in the output layer, representing the three actions respectively. For example, the output might be: Q(s,match)=8.5, Q(s,mismatch)=6.2, Q(s,sent for review)=7.1.

[0047] Next, the probability calculation subunit 1642 receives these Q values ​​and converts them into selection probabilities. Directly selecting the action with the highest Q value may cause the model to be too deterministic and lack exploratory. Therefore, in a specific implementation, the probability calculation subunit 1643 is used to calculate the final selection probability of each action based on the Q value and temperature parameter of each action using the following formula, where the formula is: ;in, and is the Q value of each action, is the temperature parameter, The final selection probability for each action. In other words, a temperature parameter is used to regulate the impact of Q-values ​​on the final probability. T is a positive number, determined through experimentation and tuning on the validation set, for example, set to 0.8. Higher T values ​​result in a flatter probability distribution, favoring exploration; lower T values ​​result in a sharper probability distribution, favoring the action with the highest Q-value. This unit calculates the selection probability for each action. For example, P(match|s) ≈ 0.76, P(unmatch|s) ≈ 0.08, and P(submit for review|s) ≈ 0.16.

[0048] Finally, the final action determination subunit 1643 makes a decision based on these probabilities. It simply selects the action with the highest final selection probability as the final action. In this example, 0.76 is the highest probability value, and its corresponding action is match. Therefore, the unit determines match as the final decision result for this record pair.

[0049] Specifically, when the record-pair feature vectors are fed into a hierarchical hybrid decision model, the first layer is a lightweight contextual bandit model. For efficiency, this model's core is a linear regressor, meaning it excels at understanding linearly separable data. However, the original feature vectors directly concatenate similarity features (such as name and address similarity) and contextual features (such as data source and record quality). These two types of information have vastly different properties and scales. Their coupling can blur the feature space distribution and reduce the discrimination between different decision boundaries. For linear models, this ambiguity can severely impact their predictive accuracy. Therefore, before feeding the record-pair feature vectors into this linear model, they must be preprocessed to enhance their discrimination in the regression decision space, thereby improving the accuracy of the contextual bandit model's predictions of expected immediate returns.

[0050] In another specific implementation, the decision module includes: a record pair optimization unit, which is used to perform discrimination decoupling embedding optimization on the record pair feature vector to obtain an optimized record pair feature vector; a profit calculation unit, which is used to input the optimized record pair feature vector as context into the contextual bandit model to obtain the expected immediate profit of each action; a confidence generation unit, which is used to calculate the confidence based on the expected immediate profit of each action; a final action determination unit, which is used to determine whether the confidence exceeds a preset high confidence threshold, and in response to the confidence exceeding the preset high confidence threshold, determine the action with the highest expected immediate profit as the final action; a decision unit, which is used to input the optimized record pair feature vector as the current state into the deep Q network in response to the confidence not exceeding the preset high confidence threshold to obtain the decision result.

[0051] Based on this, in a specific implementation, the record pair optimization unit is used to: first, calculate the similarity distance matrix and the context distance matrix based on the feature vectors of each record pair. It should be understood that the original record pair feature vector directly couples the two heterogeneous information of intrinsic similarity and external context, resulting in fuzzy decoupling of its discrimination in the decision space. In order to solve this problem, it is necessary to separate the two types of information and quantify their respective global relationships. This step first splits each record pair feature vector into a similarity part and a context part. Then, the distance between all record pairs in the batch is calculated to form two matrices: the similarity distance matrix and context distance matrix . Each element in The eigenvalue represents the Hedi The Euclidean distance of a pair of records in similarity dimensions such as name and address; similarly, Each element in The eigenvalues ​​represent their distances in contextual dimensions such as data source and quality score. This makes the relationships previously implicit within each individual vector explicit, laying the foundation for the subsequent construction of an embedding space that can simultaneously perceive both relational structures.

[0052] Next, based on the similarity distance matrix and the context distance matrix, primitive embedding is performed on the feature vector of the record pair to obtain the primitive embedding value of the feature vector of the record pair, that is: ;in, is the similarity distance matrix, is the context distance matrix, is a row vector that records the eigenvectors of is matrix multiplication, is the vector transpose operation, To calculate the two norm of a vector, is the primitive embedding value. Accordingly, the distance matrix alone is not enough to directly optimize a single eigenvector. A mechanism is needed to inject global structural information into each independent vector. To this end, this application generates an initial embedding representation for each eigenvector that reflects its position in the mixed information space, namely the primitive embedding value, by utilizing the distance relationship decoupled in the previous step. That is, it compares each record pair eigenvector with its own norm (representing information richness) and with the two distance matrices. and This computation essentially projects the feature vectors of a record pair into a structured space defined by global similarity and context. This transforms the originally flat feature vector into a primitive that carries global structural information. This primitive already embodies the relative proximity of this record pair to all other record pairs in terms of both similarity and context.

[0053] Finally, based on the primitive embedding value, the record pair feature vector is associated mapped to obtain the optimized record pair feature vector, that is: ;in, It is the point product of position. is the optimized record pair feature vector. That is, the primitive embedding value rich in structural information generated in the previous step is actually applied to the record pair feature vector, here by multiplying the primitive embedding value and the record pair feature vector element by element. This operation is equivalent to using the primitive embedding value The global structural information contained in the , to adjust and calibrate the record feature vector The importance of each feature in the decision space. The optimized feature vectors of record pairs that are close in both similarity distance and context distance are also adjacent to each other in the new decision space. This association mapping greatly improves the discrimination between feature vectors and ensures that the conversion of hybrid features from the original space to the regression decision space is controllable and clear. This not only provides the lightweight context bandit model with an input that is easier to distinguish linearly to improve the accuracy of its rapid decision-making, but also provides the heavyweight deep Q network model with a more informative state representation containing global structural information, thereby enhancing its in-depth analysis capability for handling complex and difficult cases. In particular, the processing procedures of the benefit calculation unit, confidence generation unit, final action determination unit and decision unit in this example are the same as the processing procedures of the action expected immediate benefit calculation unit 161, confidence calculation unit 162, final action generation unit 163 and decision result generation unit 164 in the above-mentioned implementation example, so they will not be elaborated on again. By performing the above operations on the feature vectors of each record pair, a list of decision results is finally obtained.

[0054] Specifically, the decision result list execution module 170 is responsible for executing the decision result list to obtain an updated EMPI database or manual review task. In other words, after a series of complex calculations and intelligent decisions by the preceding modules, the system has generated a clear final action for each new patient record paired with a candidate record: match, mismatch, or send for review. However, these decisions themselves are merely instructions stored in system memory and have no actual impact on real-world data. The patient master index database (EMPI) remains in an outdated state, and the task requiring manual review has not been created. If the decision-making process were to remain at this step, the entire matching process would be meaningless. Therefore, in order to transform the wisdom of all the preceding modules into specific, persistent data operations, it is necessary to execute the decision result list to obtain an updated EMPI database or manual review task.

[0055] In a specific implementation, Figure 5 Schematic diagram of data flow of the decision result list execution module in the cross-institutional patient master index dynamic matching system based on reinforcement learning according to an embodiment of the present application. Figure 5 As shown, the decision result list execution module 170 is configured to: if the final action in the decision result is a match, link the new patient record to the existing patient unique identifier in the corresponding record pair to obtain the updated EMPI database; if the final action in the decision result is a mismatch, not link; and if the final action in the decision result is submit for review, generate the manual review task.

[0056] In a specific implementation, the decision result list execution module 170 is implemented as follows: The decision result list contains the final decision action for each record pair. This module traverses this list and performs corresponding database operations or task generation based on each decision result. For example, the decision result list contains the following three decisions: 1. For the record pair of source record Zhang Wei and candidate record EMPI-001, the final action is match. 2. For the record pair of source record Zhang Wei and candidate record EMPI-002, the final action is mismatch. 3. For the record pair of source record Zhang Wei and candidate record EMPI-003, the final action is submit for review.

[0057] The module's processing is as follows: When the first decision result matches, it performs a database link operation. It first extracts the candidate record's unique identifier, EMPI-001, from the record pair. It then locates the newly received source record for Zhang Wei. The module initiates an update command to the EMPI database system, linking this new record to EMPI-001. At the database level, this means adding a primary index ID field pointing to EMPI-001 to the new record's data entry, or adding a new record to a dedicated association table indicating that the primary index for this new record's data identifier is EMPI-001. This update updates the EMPI database, logically assigning the new record to the unique patient identity represented by EMPI-001, thus achieving data integration.

[0058] Next, the module handles the second decision result: mismatch. In this case, the system determines that the source record, Zhang Wei, and the candidate record, EMPI-002, do not belong to the same individual. Based on pre-set logic, the module performs an unlink operation. This means that the system will not make any modifications to the EMPI database related to this record pair. This decision, effectively an ignore or skip instruction, ensures that unrelated records are not mistakenly linked, thus maintaining the accuracy of the EMPI database. At the end of the entire process, if all candidate records are determined to be mismatched, the system will create a new EMPI identifier for the new record and store it as a new entry in the database.

[0059] Finally, the module processes the third decision result and sends it for review. This indicates that the system was unable to make a definitive judgment automatically. The module then generates a manual review task. It collects all relevant information for this decision, including the complete source record, the complete candidate record EMPI-003, and the record pair feature vectors calculated by the previous module. It then packages this information and calls a task management system interface to create a new review task. This task is assigned to a data administrator with appropriate permissions. On the task interface, the administrator can clearly see a side-by-side comparison of the two records, along with the various similarity scores assigned by the system, to assist in making the final manual decision.

[0060] In summary, the cross-institutional patient master index dynamic matching system 100 based on reinforcement learning according to the embodiment of the present application is explained. In order to solve the problems of poor adaptability of traditional static rules and high manual maintenance costs, a reinforcement learning mechanism is introduced, that is, matching tasks are handled through an innovative hierarchical hybrid decision model. Specifically, the new patient record and the retrieved candidate record are first paired to obtain a set of record pairs, and the context gambling machine is used to make fast and accurate automated decisions on the record pairs with high confidence, effectively coping with data quality fluctuations. When encountering situations where similarity is fuzzy and decision uncertainty occurs, the system seamlessly switches to a deep Q network for more refined strategy evaluation, or transfers the task to manual review, thereby avoiding the decision-making risks of a single model in complex scenarios. In this way, contextual information is integrated, and while ensuring high-precision matching, a balance between automation efficiency and decision robustness is achieved, ultimately constructing an intelligent EMPI matching process that can dynamically adapt and self-optimize, effectively solving the bottlenecks faced by the existing technology.

[0061] While various implementations of the present disclosure have been described above, the above description is intended to be illustrative and not exhaustive. The present disclosure is not limited to the disclosed implementations, and numerous modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations.

Claims

1. A cross-institutional patient master index dynamic matching system based on reinforcement learning, characterized by: include: New patient record acquisition module, used to acquire new patient records from external medical institutions; an index key generating module, configured to generate an index key based on the standardized new patient record after the new patient record is standardized; A candidate module, configured to perform candidate set retrieval in the EMPI database based on the index key to obtain a candidate record set; a pairing module, configured to pair the new patient record with each candidate record in the candidate record set to obtain a set of record pairs; a record pair processing module, configured to perform multi-dimensional similarity calculation and context feature addition on each record pair in the record pair set to obtain a record pair feature vector list; A decision module is configured to input each record pair feature vector in the record pair feature vector list into a hierarchical hybrid decision model to obtain a decision result list, wherein the hierarchical hybrid decision model includes a contextual bandit model and a deep Q network; and a decision result list execution module is configured to execute the decision result list to obtain an updated EMPI database or manual review task.

2. The cross-institutional patient master index dynamic matching system based on reinforcement learning according to claim 1 is characterized in that: The record pair processing module includes: a name similarity calculation unit, which is used to calculate the Jaro-Winkler distance between the name field in the new patient record and the name field in the candidate record as name similarity; an ID number similarity calculation unit, which is used to calculate the Levenshtein distance between the ID number in the new patient record and the ID number in the candidate record as ID number similarity; an address similarity calculation unit, which is used to calculate the cosine similarity between the address in the new patient record and the address in the candidate record as address similarity; and a birth date similarity calculation unit, which is used to accurately compare the birth date in the new patient record with the birth date in the candidate record to obtain birth date similarity.

3. The cross-institutional patient master index dynamic matching system based on reinforcement learning according to claim 2 is characterized in that: The record pair processing module also includes: a context information extraction unit for extracting context information related to the matching task, wherein the context information includes a data source, a record quality score, and a processing timestamp; a similarity arrangement unit for arranging the data source, the record quality score, the processing timestamp, the name similarity, the ID number similarity, the address similarity, and the date of birth similarity into a record pair feature vector.

4. The cross-institutional patient master index dynamic matching system based on reinforcement learning according to claim 1 is characterized in that: The decision module includes: an action expected immediate benefit calculation unit, used to input the record pair feature vector as context into the contextual bandit model to obtain the expected immediate benefit of each action; a confidence calculation unit, used to calculate the confidence based on the expected immediate benefit of each action; a final action generation unit, used to determine whether the confidence exceeds a preset high confidence threshold, and in response to the confidence exceeding the preset high confidence threshold, determine the action with the highest expected immediate benefit as the final action; a decision result generation unit, used to input the record pair feature vector as the current state into the deep Q network in response to the confidence not exceeding the preset high confidence threshold to obtain the decision result.

5. The cross-institutional patient master index dynamic matching system based on reinforcement learning according to claim 4 is characterized in that: The decision result generation unit includes: an action Q value generation subunit, which is used to input the record pair feature vector as the current state into the deep Q network to obtain the Q value of each action; a probability calculation subunit, which is used to calculate the final selection probability of each action based on the Q value and temperature parameter of each action; and a final action determination subunit, which is used to determine the action corresponding to the one with the highest final selection probability as the final action.

6. The cross-institutional patient master index dynamic matching system based on reinforcement learning according to claim 5 is characterized in that: The probability calculation subunit is used to calculate the final selection probability of each action based on the Q value and temperature parameter of each action using the following formula, wherein the formula is: ;in, and is the Q value of each action, is the temperature parameter, The final selection probability for each action.

7. The cross-institutional patient master index dynamic matching system based on reinforcement learning according to claim 1 is characterized in that: The decision module includes: a record pair optimization unit, which is used to perform discrimination decoupling embedding optimization on the record pair feature vector to obtain an optimized record pair feature vector; a benefit calculation unit, which is used to input the optimized record pair feature vector as context into the contextual bandit model to obtain the expected immediate benefit of each action; a confidence generation unit, which is used to calculate the confidence based on the expected immediate benefit of each action; a final action determination unit, which is used to judge whether the confidence exceeds a preset high confidence threshold, and in response to the confidence exceeding the preset high confidence threshold, determine the action with the highest expected immediate benefit as the final action; a decision unit, which is used to input the optimized record pair feature vector as the current state into the deep Q network in response to the confidence not exceeding the preset high confidence threshold to obtain the decision result.

8. The cross-institutional patient master index dynamic matching system based on reinforcement learning according to claim 7 is characterized in that: The record pair optimization unit is configured to: calculate a similarity distance matrix and a context distance matrix based on each record pair feature vector; and perform primitive embedding on the record pair feature vector based on the similarity distance matrix and the context distance matrix to obtain a primitive embedding value of the record pair feature vector; Based on the primitive embedding value, association mapping is performed on the record pair feature vector to obtain the optimized record pair feature vector.

9. The cross-institutional patient master index dynamic matching system based on reinforcement learning according to claim 1 is characterized in that: The decision result list execution module is configured to: if the final action in the decision result is a match, link the new patient record to the patient unique identifier that already exists in the corresponding record pair to obtain the updated EMPI database; If the final action in the decision result is mismatch, no link is made; If the final action in the decision result is to send it for review, the manual review task is generated.

Images