Sunday, August 12, 2018

Merge Patient Data Project - GSoC FINAL REPORT

 Project : Merge Patient Data From Multiple Installations

Overview


There are individual installations where each installation is based at a facility (no guarantee of a consistent Internet connection), and is at the same version (OpenMRS, HTML forms, concepts and other metadata) - but there is a need to bring the patient records (or extracts) together to a central database. Site level users and metadata are not synced, neither are concepts and forms, as they are expected to be similar. The merged data (father instance) would be read-only, used reporting and analysis purposes.



Objectives

  • Merge Patients      --> Achieved
  • Merge Encounters --> Achieved
  • Merge Obs             --> Achieved

Extra Credit

  • Encrypt Data During Transfer --> Achieved 

Contributions

While working on this project, I developed a new Openmrs module.
If you wanna use this module, what you simply want is to build this project,  install your .OMOD on your running Openmrs instance and your set.


While working, I felt comfortable managing my progress using trello, I setup my dashboard before my second evaluation. I worked on the following cards.

Commits on the github project can be found here.

Resources 

This is a quick documentation on how to deploy the module with a steps and guidelines in a convention of 'How To' approach available here.

Talk Discussions

A more detailed Presentation





Experience


Well, this was my first time participating in GSoC, and it has been fun working with Openmrs. I have been able to learn lots of stuff, both programing stuff and communication skills. 

With communication I learnt working with a community which is typically OpenSource, which is made up by an ecosystem of volunteers. 

As for programming, I learned of new Libraries like js-grid. On working with js-grid, I ended up learning of Hibernate Pagination. I don't think I can exhaust all new stuff I hit upon while in the Epic. Just know, I learnt lot in, JS, Java, Spring . etc..

I thank Openmrs for participating in such a resourceful a program. This has given lots of confidence and insight to students aspiring to become advanced devs. Me as a First year student pursuing a Bachelor's of Info Systems, I have been greatly motivated that however much I was/am a newbie to everything, I can do some work. I thank my mentors,  Musoke Steve and Daniel Kayiwa. These guys were like parents to me. Due to my lil understanding of most aspects, these guys have always shown me the right path towards how to implement stuff and for long I looked at them like impossible ideals.    

Monday, August 6, 2018

Week 12

Hi all,

This is the last week of the Epic. If you missed last week's update, then you wanna look at it here.

Work done

  • The week started off swiftly with a quick fix of last week's Hibernate issue. Wycliff's advice worked like a charm.
  • After fixing this, I thought I was set to go after-all the module worked fine with my small Patient dataset. I then resorted to cleaning the codebase, implementing  most of the TODOs.
  • As the week was almost ending, I realized something was not fine. I asked the community to help me out test the module on a more realistic hospital dataset, this is when I realized we had Memory issues.
    • I had to increase my JVM heap space.
    • I had to optimize my codebase.
      • Looked for memory leaks. While doing this, I realized I was Merging Concepts which Daniel claimed shouldn't me Merged since they are expected to be similar. However, I'm still blocked from here.   

Challenges Encountered

I didn't expect to have such a blocker by this time, probably the mistake I made was to test out the module on a serious dataset late. Regardless of whether I'm getting nervous and hairy, we should come up with a fix for this.

Before, I used to test out the module on a server with around 60 Patients, and all was cool. Now with a server containing around 2000+ Patients, I hit upon Memory issues. This could be no worry, probably it could have a configurable workaround but its not the case. On exporting data, a file of around 1GB is produced. This far way large!

Looking at the codebase, I tried to hunt down memory leaks and found that Concepts are consuming more memory space than expected. This is fully addressed here.

Question

How can one identify General Concepts(eg- those already include in the Concept Dictionary) from Customized Concepts?

Regards,

Samuel Male