This is early, and we’ll still need a formal place for Project Brainstorming like was kicked off in 2022. But people have been asking me what ideas I have for 2023, so I want to share a few. I want to hear from our technical folks whether these ideas seem technically feasible within GSOC-style-scope, and whether implementers would find these valuable (e.g. @slubwama@aojwang@fanderson@mksrom and others).
I also don’t have any mentors i.d.'d for these features so if there are any tech folks or orgs interested in supporting any of these with mentorship & PR reviews, would love to hear from you!!
O3: Search Patient Chart feature
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. I have heard clinicians wish their EMR had this. Probably leverage this previous: GitHub - openmrs/openmrs-module-chartsearch: liquibase.xml
Scope: Challenging? Not sure what skills would be required. Backend? Maybe a team of BE & FE?
O3: Draw on a Body Diagram
Detailed community discussion thread: O3 Feature: Draw on a body diagram
Scope TBD. UI for a diagram (ideally where any diagram can be uploaded). Unclear whether scope should be for clicking vs drawing.
O3: Print feature
“Print this” component in O3 that can be used/configured depending on what the user wants to print. E.g. med list, recent labs, etc. Will need to do review of what people are printing / where in EMR they need/have the print button these days. Some implementers need specific areas of the chart to have a print option; others use general record printouts, e.g. a summary the patient can take with them to other locations in lieu of a digital medical record integration.
Scope: Medium? React knowledge probably needed.
O3: Built-in User Onboarding:
Implement User Onboarding in the Test 3 and O3 demo environments, like these designs show. Introduce users to major features in a typical generic outpatient workflow. There are libraries we can leverage to run this onboarding ui.
Thanks for kickstarting the GSoC 2023 brainstorming off, @grace! On the 2023 Fellowship Program side, we’re also planning to use January to brainstorm Capstone Projects.
Let’s brainstorm projects for both at the same time, through the end of January.
This way, we’re only doing a single round of project brainstorming & definition for both programs - and we can determine if a project idea is best as a GSoC project or a Fellowship Capstone Project.
Hello guys,
I am looking for some guidance on how can I contribute to openMRS,
I am good at spring boot & flutter and also looking to learn new stuffs, if your could help me to get started.
Hello guys, I am looking for some guidance on how can I contribute to openMRS, I am good at figma ui ux design & flutter and also looking to learn new stuffs, if your could help me to get started.
looking forward to meet an mentor.
thank s for reading
happy coding
Welcome to our community, @shyam1ss15 and @parthis! I suggest that you take a look at and use our Guide for the New & Curious as a starting point for your OpenMRS journey. It will point you to our community conventions, give you a sense of how we’re organized, and link out to some active squads or teams working on projects that you might want to get to know better. Many squads and teams have specific guidance for getting started on their projects.
We currently have a bunch of forms written in O3 in vanilla React. These forms, though functional, are not the most performant or extensible and for the most part, lack validation. React Hook Forms offers easy-to-use validation out of the box, performance and tiny bundle size. The task is to refactor existing forms to use the React Hook Form library and Zod for schema validations. The forms that this refactor would target include:
Start Visit form
Allergy form
Programs form
Conditions form
Visit Notes form
Appointments form
Vitals and Biometrics form
Medication Order form
Patient Registration (heaviest lift, written in Formik)
Scope: Medium. Needs good knowledge of React, HTML, CSS and TypeScript.
GSoC 2023: Extending E2E Automated Tests for the OpenMRS 3.0 RefApp
Abstract
The Microfrontends Team has created a new Reference Application, the “3.0 RefApp”, which represents the future of OpenMRS. It features a modern Microfrontend architecture and replaces the previous “2.x RefApp”. Students who excel in the end-to-end (E2E) testing of this project may also have the opportunity to contribute to the frontend widget and feature development for 3.0. This is because E2E testing will familiarize them with the 3.0 codebase and there is a high demand for feature development.
At present, there are already a few E2E tests running for the openmrs-esm-patient-management repository and more coverage is expected. The goal of the project is for someone to extend the E2E tests for openrms-esm-patient-chart and openmrs-esm-core using the Playwrite framework. The tests will be set up to automatically validate the user interface based on specific workflows.
Skills Needed
A fundamental knowledge of OpenMRS Microfrontends is required.
Proficiency in frontend web development, particularly with React, is highly desirable.
Prior experience with the Playwright framework is a plus, although the ability to write 1-2 simple test cases with it is sufficient. The rest can be learned during the project.
Scope
Medium
Objectives
Overall Goal: Set up tests that automate realistic User Workflows for openrms-esm-patient-chart and openmrs-esm-core and show the squad the results, with a warning indicator on a shared Repo ReadMe so that no one misses failing tests.
The smoke tests are organized according to user workflows, reflecting a user’s perspective.
A limited number of E2E tests are performed on the happy-path user stories (when everything goes smoothly).
These tests do not cover every possible interaction or scenario. Detailed functional tests, which are beyond the scope of this E2E Workflow-based draft, are responsible for that.
Consider the transitions between different parts of the application, managed by different Microfrontends, when developing these tests.
Our goal is for business-level users to easily understand the extent of functionality coverage through reports like this, and to quickly identify areas that may need improvement.
GSoC 2023: An effective unit & integration test strategy for OpenMRS3
Introduction
OpenMRS consists of several micro frontend modules and repositories, most of which have unit and integration tests written by individual developers. However, these tests exhibit inconsistencies due to the diverse testing strategies used by different developers. To address this issue, there is a need for a consistent and comprehensive test strategy or framework for the unit and integration tests of OpenMRS3, aimed at achieving a high level of test coverage.
Objectives:
Implementing an effective unit & integration test strategy for OpenMRS3.
Expectations:
Develop a comprehensive testing strategy that can be applied to all OpenMRS3 micro frontends.
Determine what to test (e.g. In react → props, state, rendering, event handling, error handling)
Ensure test coverage (e.g. edge cases, positive and negative scenarios)
Document the strategy
Outline the necessary tests based on the strategy (including a draft for a single repository in the project proposal)
Upgrade existing tests to align with the new strategy
Implement any missing tests
Resolve any bugs in the current tests.
Further improvements (Optional):
Improve the code quality testing mechanism (ex: eslint)
Project Size:
Medium
Skills required:
Familiarity with OpenMRS microfrontends (including setup and directory structure)
Background in microfrontend development
Proficiency in testing techniques
Final Outcome:
A robust, well-documented unit and integration testing strategy for OpenMRS3 microfrontends
To be used as a reference by developers in future development efforts.
I raised a PR adding patient-flags into RefApp 3.x as an initial task for the ANC prototype but merging is blocked for now because the backend module is not-worthy.
As a matter of fact, I personally had to do some tweaks with this module for successful getting of the flags from the backend.
@jnsereko Thanks for this work. We’re going to hold off on merging this for right now not because the frontend part is in any way not what is called for in the designs, but because I think the backend module needs to be re-engineered before it’s ready to be integrated into the RefApp. In particular, I want to be sure that it performs well enough. Once we have that added to the RefApp, we can merge this PR in.
(PS Validating and re-working the backend module for this would be an excellent GSoC project…)
I have come up with some improvements for the O3 form builder that I believe could enhance its functionality. These include
Reference forms
Ability to edit answers (Same as Ampath)
Ability to edit concept mappings (Same as in Ampath)
Ability to rearrange questions (This was suggested by Grace, where the user can rearrange the questions by dragging)
However, these improvements may not be sufficient for a 175-hour project, and I am open to any suggestions for further enhancements.
As I will be on vacation this summer, I’m interested in mentoring a GSoC project this year, if possible.
I am particularly interested in the following projects
Thanks for your interest in becoming a mentor @kumuditha!
@dennis, do you have any suggestions on how to turn the form builder into a GSoC project?
Alternatively, do you have a specific project in mind that Kumuditha could mentor?
I looked into O3: Draw on Body Diagram project idea and I think if we can scope it down to mark certain areas of an upload diagram – either with a certain shape, or a single point – and provide support to it with a data structure that can facilitate those meta data we’ll have a well scoped idea for medium sized project. Storing an array of x, y coordinates with the description will be a simple way of achieving this goal, This way we will be able make nice looking and interactive diagrams. There could be different ways like storing them within the digram itself through vector files too. We can put the dynamic drawing as an optional objective of the project and extend the basic implementation to include them later on.
I think a good proposal for this project should include,
A good requirement analysis
A good explanation on how to handle different image types
Good data structure design to store diagram meta data
Plans on,
How to handle the diagram upload and store
How to handle the editing of the diagram on the frontend
How to render those diagrams properly with the edits
Set of wireframes for the UIs
The list of API endpoints that is needed to support those UIs
Even though I won’t be able to write proposal myself since I’m working as a full time SE, I’m very much interested in getting involved in this project to help out whoever that wants to submit a proposal for this idea or even mentor the project if needed.
I’m also interested in 03: Responsiveness & Tablet-based Needs for OpenMRS 3 project. The main objective of this project is to make the responsiveness of the application consistent throughout devices. Since OpenMRS 3 is developed on Tablet first, I couldn’t be able to find many issues on the tablet view in the patient chart. But we can improve the responsiveness in other modules in the application such as Fast Data Entry, Corhort builder and Form builder.
Optimizing the code for better performance. Remove unused code, and optimize loops and conditions.
Test the application on different devices with different screen sizes, and resolutions to ensure the interface is responsive and functions properly on all devices. This will help us to identify more bugs in the interface.
Here are a few things that I think a good proposal should contain.
Requirement gathering (Identifying bugs/issues)
Identified issues in Tablet-based screens
Identified issues in Laptop screens
Implementation plan for
Tab based responsiveness
Laptop based responsiveness
Wireframes depicting the designs
Skills
React
Typescript
Javascript
What do you folks think?
I would love to help make it a success by offering my assistance as a mentor or in any other way. Please let me know how I can be of help, as I am enthusiastic about contributing to this project in any way possible.
Hey @kumuditha !
Interesting capture of the project needs and requirements. Just want to clarify, are you interested to contribute as a developer contributor or as a mentor?
O3: Search Patient Chart feature
O3: Draw on a Body Diagram
O3: Print feature
O3: Built-in User Onboarding:
O3: Migrate forms to React Hook Form