Create went-for-an-appointment-came-back-with-a-list

Author: johnrimmer2

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

@@ -0,0 +1,222 @@
+---
+title: "Went for an appointment, came back with a list s"
+date: 2025-07-11
+---
+
+
+## The challenge
+
+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.  
+
+ 
+
+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. 
+
+ 
+
+More specifically, some of the high level benefits we assumed would be: 
+
+ 
+
+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. 
+
+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. 
+
+ 
+
+ 
+
+As part of our assumption we determined that there were 2 feasible options on the table for how we might achieve this for RAVS. 
+
+
+
+### 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 
+
+ 
+
+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. 
+
+
+
+
+
+
+Notification re-design:
+
+![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)
+
+
+
+![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.