Duplicates from loading Ubedhe data and OpenMRS data
Because we have only 4,040 OpenMRS records, they likely will not meaningfully inform the matching algorithm configuration, and we will be acquiring OpenMRS registration data more comprehensively after go-live as a feature of the system.
So, here is my question- is it not easiest to find the matches between the OpenMRS and Ubudehe data- and delete those records from the Ubudehe before loading? If we have multiple registration domains, then no records are deleted: 1 for Ubedehe domain, 1 for OpenMRS domain
This can work. @Liz on the last call, I thought I heard you say that only a single OpenMRS site has patient data loaded into OpenMRS. So I asked Rhonwyn and Emmanuel to check this and below is a summary of the information gathered so far which shows that other sites do already have patient data loaded into OpenMRS. So if we go with this approach, does this mean we will have to run the matching algorithm for each sites database (site database (list of patients) against Ubudehe) and provide a filtered Ubudehe data-set to be loaded into that particular site.
@Shaun - here are some clarifying questions to figure out the best way forward
1. We will need to provide you with a list of patients and their demographics from each sites database. Can you define the minimum set of attributes to be included in this export. Theoretically we could import all records from OpenMRS. The lower quality registrations (e.g. those with inaccurate or incomplete fields) would simply never be matched moving forward.
2. When will you be able to begin this process of filtering the Ubudehe data-set for each site and how long will it take. I assume by "filtering the Ubedehe data set for each site" you mean creating a subset of the Ubedehe data set for each clinic site? My understanding is that, based on the district that the clinic resides in, we will load each clinic's OPenMRS instance with the district records specific to that district.
SITE |
DATA MANAGER |
TELEPHONE |
# hiv patient |
|
Gishali Healtyh Centre |
Murebwayire Jeanne |
788457460 |
46 |
(just started last month) |
Avega Health Centre |
Mukadusenge Alexianne |
783477177 |
270 |
|
Rubona health Centre |
Ntawukuriryayo Jean Baptiste (IT Mgr) |
788690082 |
378 |
|
Rwamagana Health Centre |
Munyengabe Jean Baptiste |
788443998 |
217 |
|
Murambi Health Centre |
Nshimiyimana Ellam |
783640270 |
|
|
Karenge Health Centre |
Rugoro Emmanuel (Head) |
788864190 |
|
|
Nzige Health Centre |
Musabese Janviere |
785286728 |
407 |
|
Muyumbu Health Centre |
Musoni Narcisse (IT Mgr) |
728522409 |
|
|
Nyagasambu Health Centre |
Nkundabatware Jean Damascene |
788407931 |
|
|
Musha Health Centre |
MAHINGA Prosper (Head) |
783254688 |
265 |
|
Ruhunda Health Centre |
KABERUKA Gerard (Head) |
785663232 |
|
|
Munyaga Health Centre |
Sr NYIRAHABIMANA Marie Vestine (Head) |
788215232 |
199 |
|
Rwamagana Hospital |
Muhayimana Mathilde |
788624834 |
3257 |
district hospital |
Does that not significantly reduce the work of creating the script to load OpenMRS?
The approach of not performing matching during the load reduces the complexity of the load scripts, but this will still take time to properly develop and test. <= 2 weeks
We can ALSO merge records manually if needed – but if we clean up the obvious ones first- those numbers should be small.
- I agree with Paul's responses to how OpenMRS could manage duplicates if we were to load the Ubudehe data into OpenMRS without any matching when we load.
- Your suggestion to Shaun regarding pre-processing the Ubudehe data source loaded into each OpenMRS Implementation database can work.
Wayne