Admin UI - Deletion in TIS

Users can apply a status of "DELETE" to a particular record, which would mean that the record would be hidden from the front end

• applied at record level 
• this acts as a soft delete
• remove the record from the front end
• does not remove the relationship where already in use, e.g. where a 'Curriculum' status is changed to 'DELETE', it'll remain available against Programmes where it's attached to retrospectively.
• removes the ability to use an DELETE status value when creating/editing a record. i.e. made unavailable in the Front End to be used against new records. e.g. you cannot attach a 'Curriculum' with a status of 'DELETE' when creating a new programme.

Example: People (Sensitive Data / Manage Record / Status)

• People
• Programmes
• Posts
• Curriculum
• Rotations
• Reference (All those maintained in TIS)

• Remove “DELETE” as a status that can be applied in the FE across all records
• Apply "DELETE" status in the BE only, in certain scenarios (see below)
• Remove Status against People altogether and consider the use and recording of Leaving Destination and Leaving Reason within Programme membership as suggested on workhop 2018-09-21
• Ensure if there are records with a Status of DELETE in the BE, the various API calls/end points consider ignoring/including them in any search
• Display the records with DELETE status in the FE/BE audit logs
  Matt UX: Example of the deleted item in Audit trail
  TIS Admin UI - UX Enhancement - Removing delete status from all fields with Audit example of removed data
• Allow NDW reporting for records with "DELETE" status

Users can apply a status of "INACTIVE" to a particular record or reference data, which would mean that the record is made temporarily unavailable

• can be applied at record
• impact of applying this to a field being used in a current record, is
  • filtering may need to be applied to view the record in a list page i.e. To show both current and inactive records
  • drop downs for reference tables will not display anything that has been made with an inactive status
  • records containing inactive data will not be flagged, but editing may present errors to the user
  • assessment records may become legacy, and no editing will no longer be possible (AR 16/08: Don't understand what this means)

Example: People records (People / Sensitive Data / Manage Record / Status)

• People
• Programmes
• Posts
• Curriculum
• Rotations
• Reference

• "INACTIVE" should be a Status that can be applied to to reference data and all records in column 4.
• By making a record "INACTIVE", it should remove the ability to create/edit a record using an INACTIVE value
• However existing links to an INACTIVE value should not stop a user from editing the record for other details. E.g. 'University of Newcastle' is INACTIVE in reference table, but in use against Person A qualifications, an admin should be able to change the 'Date attained'.
• On edit, system should flag where there are records using/linked to this data that have a status of “current”. E.g. When making a Post INACTIVE, system should flag if there are 
  • a) Current Placements against the Posts.
  • b) Current Programmes against the Post
  • Alistair Pringle (Unlicensed)/ Joanne Watson (Unlicensed) - Any other scenarios else to consider here? 
• Display which records are linked or using the data, line by line TBC if this is possible and how (Matt Leech (Unlicensed) to review the best approach)

• It should be possible to change the status of the records from INACTIVE back to CURRENT.

Matt UX: No need for design work. This can be done at Dev level.

Users can click on the trash can next to a field and permanently remove data from TIS

• this functions as a hard delete
• removes existing relationship with records. e.g. The Placement is removed which represents the relationship between a Person and a Post, but the actual Person and Post records remain intact.
• No audit trail is kept of for the deleted record

Example: Placement record (People / Placements / Placement list)

• People: Placement
• People: Assessment (new development)

• The trashcan interaction should be applied to all Placement record types, i.e. CURRENT, PAST as well as FUTURE.
• To be consistent with list views deletions, the trashcan interaction to be applied to Assessments. 
• This should act as a soft delete, and render the record/field as follows
• remove the record completely from view in the FE
• apply status “DELETE” 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 
• Consideration of warning message
• Impact assess implications to ESR which currently relies on the trashcan interaction to create Notifications to be sent in the TIS-ESR interface.

Example applicable scenarios

• accidental creation of a record
  
  Matt UX: An example of the 'Delete' notification/prompt prototyped below on InVision. Use the hotspot links to view each option for the removal denial due to Child relationships.
  
  https://invis.io/EANNM8F6YHM
  
  Option 1 ) A notification prompt with links to the child areas which need to be changed (Status) so the user can remove the item
  
  Option 2) A link to a generic notification informing the user that this item has child records associated to it so cannot be removed. This would require the user to find the child items themselves to make the changes they need before they can delete the item.
  
  We may need to investigate this with POs if we feel that the user needs to 'Speak with a Data lead' to authorize the deletion?

• TISNEW-1440
• TISNEW-1427

Users can click on the minus sign next to a record and in some cases additionally click on 'Save/Update' button to permanently remove it from TIS, generally:

• this functions as a hard delete
• removes existing relationship with records. e.g. Programme membership which is a relationship between a Person and a Programme is removed, but the actual Programme and Person record are intact.
• No audit trail is kept of for the deleted record

Example: Curricula (Programme / Curricula)

• Posts: Other specialties

User has to click on Minus and Save button to remove the relationship.

• Posts: Sub-specialties

User has to click on Minus and Save button to remove the relationship.

• Posts: Other grades

User has to click on Minus and Save button to remove the relationship.

• Posts: Programme names

User has to click on Minus and Save button to remove the relationship.

• Posts: Rotation name

User has to click on Minus and Save button to remove the relationship.

Users can click on the X sign next to a field and permanently remove it from TIS and in some cases have to confirm the prompt message to complete the deletion.

• this functions as a hard delete
• removes existing relationship with records. e.g. the role is removed from the Person record, but the actual Role is available to be used against new person records. 

Example: Roles field (People / Sensitive Data / Manage Records / Roles)

• People: Roles
• Document: Tags
• Document

• 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
  • AR 16/08: Joanne Watson (Unlicensed) Alistair Pringle (Unlicensed) - Don't think this is straight forward to make a soft delete as it would mean that we should maintain in TIS at field level all possible Roles, whereas currently Roles is just one field which holds comma separated values in the table. One to be discussed...
• keep a record of the change in the back end
• 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 
  
  Matt UX: No design work needed
  

Dates from/to

Users can specify an end date, which would make the related record or fields 'INACTIVE' after that date has elapsed

• this functions as an automatic soft change of the Status
• status of the records automatically changed from CURRENT to INACTIVE and vice-versa

Example: Post funding (Posts / Post record / Funding)

• People: Registration dates
• People: Inactive date (Has been hidden in the Front End)
• People: Programme membership

• 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 record "INACTIVE" when 'Date To' exceeds today's date
  • make record "CURRENT" where today's date reaches 'Date from'.
  • keep the record in view within UI and searchable when relevant filter applied
• keep a record of the change in the back end (accessible via audit logs)
• Can be overridden manually by status change, 

Example applicable scenarios:

• Joanne Watson (Unlicensed)/ Alistair Pringle (Unlicensed) - AR 16/08: I can't think of any current scenario on TIS where this is currently available. It was previously here witihin People > Sensitive data > Inactive date , but the Inactive date is hidden from the FE currently.
• supervisor approvals (not on TIS, to consider when this is available)
• GMC/GDC/PH number validity
  
  Matt UX: No design work needed

Archive

Archiving paper/guidance:

Requires further discussion with Joanne Watson (Unlicensed) / Ray / IG

• 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 Back End 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 Front End and should not be searchable/accessible via any means from the UI.
  • Notify users in bulk of records that have been archived - AR 29/08: What does this mean and entail ???
  • Apply status of  "Archive/Suppressed"
• All archived data should be retrievable via NDW - AR 29/08: Has this been verified if compliant with IG?

Applicable scenarios

• where data needs to be retired relating to Trainee records (after 10 years have elapsed)

Bulk Upload/Update

Users able to bulk change the statuses (People) or hard delete (Placements) of multiple records at once using the bulk import facility in TIS.

• Functions as a soft change to the Status for People to either INACTIVE/DELETE/CURRENT
• Functions as a hard delete for placements, which is currently only available to data leads to use.

• People
• Placement

Joanne Watson (Unlicensed)/ Alistair Pringle (Unlicensed):

• Is there a requirement to bulk add 'Inactive date' to People records, if we are going to make it visible in the FE?
• Should we remove the ability to change the People records to 'DELETE' via bulk but keep the ability to make them INACTIVE or CURRENT so that deletions can be undone in bulk?
• The current restricted bulk delete placement which is only available to data leads does hard delete, should we make this a soft delete to be consistent with #3 (trashcan To-Be)?
• Should we consider audit logs for bulk?
• keep a record of the change in the back end (accessible via audit logs)?

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.