TSS - Customising notification content by LO / programme
https://hee-tis.atlassian.net/browse/TIS21-5331
New Starter Letter 1 - Welcome Comms
Data template:
Scope of investigation: Welcome Comms Letter only at this stage.
Identify data and how to get it:
Propose that no programme-level contact details are held in TIS, only Local-office (LO) level details. The following would be added to TIS:
New TCS table: LoSupport |
|
id | Primary key |
localOfficeId | Many-to-one with Reference.LocalOffice.id |
loSupportTypeId | Many-to-one with LoSupportType.id |
contactText (mostly email(s) or URL) | This is currently a bit messy: not sure if we can enforce any rules on the content text |
|
|
New Reference table: LoSupportType |
|
id | Primary key |
supportType | Create four records: General / Deferral / LTFT / Sponsorship |
|
|
TIS Add to Specialty table: |
|
inBlockIndemnityScheme | True for specialties where |
Simple mock-ups:
Assumptions: we do not need to track changes in any of these tables (e.g. to see whether a specialty used to belong to the block indemnity scheme).
TIS Self-Service:
Sync LoSupport |
Sync LoSupportType |
Data mapping:
Mapping: |
|
|
Welcome Letter Field | TIS field | Joins from Person |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| see LTFT URL/email |
|
| Disambiguation webpage, though the College name(s) can be identified |
|
|
|
|
|
|
|
This assumes the table structure from https://hee-tis.atlassian.net/browse/TIS21-5343
Note that TSS would need to sync the following new tables to have access to this data:
LoSupport |
LoSupportType |
Specialty sync’d table DTO would need a new field added.
Maintaining mappings:
If the data is added as per https://hee-tis.atlassian.net/browse/TIS21-5343 then the obvious place to manage it would be within TIS. This would require editing infrastructure and permissions for
LoSupportType (new Reference table)
Specialty:
inBlockIndemnityScheme
fieldLocal Office: list of
LoSupport
entries
TSS would need to sync changes to these data and include them in the broadcast ProgrammeMembershipEventDto (details of that data design can be finalised later).
LO’s with programme-specific contact details:
For LO’s with programme-specific contact details (e.g. Thames Valley), the proposal is to include programme details in the email header / subject that is sent to the single main email address for that LO. This will allow the LO’s themselves to route the mails to programme-specific email addresses using mail filtering / forwarding rules.
This will also hopefully act to encourage LO’s to use generic email addresses for their main points of contact (e.g. ‘england.tis.eoe@nhs.net’) rather than staff-specific email addresses that might change over the course of time due to staff turnover.
By keeping the contact details at the level of the LO, rather than the programme, keeping the content up-to-date and consistent should be much easier. Otherwise, for a LO with 100+ programmes (as many of them have), the likelihood of keeping contact details up-to-date and consistent for each programme is less than certain. There is no programme-level bulk update facility in TIS Admin.
Example completed template:
Plan B:
The design sketched above would require some effort to implement:
development time for the TIS Admin and TSS teams,
training for LOs, and
time to populate and maintain the data.
If this cannot be justified at this stage, another option would be:
Manage an ad-hoc LO contact table in TSS directly. This would free-up the TIS Admin team, but require LOs to ask TSS to manually update their contact details when these change, which could become burdensome if there is data churn.
Slack: https://hee-nhs-tis.slack.com/
Jira issues: https://hee-tis.atlassian.net/issues/?filter=14213