Cht-core: Allow for default values in JSON forms

[benkags]

Is your feature request related to a problem? Please describe.
We currently do not have a way of providing a fallback value in a JSON form if the user does not provide it when submitting the report. This is a pain in situations where the text form SMS format is just the form.

Describe the solution you'd like
For a field that is optional, allow for the config to set a default value instead of having it as null.
The CDC-MOH-KE project has a candidate use case. Submitting a report (signal) requires that the user sends only one character e.g 1. That will register a patient record but because patient_name isn't provided in the report, that contact is created without patient name and as result, a list of patients without names is displayed as in the screenshot below.

Reports view has 'Unknown subject' for the patient name.

_Suggestion of how this would work_
Using the example above, the JSON form config would look like this:

"forms": {
 "1": {                                                                                                                                                                                                                                           
    "meta": {                                                                                                                                                                                                                                        
        "code": "1",                                                                                                                                                                                                                                   
        "label": {                                                                                                                                                                                                                                       
            "en": "1"                                                                                                                                                                                                                                    
        }
    },
"fields": {
    "defaultValue": "<string> or <traslation_key>"
 // would be nice if it supported variable expansion (mustache contemplating) for contact & report variables [just an idea, don't know how complex it would be to implement this]
 }
...                                                                                                                                                                                                                
}

Describe alternatives you've considered
I couldn't find a workaround.

Additional context
Provided above.

This issue was originally medic/medic-projects#6356

[benkags]

Given the effect on the user interface, with a lot of blanks on the user's (CHA) profile, we have been holding off giving county and sub-county teams access to the web app for contacts management until we have this feature available.

[benkags]

cc @Maigua

[SCdF]

tl;dr; I talked individually to @benkags and @abbyad. This is actually a more broad need for case centric workflows. We need to take a step back and work out the best way to achieve this in our system, and from there identify changes we may need to make in the product.

---

So I talked to @benkags. This ticket is a proposed solution to a much more generic problem. Here is what they are trying to achieve:

• CHWs are meant to report "signals" in their area, which supervisors are then meant to investigate and deal with (somehow: I'm guessing XFiles) these signals, and report that back into the app
• Signals are a number from 1 to 8
• CHWs send in SMS from feature phones, supervisors at least right now use Medic Collect

The proposed flow is:

• CHW sends in a very simple SMS, with one digit: 1 to 8
• The system creates a new event for that signal, giving it an ID.
• It sends a reply back to the CHW to confirm that it was received, and another SMS to the correct supervisor telling them there is a signal of ID abc and value 1 to 8
• The supervisor then uses that ID to report about that signal

Bernard has attempted to implement this as a patient workflow, where every reported signal is a new patient. This gives him a unique id: the shortcode that gets generated by registering a new patient. This ticket is reporting a flaw in that plan: that Unknown Subject is listed as the patient name instead of something useful, such as Signal 12345.

However, what is being described above is a case centric workflow, which we should still support! It may be that we just need another way of generating ids that doesn't require patient flows (like a case id generation transition), or it might mean something else. @MaxDiz / @michaelkohn I'm punting this one back to scoping. We need to have a conversation about what is written above, and where the gaps are. There is also the question of whether or not supervisors have to use Collect. Removing collect removes the need for hooking up SMS in this way.

[abbyad]

We are facing the same "unknown subject" scenario while reworking the event based surveillance to include Covid, despite not using Collect in that workflow at all.

@senseibara and @michaelkohn can provide more details of that workflow, but it appears that the requirement is for the CHT to handle _case_ reporting, especially when it is initially triggered by an SMS. Some specific requirements could be that forms can be configured to be registrations that provide a case number, similar to how we create patient IDs, and also associating case reports to the submitter's place.

[SCdF]

@abbyad so are we OK with closing this ticket and replacing it with a different ticket once the conversations you're going to be having have resulted in concrete work? Are you able to coordinate that?

[kennsippell]

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 second most important issue to prioritise for COVID EBS scale-up response behind #5817.

[abbyad]

From my understsanding, solving https://github.com/medic/cht-core/issues/6286 would make it so that reports without a patient ID would be associated to the sender. That would appear to resolve the "unknown sender" symptom in this issue.

Also, creating case-based IDs in https://github.com/medic/cht-core/issues/6291 would make it so that you don't need to create people, meaning that you wouldn't get blank people.

If that's the case, this issue seems superceded by those two newer issues. @benkags, is that your understanding too? If not, can you clarify how these would be useful on their own for EBS?

[SCdF]

@kennsippell is your comment taking account my discussion above with Bernard where it was determined that we probably don't want this ticket at all, or is it just copy / paste?

[kennsippell]

@SCdF I posted that here to amplify the prioritised list of bugs as reported by Bernard and agreed upon by the CDC-DRSU squad as of Apr 8th. This list was created after the note you wrote above, so perhaps there remains a disconnect.

You summarized this issue nicely -- "This ticket is reporting a flaw in that plan: that Unknown Subject is listed as the patient name instead of something useful, such as Signal 12345". Your solution seems to be based on "rescoping" + potentially avoiding Collect.

I'll re-iterate this comment from @abbyad which is a possible source of disconnect

We are facing the same "unknown subject" scenario while reworking the event based surveillance to include Covid, despite not using Collect in that workflow at all.

Perhaps you can help us understand concretely how to avoid this issue without collect, as you proposed? The prioritisation of this issue is a bit complex because there is the CDC-DSRU EBS configuration but also a COVID response EBS system which is slightly different. The COVID response EBS system aims to work as a part of existing configurations/hierarchies, and so these "unknown contacts" in the hierarchy have become harder to hide and thus it is more important we find a solution.

[garethbowen]

After talking to @michaelkohn I'm confident that a solution to #6291 will solve this so I'm going to close it as a duplicate. Please let me know if there's anything here that's not captured by other issues.