Background
During consultation, a doctor may want to view historical values of a parameter while filling clinical observation templates. For example, during a diabetic follow up consultation, she may want to see the history of vital values (Systolic BP, Diastolic BP, Weight etc) right inside the template, while filling the template. Including the values entered by a nurse just before consultation using another template (a vitals template).
Apart from observations, doctor may also want to see certain lab test result values and its history, right inside the observation templates.
On a related note, for those chronic disease patients who have been receiving continuous care, doctor may want to set personalized target values for certain parameters like weight, Systolic BP, Diastolic BP, HbA1c etc and view them in relevant templates while doing follow up consultations. Currently, there’s no requirement to automatically calculate the target values using any algorithm though. Instead, doctor will enter and update target values for a patient using clinical templates.
Proposal
We are proposing to show the historical values of a field in a template, if required, just under that field, with a history link to show and hide. See an example template with history below.
We do not want to show history for all the fields in a form, so we will have a configuration to enable history for a form field. We will have a JSON config param, that can be set from the form-builder UI.
Enable history (Yes/No).
Also, we are proposing to show historic values of certain member fields of a template, displayed in a flowsheet (pivot) on the top portion of that template. See an example below.
We do not want to show all the fields of a template inside the flowsheet.
Only those fields that are not meant for data review will be added to the flow sheet. If a form field is meant for data entry then it should not be added to the flowsheet. We will have a configuration for this setting that can be done using a JSON config param, again set from the form-builder UI. Show in Flowsheet (Yes/No)
With the above two configurations, we will be able to have personalised target parameters as mentioned above. We would define new concepts for target parameters: For example Target Weight, Target Systolic BP, Target Diastolic BP etc. Will capture them as observations using a clinical template(say target vitals). In whichever forms these values have to be displayed for review, will add them as member fields with the config Show in Flowsheet as Yes. See an example below.
I would discourage any major (and this seem major) work onto the Form 1.0 behavior. We don’t want to be maintaining the Forms 1.0 codebase, which is already really difficult to maintain.
In case you didn’t know, we now have a Forms 2.0 way of building forms, which uses react and is based on component model. Showing past value (only one by default and a link which will open another page to show their historical values) was one of the requirements (we don’t have it yet). I would encourage discussing and providing this feature onto new Form 2.0 controls.
Thanks for your comments. The plan is to build this on to Form 2.0
and have the configuration come from the form builder as a control property. Let us know if you have any further comments.
@sandeepe - just clarifying, we don’t have the feature in Forms 2 yet to show the past values. But we would ideally be more inclined to enhance the existing Forms 2.0 controls.
@angshuonline we are planning to develop this ourselves, and would like to contribute this to Bahmni codebase. Is this going to conflict with your future plans/roadmap? Looking for your suggestions.
@angshuonline, are there any relevant design/planning docs showing the UX thinking we had done that @sandeepe can review?
@sandeepe, it would be great if you can work on this feature as a part of the core Bahmni application.
The first step is to start a public conversation (as is happening here).
The next step is to write down a more explicit statement of what you’re proposing, for more detailed feedback. (You might do this as a google doc that you make world-commentable.)
Some comments of my own:
the mockups/screenshots are too small/blurry for me to read well
Obs history
In general I like the idea of (optionally) allowing the user to see history of prior recorded observations
I have always envisioned showing this history to the right, not below.
I’m not sure it’s good enough to do this at the single concept level. In the example you’ve given here of blood pressure, it would provide better user experience to show a history of Systolic/Diastolic together, not individually.
Flowsheet:
It sounds like you’re suggesting that all forms would have a flowsheet element, but I would suggest that instead you introduce a flowsheet control which can be optionally added to the form just like an obs control can. (Maybe that’s what you’re suggesting already.)
I would also be interested in reviewing these and contributing ideas where I can, if I could see the images more clearly (and any easily-distributed functional design statements).
I agree with @darius that the right side is where I’d most expect the historical values — which also allows the possibility of having your flowsheet line up with the entry values as a table on the right side of a page. But I can’t quite tell with the current screenshots.
We are on a tight timeline, so we have gone ahead and done 80% of the work already, but we are still open to make amendments as per your suggestions.
Most of the comments that are raised above have been addressed.
I am still putting the history component below the field, because there is not enough space on the right. There will be even less space on tablets.
@jteich@darius and anyone else who is interested, please review the document above and provide suggestions.
@apaule I have left comments in the document. I will probably compile another reply on this thread and raise it for contextual discussion in this thread. There are few things I think are straight forward, and we can decide on enhancements and addition to the existing codebase. However, for some things like “HTML”, lets have a design discussion. It will be good if you can create relevant cards and PRs specific to enhancements.
I actually have a design suggestion for you
Forms 2.0 and Form builder was designed with the idea that others may plugin their controls arbitrarily. The idea was that anyone can develop their own control and this need not be bundled with the core distribution. We would like to retain that design. Can you develop some of the controls that you are seeking that way? There are already ways to register controls and designer classes. There might be some hooks and extensions that might need to be provided from the product side, and I would rather prefer this approach.
This approach will also help implementers not be fork codebase and yet able to plugin their controls and if accepted such a control can be contributed back to Bahmni, whenceforth it will come distributed with Bahmni.
I would also suggest that you call for a subgroup discussion to discuss the design and approach.
Thanks for the reminder, I just made some comments.
@apaule, I really appreciate the approach that you’re taking here, of requesting and incorporating feedback. It’s a model of what open-source development should work like!
@darius this is not finished yet. Because of project pressure, we had to roll it out to the client without many changes that were proposed during the review. In September, @sandeepe is planning to work on the review comments and merge it to Bahmni.
