We decided a Hack day was long overdue! Hack days are great opportunities to do a bunch of things:
practice collaboration outside the normal group of people you collaborate with
test your specialist skills, or, conversely, test your non-specialist skills
challenge a group of people that may not always work together to plan a time-bound task
examine how the team approaches that task - Agile / UCD
(e.g. plan an hour, reconvene, check with client, plan another hour, reconvene, check with client etc /
research, clarify context, confirm problem statement, hypothesise and experiment to a PoC)maintain focus on one task for a whole day
Lean coffee 'ideation' session
Using a Mural board to give everyone the opportunity to present any ideas they had that the group could then vote on as the most popular subject for a day of teamwork.
Ideas put forward were attributed to their proposer.
Dot-voting
on the range of ideas (using a neat in-built Mural function).
narrowed the list of ideas down to 5 (all receiving 3 votes each).
followed by sticking names next to the idea each individual wanted to work on during the day.
for the most voted on ideas, the proposer of the idea became the de facto ‘Client’ for that idea. They were still allowed to work on their idea, but would be the first port of call for anyone who had questions about the idea, and could be the user to bounce off when it came to experimentation.
Split into teams
…with some suggestions of things to think about
Split the day into morning (10:45-12:15) and afternoon (13:00-15:30) sections, with AndyN checking in to see if anyone needed any help at the start of each session and from time to time throughout.
Both teams began by asking the ‘Client’ to provide more context to the idea so that the team were all on the same page
Team Alpha: Chatbot
Questions to consider answering about how the day went
Team One Data Wranglers!
Team to add what they did, how they got on, observations, etc
Team Alpha had a quick conversation with Nazia AKHTAR as she was the client of this task. The following problem statement was reported by client :
There is an expectation that as we transition the forms R/ARCP process into TIS self service there will be a number of queries from the trainees regarding Form Rs, ARCP process, personal data.
Historically trainees would email admin staff or visit the regional websites for information which adds delay and is time consuming. The aspiration is to get trainees rapid responses in one centralised location and to reduce manual query handling by admins. This will also improve the engagement with trainees and also result with confidence in the system.
The following requirements were discussed. She articulated that if the proposed system could handle “Categories of enquires”, “Doctors enquiry on personal data of ESR”, “Capturing the questions while admins are not able to answer instantly”, “Some queries on ARCPs process” etc.
Rob Pink mentioned that HEE has a chat system which supports for Specialty recruitment for junior doctors and others, i.e, How they can apply for a job. He also mentioned E-learning for health care which does the word search.
After having some concepts in mind that team considered few things to design the chatbot. Some of them are stated below:
Capturing inaccuracy of data
Traffic of email
less delay – save time
Responses from Admin
Conversation tree – add that in the future
Instant answer
Reporting mechanism
How intelligent the chatbot would be?
FAQ
Given the above characteristics team were researching on the net to get some hints and also design and implementation discussions were being continued. Andy Dingley came up with the ideas of implementing Amazon lex into our TSS. We found out that we had only 1 hour 30 minutes sprint/iteration to come up with the PoC.
We had only 30 minutes lunch break and we divided the dev team into front and back end part. AndyD and Jay were looking into the Amazon lex and john o and Yafang Deng were concentrating on the Front end with Amplify.
Screenshot of the TIS Self-Service implementation:
Team to add what they did, how they got on, observations, etc
Team Data Wranglers looked at the issue of whether TIS data could be used as a predictor of poor trainee assessment outcomes. The objective would be to flag-up 'at-risk' trainees to help to target local or national supportive interventions.
Being a very broad objective, the team spent most of the morning in a huddle call devoted to exploring the problem space:
expanding our understanding of the assessment process and outcomes,
the implications for HEE of trainees taking longer to complete their training than expected,
existing research on risk factors for trainee progression (e.g. https://www.gmc-uk.org/-/media/documents/2016_04_28_FairPathwaysFinalReport.pdf_66939685.pdf),
the tools and statistical frameworks one might use to tackle the problem (e.g. Amazon Sagemaker),
ethical concerns around trainee profiling,
other non-TIS sources of data that could be diagnostic (e.g. ePortfolios), and
how one might interface with existing support programmes such as Doctors in Difficulty.
Participation in the call was good (even ‘the client’ pitched-in), but it became apparent that it was unlikely that we would be able to deliver any actual ‘work’ (i.e. a product or POC) during a one-day session. As energy levels flagged, we broke for a 30min lunch with a view to consolidate our objectives for the day thereafter.
After lunch, we decided that non-TIS data might be key to providing trainee-specific risk assessments, while TIS data could provide a baseline of general risk pertaining to e.g. particular programmes/specialties. This suggested two avenues of work:
to model general trainee risk using TIS data, and
to look at incorporating ePortfolio data into TIS, to make it more readily useable for more detailed modelling in future.
At that point, Steven Howard made contact with the London Workforce Planning & Business Intelligence Directorate, and obtained a very useful presentation on their own initiative in exactly this area. Reviewing and discussing that work consumed much of the remaining time, but gave rise to another avenue of work:
to collaborate with LWP&BID
to investigate why the project had perhaps stalled
to see which areas we could help advance
to apply the modelling framework to Outcome 3s (training extensions), as the existing work has focused on Outcome 4s where trainees leave training altogether.
Overall, it was a very useful learning experience for the group. Targeting a broad objective, of which we had limited knowledge at the start, it was perhaps to be expected that we would not be able to deliver anything more concrete than the avenues of work to explore indicated above. However, without the galvanising vision of a specific product to work towards, we were perhaps more in need of a process champion to keep us focused in the latter parts of the day than the other group.
0 Comments