Data deletion process / slides / stuff

I’ve been asked to provide an overview of the process and nature of soft deleting in openEHR and wondered if anyone had already done something similar? I need to detail what happens to the data, how the audit works for a clinical group and reinventing the wheel is not a preferred option.

1 Like

Here’s the bit of spec you want.

Hi @johnmeredith

Technically a delete is the same as a modification or amendment, so if you can explain those, you can explain delete too. Though there are minimal differences like, when deleting, you don’t need to commit a version of the item you are deleting, like you need to do for modifications/amendments.

If you actually need to explain how modifications/amendments work, and these items are the same for deleting. A modification…

  1. needs to reference the previous version of the item you are modifying (preceding version uid)
  2. generates a new version of the item, which is linked to the corresponding VERSIONED_OBJECT
  3. generates a new contribution
  4. generates audit logs at the contribution and version levels
  5. the audit at the version level contains the change type (modification, amendment, deleted)
  6. doesn’t modify existing items, just generates a new version, maybe marking that as the last version, and the rest of the versions are there just untouched, and we can read the whole modification history from creation to deletion of an item

That is in a nutshell, I might forgot something because that’s from memory. Then each implementation has it’s own technical details on how they handle the data at the database level, like using the same or different tables for storing historic data, deindexing items that were deleted, etc.


Thanks both. I think i have the narrative now plus @ian.mcnicoll lobbed me some AQL to use as an example.

1 Like

The details of logical deletes Tom referenced are implementation specific as Pablo points out. Audit is an entirely different beast because its meaning is context specific and the means to perform it are again implementation specific.

Unless you’re supposed to provide information for deletion and audits at a very high level, this is vendor specific I’m afraid.