Deleting participants from database enrollment table does not remove from other datasets

[dasads44]

Currently when you delete a participant from the database enrollment table it removes them from the participant list. however all the data from the other datasets remain under the original participant ID.

There is the potential for the same Participant ID to be used again meaning the data will be assigned to the wrong participant.

Options

• When a participant is removed from the database enrollment table all their data is removed from all datasets.
• Force participant ID to not repeat.

We could implement both options, but we need to discuss how this will affect the OUH version once mirth rest API issue is resolved.

[spikeheap]

Hi @dasads44,

The LabKey participant list is a bit cleverer, so when we create a new participant the generated ID will be one greater than the newest created ID (even if it's removed in LabKing).

A user could override the ID and create a Database_Enrollment entry for the existing ID. This would fail if the existing ID already has a Database_Enrollment record, but succeed if it had been deleted.

This behaviour exists because we are really just adding a Database_Enrollment record (rather than creating a participant explicitly).

I can't see a way to delete participants entirely, and even removing all of their entries from all datasets seems to leave the participant in the LabKey participant list (though not in the LabKing list). I think this makes sense, because you (probably) wouldn't want to give a new participant an ID that has previously been used by a different participant – any external links or backed-up snapshots would then be at risk of sharing an ID between different participants.

One solution would be to make the ParticipantId non-editable in our 'Create' modal, so the user is forced to create a participant with the next sequential ID.

This does raise a question around removing participants. Currently we just delete their demographic record, but we could update the behaviour (as you suggest) to remove all references to that participant. We could also change the behaviour of the participant list so that it mimics the LabKey participant list, and thus you wouldn't be able to completely remove any participants, only their data. If we did this, deleting the participant's Database_Enrollment row wouldn't remove them from the filter as it does now.

@dasads44 what do you think?

[dasads44]

I think making the particpentid non-editable in the 'Create' modal makes sense.

Deleting participants does pose a few questions.

When it comes to deleting participants from research databases each study will have different "consent withdrawal options" the standard ones being:

• Stop collecting and delete all the data that is currently stored
• Stop collecting new data but currently stored data can be retained.

There will also be more project specific versions. such as removing specific datasets. So essentially we will need to do both of the options you previously listed.

[spikeheap]

Hi @dasads44, I've disabled deleting records in the main demographic dataset, and locked the participantId, which should resolve this issue. Let's catch up about this one in the hangout