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.

Getting Started with Patient Merge Enhancement

As the first step of the GSoC project – Merge Patient Enhancement, Since “community bonding period”, I had around five discussions how to implement this project with Simon Savai and Ada Yeung. At the begin of the bonding period, Simon and Ada were tried to give an understanding of the implementation. How it uses the current module, how it’s working, what’s the purpose of the project implementation.

After having three meeting with my mentors, I started designing my UI mockups as matching project requirements. As my understanding, I have developed UI mockups first phase. However, After getting valuable feedback from the mentors, We decided those UI should have a redesign for matching easier way.

In the GSoC project implementation, there are major three components,

• Merge Patient Registration Data
•  Create New Patient Registration Data
• Enhance Error resolution UI to make it easy for resolving other types of errors encountered during processing of data coming from mobile devices.

Merge Patient Registration Data Mock-ups

In the merge, patient registration data UI give those functionalities for the user,

• Use The user can select “Short View” or “Extend View”, If the user selects “Short View”, the user can only see conflicted data attributes and new attributes with red and orange colors. “Extend View”, the user can see all attributes of the Patient Registration data from EMR DB and Patient Registration data from mUzima mobile side by side.
•   The user can start edit by click on the locked padlock. If padlock unlock user can start change attributes of the registrations.
•  The user has two ways to edit Patient Registrations. 1) The user can edit Patient Registration by type on the text area of each attribute, or 2) User can select attributes by click on the checkbox. As an additional feature, the user can merge all conflicting data into one registration from another registration by click on the relevant “Select All” checkbox.
•  From the different colored UI, User can clear understand edited, conflicted, conflicted after edited, identically same after the edit.
• Merging Alerts avoid user mistakes clicks.

Create New Patient Registration Data Mock-ups

•  The user can start edit by click on the locked padlock (If padlock unlocked user can start change attributes of the New Registration)
• From the different green color indicates edited attributes of the Patient Registration.
•   The user can continue New Patient Registration with newly edited attributes or old patient registration data which came from the mobile application.
• Alerts avoid user mistakes clicks and give an understanding of the changes on registrations.

With the aim of provides more idea about UI, I have created a demo video for the UI mock-ups.

mUzima – Patient Merge Enhancment Mock-up Demo

TODO List:

• How to incorporate the new UI.
• Understand current uzima core module.
• Divide workload into subtask and create Tickets.

 

GSOC 2018 with OpenMRS and mUzima

                       

I’m really proud getting selected as a student for Google Summer of Code 2018. This is my second time got select GSoC with OpenMRS. This time I will work with both OpenMRS organization and mUzima organization. This will be a really impressive experience for me in my life.

My experience with OpenMRS was started at 2015, When I was beginning of my opensource software developer carrier path, I heard about OpenMRS organization from my brother. Since knowing about the organization, I started working with the community, When my first GSoC project discussion period at 2015, Sashrika gave a lot of motivations and guidelines to contribute to the organization. I would like to give my special thanks for “Sashrika Waidyarathna“, he is my turning point on the OpenMRS. Since starting my project at OpenMRS, Harsha Kumara helped me a lot to get through some difficult tasks. Thank you very much, Harsha!. Also, I like to thanks to Judy Gichoya, Suranga Kasthurirathne, and Daniel Kayiwa! and every other member of the organizations to success my previous GSoC project and other works!

At the beginning of the GSoC 2018 project, I have worked on both Apache and OpenMRS project to getting selected GSoC project. In the Apache organization, I have prepared my works on Tomcat project. It’s project about creating AJP client and Command line tool. I would like to thanks for having a nice interview with Mark Thomas. At the GSoC 2018 project discussion period I worked with “Merge Patient data from Multiple Installations” project. However, I think Samuel Male is the right person for that GSoC project. I would like to wish for him and other GSoC students!

Finally, I have selected “Patient Merge Enhancement” project. Thanks, very much Daniel Futerman, Simon Savai, and Ada Yeung to getting selected me for this project. Thank you very much OpenMRS for selecting me as a student!.

Mapping ImagingStudy Resource Attributes to OpenMRS

We are currently developing Radiology Handler. By the time, we got into implementing ImagingStudy FHIR resource. It’s a FHIR resource which is referenced by DiragnosticReport FHIR resource. So, we had to came up with a mapping to store those data in a good way using OpenMRS API.

ImagingStudy (Obs) 0..*
  - Patient : Person
  - uid : uuid
  - accession : AccessionNumber
  - numberOfSeries : Get Size of Series of Obs
  - numberOfInstance : ? Answer to the concept
  - clinicalInformation : comment
  |
  |--> Series (Obs) 0..*
         - modality : ?
         - uid : uuid
         - numberOfInstances: ? Answer ot the concept
         - url : comment
          |
          |--> Instance (Obs) 0..*
                 - number : ?
                 - uid: uuid
                 - sopclass : ?
                 - type : ?
                 - title : ?
                 - content : Complex Obs

But Judy (my mentor) suggested following mapping.

ImagingStudy
Started – saved as a date time concept (162830)
Patient – Patient object in openmrs
Uid – is numeric for identifier for the study –ideally should be unique but not sure if this is the practical case
Accession – ID number saved as obs
Order – should be saved under the OrderObject in openmrs
ModalityList – Text object in obs
Referrer – obs free text
Availability – coded concept with options of ONLINE |OFFLINE|NEARLINE and UNAVAILABLE – really not important to save this
url – saved as text in obs
numberofseries – numeric obs saved
numberofinstances – numeric obs save
clinicalinformation – free text obs save
procedure – saved as obs
interpreter – free text obs
descrition – NO NEED TO SAVE THIS – but can be free text obs
series (these will be likely repeated as there can be more than one series --- so use the numberofseries to add these)- Each series should be an obs group .. then all above obs should be grouped together under a CONVENIENT SET
-       number :– obs  numeric
-       modality – Text obs
-       uid - Unique ID for series
-       description – obs text
-       numberofInstances – obs numeric
-       availability – No need to save this but t would be OBS
-       url – obs text
-       bodysite – obs
-       laterality – obs
-       dateTime – obs datetime
        -       instance   > obs for uid,sopclass,type,title,content

Also she suggested flowing work flow as well;

1. Confirming that the schema of the report you receive is valid DSTU2 report
2. Saving the data as a nested OBS using the relevant concept
3. Suranga I know you never wanted anything to be input but don’t you think we should have had global properties that one can update the concept (saved as a convenient set ) they want to use for the data
4. Thereafter we could check whats present in the DB and you can save it – Not sure how we delt with non existing concepts for importing lab