OpenMRS Planet

On October 15th, a day before the start of MobiCom, I will attend two hands-on tutorials hosted at the University of Utah about two emerging wireless technologies: PhantomNet, a platform with an end-to-end mobile testbed to experiment with new wireless technologies in the wild; and ParaDrop, a new edge computing platform that allows experimenters to deploy edge services in a WiFi Access Point.

I wrote a post on Medium about Bluetooth Low Energy security showing how Visible Light Communication can improve it.

Follow this link to read it on Medium.

About IoT security

Since the Internet of Things is still in the emerging phase, ensuring security and privacy is an important issue that must be addressed and resolved now.

The number of IoT and connected objects grows exponentially, so their security exploits will have more and more repercussions, making them very attractive for the hackers. Recent news and the growing IoT track at security conferences such as Blackhat, or Defcon perfectly illustrates this phenomenon.

About Bluetooth

In regards to Bluetooth, the SIG greatly enhanced the BLE security releasing at the end of 2014 the Bluetooth Core Specification 4.2. This update introduces LE Secure Connections pairing model with the numeric comparison method and the Elliptical Curve Hellman-Diffie (ECDH) algorithm for the key exchange.
LE Secure Connections fixes BLE 4.0–1 exploits unveiled in 2012 by Mike Ryan at TOORCON (video, crackle project).

Like LE Legacy pairing, LE Secure Connection defines several modes and levels of security (see section 5.2.4 Association Models of the Bluetooth Core Specification 4.2). Nonetheless, the available modes depend on the “IO Capabilities” — keyboard, display, button — that the pairing devices have.

The highest level of security, Numeric Comparison requires that both BLE devices have a keyboard and a display to confirm and compare a number displayed on both the peripheral and smartphone. An alternative and more convenient approach is using NFC.
By placing a smartphone close to the BLE (and NFC) peripheral, NFC will automatically initiate the BLE pairing and keys exchange mechanisms to establish an authenticated and encrypted communication channel.

However, the highly limited bill of material (BOM) cost or the PCB size prevents placing a screen, an interactive input, or an NFC antenna on such devices.
As a consequence, they provide a weak level of security whereas the attacks targeting such smart objects are rising.

To overcome this issue, we propose a technological solution based on Visible Light Communication (VLC) solution to assist the pairing and the secure connection setup between a BLE 4.2 peripheral and a smartphone.
This solution targets low-cost and size-constrained IoT devices that need to setup the Secure Connection with Numeric Comparison to provide a high level of security even on BLE devices that have neither input and display nor NFC.

Few words about Kiwink and VLC

Rtone has recently developed Kiwink®, a short range bidirectional Visible Light Communication system between an unmodified smartphone and a basic and cheap LED.
Kiwink® uses the camera and the flashlight of an Android or iOS smartphone and does not need hardware modification in the IoT peripheral since it works with any micro-controller.

In fact, bringing Visible Light Communication to your nRF52 BLE device just need a firmware update!

The communication range of such technology is tens of centimeters while the throughput is about 1kbps from the peripheral LED to the smartphone and 50bps from the smartphone to the peripheral LED.

Kiwink® is a trademark and its technology patented.

Improving BLE security with Kiwink and VLC

To solve the problem described above, we propose to take advantage of this VLC-based technology and ubiquitous LEDs, to provide a safe side channel to acknowledge or display a confirmation code and establish a BLE Secure Connection. We can also envisage to transmit a larger key if another Secure Connection mechanism is used.

This out of band key exchange is thus safer than NFC against passive eavesdropper since the light signal is highly directive and easy to obfuscate.

In practice, the connection establishment should work as follow:

1. The smartphone starts sending a BLE Secure Connection request to the peripheral
2. The smartphone and the peripheral proceeds to the Secure Connection Establishment with Numeric Comparison according to the BLE 4.2 standard
3. While the smartphone confirmation number appears on the smartphone screen, the peripheral LED starts lightning and transmits its number.
4. By placing its smartphone above its screen, the application decodes the signal and displays the peripheral number on the smartphone screen.
5. The user confirms that both codes are equal.
6. The smartphone sends the acknowledgment to the peripheral using the flashlight.
7. The peripheral decodes the acknowledgment signal and the secure connection establishment can proceed according to the BLE 4.2 standard.

Conclusion

We have shown that Kiwink and VLC offer the possibility to setup a SecureConnection with Numeric Comparison or Out-Off-Band authentication on low-cost and size-constrained IoT devices that have neither input and display nor NFC.

Our solution brings a high level of security on BLE devices that would have been completely unsafe otherwise. The costs of this major improvement are negligible since Kiwink only relies on a cheap LED and a piece of software.

Besides, many application fields and use cases of VLC exists like access control, device-to-device communication, or accurate indoor localization using ceiling LEDs (Kiwink website gives further information about VLC).

Finally, feel free to give your feedback about that. We are are waiting for your comments and suggestions!

You can also read this post and engage the conversation on the NordicDeveloperZone.

Google Summer of Code is sponsored by Google, which aims to allow students to writing code and learning about open source development while earning a stipend with their summer break. There are many amazing projects that you can select your favourite. If you are accepted, your organization will provide mentors for your project to help you to complete the project.

OpenMRS is a collaborative open source organization which aims to develop software to support the delivery of health care in developing countries. And In fact, there are many helpful developers, implementers and user in OpenMRS community from around the world who contribute to the OpenMRS projects.

I am glad that I am one of the students of Google Summer of Code 2017 with OpenMRS, and now GSoC 2017 is coming to an end, so I would like to make a summary of this summer vacation of my life.

Open Concept Lab Enhancement

• Primary mentor : Jonathan Payne
• Backup mentor : Ellen Ball
• Student : Xu Hao

Overview

Open Concept Lab (https://openconceptlab.org1) is the tool that we want to use in the OpenMRS community to mix-and-match shared, curated concepts (e.g. from the CIEL dictionary) with locally-defined concepts.
The goal of this project is to make UI enhancements to OCL to make it easier for OpenMRS implementations to use it to create and share content.

Main Objectives

• Add a “Fork This Concept” feature to be convenient for user to make local edits to someone else’s concept

• Add a graphical “Diff Viewer”. User can view the changes across concepr versions.

• Add a “Relationship Browser” view in OCL, so user can see immediately-related concepts in an intuitive way, and quickly browse to them.

Extra Objectives

• Fork This Mapping
• Diff Viewer can compare different concepts to each other.

Contributions

I put all features in one pull request with each module, so there are many changes in each pull request, and mentor is reviewing it. So it needs time to be merged. Sorry for this.

Pending

• implement the Forking this Concept and mapping by hao555sky · Pull Request #521 · OpenConceptLab/oclapi
• implement the Forking this Concept and mapping by hao555sky · Pull Request #324 · OpenConceptLab/ocl_web

Video

Future Work

• Add a “Fork This Collection” feature, e.g. so an implementation could take a form of “OpenMRS Condition List starter set” and make some local modifications.
• Make UI more beautiful

References

• Project wiki
• Project detail in OpenMRS Talk
• Blogs

Acknowledge

Time files, three months has passed. There are too many words to talk in my heart.

Firstly, thanks OpenMRS very much, OpenMRS is reponsible and helpful to students. OpenMRS arranges everything for our students, which is with the bases that I can finish my work better.

Secondly, sincere thanks to my mentor @paynejd who gave me many help to finish this project. He always be patient and helpful to my questions and problems, I can ask him for help no matter what diffculties I encountered.

In the end, thanks to Google for sponsoring the project, providing chances for our students to contribute to open source project.

Thanks

Xu Hao

GSoC’17 — Final Blog Post

Hello Everyone,

This post is the summery of what I did during GSoC 2017 and how you can use it along with other useful resources.

Primary Mentor: Stephen S. Musoke (@ssmusoke)
Backup Mentor: Mayank Sharma (@maany)

OpenMRS receives data from various sources which have a different implementation. It is not always possible to check the validity of the data immediately, thus the Data Integrity Module is very helpful to check the validation of the data and alert the administration if something wrong. It helps to maintain data quality.

Summary

• Improved filtering and display of results page.

Added multiple filters, upgraded the datatables versions. Arranged various components in intuitive way.

Result Page

• Added feature which exports filtered list of results into CSV, Excel or PDF.

Export Buttons

Exported List

Added this feature using the datatables library. Adding icons in OpenMRS was a tough task.

• Create and Expose Module’s APIs

Most of the APIs are written but some APIs are left along with their unit tests. Learned about Test Driven Development here. Used OpenMRS Web-Services module.

• Externalize all Labels, messages, and errors into the module

There was lots of hard-coded string in the module. Moved them to a particular file which can also be used for localization.

• Others

Updated ReadMe of the project and few wiki pages. Added an example module which is already integrated to Data Integrity Module.
Minor fixed in patient dashboard — took me a lot of time to understood the working of widgets within OpenMRS.

What’s left

• DINT-82: Create and Expose Data Integrity Module APIs
• DINT-70 — Add the ability to run SQL based rules

There are the two major work left I couldn’t complete during GSoC period. Anyways, I’ll keep contributing in OpenMRS with the focus of completing these tasks first.

Contributions

Pull Requests

• DINT-73: Improve filtering of results of results from running the rules
• DINT-79: Update README
• DINT-77: Add dashboard widget definition
• DINT-76: Add capability to export rule violations to CSV and/or Excel
• DINT-80: Externalize all Labels, messages, and errors into the module
• DINT-82: create and expose API of the Data Integrity module — Work in progress
• UICM-76: Need to update version of Datatables.
• DINT-77: Dashboard Widget — Should show the note for the result by default
• AC-408: Write Introduction (Android Client User Guide)
• Android Client User Guide Readme updated.

Issue I’ve opened

• DINT-82: create and expose API of the Data Integrity module.
• RA-1382: Patient Dashboard — buttons shift below if text beside it is very long
• DINT-79:Update Data Integrity Github README
• DINT-78: Update Data Integrity Wiki Page to reflect latest updates
• UICM-76: Need to update version of Datatables

Video

After last midterm evaluation there wasn’t much visual addition so I’ve used the same video.

Experience

I have learned lots of things that I couldn’t even count. From Webpack to sass, Hibernate to Test driven development, etc. I found mentors and OpenMRS Community is very helpful whenever I got stuck somewhere or whenever I need any feedback.

Before GSoC, I haven’t contributed to any OpenMRS module and it took me a lot of time to understand the architecture and working of OpenMRS. During the community bonding, I was struggling to set-up data integrity module on my machine. Mentors and especially, @ssmusoke was very patient and encouraging. He helped me in every way possible in each and every time I asked for help or guidance. Overall it was a great fun and learning experience.

There is a lot of work needs to be done and I really love contributing to OpenMRS so I will keep contributing.

Thanks Stephen(@ssmusoke), Daniel(@dkayiwa), Darius(@darius) for you help. Thanks OpenMRS for such a wonderful summer :D

Resource

• Talk Post
• Project Wiki Page
• Github Repository

Generic Tagging Mechanism

Primary mentor : Wyclif Luyima
Backup mentor : Burke Mamlin
Student : Jai Tatia
Project wiki : Link To Wiki

Overview
OpenMRS has always lacked a mechanism that allows users to annotate domain objects with simple text labels/tags, these labels can be useful in various ways e.g to group data and generating work queues. The goal of this project was to provide a tagging mechanism in OpenMRS that cuts across all domain objects.

Objectives

There were changes made to the objectives midway based on feedback from the community.

• To create a generic robust Api which will interact with the database and can be used for tagging OpenMRS Objects. (COMPLETED)
• To create a Rest Resource to expose the module and to be able to make Rest Calls to obtain tagging related data. (COMPLETED)
• To create a UI fragment extension to the second Column Fragment of the clinician facing patient dashboard, for performing simple functions such as adding, removing and viewing tags. (COMPLETED)
• To add a feature where-in clicking on a tag redirects to a page where all Patients having that tag are listed. (COMPLETED)

Implementation
The following pages cover the implementation details, including rest calls and the user interface.
http://wiki.openmrs.org/display/docs/Generic+Tagging+Module
https://wiki.openmrs.org/display/docs/Generic+Tagging+Module+-+Technical+Documentation
https://wiki.openmrs.org/display/docs/Generic+Tagging+Module+-+User+Guide

Video Presentation:  https://youtu.be/v6fJNYRR0_c

Commit History

https://github.com/openmrs/openmrs-module-tag/commits/master?author=jtatia

Main Project Link

https://github.com/openmrs/openmrs-module-tag

Other Resources

Project Documentation: https://wiki.openmrs.org/display/docs/Generic+Tagging+Module
Talk Discussion: https://talk.openmrs.org/t/rest-api-for-generic-tagging/11522

Blog History

• WEEK 12 [16th August – 22nd August]
• WEEK 11 [9th August – 15th August]
• WEEK 10 [ 2nd August – 8th August]
• WEEK 9 [26th July – 1st August]
• WEEK 8 [19th July – 25th July]
• WEEK 7 [12th July – 18th July]
• WEEK 6 [5th July – 11th July]
• WEEK 5 [28th June – 04th July]
• WEEK 4 [21st June – 27th June]
• WEEK 3 [14th June – 20th June]
• WEEK-2 [07th June – 14th June]
• WEEK -1 [30th May – 6th June]
• Community Bonding Period
• Google Summer Of Code

Add Ons Enhancements

Primary mentor : @darius
Backup mentor : @mseaton
Student: @reubenv
Project wiki: Link

Overview

This project aims at making certain changes to the existing OpenMRS Add Ons infrastructure thereby making it fit as a complete replacement for the existing OpenMRS modulus. The main motive behind this project is to be able to completely retire OpenMRS modulus whose codebase has become tough to maintain. OpenMRS Add Ons also supports OWA’s which is a vital feature that Modulus lacked. The developer is now free to host his module in any of the supported hosting sites while Add Ons does the job of adding it to the OpenMRS module index. Add Ons also gives the freedom of choice of hosting location in hands of the module developer. Add Ons is built on a light framework and hence is hopefully easier to maintain as compared to Modulus.

Objectives:

• (Front-end) Allow a user to find add-ons that are compatible with their particular version of OpenMRS
• (Backend) Support for indexing Modules and OWAs that are released as GitHub Releases
• (Front-end) Show a list of most-active or most-downloaded modules
• (Backend) Add new Rest end points for getting module by its Package Name and also add the Package
  Id as metadata to the details of a module
• (Backend) Improve Search algorithm used
• (Front-end) Improved utility of tags in add-ons
• Ensure smooth migration from using modules.openmrs.org as the primary data source to Bintray
• Ensure Add-Ons is live by the end of GSoC period

Final Video Presentation

GSoC Contributions

openmrs/openmrs-contrib-addonindex

Other Resources:

Project Documentation: https://wiki.openmrs.org/display/projects/Add-On+Index+Enhancements+Project
Talk Discussion: https://talk.openmrs.org/c/projects/add-on-index
Blogs: Medium blog

Experience:

I must admit that this has been by far one of my most productive summers yet. I loved every moment of working for this organisation. There have been so many nights, I was up all night implementing features, not because I was forced to but because I was enjoying it. I would like to especially thank @darius for his immense support, help and patience. He has been patient enought to review all my silly mistakes and poor coding habits. He is a person who clearly stands by this quote : “The finest steel has to go through the hottest fire”. He ensured that I fix each and every minute detail in my PRs so that I won’t commit those silly mistakes again. I must admit that my coding style and knowledge has surely improved greatly. I also wish to thank all of the other wonderful members for helping me get involved in this community.

Though GSoC is coming to an end, my contributions to this community will continue for a long time. So don’t miss me just yet

GSoC 2017 — More Meta Management in Admin UI

Module Management

System Information

Manage Scheduler

For more project information,

https://wiki.openmrs.org/display/projects/More+Metadata+Management+in+AdminUI+-+GSoC+2017+Project

There is no project type called Reference Application. There are only platform modules. Platform modules are the ones which runs on the OpenMRS platform. FYI, there is a platform module called “Reference Application”. But this is just another typical platform module.

openmrs/openmrs-module-referenceapplication

Thank you and keep in touch! :-)

Hello Everyone!

Last week I continued working on DINT-82 which is going to complete soon, the complex stuff is done, just need to build on it.

This week is 12th week— i.e. last week of GSoC. I have learned lots of things during this period of 4 month (including 1 month of community bonding). I will include all the things I learned in my final post of GSoC’17 .

Coming back to DINT-82, I had real problem testing the REST APIs I was building. Basically, these APIs are written in Java and there isn’t any default hot-reload support for this so testing them every time you make a change was a real pain. Finally, tired of restarting server again and again I asked my mentors what can we about it ? Darius came to my rescue — I was introduced to test driven development. It is a great method for test if being developed feature is working as it supposed to.

I also learned that how can you mock the database and use it for testing, you just need an xml file with the data.

That’s all for now. Thank!

Useful links:

• Talk discussion post
• OpenMRS Testing conventions

OpenMRS is an open source community driven software which can be used in clinical environments(specially for resource constrained). It has many functionalities and it is widely used across millions of users. As there are many users, product has different variants for different use cases. Typically those are known as distributions. OpenMRS keeps a general purpose distribution called Reference Application. This distribution comes with a modern UIs and most essential modules which needs to have for any clinic to manage the work.

It was suggested that to include reports which are out of the box for Reference Application which gives a better picture about the system data. So, this idea has turned out to be a Google Summer of Code project in 2017.

Project:

Built-in reports for Reference Application

Overview:

• Primary Mentor: Rafal Korytkowski
• Backup Mentor: Stephen Senkomago Musoke
• Student: Jude Niroshan

Final Presentation (OpenMRS talk thread post):

GSoC 2017 - Built-In reports for Reference Application | Final Presentation

Project Goals:

• Define reports inside the OpenMRS server
• Access those reports through Reporting REST API
• Create a new Open Web App
• Visualize Data through charts

Basic Reports

• Number or Visits
• Number of Patient Registrations
• Number of Admissions/Transfers/Discharges per service area
• Number of Visit Notes
• List of Diagnosis’s made and quantity
• List of Providers (grouped by active/retired)
• List of Users (grouped by active/retired)
• List of new Patient Registrations
• Patient Visit Report

Implementation in brief

Before starting any work, knowledge about the reporting module is essential to this project. The best time for this was the Community Bonding period. Within this period, basic reports were created by simply using the reporting module. This is purely a functional task which involved no coding work. This led the developer to get a clear picture of the existing module functionalities and how it should be used in order to achieve the project goals.

This was communicated in the first meeting with the mentors.

First meeting with GSoC mentors

Defining reports inside the server would give a clear idea on what needs to be achieved. Therefore, development work was started by defining the reports inside reference application module. Once the module has deployed into a OpenMRS server, those defined reports has to be created automatically. It was realized that those report definitions actually needs to resides within the Reference MetaData module rather than Reference Application module. So, those developments were moved to this module.

Implementing reports in Java — OpenMRS

Server side commits — ReferenceMetaData module:

• - Built-in reports for reference application · openmrs/openmrs-module-referencemetadata@78527d2
• built-in reports multiple rows reports test coverage · openmrs/openmrs-module-referencemetadata@625285e
• [RA-1386] Fixed the duplicate uuid for built-in reports excel report ... · openmrs/openmrs-module-referencemetadata@f4f7c7e
• Renamed the report column names and modified the tests accordingly · openmrs/openmrs-module-referencemetadata@5f9c68c

Client side — Open Web App:

Once this has completed, it was time to create a new Open Web App to access those reports and display them with rich graphical interface. This new web app makes calls through reporting REST API in the OpenMRS server.

JudeNiroshan/openmrs-owa-built-in-reports

Problems faced while development:

There was a build problem I was facing while implementing the unit tests.

Implement a report inside a .omod (Build Error)

I have spent some weeks struggling on getting the created_date into a cohort definition. Finally with the help from Mike Seaton I was able to find a solution.

how to get date_created as a data definition [solved]

When I was fetching the report data through Reporting REST API, I was facing some other problems to get the proper report data.

Fetching a report to OWA through Reporting REST API

Passing Location as a parameter to some of my reports through Reporting REST had an issue. My mentor Rafal helped me to get through this problem.

How to pass Location object from OWA to reporting REST API

Mid-term presentation

Basic Reports:

These are the report interfaces which are implemented inside the openmrs-owa-built-in-reports

Weekly blog posts:

• Week 1 — Implement reports inside reference application module
• Week 2 — Integration of Cohorts into reports
• Week 3 — Unit tests coverage for reports
• Week 4 — Create the Open Web App skeleton in ReactJS
• Week 5 — Fetch report data through Reporting REST API
• Week 6 — Issue in fetching report data in Reporting REST API
• Week 7 — Move server development to Reference MetaData module
• Week 8 — Create specialized React components for reports
• Week 9 — More React components
• Week 10 — React component unit test coverage
• Week 11 — CSS style modifications, improve code quality
• Week 12 — Improve code quality, write documentation

OpenMRS talk thread:

Since the day I decided to work on this project and being selected for Google Summer of Code 2017, all things can be tracked down in this thread post:

[GSoC-2017] : Built-In Reports for Reference Application

I would like to take this moment for say a big thanks to my mentor Rafal Korytkowski who gave me this wonderful opportunity to become a GSoC student and work on this cool project.

Also special thanks goes out to Akshika Wijesundara who supported me in lot of ways to get into this position. Without him, I wouldn’t have the privilege of becoming a GSoC student.

It’s great work, and you have completed everything! This is really helpful for future GSoC students.

Continue reading "GSoC 2017 With OpenMRS – Operation Theater Module Workflow Enhancements"

So this is the final week of GSoC, the time was amazing I learnt a lot of new things and my coding skills improved lot. I was quite busy at the end due to college and internship season but still I managed to work it out.

Last week I worked a lot. I tested the app in every possible way to find bugs and fix them at the earliest. I also added somore features and started writing my final report too.

This was the final week of GSOC before the evaluation week begins. For this period i added a feature where clicking on a tag redirects a user to a page which lists all patients with that tag.

This week will mainly be spent on cleaning up the code, getting rid of any bugs and completing the documentation.

Overview

• Primary mentor : Sri Maurya Kummamuru
• Backup mentor : Kaweesi Joseph
• Student : Choxmi Sathsara

DHISReporting module automates the process of running sql queries against an OpenMRS instance and posting the results to a DHIS2 instance. It even exposes a set of web services that can be consumed through your applications or by using cURL. The module works with OpenMRS 1.9.x and higher.

Objectives

• Implement report mapping function

Report mapping function is about mapping DHISReports with Reporting module reports. With this functionality DHIS Data elements will be mapped with the Reporting Indicators of the reporting module. More

• Handle un-mapped reports

Module should be able to handle the data indicators which hasn’t mapped with any SQL query or any other cohort report. With this implementation, those reports will be indicated and will not allow the user to generate the report until the mapping is get completed.

• Generate report history in reporting module and link history to DHIS report

With the new implementation, now user can view the history of the reports which is linked to DHISReports. About this implementation and un-mapped report part is described here.

• Prioritize the report generation

This objective is about report rendering. The user can decide which should be prioritize when rendering the report. It can be SQL or Reporting. Some reports may have mapped with SQL Cohort reports. In that case the query result may be different from the result generated in reporting module. This functionality will address that issue. More

Demo (Created for mid evaluation. Prioritize the report generation hasn’t included) :

Documentation : https://wiki.openmrs.org/display/docs/DHIS+Report+Module#DHISReportModule-3.4ReportMapping

Github URL : https://github.com/Choxmi/openmrs-module-dhisreport/tree/report-mapping

Blog posts : week1, week2, week3, week4, week5, week6, week7, week8, week9, week10, week11

Issues reported and worked on : DRM-28 , DRM-9 , AC-395 , AC-399 , REPORT-812 , REPORT-828

Hello, guys, as you see in the title, this is the last week of coding period, and we should finish the coding work to be ready for the last evaluation. In fact, I have to say, this is a difficult week for to to do the last objective. Because I have to show the data with visualization. You know that, front-end is hard for me. Up to now, I have a question that I can not solve.

Alright, I say something about the work in this week. You know that, the objective of this month is to add a “Relationship Browser” view in OCL, so that when you are looking at a concept, you can see immediately-related concepts in an intuitive way, and quickly browse to them. So what I should do is that get right data and display them with right way. So Firstly, I coded in back-end to get data, and select them to delete data that does not match. And Secondly, I should show them with visualization ways, so I need to find a right JavaScript library to use, but I met an emergency, so I asked for mentor to help me find a proper JavaScript library. Now, I am working for show data with it.

In fact, I encounter the problem that show the data with JavaScript library, so I have to solve it tomorrow, and finish the work of this month. And I need to get ready for the last evaluation. That’s all work I will do next week.

That’s all, thanks to everyone who cares for me and helps me a lot. Have a good time.

This is the 2nd last week of Gsoc and I was busy fixing some issues that were caused after migration to Bintray . After all , no script can be perfect ;-)

Moreover, I’ll be focusing on getting the Module versions based on user platform version to work. I am currently also trying to tackle my college exams on the other hand and hence was busy;-)

After 3 whole months, 2 evaluations, thousands of LOC, countless nights of coding, this week has finally come when Gsoc comes to an end. I am not sure whether I am happy or sad about it but one thing is for sure and that is that I will never forget this experience ever. Moreover, I am so glad to have got this opportunity to work with an open source organisation.

Coming to the progress report, this week had been all about getting the new Rest APIs set up and also the suggestion of modules compatible with the user’s platform version. In the final week, I will be implementing the download counts feature wherein I’ll be fetching the info from Bintray and rendering it in Add Ons.

So finally, now comes the big question. Will the Gsoc mean the end of my relation with OpenMRS? NEVER! I absolutely love working in this organisation and I don’t think I’ll ever want to stop contributing to it.

Google Summer of Code Final Report — Week 12

Overview

• Primary Mentor: Daniel Kayiwa
• Backup Mentor: Wyclif Luyima
• Student: Suthagar Kailayapathy

OpenMRS Legacy Module contains a lot of administrative functionalities which are needed to manage the reference application. Most of this administrative functionalities contain a legacy model and less experience to the users. So OpenMRS Community wanted to migrate those administrative features to the Modern Open Web App view. More Metadata Management in Admin UI project is one of those projects which are designed to migrate some of these administrative functionalities to the modern open web app view. In the More Meta data Management in AdminUI project, We focused on this following functionalities,

1. Manage modules
2. System Information
3. Manage Scheduler

Those features are implemented as Open Web Apps with the modern view to the users.

More Metadata Management in AdminUI - GSoC 2017 Project - Projects - OpenMRS Wiki

Project Goals

• Migrate the legacy functionalities to the modern open web apps
• Increase the user experience and feasibility of the legacy functionalities

Use some better user interfaces instead of legacy model

Change the workflow of the functionalities to increase the usability

Simplify the administrative functionalities for the users.

• Extend the usage of the legacy functionalities with REST APIs
• Extend the administrative features using existing functionalities
• Improve the problems which are identified in the legacy UI modal

Implement Module Drag and Drop features

Implement Module Information page

Allow user to directly download the modules from OpenMRS Addons

Increase the System Information view

Implement Real Time Task Execute features

Demo Presentation

Implementation

Those features are implemented as an Open Web App and included into the SysAdmin Open Wep App.

Used technologies for the developments,

• Front End Development : HTML, CSS, Angular JS, jQuery
• Back End Development: Java, REST API

Home Page of the Open Wep App

Manage Modules

This feature will be used to manage the modules in the OpenMRS reference application. Users can use this implementation for this following functionalities,

Features of the Manage Modules

1. List all the installed Module — New Icons used to indicate the module status
2. Start the module
3. Stop the module — Confirmation Pop up will be shown with the dependent modules details to alert the user
4. Delete/Unload the module — Confirmation Pop up will be shown with the dependent modules details to alert the user
5. Check updates — Module updates will be checked with OpenMRS AddOns and listed in the new page for
   the user selection.
6. Check one module update — Check the update with OpenMRS AddOns and indicate the update status
7. Start All Modules — No Modifications
8. Add/Upgrade Modules — Implemented Drag and Drop feature
9. Search Modules — Connected with OpenMRS Addons and user can search the module independently
10. Search Module Information — User can view the detailed information about the searched module
11. Module Information View — Used to display the module information with required modules, aware of modules,
    and depend on module details
12. View not installed module information — Connected with OpenMRS add-ons and indicate the user about the installation features.

Some of the Manage Module’s screens

System Information

This feature will be used to display the System information about the OpenMRS server and the system. Users can use this feature to get this following information,

1. OpenMRS Information
2. Operating System Information
3. Java Runtime Information
4. User Information
5. Memory Information
6. Database Information
7. Module Information

New Features

1. Divided the existing System Information under different set of categories to increase the usability
2. Used some new kind of Icons to illustrate the Information Category properly
3. Modified Module Information Section with some new ideas.

Manage Scheduler

This feature will be used to manage the tasks in the OpenMRS reference application. Users can use this implementation for this following functionalities,

Features of the Manage Modules

1. List all the installed Module — New Icons and UI used to indicate the module status
2. Schedule Task — No Modifications
3. Shutdown Task — Confirmation Pop up will be shown to alert the user
4. Reschedule Task — It will reschedule the existing task in the system
5. Delete Task — Confirmation Pop up will be shown to alert the user
6. Reschedule All Tasks — It will reschedule all the tasks in the system
7. Shutdown All Tasks — It will shut down all the tasks in the system
8. Startup Tasks — It will reschedule all the tasks in the system
9. Refresh Tasks — It will refresh the list of registered tasks
10. Add New Task Definition — Used to create new Task Definition, Implemented new UI for this functionality
11. Edit Task Definition — Used to edit existing Task Definition, Implemented new UI for this functionality

Some of the Manage Scheduler Screens

Resources

OpenMRS talk discussions

You can get more information about the projects development workflow using those talk threads

• GSoC 2017 — More Metadata Management in AdminUI

GSoC 2017 - More Metadata Management in AdminUI

• REST Implementation for Scheduler in Legacy UI Module

REST Implementation for Scheduler in Legacy UI Module

• Manage Scheduler Implementation on SysAdmin OWA

Manage Scheduler Implementation on SysAdmin OWA

• New REST Implementation for System Information

New REST Implementation for SystemInformation

• System Information Page Interface Modification

System Information Page Interface Modification

OpenMRS JIRA Tickets Information

Created and worked tickets during the project development

• OWA-21 : Implement Module Management Functionalities in OWA

[OWA-21] Implement Module Management Functionalities in OWA - OpenMRS Issues

• OWA-22 : Implement System Information functionality in OWA

[OWA-22] Implement System Information functionality in OWA - OpenMRS Issues

• OWA-24 : OWA-22 / Modify System Info Page

[OWA-24] Modify System Info Page - OpenMRS Issues

• OWA-25 : OWA-21 / Implement Module Details view page

[OWA-25] Implement Module Details view page - OpenMRS Issues

• OWA-26 : OWA-21 / Integrate with OpenMRS Add-Ons to get module updates

[OWA-26] Integrate with OpenMRS Add-Ons to get module updates - OpenMRS Issues

• OWA-27 : Implement Manage Scheduler functionalities in OWA

[OWA-27] Implement Manage Scheduler functionalities in OWA - OpenMRS Issues

• RESTWS-673 : Implement REST services to Manage Scheduler functionalities.

[RESTWS-673] Implement REST services to Manage Scheduler functionalities. - OpenMRS Issues

• RESTWS-674 : Include More Test cases for ModuleController1_8 in REST Module

[RESTWS-674] Include More Test cases for ModuleController1_8 in REST Module - OpenMRS Issues

• OWA-31 : OWA-21 Implement Drag and Drop module upload feature

[OWA-31] Implement Drag and Drop module upload feature - OpenMRS Issues

Created tickets for the issues by me during the development period

1. AO-8 : Allow cross-origin calls to our REST API
2. AO-9 : REST endpoint for getting a module by it’s modulePackage value
3. PDMO-1 : Implement Encounters functionalities in OWA

Weekly Blog Post

1. Week 1 — OpenMRS Module Management OWA
2. Week 2 — Upload module to OpenMRS using REST
3. Week 3 — System Information Open Web App
4. Week 4 — OpenMRS System Administration OWA
5. Week 5 — First Evaluation — Google Summer of Code
6. Week 6 — System Administration OWA — Final Stage
7. Week 7 — Complete the SysAdmin — Final Stage
8. Week 8 — Module Update with OpenMRS Add Ons
9. Week 9 — Second Evaluations — GSoC 2017
10. Week 10 — Started working on Manage Scheduler
11. Week 11 — Drag and Drop Module Implementation

Code Contributions

REST Web services module

• RESTWS-665 : SystemInfo REST implementation by suthagar23 · Pull Request #285 · openmrs/openmrs-module-webservices.rest
• RESTWS-645 Added version to Module Resource default representation by suthagar23 · Pull Request #291 · openmrs/openmrs-module-webservices.rest
• Restws 674 - Include More Test cases for ModuleController1_8 in REST Module by suthagar23 · Pull Request #292 · openmrs/openmrs-module-webservices.rest
• [RESTWS-673] Scheduler REST Implementation by suthagar23 · Pull Request #293 · openmrs/openmrs-module-webservices.rest

SystemAdmin Open Web App

suthagar23/openmrs-owa-sysadmin

Get more Open Web App Screens here,

OpenMRS SystemAdmin Open Web App

GSoC Time with OpenMRS…. Write Code, Save Lives….!

This week was very productive in terms of quality and quantity. Finally, the module is FINISHED !!

This week, I finished the Client Management REST Controller. Initially all testing was done against the authenticationManager used by the token services. So, I made a new authenticationManager one custom to server the needs of the REST Controller.

The controller supports the following endpoints :

• GET /clientManagement?username=xyz&password=xyz
•          This will return all the clients registered by the client developer xyz.
• POST /clientManagement?username=xyz&password=xyz?name=abc….
•          This will create a new client for the client developer xyz
• DELETE /clientManagement?username=xyz&password=xyz?client_id=abc
•          This will unregister the client with client_id abc
• UPDATE /clientManagement?{details here}
•          This will update the client details

Progress on SMART ?

All initial research was finished and discussed thoroughly with Mayank (my mentor, @maany) this week and all the authorization endpoints were completed in the module. The next step is to code the JavaScript based SMART on FHIR client which will run against the OAuth module, get a token and access FHIR resources. The JavaScript client is in development phase at the time of writing the blog and I am expected to finish it by Tuesday.

What next?

After the SMART on FHIR client is completed, I will be documenting all the work done in this summer and create a static github.io page explaining all the work and give useful statistics about my work.

The post Week 12 – Controller Finished – SMART in final development appeared first on Sanatt Abrol.

So, this is it! It’s the final week of Google Summer of Code program. I’m still so proud that I was chosen as a student in OpenMRS community to do some cool work in this summer. This week I was mainly working on writing test cases for React components. Now It’s the time to bundle up the things and make things shinny.

I have changed the appearance drastically with CSS modifications to the user interfaces. Now the things are more clean and minimal. I’m still left with the documentation and preparing a video presentation which need to be shared among the OpenMRS community.

Tomorrow I’ll have the weekly meeting with my mentor. I plan to discuss about the release of this OWA and integrating the TravisCI to this OWA. At the same time I have to write clean documentation what I have done in this summer. Seems like a busy week is coming up ahead. So, I’m getting ready for it :-)

This is the last week of GSoC. I managed to complete all tasks. The swagger SDK generation postpond due to major version upgrade to STU3. I completed medication request GET, POST and DELETE operations. OpenMRS DrugOrder not allow to edit.

Added Documentation added in https://wiki.openmrs.org/display/projects/MedicationRequest+Resource

Medication request specification https://www.hl7.org/fhir/medicationrequest.html

Challenges and Concerns when implement the MedicationRequest

• Medication request timing can’t match with DrugOrder

“timing”: {
“repeat”: {
“boundsPeriod”: {
“start”: “2015–01–15”,
“end”: “2015–01–20”
},
“frequency”: 1,
“period”: 6,
“periodMax”: 12,
“periodUnit”: “h”
}
}

• Medication request fields status, intent, maxDosePerAdministration and validityPeriod can’t map

I’ll add my final presentation in next which is the last post.

Back in Action….

Live Log Viewer feature has been enabled in the WSO2 API Cloud. Unfortunately, Live log viewer feature was disabled in the API Cloud for a long time due to some internal reasons. After some improvements, WSO2 API Cloud is going to provide the live log viewer feature again to increase the user experience and feasibility. It will give the real experience to the users like real log viewers.

Visit WSO2 API Cloud to get the Live Log Viewer Experience

Why is Live Log Viewer Important?

WSO2 API Cloud contains a reasonable amount of customer in this time and they are using API Cloud for their internal and external API Management. They are creating/managing their APIs in the API Cloud and debugging for their needs.

Do you know the challenge of Debugging? The following quotes of Brian Kernighan will express the depth of debugging,

“ Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it? ”

So there should be some kind of tips to identify the issues in the debugging time. Now a days the Logs are plays major role in the debugging, every programmers and debugger depend on the different type of logs to identify the issues to fix it. It is an easy way also to identify the issues regarding some problems.

WSO2 API Cloud is the middle ware platform which is working in the background to manage the customer’s APIs. If there are any critical time for the customers and while they are trying to debug it, There is no way to debug with API Cloud from the customer level. The only way is getting the logs from API cloud and analysis those logs to identify the problem. So WSO2 API Cloud is responsible to provide the logs for their customers in the real time. Now customers can easily go to API Cloud live log viewer and get their logs in the real time when they are dubbing their API’s.

Follow these steps to get your live log viewer in the API Cloud

1. Log in to your WSO2 API Cloud (If you are an existing customer you are required to log out and log in again at the first time of the use)
2. Go to API Cloud Admin Dashboard ( Click the Configure menu in the top bar and click Admin Dashboard menu)
3. Then Click Log Analyzer menu on the left side, then It will expand and show Live Log Viewer menu
4. Click on Live Log Viewer to get your recent logs.

Features of WSO2 API Cloud Live Log Viewer

It provides the recent logs respected to your organization. If you haven’t any logs for last certain time, then you will get an empty live log viewer. So better to use it in the real time while you are busy with debugging.

It will automatically refresh and provide the latest logs to the customers. Works across all regional gateways around the globe. Customers can get the following type of logs from Live Log viewer

• INFO Type Logs — Blue color tag
• ERROR Type Logs — Red color tag
• WARN Type Logs — Golden Brown color tag
• DEBUG Type Logs — Green color tag

Live log viewer display pattern will be like,

{ LOG TYPE } { LOG TIME } { LOG MESSAGE }

Live Log Viewer notifications and solutions

Live Log Viewer failure notification

Are you getting the above error message in the Live Log Viewer? then the reasons for the error message and solutions are,

• Your current browser session might be corrupted due to some browser actions. So just Refresh the browser to get the logs.
• Your browser session might be expired or cleared. So just log out from the API Cloud and log in again
• It may take some time to retrieve the logs at the first time. So if there any corruptions during this interval It may lead to this error message, So better to refresh the Live log viewer page.

Live Log Viewer too much of logs notification

If you are getting above type of error, that means you have reached the maximum limit of log line during your current session. The limit of the log lines is very large and appropriate for the debugging. If you intend to get more logs using this current session, It may lead to down your browser. So better to refresh your browser once to get the latest logs.

If you can’t get the logs using those above solutions, then feel free to contact our WSO2 Cloud team — cloud@wso2.com

So last week, I was having some troubles with integrating the Client Management REST controller into the module. The troubles were about managing the entry point for the URL mapping. Finally, me and my mentor Mayank decided to do it the way IETF (Internet Engineering Task Force) describes. Like the document here and also manage the client dynamically using protocols defined here.

So I’ve implemented the process using the standards defined by IETF.

Next Problem ? (Because there’s always one  )

 org.codehaus.jackson.map.JsonMappingException: Direct self-reference leading to cycle (through reference chain: java.util.ArrayList[0]->org.openmrs.module.oauth2.Client["creator"]->org.openmrs.User["creator"])

The client class inherits fields like “creator” and “voided” from the BaseOpenMRSData which in turn inherits org.openmrs.User. This leads to a recursive cycle and causes a Jackson JsonMappingException.

Meaning? We simply can’t return OAuth client objects and expect Jackson to convert them into JSON (like it’s supposed to)

Fix? Convert your objects into JSONObjects manually using JSON classes and then send them with the appropriate Http Message.

Progress on SMART ?

As mentioned in the last week’s blog post, the next piece of business was supposed to be SMART. I worked and researched a lot on SMART. SMART on FHIR is a use-case for the module and it’s highly necessary that it is completed in this year’s GSoC.

My initial plan was to use the SMART on FHIR sample JS application and modify it to our needs. However after spending lots of time on 17000 and so lines of code on the fhir-client.js it turns out the app was designed only to be run against their own sandbox server

So the work on SMART is put on hold for now and further work will be done after a call with my mentor (The call is scheduled for 15th Aug 9:30 pm IST).

The post Week 11 – Back to Controller appeared first on Sanatt Abrol.

Hello Everyone!

This week followed the work I have done last week. Last week I have designed the APIs and gathered feedback from community. I started with implementation of the REST APIs this week. Turns out OpenMRS developed a module for facilitate the development of REST APIs — it looks quite useful even I though I didn’t explore it much.

Major design issue of last week was tackle by @darius and he gave me but wonderful feedback. One of the major issue was should we host run_rules under /results or /rules . By the help of Darius, I was able to solve this issue. Finally we are hosting runrequest instead of run_rule under /rules , so this APIs call can maintain a queue or run the rule immediately and send back the response.

Even during last weeks I’m learning something new. During the discussion I came across realised that testing could be sometimes better that hot-redeployment. It would be much faster and you’ll also get accurate behaviour. All thanks to @darius again. I’m not much familiar with Test Driven Development but I will learn it and try to use it.

This week I will continue with the implementation and try to finish it as soon as possible. Apart from this I have other works like — updating wiki pages, fix some small issues etc as this is the last week of GSoC’17 ,

Useful

• WebServices wiki page
• REST APIs design convention followed by OpenMRS
• Design discussion thread

This was the worst week ever. I was working on a lot things and I was half way through my work. Since the code was not complete so I haven’t pushed it anywhere and was working on the localhost, and then suddenly my mac froze and I had to force restart it. And then the most devastating thing happened. My hard disk crashed. Every bit of data gone in snap.

And this is not the worst part, since Apple’s internet recovery doesn’t work behind proxy so I cannot just reinstall the OS directly. I first had to find a person who has Mac, then I had to download OS on his system from App Store and then make a bootable pendrive to install OS on my system. And due to bad internet speed it took forever to download that 5 GB file.

Anyway at last I installed everything, setup my working environment and started working again.

I am definately gonna replace my hard disk now once the GSoC period is over.

We are almost at the end of the GSOC period. Just one more week to go. This week I focused on cleaning up my UI code. A couple of asynchronous features weren’t working so i worked on getting them to work. Other than that i made corrections based on my mentors review. I also submitted a pr for changing the module structure which was merged.

There is one small feature left, which i plan to work on after the current pr gets merged, hopefully by tomorrow. The feature shouldn’t take too much time.I then plan on working on the documentation and debugging my code.

Continue reading "GSoC 2017 – Week 11"

It was a very busy week for me. I was left with bunch of small tasks in my project. In the last meeting with my mentor, I showed the progress on Open Web App which I developed using ReactJS.

User Interfaces are not super fantastic, but it does what we expect. I am having a big plan to take care of this OWA for the rest of my life. I can see many things can be improved in this web app. But with limited time period in GSoC program, everything is not possible. But with the current work, anyone can further improve this module. Foundation has laid properly with the help from my great mentor Rafal.

Currently I’m working on writing unit test for React components. It’s something new for me, and I like to learn something new. As coming up week is my last week of the program, I need to bundle up what I have done for last 12 weeks.

Week 11 [Aug 08, 2017 — Aug 14, 2017]

I am reaching the end of GSoC timeline and wanted to prepare for the final evaluations. Last week, I spent more time on Scheduler REST Implementation and SysAdmin Modifications. I couldn’t move with OpenMRS Add-Ons with last week also, because they haven’t pushed the changes to the live. So probably I will work on OpenMRS Add-Ons this week.

I have implemented Drag and Drop feature to the SysAdmin module upload. It is a new feature to the users and they can easily drag and drop the .omod files to upload the module.

Drag and Drop module changes and updates · suthagar23/openmrs-owa-sysadmin@55a316f

Then I have updated the Loading spinner icon from OpenMRS logo to another one. OpenMRS Community decided to move with a new spinner logo for the usage instead of OpenMRS Logo, I have changed like this following,

Last week, I worked on these tickets

1. RESTWS-673 : Implement REST services to Manage Scheduler functionalities.
2. OWA-27 : Implement Manage Scheduler functionalities in OWA
3. RESTWS-674 : Include More Test cases for ModuleController1_8 in REST Module

and created a ticket for module drag and drop feature,

1. OWA-31 : Implement Drag and Drop module upload feature

I could not complete the REST Implementation with in last week and wanted to complete the REST development with in this coming week :-)

The GSoC coming to and end. Past week I publish my video on my current work. Please watch it below.

During this week I implement medication request GET and POST implementations. Now person can create a DrugOrder through FHIR Medication Request. Below content use to create a DrugOrder.

{
“resourceType”: “MedicationRequest”,
“id”: “56b9196c-bcac-4c2f-b3a2–123464a96439”,
“status”: “stopped”,
“intent”: “order”,
“priority”: “routine”,
“medicationCodeableConcept”: {
“id”: “865fceb1-ad0c-4102-aead-26ca25c77b09”,
“coding”: [
{
“system”: “http://openmrs.org”,
“code": “cedf8fc4–6fc9–11e7–9b2b-c4d98716fd91”,
“display”: “Cetirizine”
}
]
},
“subject”: {
“id”: “cf14c415–6fc9–11e7–9b2b-c4d98716fd91”,
“reference”: “Patient/cf14c415–6fc9–11e7–9b2b-c4d98716fd91”,
“display”: “John Patient(Identifier:100)”
},
“context”: {
“id”: “3fcd2047–2aca-404f-ab9d-0d009265d4dd”,
“reference”: “Encounter/3fcd2047–2aca-404f-ab9d-0d009265d4dd”
},
“authoredOn”: “2008–10–19T09:24:10+05:30”,
“requester”: {
“agent”: {
“id”: “b3d97e25–274e-4ed6-b1aa-18848505c33e”,
“reference”: “Practitioner/b3d97e25–274e-4ed6-b1aa-18848505c33e”,
“display”: “Super User(Identifier:Test)”
}
},
“recorder”: {
“id”: “b3d97e25–274e-4ed6-b1aa-18848505c33e”,
“reference”: “Practitioner/b3d97e25–274e-4ed6-b1aa-18848505c33e”,
“display”: “Horatio L Hornblower(Identifier:Test)”
},
“dosageInstruction”: [
{
“sequence”: 1,
“timing”: {
“code”: {
“coding”: [
{
“system”: “http://openmrs.org”,
“code”: “ae984cea-24cb-4e1e-abdd-fd19c9802704”,
“display”: “1/day x 7 days/week”
}
],
“text”: “1/day x 7 days/week”
}
},
“route”: {
“id”: “cee0f244–6fc9–11e7–9b2b-c4d98716fd91”,
“coding”: [
{
“system”: “http://openmrs.org”,
“code”: “cee0f244–6fc9–11e7–9b2b-c4d98716fd91",
“display”: “UNKNOWN”
}
],
“text”: “UNKNOWN”
},
“doseQuantity”: {
“value”: 3.0,
“unit”: “mg”
}
}
],
“dispenseRequest”: {
“quantity”: {
“value”: 1.0,
“unit”: “tab (s)”
}
}
}

In swagger console you can see the medication request is added.

Next week plan is to complete update and documentation. Few concerns will be raised in OpenMRS talk.

I was able to complete the development phase and the documentation. Updated documentation can be found here.

In addition to that, when I was testing the module, I was able to find two bugs and resolved those two bugs as well.

That’s all for this week. ☺

As the title said, this week is the 11th week of Google Summer of Code 2017. In fact, I remember that time is tense, I should finish the last objective in the last time. As we all know, it is hard to have a good ending. However, I will try my best to finish it.

Last week I captured the video about my work. Originally, I do not know how to capture the video with English. Because we don’t speak English in China at all, and my Spoken English is not standard. But I finish the work when I do it over 30 times. I am proud of me.

In next week, I plan to finish the third objective. In my opinion, the technologies in the third objective are similar to the second objective, they are all about front-end. But I know the third objective is harder than the second objective, because I should show the relationships of concept. And I will write a detail proposal about the third objective.

That’s all. I will work harder to have a good ending. Thank you.

This is the tenth week of gsoc and I still am enjoying every moment of it ☺.

This week’s task was to get a previous feature to work as per comments received from my mentor. I also had to create new rest end points so that the developer who may want to use the even is given more flexibility in his choice of parameters. The PR is still under review.

I am also working on OpenMRS platform select. I have successfully migrated all the modules to now use Bintray as the primary source for module downloads instead of Modulus.

I the platform select feature, I am on the lookout for a good way to pass props from parent to {this.props.children} without using redux or flux. Fortunately, I came across React.child. Now I am able to pass the params easily. Currently, I am trying to fix some bugs with this feature.

In the meantime I have also started look at ideas for implementing the comments feature.

Hopefully the coming week is much more productive.

Unfortunately I do not have much to speak of because I have already spoken about this issue in a previous video .

You may view the video here : https://goo.gl/7tWMMm

Continue reading "GSoC 2017 – Week 10"

This week I worked on DINT-82 — a task related to design and implementation of REST API. As of now, data integrity module don’t have any API support for showing rules and results or generating results by running rules.

This task is particularly challenging as well as important as by exposing data integrity module APIs, other services can easily use this module. OpenMRS Android Client or other such apps can use these APIs to check the validity of data received.

The design basically involved two resources in terms of REST API design conventions which are:

Data Integrity Rules

• Hosted at /dataintgrityrules which supports getting list of all rules, all rules belongs to same category or a single rule.
• Users can also fetch list of results generated for a particular rule. As it can be very huge list, the server will send data in chunks. In other words, it will be paginated.
• Similar to other APIs in OpenMRS, rules can also be fetched by uuid instead of rule-id.

Data Integrity Results

• Hosted at /dataintgrityresults. Returns paginated list of results.
• This API call will also support fetching results which generated for a patient or a program. You can get list of results generated for a particular program/patient.

This task involved an interesting design challenge on which the discussion still going on. The set of above API will also support running a rule for an API call — so the question raised where it should be hosted ? If we host it under /dataintegrityrule then it violates the REST conventions. Basically, it will be a POST call which will add new resources and hosting it under the rules APIs call would be misleading as it is not adding any new rule. Hosting it under /dataintegrityresults is fine according to REST conventions but we it also doesn’t seems okay as we aren’t generating results directly by this call. Hopefully we’ll find a good solution — you can find the ongoing discussion link below.

Another interesting stuff I came across while working on this task is swagger — its a framework for APIs. I didn’t explored it much but will do. More information can be found here.

Links

• You can find related post here.
• A very nicely written blog about REST APIs and how one should use them share with me by @dkayiwa can be found here.

Thanks!

This is the tenth week of gsoc and I still am enjoying every moment of it ☺. This week’s task was to get a previous feature to work as per comments received from my mentor. I also had to create new rest end points so that the developer who may want to use the even is given more flexibility in his choice of parameters. The PR is still under review. In the meantime I have also started look at ideas for implementing the comments feature. Hopefully this week is very productive.

Unfortunately I do not have much to speak of because I have already spoken about this issue in a previous blog.

This week was a bit hectic. I started working on adding support for visit documents and since the Visit Document UI module[1] is not a part of OpenMRS ref app so it is not installed on demo server I was using till now for testing. Therefore, I had to setup the local instance of the OpenMRS server.

In summers also I tried a lot of failed attempts to setup the server but thanks to Daniel it was working this time. Though it took a lot of time to setup due to low internet speed of the campus and the maven install failed a couple of times too. But at last it was all working fine.

Antony pointed out that app needs login locations but there setup dosen’t use locations and therefore they are not able to use the app. So, I started working on resolving it after getting the server credentials from him. But the REST services was not working properly. Everytime I sent a GET request, the server was returning the source of the webpage which should not be the case if REST services were working properly. So, I mentioned about it in the issue itself and waiting for his reply.

I also started with the appointment scheduling module and was reading its documentation to implement it in the android client.

References :

[1] https://modules.openmrs.org/#/show/265/visit-documents-ui-1

There was major progress this week with regards to the UI Fragment that was to be added to the clinician facing patient dashboard. After major hacking, the angular resource was completed and the controller is almost at completion. Now all tags added to a patient can be viewed.

Tags can be deleted :-

And Tags can be added:-

A couple of features are left that should be done within the next week. I will then finally move on to documentation, testing and finally making the module ready for the final evaluation.

OMG…! It’s has reached to 10th week in GSoC program. I can’t believe it. Time really flies. I’m starting to feel sad deep down in myself. This wonderful program is sooner going to be end. However I have 2 more weeks left. Last week I was working on implementing a new React component. As per my mentor’s advise, I broke down components further and add the styling to the components as it’s now time to bundle up my project and prepare for the final presentation.

I have many things to clean up. Specially the OWA has lot of half-work done. So, I need to add more styling and make things shinny. Because reports are important. I have to write unit tests for those as well in React. But for the moment, I am trying to finish the things up and then move to unit testing. Because the priority is to implement the features.

Currently I’m adding more and more css styles to report components and making things clear. Tomorrow I have my weekly meeting with my mentor. So, hopefully his advice is really matters now for me. I feel that I don’t have enough time to do more things. But I try my best to deliver my maximum with great quality which I think I have already done in my project.

After the weekly meeting with my mentor, we decided to add prioritizing functionality to the mapping section. Users can prioritize the report rendering method. When an element mapped with a SQLCohort, the edit report section allows to edit the query as well. In this case, even if the element is mapped, user can get report from either SQL query or reporting module indicator. If user select SQL option, the report execution will give the priority to SQL query.

In addition to that, I did some formatting and improved the efficiency of mapping code as well.

That’s all for this week :)

Time flies. This is the first week of the last month, as we all know, everyone wants a good ending, and we all will try our best to do our work. Mentor and I gave many efforts to this project, I hope we can hold on the last moment.

This week I don’t do the work because I did some things about summer vacation and my sister’s new baby. She is cute and funny, I can watch all day. As the weak work week, so I prepare to work next week.

And I want to say thank to mentor and people in organization, they give many help to me to finish the project. I will try my best to do the last objective, thank you.

Week 10 [Aug 01, 2017 — Aug 07, 2017]

After the second evaluations, I spend some days on SysAdmin Open Web App to fix some issues and feed backs. I couldn’t complete the module update part yet, because OpenMRS Add-Ons project also improved during this GSoC time and currently they haven’t completed for those required end points for the access.

So We decided to move Scheduler part this week. My mentor advised me to complete this part as soon as possible. There are two huge tasks wanted complete under Manage Scheduler

1. Implement REST Part for the Manage Scheduler
2. Create Open Web App with all Manage Scheduler functionalities.

Manage Scheduler Dashboard — Legacy UI Module

So I started to implement REST part for the scheduler. I created two tickets to implement Manage Scheduler part,

1. RESTWS-673 : Implement REST services to Manage Scheduler functionalities.
2. OWA-27 : Implement Manage Scheduler functionalities in OWA

Apart from that, I have worked on two more tickets during this week.

1. RESTWS-645 : Default representation of the module resource should include version
2. RESTWS-674 : Include More Test cases for ModuleController1_8 in REST Module

RESTWS-645 Added version to Module Resource default representation by suthagar23 · Pull Request #291 · openmrs/openmrs-module-webservices.rest

I planned to complete the REST Implementation with in this three days and wanted to complete at least half part of Open Web app development with in this coming week :-)

This week my target to comple the FHIR Medication resource get requests. I have went through the MedicationRequest resource of FHIR and identified mappings between OpenMRS DrugOrder. There are some fields which we can’t map with DrugOrder. I have discuss it with mentor and did possible workarounds. Plan is to put a OpenMRS talk post.

Finally, one of the major tasks for the summer (Project migration) was completed and now we can start work with the SMART application.

Overview of SMART on FHIR : 

SMART on FHIR is a set of open specifications to integrate apps with Electronic Health Records, portals, Health Information Exchanges, and other Health IT systems.

The SMART application we’ll be creating will serve as a use-case for OpenMRS Community.

When an OpenMRS user launches the SMART app, we’ll get a “launch request” notification. Just ask for the permissions you need using OAuth scopes like patient/*.read and once you’re authorized you’ll have an access token with the permissions you need – including access to clinical data and context like:

• which patient is in-context in the OpenMRS
• which encounter is in-context in the OpeMRS
• the physical location of the OpenMRS user
• access to a patient data using FHIR module

The SMART will be a JavaScript application. The original plan was to make a REST based application, however there’s not much documentation available for implementing SMART using REST. The javaScript application that I’ll be making in the next ten days or so will be based entirely on the sample JavaScript by smart helthcare.

SMART is a tech stack for health apps. More information about this can be found here.

The post Week 10 – Work on SMART started appeared first on Sanatt Abrol.

Atlast, the form creation issue is resolved and I have pushed the code to GitHub. Finaaly no more missing forms in the app.

Also, some one who is using the android app pointed out that he cannot login to the app even if no locations are configured. I will fix that this week along with my other work.

This week marked the second evaluation for which we had to give a short presentation of our work till now, my presentation video can be found here :

GSoC-2017 | OpenMRS | Android Client Project | Mid Term Presentation

Continue reading "GSoC 2017 – Week 9"

This week involved working on the UI Fragment for the clinician facing patient dashboard. The fragment will be backed by an angular app. The angular controller will render data by calling methods from an angular service, which in return Uses $resource and $promise for asynchronous data fetching. We make use of the rest resource by making rest calls to obtain data.

The UI Fragment Will Look like below:

I also made a video as my mid-term presentation to describe the work done till now.

This week I have able to test the functionality of the code. I tested available FHIR resources of the module and fixed several minor issues due to module upgrade. Afterwards, I checked swagger console and it broken due to the recent upgrade. Then I fixed the issues and now the swagger console works fine as well.

My next target is to implement the medication request resource of the FHIR.