deleted, but still in audit-log?

GerbenRienk

I have a question about deleting subject-data: in oc341 and before you could completely delete subjectdata, for example in case of a participant withdrawing consent.
It appears that this is no longer possible in oc36 and what's more: in the audit-log the old values are still visible. This is in some countries against regulations.
Am I overlooking something? Or was does done accidentally and will it be fixed?

kristiak

Hi Gerben,

Sharp eyed as usual. Yes you are absolutely correct. If a patient withdraws the consent then we must erase all the data including the audit log,

Regards

Krister

agoodwin

Hi Gerben and Krister,

Thanks for bringing this up - it's a good discussion point. However; this
is not a bug but an intentional change to meet regulations. We had gotten
feedback from clients and going over the regs we thought we needed to make
a change. Laura will follow with more detail and we would love to get more
feedback. (Note that this is in the release notes under "changes and fixes"
https://docs.openclinica.com/release-notes/release-notes-openclinica-3.6 ),
though I could probably describe it a little more clearly.

Thanks,
Alicia

On Sun, Aug 23, 2015 at 11:45 AM, kristiak
wrote:

> Hi Gerben,
>
> Sharp eyed as usual. Yes you are absolutely correct. If a patient
> withdraws the consent then we must erase all the data including the audit
> log,
>
> Regards
>
> Krister
>
> --
> To manage your email notifications, please visit:
> https://www.openclinica.com/forums#/profile/preferences
>
> Reply to this email directly or follow the link below to check it out:
> http://openclinica.vanillaforums.com/discussion/comment/17245#Comment_17245
>
>

lkeita

As Alicia mentioned, this feature was added to comply with regulations - two of which I'll reference here. If you are aware of other regulations and/or guidance documents that conflict with what is below, please let me know.

According to the attached FDA guidance document, "FDA recognizes that a subject may withdraw from a study; however, the withdrawal does not extend to the data already obtained during the time the subject was enrolled." That document later states, "Subjects may subsequently withdraw from such studies, but the data collected up to withdrawal may not be removed." And "...data collected on study subjects up to the time of withdrawal must remain in the trial database in order for the study to be scientifically valid." This FDA guidance document references international guidance documents and codes as well.

In addition, the ICH E6(R1): Guideline for Good Clinical Practice states:
"When using electronic trial data handling and/or remote electronic trial data systems, the sponsor should: ... 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)."

Both of these documents clearly state the need to maintain data that was collected for a subject while under consent and that data cannot be deleted. As always...open for discussion and for any information on other regulations that may be counter to these.

Laura

kristiak

Hi Alicia,

Could this possibly a parameter that you could turn on or off to satisfy local regulations.

Best

Krister

toskrip

Hi,

I also think that this behavior should be configurable... In EU right to forgotten applies for any personal data collection initiatives. Not sure what is currently the status of the new EU data protection regulation but having this configurable is the only way for satisfying local regulations as different as they can be...

Tomas

kristiak

I will ask our Data Inspection Agency what their current interpretation of the EU legislations is. It will probably take a couple of weeks to get an answer.
Best
Krister

agoodwin

Hey Krister,

It would be really useful if you could point us to specific regulations
that are counter to these.

A couple of challenges in building a product like OpenClinica (which is a
very robust and has a lot of functionality) is that while it can be nice to
have lots of configuration options, this also introduces complexity.

Specifically around this issue is that we really try to limit the ways in
which a user could "shoot themselves in the foot". Knowing that this is a
regulatory concern we want to leave as little room as possible for error.

We absolutely want to build a product that can be widely adopted and
appreciate specific feedback on other regulations, their impact and if they
are in contrast so that we can try to find the best solutions.

Best,
Alicia

On Mon, Aug 24, 2015 at 1:37 PM, kristiak
wrote:

> Hi Alicia,
>
> Could this possibly a parameter that you could turn on or off to satisfy
> local regulations.
>
> Best
>
> Krister
>
> --
> To manage your email notifications, please visit:
> https://www.openclinica.com/forums#/profile/preferences
>
> Reply to this email directly or follow the link below to check it out:
> http://openclinica.vanillaforums.com/discussion/comment/17250#Comment_17250
>
>

agoodwin

Hey all,

I should be clear about how the functionality works and why, so that we're
all working with the same information. Let's start with a specific use case
and the steps to get there.

The use case is: A data entry person has entered data into an Event CRF,
entered a discrepancy note for one of the questions that was out of range
and saved the form. The data entry person realizes that they entered the
data for Study Subject 102 but they meant to enter it for Subject 103.

Precondition:
1. An Event CRF has been entered
2. A discrepancy note has been entered on an item (perhaps as a result of a
rule)

To Delete:
1. An Admin can go to the Event CRF
2. Admin uses the Red "X" to "delete"

Outcome:
1. All CRF Item data values are set to blank
2. All discrepancy notes are automatically set to "closed"
3. All Rules and Show/Hide behavior is reset (if re-entered in the future,
this will trigger as if it has never been triggered before)


Now, the form can be re-entered at a later time and it will be as if it was
never entered before. HOWEVER; the audit trail remains. This means that no
clinical data will be extracted for the form (because it won't exist) but
if an auditor wanted to see when it was deleted and *what* was deleted,
this is possible in the audit log.

Now if you really don't to have any data from that record to be included in
any extract or print or WS call, you can also "remove" it.

Does this add any clarity? Is this viable?

Thanks,
Alicia








On Mon, Aug 24, 2015 at 1:50 PM, Alicia Goodwin
wrote:

> Hey Krister,
>
> It would be really useful if you could point us to specific regulations
> that are counter to these.
>
> A couple of challenges in building a product like OpenClinica (which is a
> very robust and has a lot of functionality) is that while it can be nice to
> have lots of configuration options, this also introduces complexity.
>
> Specifically around this issue is that we really try to limit the ways in
> which a user could "shoot themselves in the foot". Knowing that this is a
> regulatory concern we want to leave as little room as possible for error.
>
> We absolutely want to build a product that can be widely adopted and
> appreciate specific feedback on other regulations, their impact and if they
> are in contrast so that we can try to find the best solutions.
>
> Best,
> Alicia
>
> On Mon, Aug 24, 2015 at 1:37 PM, kristiak
> wrote:
>
>> Hi Alicia,
>>
>> Could this possibly a parameter that you could turn on or off to satisfy
>> local regulations.
>>
>> Best
>>
>> Krister
>>
>> --
>> To manage your email notifications, please visit:
>> https://www.openclinica.com/forums#/profile/preferences
>>
>> Reply to this email directly or follow the link below to check it out:
>>
>> http://openclinica.vanillaforums.com/discussion/comment/17250#Comment_17250
>>
>>
>
>
> --
> Alicia Goodwin
> Senior Product Owner
> Direct Phone: 617.735.5556
>
>
>

kristiak

Hi Alicia,
It sounds OK to me but I'm not a lawyer who interprets regulations like the devil. I have written to our highest regulatory body for privacy rules and asked for their opinion.

Best

Krister

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).

Tomas