GOOGLE SUMMER OF CODE Enhancing the OpenMRS Patient Matching Module Demo Mentored By Shaun Grannis James Egg Gauthami Pingili

Objectives Managing the Strategies Interface* Adding a Merge Confirmation * Configuring an Analysis Server to point to the Production Server * Persisting configuration data for each de-duplication report * Enhancing the Matching algorithm by matching the Transposed Fields* * Accomplished *Testing

Managing the Strategies Interface Improved Manage Strategies Interface:  The module’s ‘Create new strategies’ page, which lists the available matching fields, was modified to 2 columns to avoid horizontal scrolling

The Previous Strategies Screen

The Revised Strategies Screen

Highlighted “active fields” used for matching in the strategy page so that they are recognized easily

Added Merge Confirmation because merging patient records is not reversible programmatically, we should add a warning statement when users click on the "patient merge" button.

Configured An Analysis Server to Point to a Production Server Added a URL property option to the patient de- duplication module to define which OpenMRS instance the de-duplication report points to, instead of automatically defaulting to the local URL. The aim is to perform the merging process on the production serverrather than on the research server

Persisting configuration data for each de-duplication report The report metadata is persisted whenever a new report is generated,information such as the user that ran the report, a timestamp for the report, elapsed time for each sub-step of the analysis, and which strategies were used should be associated with the de-duplication report. :

The available reports screen

Improvised available report screen

The report metadata is stored in a table

The metadata can be view by clicking the View Statistics link on the create report page

Enhancing the Matching algorithm by matching the Transposed Fields Patients occasionally interchange or transpose their three names (Given Name, Middle Name, and Family Name). A process is created where transposed fields can be compared and used for matching. On the UI,while creating a strategy the fields that are needed to be interchanged should be identified

The fields that are interchangeable necessarily have to be “Should match” fields. As an example,if the given name middle name and family name have to be matched even if they are transposed then all the three fields should be marked as “should match” The process includes concatenating the interchangeable fields and applying the Longest Common Subsequence (LCS) Comparator to the Concatenation field. If the LCS score is greater than 0.85, consider the concatenated fields as a matching.

If LCS("SMITHJOHNALLEN", "ALLENSMITHJOHN") > 0.85, then consider those fields as agreeing. When we have interchangeable fields, each individual field contributes a positive score ( if it agrees) and each individual field still can contribute a negative score ( if it disagrees) So if LCS is above the score threshold, then the agreement scores for each of the individual fields are added to the overall composite score. If the LCS does not pass the score threshold, then the record pair should be scored as it currently is

Storing the concatenated values in the database

Transposed fields