Page Comparison

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

• applied at both record and field levellevel 
• this acts as a soft delete
• removed remove the field from record from the front end
• does not de-link where appliedremoves link ability for new scenariosremove 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)
• 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
• Allow NDW reporting for records with "DELETE" status

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

• can be applied at both record and field level
• 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 possiblepossible (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.

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 linkages relationship with records and other fields. 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/field

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

• People: Placement
• People: Programme Membership

• The trashcan interaction should be applied to all Placement record types, i.e. CURRENT, PAST as well as FUTURE.
• 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

Users can click on the minus sign next to a field and 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 linkages relationship with records and other fields. 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
/field

Example: Curricula (Programme / Curricula)

Users can click on the X sign next to a field and permanently remove it from TIS

• this functions as a hard delete
• removes existing linkages with records and other fields

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

• People: Roles

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

• this functions as a hard delete
• removes existing linkages with records and other fields

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

• People: Registration dates
• People: Inactive date
• People: Programme membership

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

• Minus button should enable the removal of sub-sections to a record

• This should act as a soft delete
  • remove the data from the FE
  • apply status of

• • DELETE in BE
• To keep a record of the change in the back end
• To 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. System should flag when: 
  
  • a) removing a curriculum against a programme where there are child associations, e.g. curriculum attached to an assessment or a programme membership
  • b) removing the curriculum from the programme membership, where there are assessments attached
  • Alistair Pringle (Unlicensed)/ Joanne Watson (Unlicensed) - Any other scenarios else to consider here? 
• Send deleted fields to NDW in segregated area to support

• reporting
• The use of Minus and Save/Update in some places to be reviewed for the best UX approach (Matt Leech (Unlicensed) see As-Is column) 

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

Image Added

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 

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

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

Applicable scenarios

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

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