Roadmap & New Feature Ideas
Add-Ons & Code Contributions
Q & A
Installation & Setup
Study Build, Rules, and CRFs
Data Entry, Monitoring, and Data Management
Extracting & Reporting
Web Services & Integration
Internationalization and Localization (i18n / L10n)
Announcements & Updates
Announcements & Updates
Users Mailing List
Developer Mailing List
We hope you'll join us for our 4/23 webinar on using data tables to apply reference ranges and AE codes in OC4. For more information and to register, visit
deleted, but still in audit-log?
This may not be the best solution but it is possible to, in addition to
clearing the data, to reassign the "subject" then to the study-level where
(presumably) those users do not have access to the patient record?
On Mon, Aug 24, 2015 at 2:49 PM, toskrip
> The problem is that if patient explicitly ask for data deletion it cannot
> be possible for anybody to track back what data was associated with patient
> (as identifiable subject). If this is still tracked in audit log, this also
> means that there is a user role that is allowed to access this information
> and theoretically can reconstruct the the original data from the log itself.
> If we receive such request for data removal (very very rare occasion) we
> have to deal with it. One way to solve this is replace PersonID of that
> subject with randomly generated value and this way completely anonymise the
> study subject = data protection regulations are not applying for anonymous
> data. (But this needs to be done on database level because any change in
> patient ID within OC will be again audited).
> As you see it is not so much about the data deletion itself, but about the
> association of patient data with patient identity. That is why wee need to
> cut the ID that links to data to patient identity (which in our setups is
> always PersonID).
> To manage your email notifications, please visit:
> Reply to this email directly or follow the link below to check it out:
actually we usually move them to dedicated site with name (DELETED) before, but this is only to clean the subject matrix for standard users. Administrator can still access the subject and see the log so it has no effect on the problem with subject data privacy. In my opinion there are just two solutions:
- completely remove the data from database (including audit log records)
- or anonymise the subject (replace IDs without auditing this procedure)
We are going through a similar procedure to get rid of data that have been entered in error, such as patients who have been entered that have not yet signed the consent form and changed their mind or entered in error but saved as completed.
What are people using as a procedure when only one event CRF was entered in error, and not the entire subject record?
This discussion has been closed.