Google Summer of Code: OpenMRS Projects for students
Google Summer of Code just has opened registration for students who want to take part in the Google Summer of Code program this year. If you are looking for help on how to apply for GSoC and what terms need you to fill up take a look at our previous post about that. I’m sure you find there what you are looking for, if not please contact us at firstname.lastname@example.org – we’ll do our best to help you.
Projects in OpenMRS
This year OpenMRS offers even 12 projects in different fields for GSOC students. For each project are assigned two mentors- main and backup who will take care of you and your project during the program. They will support you during work and check your progress and what is the most important prepare with you a project plan which will lead the whole program.
FHIR is an emerging standard for healthcare interoperability. One of the key pieces of FHIR-based technology which should be supported is the SMART on FHIR App Launch Framework. This is a standard for connecting custom applications to a FHIR server in a secure manner. Essentially, it allows non-OpenMRS applications to talk to OpenMRS in a secure manner using the OAuth2 authentication framework.
OpenMRS has had a history of trying to integrate the SMART on the FHIR framework, including past GSoC projects, such as this from 2017 and this project from last year, but so far we haven’t quite gotten things production-ready. The goal of this project is to build on the work done in GSoC 2020 to get things into a state where our setup is production-ready. In addition to the value of running SMART-on-FHIR applications, this work will demonstrate how to integrate OpenMRS and Keycloak to provide a (hopefully) seamless user login experience.
- Good Java skills
- Good understanding of REST
- Some familiarity with Docker
- Familiarity with J2EE web programming (e.g., JSPs)
- Familiarity with OAuth2
- Soft skills to interact with the HAPI and FHIR community and OpenMRS community in order to gather requirements and technical feedback
- A willingness to learn (honestly, there are a lot of technologies involved in this; you don’t need to be an expert on all of them, just willing to learn).
While OpenMRS has been an early adopter of the FHIR standard and there has been some work done on it already, there is a scope to do more in that area. FHIR defines a very detailed API for searching that is fundamental to providing the correct data to any front-end application. Currently, the OpenMRS FHIR module supports a good amount of search functionality including the capability to search across multiple properties and support advanced search parameters such as _include/_revinclude along with pagination.
This project aims to extend the FHIR module to include support for extended operations. Operations (for these purposes) serve as stored queries where there is some logic built into the semantics of the operation itself. For example, the $lastn operation on the Observation resource (invoked using [base]/Observation/$lastn?subject=Patient/123&max=3 endpoint for example) should return the most recent 3 Observations associated with the specified Patient reference. The aim is to implement extended operations that would prove useful for clients using the FHIR module.
- Good Java skills
- Familiarity with SQL
- Bonus points for familiarity with Hibernate and especially the Criteria API
- Bonus points for knowledge of how to write efficient queries and how to optimise queries
- Admin Dashboard. Creating the admin dashboard with an extension point to allow other admin frontend modules to add admin pages. Also will need to create a REST API to expose the list of admin links for installed modules and the frontend code needed to automatically add these links to the admin dashboard. Bundle the dashboard into an Admin 3.0 module that can eventually replace our Legacy UI module (i.e., legacy administration pages).
- People Management. This project will focus on porting User/Person/Patient/Providers administration functions to the Micro Frontend framework.
- Clinical Data Management. This project will focus on porting Visits/Encounter/Observations administration functions to the Micro Frontend framework.
- Metadata Management. This project will focus on porting Locations/Programs/Scheduler/Maintenance functions to the Micro Frontend framework.
- System Management. This project will focus on porting OpenMRS system management functions (global properties, scheduler, module management) to the Micro Frontend framework.
- The REST of Administration. Focused on the backend (Java) to implement missing endpoints for REST/FHIR APIs needed to be able to implement admin features through the client-side app.
- Familiarity with React and TypeScript
- Good understanding of REST
The goal of the Android client is to provide an alternative to access a hospital’s OpenMRS instance by just using the provider’s Android devices. See the full Android client guide for more info.
Considering the services offered by a hospital, an Android application can help doctors, patients, and other staff a lot with its mobility and ease of use, without them having to start the OpenMRS web app on a desktop computer. This will improve the productivity and efficiency of the hospital workflow. This year, we will work on making the Android client more extendable and implementing the offline-first architecture in the app, the Android app must be extendable and easy for the implementers to deploy and implement by encapsulating common functionalities of the app using Jitpack library so that the android client is properly utilized and really solves some healthcare problems.
- Jitpack libraries
- MVVM Architecture
Late last year, OpenMRS began collaborating with researchers from North Carolina State University (NCSU) to better secure the OpenMRS Reference Application. NCSU researchers, using cutting-edge security assessment techniques, have identified almost 300 distinct security issues. Many of those issues are relatively low-complexity, requiring one-line patches. This is a great opportunity for students who are interested in software security to get first-hand experience in the field.
If we have this functionality, then we will be able to export OMRS period indicator reports; which make the DHIS2 integration much easier by avoiding work duplication on metadata mappings. (This is needed to create reference implementations: To create and connect the reporting definitions)
DHIS2 Connector module is a module which is used to post aggregate data from OpenMRS to DHIS2 instance, supported with a UI for an easier-to-set-up OpenMRS to DHIS2 pipeline.
The aim of the project is to develop the module with improvements such as location mapping, user access control, improved performance, introducing some useful features, etc. The student needs to go through the community requirements and improve the module to provide a better integration workflow.