1.

Does DRAFT mean that It's not a placement that has started yet? i.e. start date is in the Future

Not necessarily.

Current placement alterations as a reason of someone going into parental leave, where they are end dated. The placement is technically still in in APPROVED. But the new placement that is going to be created goes into DRAFT (regardless of whether it is a CURRENT or FUTURE placement).

 ·        A Change of Date Notification will be sent for the end dated placement.

·        A Notification type 1 sent for the newly created placement when the >2 days within 13 weeks window is met.

DRAFT is only an indication for HEE admins that there are changes (any) being made to it and it’s not approved. They do not need to be restricted from being able to change it.

2.

Does DRAFT mean that this lifecycle status would normally be the default status for a placement being created by a specific type of user (e.g. TPD?)

Yes – Programme Admin and Trust admins specific. They should be able to make amendments in any of those lifecycle statuses.

No – Not applicable for HEE Admins, and other admins role like Reval Amin, Admin Sensitive etc.

https://hee-tis.atlassian.net/browse/TISNEW-3648

3.

Does the DRAFT lifecycle status mean it can only be set to placements which are FUTURE and not to CURRENT and PAST? If not, in which scenario does a user need to be able to set a DRAFT lifecycle status to a CURRENT/PAST placement?

Business perspective:

As many placements approved at 12 weeks (COP) and 6 weeks. (FUTURE placements)

• Any amendments made to CURRENT/PAST placements, the status remains in APPROVED.

• Any amendments or creation of FUTURE placements should be set to DRAFT.

Business Process required on How the Admins update NPN’s on placements and informing ESR. Note: Users would need to delete the placements in order to withdraw. For any other changes, it would still be BAU.

Not applicable for HEE Admins, and other admins role like Reval Amin, Admin Sensitive etc.

Only applicable to Programme Admins.

https://hee-tis.atlassian.net/browse/TISNEW-3656

3.1

What makes an APPROVED placement?

• TPDs placements signed off,

• Created on TIS

• Set to APPROVED/published.

• For FUTURE placements, they will start to flow to ESR.

4.

Does the DRAFT/APPROVED lifecycle only applies to placement being created via the PPT tool, and not via the person>placement UI or Bulk Placements create/update tools? If so, does this status need to be set by default to APPROVED when added/updated using the other non-PPT alternatives?

Bulk Uploading of Placements ???

• Ideally restrict them (Programme and Trust admin roles) from being able to bulk upload placements

• OR  Set to DRAFT only for these 2 types of users when bulk uploading.

PPT placement creation and Person>Placement UI creation to behave the same way for  ALL users. Same set of Rules as (2).

https://hee-tis.atlassian.net/browse/TISNEW-3657

4.1

If NO to 4, will all user types (HEE Admin and TPDs etc.) be expected to have same interaction when creating/updating placements on TIS via the other ways of interacting with placements?

Answered above.

5.

Does APPROVED mean a placement that can be CURRENT/PAST/FUTURE and has been published for use specifically by a specific type of user?

Answered above.

6.

What sort of changes to a placement would a PPT user expect to make in DRAFT mode that cannot be made whilst it's already APPROVED mode?

• Change to NPN?

• Change to Site?

• What else?

Answered in point (3).

1.

Currently when a placement is withdrawn (via the bin/delete interaction), it is hard deleted from TIS. If the placement has previously been exported to ESR (Applicant Export), then a withdrawal notification is generated and sent to ESR. When a new placement is created, and we have a matching POS/POR on TIS for the NPN, it gets exported as a new Applicant if the start date is >2 days within 13 weeks window.

Current implementation.

2.

ESR definition of Withdrawal (NHS0098):

These notifications will be sent by the Deanery/HEE Local Office systems to the MSO Role when an applicant previously created has subsequently been withdrawn from the position and a replacement applicant is required.

TIS understanding validated with ESR:

2’ - “Update to Medical Rotations – Applicant Withdrawn”

This is sent in the notification file of a future trainee that has withdrawn and not someone who is already in post. This means where the Projected Start date on the placement is within 13 weeks in the future and greater than 2 days AND the DPN is one of the POS records we would have received in an earlier RMT file.

Current implementation.

3.

With this new lifecycle status if a placement is in DRAFT, I am assuming that it is not an actual placement with any of the status of CURRENT/PAST/FUTURE, is this correct?

No. See above.

4.

Under which circumstances would a placement need to be changed from APPROVED to DRAFT?

FUTURE placements amendments and creations ONLY.

5.

If a placement is set from APPROVED back to DRAFT (for whatever reason), is the expectation that it will be at some point be set back to APPROVED? As I believe that we would not want to create a process where we would end up with a number of placements sitting in DRAFT, either because they are Invalid or they have since re-created a new placement with APPROVED status.

The expectation is that they should be moved back to APPROVED or Deleted.

Reporting – to flag these in NDW. (@James Harris )

6.

If we do go down the route of considering letting ESR know via a withdrawal notification that a placement has been changed to DRAFT from APPROVED (i.e. a POS/POR exist on TIS and ESR, and previously exported to ESR based on the start date of >2 days within 13 weeks window) and is equivalent to the existing withdrawal (bin/delete) interaction, Then if re-approved, I assume similar interaction as in (3) above is expected, i.e. re-setting to APPROVED from DRAFT means a new Applicant Export. Although this might be a duplicate.

It’s not a withdrawal per se.

7.

If we choose not to let ESR know about any of the DRAFT/APPROVED lifecycle status changes, then all placements DRAFT or APPROVED should be treated the same way by the ESR interface. (i.e. as in (3) above using the same rules regardless of whether the lifecycle is DRAFT or APPROVED)

This is the route we are going for.