Backlog
Requirements were gathered during interviews and conversations with the end users and the Product Owner. The functional requirements for the new system are much the same as those for the current system. Most observations from the end users concerned non-functional requirements.
The functional and non-functional requirements are specified below.
The next step will be to translate these requirements into:
EPICs - large functional requirements that deliver areas of functionality that is completed within the project. EPICs contain Features.
Features - smaller functional requirements that deliver areas of functionality that is completed within an increment (4-12 weeks). Features contain User Stories.
User Stories - smaller functional requirements that deliver areas of functionality that is completed within a Sprint (2 weeks). User Stories contain Tasks. Task breakdown of User Stories will take place during Backlog Refinement meetings during Sprints once the project team is assembled.
Themes - deliver cross cutting elements of the project; usually non-functional requirements.
Requirements from Current System
To be completed
Requirements from User Research During Evaluation
Requirement 1
A service that doesn't crash | |
---|---|
As a | Revalidation Administrator |
I Want | a reliable service that doesn't crash all the time |
So that | I can do my work without the frustration of an unreliable system |
MoSCoW |
|
Priority |
|
Notes | I saw the system crash twice at Thames Valley and once at West Midlands, so this is not an infrequent occurrence. |
Requirement 2
Align HEE deferral reasons with GMC deferral reasons | |
---|---|
As a | Revalidation Administrator |
I want | to align (cross refer) my deferral reasons with the GMCs |
So that | I can continue to use my local deferral reasons but report to the GMC more accurately |
MoSCoW |
|
Priority |
|
Notes | The GMCs deferral reasons don’t align with the deferral reasons used by Designated Bodies. Linking local deferral reasons to GMC reasons will allow better local reporting of deferral reasons while keeping the GMC ones more accurate. |
Requirement 3
Automatic Connection | |
---|---|
As a | Revalidation Administrator |
I want | Trainees to automatically connect to my Local Office on the day they start training with us |
So that | Trainees are connected to the right Local Office at the right time, thereby avoiding extra clerical effort to ensure they are connected properly |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 4
Automatic Notification of Outcome 6 | |
---|---|
As a | Revalidation Administrator |
I want | an automatic notification from TIS when a Trainee is awarded an Outcome 6 |
So that | I know the Trainee is eligible for Revalidation without having to search for them. |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 5
Automatically check for Trainees under notice | |
As a | Revalidation Administrator |
I want | the Revalidation service to tell me when Trainees that are not under notice should be. |
So that | I don't have to manually reconcile my list of Trainees with the All Doctors list from GMC Connect |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 6
Be able to see Trainee’s evidence for Revalidation | |
---|---|
As a | Revalidation Administrator |
I want | to be able to see the three elements of a Trainee's evidence (Form R part B, Trainee ARCP, Trainee Concerns) |
So that | I can process all the information to support a Trainee's Revalidation at one time. |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 7
Be notified of outcomes from GMC | |
---|---|
As a | Revalidation Administrator |
I want | to know when the CMG has reached an outcome |
So that | I can track the progress of revalidations I have submitted to the GCM |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 8
Bring forward Revalidation date using TIS | |
---|---|
As a | Revalidation Administrator |
I want | To be able to use TIS to bring forward a Doctor's revalidation date |
So that | I don't have to waste time switching systems and logging into GMC Connect to bring forward revalidation dates |
MoSCoW |
|
Priority |
|
Notes | This will require cooperation from GMC as they will have to provide a new API. |
Requirement 9
Bulk upload of concerns data | |
---|---|
As a | Revalidation Administrator |
I want | to be able to upload multiple documents to the concerns log in one go |
So that | I don't have to keep repeating the same operation over and over again. |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 10
Bulk upload of historic Form R data | |
---|---|
As a | Revalidation Administrator |
I want | to be able to upload multiple Form Rs to Revalidation in one go |
So that | I don't have to keep repeating the same operation over and over again. |
MoSCoW |
|
Priority |
|
Notes | This should be tackled as part of migration to the new Revalidation service, but might be needed once live if not all Form R data is available at migration time. |
Requirement 11
Create Out of Programme “line in placements” | |
---|---|
As a | Revalidation Administrator |
I want | to see an Out of Programme" line in a Trainee's placement history to cover periods when they are not training" |
So that | there are no breaks in the Trainee's legitimate training history otherwise I have to chase round to find out if there is a genuine gap in the placement history |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 12
Create a snapshot of Revalidation data | |
---|---|
As a | Revalidation Administrator |
I want | to hold a snapshot of the information supplied for the revalidation |
So that | I can see the evidence the revalidation recommendation was made on if there are queries about the case in the future |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 13
Display Revalidation submission date in core TIS | |
---|---|
As a | Revalidation Administrator |
I want | to see the Trainee's revalidation submission date in Core TIS |
So that | This could go in Personal Details -> GMC Details |
MoSCoW |
|
Priority |
|
Notes | This could go in Personal Details -> GMC Details |
Requirement 14
Do not show the details of training doctors | |
---|---|
As a | Revalidation Administrator |
I want | to not want training doctors appearing in Revalidation |
So that | I don't see inappropriate connections or data |
MoSCoW |
|
Priority |
|
Notes | When a trainee becomes a training doctor their details still show up as a Trainee |
Requirement 15
Don’t show military trainees | |
---|---|
As a | Revalidation Administrator |
I want | military trainees not to be displayed in my lists |
So that | I don't have to sort through military trainees to find the trainees I should be dealing with |
MoSCoW |
|
Priority |
|
Notes | This only seems to be a problem in the West Midlands Designated Body. Military trainees have their own training and revalidation programmes not associated with the HEE designated bodies. |
Requirement 16
E-mail Trainees directly from Revalidation | |
As a | Revalidation Administrator |
I want | to be able to send a template e-mail, which I can amend, from the Revalidation service to Trainees |
So that | I can quickly send out standard e-mails to Trainees. |
MoSCoW |
|
Priority |
|
Notes | Administrators should be able to select an e-mail template from a drop down list then, after it is populated, be able to amend the e-mail before sending it. |
Requirement 17
Handle trainees in a complicated relationship | |
As a | Revalidation Administrator |
I want | to be able to manage Trainees who are in consortia or shared programmes through both Designated Bodies |
So that | either I, or a colleague in a different Designated Body, can identify the bodies a Trainee belongs to when they are in a complicated arrangement. |
MoSCoW |
|
Priority |
|
Notes | A Trainee who belongs to a shared programme can only be connected to one Designated Body which means they cannot be seen in the partner body. (This may be alleviated by being able to see the full history of Trainees.) |
Requirement 18
Have a concerns log that works | |
As a | Revalidation Administrator |
I want | a concerns log that works |
So that | I can collect the evidence for revalidation on the Revalidation system |
MoSCoW |
|
Priority |
|
Notes | The concerns log just doesn't work! Admins need to be able to make notes and upload evidence of concerns to Revalidation. General TIS users should not be able to see the concerns. |
Requirement 19
Have a support contact | |
As a | Revalidation Administrator |
I want | support to be available during normal office hours |
So that | if I have a problem with Revalidation (or TIS in general) someone will solve the problem or enable me to work round it so I can continue with my day's work |
MoSCoW |
|
Priority |
|
Notes | There should be a proper TIS help desk set up with a published SLA |
Requirement 20
Hide trainers from the connections list | |
As a | Revalidation Administrator |
I want | to be able to stop trainers from appearing in the Connection Discrepancies list |
So that | they don't clutter up the list of Trainees that really do need connecting |
MoSCoW |
|
Priority |
|
Notes | Some doctors, typically trainers who are retired, that need a licence but do not practice show up in the connections discrepancy list because there is no other way to link them to a Designated Body. These doctors do not require linking. |
Requirement 21
Improve the comments box on TIS | |
As a | Revalidation Administrator |
I want | the comments box on TIS to be much larger |
So that | I can read the notes without having to scroll through the small field using the arrow keys (while trying to remember what I've read). |
MoSCoW |
|
Priority |
|
Notes | This box should auto expand to a set number of lines, then fully expand or pop out to give a full view of the comments/notes. |
Requirement 22
Instant refresh of data from TIS | |
As a | Revalidation Administrator |
I want | updates that I or a colleague make on TIS Core to be immediately visible on Revalidation |
So that | I don't have to wait 24 hours for changes to come through to carry on processing a Trainee's revalidation |
MoSCoW |
|
Priority |
|
Notes | All data in TIS should be immediately visible in Revalidation and vice versa. |
Requirement 23
Keep snapshots of revalidation evidence | |
As a | Revalidation Administrator |
I want | the system to keep snapshots of the evidence I used a the point of revalidation |
So that | I can produce the evidence of why a revalidation was made if it is challenged in the future. |
MoSCoW |
|
Priority |
|
Notes | Because a lot of TIS data is dynamic it changes as time moves on. Unfortunately this means the data a revalidation decision was based on is lost. |
Requirement 24
Log that all review documentation has been considered | |
As a | Revalidation Administrator |
I want | to be able to log that all the necessary documentation (ARCP, From R part B, concerns and CCT date) has been considered before a recommendation is made |
So that | it is noted that the legal and procedural requirements have been performed before the recommendation is made |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 25
Mark recommendations as ready to submit to GMC | |
As a | Revalidation Administrator |
I want | to be able to mark recommendations as being ready to submit to the GMC |
So that | recommendations that are completed can have a final check before they are submitted to the GMC |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 26
Need Revalidation data in Tableau | |
As a | Revalidation Administrator |
I want | to see a Trainee's revalidation data in Tableau |
So that | I can use Tableau for reporting on KPIs include things such as deferral sub-reason, late submissions, not revalidated at CCT etc. |
MoSCoW |
|
Priority |
|
Notes | There is no reporting facilities in TIS Revalidation so all reporting has to be done from Tableau and no data gets put into the warehouse from Revalidation. |
Requirement 27
Need a watch list | |
As a | Revalidation Administrator |
I want | a watch list |
So that | I can better manage the Trainees I am focusing on. |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 28
One Click Copy Facility | |
As a | Revalidation Administrator |
I want | a facility to copy GMC number to the clipboard with one click |
So that | I can paste the number into other applications quickly and accurately |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 29
Perform revalidations in quick succession | |
As a | Revalidation Administrator |
I want | to be able to perform a second revalidation, if required, within a short space of time, say six months |
So that | I can bring CCT and Revalidation dates into line |
MoSCoW |
|
Priority |
|
Notes | When only a short period of time has elapsed since the previous validation, Trainees don't appear in the under notice" list" |
Requirement 30
Prevent doctors connecting or disconnecting too early | |
As a | Revalidation Administrator |
I want | to stop doctors connecting or disconnecting from their Designated Body too soon |
So that | I can fully process their Revalidation |
MoSCoW |
|
Priority |
|
Notes | Disconnecting from their Designated Body too early seems to be a particular problem for Doctors who trained to be GPs. I don't have a specific answer as to why this is mainly GPs, but it's possible they get into a practice faster than specialists get positions. The problem is, once they disconnect, they are lost to the Designated Body they should be connected to. |
Requirement 31
Prompt Trainees to make sure they connect properly | |
As a | Revalidation Administrator |
I want | to regularly prompt Trainees to get them to connect to their correct Local Office |
So that | Trainees do not appear on my list of submissions with only a few days notice. |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 32
Pull back inappropriately disconnected Trainees | |
As a | Revalidation Administrator |
I want | to be able to pull back disconnected Trainees into my Designated Body |
So that | Trainees who have disconnected to early can be brought back to the correct Designated Body |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 33
Pull date fully registered from GMC | |
As a | Revalidation Administrator |
I want | to pull the date a doctor becomes fully registered from the GMC database |
So that | I know the FC1s have fully registered before I connect them as FC2s |
MoSCoW |
|
Priority |
|
Notes | This date is not currently pulled from GMC. This would be a change to the GMC interface. |
Requirement 34
Put Trainees under notice | |
As a | Revalidation Administrator |
I want | to put Trainees under notice three months before their due date |
So that | I have adequate notice to process the Trainee's Revalidation |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 35
Record the full Form R on Revalidation | |
As a | Revalidation Administrator |
I want | to see all completed Form Rs (both parts) in the evidence section of Revalidation |
So that | I have all the evidence necessary to make a recommendation in one place |
MoSCoW |
|
Priority |
|
Notes | Form R is am essential part of the evidence used for revalidating trainees. It needs to be presented in the evidence section. |
Requirement 36
Reduce the duplication of effort transcribing data from e-portfolios | |
As a | Revalidation Administrator |
I want | to reduce the amount of copying of revalidation details from the e-portfolio to TIS |
So that | I don't waste time or make mistakes |
MoSCoW |
|
Priority |
|
Notes | The e-portfolios are administered by the Royal Colleges. Each college has its own e-portfolio system. There are 24 Royal Colleges! Additionally, HEE has its own e-portfolio system called HORUS. Maybe we could do some screen scraping? |
Requirement 37
Remove TIS Id from screens | |
As a | Revalidation Administrator |
I want | the TIS Id removed from screens |
So that | I am not distracted or confused by a meaningless identifier. |
MoSCoW |
|
Priority |
|
Notes | TIS Id is not used by the revalidation teams. They use GMC/GDC number as their sole unique identifier for trainees and doctors. Having two separate identifiers for the same person is confusing and misleading. |
Requirement 38
Reporting on deferral reason | |
As a | Revalidation Administrator |
I want | to be able to report on deferral reasons |
So that | I can check the expected number and reasons for deferral are reported properly |
MoSCoW |
|
Priority |
|
Notes | This should be coming out of Tableau but the raw data is not being loaded |
Requirement 39
Save e-mails I have sent to Trainees | |
As a | Revalidation Administrator |
I want | to save and e-mails I send to Trainees against the record in TIS |
So that | I can see the correspondence I, or others, have had with a Trainee. |
MoSCoW |
|
Priority |
|
Notes | Thoughts on this… |
Requirement 40
See all relevant information at a glance | |
As a | Revalidation Administrator |
I want | to see all a Trainees relevant information at a glance |
So that | I get a overall picture of what is happening to the Trainee as rapidly as possible |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 41
See the full history of a Trainee | |
As a | Revalidation Administrator |
I want | to see the full history of a Trainee even after they have moved Designated Body or finished their training. |
So that | I can answer queries about Trainees which can come in years after the Trainee has moved on. |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 42
See the total number of Trainee's retrieved | |
As a | Revalidation Administrator |
I want | to see the number of Trainees retrieved and which page I am on when I have a list of Trainees displayed to me |
So that | I can get a sense of how many Trainees I am dealing with and how far through them all I am at any one time. |
MoSCoW |
|
Priority |
|
Notes | None of the TIS or current Revalidation pages displaying lists of Trainees give an indication of how many Trainees there are in total or how far through the dataset the user is. This means the user has no sense of scale or position in a dataset. |
Requirement 43
See when the last GMC download took place | |
As a | Revalidation Administrator |
I want | to see on my screen when the last GMC nightly download took place |
So that | I know when the list of doctors is out of date |
MoSCoW |
|
Priority |
|
Notes | LOs have indicated it is not always obvious that they are working with stale data. Sometimes it can take two or three days for them to realise the nightly update has failed. |
Requirement 44
Select Revalidation recommendation from a list | |
As a | Revalidation Administrator |
I want | to be able to select recommendation types from a drop down list |
So that | I don't have to type in the recommendation type and can be sure that I have entered a valid recommendation |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 45
Sortable Columns | |
As a | Revalidation Administrator |
I want | All columns on data tables I see to be sortable |
So that | I can organise the data I see more efficiently |
MoSCoW |
|
Priority |
|
Notes | Sorting needs to be based on the whole dataset, not just the screen being displayed. |
Requirement 46
Stop FC1 trainees from being connected | |
As a | Revalidation Administrator |
I want | the system to prevent me from connecting the trainee to my Designated Body |
So that | FC1 trainees are not connected before they start their FC2 course |
MoSCoW |
|
Priority |
|
Notes | FC1s appear in the connections list, but there is no indication they are FC1s and thus can be connected. This is an error, they should not be connected before the first day of their FC2 course |
Requirement 47
Stop early connection of GPs | |
As a | Revalidation Administrator |
I want | to stop GPs connecting if they defer their start date until the post start date even if the programme has started |
So that | GPs are not connected to my Designated Body too early |
MoSCoW |
|
Priority |
|
Notes | The DB does not become responsible for a GP until they actually start their course so, even if the programme has started, GPs should not be connected until they actually start their course. |
Requirement 48
Store actual reason for deferment | |
As a | Revalidation Administrator |
I want | To be able to store the actual reason for deferment alongside the GMC reason |
So that | I can better report on the reason for deferments |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 49
Submit a single recommendation | |
As a | Revalidation Administrator |
I want | to be able to submit a single recommendation from my list of recommendations ready to submit |
So that | I can selectively submit recommendations without having to change the status of recommendations I don't want to submit yet (possibly because not all checks have been made). |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 50
Submit all recommendations in one go | |
As a | Revalidation Administrator |
I want | to be able to submit all recommendations ready to submit to the GMC in one go |
So that | I don't have to waste time repeatedly submitting recommendations on at a time |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 51
View recommendations ready for submitting to the GMC | |
As a | Revalidation Administrator |
I want | to be able to view a list of Trainees whose recommendations are ready to submit to the GMC |
So that | I can easily see which recommendations are ready to submit without having to scan through the whole list of Trainees on the system |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 52
View revalidation status held by the GMC | |
As a | Revalidation Administrator |
I want | to be able to see the GMC status of recommendations I've submitted |
So that | I can track the progress of revalidations I've submitted |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 53
Create a better HTML user interface | |
As a | Revalidation Product Owner |
I want | A better designed user interface which integrates closely with the TIS user interface |
So that | Revalidation Administrators and Trainees are not conscious that they are using different back end systems when they switch between business tasks |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 54
Remove unused fields from Revalidation | |
As a | Revalidation Product Owner |
I want | to remove fields from revalidation that are not used |
So that | The user interface is cleaner and irrelevant data is not stored. |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 55
Don't download the whole GCM Connect Doctors file every night | |
As a | Solution Designer |
I want | To not have to download the full doctors file from GMC Connect every night. |
So that | Revalidation Administrators do not have to wait for an overnight batch run to bring Revalidation into line with GMC Connect. |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 56
Don't clear down the database if the full doctor download fails | |
As a | Product Owner |
I want | To ensure that, if the full Doctors download from GMC Connect fails, the Revalidation database is not cleared down. |
So that | The service can continue to be used even if it is not 100% up to date. |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 57
Provide a 24/7 service | |
As a | Trainee |
I want | Revalidation to be available 24 hours per day, seven days a week. |
So that | I can complete my revalidation tasks at any time of the day. |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 58
Auditing | |
As a | Operations Manager |
I want | comprehensive auditing of messages entering and leaving the service |
So that | I can trace failures in the service more quickly and accurately |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 59
Scalable service | |
As a | Operations Manager |
I want | Revalidation to be a scalable service |
So that | I can meet the seasonal demands on Revalidation without a reduction in service to the end users |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 60
Traceable messaging | |
As a | Operations Manager |
I want | all messages to carry a correlation id |
So that | I can easily trace a single message through multiple systems when tracing faults |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 61
Assign Trainee to an Administrator | |
As a | Responsible Officer |
I want | to be able to assign Trainees to a particular Administrator |
So that | I can balance the workload for Revalidations amongst my team |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 62
Manage Administrators in my Office | |
As a | Responsible Officer |
I want | to be able to add and remove Revalidation Administrators from the system |
So that | I can delegate the management of Revalidations to individuals within my team. |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 63
Permanently re-allocate Revalidations to another Administrator | |
As a | Responsible Officer |
I want | to be able to permanently allocate Revalidations, in one go, to another Revalidation Administrator |
So that | Revalidations are not held up if a Revalidation Administrator is absent for a long period or leaves HEE |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 64
Temporarily re-allocate Revalidations to another Administrator | |
As a | Responsible Officer |
I want | to be able to temporarily allocate, in one go, Revalidations from one Revalidation Administrator to another |
So that | Revalidations are not held up if a Revalidation Administrator is absent for a short period. E.g. sick, holiday, training etc. |
MoSCoW |
|
Priority |
|
Notes |
|
Requirement 65
Set up a mock GMC Connect service | |
As a | Developer |
I want | a mock GMC Connect service |
So that | I can simulate calls to GMC Connect during development and user testing. |
MoSCoW |
|
Priority |
|
Notes |
|
Slack: https://hee-nhs-tis.slack.com/
Jira issues: https://hee-tis.atlassian.net/issues/?filter=14213