Update went-for-an-appointment-came-back-with-a-list.md

reduced a lot of the content after Dan reveiw

Author: johnrimmer2

app/posts/record-a-vaccination/2025/07/went-for-an-appointment-came-back-with-a-list.md

@@ -4,201 +4,57 @@ date: 2025-07-11
 ---
 
 
-## The challenge
+## What
 
-For a long time now we’ve heard from RAVS users that they often need to pair RAVS with another system when running clinics in order to ensure they’re both up to date with and updating systems they may use for booked vaccine appointments. This can mean having two systems open, copying and pasting as well as other manual duplication.
+We wanted to create appointments in RAVS to allow users to benefit from having structured lists of patient to reflect the way in which many already work. We could also shorten the recording time with the appointments having the same attributes such as the vaccine they will receive. This means no need to record vaccine, time, date etc. as it’s already known in RAVS. 
 
+Unfortunately we not be able to integrate with booking systems anytime soon, given the technical effort, time differing data points across all systems in the market.
 
+So, we decided to see if we could recreate something similar in RAVS, but with some manual entry by the user. 
 
-Being able to show appointments in RAVS  would be a step closer to an end-to-end experience for healthcare workers dealing with patient bookings. They could simply pick a patient from a list with a time and date against their name and are booked in to receive a vaccine. By having the appointments in RAVS it could mean one less system used, one less screen open, one less new tool to learn and stay on top of for NHS staff.
 
+## Approach
 
+We first tried to be clever and allow the user to do more and get more 
+We looked at many options including asking users to use a template to then upload a consistent set of data for each of their appointments.
 
-More specifically, some of the high level benefits we assumed would be:
+We decided this could become difficult to explain and put the burden too far on to the user. Instead we asked them to answer a few questions and upload a ‘list’ of the NHS numbers they had from their booking system or elsewhere to let RAVS do the rest and create a view of the uploaded names. 
 
 
+## Designs part 1
 
-Time saved not having to find patients via typing in unique 10 digit NHS numbers in RAVS and  no inaccuracies or re-typing.
 
-Time saved in the record journey of RAVS by pre-loading a list of patients with the same attributes such as vaccine, date, vaccinator and so on. This would mean the clinician would not need to select them when recording.
 
-Improve recording accuracy by selecting the right patient from a predefined list.
+## Outcome
 
-Ability to flow data from RAVS to the booking systems could mean wider benefits for following up on ‘Reasons for not having the vaccine’ at an appointment, with opportunities for more patient-specific care thereafter to help drive uptake.
+We tested with users and found that adding NHS numbers was a particularly tricky task for our them.
 
+This could’ve been due to many reasons. 
 
+It’s a completely new concept and a new task in RAVS. Adding large sets of data doesn’t have a lot of precedent in NHS or GOV design patterns, so we were designing new ground.
 
+We weren’t able to see or access their lists of patients for confidentiality reasons, so seeing how they might copy and paste patient data in anger wasn’t possible and providing them with a faux list didn’t solve the issue of being able to see theirs.  
 
 
-As part of our assumption we determined that there were 2 feasible options on the table for how we might achieve this for RAVS.
+## Iteration
+To do a better job for our users we decided further simplicity was the best approach, then we can change and adapt if it is successful and users have more confidence. We reduced what the user needed to do further by:
+- Removing the ‘check’ screen in favour of error messages on the page for erroneous NHS numbers
+- Only showed 1 list instead of 2 tabs of Awaiting and Recorded on the list page
+- The search then only applied to 1 list
+- Moved ‘delete list’ to the bottom of the page to reduce how busy it was at the top
+- Review and iterated the content, particularly on the add nHS numbers page
 
+Finally, we renamed the section to better describe what the thing now was. A list of patients, their NHS numbers, a date and a location
 
-
-### Option A
-
-Integrate with existing booking systems currently in the market and allow those systems to speak to RAVS to automatically show booked patient appointments, with little to no effort from the user. However, this would mean time and effort from both RAVS and the booking system providers to facilitate and develop any potential solution.
-
-
-
-
-We would also have to manage the ingestion of potentially hundreds of differently formatted data types across the different booking systems, depending on how they choose to name and store their data in the absence of a uniform approach. The upshot of this option would mean much less work for end users a long term goal of RAVS no doubt, but greater efforts to develop in the meantime.
-
-### Option B
-
-Allow users to manually add appointments by designing and building a section in RAVS which would let users do this themselves, on the prerequisite that they have a list of names and matching NHS numbers. This could come form their booking system or another source, such as a staff list stored locally on their device (e.g. an excel file).
-
-
-
-The benefits of this option meant the RAVS team could be more in control of when and how it was delivered and could be a stepping stone for future appointments integration if the feature was in some way successful. The downside was the requirement on the user to understand the introduction of this new feature and whether they would be able to successfully do what was asked of them in RAVS.
-
-
-
-
-
-Ultimately, we decided to both. We would attempt a tactical solution with option B and have plans for a longer term strategy of integrating systems in option A.
-
-
-
-We would speak with providers of booking systems to understand their timelines, needs and expectations around integrating appointments with RAVS. This meant we had at least opened a line of communication with stakeholders we would need to speak to in the future, but also understand approximately what the development feasibility and viability from a cost and time perspective.
-
-
-
-Our business analyst also conducted an analysis of all available booking systems where possible, to understand what data they captured and what structure it was in. This would allow us to know what data we could potentially integrate, from which system and in what form. For example, did the booking system capture the NHS number when creating a booking? In almost all cases, the answer was yes.
-
-
-
-In tandem, we got to work as a UCD team to look at how such an appointments solution might look like in RAVS.
-
-
-
-
-
-## Our approach
-
-Like any good design challenge we started with big ideas and refined them. Our initial concepts included allowing the user to do as much as possible with a lot of flexibility in order to help them adapt the appointments to suit their organisations needs, whilst allowing them to reduce the amount of answers they would have to record with each vaccination record, as data was being pre-selected upfront.
-
-
-
-One such solution would require a user to download an excel template from RAVS with columns showing the expected data and format to copy across from their booking system. This could then be uploaded in to RAVS and the user could see as much or as little information as they had added to their file.
-
-
-
-Pre-determined vaccine for the booking? That would show on the appointments.
-
-
-
-1000 patients listed? We’d allow them to add as many as they needed.
-
-
-
-However, after much deliberation, sketching and sharing opinions, we decided that with an MVP approach in mind and time to learn for users at a premium in care settings, that simpler would be better and that we could build on anything we learned if we succeeded in translating the concept to our users. To do this, we would ask for NHS numbers, site and date as a minimum, in order to be able to search against the Patient Demographic Service (PDS) and make displaying patient details and vaccination history easier in RAVS.
-
-
-
-
-## Designs
-
-The initial designs asked users to go through a few steps to add their appointments. It was also assumed based on the analysis and desk research that uses in many cases would be able to extract a list of NHS numbers in some form that they could enter in to RAVS. The screens consisted of:
-
-
-
-- Appointments home screen
-
-- Select a date
-
-- Select a site
-
-- Add NHS numbers
-
-- Check appointments
-
-- Appointments list
-
-
-
-Once a list of appointments had been added in, a link to the site or team was visible on the home-screen, taking the user to a view of dates of lists associated to that site or team.
-
-
-
-
-
-## User Feedback
-
-We tested the appointments design with RAVS users in order to assess their understanding and their ability to create appointment lists. Although the prototype wasn’t set-up to ingest information or sort them in to lists, we helped to explain these concepts where necessary during the testing.
-
-
-
-RAVS user included:
-
-- 1 service manager
-
-- 4 in house vaccinations teams in hospital settings
-
-- 5 antenatal midwives/nurses
-
-- 2 nurse in hospitals
-
-
-
-Positive feedback from the testing included:
-
-
-
-- Understood the concept of setting up appointments
-
-- Understood the potential benefits to having a list of pre-booked appointments in RAVS
-
-
-
-However, some pain-points for users included:
-
-
-
-- Lack of immediate understanding for the add NHS numbers and check pages
-
-- Without times, it wasn’t quite the same as the appointments systems
-
-
-
- ## Iterations
-As a team we discussed the feedback and considered our next steps. Whether we should iterate and improve the design to give needed clarity, or accept that sit may be better to wait until seamless integration with booking systems should be the preference to relocate time and effort elsewhere without committing to development.
-
-
-
-We decided to pursue iterating the designs given the time between now and when integration would be realistically ready, as well as the benefits that we could give, which were echoed by our users in testing.
-
-So we simplified the journey, looked at how we were using content across the piece and considered whether appointments was actually the correct term to use. We wondered whether we were trying to provide too much or being over-promising in our language. Instead, we decided that ‘Lists’ were a more appropriate way to describe the concept and didn’t require the user to have times allowed to each booking. Instead, we wanted to to see how they might use lists in-practice, with our assumption that settings such as maternity clinics, or for staff vaccinations (which so far have made up approximately 40% of vaccinations) there would be a real benefit to develop ‘Lists’.
-
-
-
-The designs were changed to include:
-
-
-
-- List home screen, with additional ‘How to use’ instructions
-
-- Select a date
-
-- Select a site
-
-- Add NHS numbers
-
-- ~~Check appointments~~
-
-- Appointments list
-
-![](lists-home.png)
-
-We removed the Check page and opted for better validation earlier on the  ‘Add NHS numbers page’ to reduce steps and hopefully simplify for the user.
-
-
- ## Next steps
-
-We decided that the next best course of action would be to develop and release Lists as a new feature and assess how well it is adopted and how easily it is used by RAVS users in the real world. Watch this space.
+We believe this will benefit a large cohort of our users, like staff vaccinations which account for 40%of our total vaccination records and maternity clinics
+This is because there isn’t always a specified time for the appointment and current processes we know of use informal lists without a booking system.
 
 
+## Designs part 2
 
 
+## Future
+In future we still wish to integrate automatically with booking systems, but for now we hope ‘Lists’ will give us an understanding of whether users benefit from this sort of feature in RAVS.
 
 
 Notification re-design:
@@ -210,11 +66,4 @@ The high level interruption card was also re-styled to be clearer and consistent
 
 
 
-![new notification](notification1.png)
-
-The high level interruption card was also re-styled to be clearer and consistent with other messages.
-![new interruption](interruption1.png)
-
-## Future
 
-We will need to continue to assess the effectiveness of these components through user testing and also keep speaking and learning from other services within the NHS which may share a similar problem, particularly staff facing products or services.