Trainee UI - Scenarios

Trainees will not be requesting access we will send creds out as part of the onboarding process. We will have to consider how we migrate the current trainees onto TIS.

1. Import trainees from Oriel
2. Trigger welcome message send -  inform trainees of what TIS is about, support, login details to follow
3. Trigger credentials send

Admins should be able to trigger welcome message, credentials message, oriel manual upload

User able to change their password once logged in for the first time. User name will be email address.

Non-oriel import (Dentists / Other Academic Trainees)

• Username format: valid email address
• No account validation
• Password to be autogenerated
• All users given appropriate access for "Trainee" role

No need to report on this

I expect all trainees will require new login credentials but they will not have to 'register' as we will send out logins as and when we migrate trainees to TIS.

The process will be the same for Synapse users as they are transitioning from one system to another.

Trainee has been registered on system

1. Trainee enters username
2. Trainee enters password
3. System validates details
4. System presents logged in view of system

T-17 Forgotten Username

T-18 Forgotten Password

T-19 Username / Password Error

T-XX: update login details

• Error: Invalid email/password entered

No users logging in

Further discussion required

Trainee has been registered on system

Trainee has validated their registered details

1. Trainee selects to logout
2. System logs user out
3. System presents logged out view

Trainee

System

Summary details in view

Navigation menu available

1. User logs in
2. System presents summary
3. User navigates through view

 Fields displayed

• Current Placement End Date & Site (Steve to confirm)
• Next Placement Start Date & Site (Steve to confirm)

• Read only

Trainee can see currently stored details in an editable format

Trainee can make and save changes to specified details

System updates personal details centrally

1. User navigates to Personal Details space
2. System presents personal details in editable view
3. User makes changes to relevant fields
4. System validates changes
5. System saves changes

Relevant Fields:

Surname
Forenames
Known As
Maiden Name
Title
Telephone
Mobile
Email Address
Address 1
Address 2
Address 3
Address 4
Post Code

Non-editable (editable by central admin team)
GMC / GDC Number
GMC / GDC Status
EEA Resident
Permit to Work
Settled
Visa Issued
Details/Number

• View & Edit select fields, see data table

User is logged in

1. User navigates to programme view
2. User views Programme data
3. User selects to leave Programme Detail view
4. System presents summary view 

Fields

• Programme Name
• Curriculum
• Start Date
• End Date
• Managing Deanery
  

• View only
• View will show historical programmes, current and future programmes if applicable

1. User navigates to summary view
2. User views Placement data
3. User selects to leave Placement Detail view

Fields

Start Date
End Date
Site
Grade
Specialty
Placement type

• View only
• Detailed view should present historical, current and future placements

1. User navigates to Assessment view
2. User views assessment data 
3. User selects to leave Assessment Detail view

Fields

Review (date)
Curriculum Assessed
Outcome
Grade at Time
Period From
Period To

• View only
• Detailed view should present historical, current and future assessments

1. User navigates to summary view
2. System presents summary information
3. User selects to view detail
4. System presents detail view
5. User selects to leave Course Detail view
6. System presents summary view 

User is logged in

Available to medical trainees only

User personal details are updated in TIS across all systems

User personal details are updated with HEE Admins

1. User navigates to Form R, Part A space
2. System presents form in editable view
3. System autopopulates relevant fields
4. User makes changes to relevant fields
5. System validates changes
6. System saves changes
7. User signs the form 
8. User selects to submit Form-R (Part A)
9. Form-R (Part A) is sent to HEE Admins
10. Historical view of submissions is updated

Manual Trigger perhaps more appropriate dependent on design.

Fields

• forename
• GMC registered surname
• GMC number
• Deanery / HEE local team
• DOB
• gender
• immigration status
• primary quaification
• date awarded
• Medical Scool
• Home Add
• Contact Tel
• Contact Mob
• Preferred email
• Prog Spec
• Spc 1 for Award of CCT (non-mand)
• Spec 2 for Award pf CCT (opt)
• Royal College/Faculty assessing training for the award of CCT
• Anticiapted completion date f curr prog if known
• Options - confirmations x6 (see data table
• declaration of programme

• Autopopulation will be required from personal details and other sections, where appropriate
• Must be submitted for new trainees

Trainee

GMC

User is logged in

Form-R submission is imminent

Cannot be submitted at anytime, it is usually requested by the local office prior to the ARCP, I think the timescales differ in different local offices.

To be confirmed whether there is a trigger requirement in TIS for admins - IO

1. User navigates to Form R Part B space
2. System presents form details in editable view
3. User completes relevant fields
4. System validates fields
5. System saves changes
6. User signs form (tbc as with Part A)
7. User selects to submit Form-R (Part B)
8. Form-R (Part B) is sent to Admin UI
9. Historical view of submitted Form's updated

Unsure. May be best to keep both parts A&B together in their own space. Steve to confirm

Validation as per data table

• Error message: cannot be edited once submitted, as no longer a draft

 Where is the result sent?

Administrator will need to receive the form in order for it the details to be checked and the application either accepted or denied by the designated authority (Dean or deputy)

1. User navigates to XXX space
2. System presents form details in editable view
3. User completes relevant fields
4. System validates fields
5. System saves changes
6. User selects to submit OOP request
7. OOP request is sent to XXX
8. Historical view of submitted Form's updated

Is this necessary? 

Yes

Where is the result sent? 

Administrator will need to receive the form in order for it the details to be checked and the application either accepted or denied by the designated authority (Dean or deputy)

1. User navigates to XXX space
2. System presents form details in editable view
3. User completes relevant fields
4. System validates fields
5. System saves changes
6. User selects to submit LTFT request
7. LTFT is sent to XXX
8. Historical view of submitted Forms updated

1. User navigates to XXX space
2. System presents form details in editable view
3. User completes relevant fields
4. System validates fields
5. System saves changes
6. User selects to submit expenses request
7. Expenses are sent to XXX
8. Historical view of submitted Forms updated

• can be edited any number of times
• Error message: cannot be edited once submitted, as no longer a draft

• display contact details as per local office where they were registered OR
• display central contact details (if available)

1. User navigates to relevant form
2. System presents form details in editable view
3. User completes relevant fields
4. System validates fields
5. System saves changes
6. User leaves relevant space without submitting the form
7. System stores draft

1. System User contacts HEE by telephone / email
2. HEE provides username

1. User selects password reminder
2. New password is autogenerated
3. New password is sent to registered email address
4. User logs in using password sent

• no validation

1. User navigates to summary view
2. System presents summary information
3. User selects to view detail
4. System presents detail view
5. User selects to book Course
6. System presents Booking view