What feature do you want to improve?
When a client registered in the system submits a text form with the phone number in their profile, we are able to associate that report with that person. However, the report does not appear under their reports, in the reports section on their profile which I interpret to mean that we are not able to associate such reports with the contact when fetching a contact's reports. I suspected this had to do with the lack of patient_id in the report and to investigate this hypothesis, I added it to the report manually and viola! The report now appears among a contact's reports. This affects schedule clearing logic in schedules where bool check expects such reports.
To Reproduce
Steps to reproduce the behavior:
Describe the improvement you'd like / Expected behavior
When the patient id is not available in a text form report, append it by looking up the patient profile using the phone number.
Describe alternatives you've considered
n/a
Additional context
App version: 3.8.0
Instance: local docker setup
@benkags as this is maybe a bug, can you add reproduction steps here please, including any configuration changes needed
@SCdF I've updated the ticket description to add some steps to reproduce.
I think this is a bug too. Scheduling for 3.9.0 for investigation.
I'm not sure I understand. We're supposed to consider a subject-less report submitted by a known contact to actually be _about_ that contact? Have we ever supported this?
@benkags Is this for messages coming from a patient or a CHP?
In this case, the messages are coming from the patient.
@dianabarsan yes. We could make an opt-in feature maybe to still allow for subject-less reports to remain subject-less.
I don't think we've ever supported this. cc @garethbowen ?
Is this a new feature request?
Yes you're right, it's a new feature. Sorry I misread this the first time through!
This feature is very relevant to the I-TECH Zimbabwe(scale-up) project piloting in about a week or two from now and we won't be able to support specific workflows without it. The workflows have to do with the ability to schedule and clear tasks and schedules using reports clients send to the system. The report is a TextForm that is just the form name e.g a '1' or a '0'. The alternative to this would be to have the client send in the reports and their patient id and that introduced serious usability concerns.
Hi @benkags this is not a reasonable or achievable timeframe for a feature request. Happy to get on a call with you and @kennsippell to try to troubleshoot/figure out alternatives. Let's move this conversation to slack
We are scaling our existing EBS systems to new counties and spinning up new EBS systems for our COVID response. Project teams feel this was the third most important issue to prioritise for COVID EBS scale-up response behind #5817 and #6148.
Not in 3.9.0 because immediate needs can be solved with ability to generate short codes (similar to patient_id) in reports #6291, or by using rapidpro as middleware.
This issue is quite different from the case-based issue and RapidPro isn't much of an option for the ITECH project that this is required for due to budget limitations. @Maigua can comment further on this.
@benkags correct, we don't have the budget to support Rapidpro integration during this project period.
OK so to summarize this feature: An SMS that is considered a form (ie starts with a configured form name and so isn't considered plain text), but does not have a patient_id and is not a registration (eg N Sally does not count here) is considered about the person attached to the phone number used to send the SMS
@benkags please confirm that is the breadth and scope of the problem we want to solve.
Affirmative @SCdF
Having that criteria is helpful. We should consider how it fits with these questions from the case-based workflows issue:
- Can we see these reports on contact profiles? The contacts profiles only show reports about the contact. This makes sense in some contexts, but with case-based reporting it could be anticipated that all the reports be seen on the profile of the person that submitted them -- both Michael and I had this implicit expectation when we were testing it.
- How do we deal with self reporting? Since these reports are not currently shown on the person's profile, it is clear that this issue doesn't replace issue #6286.
Since case-based reports use a new add_case registration, but don't get associated with the submitter or their profile, it seems to indicate that they will still be excluded with the criteria listed. It raises the question of whether case-based workflows are mutually exclusive from person-centric flows? I suspect not, and we will soon see scenarios where we want both a person id and a case id assigned to a report.
An example of this scenario, which would be in the projects that @isaacholeman mentions in https://github.com/medic/cht-core/issues/6306#issuecomment-607276628, is that a patient self-report creates a case that someone else would respond to via a text channel (where we don't have the UUID). Associating reports to each other has been a specific request for app workflows for data analysis (eg saving a specific pregnancy ID with the visit and delivery reports).
In summary, a requirement for this issue is that case-based reports should also be associated to the submitter if configured as such. We can open that as a separate issue, but it was thought at some point that this issue would solve for the self-reporting scenario too.
Any work on this ticket should be charged to: 117 I-TECH-Zimbabwe
Ready for AT in 6286-sender-as-patient
Documentation here: https://github.com/medic/medic-docs/pull/213/files
LGTM - Pinging @benkags to have a go at it and see if that's what he expect before closing this off.
LGTM.
Thanks everyone!
Merged.