Monday, June 25, 2018

Week 6

Hi folks,

Like I said in the preceding week my machine was down. Actually I purchased another machine. I'm struggling with my dev environment setup and adopting to a new platform that's OSx.

Today I had a physical meetup with my mentor( Senkomago Stephen) at Kololo Uganda. We had lunch together, he advised  me on better/recommended development practices as required by GSoC. I have loved this guy, he is very motivating and resourceful.

Project Progress

To be honest, for this week I have done less as expected by last week's objectives. The module currently downloads/exports data but I started with the Patient domain as a Resource. I also tried to implement the import part of it. Just like you know in development, we always hit upon bugs. There is this logical bug that took me almost 2 days to hunt down and understand. I use the gson library for serialization and de-serialization of data. Serialization is quite straight obvious. I love all the magic with this library. But as data goes complex, de-serialization is quite complicated That when your dealing with generic Classes/domains.
  
public interface Resource {
    // Some logic goes here
}

public class Patient implements Resource {
    //Patient Resource logic
}

public class Location implements Resource {
    //Location Resource logic
}

@Test
public void dummyTest() {
Patient patient = new Patient();
Location location = new Location();

//Add the Resources to a Collection
HashMap resourceMap = new HashMap();
resourceMap.add("Patient", patient);
resourceMap.add("Location", location);

//Serialize
String data = gson.toJson(resourceMap); // Works fine

//deserialize
HashMap deserializedObj = gson.fromJson(data, HashMap.class);

//Attempt getting a Patient object.
Object patientResource = deserializedObj.get("Patient");
Patient patient = (Patient) patientResource; //Ooopppss, this throws an //Exception."ClassCastException : gson.internal.LinkedTreeMap cannot be cast to Patient.class"

}

That's basically my current blocker. I googled around it and I'm planning to implement manual handlers. I you have a better and quick work around, feel free comment it here or get me on talk and ping me (@samuel34) . We could resolve this an the module would start working at all ends. Then I work on  the Configuration part of it.

Regards,

Samuel Male.

Monday, June 18, 2018

Week 5

Hi folks,

For this week, I got number of blockers, my machine was down and we had power shortage in my home area. But however, I tried to nab a few of this week's objectives(check down here).

What the module can currently do.

Currently, the module can download or export Patient data in an encrypted format but depending on default configurations.

Steps followed
  • Build the module with "mvn install" (src :- mergepatientdata);
  • Install the module on Reff App 2.x;
  • Move to the module dashboard;
  • Click the export button;
    • This will trigger the whole process, collects all Patient data, encrypts it and a download is automatically triggered. 
  • NB:- Currectly the module supports only Patient and Location as a Resource. I think next week I will add support for other Resources.
More about the dev work this week
  • I looked through my codebase as a module, did some code cleaning and Implemented logging for debugging purposes. 
  • I refactored my Resource Services to a better implementation. 
  • I think as for now I finished with the export logic. Exporting works good, However I haven't tested it with a big dataset ☹️.
  • Written lots of lines of code and Utility methods.
  • And by the way, I successfully completed my first evaluation with Google and Passed 😃
Next week( week 6 ) Expectations

   NB:- I have kept pushing objectives from one week to another which I want to stop this week ☺️
  • I expect to get done with the importing/merging logic from the UI point of view.
    • Need to add a dialog box where one can drag and drop or browse to the ".mpd" file
    • Test whether the entire API can really merge MPD data.
  • Need to also work on the Configuration support from the UI.
    • I think I will add another GSP page that will contain the congs
    • I think I will use the gridJs Library at the front end for indexing, paging, validation etc..
If it doesn't challenge me, then I won't help me. I think I will be strong enough to stand all this. 

Regards,

Samuel Male

Sunday, June 10, 2018

Week 4

Hi all,

Release tasks.

Looking at the lately anticipated tentative release date, I couldn't proceed with the release process when most of the tickets in the Road Map in the batch aren't fixed. Lots of the time for this week was invested in release tasks. We were very ambitious that by this week, Platform 2.2 could released!

Merge Patient Data Module

Basing from the expected  objectives (check here down) for this week,
  •  I'm only and almost done with the Data exporting logic (I mean from the UI end).
  • I did some little work on Exception handling.
  • To be honest, not yet implemented logging in the entire API. I don't know why I consistently forget.
  • The UI 
    • I added a mergepatientdata app link on the OpenMRS Ref app homepage.
    • I created a mergepatientdata dash board. 
    • I'm still caught up assembling the rest of the API to actually get real life application. I started with the Export fuctionality.

Week 5 Expections

  • In week five, we need to do the first program evaluation with Google. So I'm gonna prepare myself. I anticipate doing it tommorow(Monday).
  • I need to make sure the module really gives a basic functionality. At least covering 58% of the project objectives. 
Thanks for keeping track and getting concerned with this project development.

Regards,

Samuel Male

Sunday, June 3, 2018

Week 3

More coding 

Hi,

Week three has been sort of challenging but lots of work has been done. More work has been done on the API of the module.

Work done.

I started work capitalizing on a Patient as the main Resource. Later, I will work on the rest of the Resources like Location, OBs etc.

MPDClient

Abstract
This client will abstract us from all the logic of exporting and importing data. It simply uses a given configuration, collect the required data from the database, serialize it to a file and then encrypt the file and possibly return an Audit message. It accomplishes all this by delegating the concerned Services that are currently partly implemented.

Week 4 Expectations

  • I expect to get done with the MPDClient(Both export and import logic). 
  • Need to work on Exception handling of the entire API.
  • Need to work on logging in the entire API.
  • Need to work on the UI.
    Implement a module page on the RefApp.

Extra Credit for Week 4

  • The module should be able to export and import data.
  • I'm gonna do some release task since I'm the OpenMRS Release Manager for platform 2.
Best Regards

Samuel Male

Friday, May 25, 2018

Week 2

Implementation phase

In the preceding week, I was basically trying to study  sync2, how it works and technically understanding its codebase. At the beginning of this week, I finalized on the study case, roughly made a design model for the  MergePatientData module. I also came up with a number of properties the project must portray ie:-
  • Serialisation and Encryption(Cryptography):
    Resource data will be serialized to JSON and stored in a file, which will be encrypted to a 'data.mpd' file. This can reversely be decrypted by the module. 
  • Persistance:
    The module should be in position to retrieve/save data from the OpenMRS context after-all the module merges data from one OpenMRS instance to another.
  • Auditing:
    Like in the sync2 module, Auditing is required to keep track of what really happened during a transfer process of data.
  • Configuration and Validation:
    We should configure which type of data is required to be merged.
Late this week, I started with the coding phase. I'm writing code basing on the design I came up with.

Work done so far.

  • Resource domain:
    I wrote code for almost all intended Resources .
  • Implemented a Service layer for some Resources like PatietResourceService .. However, more work is still required here.
  • I came up with a Repository(MergeAbleBatchRepo) that can store all Resources intended to be shared in a format that it could be easy to serialize. 
  • Lots work has been done. (check it out)
Best Regards 

Samuel Male

Tuesday, May 22, 2018

Week 1

Design phase 

Currently, sync2 depends on AtomFeed and Fhir/REST modules for synchronizing Patient and related metadata in Openmrs. As a matter of fact that the MergePatientData module will be an improvement of the sync module, I was advised that it should depend on the sync2 module. What basically fails sync2 is synchronizing data that existed before it was running in the OpenMRS context. Since we are depending on sync2, I spent the 1st week trying to gather information and looking at the entire codebase of sync and how it works. I came with a simple design. MergePatientData should checkout all existing synchronize-able data at a given Node(Could be child/parent). If sync is running, get data from sync tables, do a filtration of data and store it in a zip file with some encryption. The module should be able to download the zip file.
In a nutshell, I have encountered the following:
  • I started designing a workflow of how the project will be best implemented.
  • I closely studied and inspected the codebase of the sync module and left at an average understanding of the entire logic.
  • I created a skeleton(an initialization) of the module(mergepatientdata)

Blockers

I don't know whether its quite trivial but in the process of studying sync, All I know it uses AtomFeed module to update it of new events/feeds but I have failed to understand how :( . 

Sunday, May 13, 2018

Google Summer of Code with OpenMRS


Abstract

I received an email on April 23, it sounded like, “You got selected for Google Summer of Code 2018”. This made me pretty excited, called my friends and jazzed them about it. To my side it was a great achievement because it was my first time to apply and write a project proposal. However, according to the contributions that I made before in OpenMRS, I felt it/I was worth.

About The Project

I made two project proposals, one for Merge Patient Data From Multiple Installation  and the other for Location Based Access Control and I got selected for Merge Patient Data From Multiple Installation . Its about creating an OpenMRS module that adds the functionality of merging Patient and related Metadata from like a childNode database to the ParentNode or Central Database to OpenMRS. To some of the OpenMRS implementations,  there is no guarantee for a stable Internet connection for the "sync module" to work efficiently. 

I thank the OpenMRS community for entrusting me with this project. 

Happy coding and best regards.

Samuel Male.