/
Fix the Fast Data Entry feature (GSOC 2025)

Fix the Fast Data Entry feature (GSOC 2025)

Summary

  • The Fast Data Entry feature (FDE) is broken and unusable in the OpenMRS community’s main product (the O3 RefApp). No community organization or contributor has had the time or ability to fix this, and yet it is an important foundational feature for OpenMRS users. 

  • The goal of this project is to fix the FDE feature and get it useable again in the O3 RefApp, primarily by engineering the feature to leverage the React Form Engine instead of the Angular Form Engine.

Project Size

Medium

The Current Problem with the Fast Data Entry Feature

The Fast Data Entry feature was originally contributed by ICRC (thank you ICRC!) back when OpenMRS v3 supported the community’s “Angular Form Engine”. However since that time, OpenMRS v3 now uses a different form engine, the “React Form Engine” (RFE). 

In Dec 2024, community members from ICRC investigated why FDE was broken in the O3 RefApp, and discovered it is because the feature has not been set up to support the React Form Engine.

How it SHOULD work: (demo videos - please see the Fast Data Entry repo README for much more information on workflows!)

Fast (Bulk) data entry working

181378774-341b2a2f-3ecc-4052-b960-d61ba07980fb.mov

Group Visit data entry working

194318314-90bf95a0-cbbc-4ed2-9f83-f8e20d317fbf.mov

How it CURRENTLY looks:

 

You Will Need to:

  • Familiarize yourself with the Fast Data Entry code repository

  • Identify all the areas that will need to be updated/changed in the FDE code in order to support the RFE;

  • Test the Fast (Bulk) and Group data entry flows to confirm they work as expected;

  • Add a few happy-path automated frontend E2E test coverage so that if this feature breaks in the future, the community will be notified quickly. 

Key Resources & Links:

Detailed Background: Why the Fast Data Entry Feature is Important

Fixing the Fast Data Entry feature will help solve two important problems: (1) “The Big Stack of Similar Papers Problem”, and (2) easily recording Group Visits. 

  1. Background of “The Big-Stack-of-Similar-Papers Problem”: 

    1. Causes: Many OpenMRS sites end up with large volumes of paper forms with handwritten data. The information in these stacks of paper needs to be entered into the EMR. Two common causes of this big-stack-of-paper problem are:  

      1. During the Transition from Paper to Digital: need to add older, past data from existing paper records into a new OpenMRS system, so that a patient does not have a blank electronic chart (e.g. if they’ve been attending the clinic in the past, when the clinic was still using paper); 

      2. Catch-up after System Outage: sometimes computer systems go down (e.g. due to power or network outages) and facilities use paper to record patient information. When the system is useable again, there can be a big stack of paper that someone needs to enter into different patient records.

    2. Persona: Often, past data is entered by a role called a “Data Entry Clerk”. Depending on the site, this may be a medical student, other clerical staff, or even a nurse working after hours. 

    3. About RDE: In OpenMRS, entering past/old information is known as “Retrospective Data Entry” (RDE), since the data was not entered into the system at the Point of Care (POC). However, the “Big Stack of Similar Papers” problem is different than other RDE use cases, because usually the forms are all the same or similar. E.g. imagine a stack where all the forms are the same form (such as a “Follow Up Visit Form”), but all the patient names are different. 

    4. How the Fast-Data-Entry Feature Helps the Workflow: Because the forms are often the same, the user does not want to have to click on every single patient chart one-at-a-time and navigate to the relevant form. Instead, it is better for the Data Entry Clerk/User to use the “Fast Data Entry” feature. This feature enables users to focus on the Form Template they are filling in, and they do not need to switch between different patient charts.

  2. Background of Recording Group Visits: “Group Visits” are a type of clinical care where more than 1 patient is cared for at a time. Common examples include: a midwife teaching prenatal education to a large group of pregnant women (eg 10-20); a nurse teaching diabetes self-care to multiple patients with diabetes; or a Mental Health Worker hosting a group therapy visit. 

    1. Persona: May be a Data Entry Clerk (if paper was used) OR a clinician who just performed a group visit. 

    2. User Story & How the Fast-Data-Entry Feature Helps: 

      1. “I each patient’s chart to reflect that they attended a Group Visit, and when, and some note or form about what information we covered, so that it is not forgotten or overlooked that the patient was seen in this setting.”

      2. “I do not want to have to open every single patient’s chart to record the Group Visit. It is much more efficient and time-saving for me if I can record the Group Visit once, and have that Visit and associated notes about the Group Visit applied to the chart of each patient who was in that group.”

Related content

Forms Migration Tool: Help HTML Form users switch to using O3 React Forms
Forms Migration Tool: Help HTML Form users switch to using O3 React Forms
More like this
Summer of Code 2025
Summer of Code 2025
Read with this
GSoC 2023: O3: Migrate vanilla React forms to RHF
GSoC 2023: O3: Migrate vanilla React forms to RHF
More like this
O3 Growth Chart (GSOC 2025)
O3 Growth Chart (GSOC 2025)
Read with this
Enable HTML Form Entry forms in OpenMRS 3
Enable HTML Form Entry forms in OpenMRS 3
More like this
Immunizations & Vaccination Schedule in O3 (GSOC 2025)
Immunizations & Vaccination Schedule in O3 (GSOC 2025)
Read with this