design: weekly email report

[jniles]

We've talked about email reporting for a long time, but we'll need to start somewhere to actually refine the procedure. I propose that we begin with a weekly email report that we hand-craft ourselves. Then, following client feedback, we can remove fields, add fields, or change the frequency as needed.

Prior Art For reference and inspiration, see an email from bhima 1.x below: Fig 1: Daily Email Report from 1.X

Technical Design In 1.x, we used child_process.exec() calls to the mail command to send email. This meant that all error handling, retrying etc, was handled ourselves.

This time, I suggest we leverage mailgun for emailing, retries, bounces, etc. It has the following advantage:

1. Allows us to monitor the progress of sending mail from afar. In 1.x, we had to physically be on site to update the recipients. With mailgun, we won't have to.
2. Manages mailing lists for us.
3. Both @sfount and I have used it extensively.
4. Has a nice nodejs library that is actively maintained.

Report Design These are the following questions the report should address. The can be altered as the report is developed if the information is not present or shown to be irrelevant.

1. How many users used the application this week?
2. How many patients were registered this week, categorized by age range?
3. How many payments were made this week? How does that compare to the average number of payments per week?
4. How much money entered the main coffres? How much exited?
5. How many invoices were made versus how many were closed (paid in full)? This should filter out credit notes.
6. What were some of the most purchased items this week? This is defined as sold to the most number of patients. What was the average quantity and price of those sales?

[sfount]

This is a great jumping off point for integrating emails. I second the recommendation to use mailgun for this feature.

Another thing that may be useful to see on a weekly basis is how many patients are being invoiced only once or to surface patients that seem very similar to previous patients. One of the major practical problems during installation has been the re-registering of patients so a metric that might help reduce that may be useful to provide.

[jniles]

Hey, that's a good idea. Or even patients that are never invoiced. Both those would provide insight into how the posts are relating to each other.

[DedrickEnc]

Yes, I think it is time to have this report but I have a question : We had already a weekly report and some items inside instructed by Mr Larry, how will we handle that? Because with the Bhima 1.x weekly report we was grouping patient registration by day also invoicing and payment was grouped by day? @jniles you proposed to group patient registration by age so will we have a nested group?

[jniles]

@dedrickenc, the report instructed by Mr. Larry was tied specifically to IMCK/HBB - two columns for the two projects there. That works well for IMCK, but we should try and get a more general email report. If you have documentation about what Larry wanted in those emails, it will be useful to see as we design the next generation.

Since we've figured out PDF generation, we will probably be able to use the dashboards @mbayopanda is building in #1692, and simply attach them as PDF reports for administrators, sponsors, etc.

Because with the Bhima 1.x weekly report we was grouping patient registration by day also invoicing and payment was grouped by day?

For daily reports, it would make the most sense to simply look into the BHIMA application. I think we can show really powerful analysis with weekly reports, at least to begin with. If our clients as for a daily report, we can implement that following this model.

@jniles you proposed to group patient registration by age so will we have a nested group? Nested groups would be really hard to implement in an email in a readable way. I guess I was imagining:

< 5 Years Old	5 - 18	18-30	30-60	60+ Years Old	Total
15	20	0	15	10	70

Male 65% Female 35%

---

The idea is to get a product into our clients' hands as quickly as possible so they can give us feedback on what they wish to see.

[jniles]

Additional prior art: #677