5.5.3 When using electronic trial data handling and/or remote electronic trial data systems, the sponsor should:
(a) Ensure and document that the electronic data processing system(s) conforms to the sponsor’s established requirements for completeness, accuracy, reliability, and consistent intended performance (i.e. validation).
(b) Maintains SOPs for using these systems.
(c) Ensure that the systems are designed to permit data changes in such a way that the data changes are documented and that there is no deletion of entered data (i.e. maintain an audit trail, data trail, edit trail).
(d) Maintain a security system that prevents unauthorized access to the data.
(e) Maintain a list of the individuals who are authorized to make data changes (see 4.1.5 and 4.9.3).
(f) Maintain adequate backup of the data.
(g) Safeguard the blinding, if any (e.g. maintain the blinding during data entry and processing).
In fact the word password occurs at no point ever in the GCP regulations.
My question @aurdipas for your data manager would be
"Where is the password for paper"
We propose to get round this with other approaches
Device level locking
If necessary one username/password per device
i.e
Different Collect account for every fieldworker
this means to me that a sort of password protected. But I'll ask our data manager to be more precise.
FDA is also expecting that
Access must be limited to authorized
individuals
• Each user should have an individual
account/password
• Passwords should be changed at
established intervals
• The system should limit and record the
number of unauthorized log-in attempts
• Automatic log off for long idle periods
we are not on paper we use an electronic tool for data collection Macro
And our data manager agreed that this system is paper equivalent (without password).
I'll ask more details to him as soon as possible and share with you.
(d) Maintain a security system that prevents unauthorized access to the data.
At the device level - just password protect the phone/tablet.
Maintain a list of the individuals who are authorized to make data changes
This is normally at the server level I think; i.e who can change the raw data.
But could also be done by giving each data collector a unique username.
the login/password is a wish for me in the future.
For the moment being paper equivalent is OK.
this means a tablet per fieldworker that can not be used from someone else or you have multiple users per tablet?
The limitation of not having a login is also that the user that first fill the form is not tracked (the reason for change it happens for a modification not for first fill the form).
not necessarily at server level. We are talking also of access to the tablet.
And giving each data collector a username does not suppose a sort of login?
We can continue the discussion on Thursday next week with a beer, I pay the first one
This is certainly possible but it seems like it would then be worse than paper. I think from a user experience standpoint, it's also easier to explain a change right after it has been made rather than explaining multiple changes at the end. Are you suggesting this as a simplification or do you see an advantage to it?
In a one-question-per-screen context (Collect's default), changes while on the same screen are not captured. You can see this in action at second 9 of the little demo I built:
So “Why are you editing this form?” vs “Why are you changing this response?”... Former is certainly a lower-hanging fruit, one which might be accomplished via a simple additional field when prompting for ‘username’.
But would this actually be sufficient for most/some/any usecases requiring “change tracking” ?!
It is all in the eye of the beholder.
For what it is worth Redcap (considered GCP compliant) doesnt appear to record reason for change at all, only who made change, when they made it, and what change was made.
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