July 16, 2007 at 4:39 pm
Comments posted here are about the content posted at http://www.sqlservercentral.com/columnists/bnordberg/3105.asp
July 19, 2007 at 7:11 am
Thanks for this quick review of the fuzzy logic transform in SSIS. Very helpful for patient identification/matching in health care organizations like ours. We're a community health center in Boston that has lots of patient matching needs.
July 19, 2007 at 7:28 am
"I will have to generate a work list for someone to review"
And what is the confidence factor of the reviewer? (since this is likely to be an unpleasant task that may end up being an intern or a temp)
It's an interesting concept, but I would feel much better seeing it used for marketing analysis/data mining rather than patient records. When my new doctor's office requested medical files from my old doctor's office, they recieved information for a patient that was not me (but had the same first and last name) - I assumed it was human error. The intentional use of 'fuzzy' record matching at the machine/DB level seems unwise.
I would make a stronger argument for information integrity at entry rather than risk "fuzziness" as a systemic means of mitigating sloppy data. Of course that's a different topic and a considerable amount of work in itself.
.. and not to be completely down on the author of this article - the screenshots and examples make it obvious there is considerable power available with this technique. (a feature I did not know, and would likely have tried to home-grow if needed) I feel this is the same kind of power as using index hints or NoLock directives: if used properly it's a great asset, if used improperly it's a great liability.
July 19, 2007 at 7:31 am
It is worth mentioning that these "Fuzzy" features require an Enterprise SQL edition.
July 19, 2007 at 8:15 am
In answer to Mr. Dougherty, it is always preferable to create correct record linkages from the start. However, fuzzy matching as described here is sometimes a necessity, especially when two recordsets come from completely different sources but have some overlap in the entities represented. A classic example would be finding common patients in two different vaccination campaigns with no collaboration. Matching through inner joins will both miss true matches and cause duplicates in the output.
I very much enjoyed this article. The SQL Server 2005 fuzzy record linking implementation is a good start and will suffice for many users. My company, Balance Engines, has been doing similar reconciliations for the cellular and oil industries for five years. Other factors that our software addresses are fuzzy lookups that aren't based on string "edit distance" such as custom date and Double comparisons and rules-based match score modifications. The review process mentioned in the article is absolutely essential because fuzzy comparisons are always an imperfect form of machine learning. However, they can be extremely useful in comparing large recordsets that would be cost prohibitive to review in a completely manual way. By eliminating all but a few percent of sure matches or non-matches, the labor required to review the rest can be made affordable.
I love talking about record matching issues. Feel free to contact me at bezell balanceengines.com
July 19, 2007 at 1:44 pm
I agree with Mr Dougherty, in a perfect world we would not want or need to do this. Unfortunately when you get patients in the ER, getting a correct spelling of their name is second to stopping the bleeding. I've been using probabilistic techniques for years - particularly with EMS (emergency medical services), where the patient may not even be able to give a name.
I found that once we get below .80 the matches are of variable use. But it depends on the fields you have to match with, and the discriminating power of each within the set.
Hyphenated last names (for example Nordberg vs Halbe-Nordberg) are the worst as they produce very weak matches, but the match is evident when human reviewed - hence the need for human intervention.
February 18, 2009 at 2:47 pm
Brian,
It's an interesting approach and one that I wish I could use, however this doesn't allow me to establish conditional matching as well. Therefore, I'm attempting to do record grouping within T-SQL. While I can identify the matches easily enough for a single record, I'm having trouble doing so in bulk. I cannot seem to create unique group identifiers for each set of matches.
If I take each record one at a time and compare against all records, I get a reasonably accurate match rate, but it takes almost 24 hours to group 90,000 records (and that's just my sample size!!). I currently have 23 various tests with a decreasing confidence level to determine if records should be grouped together. I considered using a RANK() OVER partition method, but the ORDER BY portion is not precise enough to account for allowable variances (such as month and day being reversed in a DOB).
Does anyone have any suggestions?
Aaron
LinkedIn: https://www.linkedin.com/in/sqlrv
Website: https://www.sqlrv.com
April 8, 2009 at 11:47 pm
Hi not sure if you will get this post or not but here goes.
I have started working on a Linkage Project and was mucking around with the Fuzzy Matching in sql 2008. Do you know if there is a way of sort of fuzzy matching on date ie birthdate which is a common field in different data sets. I guess it would do a check to see how far it was out by and allocate a score.
thanks
Fred
April 9, 2009 at 7:55 am
Yes date of birth is always good to use. And it will allocate a proximity score. Unfortunatly DOB's can differ significantly with simple typos e.g: 5/11/1972 vs 5/11/1927 or the more common 5/11/1972 vs 11/5/1972... So make sure you have other, more reliable variables to include (gender, names ...)
April 9, 2009 at 11:41 pm
thanks for your reply. why is that Date fields will only display for exact matches?
I cant set it to fuzzy matching.
the fields i use are firstname, surname, sex and Date of birth. but unfortunately the Date of birth only looks at exact matches.
any ideas?
thanks again
Fred
April 10, 2009 at 8:52 am
I'm going to quote my own article "If your data columns are anything aside from strings (datetime, int, etc.) the Mapping Type will only allow exact." I dislike this fact, but its true. So do a view of your data with a convert(varchar, datetimefield,101)
B
April 11, 2009 at 6:35 am
excellent idea thanks.
was wondering how it compares when the dates are slightly different. i guess as you said as long as we have other variables like firstname, surname and gender should get a good result
April 14, 2009 at 12:36 am
Hi Brian
thanks for your help with this..I have a querie i am trying to work out not sure if you have come across an issue like this.
I am comparing Surname, given name and Date Of birth. seems like if the given name has a middle name included in the reference field and not in the source given name field it doesnt even seem to compare the other fields as it gives a 0 confidence.
is there a particulare setting i should be using?
April 14, 2009 at 7:44 am
No I have not seen that, it could be that it is dragging the match weight down enough that it is below your threshold for a match?
Regardless they will lower your scores. Can you script them out? I know it is error prone such as Mary Anne is Anne the middle ... Then once you script them to their own field find the person that made the database and give them a good tutorial on atomicity of fields!
B
April 14, 2009 at 8:04 am
bnordberg (4/14/2009)
...find the person that made the database and give them a good tutorial on atomicity of fields!
If only it were that easy!! I deal with data all the time that is very messy because folks don't care as long as it prints on paper OK. They don't consider the benefits of putting data into the appropriate fields. I get data from Electronic Medical Record systems and the majority of important data is entered into comment fields simply because it's easier to enter that way and as long as the printed paper has the info for the doc to read, it's OK in their minds. Of course, that wrecks havoc on any attempt to utilize the data for any other purpose!
LinkedIn: https://www.linkedin.com/in/sqlrv
Website: https://www.sqlrv.com
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply