How to set/unset that changes to a record require providing a reason for the change?
Project Setup tab -> Enable optional modules and customizations section -> click on "Additional customizations" button -> check/uncheck "Require a 'reason' when making changes to existing records?"
Require a 'reason' when making changes to existing records?
Require users to enter a reason (200 character max) in a text box when making any data changes to an already existing record on a data collection instrument. The prompt is triggered when clicking the Save button on the page. Any 'reasons' entered can then be viewed anytime afterward on the Logging page.
And if can be useful:
" The "Require Reason for Change" feature, which can be enabled in the
Additional Customizations popup on the Project Setup page, no longer requires a reason when
adding data to an empty data entry form (i.e., having a gray status icon). In previous versions, it
would prompt the user for a reason even when adding new data to a form that had never had
data entered before, which was deemed as unnecessarily aggressive, thus making the feature
less useful to many users. So now in the event that data has never before been entered on the
current instrument for a given record, the user will not be prompted for a reason (that is, until
they return to the instrument at a later time and add/edit/delete data). Note: The Regulatory &
Software Validation Committee has reviewed this change, and has approved it for general use."
"It is true that GCP does not state this very strongly (GCP is the vaguest of all guidelines I would say)
However, it is not only GCP we need to comply to. Depending on the study, you also need to take FDA and GDPR into account. Nevertheless, clinical trials that are inspected generally are not likely to receive a good review without having implemented two factor authentication and solid processes of its management."
Well I would still say you can achieve that (user authentication) at the device level.
Obviously passwords within ODK would help but that's a long way off I think @LN?
Most of our trials are not FDA stuff so their specific requirements don really matter as much - as long as we are GCP compliant that's what matters.
And whilst you can turn on/off reason within Redcap it remains interesting that it's not compulsory - my guess is many people have that turned off - it has been on all the projects I've looked at.
I think here we are trying to develop something that works for all the community not solely for LSTHM.
Being flexible is always a good thing Maybe after Brexit you should consider FDA more (Joking)
how many of these were CT? I've seen this ON in several projects. But anyway in odk it will be condigurable as well (track-changes-reason=true)
I'd like to suggest a way forward on change reasons. @dr_michaelmarks' comment and @aurdipas' user story suggest that there isn't a hard requirement for question level reasons for change.
Also, there is debate about when to ask for question level reasons and what to do with multiple questions per screen. Given all this, I think we should ship the least intrusive addition first and get feedback from @dr_michaelmarks and other users.
I propose we parameterize the attribute (track-changes-reasons). We can start with the one option where we have agreement: the user will be prompted at the end of a form edit session.
@LN and I have written up a more detailed specification at track-changes-reasons spec about how this will look in the XForms spec, XLSForm, pyxform, and Collect.
We have also separated identifying the user into its standalone specification at identify-user spec as was recommended. I think this should make it easier to approve.
I would request that @TAB (especially @aurdipas, @martijnr, and @xiphware) review both these specs with the aim of revising and approving by or at our next meeting.
Thanks @yanokwa
I've shared these specs with @Lal_S & @chrissyhroberts
The identify user spec looks good have added a few comments on it
A login feature to collect in the long term may of course resolve this definitively if that was ever considered a viable approach
For what it is worth, both of these specifications look practical and sensible to me and should achieve the primary goal.
The use of per-form rather than per question collection of reasons for edit information is probably fine because
A) The number of edits is likely to be very small in any highly controlled setting such as a clinical trial
B) More extensive edits with a common purpose can be rationalised in summary
e.g. All the geographical data were wrong as I was holding my map upside down. I have corrected all of the variables district, sub-district, town, street
C) More extensive edits with distinct purposes can be sequenced as part of best-practise and standard operating procedures. For instance,
Edit 1 / Save 1
Form opened, collect asks for user name
User edits one variable
Saves form and records reason for change
Changed gender from female to male as it turned out that name "Adama" can be male or female and I made wrong assumption. Parent made sex of child clear only after initial data submission
Edit 2 / Save 2
Form opened, collect asks for user name
User edits a couple of variables about location
Saves form and records reason for change
Changed street name from "Bishopsgate" to "Gracechurch St" as realised later that south of "Leadenhall St" crossroads the name of the A10 changes. Postcode also changed from EC2 to EC3
Thanks to everyone who has participated in this feature design journey and to @seadowg for the implementation. @seadowg has had the opportunity to do a live demo with @chrissyhroberts and we now have a demo form up on the default server to try out with the latest Collect v1.25 beta!
Maybe after Brexit you should consider FDA more 
(Joking)
journey