We’ve designed a mockup for an interstitial page that appears when a user attempts to register a patient who may already exist in the system. The goal is to help users more easily identify and manage potential duplicates before proceeding with registration.
A few quick thoughts here, I hope they’re helpful:
I think the component that’s needed here is a modal. Modals are the highest level of interruption for a user, and forces them to take action on something before proceeding. As a result, we need to be careful about the interactive elements that are on-screen.
For example, in the mock-up you shared it would appear that the user could click on the patient name, or patient lists they are a part of. This would presumably take the user to that patient chart, and so not force the user to take action on the modal.
I think it would be helpful to highlight where the similarity between other patients was found. Is it a similar name? If yes, maybe consider how visually that can be made clearer for the user so they don’t have to hunt for the information they need to confirm with the patient.
The final point I would mention is the use of capitalisation for various elements on the screen. OpenMRS uses ‘sentence case’ for headings, which offers a neater and more consistent reading experience.
What is the trigger for the screen that shows potential duplicates? It would seem the user is taken to a new screen… is that after they click ‘Register’ or when name, gender and DOB are filled? Is the user given an option to check duplicates or automatically shown them?
Depending on how often this happens and the chance of it being an actual match, I would consider the level of interruption on that basis. Do we have any sense of this from research?
Do we need to duplicate the ‘Create as new’ action?
If we’re asking them to review other records, should they be a the top? Maybe with the ‘in progress’ registration underneath with the more prominent button?
This is great. In addition to the comments above, I think you should consider two things: How much information does the user need to know to determine if it is a duplicate and to balance this against the need for privacy since the user might not have a valid reason to open someone else’s chart. The second thing would be to add a photo to the patient details section (or perhaps in the initial list of dupes).
I also wonder whether this dialog is a reason for someone to notify an administrator of potential dupes in the list of dupes… in other words generate an email/message to an admin with the id’s of possible dupes to be addressed later.
@cduffy Thank you for your thoughtful feedback on the mockup!
You’ve raised excellent points about using modals appropriately. I agree that we need to ensure the interface explicitly forces a decision rather than allowing users to navigate away. We’ll modify the design to remove clickable patient names so as to maintain focus on the duplicate resolution task.
Your suggestion to visually highlight the matching fields between patients is also spot-on. Perhaps we could implement visual indicators to highlight fields that match and i believe this would make it much easier for the users.
Thank you for pointing out the capitalization inconsistency - we’ll update all headings to follow OpenMRS’s sentence case convention.
@pauladams
Thank you for your insightful questions and suggestions!
The interstitial page will appear once the user completes the registration and clicks ‘Register’ on the form. At this point, any potential duplicates will be displayed, and the user can expand the accordion—as shown in the third mockup—to view full patient details.
Regarding the frequency of true vs. false duplicates - would need to do more research on this one. Do you have some recommendations on the same and how we could approach it?
Regarding the redundant “Create as new” actions, we actually had debated about that … i guess we can address that easily once we revise the layout to have the potential matches at the top and in progress below.
Your suggestion to reorganize with potential matches at the top and in-progress registration below makes perfect sense. We’ll revise the layout.
@akanter Thank you for highlighting these important considerations!
Making the duplicate detection fields fully customizable to allow implementations to configure exactly which patient attributes are displayed based on their specific workflow and privacy requirements is very necessary.
Adding patient photos as one of these customizable fields is an excellent suggestion. Implementations that capture patient photos could choose to include this visual element, which could significantly improve duplicate detection accuracy in many contexts. But since not all implementations may collect photos, making this configurable ensures the system remains flexible for various use cases.
Your suggestion for a notification feature is great - since registration staff may need to defer complex duplicate resolution issues say to admin. Certainly an area to think of.