Summer of Code 2024

O3: User Onboarding

Medium

175 hours

Implementing user onboarding in the Test 3 and O3 demo environments, as illustrated in these designs, is crucial for introducing users to major features within a typical generic outpatient workflow. By incorporating user onboarding processes, new users can navigate through the system more seamlessly, gaining a better understanding of how to utilize various functionalities effectively. This not only enhances user experience but also ensures that users are equipped with the necessary knowledge to maximize the capabilities of OpenMRS in their outpatient workflows. Additionally, user onboarding can help reduce the learning curve associated with adopting a new system, ultimately leading to increased user satisfaction and productivity.

More details: https://talk.openmrs.org/t/gsoc-2024-o3-user-onboarding/42076

React

@vijaykv

 @Piumal Rathnayake

@Jayasanka Weerasinghe

Validation rule builder for the form builder

Medium

175 hours

The form engine and builder currently supports JavaScript expression-based validation. However, this can be challenging when creating complex validations and may potentially lead to errors. In most cases, form creation is done by BAs who may not have experience with writing JavaScript expressions. The proposed solution is to introduce a UI-based validation rule builder to the form builder, something similar to https://tally.so/help/conditional-form-logic

React

@senthilathiban

@Dennis Kigen 

@Hadijah Kyampeire 

Building an Offline-Capable Android Application for LMICs Integrated with Enhanced OpenMRS 3.0 FHIR Module

Advanced

350 hours

The aim is to develop an Android application optimized for LMIC healthcare settings, utilizing Google's Open Health Stack for offline functionality. The application will be designed to integrate seamlessly with the enhanced FHIR module of OpenMRS 3.0, as developed in the above proposal. This integration will enable efficient data management with capabilities for offline data collection, and two-way synchronization with OpenMRS 3.0 once connectivity is available, improving healthcare delivery in resource-limited settings

Kotlin
Android

Parth Panchal

Jose Francisco

@Frédéric Deniger 

Integrating CFL’s SMS Module into O3

Medium

175 hours

The CFL SMS module in general is an API module. It provides a layer between other OMRS modules and common SMS (or any text message) service providers.

The main advantage is that once you make your module to work with the SMS module, you can later configure any provider to work with the SMS module without any additional coding, that includes world-wide services like Vonage, turn.io and also local service providers like Rwanda-based FDI. The complete solution comes as an OpenMRS module, no other middleware is required. Some general documentation regarding the module can be found here.

We think it might be useful for other implementations and we would like to make it more accessible.

The goal of the project is:

1. Making an O3 UI for configuring a service provider, inc.: maintenance view with list of all messages sent from the system. There are no O3 designs, but there is customised 2.x style UI to base new design on.

2. Making an O3 UI, aimed at system administrators, to facilitate configuration of Scheduling SMSes on a predefined interval.

In short, using the SMS module you can configure that: at 12 o’clock the system should get recipients and corresponding text messages from an OMRS report and send SMS to everyone on that list.

React

@JESSIE SSEBULIBA

@Piotr Wargulak 

@Samuel Male 
@Dawid Ruchniewicz

Integrating CFL’s Messages Module into O3

Medium

175 hours

The CFL Messages module allows configuring a Message Service. Message Service is a combination of: schedule (an SQL script really) according to which the system should send messages to patients; Apache Velocity scripts which generate specific messages.

In practice, using the Messages module in conjunction with SMS module, system administrators can create visit reminders, missed visit reminders (send message a day after scheduled visit date), pill reminders (send text message everyday for x days) just through configuration (albeit complex configuration).

The integration between other OMRS functionality is made via schedule SQL query, so no coding is required in the other modules to use it as source of data for schedule.

Some general documentation regarding the module can be found here.

The goal of the project could be:

1. Making an O3 UI patient-based calendar with visualisation of a schedule, showing when a message from a particular Message Service is going to be sent to the Patient. There is 2.x style customised UI for it, not useful for O3.

2. Making an O3 UI, aimed at system administrators, to facilitate configuration of Message Services - create new one, upload SQL queries, configure configuration options.

React

@Christopher Lumu

@Dawid Ruchniewicz

@Piotr Wargulak

Validating and re-working (updating) the OpenMRS PatientFlags module 

Medium

175 hours

The OpenMRS openmrs-module-patientflags module has a number of loopholes that need to be addressed before integrating into O3 RefApp.With this project, we expect to revamp the module codebase, address any performance issues, and update this module to modern OpenMRS standards.

Java

REST APIs

@Manoj Rathnapriya

@Wikum Weerakutti 

@Daniel Kayiwa 

OpenMRS Standalone

Advanced

350 hours

Replace the Standalone with something else. Very old, can’t even build in our latest releases - we disable it as the technology no longer works and is no longer supported. We now just ship the .war file and README. Suggestion to leverage Docker - something that works by double clicking and then just runs.

We never intended to use the OpenMRS Standalone version in production. But it turned out to be used in a number of places because they found it easier to use for sites that did not have support staff with advanced IT skills. We are also seeing an increasing number of people in our community who do not have lots of computer skills and just want something to download, click and run for their hospitals.

Java

CANCELLED

@Daniel Kayiwa 

@Wikum Weerakutti 

User-defined extension show / hide rules

Medium

175 hours

The idea here is to implement something like O2’s checkRequireExpression() via the configuration schema’s “Display conditions”, allowing implementations to right JS rules to determine whether a specific extension should be visible or not.

CANCELLED

@ian_bacher (Unlicensed)

@Vineet Sharma

Animated Loading Visualization

Small

90 hours

In response to varying loading times influenced by user devices, internet connections, and server specifications, this project aims to enhance user experience within OpenMRS by implementing an animated loading visualization inspired by the OpenMRS logo. By addressing the challenge of unpredictable loading times with a visually appealing solution, this project aims to elevate user satisfaction and usability within the OpenMRS platform.

SVG Animation

React

CANCELLED

@Jayasanka Weerasinghe 

@Grace Potma 

Revamping OpenMRS 3.0 FHIR Module for Enhanced Offline Data Synchronization and Interoperability

Advanced

350 hours

This proposal aims to overhaul the FHIR module in OpenMRS 3.0, focusing on enabling its interoperability with applications like Google's Open Health Stack for efficient offline data collection. The project will involve a comprehensive review of the current module, identification of limitations, and subsequent enhancements to support adding, editing, and deleting patient data, visits, encounters, and observations. The goal is to facilitate robust two-way data synchronization, crucial for healthcare settings in LMICs with intermittent internet connectivity.

Java

OpenMRS

CANCELLED

@Pedro Sousa 

@Frédéric Deniger 

Next Generation Implementer Tools for OpenMRS 3

Redesigned config tools for O3

Advanced

350 hours

Non-tech users can set up a 3.x EMR in a friendly, no-code UI, similar to designing a website. Empowers local team members to set up and config their EMR themselves. More detailed user stories and requirements documented here. Project plan documented here.

Scope: technical work on the redesigned config tools for O3.

*Design is done because Ampath/@jdick graciously contributed designs and user testing, sample designs, and @bistenes gave a lot of architectural and technical input but then had to set the project aside.

React

Javascript

Typescript

Dennis?

Brandon?

TBC

TBC

O3: Search Patient Chart feature 

Advanced

350 hours

E.g. search all of a particular patient chart for an item of interest, e.g. "IUD" or "COVID", to find if that term/situation has ever come up for this patient. We can likely leverage this past work: https://github.com/openmrs/openmrs-module-chartsearch Will need an API.

Ian?

Dennis?

Vineet?

TBC

TBC