Merge Patient data from Multiple Installations Project

Tags: #<Tag:0x00007f88c987c180>

(Stephen Senkomago Musoke) #21

@samuel34 What stops you from dumping the sync data into a file and uploading it into another server?

(Samuel Male) #22

Obviously nothing stops me :smile: but I was confused on why we should depend on sync :frowning:

(Stephen Senkomago Musoke) #23

@samuel34 What options did you envisage other than sync?

(Tomasz Mueller) #24

Hi, @samuel34

I can see nothing wrong in your config, but I suspect that your local instance may not be accessible from outside and that’s why sync4 can’t access it as well.

Regards, Tomasz

(Samuel Male) #25

I think I was getting it wrongly.
Since its in the same circles, I think its sync.

(Stephen Senkomago Musoke) #26

@dkayiwa @samuel34 Just to confirm that we are on the same page… Below is my understanding.

  1. The purpose of this project is to be able to merge patient data from multiple installations

  2. The default way is to extract the patient information from each of the different tables and package it in a way that can be imported into another instance

  3. However with sync2 in progress, there is a possibility to leverage this. How:

  • Sync currently exposes patients, observations etc into a FHIR/REST interface, but underneath all that the data is stored in tables (in case of no connection)
  • The idea in this case is to export the data from the sync tables and import it into another instance…
  • That way the project is dependent on the sync structure, but extends it in a way that was not planned earlier

@tmueller Please do add your thoughts too - I may be totally off track here

(Samuel Male) #27

I think I now understand and agree with that design.

(Mark Goodrich) #28

Sorry, just jumped in here with very little context, but it does sound like if this project could leverage sync like @ssmusoke suggests, that would be great… I would definitely get the thoughts of the team working on Sync about this use case.

Take care, Mark

(Daniel Kayiwa) #29

@samuel34 @ssmusoke is your primary mentor and hence has the final say in regards to the direction of this project. :smile:

(Stephen Senkomago Musoke) #30

@dkayiwa I am happy to be swayed … in a direction that is best for OpenMRS and the overall implementation community a sanity check for my tunnel vision…

(Samuel Male) #31

Hi all!
I’m still getting myself familiar of how sync2 works by looking directly at the code base.
I’m atleast aware that sync uses the atomfeed module for getting aware of events in the entire platform ie. New Patient update. But I was curious of how it happens(is it through some AOP logic!). Looking at the codebase, I hit upon this AtomFeedClient#process() method delegated here. Is that the method that checks the entire OpenMRS context for new events(Atom feeds) ? If not, could you try explain this for me or point me to related resources!
cc: @tmueller , @ssmusoke , @mogoodrich and Others.

(Tomasz Mueller) #32


but the methods that trigger the whole synchronization process are:

LocalFeedWorker#process and ParentFeedWorker#process

Regards, Tomasz

(Samuel Male) #33

Hi @ssmusoke!
I think I should get started with “real” work on this today.

How to get started

I thought of starting with implementing service layers that retrieve the sync-able data from the entire OpenMRS context first. Could you come in here now, help me get moving by giving me directives in form of TODOs? I feel its the best way we can get moving :slight_smile:

(Samuel Male) #34

Hi !
As a starting point, I have so far focused on a Patient as a Resource. I made a PatientResourceService, however, this doesn’t have a DAO. I’m thinking of just it just delegating the core PatientService here. However, running this test case fails with the error below.

ERROR - Context.getServiceContext(258) |2018-05-25 04:07:20,859| serviceContext is null. Creating new ServiceContext()

Could I be missing something?
cc: @ssmusoke , @dkayiwa

(Stephen Senkomago Musoke) #35

@samuel34 What task are you working on? What are you trying to achieve?

(Samuel Male) #36

Looking at a Patient as a Resource, I’m trying to implement some service that will have to persist the ‘merged/uploaded’ Patient into the DB.

(Samuel Male) #37

At the same time retrieve a batch of data from the DM for exportation

(Samuel Male) #38

BTW @ssmusoke , does this use case make any sense? If so, could the problem be with my moduleApplicationContext.xml?

(Samuel Male) #39

The problem was solved :wink:

But just to ask a little about openmrs-platform .
Should snapshot 1.0.0 depend on platform 1.11.6 as it is by default? Or!
How do we basically handle platform compatibility?
cc: @ssmusoke, @dkayiwa

(Samuel Male) #40

I’m gonna depend on platform 2.0.5