GSoC 2018 - Merge Patient data from Multiple Installations

I would like to clarify that Merge Patient data from Multiple Installations is led by @ssmusoke and @dkayiwa. They can provide more information on that project.

Patient Merge Enhancement is a project that is related to mUzima and is led by @mssavai and me. Ours is to create a UI on the OpenMRS side to allow data managers to review and resolve (either by creating a new patient record or merge existing patient record) within the same EMR which is totally different from Merge Patient data from Multiple Installations.

he @dkayiwa

I have gone through in this project past days and I have to clarify following facts

  1. should we create a new module for this project
  2. What we have to implement are java classes that get patient data from multiple places and merge the into one master database and build a api(think basically a gui) for return data am I right??
  3. should we use sync module for this project

your help and guidance is much appreciated

thank you

  1. Yes a new module needs to be created.

  2. Once data is merged into one database, that should be all.

  3. This will not use the sync module

1 Like

@dkayiwa is that all should we know about this project? If there are any information that we should know about this project can you tell us because I am going to start to write my proposal. your guidance is much appreciated

thank you

That is all the scope for GSoC.

Hi all,

I am Milan, a final year undergraduate at the University of Moratuwa. I am contributing with OpenMRS since 2015 and worked with several tasks and issues. I am happy to say, I have completed my first GSoC project with OpenMRS (Support Laboratory Data Exchange with FHIR) at 2015. I would like to give my contribution to work on this project this year also.

Thanks, Milan

Hi, I have some clarification about the module. We can implement modules are as follows,

  1. Implement two modules Master module: Only install on master(father) database server Child module: Only install on child database server
  2. Implement slave and master functions within the same module. Implement both functions within the same module and I can be deployed on every database server.

@dkayiwa @ssmusoke could I please clarify what is the best way of implementing modules?

Hi @milan

A module will be developed and expected to cover the whole scope of the expected objectives for this project.
Best Regards :slight_smile:

Hi @samuel34, Thanks for the quick reply!.

As @dkayiwa mentioned above, all the data from slave OpenMRS instance need to be merge and sync patients, encounters, and observations from multiple instances into a the given master OpenMRS instance for Analysis and Reporting (may store in read-only form).

As I can understand, there’s two type of functionalities in the module.

  1. Client instance running on the Slave nodes (OpenMRS instances)

These clients will use by the master to retrieved patients, encounters, and observations of particular instance. As it’s requested in the project idea, client will encrypt the data while transmission.

  1. Master instance running on a given Master node (save data as read-only, used reporting and analysis purposes)

This instance of master will retrieve data from client nodes, and use a set of rules to merge the available data of patients, encounters, and observations.

@dkayiwa, @ssmusoke correct me if I’m wrong about getting the problem.


@samuel34, As we can see above in order to implement this feature, I think we need above functionalities and that kind of architecture. So what I tried to ask was, in that case we can have them as separate modules Or merge as a single module which has both functionalities?

Event we implement this as a single module, we have to select on as the master node which will save the merged data. In that case, I’m asking what’s the preferred way to do it?

I understand what your trying to insinuate @milan . All the features you mention are right and are part of the project objectives. But development should and can possibly be in a single module. The same module will be in position to export( with encryption possibilities from child node) and also import (merge the data to master DB) data.

He asked the above question . And he was given the reply below :slight_smile:

But all I think, all functionalities should be bundled in a single module.

Hi @samuel34,

Thank for confirming that, I have got the objectives of the project right, and your support regarding understanding the project. :grinning:

Yes, I have look into those answers. But is there any reason to have it as a single module ? (e.g. easy installation for the user etc…).

At the same time, I’m wondering what would be the advantage if we implement those two objectives as two modules s.t. merge_module-server, and merge_module-client. As I can see,

  1. The Architecture is more modularized and separate of concerns

    When it’s going to merge data from different client/slave nodes in to a server/master node, it follows the architecture of client-server or master-slave. Since these two are focus on two different concerns, it’s better to have them as two modules.

    As an example, if we consider Apache Thrift, in it’s home page’s example, you can see that, for a given Thrift definition file, it’s creating two different files s.t. Python Client and Java Server. So, it has modularize the two functions into two separate files. Otherwise, if they create each as single file, then the output will be Python File and Java File.

    For another example of Java, please look into this Java Apache Thrift.

  2. Easy to use by end user

    In the instruction of using these modules, we can say to user like,

    " Install the merge_module-client on OpenMRS instances which data need to be push into master server, and install merge_module-server on the OpenMRS instance that store the data merged from client nodes. "

    If it’s a single, module, user has to configure the modules on client OpenMRS instances as clients, and need to configure the module on the master OpenMRS instance as master.

  3. Independent of upgrade for decoupled modules

    Since the functionalities are decoupled, in such a case of upgrade on module can be done independently. Let say there’s an upgrade on merge_module-server. In that case, we don’t need to update the client nodes.

These are some thoughts on advantages of having two modules. Anyway that’s depending on user preference. What do you think ? any suggestions ?

Hi @ssmusoke, @dkayiwa,

I have sent my draft proposal to Merge Patient data for Multiple Installations. We can use one encryption from both HTTPS and SSH. :smiley:

Could you please give your valuable feedback!

Thanks and Regards, Milan

Thank you very much @ssmusoke and @dkayiwa for entrusting me to work on this project.
Just looking forward to start work on this :slight_smile:

2 Likes

Congratulations @samuel34 ! :confetti_ball::tada::confetti_ball::tada::smiley:

Thanks bro. Will welcome your ideas for making this implementations better :smile:

2 Likes

Congratulation :smiley:

1 Like