Intrepid Version 10 Output template – Person

Title of output / Mechanisms for recording and managing persons on Deanery data systems
Owner / Author / Owner - Intrepid person workgroup
Author – John Thompson
Version / 0.9 Initial draft for comments
Product purpose / To define a set of requirements for the composition and function of the following aspects of Deanery data:
  • Person
  • Role
  • System security
  • The propagation of functions and imposition of constraints within the system based upon roles assigned.
  • Integration / crossover with other system functions (including but not limited to assessments, programmes and posts)

Product composition / The following principles permeate these requirements:
  • Conformity to the narrative (express and implied) and data standards defined in the Deaneries data manual – Person section.
The description of person data encompasses the following:
  • Data required to support person, person roles and associated activities contingent upon the assignment of roles to persons.
  • System security and access to functional components based on roles assigned.
  • The data structure of the system.
  • System logic which exists in support of required functionality.
  • A system architecture which supports extensibility for future data requirements

Basic Data about persons / See person data spec for an overview. Subsequent data lists by role will be generated (see below).
Product composition / A means to record basic details of persons.
A set of roles for persons that allows the sensible and efficient functional decomposition of system activity
System security to allow access for users to defined components based on allocated roles.
A means to define roles for persons and logic to support the correct assignment of roles based on other roles and additional aspects of the system
A means to assign persons functional access permissions to components of the data system. This may be either inherited from their roles or manually assigned.
A means to record / manage data about persons using this and other components of the system, as defined by their roles.
A means to identify, filter and / or utilise groups of persons according to their roles and /or membership of other system groups (e.g. programmes, schools, trusts etc)
Means to carry out automatic activity on defined groups of persons, depending upon their role(s).
Product composition details
1)Basic details of persons / The system should not explicitly distinguish between system users (operators) and data subjects (records). All data subjects are potential operators and all operators are data subjects.
All users of the system (persons) should have basic details recorded, sufficient to allow for system administration:
  • Name
  • Email address
  • Phone number(s)
  • Address
  • etc
In addition, the data requirements for individual roles will vary. The system should be able to enforce data requirements based upon roles and provide reports to show where such required data is missing. It should be possible to further constrain role access by school and or programme. Specific data requirements for rolesare attached to this specification.
2)Roles / The role of a person (in conjunction with school, programme and or trust) recorded on the system is the determinant of the following:
  • Constraints on system access permissions (what individuals can see and do on the system, unless overridden by an administrator)
  • Data requirements (what data fields are exposed for individuals)
  • Record keeping / business processes (what components of the system are required to be utilised in support of the business activities carried out by / on behalf of users).
  • Audit / compliance (what exposed data fields and expected processes have occurred for individuals vs what would be routinely expected)
The following user types have been identified to date:
  • Trainee (on training programme)
  • Regular trainee
  • Locum (temporary attachment to programme)
  • Clinician (not on training programme)
  • Consultant
  • Staff Grade
  • LAS (temporary attachment to programme)
  • etc
  • Educational Supervisor
  • Clinical Supervisor
  • Training Programme Director
  • Head of School
  • Clinical Tutor
  • Training Programme Director
  • Royal College Regional Advisor
  • Associate Postgraduate Dean
  • Lay person
  • System administrator
  • System user
  • Deanery
  • Trust
  • Other
  • etc

3)Security / The default system functions exposed to a person will be dependant upon their role. These should be defined and granting of access permissions should be automated where prudent to do so.
Security should be industry standard, using stored database procedures and security role objects with specific access permissions to the stored procedures.
4)Role definitions and assignment / Creating / importing a person record into the system should involve the assignment one or more roles to that person. Where that role can be implied, it should be created automatically (e.g. candidate import from recruitment : role = trainee).
There should be a truth table for all roles, showing which other ones are not permissible in combination with that particular role. (e.g. It is not possible to be an educational supervisor AND a trainee simultaneously).An alternative approach would be a hierarchy of role classes as inheritance objects.
Role assignment should be automatic where predictable (e.g. Assignment of a person to a training programme).
A role assignment has a start date and an end date, and may have multiple instances.
5)Role permissions / Each role will be able to access certain views of person data and carry out certain system functions.
6)Role behaviours / A role can have a lifecycle which may be semi-automated.
Example: Trainee lifecycle in conjunction with programme object
  • Candidate import – Role = Trainee  role start date
  • Assign to programme (based on recruitment)
  • Assign NTN / DRN – issue date = trainee role start date
  • Process form R
  • Assign to school (programme school)
  • Assign placement rotations
  • Conduct assessments as required / modify placement as required
  • Automaticall y assign end of placement questionnaires.
  • Manage leave / study requests
  • Manage CESR as required
  • Manage OOP / Maternity / modify placement as required
  • Final assessment / accreditation
  • Period of grace
  • Release training number = release date = trainee role end date
  • Release from training programme
  • Inactivate person record
  • Remove role = trainee  role end date
  • Remove system access permissions
Example: Educational supervisor lifecycle
  • Assign role to existing consultant – role  start date
  • Associate trainer with programme (prompted)
  • School automatically assigned (from programme)
  • Trainer now available to assign to trainee(s)
  • Record accreditation in supervisor training
  • Record training assignments (trainees / posts)
  • Trainer no longer wishes to be a supervisor  role end date, remove role permissions
  • OR Consultant retired (from other module) position end date, role end date, inactivate person record, remove data permissions

7)Role constraints / Each role will impose constraints upon system activities and data:
Full list to be defined.
Examples:
Training programme director
  • Read / write view of rotation planner for own programme(s)
Head of school
  • Read only view of all rotation planners for programme(s) within own school
  • ? Trainee records for all trainees within own school

8)Roles as filters / The system should support the filtering of lists of persons by role and associated data set. This may be a significant determinant of the views system users have.
Full list to be defined.
Examples:
  • Specialty programme administrator person list view = all trainees associated with the programme. Data set restriction = all data required for programme management.
  • Educational supervisor list view = all trainees assigned to that supervisor
  • Trust medical staffing view = all clinical staff assigned to that Trust
  • CESR administrator list view = all trainees with CESR records
  • Course administrator person view = all persons who have applied online for that course. Data set restriction = relevant data for course booking.
  • Trainee view = own data only, plus perhaps contact details of people on / managing their own programme(or a messaging system which hides their contact details but still allows contact).

9)Automated activity based on roles / There are a number of labour saving activities that should be automated, based on roles.
All roles that can be derived should be automatically assigned, with conflicts being passed as errors to users.
Examples:
  • If a person is inactivated, all their roles should be inactivated from this date.
  • If a trainee is created, their trainee role should be activated from this date.
  • If a trainee leaves a programme, their trainee role should be inactivated from this date.

Product derivation / Deaneries Data Group Person specification
Product format / Online data system
Responsibility for producing product / Hicom ltd
Deaneries data group – Intrepid V10 project board
Product quality criteria /
  • Meets specifications – signed off by deaneries data group Intrepid V10 project board
  • Meets user acceptance test criteria (tbc)
  • Independently verified system penetration testing

Note / The concept of programme is central to the use of person data within medical training. A programme will determine the trainees which a person / role combination will have access to

Examples of View Tables

1)Educational and clinical supervisor @ Cornwall Hospitals (with access to CESR system)

Role / Programme / Trust / School / Notes
Educational Supervisor / Core Medical Training / Cornwall Hospitals
Clinical Supervisor / Cornwall Hospitals / Can clinically supervise any trainee @ Cornwall
Clinician / Own data view
CESR / Core Medical Training / Cornwall Hospitals

2)Deanery programme administrator – schools of medicine and pathology

Role / Programme / Trust / School / Notes
System user / Medicine
System user / Pathology
Person / Own view

ROUGH NOTES – alternative approaches and concept verification

Person Hierarchy

A generic person is broken down into 2 distinct components:

System access

Which components of the data system the person will have access to

Person Type

What information will be recorded about the person on the data system

Person types

Persons are broken into two possible types – inherited roles (classes) and assigned roles (interfaces)

Question – will there be inheritance or is everything to be managed as a flat hierarchy?

Possible inherited roles hierarchy

  • Abstract class - may be useful if system expansion into non-medical clinical staffing is required in the future.

Question and assumptions:

How do you define a medic?

  • Assign a role of ‘medic’
  • Create as a subclass of person
  • Do not specify

Are there subclasses of ‘Medic’

  • GP / Dentist etc
  • Defined by assignment / placement

Is a trainee class a separate class?

  • Option 1 - Atrainee is any medic who is currently assigned to a training programme.
  • Option 2 – a trainee is anyone who is explicitly assigned the role

Is there a need for a separate non-trainee medical staff class?

  • Depends if you want to explicitly prevent non-trainees from being treated as trainees.

Is there a need for a non-clinical staff class?

  • Depends if you want to explicitly prevent non-clinical staff from being treated as medics

Which system roles are inherited from person class membership?

  • E.g. leave manager

Roles (Interfaces)

Role / Permitted Classes (if used) / Role(s) not allowed
Educational Supervisor / Medic / Trainee
Clinical Supervisor / Medic / Trainee
Clinical Tutor / Medic / Trainee
Training Programme Director / Medic / Trainee
Royal College Regional Advisor / Medic / Trainee
System administrator / Person
Associate postgraduate Dean / Medic / Trainee
Foundation programme Director / Medic / Trainee
Administration staff / Person
GP educator / Medic / Trainee
GP education fellow / Medic / Trainee
GP tutor / Medic / Trainee
Director of Medical Education / Medic / Trainee
Lay representative / Person
Royal College External Advisor / Medic / Trainee
Trainee / Any where trainee not allowed

Question: will the list of restricted roles be user definable?

If so, automated system logic may be difficult to implement!

Roles define access to system security

Assign roles to person

Filter by role

Automatic filter by role in certain circumstances

Automatic for anyone assigned to a training programme (NTN/DRN)

Assign school

Automatic for anyone on or a member of a programme

Assign programme

Prompts for role

Assigns school

Assigns role

System cleanup

How are roles etc cleaned up – what automation rules are there?

Start and end dates for roles?

System functions

Create person

Amend person

Inactivate person

Delete person

Assign role

Deactivate role

Recruitment import – automatically assign role of ‘trainee’

Assign programme (as trainee)

Automatically assign role of trainee

School inherited from programme

Activities within programmes

Recruitment

NTN / DRN assignment

Form R

OOP or maternity

Assessment

CCT award

Rotation

Leaver process

Leave

Annual

Study

OOP

Maternity

Course booking

CPPS self referral / access to workflow

Update own information