Reinforcement learning based cross-institutional patient master index dynamic matching system

Abstract

The application relates to the technical field of medical information, and particularly discloses a cross-institutional patient master index dynamic matching system based on reinforcement learning, which introduces a reinforcement learning mechanism, that is, a hierarchical hybrid decision model is used to process a matching task. Specifically, first, new patient records and retrieved candidate records are paired to obtain a record pair set, then, a context gambler is used to make a quick, accurate and automated decision on the record pairs with high confidence. When encountering a situation with ambiguous similarity and uncertain decision, the system seamlessly switches to a deep Q network for more detailed strategy evaluation, or transfers the task to manual review, thereby avoiding the decision risk of a single model in a complex scenario. In this way, the balance between automation efficiency and decision robustness is achieved, and finally, an intelligent EMPI matching process that can dynamically adapt and self-optimize is constructed, effectively solving the bottleneck faced by the prior art.

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

[0002] In modern medical informatization construction, the cross-institutional patient master index (EMPI) is the core of realizing regional medical data interconnection and constructing a complete patient health record. However, due to the non-uniform data standards among medical institutions, there are problems such as differences in name spelling, differences in ID card number formats or missing, and address information changes in patient records, resulting in multiple independent records of the same patient in different institutions. In order to accurately associate these scattered records to the unique patient identity, efficient and accurate matching technology is needed. Traditional patient master index systems mostly rely on fuzzy matching algorithms based on rule engines or fixed similarity threshold models. Although this method solves the problem to some extent, the static matching logic is difficult to adapt to the dynamically changing medical data environment. For example, when a new institution accesses the platform, its unique data format or quality fluctuations often lead to a significant decrease in the matching accuracy of the preset rules, requiring a large amount of manpower to reconfigure the rules and repeatedly debug the threshold, which not only has high maintenance cost, but also cannot meet the growing real-time matching demand.

[0003] In order to overcome the limitations of traditional methods, the industry has begun to explore the application of machine learning, especially reinforcement learning, to patient record matching tasks. Reinforcement learning learns the optimal decision strategy from the feedback of historical matching (such as manual review results) through the interaction and trial-and-error of the agent and the environment, which can theoretically dynamically adapt to data changes and reduce human intervention. However, directly applying reinforcement learning to the complex EMPI matching scenario poses challenges. On the one hand, matching decisions not only depend on the similarity between records, but also are influenced by context information such as data source reliability and record quality, and a single reinforcement learning model cannot effectively integrate these multi-dimensional heterogeneous information. On the other hand, in practical applications, matching decisions need to strike a balance between automated processing and manual review. For fuzzy matching with low confidence, if the model is forced to make a matching or non-matching decision, it is easy to introduce incorrect links or miss correct links, while excessive reliance on manual review will sacrifice efficiency.

[0004] Therefore, there is no reinforcement learning matching scheme in the prior art that can balance the efficiency of automation at high confidence and the robustness of decision-making at low confidence. SUMMARY

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

[0006] According to an aspect of the present application, a cross-institutional patient master index dynamic matching system based on reinforcement learning is provided, which comprises: a new patient record acquisition module configured to acquire a new patient record from an external medical institution; an index key generation module configured to generate an index key based on the standardized new patient record after standardizing the new patient record; a candidate module configured to perform candidate set retrieval based on the index key in an EMPI database 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 record pair set; a record pair processing module configured to perform similarity multi-dimensional 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 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, the hierarchical hybrid decision model comprising a context slot machine model and a deep Q network; and a decision result list execution module configured to execute the decision result list to obtain an updated EMPI database or a manual review task.

[0007] Compared with the prior art, the cross-institutional patient master index dynamic matching system based on reinforcement learning provided by the present application solves the problems of poor adaptability of traditional static rules and high cost of manual maintenance, and introduces a reinforcement learning mechanism, i.e., an innovative hierarchical hybrid decision model is used to process the matching task. Specifically, first, the new patient record and the retrieved candidate record are paired to obtain a record pair set, the context slot machine is used to make a quick and accurate automated decision for the record pair with high confidence, and the data quality fluctuation is effectively coped with. When the similarity is ambiguous and the decision is uncertain, the system seamlessly switches to the deep Q network for more detailed strategy evaluation, or transfers the task to manual review, thereby avoiding the decision risk of a single model in a complex scenario. In this way, the context information is fused, the balance between automation efficiency and decision robustness is achieved while ensuring high-precision matching, and finally 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 DRAWINGS

[0008] The above and other objects, features and advantages of the present application will become more apparent from the following detailed description of embodiments of the present application taken in conjunction with the accompanying drawings. The drawings provided in the present application are used to provide a further understanding of embodiments of the present application and constitute a part of the specification, which serve to explain the present application together with the embodiments of the present application, but do not constitute a limitation of the present application. In the drawings, the same reference numerals generally designate the same components or steps throughout the drawings.

[0009] Figure 1 A block diagram of the cross-institutional patient master index dynamic matching system based on reinforcement learning according to the embodiments of the present application.

[0010] Figure 2 Data flow diagram of a reinforcement learning based cross-institutional patient master index dynamic matching system according to embodiments of the present application.

[0011] Figure 3 Block diagram of a record pair processing module in a reinforcement learning based cross-institutional patient master index dynamic matching system according to embodiments of the present application.

[0012] Figure 4 Block diagram of a decision module in a reinforcement learning based cross-institutional patient master index dynamic matching system according to embodiments of the present application.

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

[0014] Embodiments of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings. While several embodiments of the present disclosure are shown in the drawings, it is understood that the present disclosure can be embodied in various forms and should not be construed as being limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and fully convey the scope of the present disclosure to those skilled in the art. It should be understood that the drawings and embodiments of the present disclosure are only for illustrative purposes and are not intended to limit the scope of protection of the present disclosure.

[0015] It should be understood that each of the steps recited in the method embodiments of the present disclosure can be performed in different orders and / or in parallel. In addition, the method embodiments can include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this respect.

[0016] The present application is proposed in view of the problems in the prior art described above. Figure 1 Block diagram of a reinforcement learning based cross-institutional patient master index dynamic matching system according to embodiments of the present application. Figure 2 Data flow diagram of a reinforcement learning based cross-institutional patient master index dynamic matching system according to embodiments of the present application. Specifically, as shown in FIG. 3, the system includes a record pair processing module 301, a decision module 302, a decision result list execution module 303, and a record pair matching module 304. Figure 1 and Figure 2As shown, the cross-institutional patient master index dynamic matching system 100 based on reinforcement learning according to the embodiment of the application comprises: a new patient record acquisition module 110, configured to acquire a new patient record from an external medical institution; an index key generation module 120, configured to generate an index key based on the standardized new patient record after standardizing the new patient record; a candidate module 130, configured to perform candidate set retrieval in an EMPI database based on the index key to obtain a candidate record set; a pairing module 140, configured to pair 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, 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 160, 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, the hierarchical hybrid decision model comprising a context slot machine model and a deep Q network; and a decision result list execution module 170, configured to execute the decision result list to obtain an updated EMPI database or a manual review task.

[0017] Specifically, the new patient record acquisition module 110 is configured to acquire a new patient record from an external medical institution. It can be understood 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, the patient's medical behavior naturally has the characteristics of cross-region and cross-institution, and his or her health information is scattered in various independent hospitals, clinics or physical examination centers. If these scattered records cannot be effectively integrated, they will form an information island, leading to problems such as repeated examination, drug conflict and incomplete diagnosis and treatment history. Therefore, in order to break these barriers and achieve the continuity and integrity of patient information, it is the first prerequisite to actively and continuously collect patient information from different data sources, which is the starting point and data entry of the entire dynamic matching process, ensuring that any newly generated patient information can be timely included in the master 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. The interface is based on medical information exchange standards such as HL7 or FHIR, and uses HTTPS protocol for encrypted transmission to ensure the security and compliance of data interaction.

[0019] When a new patient is registered or visits an external medical institution, such as the First People's Hospital of City A, its hospital information system (HIS) will trigger an event. This event will package the newly generated patient record into a standard format message, such as an XML or JSON file containing basic patient information. The file may contain fields such as: {name: "Zhang Wei", ID number: "32010119850315XXXX", date of birth: "1985-03-15", address: "123 C Street, B District, A City", data source: "First People's Hospital of City A", record generation time: "2023-10-26T09:30:00"}.

[0020] Next, the HIS system of the First People's Hospital of City A will actively push or regularly pull this message to the designated server endpoint through the pre-configured security data interface. After receiving the data package, the new patient record acquisition module will first perform security verification, such as verifying the source IP and API key, to ensure the legitimacy of the data source. After verification, the module will parse the data package and extract 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 the heterogeneity of data. Even for the same patient, their name may differ due to input errors or aliases, such as Zhang Wei and Zhang Wei; address formats may vary greatly, such as C Street 123, B District and 123 B District, C Street; and ID numbers may differ by 15 or 18 digits, or contain non-numeric characters. If these raw and noisy data are directly used to search the vast EMPI database, not only is the efficiency low, like finding a needle in a haystack, but also a large number of potential matching objects may be missed due to minor differences. Therefore, before large-scale retrieval, the data needs to be cleaned and standardized, and the core identifier that can resist slight changes and has high discrimination needs to be extracted. Based on this, after standardizing the new patient record, the index key is generated based on the standardized new patient record to create an efficient, accurate, and fast channel for subsequent candidate set retrieval through data standardization and index key generation.

[0022] In one 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 performs full-width to half-width conversion, removes spaces, and converts Chinese characters to standard pinyin, such as zhangwei for Zhang Wei. For the ID number field, the module checks its format and length, removes all non-alphanumeric characters, and upgrades all 15-digit old numbers to 18 digits. For the birth date field, the format is unified to YYYYMMDD, i.e. 19850315. For the address field, the module uses a pre-set address dictionary and a segmentation algorithm to structure and extract key elements, such as A City B District C Street 123 to {province: "A Province", city: "A City", district: "B District", street: "C Street", house number: "123"} and remove secondary information. After this stage, a standardized new patient record is obtained.

[0023] Next, index keys are generated based on this standardized record. The design goal of the index key is to have certain fault tolerance and high selectivity. This embodiment adopts a combined index key strategy to generate multiple index keys of different dimensions to improve recall rate. For example, the following index keys can be generated: 1. Name Pinyin + Birth Date Key, combining the standardized name pinyin and birth date to generate zhangwei19850315. This key is very efficient for accurate name and birth date. 2. ID Number Key, using the standardized 18-digit ID number as the index key, which is the most discriminative key. 3. Soundex (Name) + Birth Date Key, to deal with spelling errors, the Soundex algorithm is applied to the name pinyin zhangwei to obtain a phonetic code, such as Z520. Then combined with the birth date to form Z52019850315. The Soundex algorithm can map strings with similar pronunciation but different spelling to the same code, thus tolerating spelling errors. 4. Address Key Element Key, extracting the core elements of the standardized address, such as A City B District C Street, and combining them. Finally, the output is a standardized new patient record and a set of multiple index keys, such as {"zhangwei19850315", "32010119850315XXXX", "Z52019850315", "A City B District C Street"}.

[0024] In particular, the candidate module 130 is configured to perform candidate set retrieval in the EMPI database based on the index key to obtain a candidate record set. It should be understood that when processing a large amount of patient master index data, if a new record is compared with millions or even tens of millions of existing records in the database one by one for detailed similarity comparison, the calculation overhead will be huge, and it is completely impossible to meet the real-time requirements of medical business. Such a matching method is not only inefficient, but also consumes a large amount of computing resources. Therefore, an efficient screening strategy is needed to quickly lock a controllable and highly relevant subset from the huge database before performing detailed comparison. This subset should contain all truly possible matching records, while excluding most obviously irrelevant records. Therefore, in order to achieve this key coarse screening process, the present application performs candidate set retrieval in the EMPI database based on the index key, so as to use the index key generated in the previous step to convert the full database scanning problem into an efficient and small range accurate matching problem.

[0025] In a specific implementation, the candidate module 130 is implemented as follows: the module interacts with a specially optimized EMPI database. The 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 the index key generation module 120, and establishes a high-speed retrieval engine (for example, using B-tree or hash index) for these index key fields. That is, the EMPI database is not a simple information repository, but the cornerstone and historical accumulation of the entire matching system. Its construction is a continuous accumulation process: whenever a new patient record is confirmed as a new identity through the matching process, the complete information of the record, its standardized data, and the generated multiple index keys (such as ID number key, name pinyin + birth date key, Soundex phonetic coding key, etc.) are stored in the database and are assigned a globally unique patient identifier (EMPI-ID). At the same time, the database management system establishes an efficient index structure for these pre-generated index key fields, for example, using hash index for ID number fields with high cardinality and strong uniqueness to achieve nearly constant time lookup, and using B-tree index for name pinyin, address, and other fields that may require range or fuzzy query. The database grows and becomes richer over time, and constitutes the standard and retrieval target for matching decisions.

[0026] The candidate module 130 will iterate through each key in the inputted set of index keys and query the EMPI database using them in the corresponding index fields. The operation is as follows: first, use the index key 32010119850315XXXX to query the EMPI database on the ID number hash index for an exact match, and return the matching EMPI-ID. If the query hits a record, its unique identifier is EMPI-001. Next, use the index key zhangwei19850315 to query the database on the name pinyin + birth date B-tree index. If the query hits EMPI-001 and another record EMPI-002 (possibly a patient with the same name and birth date). Then, use the index key Z52019850315 to query the database on the Soundex (name) + birth date index field. This query may hit EMPI-001, EMPI-002, and also a record EMPI-003 named Zhang Wei, because the Soundex code for Zhang Wei can also be Z520. Finally, use the index key A City B District C Street to query the database on the address key element index field, which may return EMPI-001 and other records living in the same area, such as EMPI-004. After all parallel query tasks are completed, the candidate module will collect all returned EMPI-IDs to form a temporary list that may contain duplicates [EMPI-001, EMPI-001, EMPI-002, EMPI-001, EMPI-002, EMPI-003, EMPI-004]. The module will internally perform an efficient deduplication operation on this list to generate a unique set of candidate IDs {EMPI-001, EMPI-002, EMPI-003, EMPI-004}. This set represents all potential matching objects associated with the new record through any dimension. Finally, the module will initiate a batch database read operation to extract the full details of these four records from the EMPI database at once based on this ID set. The final output candidate record set, i.e., [full information of record EMPI-001, full information of record EMPI-002, full information of record EMPI-003, full information of record EMPI-004].

[0027] In particular, the pairing module 140 is configured to pair the new patient record with each candidate record in the candidate record set to obtain a record pair set. It can be understood that after the coarse screening of the candidate set is completed, a small range of potential matching list highly related to the new patient record is obtained. However, this list itself is only a set of independent records, and the subsequent decision model needs to analyze not a single record, but the relationship between the new record and each candidate record. The core of the decision is comparison, that is, whether the new record A and the candidate record B point to the same person. If they are not explicitly organized into a paired comparison unit, the subsequent similarity calculation and feature extraction will become disordered and chaotic. Therefore, before entering the refinement analysis stage, a clear and structured comparison framework needs to 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 record pair set.

[0028] In a specific implementation, the 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 only source record to form a record pair. This process can be imagined as a simple loop or mapping operation, which converts a one-to-many potential relationship into multiple one-to-one entities to be analyzed. The module first takes out the first record in the candidate record set, that is, the complete information of EMPI-001, and then pairs the source record Zhang Wei with the record EMPI-001 to generate the first record pair. Then, 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, and EMPI-003 and EMPI-004 are processed in turn to generate the third and fourth record pairs.

[0029] After all the candidate records are iterated through, the output is a structured record pair set. This set is represented as a list or array in data structure, 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 similarity calculations and contextual feature appending 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 subsequent reinforcement learning models to make intelligent decisions. The model cannot directly understand raw text like "Zhang Wei" and "Zhang Wei"; it requires quantifiable, computable input. The basis for decision-making, i.e., whether two records point to the same person, essentially depends on their similarity across multiple dimensions such as name, ID card number, and address, as well as implicit information such as data source and record quality. If this qualitative, multi-dimensional information is not transformed into a unified, numerical expression, the model cannot compare and judge. Therefore, in order to transform the raw, unstructured record pairs into a language that machine learning models can understand and process—that is, numerical feature vectors—this application performs multi-dimensional similarity calculations and contextual feature appending on each record pair in the record pair set. Figure 3 This is a block diagram of the record pair processing module in a reinforcement learning-based cross-institutional patient master index dynamic matching system according to an embodiment of this application. Figure 3 As shown: In a specific implementation, the record pair processing module 150 includes: a name similarity calculation unit 151, 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, 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, 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 154, used to perform a precise comparison between the birth date in the new patient record and the birth date in the candidate record to obtain birth date similarity.

[0031] In a specific implementation, the record pair processing module 150 is implemented as follows: The record pair processing module 150 receives a set of record pairs from the pairing module 140 as input. Each record pair in this set will undergo parallel processing by a series of computing units within this module to generate a quantized feature vector. Taking the source record Zhang Wei and the candidate record EMPI-003 as an example, such as the incorrectly entered record 32010119850315XXXA with the name Zhang Wei, ID number 32010119850315XXXX, address 123, C Street, B District, City A, and date of birth 1985-03-15, the processing procedure is as follows.

[0032] First, the name similarity computation 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 is worth mentioning that the Jaro-Winkler distance algorithm performs outstanding robustness and accuracy in dealing with short strings such as names, especially in dealing with common input errors (such as typos, homophonic character replacement). Unlike simple edit distance, it not only cares about whether the characters are the same, but also considers the order and position of the characters, and especially enhances the reward for matching the prefix of the string, which is very suitable for the feature that the surname in Chinese name is usually at the beginning, which can effectively distinguish between Zhang Wei and Li Wei. Specifically, the calculation process of the Jaro-Winkler algorithm consists of two main steps. First, it calculates the basic Jaro similarity. This step involves finding matching characters in two strings, Zhang Wei and Zhang Wei. Here, matching is defined as a relatively loose definition, that is, the positions of two identical characters in their respective strings cannot differ too much, and the distance threshold is half the length of the longer string minus one. In this example, Zhang and Wei are 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 matching characters that are in different orders in the two strings, which is 0 in this case. Based on the number of matching characters and the number of transpositions, the Jaro similarity can be calculated by a specific formula: Jaro similarity=(1 / 3)*((m / |s1|)+(m / |s2|)+((m-t) / 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 in this application, that is, comparing Zhang Wei (s1) and Zhang Wei (s2), the key parameters m and t in the formula need to be determined. The prerequisite for calculating m is to define the matching range, that is, the maximum matching distance, which is calculated by taking half of the maximum length of the two strings and rounding down, then subtracting one. For Zhang Wei and Zhang Wei, both of which have a length of 2, the maximum matching distance is zero, that is, only the same characters in the same position of the two strings are considered to be matched. According to this rule, the first character Zhang in s1 matches the first character Zhang in s2, while the second character Wei does not match Wei. Therefore, the number of matching characters m is 1. Next, the number of transpositions t is calculated. Transposition refers to the case where matching characters in two strings are in different orders in their respective strings. The matching characters in the two strings are extracted in the original order to form two matching sequences. For Zhang Wei and Zhang Wei, their respective matching character sequences both have only one character, Zhang. Since the two sequences are identical, there are no characters with inconsistent orders, so the number of transpositions t is zero, that is, t equals 0. Finally, all the calculated parameters are substituted into the Jaro similarity formula for final calculation.Substituting the formula, we get: (1 / 3)*((1 / 2)+(1 / 2)+((1-0) / 1)) ≈ 0.667. This value is the base Jaro similarity, which objectively quantifies the similarity between Zhang Wei and Zhang Wei in terms of character composition and arrangement. Next, the algorithm enters the Winkler correction. This step is to give an extra bonus to the strings that match the prefix. The algorithm checks the length of the characters that match continuously from the beginning of the two strings, which is called the common prefix length. In the example of Zhang Wei and Zhang Wei, the common prefix is Zhang, with a length of 1. The Winkler correction uses this common prefix length to weight the original Jaro similarity by an empirical constant, such as 0.1, which is determined through experiments and tuning. In fact, the original Jaro similarity is weighted and improved, and the formula is expressed as: Jaro-Winkler = Jaro + common prefix length * p * (1-Jaro). The final Jaro-Winkler similarity value will be higher than the original Jaro similarity, because it rewards the correct matching of the surname. After this series of fine calculations, the unit finally outputs a value between 0 and 1, such as 0.70, which not only reflects the high similarity between the two names as a whole, but also appropriately reflects the small differences caused by the different characters at the end.

[0033] At the same time, the identity card number similarity calculation unit 152 begins to process the identity card number field. It obtains 32010119850315XXXX from the source record and 32010119850315XXXA (here only an example of incorrect input) from the candidate record. This unit uses the Levenshtein distance algorithm, which calculates the minimum number of single character edits (insertions, deletions or replacements) required to convert one string into another. In this example, it needs to replace the last X with A to convert from the former to the latter, and the edit distance is 1. In order to normalize this distance into similarity, the formula 1-(edit distance / length of longer string) is used. Therefore, the identity card number similarity is 1-(1 / 18) ≈ 0.94.

[0034] Next, the address similarity computation unit 153 processes the address fields. It obtains the address A City B District C Street 123, Number for the source record and the address A City B District C Street 123, Number for the candidate record. The core of this unit is a deep learning driven text representation model, which is a domain-adapted BERT model. BERT model is essentially a multi-layer bidirectional encoder based on the Transformer architecture, which contains multiple layers of self-attention mechanism and feedforward neural networks inside. The key component of the model is its huge parameter matrix, i.e., the weights and biases are learned through unsupervised pre-training tasks on massive general text corpus. The processing of this unit begins with the preprocessing of the original address text. First, the address string, such as A City B District C Street 123, Number, will be broken down into a series of wordpieces by a specialized tokenizer, e.g., ['[CLS]', 'A', 'City', 'B', 'District', 'C', 'Street', '123', 'Number', '[SEP]']. These wordpieces are then fed into the fine-tuned BERT model. Inside the model, each wordpiece is first mapped to an initial embedding vector, which is added to a position encoding vector to preserve its order information in the address. Then, this sequence of vectors with position information flows through the model's multi-layer Transformer encoder. At each layer, the self-attention mechanism calculates the association weights between each wordpiece in the address and all other wordpieces, enabling the model to understand the contextual relationships, e.g., Street and Street are equivalent in a specific context. After multiple layers of complex nonlinear transformations, the model finally generates a contextually rich output vector for each input wordpiece. To obtain a single vector representing the entire address, the unit employs a pooling strategy. One 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 wordpieces, i.e., to average the values dimension by dimension. In this way, the two slightly different address texts, A City B District C Street 123, Number and A City B District C Street 123, Number, are respectively converted into two high-dimensional, dense address vectors. Finally, the unit calculates the cosine similarity between the two address vectors, which measures the cosine of the angle between the two vectors, and the result will be very close to 1.0, e.g., 0.99, thus accurately quantifying the high consistency of the two addresses at the semantic level.

[0035] Finally, the birth date similarity computation unit 154 performs the acquisition of the birth date fields in both records, which are both 1985-03-15. This unit performs an exact string or date object comparison. If the two dates are exactly the same, the similarity is 1.0; as soon as there is any difference in days, months, or years, the similarity is 0.0. In this example, the two dates are exactly the same, so the birth date similarity is 1.0.

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

[0037] In particular, the subsequent processing of the record pair by the processing module 150 is jointly accomplished by the context information extraction unit 155 and the similarity arrangement unit 156, which are responsible for integrating the discrete similarity scores with the background information into a standard input available for 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, for example, the pairing of the source record Zhang Wei and the candidate record EMPI-003. Its task is to extract predefined context information from the metadata of this record pair. First, it extracts the data source information. The source record carries the identification of its source institution when it is acquired, for example, the First People's Hospital of City A, while the candidate record EMPI-003 also stores its original source in its database entry, for example, the Community Health Service Center of District B. In order to enable the model to process these category information, the unit will query a preset institution coding table to map the First People's Hospital of City A to its unique digital code, such as 101, and map the Community Health Service Center of District B to 205. Then, the unit extracts the record quality score. This score is 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 card, a structured address, and no obvious missing fields may have a quality score of 0.95; while a record lacking a contact number and having a vague address may have a score of only 0.70. The unit will obtain the quality scores of the source record and the candidate record respectively. Finally, the unit extracts the processing timestamp, that is, the exact time when the current system performs the matching operation. This timestamp will be converted into a numerical value, such as the number of seconds since a certain epoch (such as January 1, 1970), to capture the temporal characteristics of the matching behavior. After the context information extraction unit 155 completes the information extraction and quantification, its output, together with the similarity scores obtained by the previous calculation unit, is passed to the similarity arrangement unit 156. The input of this unit is all the discrete numerical features for a record pair: for example, the name similarity 0.70, the ID number similarity 0.94, the address similarity 0.99, the birth date similarity 1.0, the source record data source code 101, the candidate record data source code 205, the source record quality score 0.95, the candidate record quality score 0.88, and the processing timestamp 1698282000. The core function of the similarity arrangement unit 156 is to organize these numerical values into a one-dimensional numerical array, that is, a feature vector, in a predefined and fixed order. For example, the unit sets the arrangement order as: [name similarity, ID number similarity, address similarity, birth date similarity, source data source code, candidate data source code, source record quality score, candidate record quality score, timestamp].According to this sequence, the unit will arrange the above-mentioned numerical 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 the 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, wherein the hierarchical hybrid decision model includes a contextual slot machine model and a deep Q network. Accordingly, after obtaining the quantified record pair feature vector, the system faces the final decision challenge: for each record pair, should it be determined as a match, a mismatch, or should it be sent for review due to too 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 be difficult to balance efficiency and accuracy. In actual business, a large number of record pairs have obvious matching relationships and can be quickly and automatically processed; while a small number of ambiguous cases need more in-depth and complex analysis. If a heavy and complex model is used to handle all cases, it will cause a huge waste of computing resources; on the contrary, a lightweight model may make mistakes in complex cases. Therefore, this step introduces a hierarchical hybrid decision model to establish an intelligent triage mechanism: use a contextual slot machine to handle most cases, and use a deep Q network to handle cases that the contextual slot machine cannot handle, so as to maximize the overall processing efficiency of the system while ensuring high accuracy.

[0039] In a specific implementation, Figure 4 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. As shown in the figure, the decision module 160 includes an action expected immediate reward calculation unit 161, a confidence calculation unit 162, a final action generation unit 163, and a decision result generation unit 164. Figure 4 The action expected immediate reward calculation unit 161 is configured to input the record pair feature vector as a context into the contextual slot machine model to obtain the expected immediate reward of each action. The confidence calculation unit 162 is configured to calculate the confidence based on the expected immediate reward of each action. The final action generation unit 163 is configured 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 reward as the final action. The decision result generation unit 164 is configured to input the record pair feature vector as a current state into the deep Q network to obtain the decision result, in response to the confidence not exceeding the preset high confidence threshold.

[0040] In one specific implementation, the decision module 160 is implemented as follows: First, the action expected immediate reward calculation unit 161 is performed. The contextual bandit model adopted is a linear upper confidence bound (LinUCB) model. This model maintains a separate parameter matrix for each possible action, i.e. matching, not matching, and sending for review. The weights and biases of these parameter matrices are obtained through offline training on a large amount of historical matching data. The specific architecture of this model includes a feature mapping layer and three parallel linear regressors, each corresponding to an action. When receiving an input feature vector, the feature mapping layer first possibly expands it, for example, by adding cross terms or polynomial terms to enhance the expression capability. Subsequently, the expanded feature vector is input into the three linear regressors respectively. Each regressor performs a matrix multiplication operation, multiplying the input vector with its own parameter matrix, thereby calculating an expected immediate reward for the corresponding action. For example, for an input feature vector, the model may output: the expected reward of action matching is 0.15, the expected reward of action not matching is 0.88, and the expected reward of action sending for review is 0.35.

[0041] Next, the confidence calculation unit 162 evaluates the degree of confidence of the model decision based on these expected rewards. The calculation logic of this unit is: first, find the maximum value and the second largest value of the expected rewards among all actions. In this example, the maximum reward is 0.88, corresponding to not matching, and the second largest reward is 0.35, corresponding to sending for review. Then, calculate the difference between the two values, i.e. 0.88-0.35=0.53. The larger this difference is, the more explicit the model's judgment of the best choice is, and the higher the discrimination from other options is. In order to normalize this difference into a standard confidence score, it can be mapped through a Sigmoid function, or directly use this difference as a measure of confidence. Here, 0.53 is taken as the confidence.

[0042] Then, the final action generation unit 163 makes a decision based on this confidence. This unit has a preset high confidence threshold inside, which is obtained by testing and tuning on the validation set, aiming to balance the automation processing rate and the accuracy rate, for example, set to 0.5. The unit will compare the calculated confidence 0.53 with the preset threshold 0.5. Since 0.53 exceeds 0.5, it meets the condition of high confidence. Therefore, the unit will directly adopt the suggestion of the contextual bandit model, and determine the action with the highest expected immediate reward, i.e. not matching, as the final action for this record pair. This decision result will be recorded, and the processing flow of this feature vector is completed here, without the need to enter the more complex deep Q network layer.

[0043] When the upper contextual gambler model lacks sufficient confidence in the decision of a record pair, it means that the case is likely to be a complex problem. For example, two records are highly similar in name, but have subtle differences in ID number, and the reliability of the data sources is not the same. In this case, a simple linear model may not be able to capture the complex and nonlinear interaction relationship between the features. Directly making a matching or non-matching decision is risky, and unconditionally transferring to manual review will reduce the efficiency of automation. Therefore, the system needs to understand the potential association behind these ambiguous 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 perform deep analysis on the complex record pair, so as to make the optimal final decision under the premise of maintaining high accuracy.

[0044] In a specific implementation, the decision result generation unit 164 includes: an action Q value generation sub-unit 1641, configured 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 sub-unit 1642, configured to calculate the final selection probability of each action based on the Q value of each action and a temperature parameter; and a final action determination sub-unit 1643, configured to determine the action corresponding to the maximum final selection probability as the final action.

[0045] The implementation is as follows: when the confidence of a record pair does not exceed a 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. For example, a record pair feature vector (the name and ID number similarity are both high, but not completely matched) results in low confidence, which will be input as the current state s into the deep Q network of the present unit.

[0046] The deep Q network (DQN) relied on by the action Q value generation sub-unit 1641 is a multi-layer feedforward neural network, and its core function is to approximate a complex function, i.e. , used to evaluate the expected value of the future cumulative return that can be obtained by performing a certain action a under the current state s. The architecture of the network includes an input layer whose number of neurons is the same as the dimension of the feature vector; several hidden layers using ReLU or other nonlinear activation functions to capture the complex relationship between features; and an output layer whose number of neurons is equal to the size of the action space, which is 3 in this case, corresponding to matching, non-matching and sending for review. The weight and bias parameters of the network are obtained through the training process of deep reinforcement learning. When the above feature vector is input as the current state s into this pre-trained DQN network, it will undergo nonlinear transformation layer by layer through the network, and finally obtain three values in the output layer, representing the The output can be, for example: Q(s, match) = 8.5, Q(s, mismatch) = 6.2, Q(s, send 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 can cause the model to be too deterministic and lack exploration. Therefore, in one specific implementation, the probability calculation subunit 1643 is configured to calculate the final selection probability of each action based on the Q value of each action and a temperature parameter, according to the following formula: ; where, and Q(s, a) is the Q value of each action, T is the temperature parameter, P(s, a) is the final selection probability of each action. That is, a temperature parameter is used to adjust the influence of the Q value on the final probability. T is a positive number, which is determined by tuning on the validation set through experiments, for example, set to 0.8. The higher the value of T, the flatter the probability distribution, and the more inclined to explore; the lower the value of T, the sharper the probability distribution, and the more inclined to use the action with the highest Q value. This unit calculates the selection probability of each action. For example, P(match | s) ≈ 0.76, P(mismatch | s) ≈ 0.08, P(send 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 largest final selection probability as the final action. In this example, 0.76 is the largest probability value, and the action corresponding to it is match. Therefore, this unit determines that match is the final decision result for this record pair.

[0049] In particular, when the record pair feature vector is input into the hierarchical hybrid decision model, the first layer of the model is a lightweight context slot machine model. The core of this model is a linear regressor in order to pursue efficiency, which means that it is better at processing linearly separable data when understanding features. However, the original feature vector directly concatenates similarity features (such as name, address similarity) and context features (such as data source, record quality), and the properties and scales of these two types of information are very different. Coupling them can cause the feature space distribution to be blurred, and the discrimination of different decision boundaries to be reduced. For a linear model, this blurring can seriously affect its prediction accuracy. Therefore, before the record pair feature vector is input into this linear model, it needs to be preprocessed to enhance its discrimination in the regression decision space, thereby improving the accuracy of the context slot machine model in predicting the expected immediate return.

[0050] In another specific implementation, the decision module comprises: a record pair optimization unit, configured to perform discriminative decoupled embedding optimization on the record pair feature vectors to obtain optimized record pair feature vectors; a reward calculation unit, configured to input the optimized record pair feature vectors as context into the contextual bandit model to obtain expected immediate rewards of each action; a confidence generation unit, configured to calculate a confidence based on the expected immediate rewards of each action; a final action determination unit, configured to determine an action with the highest expected immediate reward as the final action in response to the confidence exceeding a preset high confidence threshold; and a decision unit, configured to input the optimized record pair feature vectors as a current state into the deep Q network to obtain the decision result in response to the confidence not exceeding the preset high confidence threshold.

[0051] Based on this, in one specific implementation, the record pair optimization unit is configured to: first, calculate a similarity distance matrix and a context distance matrix based on the record pair feature vectors. It should be understood that the original record pair feature vectors directly couple the intrinsic similarity and the extrinsic context, which makes the discriminative decoupling of the record pair feature vectors in the decision space ambiguous. To solve this problem, the two types of information need to be separated first, and their respective global relationships need to be quantified. This step first splits each record pair feature vector into a similarity part and a context part. Then, the distances between all record pairs in a batch are calculated, forming two matrices: a similarity distance matrix and a context distance matrix . Each element in the first feature value of the first and the first record pair represents the Euclidean distance in the name, address, etc. similarity dimension; similarly, Each element in the first feature value represents the distance between them in the data source, quality score, etc. context dimension. In this way, the relationship originally implied in each independent vector is explicitly expressed, laying a foundation for subsequent construction of an embedding space that can simultaneously perceive both relationship structures.

[0052] Then, based on the similarity distance matrix and the context distance matrix, the record pair feature vectors are subjected to primitive embedding to obtain the primitive embedding values of the record pair feature vectors, i.e.: ; wherein, is the similarity distance matrix, is the context distance matrix, is the record pair feature vector as a row vector, is matrix multiplication, is the vector transposition operation, to calculate the two-norm of a vector, is the element embedding value. Accordingly, only the distance matrix is not enough to directly optimize the individual feature vector. A mechanism is needed to inject global structural information into each independent vector. To this end, the present application generates an initial embedding representation for each feature vector that can reflect its position sense in the mixed information space, i.e., the element embedding value, by utilizing the distance relationship decoupled in the previous step. That is, it will make a complex combination of each record pair feature vector with its own norm (representing information richness), and the product of the two distance matrices and This calculation process essentially projects the record pair feature vector into a structured space defined by the global similarity relationship and the context relationship. In this way, the originally flat feature vector is transformed into an element that carries global structured information, which has already embedded the relative proximity of the record pair to all other record pairs in terms of similarity and context.

[0053] Finally, based on the element embedding value, the record pair feature vector is associated mapped to obtain the optimized record pair feature vector, i.e., ; wherein, is the position point multiplication, is the optimized record pair feature vector. That is, the element embedding value generated in the previous step, which is rich in structural information, is actually applied to the record pair feature vector, here by multiplying the element embedding value with the record pair feature vector element by element. This operation is equivalent to using the global structural information contained in the element embedding value to adjust and calibrate the importance of each feature in the record pair feature vector . So that those record pairs that are similar in similarity distance and context distance have their optimized feature vectors also close to each other in the new decision space. This associated mapping greatly improves the distinguishability between feature vectors, ensuring that the conversion of mixed features from the original space to the regression decision space is controllable and clear. In this way, not only does it provide a more easily linearly distinguishable input for the lightweight context gambling machine model to improve its fast decision-making accuracy, but it also provides a more information-rich state representation that contains global structural information for the heavy deep Q network model, thereby enhancing its deep analysis capabilities for handling complex and difficult cases. In particular, the processing processes of the benefit calculation unit, the confidence generation unit, the final action determination unit and the decision unit in this example are the same as those of the action expected immediate benefit calculation unit 161, the confidence calculation unit 162, the final action generation unit 163 and the decision result generation unit 164 in the above implementation example, so they will not be described again. By performing the above operations on each record pair feature vector, the final decision result list is obtained.

[0054] In particular, the decision result list execution module 170 is configured to execute the decision result list to obtain the updated EMPI database or the manual review task. That is, 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 and candidate record pair, which is matching, not matching, or sending for review. However, these decisions themselves are only instructions in the system memory, and have not yet had any actual impact on real-world data. The patient master index database (EMPI) is still in the old state, and the manual review task has not been created. If the decision stops at this step, the entire matching process loses its meaning. Therefore, in order to convert the wisdom of all the preceding modules into specific, persistent data operations, the decision result list needs to be executed to obtain the updated EMPI database or the manual review task.

[0055] In one specific implementation, Figure 5 A data flow diagram of the decision result list execution module in the reinforcement learning based cross-institutional patient master index dynamic matching system according to an embodiment of the present application is shown in FIG. 17. As shown in FIG. 17, the decision result list execution module 170 is configured to: if the final action in the decision result is matching, 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 not matching, do not link; and if the final action in the decision result is sending for review, generate the manual review task. Figure 5

[0056] In one 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 iterates through this list and performs the corresponding database operation or task generation according to each decision result. For example, the decision result list contains the following three decisions: 1. For the record pair of the source record Zhang Wei and the candidate record EMPI-001, the final action is matching. 2. For the record pair of the source record Zhang Wei and the candidate record EMPI-002, the final action is not matching. 3. For the record pair of the source record Zhang Wei and the candidate record EMPI-003, the final action is sending for review.

[0057] ​The module's processing procedure is as follows: when the first decision result matches, the module performs a database linkage operation. It first extracts the unique identifier of the candidate record, EMPI-001, from the record pair. Then, it locates the newly incoming source record about Zhang Wei. The module issues an update instruction to the EMPI database system, associating the new record with EMPI-001. At the database level, this means adding a primary index ID field pointing to EMPI-001 in the data entry of the new record, or adding a new record in a special association table indicating that the data identifier of the new record corresponds to the primary index EMPI-001. After performing this operation, the EMPI database is updated, logically subsuming the new record under the unique patient identity represented by EMPI-001, achieving data fusion.

[0058] Next, the module processes the second decision result, which does not match. In this case, the system determines that the source record Zhang Wei and the candidate record EMPI-002 do not belong to the same person. According to the preset logic, the module will perform a no-link operation. This means that the system will not make any modifications to the EMPI database related to this record pair. This decision is actually an instruction to ignore or skip, which ensures that unrelated records are not incorrectly associated, maintaining the accuracy of the EMPI database. After the entire process ends, if all candidate records are determined to be not matching, the system will create a new EMPI identifier for this new record and store it as a new entry in the database.

[0059] Finally, the module processes the third decision result, which goes to review. This indicates that the system cannot automatically make a clear judgment. The module will perform an operation to generate a manual review task. It will collect all information related to the decision, including the complete source record, the complete candidate record EMPI-003, and the record pair feature vector calculated by the previous module. Then, it packages these information and calls an interface of a task management system to create a new review task. This task will be assigned to a data administrator with corresponding permissions. In the task interface, the administrator can clearly see the side-by-side comparison of the two records and the similarity scores given by the system, thereby assisting 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 embodiments of the present application is illustrated, which is to solve the problems of poor adaptability of traditional static rules and high cost of manual maintenance, and introduces a reinforcement learning mechanism, that is, an innovative hierarchical hybrid decision model is used to process the matching task. Specifically, first, the new patient record and the retrieved candidate record are paired to obtain a record pair set, the context gambler is used to make a quick, accurate and automated decision for the record pair with high confidence, and the data quality fluctuation is effectively coped with. When the similarity is ambiguous and the decision is uncertain, the system seamlessly switches to the deep Q network for more detailed strategy evaluation, or transfers the task to manual review, thereby avoiding the decision risk of a single model in a complex scene. In this way, the context information is fused, the balance between automation efficiency and decision robustness is realized while ensuring high-precision matching, and finally an intelligent EMPI matching process that can dynamically adapt and self-optimize is constructed, effectively solving the bottleneck faced by the prior art.

[0061] The implementations of the present disclosure have been described above with the foregoing description being exemplary rather than limiting in nature. Also, the implementations disclosed are not limited to what has been described in relation to the implementations disclosed. Numerous modifications and variations have been omitted and are apparent to those skilled in the art without departing from the scope and spirit of the implementations described.

Claims

1. A cross-institutional patient master index dynamic matching system based on reinforcement learning, characterized in that, The method comprises the following steps: a new patient record acquisition module is configured to acquire a new patient record from an external medical institution; an index key generation module is configured to generate an index key based on the standardized new patient record after standardizing the new patient record; a candidate module is configured to perform candidate set retrieval in an EMPI database based on the index key to obtain a candidate record set; a pairing module is configured to pair the new patient record with each candidate record in the candidate record set to obtain a record pair set; a record pair processing module is configured to perform similarity multi-dimensional 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 comprises a context slot machine model and a deep Q network; a decision result list execution module is configured to execute the decision result list to obtain an updated EMPI database or a manual review task; wherein the decision module comprises: a record pair optimization unit configured to perform discriminability decoupling embedding optimization on the record pair feature vector to obtain an optimized record pair feature vector; a reward calculation unit configured to input the optimized record pair feature vector into the context slot machine model as context to obtain an expected immediate reward of each action; a confidence generation unit configured to calculate a confidence based on the expected immediate reward of each action; a final action determination unit configured to determine whether the confidence exceeds a preset high confidence threshold, and in response to the confidence exceeding the preset high confidence threshold, determine an action with the highest expected immediate reward as a final action; and a decision unit configured to input the optimized record pair feature vector into the deep Q network as a current state to obtain the decision result in response to the confidence not exceeding the preset high confidence threshold. wherein 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; 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; and perform association mapping on the record pair feature vector based on the primitive embedding value to obtain the optimized record pair feature vector.

2. The reinforcement learning-based cross-institutional patient master index dynamic matching system of claim 1, wherein, The record pair processing module comprises: a name similarity calculation unit configured to calculate a Jaro-Winkler distance between a name field in the new patient record and a name field in the candidate record as a name similarity; an ID number similarity calculation unit configured to calculate a Levenshtein distance between an ID number in the new patient record and an ID number in the candidate record as an ID number similarity; an address similarity calculation unit configured to calculate a cosine similarity between an address in the new patient record and an address in the candidate record as an address similarity; and a date of birth similarity calculation unit configured to compare a date of birth in the new patient record with a date of birth in the candidate record exactly to obtain a date of birth similarity.

3. The reinforcement learning-based cross-institutional patient master index dynamic matching system of claim 2, wherein, The record pair processing module further comprises: a context information extraction unit configured to extract context information related to the matching task, the context information comprising a data source, a record quality score, and a processing timestamp; and a similarity arrangement unit configured to arrange 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 reinforcement learning-based cross-institutional patient master index dynamic matching system of claim 1, wherein, The decision module comprises: an action expected immediate reward calculation unit configured to input the record pair feature vector into the contextual gambling machine model as context input to obtain an expected immediate reward of each action; a confidence calculation unit configured to calculate a confidence based on the expected immediate reward of each action; a final action generation unit configured to determine whether the confidence exceeds a preset high confidence threshold, and in response to the confidence exceeding the preset high confidence threshold, determine an action with the highest expected immediate reward as a final action; and a decision result generation unit configured to input the record pair feature vector into the deep Q network as a current state in response to the confidence not exceeding the preset high confidence threshold to obtain the decision result.

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

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

7. The reinforcement learning-based cross-institutional patient master index dynamic matching system of claim 1, wherein, The decision result list execution module is configured to: if the final action in the decision result is matching, link the new patient record to a patient unique identifier already existing in the corresponding record pair to obtain the updated EMPI database; if the final action in the decision result is not matching, do not link; and if the final action in the decision result is to be sent for review, generate the artificial review task. The decision result list execution module is configured to: if the final action in the decision result is matching, link the new patient record to a patient unique identifier already existing in the corresponding record pair to obtain the updated EMPI database; if the final action in the decision result is not matching, do not link; and if the final action in the decision result is to be sent for review, generate the artificial review task. ​

Images