Add UI to visualize M&E Indicator Data

[danfuterman]

See #14.

Mockups:

[danfuterman]

In the mockups above, we are able to filter the results by Endpoint. I don't think this is a requirement for now, and the indicators that have been defined for now do not cater for this. We should still be able to filter by site (i.e. origin) though.

[psbrandt]

In my opinion, being able to filter by endpoint makes sense for a lot of use cases. Even if we don't add that feature in right now, I think we should keep it in mind when we're designing stuff.

[danfuterman]

@psbrandt Agree, it would be useful. @waynechelliah, @carlsbox, @rcrichton - The indicators that have been defined for now do not send stats on a per-endpoint basis, and we would not be able to filter by endpoint. My suggestion would be to leave this as is for now, and look at possibly extending the XML/functionality to include this feature at a later stage.

[ruzdezzy]

@Daniel agreed for now we could leave out. On Aug 28, 2013, at 10:43 AM, Daniel Futerman wrote:

@psbrandt Agree, it would be useful. @waynechelliah, @carlsbox, @rcrichton - The indicators that have been defined for now do not send stats on a per-endpoint basis, and we would not be able to filter by endpoint. My suggestion would be to leave this as is for now, and look at possibly extending the XML/functionality to include this feature at a later stage.

— Reply to this email directly or view it on GitHub.

[rcrichton]

@danfuterman @ruzdezzy I agree, it would be very useful but perhaps we should get this working first then look to extend it as you guys have said.

[danfuterman]

Looking at the XML format that will be used for the current indicators, we would be able to filter the results by Queue. in place of the Endpoint filter, I will add a Queue filter, with the following options:

• All
• Processing Queue
• Archive Queue
• Error Queue

[danfuterman]

Attached screenshot of current solution that has been implemented. Functionality contained in Pull Requests #20 & #21.

[danfuterman]

The next step would be move from table to graph. Further extensions to this could be to include the the secondary measure (For each encounter type what is the (Min, Mean and Max) number of observations collected), and if needed, include the option to filter the primary measures by queue type (the indicator data we are sending is split into archive/processing/error queue values - for now we are calculating the total as the sum of all 3 queues. The other indicator elements that we are not using for now are the following:

    <dataElement name="totalEncountersSaved" dataType="int">[###]</dataElement>
<dataElement name="totalPatientsSaved" dataType="int">[###]</dataElement>
    <dataElement name="totalPatientsUpdated" dataType="int">[###]</dataElement>

     <dataElement name="minResponseTimeMS" dataType="int" units="msec">[###]</dataElement>
     <dataElement name="maxResponseTimeMS" dataType="int" units="msec">[###]</dataElement>
     <dataElement name="avgResponseTimeMS" dataType="int" units="msec">[###]</dataElement>

We could use these values to extend the reporting functionality to include some of the Sandbox indicators that were defined.

[carlsbox]

HI Dan,

Any chance we could include the (%) value next to the received and not received values, i.e. 6 (30%) e.g.

cheers, Carl

On Mon, Sep 2, 2013 at 11:04 AM, Daniel Futerman notifications@github.comwrote:

The next step would be move from table to graph. Further extensions to this could be to include the the secondary measure (For each encounter type what is the (Min, Mean and Max) number of observations collected), and if needed, include the option to filter the primary measures by queue type (the indicator data we are sending is split into archive/processing/error queue values - for now we are calculating the total as the sum of all 3 queues. The other indicator elements that we are not using for now are the following:

<dataElement name="totalEncountersSaved" dataType="int">[###]</dataElement>

[###]

<dataElement name="totalPatientsUpdated" dataType="int">[###]</dataElement>

 <dataElement name="minResponseTimeMS" dataType="int" units="msec">[###]</dataElement>
 <dataElement name="maxResponseTimeMS" dataType="int" units="msec">[###]</dataElement>
 <dataElement name="avgResponseTimeMS" dataType="int" units="msec">[###]</dataElement>

We could use these values to extend the reporting functionality to include some of the Sandbox indicators that were defined.

— Reply to this email directly or view it on GitHubhttps://github.com/jembi/openhim-webui/issues/17#issuecomment-23648427 .

Carl Fourie Assistant Director of Programs, Jembi Health Systems | SOUTH AFRICA Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17 E-mail: carl@jembi.org

[danfuterman]

@carlsbox - yes, this will be easy to add.

[danfuterman]

@carlsbox - most recent screenshot, including % values for processed/not processed indicators, and displays 0 values, rather than 'None'. Functionality contained in Pull Requests #20 & #21.

[carlsbox]

Hi Daniel,

Looks great. A quick question here is '0' meaning no messages were sent on the day or '0' means that the system hasn't received the stats for that week? 0 is a very difficult number to work with as it can be misleading.

Please lets make sure we are using 0 for "no messages sent" and another phrase to indicate that the data hasn't been received yet.

Cheers, Carl

On Mon, Sep 2, 2013 at 12:30 PM, Daniel Futerman notifications@github.comwrote:

@carlsbox https://github.com/carlsbox - most recent screenshot, including % values for processed/not processed indicators, and displays 0 values, rather than 'None'.

Functionality contained in Pull Requests #20https://github.com/jembi/openhim-webui/issues/20&

21 https://github.com/jembi/openhim-webui/issues/21.

[image: reports view ii]https://f.cloud.github.com/assets/1052668/1066729/799f9f6c-13ba-11e3-9639-c7aed126ef5d.png

— Reply to this email directly or view it on GitHubhttps://github.com/jembi/openhim-webui/issues/17#issuecomment-23652435 .

Carl Fourie Assistant Director of Programs, Jembi Health Systems | SOUTH AFRICA Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17 E-mail: carl@jembi.org

[danfuterman]

thanks @carlsbox, I have already addressed the issue of 0 / Null / 'None' in #22. For now, I have switched to 0 to make it visually clearer, but this would need to be handled better once actual report data is being sent to the HIM.

[hnnesv]

Merged the table functionality. Issue is still open for the remaining graph functionality.