First of all, I would like to THANK YOU all the students, mentors and community members who worked very hard to make our GSoC 2017 a success. Without enamors support of all the parties, we wouldn’t have achieved this. We have 100% passing rate with this year’s GSoC which is a great collective achievement. This is first time myself and @k.joseph acting as organization admins. We started our journey with OpenMRS as GSoC students. Our special thanks for @burke and @surangak for guiding us with their experience as previous GSoC admins.

It’s amazing what we have achieved as the OpenMRS community through this year’s GSoC program. We’re glad combined efforts we have had such a tremendously successful summer of code program where we’ve had several successful projects added to our community or improved.

We were first gladdened by Google granting us the maximum number of slots we requested, yes; they added us 5 more slots from the previous year 2016 where we had 10. This was such an overwhelming blessing we hadn’t expected at a time when there were so many new organizations accepted by Google. We then started the quest for the best students that we could be confident in as personnel through which under the successful and historical mentorship of our community we could overwhelm the world with lots of flowery add-ons to supplement the popular community centered OpenMRS medical records platform.

This year we had a big number of good students apply for GSoC. Most of our applicants had amazing proposals and this gave us a pretty busy time selecting the best out of the good, we have received around 50 project proposals. We have filtered out 32 good proposals to select the best 15 out of it. Big thanks to our mentors for intensely looking through each proposal, selecting the best students for every applied for project and then looking for the best proposals among the remnants whose student owners we then reached out to find out whether they would be ok working on another project and that’s how we finally found good students to work on our very few remaining projects.

This is what we have achieved through this summer and we are greatly thankful to Google for this year’s summer of code program sponsorship which includes supporting at-least three mentors to join the Mentor Summit in October from OpenMRS. These are the projects that we have completed this year.

Final Presentations

More Metadata Management in AdminUI

We have basically two ways to extend or customise OpenMRS platform; either through modules or Open web applications (OWA). @suthagar23 under the mentorship of @dkayiwa and @wyclif has innovatively written an OWA that supports management of modules within the Reference application and lists out key system information (OpenMRS info, Memory, OS & Java details, User etc) details more spiced than what we had in our legacy user interface. The objectives of this project include migrate the legacy functionalities to the modern open web apps, increase the user experience and feasibility of the legacy functionalities, extend the usage of the legacy functionalities with REST APIs, improve the administrative features using existing functionalities and find the solutions for the problems which are identified in the legacy UI model.

Add-On Index Enhancements

@reubenv under the mentorship of @darius and @mseaton has amazingly improved the functionality of our new repository of Add-ons for the OpenMRS. 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 code base 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.

Generic Tagging Mechanism

Jai Tatia under the mentorship of Wyclif Luyima and Burke Mamlin has added support to tag any OpenMRS API (Application Programming Interface) object, in the OpenMRS platform we have very many java objects which historically grew from; Patient, Obs (clinical observation), Concept (any medical concept such as drugs, medication, diagnosis, vitals etc), Location (health facility) among others, each of these grew into tens of other objects in the past years; Jai has made it possible to tag any of these API objects to a name/phrase and to retrieve objects by name, object type etc. We hope to see a lot of UI improvement by the final presentation of his project.

Built-in Reports for Reference Application

@judeniroshan under the mentorship of @raff and @ssmusoke has worked on some basic in-built reports which we would wish to by default ship the platform with which includes a list of system users, clinical visits, new patients, providers (clinicians) diagnoses, discharge, and transfers.Reference Application comes with many cool modules together. It also includes the reporting module which enhances the capability of creating customized reports for the users. However, there are no built-in reports which come with the Reference Application bundle. With built-in reports for reference application, new reports will be available by default with reference application. These reports will give an overview of the data in the OpenMRS system while enriched with new OWA which includes more user oriented data visualizations. This project aimed to achieve objectives of reach out to implementations to determine the most useful reports to include in the module, implement various reports using the Reporting module API, access those reports through Reporting REST API, create a new Basic Reports Open Web App UI and add charts to visualize data for some of the implemented reports

FHIR OAuth Smart Apps Integration and OAuth module enhancements

@mavrk under the mentorship of @maany and @harsha89 has worked on improving OAuth module to support the newest version of spring security framework. The initial work on OpenMRS OAuth module has carried out in the Implement the OAuth2 Support for Web Services APIs during the previous GSoC. The objective of this project is to migrate existing module to latest OpenMRS 2.x release and make all the OAuth grant type to work. This functionality should be demonstrated with the FHIR module. The new release also opens door to using higher versions of Spring Security OAuth2 project with the module which needs to be explored. Another major goal is to make FHIR module work with SMART applications which need OAuth2 Authorization code grant type based authentication. So the plan is to improve our OAuth module to implement this capability and do required enhancements.

Open Concept Lab enhancements

In OpenMRS medical concepts (clinical questions and answers) are used as the building blocks for clinical encounters, observations, forms, orders, summaries, reports and almost every aspect of the data. These concepts are distributed through an open concept dictionary (OCL), OpenMRS is by default shipped with an OCL from https://openconceptlab.org This summer @hao555sky works under the mentorship of @paynejdand @ball to make UI enhancements to OCL to make it easier for OpenMRS implementations to use it to create and share content.

Improved REST API Documentation

We have a Rest Webservice API that exposes the OpenMRS data-model plus API and makes it possible to add, update or purge objects, during this summer @gayanw under the mentorship of @bholagabbar and @pascal has improved the user interface (swagger docs) that accesses that web services functionality. The main objective of this project is to improve the living documentation of the OpenMRS REST API, by improving its Swagger Specification and through improvements to how its Swagger Specification is being generated. All my code goes in the OpenMRS REST Web Services Module.

Android Client Feature Parity and Improvements

Android Client is the mobile distribution of OpenMRS for Android devices, it’s just an interface app that uses the Rest Web services functionality to access a remote OpenMRS platform, @defcon under the mentorship of @avijitghosh82 and @raff has worked on Android Client Feature Parity and Improvements project.The purpose of this project is to provide an OpenMRS 2.x client for Android devices. The app covers most of the functionality present in the web application including registering patients, taking visit notes, capturing vitals, etc. The app communicates with OpenMRS instances using REST. It supports working offline (without network connection) with a chosen subset of patients. The database on the device is encrypted and password protected in order to secure patient data.

Operation Theater Module Workflow Enhancements

Managing and scheduling Operation Theater (OT) activities are critical tasks in a hospital. @merovingienneunder the mentorship of @akshika47 and @harsha89 has worked on Operation Theater Module Workflow Enhancements project.
Project objectives mainly include Migrate the module to work with the latest OpenMRS platform and
Perform workflow enhancements to make it more useful.

Patient Matching 2.0

This GSoC @lahiruj under the mentorship of @burke and @sgrannis has worked on Patient Matching 2.0 project.
Properly identifying patients is a critical feature of any electronic medical record system. In the real world, there can be many challenges to patient identification. While some countries have reliable universal identifiers, most countries do not and we rely on patient demographics (e.g., names, gender, date of birth, etc.) to identify patients. In many cases, proper identification can be challenging (e.g., the variable spelling of names, estimated or unknown date of birth). While ongoing efforts to incorporate biometrics and other means of reliable identification, the reality is many systems ending up with duplicate records for patients. Identifying and correcting duplicate records can be a painful process when performed manually. The OpenMRS Patient Matching module was created by one of the world’s leading experts on patient matching techniques, Dr. Shaun Grannis, to use statistical methods to maximize the value of automated patient matching. We’re very lucky to have this module; however, it has not been widely adopted because of some key features needed to make it easy for implementations to use. The goal of this project addresses the key features missing in the Patient Matching module, release a new 2.0 version with the features addressed, and, thereby, help the OpenMRS community benefit from the power of this patient matching module. Main objectives of this project is to implement Incremental Patient Matching and Merging Patients & Excluding non-matching Patients from the Patient-Matching Report.

OWA Generator Improvement

This GSoC @ankitkumar under the mentorship of @pascal and @darius has worked on OWA Generator Improvement project. The OWA Generator is a tool that uses Yeoman to scaffold an OpenMRS Open Web App. The goal of this project is to make it as easy as possible for a developer with some knowledge of EHRs and JavaScript to build an app on top of the OpenMRS platform. It should be very easy to get a development and test environment set up and help should be easy to access and understand.

Data Integrity Module 4.x Improvement

This GSoC @shivtej under the mentorship of @ssmusoke and @maany has worked on Data Integrity Module 4.x Improvement project. 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. The Data Integrity module is used to find data quality violations in data entered in OpenMRS from different sources like the Web app or the Android Client and it is not always possible to validate data while taking input. It is often used for validations that cannot be done within the form capture tools. The violations are checked across any OpenMRS objects visits, encounters, observations and patient attributes even across time. The violations are checked against the rule written in Java or Groovy. As the rules can be programmed, there is very little scope for inconsistency. Added rules can also be configured to run on scheduled time. The current module based on code donated from a rewrite by ThoughtWorks for the Bahmni project. The long term plan is to support data quality improvement projects and best practices.

DHIS Report Reporting Enhancements

This GSoC @choxmi under the mentorship of @maurya and @k.joseph has worked on DHIS Report Reporting Enhancements project.OpenMRS-DHIS2 integration is a need for many implementations in the OpenMRS community. DHIS2- https://www.dhis2.org/ is an aggregate indicator system used along with OpenMRS in many countries.The Present DHIS report module being used 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 cURL. But, this requires a knowledge of the database structure and also SQL skills. Reporting Module has a system that allows generating reports based on a cohort system that generates the SQL queries automatically. The current module can generate DHIS2 report from the reporting module. The goal of this project is to improve the existing functionality of the current module to make it more implementer friendly.

FHIR Module Enhancements

This GSoC @kwateng under the mentorship of @harsha89 and @dkayiwa has worked on FHIR Module Enhancements project. The purpose of this project is to expand the capabilities and functions of the OpenMRS FHIR module. OpenMRS has recently undertaken a commitment to implement FHIR in order to ensure better interoperability between healthcare systems. The OpenMRS FHIR module was developed as part of these efforts. FHIR specification is continuously subjecting to several development iterations which improve the usability. This project aiming to upgrade the FHIR module to the latest version of the standard.

Anonymous Patient Registration Project

This GSoC @nipun under the mentorship of @sara and @akshika47 has worked on Anonymous Patient Registration Project. OpenMRS already supports registration of Unknown patients. Even though this feature is a key component that should be available on the platform, it was not implemented on the platform at the first place. The main objective of this project is to move the feature to the platform. Objectives of this project include find out required modules for this function to work which are registration application module and registration core module then make this work out of the box in the reference application.

Thank you all for your dedication support. We hope students will continue to support OpenMRS with their capacity. We are looking for new mentors from our GSoC students next year. If you can come up with a brilliant idea to help OpenMRS, you can discuss it and become a mentor. We are looking for an awesome GSoC 2018 next year.

Thank You!
Harsha & Kaweesi,
OpenMRS GSoC Admins, On behalf of the OpenMRS Community