Embed Size (px)
Citation preview
GOOGLE SUMMER OF CODE
Enhancing the OpenMRSPatient Matching Module
Demo
Mentored ByShaun 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
