GSoC 2024: Project Brainstorming

Community GSoC
1

Hello everyone!

As the application period for GSoC 2024 Organizations is just around the corner, it’s time for the OpenMRS community to brainstorm ideas for potential projects for GSoC 2024!

OpenMRS has been part of Google’s Summer of Code for more than fifteen years, and we’re excited to apply as a organization for Google Summer of Code 2024. We’re actively seeking project ideas for GSoC 2024 as part of the application process. The deadline for the organization application is February 6th, so we’re aiming to wrap up as many project ideas as we can by then. So, let’s use this thread to gather and discuss these exciting project ideas!

Just to note, this time GSoC supports small-sized projects (90 hours) in addition to the medium (175 hours) and large (350 hours) size projects.

We invite the community to contribute to this process by sharing any project ideas you may have in mind. Feel free to express your thoughts and suggestions, as your input is valuable in shaping the projects for GSoC 2024. Looking forward to hearing from you all!

cc: @jayasanka @vasharma05 @grace @ibacher @dkigen @jennifer @burke @dkayiwa @bistenes @samuel34 @dkibet @hadijah315 @kumuditha @jnsereko @anjisvj @dev5 @dev4 @dev3 @dev2

13 Likes
2

Currently, we have the following set of unassigned projects, and we believe they could serve as potential ideas for GSoC 2024 with the input of the community.

  • :teacher: O3: Built-in User Onboarding:

    • Implement User Onboarding in the Test3 and O3 demo environments, like these designs (Zeplin - Login) show. Introduce users to major features in a typical generic outpatient workflow. There are libraries we can leverage to run this onboarding ui.
    • Scope: Medium?

  • :mag: O3: Search Patient Chart feature

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

  • :desktop_computer: Next Generation Implementer Tools for OpenMRS 3

    • 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 and here.
    • Scope: technical work on the redesigned config tools for O3.
4 Likes
3

The Next Generation Implementer Tools probably needs to be scrapped. The designs are essentially unimplementable.

5 Likes
4

Here’s a summary of the brainstorming session had today on the platform call with the help of @burke and @dkayiwa

  1. An audit tool to track user access and actions.

    Something to track which users accessed which patient data, and what actions they performed. This promotes accountability, deters unauthorized access, and aids in regulatory compliance, such as HIPAA or GDPR

  2. Improve Exception Handling of backend APIs

    Implementing a exception handling mechanism, with well defined and documented error codes. ex: something similar to Error Codes - Messenger Platform - Documentation - Meta for Developers

  3. Library updates:

    ex: supporting newer version of either Java, xstream, hibernate, spring, etc.

    @dkayiwa could you please elaborate on our current needs?

  4. Improvements to the SDK

2 Likes
5

We were brainstorming on potential GSoC projects for the OCL module today. Some of the ideas that could be fleshed out into a project or maybe combined into a single project for the OCL module during GSoC 2024:

  • Adding features for change management
    • Helping understand what will change or did change with an import of new dictionary content.
    • Include summary information about content (OCL team could include content summary info in export)
  • Improving error handling
    • Improving messaging during failed import
    • Link to the OCL concept so there’s more seamless integration between the tools
  • Leverage OCL’s checksums in the OCL module (e.g., calculate & expose checksums in OpenMRS, so they can be compared to OCL)

@mseaton, @ibacher , @raff – any thoughts or suggestions on what would be useful or nice to have improvements for the OCL module? Either functionality that could be more robust or filling out missing features.

3 Likes
6

Thanks @burke!

7

This idea is originally came from @dkigen,

UI based validation rule builder for the form builder:

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

Current implementation: https://ohri-docs.globalhealthapp.net/docs/validation

2 Likes
8

To revise this somewhat: I do think a project to revitalize the implementer tools (i.e., build out the UI to actually support complex configurations) would be a good addition, as well as tools to, e.g., allow more easily assigning specific extensions to specific slots.

More stuff:

User-defined extension show / hide rules: (needs a better title) Basically, 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.

Flexible ID generation: The IDGen module is great, but it’s a little specific to patient identifiers, and there are other cases where we want to be able to generate identifiers for non-patient objects that have similar properties. It might be good to extend the IDGen model to support generating non-patient identifiers. (The immediate use-case is to be able to create unique visit identifiers).

REST API Handling of Lists: Basically implementing the ideas from this thread: REST Module and Multi-valued attributes

9

Hello everyone,

I’d like to propose a topic for discussion that I believe holds great potential for OpenMRS 3:

AI-Driven Clinical Support for OpenMRS 3

Given the current surge in AI technology and its significant benefits, particularly in healthcare, I believe it’s time to explore the integration of AI-driven clinical support into OpenMRS 3. Here are some key points to consider:

  1. User Interaction: AI can seamlessly integrate into the OpenMRS 3 user interface, facilitating chat-based or conversational interactions. Users would be able to communicate with the an AI powered bot using natural language.

  2. Natural Language Processing (NLP): Leveraging NLP, the AI would be capable of understanding and interpreting natural language queries and commands from users, ensuring a more intuitive and user-friendly interaction.

  3. Clinical Decision Support: AI can provide invaluable clinical decision support by analyzing patient data within the EMR. This could include offering suggestions, alerts, or recommendations based on evidence-based medicine, clinical guidelines, and the patient’s medical history.

  4. Data Retrieval and Reporting: Users could query the AI bot to retrieve specific patient information or generate reports directly from the EMR. The bot’s NLP capabilities would enable it to comprehend user queries and fetch relevant data from the EMR’s database.

  5. Treatment Plan Recommendations: Drawing from the patient’s medical history, current condition, and established protocols, the AI bot could suggest or assist in developing personalized treatment plans. This could involve considering historical data and recommending interventions aligned with best practices.

  6. Medication Management: The AI bot could support healthcare providers in managing medications by offering information on drug interactions, suggesting alternative medications, or aiding with dosage adjustments. Integration with the EMR’s medication records could enhance overall medication management.

  7. Patient Engagement: Engaging with patients through the AI bot could involve providing information about their treatment plans, answering queries, and offering reminders for appointments or medication adherence. This approach has the potential to significantly enhance patient education and overall engagement.

  8. Automated Documentation: The AI bot might assist healthcare providers in documenting patient encounters by offering suggestions for note-taking based on the conversation. Automation in documentation could streamline processes and improve overall efficiency.

  9. Learning and Adaptation: The AI bot would continually learn from user interactions, adapting its responses over time. This continuous learning process would improve its understanding of user queries, leading to more relevant and accurate information provision.

  10. Integration with IoT Devices: In scenarios relevant to healthcare, the AI bot could integrate seamlessly with Internet of Things (IoT) devices, wearables, or other monitoring tools. This integration would allow the bot to analyze data from these devices and incorporate the information into the patient’s records.

I’m eager to hear your thoughts on this proposal and whether there are existing implementations that have explored similar avenues.

4 Likes
10

Bug Fix

Everytime a user imports a concepts from OCL, the user should see a clear message of the completed transaction, however all times an error of failure is shown to the user even when the concepts have been imported into the instance.

This is has been experienced in 2.12.X and I believe lower / higher versions. Am not sure about 3.X

11

This isn’t the right forum for bug fixes; just create a ticket for it.

2 Likes
12

Thanks for sharing ideas, @suubi7. Unfortunately, we lack the necessary mentor resources at the moment dedicated to AI-related projects.

2 Likes
13

Hello everyone,

we’ve got project ideas related to modules used in Connect for Life OpenMRS:

These ideas sound like medium or big projects, and would involve some design work. I would be happy to provide mentoring from the module’s side, but it would be nice to have someone with good O3 knowledge to be involved too.

Integrating CFL’s SMS Module into O3

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 could be:

  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.

Integrating CFL’s Messages Module into O3

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.

cc: @druchniewicz @jslawinski

3 Likes
14

Thank you @pwargulak for a detailed description. We are ready to mentor at least 1-2 students this year.

Besides CfL related projects we could also support the following ones:

UI based validation rule builder for the form builder

O3: Built-in User Onboarding

6 Likes
15

Hello everyone

I have gone through all ideas and they are briliant.

Tutorial Mode (better title can be suggested) A button that toggles tutorial mode on and off.

What I mean by tutorial mode: that first page you get you get whenever you install a new application that takes you through the basic usage of the controls/buttons on the screen.

When a user has the tutorial mode on;

  1. Guide them through the activity they are doing as long as they know how to read the language shown in the tutorial.
  2. Can also show details about visual elements of the app.
  3. When someone has completely mastered the app (user interface), the user can toggle the tutorial mode off.

This adds to the list of already suggested ideas.

16

O3 Notifications and Alerts

O3 Notifications for the users and admins related to different user cases and broadcast alerts to the user groups/ whole setup. I remember that we have the designs developed for the same.

Thanks!

3 Likes
17

2 More ideas:

:openmrs: Loading Visual (Small Project)

I’ve been watching the Loading indicator a lot at sites and it’s so boring :stuck_out_tongue: Could we get someone to build a little page loading component? e.g. something like this one in our “About Us” video:

openmrs youtube loading icon

:robot: AI Experiment (probably Large Project)

Experiment with LLM/GenAI models to have an insta-summary about the patient on the patient summary (e.g. “Mrs. Agnes Testerson is a 55 year old woman with a significant history of NCD comorbidities consistent with metabolic syndrome…”), like the short summary of Patient History that medical residents collect (so I think of this like a “Robot Resident”):

image
image1140×302 70.5 KB
Seeing if I can convince a friend who works as an AI engineer to mentor this.

8 Likes
18

Hi everyone @here,

Great to see all the fantastic ideas pouring in from various squads and areas. Thanks for your enthusiasm. We are currently in the process of adding your ideas to our GSoC 2024 wiki page.

We’re planning to have a call on 2024-02-08T14:00:00Z to delve deeper into the project ideas and finalize them. The mentors of each project will also be finalized during the call. If you have any questions or need clarification regarding the projects and mentoring, this call will be the perfect opportunity to address them.

Also, If you feel there are improvements to be made in the descriptions of the project ideas you came up with, please feel free to edit the above-mentioned wiki page accordingly.

Thank you, and see you on the call on Thursday! I will add the calendar invitation and the Zoom link as soon as possible.

cc: @jayasanka @vasharma05 @ibacher @grace @dkayiwa @burke @dkigen @pwargulak @jslawinski @mseaton @raff @bistenes @icrc.psousa @jofrancisco @frederic.deniger @pwargulak @chibongho1 @hadijah315 @jnsereko

3 Likes
19

Awesome idea @grace I have wanted to do this for a sometime now. Do you happen to have this animation After effects file or the original file before rendering it to a video.

1 Like
20

This is a good project and i would be more interested to dive into it. @pwargulak