...
| Type | Functional description for TIS | Where used in TIS | Warning/error messages in TIS | Comments | |
|---|---|---|---|---|---|
| 1 | Delete (status) | Users can apply a status of "delete" to a particular record, which would mean that the record would be deleted from the front end
Example: People (Sensitive Data / Manage Record / Status) |
| No error message displayed | TBC: In intrepid, this flagged the applicable field or record for archiving in the back end but kept it in view on the UI?. Applicable to fields in ref table and records Reversible |
| 2 | Inactive (status) | Users can apply a status of "Inactive" to a particular record or reference data field, which would mean that the record or field is made temporarily unavailable
Example: People records (People / Sensitive Data / Manage Record / Status) |
| No error message displayed | TBC In Intrepid, this meant the applicable field/record would need to be activated (made current) before it could be used in TISin a record Applicable to fields in ref table and records Reversible |
| 3 | Trash can | Users can click on the trash can next to a field and permanently remove data from TIS
Example: Placement record (People / Placements / Placement list) |
| "Are you sure you want to delete?" displayed | N/A |
| 4 | Minus | Users can click on the minus sign next to a field and permanently remove it from TIS
Example: Curricula (Programme / Curricula) |
| No error message displayed | N/A |
| 5 | X button | Users can click on the X sign next to a field and permanently remove it from TIS
Example: Roles field (People / Sensitive Data / Manage Records / Roles) |
| No error message displayed | N/A |
| 6 | Dates from/to | Users can specify an end date, which would make the related record or fields Inactive after that date has elapsed
Example: Post funding (Posts / Post record / Funding) |
| No error message displayed | Applied in addition to any status of current, inactive or delete - purely informational |
| 7 | Archive | Not currently implemented in TIS | N/A | N/A |
In terms of data being passed down to NDW, it is assumed that hard delete data is not passed on, but soft delete data is.
To Be << to be discussed and agreed with data leads
In order to consolidate the way that the concept of deletion is used across TIS, the following rules should be applied:
...
- remove “delete” as a status that can be applied from in the FE across all fields and records
- apply delete status in the BE only, in certain scenarios (see below)
- display the fields with deleted status in the FE/BE audit log andlogs
- Allow NDW reporting
...
- for records with "delete" status
Example applicable scenarios
N/A - see Trash Can
Conversation
- need back end reporting function for deleted records
Inactive status
- this should only be applied to the following to reference data fields and all record types
- It should remove the ability to link to new records, however wxistinrecord linkages will remain unless edited
- On edit, system should flag where there are records using/linked to this data that have a status of “current”
- display which records are linked or using the data, line by line
...
- TBC if this is possible and how
Example applicable scenarios
- records and fields that need to be temporarily retired
- Reference data
...
- this interaction type should be applied to all record types and certain fields
- this should act as a soft delete, and render the record/field as follows
- remove the record or field completely from view in the FE
- apply status “deleted” in the BE for audit purposes
- display the deletion in audit log against the relevant user/record - this should also allow user to undo deletion
- Do not allow deletion where linked child records / fields
...
- Send deleted fields to NDW in segregated area to support reporting
Example applicable scenarios
- accidental creation of a recordaccidental input of a "multiple-entry" field e.g programme membership
Minus
- this interaction should enable the removal of sub-sections to a record
- this should act as a soft delete
- remove the data from the UIFE
- apply status of Delete in BE
- keep a record of the change in the back end (accessible via audit logs)
- display the deletion in audit log against the relevant user/record - this should also allow user to undo deletion
- do not allow deletion where there are linked records
...
- Send deleted fields to NDW in segregated area to support reporting
Example applicable scenarios
- accidental addition of a sub-section (e.g. placement or assessment to a Person) record
- accidental addition of a curriculum to a Programme
...
- this interaction allows the removal of "multi-add" fields against a record
- it should act as a soft delete
- remove the data from the UI
- apply status of Delete in BE
- keep a record of the change in the back end (accessible via audit logs)
- do not share deleted records with NDW
...
- display the deletion in audit log against the relevant user/record - this should also allow user to undo deletion
- Send deleted fields to NDW in segregated area to support reporting
Example applicable scenarios
- removal of roles against a person record*
- sites against a Post?others???
Dates From/To
- this interaction should trigger automatic status change to "inactive" or "current" dependent on when the dates lie in relation to "today's date"
- it should act as a status change only
- make applicable record "inactive" when end date passes today
- Make applicable record "current" when elapsed time start date passes today
- keep the record in view within UI
- keep a record of the change in the back end (accessible via audit logs)
...
- Can be overridden manually by status change,
Example applicable scearios
- supervisor approvals
- GMC/GDC/PH number validity
- others?
ArchiveArchive REQUIRES FURTHER DISCUSSION WITH JW
- this is required to enable permanent retirement of record types e.g. when a trainee record falls outside of the data retention period
- this should be an automated process that triggers the following
- change of status in BE that removes "Inactive" trainees after a defined duration has elapsed e.g. 7 years from their programme end date
- remove view of the record in the FE
- notify users in bulk of records that have been archived
- apply status "archive"
- all archived data should be retrievable via NDW
...
- where data needs to be retired relating to Trainee records (after 10 years have elapsed)
...
| # | Question | Comments |
|---|---|---|
| 1 | Other than reference date and records (forms), is there anywhere else, or data type, that it should be possible to apply inactive as a status? | |
| 2 | Other than within record, are there other scenarios you might want to delete (trashcan) a data entity? for example, particular fields? | |
| 3 | Deleting programme membership or curriculum membership current behaviour. Think these are hard deletes too, should they be? If so, do we currently audit the deletion of these? Requires technical design guidance as to what a consistent delete on TIS should be. | |
| 4 | What are archiving rules regarding elapsed time and what can/cannot be stored? | |
| 5 | What data will need to be accesible (GDPR) and for how long? | |
| 6 | Are there any notifications we need to provide to users / trainees regarding the editing/deleting/archiving of their data? |
...