Just to highlight the big conceptual breakthrough (still untested in production, but hopes are high):
In OpenMRS Core there's a single "Look at these possible similar patients" as a blocking step in the workflow. (And in core this step happens before the user has inputted enough info to give a really good result.) In this new workflow, they're displaying the possible matches more subtly, and it doesn't block the workflow. But it's shown on several screens, so the user has more chances to see it. And each time the user enters a bit more data, the list of possible matches is refined further. (I can imagine that in some future version depending on the level of certainty of the match, they could make the visual cue more or less subtle.) -Darius On Thu, Nov 17, 2011 at 10:38 AM, 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]
