Data quality is a central issue in exploiting public databases. As part of the EurosForDocs project, which aims to bring transparency to financial ties between pharmaceutical companies and healthcare professionals, this issue is particularly critical. The reliability of analyses depends on our ability to unambiguously identify each healthcare professional receiving remuneration or benefits.
The RPPS (Shared Directory of Health Professionals) is a national government directory that lists all healthcare professionals in France and assigns them a unique and public number. This number is for example visible in the “Legal Information” section of a practitioner’s page on Doctolib, or on a prescription. In theory, the RPPS number should guarantee a reliable association between a remuneration declaration from a company and a healthcare professional. It is therefore essential to ensure that this information is as accurate as possible. However, in practice, data entry errors are frequent. It is not uncommon for the same professional to be assigned multiple RPPS numbers by the same company, creating conflicts that distort the analysis.
This article presents a methodology for detecting and correcting these inconsistencies on a large scale. We detail a fuzzy matching approach that consists of measuring the similarity between declared data and an official source. Depending on the level of similarity measured, you can then correct the data. This method makes it possible to automate identifier cleanup and significantly improve database quality.
For a more general view of EurosForDocs project data quality issues, you can consult this article.
The problem: unique identifiers that aren’t #
The RPPS number is the cornerstone of the declaration system. Each healthcare professional should be associated with a unique number to guarantee reliable identification across different declarations from different companies.
However, the reality of the data is more complex. We observe many cases where the same company declares multiple remuneration with the same name, first name, profession and postal code of beneficiary (which seems to indicate the same person) but with different RPPS numbers. This situation creates an ambiguity: is it a data entry error or two distinct but same-named professionals?
To resolve this doubt, the procedure consists of comparing the official information linked to each declared RPPS number with the other information declared by the company. This approach makes it possible to identify absurd RPPS numbers compared to the declared information, and to determine the number that seems most relevant compared to the declaration.
Let’s take a concrete example:
A laboratory declares a beneficiary, “Jean Crochet”, assigning him two RPPS numbers: 10002956406 and 10003257325.
- The RPPS directory confirms that number
...406indeed belongs to Dr. Jean Crochet, a doctor practicing in the stated department. The information is consistent. - Conversely, number
...325is assigned to Dr. Nathalie Bourgeois, another practitioner. The information is clearly inconsistent.
This simple cross-check is sufficient to invalidate the second RPPS number and resolve the ambiguity. The challenge is not conceptual but operational: with more than 12,500 similar cases identified, and new cases potentially appearing daily, manual processing is unthinkable. It is therefore necessary to develop an automated method to apply this reasoning systematically and reliabilize the database.
A flexible approach: textual similarity #
Simple identifier verification quickly runs into another reality: declared information (name, first name) is often close but not strictly identical to that in the directory. A typo, an inversion between name and first name, or the use of a maiden name can be enough to incorrectly invalidate a match.
For example, a doctor “Jean-Luc Vilatte” is declared with two RPPS numbers. The official directory indicates that one number belongs to “Jean-Luc Vallet” and the other to “Jean-Luc Villate”. A strict comparison would reject both options. However, many algorithms offer different ways to measure the similarity between two character strings. The EurosForDocs project chose to work with the Jaro-Winkler metric. The exact definition of this metric not being the objective of this article, curious readers can refer to this article. Using this metric, we measure 97% similarity for “Villate” versus “Vilate” but only 74% versus “Vallet”. This metric therefore allows us to identify the name that corresponds least to the declaration.
Rather than seeking an exact match, our method will create a similarity score between the declared information and the official information. This score is defined as the sum of the similarity of first names and the similarity of surnames. An absurd RPPS number will have a similarity score close to zero while a perfect declaration will have a score of 2 (100% for each part of the identity). This approach, known as fuzzy matching, provides the flexibility needed to handle various types of data entry errors.
Managing common entry errors #
It should be noted that even in the RPPS directory, the same professional can appear under multiple names. A typical case is the presence of female doctors who appear with different combinations of their maiden name and married name. In this case, we calculate the similarity score for all variations. The best score for each RPPS number will help identify the most relevant number.
But there are also different types of data entry errors that give poor similarity scores and don’t allow us to correctly select the correct RPPS number.
-
Name/first name inversions: Sometimes the name and first name fields are inverted during entry. To neutralize this effect, we calculate similarity for both
name/first nameandfirst name/name(in addition to traditionalname/nameandfirst name/first name), and we keep the most favorable score. -
Compound names and first names: A professional named “Loriot De Rouvray” can be declared simply as “De Rouvray”. Using the Jaro-Winkler metric directly would give only 42% similarity; which is very low. To solve this case, we use a custom metric: we count the number of words in common between the declared name and the official one, divided by the smallest number of words in either name. Thus, “De Rouvray” and “Loriot De Rouvray” obtain 100% similarity. Indeed, the two names have two words in common (“De” and “Rouvray”) and the smallest name also contains two words. The same logic applies to first names, allowing recognition of “Jean” as a short version of “Jean-Luc”.
The final similarity is then a combination of the different factors described earlier. The calculation breaks down into several steps to obtain an overall similarity score.
The objective is to build a robust score that takes into account the different ways a name and first name can be entered.
-
Evaluation of similarity for name and first name For the family name, we calculate two distinct scores: the Jaro-Winkler metric and the composition score. We then keep the higher value of the two. This operation is repeated for the first name. We then have a similarity score for the name, and another for the first name.
-
Calculate a “direct similarity” score We add the two scores obtained in the previous step. This total represents our similarity score when we assume that the declaring company did not invert the name and first name of the beneficiary.
-
Account for name/first name inversion To handle cases where the name and first name might have been inverted during entry, we calculate an “inverted similarity” score. To do this, we compare the declared family name with the official first name, and vice versa, using the Jaro-Winkler metric. Unlike direct similarity, we don’t account for a composition score here to allow only one “error” on the part of the declaring company and limit the risk of getting a good score by chance.
-
Determination of final score The final similarity score is simply the maximum between the direct similarity score and the inverted similarity score.
Refining the score: contextual variables and confidence threshold #
While name and first name similarity is an excellent indicator, it is not always sufficient. Two situations require adjustments to ensure method reliability: handling of homonyms and very poor quality data.
Handling homonyms: the need for contextual information #
The method reaches its limit when faced with true homonyms: two distinct professionals with the same name and first name; that is, the same similarity score. To distinguish between them, it is essential to use additional contextual information:
- Postal code
- Profession
- Department of practice
However, these variables must be used with caution. A match on postal code should not over-compensate for very different names and first names. We integrate them as slight bonuses to weight the similarity score. A match between the professional directory’s postal code and that of the declaration increases the similarity metric by 0.04. Likewise, a profession match adds 0.02 to the similarity. Finally, a match of the department of practice adds 0.01 to the similarity. These values were chosen arbitrarily following data exploration; the objective being to distinguish between two very similar candidates, but insufficient to make a completely incoherent name pass in front of a more relevant name solely thanks to a postal code or profession.
The validity threshold: protecting against aberrant data #
Sometimes none of the beneficiaries linked to the declared RPPS numbers seem suitable. For example, a declaration for the nurse “Karine NOREILS” is associated with two RPPS numbers which, according to the directory, correspond to two doctors: “Christophe Michiels” and “Bernard Duclos”. The names, first names and professions are so far apart that no match is acceptable.
To avoid creating incorrect links in such cases, we have defined a minimum similarity threshold. If the best score obtained does not reach this threshold (arbitrarily set at 1.7), no decision is made. The ambiguity is retained and the case is flagged for further analysis. This safeguard is essential to ensure that only corrections with a high degree of confidence are automated.
Putting things in perspective and conclusion #
The methodology described here is a concrete application of fuzzy matching techniques to a data quality problem. It illustrates that a simple and pragmatic approach, combining a standard similarity algorithm with targeted business rules, makes it possible to resolve a large part of the ambiguities automatically.
On all beneficiaries presenting RPPS number ambiguity, this system allows us to resolve more than 95% with a high degree of confidence. The remaining cases, often the most complex, are flagged for further analysis.
This approach demonstrates the importance of adapting data science tools to business context. A deep understanding of data and potential sources of error (homonyms, compound names) is essential to build a cleaning solution that is both robust and reliable.
