Code Progress with Director for the Merge UI

At the begin of the week, I tested my Previous implementation “Search by Error Registration by Error type” on OpenMRS version 1.11.5. So I just step up my testing environment with OpenMRS core version 1.11.5 on my machine with my mentor help. After doing that I just configured Muzima core module with muzima forms, in that configurations, I had face unable to upload Muzima forms due to some bug on the current module. Finally, I upload a form with the guide of my mentor. I just note down what are the steps I did for the setup testing/development environment, I think it would help to the new developers who are the developers engaged with muzima core development in the future. 🙂

After setting up the environment I tested my implementation for my mentor’s DB dump. As my mentor said there was duplication in my implementation. So I tried hard to fixed this issue. And make some changes as the guide my mentor. Even that not fixed, So I just move my next ticket. 😦

My next implementation is “Adding button for the Error Registrations as Direct to the Merge UI” from this implementation user can move from error UI into merge UI for merging conflicted patient registration or create another new patient registration. This merge button if Patient Error registration error occurred by merge conflicted. Otherwise, there is no merge button on the error UI. It will prevent confused user when it appearing for other data. 🙂 When I implementing those feature  I used Angularjs technology as my mentor advice. When starting work with Angularjs, It little bit hard to work on it, because this is the first time I work with Angularjs. However, Angularjs has several inbuilt advantages. When the registration error happened by a patient with similar characteristics user can see the merge button as shown on the figure.

After finishing that implementation, I start my implementation on another ticket which is Initial Patient Merge UI. Next week I’ll work on this issue. There are three major implementations,

• Retrieve Successfully Registered Patient registration from OpenMRS table (by considering merge conflict error).
• Data shows on two different UI.
• Adding functionality for UI.

Pull request for “Adding button for the Error Registrations as Direct to the Merge UI“, https://github.com/muzima/openmrs-module-muzimacore/pull/34

Error Search and Search API implementation

In this week I worked hard on the pull request of the search error function. Actually, In this week I just plant to just complete this improvement and go to the next step of the development. However, I have to work more on the issue, due to it give some issues. After getting review by my mentor I just try to getting Message Content from the Another data table which stores the messages for the error register.

I had busy with some changing on the implementation and make few commits on the pull request. Before that commit, I spend more time to test those search enhancement for the different searching parameters. It’s some time-consuming process and I want to find an easy way to testing.

https://github.com/muzima/openmrs-module-muzimacore/pull/29

Next tasks

• In the next step, I will work on the API implementation of the Patient Merge when conflict happened when patient registration.
• Implement UI for the opening UI for the merging task.

GSoC code progress with Hibernate

In this week I worked with Hibernate. Criteria API is one of advantage API for my current work on GSoC.

Hibernate – Criteria

Hibernate provides alternate ways of manipulating objects and in turn data available in RDBMS tables. One of the methods is Criteria API, which allows you to build up a criteria query object programmatically where you can apply filtration rules and logical conditions.

The Hibernate Session interface provides createCriteria() method, which can be used to create a Criteria object that returns instances of the persistence object’s class when your application executes a criteria query. [1]

I were implemented ORM in hibrenate for the patient error registrations by using method of the Criteria api. “.eq” will give error registrations with the same ID. “.in” will give multiple exact matches of the error registrations and it’s messages.

public List<ErrorData> getPagedErrorData(final String search, final Integer pageNumber, final Integer pageSize) {
    List<ErrorData> errorMessages = errorMessageData(final String search, final Integer pageNumber, final Integer pageSize)
    // Integer[] errorMessageIds = new Integer[]{};
    ArrayList<Integer> errorMessageIds = new ArrayList<>();
    for(ErrorMessage errorMessage : errorMessages){
        if (StringUtils.contains(errorMessage.getMessage(), search)){
                errorMessageIds.add(errorMessage.getId());
            }
    }
    if (errorMessageIds.size() > 0){
        return errorDataDao.getPagedData(search, pageNumber, pageSize, (Integer[]) errorMessageIds.toArray());
    }
    return errorDataDao.getPagedData(search, pageNumber, pageSize);
}

Next week I will start our merge patient registration UI for the muzima core module and It’s API.

[1] https://www.tutorialspoint.com/hibernate/hibernate_criteria_queries.htm

First Evaluation

This is the final week of the GSoC first phase. Every students and mentors were completed their evaluation in the week. At the end of week, I had completed my first evaluation of the GSoC project and got a email about my first evaluation completed. I was really happy about that. I would like to thank my mentors and Their valuable feedback for me.

In this week I were busy on the Muzima api development for the enhance searching function from the database access by the hibrenate framework.

Go forward with Coding

At the begin, I have faced a problem with creating a data set which is generated Error when creating a registration on the mUzmia module. After discussed with my mentor we tried to create a new dataset from the data registration with the help of the android simulation, app of the mUzima.

There was not any cohort report to download when Configuring the simulated mobile app. Therefore, I just configure OpenMRS instance to cohort report. Even I tried to configure cohort report It gives null point exception on spring framework when I creating cohort report. With the help of my mentor, I follow the steps to create cohort and getting hands dirty with those configurations. Muzima registration form can be downloaded from the https://github.com/muzima/muzima-form repository.

After creating a registration, from the mUzima mobile application and sent it to the Queue data of the OpenMRS instance to process and insert into the registration. It fails every time with the same error. The error was registration was failed on mod 30 validation. Then I had to read more about Luhn algorithm and after getting knowledge about it. I manage issue on the registration. At the final able to create a relevant dataset with errors as I expected.

Especially I would like to thanks, my mentors. Thanks, both of you for the great help

Unxpected experience during Coding Period

This is the third week of the Google Summer of Code 2018 coding period. Since the previous week, I had face problem with my laptop failure. I had to apologize my mentors for that situation. After doing hard try with my laptop, I had to change my laptop during this week due to wasn’t able fixed it even attempt a lot of stuff on it.

After replaced the laptop, I had to set up the whole environment on my another laptop. After that, I looked into the creating new sample data into the database to start my next implementation and I had tried it and I will work on it during next week.

I would like to thank my mentors, They were really kindness within that much hard situation and giving help me during those periods.

Improve mUzima core, Search Patient Registration Errors by Error Attributes

At the begin of the week, I continued final evaluation of the mockups with the Simon and Ada. We continued UI evaluation meeting in three major areas. We discussed UI implementation within three main ideas,

• The potential merges should be from mUzima Registration pairs (not through OpenMRS Merge Patient Search) – Our final decision was this implementation should not go through OpenMRS Merge Patient Search, It will design new interface as part of the project. It will search Data from the mUzima Registrations Databases, EMR Database and Queue Database. We will develope this project based on the major two types of users. Firts type of user will be use this merging system to merge whatever patient registration data which conflicted on their mUzima registration. Second type of user will be use this merging system for merge known registration by typing, Name, Gender, Birthdate, etc. The first user can use UI “Merge Patient Search – by Select Attribute” as on figure 1.1 and Second type user can use “Merge Patient Search – By Type” as on figure 1.2.

figure 1.1 Merge Patient Search – By Select Attribute

figure 1.2 Merge Patient Search – By Type

• Two buttons (Merge Queue into EMR and Create New Patient with Queue) will be move to the top of the page instead keep on the foot – As aim of getting more comfortable for the user and getting speed of  the merge process or go to the create new patient registration without loading entier dataset, we decided to change those buttons position.

figure 1.3 Merging Window – Initial – Short View with changed buttons

• Store the additional metadata in the mUzima Registration pairs table – The project will create new metadata about merging like encounter date, date synced to server, date the pairs resolved, provider, location, resolved by, resolution (merged or created), etc. Furthur implementation, evaluationr can be use those metadata for make evaluations about merging duties and accurarcy of the merge.

As first step of the project implemention, Simon gave advice to current module openmrs-module-muzimacore module. There are three separate sub modules,

• API
• JavaRosa
• Omod

With the guidance of my mentors I have start loking integrate my implementation into currnet mUzima core module. As first step of the project, My mentors gave idea about searching enhancement of the current error search of the module. From that enhancement user can search error registration of the mUzima patinet registration can be search by typing error type. This implementation will be finish within next week.