Record linkage (RL) refers to the task of finding records in a data set that refer to the same entity across different data sources (e.g., data files, books, websites, databases). Record linkage is necessary when joining data sets based on entities that may or may not share a common identifier (e.g., database key, URI, National identification number), as may be the case due to differences in record shape, storage location, and/or curator style or preference. A data set that has undergone RL-oriented reconciliation may be referred to as being cross-linked. In mathematical graph theory, record linkage can be seen as a technique of resolving bipartite graphs.
History edit
The initial idea of record linkage goes back to Halbert L. Dunn in his 1946 article titled "Record Linkage" published in the American Journal of Public Health.[1] Howard Borden Newcombe laid the probabilistic foundations of modern record linkage theory in a 1959 article in Science[2], which were then formalized in 1969 by Ivan Fellegi and Alan Sunter who and proved that the probabilistic decision rule they described was optimal when the comparison attributes are conditionally independent. Their pioneering work "A Theory For Record Linkage"[3] remains the mathematical foundation for many record linkage applications even today.
Since the late 1990s, various machine learning techniques have been developed that can, under favorable conditions, be used to estimate the conditional probabilities required by the Fellegi-Sunter (FS) theory. Several researchers have reported that the conditional independence assumption of the FS algorithm is often violated in practice; however, published efforts to explicitly model the conditional dependencies among the comparison attributes have not resulted in an improvement in record linkage quality. [citation needed]
Record linkage can be done entirely without the aid of a computer, but the primary reasons computers are often used for record linkage are to reduce or eliminate manual review and to make results more easily reproducible. Computer matching has the advantages of allowing central supervision of processing, better quality control, speed, consistency, and better reproducibility of results.[4]
Naming conventions edit
"Record linkage" is the term used by statisticians, epidemiologists, and historians, among others, to describe the process of joining records from one data source with another that describe the same entity. Commercial mail and database applications refer to it as "merge/purge processing" or "list washing". Computer scientists often refer to it as "data matching" or as the "object identity problem". Other names used to describe the same concept include "entity resolution", "identity resolution", "entity disambiguation", "duplicate detection", "record matching", "instance identification", "deduplication", "coreference resolution", "reference reconciliation", "data alignment", and "database hardening". This profusion of terminology has led to few cross-references between these research communities.[5][6]
While they share similar names, record linkage and Linked Data are two separate concepts. Whereas record linkage focuses on the more narrow task of identifying matching entities across different data sets, Linked Data focuses on the broader methods of structuring and publishing data to facilitate the discovery of related information.
Methods edit
Data preprocessing edit
Record linkage is highly sensitive to the quality of the data being linked, so all data sets under consideration (particularly their key identifier fields) should ideally undergo a data quality assessment prior to record linkage. Many key identifiers for the same entity can be presented quite differently between (and even within) data sets, which can greatly complicate record linkage unless understood ahead of time. For example, key identifiers for a man named William J. Smith might appear in three different data sets as so:
| Data set | Name | Date of birth | City of residence |
|---|---|---|---|
| Data set 1 | William J. Smith | 1/2/73 | Berkeley, California |
| Data set 2 | Smith, W. J. | 1973.1.2 | Berkeley, CA |
| Data set 3 | Bill Smith | Jan 2, 1973 | Berkeley, Calif. |
In this example, the different formatting styles lead to records that look different but in fact all refer to the same entity with the same logical identifier values. Most, if not all, record linkage strategies would result in more accurate linkage if these values were first normalized or standardized into a consistent format (e.g., all names are "Surname, Given name", all dates are "YYYY/MM/DD", and all cities are "Name, 2-letter state abbreviation"). Standardization can be accomplished through simple rule-based data transformations or more complex procedures such as lexicon-based tokenization and probabilistic hidden Markov models.[7] Several of the packages listed in the Software Implementations section provide some of these features to simplify the process of data standardization.
Deterministic record linkage edit
The simplest kind of record linkage, called deterministic or rules-based record linkage, generates links based on the number of individual identifiers that match among the available data sets.[8] Two records are said to match via a deterministic record linkage procedure if all or some identifiers (above a certain threshold) are identical. Deterministic record linkage is a good option when the entities in the data sets are identified by a common identifier, or when there are several representative identifiers (e.g., name, date of birth, and sex when identifying a person) whose quality of data is relatively high.
As an example, consider two standardized data sets, Set A and Set B, that contain different bits of information about patients in a hospital system. The two data sets identify patients using a variety of identifiers: Social Security Number (SSN), name, date of birth (DOB), sex, and ZIP code (ZIP). The records in two data sets (identified by the "#" column) are shown below:
| Data Set | # | SSN | Name | DOB | Sex | ZIP |
|---|---|---|---|---|---|---|
| Set A | 1 | 000956723 | Smith, William | 1973/01/02 | Male | 94701 |
| 2 | 000956723 | Smith, William | 1973/01/02 | Male | 94703 | |
| 3 | 000005555 | Jones, Robert | 1942/08/14 | Male | 94701 | |
| 4 | 123001234 | Sue, Mary | 1972/11/19 | Female | 94109 | |
| Set B | 1 | 000005555 | Jones, Bob | 1942/08/14 | ||
| 2 | Smith, Bill | 1973/01/02 | Male | 94701 |
The most simple deterministic record linkage strategy would be to pick a single identifier that is assumed to be uniquely identifying, say SSN, and declare that records sharing the same value identify the same person while records not sharing the same value identify different people. In this example, deterministic linkage based on SSN would create entities based on A1 and A2; A3 and B1; and A4. While A1, A2, and B2 appear to represent the same entity, B2 would not be included into the match because it is missing a value for SSN.
Handling exceptions such as missing identifiers involves the creation of additional record linkage rules. One such rule in the case of missing SSN might be to compare name, date of birth, sex, and ZIP code with other records in hopes of finding a match. In the above example, this rule would still not match A1/A2 with B2 because the names are still slightly different: standardization put the names into the proper (Surname, Given name) format but could not discern "Bill" as a nickname for "William". Running names through a phonetic algorithm such as Soundex, NYSIIS, or metaphone, can help to resolve these types of problems (though it may still stumble over surname changes as the result of marriage or divorce), but then B2 would be matched only with A1 since the ZIP code in A2 is different. Thus, another rule would need to be created to determine whether differences in particular identifiers are acceptable (such as ZIP code) and which are not (such as date of birth).
As this example demonstrates, even a small decrease in data quality or small increase in the complexity of the data can result in a very large increase in the number of rules necessary to link records properly. Eventually, these linkage rules will become too numerous and interrelated to to built without the aid of specialized software tools. In addition, linkage rules are often specific to the nature of the data sets they are designed to link together. One study was able to link the Social Security Death Master File with two hospital registries from the Midwestern United States using SSN, NYSIIS-encoded first name, birth month, and sex, but these rules may not work as well with data sets from other geographic regions or with data collected on younger populations.[9] Thus, continuous maintenance testing of these rules is necessary to ensure they continue to function as expected as new data enter the system and need to be linked. New data that exhibit different characteristics than was initially expected could require a complete rebuilding of the record linkage rule set, which could be a very time-consuming and expensive endeavor.
Probabilistic record linkage edit
Probabilistic record linkage, sometimes called fuzzy matching, takes a different approach to the record linkage problem by taking into account a wider range of potential identifiers, computing weights for each identifier based on its estimated ability to correctly identify a match or a non-match, and using these weights to calculate the probability that two given records refer to the same entity. Record pairs with probabilities above a certain threshold are considered to be matches, while pairs with probabilities below another threshold are considered to be non-matches; pairs that fall between these two thresholds are considered to be "possible matches" and can be dealt with accordingly (e.g., human reviewed, linked, or not linked, depending on the requirements). Whereas deterministic record linkage requires a series of potentially complex rules to be programmed ahead of time, probabilistic record linkage methods can be "trained" to perform well with much less human intervention.
Many probabilistic record linkage algorithms assign match/non-match weights to identifiers by means of u probabilities and m probabilities. The u probability is the probability that an identifier in two non-matching records will agree purely by chance. For example, the u probability for birth month (where there are twelve values that are approximately uniformly distributed) is 1/12 ≈ 0.083; identifiers with values that are not uniformly distributed will have different u probabilities for different values (possibly including missing values). The m probability is the probability that an identifier in matching pairs will agree (or be sufficiently similar, such as strings with high Jaro-Winkler distance or low Levenshtein distance). This value would be 1.0 in the case of perfect data, but given that this is rarely (if ever) true, it can instead be estimated. This estimation may be done based on prior knowledge of the data sets, by manually identifying a large number of matching and non-matching pairs to "train" the probabilistic record linkage algorithm, or by iteratively running the algorithm to obtain closer estimations of the m probability. If a value of 0.95 were to be estimated for the m probability, then the match/non-match weights for the birth month identifier would be:
| Outcome | Proportion of links | Proportion of non-links | Frequency ratio | Weight |
|---|---|---|---|---|
| Match | m = 0.95 | u ≈ 0.083 | m/u ≈ 11.4 | ln(m/u)/ln(2) ≈ 3.51 |
| Non-match | 1−m = 0.05 | 1-u ≈ 0.917 | (1-m)/(1-u) ≈ 0.0545 | ln((1-m)/(1-u))/ln(2) ≈ -4.20 |
The same calculations would be done for all other identifiers under consideration to find their match/non-match weights. Then, the identifiers of one record would be compared with the identifiers with every other record to compute the total weight: the match weight is added to the running total whenever a pair of identifiers agree, while the non-match weight is added (i.e. the runnin total decreases) whenever the pair of identifiers disagrees. The resulting total weight is then compared to the aforementioned thresholds to determine whether the pair should be linked, non-linked, or set aside for special consideration (e.g. manual validation).[10]
Determining where to set the match/non-match thresholds is a balancing act between obtaining an acceptable sensitivity (or recall, the proportion of truly matching records that are linked by the algorithm) and positive predictive value (or precision, the proportion of records linked by the algorithm that truly do match). Various manual and automated methods are available to predict the best thresholds, and some record linkage software packages have built-in tools to help the user find the most acceptable values. Because this can be a very computationally demanding task, particularly for large data sets, a technique known as blocking is often used to improve efficiency. Blocking attempts to restrict comparisons to just those records for which one or more particularly discriminating identifiers agree, which has the effect of increasing the positive predictive value (precision) at the expense of sensitivity (recall).[10] For example, blocking based on a phonetically coded surname and ZIP code would reduce the total number of comparisons required and would improve the chances that linked records would be correct (since two identifiers already agree), but would potentially miss records referring to the same person whose surname or ZIP code was different (due to marriage or relocation, for instance). Blocking based on birth month, a more stable identifier that would be expected to change only in the case of data error, would provide a more modest gain in positive predictive value and loss in sensitivity, but would create only twelve distinct groups which, for extremely large data sets, may not provide much net improvement in computation speed. Thus, robust record linkage systems often use multiple blocking passes to group data in various ways in order to come up with groups of records that should be compared to each other.
In recent years, a variety of machine learning techniques have been used in record linkage. It has been recognized that probabilistic record linkage is equivalent to the "Naive Bayes" algorithm in the field of machine learning, and suffers from the same assumption of the independence of its features (an assumption that is typically not true). Higher accuracy can often be achieved by using various other machine learning techniques, including a single-layer perceptron.
Mathematical model edit
In an application with two files, A and B, denote the rows (records) by in file A and in file B. Assign characteristics to each record. The set of records that represent identical entities is defined by
and the complement of set , namely set representing different entities is defined as
.
A vector, is defined, that contains the coded agreements and disagreements on each characteristic:
![{\displaystyle \gamma \left[\alpha (a),\beta (b)\right]=\{\gamma ^{1}\left[\alpha (a),\beta (b)\right],...,\gamma ^{K}\left[\alpha (a),\beta (b)\right]\}}](https://wikimedia.org/api/rest_v1/media/math/render/svg/052313bc7c782a24bd94cdb758894ef65c57aa81)
where is a subscript for the characteristics (sex, age, marital status, etc.) in the files. The conditional probabilities of observing a specific vector given , are defined as
![{\displaystyle m(\gamma )=P\left\{\gamma \left[\alpha (a),\beta (b)\right]|(a,b)\in M\right\}=\sum _{(a,b)\in M}P\left\{\gamma \left[\alpha (a),\beta (b)\right]\right\}\cdot P\left[(a,b)|M\right]}](https://wikimedia.org/api/rest_v1/media/math/render/svg/249987a0822c0454857b53d332067451bd840663)
and
respectively.[citation needed]
![{\displaystyle u(\gamma )=P\left\{\gamma \left[\alpha (a),\beta (b)\right]|(a,b)\in U\right\}=\sum _{(a,b)\in U}P\left\{\gamma \left[\alpha (a),\beta (b)\right]\right\}\cdot P\left[(a,b)|U\right],}](https://wikimedia.org/api/rest_v1/media/math/render/svg/74e79cee4835157ed3f3b314816a19de89e277b0)
Applications edit
Data warehousing and business intelligence edit
Record linkage plays a key role in data warehousing and business intelligence. Data warehouses serve to combine data from many different operational source systems into one logical data model, which can then be subsequently fed into a business intelligence system for reporting and analytics. Each operational source system may have its own method of identifying the same entities used in the logical data model, so record linkage between the different sources becomes necessary to ensure that the information about a particular entity in one source system can be seamlessly compared with information about the same entity from another source system. Data standardization and subsequent record linkage often occur in the "transform" portion of the extract, transform, load (ETL) process.
Historical research edit
Record linkage is important to social history research since most data sets, such as census records and parish registers were recorded long before the invention of National identification numbers. When old sources are digitized, linking of data sets is a prerequisite for longitudinal study. This process is often further complicated by lack of standard spelling of names, family names that change according to place of dwelling, changing of administrative boundaries, and problems of checking the data against other sources. Record linkage was among the most prominent themes in the History and computing field in the 1980s, but has since been subject to less attention in research.[citation needed]
Medical practice and research edit
Record linkage is an important tool in creating data required for examining the health of the public and of the health care system itself. It can be used to improve data holdings, data collection, quality assessment, and the dissemination of information. Data sources can be examined to eliminate duplicate records, to identify under-reporting and missing cases (e.g., census population counts), to create person-oriented health statistics, and to generate disease registries and health surveillance systems. Some cancer registries link various data sources (e.g., hospital admissions, pathology and clinical reports, and death registrations) to generate their registries. Record linkage is also used to create health indicators. For example, fetal and infant mortality is a general indicator of a country's socioeconomic development, public health, and maternal and child services. If infant death records are matched to birth records, it is possible to use birth variables, such as birth weight and gestational age, along with mortality data, such as cause of death, in analyzing the data. Linkages can help in follow-up studies of cohorts or other groups to determine factors such as vital status, residential status, or health outcomes. Tracing is often needed for follow-up of industrial cohorts, clinical trials, and longitudinal surveys to obtain the cause of death and/or cancer. An example of a successful and long-standing record linkage system allowing for population-based medical research is the Rochester Epidemiology Project based in Rochester, Minnesota.
Software implementations edit
- Duke - small and fast Java deduplication and record linkage engine (open source)
- Data Deduplication and Integration - developed by the CS department at University of Maryland
- DataCleaner - by eobjects.org
- Daurum - Deduplication and Integration tool & services - by Sparsity Technologies
- Febrl - Open source software application for RL - by the Australian National University.
- FRIL - Fine-Grained Record Integration and Linkage Tool - developed at the Emory University and US Centers For Disease Control and Prevention
- Link Plus Probabilistic record linkage program - developed at the US Centers For Disease Control and Prevention
- MTB - Merge ToolBox - by the University of Duisburg-Essen
- Open Source ChoiceMaker Technology - released by ChoiceMaker Technologies
- OpenDQ Massively scalable record linkage / Data Matching - by Infosolve Technologies
- Silk - open source RDF-based record linkage framework from Freie Universität Berlin
- SimMetrics Open source library of String Similarity techniques - by Sam Chapman at the University of Sheffield
- OpenEMPI - Open Source Enterprise Master Patient Index - developed by SYSNET International
- DataQualityTools - by DataQualityApps
- The Link King - SAS System application - developed at Washington State's Division of Alcohol and Substance Abuse (DASA) by Kevin M. Campbell
- MatchMetrix EMPI - Enterprise Master Patient Index - developed by NextGate
- Data Match - DataMatch 2011 for record linkage - developed by Dataladder
- Oyster Entity Resolution - Oyster Entity Resolution - Developed by The University of Arkansas at Little Rock, John Talburt Ph.D.
See also edit
References edit
- ^ Dunn, Halbert L. (December 1946). "Record Linkage" (PDF). American Journal of Public Health. 36 (12): pp. 1412–1416. doi:10.2105/AJPH.36.12.1412. Retrieved 2008-05-31.
{{cite journal}}: CS1 maint: date and year (link) - ^ Newcombe, H. B.; Kennedy, J. M.; Axford, S. J.; James, A. P. (1959). "Automatic Linkage of Vital Records". Science. 130 (3381): 954–959. doi:10.1126/science.130.3381.954. PMID 14426783.
{{cite journal}}: Unknown parameter|month=ignored (help)CS1 maint: date and year (link) - ^ Fellegi, Ivan P.; Sunter, Alan B. (1969). "A Theory for Record Linkage". Journal of the American Statistical Association. 64 (328): pp. 1183–1210. doi:10.2307/2286061. JSTOR 2286061.
{{cite journal}}: Unknown parameter|month=ignored (help)CS1 maint: date and year (link) - ^ Winkler, William E. "Matching and Record Linkage" (PDF). U.S. Bureau of the Census. Retrieved 12 November 2011.
- ^ Cristen, P & T: Febrl - Freely extensible biomedical record linkage (Manual, release 0.3) p.9
- ^
Elmagarmid, Ahmed (January 2007). "Duplicate Record Detection: A Survey" (PDF). IEEE Transactions on Knowledge and Data Engineering. 19 (1): pp. 1–16. doi:10.1109/TKDE.2007.9. Retrieved 2009-03-30.
{{cite journal}}: Unknown parameter|coauthors=ignored (|author=suggested) (help)CS1 maint: date and year (link) - ^ Churches, Tim; Christen, Peter; Lim, Kim; Zhu, Justin Xi (13 December, 2002). "Preparation of name and address data for record linkage using hidden Markov models". BMC Medical Informatics and Decision Making. 2: 9. doi:10.1186/1472-6947-2-9. PMC 140019. PMID 12482326.
{{cite journal}}: Check date values in:|date=(help)CS1 maint: date and year (link) CS1 maint: unflagged free DOI (link) - ^ Roos, L. L.; Wajda, A. (1991). "Record linkage strategies. Part I: Estimating information and evaluating approaches". Methods of Information in Medicine. 30 (2): 117–123. doi:10.1055/s-0038-1634828. PMID 1857246. Retrieved 11 November 2011.
{{cite journal}}: Unknown parameter|month=ignored (help)CS1 maint: date and year (link) - ^ Grannis, S. J.; Overhage, J. M.; McDonald, C. J. (2002). "Analysis of identifier performance using a deterministic linkage algorithm". Proc AMIA Symp.: 305–9. PMC 2244404. PMID 12463836.
{{cite journal}}: CS1 maint: date and year (link) - ^ a b Blakely, Tony; Salmond, Clare (2002). "Probabilistic record linkage and a method to calculate the positive predictive value". International Journal of Epidemiology. 31 (6): 1246–1252. doi:10.1093/ije/31.6.1246. PMID 12540730.
{{cite journal}}: Unknown parameter|month=ignored (help)CS1 maint: date and year (link)