V10 Liaison Group
Output template
Title of Output / Programmes Management ComponentOwner / author / John Thompson
Version and note / V1.2 24th April 2012 – Draft for liaison group approval
Product Purpose / To provide a component for the creation and management of medical training programmes, including the integration of this component with other components that are controlled by it.
Product Dependencies / Programmes are high level ‘container’ objects used to group, organise andadministerdeanery activities. They hold their own data and facilitate drill down to other component parts. Programmes hold all the data which is distilled down to their posts and to the related placements.
- Person(trainees are trainees because they are enrolled on programmes)
- Curricula - the training content of programmes.
- Post (a training post is a post belonging to a programme). Posts within a programme may be subdivided into rotational families, which assist with rotational planning. Posts may be approved for more than one programme but may only belong to a single programme at any time.
- Training number (training numbers are associated with programmes).A training number has the same specialty code as the primary specialty of its containing programme.
- Rotational Planning (usually happens within programmes)
- Assessment (occurs within programmes and is ultimately assessment of programme / curriculum progress, not placement progress)
- Out of programme (not really ‘out’, but still ‘in’ while doing something other than regular training)
- Maternity leave (from a programme, at least for trainees)
- Study leave (learning carried out while on a programme)
- Sick leave / absence (total days sick during training may affect certification eligibility)
- Expenses (ad hoc expenses for relocation occur across all programmes together during the entirety of training)
- Grade groups (sets of grades that are valid grades to assign within programmes – there may be more than one for a programme)
- Progression (advancement through enumerated grades as a result of assessment within one or more programme specialties)
Product composition / The component will have the following, major functions:
- Facilities for selecting and displaying programmes and drilling down to their component parts (by trainee, post, training number, curriculum, rotation, assessment etc). A list of programmes is likely to be one top level view within v10
- Addition of a management area to administer programme set-up, approvals and review. This would include a new programme status where the programme (and associated posts) may be in a “pre-live” status. Review of the programme may be against all or part e.g. a review of the MTC against curriculum.
- Facilities for setting up and managing curricula and for assigning or removing them from programmes. Curricula may exist in their own right, but are always employed within the context of programmes.
- Facilities for managing descriptive data regarding programmes
- Programme name
- GMC approval code
- GMC Maximum training capacity
- Warnings where WTE maximum training capacity may be exceeded
- GMC approval start / end dates
- GMC review date
- Training number type for regular (not LAT / FTSTA) trainees (NTNor DRN will be the options)
- Training level
- Training length (N days /months / years) – moved to curriculum
- Programme Director (person(s))
- GMC approved sites (list)
- GMC approved trusts (list)
- Site and trust approval status
- Any rotation families that exist for that programme (subgroupings for posts / trainees to assist with planning)
- Programme specialties. These are the options for the specialty assessed for a trainee. An assessment for a trainee on a programme may be for one or more of these specialties only.
- Approved curricula + historical data
- one programme may have more than one curricula
- it may only be possible to enrol on one of several active curricula (additionally, other curricula may still be active with trainees ‘finishing off’, but these curricula are not recruitable to)
- A trainee may follow any curriculum associated with the programme they belong to. A trainee on a programme inherits the properties of the curricula they are following (specialties, programme length etc).
- A trainee may follow more than one curriculum while on a programme, but only one at a time (ie trainees may move between curricula).
- A programme could have many curricula attached to it
- A curriculum may be associated with more than one programme
- A trainee with an “earlier” curriculum may not be able to be placed in a post which is approved for a “later” curriculum.
- Curricula may be bypassed and are not functional requirements for users
- Facilities for adding or removing data components comprising (packaged within) programmes
- Adding or removing posts, including temporary transfer of posts from one programme to another.
- Creating, assigning or removing curricula from programmes.
- Adding or removing trainees (enrolling, graduating or removal). There will be a clear lifecycle with validation and automation where appropriate. Closure of a programme for a trainee will require all subcomponents to be closed off correctly.
- Adding / creating or removing training numbers, including the facility to pick the next NTN or create a new DRN as required.
- A specialty level view of training numbers (above the programme view), showing the programmes they belong to and with the facility to move numbers (not currently held) between programmes.
- Automatic methods to recycle / archive training numbers (DRN = archive, NTN = recycle)
- Scheduling, creating, adding or removing assessment events. Addition of the first assessment event (PAR – see assessments module) will be automatic on enrolment to a programme.
- Facilities to create grade groups and assign grade groups to programmes
- The ability to “filter” grades, specialties and sites for further distillation to posts. i.e. A post cannot have a specialty, grade or location which is not captured at programme level.
- The ability to assign posts and trainees to rotation families
- Facilities for managing individual programme assignment data for trainees within programmes (personprogramme):
- All a trainees programmes (top level view of a trainee). A view of a trainee’s placement record should be switchable between programme level and placement level views. Programme view will ‘box up’ all placements within a programme and show the programme name start and end dates. Post view is an expansion to show all placements within a programme.If a person has non-training placements (outside a programme), these will be incorporated in date order, but are not boxed into a programme view.
- For each trainee’s programme
- Educational contract details
- Programme Start Date
- Programme End date
- Specialties (inherited from curriculum if set)
- Cct date (if applicable)
- Status (pending, training, OOP, sick, military placement, period of grace, completed)
- Training number (list – only one may be current). The issue and release date will usually coincide with the programme start and end date (unless the training number is changed, in which case these will be a list of previous numbers and dates). For multiple training numbers within a programme, the first issue and last release date corresponds with the programme start and end date.
- Time in programme
- Training time in programme
- Placements in programme
- Assessments in programme (including assessments due)
- Out of programme data (where appropriate, including periods of military service for MOD trainees)
- Facilities for managing individual programme assignment data for posts within programmes (programmepost):
- All posts
- Post approval status within programme
- Assignment of rotation family
- Occupancy / Vacancies
- Locum occupancy
- (Once a user has selected a programme)a display of the programme data with drill down to lists of all the posts, training numbers and trainees who are containedwithin the selected programme. Within the selected programme, it will be possible to use predefined filters to narrow down the actual posts and trainees displayed, (e.g. by rotation family / trust / site / curriculum etc).
- Trainees and posts within a programme should be bindable to a rotation matrix. In many cases, programmes (or rotation families) should be the main selection unit when creating a rotation, although other filters may also apply (grade, trust, curriculum etc).
- It should be possible for a trainee to change curricula from one to another within the same programme, bounded by dates.
- It should be possible for a trainee to change their training number from one to another within the same programme, bounded by dates.
- All training should ultimately take place within programmes and it should not be possible to manage training, placement or assessment for trainees without correctly established programmes to contain this activity.Trainees may usually only be assigned posts within the programme they are enrolled on (exceptions will require temporary virement of posts to a programme, with an accessible audit trail and permissions requirements from data administrators / programme directors of the donor programme)
- LATs and FTSTAs will be assigned to programmes. DRNs will be issued. Appropriate grade groups will be required.
- Non training locums (LAS) may be assigned to programme posts but willnot be full members of the training programme (no training number or assessment). A separate status or flag will be required for this, This type of placement within a programme post should be the only option for persons not enrolled on training programmes.
- Facilities to remove trainees from programmes which take into account any embedded / child data and manage this process correctly (check for unfinished assessments, future posts, training number release, current posts etc).
- Programmes will be a security object within Intrepid v10. It will be possible to constrain user views by programme (among other things).
- For convenience and for ease of administration of non-deanery activity on Intrepid, non training posts and non trainees (consultants, trust grades etc) will be contained within a virtual programme consisting of all such objects NOT within a programme. This virtual ‘non programme data’ object will be a security object. This security object can be used to set up staff in hospitals who do not deal with trainees (non training post creation etc)
- Recruitment will be to a programme. Membership of a programme will be ‘pending’ after recruitment and before rotations commence.
- The ability to cluster programmes against a School (in a hierarchy, the level below the deanery).The facility will be provided to group programmes within schools under a head of school, if required. Schools will be security objects.
- The ability to share programme (and post) information between different deaneries. In the Dataset this is indicated by “ownership”. The ideal would be fordata to be shared as read-only records between e.g. deanery A and deanery B. For example, where deanery A creates placements against posts “owned” by deanery B. This functionality would avoid the need for duplication of posts and trainees where ownership is elsewhere, so that each deanery can see the “full picture”.
Product derivation / Gold Guide, Deanery Data Manual, the supplier, requirements analysis both with deanery admin staff and with potential end users of the module.
Product format / A software module plus online documentation and additional documentation in Word format.
Responsibility for producing product / Hicom, Deaneries Data Group, Intrepid V10 Project Board.
Product quality criteria /
- Does the module conform fully to the principles contained in the Deanery Data Manual: specifically, the principles that govern the concepts of Programme, Rotation, Post and Placement, and the relationships between them?
- Does the module contain certain key features? These are:
- Creation of programmes, including configuration of programme data
- Assignment of curricula, posts, persons and training numbers to programmes
- Constraint of grades assigned within programmes by grade group
- Constraint of placements assigned to by programme
- Management of trainees within programmes
- Planning and administering rotations through programmes or subsets of programmes (filtered or saved rotation groups ./ rotation families)
- Organisation of assessments by programme
- Drill down to linked / contained data through programmes
- Does the module allow Programme Directors / School managers to hold the data that are required in order for them efficiently to manage programmes?
- Are there adequate reporting functions to allow reports on programmes to be easily and quickly generated? Does the data structure support a standardised recordset with predictable properties?
- Does the module display acceptable response times?
- Is the module interface sufficiently easy to understand and operate in relation to its target users?
- Has the product been inspected and approved by a representative sample of its target users?
- Is there adequate documentation? Is it accurate and complete?
- Has the product been adequately piloted?
Product testing Methods /
- Inspection against Data Manual.
- Inspection for presence of key features.
- Inspection / testing by deanery technical personnel.
- Inspection / testing by user community.
- A pilot.
- Inspection of documentation for intelligibility, accuracy and completeness.
Notes
Title / Descriptive title of the Output / ProductOwner / Who “owns” the document
Version / The document may be iterative
Product purpose / What purpose does the product fulfil
Product composition / The detailed explanation for the output of the requirement. This provides the precise output requirements and parameters from which Hicom can design a solution.
Product derivation / Further references which dictate or influence the product e.g. Gold Guide etc
Product format / The form the product will take.
Most outputs will be based within V10.
Responsibility for producing product / This will a list of those who are participating in the development work, including a named Hicom contact
Product quality criteria / Self explanatory, although some global quality measures will be defined
Product testing criteria / How the developed product is tested and to what standards
Appendix – Descriptions and examples
NTN
- One trainee holds one training number at a time (except foundation trainees, who do not currently have a training number)
- The training number itself only indicates one specialty (unless the GMC create a trick specialty code for dual specialty etc), although accompanying data may indicate more.
Programme
- A trainee will belong to a single ‘programme’ at any time.
- A programme will have a single primary specialty (conventional) which will match their training number specialty.
- All training numbers will belong to programmes associated with their default specialty
- The Foundation programme does not currently have training numbers.
Curriculum
- A Curriculum is a template for a programme, which outlines the ‘flavour’ of training for a trainee. A trainee’s programme will inherit the properties of their curriculum
- A curriculum may have one or more specialties. These curriculum specialties are the CCT specialties a trainee is working towards. Each may have it’s own specific requirements
- Trainees on dual or tri cct will belong to a single programme (defined by their conventional primary specialty from their NTN) with a curriculum that describes the multiple cct specialties they are training towards
- Each curriculum specialty may have a sub specialty.
- A curriculum will have a length.
- Each curriculum specialty may have it’s own specific training requirements. It will be possible to attach a descriptive document to a curriculum.
- A curriculum may belong to more than one programme. For example, a set of GP training programmes split geographically within Deanery boundaries may have several GMC programme approval codes but share one curriculum.
- A curriculum could exist unattached to a programme, in this case, it is fallow.
Post
- A post may be approved for zero or more programmes
- A post may belong to zero or one programme at any time.
- A post may be approved for zero or more curricula
- If a post is approved for a programme, the default is for it to be approved for all the curricula associated with that programme.
Maximum training capacity
- A programme may have a maximum training capacity.
- A curriculum may have a maximum training capacity.
- Training locations may have maximum training capacity set by programme or curriculum,
- Calculation of MTC thresholds and reporting will require further specification.
Examples which the model will need to / can cope with in current form
1)Respiratory medicine
All respiratory medicine trainees will have an NTN of the form NTN/004/nnn/X
e.g.PEN/004/001/C
WMD/004/025/N
There are 3 possible curricula within specialty training for respiratory medicine
- Respiratory medicine (4 years)
- Respiratory medicine and general Internal medicine (5 years)
- Respiratory medicine, general internal medicine and intensive care medicine (6 years)
Each trainee will may have zero or one curriculum, which will provide a template of their specialties and their estimated cct date. Manual setup is possible.
It is possible to set up a single programme for all respiratory medicine trainees containing all curricula or multiple programmes, each with their own curriculum. The choice of option will be at the discretion of individual deaneries.
Each curriculum may have it’s own MTC. Posts may be approved against the curriculum. Approval against the programme may also be conducted if required.
2)Dual CCT in Psychiatry and Psychotherapy with new specialty code
There are currently 3 specially coded psychiatry dual specialty programmes:
- XP4 Forensic Child and Adolescent Psychiatry
- XP1 General Adult Psychiatry/Old Age Psychiatry
- XP2 General Adult Psychiatry/Psychotherapy
Trainees enrolled on these programmes will have an NTN of the form NTN/XPn/nnn/X
e.g.WSX/XP4/001/N
TSD/XP2/095/A
Each of these programmes will have their own curriculum containing 2 specialties.
Each trainee will follow a single curriculum containing both specialties.