Request for Patient Data Reset Script in OpenMRS

Development
,
1

Question

Has anyone developed or used a script to reset patient data in OpenMRS while preserving metadata? If so, could you share your solution or experience here?

Background

  • Our previous approach: install fresh OpenMRS, load current metadata, create database dump
  • Issue: This approach fails when metadata changes occur, resulting in loss of crucial data

Similar Solutions

  • Bahmni has a utility script for a similar purpose: clear_openmrs.sql
  • Not sure if anyone in the community has experience with this script

cc @dkayiwa @ibacher @achachiez @corneliouzbett @samuel34 @mogoodrich @michaelbontyes @pirupius @vasharma05 @slubwama @aojwang @ssmusoke

1 Like
3

Why not just build on the Bahmni script?

4

If there is no other existing script/approach then that’s what we can do. What do you think @michaelbontyes

5

@jnsereko Just trying to understand what kind of data you would like to carry along. and also what does cleaning mean.

6

Content or metadata would be persisted eg roles, privileges, encounter types, person attribute types, identifier types, concepts etc.

Removing patient related data like patients, observations, encounters, appointments, etc

We had improved the bahmni script to come up with something like this

7

So your end goal is an empty implementation initial DB??

8

Yes @slubwama

9

Have you explored building a distro that is self reliant with ability to create an initial DB by its self at anyone moment. Other than creating a query that deletes data from the a db ??

10

Yes, we previously attempted that approach, but found it wasn’t sustainable long-term. With constantly updated content, we risked reproducing previous bugs, while recreating an initial dump each time was time consuming

11

In actual principle It should be the most Ideal but if this is failing its important to invest the time to understand where these potential bugs may come in from and equally close them out. I do not recommend the approach of cleaning data. you might forget something which might get you messed up, secondly incase of any table changes in the core or any modules your script will be outdated and you will need to start allover again to debug.

My recommendation. (When you completely fail)

  1. Generate a stable DB as the iniz DB.
  2. Add that to your distribution as a DB that gets initialised on iniz
  3. You can equally share that when starting a new site at all time.
3 Likes
12

With constantly updated content, we risked reproducing previous bugs

Any “data cleaning” script would run into similar issues, between the need to figure out dependency order and ensure that it covered all relevant tables from all relevant modules.

On the other hand, automatically generating a “clean” version of a DB is a task that’s imminently suitable to be done via CI. All you would need is a CI script that spins up a copy of your distro and then grab a copy (via mysqldump or similar) of the database and maybe the checksums from Iniz, which can then be used in creating new instances. Doing it in CI means you can trigger the job to run whenever your metadata is updated, which should help alleviate the issues with “constantly updated content” and, since it’s automated, you should be able to build a CD process that only deploys once the content is updated and the updated script is generated.

3 Likes