Thanks Cosmin. This is very helpful. We came up with something very similar when creating a registration module for AMPATH – i.e., providing possible matches "inline" during data entry instead of as a separate step. Part of the trick was deciding the level of sensitivity & specificity as well as when it's helpful (or not helpful) to alert users. For example, telling someone that there are 100 matches to a common names doesn't help, but saying there are 3 likely matches can be very helpful. Should gender match be required (probably not true when every other demographic matches); so, we ended up with some considerations like "gender must match unless name(s) & birthdate are exact matches." We also avoid alerting of potential matches if there are too many (something like 5-10, I believe).
Thanks again for sharing your approach. Cheers, -Burke On Thu, Nov 17, 2011 at 1:38 PM, Cosmin Ioan <[email protected]> wrote: > Hi all,**** > > ** ** > > Thank you for your interest and we appreciate the great feedback. The only > patient search algorithm we are leveraging at this point is a search based > on the patient full name. The system combines the results returned by > OpenMRS PatientService.getPatients(String query) with the results returned > by NamePhonetics module findPatient() method. Our plan is to build a bit > more complex algorithm. As the registration process advances from one > screen to another the potential patient matches would filter even more > based on the additional information captured. Please see the attached pdf > which represents the UI screens designed by Evan. e.g. As soon as the > patient name and gender are captured the system retrieves a list of all > possible matches, once the patient age is captured the system would filter > out the previous list based on the patient age(+/- n(configurable setting) > years), once the patient address is captured the list would be filtered > even more presenting maybe only the possible matches from the same > geographical area (department or commune). Those are just some initial > thoughts, we would probably have a better idea on how to prevent duplicates > after we deploy the pilot and analyze the data entered by real users. Based > on those results we will refine and tune the patient search algorithm. Any > other ideas or suggestions on how to build a flexible and a pretty generic > search algorithm would be appreciated.**** > > ** ** > > Thanks,**** > > Cosmin**** > > ** ** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Burke > Mamlin > *Sent:* Thursday, November 17, 2011 10:55 AM > *To:* [email protected] > *Subject:* [OPENMRS-DEV] Algorithm for detecting possible duplicate > patients during registration**** > > ** ** > > Cosmin & PIH folks,**** > > ** ** > > We really appreciated the demo on today's dev forum. Could you give a > quick summary for or a link to the algorithm you're using to find potential > duplicate. I realize that these algorithms could easily be regional, but > there could be good shareable lessons in finding the balance between > sensitivity & specificity too – e.g., only show when possible matches are > less than n, which parts of demographics must match (gender?) & which have > fuzzy matches (birthdate?), etc.**** > > ** ** > > Thanks!**** > > ** ** > > Cheers,**** > > ** ** > > -Burke**** > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
