I’m writing to say how much the O3 Growth Chart project for GSoC 2025 interests me.
I see how important this capability is for paediatric care inside the OpenMRS environment after looking over the requirements. I’m thrilled to take the lead on this and am totally dedicated to seeing this project through to completion.
I’ve already written a thorough project proposal and started integrating the Growth Chart app with the O3 Patient Chart to gain a jump start. My objective is to develop a solution that satisfies our implementers’ clinical demands.
Here is a screenshot of the implementation so far:
I have attached my project proposal below. I would be incredibly happy to receive your guidance, feedback, and inputs to ensure the design and timeline align with the community’s vision.
I look forward to arranging a meeting with the mentors to discuss the technical approach in more detail and start working on the next steps immediately.
It would be great to have an updated version included in the O3 framework! Have you checked out the SMART on FHIR version here: Growth Chart
I would think that @ball would want to comment on this, too. My only recommendation would be to use black for patient data as the colors on the graph are quite distracting. Viewing data both in raw form and percent/z-score would also be helpful, but leave that commentary to practicing pediatricians
Thanks for bringing this up. Partners In Health uses the growth chart with OpenMRS RefApp2 for Haiti, Sierra Leone and other implementations. This was written for iSantePlus by Kaweesi Joseph (may his memory be a blessing) and others. The code has been awesome, bug-free, and flexible. It allows for multiple CDC or WHO growth charts. It is an excellent example of code written by the community and shared with all. A great example to start the new year. And even better to get this implemented with O3.
Thank you both for the incredibly insightful feedback! @akanter@ball
It is really motivating to hear how important this functionality is for the community and its history in implementations.
@akanter — Thank you for sharing the SMART on FHIR reference. I will definitely study it to ensure we align with industry standards. Regarding your design feedback.
@ball — Thank you for the historical context. It is an honor to work on modernizing a tool that has been so reliable for the community. I will closely review the 2019 thread and the original RefApp2 code to ensure the O3 version retains that same level of flexibility and bug-free reliability.
Could you please review the Epic and its child work items and let me know if anything needs to be corrected, refined, or changed?
@dkigen I would looking the guidance on the best approach for pushing the implementation to the main branch. I came up with 2 ideas.
Create a single feature branch (e.g: growth-chart) from main, implement each child work item incrementally in to that branch, and finally merge it into main.
Create a separate branch for each child work item from main and merge each one individually into main.
Could you kindly advise which approach would be preferred for this project?
I have started implementing this project and raised a few PRs for the work done so far. As @nethmi suggested during the PR review, I am now working to combine this work into a single PR.
I have two questions regarding this implementation.
Q1 - Feature flags
What is the recommended way to implement feature flags for patient chart features in O3?
Should this be done via the configuration framework / app config, or is there an existing feature flag utility or pattern I should follow?
Q2 - Backend
My initial implementation placed the WHO standard data as static JSON within the frontend module, but during PR review it was pointed out that embedding this data as static JSON in the frontend is not ideal, and that initializer/content packages would be preferable for configurability. However, I’m unsure how best to approach this since there’s currently no backend module managing this metadata.
Could you advise on the recommended way to handle this challenge, particularly whether introducing a backend module?