We’re working on implementing the “Prevent Duplicates at Registration” feature and would greatly appreciate your review and input on our current requirements and approach.
We’ve outlined requirements for preventing duplicate patient registrations based on our analysis, but we want to ensure we’re addressing the full scope of the challenge. Our current approach includes:
Patient Search Enhancement: Improving the search functionality to identify potential matches before new registrations are created
Match Criteria Configuration: Allowing the implementation to configure which demographic fields should trigger duplicate detection
Review & Resolution Process: Creating a workflow for reviewing and resolving potential duplicates
Key Questions for the First Iteration
Required Fields: Currently considering name, gender, birth date and address as matching criteria. Are there other identifiers that have proven critical in your implementation?
Cultural Considerations: How can we account for naming variations across different cultures and regions? (e.g., name order, spelling variations, shortened names)
Performance Impact: Has anyone experienced significant performance issues with duplicate checking at registration?
User Experience: What has been most effective in your experience for presenting potential duplicates to users during registration?
False Positives/Negatives: What strategies have you employed to minimize false positives while still catching potential duplicates?
Implementation Considerations
We would love to hear about your experiences, challenges, and any lessons learned.
Timeline and Next Steps
We aim to finalize the requirements in the next two weeks. Your inputs would be incredibly valuable in shaping this work.
Thank you for your insights and continued support of the OpenMRS Community!
Before we go too deep into thinking about and creating requirements, have we assessed the “find similar patients” feature from the O2 RefApp and whether that’s a style / pattern we want to adopt?
Thanks both; yes, we have reviewed these. Screenshots and details that were obvious in the UI were captured in the wiki page. This Monday we also had a great session with PIH folks (Fiona, Dave, Mark, Mike) about this and they shared in great detail the UI and algorithm nuances they’ve been running into:
Notes from Monday Session, 2025-04-14: BA & Dev Feasibility Meeting: Review of Existing PIH Algorithm & UI
Summary: Timing of this project is great because at same time PIH has been noticing they still have many duplicate patients being created, despite the O2 UI and algorithm. They think it’s a multi-factor problem, with UI and with the weights in the algorithm. Open to alternative algorithm approaches too. Next steps plan: (1) All agreed UI should have Interstitial page for Registration clerks; @veronica to work on that and re-present. (2) To find out if DIGI or other community members know of alternative logic approach.
There is a means for configuring on the backend: APIs in backend allow for finding similar pts; 2 diff algorithms: “Fast Search” (run during workflow), and “Precise Search” (run at end of workflow, when user completes registration).
Fast Search occurs while each field in Registration Form is completed. Seems performant, including with implementations with 100,000’s of patients.
Don’t have to use 2 algorithms; could just point to 1.
Data received from API call: The patient, the Match Quality (weighted score), and matched fields. In UI: ordering of the matches is based on the weighted score.
Configured in Global Properties re. Which algorithm (fast or slow) you want to use. Rwanda and Haiti systems are configured this way.
Includes phonetic name search: Github Repo. Specifically uses “Double Metaphone” approach. Does double-metaphone matches on first and last name (as starting point, for base cohort)
PIH implementations also specificaly include considerations cor Chichewa and Kinyarwanda (eg r’s and l’s swapped in Rwanda).
Don’t want to have to have custom module; likely want added into Registration module and supported via Iniz.
Vision: Every single time a field is changed, javascript would hit this endpoint.
Review of Current Algorithm: Score/Points-Based. Assigns score: Higher score —> more likely match. Points weights are manually configured; last adjusted ~10-15 yrs ago at PIH.
Points for address matching: In implementation-specific logic, includes nuanced address field matching (e.g. in Haiti, “cell”, “commune”…) but we could adjust generic one (and include config docs if ppl want to adjust for their implementation)
@ddesimone did a review a few days ago of real patients’ results and their “possible match” scores. Findings: scores >20ish were definitely matches; under 10 low/no-value
Next steps plan: (1) All agreed UI should have Interstitial page for Registration clerks; @veronica to work on that and re-present. (2) To find out if DIGI or other community members know of alternative logic approach.
@ibacher@caseynth2@reagan@pmanko & DIGI team members: I know you have a lot of experience with patient matching challenges because of DIGI’s work with HIEs and MPIs / Patient Registries.
Based on your experience, would you recommend we carry on with a simple weighting/points/score-based algorithm for duplicate detection in the Registration Clerk’s workflow? Or is there a different approach you suggest?
(Keeping in mind IMHO we want to keep this relatively simple so it can be easy to maintain and configurable by implementation, such as in the example PIH has where they added weights for some locations’ township names etc.).
What you’ve described above qualifies as fairly sophisticated. It would be better to have a pluggable and configurable algorithm to do the matching (double metaphone is fine, but focused on US pronunciation and useless with non-Latin alphabets), but the goal here is quickly surfacing possible matches more so than some perfect algorithm.
“As @grace mentioned, one of the suggestions that emerged during the design session was to introduce an interstitial page to manage potential duplicate patients. I’ve put together two mock-ups for your review and feedback.” All ideas are welcome. cc: @cduffy@pauladams@ibacher
