Hello community , As part of the Reference Application 2.10 Release Road Map (Feature No. 3), we would want to include a Growth Chart in the Ref-App 2.10.
Following the discusion from Growth chart in Reff-app, Here is the Coclusion that was reached at but need a little further Discussion on it.
We can Harvest the openmrs-module-isanteplus from IsantePlus rather than writing a whole new feature from scratch.
Here are a few things to look at.
The openmrs-module-isanteplus contains the Growth Charts that we need but also contains other features ,some of which we already have in the Reference Application like Weight’s Graph.
We need to define the whether whether we shall give the module a new name(Artifact) or retain the current name.
We need to define whether we remove some of the features we may probably not need from the module or we take it all as it is.
We should also probably look at the legal implications of Harvesting and Modifying this module into reff-app.
Another Suggestion was to Install the SMART apps into the reference apllicaton, Which will use FHIR resources to provide services.
Actual logic and data: openmrs-module-referenceapplication - add a new form like Vitals to capture and display the information plus the workflows needed
Demo data - update to include some random growth chart data
I do not think we need a new module for this as that is too much overhead
i think growth charts are different from the charting widget in coreapps, i believe although not good enough in a new module, this can be part of coreapps, maybe building these using the existing charting vs harvesting should be the first discussion.
It looks like the discussion is leaning towards reworking Chart Search maybe? Chart Search is an important module that could do with an overall upgrade.
chart search though is about something else IPV, searching for data within the patient chart vs growth charts which consume some of that data that chartsearch tracks
It might also be worthwhile to design the concept of multiple growth charts and a UX to have the clinician pick the appropriate growth chart. Not every country uses the WHO charts (China, India) and some medical conditions (Down Syndrome or Turner syndrome) have specific growth charts as well.
I wonder what the mechanism would be to define, install, or select specific charts per installation.
we could change that ui in some way to avail or not that select option by use a global property to display one at a time or maintain the select ui, by default displaying one either from WHO or CDC. for those using others besides CDC and WHO, we could avail a way to install their metadata and the graph would handle it similar as it treats these 2
From the PM call today , it seems the conclusion was going back to Harvesting the whole openmrs-module-isanteplus , to make use of the rest of the features ,in addition to the Growth chart.
We are going to do a little deeper investigations with @c.antwi in the isanteplus module ,and the different feature usage, and come up with suggestion which will be again brought into discussion in the design call.
For our pediatric patients, the weight/height/bmi graph isn’t enough, @mksd. It doesn’t show what the relationship of the patient data to “normal” or percentile values which are shown on the growth chart.
It would be very cool to have a customization page which allows implementers (without java coding) to multi-select the growth chart(s) shown (ie. WHO, CDC, India, China, Downs syndrome, etc). For MVP, you don’t need all of these. It might be enough to hit the most common 2 growth charts for OpenMRS implementations.
@mozzy Agree with @k.joseph. We only want to bring in the growth chart from iSantePlus. (iSantePlus is the Haiti MoH OpenMRS implementation which includes lots of forms, metadata, dashboards, and functionality.)