V10 Liaison Group
Output template
Title of Output
Programmes Management Component
Owner / 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 and administer deanery 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)
Programmes also have their own data (outlined below).
Product composition
The component will have the following, major functions:
1. 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
2. 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.
3. 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.
4. 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 (NTN or 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
(sub groupings 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
5. 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
6. Facilities for managing individual programme assignment
data for trainees within programmes (personprogramme):
For each trainee.
 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
o Educational contract details
o Programme Start Date
o Programme End date
o Specialties (inherited from curriculum if set)
o Cct date (if applicable)
o Status (pending, training, OOP, sick, military
placement, period of grace, completed)
o 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.
o Time in programme
o Training time in programme
o Placements in programme
o Assessments in programme (including
assessments due)
o Out of programme data (where appropriate,
including periods of military service for MOD
trainees)
7. Facilities for managing individual programme assignment
data for posts within programmes (programmepost):
For each programme
o All posts
o Post approval status within programme
o Assignment of rotation family
o Occupancy / Vacancies
o Locum occupancy
8. (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 contained within 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).
9. 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).
10. It should be possible for a trainee to change curricula from
one to another within the same programme, bounded by
dates.
11. It should be possible for a trainee to change their training
number from one to another within the same programme,
bounded by dates.
12. 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)
13. LATs and FTSTAs will be assigned to programmes. DRNs
will be issued. Appropriate grade groups will be required.
14. Non training locums (LAS) may be assigned to programme
posts but will not 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.
15. 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).
16. Programmes will be a security object within Intrepid v10. It
will be possible to constrain user views by programme
(among other things).
17. For convenience and for ease of administration of nondeanery 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)
18. Recruitment will be to a programme. Membership of a
programme will be ‘pending’ after recruitment and before
rotations commence.
19. 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.
20. The ability to share programme (and post) information
between different deaneries. In the Dataset this is indicated
by “ownership”. The ideal would be for data 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
Responsibility for producing
product
Product quality criteria
A software module plus online documentation and additional
documentation in Word format.
Hicom, Deaneries Data Group, Intrepid V10 Project Board.

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 record set 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?
Product testing Methods

Has the product been adequately piloted?

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
Owner
Version
Product purpose
Product
composition
Product derivation
Product format
Responsibility for
producing product
Product quality
criteria
Product testing
criteria
Descriptive title of the Output / Product
Who “owns” the document
The document may be iterative
What purpose does the product fulfil
The detailed explanation for the output of the requirement. This provides the
precise output requirements and parameters from which Hicom can design a
solution.
Further references which dictate or influence the product e.g. Gold Guide etc
The form the product will take.
Most outputs will be based within V10.
This will a list of those who are participating in the development work,
including a named Hicom contact
Self explanatory, although some global quality measures will be defined
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
a. Respiratory medicine (4 years)
b. Respiratory medicine and general Internal medicine (5 years)
c. 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.
The MTC of each programme is set separately.
3) GP programmes split by region
Some Deaneries split programmes by region. An example of the Peninsula GP training
programme, which consists of 5 geographical regions, each with their own programme
approval:





SWP917 - Cornwall
SWP918 - Plymouth
SWP919 - Torbay
SWP920 - Exeter
SWP921 – North Devon
A trainee will be recruited to one of these programmes.
Each programme will share one curriculum (General Practice).
The MTC of each programme is set at the programme level (i.e. there is no MTC for the
curriculum)
Maximum training capacity
MTC is calculated as the total number of wte trainees that may simultaneously occupy posts
belonging a programme. This may need to be be broken down by trust, site and/or curriculum version.
In order to discover whether MTC is being compromised, it is necessary to be able to calculate the
total WTE complement of trainees against MTC numbers.

Programme – Calculate MTC against programme specified MTC

Curriculum version – Calculate MTC against curriculum defined MTC (n.b. it is necessary to
utilise curricula for this to work).

Trust – calculate WTE at the trust against programme / curriculum specified Trust MTC

Site - calculate WTE at the trust against programme / curriculum specified site MTC
System logic Description
1 School provides 0 or more programmes
1 Programme belongs to 0 or 1 school

Schools are optional – there is no requirement for programmes to belong to schools,
nor for schools to be created
1 Programme delivers 1 or more CCT specialties
1 CCT specialty is delivered by 0 or more Programmes

Each programme must have at least 1 specialty associated with it (programme
specialty) – generally this is the same as the programme name
1 curricula is associated with one or more programme specialties
1 curricula is associated with zero or more programmes

A curriculum is an optional component which defines the specific specialties and
training time for a programme.
A trainee on a programme may be assigned to a curriculum. The curriculum assigned will dictate
programme specialties and completion dates.
A trainee on a programme must have at least one programme specialty that matches the
programme’s specialty list (conventionally, they should match the first (primary) speciality and hold a
first specialty training number).
All training numbers belong to programmes. A training number may only belong to a programme with
which it shares the programme’s primary specialty.
Training numbers may be moved between programmes, provided the specialty codes are shared (as
above).
A trainee may only hold one training number at a time, but a trainee may hold more than one training
number during the course of programme membership.
A programme has a number of approved posts associated with it. Each post may be approved for
zero or more programmes (posts not approved for programmes are not training posts).
A post may only belong to a single programme at a time.
A post may be approved against zero or more curricula
A trainee on a programme will have 1 or more programme specialties,
If a trainee is assigned a curriculum, each programme specialty will match the programme specialties
of the assigned curricula for that specialty.
A trainee (a person enrolled on a programme) may have zero or one training number at any time,
drawn from the pool of training numbers associated with that programme.
A trainee on a programme will conventionally be placed in posts approved for that programme,
although this may be overridden.
Logic order – System setup for programmes / curricula
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
11)
12)
13)
List all specialties with specialty codes (reference data)
Complete Trust and site data (reference data)
Create Schools (if required)
Generate programmes, including GMC approval codes, primary specialty and MTC
Assign programmes to schools (if required)
Create curricula (if required)
Assign specialties to curricula if used.
Create training numbers
Assign training numbers to programmes
Create posts
Assign posts to programmes
Create trainees
Assign trainees to programmes
a. If curricula are assigned, assign trainees to curricula
b. If no curricula, set programme specialties and completion dates etc manually
14) Assign NTN to trainees (dates should inherit from programme start / end dates)
15) ROTATIONS...
16)
Design options worth further consideration (likely to be an easy change in software)
1) Link training number to Training Specialty rather than to Programme
 A pool of TN’s would exist for all programmes sharing the primary specialty of the TN
 This is a moot point – both views should be possible if NTN’s are assigned to
programmes.
2) Allow a post to belong to more than one programme at a time
 Sharing of posts between programmes for complex rotations would be easier but
accounting for these posts would be harder.
 The correct design decision for this may not emerge until after usability testing.
Further development discussion required

How to calculate / manage maximum training capacity for programmes, curricula,
trusts and sites.
John Thompson
24th April 2012
Example class diagram showing significant programme components and associations