Defining Efforts Needed to Include Growth Charts In the Reference Application

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.

  1. 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.
  1. Another Suggestion was to Install the SMART apps into the reference apllicaton, Which will use FHIR resources to provide services.

cc @jennifer @c.antwi @dev5 @dev4 @dev3 @dkayiwa @burke @k.joseph @ball
Looking forward to see your submisions.
Best Regards
Mutesasira Moses

1 Like

Thanks @mozzy for leading this on. This is also in relation to another post Contributing code to the Core: Approaches /Mechanisms We Need Your Input

@mksd @ssmusoke @ningosi

Growth charts are specific to paediatrics, that’s a very implementation-specific feature.

It should be made easy to obtain growth charts with the Ref App, but it should not come out of the box with the Ref App.

There is already a charting widget made in Angular (I believe that it lives in Core Apps), isn’t that enough to cover most use cases?

Leveraging my ignorance & @mksd contribution

How about this:

  • Charts: add to coreapps module in the dashboard widgets - these should be generic
  • Growth Charts metadata: reference-application-metadata
  • 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

1 Like

I do not think we need a new module for this as that is too much overhead

+100

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.

1 Like

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.

@ssmusoke, thats perfect , but from he PM call it seemed to be duplication of effort. We should table this down in the design call.

Great discussion.

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.

3 Likes

@ball , what do you think of the idea of building this into our existing modules VS Harvesting the whole openmrs-module-isanteplus into reff app ??

we can’t have the entire isanteplus module in ref app since it’s implementation specific, we can only pull that feature in particular

1 Like

@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.)

1 Like