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

Small

90 hours

SVG Animation

React

Medium

175 hours

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

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

Advanced

350 hours

Kotlin
Android

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.

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.

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.

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

Medium

175 hours

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?

Advanced

350 hours

Ian?

Dennis?

Vineet?