Merge Patient data from Multiple Installations Project

gsoc2018
Tags: #<Tag:0x00007f88c93fa490>

(Stephen Senkomago Musoke) #62

@samuel34 and how does Sync 2 handle these use cases, my understanding is that we are meant to build on top of that module rather than go all the way from scratch?

Actually I would like to step back a bit, request that we leave coding and go back to planning. What are the gaps in Sync 2 that need to be addressed? Before we start wondering how to address the gaps technically

Take this example https://docs.google.com/document/d/1Ec-iSJyBKfCCHM9pbQN-wKxChUwz2-QU8Ve8zjygEbM/edit


(Samuel Male) #63

Now for sync2, they deal with only one Resource per operation. But for our Implementation, we deal with many.

Thats why we need these @ssmusoke


(Samuel Male) #64

Actually sync2 is awesome. It syncs Resources one at ago using Rest injections. The gaps could be

  • Syncing already existing data b4 sync2 was running.
  • Storing data somewhere for later use or data analysis.
  • Sync2 mob depencies. It depends on a quite a number of modules like Atom, FHIR, REST.

Merge Patient Data

  • Light weight
  • It can actually store data in a special file/format for future use
  • Currently its not depending on sync2

By the way, could you put me right in this @ssmusoke? Sync2 has a similar functionality with mergepatientdata module but they all achieve this in a very different way.


(Samuel Male) #65

But according to this, we were just supposed to refactor sync2 and add the merging Patient data functionality :slight_smile:


(Stephen Senkomago Musoke) #66

@samuel34 we need to fill the gap for this specific use cases so that you do not have to build everything from scratch


(Samuel Male) #67

Your right. Maybe its cause of my little understanding that I’m still blinded. I’m probably thinking within the box. But as for now, we caught up within the middle of the sea. So lets sway in the direction that we shall deliver at the end of the day. @ssmusoke


(Samuel Male) #68

Finished working on mapping concepts heading to mapping Obs

cc:@ssmusoke , @dkayiwa


(Samuel Male) #69

Week 10 update @ssmusoke


(Samuel Male) #70

@ssmusoke here is the dataset I would like to depend on


(Samuel Male) #71

@ssmusoke and @dkayiwa please read this update and save a soul :flushed:


(Daniel Kayiwa) #72

Did you get past this?


(Samuel Male) #73

I think am good, except with this limitation.


(Daniel Kayiwa) #74

One cannot tell so from that thread.


(Samuel Male) #75

Why @dkayiwa, did I present my issue poorly?


(Daniel Kayiwa) #76

“Overriding the default multipart file size” does not look like a problem any more.


(Samuel Male) #77

I said its a limitation :smile:


(Samuel Male) #78

Hey @ssmusoke, don’t you think we could swap the code to the Openmrs repo?

cc: @dkayiwa


(Daniel Kayiwa) #79

Since you are the only one working on it for now, it is fine keeping it in your public repository.


(Samuel Male) #80

The module is a state where its blocked by its dependencies.

Currently the module assumes that metadata like Concepts is similar in all instances. But to achieve this, we use tools like metadatasharing module. However, there is a know issue like duplicate Concepts that make exporting this data impossible. Good enough there is the Validation module in place, but this module is in a state that it still needs lots of work like adding support for platform 2.x. I started that here

cc: @ssmusoke, @dkayiwa


(Daniel Kayiwa) #81

I guess you eventually got over this. Not so?